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

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

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

فهرست مطالب

۱ مقدمه ۴
۲ معماری نرم افزار چیست ؟ ۵
۲-۱ تعاریف پایه در معماری نرم افزار ۶
الگوهای معماری یا سبکهای معماری ۶
مدل مراجع ۶
معماری مرجع ۶
۲-۲ دیدگاه های معماری ۷
دیدگاه Bass 7
دیدگاه ۴+۱ ۸
دیدگاه‌های دیگر ۸
۳ طراحی معماری نرم افزار ۹
۳-۱ کارکرد‌های سیستم و معماری نرم‌افزار ۹
۳-۲ ویژگی‌های کیفی ۹
۳-۳ ویژگی‌های کیفی سیستم ۱۰
۳-۴ سناریو‌های ویژگی‌کیفی ۱۰
۳-۵ ویژگی‌های کیفی کسب و کار ۱۱
۳-۶ ویژگی‌های کیفی معماری ۱۲
۳-۷ یک طراحی معماری خوب باید دارای چه ویژگی‌هایی باشد؟‌ ۱۲
۳-۸ دستیابی به ویژگیهای کیفی ۱۲
تاکتیکهای معماری ۱۲
الگوهای معماری ۱۴
ارتباط تاکتیکها و الگوهای معماری ۱۵
۴ روشهای طراحی معماری نرم افزار ۱۶
۴-۱ طراحی مبتنی بر ویژگی ۱۶
۴-۲ طراحی به کمک سبک های معماری مبتنی بر ویژگی ۱۷
۴-۳ طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه ۱۹
۵ ویژگی کیفی قابلیت تغییر ۲۳
۵-۱ تعریف قابلیت تغییر ۲۳
۵-۲ مشخص نمودن نیاز‌های قابلیت تغییر با استفاده از سناریو‌های کیفی ۲۳
۵-۳ مدل سازی قابلیت تغییر در سطح معماری نرم افزار ۲۴
۵-۴ تاکتیک‌های قابلیت تغییر ۲۴
۵-۵ تاکتیک‌هایی که تغییرات را محلی می‌کنند. ۲۵
۵-۶ تاکتیک‌هایی که میدان دید وظایف را کاهش می دهند. ۲۶
۵-۷ تاکتیک‌هایی که از پخش شدن تغییرات جلوگیری می‌کنند. ۲۶
۵-۸ ارزیابی قابلیت تغییر ۲۷
ارزیابی نحوه اختصاص وظایف ۲۷
ارزیابی وابستگی بین ماژول‌ها ۲۷
انواع وابستگی ۲۷
نحوه بازنمایی وابستگی‌ها ۲۹
روش Brute-force 29
استفاده از بستار انتقالی ۲۹
استفاده از روش‌های بهینه سازی ۳۰
استفاده از جدول وابستگی‌ها ۳۰
۵-۹ تصمیم گیری نهایی در مورد طراحی ویژگی کیفی قابلیت تغییر ۳۰
۶ مطالعه موردی ۳۱
۶-۱ مرحله ۱ – انتخاب یک سناریو حقیقی ۳۱
۶-۲ مرحله ۲ – بررسی نوع سناریو حقیقی ۳۱
۶-۳ مرحله ۳ – انتخاب چهارچوب استدلال مناسب ۳۲
۶-۴ مرحله ۴ – مشخص نمودن پارامتر‌های محدود و آزاد ۳۴
۶-۵ مرحله ۵ – مشخص کردن تاکتیک‌های وابسته به پارامتر‌های آزاد ۳۵
۶-۶ مرحله ۶ – اختصاص مقادیر اولیه به پارامتر‌های آزاد ۳۶
۶-۷ مرحله ۷ – انتخاب تاکتیک‌ها و به کاربردن آنها برای دستیابی به پاسخ مناسب ۳۶
استفاده از کامپایلر به عنوان واسط ۳۸
استفاده از سیستم‌عامل به عنوان واسط ۳۸
۶-۸ مرحله ۸ : اختصاص مسئولیت‌ها به عناصر معماری ۳۸
۷ خلاصه و نتیجه گیری ۴۰
۸ مراجع ۴۱

