תיכון מונחה עצמים

11שעור

חשיבות התכנון הנכון

סעדו-שחר אסתר כהן1

מדריך מעשי לפיתוח תוכנה בהוצאת הוד עמי Code completeהשיעור מבוסס על הספר

מאפיינים של תכנון וכתיבת תוכנה איכותית

הבנה של כלי הפיתוח.

הבנה של תהליך תכנון התוכנה.

הבנה של הדרך בה הקוד מייצג את המציאות.

הבנת מחזור החיים של הקוד והתוכנה.

הבנה של האופן בו כתיבת הקוד משפיעה על התחזוקה העתידית שלו.

2

מאפיינים של כתיבת קוד טובה

קוד קריא ונוח לתחזוקה.

קוד נכון שעושה את מה שהוא צריך לעשות.

בתהליך התכנון והכתיבה ישנו ניצול נכון של הזמן.

הצוות עובד בצורה יעילה ובשיתוף פעולה.

הצוות קשוב למה שקורה בזמן הפיתוח ומוכן להסיק מסקנות להמשך

.ולפיתוח עתידי

3

תכנון תוכנה

עבודת תכנון(Design )הינה חלק מהותי מבניית מכלול התוכנה.

תכנון יכול להיות כתיבת פסאדו קוד של המחלקה.

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

בחירת תבנית תיכון (Design Pattern)

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

.של המערכת

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

המשמעות של תכנון תוכנה היא פיתוח סכימה שבאמצעותה ניתן יהיה

.להפוך את המפרטים המתארים את התוכנה לתוכנה מתפקדת

תכנון מקשר בין מפרט הדרישות לבין כתיבת הקוד בפועל.

4

אתגרי תכנון תוכנה

צריך , בעיה שכדי להגדיר אותה במדויק : בעיה מרושעת"התכנון הוא

כדי להתמודד עם בעיה כזו צריך . לפתור אותה במלואה או לפחות בחלקה

לפתור אותה במלואה פעם אחת על מנת להגדיר אותה במדויק ואז לפתור

.אותה שוב כדי להפיק פתרון עובד

התוצאה הסופית של תהליך תכנון התוכנה : התכנון הוא עניין מבולגן

גם .צריכה להיות מסמכים מסודרים אבל התהליך עצמו אינו מסודר

שגיאות הן חלק מתהליך התכנון וגילוי השגיאות במהלך התכנון זול יותר

.מגילוי שלהן במהלך כתיבת התוכנה

.התכנון אינו מוגבל מבחינת היקף אך הוא מוגבל בזמן

5

אתגרי תכנון תוכנה

חלק חשוב של עבודת : תכנון הוא עניין של חלופות וסדרי עדיפויות

.התכנון הוא שיקול והערכה של אילוצים מהעולם האמיתי

.יילקחו שיקולים שונים בבניית המערכת, בהתאם לצרכים

תכנון הוא תהליך שבחלקו פותר בעיות : תכנון כולל יצירת מגבלות

בסופו ( כגון משאבים או זמן פיתוח) מגבלות אלו . ובחלקו יוצר מגבלות

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

כל מתכנן מערכת יכול לתכנן אותה : תכנון הוא תהליך לא דטרמיניסטי

. בצורה שונה

י מספר אנשים כך שכל תכנון "אותה המערכת תתוכנן בצורה שונה ע

.עשוי להיות קביל לחלוטין6

אתגרי תכנון תוכנה

שיטות התכנון הינן לא (: לא מוחלט)תכנון הוא תהליך היוריסטי

. אין זה תהליך שניתן לחזור עליו ולקבל תוצאות צפויות מראש. מוחלטות

.התכנון מבוסס לעיתים על ניסוי וטעייה

ואין כלי שמתאים לכלל . שיטות מסוימות מתאימות לפרויקטים מסוימים

.הפרויקטים

תכנון מתפתח כתהליך שכולל בחינה ושינוי : תכנון הוא תהליך מתפתח

.והרצת התוכנהבדיקת הקוד , כתיבת קוד, דיונים , של תכנון קודם

7

שני סוגי קשיים בתכנון תוכנה

התכונות המובנות של תוכנה הינן התכונות הבסיסיות : קושי מובנה

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

