השלב הראשון בעיצוב (תכן) המודול אותו עלינו לממש הוא שלב החלוקה לאובייקטים.
בשלב זה נזהה:
- את היישויות (Entities) שיש לנו במערכת
- את התחומים אליהם מתחלקת המערכת שלנו ונגדיר "מנהל" על כל תחום
שים לב!
אין מדובר כאן על תכנון מחלקה או שתיים לצורך תוכנית קטנה שאמורה לבצע דבר ספציפי.
אנו מדברים על עיצוב מערכת שאמורה לממש מספר רב של תהליכים שחלקם טרם הוגדרו עד הסוף. לכן, שלב העיצוב אינו מוכוון תהליכים אלא מוכוון יישויות ורכיבים שיהיו "אחראים" על תחום מסוים. אם נחלק נכון את הרכיבים שלנו, נוכל מאוחר יותר "להלביש" את התהליכים על האובייקטים ללא קושי.
דוגמא - מחשוב דלפק חלוקת ציוד סקי באתר החרמון
זהו עולם התוכן שלנו. שימו לב - אין מדובר בתוכנית קטנה שתחשב כמה גולשים עברו בדלפק במשך השבוע אלא במערכת שתנהל את הדלפק על כל התהליכים המתבצעים בו.
כמובן שאין ביכולתנו לעצב על בסיס הכותרת הנ"ל. ניגש לשלב העיצוב רק לאחר שקיבלנו תיק ניתוח המפרט את התהליכים הנדרשים למימוש במערכת וכך יהיה לנו מושג טוב יותר לגבי מה אנו נדרשים לממש. לצורך הדוגמא, ניקח שני תהליכים מרכזיים המתרחשים בדלפק: השכרת ציוד (מכל סוג)וקבלה/הסרה של ציוד למלאי/מהמלאי.
מיהו המשתמש במקרה זה? (Actor)
המשתמש הוא אותו עובד בדלפק שקיבל סנובורד חדש ומבקש להוסיף אותו ולמאגר הציוד. מקובל במערכות גדולות להגדיר גם רכיב שינהל את משתמשי המערכת מבחינת הבקרה על הכניסה למערכת ועל הסיסמאות עפ"י כללי הארגון. בדוגמא שלנו לא נתעכב על רכיב זה אך חשוב שתדע על קיומו.
אם כן, מהם היישויות והתחומים בעולם התוכן של ניהול הדלפק?
- רכיב תצוגה - CDisplay
רכיב שיימצא בצורה כזו או אחרת בכל מערכת עם MMI - ממשק אדם מכונה. רכיב זה יהיה אחראי על ניהול התצוגה אל מול המשתמש, הצגת טפסים, ניהול החלונות המוצגים במערכת חלונאית וכו'. רכיב זה (שינהל עוד רכיבים רבים של טפסים ותצוגות) ינתב את הפעולות שהמשתמש מבקש לבצע אל רכיבי הלוגיקה עצמם. - רכיב גישה לבסיס הנתונים - CDBExecuter
עוד רכיב שיימצא בצורה כזו או אחרת בכל מערכת עם מידע המנוהל מאחוריה. רכיב זה יהיה המקשר בין רכיבי הלוגיקה לבין בסיס הנתונים וייצא שגרות כתיבה וקריאה מבסיס הנתונים. - רכיב מנהל הציוד - CEquipMgr
הנה המנהל הראשון שלנו בשכבת הלוגיקה - מנהל הציוד האחראי על כל תחום תחזוקת הציוד, קליטת ציוד למלאי והסרתו. כשנקבל תהליך למימוש כגון מסירת ציוד לתיקון - נוסיף שגרה לרכיב זה.
בשלב זה, מחולקת המערכת שלנו לרכיבים, אובייקטים ומחלקות המחולקים עפ"י תחומי אחריות עליהם הם ממונים.
זיהוי השגרות של רכיבי התוכנה אינו תהליך רצוף וחד פעמי כמו החלוקה לרכיבים. זהו תהליך שניתן להגדירו ספירלי שכן זיהוי שגרות מתבצע במסגרת עיצוב כל תהליך במערכת (Use Case).
פונקציות הן כלי חשוב מאוד לחלוקה של הסיבוך בתוכנה. כשאתה חושב על כמה יהיה קשה לתוכניתן להבין קטע אתה צריך לזכור שלפקודה בודדת אין משמעות מבחינת התוכנית. מצד שני, רצף של הרבה פקודות אולי מבטא קטע לוגי מאוד משמעותי, שקשה לפענח אותו.
פונקציה מאפשרת לך לכתוב שורה אחת שתהיה משמעותית מאוד בהקשר של התוכנית, ותבצע קטע לוגי שלם. מבחינת קריאות, זה אידיאלי. המשמעות של זה היא ששימוש מושכל בפונקציות יכול להיות גורם מאוד חשוב בקריאות התוכנית שלך.
- שגרה צריכה לבטא קטע לוגי
מה זה אומר? זה אומר ששגרה צריכה לבצע פעולה שלמה. כלומר, אם יש זוג שגרות שתלויות אחת בשניה, ככה שקוראים להן תמיד אחת מיד אחרי השניה, יש סיכוי טוב שצריך לאחד אותן, כי הן לא שלמות לבד. שגרה שמרימה כדורעף להגשה ולא חובטת בו היא לא שלמה.- שגרה צריכה לבצע פעולה אחת
צורה פשוטה לבדוק את זה - שם השגרה צריך לבטא פעולה בודדת ומוגדרת היטב, ומצד שני, השגרה לא צריכה לעשות כלום שלא קשור לאותה פעולה. שגרה שמבצעת קלט של מספר למשתנה ומוסיפה לו 2 לא מבצעת פעולה אחת מוגדרת היטב. אם שגרה מבצעת פעולה מורכבת, שתקרא לשגרות נוספות שמבצעות פעולות פשוטות יותר. - שגרה צריכה לבצע פעולה אחת
נחזור לאתר החרמון.
אחרי שזיהינו את שלושת הרכיבים הנ"ל, נראה כיצד הם משתלבים בתהליך שנדרשנו לממש - תהליך הוספת סנובורד למאגר הציוד:
CDisplay יפנה אל CEquipMgr ויקרא לשגרה המתאימה למה שהמשתמש ביקש לבצע - הוספת סנובורד. והנה זיהינו שגרה - (...)CEquipMgr.AddSkiItem.
מה יופיע בתוך הסוגריים? כאן יופיע פרמטר שמייצג את האובייקט שנרצה להוסיף למאגר. יכול להופיע כאן כל סוג של ציוד סקי - מגלש סקי, סנובורד וכו', ואלה גם יהיו היישויות שלנו.
זהו אוביקט מסוג יישות (Entity) - הדבר העיקרי המבדיל יישות מאובייקט אחר הוא העקרון שליישות אין שגרות - רק מידע. סנובורד אינו יודע לבצע פעולות במערכת ואין בו לוגיקה.
למשל, הגדרת שגרה כגון CSnowboard.RepairSnowboard היא שגיאה וערבוב מין שבאינו מינו.
בשלב זה נדרש המעצב לקבל החלטה - האם להגדיר שגרה אחת כפי שעשינו שתטפל בכל הוספת ציוד הסקי או שגרה נפרדת לכל סוג פריט סקי. נכנסים כאן שיקולים כגון צימוד (Coupling) ושימוש חוזר (Code Reuse) אותם נלמד בהמשך הפרק.
בשלב זה רק נגיד שאין החלטה נכונה ולא-נכונה. שוקלים את השיקולים לכאן ולכאן ולבסוף מבצעים סקר עיצוב שבו דנים על ההחלטה שלנו ומאשרים אותה.
מרגע שנקראה השגרה של הוספת הפריט, באחריותה לסיים את התהליך כולו - קבלת מספר סידורי לפריט, שמירה לבסיס הנתונים וכל מה שיוגדר בתהליך ע"י הניתוח.
לשם מה נדרשת לרכיב מנהל הציוד גישה לבסיס הנתונים?
- לשם כתיבה של הפריט החדש לבסיס הנתונים.
- לשם בדיקה אם הפריט לא קיים כבר במאגר.
- לשם ביצוע בדיקות תקינות נוספות מול בסיס הנתונים.
מערכת תוכנה לא תידרש בדרך כלל לתת פתרון רק לתחום מצומצם כמו דלפק חלוקת ציוד סקי. בדרך כלל המערכת תידרש לנהל את כל האתר מכל הבחינות - תשלומים, תחזוקת מסלולים, ניהול הסעות, ניהול השיווק והפרסום וכו'. מחשוב דלפק חלוקת ציוד הסקי יהיה רק תת-מערכת בתוך המערכת הגדולה.
גולשים מקוונים: 7