ניתוח ועיצוב מערכות תוכנה אביב 2012

ניתוח ועיצוב מערכות תוכנהאביב 2012 תרשימי מחלקות ואילוצי OCLפתרון שאלות ממבחנים קודמים

מועד א 2009 אביב – סיפור מקרה משאלה 1 • לפניכם תיאור חלקי של מערכת ניהול כנסים אקדמיים. במערכת זו מגוון משתמשים: מנהל מערכת, מנהל כנס, מעריכים ומחברים. • מנהל המערכת יכול להגדיר כנסים, ומשתמשים. מנהל כנס יכול לצרף מעריכים לכנס, לבצע השמה של מעריכים למאמר, לקרוא את המלצות המעריכים, וכן להחליט על קבלה או דחייה של מאמר לכנס האמור. בנוסף יכול מנהל הכנס לשלוח הודעות שונות לאוכלוסיות השונות תוך שימוש במערכת הדוא"ל הקיימות. • מעריך, יכול להירשם למערכת ולבצע הערכה על המאמרים שהוגדרו עבורו. • את ההערכה הוא מבצע עפ"י קריטריונים שמגדיר מנהל הכנס כאשר בכל קריטריון סולם הציונים נע בין 1 ל 10. מחבר יכול להגיש מאמר, לקרוא את ההערכות בגמר תהליך ההערכה. יכולים להיות מספר מחברים לאותו מאמר. לכל המשתמשים באתר נשמרים אותם הפרטים של שם, תואר, מוסד ודוא"ל. • כדי להגיש מאמר, תחילה נרשם המחבר. רק לאחר הרישום הוא יכול לבצע הגשה של המאמר הכוללת את שמו, תקציר וקובץ מצורף. בנוסף על מחבר להגדיר את הקטגוריות להם שייך המאמר.

מועד א 2009 אביב – זיהוי נתונים משאלה 1 • ראשית נבחין מיהם השחקנים בסיפור המקרה : מנהל מערכת, מנהל כנס, מעריכים ומחברים. • זיהוי של אלמנטים נוספים פרט לשחקנים : כנסים, מאמרים, הערכות של מאמרים, קריטריונים לצרכי הערכה וקטגוריות המאמר. • נקודה למחשבה – האם כדאי להשתמש באסוציאציות כדי לתאר את תפקידי השחקנים, במקום בהגדרת מחלקה עבור כל בעל תפקיד. לצורך שימוש באסוציאציות נצטרך להגדיר מחלקה בסיסית עבור כל בעלי התפקידים.

הגישה הנלהבת: ללכת לפי הסיפור, ולבנות מחלקות ולקשר ביניהן בלי לחשוב פעמיים – "צמוד לטקסט". (טיוטה)

זה יעבוד. • אבל: משתמשים מסוגים שונים יורשים ממחלקה אחת. מה ההבדלים? • משתמש שמפרסם – הוא מחבר. • משתמש שמפרסם ביקורת – הוא מעריך. • מחבר-מעריך?

גרסה משופרת – צמצום במחלקות ובקשרים מי מגדיר קריטריון לכנס? מי מגדיר קטגוריה למאמר? משתמש לא יכול לנהל כנס? (ניתן לפתרון?)

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

מועד א 2009 אביב – תרשים מחלקות לשאלה 1

מועד א 2009 אביב – הוספת אילוצים לשאלה 1 • לפניכם מספר אילוצים בשפה טבעית למערכת שתוארה לעיל. עליכם לבדוק האם נדרש לכתוב את האילוץ ב-OCL. אם כן יש לכותבו, אם לא יש להסביר מדוע אינו נדרש : • למאמר יכולים להיות עד 5 מחברים. • מאמר לא יכול להיות מוערך ע"י אחד ממחבריו. • מספר המאמרים שמגיש מחבר בקטגוריה אחת לא יכול להיות גדול מ-3. • ממוצע ציוני מעריך צריך להיות גדול מ-5 בכל אחד מהקריטריונים. • ממוצע ההערכות של המאמרים בכל קטגוריה צריך להיות זהה.