.וכדומה

תכונות מקריות הן תכונות שעשויות להשתייך למוצר מסוים : קושי מקרי

למכונית יכולות להיות . אך הן אינן משפיעות על היותו שייך לסוג מסוים

.דלתות אך זו עדיין מכונית4דלתות או 2

8

קושי מובנה–שני סוגי קשיים בתכנון תוכנה

משימת פיתוח תוכנה הינה הבנה ופענוח של הפרטים הקשורים למערכת

.הפרטים משולבים זה בזה ומורכבים. המפותחת מרעיון

קושי בזיהוי קשרי גומלין בין ישויות

זיהוי מקרים חריגים בצורה מלאה.

על הצרכים" בערך"הפיתרון המעוצב צריך להיות מדויק ולא לענות.

קשה לנתח איך פועל ומתפקד העולם האמיתי .

קשרי הגומלין בין הישויות מורכבים יותר , ככל שהבעיה מורכבת יותר

.וכך גם הפיתרון

לא ניתן למצוא שפת תכנות או תוכנה מובנית שתמצא לנו פיתרון לקושי

.זה

9

קושי מקרי–שני סוגי קשיים בתכנון תוכנה

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

(Brooks.)

קשיים מקריים יכולים להיות קשורים למבנים מסורבלים בשפת תכנות–

.נפתרו באמצעות שפות מונחות עצמים

נפתרו עם התפתחות מערכות -פעולות אינטראקטיביות עם המחשב

.הפעלה מתקדמות

קיימות סביבות פיתוח משולבות-שילוב כלים בצורה טובה.

קיימות אפשרויות רבות לטיפול בבעיות מסוג זה-שילוב בין מערכות.

10

תכנון מורכבות

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

פרויקט נכשל מבחינה טכנית כאשר מורכבות הפרויקט והתוכנה יצאה

כ שאף אחד לא יודע לומר בוודאות "משליטה והתוכנה הפכה למורכבת כ

.מה היא עושה או איך היא פועלת

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

מומלץ לעצור את התקדמות , קוד במקום אחד על מקומות אחרים

.הפרויקט

ניתן להתמודד עם מורכבות של מערכת באמצעות:

(.מודולריות)חלוקת המערכת לתת מערכות

הגדרת אובייקטים בצורה ברורה.

הגדרת פונקציות קטנות.

קוד קל יותר להבנה מכיל פחות שגיאות.11

מאפיינים של תכנון מוצלח

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

.בחלקים של הבעיה עד ליצירת פיתרון כולל

תכנון המערכת כך שתהיה מובנת גם למתכנתים אחרים : קלות תחזוקה

.לצורך תחזוקה

תכנון מחלקות שיש בניהן . קשרים רופפים בין חלקי תוכנה:צימוד רופף

קשרי גומלין מעטים ככל האפשר תוך שימוש בעקרונות כימוס והסתרת

.מידע

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

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

.במערכת

שימוש חוזר בחלקי קוד:פתיחות לשימוש מחדש.

מספר גדול של מחלקות משתמשות במחלקה : שימוש של רבים ביחיד

קיימות מחלקות הנותנות שירות ונמצאות ברמות הנמוכות של . נתונה

.המערכת12

מאפיינים של תכנון מוצלח

מחלקה משתמשת במספר נמוך של מחלקות :שימוש של יחיד ברבים

הדבר , ככל שהמחלקה משתמשת במספר גבוה יותר של מחלקות . אחרות

.מעיד על מורכבות גבוהה

תכנון המערכת כך שניתן יהיה בקלות להעביר אותה לסביבת :ניידות

.עבודה אחרת

מערכת ללא חלקים מיותרים": רזה"מערכת.

התבוננות על המערכת ברמה מסוימת תוך קבלת תמונה : ארגון בשכבות

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

.שלה מבלי להיכנס לרמות נמוכות יותר

שימוש בגישות וטכניקות מקובלות ומוכרות מקנה :טכניקות סטנדרטיות

.למתכנת תחושת ביטחון

13

רמות תכנון של תוכנה

תכנון מערכתי–1רמה:

.תכנון המערכת כולה

14

