תרשים זרימה של תהליך פיתוח תוכנה: סמלים, סוגים ודוגמאות

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

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

מהו תרשים זרימה בפיתוח תוכנה?

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

מקורם של תרשימי זרימה בשנות ה-20 של המאה ה-20 בהנדסת תעשייה, שם הם שימשו לתיעוד תהליכי ייצור. הטכניקה פורמלית למחשוב בשנות ה-40 וה-50, וכשהתכנות המובנה הפך לנוהג סטנדרטי בשנות ה-70, תרשימי זרימה הפכו לחלק מרכזי בתיעוד עיצוב תוכנה. כיום, תרשימי זרימה עדיין בשימוש פעיל לעיצוב אלגוריתמים, תיעוד הטמעה, מיפוי תהליכים עסקיים ותקשורת לוגיקה לבעלי עניין שאינם טכניים, גם כאשר סוגי דיאגרמות מיוחדים יותר (UML, דיאגרמות רצף, דיאגרמות מצב) השתלטו על חלק מהתפקידים שמילאו תרשימי זרימה במקור.

מה ההבדל בין תרשים זרימה לתרשים זרימה של תהליך?

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

סמלי תרשים זרימה: ההפניה המלאה

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

סמל	צוּרָה	שם	משמעות
⬭	מלבן סגלגל / מעוגל	שליחות קטלנית (התחלה/סוף)	מסמן את תחילתו או סופו של התהליך
▭	מלבן	התַהֲלִיך	מייצג שלב, פעולה או פעולה בודדים
◇	יהלומים	הַחְלָטָה	נקודת הסתעפות עם שתי תוצאות אפשריות או יותר (כן/לא, נכון/לא נכון)
▱	מקבילית	פלט קלט	מייצג נתונים הנכנסים או יוצאים מהתהליך
⬡	משושה	הכנה	מייצג שלב הגדרה, כגון אתחול מונה לולאה
▭ (עם גבול כפול)	תהליך מוגדר מראש	קריאה לתהליך או תת-שגרה נפרדים שכבר מוגדרים
⬠	מסמך	מייצג מסמך מודפס או שנוצר
○	מעגל קטן	מַחבֵּר	מקשר שתי נקודות בתרשים הזרימה, משמש לעתים קרובות כדי למנוע קווים מחציתיים
▽	משולש (הנקודה כלפי מטה)	למזג	משלב מספר נתיבים לאחד
△	משולש (הצבע כלפי מעלה)	להוציא	מפצל נתיב אחד למספר נתיבים
→	חץ	קו זרימה	מציין את כיוון זרימת התהליך
⬢	מחבר מחוץ לדף	מציין שהזרימה ממשיכה בעמוד אחר

שני הסמלים שכל קורא צריך לזהות מיד הם המלבן (שלב בתהליך) והיהלום ( נקודת החלטה עם מספר יציאות). שני אלה לבדם מכסים את רוב התוכן של כל תרשים זרימה. הסימן הסגלגל/מעוגל של ההתחלה והסוף משלים את אוצר המילים המינימלי הדרוש לקריאת רוב תרשימי הזרימה בצורה נכונה.

סוגי תרשימי זרימה המשמשים בפיתוח תוכנה

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

סוג תרשים זרימה	מה זה מראה	הכי מתאים ל
תרשים זרימה של התהליך	שלבים עוקבים בתהליך יחיד	תיעוד אלגוריתם, לוגיקה של פונקציה או נוהל עסקי
תרשים זרימה של המערכת	כיצד נתונים עוברים דרך רכיבי חומרה ותוכנה	תיעוד ארכיטקטורה ברמה גבוהה, מיפוי מערכות מדור קודם
תרשים זרימה של נתיב שחייה (חוצה תפקידים)	שלבים מקובצים לפי האדם, הצוות או המערכת האחראים	תהליכים המשתרעים על פני מספר תפקידים או מחלקות
דיאגרמת זרימת נתונים (DFD)	כיצד נתונים עוברים בין תהליכים, חנויות וישויות חיצוניות	תיעוד טרנספורמציות נתונים במקום לוגיקת בקרה
דיאגרמת זרימת עבודה	מסירות משימות ושרשראות אישור בתהליך עסקי	ניהול פרויקטים, תהליכי עבודה לאישור, ניתוב כרטיסים
דיאגרמת פעילות UML	פעילויות מקבילות ועוקבות עם סימון UML פורמלי	תיעוד עיצוב תוכנה מונחה עצמים

דיאגרמת זרימת נתונים לעומת תרשים זרימה: מה ההבדל?

זוהי אחת מנקודות הבלבול הנפוצות ביותר, והיא ראויה לתשובה ישירה. תרשים זרימה מציג את זרימת הבקרה : הסדר שבו השלבים מבוצעים והתנאים הקובעים איזה נתיב נלקח. דיאגרמת זרימת נתונים (DFD) מציגה את זרימת הנתונים : היכן מקור הנתונים, אילו תהליכים הופכים אותם, היכן הם מאוחסנים ולאן הם מגיעים בסופו של דבר, מבלי בהכרח להראות את הסדר הרציף של הפעולות או את לוגיקת ההחלטות.