מועד א 2009 אביב – טיפול באילוצים בשאלה 1 • למאמר יכולים להיות עד 5 מחברים. לא נדרשת הוספת אילוץ – הטיפול כאן יעשה ע"י הוספת ריבוי של 1 עד 5 באסוציאציה של בעל תפקיד ומאמר. • מאמר לא יכול להיות מוערך ע"י אחד ממחבריו. נשתמש ב-excludesAll בין קבוצת מחברי המאמר ומעריכי המאמר : Context Paper inv: reviewers->excludesAll(authors) • מספר המאמרים שמגיש מחבר בקטגוריה אחת לא יכול להיות גדול מ-3. נמצא את אסופת כל הקטגוריות של מאמרים שכתב מחבר, עבור כל קטגוריה נאסוף את כל המאמרים שנכתבו ע"י המחבר הנוכחי, ונדרוש פחות מ-4 מאמרים : Context Person inv: authored.category->forAll(c|c.paper->select(authors->includes(self))->size()<4)

מועד א 2009 אביב – טיפול באילוצים בשאלה 1 • ממוצע ציוני מעריך צריך להיות גדול מ-5 בכל אחד מהקריטריונים. נמצא את אסופת כל הקריטריונים של הערכות המעריך, ועבור כל קריטריון כזה, נבצע סכימה של הציון של כל הערכה ע"פי קריטריון שביצע המעריך – ונקבל את סך כל הציונים של מעריך לכל קטגוריה. נחלק את סך כל הציון של כל קטגוריה במספר ההערכות בכל קטגוריה – כאשר נמצא את מספר כל ההערכות בדומה למציאת סך כל הציונים בקטגוריה. חלוקת סך כל הציונים במספר הציונים תניב את הממוצע – ונדרוש שמספר זה יהיה גדול מ-5 לכל קטגוריה : Context Person inv: review.criterion  forAll(c| (self.review.evaluation  select(criterion =c).gradesum() / self.review.evaluation  select(criterion =c).gradesize())>5) Context Category inv: Category.allInstances->forAll( c1, c2|c1.paper.review.evaluation.grade  sum()/c1.paper.review.evaluation.gradesize()=c2.paper.review.evaluation.gradesum()/c2.paper.review.evaluation.grade size())

מועד ב 2009 אביב – סיפור מקרה משאלה 1 • לפניכם תיאור חלקי של מערכת רכש. • במערכת זו עובדים יכולים להזמין מוצרים שונים המסווגים לפי קטגוריות שונות. • הבקשה להזמנה כוללת את תיאורה והדחיפות שלה, תאריך ועוד פרטים נדרשים (מלל חופשי). • לאחר ההזנה, הבקשה עוברת לאישור מנהל מחלקה. • במידה שהמנהל מאשר את הבקשה, היא עוברת למחלקת רכש. • בעת הטיפול בבקשות, לכל בקשה בוחרת מחלקת הרכש את הספק הרצוי מרשימת ספקים המתקבלת ממערכת חיצונית (אבל מנוהלת במערכת), מחליטה על המחיר ופותחת בקשת רכישה חדשה. • לעיתים, יש גם עריכה של ההזמנה המקורית (לדוגמא שינוי מוצר). • כלל הפעילויות ומבצעיהם נשמרים במערכת כך שמנהל המפעל יכול לקבל דוחות שונים על פעילות המערכת.

מועד ב 2009 אביב – זיהוי נתונים משאלה 1 • זיהוי שחקנים: עובדים, מוצרים, קטגוריות, ספקים, בקשות. • זיהוי קשרים בין האלמנטים: • עובדים מזמינים מוצרים • מוצרים משתייכים לקטגוריות • בקשות מסופקות ע"י ספקים • אותם ספקים מספקים מוצרים • ישנו עובד – מנהל – שמאשר את הבקשות • כיצד נבדיל בין עובדים של מחלקות שונות? • כיצד נבדיל בין עובד רגיל לבין מנהל המחלקה שלו? • כיצד נבדיל בין בקשה שהוגשה וטרם אושרה לבין בקשה מאושרת ומתומחרת? • כיצד נאפשר עריכה מחודשת של ההזמנה (הבקשה) המקורית? • אלמנטים שקופים: המפעל / החברה? מחלקת הרכש? מנהל המפעל?

