גישת האובייקטים UML

גישת האובייקטים - OO/UML

מדריך זה מכיל הנחיות מעשיות לשילוב גישת האובייקטים (Object Oriented) בכלל ושפת UML (Unified Modeling Language) בפרט, עם שיטת מפת"ח. שילוב זה מתבטא בראש ובראשונה בהתאמה של עץ המערכת לתוצרים (artifacts) של שפת  UML. השפעה חשובה אחרת היא על מחזור החיים של הפרויקט ואופן ניהולו.  הבנת מדריך זה והשימוש המעשי בו מותנים בהכרה בסיסית מוקדמת (וניסיון מעשי) של נוהל מפת"ח בכלל וגישת האובייקטים ושפת UML בפרט.

מבוא ומושגי יסוד

גישת האובייקטים Object Oriented או בקיצור OO - תרגום מוצע בעברית: מכוון או מונחה עצמים - היא גישה מוכחת להנדסת תוכנה, היינו, לפיתוח ותחזוקה של מערכות ממוחשבות לסוגיהן השונים: מערכות מידע, מערכות זמן אמת ומערכות תשתית. השיטה החלה ברמת התכנות OOP - Object Oriented Programming כשהיא מלווה בקומפיילרים ושפות תכנות חדשות, המשכה בעיצוב OOD - Object Oriented Design ובאפיון וניתוח מערכת Object Oriented Analysis - OOA. פרק זה מסתמך על הכללים והסימולים שנקבעו בתקן UML – Unified Modeling Language. תקן זה מוסבר בקצרה בסעיף שפת (תקן) UML להלן.

במרכז גישת האובייקטים עומדת התפיסה לפיה המערכת בנויה מאובייקטים ש"מדברים" אחד עם השני באמצעות שדרים (messages) מוגדרים היטב. כל המשאבים או הישויות במערכת הם "אובייקטים". לכל אובייקט יש אחריות (responsibility) או תפקיד (role) מסוים. על מנת לבצע את תפקידו, הוא מכיל את כל הנתונים הדרושים (attributes) ואת כל הפעולות (methods) הרלוונטיות למידע זה. האובייקט גם זוכר כל הזמן את המצב (state) בו הוא נמצא. המבנה הפנימי של אובייקט מכיל אפוא נתונים, פעולות (פונקציות) ומצב שזורים ומשולבים היטב. מבנה פנימי זה הוא "קופסא שחורה" לעולם החיצון. העולם החיצון, היינו אובייקטים אחרים, מכיר אך ורק את "חתימת" האובייקט, כלומר את השדרים ואת התנאים הדרושים לפני ואחרי הפעלתם. חתימת האובייקט, signature, הממשק שלו עם העולם החיצוני, נקראת בספרות גם ה"חוזה" – contract, מה שהוא מתחייב לבצע בתנאים נתונים.

 

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

 

 ·         הערה: ההגדרה הנ"ל היא המקובלת בתקן UML. בחלק מהספרות ההגדרה של אובייקט ומחלקה היא קצת שונה. מחלקה כפי שהוגדר כאן נקראת "סוג אובייקט" ((object type או סתם "אובייקט". אובייקט כפי שהוגדר כאן נקרא שם מופע - instance. במסמך זה אובייקט הוא המופע ומחלקה היא הקבוצה.

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

 

החיבור הצמוד של הנתונים\מאפיינים (attributes), פעולות (operations) ומצב (state) ל"קופסא שחורה" שניתן לתקשר איתה אך ורק ע"י שדרים מוגדרים ומותנים, הוא התכונה המרכזית הראשונה של גישת האובייקטים. תכונה זו נקראת Encapsulation (כמיסה, מלשון כמוסה - קפסולה) והיא המשך של רעיונות ידועים כמו החבאת מידע - Information Hiding או הפשטת נתונים Abstract Data Type, אשר קיימים כבר זמן רב בשפות כמו ADA וC++-.

התכונה המרכזית השנייה של גישת האובייקטים היא ההורשה - Inheritance. מחלקות האובייקטים אינן סתם וקטור רציף ללא קשר אחד עם השני, אלא מסודרות בהיררכיות. בראש ההיררכיה (או בשורש של העץ) עומדת מחלקה כללית ביותר, כגון: חשבון בנק. במחלקה זו מוגדרים הנתונים (attributes) והפעולות (operations) המשותפים לכל חשבון בנק מכל סוג שהוא וכן השדרים שמחלקה כללית זו מבינה ויודעת לטפל בהם. "מתחת" למחלקה ראשית זו מוגדרות מחלקות מתמחות וספציפיות יותר כגון: חשבון עו"ש, חשבון מט"ח, חשבון חסכון וכו'. ראה איור מס' 1 להלן. יש לשים לב שבתרשים מופיעות רק המחלקות ולא האובייקטים הספציפיים: חשבון הבנק של חברה  X או של אזרח Y אלה "מסתתרים" מאחורי כל מחלקה.

תיאור: Inheritance_100105

איור 1: תרשים סכמתי של קשרי הורשה - Inheritance

 

