עקרונות פיתוח מערכות מידע

ברוכים הבאים לשיעור הממוקד ביחידת "עיצוב מערכות מונחה עצמים (OOD)" בקורס "עקרונות פיתוח מערכות מידע" (20436). יחידה זו מתמקדת בתכנון ארכיטקטורת המערכת ורכיביה בגישה מונחית עצמים, ומהווה גשר קריטי בין שלב ניתוח המערכת (OOA) לבין שלב המימוש. הבנה מעמיקה של עקרונות OOD חיונית ליצירת מערכות גמישות, ניתנות להרחבה ולתחזוקה, והיא נבחנת רבות ביכולתכם ליישם עקרונות אלו בתרחישים מעשיים.

מהו עיצוב מערכות מונחה עצמים (OOD)?

עיצוב מערכות מונחה עצמים (Object-Oriented Design - OOD) הוא השלב בתהליך פיתוח תוכנה שבו אנו מתרגמים את הדרישות והמודלים שנוצרו בשלב הניתוח (OOA) למבנה קונקרטי של המערכת. בשלב זה, אנו מתכננים את הארכיטקטורה הכוללת של המערכת, את המודולים, המחלקות, הממשקים והיחסים ביניהם, תוך התחשבות בעקרונות תכנון מונחי עצמים. המטרה היא ליצור עיצוב יעיל, קריא, ניתן להרחבה ולתחזוקה.

עיצוב מונחה עצמים (OOD): תהליך תכנון ארכיטקטורת תוכנה, מבנה המחלקות, הממשקים והיחסים ביניהם, תוך שימוש בעקרונות מונחי עצמים כדי לעמוד בדרישות המערכת.

ארכיטקטורת מערכת: המבנה הבסיסי של מערכת, המגדיר את רכיביה, את היחסים ביניהם ואת העקרונות המנחים את תכנונה והתפתחותה לאורך זמן.

עקרונות יסוד בעיצוב מונחה עצמים (SOLID)

עקרונות SOLID הם חמישה עקרונות תכנון מרכזיים המנחים את תהליך ה-OOD. יישום עקרונות אלו מוביל למערכות גמישות, מודולריות, קלות יותר לתחזוקה ולהרחבה. הבנה ויישום של עקרונות אלו הם אבן יסוד בהצלחה במבחן.

S - Single Responsibility Principle (SRP)

עיקרון האחריות היחידה: מחלקה צריכה להיות בעלת אחריות אחת ויחידה, וצריכה להיות רק סיבה אחת לשינוי בה.

O - Open/Closed Principle (OCP)

עיקרון פתוח/סגור: יש לתכנן ישויות תוכנה (מחלקות, מודולים) כך שיהיו פתוחות להרחבה (Open for extension) אך סגורות לשינוי (Closed for modification).

L - Liskov Substitution Principle (LSP)

עיקרון ההחלפה של ליסקוב: אובייקטים של מחלקת אב צריכים להיות ניתנים להחלפה באובייקטים של מחלקות בת מבלי לשבור את תקינות התוכנית.

I - Interface Segregation Principle (ISP)

עיקרון הפרדת הממשקים: לקוחות לא צריכים להיות תלויים בממשקים שאינם משתמשים בהם. עדיף מספר ממשקים קטנים וספציפיים על פני ממשק גדול וכללי.

D - Dependency Inversion Principle (DIP)

עיקרון היפוך התלויות: מודולים ברמה גבוהה לא צריכים להיות תלויים במודולים ברמה נמוכה. שניהם צריכים להיות תלויים בהפשטות (Abstraction). הפשטות לא צריכות להיות תלויות בפרטים, אלא הפרטים בהפשטות.

עקרונות SOLID: זהו נושא קריטי למבחן! שאלות רבות ידרשו מכם לזהות הפרות של עקרונות אלו בתרחיש נתון, להסביר מדוע הן בעייתיות, ולהציע פתרונות עיצוביים מתאימים. הבנה תיאורטית אינה מספקת; עליכם להיות מסוגלים ליישם את העקרונות הלכה למעשה.

כלים וטכניקות מרכזיות ב-OOD

דיאגרמות UML

שפת המידול המאוחדת (UML) היא סטנדרט למידול ויזואלי של מערכות תוכנה. ב-OOD, אנו משתמשים בדיאגרמות UML כדי לתאר את מבנה המערכת והתנהגותה באופן ברור וחד-משמעי. דיאגרמות מפתח כוללות:

דיאגרמת מחלקות (Class Diagram): מתארת את המחלקות במערכת, התכונות שלהן, הפעולות שלהן והיחסים ביניהן (אסוציאציה, ירושה, הרכבה).
דיאגרמת רצף (Sequence Diagram): מתארת את האינטראקציה בין אובייקטים בסדר כרונולוגי, ומציגה את זרימת המסרים ביניהם עבור תרחיש ספציפי.
דיאגרמת מקרי שימוש (Use Case Diagram): מתארת את הפונקציונליות של המערכת מנקודת מבטו של המשתמש (Actor). משמשת בעיקר בשלב הניתוח אך רלוונטית גם בעיצוב.

UML (Unified Modeling Language): שפה סטנדרטית למידול ויזואלי של מערכות תוכנה, המאפשרת לתאר את מבנה המערכת והתנהגותה באמצעות מגוון דיאגרמות.

תבניות עיצוב (Design Patterns)

