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

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

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

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

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

את מידת המענה של הפתרון לדרישות פונקציונאליות קל (יחסית...) לבחון מבחינה טכנולוגית. "תופסים" את הדרישות האלו באמצעות תסריטים (scenarios) ו – use cases (או themes, epics ו – user stories , תלוי במתודולוגיית הפיתוח). האתגר בדרישות אלו הוא בדרך כלל אתגר של התנהלות ופוליטיקה ארגונית (השאלה "מהי הפונקציונליות הרצויה" תלויה לעתים קרובות באופי הארגון המפתח מאשר בצרכי המשתמש הסופי), בשיקולים של מאפייני המשתמשים (רקע וניסיון, ציפיות מוצהרות ולא-מוצהרות להתהגות המערכת, ציפיות סמנטיות, עומס קוגניטיבי סביר) ועוד.

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

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

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

שאלה שנייה: כיצד מצמצמים את האפשרויות ?

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

וכאן נכנסים לתמונה ה – Architecture Styles.

ההגדרה ה"רשמית" של architecture styles (עד כמה שניתן למצוא הגדרות רשמיות במקצוע עמו ארכיטקטורת תוכנה, שעדיין נמצא בתהליכי התגבשות), היא:

(מתוך המאמר המומלץ בחום "Introduction to Software Architecture" של David Garlan and Mary Shaw מ – 1994. מאמר שאפשר לשייך לו לא מעט השפעה בהיסטוריה של מקצוע ארכיטקטורת תוכנה).

ישנו דמיון רב בין Design Patterns לבין Architecture Styles (הכינוי הנפוץ "Architecture Patterns" מעיד על כך). עם זאת מדובר במשפחות שונות של תבניות (Patterns) שגם ממוקמות ברמות שונות בהיררכיה של ניתוח ואפיון מערכות תוכנה (רמת הארכיטקטורה לעומת רמת העיצוב – design – של המערכת). בגדול, אפשר לתאר את ה – architecture styles כתבניות בעלות נפח והשפעה מערכתית גדולים יותר (לעתים, הרבה יותר) מאשר Design Patterns.

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

שאלה שלישית: כיצד בוחרים את ה – Architecture Style המתאים ?

לכל Architecture Style יש מגוון מסוים וידוע מראש של מאפיינים אותם הוא מספק (במידה זו או אחרת). מאפיינים אלו ניתנים לניסוח כאותם Quality Attributes, הידועים כדרישות לא-פונקציונאליות. דוגמא אחת היא ה – Pipes and Filters architecture style (ה - style החביב עלי), שמאפשר לספק Quality Attributes כגון: Configurability, Composeability, Manageability, Reusability, Testability ועוד (הגדרת ה – Quality Attributes הנ"ל אינה ב – scope של הפוסט הנוכחי, אך ניתן ללמוד יותר בקישורים המצורפים).

וכאן אנו מגיעים לנקודה המרכזית –

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

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

מידת ההתאמה ל – quality attributes נובעת מהמאפיינים המובנים והידועים מראש של ה – Architecture Styles השונים (כאן בא לידי ביטוי הדמיון הרבה בינם לבין Patterns בכלל). הניסיון הרב שנצבר במימוש ה – Architecture Styles השונים מספק מידע רב לגבי יתרונותיהם וחסרונותיהם בהתייחס למגוון של תסריטים, וכן, עצם השימוש במונחים אחידים (vocabulary) מאפשר תקשורת יעילה מול ארכיטקטי תוכנה אחרים על מנת לאסוף המלצות, תובנות, הערות והארות בשלב מוקדם ככל האפשר בתהליך הניתוח האפיון.

כל זאת, בלי לזלזל או להתעלם מחשיבות הרבה שיש למימוש בפועל של ה – Architecture Style על היכולת לספק מענה לדרישות השונות.
לאחר צמצום האפשרויות ובחירת מספר Architecture styles שמועמדים לאימוץ במסגרת הפתרון הארכיטקטוני, מומלץ (מלשון "חובה" J), לבחון מאפיינים מעשיים, מדידים ומוחשיים של פתרונות אפשריים שמממשים Architecture Style שמועמד לשימוש. היות ורוב ה – Architecture Styles מומשו במסגרת Framework או מוצר זה או אחר, וזמינים לשימוש כ"קופסא שחורה", עולה השאלה של מידת ההתאמה של המוצר (או הרכיב, או התשתית וכו') לתסריט הספציפי עבורו מנסים לספק מענה. כמו תמיד – אלוהים נמצא בפרטים הקטנים (והשטן גם).

ולסיכום -

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

קישורים למקורות מידע נוספים בנושא -

• Introduction to Software Architecture - המאמר המייסד של התחום
• Microsoft Patterns & Prectices Application Architecture Guide 2.0 - Chapter 3 - Architectural Patterns and Styles - ספר מצוין של החבר'ה מ - Patterns & Practices
• Pattern-Oriented Software Architecture - A System of Patterns - החלק הראשון בסדרה (POSA1), ולטעמי הטוב שבהם. מכיל סקירה מצוינת של מגוון Architecture Styles.
• מצגת Architecture Styles מתוך סדנת ארכיטקטורת תוכנה.

HTH,

דני.

שמי דני כהן ואני ארכיטקט ויועץ בצוות MCS Israel, ומתמחה במערכות מבוזרות, Cloud Computing, מתודולוגיות פיתוח וארכיטקטורת תוכנה.