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

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

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

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

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

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

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

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

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

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

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

12. מטרות 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. שלבים בתהליך הפיתוח 1 2 3 4 5 6 חקר מצב קיים DFD
הגדרת דרישות (רק כאן המשתמש מעורב מלא)
זהו כתב הכמויות, ההסכם של התכולה
תרשים
תיאור הפונקציונאליות (תקן לסעיפים)
Use case 3
תיאור מפורט/אפיון של תוצר שלב 2
שימוש בתפישת OOAD מיוצגת על ידי UML
תרשימים בסימון #SQ, #UC
Use Case Documentation 4
הגדרת החוקיות בעולם של הלקוח
Class Diagram 5
הגדרת ההתנהגות של הפרויקטים בממד הזמן
Dynamic Diagrams 6
התכנון הפיסי, ההתקנות
All Others

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

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

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

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

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. מופעל עם הלחיצה על כפתור במעלית מופעל עם הלחיצה על כפתור בקומה
אפיון מונחה עצמים
מבוא להנדסת תוכנה
מעלית - UCD
System Boundaries
תרחיש נסיעה במעלית.
מופעל עם הלחיצה על כפתור במעלית
Elevator
ride the elevator
User
call the elevator
תרחיש קריאה למעלית.
מופעל עם הלחיצה על כפתור בקומה
© , ד"ר עמיר תומר

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

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

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

31. - מעליתuse-case שחקנים (Actors) תנאים מקדימים (pre-conditions)
משתמש (נוסע)
תנאים מקדימים (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
illuminated: Boolean
ירושה
inheritance
Elevator Button
Floor Button
communicates
with 1 m
communicates
with
2m - 2 n
Elevator
doors_open: Boolean
זיקה
association

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

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

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

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

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

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

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

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

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

46. UML Diagram Usage - Summary
How does ProVision use the UML?
The goal of each phase of ProVision is to produce a specific kind of knowledge -- a list of requirements, a description of how requirements can be met, a working and deployed system. Each of those goals is supported by some of the UML diagrams, as shown above. This does not mean there is no place for other diagrams. Keep in mind that the goal of the UML is to facilitate communication between those producing a specific kind of work product, and between those taking one kind of work product, and using it to develop other work products.

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. Class Diagram המודל הסטטי ← מתאר את החוקה העסקית בארגון
שלב 4 ← הגדרת החוקיות
Class Diagram המודל הסטטי
← מתאר את החוקה העסקית בארגון
תרגום של ה← Use Case
שמות העצם ← מחלקות
תיאור שמות העצם ← תכונות
פעלים ← שיטות
תרגום ה← ERD
הוספה של השיטות
הגדרה של ההורשה

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

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

51. State machine תרשים (מכונת) מצבים
שלב 5 ← התנהגות על פני ממד הזמן (3)
State machine תרשים (מכונת) מצבים
המנתח מכין עבור התוכניתנים:
המצבים השונים של אוביקט מסוים במחזור חיי המערכת
לעתים תוך ציון הערכים של התכונות
האירועים המשפיעים על מצבו
סדר האירועים
התנהגות סדרתית של האוביקט
מצבים מיוחדים:
לא ניתן להגיע אליו
מבוי סתום, אי אפשר לצאת ממנו

52. Activity Diagram תרשים פעילויות
שלב 5 ← התנהגות על פני ממד הזמן (4)
Activity Diagram תרשים פעילויות
בשלב האפיון או העיצוב, להמחשה של ה← Business Logic
דומה לתזרים זרימה

53. התרשימים ↔ החוקים העסקיים, ללא פירוט התכונות
Use case Diagram
Use case Description
חלוקת המערכת לפונקציונאליות לצורך הגדרת הדרישות
Class Diagram
Sequence Diagram
Collaboration Diagram
State Chart Diagram
↔ החוקים העסקיים, ללא פירוט התכונות
↔ התנהגות בעולם הלקוח ברצף הזמן
לפי הפונקציונאליות של ה←Use Case
↔ שילוב של CD ו← SD
↔ מצבי האוביקט במחזור החיים
Activity Diagram
↔ הפעילויות במערכת בחלוקה לתחומי אחריות
Component Diagram
הרכיבים
Deployment Diagram
תרשים תלויות ← פריסה לוגית, גיאוגרפית/ע"ג החומרה
Object Diagram
תרשים האוביקטים

54. שימוש בתרשימים ↔ החוקים העסקיים, ללא פירוט התכונות
אפיון דרישות
Use case Diagram
Use case Description
את תיאור המצב הקיים תיארנו DFD או ERD
ניתוח +
עיצוב לוגי
Class Diagram
Sequence Diagram
אם צריך:
Object Diagram
Collaboration Diagram
State Chart Diagram
↔ החוקים העסקיים, ללא פירוט התכונות
↔ הפונקציונאליות, עץ המסכים
תיאור התהליכים באמצעות המודל הדינמי
להתחיל שלבי פריסה ומימוש
בסיס הנתונים ← הגדרת Entity והסוגים של התכונות
עיצוב
Activity Diagram
התייחסות לטכנולוגיה:
← פירוט של כול תרשימי האפיון
← פירוט כול תהליך/אירוע כולל רמת האבטחה
← הוספה של המסכים ל←Class Diagram
← שגרות דרך הגדרת השיטות וה←Controllers
באמצעות Activity Diagram או עברית מבנית
← Class הופך לטבלה
מימוש
Component Diagram
בנייה של קבצים, הוספה של תרשים המרכיבים
פריסה
Deployment Diagram
תלויות ← פריסה גיאוגרפית/ע"ג החומרה

55. MVC - Data Model View Controller
חלוקה של ה← Class Diagram
Entity מחלקות מידע ← מאגר נתונים
Boundry מחלקות תצוגה: מסכים, דוחות
Controllerמחלקות ניהול:
השולפות מהתצוגה, מעבדות ושומרות
שולפות ממאגר הנתונים, מעבדות ושומרות
כול מסך הוא אוביקט, הקשר הוא על ידי עץ המסכים

56. CASE - Computer Aided Software Engineering
כלי אשר:
אליו מגדירים את ה←UML
Upper Case ← ניהול האפיון, העיצוב, הבדיקות
Lower Case מפתח את:
בסיס הנתונים
התוכנה

57. שאלות ?
תרשימי UML