שאלות לגבי אפיון UML

[אור 1925]

שאלות לגבי אפיון UML

אני מבצע אפיון עבור מערכת מידע קטנה-בינונית (כחצי שנת אדם). האפיון מבוצע ב-UML והתרשימים יבוצעו ב-VISIO 2003 (אילוץ מוכתב). מכאן ואילך יש לא מעט שאלות שעולות - 1. אני מתכוון להפיק תרשימי Use Case עבור התהליכים (כל קבוצת תהליכים בתרשים). אני מעוניין לפשט ולהקל על שלב העיצוב ולכן מתכוון לפרט את המורכבים שבתהליכים בשתי צורות : א. הוספת התייחסות לתהליכי משנה ע"י פירוק מסוג include. במאמר מוסגר, לא היה ב-VISIO קשר מעין זה והוספתי אותו בהתבסס על generalization. האם בסדר? האם מקובל/ניתן לייצר אף פירוק לפירוק? ב. יצירת Activity Diagram לכל use case משמעותי. 2. המערכת כוללת מספר תהליכים, שמשותף להם תהליך בסיסי. לצורך הדוגמה, מדובר בתהליך מכירת רכב והתהליכים הנגזרים הם מכירת רכב פרטי, מכירת ג'יפ וכו'. חשבתי על הכיוון הבא - א. להגדיר תרשים אשר יכיל את התהליך הבסיסי (עם פירוקי include, כאמור). להפיק תרשימים עבור התהליכים הנגזרים, כאשר ליצור קשר של Generalization בין תהליך ה"בסיס" לבין התהליך מורחב. אגב, ב-VISIO תחת הסטנסיל של Use Case, מצאתי רק קשר של inherits. האם מתאים או שמא עליו לייצר קשר ללא כיתוב וכיוון החץ (מתהליך הבסיס לתהליך הנגזר) יצביע על המהות? 3. ממשקים/שירותים ישומיים – יש לי מספר ממשקים שונים של שליפת מחיר ואימות פרטי לקוח ממערכות תפעוליות שונות, כחלק מתהליכי המכירה. חשבתי לייצר תרשים של ממשק שליפה בסיסי למערכת תפעולית (עם פירוק לשליפת מחיר ולאימות פרטי לקוח). ולאחר מכן לייצר קשר של generalization ל-UC של השוואת נתונים מול מערכת X (לכל המערכות, למעשה). אם לסבך את התמונה, ה-UC של השוואת נתונים ממערכת X הוא פירוק של תהליך מכירת רכב פרטי, למשל. א. האם נכון/מקובל? ב. איך זה מסתדר עם כך ש-UC צריך להראות אינטרקציה בין actor לבין UC? בהתאם לתכנון למעלה, קיצור בין actor של המשתמש הוא מלאכותי ומאולץ. הערה: בשל הרקע בתכנות, אני חש שאני יותר מדי מודע ליחסי ההכלה וההורשה האפשריים. האם בעוכריי? ככלל, כיצד מביאים לידי ביטוי וכיצד מקובל להתייחס ליחסי הורשה בתרשים ה-UC? 4. האם מקובל לציין חומרה (למשל, מדפסת), כ-ACTOR? מהם החוקים ל-ACTOR? 5. ארגון הנתונים בכלי – אני משתמש, כאמור, ב-VISIO 2003. חשבתי לארגן את המודל בצורה הבאה – לכל קבוצת תהליכים (וה-actors הבלבדיים שלהם) לפתוח subsystem משלהם. מה דעתכם? האם יש שיטות יותר מקובלות/מפורטות בכלי זה? ראשית, תודה על הסבלנות

שנית, אשמח לכל תגובה/השגה/הערה/הארה/תשובה על הגיגיי אלה.

 

[עידו פ]

-->

