تحقیق در مورد معماری نرم افزار

بخشی از مقاله

معماری نرم افزار

چکیده
با گسترش روز افزون استفاده از مدل¬های فرایند مبتنی بر معماری، طراحی معماری نرم افزار اهمیت ویژه¬ای یافته است. یک طراحی معماری خوب، طراحی است که نیاز¬های کیفی مورد انتظار مشتری را برآورده نماید. در این گزارش روش ¬های گوناگون طراحی معماری نرم افزار مورد بررسی قرار خواهد گرفت. سپس ویژگی کیفی قابلیت تغییر به طور دقیق و جزئیات معرفی خواهد شد و سپس معماری یک سیستم مطالعه موردی با دیدگاه دستیابی به قابلیت تغییر طراحی خواهد شد.

فهرست مطالب

1 مقدمه 4
2 معماری نرم افزار چیست ؟ 5
2-1 تعاریف پایه در معماری نرم افزار 6
الگوهای معماری یا سبکهای معماری 6
مدل مراجع 6
معماري مرجع 6
2-2 دیدگاه های معماری 7
ديدگاه Bass 7
ديدگاه 4+1 8
ديدگاه‌هاي دیگر 8
3 طراحی معماری نرم افزار 9
3-1 كاركرد‌هاي سيستم و معماري نرم‌افزار 9
3-2 ويژگي‌هاي كيفي 9
3-3 ويژگي‌هاي كيفي سيستم 10
3-4 سناريو‌هاي ويژگي‌كيفي 10
3-5 ويژگي‌هاي كيفي كسب و كار 11
3-6 ويژگي‌هاي كيفي معماري 12
3-7 يك طراحی معماری خوب بايد داراي چه ويژگي‌هايي باشد؟‌ 12
3-8 دستیابی به ویژگیهای کیفی 12
تاکتیکهای معماری 12
الگوهای معماری 14
ارتباط تاکتیکها و الگوهای معماری 15
4 روشهای طراحی معماری نرم افزار 16
4-1 طراحی مبتنی بر ویژگی 16
4-2 طراحی به کمک سبک های معماری مبتنی بر ویژگی 17
4-3 طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه 19
5 ويژگي كيفي قابليت تغيير 23
5-1 تعريف قابليت تغيير 23
5-2 مشخص نمودن نياز‌هاي قابليت تغيير با استفاده از سناريو‌هاي كيفي 23
5-3 مدل سازي قابليت تغيير در سطح معماري نرم افزار 24
5-4 تاكتيك‌هاي قابليت تغيير 24
5-5 تاكتيك‌هايي كه تغييرات را محلي مي‌كنند. 25
5-6 تاكتيك‌هايي كه ميدان ديد وظايف را كاهش مي دهند. 26
5-7 تاكتيك‌هايي كه از پخش شدن تغييرات جلوگيري مي‌كنند. 26
5-8 ارزيابي قابليت تغيير 27
ارزيابي نحوه اختصاص وظايف 27
ارزيابي وابستگي بين ماژول‌ها 27
انواع وابستگي 27
نحوه بازنمايي وابستگي‌ها 29
روش Brute-force 29
استفاده از بستار انتقالی 29
استفاده از روش‌هاي بهينه سازي 30
استفاده از جدول وابستگي‌ها 30
5-9 تصميم گيري نهايي در مورد طراحي ويژگي كيفي قابليت تغيير 30
6 مطالعه موردي 31
6-1 مرحله 1 - انتخاب يك سناريو حقيقي 31
6-2 مرحله 2 - بررسي نوع سناريو حقيقي 31
6-3 مرحله 3 - انتخاب چهارچوب استدلال مناسب 32
6-4 مرحله 4 - مشخص نمودن پارامتر‌هاي محدود و آزاد 34
6-5 مرحله 5 - مشخص كردن تاكتيك‌هاي وابسته به پارامتر‌هاي آزاد 35
6-6 مرحله 6 - اختصاص مقادير اوليه به پارامتر‌هاي آزاد 36
6-7 مرحله 7 - انتخاب تاكتيك‌ها و به كاربردن آنها براي دستيابي به پاسخ مناسب 36
استفاده از كامپايلر به عنوان واسط 38
استفاده از سيستم‌عامل به عنوان واسط 38
6-8 مرحله 8 : اختصاص مسئوليت‌ها به عناصر معماري 38
7 خلاصه و نتیجه گیری 40
8 مراجع 41

فهرست مطالب

شكل 1 - ارتباط بين الگوي معماري، مدل مرجع و معماري مرجع 7
شكل 2 - بخش‌هاي تشكيل دهنده سناريو ويژگي كيفي 11
شکل 3 – خلاصه¬ای از تاکتیک¬های قابلیت تغییر 11
شکل 4 – خلاصهای از تاکتیکهای کارایی 13
شکل 5 - مجموعه ای از مهمترین الگوهای معماری 14
شکل 6 – ورودیها و خروجیهای روش ADD 16
شکل 7 – الگوی معماری خط لوله همزمان 18
جدول 1 – پارامترهای الگوی خط لوله همزمان 18
جدول 2 – خروجی فاز اول روش CBAM 20
شكل 8 - نمودار مقايسه ميزان كاربرد هر راهبرد در مقابل هزينه 20
شكل 9 - انواع نمودار‌هاي ممكن براي سودمندي براساس پاسخ 21
شكل 10 - معماري سه لايه 24
جدول 3 - نحوه بازنمايي وابستگي بين دو ماژول 29
شكل 11 - نمودار جريان داده ( تغييرات به طور غير مستقيم از A به B منتقل مي‌شود) 30
جدول 4- سناريو حقيقي قابليت تغيير براي سيستم مورد مطالعه 31
جدول 5 - سناريو عمومي قابليت تغيير براي مسئله مورد بررسي 32
شكل 12 - نمايش سيستم به صورت دو ماژول وابسته 32
جدول 6 - چهارچوب استدلال براي ويژگي كيفي قابليت تغيير 33
شكل 13 - پارامتر‌هاي اثر گذار بر روي هزينه تغييرات 34
جدول 7 - پارامتر‌هاي قابليت تغيير و تاكتيك‌هاي اثر گذار بر روي آنها 35
جدول 8 - قانون‌هايي كه نحوه استفاده از تاكتيك‌ها را مشخص 36
شكل 14 - تكه طراحي تاكتيك شكستن زنجيره وابستگي 38
شکل 15 - اختصاص وظايف با توجه به تاكتيك‌هاي اعمال شده 39

1 مقدمه

امروزه يكي از مهمترين ويژگي‌هاي هر سيستم نرم‌افزاري، كيفيت مي‌باشد. با پيشرفت‌هاي انجام شده و گسترش ابزار‌هاي گوناگون براي توسعه نرم‌افزار، توسعه نرم‌افزار‌هايي كه كاركرد‌هاي مورد نظر مشتريان را برآورده سازند، امري آسان و سريع گشته است. در حال حاضر، تفاوت بين دو نرم‌افزار را توانايي نرم‌افزار‌ها در برآورده ساختن ويژگي‌هاي كيفي مورد انتظار تعيين مي‌كند.

معماري نرم افزارِ يك برنامه يا سيستم كامپيوتري، ساختار يا ساختارهايي از سيستم مي باشد، كه در برگيرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بين آنها باشد[Bass 03] . معماري نرم‌افزار شامل اولين تصميمات طراحي سيستم مي‌باشد و اين تصميمات زيربناي فعاليت‌هاي طراحي، پياده‌سازي، استقرار و نگهداري سيستم مي‌باشد. همچنين معماري نرم‌افزار، اولين عنصر قابل ارزيابي در فرايند توسعه نرم‌افزار مي‌باشد[Bass 03] . بنابراين براي طراحي سيستمي كه نياز‌هاي كيفي مورد نظر را برآورده سازد، توليد معماري نرم‌افزار اولين گام در دستیابی به كيفيت در نرم‌افزار و همچنين ارزيابي ويژگي‌هاي كيفي است.

در مدل¬های فرایند توسعه نرم¬افزار مبتنی بر معماری معمولاً ابتدا نیاز¬های کیفی سیستم تعیین شده و سپس معماری نرم¬افزار مربوطه طراحی می¬گردد. پس از طراحی معماری، می-توان به ارزیابی آن پرداخت و تغییرات لازم را در طراحی مورد نظر ایجاد داد. بنابراین دو بخش اساسی در مدل¬های

فرایند توسعه نرم¬افزار مبتنی بر معماری، بخش¬های طراحی و ارزیابی معماری نرم افزار می¬باشند. این دو بخش در ارتباط مستقیم با یکدیگر می¬باشند و هر یک مکمل دیگری می¬باشد. بنابراین فرایند طراحی معماری را می¬توان شامل ساخت معماری نرم¬افزار، ارزیابی آن و اصلاح معماری پیشنهادی دانست.
در این گزارش، هدف بررسی روش¬های موجود در طراحی معماری نرم¬افزار بر اساس ویژگی¬های کیفی مورد نظر مشتریان و بررسی نحوه خودکار سازی فرایند طراحی معماری با ارائه ابزار¬هایی برای این منظور می¬باشد. ادامه مطالب گزارش به این صورت طبقه بندی شده اند. در بخش 2 توضیح مختصری در

ارتباط با معماری نرم¬افزار و مفاهیم مرتبط با آن ارائه می¬شود. این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد. در بخش 3 طراحی معماری نرم¬افزار، ویژگی¬های یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت. در بخش 4 روش¬های طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت. در بخش 5 خلاصه و نتیجه گیری ارائه خواهد شد. در بخش 6 مراجع مورد استفاده در این گزارش معرفی می¬گردد.
2 معماری نرم افزار چیست ؟

براي معماري نرم‌افزار، تعريفي كه به طور عمومي پذيرفته شده باشد، وجود ندارد. افراد مختلف، معماري نرم‌افزار را به اشكال گوناگون تعريف كرده‌اند. اين تعاريف، از لحاظ ظاهري متفاوتند ولي به مفهوم مشتركي اشاره مي‌كنند.
در [Bass 03] معماري نرم افزار به صورت زير تعريف شده است :
معماري نرم افزار يك برنامه يا سيستم كامپيوتري، ساختار يا ساختارهايي از سيستم مي باشد، كه در برگيرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بين آنها باشد.
از تعريف فوق مي توان به نتايج زير دست يافت :
• معماري، اجزاي نرم افزار را تعريف مي نمايد. همچنين در اين تعريف، از جزئياتي از اجزا، كه در نحوه استفاده و ارتباط با اجزاي ديگر كاربردي ندارند؛ صرف نظر مي گردد.
• هر سيستم نرم افزار شامل چندين ساختار مي باشد؛ و هيچ يك از اين ساختارها، به تنهايي معماري نرم افزار نمي¬باشد. بلكه اين ساختارها در كنار يكديگر معماري نرم افزار را تشكيل مي دهند.
• هر سيستم نرم افزاري داراي يك معماري مي باشد. (زيرا هر سيستم نرم افزاري داراي اجزايي است كه اين اجزا با يكديگر داراي رابطه مي باشند).
• رفتار هريك از اجزاء، بخشي از معماري نرم افزار مي باشد. (زيرا اين رفتار در نحوه ارتباط بين اجزا تاثيرگذار است.)
• معماري نرم افزار بايد قابل ارزيابي باشد تا بتوان از روي آن تشخيص داد سيستم مورد نظر بر پايه معماري انتخاب شده نيازهاي خود را برآورده خواهد كرد يا خير.
علاوه بر تعاریف ارائه شده در [Bass03] تعاریف گوناگون دیگری نیز برای معماری نرم افزار ارائه شده است که در اینجا به برخی از آنها اشاره خواهیم کرد :
در [IEEE00]معماري نرم افزار به صورت زير تعريف شده است :
معماري نرم‌افزار، سازمان زيربنايي سيستم مي‌باشد، كه در قالب اجزا و روابط بين آنها و همچنين روابط آنها با محيط، بيان شده است و براي طراحي و تكامل آن اصولي وجود دارد.
در اين نوع تعريف، فرايند توليد معماري، عضوي از معماري در نظر گرفته شده است. ( زيرا قوائد و اصول طراحي و تكامل نيز عضوي از معماري در نظر گرفته شده اند.‌) در حالي كه اين موارد جزء معماري محسوب نمي‌گردند. معماري هر سيستم نرم‌افزاري مي‌تواند بدون توجه به نحوه توليد آن مشخص و ارزيابي گردد.
در [Booch 98] معماري نرم افزار مجموعه‌اي از تصميمات مهم درباره ساختار سيستم نرم‌افزاري ، انتخاب اجزاء ساختاري و ارتباطات بين آنها و همچنين مشخص نمودن نحوه همكاري اين اجزاء با يكديگر مي‌باشد. وقتي اين اجزاء در كنار يكديگر سيستم بزرگي را تشكيل دهند معماري نرم افزار به وجود خواهد آمد.
در [Garlan 93]، معماري نرم‌افزار سطحي از طراحي تعريف شده است كه داراي ويژگي‌هاي زير مي‌باشد :
• وراي الگوريتم و ساختمان داده طراحي شده باشد.
• شامل ساختار كلي سيستم، ساختار‌هاي كنترلي عمده، پروتكل‌هاي ارتباطي، اختصاص كاركرد‌ها به اجزاء، توزيع فيزيكي اجزاء باشد.
• تركيبي از اجزاء طراحي باشد كه از بين گزينه‌هاي طراحي موجود انتخاب شده است.

در تعاريف ارائه شده توسط [Booch 98] و [Garlan 93]، از معماري به عنوان ساختار كلي سيستم نام‌ برده شده است. بايد توجه داشت، ضعف اين تعريف نسبت به تعريف ارائه شده توسط [Bass 03] در محدود كردن ساختار سيستم به تنها يك ساختار مي‌باشد. در حالي كه سيستم براي مشخص كردن معماري، داراي ساختار‌هاي گوناگون باشد.
در [RUP 03] معماري نرم‌افزار سازمان يا ساختار اجزاء اصلي سيستم كه از طريق واسط‌هايي با هم ارتباط برقرار مي‌كنند؛ مي‌باشد به طوري كه هر يك از اجزاء از اجزاء كوچكتري تشكيل شده كه اين اجزاء كوچك نيز با يكديگر ارتباط دارند. در اين تعريف نيز، به ساختار‌هاي گوناگون اشاره نشده است. گرچه در [RUP 03] در مرحله طراحي معماري نرم‌افزار، ساختار‌ها يا ديدگاه هاي مختلفي براي معماري معرفي شده است.

