אפיון ועיצוב מערכות מוכוון עצמים - לפי UML -

1. אפיון ועיצוב מערכות מוכוון עצמים - לפי UML -

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

3. הסיבות לכישלון של פרויקטים • אין שיטה אחת ל←סימון/תיעוד מסמכים, לכן: • כול צוות פיתוח מתעד לעצמו • המסמך אינו מתאר ממש את סביבת הלקוח • אין שימוש חוזר בקוד • מוכוון עצמים • בהתחלה השפות: SMALLTALK, C++ • לאחר מכן שיטות הרישום NOTATION

4. וַיְהִי כָל הָאָרֶץ שָׂפָה אֶחָת וּדְבָרִים אֲחָדִים. וַיְהִי בְּנָסְעָם מִקֶּדֶם וַיִּמְצְאוּ בִקְעָה בְּאֶרֶץ שִׁנְעָר וַיֵּשְׁבוּ שָׁם. וַיֹּאמְרוּ אִישׁ אֶל-רֵעֵהוּ, הָבָה נִלְבְּנָה לְבֵנִים וְנִשְׂרְפָה לִשְׂרֵפָה; וַתְּהִי לָהֶם הַלְּבֵנָה לְאָבֶן וְהַחֵמָר הָיָה לָהֶם לַחֹמֶר. וַיֹּאמְרוּ, הָבָה נִבְנֶה לָּנוּ עִיר וּמִגְדָּל וְרֹאשׁוֹ בַשָּׁמַיִם, וְנַעֲשֶׂה לָּנוּ שֵׁם פֶּן נָפוּץ עַל פְּנֵי כָל הָאָרֶץ. וַיֵּרֶד ה' לִרְאֹת אֶת הָעִיר וְאֶת הַמִּגְדָּל אֲשֶׁר בָּנוּ בְּנֵי הָאָדָם. וַיֹּאמֶר ה', הֵן עַם אֶחָד וְשָׂפָה אַחַת לְכֻלָּם וְזֶה, הַחִלָּם לַעֲשׂוֹת; וְעַתָּה לֹא יִבָּצֵר מֵהֶם כֹּל אֲשֶׁר יָזְמוּ לַעֲשׂוֹת. הָבָה נֵרְדָה וְנָבְלָה שָׁם שְׂפָתָם אֲשֶׁר לֹא יִשְׁמְעוּ אִישׁ שְׂפַת רֵעֵהוּ. וַיָּפֶץ ה' אֹתָם מִשָּׁם עַל פְּנֵי כָל-הָאָרֶץ וַיַּחְדְּלוּ לִבְנֹת הָעִיר. עַל כֵּן קָרָא שְׁמָהּ בָּבֶל,כִּי שָׁם בָּלַל ה' שְׂפַת כָּל הָאָרֶץ, וּמִשָּׁם הֱפִיצָם ה', עַל-פְּנֵי כָּל-הָאָרֶץ. בראשית (יא, א-ט)

5. חשיבות הבנת הדרישות - סיפורו של פרוייקט עדכון ממשק המשתמש מה הבין מנתח המערכת רצון הלקוח חלומו של מעצב המערכת

6. איש מכירות תאר כך התמיכה.. התעוד הנלווה לפרוייקט סיפורו של פרוייקט (2) התוכניתן כתב

7. הלקוח חויב בעבור.. סיפורו של פרוייקט (3) המשתמש היה צריך...

8. התוצאה במציאות

9. מהו ניתוח מוכוון עצמים - OO • לא עוד טיפול בתהליכים. • לא עוד טיפול באירועים. • כעת מטפלים בעצמים - אובייקטים. • הלקוח במרכז ← המערכת היא כפי שהוא רואה אותה • גישת האובייקטים עוסקת בעולם האמיתי: לא בהסבות ורעיונות של אנשי מערכת מידע.

10. מהו אובייקט • כל דבר [מוחשי או וירטואלי] שקיים בעולם וניתן לייחס לו תכונות: אדם, ציפור, ספר, קורס, חשבון בנק

11. הכרות עם Unified Modeling Language • גרסה ראשונה בשנת 1997. • מטרת העל: יצירת שיטת סימון/תצוגה אחידה לאפיון ועיצוב מערכת מידע במתודולוגיה מוכוונת עצמים.

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

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