בכל אחת ממחלקות הבנים מוגדרים רק המאפיינים, הפעולות והשדרים הנוספים או השונים לעומת אלה של מחלקת האב. וכך הלאה בהיררכיה, המחלקה חסכון בונוס מוגדרת "תחת" חשבון חסכון,עו"ש משופר מוגדר "תחת" חשבון עו"ש וכו'. ובדוגמא של צורות על המסך: ריבוע הוא בן של מרובע, שהוא בן של מצולע וכו', עד לשורש העץ המגדיר "צורה על מסך" שיתכן שכל מה שהיא יודעת לעשות זה שתי פעולות פשוטות: צייר ומחק. שיטה זו של הגדרת תוספות ושינויים בלבד נקראת גם בשם differential programming. התכונות של אובייקטי בנים, בכל רמה שהיא בעץ, הן שילוב של תכונות (מאפיינים, פעולות ושדרים) שהם יורשים מהאב יחד עם תכונות פרטיות שלהם. לבן יש תמיד הזכות להוסיף תכונות חדשות (מאפיינים/שדרים) או לשנות (לבצע override על) את שיטת הטיפול בשדרים שקיבל בירושה. אם האב הוא עצמו בן, אזי הנכד יכול באופן זה לקבל תכונות בירושה גם מהסבא, מהסבא-רבא וכו'.

הגדרת עץ ההורשה, בדומה לכל ניתוח מערכת, יכולה להיעשות "מלמעלה למטה" (top down) או "מלמטה למעלה" (bottom up). במקרה הראשון מדובר על specialization, היינו ממחלקות כלליות גוזרים מחלקות יותר ויותר ספציפיות (מתמחות) המשתמשות בהגדרות קיימות ומוסיפות רק את התכונות המיוחדות שלהן. במקרה השני מדובר על generalization, היינו מנסים לבצע האחדה (קנוניזציה) של מחלקות דומות והכנסתן לעץ הורשה תוך כדי "חיתוך" ופישוט של הגדרתן וויתור על תכונות כלליות שאינן ספציפיות. כך או כך, כל מחלקה חדשה יוצרת דילמה לאן לשייך אותה, לעץ הורשה קיים, זה או אחר, לפתוח עץ חדש, מחלקה העומדת בפני עצמה וכו'. זו האמנות של ניתוח מערכת בכלל וניתוח מערכת בגישת האובייקטים בפרט.

 

הפעלת האובייקטים נעשית תמיד "מלמטה למעלה". כאשר שולחים שדר משיכה לאובייקט עו"ש-משופר, למשל, הוא נבדק מאובייקט זה "ומעלה" (לכיוון שורש העץ) והראשון שמבין מה זו משיכה מבצע את הפעולה הנדרשת. אם הראשון הוא עו"ש משופר עצמו, היינו, יש לעו"ש משופר פעולת משיכה מיוחדת, היא זו שתבוצע. אם אין, תיעשה פנייה לאב, היינו לחשבון עו"ש ואם גם בו לא מוגדרת פעולה כזו תתבצע משיכה כפי הגדרתה בסבא: חשבון בנק. לעובדה שאובייקטים רבים מגיבים לאותו שדר (בעל אותו שם, אך אשר מבצע פעולה שונה) קוראים Polymorphism (ריבוי צורות). מונח אחרון זה מבליט את אחד היתרונות של OO בכלל, ושל תכונת ההורשה בפרט, שהוא, פישוט שפת התכנות ע"י צמצום הפעלים (verbs) שבהם משתמשים ופישוט מבנה התכנית ע"י הקטנת ההתניות (פקודות הIF- או הCASE-) בקוד עצמו. השדר משיכה נשלח לאובייקט עו"ש משופר. אם הוא יודע לבצע זאת, מה טוב. אם לא, הפעולה הנדרשת מתגלגלת כלפי מעלה בעץ עד שהיא "נתפסת" ע"י האובייקט הראשון שיודע איך מבצעים משיכה. באופן זה נמצאות ההתניות, היינו חלק חשוב בלוגיקה ובסיבוכיות של המערכת, בעץ ההורשה ולא בקוד. אגב, ריבוי הצורות גם מחזיר אותנו לתכונת הכמיסה. אם שני אובייקטים יודעים להגיב לשדר החיצוני משיכה, אך כ"א מבצע זאת באופן פנימי שונה - זו היא הכמיסה! זאת הוכחה שהאובייקטים אכן כמוסים ואין תלות בין השדר שנשלח (והשדר היוצא) ובין המבנה הפנימי של האובייקט.

 

סיכום – המשך קריאה

סקירה מלאה של גישת האובייקטים היא מעבר לתכולת מדריך זה ולשם כך מומלץ לפנות לספרות המקצועית אשר חלקה מוזכר בסוף המדריך. להלן נדון במספר הרחבות החיוניות לשילוב מפת"ח וגישת האובייקטים. הנושא העיקרי בו נרחיב להלן הוא שפת ה- UML, שהיא היום התקן המקובל והנפוץ ביותר ליצירת מודלים לאפיון ועיצוב מונחי עצמים. את התקן יוצר ומתחזק ארגון ה- OMG (Object Management Group) אשר חברת בו מספר מאות חברות בעלות עניין, מהמובילות בשוק התוכנה.

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