ديدگاه ما نسبت به معماري، ديدگاه [Bass 03] مي‌باشد. يكي از نكات مهم در اين تعريف، امكان ارائه ساختار‌هاي گوناگون براي معماري مي‌باشد. اين ساختار‌ها نبايد محدود به چندين ساختار پيش فرض باشند. به عنوان مثال براي توليد معماري يك سيستم امن، مي‌توان مدل امنيتي سيستم را نيز عضو معماري قرار داد. زير بررسي و ارزيابي آن قبل از مرحله پياده سازي بسيار حياتي مي‌باشد.

2-1 تعاریف پایه در معماری نرم افزار
در این بخش به بررسی برخی از مفاهیم پایه در معماری نرم افزار خواهیم پرداخت. در بخش های بعدی از این مفاهیم پایه استفاده زیادی خواهد شد.
الگو¬های معماری یا سبک¬های معماری
الگوهاي معماري یا سبک ¬های معماری شامل شرحي از اجزاء و نوع روابط بين آنها مي باشد به نحوي كه تعدادي قانون براي معرفي اجزاء و نحوه ارتباط بين آنها، مشخص گردد. [Bass 03]
به عنوان مثال client-server يك الگوي معماري است كه مشخص مي كند سيستم داراي دو جزء مي باشد و اين دو جزء تحت پروتكل خاصي با يكديگر ارتباط دارند.
هر الگوي معماري در برگيرنده تعدادي معيار كيفي مي باشد و معمار نرم افزار بر اساس نيازهاي كيفيتي مورد نظر، الگوي معماري مناسب را انتخاب مي نمايد.
در بسياري از موارد از سبك‌هاي معماري، به جاي الگوهاي معماري استفاده مي گردد.
از ديدگاه ما الگو‌هاي طراحي بايد بتوانند يك يا چند نياز كيفي را برآورده نمايند. زيرا درصورتي كه تنها كاركرد مد نظر باشد بدون استفاده از الگوي خاصي مي‌توان به آن دست يافت.

مدل مرجع
مدل مرجع، تقسيم بندي و تجزيه كاركردهاي مختلف يك سيستم به همراه جريان داده هاي بين هريك از بخش‌ها مي باشد. در حقيقت مدل مرجع، تقسيم بندي يك مسئله مشخص به اجزاء مي‌باشد به گونه اي كه اين اجزا توانايي حل مسئله را داشته باشند. به عنوان مثال، مدل مرجع براي يك نرم افزار سيستم عامل، شامل بخش‌هايي نظير : مديريت حافظه، مديريت ديسك، مديريت فعاليت‌ها و ... مي‌باشد.

معماري مرجع
معماري مرجع، مدل مرجعي مي باشد كه به اجزاي نرم افزاري نگاشت شده است. در حقيقت در معماري مرجع، جايگاه هريك از كردهاي سيستم در قالب اجزاي نرم افزاري تشكيل دهنده سيستم مشخص شده است. هر جزء نرم افزار در اين مدل ممكن است قسمتي از يك كاركرد يا چندين كاركرد را پياده سازي نمايد. به عنوان مثال براي يك سيستم‌عامل، مديريت حافظه توسط جزء هسته انجام شود. مديريت ديسك توسط جزء مدير ديسك و هسته انجام شود و ...
ارتباط بين الگوهاي معماري، مدل مرجع و معماري مرجع در شكل 1 نمايش داده شده است.
شكل 1 - ارتباط بين الگوي معماري، مدل مرجع و معماري مرجع

2-2 دیدگاه های معماری
سيستم هاي مدرن و امروزي به اندازه اي پيچيده هستند كه يه ساختار و ديدگاه واحد، توانايي نمايش همه جنبه هاي آنها را ندارد.[Bass 03] بنابراين براي نمايش معماري يك سيستم نرم افزاري از ديدگاه هاي مختلف استفاده مي كنيم. يك ساختار يا ديدگاه معماري، نمايش مجموعه اي از اجزاي معماري مرتبط با يكديگر و ارتباط بين اين اجزا مي باشد.

ديدگاه Bass
بر اساس طبقه بندي ارائه شده در [Bass 03] ساختارهاي معماري نرم افزار قابل دسته بندي از سه گروه عمده به شرح زير مي باشند:
• ساختار ماژول‌ها
در اين ساختار، اجزاء تشكيل دهنده ماژول ها هستند. ماژول، يك واحد پياده سازي شده از سيستم مي‌باشد. ساختار ماژول‌ها نمايشي مبتني بر كد از سيستم مي باشد. هر ماژول شامل طيفي از وظايف مي‌باشد. در ساختار ماژول‌ها، بيشترين تاكيد بر نحوه پخش شدن وظايف مختلف بر روي ماژول‌ها و نحوه ارتباط ماژول‌ها با يكديگر است. در اين ساختار تاكيد خاصي روي ساختار‌هاي اجرايي نمي‌شود.
• ساختار اجزاء و رابط‌ها
در اين ديدگاه، اجزاء تشكيل دهنده واحد‌هاي در حال اجرا مي باشند(واحد‌هاي محاسباتي). همچنين رابط‌ها نحوه ارتباط و گفتگوي بين اجزاء را نشان خواهند داد. اين ساختار مشخص كننده اجزاي مهم اجرايي و نحوه ارتباط آنها با يكديگر است. همچنين اين ساختار مواردي نظير : مهمترين محل‌هاي ذخيره اطلاعات، نحوه تكرار داده‌ها، اجزايي كه به طور موازي اجرا مي‌گردند، مي‌باشد.
• ساختار تخصيص منابع
اين ساختار ارتباط بين اجزاء نرم افزاري و اجزائي كه در محيط خارجي توليد و استقرار نرم افزار وجود دارند را نشان مي دهد. اين ساختار، نحوه استقرار اجزاء برنامه روي پردازنده‌ها، فايل‌هاي مربوط به هريك از بخش‌هاي برنامه نرم‌افزاري در طول پياده‌سازي، اجرا و تست و نحوه اختصاص وظايف پياده‌سازي به تيم را مشخص مي‌نمايد.
در اين ديدگاه، از ابزار UML استفاده نشده ولي از لحاظ مفهومي قابليت پياده سازي با استفاده از UML وجود دارد.

ديدگاه 4+1
اين ديدگاه در [Kruchten 95] ارائه شده و امروزه به عنوان استاندارد در IEEE 1471 [IEEE 00] مطرح مي‌باشد. در اين ديدگاه، ساختارهاي معماري به صورت زير طبقه بندي شده اند :
• Logical View
• Process View
• Deployment View
• Implementation View
• Use-case View
همچنين اين ديدگاه در [RUP 03] نيز به عنوان استاندارد توسعه معماري نرم افزار معرفي گرديده است. پايه اين ديدگاه متدولوژي شيء گرا و ابزار استفاده از آن UML مي باشد. براي استفاده بهينه از اين ديدگاه پيشنهاد مي شود كه مدل فرايند انتخابي به صورت تكراري و بر پايه RUP انتخاب گردد.

ديدگاه‌هاي دیگر
از ديگر ديدگاه هايي كه در [Garland 03] معرفي گرديده شده مي توان به :
• ديدگاه RM-ODP (استاندارد ISO )
• ديدگاه Hofmeister
اشاره نمود. براي جزئيات بيشتر به [Garland 03] مراجعه شود.
3 طراحی معماری نرم افزار
در اين بخش به بررسي عوامل تاثير گذار بر معماري نرم‌افزار و نحوه توليد معماري خواهيم پرداخت. با توجه به تعاریف انجام شده، معماری نرم¬افزار هر سیستم، پس از به دست آوردن نیاز¬های آن سیستم باید تولید شود. بنابراین در طراحی یک معماری، باید به دو عامل توجه داشت :
• نیاز¬های کارکردی سیستم
• ویژگی¬های کیفی
بنابراین معماری باید به گونه ای طراحی شود که عوامل فوق را پوشش دهد. در ادامه هریک از دو ویژگی فوق را تعریف کرده و نقش آن را در طراحی معماری مورد بررسی قرار خواهیم داد.

3-1 كاركرد‌هاي سيستم و معماري نرم‌افزار
كاركرد‌هاي سيستم، توانايي‌هاي سيستم در انجام كارهاي مختلف مي‌باشد[Bass 03]. براي دستيابي به كاركرد‌هاي مورد نظر در يك سيستم نرم افزاری مي‌توان از ساختار‌هاي گوناگون استفاده نمود. به بياني ديگر در صورتي كه در توليد نرم افزار تنها كاركرد مورد نظر مي بود؛ امكان توليد نرم افزار در قالب يك واحد يكپارچه و مستقل امكان پذير بود. اما معمولاً كاركرد، تنها نياز نرم افزار نمي باشد. بنابراين براي برآورده كردن نيازهاي ديگر كه شامل نيازهاي غيركاركردي و كيفي مي¬باشند؛ بايد از ساختارهاي خاصي در توليد نرم افزار استفاده نمود. به عنوان مثال، هنگامي كه يك سيستم را مبتني بر ماژول‌هاي مختلف پياده سازي مي‌كنيم، هدف دستيابي به كاركردي خاص نمي‌باشد. زيران كاركرد‌ها در قالب يك ماژول يكتا نيز قابل دستيابي است. هدف ما از پياده سازي سيستم مبتني بر ماژول‌ها دستيابي به تعداد ويژگي كيفي در نرم‌افزار مي‌باشد.
همانطور كه در بخش‌هاي قبلي اشاره گرديد، معماري نرم‌افزار شامل ساختار يا ساختارهايي از سيستم مي باشد، كه در برگيرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بين آنها باشد. هدف از بيان سيستم نرم افزاری در قالب ساختار‌هاي گوناگون كه با هم داراي رابطه هستند، برآورده كردن نياز‌هاي كيفي مورد نظر در سيستم نرم‌افزار مي‌باشد.

3-2 ويژگي‌هاي كيفي
ويژگي‌هاي كيفي، نياز‌هايي از سيستم هستند كه جنبه غير كاركردي دارند(نیاز¬های غیر کارکردی). اين نياز‌ها در مراحل طراحي، پياده سازي و استقرار سيستم بايد مد نظر قرار گيرند[Bass 03]. در حقيقت، برآورده كردن اين ويژگي‌هاي كيفي، مستلزم توجه به آنها در مرحله طراحي، پياده سازي و استقرار است. به عنوان مثال ويژگي كيفي قابليت استفاده داراي جنبه‌هاي گوناگون است. استفاده از دكمه‌ها و نحوه چينش اجزاء تشكيل دهنده واسط كاربر، فعاليتي مربوط به پياده سازي محسوب مي‌گردد. در حالي كه قابليت بازگرداندن تغييرات انجام شده، يا فراهم آوردن امكان Cancel كردن فعاليت‌هاي نرم افزار توسط كاربر از جنبه‌هاي مربوط به معماري اين ويژگي كيفي محسوب مي‌گردد. با توجه به مطالب مطرح شده دو نكته مهم در زمينه ارتباط ويژگي‌هاي كيفي و معماري وجود دارد :

• معماري نرم‌افزار يكي از اجزاي حياتي فرايند توليد نرم‌افزار براي برآورده نمودن ويژگي‌هاي كيفي مي‌باشد. معماري بايد قابليت بيان مهمترين ويژگي‌هاي كيفي نرم‌افزار را داشته باشد و امكان ارزيابي آنها را در سطح معماري فراهم سازد.

• معماري نرم‌افزار به تنهايي قادر به برآورده ساختن نياز‌هاي كيفي نمي‌باشد، بلكه به عنوان بستري براي قرار دادن كيفيت در سيستم نرم‌افزار به كار مي‌رود. ويژگي‌هاي كيفي پس از معرفي در معماري نرم‌افزار، در مراحل بعدي توسعه نيز بايد مد نظر قرار گيرند.

بايد توجه داشت كه برآورده ساختن يك نياز كيفي، بر روي ديگر نياز‌هاي كيفي اثرگذار است. به عنوان مثال، سيستم‌اي كه داراي ويژگي كيفي امنيت مي‌باشد، معمولاً داراي ويژگي قابليت اطمينان نيز است. يا براي مثال سيستمي كه داراي كارايي مناسبي مي‌باشد، قابليت تغيير پايين‌تري مي‌باشد. در [With 02] ارتباط بين ويژگي‌هاي كيفي گوناگون بيان شده است.

معيار‌هاي كيفي را مي‌توان به دسته‌هاي گوناگون طبقه بندي نمود. در [Bass 03] معيارهاي كيفي كه در توسعه معماري نرم افزار تاثير گذاراند در سه دسته زير طبقه بندي شده اند :
• كيفيت سيستم ( availability، modifiability، performance، security، testability و usability )
• معيارهاي كيفي كسب و كار ( زمان تحويل به بازار و ... )
• معيارهاي كيفي نظير يكپارچگي منطقي معماري كه مستقيماً متوجه خود معماري مي‌باشد و به طور غير مستقيم بر روي كيفيت سيستم تاثيرگذار است.

همچنين در [Garland 03] معيارهايي علاوه بر معيارهاي فوق ارائه گرديده است :

• قابليت انطباق با فرهنگ‌هاي مختلف
• يكپارچگي داده اي
• قابليت نگهداري بالا
• قابليت سلامت ( Safety )
• قابليت مديريت
در [With 02] فهرست كاملي از ويژگي‌هاي كيفي گوناگون ارائه شده است.

معيار‌هاي كيفي مورد توجه ما، معيار‌هاي كيفي سيستم مي‌باشد. زيرا در اين گزارش، هدف طراحی معماري نرم‌افزار بوده و براي آن معماري سيستم بايد مورد ارزيابي قرار گيرد.