תרשים זרימה עונה על שאלות כמו "מה קורה, באיזה סדר, באילו תנאים?". דיאגרמת זרימת נתונים עונה על שאלות כמו "מאי מגיעים הנתונים האלה, מה משנה אותם, ולאן הם מגיעים?". מערכות אמיתיות רבות נהנות משניהם: תרשים זרימה לתיעוד לוגיקת העיבוד, ותרשים זרימה נתונים (DFD) לתיעוד כיצד מידע עובר דרך לוגיקה זו.

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

תחביר ה-Mermaid שלהלן מעובד ישירות ב-GitHub, GitLab, Notion, וברוב פלטפורמות התיעוד המודרניות, מה שהופך אותו לדרך הסטנדרטית לשמור על תרשימי זרימה מגרסאות לצד הקוד במקום לתחזק אותם כתמונות סטטיות נפרדות.

תרשים זרימה של תהליך בסיסי

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

תרשים זרימה עם לולאה

לולאות בתרשימי זרימה מיוצגות על ידי חץ שחוזר לנקודת החלטה קודמת במקום להמשיך קדימה. זהו המקבילה בתרשים הזרימה של for or while לולאה בקוד, וזו אחת התבניות הנבדקות בתדירות הגבוהה ביותר בקורסי תכנות מבוא, "צייר תרשים זרימה למציאת הגדול ביותר מבין שלושה מספרים" ותרגילים דומים כמעט תמיד דורשים לולאה או מבנה החלטה מקונן.

דוגמה לתרשים זרימה של מסלול שחייה

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

כיצד ליצור תרשים זרימה של תהליך פיתוח תוכנה

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

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

שלב 3: זהו כל נקודת החלטה. עברו על רשימת השלבים וסמנו כל מקום שבו הפעולה הבאה תלויה בתנאי. כל נקודת החלטה הופכת ליהלום עם לפחות שני נתיבים יוצאים, וכל נתיב חייב להיות מתויג (כן/לא, נכון/לא נכון, או התנאי הספציפי).

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

שלב 5: חיבור באמצעות חיצי כיוון. לכל סמל צריך להיות חיבור נכנס ויוצא ברור (למעט ההתחלה, שאין בה כניסות, והסוף, שאין בו יציאות). החצים צריכים לזרום בכיוון כללי עקבי, בדרך כלל מלמעלה למטה או משמאל לימין, כדי למנוע בלבול חזותי.

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

כלי תרשימי זרימה לפיתוח תוכנה

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

Mermaid ו- PlantUML הם כלי דיאגרמות-כקוד: תרשים הזרימה מוגדר כטקסט ומוצג אוטומטית, מה ששומר על בקרת גרסאות לצד קוד המקור שהוא מתעד. זוהי הגישה המומלצת לכל תרשים זרימה שמתעד לוגיקת קוד, מכיוון שניתן לעדכן אותו באותו commit כמו שינוי הקוד שהוא מתאר.

Lucidchart , Microsoft Visio ו- draw.io הם כלי יצירת דיאגרמות לשימוש כללי עם ממשקי גרירה ושחרור, המתאימים לתיעוד תהליכים עסקיים, מצגות ודיאגרמות המתוחזקות מחוץ לבקרת גרסאות.

כלי לוח לבן (לוחות לבן פיזיים, Miro, FigJam) מתאימים לפגישות עיצוב שיתופיות שבהן תרשים הזרימה הוא חפץ עובד במהלך דיון ולא מסמך קבוע.

הפשרה בין קטגוריות אלו היא סינכרון: דיאגרמות המתוחזקות ידנית ב-Lucidchart או Visio מתיישנות ככל שהתהליך או הקוד הבסיסי משתנים, מכיוון שעדכון הדיאגרמה דורש שלב ידני נפרד שקל לשכוח. דיאגרמות כקוד ויצירה אוטומטית פותרות שתיהן פתרון זה על ידי קשירת דיוק הדיאגרמה לתהליך אוטומטי ולא לזיכרון אנושי.

יצירת תרשימי זרימה באופן אוטומטי מקוד קיים

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

עבור בסיסי קוד קיימים, במיוחד מערכות גדולות או מדור קודם, יצירת תרשימי זרימה אוטומטית מנתחת את קוד המקור בפועל ומייצרת את תרשים הזרימה ישירות מזרימת הבקרה שלו, כל... if, כל לולאה, כל קריאה לפונקציה מוצגת כסמל תרשים הזרימה המתאים, מבלי לדרוש מאדם לעקוב ידנית אחר הלוגיקה תחילה.

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

איך SMART TS XL יוצר תרשימי זרימה מבסיס הקוד שלך

SMART TS XL מייצרת תרשימי זרימה, גרפי קריאה ודיאגרמות תלות ישירות מניתוח קוד מקור, COBOL, JCL, Java, Python, RPG ושפות אחרות, במקום לדרוש ממפתחים לצייר אותם ידנית. זוהי גישה שונה באופן מהותי מכלי דיאגרמה לשימוש כללי כמו Lucidchart או Visio, המספקים בד ציור אך אינם מודעים למה הקוד שלך עושה בפועל.

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

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

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

תרשימי זרימה הם כלי תקשורת, לא רק חפץ תיעודי

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

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