בגישת האובייקטים, האובייקטים הם אותם אובייקטים באפיון, בעיצוב, בבנייה וכו', אלא שהם מקבלים פירוט והופכים למוחשיים ומוגדרים יותר ויותר ככל שמתקדמים בפרוייקט. תפיסה זו דומה מאד למודל המטריצה של מפת"ח, לפיו רכיבי עץ המערכת הולכים ומתפתחים לאורך מחזור החיים של הפרויקט. המשימה העיקרית היא אפוא, ליצור קשר בין תוצרי גישת האובייקטים לבין עץ המערכת. זאת נעשה בגלופת עץ המערכת המותאמת ל- UML.

שפת (תקן) UML

UML - Unified Modeling Language היא שפה גרפית שנקבעה כסטנדרט בעולם האובייקטים. שפה זו תומכת בכל מחזור החיים של מערכת המידע וקובעת תוצרים ברורים לכל שלב בחיי המערכת. תוצרים אלה מוצגים כתרשימים (Diagrams). באמצעותה ניתן לדמות, לפרט, לבנות ולתעד את תוצרי התוכנה של מערכת מידע. UML מאפשרת להשתמש בשיטה סטנדרטית ליצירת אפיוני מערכת המכסים תהליכים עסקיים ופונקציות במערכת, כמו גם דברים מוחשיים כמו מחלקות (classes) הנכתבות בסביבת פיתוח מסוימת, סכימת בסיס הנתונים וקטעי קוד המיועדים לשימוש חוזר (reuse).  יש לשים לב כי UML אינהמתודולוגיה. UML רק מגדירה את השפה שבה מכינים תוצרים במהלך מחזור החיים של פיתוח מערכת מידע אולם היא לא מגדירה ולא ממליצה על השיטה ורצף הפעילויות שיש לבצע כדי להשתמש באותה שפה. לשם כך פותחו מתודולוגיות רבות ומגוונות, שלכל אחת מהן יש יתרונות וחסרונות. כל ארגון המעוניין להשתמש ב- UML לאפיון ו/או עיצוב המערכת צריך גם לאמץ לעצמו מתודולוגיה ברורה אשר תגדיר מהו רצף הפעילויות שעל המנתח/מעצב לבצע בכל שלב במדויק. בהקשר זה מפת"ח מגדיר במידה רצף פעילויות כזה, ועושה "סדר בבלגן" באופן ראשוני, משום שהוא מגדיר איזה תוצר UML מומלץ להכין בכל שלב של מחזור החיים, והיכן יש לשלב אותו בעץ המערכת. לכן מפת"ח מהווה נוהל מסגרת ומתודולוגיית-על, אולם ההנחיות הכלולות בו אינן מהוות מתודולוגיה פרטנית ושלמה, מכיוון שהן לא כוללות הנחיות והמלצות מפורטות לגיבוש מסודר ושיטתי של התוכן של אותן דיאגרמות. להפניות למתודולוגיות לשימוש ב UML ראה פירוט בסוף מדריך זה.

מדריך זה מבוסס על מהדורה 1.1 של התקן. מהדורה 2.0 פורסמה לאחרונה ומכילה מספר חידושים (ראה פרק ההפניות והסימוכין בסוף המדריך לקישור לאתרים באינטרנט המכילים מידע באשר לשיפורים במהדורה 2.0).

דיאגרמות - תוצרי UML

במסגרת UML מוגדרים תשעה סוגים עיקריים של דיאגרמות המשמשות להצגת המערכת בשלבים שונים, מנקודות מבט שונות ולגורמים שונים המעורבים בפיתוחה.

1.       Use case diagram

2.       Class diagram

3.       Object diagram

4.       Sequence diagram

5.       Collaboration diagram

6.       Activity diagram

7.       State chart diagram

8.       Component diagram

9.       Deployment diagram

דיאגרמות מסוג Class, Object, Component ו- Deployment שייכות לקבוצת דיאגרמות הנקראת Structural diagrams, מכיוון שהם מתארות את מבנה המערכת.

שאר הדיאגרמות שייכות לקבוצת דיאגרמות שנקראת Behavior diagrams משום שהן מתארות את התנהגות המערכת וחלקיה הפנימיים.

Use case diagram

Use case מייצג פונקציונליות שלמה (אוסף פעילויות) מנקודת ראות של Actor מסוים (או מספר Actors אם כולם מבצעים את אותו Use Case), כאשר Actor מייצג משתמש או מערכת השולחים או מקבלים מסרים מהמערכת. Use Cases מקושרים ל- Actors ול- Use cases אחרים באמצעות Associations, לכל Use Case יכולים להיות מספר Actors ולהפך.