14. מרכיבי UML • Use Case Diagram - חלוקת המערכת לפונקציונליות לצורך הגדרת הדרישות. • Class Diagram - מודל המחלקות - המביע את החוקיות עליה מבוססת המערכת, כפי שקיימת בעולמו של הלקוח. • Sequence Diagram - התנהגות בעולם הלקוח ברצף הזמן, בחלוקה לפי הפונקציונליות שהוגדרה בשלב ה-Use Case.

15. מרכיבי UML • Collaboration Model- שיתוף מודל המחלקות וה-Sequence Model לצרכים שונים. • State Chart Diagram - מצבי האובייקט במחזור החיים. • Activity Diagram - פעילויות במערכת.

16. מרכיבי UML • Deployment Diagram- פריסת המערכת על חלקיה • Component Diagram - רכיבי מערכת המידע. • Object Diagram - תיאור האובייקטים במערכת.

17. UML - Unified Modeling Language • DFD ← פירוק עד לרמה מפורטת ביותר • אירועים ← • מתחילים באמצע • עולים ל"אירוע על" • יורדים/יוצרים פירוט לשגרות • UML ← עד לרמת הפירוט אותה מבקש הלקוח

18. שלבים בתהליך הפיתוח

19. אפיון מערכות מוכוון עצמים (1) OOAD • אובייקט ← הוא הדבר האמיתי, אם כי לא תמיד מוחשי • CLASS← תבנית לוגית הקובעת תכונות של העצמים הנגזרים ממנה, בעלי אוסף מוגדר של מאפיינים • ←אותה רשימת מאפיינים לכול האובייקטים, נבדלים בערכים שלהם: • הפשטה ← זווית ההסתכלות לפי שימוש או כוונת המתבונן • תכונות ← לפי סוגי שדות TYPE • שיטות ← פעולות (פונקציות, פרוצדורות) • קבלת מידע מ←האוביקט accessor, getter • שינוי המידע האצור באוביקטmutator • הכמסה של ה←class ← • כלפי חוץ יש רק הוראות/שיטות קישור/גישה, המבנה הפנימי אינו מעניין • - שיטת גישה פרטית ← רק האוביקט עצמו יודע על קיום תכונה ושיטה • + שיטת גישה ציבורית ← כול אוביקט מכול מחלקה המוגדרת בה תכונה ציבורית יודע על קיומה

20. אפיון מערכות מוכוון עצמים (2) OOAD • בנאי ← כול מחלקה יש לה בנאי הבונה אוביקטים • על ידי אתחול הערכים של האוביקט • מפרק ← סגירה של אוביקט, סימונו כמבוטל • תכונה • מחלקתית ← זהה בכול האוביקטים: שע"ח, מונה • סופית ← לאוביקט מסוים, אינה ניתנת לשינוי (ת.ז.) • קשרים בין מחלקות • אסוציאטיבי ← כיוון, מידת ריבוי (30 כסאות בכיתה), • אסוציאטיבי עצמאי ← קישור מחלקה אל עצמה מנהל ועובד • מחלקת קשר ← שומרת את הערכים של הקשר (תאריך ערך) • הכלה aggregation← רכב וגלגלים או הכלה חזקה/תלות פרק וסעיפים

21. אפיון מערכות מוכוון עצמים (3) OOAD • הורשה ← של תכונות ושיטות ממחלקה אל מחלקה • הורשה מרובה ← יורשת מיותר מאשר מחלקה אחת • הסימון הפוך לכיוון ההורשה • מוגן # ← הערך פרטי עבור כלל המחלקות למעט עבור מחלקות יורשות • רמיסה ← של שיטות (לא תכונות) על ידי היורשת: חלקית או מלאה • ריבוי צורות polymorphism בשל הרמיסה • הפעלת פעולה על אוביקט, מחפשת את הפעולה במעלה עץ ההורשה • ממשק ← מחלקה ללא תכונות, רק שיטות אשר היורשת חייבת לממש • מחלקה מופשטת ← לא ניתן לייצר ממנה אובייקטים • רק תכונות ושיטות הניתנות להורשה

22. ישויות, קשרים, יחסים שחקנים, תרחישים, אופני פעולה Use Case Model Class Diagram מקרא: מודל סטטי מודל דינמי מודל ניהולי “חבילות עבודה” Activity Diagram State Chart לוגיקה, זרימה התנהגות Package Diagram ארכיטקטורת התוכנה פונקציונליות, אינטראקציה Sequence Diagram Component Diagram Deployment Diagram UML - “מפת דרכים” ארכיטקטורת מערכת דרישות מערכת פריסת התוכנה על גבי החומרה