מועד ב 2009 אביב – שרטוט ראשוני

מועד ב 2009 אביב – שרטוט ראשוני + פירוט

מועד ב 2009 אביב – ניסיון 2#

מועד ב 2009 אביב – תרשים מחלקות לשאלה 1

מועד ב 2009 אביב – תרשים מחלקות לשאלה 1 Error: every Employee is also a manager???

מועד ב 2009 אביב – תרשים מחלקות לשאלה 1 Solves Many Problems!!!

מועד ב 2009 אביב – תרשים מחלקות לשאלה 1 Can Supplier supply Products?

מועד ב 2009 אביב – השוואה בין פתרונות • Approval is only relevant inthe context of ApprovedRequest! • Differences in Multiplicites (Category-Product) • Differences in Department-Employee association (Regular vs. Composition)

מועד ב 2009 אביב – הוספת אילוצים לשאלה 1 • לפניכם מספר אילוצים בשפה טבעית למערכת שתוארה לעיל. עליכם לבדוק האם נדרש לכתוב את האילוץ ב-OCL. אם כן יש לכותבו, אם לא יש להסביר מדוע אינו נדרש : • עובד יכול להזמין עד 5 פריטים במהלך שנה. • סך כל הפריטים שעובד יכול להזמין צריך להיות קטן מ-100. • לכל בקשה יש רק הזמנה אחת. • לא יכולה להיות הזמנה לבקשה שאינה מאושרת ע"י מנהל המחלקה של העובד. • הבקשות של עובדים מאותה מחלקה צריכים לכלול עד 10 פריטים מכל קטגוריה.

מועד ב 2009 אביב – טיפול באילוצים בשאלה 1 1. עובד יכול להזמין עד 5 פריטים במהלך שנה. Context Employee inv Max5OrdersPerYear: let years : Set(Integer) = issued.date.year()->asSet() in years  forAll(y : Year | self.issued  select(o : OrderRequest |o.date.year() == y)  size() <= 5)

מועד ב 2009 אביב – טיפול באילוצים בשאלה 1 2. סך כל הפריטים שעובד יכול להזמין צריך להיות קטן מ-100. Context Employee inv Max100Products: Issued.Product  size() < 100

מועד ב 2009 אביב – טיפול באילוצים בשאלה 1 3. לכל בקשה יש רק הזמנה אחת. ננווט מ-OrderRequest אלי PurchaseOrder. הריבוי הוא 1..0 . האילוץ מתקיים. (רק הזמנה אחת לכל היותר.)

מועד ב 2009 אביב – טיפול באילוצים בשאלה 1 4. לא יכולה להיות הזמנה לבקשה שאינה מאושרת ע"י מנהל המחלקה של העובד. אם היא מאושרת ע"י מנהל המחלקה – אזי, בקיצור, היא מאושרת! Context PurchaseOrder inv approved: status = true

מועד ב 2009 אביב – טיפול באילוצים בשאלה 1 4. לא יכולה להיות הזמנה לבקשה שאינה מאושרת ע"י מנהל המחלקה של העובד. התשובה הקודמת נלקחה מן הפתרון הרשמי. אם נרצה לפרט יותר, אזי: context PurchaseOrder inv approvedByManager: status implies ((נניח כאן כי 'סטטוס' הנו משתנה בוליאני issued.Department.manager.approvedBy->includes(self)

מועד ב 2009 אביב – טיפול באילוצים בשאלה 1 5. הבקשות של עובדים מאותה מחלקה צריכים לכלול עד 10 פריטים מכל קטגוריה. Context Department inv Max10ItemsPerCategory: Worker.issued.product.category asSet()  forAll(c:Category | self.worker.issued.product  select (p:Product |p.category = c)  size() < 10)

ניתוח ועיצוב מערכות תוכנה אביב 2012