فهرست مطالب

شکل ۱ – ارتباط بین الگوی معماری، مدل مرجع و معماری مرجع ۷
شکل ۲ – بخش‌های تشکیل دهنده سناریو ویژگی کیفی ۱۱
شکل ۳ – خلاصه¬ای از تاکتیک¬های قابلیت تغییر ۱۱
شکل ۴ – خلاصهای از تاکتیکهای کارایی ۱۳
شکل ۵ – مجموعه ای از مهمترین الگوهای معماری ۱۴
شکل ۶ – ورودیها و خروجیهای روش ADD 16
شکل ۷ – الگوی معماری خط لوله همزمان ۱۸
جدول ۱ – پارامترهای الگوی خط لوله همزمان ۱۸
جدول ۲ – خروجی فاز اول روش CBAM 20
شکل ۸ – نمودار مقایسه میزان کاربرد هر راهبرد در مقابل هزینه ۲۰
شکل ۹ – انواع نمودار‌های ممکن برای سودمندی براساس پاسخ ۲۱
شکل ۱۰ – معماری سه لایه ۲۴
جدول ۳ – نحوه بازنمایی وابستگی بین دو ماژول ۲۹
شکل ۱۱ – نمودار جریان داده ( تغییرات به طور غیر مستقیم از A به B منتقل می‌شود) ۳۰
جدول ۴- سناریو حقیقی قابلیت تغییر برای سیستم مورد مطالعه ۳۱
جدول ۵ – سناریو عمومی قابلیت تغییر برای مسئله مورد بررسی ۳۲
شکل ۱۲ – نمایش سیستم به صورت دو ماژول وابسته ۳۲
جدول ۶ – چهارچوب استدلال برای ویژگی کیفی قابلیت تغییر ۳۳
شکل ۱۳ – پارامتر‌های اثر گذار بر روی هزینه تغییرات ۳۴
جدول ۷ – پارامتر‌های قابلیت تغییر و تاکتیک‌های اثر گذار بر روی آنها ۳۵
جدول ۸ – قانون‌هایی که نحوه استفاده از تاکتیک‌ها را مشخص ۳۶
شکل ۱۴ – تکه طراحی تاکتیک شکستن زنجیره وابستگی ۳۸
شکل ۱۵ – اختصاص وظایف با توجه به تاکتیک‌های اعمال شده ۳۹

۱ مقدمه

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

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

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

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

ارتباط با معماری نرم¬افزار و مفاهیم مرتبط با آن ارائه می¬شود. این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد. در بخش ۳ طراحی معماری نرم¬افزار، ویژگی¬های یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت. در بخش ۴ روش¬های طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت. در بخش ۵ خلاصه و نتیجه گیری ارائه خواهد شد. در بخش ۶ مراجع مورد استفاده در این گزارش معرفی می¬گردد.
۲ معماری نرم افزار چیست ؟

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

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

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

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

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

معماری مرجع
معماری مرجع، مدل مرجعی می باشد که به اجزای نرم افزاری نگاشت شده است. در حقیقت در معماری مرجع، جایگاه هریک از کردهای سیستم در قالب اجزای نرم افزاری تشکیل دهنده سیستم مشخص شده است. هر جزء نرم افزار در این مدل ممکن است قسمتی از یک کارکرد یا چندین کارکرد را پیاده سازی نماید. به عنوان مثال برای یک سیستم‌عامل، مدیریت حافظه توسط جزء هسته انجام شود. مدیریت دیسک توسط جزء مدیر دیسک و هسته انجام شود و …
ارتباط بین الگوهای معماری، مدل مرجع و معماری مرجع در شکل ۱ نمایش داده شده است.
شکل ۱ – ارتباط بین الگوی معماری، مدل مرجع و معماری مرجع

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

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