3-3 ويژگي‌هاي كيفي سيستم
ويژگي‌هاي كيفي سيستم، نياز‌هاي غيركاركردي مي‌باشند كه بر روي كاركرد‌هاي سيستم اثرگذار خواهند بود. تعريف ويژگي‌هاي كيفي به صورت كلي و در قالب نياز‌هاي غيركاركردي داراي مشكلات زير مي‌باشد :
• تعريف ويژگي كيفي قابل استفاده عملي نمي‌باشد. به عنوان مثال وقتي مي‌گوييم سيستم بايد قابليت تغيير داشته باشد، اين قابليت تغيير مي‌تواند شامل قسمت‌هاي مختلفي از سيستم گردد.
• در اين تعريف، مشخص نيست كه هر ويژگي كيفي چه زمينه‌هايي از سيستم را در بر مي‌گيرد. به عنوان مثال، قابليت خراب نشدن عمليات سيستم مي‌تواند در دسته ويژگي‌هاي قابليت در دسترس‌بودن، امنيت و قابليت اطمينان طبقه بندي شود.
• هريك از ويژگي‌هاي كيفي، داراي پارامتر‌هاي متفاوت مي‌باشند. به عنوان مثال، كارايي، داراي پارامتر‌هايي نظير "پيغام" هاي وارد شده به سيستم دارد. امنيت داراي حمله است و قابليت استفاده داراي پارامتري نظير ورودي كاربر مي‌باشد. همه اين پارامتر‌ها بيانگر يك عمل بر روي سيستم مي‌باشند ولي با لغات مختلف نشان داده شده اند.
براي حل اين مشكلات [Bass 03] مفهومي به نام سناريو‌هاي ويژگي كيفي را ارائه داده است. اين سناريو‌ها راه حلي براي بيان دقيق ويژگي‌هاي كيفي يك سيستم نرم‌افزار ارائه مي‌كنند.

3-4 سناريو‌هاي ويژگي‌كيفي
سناريو‌هاي ويژگي‌ كيفي، يك نياز غير كاركردي مي‌باشند. اين نياز‌ها به طور دقيق بيان شده اند و هر نياز مربوط به يك ويژگي كيفي خاص مي‌باشد. هر سناريو ويژگي كيفي از بخش‌هاي زير تشكيل شده است :
منبع محرك : اين بخش، موجوديتي است ( يك انسان، سيستم كامپيوتري يا ... ) كه عملي را در قبال سيستم انجام مي‌دهد. در حقيقت سيستم را تحريك مي‌نمايد.

محرك : محرك، شرايطي است كه وقتي رخ دهد، سيستم نرم‌افزاري بايد در قبال آن عملي را انجام دهد.
محيط : محيطي كه محرك در آن رخ مي‌دهد، بسته به شرايط سيستم مي‌تواند متفاوت باشد. به عنوان مثال سيستم مي‌تواند در شرايط حداكثر بار و يا در شرايط اجراي معمولي باشد. شرايط ديگر نيز مي‌تواند وجود داشته باشد.

محصول نرم‌افزاري : اين بخش بيانگر محصول نرم‌افزاري است كه محرك بر روي آن اثر گذار است. اين محصول مي‌تواند كل سيستم و يا بخشي از آن باشد.
پاسخ : پاسخ عملي است كه سيستم در قبال تحريك انجام مي‌دهد.
مقياس پاسخ : وقتي سيستم پاسخي در قبال محرك نشان مي‌دهد، اين پاسخ بايد قابل اندازه‌گيري باشد. اندازه گيري اين پاسخ، مشخص مي‌نمايد كه آيا نياز مربوط به سناريو برآورده شده است يا خير.

در [Bass 03] سناريو‌هاي كيفي به دو دسته زير طبقه بندي شده اند :
• سناريو‌هاي عمومي : سناريو‌هايي كه مستقل از نوع سيستم مي‌باشند. از اين سناريو ها براي مشخص كردن بخش‌‌هاي كلي يك ويژگي كيفي استفاده مي‌شود.

• سناريو‌هاي حقيقي : سناريو‌هايي هستند كه به طور خاص بيانگر نياز‌هاي سيستم تحت توسعه مي‌باشند.
در شكل2 بخش‌هاي تشكيل دهنده يك سناريو ويژگي كيفي ارائه شده است.

شكل 2 - بخش‌هاي تشكيل دهنده سناريو ويژگي كيفي

3-5 ويژگي‌هاي كيفي كسب و كار
علاوه بر ويژگي‌هاي كيفي سيستم نرم‌افزاري، تعداد ويژگي كيفي مرتبط با كسب و كار نيز وجود دارد كه بر شكل‌دهي معماري سيستم نرم‌افزاري اثر گذار است. اين ويژگي‌هاي كيفي شامل مواردي نظير هزينه‌ها، زمان بندي، و ملاحظات مربوط به بازاريابي مي‌باشد. در [Bass 03] تعداد از ويژگي‌هاي كيفي كسب و كار به شرح زير ارائه شده است :

• زمان دستيابي به بازار : زمان مورد نياز براي ارائه سيستم به بازار از عوامل تاثير گذار بر معماري است. به عنوان مثال براي سيستمي كه بايد به سرعت آماده ارائه به بازار شود، استفاده از بخش‌هايي هر سيستم‌هاي قبلي بسيار مهم است.

• هزينه و سود : بايد براي انتخاب معماري مورد نظر براي هر سيستم نرم‌افزاري، تحليل سود - هزينه انجام داد. به عنوان مثال استفاده از معماري كه قابليت تغيير بالايي دارد، قطعاً هزينه بيشتري براي سازمان به همراه خواهد داشت. بنابراين بايد سود استفاده از هر معماري را در مقابل هزينه‌هاي آن بررسي نمود.
• زمان انجام پروژه و ماندگاري پروژه : در صورتي كه پروژه در بازه زماني بالايي انجام مي‌گردد و يا در آينده قرار است سيستم‌هاي زيادي بر پايه معماري سيستم در حال توسعه ايجاد شود، معماري سيستم در حال توسعه بايد داراي قابليت تغيير و انعطاف بالايي باشد.

• بازار هدف : براي به دست گرفتن بازار و رقابت با ديگر محصولات بايد ويژگي‌هاي كيفي نرم‌افزار را ارتقاء داد. همچنين هر بازار، به يك ويژگي كيفي خاص توجه مي‌كند. به عنوان مثال، بازار‌هاي عمومي، به ويژگي كيفي قابليت استفاده توجه خاص دارند ولي بازار‌هاي تخصصي و حساس به ويژگي‌هاي كيفي قابليت اطمينان نياز بيشتري دارند.
• برنامه ارائه نرم‌افزار در فاز‌هاي متفاوت : در صورتي كه نرم‌افزار بايد در فاز‌هاي متفاوت و به صورت افزايشي توسعه داده شود، قابليت تغيير و انعطاف معماري از اهميت ويژه اي برخوردار است.
• يكپارچه سازي با سيستم‌هاي موجود : در صورتي كه سيستم در حال توسعه مي‌خواهد با سيستم‌هاي موروثي يكپارچه شود، بايد مكانيزم‌هاي يكپارچه سازي در آن به كار برد.

3-6 ويژگي‌هاي كيفي معماري
در [Bass 03] تعداد ويژگي كيفي ارائه شده كه مرتبط با كيفيت كلي معماري نرم‌افزار مي‌باشد. اين ويژگي‌ها عبارتند از :
• يكپارچگي مفهومي : يكپارچگي مفهومي به معناي هماهنگ بودن و يكسان بودن روش‌ها به كاربرده شده در معماري نرم‌افزار مي‌باشد. به عنوان مثال سيستم نرم‌افزاري كه برخي از بخش‌هاي آن با استفاده از تكنيك‌هاي شيء گرا و برخي ديگر از بخش‌هاي آن توسط تكنيك‌هاي غيرشيء گرا توليد شود، داراي يكپارچگي مفهومي نيست.

• صحيح بودن و كامل بودن : معماري نرم‌افزار بايد كامل و صحيح باشد. به اين معني كه بايد مدل‌هاي توليد شده از نظر نحوي و مفهومي داراي ويژگي‌هاي لازم باشند. همچنين همه ساختار‌هاي لازم براي ارائه معماري كامل باشد.
3-7 يك طراحی معماری خوب بايد داراي چه ويژگي‌هايي باشد؟‌

از نظر ما يك معماري خوب، معماري است كه ويژگي‌هاي كيفي اشاره شده در فوق، در آنها برآورده شود. بايد توجه داشت كه ويژگي‌هاي كيفي كسب و كار، در صورت برآورده شدن ويژگي‌هاي كيفي سيستم، برآورده خواهند شد. همچنين بين برآورده شدن ويژگي‌هاي كيفي سيستم و ويژگي‌هاي كيفي معماري رابطه مستقيم برقرار است ولي دستيابي به ويژگي‌هاي كيفي سيستم به معناي دستيابي به ويژگي‌هاي كيفي معماري نمي‌باشد. زيرا يك معماري مي‌تواند ويژگي‌هاي كيفي سيستم نظير كارايي، قابليت تغيير و ... را برآورده ساخته ولي از نظر مفهومي داراي يكپارچگي نباشد.

بنابراين معماري خوب، بايد ويژگي‌هاي كيفي سيستم و معماري را برآورده نمايد. كه در اين بين پارامتر ويژگي‌هاي كيفي سيستم از اهميت ويژه‌اي برخوردار است. بنابراین برای طراحی معماری، یکی از ورودی¬های ضروری ویژگی¬های کیفی سیستم می¬باشد. برای اندازه گیری میزان برآورده شدن ویژگی¬های کیفی، تکنیک¬های گوناگونی وجود دارد. یکی از روش¬های مرسوم، ارزیابی معماری نرم افزار می¬باشد. همچنین در [Chastek 05] در مورد امکان معرفی تعدادی سنجه برای اندازه گیری ویژگی¬های کیفی در معماری نرم افزار بحث شده است ولی هنوز سنجه دقیقی برای اندازه گیری معماری معرفی نشده است.

3-8 دستیابی به ویژگی¬های کیفی

برای دستیابی به ویژگی¬های کیفی، روش ها و تکنیک گوناگونی وجود دارد. دو تکنیک مطرح در این زمینه استفاده از تاکتیک¬ها و الگو¬ها (سبک¬ها) معماری می¬باشد.

تاکتیک¬های معماری
برای دستیابی به ویژگی کیفی، باید تصمیماتی مربوط به نحوه طراحی معماری اتخاذ نمود. به این تصمیمات پایه تاکتیک معماری نامیده می¬شوند. در حقیقت تاکتیک یک تصمیم طراحی است که با اعمال آن بر روی معماری، می¬توان پاسخ ویژگی کیفی را کنترل نمود و آن را به میزان مورد نظر تبدیل نمود [Bass03]. باید توجه داشت که تصمیمات معماری را می¬توان به دو دسته تقسیم نمود. برخی از تصمیمات طراحی برای دستیابی به کارکرد مورد نظر می¬باشد و برخی از تصمیمات برای کنترل پاسخ ویژگی کیفی. در اینجا منظور از تاکتیک ها، مورد دوم می¬باشد.

به هر ویژگی کیفی می¬توان تعدادی تاکتیک معماری نسبت داد و هنگام طراحی معماری با توجه به خاصیت تاکتیک مورد نظر از آن استفاده نمود. به عنوان مثال برای ویژگی کیفی قابلیت تغییر و کارایی می¬توان تاکتیک¬های ارائه شده در شکل 3 و 4 را در نظر گرفت. این تاکتیک ها با توجه به نوع کاربرد در سه دسته طبقه بندی شده اند.
شکل 3 – خلاصه¬ای از تاکتیک¬های قابلیت تغییر

شکل 4 – خلاصه¬ای از تاکتیک¬های کارایی
الگو¬های معماری
الگوهای معماری، یا سبک¬های معماری دارای مفهومی مشابه با سبک های معماری در ساختمان می¬باشند. به عنوان مثال در ساختمان سبک¬های معماری نظیر : یونانی، ایتالیایی و ... وجود دارد. هر سبک معماری دارای یک یا چندین ویژگی کلیدی و قوانینی برای ترکیب آن¬ها می¬باشد. هر الگوی معماری با اجزای زیر تعریف می¬شود :
• مجموعه ای از اجزاء ( به عنوان مثال محل ذخیر سازی داده، اجزاء محاسباتی و ... )
• توپولوژی ارتباطی اجزاء با یکدیگر شامل ارتباط¬ها، پروتکل ارتباطی و ...
• مجموعه ای از قیود منطقی ( به عنوان مثال در الگومعماری لوله و فیلتر لوله ها انتقال دهنده داده ها هستند و به طور افزایشی داده ورودی را به خروجی تبدیل می¬کنند. همچنین جهت حرکت داده ها در لوله¬ها نشان داده نمی¬شود. )
• مجموعه ای از مکانیزم¬های تبادل اطلاعات ( به عنوان مثال فراخوانی روتین، تخته سیاه و ... ) که مشخص کننده نحوه ایجاد هماهنگی بین اجزا در توپولوژی معرفی شده می¬باشد.

در [Shaw 96] مجموعه ای از مهمترین الگو¬ها یا سبک¬های معماری که می¬تواند در طراحی معماری نرم افزار سودمند باشد، معرفی شده است. این مجموعه در شکل 5 نشان داده شده است.

شکل 5 - مجموعه ای از مهمترین الگو¬های معماری

ارتباط تاکتیک¬ها و الگو¬های معماری
تاکتیک ها و الگو¬های معماری دارای ارتباط مستقیمی با یکدیگر می¬باشند. یک الگو یا سبک معماری، مجموعه ای از تاکتیک های مرتبط با یکدیگر را برای دستیابی به یک ویژگی خاص کنار هم جمع می¬نماید. به عنوان مثال برای دستیابی به ویژگی کیفی در دسترس بودن، می توان از تاکتیک تکرار استفاده نمود. اما باید توجه داشت استفاده از این تاکتیک به تنهایی کافی نمی¬باشد زیرا در صورت ارائه تکرار باید روشی برای همسان سازی نسخه های تکراری نیز معرفی نمود. بنابراین می¬توان مجموعه این دو تاکتیک را به عنوان یک الگو یا راهبرد معماری مورد استفاده قرار داد. در [Bass 01] از الگو¬های معماری به عنوان سازنده¬های ویژگی¬های کیفی نام برده شده است. باید توجه داشت که یکی از مسائل مرتبط با استفاده از الگو¬های معماری این است که هر الگو علاوه بر تاثیرات مثبت بر ویژگی¬های کیفی مورد نظر، ممکن است تاثیر منفی بر چند ویژگی کیفی داشته باشد.