Use case diagram מציגה Actors ו- Use cases הקשורים ביניהם. הדיאגרמה יכולה להיות מלאה או חלקית. ניתן להציג Actor וה- Use cases הקשורים אליו או להיפך: Use case וה- Actors הקשורים אליו. ניתן אף ליצור דיאגרמה מורכבת המכילה מספר Actors ומספר Use Cases עם כל הקשרים ביניהם. רכיב 2.2 (תיחום חיצוני) בעץ המערכת יכיל דיאגרמות Use Case, כאשר במרכז יופיע ה- Actorומסביבו ה- Use Cases הקשורים אליו. רכיב 2.6 (Use cases) בעץ המערכת יכיל דיאגרמות אלה, אך בכיוון ההפוך: ה- Use Case במרכז, ומסביבו כל ה- Actors הקשורים אליו.

 

תיאור: Use Case_230904

איור 2Use Case diagram

Object diagram

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

Object diagram הוא תרשים המכיל אובייקטים והקשרים ביניהם בנקודת זמן. ניתן להתייחס אל תרשים אובייקטים כאל מקרה מיוחד של  class diagram או של collaboration diagram (ראה להלן).

Class diagram

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

Class diagram הוא תרשים בו משתמשים לתיאור Classes והקשרים בין Classes. להלן דוגמא:

 

תיאור: Class_230904

איור 3Class diagram

 

הקשרים בין המחלקות הם מהסוגים הבאים:

 ·         קשרים תפעוליים/פונקציונאליים (Association) כגון הקשר "ספק - פריט" שפירושו: ספק מספק אחד או יותר פריטים ופריט ניתן לרכישה מספק מסוים.

 ·         קשרי הכלה (Aggregation) כגון: "מפעל" או "קו-ייצור" השייכים לספק מסוים. נקראים גם Aggregation.

 ·         קשרי הורשה (Inheritance) כגון: "ספק-אשראי" שהוא בן של "ספק" ומקבל בירושה את כל התכונות של הספק עליהן הוא מוסיף תכונות פרטיות שלו. סוג זה של קשר הוא ייחודי לגישת האובייקטים.

Sequence diagram

מתאר את רצף הפעילויות בתוך Use Case או בתוך Class diagram, מדגיש את גורם הזמן, מציג את קשרי הגומלין בין האובייקטים ומציג את קשרי הגומלין  בין ה- Actors למערכת. משתמשים בתרשים זה לשני שימושים עיקריים:

 ·         System Sequence Diagram - תרחיש בסיסי לאורך ציר הזמן של ה-Use Case. ניתן להשתמש לצורך זה גם ב- Activity diagram (מוסבר בהמשך).

 ·         Sequence Diagram - תרשים מתקדם תוך לקיחת שיקולים עיצוביים נוספים מעבר לתרחיש הבסיסי. תרשים זה מראה את קשרי הגומלין בין האובייקטים ב- Class diagram.

 

תיאור: Sequence_230904

איור 4Sequence diagram

Collaboration diagram

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

 

תיאור: Collaboration_230904

איור 5Collaboration diagram

Activity diagram

תרשים פעילות / זרימה, המשמש לתיאור גרפי של תהליכים עסקיים (או"ש), Use Cases, או אלגוריתמים פנימי של אובייקט. התרשים משמש כתרשים זרימה (Flow Diagram) ומציג את הפעילויות (Activities) המבוצעות כאשר מבוצעת פעולה (Method) או אף Use Case שלם. כמו כן ניתן להציג בתרשים זה את הפעילויות לפי תחומי אחריות.

 

תיאור: Activity_230904

איור 6Activity diagram

State chart diagram

מציג את המצבים השונים של אובייקט ואת את השפעת אירועים שונים על המצבים. הוא נחוץ עבור ה- Classes בהם ישנם מצבים שונים  ורבים, וכאשר נדרש לחדד את הכללים למעבר ממצב למצב (לפי הפעולות המופעלות).

 

תיאור: State Transition_230904

איור 7State chart diagram

Component diagram

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

Component diagram מציג אוסף של רכיביםואת הקשרים ביניהם. Component diagram הוא ההיבט הפיסי של Class diagram (כפי שאובייקט הוא ההיבט הפיסי של מחלקה שהיא דבר מופשט ולא קיים באופן מוחשי).

 

תיאור: Component_230904

איור 8Component diagram

Deployment diagram

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

 

תיאור: Deployment_230904

איור 9Deployment diagram

הרחבות

סוגי אובייקטים

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

 ·         אובייקטי מידע (Business Class) ואובייקטי בקרה (Control Objects)

 ·         אובייקטי ממשק משתמש (מסכים) User Interface/Boundary Class))

 ·         אובייקטי ממשק מערכת (ממשקים) Interface Class))

נהוג לחלק את המערכת לשלוש שכבות:

 ·         שכבת הנתונים - DB Class

 ·         שכבת העיבודים – Logical/Application Class

 ·         שכבת הממשק למשתמש - UI Class

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

מודלים מקובלים

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

Business Process Modeling

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

המודל משתמש בתוצרי UML כדי לתאר היבט או"ש של ניתוח התהליכים הארגונים במערכת.

בד"כ תוצרי המודל הם Activity diagrams כאשר כל פעילות בתוכם מתארת בסופו של דבר Use case אחד או יותר.

Use Case Modeling

המודל מציג את משתמשי המערכת והפעילות שיבצע כל משתמש במערכת.

תוצרי המודל הם :

 ·         רשימת משתמשים  Actor Catalogue.

 ·         רשימת Use Cases.

 ·         תרשימי Use Case Diagram עבור כל Actor במערכת.