دیدگاه ۴+۱
این دیدگاه در [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] مراجعه شود.
۳ طراحی معماری نرم افزار
در این بخش به بررسی عوامل تاثیر گذار بر معماری نرم‌افزار و نحوه تولید معماری خواهیم پرداخت. با توجه به تعاریف انجام شده، معماری نرم¬افزار هر سیستم، پس از به دست آوردن نیاز¬های آن سیستم باید تولید شود. بنابراین در طراحی یک معماری، باید به دو عامل توجه داشت :
• نیاز¬های کارکردی سیستم
• ویژگی¬های کیفی
بنابراین معماری باید به گونه ای طراحی شود که عوامل فوق را پوشش دهد. در ادامه هریک از دو ویژگی فوق را تعریف کرده و نقش آن را در طراحی معماری مورد بررسی قرار خواهیم داد.

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

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

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

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

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

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

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

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

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

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

۳-۴ سناریو‌های ویژگی‌کیفی
سناریو‌های ویژگی‌ کیفی، یک نیاز غیر کارکردی می‌باشند. این نیاز‌ها به طور دقیق بیان شده اند و هر نیاز مربوط به یک ویژگی کیفی خاص می‌باشد. هر سناریو ویژگی کیفی از بخش‌های زیر تشکیل شده است :
منبع محرک : این بخش، موجودیتی است ( یک انسان، سیستم کامپیوتری یا … ) که عملی را در قبال سیستم انجام می‌دهد. در حقیقت سیستم را تحریک می‌نماید.

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

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

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

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

شکل ۲ – بخش‌های تشکیل دهنده سناریو ویژگی کیفی

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

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

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

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

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

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

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

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

۳-۸ دستیابی به ویژگی¬های کیفی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

جدول ۲ – خروجی فاز اول روش CBAM
راهبرد معماری قابلیت تغییر
(۵۰) در دسترس بودن
(۳۰) کارایی
(۲۰) هزینه
راهبرد ۱ — + ++ L
راهبرد ۲ — ۰ + M
راهبرد ۳ ++ ۰ – H

بعد از مشخص نمودن اثر راهبرد‌ها بر هریک از سناریو‌ها، می‌توان راهبرد‌ها را با توجه به اهمیتشان در مقابل هزینه در نموداری نظیر شکل ۸ مشخص نمود.

شکل ۸ – نمودار مقایسه میزان کاربرد هر راهبرد در مقابل هزینه

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

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

مرحله ۲ – پالایش سناریو‌ها : در این مرحله برای هر سناریو‌، پاسخ آن در چهار حالت زیر مشخص می‌گردد‌ :
• بدترین حالت
• وضعیت موجود یا وضعیتی که به راحتی قابل تامین است.
• وضعیت مطلوب
• بهترین حالت

مرحله ۳ – اولویت بندی سناریو‌ها : پس از مشخص نمودن موارد فوق، نتایج در اختیار ذینفعان سیستم قرار گرفته و آنها سناریو‌ها را مجدداً اولویت بندی می‌کنند. به این منظور به هر شرکت کننده ۱۰۰ حق رای داده می‌شود. هر شخص می‌تواند ۱۰۰ رای خود را بر روی یک یا چند سناریو خرج نماید. پس از مشخص شدن رای هر سناریو، به سناریو با بالاترین رای امتیاز ۱ و باقی سناریو‌ها نیز بر اساس بالاترین امتیاز، نرمال می‌شوند. پس از مشخص شدن امتیاز‌ها، ۵۰ درصد سناریو‌ها برای مراحل بعد انتخاب می‌گردند.

مرحله ۴ – مشخص نمودن سودمندی هر سناریو : در این مرحله برای پاسخ‌های مشخص شده در مرحله ۲، عددی به عنوان سودمندی تعیین می‌کنیم. به عنوان مثال می‌گوییم این سناریو در حالت موجود برای ما ۲۰% سودمندی دارد. در این روش، میزان سودمندی عددی بین ۰ الی ۱۰۰ خواهد بود. صفر بیانگر بدون سودمندی و ۱۰۰ بیانگر سودمندی کامل خواهد بود. عمل تخصیص سودمندی نیز توسط هریک از ذینفعان انجام می‌شود. به این ترتیب که هریک از افراد میزان سودمندی را مشخص کرده و سپس میانگین آن محاسبه می‌شود.