با استفاده همزمان از این دو مفهوم می¬توان به طراحی معماری نرم¬افزار پرداخت. در بخش 4 روش¬های گوناگونی برای طراحی معماری نرم افزار با استفاده از مفاهیم تاکتیک¬ها و الگو¬ها ارائه می¬گردد.

4 روش¬های طراحی معماری نرم افزار
در این بخش به بررسی روش¬های طراحی معماری نرم افزار خواهیم پرداخت. در این مرحله از فرایند تولید معماری سیستم فرض می شود که نیازهای سیستم به همراه ویژگی های کیفی مورد نظر تعیین شده اند و می¬خواهیم معماری سیستم را ایجاد کنیم. برای این کار روش-های گوناگونی پیشنهاد شده است که در اینجا برخی از آنها را بررسی می کنیم.

4-1 طراحی مبتنی بر ویژگی¬
طراحی مبتنی بر ویژگی [Bass 01]، به عنوان ورودی نیاز¬های سیستم (کارکردی و ویژگی¬های کیفی) را دریافت کرده و خروجی آن طراحی منطقی (نه دقیق) معماری می باشد(شکل 6). بنابراین این روش در فرایند توسعه سیستم می¬تواند پس از به دست آوردن نیازهای سیستم انجام شود.

شکل 6 – ورودی¬ها و خروجی¬های روش ADD

در این روش طراحی معماری نرم افزار با طی مراحل زیر انجام می شود :
1 – یک عنصر طراحی برای تجزیه شدن انتخاب می¬شود. این عنصر معمولاً در ابتدای فرایند طراحی، کل سیستم است. در این حالت باید همه ورودی¬های لازم برای انجام عمل طراحی (محدودیت¬ها، نیاز¬های کارکردی و ویژگی¬های کیفی) مشخص باشد.
2 – عنصر ایجاد شده با طی مراحل زیر پایش می¬شود :

2-1- ابتدا پیشبرنده¬های معماری از مجموعه سناریو¬های ویژگی¬های کیفی و نیاز¬های کارکردی انتخاب می¬شوند. در حقیقت این مرحله مشخص می¬کند که برای انجام عمل تجزیه چه چیزی حائز اهمیت است.

2-2- الگوی معماری که برآورده کننده پیشبرنده¬های معماری مورد نظر است انتخاب می¬شوند. این الگو¬ها معمولاً با توجه به تاکتیک¬های لازم برای برآورده کردن پیشبرنده مورد نظر، انتخاب یا ایجاد می¬شوند. همچنین در این مرحله زیر ماژول¬های لازم برای به کار بردن تاکتیک¬های مورد نظر مشخص می¬شوند.
2-3- ماژول¬های مورد نظر ایجاد شده و کارکرد¬های لازم برای هر ماژول با توجه به موارد کاربرد به آن¬ها اختصاص داده میشوند.

2-4- برای زیر ماژول¬ها، واسط هایی انتخاب می¬شود. همچنین تجزیه انجام شده، محدودیت¬هایی را بر روی ارتباطات بین ماژول¬ها ایجاد می¬کند. این اطلاعات در این مرحله مستند می¬شوند.
2-5- در این مرحله زیر ماژول¬ها با توجه به کارکردها و ویژگی¬های کیفی مجدداً مورد بررسی قرار می¬گیرند تا اطمینان حاصل شود که برآورده کننده نیاز¬های مورد نظر می¬باشند.
3 – مراحل فوق را برای ماژول¬های ایجاد شده تکرار نمایید.

4-2 طراحی به کمک سبک های معماری مبتنی بر ویژگی¬
در روش طراحی مبتنی بر ویژگی، یک چارچوب کلی برای نحوه طراحی سیستم پیشنهاد گردید و در آن معماری نرم افزار به کمک عمل تجزیه و استفاده از الگو¬ها یا سبک¬های معماری طراحی گردید. در طراحی به کمک سبک¬های معماری مبتنی بر ویژگی، به جای استفاده از الگو¬ها یا سبک های معماری، استفاده از مفهومی به نام سبک¬های معماری مبتنی بر ویژگی [Klein 99] پیشنهاد شده است.

سبک¬های معماری در حقیقت مجموعه ای از اجزاء و ارتباط دهنده ها بودند که کلاس-های طراحی را تشکیل می¬دادند. این سبک¬ها به همراه خود توصیفی غیر رسمی و غیر صریح از نقاط قوت و ضعف استفاده از سبک را نیز دارا بودند. استفاده از این سبک¬ها امکان استفاده از تجربیات گذشته را برای معماران نرم¬افزار فراهم می¬آورد.

در سبک¬های معماری مبتنی بر ویژگی یا ABAS، هدف تبدیل سبک معماری به ابزاری است که بتوان به کمک آن در مورد طراحی انجام شده و کیفیت آن اظهار نظر نمود. برای دستیابی به این هدف، در ABAS به هر سبک معماری یک چارچوب استدلال نسبت داده می¬شود که به کمک آن می¬توان میزان در مورد طراحی مورد نظر استدلال انجام داد. برای هر ویژگی کیفی می¬توان یک چارچوب استدلال مبتنی بر مدل¬های آن ویژگی کیفی اختصاص داد. این مدل¬ها عموماً برای هر ویژگی کیفی توسط متخصصین حوزه مربوطه ایجاد می¬شوند. در ادامه به بررسی ساختار ABAS ها و نحوه استفاده از آنها می¬پردازیم. در معرفی بخش های مختلف ABAS از یک ABAS به نام خط لوله همزمان استفاده می¬کنیم. این ABAS نوعی از الگوی معماری لوله و فیلتر معرفی شده در [Shaw 96] می باشد که می-توان از آن در ساخت سیستم¬های بلادرنگ استفاده نمود. این معماری را می¬توان شامل چندین لوله و فیلتر موازی دانست.
هر ABAS از چهار بخش زیر تشکیل می¬شود:

• توصیف مسئله : به طور غیر رسمی به توصیف مسئله¬ای که باید توسط ABAS حل شود شامل : ویژگی¬ کیفی مورد نظر، حوزه مورد استفاده، محدودیت ها و نیاز¬های خاص مربوط به هر ویژگی کیفی می¬پردازد.
در مثال ABAS همگام سازی بخش شرح مسئله به صورت زیر خواهد بود :
در ABAS خط لوله همزمان، هدف ارائه سبک معماری می¬باشد که در آن مجموعه ای از لوله و فیلترها (لوله و فیلتر شامل حرکت داده ای به عنوان ورودی، انجام پردازش¬های متوالی به روی آن و تولید خروجی می¬باشد) می¬باشد که به صورت همزمان و بر روی یک سیستم تک پردازنده فعالیت می¬کنند. در این سیستم هر پردازه شامل داده ورودی خاص خود بوده و باید خروجی خود را در زمانی مشخص تحویل دهد.

• محرک و سنجه پاسخ ویژگی کیفی : شامل توصیف محرکی که ABAS باید به آن پاسخ دهد و همچنین سنجه پاسخ ویژگی کیفی در قبال محرک می¬باشد.
برای مثال مورد بررسی محرک و پاسخ به شرح زیر می¬باشد :
محرک : ورود متوالی و یا نامشخص پیغام¬ها
پاسخ : بد ترین زمان ممکن برای پردازش پیغام

• الگوی معماری : توصیفی از سبک¬ معماری مورد استفاده شامل اجزا و ارتباط دهنده¬ها، ویژگی های آنها، الگو¬های ارتباط بین اجزا و محدودیت¬های بین آنها می-باشد.
الگوی معماری مورد استفاده در مثال مورد بررسی در شکل 7 نشان داده شده است. در این الگو چندین پیغام به طور همزمان وارد اولین پردازه هر سری می¬شود. این پیغام ها با الگوریتم FIFO در صف قرار داده می¬شوند و وقتی به سر صف برسند مورد پردازش قرار خواهند گرفت. هر سری در این الگو در حقیقت یک لوله و فیلتر می¬باشد.

شکل 7 – الگوی معماری خط لوله همزمان

پارامتر¬های این الگوی معماری در جدول 1 ارائه شده است. این جدول پارامتر¬هایی را که بخش بعد برای ارزیابی الگو مورد استفاده قرار می¬گیرند معرفی می¬کند.

جدول 1 – پارامتر¬های الگوی خط لوله همزمان
پارامتر¬های مربوط به کارایی معماری
توپولوژی : خط لوله (ها)
سیاست اجرا : اجرا بر اساس اولویت
زمان لازم برای پردازش هر ورودی برای هر پردازه : Ci
استراتژی اولویت بندی : دنباله اولویت ها در خط لوله
سیاست زمان بندی پردازه ¬ها : اولویت بندی ثابت

• ارزیابی : توصیفی از اینکه چگونه ویژگی¬های کیفی به صورت فورمال در ارتباط با الگوی معماری می¬باشد و روشی برای نتیجه گیری کلی در باره رفتار معماری با استفاده از الگوی معرفی شده.

در مثال مورد بررسی، در این بخش با توجه به پارامتر¬های ارائه شده در بخش قبل امکان آنالیز فورمال مدل را برای به وجود خواهد داشت. با توجه به اینکه آنالیز فورمال از حوزه این گزارش خارج می¬باشد برای مشاهده جزئیات بیشتر به [Klien 99] مراجعه شود.

4-3 طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه
در روش¬های معرفی شده در فوق، هدف اصلی ایجاد بهترین طراحی بدون توجه به هزینه به کار بردن یک سبک یا الگوی معماری بود. در روش CBAM مي‌خواهيم با توجه به محدوديت‌هاي موجود در زمينه هزينه‌ها، بهترين روش‌ها و راهبرد‌ها را براي برآورده ساختن معيار‌هاي كيفي انتخاب نماييم. در حقيقت خروجي اين روش، فهرستي از راهبرد‌هاي معماري است كه به ترتيب سودمندي مرتب شده اند. روش CBAM در مراجع عموماً به عنوان یکی از روش¬های ارزیابی معماری نرم افزار معرفی می¬گردد. اما با توجه به رابطه مستقیم بین روش¬های طراحی و ارزیابی معماری، این روش می¬تواند هم در مرحله طراحی و هم در مرحله ارزیابی معماری نرم افزار مورد استفاده قرار گیرد. در صورتی که از این روش در مرحله ارزیابی معماری استفاده شود، پیشنهاد می¬شود که قبل از آن ارزیابی معماری به کمک روش ATAM انجام گیرد.

ورودي‌هاي و پيشنياز‌هاي روش CBAM : مهمترین ورودی¬های این روش عبارتند از :
• مهمترين اهداف كسب و كار و سيستم
• سناريو‌هاي كيفي به دست آمده در مراحل تهیه نیازها
• فهرستي از تصميمات معماري (تاكتيك‌ها و راهبرد‌ها)
• محدوديت‌هاي اقتصادي پروژه

مراحل انجام طراحی به روش CBAM : روش CBAM شامل 2 فاز مي‌گردد[Asundi 01] . هر 2 فاز اين روش داراي مراحل يكساني هستند. اما در فاز اول همه محاسبات به صورت كلي انجام شده و هدف از آن پالايش راهبرد‌هاي معماري مي‌باشد. زيرا گزينه‌هاي موجود براي راهبرد‌ها ممكن است زياد باشد و انجام مراحل دقيق CBAM براي همه راهبرد‌ها عملي هزينه بر است. خروجي فاز اول CBAM فهرستي از راهبرد‌هاي معماري و اثرآنها بر روي سناريو‌هاي كيفي است. به اين منظور درجه اهميت هر سناريو مشخص شده و اثر هر راهبرد‌معماري بر روي سناريو با مقادير (++ ، + ، 0 ، - ، -- ) مشخص مي‌گردد. در ضمن هزينه هر راهبرد معماري با علامت (H, M, L) نمايانگر (پايين، متوسط، بالا) مشخص مي‌گردد. نمونه اي از اين عمليات در جدول 2 نشان داده شده است.

جدول 2 – خروجی فاز اول روش CBAM
راهبرد معماري قابليت تغيير
(50) در دسترس بودن
(30) كارايي
(20) هزينه
راهبرد 1 -- + ++ L
راهبرد 2 -- 0 + M
راهبرد 3 ++ 0 - H

بعد از مشخص نمودن اثر راهبرد‌ها بر هريك از سناريو‌ها، مي‌توان راهبرد‌ها را با توجه به اهميتشان در مقابل هزينه در نموداري نظير شكل 8 مشخص نمود.

شكل 8 - نمودار مقايسه ميزان كاربرد هر راهبرد در مقابل هزينه

پس از مشخص نمودن امتياز هر راهبرد و سناريو، مي‌توان وارد فاز ارزيابي شد. مراحل اين فاز عبارتند از[Kazman 02] :

مرحله 1 - جمع آوري سناريو‌ها و راهبرد‌ها : در اين مرحله سناريو‌هايي كه در کیفی جمع آوري مي‌شوند. در اين مرحله بايد مهمترين سناريو‌ها انتخاب گردند. براي اينكار از سناريو‌هاي امتياز دهي شده در بخش قبل استفاده مي‌شود. معمولاً حدود يك سوم سناريو‌ها براي مرحله بعد انتخاب مي‌شوند.

مرحله 2 - پالايش سناريو‌ها : در اين مرحله براي هر سناريو‌، پاسخ آن در چهار حالت زير مشخص مي‌گردد‌ :
• بدترين حالت
• وضعيت موجود يا وضعيتي كه به راحتي قابل تامين است.
• وضعيت مطلوب
• بهترين حالت

مرحله 3 - اولويت بندي سناريو‌ها : پس از مشخص نمودن موارد فوق، نتايج در اختيار ذينفعان سيستم قرار گرفته و آنها سناريو‌ها را مجدداً اولويت بندي مي‌كنند. به اين منظور به هر شركت كننده 100 حق راي داده مي‌شود. هر شخص مي‌تواند 100 راي خود را بر روي يك يا چند سناريو خرج نمايد. پس از مشخص شدن راي هر سناريو، به سناريو با بالاترين راي امتياز 1 و باقي سناريو‌ها نيز بر اساس بالاترين امتياز، نرمال مي‌شوند. پس از مشخص شدن امتياز‌ها، 50 درصد سناريو‌ها براي مراحل بعد انتخاب مي‌گردند.

