UML

[ברנדל]

יש לי כבר ספר כזה

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

 

[הצלוי]

אני אנסה להסביר את המושגים עצמם

שימו לב שאני לא מבין מאוד בUML, אז תבדקו את התשובות שלי. אני כותב את זה מהיגיון וניסיון מועט שלי בנושא. אני אשתמש במחלקות Parent וChild בדוגמאות... (בכל דוגמא יהיו מאפיינים אחרים) dependency- תלות מחלקות. נניח שבParent יש איזשהוא אובייקט כמו מטריצה בוליאנית, וChild מחזיק יחס אליה. Child תלוי בParent כי כל פעם שהמטריצה תשתנה, כך גם Child. דוגמא לכך ב"משחק החיים"- ששאלתי עליה עוד היום. תסתכל שם. aggregation- שלם וחלקיו. בParent יש מופע של המחלקה Child. הוא "מורכב" מאובייקט של Child. שים לב להבדל בין זה לcomposition! פה המופע של Child יישאר קיים גם אחרי שנמחק את Parent. מתי זה יקרה? למשל אם נקבל מופע קיים של Child בפונקציה כלשהיא של Parent ולא ממש ניצור את המופע. composition- לחלק אין "זכות קיום" בלי השלם. כמו הקודם, רק שהפעם המחלקה עצמה (Parent) יוצרת את החלק Child, ולכן מתי שהשלם יימחק, כך יימחקו גם חלקיו. generalization- הירושה הבסיסית. Child היא מחלקה "מפורטת" יותר של Parent- לדוגמא "מכונית" ו"פיאט", "סובארו" או משהו.. אז Child יורש את התכונות של Parent ומוסיף עוד תכונות ספציפיות לChild. realization- מימוש ממשק. Parent היא מחלקה אבסטרקטית, או ממשק (אף פעם לא ממש הבנתי את ההבדל ביניהם.. ) ללא שום מימוש או גוף, וChild פשוט מממשת את הממשק. זה בערך קיצוניות של generalization... בקשר למושגים האחרים association וassociation navigation האמת שאין לי מושג כללי מדי.. מה זה "קשר בין מחלקות"? השאר לא היו קשרים בין מחלקות?....

 

[אוֹריארד]

הבהרות...../images/Emo26.gif

לגבי association - הוא מייצג קשר בין המופעים של המחלקות... כלומר בין אובייקט של Customer לבין אובייקט של Order. ולא - "השאר" לא היו קשרים בין מופעים. כשיש לך קשר של הורשה (generalization) למשל - הקשר הוא לא בין אובייקט של Poligon לבין אובייקט של Triangle... שאלת גם מה ההבדל בין מחלקה אבסטרקטית לבין interface - במחלקה אבסטרקטית חלק מהמתודה יכולות להיות ממומשות, ב-interface יש רק חתימות של המתודות ללא מימוש כלל.

 

[אוֹריארד]

טוב, ננסה:...generalization

generalization זה:

public class poligon { ... } public class triangle extends poligon { ... }​

ואז יהיה לך חץ מ-triangle ל-poligon עם "ראש-חץ" משולש ריק.

 

[אוֹריארד]

realization ../images/Emo26.gif

החץ הוא כמו של generalization אבל הקו מקווקו.

public interface animal { ... } public class dog implements animal { ... }​

 

[אוֹריארד]

association ../images/Emo26.gif

טוב... אז נניח שיש קשר association בין מחלקה order למחלקה customer. הקשר הוא one-to-many, כלומר לכל לקוח יכולות להיות כמה הזמנות. הקוד יכול להיות:

class Order { public Customer getCustomer(); ... }​

אבל... הוא יכול להראות גם ככה:

class Customer { public Set getOrders(); ... }​

ויתכן גם שיהיה קשר דו-כיווני - כלומר, שגם ב-Customer ישב Collection של Order וגם ב-Order ישב reference ל-Customer. הקשר של association לא נותן לך את המידע הזה.

 

[אוֹריארד]

navigability ../images/Emo26.gif

בהמשך לדוגמה הקודמת של association, במקרה ורוצים להוסיף את המידע (האם ההזמנה מחזיקה את הלקוח או הלקוח מחזיק את ההזמנות), אפשר להוסיף חץ (navigability) בקשר של ה-association. אם לדוגמה יהיה חץ שמכוון ל-Customer אז נדע ש-Order "מכיר" את Customer ולא ההפך. ואז הקוד יכול להראות כמו בדוגמה הראשונה בהודעה הקודמת:

class Order { public Customer getCustomer(); ... }​

 

[אוֹריארד]

תרשים לשתי ההודעות:../images/Emo26.gif

 

[הצלוי]

עכשיו זה מובן../images/Emo13.gif

 

[ברנדל]

תודה

לזה התכוונתי פשוט דיברתי על c++ לא מכיר java. אם מישהו יכול שיראה מימוש כזה ב c++. אם לא אז אני אנסה להבין לבד. ושוב תודה.

 

[אוֹריארד]

מ-CPP ל-Java../images/Emo26.gif

זה די דומה בעקרון - איפה שכתבתי Set אתה יכול להחליף בכל container של STL, למשל:

vector<Orders> orders;​

interface מבחינתך זה מחלקה שכל המתודות שלה הן pure virtual. (ו-realization זה קשר של מחלקה שיורשת מכזו מחלקה). ומבחינת הקוד ששמתי ל-realization ו-generalization ב-CPP אני מניח שזה יראה זהה:

class dog: public animal { ... } class triangle: public poligon { ... }​

או משהו כזה, לא?.. (כש-animal היא מחלקה שכל המתודות שלה pure virtual ו-poligon מחלקה רגילה, אם רוצים להיות קונסיסטנטים לדוגמאות שהבאתי ב-Java)

 

[ברנדל]

אחת הבעיות שלי:

אם כל navigability זה גם assosiation רק שהראשון נותן יותר מידע, אז למעשה לעולם אין צורך להשתמש ב assosiation. כי תמיד ניתן לשים איזה חץ יותר ספציפי. לא?

 

[הצלוי]

אולי צריך להשתמש בassosiation

כשיש קשר דו-כיווני במקום חץ לפה וחץ לשם- כשהם משתמשים אחד בשני..?

 

[אוֹריארד]

זה בדיוק חלק מהעניין...../images/Emo26.gif

לפעמים מי שעושה design דווקא לא ירצה להגביל את מי שמממש... אתה מבין?... אני רק אתן את הקשר בין היישויות - אתה כבר תעשה את שיקולי המימוש שלך ותחליט מי יצביע למי... כמו גם אם להשתמש בפויינטר או ברפרנס, או אם להשתמש ב-set או ב-vector... לפעמים אני דווקא ארצה שתדע שלא איכפת לי מי "יצביע" על מי במימוש... למשל בדוגמה של ה-Customer וה-Order - ב-Problem Domain לא ממש ברור מי "מכיר" את מי... אין כיוון מובהק מההזמנה ללקוח או מהלקוח להזמנה... את ההחלטה אתה תעשה באימפלמנטציה עפ"י השיקולים שלך - אבל זה יהיה משיקולי-מימוש ולא משיקולי design! לכן אם ה-Class Diagram מתאר את מודל ה-Design (או אפילו ה-analisys) זה יהיה לא נכון להשתמש שם ב-navigability...

 

[hatulflezet]

יצא כאן דווקא שירשור לא רע בכלל

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