23. מסגרת הדיון: • מודל מקרי-שימוש (Use-Case Model) • “שחקנים” • מקרי-שימוש (use cases) • תרחישים • תרשים מקרי-שימוש (use-case diagram) • המודל הסטטי (Static Model) • מחלקות • קשרים • תלויות • תרשים מחלקות (class diagram) • המודל הדינמי (Dynamic Model): בד"כ יותר מאוחר, בשלב עיצוב התוכן • מצבים • מעברים • תרשימי מצבים (state-chart diagrams)

24. דוגמה לניתוח מונחה עצמים: מעלית רשימת הדרישות • המערכת מבקרת nמעליות המשרתות mקומות • בכל מעלית יש mכפתורים - אחד לכל קומה • עם הלחיצה על כפתור-מעלית • הכפתור מואר • המעלית מגיעה לקומה המבוקשת • הדלתות נפתחות והכפתור כבה • בכל קומה, פרט לראשונה ולאחרונה, יש שני כפתורים (לעליה ולירידה) • עם לחיצה על כפתור-קומה • הכפתור מואר • כאשר מעלית מגיעה לקומה המבוקשת - הדלתות נפתחות והכפתור כבה • לאחר השהיה נסגרות הדלתות והמעלית ממשיכה בכיוון המבוקש (אם ישנן בקשות קיימות) • כאשר אין בקשות למעלית, היא חונה בקומה הנוכחית כשדלתותיה סגורות

25. היכן נמצאים האובייקטים? היכן נמצאות הפונקציות? • המערכתמבקרת nמעליות המשרתות mקומות • בכל מעלית יש mכפתורים - אחד לכל קומה • עם הלחיצה על כפתור-מעלית • הכפתור מואר • המעלית מגיעה לקומה המבוקשת • הדלתותנפתחות והכפתור כבה • בכל קומה, פרט לראשונה ולאחרונה, יש שני כפתורים (לעליה ולירידה) • עם לחיצה על כפתור-קומה • הכפתור מואר • כאשר מעלית מגיעה לקומה המבוקשת - הדלתות נפתחות והכפתור כבה • לאחר השהיהנסגרות הדלתות והמעלית ממשיכה בכיוון המבוקש (אם ישנן בקשות קיימות) • כאשר אין בקשות למעלית, היא חונה בקומה הנוכחית כשדלתותיה סגורות שמות עצם עשויים לציין אובייקטים פעליםעשויים לציין פונקציות

26. תרשים מקרי שימוש (Use-Case Diagram) • שחקנים (Actors) • תפקיד שממלא משתמש כלשהו במערכת • משתמש אחד יכול למלא תפקידים שונים • כותב • מאייר • עורך • שחקן לא חייב להיות אנושי • חיישן • בקר • מקרי שימוש (Use Cases) • אופני ההפעלה של המערכת • אינטראקציה בין המערכת לבין שחקניה • תרחישים (scenarios) חיצוניים

27. Elevator User מעלית - UCD System Boundaries תרחיש נסיעה במעלית. מופעל עם הלחיצה על כפתור במעלית ride the elevator call the elevator תרחיש קריאה למעלית. מופעל עם הלחיצה על כפתור בקומה

28. קשרים בין Use Cases • Extend • UC אחד מרחיב UC אחר ע"י תוספת של התנהגות • ניתןלהגדיר את "נקודת ההסתעפות" (Extension Point) • Include • UC אחד כולל בתוכו את ההתנהגות של UC אחר

29. מעלית טכנאי משתמש מכבי אש מעלית - UCDמורחב repair & test <<include>> ride מפעיל קריאה / נסיעה כחלק מתהליך הבדיקה <<include>> <<extend>> call rescue <<extend>> מפעילים קריאה / נסיעה באופנים נוספים תוך שימוש במפתח מיוחד

