שיעור חזרה למועד א'

1. שיעור חזרה למועד א' ניתוח ועיצוב מערכות תוכנה אביב 2012

2. ניתוח ועיצוב מערכות תוכנה • זה לא DFD • ולא תרשימיUML • תקשורת בין מתכנתים • ניתוח ועיצוב

3. למה מנתחים ומעצבים? • שפה משותפת עם הלקוח • שפה משותפת בתוך הצוות • בקרת איכות • תיעוד • שימוש מחדש

4. ADISSA • ניתוח • תרשימיDFD היררכיים • מילון נתונים • עיצוב • זיהוי טרנסאקציות וכתיבת תיאור על • עיצוב מסכי קלט/פלט, עץ תפריטים, סכמת DB • תיאור מפורט של טרנסאקציות

5. שלבי מתודולוגיית ADISSA

6. תרשימי DFD היררכיים • "תרשים DFD הוא אמצעי גרפי לתיאור פעילויות (כלומר תהליכים, פונקציות) וזרימת המידע ביניהן.... אינו דומה לתרשים זרימה של תכנית ואין מטרתו להציג את לוגיקת ביצוע הפעילויות. אפשר לומר שתרשים DFD מציג תמונה "סטטית" ל זרימת מידע אפשרית בין פעילויות." • פרץ שובל, כרך ב', סעיף 5.2.1 (עמ' 23)

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

8. תרשימי DFD היררכיים • פונקציה מסמלת פעולה שהמערכת תבצע. פעולה היא היפוך או עיבוד של נתונים: הפונקציה מקבלת נתונים ממקורות כלשהם ומבצעת פעולה הגורמת לשינוי כלשהו בנתונים. • מאגר הוא אבסטרקציה של אחסון נתונים. • ישות – היא מקור המידע (לאו דווקא המשתמש/ת) • זרם מידע – תמיד פונקציה באחד הצדדים!

9. מילון נתונים כביכול הטבלה השנייה מיותרת: אבל באמצעותה ניתן לשחזר את אופן הצגת התרשים ("כותרות" לזרמים).

10. זיהוי טרנסאקציות • רכיבי קשירות של פונקציות • זה הזמן להסביר את הלוגיקה

11. כתיבת תיאור על של טרנסאקציות • פונקציה יסודית  בצע פונקציה... • זרם מידע מישות חיצונית לפונקציה (למעט מישות זמן) קלוט מישות... • זרם מידע מפונקציה לישות חיצונית הפק פלט לישות... • זרם מידע ממאגר מידע לפונקציה קרא ממאגר מידע... • זרם מידע מפונקציה למאגר נתונים  כתוב למאגר מידע • לוגיקת ביצוע הפעולות מתוארת באמצעות תבניות של תכנות מובנה, דהיינו: • יש פעולות שתתבצענה סדרתית, זו אחר זו. • יש פעולות שתתבצענה בתנאי, כלומר תהיינה נקודות הסתעפות. תנאי ההסתעפות אינם מצוינים בתרשים הטרנסאקציה: הם "נסתרים" בתוך הפונקציות. תיאור-העל יציין במפורש את תנאי ההסתעפות, על אף שכל יתר פרטי הפונקציות אינם מפורטים בתיאור-העל. • יש פעולות שתתבצענה בלולאה, כלומר, מספר דרוש של פעמים. מידע על ביצוע פעולות בלולאה, מה הן הפעולות הנכללות בה וכמה פעמים היא צריכה להתבצע בוודאי אינו מצוי בתרשים ה-DFD ויש להגדיר זאת בשלב זה. • פרץ שובל, כרך ב', עמ' 151)

12. כתיבת תיאור על של טרנסאקציות • מילון נתוני הטרנסאקציות: • זיהוי • שם • מרכיבים • תרשים • תיאור-על • סוג הטרנסאקציה ותנאי הפעלתה. • המשתמשים. • אמצעי קלט ופלט • פרץ שובל, כרך ב', עמ' 166

13. עץ תפריטים • המרה של ה-DFD לתרשים-עץ. • איחודי שורות ותפריטים עד שלכל טרנסאקציה שורות הפעלה בודדה. • בסוף: שינוי שמות / סידור-מחדש נוסף במידת הצורך. • לא כוללים טרנסאקציות זמן, זמן-אמת. • לא מחייב את עיצוב התפריטים הסופי בתוכנית.

14. סכמת DB • ב-ADISSA שומרים מידע בצורה רלציונית. • מאגר הוא אבסטרקציה: בפועל צריך לעצב ממש את סכמת ה-DB ולהגדיר את הטבלאות. • כל מאגר יומר לטבלה אחת או יותר. • יש לבדוק שהמאגר מאוזן לפני ביצוע ההמרה. • במידה והמאגר מתפרש על מספר טבלאות, יש ליצור קשרי PK-FK.

15. כתיבת תיאור מפורט של טרנסאקציות • כדי להשלים את עיצוב מערכת המידע יש לתאר במפורט את הטרנזאקציות שיהיו בסיס לכתיבת תוכניות מחשב בשפת התכנות שנבחרה • בשלב זה מתייחסים לכל טרנזאקציה כאילו היא תיושם כתכנית מחשב נפרדת • כל פקודה תטופל כלהלן • פקודת Execute Function - תוחלף בתיאור מובנה של הפונקציה המתאימה. • פקודת Input/Output - תוחלף בהפניה להגדרת הקלט או הפלט שלה • פקודת Read/Write - תוחלף בפקודות בשפת SQL.

