מושגי יסוד בהגדרת תהליכים

הסבר: מהו Actor

1. שחקן הוא ישות מחוץ למערכת המידע

2. השחקן מוגדר מנקודת המבט של המערכת החדשה

3. השחקן מבצע אינטראקציה עם המערכת באמצעות Use Cases וגורם לה להגיב לאירוע עסקי, אבל אינו חלק ממנה

4. השחקן יכול להיות משתמש בתוך הארגון או מחוץ לארגון

5. שחקן יכול להיות מערכת חיצונית שמתממשקת למערכת

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

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

למערכת אין שליטה על השחקן הראשי

שחקן משני: שחקן אשר מקבל/מוסר/מחליף מידע עם המערכת במטרה לסייע למערכת לייצר ערך מדיד עבור השחקן הראשי

הסבר: מה זה Use Case

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

משימה: הכוונה לתהליך עסקי שלם מתחילתו ועד סופו שמתבצע כיחידה אחת בנקודת זמן מסויימת

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

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

אירוע עסקי בעל ערך מדיד: אירוע לוגי שקשור לתיחום של המערכת החדשה אשר יש לו משמעות עסקית ברורה שניתנת למדידה. בדוגמא א: משיכת סכום הוא אירוע עסקי מדיד, בסוף התהליך הלקוח מקבל כסף

בדוגמא ב: הקופאית מבצעת מכירה אשר בסופה היא מקבלת תשלום

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

הקשר לדרישות: בדרך כלל Use Case הוא תיאר מפורט של דרישה פונקציונאלית אחת או יותר

הסבר: מה זה Include

1. הכלה(Include) מציינת קשר בין שני מקרי שימוש. A מכיל תמיד את B

2. השימושים העיקריים

פירוק תהליך מורכב למספר תהליכים פשוטים יותר

אפשרות לשימוש באותו תת תהליך במספר רצוי של תהליכים (Reusability)

3. מקרה השימוש A מפעיל תמיד גם את כל הפונקציונליות של B

4. בנקודה מסויימת, תוך כדי ביצוע הפעילויות השונות של תהליך A יופעל תמיד תהליך B בשלמותו ולאחר מכן ימשיך A לבצע את שאר הפעילויות שלו

5. מקרה השימוש B יכול להיות מוכל במספר רצוי של מקרי שימוש אחרים

6. מקרה השימוש B לא יכול להתבצע עצמאית

7. אין מגבלה על מספר ה Includes ל use Case נתון

כלל עזר: מומלץ לטפל בכל מסך על ידי Use Case נפרד

דוגמא: נניח שתהליך ביצוע הזמנת רכב הוא מורכב ובנוי מ 4 מסכים: מסך פרטי לקוח, מסך פרטי רכב מבוקש, מסך פרטי ביטוח, מסך פרטי תשלום

הסבר: מה זה Extend

1. קשר הרחבה בין שני מקרי שימוש מכונה Extend

2. המשמעות היא: A מפעיל את B בצורה אופציונלית, רק בהתאם לצורך

3. שימו לב!! כיוון הקשר הינו מ B ל A

4. בנקודה מסוימת , תוך כדי ביצוע הפעילויות השונות של תהליך A , יופעל על פי התניה מתאימה תהליך B ולאחר מכן ימשיך A בפעילויות הבאות שלו(לפעמים ההתניה ריקה)

5. ייתכן מצב בו A מפעיל את B בצורה אסינכרונית (Interrupt )

6. מקרה השימוש B יכול להרחיב מספר של מקרי שימוש

7. מקרה שימוש B יכול להתבצע גם עצמאית, ללא מקרה שימוש A

8. למעשה Include ו Extend דומים מאד פרט לצורת ההפעלה. בעוד ש Use Case I שקשור ב Include מופעל תמיד הרי Use Case שקשור ב Extend מופעל בצורה מותנית​

9. בכל מקרה חשוב לזכור שהמטרה העיקרית הינה לפרק את 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 חודשים

• הפוליסה בתוקף

מאמר אנגלית: User Stories And Use Cases - Don’t Use Both

קרא עוד

סרטון אנגלית: What is a use case

סרטון אנגלית: Use Case basics

#מושגייסוד #הגדרתתהליכים