مرحله 4 - مشخص نمودن سودمندي هر سناريو : در اين مرحله براي پاسخ‌هاي مشخص شده در مرحله 2، عددي به عنوان سودمندي تعيين مي‌كنيم. به عنوان مثال مي‌گوييم اين سناريو در حالت موجود براي ما 20% سودمندي دارد. در اين روش، ميزان سودمندي عددي بين 0 الي 100 خواهد بود. صفر بيانگر بدون سودمندي و 100 بيانگر سودمندي كامل خواهد بود. عمل تخصيص سودمندي نيز توسط هريك از ذينفعان انجام مي‌شود. به اين ترتيب كه هريك از افراد ميزان سودمندي را مشخص كرده و سپس ميانگين آن محاسبه مي‌شود.

مرحله 5 - مشخص نمودن راهبرد‌هاي معماري و اثر هر راهبرد بر پاسخ سناريو‌ها : در اين مرحله، راهبرد‌هاي معماري را مشخص خواهيم كرد كه بر روي پاسخ هر سناريو موثر هستند. سپس تعيين مي‌كنيم كه هر راهبرد چه اثري بر روي سناريو خواهد داشت. ( در صورتي كه راهبرد بر روي چندين سناريو اثر گذار باشد، براي هر سناريو پاسخ متاثر از راهبرد را تعيين مي‌كنيم ).

مرحله 6 - محاسبه سودمندي هر راهبرد معماري : در اين مرحله، با توجه به پاسخ ايجاد شده براي هر سناريو در اثر يك راهبرد معماري، سودمندي راهبرد مذكور را در ارتباط با هر سناريو به دست مي‌آوريم. با توجه به مقادير محاسبه شده در مرحله 4، مي‌توان نمودار تقريبي سودمندي يك سناريو را به دست آورد. پس از تعيين نمودار سودمندي و استفاده از درونيابي، مقدار تقريبي سودمندي راهبرد به دست مي‌آيد. در شكل 9، نمونه‌هايي از نمودار‌هاي ممكن براي سودمندي بر اساس پاسخ ارائه شده است.

شكل 9 - انواع نمودار‌هاي ممكن براي سودمندي براساس پاسخ

مرحله 7 - محاسبه سود كلي حاصل از يك راهبرد : در اين مرحله با استفاده از سودمندي هر رويكرد در ارتباط با سناريو‌هاي مربوطه و وزن هر سناريو، سودمندي كلي يك راهبرد را محاسبه مي‌كنيم. براي اين منظور از روابط زير بهره مي‌گيريم :

به طوري كه داشته باشيم :

مرحله 8 - انتخاب رويكرد‌ها بر اساس ROI : در اين مرحله هزينه‌هاي هر رويكرد را محاسبه مي‌كنيم ( براي اين منظور از روش‌هاي معمول تخمين هزينه مانند LOC و يا Function Point استفاده مي‌كنيم ). پس از محاسبه هزينه‌ها ROI هر رويكرد را از رابطه زير به دست مي‌آوريم :


حال به ترتيب رويكرد‌هايي با بالاترين ROI را انتخاب مي‌كنيم. معمولاً اين كار تا زماني انجام مي‌شود كه همه سناريو‌هاي مورد نظر توسط يك راهبرد پوشش داده شوند و يا هزينه‌هاي انجام شده براي راهبرد‌ها بيش از بودجه مربوط به راهبرد‌ها در پروژه گردد.

مرحله 9 - بررسي نتايج با واقعيت : در اين مرحله نتايج را بررسي كرده و مشخص مي‌كنيم كه آيا همه اهداف كسب و كار توسط راهبرد‌هاي انتخاب شده برآورده شده است يا خير. سپس در صورت وجود اشكال به بازبيني مراحل قبلي مي‌پردازيم.

5 ويژگي كيفي قابليت تغيير
در این بخش ویژگی کیفی قابلیت تغییر را به عنوان یک ویژگی کیفی نمونه انتخاب کرده و آن را تعریف خواهیم نمود. سپس تاکتیک¬های موجود برای دستیابی به آن را بررسی خواهیم کرد و نحوه ارزیابی یک معماری که دارای ویژگی کیفی قابلیت تغییر است را ارائه می کنیم. با توجه به مطالب ارائه شده در این بخش، در بخش 6 یک سیستم که دارای ویژگی کیفی قابلیت تغییر است به عنوان مطالعه موردی انتخاب شده و معماری آن طراحی می گردد.

5-1 تعريف قابليت تغيير
ويژگي كيفي قابليت تغيير، معماري را از ديدگاه هزينه تغييرات بررسي مي‌كند. يك معماري را قابل تغيير مي‌نامند، در صورتي كه تغييرات در بخش كوچكي از آن اثر گذار باشد و با هزينه كمي انجام شود[Bachmann 02].

تغييرات، داراي سه جنبه مختلف مي‌باشند :
• تغيير چيست ؟ بايد مشخص گردد كه تغيير شامل چه بخشي از نرم افزار است ؟ به عنوان مثال تغييرات مي‌تواند بر روي واسط كاربر يا سيستم عامل انجام شود. همچنين ممكن است بخش جديدي به سيستم اضافه شده، حجم سيستم افزايش و يا كاهش يافته باشد.
• تغيير دهنده كيست ؟ بايد مشخص گردد كه تغيير توسط چه كسي انجام مي شود. به عنوان مثال تغيير ممكن است توسط توسعه دهنده با تغيير كد، توسط مدير سيستم با تغيير پيكربندي و يا توسط كاربر با تغيير ويژگي‌هاي قابل تغيير سيستم، انجام شود.
• در چه زمان تغيير واقع مي‌شود؟ سيستم مي‌تواند در زمان توسعه، در زمان پيكربندي اوليه، در زمان نصب، در زمان آغاز به كار و در زمان اجرا تغيير كند. ما در اينجا به بررسي تغييرات انجام شده در زمان توسعه سيستم مي‌پردازيم.

5-2 مشخص نمودن نياز‌هاي قابليت تغيير با استفاده از سناريو‌هاي كيفي
براي طراحي يك معماري با قابليت تغيير، ابتدا نياز‌هاي مربوطه با استفاده از سناريو‌هاي كيفي قابليت تغيير مشخص مي‌شوند. اين سناريو‌ها حداقل بايد داراي دو بخش باشند. بخش اول، محرك سناريو است. محرك عامل ايجاد تغيير مي‌باشد. بخش دوم پاسخ سناريو است كه مشخص كننده هزينه تغيير است. (عموماً اين هزينه در قالب تعداد ماژول‌هايي كه بايد تغيير كنند مشخص مي گردد. )

سه پارامتر كلي را مي‌توان در مورد تغييرات مد نظر قرار داد :
• احتمال تغيير : به عنوان مثال با چه احتمالي ممكن است سيستم عامل مورد استفاده تغيير كند.
• فواصل تغييرات : به عنوان مثال با چه فواصل زماني ممكن است درخواست تغيير در يكي از ويژگي‌هاي سيستم بوجود آيد.
• وابستگي : به عنوان مثال آيا اضافه كردن يك وسيله جانبي جديد، نياز به تغيير در واسط كاربر را نيز ايجاد مي‌نمايد يا خير؟

5-3 مدل سازي قابليت تغيير در سطح معماري نرم افزار
براي مدلسازي قابليت تغيير در سطح معماري از دو مولفه زير استفاده مي‌كنيم :
• ماژول نرم افزار : يك ماژول، يك قطعه نرم افزاري است كه يك كاركرد را به طور كامل ارائه مي‌دهد. هر ماژول داراي تعدادي واسط و همچنين تعداد وظيفه است.
• ارتباط بين ماژول ها‌ : در صورتي كه تغيير در ماژول A، نيازمند تغيير در B نيز باشد، مي‌گوييم دو ماژول با هم در ارتباط هستند.

براي اندازه گيري اثرات تغييرات با استفاده از اين دو پارامتر، با توجه به ميزان سختي در انجام تغييرات در يك ماژول، به آن يك وزن اختصاص مي‌دهيم. مثلاً ماژولي كه انجام تغييرات در آن ساده است وزن 1 خواهد گرفت. سپس با توجه به ارتباطات بين ماژول‌ها، جمع وزن ماژول‌هاي مرتبط را محاسبه كرده تا درجه سختي انجام يك تغيير و اثر آن را محاسبه نماييم.

5-4 تاكتيك‌هاي قابليت تغيير
تاكتيك‌هاي قابليت تغيير را مي‌توان به سه دسته تقسيم نمود :
• تاكتيك‌هايي كه تغييرات را محلي مي‌نمايند.
• تاكتيك‌هايي كه ميدان ديد وظايف را كاهش مي‌دهند.
• تاكتيك‌هايي كه از پخش شدن تغييرات جلوگيري مي‌كنند.

به عنوان مثال يك سيستم نرم افزاري را در نظر بگيريد كه از يك معماري سه لايه تبعيت مي‌كند. هر لايه در قالب يك ماژول مستقل پياده سازي شده است و ماژول‌ها از طريق واسط‌ها با هم مرتبط هستند. (شكل 10)

شكل 10 - معماري سه لايه

در اين معماري مي‌توان انواع تاكتيك‌ها را به صورت زير مشاهده نمود :
• وظايف در قالب لايه‌هاي مختلف تقسيم شده اند. در صورتي كه تغييرات بر روي هر لايه انجام شود، تغييرات آسان خواهد بود. در صورتي كه تغييرات بر روي جزئيات پياده سازي هر ماژول باشد ( نه بر روي واسط ها ) تغييرات بر روي ماژول‌هاي ديگر اثرگذار نيست.
• چگونگي تعريف واسط، بخش‌هايي كه قابل رؤيت هستند و بخش‌هايي كه پنهان هستند، اثر چشمگيري بر روي قابليت تغيير دارند.
• در اين معماري، لايه وسط، مي‌تواند به عنوان سدي براي جلوگيري از پخش‌ شدن تغييرات از لايه بالا به پايين و برعكس عمل نمايد.

در ادامه هريك از سه گروه تاكتيك اشاره شده را مورد بررسي قرار خواهيم داد.

5-5 تاكتيك‌هايي كه تغييرات را محلي مي‌كنند.
نحوه اختصاص وظايف به ماژول‌ها، اثر چشمگيري بر روي هزينه تغييرات دارد. با توجه به نوع توزيع وظايف بين ماژول‌ها، يك درخواست تغيير مي‌تواند موجب ايجاد تغيير در يك ماژول و يا چند ماژول گردد. هدف از تاكتيك‌هاي ارائه شده در اين بخش، حداقل ساختن اثر تغيير بر تعداد ماژول‌ها مي‌باشد.
برقراري ارتباط مفهومي : در اين روش، وظايفي كه از لحاظ مفهومي، مشابه يكديگر هستند در يك ماژول جاي خواهند گرفت. اين امر، موجب مي‌شود كه در صورتي كه تغييري در يكي از وظايف سيستم رخ دهد ( اين تغيير احتمالاً بر روي چندين ماژول كه از لحاظ معنايي شبيه به هم هستند اثر گذار خواهد بود)، اين تغيير محدود گردد. يكي از مثال‌هاي اين تاكتيك، جدا سازي سرويس‌هاي معمول ( كه توسط بسياري از ماژول‌ها استفاده مي گردند. ) در قالب يك ماژول مي‌باشد.

جداسازي تغييرات قابل پيش بيني : در اين تاكتيك، بخش‌هايي از نرم افزار كه امكان ايجاد تغيير در آنها بالا است، از بخش هايي كه احتمال تغيير در آنها كم است، جدا مي‌گردد. به اين ترتيب معماري به دو بخش ثابت و متغير تبديل خواهد شد.

افزايش سطح تجرد : با بالابردن سطح تجرد در يك ماژول، و عام كردن فعاليت‌ آن مي‌تواند ميزان تغييرات در آن ماژول را كاهش داد. براي مثال در صورتي كه ماژول با توجه به نوع ورودي، بتواند فعاليت مناسب را انجام دهد، نياز به تغييرات در آن كمتر به وجود خواهد آمد و تغييرات را مي‌توان با تغيير در ورودي‌ها اعمال نمود.

محدود نمودن گزينه‌ها [Bass 2003] : تغييرات بر روي معماري مي‌تواند دامنه وسيعي داشته باشد. با محدود كردن اين تغييرات مي‌توان از گسترش آنها جلوگيري نمود. به عنوان مثال در صورتي كه در يك معماري نياز به تغيير پردازنده باشد، مي‌توان تغييرات را با قرار دادن قوانيني محدود نمود. به عنوان مثال مي‌توان اعلام نمود كه پردازنده جديد بايد داراي دستورات مشابهي با پردازنده اصلي باشد.

5-6 تاكتيك‌هايي كه ميدان ديد وظايف را كاهش مي دهند.
در صورتي كه تغييري در يك ماژول رخ دهد و ديگر ماژول‌ها بتوانند اين تغيير را مشاهده كنند، ماژول‌هاي ديگر هم بايد تغيير پيدا كنند. بنابراين محدود كردن ميدان ديد تغيير در ماژول‌ها بسيار مهم مي‌باشد.

پنهان‌سازي اطلاعات : اين تاكتيك، شامل تقسيم بندي ماژول به دو بخش مي‌باشد. در اين روش، ماژول به دو بخش عمومي و خصوصي تقسيم مي‌شود. هدف از انجام اين تاكتيك، ارائه جزئيات كمتري از ماژول، به ماژول‌هاي ديگر مي باشد.

حفظ واسط هاي موجود : در اين تاكتيك، سعي بر حفظ واسط هاي سابق مي شود. در صورتي كه ماژول تغيير يابد، سعي مي كنيم با اضافه كردن واسط هاي جديد و يا ايجاد نسخه‌هاي گوناگون از واسط، مفهوم واسط هاي سابق را حفظ نماييم.

جدا سازي واسط ها از پياده سازي : در اين روش، واسط ها در مرحله پياده سازي مشخص نمي‌شوند بلكه واسط‌ها در سطحي بالاتر طراحي شده و تغييرات احتمالي در پياده سازي بر روي طراحي واسط‌ها تاثير گذار نخواهد بود.