مرحله ۵ – مشخص نمودن راهبرد‌های معماری و اثر هر راهبرد بر پاسخ سناریو‌ها : در این مرحله، راهبرد‌های معماری را مشخص خواهیم کرد که بر روی پاسخ هر سناریو موثر هستند. سپس تعیین می‌کنیم که هر راهبرد چه اثری بر روی سناریو خواهد داشت. ( در صورتی که راهبرد بر روی چندین سناریو اثر گذار باشد، برای هر سناریو پاسخ متاثر از راهبرد را تعیین می‌کنیم ).

مرحله ۶ – محاسبه سودمندی هر راهبرد معماری : در این مرحله، با توجه به پاسخ ایجاد شده برای هر سناریو در اثر یک راهبرد معماری، سودمندی راهبرد مذکور را در ارتباط با هر سناریو به دست می‌آوریم. با توجه به مقادیر محاسبه شده در مرحله ۴، می‌توان نمودار تقریبی سودمندی یک سناریو را به دست آورد. پس از تعیین نمودار سودمندی و استفاده از درونیابی، مقدار تقریبی سودمندی راهبرد به دست می‌آید. در شکل ۹، نمونه‌هایی از نمودار‌های ممکن برای سودمندی بر اساس پاسخ ارائه شده است.

شکل ۹ – انواع نمودار‌های ممکن برای سودمندی براساس پاسخ

مرحله ۷ – محاسبه سود کلی حاصل از یک راهبرد : در این مرحله با استفاده از سودمندی هر رویکرد در ارتباط با سناریو‌های مربوطه و وزن هر سناریو، سودمندی کلی یک راهبرد را محاسبه می‌کنیم. برای این منظور از روابط زیر بهره می‌گیریم :

به طوری که داشته باشیم :

مرحله ۸ – انتخاب رویکرد‌ها بر اساس ROI : در این مرحله هزینه‌های هر رویکرد را محاسبه می‌کنیم ( برای این منظور از روش‌های معمول تخمین هزینه مانند LOC و یا Function Point استفاده می‌کنیم ). پس از محاسبه هزینه‌ها ROI هر رویکرد را از رابطه زیر به دست می‌آوریم :

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

مرحله ۹ – بررسی نتایج با واقعیت : در این مرحله نتایج را بررسی کرده و مشخص می‌کنیم که آیا همه اهداف کسب و کار توسط راهبرد‌های انتخاب شده برآورده شده است یا خیر. سپس در صورت وجود اشکال به بازبینی مراحل قبلی می‌پردازیم.

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

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

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

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

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

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

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

۵-۴ تاکتیک‌های قابلیت تغییر
تاکتیک‌های قابلیت تغییر را می‌توان به سه دسته تقسیم نمود :
• تاکتیک‌هایی که تغییرات را محلی می‌نمایند.
• تاکتیک‌هایی که میدان دید وظایف را کاهش می‌دهند.
• تاکتیک‌هایی که از پخش شدن تغییرات جلوگیری می‌کنند.

به عنوان مثال یک سیستم نرم افزاری را در نظر بگیرید که از یک معماری سه لایه تبعیت می‌کند. هر لایه در قالب یک ماژول مستقل پیاده سازی شده است و ماژول‌ها از طریق واسط‌ها با هم مرتبط هستند. (شکل ۱۰)

شکل ۱۰ – معماری سه لایه

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

در ادامه هریک از سه گروه تاکتیک اشاره شده را مورد بررسی قرار خواهیم داد.

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

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

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

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

۵-۶ تاکتیک‌هایی که میدان دید وظایف را کاهش می دهند.
در صورتی که تغییری در یک ماژول رخ دهد و دیگر ماژول‌ها بتوانند این تغییر را مشاهده کنند، ماژول‌های دیگر هم باید تغییر پیدا کنند. بنابراین محدود کردن میدان دید تغییر در ماژول‌ها بسیار مهم می‌باشد.

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

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

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

