מושגי יסוד בהגדרת תהליכים
הסבר: מהו Actor
שחקן הוא ישות מחוץ למערכת המידע
השחקן מוגדר מנקודת המבט של המערכת החדשה
השחקן מבצע אינטראקציה עם המערכת באמצעות Use Cases וגורם לה להגיב לאירוע עסקי, אבל אינו חלק ממנה
השחקן יכול להיות משתמש בתוך הארגון או מחוץ לארגון
שחקן יכול להיות מערכת חיצונית שמתממשקת למערכת
שחקן יכול להיות רכיב חומרה (חישן, סורק,מכשיר טלפון...) מבחינים בשני סוגי שחקנים:
שחקן ראשי: שחקן שגורם למערכת להגיב לאירוע עסקי וליצור ערך מדיד (התנעה/קטליזטור)
למערכת אין שליטה על השחקן הראשי
שחקן משני: שחקן אשר מקבל/מוסר/מחליף מידע עם המערכת במטרה לסייע למערכת לייצר ערך מדיד עבור השחקן הראשי
הסבר: מה זה Use Case
משימה אחת שמבוצעת על ידי בעל תפקיד אחד(השחקן הראשי )במקום אחד, בזמן אחד כתגובה לאירוע עסקי בעל ערך מדיד ומשאירה את הנתונים במצב עקבי.
משימה: הכוונה לתהליך עסקי שלם מתחילתו ועד סופו שמתבצע כיחידה אחת בנקודת זמן מסויימת
דוגמא א: משיכת סכום מזומן מכספומט. זהו תהליך שלם שמבצע הלקוח באמצעות המערכת . התהליך מורכב ממספר פעילויות: חלקם מבוצע על ידי השחקן הראשי (הזנת כרטיס אשראי, הקלדת סיסמא, בחירת סכום...) וחלקם מבוצעים על ידי המערכת (בדיקת סיסמא, בדיקת תקינות נתונים מוזנים, בדיקת קיום חוקים, עדכון היתרה , הפקת פתקית...) המשימה מסתיימת כאשר השחקן מקבל את הסכום המבוקש.
דוגמא ב: ביצוע מכירה על ידי קופאית בשופרסל. זהו תהליך שלם שמבוצע כולו ביחידת זמן אחת על ידי הקופאית (שחקן ראשי) . התהליך מורכב ממספר פעילויות שחלקן מבוצע על ידי הקופאית (אישור כרטיס האשראי, קריאת קוד פריט על ידי Barcode שקילת מוצרים, הקלדת קודים ...) וחלקם על ידי המערכת (איתור מבצעים, איתור מחיר פריט, חישוב עלות המכירה, עדכון מסד הנתונים, הפקת חשבונית) המשימה מסתיימת כאשר הלקוח משלם,
אירוע עסקי בעל ערך מדיד: אירוע לוגי שקשור לתיחום של המערכת החדשה אשר יש לו משמעות עסקית ברורה שניתנת למדידה. בדוגמא א: משיכת סכום הוא אירוע עסקי מדיד, בסוף התהליך הלקוח מקבל כסף
בדוגמא ב: הקופאית מבצעת מכירה אשר בסופה היא מקבלת תשלום
משאירה את הנתונים במצב עקבי בסוף התהליך כל הנתונים במערכת מעודכנים ושלמים, בדוגמא א, הלקוח קיבל את הסכום המבוקש והיתרה בבנק עודכנה, אין מצב שהלקוח קיבל את הסכום והיתרה לא עודכנה.
הקשר לדרישות: בדרך כלל Use Case הוא תיאר מפורט של דרישה פונקציונאלית אחת או יותר
הסבר: מה זה Include
1. Include מציין קשר הכלה בין שני Use Cases
2. השימושים העיקריים
פירוק תהליך מורכב למספר תהליכים פשוטים יותר
אפשרות לשימוש באותו תת תהליך במספר רצוי של תהליכים (Reusability)
3. Use Case A מכיל את Use Case B משמעותו: פונקציונאליות A, משתמשת תמיד בפונקציונאליות B
4. בנקודה מסויימת, תוך כדי ביצוע הפעילויות השונות של תהליך A יופעל תמיד תהליך B בשלמותו ולאחר מכן ימשיך A לבצע את שאר הפעילויות שלו
5. B יכול להיות מוכל במספר רצוי של Use Cases אחרים
6. A לא יכול להתבצע ללא B
7. B יכול להתבצע עצמאית גם ללא A
8. אין מגבלה על מספר ה Includes ל use Case נתון
כלל עזר: מומלץ לטפל בכל מסך על ידי Use Case נפרד
דוגמא: נניח שתהליך ביצוע הזמנת רכב הוא מורכב ובנוי מ 4 מסכים: מסך פרטי לקוח, מסך פרטי רכב מבוקש, מסך פרטי ביטוח, מסך פרטי תשלום
הסבר: מה זה Extend
1. Extend מציין קשר הרחבה בין שני Use Cases
2. Use case B מרחיב את Use case A משמעותו: A, משתמש בהתאם לצורך (אופציונלית) ב B.
3. שימו לב!! כיוון הקשר הינו מ B ל A
4. בנקודה מסוימת , תוך כדי ביצוע הפעילויות השונות של תהליך A , יופעל על פי התניה מתאימה תהליך B ולאחר מכן ימשיך A בפעילויות הבאות שלו(לפעמים ההתניה ריקה)
5. B יכול להרחיב את A גם בצורה אסינכרונית (לדוגמא הקשה על מקש מיוחד או Interrupt )
6. B יכול להרחיב מספר רצוי של use cases אחרים.
7. A יכול להתבצע ללא B
8. B בדרך כלל קשור ל A אבל יכול גם להתבצע עצמאית.
9. למעשה למעשה Include ו Extend דומים מאד פרט לצורת ההפעלה. בעוד ש Use Case I שקשור ב Include מפעל תמיד הרי Use Case שקשור ב Extend מופעל בצורה מותנית
10. בכל מקרה חשוב לזכור שהמטרה העיקרית הינה לפרק את A לתתי תהליכים שלכל אחד מהם יש משמעות לוגית נפרדת
דוגמא לשימוש ב Extend
הסבר: מה זה Usage
Use מציין קשר אסינכרוני בין שני Use Cases.
Use Case A מפעיל את B בצורת שגר ושכח.
הפעילות ב A ממשיכה בלי שום קשר למה שקורה ב B.
הבהרה: עד מהדורה 2.4 של UML השתמשו במונח Invoke
מאמר: מה זה הורשה
הסבר: מה זה Workflow
משימה מורחבת אשר כוללת מספר Use cases,
נמשכת לאורך זמן וכוללת מעורבות אנושית בין UC אחד למשנהו.
התהליך חוצה לעתים מחלקות
דוגמאות:
• טיפול בהלוואה גדולה
• טיפול בתלונה
• הזמנת טיול גדול
הסבר: מה זה Activity Diagram
זהו התרשים ההתנהגותי המרכזי של UML
ניתן להשתמש בו לצרכים הבאים:
מידול מפורט של Use Cases
מידול מפורט של נוהלי עבודה
הצגה מפורטת של תהליך עסקי מקצה לקצה (Workflow)
פירוט של המסלול הבסיסי וכל המסלולים החלופיים של Use Case אחד
אלגוריתמים מפורטים בעיצוב
התרשים מציג את סדר הפעילויות מתחילת התהליך ועד לסיומו
בנוסף לסדר הפעילויות ניתן להציג גם את הקשרים של כל פעילות לשאר רכיבי המערכת: מסכים, חוקים, ישויות, הודעות שגיאה.
הסבר: סוגי מסלולים ב Use Case
כאשר מפרטים את התהליך שמתבצע בUse Case ניתן להבחין ב 3 מסלולים אפשריים:
המסלול הבסיסי (Basic path/Basic Flow) מסלול זה מכונה לעיתים Happy Day
הכוונה היא לרצף הפעילויות אשר מתבצע באותו אופן ב80% מהזמן ומסתיים תמיד בהצלחה.
לדוגמא כאשר מבקשים להוציא כסף מכספומט ב80% מהזמן נשמר אותו רצף של פעולות: הלקוח מכניס את כרטיס האשראי, הלקוח מקיש את הקוד, הלקוח בוחר את הסכום המערכת מנפקת את הסכום המבוקש. התהליך מסתיים בהצלחה.
ההמלצה היא תמיד להתחיל בתיאור המסלול הבסיסי.
מסלול חלופי (Alternative Flow) זהו מסלול שכולל מספר פעילויות כחלופה לפעילויות במסלול הבסיסי, מבחינה עסקית התהליך מסתיים בהצלחה.
לדוגמא, בהוצאת כסף מהכספומט
1. מה קורה אם אם הלקוח מעוניין למשוך 500 ש"ח, אבל יש לו ביתרה למשיכה רק 400?
2. מה קורה אם הלקוח מעוניין למשוך 500 ש"ח, אבל בקופה נותרו 400?
3. מה קורה אם הלקוח מעוניין בסכום שאינו מופיע ברשימת הסכומים האפשריים
4. מה קורה אם הלקוח מעוניין גם בפתקית
בכל המקרים הללו יש מענה פונקציונלי שמאפשר ללקוח להמשיך עד לסיום מוצלח.
מסלול חריג (Exception Flow)
הכוונה היא למצב שבו המערכת נאלצת להפסיק את התהליך כיון שיש הפרה של אחד מהחוקים שנקבעו מראש לביצוע תקין של התהליך.
לדוגמא בתהליך הוצאת כספים מכספומט:
1. מה קורה אם הכרטיס המגנטי אינו בתוקף
2. מה קורה אם הכרטיס פגום ולא ניתן לקרוא אותו
3. מה קורה אם הסיסמא שגויה 4 פעמים
4. מה קורה אם אם אין תגובה של הלקוח מעל ל 5 דקות
5. מה קורה כאשר הלקוח מנסה לבצע משיכה מעל היתרה היומית החוקית
6. מה קורה כאשר הלקוח מנסה לבצע משיכה רביעית כאשר מותרות רק 3 משיכות ביום
בכל המקרים הללו לא ניתן לסיים את המשימה בהצלחה.
הסבר: תנאים מוקדמים(Preconditions)
תנאי מוקדם הוא כל תנאי שחייב להתקיים לפני ש Use case יכול להתחיל.
התנאי מוקדם מהווה מגבלה על ביצועו. התנאי יכול להיבדק על ידי על ידי ה Use Case שמפעיל את ה Use Case הנוכחי או על ידי ה Use Case הנוכחי בעצמו.
הבהרה טכנית: בפיתוח בגישת האובייקטים מומלץ שהבדיקה תהיה חלק מ Use Case הנוכחי
לדוגמא:
הלקוח מחובר למערכת וזוהה בהצלחה
הלקוח עבר כבר את ביקורת הגבולות
ההזמנה אושרה על ידי מחלקת הרכש
הדרכון בתוקף לעוד 6 חודשים
הפוליסה בתוקף