חלוקה לתת מערכות–2רמה -רמות תכנון של תוכנה

חלוקה לתת מערכות או חבילות-2רמה :

זיהוי תת המערכות המרכזיות במערכת.

ברמה זו תבוצע חלוקה של המערכת לתת מערכות או חבילות ויקבע

.הקשר בין תתי המחלקות

אם כל תתי . יש חשיבות לאופן בו תת המערכות מתקשרות ביניהן

. עיקרון ההפרדה הלך לאיבוד, המערכות מתקשרות עם כל תתי המערכות

יש להגביל את התקשורת בין תת המערכות.

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

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

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

תת מערכת אחת מכילה מחלקות של תת מערכת אחרת-קשר הדוק.

תת מערכת אחת מכילה מחלקות היורשות ממחלקות -קשר הדוק ביותר

.בתת מערכת אחרת 15

חלוקה לתת מערכות–2רמה -רמות תכנון של תוכנה

16

חלוקה לתת מערכות–2רמה -רמות תכנון של תוכנה

17

חלוקה לתת מערכות–2רמה -רמות תכנון של תוכנה

צריך . עיקרון מוצלח בתכנון תתי מערכות הוא שמירה על גרף לא מעגלי

משתמשת Bמחלקה , Bמשתמשת במחלקה Aלהימנע ממצב בו מחלקה

.Aמשתמשת במחלקה Cומחלקה Cבמחלקה

תתי מחלקות נפוצות:

המדיניות והתקנות הקשורים לתוכנה , החוקים : כללים עסקיים

.המפותחת

חלונות, תפריטים, שורות פקודה, ממשק גרפי: ממשק משתמש ,

.מערכת עזרה וכדומה

הסתרת המימוש של הגישה לבסיס : גישה לבסיס הנתונים

.הנתונים כך שהמחלקות יוכלו לטפל בניהול המידע בלבד

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

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

.בהעברת התוכנה לעבודה בסביבות שונות18

חלוקה למחלקות-3רמה -רמות תכנון של תוכנה

זיהוי של כל המחלקות במערכת.

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

מחלקות להגדרה של ,מחלקת שמירת נתונים, מחלקת גישה לבסיס נתונים

.מבנה הנתונים

קביעת יחסי הגומלין בין המחלקה לחלקי התוכנה האחרים.

קביעת הממשק בין מחלקות.

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

.מימוש שלהן למחלקות

עיקרון מפתח בתכנות מונחה עצמים הוא ההבדל בין מחלקה ואובייקט :

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

האובייקט הוא המופע של המחלקה בזמן . הדבר הסטטי שמופיע בקוד

.ריצה

19

חלוקה לפונקציות-4רמה -רמות תכנון של תוכנה

חלוקה של כל המחלקות לפונקציות.

הממשק של המחלקה מרמה שלוש יוכל בחלק מהפונקציות.

חלק מהפונקציות הן פשוטות.

חלק מהפונקציות הן מורכבות וכוללות קריאות היררכיות לפונקציות

.אחרות ומחייבות תכנון נוסף

תהליך הגדרת הפונקציות תורם להבנת ממשק המחלקה ולעיתים לשינויים

.3ברמה

לעיתים רמה זו אינה מתוכננת בצורה פורמאלית אך היא חייבת להתבצע

.לפחות מבחינה מחשבתית ותכנונית

י המתכנת עצמו"כ רמה זו מטופלת ע"בד.

20

תכנון בתוך הפונקציות-5רמה -רמות תכנון של תוכנה

תכנון הפונקציונאליות של הפונקציה הבודדת.

י המתכנת האחראי לכתיבת הפונקציה"כ ע"מבוצע בד.

התכנון כולל:

כתיבת פסאדו קוד.

חיפוש אלגוריתם מתאים.

ארגון פסקאות הקוד.

כתיבת הקוד עצמו.

21

אבני הבניין של התכנון

אובייקטיםהגדרת

חזרה על התכנון.

רמת הפשטה אחידה

כימוס של פרטי המימוש

שימוש בהורשה

הסתרת מידע

זיהוי אזורים הצפויים לשינויים

צימוד רופף

תבניות תיכון

22

תכנון אובייקטים