המודל הסטטי

מודל זה מוכר גם בשם Class Model והוא מגדיר את המחלקות במערכת (Classes), כאשר לכל מחלקה מוגדרים הנתונים (Attributes) והפעולות (Operations) השייכים אליה (חתימה), והקשרים בינה ובין מחלקות אחרות.

המחלקות מסווגות לשלוש קטגוריות עיקריות: מחלקות מידע ובקרה, מחלקות ממשק משתמש (UI – User Interface) ומחלקות ממשק מערכת (ממשקים).

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

תוצרי המודל הם :

 ·         תרשימי  User Interface Class Diagram

 ·         תרשימי  Control Class Diagram

 ·         תרשימי  Interface Class Diagram

 ·         תרשימי  Component Diagram

 ·         תרשימי  Software Component Diagram

 ·         תרשימי  Deployment Diagram

המודל הדינמי

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

תוצרי המודל הם:

 ·         תרשימי State Diagram.

Object Interaction Model

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

תוצרי המודל הם :

 ·         תרשימי Sequence Diagram.

 ·         תרשימי Collaboration Diagram.

 ·         תרשימי Activity Diagram.

Storage Object Model

מודל זה מתאר מיפוי של מחלקות לטבלאות. זו פעילות המתבצעת בשלב העיצוב וכוללת המרת מודל הנתונים (Class Diagram) לבסיס הנתונים (Tables, Columns, Relationship)

תוצרי המודל הם :

 ·         תרשימי Storage Class Diagram.

 ·         תרשימי Object Diagram.

עץ המערכת ותוצרי UML

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

1. יעדים

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

2. יישום

רכיב היישום הוא הרכיב המרכזי בו יש שוני בין מערכות OO/UML ובין מערכות מידע "מסורתיות". השוני מתמקד ברכיבים מרכזיים כגון: 2.2, 2.3, 2.5, 2.6, 2.7, 2.9, 2.11 ו- 2.22. בגלופת הלימוד יש הסבר ופירוט מלאים לרכיבים אלה. ההפניות היחידות, אם ישנן, ברכיבים אלה, הן "חזרה" למדריך זה או לגלופות מפורטות יותר בהתאמה לשלב בו נמצאת המערכת: גלופת תיק אפיון, תיק עיצוב, תיק מבדקים ותיק תחזוקה. ברכיבי יישום שאינם שונים ממערכות מידע "מסורתיות" תהיה הפניה לעץ מערכת רמה 3 בדומה לרכיבי היעדים, הטכנולוגיה, המימוש והעלות.

3. טכנולוגיה

גישת האובייקטים, בניגוד לגישות ושיטות הנדסת תוכנה אחרות, לוותה כמעט מראשיתה בכלים מעשיים המסייעים לממשה בפועל. הכלי הראשון הוא שפות תכנות וקומפיילרים, אשר גם אם לא מכריחים את המשתמש לתכנת בדיוק לפי כל כללי ה- OOP, מכילים, הן בהגדרת הנתונים (האובייקטים) והן בפקודות את כללי התחביר ו"הדקדוק" של שפת ה- OO. דוגמאות לשפות OO הן: C++, Smalltalk, ADA ועוד.

טכנולוגית ה- CASE שהתפתחה בשנים האחרונות תומכת בגישת האובייקטים ויש כבר בשוק מספר כלים התומכים גם באפיון  (OOA) וגם בעיצוב (OOD). חלקם מאפשר לנהל את כל מחזור החיים של פיתוח מערכת החל משלב האפיון וכלה בתכנות ובבדיקות.

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

ענף אחר הם בסיסי נתונים מכווני אובייקטים (OODBMS), שהמאפיין הראשי שלהם הוא אחסון התכנית (הקוד) יחד עם הקובץ (המידע). בסיס הנתונים הוא אמצעי ראשי למימוש תכונת ה- Encapsulation. בחלקם אלה בסיסי נתונים חדשים ובחלקם הם הרחבה של בסיסי נתונים טבלאיים קיימים.

רכיבי הטכנולוגיה בעץ המערכת נשארו כפי שהם, אולם התכנים יותאמו לאותם כלים מעשיים המלווים את גישת האובייקטים

5-4. מימוש ועלות

אין סיבה לשינויים מהותיים ברכיבי המימוש והעלות, להוציא את ההשלכות שיש לעובדה שמדובר ב"מערכת חלוצה" - מערכת המפותחת בארגון שנחשף לפתוח מערכות מידע בגישה מונחית אובייקטים - או במערכות שעושות כבר שימוש חוזר בתשתית שהונחה לפניהם (מערכות משתמשות). כצעד ראשון, יש לזכור שרכיב זה הוא "סופר אורתוגונלי" ונגזר מרכיבים קונקרטיים חשובים. במילים אחרות, צריך לכמת תחילה את ה"עובדה" הנ"ל - מערכת חלוצה או משתמשת –ותרבות הפיתוח של הארגון לתוך רכיבים קונקרטיים, בעיקר טכנולוגיה, מימוש ועלות (בנוסף ל- 1.2 ו- 1.3) ולהגדיר היטב את ההשלכות על הגורמים המעורבים, תכנית העבודה, עלויות וכו'.