۵-۷ تاکتیک‌هایی که از پخش شدن تغییرات جلوگیری می‌کنند.
وقتی یک ماژول، از ماژول دیگر استفاده می‌کند، تغییرات در یک ماژول موجب تغییر در ماژول وابسته می‌گردد. در صورتی که بتوان جلوی این امر را گرفت، هزینه تغییرات به میزان قابل توجهی کاهش می‌یابد.

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

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

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

۵-۸ ارزیابی قابلیت تغییر
پس از معرفی تاکتیک¬های قابلیت تغییر در بخش قبل، در این بخش، روش‌هایی برای ارزیابی قابلیت تغییر در یک معماری ارائه خواهیم نمود. به این منظور، روش‌های ارزیابی را به دو بخش تقسیم می‌نماییم :
۱٫ روش‌هایی که مشخص می نمایند تغییرات تا چه اندازه محلی شده اند.
۲٫ روش‌هایی که مشخص می‌نمایند اطلاعات چگونه پنهان شده و آیا پخش شدن تغییرات وجود دارد یا خیر.

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

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

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

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

انواع وابستگی
بین دو ماژول متفاوت، هشت نوع وابستگی ممکن است :
۱٫ وابستگی نحوی
a. بر اساس داده : برای اجرا یا کامپایل صحیح ماژول B، نوع یا شکل داده‌ای که توسط ماژول A فراهم می‌گردد و توسط ماژول B مصرف می شود باید با نوع داده ای که ماژول B انتظار آن را دارد، سازگار باشد.
b. بر اساس سرویس : برای اجرا یا کامپایل صحیح ماژول B، باید امضاء سرویسی که توسط ماژول A فراهم می‌گردد و توسط ماژول B فراخوانی می شود با امضاء مورد انتظار ماژول B، سازگار باشد.
۲٫ وابستگی معنایی
a. بر اساس داده : برای اجرای صحیح ماژول B، مفهوم داده‌ای که توسط ماژول A فراهم می‌گردد و توسط ماژول B مصرف می شود باید با مفهوم داده ای که ماژول B انتظار آن را دارد، سازگار باشد.
b. بر اساس سرویس : برای اجرای صحیح ماژول B، باید مفهوم سرویسی که توسط ماژول A فراهم می‌گردد و توسط ماژول B فراخوانی می شود با مفهوم مورد انتظار ماژول B، سازگار باشد.
۳٫ وابستگی ترتیب استفاده

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

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

۵٫ وابستگی محل اجرا
برای اجرای صحیح ماژول B، محل ماژول A باید با محل مورد انتظار ماژول B سازگار باشد. ( برای مثال ماژول B فرض می‌کند ماژول A همواره روی پردازنده‌ای که B روی آن اجرا شده است، در حال اجرا می باشد. )
۶٫ وابستگی کیفیت سرویس یا داده

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

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

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

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

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

جدول ۳ – نحوه بازنمایی وابستگی بین دو ماژول
نوع تغییر
استفاده از منابع کیفیت سرویس یا داده محل زمان اجرا موجود بودن ماژول هویت Interface‌ ترتیب سرویس ترتیب داده مفهوم سرویس نحو سرویس مفهوم داده نحو داده‌
– – + + + – – + + + + نحوه انتقال تغییرات از ماژول A به ماژول B

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

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

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

شکل ۱۱ – نمودار جریان داده ( تغییرات به طور غیر مستقیم از A به B منتقل می‌شود)

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

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

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

۶-۱ مرحله ۱ – انتخاب یک سناریو حقیقی
با توجه به مطالعه موردی این بخش، سناریو قابلیت تغییر را به صورت زیر انتخاب می‌کنیم :

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