תכנון הוא תהליך לא דטרמיניסטי ולכן שימוש בכלים שנצברו באמצעות

.ניסיון הוא חלק מתכנון תוכנה מוצלח

איתור אובייקטים מהעולם הממשי ואובייקטים מלאכותיים:

זיהוי אובייקטים והתכונות שלהם.

קביעת הפעולות שניתן לבצע על כל אובייקט.

כ "בד–קביעה מה כל אובייקט רשאי לעשות לאובייקטים אחרים

.הכלה או ירושה

מאפיינים ופונקציות-קביעת החלקים החשופים באובייקט.

הנתונים והפונקציות שהאובייקט -הגדרת הממשק של כל אובייקט

.חושף לעולם

23

חזרה על התכנון

בסיום התכנון של המערכת יש לבצע חזרה על רמות התכנון הגבוהות על

.מנת לארגן באופן טוב יותר את המחלקות

יש לחזור על התכנון של כל אחת מהמחלקות עד לרמת התכנון המפורטת

.ביותר

איטרטיביתהליך החזרה על התכנון הינו תהליך.

24

רמת הפשטה אחידה

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

ממשק טוב של מחלקה הוא ממשק שמאפשר לך להתמקד בו ולהתעלם

.מהאופן בו ממומשת המחלקה עצמה

ההפשטה מאפשרת התעלמות מפרטים לא רלוונטיים.

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

.'וכוגלגלים

25

כימוס של פרטי המימוש

הסתרה:כימוס.

עוזר בניהול מורכבות בכך שהוא מסתיר את מורכבות הפרטים.

כימוס פירושו שאתה יכול לקבל מבט פשוט על משהו מורכב ואינך רשאי

.להתבונן בפרטים המוסתרים

מה שאתה רואה הוא מה שאתה מקבל.

26

שימוש בהורשה לצורך פישוט התכנון

במערכת תוכנה קיימים אובייקטים דומים למעט תכונות מסוימות.

מחלקה מסוימת יורשת ממחלקה אחרת כך שניתן להוסיף :הורשה

.מאפיינים למחלקה היורשת

ירושה תומכת בעיקרון ההפשטה .

27

הסתרת מידע

חלק מהבסיס של תכנון מובנה ותכנות מונחה עצמים: הסתרת מידע .

המתכנת מסתיר החלטות תכנון ומימוש של חלק אחד מפני חלקי התוכנה

.האחרים

הסתרת מידע עוזרת בהסתרת המורכבות של התוכנה.

י הפרטים שהיא מסתירה ממחלקות אחרות "כל מחלקה מאופיינת ע

.בתוכנה

נסתיר חלקי קוד רגישים וחלקי קוד שיש צורך לבודד אותם על מנת

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

ממשק המחלקה צריך לחשוף כמה שפחות על הצורה שבה מתנהלים

.דברים בתוך המחלקה 28

דוגמא להסתרת מידע

יצירת מזהה ייחודי לרשומה.

במידה ונגדיר בכל מחלקה פונקציה המגדירה את הIDשל כל רשומה ,

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

ניתן להסתיר את מימוש יצירת הזיהוי בתוך פונקציתNewID()

בכל פעם שנרצה מספר לרשומה נקרא לפונקציהid=NewID()

כעת שינוי נדרש בהגדרות הזיהוי יגרור שינוי של פונקציתNewID()

.בלבד

29

זיהוי אזורים הצפויים לשינויים

היכולת להכיל שינויים היא אחת המטרות המאתגרות ביותר של תכנון

.תוכנה מוצלח

המטרה היא לבודד אזורים בתוכנה הנתונים לשינויים באופן כזה

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

מחלקה אחת או תת , נרצה ששינוי באזורים אלו יוגבל לפונקציה אחת

.מערכת אחת

הצעדים לזיהוי אזורים הצפויים לשינויים:

מפרט הדרישות צריך : זיהוי הנושאים בהם קיים סיכוי לשינוי

.לכלול גם רשימה של שינויים אפשריים

יש לבודד נושאים אלו : בידוד של נושאים הצפויים לשינויים

.למחלקות נפרדות

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

השינוי צריך להיות מוגבל למבנה הפנימי של המחלקה . לשינויים