להנחיות נוספות ומפורטות לשילוב תוצרי UML בעץ המערכת ראה לשונית 'תוצרים' בקיט זה.

שילוב תוצרי UML (UML artifacts) בעץ המערכת

הטבלה שלהלן מציגה את השילוב שבין תוצרי UML ועץ המערכת של מפת"ח. הטבלה מפרטת לכל רכיב בעץ המערכת את תוצרי UML שימוקמו בו:

רכיב עץ המערכת

שם התוצר באנגלית

הערות

2.2 תיחום חיצוני

Actor List (Catalog)

תוספת של מפת"ח, לא תוצר רשמי של UML. 

 

Use Case Diagram

מנקודת מבט של Actor מסוים: כל ה- UC’s  בהם הוא משתתף.

2.3 תיחום פנימי

Packages diagram

 

 

 

חלוקה גרפית היררכית לתת מערכות ופונקציות ראשיות.

2.4 ממשק משתמש

Class Diagram

בדגש למחלקות האחראיות לממשק המשתמש 2.4 UI Class Diag.

 

Component Diagram

 

2.5 תהליכים

Business process Hierarchy (Activity Diagram)

 

2.6 טרנזקציות Use cases

Use case diagram,

Activity Diagram

 

 

Sequence Diagram

ניתן גם להשתמש ב- Collaboration diagram.

 

Collaboration Diagram

ניתן גם להשתמש ב- Sequence diagram.

 

State Chart Diagram

 

X.2.6

Use Case Documentation

תיעוד ה- UC

ה- UC במרכז וסביבו כל ה- Actors ו- UC’s אחרים עמם יש לו קשר

X.2.7 מודולים/רכיבים

Component Diagram

בכפיפות למקובל בסביבת הפיתוח שתבחר

2.9 שגרות

Class Diagram

בדגש למחלקות האחראיות לשגרות: 2.9 Common Class Diagram

 

Component Diagram

 

2.10 טבלאות קודים (פרמטרים)

Class Diagram

בדגש למחלקות האחראיות לניהול טבלאות קודים: 2.10 Code table Class Diagram

2.11 מחלקות מידע Classes

Object Diagram

State Chart Diagram

Object Diagram ישמש בשלבי מחזור החיים המוקדמים, כאמצעי להמחשת המערכת.

 

Class Diagram

דיאגרמת המחלקות הראשית. אך גם כאן לא מומלץ להציג את כל המחלקות, רק את מחלקות המידע – Information Class Diagram

2.12 – טבלאות / קבצים

Class diagram

יש לשים לב שבשלב זה תקן UML אינו נותן מענה לעיצוב המבנה הפיסי של בסיס נתונים. קיימות הרחבות שונות של UML (באמצעות Stereotypes) לשם תיאור המבנה הפיסי של בסיס הנתונים באמצעות Class diagrams. לחילופין, ניתן להשתמש בתרשימי ERD (Entity Relation Diagram) אשר אינם חלק מ- UML אולם נותנים מענה מלא על עיצוב המבנה הפיסי של בסיס הנתונים.

2.15 דוחות

Class Diagram

בדגש למחלקות האחראיות לייצור וניהול הדו"חות: 2.15 Report Class Diagram

2.22 ממשקים וקישורים

Class Diagram

בדגש למחלקות האחראיות לניהול הממשקים: 2.22 Interface Class Diagram

3.0 טכנולוגיה

Deployment Diagram

 

 

 

מחזור חיים

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

שלב הייזום

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

שלב האפיון

התיחום הכללי של המערכת

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

 ·         Business Process Model - מודל המשמש להגדרת תיחום המערכת ולאפיון התהליכים העסקיים.

 ·         Use Case Modeling - מודל המגדיר את משתמשי המערכת ומתאר את הפעילות שתבצע המערכת עבור כל משתמש.

אופן פעילות המערכת ותפקודה

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

המידע שהמערכת מנהלת והפעולות המבוצעות על המידע

זיהוי המידע יתבצע באמצעות שימוש בטכניקת Class Modeling המגדירה את המחלקות (Classes) במערכת והקשרים ביניהן, כאשר כל Class כולל נתונים (Attributes) ופעולות (Operations) המבוצעות על נתונים אלו.

חשוב לסווג את המחלקות לקטגוריות של מחלקות ממשק משתמש (User Interface Classes), מחלקות מידע ובקרה ומחלקות ממשק מערכת (Interface Classes) ולתאר כל מחלקה במקום הטבעי שלה בעץ המערכת.

שלבי העבודה

שלב I אפיון על (הגדרת הדרישות)

 ·         זיהוי התהליכים העסקיים

 ·         הכנת Activity Diagram לתהליכים העסקיים

 ·         זיהוי ה-  Actors וה- Use Cases

 ·         הכנת  Use Case Diagram

 ·         זיהוי הקשרים בין ה- Use Cases

 ·         כתיבת תיעוד כללי ל- Use Cases עיקריים (מצורפת דוגמת גלופה לתיעוד)

 ·         זיהוי ישויות מידע ראשיות (אובייקטים) ובניית Object Diagram

 ·         בדיקה מול המשתמש וקבלת אישורו

 