1. א. זכור כי VISIO מבוסס על UML 1.1 ולא על UML 2, ולכן חסרים בו הרבה דברים, ביניהם נושא ה-include וה-extends. זו אחת הסיבות מדוע VISIO הוא כלי מעפן ל-UML ועדיף למצוא כלי אחרים. ישנם כל מיני כללי אצבע לגבי עד כמה לרדת ברמת ה-include (אתה יכול לראות בקישורים קישורים לאתרים בנושאי UML, אני ממליץ שתקרא באתר של agilemodeling). אני אישית מנסה לא לעשות יותר מרמה אחת של include (גם ככה include אמור להיות אמירה של "UC א' משתמש ב-UC ב'", אז אם תהיה הרחבה נוספת, היא תהיה בהגדרה של UC ב'. 2. ב-UML, הקונספט של UC ש"מרחיב" יכולות של UC אחר מכונה extends. ההגדרה שלך שלכל מכירות הרכבים יש משהו משותף אינו תואם את extends וגם לא ממש מתאים ל-include, מאחר ו"משהו משותף" אינו מגדיר תהליך אלא נשמע כמו משהו יותר קרוב ליישום עצמו (קטע קוד משותף) - יכול להיות באמת שהקרבה שלך לקוד הינה בעכרך. 3. UC אמור לתאר תהליך עסקי במערכת, כך שנושאים כגון התקשרות עם מערכות אחרות לשם קבלת מידע זה לא יותר מלצייר את המערכת כ-actor שיחד עם ה-actor האנושי, שניהם ביחד מפעילים את התהליך. אני לא רואה שימוש ל-UC של ממשק. אני מציע שתקרא באתר שהזכרתי לעיל למה משמש UC ו-UCD, יש לי הרגשה שאתה מפספס את המטרה של UC. לרוב מה שקורה בין המערכות בכל הקשור להשוואת נתונים הינו חלק מתיאור ה-UC ולא חלק מה-UCD עצמו (תיאור במסמך ה-UC) 4. מדפסת זה לא אקטור. אקטור הוא מישהו/משהו שעובד מול ה-UC וצורך את התוצאה של ה-UC (מדפסת לא צורכת תוצאה של UC, מדפסת היא פקטור ב-UC כמו מקלדת ועכבר). שוב אני מציע שתקרא באתר הנ"ל 5. חלוקת subsystem לרוב מבוצעת לפי ישויות המידע של המערכת, בהנחה וניתן לחלקן לקבוצות. לחילופין, יש המחלקים את ה-UC ל-sub systems לפי יחידות המסירה של המערכת.

 

[אור 1925]

תגובתי / המשך הדיון

ראשית, תודה על התגובה. בזמן שהמתנתי לתשובה, קראתי בלא מעט אתרים ולהלן מספר תובנות. לפני הכל, ישנן *בפועל* גישות שונות ואתרים לא מעטים אף מציינים זאת (על אפו וחמתו של התקן?). כך למשל, ראיתי מאמרים, שמציינים כי חומרה (יחודית?) יכולה להיות Actor (כמו למשל, התקן זיהוי של העין). 1. VISIO 2003 SP2 כבר תומך ב-UML2. יש לו uses (הצורה הקודמת של include, נאמר במספר אתרים) ו-extends, בין שלל הקשרים. 2. בנוגע ל-extends ראיתי שממליצים להשתמש כאשר קורה משהו לא "רגיל". על כל פנים, לא התכוונתי ל-extends או ל-include. התכוונתי, כאמור, ל-inherits (או ל-globalization, ללא שום כיתוב). האם לא זה שימושו? דווקא האתר שהפנית אותי אליו, מציין זאת:

" Inheritance is applied in the same way as you would on UML class diagrams – to model specialization of use cases or actors in this case"​

הדוגמה שאותה הוא מציג היא של רישום לאוניברסיטה ורישום של בן משפחה לאוניברסיטה, אשר יורש ממנו. האם אני מפספס משהו? אני אף מצרף את הדוגמה שלו, וזה מעורר שאלה – למה אין קשר בין ה-Actor לבין ה-Enroll Family Member in University? האם מעצם הירושה ו/או השימוש ע"י אותו Actor, נוצר קישור? המקרה שלי, כאמור, דומה (אך שונה?) - אני מבצע פעולות דומות, אשר מכילות פעולה בסיסית זהה. האינטרקציה של המשתמש היא עם הפעולות עצמן. האם זהו השוני? במאמר מוסגר- מהי התועלת של AD אם ה-UC מפורט דיו?

 

[עידו פ]

-->

הקדמה - UML אינו תקן, אלא נוטציה (סגנון כתיבה), ולכן כל נושא ה"תובנות" שגופים וארגונים שונים הגיעו אליהן אינן קשורות ל-UML כנוטציה אלא לשימוש ב-UML כחלק ממתודולוגיית פיתוח. 1. חיפשתי ולא מצאתי אזכור לכך שה-SP מעדכן את הויזיו ל-Uml 2.0, אשמח לקבל הפניות למסמכי מיקרוסופט אם יש לך. uses זה אכן uml 1.1 ולכן אם הוא "עדיין" תומך בזה זה אומר שהוא עדין לא עודכן. 2. המטרה של extends היא הרחבה של תהליך (דוגמת הרישום סטודנט חוץ שמרחיבה את רישום סטודנט "רגיל"). במקרה שלך אם זכורני נכון אתה דיברת על תהליכים שונים שיש להם מכנה משותף - זה לא extends, במקסימום זה include אם התהליך שאליו עושים include הוא תהליך בפני עצמו שיכול להתבצע מבלי לבצע את התהליכים שעושים לו include (לדוגמה - הכנת טופס מכירה שעושים בכל מכירה של רכב כלשהו אינו תהליך, כי הוא לא מבוצע בנפרד מ"מכירת רכב שטח" או "מכירת רכב משפחה") - מקרים כאלו הם מקרים שיש יותר לתת עליהם דגש בזמן זיהוי ותכנון ישויות המידע של המערכת ובזמן העיצוב של המערכת ירושה ב-OO כפי שרובם מכירים, הינה ירושה מאחת הסיבות הבאות - globalization (אבא הוא לרוב אבסטרקט ומכיל את המכנה המשותף לכל הבנים) או specialization (האבא הוא משמעותי וכל אחד מהבנים למעשה מהווה הרחבה של האבא לישות חדשה שמרחיבה את האבא). ירושה ב-UC היא יותר specializtion מאשר generalization כי האחרון מרמז על כך שה-UC האב הוא חסר משמעות בתור UC - ולכן גישה זו כלפי UC אינה נכונה (זכור - UC הינו תהליך עסקי שניזום ע"י או עבור איזשהו Actor במערכת) לגבי הדוגמה של הירושה, אני מניח שה-Actor לא נרשם מהסיבה שציינת (בגלל קשר הירושה). לגבי הדוגמה שלך שבהן יש חלק משותף של הפעולה - אני מבין מאיפה אתה מגיע (הרצון לעשות reuse ולהראות שמדובר באותה לוגיקה), אבל לא נהוג לרשום את זה ב-UCD מאחר, ושוב אני חוזר על כך, UC זה רק תהליך עסקי שלם - לא חלקי ! במאמר מוסגר - UCD מארגן בתוכו את התהליכים העסקיים במערכת. לכל UC מפרטים את השלבים שמרכיבים אותו, נקודות ההתפצלות וכדומה (כמו שניתן לראות באתר). ה-AD נועד יותר לתיאור אלגוריתם עסקי מבחינת תרשים זרימה תוך ציון נקודות החלטה, חלוקת אחריות בין actors שונים במערכת וכו'. לפעמים נוח לתאר חלק מ-UC בתור AD, על-מנת להראות ללקוח בצורה תרשים כיצד נקבעת החלטה בתהליך (לדוגמה - חישוב הנחה לקניית רכב עפ"י מאפיינים שונים של הקונה)