MDA ___ _____ _______ __ __________ by malj

VIEWS: 18 PAGES: 7

									        ‫‪ MDA‬עוד "שלוש אותיות" או מתודולוגיה שכדאי לאמץ?‬

                                                                               ‫1. מבוא‬
‫‪ - )1 ( )Model Driven Architecture( MDA‬מתודולוגיה קלה לאימוץ , המקיפה את כל מחזור החיים‬
    ‫. החל משלב הדרישות ועד לשלב הקידוד‬       ‫של מערכת מידע בסביבה מונחית אובייקטים ורכיבים‬
                                                                                 ‫והתחזוקה.‬
‫במאמר אציג את עקרונות המתודולוגיה – הנשענת על טכניקות וכלים שהוגדרו בתקן ‪ - UML‬והסיבות‬
                                                   ‫שבגללן כדאי לכל ארגון – גדול כקטן לאמצה.‬
‫יישום המתודולוגיה המתואר לעיל בוצע תוך שימוש בתוכנת ‪ Select Component Factory‬מבית ‪Select‬‬
                                  ‫‪ Business Solution‬אך המתודולוגיה מתאימה וניתנת למימוש –‬
                                   ‫בכל ארגון ללא תלות בתוכנת ה- ‪ Case‬הקיימת‬    ‫‪‬‬
                      ‫בכל פרוייקט – ללא תלות בשלב במחזור החיים בו הוא נמצא‬     ‫‪‬‬
‫בכל ארכיטקטורה שנבחרה בארגון לסביבות פתוח מונחות אובייקטים (כדוגמת ‪Visual‬‬      ‫‪‬‬
                                          ‫‪) MFC C++ ,C# ,Java ,Studio .Net‬‬


                                           ‫מתודולוגית ‪ MDA‬נשענת על במספר עקרונות בסיסים:‬
                                                 ‫חלוקת מחזור החיים לשלבים מוגדרים.‬        ‫א.‬
       ‫בכל שלב במחזור החיים מוגדרות המטלות שיש לבצע ומי אחראי לביצוע מטלות אלו.‬
                        ‫הפרדה בין שלב תכנון המודל העיסקי למאפייני סביבת הפיתוח .‬          ‫ב.‬
    ‫ההפרדה מאפשרת לממש את המודל העיסקי בכל סביבת פיתוח ובכל ארכיטקטורה שתהיה‬
                          ‫תקפה בזמן המימוש, להחליף בקלות גרסה ו/או סביבת פיתוח.‬
                                                    ‫כל שלב במחזור החיים מנוהל בנפרד .‬     ‫ג.‬
                            ‫כל שלב מסתמך על השלב הקודם ומרחיב את הנתונים שהיו בו.‬
  ‫המתודולוגיה מאפשרת שיוך נתונים שלב , ומוסיפה לכל נתון חיווי ויזואלי נמעיד על השלב‬
                                                      ‫במחזור החיים בו הוא נוסף למודל.‬



‫תקן למחזור החיים של מערכת מידע שפורסם על ידי ‪ – OMG‬הארגון שפרסם בין השאר את‬             ‫( 1)‬
                                                  ‫תקן ‪http://www.omg.org UML‬‬
                                                          ‫סנכרון (דו כיווני) בין המודלים.‬   ‫ד.‬
                                 ‫הסנכרון בין המודלים מתבצע בדרך כלל בשתי נקודות זמן:‬
 ‫הרלוונטים מהשלב הקודם לשלב‬        ‫בתחילת שלב בנקודת זמן זו מועתקים הנתונים‬        ‫‪‬‬
                                                                      ‫המתקדם.‬
  ‫בסיום שלב בנקודת זמן זו מסונכרנים השינויים שבוצעו בשלב המתקדם לגבי נתונים‬        ‫‪‬‬
                                                     ‫השייכים לשלב המוקדם.‬
‫הסנכרון מאפשר למשתמש לעבוד ‪ Top Down‬או ‪ ,Bottom Up‬ולהוסיף נתון חדש בכל נקודת‬
                                                                                   ‫זמן .‬


                                                   ‫שימוש בתבניות (‪. )Templates\Patterns‬‬     ‫ה.‬
‫תבנית היא תוכנית המופעלת בכל מצב בו קיים קשר בין נתונים שניתן להגדירו מראש . השימוש‬
                      ‫בתבניות משולב בכל מחזור החיים החל משלב האפיון ועד לחילול קוד .‬
‫כל התבניות – החל בסנכרון בין מודלים , דרך חילול שלד קוד ועד ביצוע בדיקות שלמות ונכונות‬
                 ‫המודל מופעלות לפי דרישה על ידי המשתמש, ומציגות את התוצאות מיידית.‬
  ‫שימוש מושכל בתבניות המשולבים במתודולוגיה יכול לחסוך עד %04 מזמן פיתוח הפרוייקט!‬

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

                         ‫)‪Computation Independent Model (CIM‬‬                     ‫2.1‬

                          ‫השלב הראשון המגדיר את הסביבה העיסקית של המערכת.‬
                                         ‫במסגרת השלב יבוצעו הפעולות הבאות:‬
                                                    ‫ניהול דרישות המשתמש‬      ‫‪‬‬
   ‫הגדרת התהליכים העיסקיים בהם תתמוך המערכת. ( ‪)Business Process Model‬‬       ‫‪‬‬
        ‫הגדרת משתמשי המערכת והשרותים שהיא תספק להם (‪)Use Case Model‬‬          ‫‪‬‬
                                              ‫בדיקות שלמות ונכונות המודל .‬   ‫‪‬‬
     ‫בין הבדיקות המומלצות בשלב זה מומלץ לא לוותר על בדיקת קיום הקשרים בין‬
                                    ‫דרישות, ‪ Business Process‬ו – ‪.Use Case‬‬
     ‫תוצאות הבדיקה יאשרו האם המערכת המתוכננת מתאימה לדרישות המשתמש.‬



                              ‫)‪Platform Independent Model (PIM‬‬                   ‫2.2‬

                              ‫השלב השני באמצעותו נבנה במודל הלוגי של המערכת.‬
                                          ‫במסגרת השלב יבוצעו הפעולות הבאות:‬
 ‫בניית מודל ‪( PIM‬בתחילת השלב - מודל ‪ PIM‬כולל בתוכו את הנתונים הרלוונטים‬      ‫‪‬‬
                                                     ‫שהוגדרו במודל ‪)CIM‬‬
                             ‫בניית המודל הסטטי של הנתונים (‪)Class Diagram‬‬    ‫‪‬‬
                                      ‫בניית תרחישי המערכת (המודל הדינמי (‬    ‫‪‬‬
  ‫הגדרת השרותים שהמערכת תחצין לסביבה ושמירתם בספריית הרכיבים הארגונית.‬       ‫‪‬‬
     ‫איתור שרותים המתועדים בספריה המסופקים על ידי מערכות אחרות הנדרשים‬       ‫‪‬‬
                                                 ‫לתפעול תקין של המערכת.‬
         ‫הגדרת פערים ותיעוד דרישות לשרותים ממערכות אחרות ותיעודם בספריה.‬     ‫‪‬‬
                                               ‫בדיקת שלמות ונכונות המודל .‬   ‫‪‬‬
‫–‪Use Case‬‬   ‫‪ CIM‬בנתוני דרישות , תהליכים עיסקיים ו‬    ‫סנכרון המודל עם מודל‬    ‫‪‬‬
                                                                  ‫שהשתנו.‬
                                      ‫)‪Platform Specific Model (PSM‬‬               ‫2.3‬
                                                                                        ‫‪‬‬
‫(‪ ) PIM‬שנבנה בשלב הקודם , לארכיטקטורה‬      ‫השלב השלישי המקשר בין המודל הלוגי‬
                                            ‫ולסביבת הפיתוח בה ימומש הפרוייקט.‬
      ‫במידה ואותו פרוייקט ימומש במספר סביבות פיתוח, ייבנה לכל סביבה מודל ‪. PSM‬‬
                                            ‫במסגרת השלב יבוצעו הפעולות הבאות:‬
 ‫בניית מודל ‪( PSM‬בתחילת השלב - מודל ‪ PSM‬כולל בתוכו את הנתונים הרלוונטים‬       ‫‪‬‬
                                                      ‫שהוגדרו במודל ‪.)PIM‬‬
                            ‫הפעלת תבניות להתאמת המודל הלוגי לארכיטקטורה‬       ‫‪‬‬
‫כל תבנית מפעילה תוכנית המעתיקה / משנה את המודל הלוגי ויוצרת ממנו את המודל‬
                                                                   ‫הפיסי.‬
                                                                 ‫לדוגמא –‬
‫‪ ‬תבנית המוסיפה ל ‪ Class‬מתודות קבועות הנובעות מסביבת הפיתוח (‪, Get \Set‬‬
                                                          ‫‪)... Clone‬‬
‫‪ ‬תבנית המתאימה את המודל הלוגי למודל השכבות תוך ביצוע הפעולות הבאות:‬
       ‫לכל ‪ Package‬שהוגדר בשלב הלוגי ייבנו שלושה ‪ Package‬חדשים :‬
 ‫‪ Package‬המקורי בתוספת סיומת‬      ‫- ל- ‪ Package‬אחד ששמו יהיה כשם‬
    ‫‪ )Domain Model( DM‬יתווספו אובייקטים מקבילים לאלו שהיו ב-‬
 ‫‪ Package‬המקורי (עם תוספת האותיות ‪ DM‬לשמם) הכוללים רק ה-‬
                                                      ‫‪.Attributes‬‬
 ‫‪ Package‬המקורי בתוספת סיומת‬      ‫- ל- ‪ Package‬השני ששמו יהיה כשם‬
‫‪ , ) Data Access Layer (DAL‬יתווספו אובייקטים מקבילים לאלו שהיו‬
‫ב- ‪ Package‬המקורי (עם תוספת האותיות ‪ DAL‬לשמם) הכוללים רק ה-‬
                                                      ‫‪.Attributes‬‬


                                             ‫וכך הלאה , עד לבניית כל המודל.‬
                                 ‫בניית ‪ Class Diagram‬מתאים לארכיטקטורה.‬       ‫‪‬‬
                              ‫עדכון המודל בשיתוף ארכיטקט המערכת ו- ‪. DBA‬‬      ‫‪‬‬
                                ‫עדכון התרחישים בהתאם לאובייקטים החדשים.‬       ‫‪‬‬
                                                ‫בדיקת שלמות ונכונות המודל.‬    ‫‪‬‬
                            ‫חילול שלד קוד ושלד טבלאות הנתונים‬                     ‫2.4‬

‫השלב מחולל שלד קוד ושלד טבלאות בסיס נתונים רלציוני , הכוללים את הנתונים שנבנו‬
               ‫בשלב ה- ‪ ,Attributes( PSM‬מתודות וכל מה שנוסף באמצעות התבניות).‬
                                            ‫במסגרת השלב יבוצעו הפעולות הבאות:‬
‫חילול שלד קוד לסביבת הפיתוח שנבחרה – לדוגמא ‪,C# ,Java ,Visual Studio .Net‬‬     ‫‪‬‬
                                                                ‫או ‪. MFC C‬‬
          ‫חילול שלד בסיס נתונים לסביבה רלציונית דוגמת ‪. SQL Server , Oracle‬‬   ‫‪‬‬



                                 ‫השלמת הקוד ובניית בסיס הנתונים‬                   ‫2.5‬

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


                                                           ‫בדיקות מערכת‬           ‫2.6‬

‫בשלב זה ייבנה אוטומטית שלד של תסריטי בדיקה הנשען על תאור התרחישים שנבנו בשלב‬
                                                                      ‫ה- ‪. PIM‬‬
 ‫ביצוע הבדיקות נמצא מחוץ לתיחום המתודולוגיה וצוות הבדיקות יבדוק את המערכת בכל‬
                         ‫כלי בדיקה הקיים בארגון וישלים את תסריטי הבדיקה כנדרש.‬
             ‫בדיקת המערכת מול התכנון מאפשר לגלות אי התאמות בין התכנון לביצוע.‬


                                                                                        ‫‪‬‬

                                                            ‫העברה לייצור‬          ‫2.7‬
                                                                                        ‫‪‬‬
                    ‫שלב העברה לייצור מהווה אבן דרך מתודולוגית לסנכרון המודלים.‬
          ‫עם העברת המערכת לייצור, יידרש מנהל הפרוייקט לשלב את הפעולות הבאות:‬
                 ‫סנכרון ( באמצעות ‪ ) Reverse Engineering‬בין הקוד למודל ‪PSM‬‬    ‫‪‬‬
                                             ‫סנכרון בין מודל ‪ PSM‬למודל ‪PIM‬‬    ‫‪‬‬
                     ‫עדכון ספריית הרכיבים בשרותים שהמערכת מספקת לסביבה.‬       ‫‪‬‬
                        ‫עדכון הדרישות בין מערכות המתועדות בספריית הרכיבים.‬    ‫‪‬‬



           ‫בניית תיק תחזוקה כבסיס לשינויים ומהדורות נוספות‬                        ‫2.8‬
‫על פי המתודולוגיה, המונח תיק התחזוקה מתייחס למודל ‪ PIM‬המעודכן, הכולל את התכנון‬
               ‫והשינויים שחלו במודל ומשמש בסיס לעדכוני המערכת וגרסאות חדשות.‬
                                                                     ‫המודל‬
       ‫שינוי בדרישה קיימת בשלב התחזוקה מאפשר למנהל הפרוייקט לדעת מיידית איזה‬
 ‫תרחישים ואילו אובייקטים ומתודות בתוך התרחישים יושפעו מהשינוי ולהעריך נכונה את‬
                                         ‫עלות השינוי ולוח הזמנים הנדרש למימושו.‬




                                                                 ‫3. מה השתנה?‬
  ‫השינוי המהותי במתודולוגיה המתוארת לעיל לא מתייחס רק להגדרת השלבים במחזור החיים ולהגדרת‬
                                                                ‫המודלים המבוצעים בכל שלב.‬
                                                                   ‫השינוי המהותי מתבטא ב –‬
                                                       ‫העלאת חשיבותו של מודל ‪PIM‬‬     ‫‪‬‬
        ‫מודל ‪ PIM‬מתעדכן בכל אבן דרך , ומשמש לאחר העברה לייצור כתיק תחזוקה לעבודה‬
                                                                           ‫שוטפת.‬
          ‫אם יש ל שנות את סביבת הפיתוח ניתן לחולל מיידית מתוך המודל שלד קוד לסביבה‬
                                                                           ‫החדשה.‬
                       ‫מיסוד הקשרים בין ובתוך המודלים ובין המודלים לסביבת הפיתוח.‬    ‫‪‬‬
                                               ‫הפעלת התבניות לאורך כל מחזור החיים.‬   ‫‪‬‬
                       ‫בדיקות איכות ושלמות המודל מתבצעות בכל שלב של מחזור החיים.‬     ‫‪‬‬
‫להדגשת חשיבות הקשרים לתבניות להלן דוגמא חלקית לקשרים , תבניות ובדיקות לשלבי‬
‫האפיון הלוגי (התבניות לשלב הקידוד נסקרו בסעיף 3.2) השימוש בתבניות חוסך זמן ומעלה‬
                                                               ‫את איכות הפתרון .‬



                                                                         ‫בשלב ה- ‪CIM‬‬
                                                        ‫קשר בין דרישה לתהליך עיסקי‬   ‫‪‬‬
‫חשיבות הקשר – לוודא שהמערכת עונה לדרישות המשתמש ( אם קיימת דרישה , ולא ניתן‬
 ‫להצביע על תהליך עיסקי הממש אותה , ניתן להסיק כי המערכת המתוכננת לא עונה לצפיות‬
                                                                       ‫המשתמש).‬
                                            ‫תבנית המחוללת ‪ Use Case‬מתהליך עיסקי‬      ‫‪‬‬
‫התבנית הופכת את המשתמש העיסקי ל- ‪ ,Actor‬מוסיפה למילון הנתונים ‪ Use Case‬בשם‬
‫זהה לתהליך העיסקי , מקשרת בין ה- ‪ Use Case‬והתהליך העיסקי , ובסיום בונה את תרשים‬
                                                              ‫‪.Use Case Diagram‬‬
                                               ‫בדיקת קשר בין הדרישות ל – ‪Use Case‬‬    ‫‪‬‬
‫הקשר בין הדרישות ל- ‪ Use Case‬נבדק משתי קצות הקשר – הבדיקה מצד הדרישה יכולה‬
‫‪ Use Case‬מגלה האם‬     ‫לגלות האם המערכת עונה לדרישות המשתמש , והבדיקה מצד ה-‬
                 ‫המשתמש לא הרחיב את תיחום המערכת מעל ומעבר לדרישות המשתמש.‬


                                                                              ‫בשלב ה- ‪PIM‬‬
                                                           ‫קשר בין ‪ Use Case‬ותרחיש‬     ‫‪‬‬
                               ‫הקשר מוודא את שלמות המודל ומזהה תרחישים חסרים‬
                  ‫תבניות המעתיקה את תאור ה- ‪ Use Case‬למשפטי עברית מבנית בתרחיש.‬        ‫‪‬‬
                             ‫בדיקה שכל ‪ Public Operation‬משתתף לפחות בתרחיש אחד.‬        ‫‪‬‬
    ‫מצביעה על כך כי השרות יופעל על ידי מסר המגיע‬   ‫הגדרה של ‪ Operation‬כ-‪Public‬‬
                                                                   ‫מאובייקט אחר.‬
  ‫העובדה שה- ‪ operation‬לא מופיע אפילו בתרחיש אחד, מעידה על פערים בתכנון המערכת.‬




                                                                          ‫4. תועלות‬
                                                                                           ‫‪‬‬
‫‪Select‬‬   ‫‪ ,MDA‬הרחבות ועידונים שנוספו על ידי חברת‬       ‫המתודולוגיה המוצגת לעיל כוללת את תקן‬
‫‪ Business Solution‬כתוצאה מהפקת לקחים ביישום המתודולוגיה בפרוייקטים בעולם והתאמות "לרוח‬
                       ‫הישראלית " שביצעה חברת די. פי. אס . תוכנה ומתודולוגיה ללקוחותיה בארץ.‬
                               ‫– מכאן שלפניכם מתודולוגיה מעשית המלווה בעזרי הדרכה והטמעה.‬

                                                   ‫המתודולוגיה תורמת לארגון בתחומים הבאים -‬
                                                                ‫חסכון משמעותי בזמן‬     ‫‪‬‬
                                  ‫חלק ניכר מהעבודה מתבצע אוטומטית בעזרת תבניות.‬
                                     ‫שימוש בתבניות יכול לחסוך עד %04 מזמן הפיתוח.‬
                                                                ‫שיפור איכות התוכנה‬     ‫‪‬‬
                                             ‫שיפור איכות התוכנה מושג בשתי דרכים:‬
                        ‫באמצעות הבדיקות המבוצעות בכל שלב של תכנון המערכת‬      ‫‪o‬‬
                    ‫בשימוש בתבניות המתאימות את המודל הלוגי לסביבת הפיתוח.‬     ‫‪o‬‬
                                                                ‫אינטגרציה בין מערכות‬   ‫‪‬‬
                                    ‫סטנדרטיזציה במונחים, במבנה התיעוד ובמבנה הקוד.‬     ‫‪‬‬
                                                                         ‫העברת ידע.‬    ‫‪‬‬

								
To top