המודל הסטטי- הרחבות

• המודל הסטטי  ((Static Model עוסק בעיקר בבניית תרשים המחלקות ובאפיון הקשרים שביניהן גם הוא הרחבות ועידון במסגרת שלב העיצוב. פרק העיצוב שאחת ממטרותיו הרחבת הידע משלב הניתוח, עוסק בנקודות הבאות:

• סטריאוטיפ

• שיקולים בקשירות בין מחלקות

• מבנה הורשה

• נראות

• ועוד... מחלקות נוספות

 <<Stereotype>>

• דרך המאפשרת להרחיב כל אחד ממרכיבי המודל הסטטי

• הרחבות אלו מייצגות בשלב העיצוב את המחלקות הבאות:

<<Actor>>

<<Interface>>

<<Abstract>>

<<Control>>

<<Policy>>

<<ועוד...>>

<<Stereotype>> ומחלקות מידע <<Entity>>

• מחלקה המתארת מידע

• מחלקה זו מזוהה בניתוח תחום המשתמש, ה-User Domain, עוברת "עיבוד" ו"הרחבה" בשלב הניתוח, ועידון נוסף בשלב העיצוב

• מחלקות אלו יהוו את התשתית לבניית בסיס הנתונים, אליהן תהיה גישה במימוש האפליקציה

<<Stereotype>> ומחלקות ממשק <<Interface>>

• מחלקה המייצגת את הממשקים הגלויים למחלקות המידע וה"אחרות"

• היבט אחר- מחלקת ה- <<Interface>> מייצגת אילו שירותים ניתן לקבל ממחלקות ה"מידע" וה"אחרות" הקשורות לממשק

• מחלקה אופיינית ב- <<Interface>> מייצגת את המסרים אותם רואה הצרכן, ואחראית למסרים לצורך ניהול ה- USE CASE (טרנסקציה)

    <<Interface>> ו- <<Actor>>

• <<Interface>> מייצג אתחול של USE CASE אחד, ואליו קשור בד"כ אובייקט  <<Actor>>

• המדד לאובייקט  <<Interface>> טוב, היא מידת היכולת לנתק או לנטרל אותו מהשינויים באפליקציה

• אתחול  (Trigger) או<<Actor>>   יכול להיות גם אמצעי מחשוב, ה-  <<Interface>> חייב להגיב בהתאמה

   

<<Stereotype>> ומחלקות ניהול <<Control>>

• אחת הבעיות בעיצוב מונחה אובייקטים, היא הענקת אחריות ניהול למחלקת ה"מידע"

• רצוי שיהיה מרכיב במערכת אשר ינהל את אירועי המערכת וזה תפקידו של ה- Controller

• ה- Controller (מיוצג כ- <<Control>>) יפקח על ביצוע ה- USE CASE ולעיתים "יאציל" סמכויות ניהול למחלקות מידע (<<Entity>>) ול"אחרות"

• פתרון אפשרי לסוגיית סמכויות הניהול- חלוקה אפשרית של סמכויות הניהול וסמכויות הביצוע, בדרך של הקצאת פעילויות למחלקות המידע  (<<Entity>>) וסמכויות ניהול למחלקות המנהלות (<<Control>>)

   

<<Stereotype>> ומחלקות מדיניות <<Policy>>

• מחלקות באפיון זה, נובעות מהמגמה להפרדה בין המחלקות המייצגות מדיניות לבין אלו של ה"מידע"

• הפרדה זו מאפשרת שמירה עי העיקרון, לפיו מחלקות ה"מידע" אינן חייבות לעבור שינוי, עם כל שינוי של מדיניות

• לדוגמא, שינוי מדיניות לגבי לקוחות או לגבי חשבונות בנק וכו' , לא בהכרח גורר אחריו שינוי במחלקות ה"מידע" או בגישה אליהן 

<<Stereotype>> ומחלקות מנהל גישה <<Shared Objects>>

• המחלקה מייצגת גישה אחידה אל בסיס הנתונים, ומכילה את קוד ה- SQL, בהתאמה למחלקות המידע

• ניתן להטיל מחלקה זו לנהל גם את סדר ביצוע הגישות אל בסיס הנתונים

<<Stereotype>> ומחלקות מנהל הודעות <<Messages >>

• ניתן להגדיר את מנהל ההודעות כ"נתב" למחלקות, המבקשות ממנו שירות זה

• הצעד הראשון- "הרשמה" אצל המנהל

• הצעד הבא- מנהל ההודעות מקבל מסר, וזה "מפיץ" אותו למחלקות, בהתאמה לסוג המסר

• יכולות להיות מוגדרות בקשות זהות לקבלת הודעות ממחלקות שונות

קשירות בין מחלקות- עקרונות

• צימוד

• מי צריך לדעת

• גיבוש חזק

צימוד Coupling

• הגדרה- רמת ה"אי תלות" בין מרכיבים

• העיקרון המנחה- תלות מינימאלית

• התוצאה- שינויים אשר באופן טבעי מתרחשים במערכת, השפעתם ברמה ה"מקומית"

• השאיפה- קשירות מינימליסטית בין מחלקות וצמצום תגובת שרשרת

• אילוץ- לא ניתן לממש אי תלות מוחלטת, מאחר וגישת האובייקטים בעיקרון מייצגת קשירות ושיתוף

"מי צריך לדעת"?

• זהו אחד העקרונות המייצג קשירות בין מחלקות, בדומה לקשירות בעולם האמיתי

• כמו בחיים, הקשר צריך להיות בין אלו שחייבים לדעת האחד אודות השני, במגמה לבצע את תפקידם

גיבוש חזק Strong Cohesion

• הגדרה- חלוקה "הגיונית" של הפעילויות במערכת, במסגרת המחלקות השונות

• העיקרון המנחה- מיקוד פעילויות אשר להן זיקה מרבית משותפת במחלקה- Strong Cohesion

• התוצאה- מחלקות כיחידות פיתוח "ברות שליטה" ושינויים בנושא ייחודי במערכת, ברמה "מקומית"

• אילוץ- לא ניתן לממש זיקה משותפת מוחלטת, מאחר וגישה זו נוגדת את עיקרון האצלת הסמכויות

• עיקרון ה- Strong Cohesion מחייב האצלת סמכויות למחלקות אחרות, כפי שמוצג בדוגמא, המגמה לקבל "יחידות" ברות שליטה

• מן הראוי להגדיר במקרה של פתיחת מופע חדש <<New>>) ) שתי מחלקות נפרדות וקשורות ביניהן- האחת הכוללת את המידע לפתיחת המופע החדש, והאחרת אשר במסגרתה ניבנה המופע החדש