שלב II אפיון מפורט (הניתוח)

 ·         זיהויClasses  ומאפיינים(Attributes) ובניית תרשים Class Diagram ראשוני

 ·         עבור כל Use Cases בנית Sequence Diagram (או Collaboration Diagram, או Activity diagram)

 ·         השלמת מאפיינים וקשרים ב-  Class Diagram

 ·         במידת הצורך, הכנת תרשים מצבים State chart או Activity Diagram נוספים

שלב עיצוב ובנייה

עיצוב

בשלב העיצוב יורחבו המודלים ולהגדרת ה- Class  במערכת, יתווספו מחלקות מסוג Control Object הדרושים להשלמת פעילות המערכת, יורחב השימוש במודל Object Interaction וישופר המודל הסטטי של המחלקות כפי שהוגדר ב- Class Model.

בעיצוב הדגש הוא כאמור על:

 ·         הגדרה סופית ומלאה של המחלקות וכל הקשרים ביניהן

 ·         הגדרה סופית של היררכיות ההורשה והתאמתן לבסיס הנתונים שנבחר (כולל המרת המחלקות לטבלאות לפי כללי המרה ברורים)

 ·         עיצוב סופי של כל האובייקטים הגרפיים (ממשקי משתמש)

 ·         תיאור מפורט של התהליכים הקריטיים במערכת.

במעבר מהאפיון לעיצוב באה לידי ביטוי ההמשכיות של מודל המטריצה של מפת"ח והפיתוח המדורג של גישת האובייקטים, במלוא תקפותם.

 

פעילויות עיצוב

 ·         בחירת תשתיות תוכנה, איתור רכיבים מוכנים

 ·         עבור כל Class: אפיון המאפיינים (Attributes), אפיון הפעולות (Operations)

 ·         הכנת GUI Class Diagram

 ·         הכנת Business Objects Classes

 ·         עיבוי ווידוא שלמות של Class Diag., Sequence Diag., Activity Diag. ו/או State Chart

 ·         מעבר לבסיס נתונים טבלאי (RDBMS) – הכנת Class diagrams המתארים את המבנה הפיסי של בסיס הנתונים (הטבלאות השונות). יש לשים לב שבשלב זה תקן UML אינו נותן מענה לעיצוב המבנה הפיסי של בסיס נתונים. למשל: לא קיימת בתקן הגדרה כיצד מתארים שדה מפתח ראשי בטבלה (הנקרא גם Primary Key). קיימות הרחבות שונות של UML (באמצעות Stereotypes) לשם תיאור המבנה הפיסי של בסיס הנתונים באמצעות Class diagrams. לחילופין, ניתן להשתמש בתרשימי ERD (Entity Relation Diagram) אשר אינם חלק מ- UML אולם נותנים מענה מלא על עיצוב המבנה הפיסי של בסיס הנתונים.

 ·         בנית מסכים, דוחות, טרנזקציות חיצוניות

 ·         תכנון מנגנון שגיאות Error Handling

 ·         חלוקת המערכת למודולים Component Diagram

 ·         בנית Deployment Diagram

 

בניית המערכת

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

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

שלב הבדיקות

ראוי לזכור את ארבעת מדדי האיכות הראשיים לפיהם נבדקת כל מערכת:

פונקציונאלית

עונה לדרישות הלקוח (ארגון-האם)

יעילה

איכותית ובנויה נכון מבחינה הנדסית, כולל גמישות לשינויים

כלכלית

עומדת בגבולות המשאבים ולו"ז שהוקצו

חוקית

עומדת בדרישות החוק, מינהל תקין וחוקת הארגון.

 

ההשפעה הישירה של גישת האובייקטים היא במדד השני והשלישי.

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

באופן דומה ייבדק גם האם כל התכונות המתוארות להלן תרמו למדד ג' - כלכליות וגרמו ליחס עלות/תועלת משופר.

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

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

תחזוקת המערכת

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

הטבלה שלהלן מציגה את השילוב שבין תוצרי UML ועץ המערכת של מפת"ח, לאורך שלבי מחזור החיים של הפרויקט. הטבלה מפרטת לכל רכיב בעץ המערכת, את תוצרי ה- UML שימוקמו בו בהתאם להתקדמות בשלבי מחזור החיים של הפרויקט.

 

רכיב עץ המערכת

משלב תוצר UML, בשלב

הערות

אפיון על

אפיון מפורט

עיצוב

2.2 תיחום חיצוני

Actor Diagram

מתגלגל ומשתכלל

מתגלגל ומשתכלל

 

Use Case Diagram

מתגלגל ומשתכלל

מתגלגל ומשתכלל

מנקודת מבט של Actor מסוים: כל ה-UC’s  בהם הוא משתמש.

2.3 תיחום פנימי

Package Component Diagram

מתגלגל ומשתכלל

מתגלגל ומשתכלל

חלוקה גרפית היררכית לתת מערכות ופונקציות ראשיות.

2.4 ממשק משתמש

 