5-7 تاكتيك‌هايي كه از پخش شدن تغييرات جلوگيري مي‌كنند.
وقتي يك ماژول، از ماژول ديگر استفاده مي‌كند، تغييرات در يك ماژول موجب تغيير در ماژول وابسته مي‌گردد. در صورتي كه بتوان جلوي اين امر را گرفت، هزينه تغييرات به ميزان قابل توجهي كاهش مي‌يابد.

شكستن زنجيره وابستگي : در اين تاكتيك، از يك عنصر واسط براي شكستن زنجيره وابستگي بين دو ماژول وابسته استفاده مي‌كنيم. براي اين كار، با توجه به نوع وابستگي روش‌هاي زير وجود دارند :
• استفاده از يك سرور نام :‌ در اين روش، در صورتي كه جاي يك ماژول تغيير يابد، نياز به تغيير ماژول وابسته وجود ندارد. ماژول وابسته از طريق سرور نام، آدرس ماژول تغيير يافته را مي‌يابد.
• استفاده از ماشين مجازي : ماشين مجازي، وابستگي به يك وضعيت خاص‌محاسباتي را از بين مي‌برد و يك وضعيت يكنواخت براي همه حالات ايجاد مي‌كند.
• استفاده از الگوي انتشار دهنده، مشترك
• استفاده از يك مخزن
• استفاده از الگوريتم‌هاي زمان بندي پويا

استفاده از داده‌هاي خود توصيف : در اين روش، به داده‌ها، اطلاعاتي متصل مي‌شود كه اين امكان را فراهم مي‌كند داده به صورت غير وابسته، داراي ويژگي‌هايش باشد. به اين ترتيب هر ماژول، بدون وابستگي به ماژول ديگر، نوع داده و نحوه برخورد با آن را تشخيص خواهد داد.

محدود نمودن مسير ارتباطي [Bass 2003] : هر ماژول معمولاً داده‌هايي را براي چندين ماژول توليد مي‌كند. در صورتي كه ماژول‌هايي كه از ماژول اوليه داده مي‌گيرند را كاهش دهيم، عملاً در صورت تغيير در ماژول اوليه، تعداد كمتري ماژول متأثر مي‌گردد. در نتيجه از پخش شدن تغييرات جلوگيري مي‌گردد.
همچنين در صورتي كه تعداد ماژول‌هايي كه براي ماژول اوليه داده فراهم مي‌سازند كاهش يابد، در صورت بروز تغيير در نوع داده دريافتي توسط ماژول اوليه، ماژول‌هاي كمتري متاثر خواهد شد.

5-8 ارزيابي قابليت تغيير
پس از معرفی تاکتیک¬های قابلیت تغییر در بخش قبل، در اين بخش، روش‌هايي براي ارزيابي قابليت تغيير در يك معماري ارائه خواهيم نمود. به اين منظور، روش‌هاي ارزيابي را به دو بخش تقسيم مي‌نماييم :
1. روش‌هايي كه مشخص مي نمايند تغييرات تا چه اندازه محلي شده اند.
2. روش‌هايي كه مشخص مي‌نمايند اطلاعات چگونه پنهان شده و آيا پخش شدن تغييرات وجود دارد يا خير.

ارزيابي نحوه اختصاص وظايف
در اين بخش، فرض مي‌كنيم تغييرات در دو دسته طبقه‌بندي مي‌شوند :
• تغييراتي كه تنها اندكي با هم تفاوت دارند و از لحاظ مفهومي يكسانند.
• تغييراتي كه بر روي كاركرد‌هاي متفاوت سيستم اثرگذارند.

در حالت ايده‌آل، يك تغيير تنها بر روي يك ماژول اثر گذار است. در اين صورت نتايج جانبي تغيير بر روي ماژول بسيار اندك خواهد بود. (مخصوصاً اگر تاكتيك‌هاي پنهان سازي اطلاعات به كار برده شده باشد.) در اين حالت در صورتي كه دو تغيير اندكي با هم متفاوت باشند، بايد هر دو بر يك ماژول واحد اثرگذار باشند. در صورتي كه دو تغيير بر روي دو كاركرد متفاوت انجام شود، بايد دو ماژول متفاوت نيز از اين تغييرات متاثر شود.

در اين بخش، هدف از ارزيابي، مشخص نمودن نحوه اثرگذاري سناريو‌هاي تغيير بر روي ماژول‌ها مي‌باشد. با انجام اين ارزيابي، مشخص مي‌شود تا چه اندازه از تاكتيك‌هاي معرفي شده در بخش قبل استفاده شده است.

ارزيابي وابستگي بين ماژول‌ها
در اين بخش، ابتدا انواع وابستگي بين ماژول‌ها را معرفي مي‌نماييم. بر اساس قاعده وابستگي، در صورتي كه ماژول B‌ به ماژول A وابستگي داشته باشد، و ماژول A تغيير يابد، در اين صورت ماژول B نيز نياز به تغيير خواهد داشت.

انواع وابستگي
بين دو ماژول متفاوت، هشت نوع وابستگي ممكن است :
1. وابستگي نحوي
a. بر اساس داده : براي اجرا يا كامپايل صحيح ماژول B، نوع يا شكل داده‌اي كه توسط ماژول A فراهم مي‌گردد و توسط ماژول B مصرف مي شود بايد با نوع داده اي كه ماژول B انتظار آن را دارد، سازگار باشد.
b. بر اساس سرويس : براي اجرا يا كامپايل صحيح ماژول B، بايد امضاء سرويسي كه توسط ماژول A فراهم مي‌گردد و توسط ماژول B فراخواني مي شود با امضاء مورد انتظار ماژول B، سازگار باشد.
2. وابستگي معنايي
a. بر اساس داده : براي اجراي صحيح ماژول B، مفهوم داده‌اي كه توسط ماژول A فراهم مي‌گردد و توسط ماژول B مصرف مي شود بايد با مفهوم داده اي كه ماژول B انتظار آن را دارد، سازگار باشد.
b. بر اساس سرويس : براي اجراي صحيح ماژول B، بايد مفهوم سرويسي كه توسط ماژول A فراهم مي‌گردد و توسط ماژول B فراخواني مي شود با مفهوم مورد انتظار ماژول B، سازگار باشد.
3. وابستگي ترتيب استفاده

a. بر اساس داده : براي اجراي صحيح ماژول B، بايد داده‌هاي توليد شده توسط ماژول A به ترتيبي باشد كه ماژول B انتظار دارد. (براي مثال، براي ماژول B مهم است كه ابتدا عنوان اطلاعات دريافت شده و سپس بدنه دريافت شود.)
b. بر اساس كنترل : براي اجراي صحيح ماژول B، ماژول A بايد در بازه زماني مشخصي قبل از ماژول B‌ اجرا گردد. ( به عنوان مثال، ماژول A بايد حداقل 5 ميلي‌ثانيه قبل از ماژول B اجرا شود. )

4. وابستگي به هويت واسط ها
ماژول A، معمولاً داراي چندين واسط است. براي اجراي ماژول B به طور صحيح، هويت واسط مربوطه در ماژول A ( به عنوان مثال نام آن ) بايد با انتظار ماژول B، سازگار باشد.

5. وابستگي محل اجرا
براي اجراي صحيح ماژول B، محل ماژول A بايد با محل مورد انتظار ماژول B سازگار باشد. ( براي مثال ماژول B فرض مي‌كند ماژول A همواره روي پردازنده‌اي كه B روي آن اجرا شده است، در حال اجرا مي باشد. )
6. وابستگي كيفيت سرويس يا داده

براي اجراي صحيح ماژول B، ماژول A بايد بتواند اطلاعات يا سرويسي كه براي ماژول B فراهم مي‌كند داراي كيفيتي مطابق انتظار B باشد. ( به عنوان مثال، ماژول A اطلاعات يك سنسور را براي ماژول B فراهم مي‌سازد. در اين صورت الگوريتم ماژول B تنها در صورتي پاسخگو خواهد بود كه اطلاعات ارسالي از ماژول A داراي دقت مشخصي باشند. )

7. وابستگي موجوديت ماژول
براي اجراي صحيح ماژول B، ماژول A بايد موجود باشد. (براي مثال در صورتي كه ماژول A به طور پويا ايجاد شود و ماژول B آن را فراخواني كند، ممكن است در زمان فراخواني ماژول A موجود بوده و يا نباشد. )

8. وابستگي استفاده از منابع
براي اجراي صحيح ماژول B، استفاده از منابع توسط ماژول A بايد مطابق انتظار ماژول B باشد. ( به عنوان مثال حافظه ماژول A و B بايد يكسان باشد. يا ماژول A نبايد از حافظه مورد استفاده توسط ماژول B استفاده كند. )

نحوه بازنمايي وابستگي‌ها

وابستگي‌ها بين دو ماژول A و B از طريق جدولي مطابق آنچه در جدول 3 نمايش داده شده است، بازنمايي مي‌شود.

جدول 3 - نحوه بازنمايي وابستگي بين دو ماژول
نوع تغيير
استفاده از منابع كيفيت سرويس يا داده محل زمان اجرا موجود بودن ماژول هويت Interface‌ ترتيب سرويس ترتيب داده مفهوم سرويس نحو سرويس مفهوم داده نحو داده‌
- - + + + - - + + + + نحوه انتقال تغييرات از ماژول A به ماژول B

در اين جدول، اگر دو ماژول يك نوع وابستگي خاص را داشته باشند، جلوي آن وابستگي علامت (+) و در غير اين صورت علامت (-) قرار داده مي‌شود.

براي پر نمودن جدول فوق، سه روش عمومي وجود دارد :
• استفاده از روش Brute-force
• استفاده از بستار انتقالی براي تشخيص وابستگي‌هاي غير مستقيم.
• استفاده از روش‌هاي بهينه سازي براي كاهش حجم كار
در زير هريك از اين روش‌ها را بررسي مي‌كنيم.

روش Brute-force
اين روش شامل مراحل زير مي‌گردد :‌
• همه زوج‌هاي ممكن از ماژول‌ها را در يك جدول (همانند جدول 1) ليست مي‌نماييم.
• براي هريك از زوج ماژول‌ها مشخص مي‌كنيم كه آيا وابستگي مشخص شده در ستون مربوطه وجود دارد يا خير ؟ وجود يا عدم وجود هر نوع وابستگي مبتني بر پياده سازي يا عدم پياده سازي يكي از تاكتيك‌ها خواهد بود.
استفاده از بستار انتقالی
در اين روش براي مشخص شدن وابستگي‌هاي غير مستقيم، بستار انتقالی مربوط به هر يك از ماژول‌ها را مشخص مي‌كنيم. به عنوان مثال، مطابق شكل 2، دو ماژول A و B، ممكن است به طور مستقيم و همچنين از طريق ماژول C با هم در ارتباط باشند. در اين حالت ماژول‌هاي A و B به طور مستقيم داراي وابستگي نحوي داده‌اي نمي‌باشند. ولي اين وابستگي ممكن است از طريق ماژول C به وجود آيد. اين نوع وابستگي‌ها را بايد مشخص نمود و با پياده سازي تاكتيك مناسب در ماژول C به رفع آنها اقدام نمود.

شكل 11 - نمودار جريان داده ( تغييرات به طور غير مستقيم از A به B منتقل مي‌شود)

استفاده از روش بستار انتقالی شامل مراحل زير مي‌گردد :
• پرنمودن جدول وابستگي از طريق روش Brute-Force
• مشخص نمودن انتقال تغييرات به طور غير مستقيم
• تغيير علامت - با + در صورت انتقال تغييرات
استفاده از روش‌هاي بهينه سازي
در اين روش، براي كاهش ماژول‌هاي مورد بررسي، در صورتي كه يك ماژول قابل تقسيم به چندين ماژول باشد، مي توان گفت كه ماژول‌هاي فرزند، وابستگي‌هاي پدر را به ارث خواهند برد. به عنوان مثال در صورتي كه ماژول A از ماژول‌هاي B و C تشكيل شود، ماژول‌هاي B و C وابستگي‌هاي A‌ را به ارث خواهند برد. همچنين اگر ماژول Z از ماژول‌هاي X و Y‌ تشكيل شود، بين X و B‌ تنها در صورتي وابستگي وجود دارد كه بين A و Z وابستگي موجود باشد.

استفاده از اين روش شامل مراحل زير مي‌شود :
• پركردن جدول وابستگي براي ماژول‌هاي پدر با استفاده از روش Brute-force
• براي هر زوج ماژول، در صورتي كه پدر‌هاي آنها وابستگي داشته باشند، آن دو ماژول نيز وابسته خواهند بود.
استفاده از جدول وابستگي‌ها
در اين مرحله با توجه به جدول وابستگي‌ها، ماژول‌هاي متاثر از هر تغيير را مي‌توان به دست آورد. همچنين با توجه به تعداد ماژول‌ها و نوع آنها، هزينه هر تغيير قابل محاسبه است.
در اين جدول، هر علامت + بيانگر امكان پياده سازي يك تاكتيك براي جلوگيري از انتقال تغييرات مي‌باشد. معمار نرم افزار مي‌تواند با توجه به هزينه تغييرات نسبت به پياده سازي اين تاكتيك اقدام نمايد.
5-9 تصميم گيري نهايي در مورد طراحي ويژگي كيفي قابليت تغيير
پس از اينكه جدول وابستگي بين دو ماژول پر گرديد، با توجه به داده‌هاي درون جدول، معماري نرم افزار سناريو‌هاي تغيير را بررسي مي‌نمايد. براي هر سناريو تغيير، ابتدا ماژول‌هايي كه تغيير مي‌كند مشخص شده و سپس با استفاده از جدول وابستگي و علائم + تعيين مي‌گردد كه چه ماژول‌هايي از تغيير ماژول اوليه متاثر خواهند شد. به اين وسيله امكان تعيين هزينه تغييرات وجود دارد. براي بهبود طراحي نيز مي‌توان از جدول وابستگي استفاده نمود. در اين جدول هنگامي كه با علائم + روبرو مي‌شويم، نشان‌دهنده عدم وجود تاكتيك مناسب براي جلوگيري از انتشار تغييرات مي‌باشد. بنابراين با استفاده از تاكتيك مناسب مي‌توان از گسترش تغييرات جلوگيري نمود.