30. מפרט UC - תיעוד קיימים גם "בעלי עניין" (stakeholders) ה-UC אמורים לשרת גם את האינטרסים שלהם! • בנוסף לתרשים, חייב כל UCלהיות מלווה בתיעוד, הכולל את הנושאים הבאים: • מטרת ה-UC • נועד למילוי משימה שתשרת שחקן אחד לפחות • רשימת השחקנים ותפקידיהם • "המערכת" איננה שחקן! • תנאים מקדימים (pre-conditions) • מה צריך להתקיים כדי שה-UC יוכל להתבצע כהלכה • תנאים לאחר מעשה (post-conditions) • מה השתנה לאחר סיום (מוצלח!) של ה-UC • תרחיש הצלחה ראשי (MSS = Main Success Scenario) • האינטראקציה העיקרית בין השחקנים לבין "המערכת" שתביא לקיום התנאים לאחר-מעשה [ללכת בתל"מ] • הסתעפויות (branches) • חלופה (alternative) ["אלתר נתיב"] • השגת התל"מ באופן שונה • חריגה (exception) • מסלול שיביא לסיום ה-UC מבלי שיתקיימו התל"מ

31. - מעליתuse-case • שחקנים (Actors) • משתמש (נוסע) • תנאים מקדימים (pre-conditions) • המשתמש נמצא בתוך המעלית והמעלית "בכיוון" עלייה • תנאים לאחר-מעשה (post-conditions) • המעלית הגיעה לקומה המבוקשת • הנוסע יכול לצאת מהמעלית

32. (המשך) - מעליתuse-case • תרחיש הצלחה ראשי - MSS • המשתמש לוחץ על כפתור המעלית של הקומה המבוקשת • כפתור הקומה נדלק • דלתות המעלית נסגרות • המעלית עולה לקומה המבוקשת • המעלית נעצרת • הדלתות נפתחות • כפתור הקומה כבה • (אם הגיע לקומה המבוקשת - המשתמש יוצא מהמעלית) • לאחר השהיה נסגרות הדלתות

33. (המשך) - מעליתuse-case • הסתעפויות • חלופה: הקומה המבוקשת נמצאת מתחת לקומה הנוכחית • 4א - המעלית עולה לקומה העליונה ביותר שהתבקשה • 4ב - המעלית יורדת לקומה המבוקשת • חלופה: "מעלית שבת" • 1 - בטל. • 4-9 - חוזר בכל קומה בדרך • חריגה: עצירת חירום (יזומה ע"י המשתמש) • 6-9 - בטלים

34. מזהה מאפיינים פעולות תרשים מחלקות (Class Diagram) • מחלקה (class) • מזהה (identifier) • מאפיינים (attributes) • ממומשים באמצעות מבני נתונים • פעולות (operations) • ממומשות באמצעות שגרות / פונקציות • זיקה (association) בין מחלקות • סוג הזיקה (ירושה, הכלה, ...) • תפקיד (role) • ריבוי (multiplicity)

35. Class Stereotypes • Entity • Boundry • Controller • Abstract מחלקה ללא אוביקטים • Interface למנוע הורשה מרובה • Actor תת תוית של הישות, הרשאות • Policy חוקי ארגון כמו מחירונים

36. Button Elevator illuminated: Boolean doors_open: Boolean m 2m - 2 communicates with communicates with 1 n מעלית - תרשים מחלקות (גרסה ראשונה) ירושה inheritance Elevator Button Floor Button זיקה association

37. Elevator Doors Button doors_open: Boolean illuminated: Boolean מעלית - תרשים מחלקות (גרסה מתקדמת) Elevator Button Floor Button mn 2m - 2 controls controls 1 Elevator Controller 1 1 1 controls controls n n Elevator

38. זיקה - Association • “הכרות” בין עצמים ממחלקות שונות • סוגים מיוחדים של זיקה • ירושה, הכללה (inheritance, generalization) • הגדרת מחלקה על בסיס מחלקה אחרת • הכלה, הקבצה (aggregation) • עצם ממחלקה כלשהי “מכיל” עצמים ממחלקה אחרת • זוג סדור של שתי מחלקות • עצם ממחלקה B "מכיר" עצם ממחלקה A

39. זיקה - Association • מאפייני הזיקה • שם (name) • סדר (ordering) • האם הזיקה היא מ-Aל-B, או להיפך? • תפקיד (role) • מה תפקידו של כל אחד מהעצמים בקשר • ריבוי (multiplicity) • האם הזיקה קיימת תמיד? • האם ההכרות היא עם יותר מעצם אחד?

40. Insurance Policy Insurance Contract Insurance Company Person 1 refers to 0..1 refers to 1..* 0..* has is expressed in a 0..* wife husband refers to has 1 married to דוגמאות לזיקה name multiplicity policy holder role insurer זיקה עצמית self association

41. employee employer 0..* * Person boss 0..1 Job worker * salary Company מחלקת זיקה (Association class) • לפעמים לזיקה עצמה ניתן לתת מעמד של מחלקה • association class • association part • visual tie • class part

42. A B מאפיינים מאפיינים פעולות פעולות ירושה (Inheritance) • מחלקה Bיורשת את מחלקה A: • Bמכילה את כל המאפיינים של A • Bמכילה את כל הפעולות של A • בנוסף, Bמכילה מאפיינים ופעולות משל עצמה • “B is-a A” • Bהיא תת-מחלקה (sub-class) של A • מינוח לא מוצלח, כי ב’ מכילה יותר מאשר א’ • Bהיא הכללה (generalization) של A • דוגמאות לירושה: • דוגמה רעה: ריבוע יורש מלבן • דוגמה טובה: ריבוע ומלבן יורשים מרובע

43. B A B A הקבצה (Aggregation) • כל עצם ממחלקה Bמכיל עצם (עצמים) ממחלקה A • “A is-part-of B” • שני סוגי הקבצה: • ל-Aיש קיום גם ללא B • שמות נוספים: • logical aggregation • shared aggregation • קיומו של Aתלוי בקיומו של B • שמות נוספים: • physical aggregation • non-shared aggregation • composition

44. 1 {ordered} 3..* Circle Point Polygon radius * * Style 1 color isFilled 1 דוגמאות להקבצה • הקבצה פיסית (composition) • למעגל יש נקודה אחת (מרכז) • נקודת המרכז משויכת אך ורק עם מעגל זה • קיומה של נקודת המרכז מותנה בקיומו של המעגל • הקבצה לוגית (aggregation) • לפוליגון יש סגנון • סגנון יכול להיות משותף למספר פוליגונים • הסגנון הוא ישות עצמאית, וקיומו אינו מותנה בקיום פוליגון • כיוון (navigation) • המעגל “מכיר” את הסגנון • הפוליגון “מכיר” את הסגנון • הסגנון אינו נדרש להכיר את העצמים המפנים אליו...

45. Building Theater Seat תלות - Dependency • יחס (relationship) בין שתי ישויות • ישות עצמאית • ישות תלויה • שינוי כלשהו בישות העצמאית עלול להשפיע על הישות התלויה • תלות יכולה להתקיים גם בין ישויות שאין ביניהן זיקה (association) כלשהי • לדוגמה: עצם ממחלקה כלשהי מועבר כפרמטר לפונקציה של מחלקה אחרת • כיוון התלות לא בהכרח זהה לכיוון הזיקה

46. UML Diagram Usage - Summary

47. שלב 2/3 ← אפיון דרישות עדיף יחד עם העיצוב הלוגי Use Case Diagram • תרשים המבטא את הדרך בה המשתמש מפעיל את המערכת שדות תקניים לתיאור: Name Assumptions Identifier Basic course of Action Description Alternate course of Action Actors Change History (change control) Frequency (open) Issues Pre Conditions Decisions (for next version) Post Conditions Extend / Include

48. שלב 4 ← הגדרת החוקיות Class Diagram המודל הסטטי ← מתאר את החוקה העסקית בארגון • תרגום של ה← Use Case • שמות העצם ← מחלקות • תיאור שמות העצם ← תכונות • פעלים ← שיטות • תרגום ה← ERD • הוספה של השיטות • הגדרה של ההורשה

49. שלב 5 ← התנהגות על פני ממד הזמן (1) Sequence Diagram המודל הדינמי • האוביקטים, לא המחלקות, הם החיים בממד הזמן • ציר Y ← האנכי ← הוא ממד הזמן • התרשים מבטא את התנהגות האוביקטים בתהליך • אילוצים: תנאי או התניית ביצוע בקיום ביטוי מסוים • הערות: בעיקר ה← Use Case • יצירה ופירוק

50. שלב 5 ← התנהגות על פני ממד הזמן (2) Collaboration Diagram תרשים שיתוף • שיתוף בין ה← Class Diagram לבין Seq. Diagram • קשר בין המחלקות, ללא ממד זמן, בהקשר של האוביקטים • נועד לבדוק נכונות של התרשימים הקודמים