16. UP • זיהוי שחקנים ונסיבות שימוש • מודל תחום • SSD לתרחישי הצלחה של כל נסיבת שימוש • חוזה לכל אירוע מערכת (Ping-Pong) • SD מפורט לכל חוזה • תרשים מחלקות של שלב העיצוב • קוד • מטא-מודל?

17. תרשים נסיבות שימוש • נסיבות שימוש =~ טרנסאקציה: תהליך המתמשך על גבי מספר צעדים. • בהיפוך מתרשים DFD, אין חשיבות לצד בו מופיע השחקן! • ניתן לבצע ירושה בין שחקנים. • במידת הצורך ניתן לתאר קשרי extend,include.

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

19. מודל תחום • תרשים מחלקות ב-UML המתאר את עולמו של הלקוח. • כולל את הרכיבים הבאים: • מחלקות מעולם הלקוח בלבד ותכונותיהן • קשרים בין המחלקות עם ריבוי ותפקידים (roles) • OCL • לא כולל: • שיטות • מחלקות תכנותיות • נראות (visibility, קשרים חד-כיווניים)

20. OCL • שפת אילוצי העצמים • משלימה את תרשים המחלקות • לשים לב שפעולות אוסף – רק ע"ג אוספים! • כלומר: forAll(…)זה רע! • allMySonsforAll(…)זה טוב!

21. תרשים רצף של המערכת(SSD – System Sequence Diagram) • תרשים רצף עם השחקן מצד שמאל והמערכת מצד ימין. רק שניהם בלבד. • פינג-פונג המגלם את תרחיש ההצלחה העיקרי. • כל זוג (הלוך-חזור, פינג-פונג...) = אירוע מערכת אשר עבורו ייכתב חוזה.

22. חוזה • מסמך המתאר אירוע מערכת מה-SSD אשר כולל: • שם • באילו UC פעולה זו מתבצעת – מאפשר מחזור • תנאי קדם (בשפה חופשית) • תנאי סיום – בלשון אובייקטים: מתמקדים ב- • יצירה, הריסה, שינוי מצב • של • אובייקטים, קשרים בין אובייקטים.

23. תרשים רצף • בהתבסס על התנאים שמציב החוזה, מציירים תרשים רצף עבור פעולה אחת (=עבור חוזה אחד). ה-System הופך ל-Controller ומצד ימין נוספים אובייקטים נוספים. • הקריאות שנכתיב כאן יקבעו את השיטות ואת ההיכרויות ב-Design Class Diagram.

24. תרשים רצף • הקפידו על: • שימוש ב-getters, setters ועקב כך ציור מפורש של כל אובייקט שבשדה שלו אתם משתמשים. • ציון מפורש של name:Type בכותרת של קו החיים. • קריאה-עצמית לטובת אתחול מפורש של משתנים. • לא לדאוג בקשר ל: • עובי של קווי-החיים • מספור

25. תרשים מחלקות של שלב העיצוב • תרשים מחלקות ב-UML המתאר את עולמה של התוכנה/המערכת. • כולל את הרכיבים הבאים: • מחלקות מעולם הלקוח בלבד ותכונותיהן • קשרים בין המחלקות עם ריבוי ותפקידים (roles) • OCL • וגם: • שיטות • מחלקות תכנותיות (Controller, DB Connector...) • נראות (visibility, קשרים חד-כיווניים) • בדר"כ פשוט הרחבה של מודל התחום.

26. קוד • במידה ותצטרכו לכתוב קוד: • שימרו על תאימות! • עם תרשימי הרצף. • עם תרשים המחלקות.

27. מטא-מודל • מודל תחום עבור מקרה כללי יותר של המערכת. • דוגמא ממועד מסתיו 2012: • הסיפור: מערכת פניות של לקוחות. נציגי שירות מטפלים בפניות של לקוחות. הנציג בוחר את הנושאים בהם עוסקת הפניה מתוך רשימת נושאים הקיימים במערכת, וממלא עבור כל נושא את טענות הלקוח. במידת הצורך מגדיר נציג השירות קטגוריה חדשה. • שאלת המטא-מודל: בהתבסס על תיאור המערכת כתבו תרשים מחלקות מוכלל לקו מוצרים (באמצעות ADOM) המטפל בתחום העוסק במעקב אחר התקדמות תהליכים, כגון משלוחים, הכשרות מקצועיות וכד'. לחלופין, בנו שפה להגדרת היישומים באמצעות מידול על (Meta Model).

28. שני הדברים החשובים בתהליך: • תוצרים השומרים על עקביות • נסיבות שימוש – תואמות לסיפור. • System Sequence Diagram – תואם לנסיבת שימוש. • חוזים – תואמים ל-SSD. • Sequence Diagram –תואם לחוזה. • Design Class Diagrams – תואם ל-Sequence. • תהליך איטרטיבי ולומד • מותר וכדאי לחזור אחורה ולתקן!!! • ואז כמובן לעדכן את השלבים הבאים בתהליך.

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

30. בעת ביצוע המבחן • בלי פאניקה! • לקרוא את כל הסעיפים לפני שמתחילים! (Reverse Engineering) • לעשות כל סעיף בצורה מסודרת. • לא להיתקע!יצירתיות והבנה הם "תהליכי רקע" בראש – לעזוב ולחזור מאוחר יותר. • לענות על הכל. • שאלות (בצירוף השאלה הרלוונטית כקובץ מצורף): guy4261@gmail.com בהצלחה!!!

31. אחרי הקורס • תשתמשו ב-ADISSA, UP? • מי יודע... • תשתמשו במתודולוגיה? • כנראה בסגנון Agile. • תשתמשו בתרשימים? • בחלק מהמקומות. • עבור טיוטות. • תבצעו ניתוח ועיצוב? • תמיד.