6 مطالعه موردي
قابليت تغيير، درجه‌اي است كه معماري مي‌تواند در پاسخ به تغييرات آينده به سادگي تغيير يابد[Bachmann 02]. در اين مرحله مي‌خواهيم به معماري دست پيدا كنيم كه پاسخگوي تغييرات آتي باشد. در این بخش از گزارش یک سیستم مطالعه موردی را به عنوان نمونه در نظر گرفته و با معرفی یک سناریو قابلیت تغییر، نحوه اعمال تاکتیک¬های معرفی شده در بخش قبل را بررسی خواهیم نمود. همچنین در روش استفاده شده از چارچوب¬های استدلالی برای قابلیت تغییر استفاده می¬کنیم. این چارچوب¬ها امکان خودکارسازی فرایند طراحی را فراهم می¬سازند. سیستم مطالعه موردی یک سیستم نرم افزار برای کنترل درب آسانسور می¬باشد. این سیستم از یک پردازنده تشکیل شده که احتمال تغییر آن زیاد است. بنابراین در اینجا می¬خواهیم معماری برای سیستم طراحی کنیم که نسبت به بروز تغییرات در پردازنده مقاوم باشد[Bachmann 03].

6-1 مرحله 1 - انتخاب يك سناريو حقيقي
با توجه به مطالعه موردي اين بخش، سناريو قابليت تغيير را به صورت زير انتخاب مي‌كنيم :

هر محصول توليد شده بر اساس معماري، داراي يك پردازنده (CPU) خاص مي‌باشد. انطباق نرم افزار با پردازنده‌هاي گوناگون بايد در يك نفر-روز انجام پذيرد.

6-2 مرحله 2 - بررسي نوع سناريو حقيقي
در اين مرحله سناريو حقيقي مورد نظر را به يك سناريو عمومي تبديل مي‌كنيم. سناريو عمومي مورد نظر از نوع قابليت تغيير مي‌باشد. براي دستيابي به اين سناريو، سناريو حقيقي مرحله قبل را به اجزاي تشكيل دهنده آن تقسيم مي‌كنيم. حاصل اين عمليات در جدول 4 نشان داده شده است.

جدول 4- سناريو حقيقي قابليت تغيير براي سيستم مورد مطالعه
جزء مقدار
منبع نامشخص
محرك تغيير پردازنده
محيط نامشخص
محصول نرم‌افزاري سيستم كنترل در آسانسور
پاسخ انطباق با پردازنده‌هاي گوناگون
ميزان پاسخ در يك نفر-روز

با توجه به تجزيه سناريو حقيقي، مي‌توان سناريو عمومي را با پركردن قسمت‌هاي خالي جدول فوق و بيان كردن مقادير جدول به طور كلي، به دست آورد. حاصل در جدول 5 ارائه شده است.

جدول 5 - سناريو عمومي قابليت تغيير براي مسئله مورد بررسي
جزء مقدار
منبع توسعه دهنده
محرك درخواست برای اضافه/ تغییر یا حذف یک کارکرد
محيط زمان کامپایل
محصول نرم‌افزاري سیستم
پاسخ انجام تغییرات بدون متاثیر شدن دیگر کارکرد¬های سیستم
ميزان پاسخ کار (Effort)

بر اساس سناريو حقيقي مطرح شده، يكي از وظايف پردازنده تغيير مي‌يابد. اگر پردازنده را يك ماژول بدانيم و سيستم كنترل در آسانسور را يك ماژول، اين دو ماژول داراي وابستگي هستند. بنابراين تغيير يكي از وظايف پردازنده، نيازمند تغيير در سيستم كنترل در آسانسور مي‌باشد. اين وابستگي در شكل 12 نشان داده شده است. هدف ما انجام تغييرات در وظايف سيستم كنترل است. اين تغييرات بايد به نحوي انجام شود كه ميزان پاسخ معرفي شده در جدول 4 را برآورده نمايد.

شكل 12 - نمايش سيستم به صورت دو ماژول وابسته

6-3 مرحله 3 - انتخاب چهارچوب استدلال مناسب
در اين مرحله بايد يك چهارچوب استدلال مناسب انتخاب شود. اين چهارچوب بايد توانايي مشخص نمودن هزينه انجام يك تغيير خاص را داشته باشد.
پاسخ اين سوال، معمولاً در قالب ميزان كار و يا زمان مورد نياز براي انجام تغيير بيان مي‌گردد. براي اينكه آماده سازي معماري براي پاسخگويي به تغييرات مناسب باشد بايد مقدار سود حاصل از اين آماده سازي بيش از مقدار هزينه آن باشد. اين مفهوم در رابطه زير بيان مي‌گردد :

كه در اين رابطه :
بيانگر كار لازم براي آماده سازي معماري در مقابل تغييرات است.
بيانگر ميزان كاري است كه در اثر آماده سازي معماري در مقابل تغييرات صرفه‌جويي شده است.
بيانگر كار لازم براي انجام تغيير است در صورتي كه معماري آماده تغيير نباشد.
بيانگر كار لازم براي ايجاد تغيير در معماري آماده به تغيير مي باشد.
بيانگر تعداد دفعاتي است كه امكان رخ دادن تغيير وجود دارد.
در حقيقت اين رابطه، نشان مي‌دهد كه صرفه‌جويي حاصل بايد بيشتر يا مساوي با سرمايه‌گذاري باشد. ميزان كار لازم براي انجام تغيير ( و ) شامل انجام فعاليت‌هاي زير مي‌باشد :
• يافتن وظايفي كه تحت اثر تغيير قرارگرفته اند.
• انطباق وظايف با تغييرات
• تست همه وظايف داخل يك ماژول
• تست همه وظايف داخل ماژول وابسته به ماژول تغيير يافته
در حالتي كه معماري آماده اعمال تغييرات باشد، كل كار لازم از رابطه زير به دست خواهد آمد ( در اين حالت كل كار برابر مقدار كار لازم براي آماده سازي معماري براي تغييرات + مقدار كار لازم در هر تغيير ( در صورت داشتن n تغيير ) خواهد بود. )

با توجه به رابطه فوق، در جدول 6، چهارچوب استدلال را براي قابليت تغيير معرفي خواهيم نمود.

جدول 6 - چهارچوب استدلال براي ويژگي كيفي قابليت تغيير
چهارچوب تصميم گيري ويژگي كيفي پارامتر‌هاي مستقل پارامتر‌هاي وابسته مقياس پاسخ
آناليز وابستگي‌ها قابليت تغيير تعداد اوليه ماژول‌هاي متاثر از تغيير
تعداد وظايف متاثر از يك تغيير داخل يك ماژول
احتمال متاثر شدن وظايفي از ماژول كه به طور عمومي قابل مشاهده هستند.
تعداد ماژول‌هاي ثانويه كه در اثر تغيير وظايف عمومي ماژول اول متاثر مي‌شوند.
تعداد وظايفي كه داخل ماژول ثانويه متاثر مي‌شوند. كار لازم براي اعمال تغييرات ( )
محدوديت هزينه

در چهارچوب ارائه شده، تعدادي پارامتر مستقل معرفي گرديد. اين پارامتر‌ها مشخص كننده ميزان كار لازم (يا هزينه) براي انجام تغييرات مي‌باشند. پارامتر وابسته به طور مستقيم قابل اندازه گيري نمي‌باشد، بلكه بايد با توجه به پارامتر‌هاي مستقل آن را اندازه گيري نمود.
در شكل 13 نحوه اثرگذاري پارامتر‌هاي مستقل مشخص شده است. تغييرات بر روي ماژول‌هاي اوليه انجام مي‌گردد. در صورتي كه تعدادي از وظايفي كه به طور عمومي قابل رؤيت هستند از اين تغييرات متاثر شود، ماژول‌هاي ثانويه‌اي نيز تحت تاثير تغيير قرار خواهند گرفت. بايد توجه داشت كه تغيير هر يك از وظايف متاثر، داراي هزينه خاص خود مي‌باشد و هزينه انجام تغيير برابر با مجموع هزينه تغييرات انجام شده بر روي هريك از وظايف است.

شكل 13 - پارامتر‌هاي اثر گذار بر روي هزينه تغييرات

6-4 مرحله 4 - مشخص نمودن پارامتر‌هاي محدود و آزاد
در اين مرحله، بايد پارامتر‌هاي آزاد و محدود مشخص گردند. پارامتر‌هاي محدود پارامتر‌هايي هستند كه مقدار آنها در اين مرحله مشخص مي‌باشد و نمي‌توان آنها را تغيير داد. به عنوان مثال، در سيستم مورد مطالعه پارامتر‌هاي زير قابل تعيين هستند :
• تعداد اوليه ماژول‌هاي متاثر از تغيير : مقدار اين پارامتر 1 است. چون سيستم مورد مطالعه داراي تنها يك پردازنده است.
• تعداد وظايف متاثر از يك تغيير داخل يك ماژول‌ : چون در سيستم مورد مطالعه، پردازنده به طور كامل تغيير مي‌يابد، تمام وظايف موجود داخل ماژول تغيير مي‌يابد.
• احتمال متاثر شدن وظايفي از ماژول كه به طور عمومي قابل مشاهده هستند. : در اين مسئله فرض بر اين است كه پردازنده به طور كامل تغيير مي‌يابد. بنابراين احتمال تغيير وظايف عمومي برابر 1 است.

دو پارامتر :‌
• تعداد ماژول‌هاي ثانويه كه در اثر تغيير وظايف عمومي ماژول اول متاثر مي‌شوند.
• تعداد وظايفي كه داخل ماژول ثانويه متاثر مي‌شوند.
پارامتر‌هاي آزاد محسوب مي‌گردند. مقدار اين پارامترها بسته به نحوه به كاربردن تاكتيك‌ها توسط معمار نرم افزار قابل تعيين است.

6-5 مرحله 5 - مشخص كردن تاكتيك‌هاي وابسته به پارامتر‌هاي آزاد
ابتدا تاكتيك‌هايي را كه مي‌توان در مورد پارامتر‌هاي مطرح در جدول 6 به‌كار برد معرفي مي‌نماييم. با به كاربردن هريك از اين تاكتيك‌ها مي‌توان مقدار پارامتر‌هاي آزاد را تغيير داد و آنها را به حد مطلوب رساند. در سيستم مورد مطالعه دو پارامتر آخر، آزاد محسوب مي‌شوند. ولي با توجه به نوع سيستم، هريك از پارامتر‌ها مي‌توانند محدود و يا آزاد تلقي گردند. در جدول 7 پارامتر‌ها و تاكتيك‌هاي مربوط به هر يك معرفي شده است.

جدول 7 - پارامتر‌هاي قابليت تغيير و تاكتيك‌هاي اثر گذار بر روي آنها
پارامتر تاكتيك‌هاي مربوطه
تعداد رخ دادن تغييرات تاكتيك‌هايي كه تغييرات را محلي مي‌كنند.
محدود نمودن گزينه‌ها (با محدود كردن گزينه‌ها مي‌توان امكان رخداد تغييرات را كاهش داد.)

تعداد اوليه ماژول‌هاي متاثر از تغيير تاكتيك‌هايي كه تغييرات را محلي مي‌كنند.
محدود نمودن گزينه‌ها (با محدود كردن گزينه‌ها مي‌توان ماژول‌هاي متاثر را كاهش داد)
جدا سازي تغييرات قابل پيش‌بيني ( با جدا سازي تغييرات قابل پيش‌بيني مي توان از متاثر شدن ماژول‌هاي گوناگون جلوگيري نمود.)
برقراري ارتباط مفهومي ( با برقراري ارتباط مفهومي مي‌توان جلوي اثر گذاري يك تغيير بر روي چندين ماژول را گرفت)
تعداد وظايف متاثر از يك تغيير داخل يك ماژول تاكتيك‌هايي كه تغييرات را محلي مي‌كنند.
محدود نمودن گزينه‌ها (با محدود كردن گزينه‌ها مي‌توان مسئوليت‌هاي متاثر شده را كاهش داد.)
جدا سازي سرويس‌هاي عمومي (از متاثر شدن سرويس‌هاي متقاوت جلوگيري مي‌گردد. )
احتمال متاثر شدن وظايفي از ماژول كه به طور عمومي قابل مشاهده هستند. تاكتيك‌هايي كه تغييرات را محلي مي‌كنند.
محدود نمودن گزينه‌ها (با محدود كردن گزينه‌ها مي‌توان مسئوليت‌هاي متاثر شده را كاهش داد.)
افزايش سطح تجرد (از متاثر شدن سرويس‌هاي متقاوت جلوگيري مي‌گردد. )
تعداد ماژول‌هاي ثانويه كه در اثر تغيير وظايف عمومي ماژول اول متاثر مي‌شوند. تاكتيك‌هايي كه از پخش شدن تغييرات جلوگيري مي‌كنند.
شكستن زنجيره وابستگي (شكستن زنجيره وابستگي موجب جلوگيري از پخش شدن و انتقال تغييرات مي‌گردد.)
استفاده از داده‌هاي self-identifying (اضافه كردن قوائد نحوي بر روي داده‌ها موجب مي‌گردد ماژول ثانويه به طور خودكار خود را با تغييرات انطباق دهد.)
محدود نمودن مسير ارتباطي (هرچه وابستگي‌ها كمتر باشد، تعداد ماژول‌هاي ثانويه كمتري متاثر مي‌گردند.)

6-6 مرحله 6 - اختصاص مقادير اوليه به پارامتر‌هاي آزاد
در اين مرحله، پارامتر‌هاي آزاد باقي‌مانده از مرحله قبل را مقدار دهي مي‌كنيم. اين پارامتر‌هاي آزاد براي سيستم مورد مطالعه عبارتند از‌ :‌
• تعداد ماژول‌هاي ثانويه كه وابسته به تغيير وظايف عمومي ماژول اوليه مي‌باشند و از آنها متاثر مي‌گردند.
• تعداد وظايف تغيير يافته در ماژول ثانويه
تعداد ماژول‌هاي ثانويه متاثر از تغيير براي سيستم مورد مطالعه، برابر يك خواهد بود. (كل سيستم كنترل درب آسانسور) اما تعداد وظايف متاثر از تغيير، مشخص نمي‌باشد.

