כלי עיצוב תוכנה
הוצג| English | משמעות |
|---|---|
| structure chart/ˈstrʌktʃə tʃɑːt/ | תרשים מבנה |
| state-transition diagram/steɪt trænˈsɪʃn ˈdaɪəɡræm/ | תרשים מעבר מצבים |
| pseudocode/ˈsuːdəʊkəʊd/ | קוד מדומה |
| decomposition/ˌdiːkɒmpəˈzɪʃn/ | פירוק |
| subroutines/ˈsʌbruːtiːnz/ | תת-תוכניות |
| parameters/pəˈræmɪtəz/ | פרמטרים |
| top-down design/tɒp daʊn dɪˈzaɪn/ | עיצוב מלמעלה למטה |
| states/steɪts/ | מצבים |
השנה שבה תוכנה הפכה להנדסה
- באוקטובר 1968, חמישים מתוכנני המחשב המובילים בעולם נפגשו בגרמיש, גרמניה, כדי לדון מדוע תוכניות גדולות נכשלות: מאוחרות, מעבר לתקציב, לא אמינות. הם ביטחו מונח עבור מה שהחסר: הנדסת תוכנה.
- ההתנגדות הייתה פשוטה. בונים מצירים לפני הבנייה. מהנדסים מחשבים לפני הגזירה. מתכננים היו מקלידים קוד לפני שאף אחד צייר מה התוכנה צריכה להיות.
- השרטוטים שנובעים מעשור זה הם אלו שתשתמש בהם בשלב העיצוב: תרשים המבנה, המראה כיצד התוכנית מחולקת לחלקים, ותרשים מעבר מצבים, המראה כיצד היא פועלת.
- שיעור זה עוסק בקריאתם, בהרכבתם ובמרתוך טבלת מבנה לקוד פסאודו.
מה שהעיצוב קובע
- הניתוח קבע מה התוכנית חייבת לעשות. העיצוב קובע איך: המבנים הנתוניים, האלגוריתמים, המודולים והממשק.
- שלב העיצוב מייצר איורים שמפתח יכול להפוך לקוד: תרשים זרימה ללוגיקה של אלגוריתם אחד, קוד פסאודו לאותו דבר בטקסט, טבלת מבנה למודולים, ותרשים מעבר מצבים להתנהגות.
- לכל כלי יש שאלה אחרת, והמבחן שואל איזה מהם מתאים.
לוגיקה של אלגוריתם אחד, צור לפני הכתיבה שלו
מעבדת תהליך תוכנה
סווגו דוגמאות פיתוח לפי השלב או הכלי שבהם הן שייכות.
טבלת המבנה
- טבלת מבנה מציגה את הפירוק ההיררכי של תוכנית למודולים, לתת-תוכניות ולפרמטרים המועברים ביניהן. עיצוב מלמעלה למטה מפצל בעיה גדולה אחת לבעיות משנה קטנות יותר, כאשר כל אחת מהן הופכת למודול.
- כל מודול הוא מלבן. קו מחבר קורא (מעל) למודול שהוא קורא (מתחת). מודולים באותו רמה נקראים משמאל לימין.
- חצים קטנים לצד הקווים נושאים נתונים: פרמטר המועבר מטה לתוך המודול, תוצאה המוחזרת למעלה לקורא. יהלום מסמן בחירה, וחץ מעוגל מסמן לולאה.
היררכיה על הקווים, נתונים על החצים
תרשים מבנה מראה:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
תרשים מבנה הוא פירוק היררכי למודולים, כאשר הפרמטרים כלפי מטה והתוצאות כלפי מעלה.
פירוק בעיה למודולים מלמעלה למטה נקרא:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
עיצוב מלמעלה למטה מייצר פתרון מודולרי.
דוגמה פותרת: קריאת החתימות מטבלת המבנה
CalculatePay
/ | \
GetEmployee CalculateBonus CalculateTax
returns: takes: sales takes: gross
employeeID returns: bonus returns: tax
GetEmployeeלא מקבל שום דבר ומחזיר מזהה עובד:FUNCTION GetEmployee() RETURNS INTEGER.CalculateBonusלוקח את סכום המכירות מטה ושולח את הבונוס חזרה:FUNCTION CalculateBonus(Sales : REAL) RETURNS REAL.CalculateTaxלוקח את השכר הכולל ומחזיר את המס. כל חץ בטבלה הוא פרמטר או ערך מוחזר בראשית; ראשית עם פרמטר שאינו מוצג בטבלה היא שגויה.
בגרף מבנה, חץ קטן המצביע כלפי מטה מהקורא לתוך מודול מראה ____ שעובר אליו.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
חצים כלפי מטה הם פרמטרים הנכנסים; חצים כלפי מעלה הם תוצאות הנתונות. יחד הם יוצרים את הכותרת של המודול.
דוגמה פותרת: בניית טבלת מבנה
- תוכנית קוראת ציוני תלמיד, מחשבת את הממוצע, ומדפיסה ציון. צייר טבלת מבנה.
- מודול עליון:
ProcessStudent. מתחתיו, משמאל לימין:ReadMarks, שמחזיר את מערך הציונים;CalculateAverage, שמקבל את מערך הציונים מטה ומחזיר את הממוצע;OutputGrade, שמקבל את הממוצע מטה ואינו מחזיר שום דבר. - שלושה דברים נבדקים: הרררכיה עם המשימה הראשית בראש, התת-משימות בסדר הפעלתן, ופרמטרים ממונים על החיצים בכיוון הנכון. חץ ללא תווית זוכה למקסימום בחצי נקודה.
ממפתח מבנה לפסאודוקוד
- המודול העליון הופך לתוכנית הראשית; כל ריבית מתחת לו הופכת לפרוצדורה או פונקציה שרأس (header) שלה קוראים מהחיצים; התוכנית הראשית קוראת אותן בסדר משמאל לימין.
PROCEDURE ProcessStudent()
DECLARE Marks : ARRAY[1:10] OF INTEGER
DECLARE Average : REAL
Marks ← ReadMarks()
Average ← CalculateAverage(Marks)
CALL OutputGrade(Average)
ENDPROCEDURE
- ערך שהוחזר הוא
FUNCTION … RETURNS; מודול שאינו מחזיר כל ערך הואPROCEDURE. רשימת הפרמטרים היא בדיוק החיצים המכוונים כלפי מטה.
סדרו את שלבי עיצוב תוכנית בגרף מבנה בסדר הנכון.
Difficulty 3/5 · 200 coins + a small bonus on first completion today
מלמעלה למטה: משימה, משימות משנה, זרימת נתונים, כותרות, קריאות. הגרם מסתיים לפני השורה הראשונה של הקוד.
מודול שחצים בגרף המבנה שלו מראים ערך שנחזר כלפי מעלה יש לכתוב כPROCEDURE.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
ערך שנחזר הופך אותו ל-FUNCTION … RETURNS. PROCEDURE אינה מחזירה דבר.
דיאגרמת מעבר מצבים
- דיאגרמת מעבר מצבים מסמרת את ההתנהגות של מערכת: המצבים בהם היא יכולה להיות והאירועים המזימים אותה ממצב אחד למצב אחר.
- כל מצב הוא עיגול או קופסה בעלת פינות מעוגלות; כל מעבר הוא חץ שמותווה באירוע הגורם לו, לעיתים גם בפעולה שבוצעה. סימן מציין את המצב ההתחלתי.
- היא מתאימה למערכות המתנות לאירועים ומגיבות להם: מכונת מכירה, רמזור, נעילת דלת, ממשק משתמש.
כל מצב, כל אירוע, כל חץ
תרשים מעבר מצבים מראה:
Difficulty 1/5 · 100 coins + a small bonus on first completion today
מצבים הם עיגולים; מעברים הם חצים עם תוויות אירוע. אידיאלי למכונות מכירה אוטומטיות, נעילה, רמזור.
מה מראה תרשים מעבר מצבים? סמן את כל האפשרויות הרלוונטיות.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
מצבים, מעברים מסומנים וסימון ההתחלה. זמן אינו חלק מהתרשים.
דוגמה מפורשת: קריאת דיאגרמת הנעילה
- הנעילה נפתחת על ידי הקוד 2, 5, 9. מתחילים בסגור. לחיצה על 2 מובילה למדויק ספרה אחת; לחיצה על 5 מנקודה זו מובילה למדויקים שתי ספרות; לחיצה על 9 מנקודה זו מובילה לפתוח.
- כל מקש אחר מכל אחד ממצבי ההמתנה מחזיר לסגור: הדיאגרמה מראה גם חיצים אלו, ודיאגרמה שנעדרת מהם יש בה חוסר. מה קורה אם לוחצים על 2 כשהמצב פתוח? אם אין חץ שמציין זאת, העיצוב טרם קבע זאת.
- זהו בדיוק ייעוד הדיאגרמה: לכל מצב חייב להיות ציין מה קורה בכל אירוע, כך שמעברים חסרים ימצאו על נייר ולא על ידי לקוח.
תרשים מעבר מצבים הופך קל לזיהוי מעברים חסרים או שאינם מטופלים, מכיוון שהכל מצבים והאירועים ביניהם מוצגים.
Difficulty 1/5 · 100 coins + a small bonus on first completion today
ראיית כל המצבים והאירועים חושפת מקרים שלא טיפלת — למשל, מטבע שני בלתי צפוי במכונת מכירה אוטומטית.
בחירת הכלי
- כדי להראות איך תוכנית מתפצלת למודולים ומה עובר ביניהם: מפתח מבנה.
- כדי להראות איך מערכת מתנהגת לאורך זמן בתגובה לאירועים, במיוחד מכונה או ממשק עם מצבי פעולה: דיאגרמת מעבר מצבים.
- כדי להראות את לוגיקת השלבים של אלגוריתם אחד: גרף זרימה או פסאודוקוד. ציין איזה ובמה.
התאם כל כלי עיצוב למה שהוא מציג.
Difficulty 2/5 · 140 coins + a small bonus on first completion today
כל כלי רואה את העיצוב באופן שונה — מבנה (מודולים), התנהגות (מצבים), זרימה (תרשים זרימה) או שלבים (קוד מדומה).
בקרת אור תנועה חייבת להגיב לטיימר ולכפתור הולכי רגל. איזה כלי עיצוב תיעד את התנהגותה הכי טוב?
Difficulty 1/5 · 100 coins + a small bonus on first completion today
אדום, אדום-ענבר, ירוק וענבר הם מצבים; המונה והכפתור הם אירועים. תרשים מבנה יראה את המודולים, לא את ההתנהגות.
סימונים נופלים מהיד
- מפתח מבנה אינו גרף זרימה. הוא מראה הרררכיה ופרמטרים, לא את סדר ההחלטות בתוך מודול.
- תווית כל חץ עם השם של הפרמטר או התוצאה ושכיוון אותו בצורה הנכונה. חץ ללא תווית אינו אומר כלום.
- מצב הוא מצב שבו המערכת נמצה, במצב המתנה; אירוע הוא מה שקורה לה. "לחץ על 5" הוא אירוע, לא מצב.
- כותרות הפסודוקוד חייבות להתאים לגרף: אותם פרמטרים, אותם ערכי החזרה, אותה סדר קריאות.
הבנתך מושלמת
- גרף מבנה מראה פירוק משמאל למעלה לטהור למודולים, עם פרמטרים העוברים מטה ותוצאות הנחזרות למעלה בחצים מסומנים
- קרא את כותרות הפסודוקוד ממנו: חצים כלפי מטה הם רשימת הפרמטרים, חץ כלפי מעלה הופך אותו ל
FUNCTION … RETURNS, והמודול הראשי קורא משמאל לימין - דיאגרמת מעבר-מצבים מראה את המצבים ואת האירועים שמניעים ביניהם, וחושפת את המעברים שעדיין לא הוחלטו עליהם
- פירוק → גרף מבנה; התנהגות → דיאגרמת מעבר-מצבים; לוגיקה של אלגוריתם אחד → תרשים זרימה או פסודוקוד