۶-۲ مرحله ۲ – بررسی نوع سناریو حقیقی
در این مرحله سناریو حقیقی مورد نظر را به یک سناریو عمومی تبدیل می‌کنیم. سناریو عمومی مورد نظر از نوع قابلیت تغییر می‌باشد. برای دستیابی به این سناریو، سناریو حقیقی مرحله قبل را به اجزای تشکیل دهنده آن تقسیم می‌کنیم. حاصل این عملیات در جدول ۴ نشان داده شده است.

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

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

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

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

شکل ۱۲ – نمایش سیستم به صورت دو ماژول وابسته

۶-۳ مرحله ۳ – انتخاب چهارچوب استدلال مناسب
در این مرحله باید یک چهارچوب استدلال مناسب انتخاب شود. این چهارچوب باید توانایی مشخص نمودن هزینه انجام یک تغییر خاص را داشته باشد.
پاسخ این سوال، معمولاً در قالب میزان کار و یا زمان مورد نیاز برای انجام تغییر بیان می‌گردد. برای اینکه آماده سازی معماری برای پاسخگویی به تغییرات مناسب باشد باید مقدار سود حاصل از این آماده سازی بیش از مقدار هزینه آن باشد. این مفهوم در رابطه زیر بیان می‌گردد :

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

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

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

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

شکل ۱۳ – پارامتر‌های اثر گذار بر روی هزینه تغییرات

۶-۴ مرحله ۴ – مشخص نمودن پارامتر‌های محدود و آزاد
در این مرحله، باید پارامتر‌های آزاد و محدود مشخص گردند. پارامتر‌های محدود پارامتر‌هایی هستند که مقدار آنها در این مرحله مشخص می‌باشد و نمی‌توان آنها را تغییر داد. به عنوان مثال، در سیستم مورد مطالعه پارامتر‌های زیر قابل تعیین هستند :
• تعداد اولیه ماژول‌های متاثر از تغییر : مقدار این پارامتر ۱ است. چون سیستم مورد مطالعه دارای تنها یک پردازنده است.
• تعداد وظایف متاثر از یک تغییر داخل یک ماژول‌ : چون در سیستم مورد مطالعه، پردازنده به طور کامل تغییر می‌یابد، تمام وظایف موجود داخل ماژول تغییر می‌یابد.
• احتمال متاثر شدن وظایفی از ماژول که به طور عمومی قابل مشاهده هستند. : در این مسئله فرض بر این است که پردازنده به طور کامل تغییر می‌یابد. بنابراین احتمال تغییر وظایف عمومی برابر ۱ است.

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

۶-۵ مرحله ۵ – مشخص کردن تاکتیک‌های وابسته به پارامتر‌های آزاد
ابتدا تاکتیک‌هایی را که می‌توان در مورد پارامتر‌های مطرح در جدول ۶ به‌کار برد معرفی می‌نماییم. با به کاربردن هریک از این تاکتیک‌ها می‌توان مقدار پارامتر‌های آزاد را تغییر داد و آنها را به حد مطلوب رساند. در سیستم مورد مطالعه دو پارامتر آخر، آزاد محسوب می‌شوند. ولی با توجه به نوع سیستم، هریک از پارامتر‌ها می‌توانند محدود و یا آزاد تلقی گردند. در جدول ۷ پارامتر‌ها و تاکتیک‌های مربوط به هر یک معرفی شده است.

جدول ۷ – پارامتر‌های قابلیت تغییر و تاکتیک‌های اثر گذار بر روی آنها
پارامتر تاکتیک‌های مربوطه
تعداد رخ دادن تغییرات تاکتیک‌هایی که تغییرات را محلی می‌کنند.
محدود نمودن گزینه‌ها (با محدود کردن گزینه‌ها می‌توان امکان رخداد تغییرات را کاهش داد.)

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

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

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

جدول ۸ – قانون‌هایی که نحوه استفاده از تاکتیک‌ها را مشخص
۱ – در صورتی که معماری فعلی پاسخ مناسب را برآورده می‌سازد، معماری مناسب است.
۲ – در صورتی که امکان محدود کردن رخ داد تغییرات وجود دارد، تاکتیک محدود کردن گزینه‌ها را اعمال کنید.

