מדריך זה מכיל הנחיות מעשיות לשילוב גישת האובייקטים (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 אלה "מסתתרים" מאחורי כל מחלקה.
(2).jpg)
איור 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 - Unified Modeling Language היא שפה גרפית שנקבעה כסטנדרט בעולם האובייקטים. שפה זו תומכת בכל מחזור החיים של מערכת המידע וקובעת תוצרים ברורים לכל שלב בחיי המערכת. תוצרים אלה מוצגים כתרשימים (Diagrams). באמצעותה ניתן לדמות, לפרט, לבנות ולתעד את תוצרי התוכנה של מערכת מידע. UML מאפשרת להשתמש בשיטה סטנדרטית ליצירת אפיוני מערכת המכסים תהליכים עסקיים ופונקציות במערכת, כמו גם דברים מוחשיים כמו מחלקות (classes) הנכתבות בסביבת פיתוח מסוימת, סכימת בסיס הנתונים וקטעי קוד המיועדים לשימוש חוזר (reuse). יש לשים לב כי UML אינהמתודולוגיה. UML רק מגדירה את השפה שבה מכינים תוצרים במהלך מחזור החיים של פיתוח מערכת מידע אולם היא לא מגדירה ולא ממליצה על השיטה ורצף הפעילויות שיש לבצע כדי להשתמש באותה שפה. לשם כך פותחו מתודולוגיות רבות ומגוונות, שלכל אחת מהן יש יתרונות וחסרונות. כל ארגון המעוניין להשתמש ב- UML לאפיון ו/או עיצוב המערכת צריך גם לאמץ לעצמו מתודולוגיה ברורה אשר תגדיר מהו רצף הפעילויות שעל המנתח/מעצב לבצע בכל שלב במדויק. בהקשר זה מפת"ח מגדיר במידה רצף פעילויות כזה, ועושה "סדר בבלגן" באופן ראשוני, משום שהוא מגדיר איזה תוצר UML מומלץ להכין בכל שלב של מחזור החיים, והיכן יש לשלב אותו בעץ המערכת. לכן מפת"ח מהווה נוהל מסגרת ומתודולוגיית-על, אולם ההנחיות הכלולות בו אינן מהוות מתודולוגיה פרטנית ושלמה, מכיוון שהן לא כוללות הנחיות והמלצות מפורטות לגיבוש מסודר ושיטתי של התוכן של אותן דיאגרמות. להפניות למתודולוגיות לשימוש ב UML ראה פירוט בסוף מדריך זה.
מדריך זה מבוסס על מהדורה 1.1 של התקן. מהדורה 2.0 פורסמה לאחרונה ומכילה מספר חידושים (ראה פרק ההפניות והסימוכין בסוף המדריך לקישור לאתרים באינטרנט המכילים מידע באשר לשיפורים במהדורה 2.0).
במסגרת 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 מייצג פונקציונליות שלמה (אוסף פעילויות) מנקודת ראות של 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 הקשורים אליו.
.gif)
איור 2: Use Case diagram
Object הוא ישות עם זהות ותיחום מוגדרים היטב, הכוללת מצב והתנהגות כאשר, מצב מיוצג על ידי מאפיינים וקשרים ואילו התנהגות מיוצגת על ידי פעולות, שיטות ומכונת מצבים. אובייקט הוא מופע של מחלקה (ראה להלן).
Object diagram הוא תרשים המכיל אובייקטים והקשרים ביניהם בנקודת זמן. ניתן להתייחס אל תרשים אובייקטים כאל מקרה מיוחד של class diagram או של collaboration diagram (ראה להלן).
Class - מחלקה היא תיאור של קבוצת אובייקטים בעלי אותם מאפיינים, פעולות, קשרים והתנהגות. האובייקטים של אותה מחלקה הם בעלי אותו מבנה ואותה התנהגות. המחלקה הנה הגדרה מופשטת של אובייקט אשר מדגישה את המבנה, ההתנהגות והקשרים המשותפים. ההבדל בין האובייקטים השייכים לאותה מחלקה הוא רק במצב שלהם, ובזיהוי שלהם (השם שלהם).
Class diagram הוא תרשים בו משתמשים לתיאור Classes והקשרים בין Classes. להלן דוגמא:
איור 3: Class diagram
הקשרים בין המחלקות הם מהסוגים הבאים:
· קשרים תפעוליים/פונקציונאליים (Association) כגון הקשר "ספק - פריט" שפירושו: ספק מספק אחד או יותר פריטים ופריט ניתן לרכישה מספק מסוים.
· קשרי הכלה (Aggregation) כגון: "מפעל" או "קו-ייצור" השייכים לספק מסוים. נקראים גם Aggregation.
· קשרי הורשה (Inheritance) כגון: "ספק-אשראי" שהוא בן של "ספק" ומקבל בירושה את כל התכונות של הספק עליהן הוא מוסיף תכונות פרטיות שלו. סוג זה של קשר הוא ייחודי לגישת האובייקטים.
מתאר את רצף הפעילויות בתוך Use Case או בתוך Class diagram, מדגיש את גורם הזמן, מציג את קשרי הגומלין בין האובייקטים ומציג את קשרי הגומלין בין ה- Actors למערכת. משתמשים בתרשים זה לשני שימושים עיקריים:
· System Sequence Diagram - תרחיש בסיסי לאורך ציר הזמן של ה-Use Case. ניתן להשתמש לצורך זה גם ב- Activity diagram (מוסבר בהמשך).
· Sequence Diagram - תרשים מתקדם תוך לקיחת שיקולים עיצוביים נוספים מעבר לתרחיש הבסיסי. תרשים זה מראה את קשרי הגומלין בין האובייקטים ב- Class diagram.
.jpg)
איור 4: Sequence diagram
תרשים המתאר קבוצה של Classes, Interfaces ורכיבים אחרים ושיתוף הפעולה ביניהם. תרשים זה מדגישה את סוגי הקשרים ולא את רצף הזמן, למרות שגם בו ניתן להבין את רצף הזמן (באמצעות המספרים הצמודים לכל קשר).
.jpg)
איור 5: Collaboration diagram
תרשים פעילות / זרימה, המשמש לתיאור גרפי של תהליכים עסקיים (או"ש), Use Cases, או אלגוריתמים פנימי של אובייקט. התרשים משמש כתרשים זרימה (Flow Diagram) ומציג את הפעילויות (Activities) המבוצעות כאשר מבוצעת פעולה (Method) או אף Use Case שלם. כמו כן ניתן להציג בתרשים זה את הפעילויות לפי תחומי אחריות.
.jpg)
איור 6: Activity diagram
מציג את המצבים השונים של אובייקט ואת את השפעת אירועים שונים על המצבים. הוא נחוץ עבור ה- Classes בהם ישנם מצבים שונים ורבים, וכאשר נדרש לחדד את הכללים למעבר ממצב למצב (לפי הפעולות המופעלות).
.jpg)
איור 7: State chart diagram
Component (רכיב) הוא חלק פיזי בר החלפה של מערכת שניתן ליישום, המספק מענה ומימוש לקבוצת ממשקים. Component מייצג קטע פיזי של יישום ממערכת הכולל קוד תוכנה בינארי (לדוגמא: DLL ב-windows, או WebService בעולם האינטרנט).
Component diagram מציג אוסף של רכיביםואת הקשרים ביניהם. Component diagram הוא ההיבט הפיסי של Class diagram (כפי שאובייקט הוא ההיבט הפיסי של מחלקה שהיא דבר מופשט ולא קיים באופן מוחשי).
.jpg)
איור 8: Component diagram
מציג את הארכיטקטורה בזמן ריצה של מחשבים, ציוד היקפי ורכיבי תוכנה. התרשים מכיל בעיקר מחברים ורכיבים ברשתות מחשבים.
.jpg)
איור 9: Deployment diagram
הרחבה חשובה אחרת, אשר מסייעת רבות להפיכת גישת האובייקטים לשיטת עבודה מעשית, היא האבחנה בין סוגים שונים של אובייקטים. הכוונה לחלוקה של:
· אובייקטי מידע (Business Class) ואובייקטי בקרה (Control Objects)
· אובייקטי ממשק משתמש (מסכים) User Interface/Boundary Class))
· אובייקטי ממשק מערכת (ממשקים) Interface Class))
נהוג לחלק את המערכת לשלוש שכבות:
· שכבת הנתונים - DB Class
· שכבת העיבודים – Logical/Application Class
· שכבת הממשק למשתמש - UI Class
החלוקה לסוגי אובייקטים היא בעיקרה תפקודית ופונקציונאלית, היינו, חלוקה לפי תפקידו של האובייקט במערכת. במערכות מידע, יהיה מרכז הכובד, בד"כ, באובייקטי עיבוד המידע, אם כי כמובן שיש יוצאים מהכלל.
מודל הוא אוסף תרשימי UML המתייחסים לנושא או היבט מסוים של המערכת. המודלים בהם משתמשים במהלך חיי הפרויקט הם:
מודל המשמש להגדרת תיחום המערכת וחלוקתה לתת מערכות/פונקציות ראשיות (יחידות מסירה ללקוח) ומגדיר את התהליכים הארגוניים המציגים את הפעילות העסקית של המערכת, כאשר כל תהליך יכול לשקף פעילות רוחבית – של כמה מחלקות במערכת.
המודל משתמש בתוצרי UML כדי לתאר היבט או"ש של ניתוח התהליכים הארגונים במערכת.
בד"כ תוצרי המודל הם Activity diagrams כאשר כל פעילות בתוכם מתארת בסופו של דבר Use case אחד או יותר.
המודל מציג את משתמשי המערכת והפעילות שיבצע כל משתמש במערכת.
תוצרי המודל הם :
· רשימת משתמשים 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.
המודל מתאר את התרחישים שהוגדרו במערכת לפי ציר הזמן. תאור התרחיש כולל את הגדרת הפעילויות הנכללות בתרחיש מסודרות על ציר הזמן, את המחלקות המעורבות בביצוע התרחיש, ואת המסרים העוברים בין Classes השונים בעת ביצוע התרחיש.
תוצרי המודל הם :
· תרשימי Sequence Diagram.
· תרשימי Collaboration Diagram.
· תרשימי Activity Diagram.
מודל זה מתאר מיפוי של מחלקות לטבלאות. זו פעילות המתבצעת בשלב העיצוב וכוללת המרת מודל הנתונים (Class Diagram) לבסיס הנתונים (Tables, Columns, Relationship)
תוצרי המודל הם :
· תרשימי Storage Class Diagram.
· תרשימי Object Diagram.
השילוב המלא והברור בין עץ המערכת של מפת"ח ובין תוצרי UML מפורט בהרחבה בגלופות הלימוד והעבודה הנלוות למדריך זה. ראה לשונית 'תוצרים' בקיט זה. להלן, תיאור תמציתי (הבהקים) של שילוב זה:
בעיקרון, אין סיבה לשינויים מהותיים בפרק היעדים בשל גישת האובייקטים. יעדי המערכת נגזרים מיעדי הארגון ולא מטכנולוגיית המחשוב או במתודולוגית הפיתוח. עם זאת, ברור שתיתכן השפעה על יעדים משניים (שיפור התשתית בארגון), על עלות/תועלת המערכת, היתכנותה, אופק הזמן וכו'.
רכיב היישום הוא הרכיב המרכזי בו יש שוני בין מערכות OO/UML ובין מערכות מידע "מסורתיות". השוני מתמקד ברכיבים מרכזיים כגון: 2.2, 2.3, 2.5, 2.6, 2.7, 2.9, 2.11 ו- 2.22. בגלופת הלימוד יש הסבר ופירוט מלאים לרכיבים אלה. ההפניות היחידות, אם ישנן, ברכיבים אלה, הן "חזרה" למדריך זה או לגלופות מפורטות יותר בהתאמה לשלב בו נמצאת המערכת: גלופת תיק אפיון, תיק עיצוב, תיק מבדקים ותיק תחזוקה. ברכיבי יישום שאינם שונים ממערכות מידע "מסורתיות" תהיה הפניה לעץ מערכת רמה 3 בדומה לרכיבי היעדים, הטכנולוגיה, המימוש והעלות.
גישת האובייקטים, בניגוד לגישות ושיטות הנדסת תוכנה אחרות, לוותה כמעט מראשיתה בכלים מעשיים המסייעים לממשה בפועל. הכלי הראשון הוא שפות תכנות וקומפיילרים, אשר גם אם לא מכריחים את המשתמש לתכנת בדיוק לפי כל כללי ה- OOP, מכילים, הן בהגדרת הנתונים (האובייקטים) והן בפקודות את כללי התחביר ו"הדקדוק" של שפת ה- OO. דוגמאות לשפות OO הן: C++, Smalltalk, ADA ועוד.
טכנולוגית ה- CASE שהתפתחה בשנים האחרונות תומכת בגישת האובייקטים ויש כבר בשוק מספר כלים התומכים גם באפיון (OOA) וגם בעיצוב (OOD). חלקם מאפשר לנהל את כל מחזור החיים של פיתוח מערכת החל משלב האפיון וכלה בתכנות ובבדיקות.
ענף טכנולוגי אחר התומך בגישת האובייקטים הוא הממשק למשתמש. הממשקים הגרפיים המתקדמים, הפועלים בסביבת חלונות (Windows), בנויים על התפיסה של עבודה עם אובייקטים ופעולות שניתן לבצע עליהם. האובייקטים מזוהים עם צלמיות (icons) והשדרים הנשלחים אליהם הם אובייקט (צלמית) אחר או פעולה מתוך תפריט חלון (שדר). למשל, השמת הצלמית של מסמך על הצלמית של מדפסת, גורמת להדפסת המסמך. דוגמא טובה יותר, הפעלת הצלמית של המסמך מביאה (מעוררת) אותו, יחד עם תוכנת מעבד התמלילים בעזרתה נכתב המסמך. שימוש נפוץ אחר הוא בניית תוצר (תכנית, מסמך) ממספר אובייקטים עצמאיים: קטעי טקסט, קטעי גרפיקה, תמונות וכו', כאשר כ"א מביא אתו את כל המידע וההוראות הפנימיות שלו. חלק מתוכנות הממשקים עצמם (תוכנת הWindows -) נכתב בגישת האובייקטים.
ענף אחר הם בסיסי נתונים מכווני אובייקטים (OODBMS), שהמאפיין הראשי שלהם הוא אחסון התכנית (הקוד) יחד עם הקובץ (המידע). בסיס הנתונים הוא אמצעי ראשי למימוש תכונת ה- Encapsulation. בחלקם אלה בסיסי נתונים חדשים ובחלקם הם הרחבה של בסיסי נתונים טבלאיים קיימים.
רכיבי הטכנולוגיה בעץ המערכת נשארו כפי שהם, אולם התכנים יותאמו לאותם כלים מעשיים המלווים את גישת האובייקטים
אין סיבה לשינויים מהותיים ברכיבי המימוש והעלות, להוציא את ההשלכות שיש לעובדה שמדובר ב"מערכת חלוצה" - מערכת המפותחת בארגון שנחשף לפתוח מערכות מידע בגישה מונחית אובייקטים - או במערכות שעושות כבר שימוש חוזר בתשתית שהונחה לפניהם (מערכות משתמשות). כצעד ראשון, יש לזכור שרכיב זה הוא "סופר אורתוגונלי" ונגזר מרכיבים קונקרטיים חשובים. במילים אחרות, צריך לכמת תחילה את ה"עובדה" הנ"ל - מערכת חלוצה או משתמשת –ותרבות הפיתוח של הארגון לתוך רכיבים קונקרטיים, בעיקר טכנולוגיה, מימוש ועלות (בנוסף ל- 1.2 ו- 1.3) ולהגדיר היטב את ההשלכות על הגורמים המעורבים, תכנית העבודה, עלויות וכו'.
להנחיות נוספות ומפורטות לשילוב תוצרי UML בעץ המערכת ראה לשונית 'תוצרים' בקיט זה.
הטבלה שלהלן מציגה את השילוב שבין תוצרי 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 |
מתגלגל ומשתכלל |
|
.gif)
איור 10: תוצרי UML בשלבי הפיתוח
נושא אבטחת האיכות של תוצרי האפיון והעיצוב ע"פ שיטת UML הוא נושא מורכב מאוד. איך מגדירים האם האפיון או העיצוב טובים ואיכותיים? התשובה לשאלה זו היא מחוץ לתיחום קיט זה.
קיט זה עוסק באפיון ועיצוב לפי גישת מפת"ח ו- UML, ולכן השאלה הרלוונטית לנושא זה היא: מהם הקריטריונים לפיהם ניתן לבדוק האם תיק האפיון או תיק העיצוב אשר נכתבו ע"פ גישת UML הם טובים ואיכותיים?
התשובה פשוטה: לא משנה באיזו גישה נכתב התיק, עליו לענות על השאלות הבסיסיות שנדרש מתוצר תיעוד של המערכת. כל רכיב ורכיב בעץ המערכת צריך להיות מוגדר בהתאם למתואר בהנחיות מפת"ח המתאימות לשלב הנוכחי במחזור החיים של המערכת. יש לזכור ששפת UML היא רק שפה. היא אמצעי וכלי לתיאור המערכת מהיבטים שונים. התיאור המתקבל צריך להיות מובן, ניתן לעיצוב ופיתוח, ניתן לבדיקה וכו'.
נשאלת גם השאלה: האם יש מדדים המאפשרים למדוד את איכות תוצרי UML המופקים בשלב האפיון והעיצוב? בנושא זה קיימות הצעות ושיטות רבות, חלקן מסובכות וחלקן פשוטות יותר. השיטות אינן קשורות ישירות ל- UML אלא לניתוח ועיצוב מונחה עצמים (OOA, OOD). קיימים מספר רב של מדדים אשר מאפשרים לנתח את מידת המורכבות של מודל האפיון והעיצוב ולהצביע על מודלים מסובכים מדי. דוגמא למדדים כאלה ניתן למצוא באתר של NASA המפנה למדדי איכות הקשורים לגישת האובייקטים (Object Oriented) ומדדים שימושיים נוספים. קישורים לאתרים אלה מובאים בלשונית קישורים והפניות בקיט זה.
חשוב לחזור ולהדגיש את העובדה שמפת"ח הוא נוהל מסגרת (מתודולוגית-על) ולא מתודולוגיה פרטנית. יש יכולת ואף צורך לשלב את מפת"ח עם כלי CASE ועם מתודולוגיות אחרות המקובלות בארגון. הדבר נכון בפרט לגבי גישת האובייקטים (תקן UML).
גישת האובייקטים היא שיטה הרואה את המערכת כ- "אובייקטים" והקשרים ביניהם. מפת"ח, לעומת זאת, רואה את המערכת באופן יותר חיצוני ומעשי, בעיני המשתמש. בראייה אחרונה זו המערכת הייתה ונשארה ישות כוללת המורכבת ממסכים, תהליכים, קבצים, טבלאות, דו"חות וכו'. המסר העיקרי של שיטת OO היא שישויות אלה הן "אובייקטים" מסוגים שונים ושיש להגדירן תוך שימוש בעקרונות היסוד שלOO, שהם: חתימה ושדרים, כמיסה, הורשה, polymorphism ועוד. המסר העיקרי של מפת"ח הוא עץ המערכת, היינו חלוקת המערכת לרכיבים ברורים שאפשר ל"חוש" אותם והם ניתנים לכימות ולכריתת חוזה עם הלקוח. יש השלמה מעניינת וחיזוק הדדי בין שתי גישות אלה.