מבנה הורשה (Inheritance)

• הרחבות נוספות בהיבט ההורשה

-        מחלקה מופשטת

-        מימוש הורשה

-        פולימורפיזם

-        אילוצים והכלה

הורשה- העיקרון

G. Booch: " ...הורשה מייצגת "מנגנון" הפעלה בין מחלקות, כאשר מחלקה אחת, ה- Super Class, משתפת בנתונים או בפעילויות מחלקות אחרות, הן ה- Sub Classes... "

" ...לכל מופע במחלקות ה"ייחודיות" יש תכונות נוספות משל עצמן..."

• בעיקרון, מסר הוא בקשת שירות הנשלחת למחלקה "מקבלת"

• במחלקה המקבלת את המסר, מופעל ה- Method המבוקש בהתאמה

• אם במחלקה המקבלת לא קיים ה- Method, מועבר המסר למחלקה ברמה עליונה יותר במבנה ההורשה עד למצאו

הורשה- סוגי מחלקות

• מחלקה "מופשטת" <<Abstract>> אינה יודעת, או אין ביכולתה ליצור אובייקטים

• לחילופין, מחלקה אשר יש ביכולתה ליצור אובייקטים מוגדרת מחלקה "קונקרטית" <<Concrete>>

• בשלב האפיון קיימת נטייה לעסוק ב"עולם האמיתי" ואז יש להניח מוגדרות המחלקות ה"קונקרטיות"

• בשלב העיצוב עיקר העיסוק במימוש, לרבות הגדרת אלגוריתמים, ואז יש להניח מוגדרות המחלקות ה"מופשטות"

פולימורפיזם- Polymorphism

• הגדרה- יכולת אובייקטים מתתי מחלקות- Sub Classes, תחת מחלקת-על Super Class משותפת, להעניק שירותים בתגובה לאותו מסר, כל אובייקט בדרכו שלו

• המימוש- במקרה זה לא יועבר המסר כלפי מעלה במנה ההורשה

• המשמעות- ניתן ל"החליף" את ה- Method במסגרת תתי המחלקות- Overriding

הורשה- סוגי פעילויות

• לסוגי המחלקות השונות יכולות להיות "פעילויות קונקרטיות" או "פעילויות מופשטות"

• פעילות מופשטת- מחויבת במימוש במסגרת תתי המחלקות, קיימת רק במחלקה "מופשטת", חייבת להיות רב-צורתית- Polymorphic

• פעילות קונקרטית- ניתנת למימוש רק במסגרת המחלקה בה היא מוגדרת, לרבות מחלקה "מופשטת", אך יכולה להיות "מוחלפת"- Overriding, בתתי המחלקות

הורשה- אילוצים והכלה

• ניתן לתאר אילוצים- Constrains , במבנה עץ ההורשה

אפיונים:

• {Disjoint} מייצג הורשה יחידנית

• {Overlapping} מייצג הורשה מרובה

• {Complete} הגדרה שלמה של תתי מחלקות

• {Incomplete} הגדרה לא שלמה של תתי מחלקות

נראות Visibility

• לכל מחלקה יש תכונות (מאפיינים ופעילויות), "ציבורי"- Public ו/או "פרטי"-  Privateו/או חסוי- Protected

• התכונה "ציבורי" ניתנת לגישה לכל אחת מהמחלקות- סימול (+)

• התכונה "חסוי" ניתנת לגישה ע"י תתי המחלקות, ה- Sub Classes- סימול (#)

• התכונה "פרטי" ניתנת לגישה רק מתוך המחלקה עצמה- סימול (-)

לסעיף הבא- הרחבות במודל הדינאמי...