6-7 مرحله 7 - انتخاب تاكتيك‌ها و به كاربردن آنها براي دستيابي به پاسخ مناسب
در اين مرحله تعدادي قانون براي انتخاب تاكتيك‌ها معرفي مي‌نماييم. در هر مرحله از اعمال قانون‌ها، بايد مقدار پاسخ سناريو مشخص گردد. در صورتي كه در مرحله مذكور به پاسخ مورد نظر دست پيدا كرديم عمليات متوقف مي‌گردد و در غير اين صورت ادامه مي‌يابد. (استفاده از این قانون¬ها به صورت سیستماتیک موجب امکان خودکارسازی فرایند طراحی می¬شود.)
اين قانون‌ها در جدول 8 معرفي شده اند.

جدول 8 - قانون‌هايي كه نحوه استفاده از تاكتيك‌ها را مشخص
1 - در صورتي كه معماري فعلي پاسخ مناسب را برآورده مي‌سازد، معماري مناسب است.
2 - در صورتي كه امكان محدود كردن رخ داد تغييرات وجود دارد، تاكتيك محدود كردن گزينه‌ها را اعمال كنيد.

3 - در صورتي كه تغييرات با توجه به محدوديت‌ها قابل انجام نيستند(در صورتي كه تنها ماژول‌هاي اوليه را در نظر بگيريم)، تاكتيك‌هاي زير را اعمال نماييد :
• برقراري ارتباط مفهومي
• جداسازي تغييرات قابل پيش‌بيني

3 - در صورتي كه تغييرات با توجه به محدوديت‌ها قابل انجام نيستند(در صورتي كه تنها ماژول‌هاي اوليه را در نظر بگيريم) و تاكتيك‌هاي مراحل 2 و 3 اعمال شده است، اين مسئله قابل حل نمي‌باشد.
4 - در صورتي كه كار لازم براي وفق دادن ماژول‌هاي ثانويه با تغييرات بيش از محدوديت‌هاي موجود است و ماژول‌هاي اوليه قابل تغيير هستند تاكتيك‌هاي زير را به كار گيريد :

• جدا سازي سرويس‌هاي معمول
• افزايش سطح تجرد
• پنهان سازي اطلاعات

• نگهداري واسط هاي موجود
• جداسازي واسط از پياده سازي
5 - در صورتي كه كار لازم براي وفق دادن ماژول‌هاي ثانويه با تغييرات بيش از محدوديت‌هاي موجود است تاكتيك‌هاي زير را اعمال نماييد.
• شكستن زنجيره وابستگي
• استفاده از داده‌هاي خودتوصیف
• محدودكردن مسير ارتباطي

6 - در صورتي كه با اعمال همه تاكتيك‌هاي فوق، پاسخ مناسب دست‌يافتني نبود، اين مسئله قابل حل نمي‌باشد.
7 - در صورتي كه هزينه به كارگيري تاكتيك‌ها بيش از سود آنها است، در نياز مورد نظر، تجديدنظر انجام دهيد.

حال اين قوانين را در مورد سيستم مورد مطالعه اعمال مي‌كنيم. هدف از اعمال اين قوانين، دستيابي به پاسخي برابر مي‌باشد. (n تعداد نفر - روز مورد نياز براي انجام تغييرات مي‌باشد.)

در ابتدا مقدار كار مورد نياز براي انجام تغييرات بسيار بيش از مقدار مورد انتظار است. ( اين مقدار دقيقاً مشخص نمي‌باشد. زيرا دامنه وسيعي از پردازنده‌ها موجود است كه حتي با برخي از آنها آشنايي وجود ندارد. )

ابتدا قانون 1 را اعمال مي‌كنيم. با اعمال اين قانون و محدود كردن تغييرات، پاسخ را به مقدار مورد انتظار نزديك مي‌كنيم. به اين منظور، فرض مي‌كنيم تنها امكان جايگزيني پردازنده با پردازنده‌هاي هم‌خانواده خود وجود دارد.

پس از انجام بررسي‌هاي لازم متوجه مي‌شويم كه اين كار، هزينه مورد نياز را به 5 نفر روز كاهش مي‌دهد.

سپس مراحل 2، 3، 4 را اعمال مي‌كنيم. اين مراحل، عملاً قابل استفاده نمي‌باشند. زيرا امكان انجام تغييرات بر روي پردازنده وجود ندارد.

سپس به اعمال مرحله 5 مي‌پردازيم. در اين مرحله، ابتدا تاكتيك شكستن زنجيره ارتباطي را اعمال مي‌كنيم. به اين منظور، ابتدا وابستگي‌هاي موجود بين ماژول پردازنده و ماژول سيستم را مشخص مي‌كنيم.

1. وابستگي نحوي ومعنايي
i. بر اساس داده : دستوراتي كه سيستم كنترل در براي پردازنده ارسال مي‌كند، حكم داده را دارند. بنابراين اين نوع وابستگي وجود دارد.
ii. بر اساس سرويس : سيستم از سرويس‌هاي ارائه شده توسط پردازنده مانند مديريت حافظه، ورودي-خروجي و ... استفاده مي‌نمايد.
2. وابستگي ترتيب استفاده : ترتيب اجرا داده‌ها (دستورات ارسالي) براي سيستم مهم مي‌باشد. همچنين سيستم تا حدودي وابسته به ترتيب كنترل پردازنده مي‌باشد.
3. وابستگي به هويت واسط ها : سيستم كنترل در، بر روي پردازنده بازيابي مي‌شود. بنابراين اين سيستم اطلاع خاصي از واسط¬های پردازنده ندارد.
4. وابستگي محل اجرا : نرم افزار بر روي پردازنده بازيابي مي‌شود. بنابراين اطلاعي از محل پردازنده ندارد.
5. وابستگي كيفيت سرويس يا داده : نرم افزار به كيفيت سرويس ارائه شده توسط پردازنده وابسته است. ( به عنوان مثال به سرعت اجراي دستورات، سرويس‌هاي ورودي - خروجي و ... )
6. وابستگي موجوديت ماژول : نرم افزار به وجود پردازنده وابسته است.
7. وابستگي استفاده از منابع : وابستگي استفاده از منابع وجود دارد. به عنوان مثال نرم افزار به نحوه زمانبندي اجراي دستورات توسط پردازنده وابسته است.

براي دستيابي به ميزان كار لازم كه در سناريو حقيقي به آن اشاره شده بود، تقريباً تمام وابستگي‌ها بايد شكسته شوند. در ادامه با اعمال تاكتيك‌ها سعي در شكستن اين وابستگي‌ها خواهيم داشت. وابستگي‌هاي محل اجرا، هويت واسط و موجوديت ماژول، با توجه به اينكه نرم افزار بر روي پردازنده بازيابي مي‌شود، عملاً وجود نخواهند داشت. همچنين وابستگي نحوه استفاده از منابع به طور پيش فرض براي سيستم وجود دارد.

استفاده از كامپايلر به عنوان واسط
با استفاده از معرفي يك زبان بالاتر به جاي زبان اسمبلر مي‌توان وابستي نحوي داده را شكست. در اينجا فرض مي‌كنيم كه كامپايلري براي پردازنده و زبان انتخابي ما وجود دارد. استفاده از كامپايلر علاوه بر شكستن وابستگي نحوي داده، باعث مي‌شود وابستگي معنايي داده (چون عملاً از زبان مجرد‌‌تري نسبت به زبان ماشين استفاده مي‌شود) و وابستگي ترتيب داده شكسته شود.
معمولاً به همراه كامپايلر يك محيط اجرايي ارائه شده كه به عنوان واسط براي برخي از سرويس‌هاي ارائه شده توسط پردازنده عمل مي‌كند. سرويس‌هاي مديريت ورودي/خروجي، مديريت حافظه و مديريت زمان نمونه‌هايي از سرويس‌هاي موجود در محيط اجرايي كامپايلر مي‌باشند.
استفاده از سرويس‌هاي فوق موجب شكسته شدن وابستگي نحوي سرويس خواهد شد. همچنين وابستگي معنايي داده نيز كاهش خواهد يافت. زيرا سرويس‌هاي ارائه شده توسط محيط اجرايي معمولاً‌ كلي تر از سرويس‌هاي ارائه شده توسط پردازنده مي‌باشند.

استفاده از سيستم‌عامل به عنوان واسط
استفاده از كامپايلر، تمام وابستگي‌هاي سرويس را از بين نخواهد برد. به عنوان مثال استفاده از كامپايلر، وابستگي سرويس ورودي خروجي براي گروهي از ابزار‌هاي خاص كه مديريت حافظه ويژه‌اي را نياز دارند از بين نخواهد برد. براي از بين بردن چنين وابستگي‌هايي از يك واسط به عنوان سيستم عامل استفاده خواهيم نمود. استفاده از اين واسط وابستگي‌هاي نحوي سرويس و منابع را براي سرويس‌هاي باقي مانده پردازنده از بين خواهد برد. همچنين وابستگي‌هاي معنايي را كاهي مي‌دهد.
در هنگامي كه وظايف واسط را در بخش تعريف مي‌كنيم با استفاده از تاكتيك‌هاي افزايش سطح تجرد و پنهان سازي اطلاعات، واسط‌هاي مجرد تري را براي سرويس‌هاي پردازنده تعريف مي‌كنيم و جزئيات وابسته به پردازنده را حذف خواهيم نمود.

6-8 مرحله 8 : اختصاص مسئوليت‌ها به عناصر معماري
در طراحي سيستم در اين مرحله از تاكتيك شكستن زنجيره وابستگي استفاده مي‌كنيم. طراحي اين تاكتيك مطابق شكل 14 مي‌باشد.

شكل 14 - تكه طراحي تاكتيك شكستن زنجيره وابستگي

سه بار استفاده از اين تاكتيك و اختصاص وظايف به هريك از بخش‌ها موجب مي‌شود طراحي كلي سيستم مطابق شكل 15 به دست آيد. در اين طراحي همه وابستگي‌هاي مستقيم شكسته شده اند. هرگونه تغيير بر روي پردازنده در معماري جديد،‌ بر روي كامپايلر و محيط اجرايي تاثير گذاشته كه اين امر با خريداري كامپايلر مربوطه قابل برطرف نمودن است. همچنين برخي تغييرات بر روي سيستم عامل اثر گذار بوده كه در صورت تغيير پردازنده با انطباق سيستم عامل مناسب با پردازنده از پخش شدن تغييرات جلوگيري مي‌شود.

شکل 15 - اختصاص وظايف با توجه به تاكتيك‌هاي اعمال شده

7 خلاصه و نتیجه گیری
در این گزارش، معماری نرم افزار و تعاریف آن مورد بررسی قرار گرفت. سپس عوامل موثر در طراحی معماری نرم افزار معرفی گردید و ویژگی¬های یک طراحی خوب مشخص شد. سپس با توجه به ویژگی¬های تعیین شده برای یک طراحی خوب، روش¬های طراحی معماری نرم¬افزار برای دستیابی به ویژگی¬های کیفی مورد نظر مورد بررسی قرار گرفت.
پس از بررسی روش¬های گوناگون طراحی، ویژگی کیفی قابلیت تغییر به عنوان نمونه¬ای از ویژگی¬های کیفی اثرگذار در معماری نرم افزار معرفی گردید. و مواردی نظیر تاکتیک-های دستیابی و روش ارزیابی آن ارائه شد. سپس یک سیستم به عنوان مطالعه موردی انتخاب گردید و یک سناریو قابلیت تغییر در آن با استفاده از تاکتیک¬ها و روش¬های معرفی شده، طراحی شد. در طراحی سعی گردید از روشی استفاده گردد که امکان انجام خودکار آن بدون نیاز به دانش ویژه انسانی در زمینه ویژگی کیفی مورد نظر فراهم گردد.

8 مراجع

[Asundi 01] J. Asundi, R. Kazman, and M. Klein, Using Economic Considerations to Choose Among Architecture Design Alternatives, Technical Report, CMU/SEI-2001-TR-035, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2001.

[Bachmann 02] F. Bachmann, L. Bass, and M. Klein, Illuminating the Fundamental Contributors to Software Architecture Quality, Technical Report, CMU/SEI-2002-TR-025, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2002.

[Bachmann 03] F. Bachmann, L. Bass, and M. Klein, Deriving Architectural Tactics: A Step Toward Methodical Architectural Design, Technical Report, CMU/SEI-2003-TR-004, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2003.

[Bass 01] L. Bass, M. Klein, F. Bachmann, "Quality Attribute Design Primitives and the Attribute Driven Design Method," In proc. of the 4th International Workshop on Product Family Engineering, Bilbao, Spain, 3-5 October 2001, pp. 122 - 130.

[Bass 03] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition, Addison-Wesley, 2003.

[Booch 98] G. Booch, J. Rumbaugh, and I. Jacobson, UML User Guide, Addison-Wesley Longman, 1998.

[Chastek 05] G. Chastek, and R. Ferguson, Toward Measures for Software Architectures, Technical Report, CMU/SEI-2006-TN-013, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2005

[Garlan 93] D. Garlan, and M. Shaw. An Introduction to Software Architecture, Technical Report, CMU/SEI-94-TR-21, 1993.

[Garland 03] J. Garland, R. Anthony, Large-Scale Software Architecture, Wiley Press, 2003.

[IEEE 00] Recommended Practice for Architectural Description of Software Intensive Systems. Technical Report IEEE P1471-2000, IEEE Standards Department, The Architecture Working Group of the Software Engineering Committee, September 2000.

[Kazman 02] R. Kazman, J. Asundi, and M. Klein, Making Architecture Design Decisions: An Economic Approach, Technical Report, CMU/SEI-2002-TR-035, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2001.

[Klein 99] M. Klein, R. Kazman, Attribute-Based Architectural Styles, Technical Report, CMU/SEI-99-TR-022, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1999.

[Kruchten 95] P. Kruchten, "The 4+1 view model of architecture", IEEE Software, 12, No. 5, 1995.

[RUP 03] P. Kruchten, The Rational Unified Process: An Introduction, Third Edition, Addison-Wesley, 2003.

[Shaw 96] M. Shaw, and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996.

[Shaw 06] M. Shaw, and P. Clements, "The Golden Age of Software Architecture," IEEE Software, vol. 23, no. 2, pp. 31-39, Mar/Apr, 2006.

[With 02] P. H.N. de With, and and G. J. van Dijk, "Architecture assessment for practical management of system architectures", Proc. Workshop Embedded Systems (Progress02), Utrecht, NL, 2002.