תבניות עיצוב הן פתרונות מוכחים לבעיות עיצוב נפוצות בהנדסת תוכנה. הן מספקות שפה משותפת למעצבים ומאפשרות יישום פתרונות אלגנטיים ויעילים תוך שמירה על עקרונות OOD. דוגמאות כוללות Singleton, Factory, Observer ועוד. הבנה של תבניות עיצוב מסייעת ביישום עקרונות SOLID ובבניית מערכות גמישות.

תבנית עיצוב (Design Pattern): פתרון כללי וניתן לשימוש חוזר לבעיית עיצוב נפוצה בהקשר נתון.

מעבר מאנליזה לעיצוב ואתגרי OOD

המעבר מניתוח (OOA) לעיצוב (OOD) כרוך בהוספת פרטי מימוש. בעוד שבניתוח אנו מתמקדים ב"מה" המערכת צריכה לעשות, בעיצוב אנו מתמקדים ב"איך" היא תעשה זאת. אתגרים נפוצים כוללים:

הידוק צימוד (Tight Coupling): מצב שבו רכיבים תלויים זה בזה באופן חזק מדי, מה שמקשה על שינוי או החלפה של רכיב אחד מבלי להשפיע על אחרים.
לכידות נמוכה (Low Cohesion): מצב שבו רכיב (למשל, מחלקה) מבצע מספר רב של משימות שאינן קשורות זו לזו, מה שמקשה על הבנתו, שינויו ותחזוקתו.

OOD שואף להשיג צימוד רופף (Loose Coupling) ולכידות גבוהה (High Cohesion) באמצעות יישום עקרונות SOLID ותבניות עיצוב.

צימוד (Coupling): מידת התלות בין רכיבי תוכנה שונים. צימוד נמוך (רופף) עדיף.

לכידות (Cohesion): מידת הקשר הפנימי בין האלמנטים בתוך רכיב תוכנה. לכידות גבוהה עדיפה.

שאלות לדיון

נתונה מערכת לניהול ספרייה. תארו כיצד הייתם מיישמים את עקרון האחריות היחידה (SRP) עבור מחלקה המטפלת בספרים, וכיצד הייתם מונעים הפרה של עיקרון זה.
הסבירו את הקשר בין עקרון הפתוח/סגור (OCP) לבין שימוש בתבניות עיצוב. תנו דוגמה לתבנית עיצוב התומכת ב-OCP.
כיצד דיאגרמת מחלקות ודיאגרמת רצף משלימות זו את זו בשלב ה-OOD? מתי תבחרו להשתמש בכל אחת מהן?
נתונה מחלקה בשם PaymentProcessor המכילה מתודות לטיפול בתשלום בכרטיס אשראי, תשלום ב-PayPal וגם לניהול היסטוריית תשלומים. אילו עקרונות SOLID מופרים כאן, ומדוע? הציעו עיצוב חלופי.

נקודות לתשובת מודל

לגבי SRP בספרייה:
- הגדרת אחריות יחידה למחלקת Book (למשל, אחסון פרטי הספר).
- הפרדת אחריות לטיפול בפעולות כמו שמירת ספר במסד נתונים (למחלקה BookRepository) או הצגת פרטי ספר (למחלקה BookPresenter).
- הסבר כיצד הפרדה זו מונעת שינויים במחלקת Book כאשר משתנה לוגיקת שמירה או תצוגה.
לגבי OCP ותבניות עיצוב:
- הסבר ש-OCP דורש שהמערכת תהיה ניתנת להרחבה ללא שינוי קוד קיים.
- תבניות עיצוב רבות, כמו Strategy או Decorator, מאפשרות להוסיף פונקציונליות חדשה (הרחבה) על ידי הוספת מחלקות חדשות, מבלי לשנות את הקוד הקיים (סגור לשינוי).
- דוגמה: תבנית Strategy עבור שיטות תשלום שונות, כאשר כל שיטת תשלום היא מחלקה נפרדת המממשת ממשק משותף.
לגבי דיאגרמות UML:
- דיאגרמת מחלקות: מתארת את המבנה הסטטי של המערכת (מיפוי ישויות, תכונות, יחסים). משמשת לתכנון ארכיטקטורה כללית.
- דיאגרמת רצף: מתארת את ההתנהגות הדינמית של המערכת עבור תרחיש ספציפי (זרימת הודעות בין אובייקטים). משמשת לבדיקת תרחישים קריטיים ואימות אינטראקציות.
- הן משלימות זו את זו: דיאגרמת מחלקות מספקת את ה"שחקנים" (המחלקות), ודיאגרמת רצף מראה כיצד הם "משחקים" יחד בתרחיש מסוים.
לגבי PaymentProcessor:
- הפרת SRP: המחלקה אחראית על מספר דברים שונים (עיבוד תשלום בשיטות שונות וניהול היסטוריה). שינוי בשיטת תשלום אחת או באופן ניהול ההיסטוריה יחייב שינוי במחלקה זו.
- הפרת OCP: הוספת שיטת תשלום חדשה תחייב שינוי במחלקת PaymentProcessor הקיימת.
- עיצוב חלופי:
  - הפרדת האחריות: מחלקה PaymentProcessor כללית שתקבל ממשק IPaymentStrategy.
  - מחלקות ספציפיות כמו CreditCardPaymentStrategy, PayPalPaymentStrategy שיממשו את הממשק.
  - מחלקה נפרדת PaymentHistoryManager לטיפול בהיסטוריה.
  - הסבר כיצד עיצוב זה עומד בעקרונות SRP ו-OCP.

מצאתם טעות או שחסר משהו?