Transcript יעדי הפרוייקט

‫קורס ניתוח מערכות מידע‬
‫אפיון ועיצוב מערכות מוכוון עצמים‬
‫‪ -‬לפי ‪- UML‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫הקדמה‬
‫‪ ‬המערכות שפותחו בעבר היו קטנות ביחס‬
‫למערכות מהידע הקיימות כיום‪.‬‬
‫‪ ‬מירב הפרויקטים אינם מצליחים או אינם‬
‫מגיעים לכדי הסיום המתוכנן‪.‬‬
‫‪ ‬כל מתכנן מע' מידע משתמש בשיטת סימון‬
‫ייחודית לו שהנה כמעין שפה שונה לגמרי‪.‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪2‬‬
‫קורס ניתוח מערכות מידע‬
‫הסיבות לכישלון של פרויקטים‬
‫אין שיטה אחת ל←סימון‪/‬תיעוד מסמכים‪ ,‬לכן‪:‬‬
‫כול צוות פיתוח מתעד לעצמו‬
‫המסמך אינו מתאר ממש את סביבת הלקוח‬
‫אין שימוש חוזר בקוד‬
‫מוכוון עצמים‬
‫בהתחלה השפות‪SMALLTALK, C++ :‬‬
‫לאחר מכן שיטות הרישום ‪NOTATION‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫ּודב ִ‬
‫ָרים אֲ חָ ִדים‪ .‬וַי ְִהי ְבנָסְ עָ ם‬
‫ָארץ שָ פָ ה אֶ חָ ת ְ‬
‫וַי ְִהי כָל הָ ֶ‬
‫ִמקֶ ֶדם וַ ִימְ צְאּו ִבקְ עָ ה בְאֶ ֶרץ ִ‬
‫שנְעָ ר וַ ֵּישְ בּו שָ ם‪ .‬וַי ֹּאמְ רּו ִאיש אֶ ל‪ֵּ -‬ר ֵּעהּו‪ ,‬הָ בָ ה‬
‫ִנלְ ְבנָה לְ ֵּב ִנים וְ ִנשְ ְרפָ ה ִלשְ ֵּרפָ ה; וַתְ ִהי לָ הֶ ם ַהלְ ֵּבנָה לְ ָאבֶן ו ְַה ֵּחמָ ר הָ י ָה לָ הֶ ם‬
‫שה לָ נּו ֵּ‬
‫ַלח ֹּמֶ ר‪ .‬וַי ֹּאמְ רּו‪ ,‬הָ ָבה ִנ ְבנֶה לָ נּו ִעיר ִ‬
‫שם‬
‫ּומג ְָדל וְר ֹּאשֹו ַב ָ‬
‫ש ַמיִם‪ ,‬וְ ַנעֲ ֶ‬
‫ָארץ‪ .‬וַ ֵּי ֶרד ה' ִל ְרא ֹּת אֶ ת הָ ִעיר וְאֶ ת ַה ִמג ְָדל אֲ שֶ ר בָנּו‬
‫פֶ ן נָפּוץ ַעל פְ ֵּני כָל הָ ֶ‬
‫ָאדם‪ .‬וַי ֹּאמֶ ר ה'‪ֵּ ,‬הן ַעם אֶ חָ ד וְשָ פָ ה ַ‬
‫ַאחת לְ כֻלָ ם וְזֶה‪ַ ,‬ה ִחלָ ם ַלעֲ שֹות;‬
‫ְב ֵּני הָ ָ‬
‫ו ְַעתָ ה ֹלא יִ ָב ֵּצר ֵּמהֶ ם כ ֹּל אֲ שֶ ר יָזְמּו ַלעֲ שֹות‪ .‬הָ בָ ה ֵּנ ְר ָדה וְ ָנבְלָ ה שָ ם‬
‫שְ פָ תָ ם אֲ שֶ ר ֹלא יִשְ מְ עּו ִאיש שְ ַפת ֵּר ֵּ‬
‫עהּו‪ .‬וַיָפֶ ץ ה' א ָֹּתם‬
‫ָארץ וַ ַיחְ ְדלּו ִלבְנ ֹּת הָ ִעיר‪ַ .‬על ֵּכן ָק ָרא שְ מָ ּה ָבבֶל‪ִ ,‬כי‬
‫ִמשָ ם ַעל פְ ֵּני כָל‪-‬הָ ֶ‬
‫ָארץ‪,‬‬
‫שָ ם ב ַָלל ה' שְ ַפת כָל הָ ֶ‬
‫ָארץ‪.‬‬
‫הָ ֶ‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫ִ‬
‫ּומשָ ם הֱ ִפיצָם ה'‪ַ ,‬על‪-‬פְ ֵּני כָל‪-‬‬
‫‪UML‬‬
‫בראשית (יא‪ ,‬א‪-‬ט)‬
‫‪4‬‬
‫קורס ניתוח מערכות מידע‬
‫חשיבות הבנת הדרישות ‪ -‬סיפורו של פרוייקט‬
‫רצון הלקוח‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫עדכון ממשק‬
‫המשתמש‬
‫‪UML‬‬
‫חלומו של מעצב‬
‫המערכת‬
‫מה הבין‬
‫מנתח‬
‫המערכת‬
‫‪5‬‬
‫קורס ניתוח מערכות מידע‬
‫סיפורו של פרוייקט (‪)2‬‬
‫איש מכירות‬
‫תאר כך‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫התוכניתן‬
‫כתב‬
‫‪UML‬‬
‫התמיכה‪..‬‬
‫התעוד‬
‫הנלווה‬
‫לפרוייקט‬
‫‪6‬‬
‫קורס ניתוח מערכות מידע‬
‫סיפורו של פרוייקט (‪)3‬‬
‫הלקוח חויב‬
‫בעבור‪..‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫המשתמש היה‬
‫צריך‪...‬‬
‫‪UML‬‬
‫‪7‬‬
‫קורס ניתוח מערכות מידע‬
‫התוצאה במציאות‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪8‬‬
‫קורס ניתוח מערכות מידע‬
‫מהו ניתוח מוכוון עצמים ‪OO -‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫לא עוד טיפול בתהליכים‪.‬‬
‫לא עוד טיפול באירועים‪.‬‬
‫כעת מטפלים בעצמים ‪ -‬אובייקטים‪.‬‬
‫הלקוח במרכז ← המערכת היא כפי שהוא רואה אותה‬
‫גישת האובייקטים עוסקת בעולם האמיתי‪:‬‬
‫לא בהסבות ורעיונות של אנשי מערכת מידע‪.‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪9‬‬
‫קורס ניתוח מערכות מידע‬
‫מהו אובייקט‬
‫‪ ‬כל דבר [מוחשי או וירטואלי] שקיים בעולם‬
‫וניתן לייחס לו תכונות‪:‬‬
‫אדם‪ ,‬ציפור‪ ,‬ספר‪ ,‬קורס‪ ,‬חשבון בנק‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪10‬‬
‫קורס ניתוח מערכות מידע‬
‫הכרות עם ‪Unified Modeling Language‬‬
‫‪ ‬גרסה ראשונה בשנת ‪.1997‬‬
‫‪ ‬מטרת העל‪ :‬יצירת שיטת סימון‪/‬תצוגה‬
‫אחידה לאפיון ועיצוב מערכת מידע‬
‫במתודולוגיה מוכוונת עצמים‪.‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪11‬‬
‫קורס ניתוח מערכות מידע‬
‫מטרות‬
‫‪UML‬‬
‫‪ ‬אחידות ‪ -‬שפה אחת‪ ,‬שיטת סימון אחת‪.‬‬
‫‪ ‬מחזור חיי המערכת ‪ -‬שיטת ‪ UML‬תומכת בכל‬
‫מחזור חיי מערכת המידע‪.‬‬
‫‪ ‬פרויקטים גדולים ‪ -‬יכולת תמיכה בפרויקטים‬
‫בכל סדר גודל‪ ,‬בעבודת צוות ובעבודה מקבילה‪.‬‬
‫‪ ‬חוסר תלות בטכנולוגיה ‪ -‬חוסר תלות מוחלט‬
‫בחומרה ובתוכנה‪.‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪12‬‬
‫קורס ניתוח מערכות מידע‬
‫מטרות‬
‫‪UML‬‬
‫‪ ‬שפה מתאימה לכולם ‪ UML -‬לוקחת בחשבון את‬
‫הלקוח‪ ,‬תכניתן‪ ,‬מעצב התוכנה‪ ,‬מנתח המערכת‪ .‬לכל‬
‫אחד מאלו קיימים שרטוטים מקובלים‪ ,‬שיטת סימון‬
‫אחת ונקודת מבט מיוחדת‪.‬‬
‫‪ ‬הפרדה בין שלב פיתוח המערכת ‪ -‬עבור הלקוח‪,‬‬
‫תוגדרנה הדרישות בשרטוט אחד‪ .‬כל אחד יאמר את‬
‫דברוץ‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪13‬‬
‫קורס ניתוח מערכות מידע‬
‫מרכיבי ‪UML‬‬
‫המערכת‬
‫‪ - Use Case Diagram ‬חלוקת‬
‫לפונקציונליות לצורך הגדרת הדרישות‪.‬‬
‫‪ - Class Diagram ‬מודל המחלקות ‪ -‬המביע את‬
‫החוקיות עליה מבוססת המערכת‪ ,‬כפי שקיימת‬
‫בעולמו של הלקוח‪.‬‬
‫‪ - Sequence Diagram ‬התנהגות בעולם הלקוח‬
‫ברצף הזמן‪ ,‬בחלוקה לפי הפונקציונליות שהוגדרה‬
‫בשלב ה‪.Use Case-‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪14‬‬
‫קורס ניתוח מערכות מידע‬
‫מרכיבי ‪UML‬‬
‫‪ - Collaboration Model ‬שיתוף מודל המחלקות‬
‫וה‪ Sequence Model-‬לצרכים שונים‪.‬‬
‫‪ - State Chart Diagram ‬מצבי האובייקט במחזור‬
‫החיים‪.‬‬
‫‪ - Activity Diagram ‬פעילויות במערכת‪.‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪15‬‬
‫קורס ניתוח מערכות מידע‬
‫מרכיבי ‪UML‬‬
‫‪ - Deployment Diagram ‬פריסת המערכת על חלקיה‬
‫‪ - Component Diagram ‬רכיבי מערכת המידע‪.‬‬
‫‪ - Object Diagram ‬תיאור האובייקטים במערכת‪.‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪16‬‬
‫קורס ניתוח מערכות מידע‬
‫‪UML - Unified Modeling Language‬‬
‫‪ ← DFD‬פירוק עד לרמה מפורטת ביותר‬
‫אירועים ←‬
‫מתחילים באמצע‬
‫עולים ל"אירוע על"‬
‫יורדים‪/‬יוצרים פירוט לשגרות‬
‫‪ ← UML‬עד לרמת הפירוט אותה מבקש הלקוח‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫שלבים בתהליך הפיתוח‬
‫‪1‬‬
‫חקר מצב קיים‬
‫‪2‬‬
‫הגדרת דרישות (רק כאן המשתמש מעורב מלא)‬
‫זהו כתב הכמויות‪ ,‬ההסכם של התכולה‬
‫תרשים‬
‫תיאור הפונקציונאליות (תקן לסעיפים)‬
‫‪3‬‬
‫תיאור מפורט‪/‬אפיון של תוצר שלב ‪2‬‬
‫שימוש בתפישת ‪ OOAD‬מיוצגת על ידי ‪UML‬‬
‫תרשימים בסימון ‪UC# ,SQ#‬‬
‫‪4‬‬
‫הגדרת החוקיות בעולם של הלקוח‬
‫‪5‬‬
‫הגדרת ההתנהגות של הפרויקטים בממד הזמן‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪DFD‬‬
‫‪Use case‬‬
‫‪Use Case Documentation‬‬
‫‪Class Diagram‬‬
‫‪Dynamic Diagrams‬‬
‫‪UML‬‬
‫התכנון הפיסי‪ ,‬ההתקנות‬
‫‪All Others‬‬
‫קורס ניתוח מערכות מידע‬
‫אפיון מערכות מוכוון עצמים‬
‫(‪)1‬‬
‫‪OOAD‬‬
‫אובייקט ← הוא הדבר האמיתי‪ ,‬אם כי לא תמיד מוחשי‬
‫‪ ← CLASS‬תבנית לוגית הקובעת תכונות של העצמים‬
‫הנגזרים ממנה‪ ,‬בעלי אוסף מוגדר של מאפיינים‬
‫←אותה רשימת מאפיינים לכול האובייקטים‪ ,‬נבדלים בערכים שלהם‪:‬‬
‫הפשטה ← זווית ההסתכלות לפי שימוש או כוונת המתבונן‬
‫תכונות ← לפי סוגי שדות ‪TYPE‬‬
‫שיטות ← פעולות (פונקציות‪ ,‬פרוצדורות)‬
‫קבלת מידע מ←האוביקט‬
‫שינוי המידע האצור באוביקט‬
‫‪accessor, getter‬‬
‫‪mutator‬‬
‫הכמסה של ה←‪← class‬‬
‫‪ UML‬הוראות‪/‬שיטות קישור‪/‬גישה‪,‬‬
‫ישלפירק‬
‫כלפי חוץ‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪OO‬‬
‫המבנה הפנימי אינו מעניין‬
‫קורס ניתוח מערכות מידע‬
‫אפיון מערכות מוכוון עצמים‬
‫(‪)2‬‬
‫‪OOAD‬‬
‫בנאי ← כול מחלקה יש לה בנאי הבונה אוביקטים‬
‫על ידי אתחול הערכים של האוביקט‬
‫מפרק ← סגירה של אוביקט‪ ,‬סימונו כמבוטל‬
‫תכונה‬
‫מחלקתית ← זהה בכול האוביקטים‪ :‬שע"ח‪ ,‬מונה‬
‫סופית ← לאוביקט מסוים‪ ,‬אינה ניתנת לשינוי (ת‪.‬ז‪).‬‬
‫קשרים בין מחלקות‬
‫אסוציאטיבי ← כיוון‪ ,‬מידת ריבוי‬
‫אסוציאטיבי עצמאי ← קישור מחלקה אל עצמה מנהל ועובד‬
‫מחלקת קשר ← שומרת את הערכים של הקשר (תאריך ערך)‬
‫מערכות ‪ OO‬לפי ‪UML‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב‬
‫‪ ←aggregation‬רכב וגלגלים או הכלה חזקה‪/‬תלות פרק וסעיפים‬
‫הכלה‬
‫(‪ 30‬כסאות בכיתה)‪,‬‬
‫קורס ניתוח מערכות מידע‬
‫אפיון מערכות מוכוון עצמים‬
‫(‪)3‬‬
‫‪OOAD‬‬
‫הורשה ← של תכונות ושיטות ממחלקה אל מחלקה‬
‫הורשה מרובה ← יורשת מיותר מאשר מחלקה אחת‬
‫הסימון הפוך לכיוון ההורשה‬
‫מוגן ‪ ← #‬הערך פרטי עבור כלל המחלקות למעט עבור‬
‫מחלקות יורשות‬
‫רמיסה ← של שיטות (לא תכונות) על ידי היורשת‪ :‬חלקית או מלאה‬
‫ריבוי צורות ‪ polymorphism‬בשל הרמיסה‬
‫הפעלת פעולה על אוביקט‪ ,‬מחפשת את הפעולה במעלה עץ ההורשה‬
‫ממשק ← מחלקה ללא תכונות‪,‬‬
‫מופשטת ← לא ניתן לייצר ממנה אובייקטים‬
‫מחלקה‬
‫לפי‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות‬
‫רק שיטות אשר היורשת חייבת לממש‬
‫‪OO‬‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫‪“ - UML‬מפת דרכים”‬
‫ארכיטקטורת מערכת‬
‫דרישות מערכת‬
‫ישויות‪,‬‬
‫קשרים‪,‬‬
‫יחסים‬
‫מקרא‪:‬‬
‫מודל‬
‫סטטי‬
‫‪Class‬‬
‫‪Diagram‬‬
‫מודל‬
‫דינמי‬
‫“חבילות‬
‫עבודה”‬
‫‪Use Case‬‬
‫‪Model‬‬
‫שחקנים‪,‬‬
‫תרחישים‪,‬‬
‫אופני‬
‫פעולה‬
‫‪Package‬‬
‫‪Diagram‬‬
‫מודל‬
‫ניהולי‬
‫‪State‬‬
‫‪Chart‬‬
‫התנהגות‬
‫פריסת התוכנה‬
‫על גבי החומרה‬
‫‪Deployment‬‬
‫‪Diagram‬‬
‫‪Activity‬‬
‫‪Diagram‬‬
‫ארכיטקטורת‬
‫התוכנה‬
‫‪Component‬‬
‫‪Diagram‬‬
‫‪Sequence‬‬
‫‪Diagram‬‬
‫לוגיקה‪,‬‬
‫זרימה‬
‫פונקציונליות‪,‬‬
‫אינטראקציה‬
‫‪22‬‬
‫קורס ניתוח מערכות מידע‬
‫מסגרת הדיון‪:‬‬
‫‪ ‬מודל מקרי‪-‬שימוש (‪)Use-Case Model‬‬
‫“שחקנים”‬
‫מקרי‪-‬שימוש )‪(use cases‬‬
‫תרחישים‬
‫תרשים מקרי‪-‬שימוש (‪)use-case diagram‬‬
‫‪ ‬המודל הסטטי (‪)Static Model‬‬
‫מחלקות‬
‫קשרים‬
‫תלויות‬
‫תרשים מחלקות (‪)class diagram‬‬
‫‪ ‬המודל הדינמי (‪ :)Dynamic Model‬בד"כ יותר מאוחר‪ ,‬בשלב עיצוב התוכן‬
‫מצבים‬
‫מעברים‬
‫תרשימי מצבים (‪)state-chart diagrams‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪23‬‬
‫קורס ניתוח מערכות מידע‬
‫דוגמה לניתוח מונחה עצמים‪ :‬מעלית‬
‫רשימת הדרישות‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫המערכת מבקרת ‪ n‬מעליות המשרתות ‪ m‬קומות‬
‫בכל מעלית יש ‪ m‬כפתורים ‪ -‬אחד לכל קומה‬
‫עם הלחיצה על כפתור‪-‬מעלית‬
‫הכפתור מואר‬
‫המעלית מגיעה לקומה המבוקשת‬
‫הדלתות נפתחות והכפתור כבה‬
‫‪‬‬
‫‪‬‬
‫בכל קומה‪ ,‬פרט לראשונה ולאחרונה‪ ,‬יש שני כפתורים (לעליה ולירידה)‬
‫עם לחיצה על כפתור‪-‬קומה‬
‫הכפתור מואר‬
‫כאשר מעלית מגיעה לקומה המבוקשת ‪ -‬הדלתות נפתחות והכפתור כבה‬
‫לאחר השהיה נסגרות הדלתות והמעלית ממשיכה בכיוון המבוקש (אם ישנן בקשות קיימות)‬
‫‪‬‬
‫כאשר אין בקשות למעלית‪ ,‬היא חונה בקומה הנוכחית כשדלתותיה סגורות‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪24‬‬
‫קורס ניתוח מערכות מידע‬
‫היכן נמצאים האובייקטים? היכן נמצאות הפונקציות?‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫המערכת מבקרת ‪ n‬מעליות המשרתות ‪ m‬קומות‬
‫שמות עצם עשויים לציין אובייקטים‬
‫בכל מעלית יש ‪ m‬כפתורים ‪ -‬אחד לכל קומה‬
‫פעלים עשויים לציין פונקציות‬
‫עם הלחיצה על כפתור‪-‬מעלית‬
‫הכפתור מואר‬
‫המעלית מגיעה לקומה המבוקשת‬
‫הדלתות נפתחות והכפתור כבה‬
‫בכל קומה‪ ,‬פרט לראשונה ולאחרונה‪ ,‬יש שני כפתורים (לעליה ולירידה)‬
‫עם לחיצה על כפתור‪-‬קומה‬
‫הכפתור מואר‬
‫כאשר מעלית מגיעה לקומה המבוקשת ‪ -‬הדלתות נפתחות והכפתור כבה‬
‫לאחר השהיה נסגרות הדלתות והמעלית ממשיכה בכיוון המבוקש (אם ישנן בקשות קיימות)‬
‫‪‬‬
‫כאשר אין בקשות למעלית‪ ,‬היא חונה בקומה הנוכחית כשדלתותיה סגורות‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪25‬‬
‫קורס ניתוח מערכות מידע‬
‫תרשים מקרי שימוש (‪)Use-Case Diagram‬‬
‫‪‬‬
‫שחקנים (‪)Actors‬‬
‫תפקיד שממלא משתמש כלשהו במערכת‬
‫משתמש אחד יכול למלא תפקידים שונים‬
‫כותב‬
‫מאייר‬
‫עורך‬
‫שחקן לא חייב להיות אנושי‬
‫חיישן‬
‫בקר‬
‫‪‬‬
‫מקרי שימוש (‪)Use Cases‬‬
‫אופני ההפעלה של המערכת‬
‫אינטראקציה בין המערכת לבין שחקניה‬
‫תרחישים (‪ )scenarios‬חיצוניים‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪26‬‬
‫קורס ניתוח מערכות מידע‬
‫מעלית ‪UCD -‬‬
‫תרחיש נסיעה‬
‫במעלית‪.‬‬
‫מופעל עם הלחיצה‬
‫על כפתור במעלית‬
‫‪Elevator‬‬
‫‪System‬‬
‫‪Boundaries‬‬
‫‪ride the elevator‬‬
‫‪call the elevator‬‬
‫‪User‬‬
‫תרחיש קריאה למעלית‪.‬‬
‫מופעל עם הלחיצה על‬
‫כפתור בקומה‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪27‬‬
‫קורס ניתוח מערכות מידע‬
‫קשרים בין ‪Use Cases‬‬
‫‪‬‬
‫‪Extend‬‬
‫‪ UC‬אחד מרחיב ‪ UC‬אחר ע"י תוספת של התנהגות‬
‫ניתן להגדיר את "נקודת ההסתעפות" )‪(Extension Point‬‬
‫‪‬‬
‫‪Include‬‬
‫‪ UC‬אחד כולל בתוכו את ההתנהגות של ‪ UC‬אחר‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪28‬‬
‫קורס ניתוח מערכות מידע‬
‫מעלית ‪ UCD -‬מורחב‬
‫מעלית‬
‫& ‪<<include>> repair‬‬
‫‪test‬‬
‫טכנאי‬
‫מפעיל קריאה ‪ /‬נסיעה‬
‫כחלק מתהליך הבדיקה‬
‫‪ride‬‬
‫>> ‪<< include‬‬
‫>>‪<<extend‬‬
‫‪call‬‬
‫‪rescue‬‬
‫מכבי אש‬
‫משתמש‬
‫>>‪<<extend‬‬
‫מפעילים קריאה ‪ /‬נסיעה‬
‫באופנים נוספים‬
‫תוך שימוש במפתח מיוחד‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪29‬‬
‫קורס ניתוח מערכות מידע‬
‫מפרט ‪ - UC‬תיעוד‬
‫‪‬‬
‫בנוסף לתרשים‪ ,‬חייב כל ‪ UC‬להיות מלווה בתיעוד‪ ,‬הכולל את הנושאים הבאים‪:‬‬
‫מטרת ה‪UC-‬‬
‫קיימים גם "בעלי עניין"‬
‫נועד למילוי משימה שתשרת שחקן אחד לפחות‬
‫)‪(stakeholders‬‬
‫רשימת השחקנים ותפקידיהם‬
‫ה‪ UC-‬אמורים לשרת‬
‫"המערכת" איננה שחקן!‬
‫גם את האינטרסים‬
‫תנאים מקדימים (‪)pre-conditions‬‬
‫שלהם!‬
‫מה צריך להתקיים כדי שה‪ UC-‬יוכל להתבצע כהלכה‬
‫תנאים לאחר מעשה (‪)post-conditions‬‬
‫מה השתנה לאחר סיום (מוצלח!) של ה‪UC-‬‬
‫תרחיש הצלחה ראשי )‪(MSS = Main Success Scenario‬‬
‫האינטראקציה העיקרית בין השחקנים לבין "המערכת" שתביא לקיום התנאים לאחר‪-‬מעשה‬
‫[ללכת בתל"מ]‬
‫הסתעפויות )‪(branches‬‬
‫חלופה )‪"[ (alternative‬אלתר נתיב"]‬
‫• השגת התל"מ באופן שונה‬
‫חריגה )‪(exception‬‬
‫• מסלול שיביא לסיום ה‪ UC-‬מבלי שיתקיימו התל"מ‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪30‬‬
‫קורס ניתוח מערכות מידע‬
‫‪ - use-case‬מעלית‬
‫•‬
‫שחקנים (‪)Actors‬‬
‫–‬
‫•‬
‫תנאים מקדימים (‪)pre-conditions‬‬
‫–‬
‫•‬
‫משתמש (נוסע)‬
‫המשתמש נמצא בתוך המעלית והמעלית "בכיוון" עלייה‬
‫תנאים לאחר‪-‬מעשה (‪)post-conditions‬‬
‫–‬
‫–‬
‫המעלית הגיעה לקומה המבוקשת‬
‫הנוסע יכול לצאת מהמעלית‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪31‬‬
‫קורס ניתוח מערכות מידע‬
‫‪ - use-case‬מעלית‬
‫)המשך(‬
‫‪ ‬תרחיש הצלחה ראשי ‪MSS -‬‬
‫‪ .1‬המשתמש לוחץ על כפתור המעלית של הקומה‬
‫המבוקשת‬
‫‪ .2‬כפתור הקומה נדלק‬
‫‪ .3‬דלתות המעלית נסגרות‬
‫‪ .4‬המעלית עולה לקומה המבוקשת‬
‫‪ .5‬המעלית נעצרת‬
‫‪ .6‬הדלתות נפתחות‬
‫‪ .7‬כפתור הקומה כבה‬
‫‪( .8‬אם הגיע לקומה המבוקשת ‪ -‬המשתמש יוצא מהמעלית)‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי ‪UML‬‬
‫השהיה נסגרות הדלתות‬
‫‪ .9‬לאחר‬
‫‪32‬‬
‫קורס ניתוח מערכות מידע‬
‫‪ - use-case‬מעלית‬
‫)המשך(‬
‫‪ ‬הסתעפויות‬
‫חלופה‪ :‬הקומה המבוקשת נמצאת מתחת לקומה‬
‫הנוכחית‬
‫‪4‬א ‪ -‬המעלית עולה לקומה העליונה ביותר שהתבקשה‬
‫‪4‬ב ‪ -‬המעלית יורדת לקומה המבוקשת‬
‫חלופה‪" :‬מעלית שבת"‬
‫‪ - 1‬בטל‪.‬‬
‫‪ - 4-9‬חוזר בכל קומה בדרך‬
‫חריגה‪ :‬עצירת חירום (יזומה ע"י המשתמש)‬
‫‪ - 6-9‬בטלים‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪33‬‬
‫קורס ניתוח מערכות מידע‬
‫תרשים מחלקות (‪)Class Diagram‬‬
‫‪‬‬
‫‪‬‬
‫מחלקה (‪)class‬‬
‫מזהה (‪)identifier‬‬
‫מאפיינים (‪)attributes‬‬
‫ממומשים באמצעות מבני נתונים‬
‫פעולות (‪)operations‬‬
‫ממומשות באמצעות שגרות ‪ /‬פונקציות‬
‫זיקה (‪ )association‬בין מחלקות‬
‫סוג הזיקה (ירושה‪ ,‬הכלה‪)... ,‬‬
‫תפקיד (‪)role‬‬
‫ריבוי (‪)multiplicity‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫מזהה‬
‫מאפיינים‬
‫פעולות‬
‫‪34‬‬
‫קורס ניתוח מערכות מידע‬
‫‪Class Stereotypes‬‬
‫‪Entity‬‬
‫‪Boundry‬‬
‫‪Controller‬‬
‫מחלקה ללא אוביקטים ‪Abstract‬‬
‫למנוע הורשה מרובה ‪Interface‬‬
‫תת תוית של הישות‪ ,‬הרשאות ‪Actor‬‬
‫חוקי ארגון כמו מחירונים ‪Policy‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
)‫(גרסה ראשונה‬
‫ תרשים מחלקות‬- ‫מעלית‬
Button
illuminated: Boolean
‫ירושה‬
inheritance
Elevator Button
Floor Button
m
2m - 2
communicates
with
36
‫זיקה‬
association
1
communicates
with
Elevator
doors_open: Boolean
UML
n
‫ לפי‬OO ‫ אפיון ועיצוב מערכות‬- 6 ‫[ שיעור‬58]
‫קורס ניתוח מערכות מידע‬
)‫(גרסה מתקדמת‬
‫ תרשים מחלקות‬- ‫מעלית‬
Button
illuminated: Boolean
Elevator Button
Floor Button
mn
2m - 2
controls
controls
1
1
controls
n
Elevator
37
Elevator Controller
1
1
controls
n
Elevator Doors
doors_open: Boolean
UML
‫ לפי‬OO ‫ אפיון ועיצוב מערכות‬- 6 ‫[ שיעור‬58]
‫קורס ניתוח מערכות מידע‬
‫זיקה ‪Association -‬‬
‫‪“ ‬הכרות” בין עצמים ממחלקות שונות‬
‫‪ ‬סוגים מיוחדים של זיקה‬
‫ירושה‪ ,‬הכללה (‪)inheritance, generalization‬‬
‫הגדרת מחלקה על בסיס מחלקה אחרת‬
‫הכלה‪ ,‬הקבצה (‪)aggregation‬‬
‫עצם ממחלקה כלשהי “מכיל” עצמים ממחלקה אחרת‬
‫‪ ‬זוג סדור של שתי מחלקות‬
‫עצם ממחלקה ‪" B‬מכיר" עצם ממחלקה ‪A‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪38‬‬
‫קורס ניתוח מערכות מידע‬
‫זיקה ‪Association -‬‬
‫‪ ‬מאפייני הזיקה‬
‫שם (‪)name‬‬
‫סדר (‪)ordering‬‬
‫האם הזיקה היא מ‪ A-‬ל‪ ,B-‬או להיפך?‬
‫תפקיד (‪)role‬‬
‫מה תפקידו של כל אחד מהעצמים בקשר‬
‫ריבוי (‪)multiplicity‬‬
‫האם הזיקה קיימת תמיד?‬
‫האם ההכרות היא עם יותר מעצם אחד?‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪39‬‬
‫קורס ניתוח מערכות מידע‬
‫דוגמאות לזיקה‬
name
policy
holder
Person
1..*
refers to
0..*
has
multiplicity
Insurance
Contract
husband
has
wife
1
married to
40
‫זיקה עצמית‬
self association
refers to
0..*
1
refers to
0..1
is expressed in a
Insurance
Policy
role
insurer
Insurance
Company
UML
‫ לפי‬OO ‫ אפיון ועיצוב מערכות‬- 6 ‫[ שיעור‬58]
‫קורס ניתוח מערכות מידע‬
)Association class( ‫מחלקת זיקה‬
‫• לפעמים לזיקה עצמה ניתן לתת מעמד של מחלקה‬
Company
Person
employee
employer
0..*
*
association class
association part•
visual tie•
class part•
boss
0..1
Job
salary
worker
41
*
UML
‫ לפי‬OO ‫ אפיון ועיצוב מערכות‬- 6 ‫[ שיעור‬58]
‫קורס ניתוח מערכות מידע‬
‫ירושה (‪)Inheritance‬‬
‫‪A‬‬
‫‪ ‬מחלקה ‪ B‬יורשת את מחלקה ‪:A‬‬
‫‪ B‬מכילה את כל המאפיינים של ‪A‬‬
‫‪ B‬מכילה את כל הפעולות של ‪A‬‬
‫בנוסף‪ B ,‬מכילה מאפיינים ופעולות משל עצמה‬
‫‪“B is-a A” ‬‬
‫‪ B ‬היא תת‪-‬מחלקה (‪ )sub-class‬של ‪A‬‬
‫מינוח לא מוצלח‪ ,‬כי ב’ מכילה יותר מאשר א’‬
‫‪‬‬
‫‪‬‬
‫‪ B‬היא הכללה (‪ )generalization‬של ‪A‬‬
‫דוגמאות לירושה‪:‬‬
‫דוגמה רעה‪ :‬ריבוע יורש מלבן‬
‫דוגמה טובה‪ :‬ריבוע ומלבן יורשים מרובע‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫מאפיינים‬
‫פעולות‬
‫‪B‬‬
‫מאפיינים‬
‫פעולות‬
‫‪42‬‬
‫קורס ניתוח מערכות מידע‬
‫הקבצה (‪)Aggregation‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫כל עצם ממחלקה ‪ B‬מכיל עצם (עצמים) ממחלקה ‪A‬‬
‫”‪“A is-part-of B‬‬
‫שני סוגי הקבצה‪:‬‬
‫ל‪ A-‬יש קיום גם ללא ‪B‬‬
‫שמות נוספים‪:‬‬
‫‪A‬‬
‫‪B‬‬
‫‪logical aggregation‬‬
‫‪shared aggregation‬‬
‫קיומו של ‪ A‬תלוי בקיומו של ‪B‬‬
‫שמות נוספים‪:‬‬
‫‪physical aggregation‬‬
‫‪non-shared aggregation‬‬
‫‪composition‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪A‬‬
‫‪B‬‬
‫‪43‬‬
‫קורס ניתוח מערכות מידע‬
‫דוגמאות להקבצה‬
‫‪1‬‬
‫}‪{ordered‬‬
‫*‪3..‬‬
‫‪Point‬‬
‫הקבצה פיסית (‪)composition‬‬
‫• למעגל יש נקודה אחת (מרכז)‬
‫• נקודת המרכז משויכת אך ורק עם מעגל זה‬
‫• קיומה של נקודת המרכז מותנה בקיומו של‬
‫המעגל‬
‫‪Circle‬‬
‫‪radius‬‬
‫‪Polygon‬‬
‫*‬
‫*‬
‫כיוון (‪)navigation‬‬
‫• המעגל “מכיר” את הסגנון‬
‫• הפוליגון “מכיר” את הסגנון‬
‫• הסגנון אינו נדרש להכיר את העצמים‬
‫המפנים אליו‪...‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪1‬‬
‫‪Style‬‬
‫‪color‬‬
‫‪isFilled‬‬
‫‪1‬‬
‫הקבצה לוגית (‪)aggregation‬‬
‫• לפוליגון יש סגנון‬
‫• סגנון יכול להיות משותף למספר פוליגונים‬
‫• הסגנון הוא ישות עצמאית‪ ,‬וקיומו אינו‬
‫מותנה בקיום פוליגון‬
‫‪44‬‬
‫קורס ניתוח מערכות מידע‬
‫תלות ‪Dependency -‬‬
‫‪ ‬יחס )‪ (relationship‬בין שתי ישויות‬
‫ישות עצמאית‬
‫ישות תלויה‬
‫שינוי כלשהו בישות העצמאית עלול להשפיע על הישות התלויה‬
‫‪ ‬תלות יכולה להתקיים גם בין ישויות שאין ביניהן זיקה )‪ (association‬כלשהי‬
‫לדוגמה‪ :‬עצם ממחלקה כלשהי מועבר כפרמטר לפונקציה של מחלקה אחרת‬
‫‪ ‬כיוון התלות לא בהכרח זהה לכיוון הזיקה‬
‫‪Seat‬‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫‪Building‬‬
‫‪Theater‬‬
‫‪45‬‬
‫קורס ניתוח מערכות מידע‬
UML Diagram Usage - Summary
Development
Phase
UML Diagrams
Analysis
Use Cases, Class Diagrams, Activity
Diagrams, Collaboration Diagrams,
Sequence Diagrams
Class Diagrams, Collaboration
Diagrams, Sequence Diagrams, State
Diagrams, Component Diagrams
Deployment Diagrams
Collaboration Diagrams, Sequence
Diagrams, Class Diagrams, State
Diagrams, Component Diagrams,
Deployment Diagrams
Package Diagrams, Deployment
Diagrams
Design
Development
Implementation
46
UML
‫ לפי‬OO ‫ אפיון ועיצוב מערכות‬- 6 ‫[ שיעור‬58]
‫קורס ניתוח מערכות מידע‬
‫ ← אפיון דרישות‬2/3 ‫שלב‬
‫עדיף יחד עם העיצוב הלוגי‬
Use Case Diagram
‫תרשים המבטא את הדרך בה המשתמש מפעיל את‬
‫המערכת‬
:‫שדות תקניים לתיאור‬
Name
Identifier
Description
Actors
Frequency
Pre Conditions
Post Conditions
Extend / Include
Assumptions
Basic course of Action
Alternate course of Action
Change History (change control)
(open) Issues
Decisions (for next version)
UML
‫ לפי‬OO ‫ אפיון ועיצוב מערכות‬- 6 ‫[ שיעור‬58]
‫קורס ניתוח מערכות מידע‬
‫שלב ‪ ← 4‬הגדרת החוקיות‬
‫‪ Class Diagram‬המודל הסטטי‬
‫← מתאר את החוקה העסקית בארגון‬
‫תרגום של ה← ‪Use Case‬‬
‫שמות העצם ← מחלקות‬
‫תיאור שמות העצם ← תכונות‬
‫פעלים ← שיטות‬
‫תרגום ה← ‪ERD‬‬
‫הוספה של השיטות‬
‫לפי של ההורשה‬
‫הגדרה‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות‬
‫‪OO‬‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫שלב ‪ ← 5‬התנהגות על פני ממד הזמן‬
‫‪ Sequence Diagram‬המודל הדינמי‬
‫(‪)1‬‬
‫האוביקטים‪ ,‬לא המחלקות‪ ,‬הם החיים בממד הזמן‬
‫ציר ‪ ← Y‬האנכי ← הוא ממד הזמן‬
‫התרשים מבטא את התנהגות האוביקטים בתהליך‬
‫אילוצים‪ :‬תנאי או התניית ביצוע בקיום ביטוי מסוים‬
‫הערות‪ :‬בעיקר ה← ‪Use Case‬‬
‫יצירה ופירוק‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫שלב ‪ ← 5‬התנהגות על פני ממד הזמן‬
‫(‪)2‬‬
‫‪ Collaboration Diagram‬תרשים שיתוף‬
‫שיתוף בין ה← ‪ Class Diagram‬לבין ‪Seq. Diagram‬‬
‫קשר בין המחלקות‪ ,‬ללא ממד זמן‪ ,‬בהקשר של האוביקטים‬
‫נועד לבדוק נכונות של התרשימים הקודמים‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫שלב ‪ ← 5‬התנהגות על פני ממד הזמן‬
‫‪ State machine‬תרשים (מכונת) מצבים‬
‫(‪)3‬‬
‫המנתח מכין עבור התוכניתנים‪:‬‬
‫המצבים השונים של אוביקט מסוים במחזור חיי המערכת‬
‫לעתים תוך ציון הערכים של התכונות‬
‫האירועים המשפיעים על מצבו‬
‫סדר האירועים‬
‫התנהגות סדרתית של האוביקט‬
‫מצבים מיוחדים‪:‬‬
‫לא ניתן להגיע אליו‬
‫לפי‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות‬
‫סתום‪ ,‬אי אפשר לצאת ממנו‬
‫מבוי‬
‫‪OO‬‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫שלב ‪ ← 5‬התנהגות על פני ממד הזמן‬
‫(‪)4‬‬
‫‪ Activity Diagram‬תרשים פעילויות‬
‫בשלב האפיון או העיצוב‪ ,‬להמחשה של ה← ‪Business Logic‬‬
‫דומה לתזרים זרימה‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫התרשימים‬
‫‪ Use case Diagram‬חלוקת המערכת לפונקציונאליות לצורך הגדרת הדרישות‬
‫‪Use case Description‬‬
‫‪Class Diagram‬‬
‫‪Sequence Diagram‬‬
‫‪Collaboration Diagram‬‬
‫‪State Chart Diagram‬‬
‫‪Activity Diagram‬‬
‫‪Component Diagram‬‬
‫↔ החוקים העסקיים‪ ,‬ללא פירוט התכונות‬
‫↔ התנהגות בעולם הלקוח ברצף הזמן‬
‫לפי הפונקציונאליות של ה← ‪Use Case‬‬
‫↔ שילוב של ‪ CD‬ו← ‪SD‬‬
‫↔ מצבי האוביקט במחזור החיים‬
‫↔ הפעילויות במערכת בחלוקה לתחומי אחריות‬
‫הרכיבים‬
‫‪ Deployment Diagram‬תרשים תלויות ← פריסה לוגית‪ ,‬גיאוגרפית‪/‬ע"ג החומרה‬
‫‪ Object Diagram‬תרשים האוביקטים‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫שימוש בתרשימים‬
‫אפיון‬
‫דרישות‬
‫ניתוח‬
‫‪+‬‬
‫עיצוב לוגי‬
‫עיצוב‬
‫‪ Use case Diagram‬את תיאור המצב הקיים תיארנו ‪ DFD‬או‬
‫‪ERD‬‬
‫‪Use case Description‬‬
‫↔ החוקים העסקיים‪ ,‬ללא פירוט התכונות‬
‫↔ הפונקציונאליות‪ ,‬עץ המסכים‬
‫תיאור התהליכים באמצעות המודל הדינמי‬
‫להתחיל שלבי פריסה ומימוש‬
‫בסיס הנתונים ← הגדרת ‪ Entity‬והסוגים של התכונות‬
‫‪Class Diagram‬‬
‫‪Sequence Diagram‬‬
‫אם צריך‪:‬‬
‫‪Object Diagram‬‬
‫‪Collaboration Diagram‬‬
‫‪State Chart Diagram‬‬
‫‪ Class Diagram‬התייחסות לטכנולוגיה‪:‬‬
‫‪ ← Sequence Diagram‬פירוט של כול תרשימי האפיון‬
‫‪ ← Activity Diagram‬פירוט כול תהליך‪/‬אירוע כולל רמת האבטחה‬
‫← הוספה של המסכים ל←‪Class Diagram‬‬
‫←‬
‫שגרות דרך הגדרת השיטות וה←‪Controllers‬‬
‫באמצעות ‪ Activity Diagram‬או עברית מבנית‬
‫‪ Class‬הופך לטבלה‬
‫←‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי ‪UML‬‬
‫‪Diagram‬‬
‫‪ Component‬בנייה של קבצים‪ ,‬הוספה של תרשים המרכיבים‬
‫מימוש‬
‫קורס ניתוח מערכות מידע‬
‫‪MVC - Data Model View Controller‬‬
‫חלוקה של ה← ‪Class Diagram‬‬
‫‪ Entity‬מחלקות מידע ← מאגר נתונים‬
‫‪ Boundry‬מחלקות תצוגה‪ :‬מסכים‪ ,‬דוחות‬
‫‪ Controller‬מחלקות ניהול‪:‬‬
‫השולפות מהתצוגה‪ ,‬מעבדות ושומרות‬
‫שולפות ממאגר הנתונים‪ ,‬מעבדות ושומרות‬
‫כול מסך הוא אוביקט‪ ,‬הקשר הוא על ידי עץ המסכים‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
‫‪CASE - Computer Aided Software Engineering‬‬
‫כלי אשר‪:‬‬
‫אליו מגדירים את ה←‪UML‬‬
‫‪ ← Upper Case‬ניהול האפיון‪ ,‬העיצוב‪ ,‬הבדיקות‬
‫‪ Lower Case‬מפתח את‪:‬‬
‫בסיס הנתונים‬
‫התוכנה‬
‫]‪ [58‬שיעור ‪ - 6‬אפיון ועיצוב מערכות ‪ OO‬לפי‬
‫‪UML‬‬
‫קורס ניתוח מערכות מידע‬
? ‫שאלות‬
UML ‫תרשימי‬
http://www.smartdraw.com/tutorials/software/uml/tutorial_01.htm
http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/diagrams.htm
58
UML
‫ לפי‬OO ‫ אפיון ועיצוב מערכות‬- 6 ‫[ שיעור‬58]