Class Diagram

מתגלגל ומשתכלל

בדגש למחלקות האחראיות לממשק המשתמש 2.4 UI Class Diag.

 

 

Component Diagram

אופציונאלי

2.5 תהליכים

Activity Diagram

מתגלגל ומשתכלל

מתגלגל ומשתכלל

מתאר את התהליכים הארגוניים

2.6 טרנזקציות Use cases

 

Use case diagram +

Activity Diagram

מתגלגל ומשתכלל

ה- UC במרכז וסביבו כל ה- Actors ו-UC’s אחרים עמם יש לו קשר. לכל Use case: תיאור הפעולות באמצעותActivity diagram או sequence diagram.

 

Sequence Diagram

מתגלגל ומשתכלל

 ניתן גם להשתמש ב- Collaboration diagram

 

Collaboration Diagram

 

מתגלגל ומשתכלל

ניתן גם להשתמש ב- Sequence diagram.

 

State Chart Diagram

 

 

X.2.7 מודולים/רכיבים

 

 

Component Diagram

 

2.9 שגרות

 

 

Class Diagram

בדגש למחלקות האחראיות לשגרות: 2.9 Common Class Diagram

 

 

Component Diagram

 

2.10 טבלאות קודים (פרמטרים)

 

 

Class Diagram

בדגש למחלקות האחראיות לניהול טבלאות קודים: 2.10 Code table Class Diagram

2.11 מחלקות מידעClasses

 

 

State Chart Diagram

 

Object Diagram

Class Diagram

מתגלגל ומשתכלל

דיאגרמת המחלקות הראשית. אך גם כאן לא מומלץ להציג את כל המחלקות, רק את מחלקות המידע – Information Class Diagram

2.12 – טבלאות / קבצים

 

 

Class Diagram

ראה הערה לעיל בנושא לייצוג מבנה פיסי של בסיס נתונים באמצעות תרשים Class diagram

2.15 דוחות

 

Class Diagram

מתגלגל ומשתכלל

בדגש למחלקות האחראיות לייצור וניהול הדו"חות: 2.15 Report Class Diagram

2.22 ממשקים וקישורים

Component Diagram

במידת האפשר

Class Diagram

מתגלגל ומשתכלל

בדגש למחלקות האחראיות לניהול הממשקים: 2.22 Interface Class Diagram

3.0 טכנולוגיה

Deployment Diagram

כללי

Deployment Diagram

מתגלגל ומשתכלל

 

 

 

תרשים תהליך הפיתוח

תיאור: Life Cycle_100105

איור 10: תוצרי UML  בשלבי הפיתוח

אבטחת איכות ומדדים

נושא אבטחת האיכות של תוצרי האפיון והעיצוב ע"פ שיטת UML הוא נושא מורכב מאוד. איך מגדירים האם האפיון או העיצוב טובים ואיכותיים? התשובה לשאלה זו היא מחוץ לתיחום קיט זה.

קיט זה עוסק באפיון ועיצוב לפי גישת מפת"ח ו- UML, ולכן השאלה הרלוונטית לנושא זה היא: מהם הקריטריונים לפיהם ניתן לבדוק האם תיק האפיון או תיק העיצוב אשר נכתבו ע"פ גישת UML הם טובים ואיכותיים?

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

נשאלת גם השאלה: האם יש מדדים המאפשרים למדוד את איכות תוצרי UML המופקים בשלב האפיון והעיצוב? בנושא זה קיימות הצעות ושיטות רבות, חלקן מסובכות וחלקן פשוטות יותר. השיטות אינן קשורות ישירות ל- UML אלא לניתוח ועיצוב מונחה עצמים (OOA, OOD). קיימים מספר רב של מדדים אשר מאפשרים לנתח את מידת המורכבות של מודל האפיון והעיצוב ולהצביע על מודלים מסובכים מדי. דוגמא למדדים כאלה ניתן למצוא באתר של NASA המפנה למדדי איכות הקשורים לגישת האובייקטים (Object Oriented) ומדדים שימושיים נוספים. קישורים לאתרים אלה  מובאים בלשונית קישורים והפניות בקיט זה.

סיכום

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

גישת האובייקטים היא שיטה הרואה את המערכת כ- "אובייקטים" והקשרים ביניהם. מפת"ח, לעומת זאת, רואה את המערכת באופן יותר חיצוני ומעשי, בעיני המשתמש. בראייה אחרונה זו המערכת הייתה ונשארה ישות כוללת המורכבת ממסכים, תהליכים, קבצים, טבלאות, דו"חות וכו'. המסר העיקרי של שיטת OO היא שישויות אלה הן "אובייקטים" מסוגים שונים ושיש להגדירן תוך שימוש בעקרונות היסוד שלOO, שהם: חתימה ושדרים, כמיסה, הורשה, polymorphism ועוד. המסר העיקרי של מפת"ח הוא עץ המערכת, היינו חלוקת המערכת לרכיבים ברורים שאפשר ל"חוש" אותם והם ניתנים לכימות ולכריתת חוזה עם הלקוח. יש השלמה מעניינת וחיזוק הדדי בין שתי גישות אלה.