۳ – در صورتی که تغییرات با توجه به محدودیت‌ها قابل انجام نیستند(در صورتی که تنها ماژول‌های اولیه را در نظر بگیریم)، تاکتیک‌های زیر را اعمال نمایید :
• برقراری ارتباط مفهومی
• جداسازی تغییرات قابل پیش‌بینی

۳ – در صورتی که تغییرات با توجه به محدودیت‌ها قابل انجام نیستند(در صورتی که تنها ماژول‌های اولیه را در نظر بگیریم) و تاکتیک‌های مراحل ۲ و ۳ اعمال شده است، این مسئله قابل حل نمی‌باشد.
۴ – در صورتی که کار لازم برای وفق دادن ماژول‌های ثانویه با تغییرات بیش از محدودیت‌های موجود است و ماژول‌های اولیه قابل تغییر هستند تاکتیک‌های زیر را به کار گیرید :

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

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

۶ – در صورتی که با اعمال همه تاکتیک‌های فوق، پاسخ مناسب دست‌یافتنی نبود، این مسئله قابل حل نمی‌باشد.
۷ – در صورتی که هزینه به کارگیری تاکتیک‌ها بیش از سود آنها است، در نیاز مورد نظر، تجدیدنظر انجام دهید.

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

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

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

پس از انجام بررسی‌های لازم متوجه می‌شویم که این کار، هزینه مورد نیاز را به ۵ نفر روز کاهش می‌دهد.

سپس مراحل ۲، ۳، ۴ را اعمال می‌کنیم. این مراحل، عملاً قابل استفاده نمی‌باشند. زیرا امکان انجام تغییرات بر روی پردازنده وجود ندارد.

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

۱٫ وابستگی نحوی ومعنایی
i. بر اساس داده : دستوراتی که سیستم کنترل در برای پردازنده ارسال می‌کند، حکم داده را دارند. بنابراین این نوع وابستگی وجود دارد.
ii. بر اساس سرویس : سیستم از سرویس‌های ارائه شده توسط پردازنده مانند مدیریت حافظه، ورودی-خروجی و … استفاده می‌نماید.
۲٫ وابستگی ترتیب استفاده : ترتیب اجرا داده‌ها (دستورات ارسالی) برای سیستم مهم می‌باشد. همچنین سیستم تا حدودی وابسته به ترتیب کنترل پردازنده می‌باشد.
۳٫ وابستگی به هویت واسط ها : سیستم کنترل در، بر روی پردازنده بازیابی می‌شود. بنابراین این سیستم اطلاع خاصی از واسط¬های پردازنده ندارد.
۴٫ وابستگی محل اجرا : نرم افزار بر روی پردازنده بازیابی می‌شود. بنابراین اطلاعی از محل پردازنده ندارد.
۵٫ وابستگی کیفیت سرویس یا داده : نرم افزار به کیفیت سرویس ارائه شده توسط پردازنده وابسته است. ( به عنوان مثال به سرعت اجرای دستورات، سرویس‌های ورودی – خروجی و … )
۶٫ وابستگی موجودیت ماژول : نرم افزار به وجود پردازنده وابسته است.
۷٫ وابستگی استفاده از منابع : وابستگی استفاده از منابع وجود دارد. به عنوان مثال نرم افزار به نحوه زمانبندی اجرای دستورات توسط پردازنده وابسته است.

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

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

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

۶-۸ مرحله ۸ : اختصاص مسئولیت‌ها به عناصر معماری
در طراحی سیستم در این مرحله از تاکتیک شکستن زنجیره وابستگی استفاده می‌کنیم. طراحی این تاکتیک مطابق شکل ۱۴ می‌باشد.

شکل ۱۴ – تکه طراحی تاکتیک شکستن زنجیره وابستگی

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

شکل ۱۵ – اختصاص وظایف با توجه به تاکتیک‌های اعمال شده

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

۸ مراجع

[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.