מחזור חיים לפי UML
- פותח הנושא duducohn
- פורסם בתאריך
-->
במקום לעבור לפי מחזור החיים, אעבור לפי סוגי הדיאגרמות ואתן כמה נקודות למחשבה : Use case diagram - דיאגרמה המשמשת בשלב האפיון. בשלב הגדרת הדרישות שהוא שלב טרם שלב האפיון, נהוג לבנות מסמך דרישות ברמת נקודות ולא להתחיל לתכנן UC-ים (במרבית השיטות/המתודולוגיות המוכרות כגון RUP ו-MSF, קיימים מסמכי דרישות שאינם מכילים תיאורי UC) Class diagram - בשלב האפיון (שנרשם דרך אגב "analysis") נהוג לתאר את ישויות המידע העיקריות של המערכת, כאשר בשלב העיצוב נהוג להרחיב את תיאור המחלקות (בדגש על מתודות) ולהוסיף פירוט הנוגע לארכיט' הפיתוח (לדוגמה - חלוקת כל מחלקה למספר מחלקות, כאשר עובדים בארכיט' פיתוח מבוססת שכבות). Object Diagram - האמת אני לא מכיר הרבה אנשים שמשתמשים בדיאגרמה זו, מאחר ולרוב ה-Class diagram נותן מספיק פירוט ראשוני וה-sequence diagram עוזר להרחיב את כל שאר הקשרים Sequence Diagram - פה המשחקים נהיים יותר מעניינים. אפשר להשתמש ב-sequence בשביל לתאר את הסדר הכרונולוגי של אלגוריתם (מה שמוגדר לרוב בשלב העיצוב של המערכת), אבל יש גם הנוהגים להשתמש בדיאגרמה זו עוד בשלב האפיון בשביל לתאר את זרימת המידע בין הישויות ואת הפעולות הלוגיות שישויות מבצעות אחת על השניה (לא ממש sequence שאפשר לחולל ממנו קוד, אבל איזשהו תרשים שעוזר למשתמש להבין איך המידע זורם במערכת) Collaboration Diagram - ראה sequence (למעשה בתוכנות כגון Rational ניתן לייצר collaboration מ-sequence בלחיצת כפתור). למעשה ההבדל היחיד בין הדיאגרמות הוא הויזואליות (למיטב זכרוני נהוג להשתמש באחרונה כאשר רוצים להראות התפצלות של פעולות ובקודמת כאשר רוצים להראות flow אחד רציף) state machine diagram - (השם state chart הוא כבר "פסה" ואינו בשימוש ב-uml 2) גם דיאגרמה זו מאוד שימושית גם בשלב האפיון ולאו דווקא בשלב העיצוב. נוח מאוד בשלב האפיון להציג למשתמש את המצבים השונים בהם ישות יכולה להיות וההשפעות שיש למעברי מצבים על הישות ועל סביבתה. activity diagram - האמת אני יותר מוצא לדיאגרמה זו שימוש בשלב האפיון ולא דווקא בשלב העיצוב. activity diagram דומה מאוד במבנה שלו לתרשים זרימה ("אלגוריתם") ולכן נוח לתיאור תהליכים (UC). לאלו שמשתמשים בדיאגרמה זו בשביל לתאר flow של תהליכים ממוחשבים (מתודות) - עדיף שישתמשו ב-sequence Component Diagram - אומנם דיאגרמת ה-component מתארת כיצד הקוד הולך להיות מחולק לרכיבים, אך ההגיון אומר שהחלטות חשובות כאלה מקבלים לפני התחלת הפיתוח ולא במהלכו. ולכן ההגיון אומר שדיאגרמה זו מבוצעת עוד בשלב העיצוב deployment diagram - לדעתי מומלץ עוד בשלב העיצוב וקביעת הארכיט' להיות סגורים על איך הולכת להיות הפריסה של החומרה, התקשורת ורכיבי המערכת. סביר להניח שדיאגרמה זו תתוקן תוך כדי הפיתוח ועד לפני שלב ההטמעה, אבל ההכנה המקורית צריכה להיות עוד בשלב קביעת הארכיט' (חבל שאחרי שמסיימים פיתוח יתחילו לתכנן איך פורסים את השרתים ואז יגלו שבין שרת ה-DB לשרת האפליקציה יש פירוול שמאפשר תקשורת רק דרך WebService ולא מאפשר שימוש לדוגמה ב-DAAB של מיקרוסופט - ותחשבו למה אני נותן במקרה את הדוגמה הזו) ודרך אגב, מה קרה ל-package diagram ? דיאגרמה חביבה שניתן לנצל אותה על-מנת להגדיר את המודולים/תתי-מערכות של המערכת (בין אם לפי חלוקת ישויות המידע או ה-UC שתוארו בשלב האפיון) אני רק מקווה שהספר במקור הציג יותר מסתם טבלה ושיבוץ, אלא גם הסבר מדוע יש להשתמש בכל דיאגרמה בכל אחד מהשלבים (מהו התוצר שיינתן, מהם הקלטים שצריך בשביל לתת תוצר זה, למי הוא מיועד וכו') - וכמובן שמומלץ שיהיה ביסוס לקביעות אלו (תמיד מומלץ לקרוא ספרים שנכתבו ע"י אנשים שהתנסו "על רטוב" ולאו דווקא ספרים של האקדמיה שלרוב נכתבו בתנאי מעבדה)
במקום לעבור לפי מחזור החיים, אעבור לפי סוגי הדיאגרמות ואתן כמה נקודות למחשבה : Use case diagram - דיאגרמה המשמשת בשלב האפיון. בשלב הגדרת הדרישות שהוא שלב טרם שלב האפיון, נהוג לבנות מסמך דרישות ברמת נקודות ולא להתחיל לתכנן UC-ים (במרבית השיטות/המתודולוגיות המוכרות כגון RUP ו-MSF, קיימים מסמכי דרישות שאינם מכילים תיאורי UC) Class diagram - בשלב האפיון (שנרשם דרך אגב "analysis") נהוג לתאר את ישויות המידע העיקריות של המערכת, כאשר בשלב העיצוב נהוג להרחיב את תיאור המחלקות (בדגש על מתודות) ולהוסיף פירוט הנוגע לארכיט' הפיתוח (לדוגמה - חלוקת כל מחלקה למספר מחלקות, כאשר עובדים בארכיט' פיתוח מבוססת שכבות). Object Diagram - האמת אני לא מכיר הרבה אנשים שמשתמשים בדיאגרמה זו, מאחר ולרוב ה-Class diagram נותן מספיק פירוט ראשוני וה-sequence diagram עוזר להרחיב את כל שאר הקשרים Sequence Diagram - פה המשחקים נהיים יותר מעניינים. אפשר להשתמש ב-sequence בשביל לתאר את הסדר הכרונולוגי של אלגוריתם (מה שמוגדר לרוב בשלב העיצוב של המערכת), אבל יש גם הנוהגים להשתמש בדיאגרמה זו עוד בשלב האפיון בשביל לתאר את זרימת המידע בין הישויות ואת הפעולות הלוגיות שישויות מבצעות אחת על השניה (לא ממש sequence שאפשר לחולל ממנו קוד, אבל איזשהו תרשים שעוזר למשתמש להבין איך המידע זורם במערכת) Collaboration Diagram - ראה sequence (למעשה בתוכנות כגון Rational ניתן לייצר collaboration מ-sequence בלחיצת כפתור). למעשה ההבדל היחיד בין הדיאגרמות הוא הויזואליות (למיטב זכרוני נהוג להשתמש באחרונה כאשר רוצים להראות התפצלות של פעולות ובקודמת כאשר רוצים להראות flow אחד רציף) state machine diagram - (השם state chart הוא כבר "פסה" ואינו בשימוש ב-uml 2) גם דיאגרמה זו מאוד שימושית גם בשלב האפיון ולאו דווקא בשלב העיצוב. נוח מאוד בשלב האפיון להציג למשתמש את המצבים השונים בהם ישות יכולה להיות וההשפעות שיש למעברי מצבים על הישות ועל סביבתה. activity diagram - האמת אני יותר מוצא לדיאגרמה זו שימוש בשלב האפיון ולא דווקא בשלב העיצוב. activity diagram דומה מאוד במבנה שלו לתרשים זרימה ("אלגוריתם") ולכן נוח לתיאור תהליכים (UC). לאלו שמשתמשים בדיאגרמה זו בשביל לתאר flow של תהליכים ממוחשבים (מתודות) - עדיף שישתמשו ב-sequence Component Diagram - אומנם דיאגרמת ה-component מתארת כיצד הקוד הולך להיות מחולק לרכיבים, אך ההגיון אומר שהחלטות חשובות כאלה מקבלים לפני התחלת הפיתוח ולא במהלכו. ולכן ההגיון אומר שדיאגרמה זו מבוצעת עוד בשלב העיצוב deployment diagram - לדעתי מומלץ עוד בשלב העיצוב וקביעת הארכיט' להיות סגורים על איך הולכת להיות הפריסה של החומרה, התקשורת ורכיבי המערכת. סביר להניח שדיאגרמה זו תתוקן תוך כדי הפיתוח ועד לפני שלב ההטמעה, אבל ההכנה המקורית צריכה להיות עוד בשלב קביעת הארכיט' (חבל שאחרי שמסיימים פיתוח יתחילו לתכנן איך פורסים את השרתים ואז יגלו שבין שרת ה-DB לשרת האפליקציה יש פירוול שמאפשר תקשורת רק דרך WebService ולא מאפשר שימוש לדוגמה ב-DAAB של מיקרוסופט - ותחשבו למה אני נותן במקרה את הדוגמה הזו) ודרך אגב, מה קרה ל-package diagram ? דיאגרמה חביבה שניתן לנצל אותה על-מנת להגדיר את המודולים/תתי-מערכות של המערכת (בין אם לפי חלוקת ישויות המידע או ה-UC שתוארו בשלב האפיון) אני רק מקווה שהספר במקור הציג יותר מסתם טבלה ושיבוץ, אלא גם הסבר מדוע יש להשתמש בכל דיאגרמה בכל אחד מהשלבים (מהו התוצר שיינתן, מהם הקלטים שצריך בשביל לתת תוצר זה, למי הוא מיועד וכו') - וכמובן שמומלץ שיהיה ביסוס לקביעות אלו (תמיד מומלץ לקרוא ספרים שנכתבו ע"י אנשים שהתנסו "על רטוב" ולאו דווקא ספרים של האקדמיה שלרוב נכתבו בתנאי מעבדה)
הערונת ונצל"ש
לפי מה שאני זוכר ממה שלמדתי, הגדרת ההבדל בין Sequence ל-Collaboration היא בכך שהסוג הראשון מדגיש את התיזמון הלוגי של זרימת המידע והשני את היחסים בים המרכיבים שביניהם זורם המידע (שזה רק ניסוח אחר, אבל קצת יותר ברור לטעמי האישי). מעבר לכך באמת מדובר, עפ"י הגדרה, ב-2 תרשימים שהמידע שהם מייצגים שקול לחלוטין. מצד שני, השאלה שכל הזמן מציקה לי היא למה יש הפרדה בין איפיון ועיצוב. אני יכול (איכשהו, בקושי) לקבל את הרעיון שהגדרת דרישות ראשונית יכולה/אמורה (?) להתבצע ע"י אנשים חסרי רקע טכני, בסגנון של "עשינו ציור עם כל מני שחקנים ועיגולים וחיצים - עכשיו תעשו מזה מוצר מגניב"... וגם ברור לי שלפני כל עיצוב חייב לבוא איפיון, כלומר לפני שעונים על ה"איך עושים" חייבים כמובן לענות קודם על "מה עושים"... אבל בסביבה מעשית ולא תיאורטית, האם באמת קיימת הפרדה בין 3 השלבים האלה? האם ניתן לצפות שאנשים ללא רקע טכני יגדירו דרישות מוצר יעילות? האם הקפיצה הלוגית בין איפיון לעיצוב (כללי ולא סופי) היא לא מיידית אצל אנשים מנוסים? מהבחינה הזו, באמת אפשר וצריך להשתמש בחלק מן התרשימים שהוזכרו הרבה לפני השלב שבמסגרתו הם הוזכרו - ואני לחלוטין מסכים עם הדוגמא לגבי תרשימי פריסה ש*חייבים* להתקיים כבר בשלב הראשוני של הפיתוח (המבנה של הפריסה הוא בדר"כ נתון קריטי לצורך האיפיון ו/או העיצוב). ועוד שאלה: מישהו יודע ומוכן לסכם *בקצרה* מה שונה/חדש ב-UML2 לעומת הגרסאות היציבות הקודמות של המפרט?
לפי מה שאני זוכר ממה שלמדתי, הגדרת ההבדל בין Sequence ל-Collaboration היא בכך שהסוג הראשון מדגיש את התיזמון הלוגי של זרימת המידע והשני את היחסים בים המרכיבים שביניהם זורם המידע (שזה רק ניסוח אחר, אבל קצת יותר ברור לטעמי האישי). מעבר לכך באמת מדובר, עפ"י הגדרה, ב-2 תרשימים שהמידע שהם מייצגים שקול לחלוטין. מצד שני, השאלה שכל הזמן מציקה לי היא למה יש הפרדה בין איפיון ועיצוב. אני יכול (איכשהו, בקושי) לקבל את הרעיון שהגדרת דרישות ראשונית יכולה/אמורה (?) להתבצע ע"י אנשים חסרי רקע טכני, בסגנון של "עשינו ציור עם כל מני שחקנים ועיגולים וחיצים - עכשיו תעשו מזה מוצר מגניב"... וגם ברור לי שלפני כל עיצוב חייב לבוא איפיון, כלומר לפני שעונים על ה"איך עושים" חייבים כמובן לענות קודם על "מה עושים"... אבל בסביבה מעשית ולא תיאורטית, האם באמת קיימת הפרדה בין 3 השלבים האלה? האם ניתן לצפות שאנשים ללא רקע טכני יגדירו דרישות מוצר יעילות? האם הקפיצה הלוגית בין איפיון לעיצוב (כללי ולא סופי) היא לא מיידית אצל אנשים מנוסים? מהבחינה הזו, באמת אפשר וצריך להשתמש בחלק מן התרשימים שהוזכרו הרבה לפני השלב שבמסגרתו הם הוזכרו - ואני לחלוטין מסכים עם הדוגמא לגבי תרשימי פריסה ש*חייבים* להתקיים כבר בשלב הראשוני של הפיתוח (המבנה של הפריסה הוא בדר"כ נתון קריטי לצורך האיפיון ו/או העיצוב). ועוד שאלה: מישהו יודע ומוכן לסכם *בקצרה* מה שונה/חדש ב-UML2 לעומת הגרסאות היציבות הקודמות של המפרט?
-->
למה צריך הפרדה בין אפיון לעיצוב ? למה יש הפרדה בין אדריכל הבניין למהנדס בנין ? כל אחד מהם יודע בתחומו הוא לעשות את עבודתו נאמנה - האחד בקטע ההגדרתי - מה צריך, למה צריך, איך כדאי שזה יראה, והשני בקטע הטכני - האם אפשר לעשות כך או אחרת, כמה זמן ידרש לבצע את זה, מהם החומרים להם זקוקים לביצוע המשימה וכו'. מן הסתם אדם שיש לו את הנסיון בשני התחומים, ניתן לנצל את הידע שלו על-מנת לעשות את שניהם, אבל מנסיון שלי, העבודה תחת שני כובעים מביעה רק צרות מאחר וכל שלב אמור לספק תוצר לשלב הבא והתוצר שסופק צריך להיות מוגדר ו"סגור" ככל שניתן (סגור מהבחינה שסגרו את כל הפינות ואישרו אותו). כאשר אתה ממלא את שני התפקידים, נוח לך "לעגל פינות" בטענה שאח"כ תסתום אותם, נוח לך לעדכן דברים שעשית בטוענה של "טעיתי, אז אני מרשה לעצמי לתקן" וכדומה. במקרה של שני אנשים, יש יותר הזדמנויות לעשות חושבים, לקבל אישור מהצד השני שאכן בוצעה טעות והאם כדאי/לא כדאי לתקן אותה לדוגמה - לפעמים כשאתה מעצב אתה מגלה שהיה הרבה יותר נוח לעצב אם לדוגמה, היית מוריד/משנה משהו באפיון, אבל התיקון הזה לאו דווקא יהיה מקובל על המאפיין (כי כנראה הוא לא יתקבל ע"י הלקוח של המערכת), ולכן העמדה בשני כובעים - גם המנתח וגם המעצב, יכולה לגרום לאדם שכזה פיצול אישיות - ומנסיון שלי, זה לא כיף. לגבי UML 2 - מרבית השינויים שאני מכיר היו תוספות של דיאגרמות והרחבת דיאגרמות קיימות, אבל אני מציע שתקרא על כך בלינק הבא: http://www.xpdian.com/UML2.0changes.html
למה צריך הפרדה בין אפיון לעיצוב ? למה יש הפרדה בין אדריכל הבניין למהנדס בנין ? כל אחד מהם יודע בתחומו הוא לעשות את עבודתו נאמנה - האחד בקטע ההגדרתי - מה צריך, למה צריך, איך כדאי שזה יראה, והשני בקטע הטכני - האם אפשר לעשות כך או אחרת, כמה זמן ידרש לבצע את זה, מהם החומרים להם זקוקים לביצוע המשימה וכו'. מן הסתם אדם שיש לו את הנסיון בשני התחומים, ניתן לנצל את הידע שלו על-מנת לעשות את שניהם, אבל מנסיון שלי, העבודה תחת שני כובעים מביעה רק צרות מאחר וכל שלב אמור לספק תוצר לשלב הבא והתוצר שסופק צריך להיות מוגדר ו"סגור" ככל שניתן (סגור מהבחינה שסגרו את כל הפינות ואישרו אותו). כאשר אתה ממלא את שני התפקידים, נוח לך "לעגל פינות" בטענה שאח"כ תסתום אותם, נוח לך לעדכן דברים שעשית בטוענה של "טעיתי, אז אני מרשה לעצמי לתקן" וכדומה. במקרה של שני אנשים, יש יותר הזדמנויות לעשות חושבים, לקבל אישור מהצד השני שאכן בוצעה טעות והאם כדאי/לא כדאי לתקן אותה לדוגמה - לפעמים כשאתה מעצב אתה מגלה שהיה הרבה יותר נוח לעצב אם לדוגמה, היית מוריד/משנה משהו באפיון, אבל התיקון הזה לאו דווקא יהיה מקובל על המאפיין (כי כנראה הוא לא יתקבל ע"י הלקוח של המערכת), ולכן העמדה בשני כובעים - גם המנתח וגם המעצב, יכולה לגרום לאדם שכזה פיצול אישיות - ומנסיון שלי, זה לא כיף. לגבי UML 2 - מרבית השינויים שאני מכיר היו תוספות של דיאגרמות והרחבת דיאגרמות קיימות, אבל אני מציע שתקרא על כך בלינק הבא: http://www.xpdian.com/UML2.0changes.html
הערות
ראשית תודה, עזרת לי. יש לי לא מעט הערות שאתייחס אליהם בהמשך. בפרוייקט שעיינתי בו, בתרשימי ה- UC, ראיתי שמופיע תרשים שכותרתו היא Abstract UC? לא הבחנתי בהבדל בינו לבין UC רגיל. שאלות: א . האם קיים הבדל בין Abstract UC לבין UC רגיל? ב . אם כן, אז מהו ההבדל? ג . אם לא, אז מדוע מתווסף ה- Abstract?
ראשית תודה, עזרת לי. יש לי לא מעט הערות שאתייחס אליהם בהמשך. בפרוייקט שעיינתי בו, בתרשימי ה- UC, ראיתי שמופיע תרשים שכותרתו היא Abstract UC? לא הבחנתי בהבדל בינו לבין UC רגיל. שאלות: א . האם קיים הבדל בין Abstract UC לבין UC רגיל? ב . אם כן, אז מהו ההבדל? ג . אם לא, אז מדוע מתווסף ה- Abstract?
קודם כל
תודה. אני גם חייב לך תשובה ובכך אתחיל. הספר שבו מדובר אינו ספר של האקדמיה. הספר נכתב על ידי בוגר ממר"ם עם ניסיון מעשי. הספר הינו בהוצאת הוד עמי ושמו ניהול מערכות מידע. יתרונו שהוא כתוב בשפה העברית. אינני מכיר ספרים נוספים שכתובים בעברית ושמסבירים את מתודולוגית ה- UML. בזאת סיימתי את קטע הפרסומות. מספר שאלות ובקשות: ברישא של תגובתך ציינת כי תעבור לפי סוגי הדיאגרמות ולא לפי מחזור החיים. א . האם ישנה סיבה לכך? ב . האם תהליך השימוש ב- UML דומה למתודולוגיות האחרות. כלומר ביצוע השלבים השונים בהקמת המערכת בסדר קבוע מסויים בהתאם לשיטה (מפ"ל מים, אב טיפוס, ספיראלי וכדומה)? ג . Use case מתורגם בספרו של יניב אליהו למונח פונקציונאליות. בתרשימי בועות ((DFD משתמשים בסימן עיגול בכדי לתאר תהליך. פרופ' פרץ שובל בספרו עיצוב ותכנון מערכות מידע, חלק ב' משתמש לאותו הדבר במונח פונקציה במקום במונח תהליך. זאת בנוסף לכך שלפי הבנתי תרשימי ה- UC מתארים את זרימת המידע בין השחקנים (Actors) לבין ה- UC ובין ה- UC לבין עצמם. האם אפשר להניח כי תרשימי ה- UC הם האנלוגיה לתרשימי ה- DFD ? ד . הזכרת את המונחים RUP ו- MSF. אודה לך אם תיתן הסבר קצר על שני מונחים אילו. ה . ה- Class diagram הזכיר לי את תרשימי ה- ER, שמשמשים להגדרת בסיס הנתונים ללא המתודות. האם הבנתי נכון ש- Class diagram הוא האנלוגיה לתרשים ER למעט המתודות? ו . ה- Sequence diagram הזכיר לי את מילון הפונקציות/תהליכים כפי שזה בא לידי ביטוי במתודולוגית ה- DFD. - האם אפשר להניח כי ה- Sequence diagram הוא המקבילה לו? - האם את ה- Sequence diagram ניתן לתאר רק בשפה מובנית, או שאפשר לתארו בכל שיטה לתיאור אלגוריתמים (שפה מובנית, טבלאות ועצי החלטה, תרשים זרימה וכדומה).
תודה. אני גם חייב לך תשובה ובכך אתחיל. הספר שבו מדובר אינו ספר של האקדמיה. הספר נכתב על ידי בוגר ממר"ם עם ניסיון מעשי. הספר הינו בהוצאת הוד עמי ושמו ניהול מערכות מידע. יתרונו שהוא כתוב בשפה העברית. אינני מכיר ספרים נוספים שכתובים בעברית ושמסבירים את מתודולוגית ה- UML. בזאת סיימתי את קטע הפרסומות. מספר שאלות ובקשות: ברישא של תגובתך ציינת כי תעבור לפי סוגי הדיאגרמות ולא לפי מחזור החיים. א . האם ישנה סיבה לכך? ב . האם תהליך השימוש ב- UML דומה למתודולוגיות האחרות. כלומר ביצוע השלבים השונים בהקמת המערכת בסדר קבוע מסויים בהתאם לשיטה (מפ"ל מים, אב טיפוס, ספיראלי וכדומה)? ג . Use case מתורגם בספרו של יניב אליהו למונח פונקציונאליות. בתרשימי בועות ((DFD משתמשים בסימן עיגול בכדי לתאר תהליך. פרופ' פרץ שובל בספרו עיצוב ותכנון מערכות מידע, חלק ב' משתמש לאותו הדבר במונח פונקציה במקום במונח תהליך. זאת בנוסף לכך שלפי הבנתי תרשימי ה- UC מתארים את זרימת המידע בין השחקנים (Actors) לבין ה- UC ובין ה- UC לבין עצמם. האם אפשר להניח כי תרשימי ה- UC הם האנלוגיה לתרשימי ה- DFD ? ד . הזכרת את המונחים RUP ו- MSF. אודה לך אם תיתן הסבר קצר על שני מונחים אילו. ה . ה- Class diagram הזכיר לי את תרשימי ה- ER, שמשמשים להגדרת בסיס הנתונים ללא המתודות. האם הבנתי נכון ש- Class diagram הוא האנלוגיה לתרשים ER למעט המתודות? ו . ה- Sequence diagram הזכיר לי את מילון הפונקציות/תהליכים כפי שזה בא לידי ביטוי במתודולוגית ה- DFD. - האם אפשר להניח כי ה- Sequence diagram הוא המקבילה לו? - האם את ה- Sequence diagram ניתן לתאר רק בשפה מובנית, או שאפשר לתארו בכל שיטה לתיאור אלגוריתמים (שפה מובנית, טבלאות ועצי החלטה, תרשים זרימה וכדומה).
שים לב
שאתה מבלבל לא מעט בין מושגים מעולם התכנות הפרוצדוראלי (מתודולוגיית DFD) למושגים מעולם ה Object Oriented Design. Class Diagram מתאר קשרים בין מחלקות ואילו ERD מתאר קשרים בין טבלאות. יש חפיפה סמנטית מסויימת בין התרשימים אך המשמעות שלהם שונה בהחלט. כמו כן, Squence Diagram הוא תרשים שמתאר זרימה של קריאות למתודות של אובייקטים דבר שלא ממש קיים במתודולוגיה פרוצדוראלית. בקיצור, המודלים של UML מתאימים ל OOD ולא תמצא הקבלות להם מעולם ה DFD - שים לב שהסטנדרט של UML איננו כולל מודלים לתיאור אלגוריתמים פרוצדוראלים (שפה מובנית, טבלאות ועצי החלטה וכו'...) אלא רק מוסיף עליהם. אני גם לא הייתי מגדיר את UML כמתודולוגיה אלא כשפה (Modeling Language) אשר ניתן להתשתמש בה על מנת להציג עיצוב OO בצורה סטנדרטית. לדעתי גם לא כתוב שום דבר ב UML לגבי תהליכי פיתוח והקמת מערכת...
שאתה מבלבל לא מעט בין מושגים מעולם התכנות הפרוצדוראלי (מתודולוגיית DFD) למושגים מעולם ה Object Oriented Design. Class Diagram מתאר קשרים בין מחלקות ואילו ERD מתאר קשרים בין טבלאות. יש חפיפה סמנטית מסויימת בין התרשימים אך המשמעות שלהם שונה בהחלט. כמו כן, Squence Diagram הוא תרשים שמתאר זרימה של קריאות למתודות של אובייקטים דבר שלא ממש קיים במתודולוגיה פרוצדוראלית. בקיצור, המודלים של UML מתאימים ל OOD ולא תמצא הקבלות להם מעולם ה DFD - שים לב שהסטנדרט של UML איננו כולל מודלים לתיאור אלגוריתמים פרוצדוראלים (שפה מובנית, טבלאות ועצי החלטה וכו'...) אלא רק מוסיף עליהם. אני גם לא הייתי מגדיר את UML כמתודולוגיה אלא כשפה (Modeling Language) אשר ניתן להתשתמש בה על מנת להציג עיצוב OO בצורה סטנדרטית. לדעתי גם לא כתוב שום דבר ב UML לגבי תהליכי פיתוח והקמת מערכת...
-->
א. אין סיבה משמעותית. מאחר ורציתי לתת את הדעת על מתי להשתמש בכל אחת מהדיאגרמות, חשבתי שיהיה יותר נכון לפרט לפי הדיאגרמות ולא לפי שלבי מחזור החיים. ב. UML הינה נוצטיה בלבד (שפה לרישום) ואינה מתודולוגיה. במתודולוגיות חדשות וכן במתודולוגיות ישנות שהותאמו ל-UML, נהוג להשתמש בתוצרי ה-UML בשלבי מחזור החיים השונים. בסגנונות מחזורי חיים כגון מפל מים, ספירלי, איטרטיבי וכו' המנצלים את ה-UML כשפת רישום, ישנו שימוש בכל הדיאגרמות, אך בסדר שונה וברמות שונות של פירוט (לדוגמה, במפל מים בשלב האפיון תצטרך לעשות UCD של כל המערכת, בעוד שבמחזור חיים איטרטיבי תתן UCD רק של האיטרציה הנוכחית). דרך אגב, המונח "מפל מים" הינו ללא גרשיים - הדימוי הוא מאחר והמים זורמים מראש המפל מטה בדומה למחזור החיים שמריץ את כל השלבים אחד אחרי השני ללא חזרה ג. נוהגים להשוות UCD ל-DFD בגלל שהם נראים דומים והם מחליפים את שלב הגדרת התהליכים. DFD נועד יותר לתיאור זרימת המידע במערכת, בעוד UCD נועד להדגיש את התהליכים במערכת, ללא מתן דגש על המידע אלא יותר דגש על התהליך כתהליך עסקי. ניתן להתסכל על UC כעל "טרנזקציה" בחיים האמיתיים - תהליך שמתחיל בנקודה מסוימת (אני מגיע לכספומט), יש לו תנאים מקדימים (בשביל להוציא כסף מהכספומט אני צריך להכניס כרטיס ולהקיש קוד סודי), יש לו תיאור הליך סטנדרטי (אני מקיש את הסכום ומקבל את הכסף), יש לו תיאור תהליכים חליפיים (אין לי כסף בעו"ש ולכן מופיעה הודעה) ויש לו תוצאה סופית (הכסף והכרטיס ביד ופחות כסף בחשבון) - לא תיארתי פה את מאגרי המידע שהייתי מתאר ב-DFD, לא הייתי מתאר את הרשומות שהיו עוברות מ-DB ל-DB (מה שהייתי עושה ב-DFD) וכו'. ד. RUP הינה מתודולוגיית פיתוח שהוגדרה ע"י חברת Rational (כיום IBM) שאינה שמה את הדגש על השלבים המוכרים של אפיון, עיצוב, קידוד ... אלא על הפאזות שמערכת עוברת (התעברות - Inception, עיבוד/תכנון-Elaboration, בנייה/פיתוח - Construction ו-מעבר/הסבות - Transition) ומתארת בכל שלב (פאזה) שכזה את התוצרים השונים שצריך לספק, בכל אחד מהשלבים המוכרים לנו (דרישות, עיצוב, אפיון, בדיקות, פיתוח - לאו דווקא לפי סדר זה) ואת רמת ההשקעה הנדרשת עבור כל תוצר. ישנם מתודולוגיות רבות שהתפתחו מה-RUP והרחיבו אותו על-מנת לטפל בסוגים שונים של מערכות (לדוגמה : מערכות שיש להם שלבי תחזוקה ארוכים). ישנם מספר לינקים לנושא זה בקישורים. MSF - מיקרוסופט אינה מגדירה את ה-MSF כמתודולוגיה אלא כמסגרת פיתוח (framework). ה-MSF למיטב זכרוני נוצר כאיזשהו נסיון של מיקרוסופט לאסוף את הנסיון שלה בפיתוח מערכות למתודולוגית/מסגרת פיתוח אחידה. ה-MSF מגדיר את שלבי מחזור החיים באופן די דומה לשלבים המוכרים - ייזום, תכנון, פיתוח, ייצוב והתקנה. עבור כל שלב ישנו אוסף מסמכים שאמורים לכסות את התוצרים שהשלב אמור לספק והסבר כיצד יש למלא מסמכים אלו. ה-MSF מסביר גם טוב מאוד את התפקידים השונים הקיימים בצוות הפרויקט ואת תפקידם במהלך פיתוח המערכת. על ה-MSF, שינוי הגישה האחרונה שבוצעה בגרסה 4 שלו ועל גרסאות קודמות, ניתן לקרוא באתר מיקרוסופט: http://lab.msdn.microsoft.com/teamsystem/workshop/msfagile/default.aspx ה. בטעות חשבתי שכתבת ERD ולא ER, אז כבר כתבתי תשובה לגבי ERD ולכן אשאיר אותה. בכל אופן לגבי ER - זה די נכון ש-ER ו-CD הן דומות, אך ב-ER נהוג להשתמש רק בשלב הייזום/אפיון על-מנת להגדיר את ישויות המידע העיקריות של המערכת, בעוד ש-CD מומלץ לשימוש גם בשלב האפיוון (שבו התוצר דומה ל-ER) וגם בשלב העיצוב בו מעובה ה-CD ומשתמש לתיאור מחלקות המערכת. ולגבי ERD (אם כבר, אז כבר): נכון שבמערכות רבות ה-CD יתורגם בסופו של דבר ל-ERD (לפחות זה של האפיון), אך ERD הוא מאוד תלוי מסד-נתונים (מבחינת ההגדרות הקשיחות של הנרמול, סוגי המשתנים וכו'). כשעוסקים במחלקות (Classes), לא צריך לתת את הדעת ל-"איך אני הולך לשמור את זה אח"כ", ולכן אפשר לנצל את יכולות ה-OO וה-CD בשביל לתאר ירושות (שאינן נתמכות ב-ERD וב-DB רלציונים), אגרגציות למיניהן (שאומנם נתמכות ב-ERD, אך לך תמצא את ההבדל ב-ERD בין אגרגציה חלשה לחזקה) וכו'. אני הייתי עושה את הדבר הבא - מתחיל בתיאור CD של ישויות המידע של המערכת, לאחר מכן נותן ל-DBA או לאיש מקצוע אחר לקבוע מה-CD את ה-ERD ובסופו של דבר, נותן למעצב ול-DBA לקבוע את ה-ERD המלא שכולל בתוכו את הטבלאות הנוספות שאינן חלק מישויות המידע. ו. האמת לא זכור לי ממש מה זה "מילון הפונקציות". ה-sequence הוא תרשים ששם דגש על הרצף הכרונולוגי של תהליך ועל הפעולות המבוצעות בזמן זה. נהוג להשתמש בדיאגרמה זו כאשר רוצים לתאר רצף פעולות שמופעלות כאשר ניזום איזשהו תהליך במערכת (לדוגמה, לחיצה על כפתור והשתלשלות האירועים והמתודות שרצות כתוצאה מלחיצה זו). ל-sequence diagram יש מבנה מוגדר מאוד מבחינה גרפית - עמודות שמתארות את המחלקות וקווים שיוצאים מעמודה אחת לאחרת ובכך מתארים קשר של הפעלת מתודה במחלקה ב' ע"י מחלקה א' (הקווים מאוזנים וכל קו הוא קצת למטה מהקו הקודם כדי ליצור רושם של תרשים מדרגות יורדות). לגבי sequence ניתן לקרוא באתרים העוסקים ב-UML (יש הרבה בקישורים), אני אישית ממליץ על האתר הבא: http://www.agilemodeling.com/artifacts/sequenceDiagram.htm כיסיתי הכל ?
א. אין סיבה משמעותית. מאחר ורציתי לתת את הדעת על מתי להשתמש בכל אחת מהדיאגרמות, חשבתי שיהיה יותר נכון לפרט לפי הדיאגרמות ולא לפי שלבי מחזור החיים. ב. UML הינה נוצטיה בלבד (שפה לרישום) ואינה מתודולוגיה. במתודולוגיות חדשות וכן במתודולוגיות ישנות שהותאמו ל-UML, נהוג להשתמש בתוצרי ה-UML בשלבי מחזור החיים השונים. בסגנונות מחזורי חיים כגון מפל מים, ספירלי, איטרטיבי וכו' המנצלים את ה-UML כשפת רישום, ישנו שימוש בכל הדיאגרמות, אך בסדר שונה וברמות שונות של פירוט (לדוגמה, במפל מים בשלב האפיון תצטרך לעשות UCD של כל המערכת, בעוד שבמחזור חיים איטרטיבי תתן UCD רק של האיטרציה הנוכחית). דרך אגב, המונח "מפל מים" הינו ללא גרשיים - הדימוי הוא מאחר והמים זורמים מראש המפל מטה בדומה למחזור החיים שמריץ את כל השלבים אחד אחרי השני ללא חזרה ג. נוהגים להשוות UCD ל-DFD בגלל שהם נראים דומים והם מחליפים את שלב הגדרת התהליכים. DFD נועד יותר לתיאור זרימת המידע במערכת, בעוד UCD נועד להדגיש את התהליכים במערכת, ללא מתן דגש על המידע אלא יותר דגש על התהליך כתהליך עסקי. ניתן להתסכל על UC כעל "טרנזקציה" בחיים האמיתיים - תהליך שמתחיל בנקודה מסוימת (אני מגיע לכספומט), יש לו תנאים מקדימים (בשביל להוציא כסף מהכספומט אני צריך להכניס כרטיס ולהקיש קוד סודי), יש לו תיאור הליך סטנדרטי (אני מקיש את הסכום ומקבל את הכסף), יש לו תיאור תהליכים חליפיים (אין לי כסף בעו"ש ולכן מופיעה הודעה) ויש לו תוצאה סופית (הכסף והכרטיס ביד ופחות כסף בחשבון) - לא תיארתי פה את מאגרי המידע שהייתי מתאר ב-DFD, לא הייתי מתאר את הרשומות שהיו עוברות מ-DB ל-DB (מה שהייתי עושה ב-DFD) וכו'. ד. RUP הינה מתודולוגיית פיתוח שהוגדרה ע"י חברת Rational (כיום IBM) שאינה שמה את הדגש על השלבים המוכרים של אפיון, עיצוב, קידוד ... אלא על הפאזות שמערכת עוברת (התעברות - Inception, עיבוד/תכנון-Elaboration, בנייה/פיתוח - Construction ו-מעבר/הסבות - Transition) ומתארת בכל שלב (פאזה) שכזה את התוצרים השונים שצריך לספק, בכל אחד מהשלבים המוכרים לנו (דרישות, עיצוב, אפיון, בדיקות, פיתוח - לאו דווקא לפי סדר זה) ואת רמת ההשקעה הנדרשת עבור כל תוצר. ישנם מתודולוגיות רבות שהתפתחו מה-RUP והרחיבו אותו על-מנת לטפל בסוגים שונים של מערכות (לדוגמה : מערכות שיש להם שלבי תחזוקה ארוכים). ישנם מספר לינקים לנושא זה בקישורים. MSF - מיקרוסופט אינה מגדירה את ה-MSF כמתודולוגיה אלא כמסגרת פיתוח (framework). ה-MSF למיטב זכרוני נוצר כאיזשהו נסיון של מיקרוסופט לאסוף את הנסיון שלה בפיתוח מערכות למתודולוגית/מסגרת פיתוח אחידה. ה-MSF מגדיר את שלבי מחזור החיים באופן די דומה לשלבים המוכרים - ייזום, תכנון, פיתוח, ייצוב והתקנה. עבור כל שלב ישנו אוסף מסמכים שאמורים לכסות את התוצרים שהשלב אמור לספק והסבר כיצד יש למלא מסמכים אלו. ה-MSF מסביר גם טוב מאוד את התפקידים השונים הקיימים בצוות הפרויקט ואת תפקידם במהלך פיתוח המערכת. על ה-MSF, שינוי הגישה האחרונה שבוצעה בגרסה 4 שלו ועל גרסאות קודמות, ניתן לקרוא באתר מיקרוסופט: http://lab.msdn.microsoft.com/teamsystem/workshop/msfagile/default.aspx ה. בטעות חשבתי שכתבת ERD ולא ER, אז כבר כתבתי תשובה לגבי ERD ולכן אשאיר אותה. בכל אופן לגבי ER - זה די נכון ש-ER ו-CD הן דומות, אך ב-ER נהוג להשתמש רק בשלב הייזום/אפיון על-מנת להגדיר את ישויות המידע העיקריות של המערכת, בעוד ש-CD מומלץ לשימוש גם בשלב האפיוון (שבו התוצר דומה ל-ER) וגם בשלב העיצוב בו מעובה ה-CD ומשתמש לתיאור מחלקות המערכת. ולגבי ERD (אם כבר, אז כבר): נכון שבמערכות רבות ה-CD יתורגם בסופו של דבר ל-ERD (לפחות זה של האפיון), אך ERD הוא מאוד תלוי מסד-נתונים (מבחינת ההגדרות הקשיחות של הנרמול, סוגי המשתנים וכו'). כשעוסקים במחלקות (Classes), לא צריך לתת את הדעת ל-"איך אני הולך לשמור את זה אח"כ", ולכן אפשר לנצל את יכולות ה-OO וה-CD בשביל לתאר ירושות (שאינן נתמכות ב-ERD וב-DB רלציונים), אגרגציות למיניהן (שאומנם נתמכות ב-ERD, אך לך תמצא את ההבדל ב-ERD בין אגרגציה חלשה לחזקה) וכו'. אני הייתי עושה את הדבר הבא - מתחיל בתיאור CD של ישויות המידע של המערכת, לאחר מכן נותן ל-DBA או לאיש מקצוע אחר לקבוע מה-CD את ה-ERD ובסופו של דבר, נותן למעצב ול-DBA לקבוע את ה-ERD המלא שכולל בתוכו את הטבלאות הנוספות שאינן חלק מישויות המידע. ו. האמת לא זכור לי ממש מה זה "מילון הפונקציות". ה-sequence הוא תרשים ששם דגש על הרצף הכרונולוגי של תהליך ועל הפעולות המבוצעות בזמן זה. נהוג להשתמש בדיאגרמה זו כאשר רוצים לתאר רצף פעולות שמופעלות כאשר ניזום איזשהו תהליך במערכת (לדוגמה, לחיצה על כפתור והשתלשלות האירועים והמתודות שרצות כתוצאה מלחיצה זו). ל-sequence diagram יש מבנה מוגדר מאוד מבחינה גרפית - עמודות שמתארות את המחלקות וקווים שיוצאים מעמודה אחת לאחרת ובכך מתארים קשר של הפעלת מתודה במחלקה ב' ע"י מחלקה א' (הקווים מאוזנים וכל קו הוא קצת למטה מהקו הקודם כדי ליצור רושם של תרשים מדרגות יורדות). לגבי sequence ניתן לקרוא באתרים העוסקים ב-UML (יש הרבה בקישורים), אני אישית ממליץ על האתר הבא: http://www.agilemodeling.com/artifacts/sequenceDiagram.htm כיסיתי הכל ?
התבארות התמונה
תמונת ה- UML מתבארת לי יותר ויותר. לגבי המפ"ל מים. אתה צודק פשוט לא שמתי לב וטעיתי טעות פרודיאנית. אני משתמש במונח מפ"ל (לא מים) שאני עושה בהקשר אחר. אנצל הזדמנות זאת ואסביר מונח זה (שוב, לא מתודולוגית מפל המים) שקיים בנוהל מפת"ח. לפי נוהל מפת"ח המונח מפ"ל הינו קיצור של מסמכים פנימים לבדיקה. משמעותם היא אוסף מסמכים שמוכנים על ידי הלקוח שמבקש RFP מספקים. המפ"ל מכיל את שיטת הבדיקה של ההצעות שיגיעו מהספקים. אחת משיטות הבדיקה הנפוצות ביותר היא ואריציה כזו או אחרת של מודל דלפי. היא כוללת בין השאר את התבחינים, משקלם וסולם הציונים לכל תבחין.
תמונת ה- UML מתבארת לי יותר ויותר. לגבי המפ"ל מים. אתה צודק פשוט לא שמתי לב וטעיתי טעות פרודיאנית. אני משתמש במונח מפ"ל (לא מים) שאני עושה בהקשר אחר. אנצל הזדמנות זאת ואסביר מונח זה (שוב, לא מתודולוגית מפל המים) שקיים בנוהל מפת"ח. לפי נוהל מפת"ח המונח מפ"ל הינו קיצור של מסמכים פנימים לבדיקה. משמעותם היא אוסף מסמכים שמוכנים על ידי הלקוח שמבקש RFP מספקים. המפ"ל מכיל את שיטת הבדיקה של ההצעות שיגיעו מהספקים. אחת משיטות הבדיקה הנפוצות ביותר היא ואריציה כזו או אחרת של מודל דלפי. היא כוללת בין השאר את התבחינים, משקלם וסולם הציונים לכל תבחין.
לא בדיוק
ה-UC מתאר תהליך שלם ו"סגור". "יצירת קשר" זוהי הדרישה של הלקוח, ולכן הייתי מתאר את ה"תהליך" שרשמת כתהליך "יצירת קשר" מבלי לתאר כיצד הוא מבוצע, מהם הדפים המעורבים ומהו המידע שהמשתמש מזין. לאחר מכן אפשר להכניס מידע שסופק ע"י הלקוח ו/או מנתח המערכת - כיצד יבוצע הקשר, האם באמצעות שליחת מייל, פרסום מספר טלפון וכו'. מהם הפרטים שצריך להזין כדי ליצור קשר. האם לאחר הזנת הפרטים יש צורך לשלוח אישור לפונה. מהו המעקב שמתבצע אחר הפניות והגורמים הפונים וכו' וכו'. חשוב שלא לבלבל בין UC לבין מסכים/ארועים במערכת. כשאני בא לדוגמה לתכן את ה-UC של המערכת שלי אני מנסה לדמיין איך הלקוח של המערכת ישתמש בה ביום-יום ומהן הפעולות אותן הוא מבצע במהלך שגרת יומו באמצעות המערכת וכך זה עוזר לי להבין מה מוגדר כ"תהליך" ומה סתם מוגדר כ"לחיצה על כפתור"
ה-UC מתאר תהליך שלם ו"סגור". "יצירת קשר" זוהי הדרישה של הלקוח, ולכן הייתי מתאר את ה"תהליך" שרשמת כתהליך "יצירת קשר" מבלי לתאר כיצד הוא מבוצע, מהם הדפים המעורבים ומהו המידע שהמשתמש מזין. לאחר מכן אפשר להכניס מידע שסופק ע"י הלקוח ו/או מנתח המערכת - כיצד יבוצע הקשר, האם באמצעות שליחת מייל, פרסום מספר טלפון וכו'. מהם הפרטים שצריך להזין כדי ליצור קשר. האם לאחר הזנת הפרטים יש צורך לשלוח אישור לפונה. מהו המעקב שמתבצע אחר הפניות והגורמים הפונים וכו' וכו'. חשוב שלא לבלבל בין UC לבין מסכים/ארועים במערכת. כשאני בא לדוגמה לתכן את ה-UC של המערכת שלי אני מנסה לדמיין איך הלקוח של המערכת ישתמש בה ביום-יום ומהן הפעולות אותן הוא מבצע במהלך שגרת יומו באמצעות המערכת וכך זה עוזר לי להבין מה מוגדר כ"תהליך" ומה סתם מוגדר כ"לחיצה על כפתור"
להבדיל מדיאגרמות DFD
בדיאגרמות UC אין דבר כזה UC0 (כמו DFD0) ולכן אין הגדרת UC ראשי. UC מתאר תהליך בודד (טרנזקציה בחיים האמיתיים) וכפי שלא נהוג להתייחס ליום עבודה כ"טרנזקציה" (אף על פי שאני מכיר אנשים שכך הם חיים את חייהם - מיום עבודה אחד להבא), כך לא נהוג להגדיר UC אחד ראשי למערכת. את גבולות המערכת ניתן לייצג ע"י Actors (שחקנים) המתארים את הפונקציות (לא פונקציה מתמטית, פונקציה ארגונית/חוץ ארגונית) שלהם יש גישה למערכת (בין אם ספקי מידע, צרכני מידע או שניהם). נהוג שלכל UC יש איזשהו שחקן שיוזם את ה-UC ולפעמים גם יש שחקן שמקבל את תוצאת ה-UC (לאו דווקא תוצאת DATA). שחקנים (Actors) יכולים לתאר פונקציה ארגונית שמאחוריה עומדים אחד או יותר אנשים (מה שמכונה Role) ואף יכולה לתאר מערכת המשיקה למערכת שלנו (דרך אגב, לא נהוג להתייחס ל-DB של מערכת או לכל אמצעי מדיה אחר כאל Actor). הצבת ה-Actors וקישורם ל-UC עוזר לקבוע את ההתחלה והסוף של התהליך ובכל לאתר מיהם ה-Actors העיקריים במערכת ואת תרומתם למערכת. ישנן שיטות כתיבה (שרטוט) המכתיבות שכאשר בונים UCD, שמים את ה-UC-ים השונים בתוך מסגרת ואת ה-Actors מחוץ למסגרת ובכך מקבלים משהו שמזכיר קצת את ה-DFD0 (אפשר לראות דוגמה לכך באתר agilemodeling.com)
בדיאגרמות UC אין דבר כזה UC0 (כמו DFD0) ולכן אין הגדרת UC ראשי. UC מתאר תהליך בודד (טרנזקציה בחיים האמיתיים) וכפי שלא נהוג להתייחס ליום עבודה כ"טרנזקציה" (אף על פי שאני מכיר אנשים שכך הם חיים את חייהם - מיום עבודה אחד להבא), כך לא נהוג להגדיר UC אחד ראשי למערכת. את גבולות המערכת ניתן לייצג ע"י Actors (שחקנים) המתארים את הפונקציות (לא פונקציה מתמטית, פונקציה ארגונית/חוץ ארגונית) שלהם יש גישה למערכת (בין אם ספקי מידע, צרכני מידע או שניהם). נהוג שלכל UC יש איזשהו שחקן שיוזם את ה-UC ולפעמים גם יש שחקן שמקבל את תוצאת ה-UC (לאו דווקא תוצאת DATA). שחקנים (Actors) יכולים לתאר פונקציה ארגונית שמאחוריה עומדים אחד או יותר אנשים (מה שמכונה Role) ואף יכולה לתאר מערכת המשיקה למערכת שלנו (דרך אגב, לא נהוג להתייחס ל-DB של מערכת או לכל אמצעי מדיה אחר כאל Actor). הצבת ה-Actors וקישורם ל-UC עוזר לקבוע את ההתחלה והסוף של התהליך ובכל לאתר מיהם ה-Actors העיקריים במערכת ואת תרומתם למערכת. ישנן שיטות כתיבה (שרטוט) המכתיבות שכאשר בונים UCD, שמים את ה-UC-ים השונים בתוך מסגרת ואת ה-Actors מחוץ למסגרת ובכך מקבלים משהו שמזכיר קצת את ה-DFD0 (אפשר לראות דוגמה לכך באתר agilemodeling.com)
דוגמא מעשית
נגיד ואני מתכנן מערכת קטלוגית (הייתי צריך לעשות זאת לעבודה, אבל לא התקבלתי) באינטרנט (כלומר אתר תדמיתי...) וזה האיפיון: גולש נכנס לאתר ומחפש מוצר לפי קטגוריה או לפי הגוף שיצר אותו, המוצר נמצא ומוצג עליו מידע מנהל נכנס לאתר ויכול לבחור אם להתנהג כמו גולש רגיל או להיכנס לממשק ניהול ולהוסיף/למחוק/לשנות מידע אודות מוצר או קטגוריה. לדוגמא: 1. גולש נכנס לאתר, מחפש נגן IPOD של חברת אפל, מוצא את הנגן המבוקש ורואה עליו מידע כמו מחיר, ארץ ייצור וכדומה... 2. גולש נכנס לאתר, בוחר בקטגוריית נגני מוזיקה ניידים, מוצא את הנגן שהוא רוצה (IPOD לצורך הדוגמא) ורואה עליו מידע כמו מחיר, ארץ ייצור וכדומה. 3. מנהל נכנס לאתר ומוסיף את הנגן IPOD החדש של חברת אפל לתוך המאגר. 4. מישהו מודיע למנהל האתר שהתמונה של ה-IPOD היא לא התמונה הנכונה לדגם שניתן – המנהל נכנס לממשק הניהול ומשנה את התמונה לתמונה הנכונה. 5. המלאי של הIPOD נגמר ואפל הפסיקו לייצר אותם – לכן המנהל של האתר מוחק את המוצר מהמאגר. 6. המנהל של האתר רוצה לפתוח בליין חדש של מוצרים – מקררים – לכן הוא מוסיף קטגוריית מקררים לאתר. 7. המנהל של האתר מחליט לשנות את השם של קטגורייה מסויימת לקטגוריה הכללית יותר כמו למשל – תנורים למוצרי חימום (טוסטרים, מצנמים, תנורים, גזיות...) – ולכן והא ישנה את שם הקטגוריה 8. המנהל של האתר מחליט שהוא יותר לא מספק מידע אודות מחשבים ולכן מוחק את קטגוריית המחשבים מהאתר. האם הUse Case Diagram שהכנתי הוא בסדר? מתאים לאיפיון ? אשמח לשמוע הערות
נגיד ואני מתכנן מערכת קטלוגית (הייתי צריך לעשות זאת לעבודה, אבל לא התקבלתי) באינטרנט (כלומר אתר תדמיתי...) וזה האיפיון: גולש נכנס לאתר ומחפש מוצר לפי קטגוריה או לפי הגוף שיצר אותו, המוצר נמצא ומוצג עליו מידע מנהל נכנס לאתר ויכול לבחור אם להתנהג כמו גולש רגיל או להיכנס לממשק ניהול ולהוסיף/למחוק/לשנות מידע אודות מוצר או קטגוריה. לדוגמא: 1. גולש נכנס לאתר, מחפש נגן IPOD של חברת אפל, מוצא את הנגן המבוקש ורואה עליו מידע כמו מחיר, ארץ ייצור וכדומה... 2. גולש נכנס לאתר, בוחר בקטגוריית נגני מוזיקה ניידים, מוצא את הנגן שהוא רוצה (IPOD לצורך הדוגמא) ורואה עליו מידע כמו מחיר, ארץ ייצור וכדומה. 3. מנהל נכנס לאתר ומוסיף את הנגן IPOD החדש של חברת אפל לתוך המאגר. 4. מישהו מודיע למנהל האתר שהתמונה של ה-IPOD היא לא התמונה הנכונה לדגם שניתן – המנהל נכנס לממשק הניהול ומשנה את התמונה לתמונה הנכונה. 5. המלאי של הIPOD נגמר ואפל הפסיקו לייצר אותם – לכן המנהל של האתר מוחק את המוצר מהמאגר. 6. המנהל של האתר רוצה לפתוח בליין חדש של מוצרים – מקררים – לכן הוא מוסיף קטגוריית מקררים לאתר. 7. המנהל של האתר מחליט לשנות את השם של קטגורייה מסויימת לקטגוריה הכללית יותר כמו למשל – תנורים למוצרי חימום (טוסטרים, מצנמים, תנורים, גזיות...) – ולכן והא ישנה את שם הקטגוריה 8. המנהל של האתר מחליט שהוא יותר לא מספק מידע אודות מחשבים ולכן מוחק את קטגוריית המחשבים מהאתר. האם הUse Case Diagram שהכנתי הוא בסדר? מתאים לאיפיון ? אשמח לשמוע הערות
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.