.כך שהממשקים החיצוניים יישארו ללא שינוי30

שינויים אפשריים-זיהוי אזורים הצפויים לשינויים

הסכמי השכר עלולים , מבנה המס יכול להשתנות:כללים וחוקים עסקיים

.להשתנות

צריך לבודד את התלות . דיסק, מקלדת, ממשקים עם מסך:תלות בחומרה

בחומרה בתת מערכת או מחקות ייעודיות לכך כל ששינוי סביבת העבודה

. יהיה קל

כמו גם . קבצים המיוצאים מהתוכנה עלולים להשתנות:אמצעי קלט ופלט

.קבצים הנקלטים לתוכנה

כדאי להסתיר אותם מאחר והם יכולים :אזורים קשים לתכנון ולפיתוח

.להיכתב ברמה נמוכה

מומלץ לשמור קבוע . שינוי בגודל מערך רצוי:מגבלות על גודל הנתונים

.שיכיל את גודל המערך במקום לחשוף את גודלו בקוד

31

שמירה על צימוד רופף

המידה שבה מחלקה או פונקציה קשורה למחלקה או פונקציה : צימוד

.אחרת

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

בתכנון תוכנה ננסה ליצור מודולים שתלויים כמה שפחות במודולים

.אחרים

קריטריונים לצימוד:

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

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

.באמצעות פרמטרים נחשבת טובה

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

כך הצימוד רופף , ככל שמודולים יכולים לקרוא למודול בקלות רבה יותר

.יותר וזה חיובי

נרצה שהמערכת תהיה מחולקת כך שיהיו בה כמה שפחות קשרים. 32

חיפוש תבניות תיכון

פתרונות מוכנים מראש היכולים לסייע בפתרון בעיות : תבניות תיכון

.תכנון נפוצות

היתרונות בשימוש בתבניות תיכון:

י שימוש בדרכים סטנדרטיות לפתרון הבעיות"מפחיתות טעויות ע.

מציעות חלופות כך שניתן לבחון את הפיתרון הטוב ביותר לבעיה.

מאפשרות רמת הפשטה גבוהה יותר.

33

כלי תכנון נוספים

עד כמה המחלקה ממוקדת בנושא אחד: השתדל להשיג עקביות חזקה .

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

.המטרה היא להשיג עקביות חזקה

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

היא מכילה , את הייצוג המופשט של רעיון וככל שהרמה נמוכה יותר

.הרעיוןאותו ייצוגים מפורטים יותר של

הממשק הציבורי של מחלקה יכול : צור חוזי מחלקות מפורשים

להיחשב כחוזה עם שאר המחלקות כך שהמחלקה מתחייבת לספק נתונים

.מסוימים ומקבלת נתונים מסוימים

על מה יהיה . חלוקת תחומי אחריות לאובייקטים:קביעת תחומי אחריות

.אחראי כל אובייקט

תכנון המערכת כך שניתן יהיה לבדוק אותה בצורה :תכנן עבור בדיקות

.חכמה ויעילה34

כלי תכנון נוספים

תכנון התוכנה צריך להיות כזה שיאפשר זיהוי : המנע ממכשולים

.מכשולים אפשריים

אתחול הינו הזמן שבו משתנה מקבל ערך :בחר במודע את זמן האתחול

יש לתכנן את הפונקציות כך שזמן האתחול של המשתנים יהיה . מסוים

.המיטבי

פונקציות או אפילו , הגדרת מחלקות:צור נקודות שליטה מרכזיות

.קבועים שיהיו נקודות שליטה מרכזיות בתוכנית

לעיתים פתרון לא מחוכם יעיל יותר :שקול פתרונות לא מתוחכמים

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

מילים1000תמונה שווה :שרטוט דיאגראמות.

קופסא "הפיכת כל פונקציה ומחלקה ל: שמירה על תכנון מודולארי

.שבה ידוע מה נכנס ויוצא ממנה אך לא ידוע מה קורה בפנים" שחורה

35

קווים מנחים לשימוש בעקרונות תכנון שונים

שלבים בפתרון בעיות מתמטיות(POLYA ) היעילים גם בפתרון בעיות

:תכנותיות

