מודולריות

מתוך הנקודאי

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

פיתוח תוכנה

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

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

יתרונות

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

עקרונות כלליים

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

הערות כלליות

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

ראו גם