Feature Assembly: A New Feature Modeling Technique

1. Feature Assembly: A New Feature Modeling Technique Lamia AboZaid, Frederic Kleinermann, and Olga De Troyer 2010 Tamar Elisha 021658612 Liann Lev-Er 200069078

2. רקע • FODA הוכר לראשונה ב- 1990 עבור domain modeling ומאז הפך לטכניקה עבור מידול Software Product Line (SPL) . • הרבה הרחבות הוצעו לטכניקה אולם טכניקות למידול מאפיינים לא זכו לאהדה מחוץ ליחידות המחקר. הסיבות הן: • קיימים הרבה ניבים (דיאלקטים) לטכניקות של Feature Modeling כאשר כל אחד מהם מתייחס לנושאים אחרים – אין מידול מוסכם יחיד. • ל- Feature Modelsיש חוסר "במנגנוני אבסטרקציה". הדבר מקשה להשתמש בהם כאשר ממדלים פרויקטים עם הרבה מאפיינים (features). • מעט הכוונה או שיטות קיימות בהקשר של איך להשתמש בטכניקת המידול (הדבר מוביל בד"כ למודלים עם ערך מוסף מזערי).

3. רקע המשך... • הטכניקה המוצגת במאמר זה מתבססת על הרבה נקודות מבט למידול תוכנות במונחים של "חיבור" מאפיינים. טכניקת המידול הזו היא חדשנית מהרבה בחינות כאשר ידוע כי התמקדות בהיבט אחד בכל פעם מסייע להתמודד עם מורכבות. • Feature Assembly Modeling (FAM)מספקת מנגנון הפשטה טוב יותר על ידי שימוש בנקודות מבט בזמן מידול תוכנות גדולות ומורכבות. בנוסף ה- Scalability גדל. מפתחי השיטה הורידו את מספר הפקודות הבסיסיות בשביל לפשט ולהקל על תהליך המידול. • ה- FAM הינה טכניקת מידול מאפיינים שמטרתה ליצור מודל שיבטא את מגוון ההיבטים הרב של תוכנה בעלת משתנים "הפכפכים" הדבר נעשה על ידי שימוש בפרספקטיבות שונות.

4. ייעוד השיטה • השיטה מיועדת למידול אפליקציות באופן כזה שיקל על תהליך המידול. היא ממדלת את האפליקציות מנקודות מבט שונות עם התייחסות בכל פעם להיבט של מאפייני האפליקציה. • השיטה מיועדת למנתחי מערכות ומפתחים בשלבי הגדרת דרישות המערכת. • על פי המאמר:Feature-Oriented Domain Analysis (FODA) Feasibility Study (המאמר אשר הציג את הנושא לראשונה). ה- feature model משרת כמתווך בין המשתמשים לבין המפתחים. עבור המשתמשים ה- feature model מראה מהם ה- features הסטנדרטים, איזה features הם יכולים לבחור ומתי. עבור המפתחים, ה- feature model מציין מה צריך לבטא במונחים של פרמטרים וכיצד זה צריך להתבצע.

5. תיאור תחום • השיטה אינה מתארת מידול תחום. היא דוגלת בעיקר במידול אפליקציות. • כותבי המאמר בחרו להשתמש בהגדרות של FODA והרחבותיו (הנקראים feature models) להרחיבן ולשנותם כך שיתאימו למערכות גדולות. • אין במאמר אזכור לכך שהשיטה נועדה למדל תחומים אלא אפליקציות (רחבות ככל שיהיו). • "The perspectives used for the modeling can be freely chosen depending on the application under consideration"

6. פעולות על אפליקציות • השיטה אינה מתייחסת לתהליך יצירת אפליקציות אלא לתיאורן מנקודות מבט שונות. • נעזרים בפרספקטיבה בשביל למדל את השונויות הרבות של תוכנה מנקודות מבט שונות. ניתן לבחור בין ההשקפות (נקודות מבט) השונות בהתאם לאפליקציה הנלקחת בחשבון. • השקפות אפשריות: השקפה מערכתית, השקפת משתמש, השקפת מיקום (לוקליזציה), השקפה פונקציונאלית/לא פונקציונאלית והשקפת ממשק משתמש. • יש לציין כי אין חובה לעשות שימוש בכל ההשקפות. יתרה מכך, ניתן להרחיב את ההשקפות המוצעות, למשל task perspective עבור task-based application. • כותבי המאמר ציינו כי במחקר העתידי שלהם הם מתכוונים ליישם את הטכניקה המוצעת בתהליך תעשייתי גדול בשביל לתת תוקף (validate) לשימושיות (usability) ולהבעתיות (היכולת להביע משהו expressivity).

7. שפת המידול

8. שפת המידול המשך... • ישנם 2 סוגים של features: • Feature – מייצג יחידה לוגית או פיזית מוחשית (ממשית) או מאפיין של המערכת. הוא מיוצג על ידי מלבן עם שם ה- feature • Abstract feature – הינו מאפיין לא מוחשי. זוהי הכללה של עוד features מסוימים (מוחשיים או אבסטרקטים) הוא מיוצג על ידי מלבן מקווקו עם שם ה- feature Feature Name Feature Name

9. Whole • Whole Part Part mandatory optional שפת המידול המשך... • האופן שבו features מורכבים ביחד במערכת נעשה באמצעותfeature relations"": • Composing relation– מתאר קשר שלם וחלקיו. הוא יכול להיות optional או mandatory.

10. Education Primary post-primary High שפת המידול המשך... • Generalization / Specification relation– נעשה בו שימוש ב- abstract feature והוא מרשה פירוט של features אפשריים של ה- abstract feature. • רק ל- abstract feature אפשר שיהיו קשרי הכללה / פירוט. • ה- abstract featureמייצג variation point כאשר ה- feature האופציונאלי מייצג את ה- variant. • ניתן להוסיף abstract feature ללא variations ולהוסיפם במועד אחר (Open).

11. שפת המידול המשך... • מספר ה- features שניתן לבחור מהם מיוצג על ידי "אילוץ עוצמה" (cardinality). האילוץ מייצג את מספר ה- features המותרים המינימאלי והמקסימאלי. מקף (-) פירושו "הכל" (Any). • Feature Dependencies – מאפשרים להגדיר תלויות בין מאפיינים; כיצד מאפיין אחד משפיע על מאפיינים אחרים. ניתן להגיד תלויות בין מאפיינים מנקודת מבט אחת ובנוסף בין מאפיינים מנקודות מבט שונות. 1 : 4 1 : - 2 : 5

12. Inter-Perspective dependencies • ישנן תלויות סימטריות (excludes, incompatible, same ), וישנן תלויות א-סימטריות (extends, impacts, includes, requires, uses), לכן הם מיוצגים באמצעות חץ כיווני. לדוגמא:

13. Intra-Perspective dependencies • לעיתים מאפיינים נקשרים אחד לשני גם כשהם שייכים לנקודות מבט שונות. נעשה שימוש באותם הייצוגים כמו ב- Inter-Perspective dependencies רק שכאן ניתן להוסיף קשרי AND ו- OR. מבנה התלויות נראה כך: • חשוב לציין כי כאן על מאפיין להיות מוגדר בשם של נקודת המבט ובשם של המאפיין עצמו: User_interface.cheackout AND …

14. השונות והזהות ב- FAM • מבוצע ע"י: • הפרדה בין feature ו- abstract feature • הבחנה בין היחסים של אותם features(composition & Generalization/Specification) • שימוש ב- Feature Dependencies (תיאור ההשפעה של feature אחד על אחר מאותה הפרספקטיבה או מפרספקטיבות שונות).

15. תהליכים וכלים מלווים • השיטה אינה מציעה תהליך פיתוח מסודר. אולם היא מציעה למדל את המערכת מנקודות מבט שונות על מנת להקל על תהליך המידול מצד אחד ועל תהליך קריאת המידול מצד שני. • השיטה אינה מציעה כלי תוכנה נלווים (לכן השתמשנו בתוכנת Visio).

16. דוגמא

17. Service & Support Systems • מרכז תמיכה בארגון נועד לקבלת דיווח על בעיות ומציאת פתרונות. • מרכז התמיכה נעזר בכלי עבודה שונים למעקב וניהול של פניות השירות כגון תקשורת טלפונית (Call Center), תמיכה מקומית (פונקצית help), ניהול צ'אט עם נציג תמיכה ועוד. • התמיכה יכולה לתת מענה לסוגי תקלות שונות כגון תקלות אחזקה, בעיות מחשוב, בעיות תפעול וכיו"ב. • מערכות אלו מאפשרות מעקב אחר סטאטוס הקריאה ואופן טיפולה תוך תיעוד השתלשלות דיווחי ההתקדמות עד לסגירתה, הקצאת משאבים ופיתוח אוסף פתרונות סטנדרטיים לבעיות משותפות. • התחום מורכב מאפליקציות שבהם משתמש או לקוח מבקש או מקבל סיוע מגורם שלישי אנושי או ממוחשב, בעוד שהאפליקציות אינן פותרות את התקלה או הבעיה כשלעצמן אלא הן מהוות אבן דרך במסלול למציאת הפתרון.

18. Inter Perspective System Perspective 1 : 2 1 : - 1 : -

19. User perspective 1 : 1 1 : -

20. Functional Perspective 3 : 3 1 : -

21. Non Functional Perspective 1 : - 1 : -

22. Intra-Perspectives • functional.mail/sms notifications requiressystem.outlook • system.callsimpactsfunctional.report generator • user.companyusesnon_functional.virus protection ANDnon_functional.backup

23. הישגי השיטה • אי בהירות במושגי המידול – ב- FODA המקורי לא ניתן להבחין מבלי להפעיל את ההבנה האינטואיטיבית של המשתמש האם מדובר בקשר של שלם וחלקיו או בקשר של הכללה / פירוט.ה- FAM מעניק מענה ע"י יצירת: • Feature – שלם וחלקיו • Abstract feature – מוגדר עבור variation point של הכללה. • החמצת אפשרויות לשימוש חוזר – ב- FODA המקורי כל feature מוגדר כ- mandatory/optional – דבר המגביל את השימוש החוזר של ה- feature בהקשר אחר. • חוסר ב Abstraction mechanisms – כאשר ממדלים ב- FODA המקורי המודלים נעשים גדולים וקשים למידול ולקריאה. מכיוון שה- FAM מציג שיטה חדשה למידול (על ידי שימוש בפרספקטיבות) קל יותר למדל ולקרוא. המודלים קטנים יותר וברורים יותר וזאת משום שמתרכזים בהשקפה אחת בכל פעם.

24. תודה רבה