האם לאחר מילוי הנתונים ? מהם הנתונים? מה הנעלם: הבנת הבעיה

?האם יש סתירות בנתונים? ניתן לפתור את הבעיה

מציאת בעיות . מציאת הקשר בין הנעלם והנתונים:בניית תוכנית

האם ניתן לשנות את . זיהוי האם נתקלנו בבעיה כזו בעבר. משנה

?הנעלם או הנתונים באופן שיביא לפתרון

ביצוע התוכנית תוך בדיקת כל שלב: ביצוע התוכנית.

האם ניתן לאמת את התוצאה. בחינה של הפתרון: הסתכל לאחור?

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

.חדשים

ניתן לפרק את הבעיה לתתי בעיות ולפתור כל אחת מהן , במידה ונתקעים

.בנפרד על לפתרון הבעיה הגדולה 36

נהלי תכנון

תכנון בסבבים.

הפרד ומשול

תכנון מלמעלה למטה ומלמטה למעלה

אב טיפוס ניסיוני

שיתוף פעולה בתכנון

37

תכנון בסבבים-נהלי תכנון

איטרטיביתכנון.

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

יש אפשרות לבחון את , כאשר מבצעים סבבים בין אפשרויות תכנון שונות

. התכנון הן ברמה הגבוהה והן ברמה הנמוכה

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

.הנמוכות יותר וההיפך

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

לעיתים פתרון הבעיה בצורה אחת יניב תובנות שיאפשרו לפתור את

.הבעיה בצורה שונה

38

הפרד ומשול-נהלי תכנון

צריך לפרק את התוכנה לתחומי עבודה שונים ולתקוף כל אחד מהם

.בנפרד

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

39

תכנון מלמעלה למטה ומלמטה למעלה

התחלה ברמות הפשטה גבוהות וככל ( פירוק:)תכנון מלמעלה למטה

הגדרת תתי . שהתכנון מתפתח יורדים לרמות הנמוכות יותר

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

.אחרים

מתחילים מהפרטים ועוברים לכיוון (הרכבה:)תכנון מלמטה למעלה

זיהוי אובייקטים כללים ואז , מתחילים מזיהוי אובייקטים מוגדרים. הכללה

.להגדרת מחלקות מתוך האובייקטים האלו

בפועל משתמשים בשילוב של שתי השיטות.

40

אב טיפוס ניסיוני

לעיתים לא יודעים אם תכנון מסוים יפעל כראוי עד שיודעים מספר

.פרטים על המימוש

כתיבת –טכניקה לפתרון בעיה זו בעלות נמוכה היא בניית אב טיפוס

החלק המינימאלי של קוד שנחוץ על מנת לענות על השאלה וברור שלא

.נשתמש בו לאחר מכן

בניית אב טיפוס מחייב שהשאלה תהיה מפורטת במלואה.

41

שיתוף פעולה בתכנון

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

מומלץ ליצור שיתוף פעולה בין מתכנני המערכת והמפתחים באופנים

:הבאים

שיתוף רעיונות.

שרטוט משותף של חלופות לפתרון הבעיה.

תכנות בזוגות.

ישיבות העוסקות ברעיונות התכנון.

י מתכנן המערכת"סקירה פורמאלית של העבודה המתבצעת ע.

התייעצות עם עמיתים מחוץ לחברה.

42

כמות התכנון

הדרושה

43

תיעוד התכנון

תיעוד נכון נעשה באמצעות מסמכים פורמאליים.

ניתן לתעד בנוסף גם באמצעים הבאים:

מבטיח . תיעוד החלטות תכנון מרכזיות בתוך הקוד: תיעוד בתוך הקוד

.שהתיעוד יהיה זמין למפתחים

WIKI :איסוף דפי אינטרנט שכל אחד בצוות יכול לערוך.

סיכום כל דיון יגרור סיכום בכתב והפצתו : סיכומים המופצים במייל

.במייל לכל הנוגעים בדבר

צילום לוח מחיק שעליו שורטטו :שימוש במצלמה דיגיטלית

.דיאגראמות

יצירת דיאגראמותUML : מתחילים בקווים כלליים ומוסיפים פרטים

.ככול שיורדים לפירוט התכנון

44