تبیین الزامات معماری نرم ­افزار و معیارهای ارزیابی آنها

عنوان تحقیق: تبیین الزامات معماری نرم­ افزار و معیارهای ارزیابی آنها در محورهای مختلف معماری جهت استفاده به منظور نظارت بر پیمانکاران نرم ­افزاری در سازمان­ های بزرگچکیده:ارزیابی معماری نرم افزار به یک روش آشنا در جامعه مهندسی نرم افزار جهت توسعه­ ی نرم افزاری با کیفیت تبدیل شده است. ارزیابی معماری تلاش و هزینه‌های توسعه نرم‌افزار را کاهش می‌دهد و کیفیت نرم‌افزار را با توجه به نیازمندی­ های کیفی و شناسایی خطرات احتمالی، افزایش می‌دهد. ارزیابی معماری نرم افزار این اطمینان را به توسعه دهندگان نرم افزار می­ دهد که معماری انتخابی آنها هم نیازمندی­ های عملکردی و هم نیازمندی های غیرعملکردی و کیفی را برآورده می کند. این مقاله بحثی را در مورد روش‌ها و تکنیک‌های مختلف ارزیابی معماری نرم‌افزار ارائه می‌کند و همچنین بر روی خلاصه‌ای از اهمیت روش‌های مختلف ارزیابی زودهنگام و دیرهنگام معماری، شباهت‌ها و تفاوت‌های بین آنها، کاربرد، نقاط قوت و ضعف آنها تمرکز می‌کند و از آنجایی که اهداف كسب­ و كار مبنايي برای تحلیل، توجیه و ارزیابی سیستم ­های نرم­ افزاری می باشند، در انتها نیز به بررسی اهداف کسب و کار که بر ارزیابی و تحلیل معماری تاثیر می گذارند، پرداخته می شود. سیستم­ های نرم افزاری برای تحقق اهداف كسب­ و كار یا ماموریتی ساخته می­ شوند. اهداف كسب و كار زیربنای بسیاری از متدها برای طراحی و تحلیل معماری نرم افزار هستند. با این حال، استخراج دقیق و تعيين اهداف كسب­ و كار همیشه مشکل­ ساز بوده است چرا که اهداف کسب و کار در اشکال مختلف و در سطوح مختلف انتزاعی وجود دارند و ذینفعان سیستم معمولاً عادت ندارند اهداف را به صورت واضح بیان کنند. 1. مقدمهارزیابی معماری نرم ­افزار تکنیک یا روشی است که ویژگی­ ها، نقاط قوت و ضعف معماری نرم ­افزار، سبک معماری نرم­ افزار یا الگوی طراحی را تعیین می­ کند. ارزیابی معماری نرم­ افزار به توسعه ­دهندگان اطمینان می­ دهد که معماری انتخابی آنها هم نیازمندی­ های عملکردی و هم غیرعملکردی و کیفی را برآورده می ­کند. یک ارزیابی معماری باید مزایای بیشتری نسبت به هزینه­ ی انجام آن داشته باشد. ارزیابی معماری نرم­ افزار افزایش درک از سیستم و مستندسازی آن، تشخیص مشکلات موجود در معماری و یادگیری سازمانی را تضمین می­ کند. چندین روش و تکنیک برای ارزیابی معماری نرم افزار پیشنهاد شده است. در میان آنها، رویکردهای مبتنی بر سناریو کاملاً بالغ در نظر گرفته می شوند. همچنین روش های دیگری بر مبنای مدل ویژگی و مدل های کمی برای ارزیابی معماری نرم افزار نیز وجود دارند و روش‌های دیگری برای توجیه سیستماتیک ویژگی‌های سبک‌های معماری و الگوهای طراحی ایجاد شده‌اند. 2. آشنایی با برخی نیازمندی های معمارانه مهمتعیین اینکه کدام نیازمندی ها دارای اهمیت معمارانه هستند بسیار حائز اهمیت است. برای هر سیستم خاص، نیازمندی های معمارانه مهم باید با اهداف کسب و کار و مأموریت سیستم همسو باشند. برخی از ویژگی­ های سیستم (ها) علاوه بر جنبه ­ی عملکردی سیستم باید از نظر معماری نیز اهمیت داشته باشند. نیازمندی های معمارانه­ مهم اغلب از موارد زیر نشات می­ گیرند:ویژگی­ های کیفی (Quality Attributes) امنیت(Security)، کارایی (Performance) ، قابلیت اطمینان (Reliability)، قابلیت تغییر (Modifiablity) و ... همه ویژگی‌های کیفیتی هستند که ممکن است بر ساختار سیستم تأثیر بگذارند. هر ویژگی کیفی دارای مجموعه­ای از تکنیک‌های ساختاری است (به عنوان مثال، تاکتیک‌های معمارانه ذکر شده در کتاب Bus) که برای دستیابی به این ویژگی­ ها به کار می ­روند. حجم عملکرد (volume of functionality):هر عملکرد خاص بر ساختار معماری تأثیری نخواهد داشت، اما مجموعه های بزرگی از عملکردهای مشابه تأثیرگذار خواهند بود. یکی از نمونه‌های مربوط به تأثیر ساختاری، شکستن عملکرد است تا بتوان آن را به موقع اجرا کرد. مثال دیگر شناسایی اشتراکات در عملکرد برای کاهش زمان اجرا و نگهداری می­ باشد. معماری برای گروهی از سیستم های مرتبط:هنگامی که نیازمندی های مجموعه‌ای از سیستم‌های مشابه مانند خط تولید نرم‌افزار جمع‌آوری می‌شوند، اشتراکات و تغییرات در آن سیستم‌ها ممکن است از نظر معماری قابل توجه باشند.انتخاب تکنولوژی­ ها:ممکن است نیاز به استفاده از یک فناوری خاص برای یک سیستم، مانند NET. یا J2EE (Java 2 Enterprise Edition) وجود داشته باشد. این نیازمندی ها احتمالا از نظر معماری مهم هستند، زیرا بسیاری از تصمیمات بعدی با به کاربردن فناوری­ های خاص محدود می­ شوند.استقرار و عملیات: نیازمندی هایی که استراتژی های مربوط به استقرار پیش‌بینی‌شده و نحوه­ ی عملکرد سیستم را توصیف می‌کنند، از نظر معماری مهم هستند زیرا ممکن است موجودیت‌های ساختاری، ملزم به حمایت از استقرار یا ملاحظات عملیاتی باشند. 3. متدهای ارزیابی معماری در چرخه عمر نرم افزارتعدادی از روش های ارزیابی معماری که در مراحل مختلف چرخه توسعه نرم افزار قابل اجرا هستند، توسعه یافته اند. در برخی از این متدها دو فرصت اصلی برای ارزیابی معماری قبل و بعد از اجرا وجود دارد. روش­ های ارزیابی زودهنگام پیش از اجرا در معماری نرم­ افزار اعمال می­ شوند. در صورتی که معماری نرم­ افزار با توجه به نیازمندی­ های کیفی خاص آن در مراحل اولیه­ توسعه نرم ­افزار ارزیابی شود، می­ توان به اهداف کیفی دست یافت. روش‌های ارزیابی دیرهنگام نیز تفاوت بین معماری واقعی و معماری برنامه‌ریزی شده را مشخص می‌کنند. این روش­ ها دستورالعمل­ های مفیدی را در مورد چگونگی بازسازی معماری واقعی ارائه می­ دهند تا با معماری برنامه ریزی شده مطابقت داشته باشد.3.1 روش­ های ارزیابی زودهنگام معماری نرم افزارارزیابی زودهنگام معماری نرم افزار را می­ توان بر اساس مشخصه­ ها و توصیف معماری نرم­ افزار انجام داد. این ارزیابی به این صورت است که در رویکردهای مبتنی بر سناریو انعطاف‌پذیری و سادگی دیده می شود. تکنیک‌های ارزیابی مبتنی بر مدل ریاضی برای ارزیابی ویژگی‌های کیفی عملیاتی، مانند قابلیت اطمینان (reliability) و کارایی (performance) به‌ویژه در سیستم‌های نرم‌افزاری بلادرنگ ،به‌خوبی به کار می روند. 3.1.1 روش های ارزیابی معماری نرم افزار مبتنی بر سناریوروش‌های ارزیابی مبتنی بر سناریو، توانایی معماری نرم‌افزار را با توجه به مجموعه‌ای از سناریوهای مورد علاقه ارزیابی می­ کنند. سناریو شرح مختصری از یک تعامل واحد بین یک ذینفع با یک سیستم است. روش­ های ارزیابی مبتنی بر سناریو ابزاری سیستماتیک برای بررسی نرم افزار و معماری با استفاده از سناریوها ارائه می ­دهد. این روش­ ها تعیین می­ کنند که آیا معماری نرم ­افزار می­ تواند یک سناریو را اجرا کند یا خیر. تیم ارزیابی سناریو را بر روی معماری نرم‌افزار کاوش یا نگاشت می‌کند تا مولفه های معماری مورد نظر و تعاملات بین آنها را که می‌تواند وظایف بیان شده از طریق سناریو را انجام دهد، پیدا کند. در صورتی که معماری نرم ­افزار نتواند سناریو را اجرا کند، این رویکرد تغییرات مورد نیاز معماری نرم­ افزار را جهت پشتیبانی از سناریو فهرست کرده و هزینه انجام تغییرات را تخمین می­ زند. روش­ های ارزیابی مبتنی بر سناریو مستلزم حضور ذی­نفعان مربوطه برای استخراج سناریوها بر اساس نیازمندی ­های آنها می­ باشد. روش‌های مبتنی بر سناریو می‌توانند کشف مشکلات در معماری نرم‌افزار را از دیدگاه‌های مختلف با درگیر کردن ذینفعان متعدد در طول فرآیند استخراج سناریو تضمین کنند، کاربر نهایی نیز می‌تواند مسائل مربوط به کارایی (performance) را نشان دهد. در زیر مجموعه ای از روش های ارزیابی مبتنی بر سناریو آمده است:SAAM (Scenario-based Software Architecture Analysis Method)ATAM (Architecture based Tradeoff Analysis Method)ALPSM (Architecture-Level Prediction of Software Maintenance) and ALMA (Architecture-Level Modifiability Analysis)CBAM (Cost-Benefit Analysis Method)FAAM (Family-Architecture Assessment Method)SALUTA (Scenario-based Architecture Level UsabiliTy Analysis)SBAR (Scenario-Based Architecture Reengineering)SAAMCS (SAAM for Complex Scenarios)ESAAMI (Extending SAAM by Integration in the Domain)ASAAM (Aspectual Software Architecture Analysis Method)SACAM (Software Architecture Comparison Analysis Method) and DoSAM (Domain Specific Software Architecture Comparison Model)شکل - 1: رفتار رایج در روش های ارزیابی مبتنی بر سناریو3.1.1.1. مقایسه روش ­های مختلف ارزیابی مبتنی بر سناریومتد ارزیابی: SAAMهدف اصلی: تحلیل تناسب معماری و ریسکمراحل ارزیابی: شامل شش فعالیت است که برخی از فعالیت­ ها به صورت موازی انجام می­شوند- شامل هیچگونه فعالیت آماده سازی نیست.طبقه­ بندی سناریو و تحلیل تاثیر: به سناریوهای مستقیم و غیرمستقیم طبقه بندی می شوند. تعداد مؤلفه­ هایی را که تحت تأثیر سناریوها قرار می­گیرند، شمارش می­ کند. رویکردهای مورد استفاده: استخراج سناریو از طریق برگزاری طوفان فکری با ذینفعان. نگاشت سناریوها روی SAها برای تأیید عملکرد یا برآورد هزینه تغییراهداف آنالیز شده: اسناد معماری، به ویژه، نمایش نماهای منطقیتضمین کیفیت (QAهای آدرس داده شده): عمدتاً قابل تغییر است اما می­ توان آن را تطبیق داد.متد ارزیابی: ATAMهدف اصلی: آنالیز حساسیت و برآورد کردن (Tradeoff)مراحل ارزیابی: شامل نه فعالیت می باشد، برخی از فعالیت ­ها به صورت موازی انجام می­ شوند. فعالیت­ های آماده سازی را شامل می شود. طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای مورد کاربردی، رشد و کاوش نقاط حساسیت و نقاط برآورد (Tradeoff) را می­ شمارد.رویکردهای مورد استفاده: ایجاد درخت سودمندی برای استخراج سناریوها. تحلیل رویکردهای معماری با استفاده از مدل­ های تحلیلی برای شناسایی نقاط و برآورد کردن (Tradeoff) ریسک­ هااهداف آنالیز شده: رویکردها یا سبک­ های معماری؛ اسناد معماری عمدتاً 1+4 Kurcten را نشان می­ دهد.تضمین کیفیت (QAهای آدرس داده شده): QAs چندگانهمتد ارزیابی: ALMAهدف اصلی: پیش بینی هزینه تعمیر و نگهداری، ارزیابی ریسک، مقایسه معماریمراحل ارزیابی: شامل پنج فعالیت است، همچنین فعالیت استخراج سناریو شامل شش فعالیت است که به صورت متوالی اجرا می شوند. به هیچ فعالیت آماده سازی نیاز نیست.طبقه­ بندی سناریو و تحلیل تاثیر: تغییر سناریو. تخمین تغییر اندازه هر مولفه رویکردهای مورد استفاده: استخراج سناریو بر اساس اهداف ارزیابی. نگاشت سناریوها بر روی SAها برای برآورد هزینه تعمیر و نگهداری با در نظر گرفتن اثرات ریپل.اهداف آنالیز شده: مستندات معماری، در مورد ساختار سیستم نیز شامل مولفه­ ها و اتصالات (مانند نمای منطقی) است.تضمین کیفیت (QAهای آدرس داده شده):قابلیت استفاده مجدد (Reusability)متد ارزیابی: CBAMهدف اصلی: ارائه معیارهای کسب و کار برای تغییرات سیستمی خاص . عدم قطعیت مربوط به تخمین ها را صراحتا بیان می کند.مراحل ارزیابی: شامل شش مرحله اصلی، کمّی سازی مزایای کیفیت، هزینه و زمان بندی مفاهیم مربوط به استراتژی های معماری است. طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای مستقیم، غیرمستقیم و کاوشی. زمان و هزینه استفاده شده توسط سناریوها را محاسبه می کند.رویکردهای مورد استفاده:آنالیز مزایای مربوط به استراتژی های مختلف معماری، ارزیابی کیفیت، و محاسبه مطلوبیت با توجه به هزینه و عامل زمان.اهداف آنالیز شده: زمان و هزینه دخیل در تحلیل عوامل کیفی و مستندات معماریتضمین کیفیت (QAهای آدرس داده شده):هزینه ها، مزایا، و پیامدهای برنامه ریزیمتد ارزیابی: FAAMهدف اصلی: تاکید بر توانمندسازی تیم ها در به کارگیری نشست FAAMمراحل ارزیابی: شامل شش مرحله اصلی است، این مراحل باید در پاسخ به تجربه ارزیابی کلی معماری سازمان تطبیق داده شوند.طبقه­ بندی سناریو و تحلیل تاثیر: تمرکز بر سناریوهای قابل تعامل. فرآیند ارزیابی کلی برای حوزه سیستم های اطلاعاتی طراحی شده است.رویکردهای مورد استفاده:ایجاد رهنمودها و الگوها در ایجاد تغییر، راهنماها و الگوها و معیارهای رتبه­ بندی نیازمندی ها.اهداف آنالیز شده: اسناد معماری، به ویژه، نشان دادن نماهای منطقیتضمین کیفیت (QAهای آدرس داده شده):تعامل پذیری و توسعه پذیریمتد ارزیابی:SALUTAهدف اصلی: آنالیز قابلیت استفاده (Usability) مراحل ارزیابی: شامل چهار مرحله اصلی است که به صورت متوالی اجرا می شود- هیچگونه فعالیت آماده سازی نیاز نیست.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای استفاده و تحلیل کیفیرویکردهای مورد استفاده: به کار گیری پروفایل ها برای بیان نیازمندی قابلیت استفاده. پیش‌بینی سناریو برای آنالیز ویژگی‌ها و الگوهای قابلیت استفاده استخراج‌شده.اهداف آنالیز شده: الگوهای قابلیت استفاده، ویژگی های قابلیت استفادهتضمین کیفیت (QAهای آدرس داده شده):نمای خاصی توصیه نمی شود. متد ارزیابی:SBARهدف اصلی: مهندسی مجدد SA برای دستیابی به QAsمراحل ارزیابی: شامل سه مرحله است که بارها و بارها اجرا شده اند. هیچ فعالیت آماده سازی نیاز ندارد.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای توسعه و عملیاتی و تحلیل کیفیرویکردهای مورد استفاده: ارزیابی کیفیت با استفاده از یکی از چهار تکنیک و تحول معماریاهداف آنالیز شده: در ابتدا اسناد معماری ایجاد شد. نمای خاصی توصیه نمی شود.تضمین کیفیت (QAهای آدرس داده شده):QAs چندگانهمتد ارزیابی:SAAMCSهدف اصلی: توسعه سناریوهای پیچیده برای دستیابی به انعطاف پذیری خاصی از دامنهمراحل ارزیابی: شامل سه مرحله است که دو مرحله آن به صورت موازی اجرا می شوند. هیچ فعالیت آماده سازی ندارد.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای پیچیده. همان SAAM است اما چهار سطح تأثیر را تعریف می کند.رویکردهای مورد استفاده: تجزیه و تحلیل SAs برای تعیین مقادیر سه عاملی که سناریوها را پیچیده می کنند.اهداف آنالیز شده: مستندات معماری خرد و کلانتضمین کیفیت (QAهای آدرس داده شده):انعطاف پذیریمتد ارزیابی:ESAAMIهدف اصلی: ادغام SAAM در فرآیند توسعه مبتنی بر استفاده مجدد از دامنه خاصمراحل ارزیابی: مانند SAAM اما وجود پایگاه دانش قابل استفاده مجدد را در نظر می گیرد.طبقه­ بندی سناریو و تحلیل تاثیر: مشابه SAAMرویکردهای مورد استفاده: فرمولاسیون یک الگوی تحلیل برای جمع آوری محصولاتی با قابلیت استفاده مجدداهداف آنالیز شده: اسناد معماری نرم افزار با قابلیت استفاده مجددتضمین کیفیت (QAهای آدرس داده شده):قابلیت تغییر(Modifiability)متد ارزیابی:ASAAMهدف اصلی: تحلیل جنبه های معماریمراحل ارزیابی: مشابه SAAM اما شامل جنبه های معماری و شناسایی مولفه های درهم نیز است.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای مستقیم، غیرمستقیم و جنبه ای و تحلیل کیفیرویکردهای مورد استفاده: شناسایی جنبه های معماری از سناریوهای مستقیم و غیرمستقیم. تعامل سناریوهای جنبه ای برای شناسایی مولفه های مختلف، مانند مولفه های درهم و بد تعریف شدهاهداف آنالیز شده: مشابه SAAMتضمین کیفیت (QAهای آدرس داده شده):قابلیت تغییر(Modifiability)متد ارزیابی:SACAMهدف اصلی: مقایسه معماری نرم افزار از منظر حوزه های مختلفمراحل ارزیابی: شامل شش فعالیت است که به صورت مکرر اجرا می شود. شامل فعالیت های آماده سازی می باشد.طبقه­ بندی سناریو و تحلیل تاثیر: مشابه ATAM است.معیارها را تعیین می کند.رویکردهای مورد استفاده: گردآوری معیارهای مقایسه ای که SAهای کاندید را در یک نمای معماری مشترک ارائه می دهد، و تناسب SAs w.r.t. به معیارها را تحلیل می کند.اهداف آنالیز شده: مشابه ATAMتضمین کیفیت (QAهای آدرس داده شده):QAs چندگانهمتد ارزیابی:DoSAMهدف اصلی: مقایسه معماری نرم افزار از منظر یک دامنه خاصمراحل ارزیابی: شامل شش فعالیت است که به صورت متوالی اجرا می شوند. هیچ فعالیت آماده سازی نیاز ندارد.طبقه­ بندی سناریو و تحلیل تاثیر: اجرا نشده است.مشابه SCAMرویکردهای مورد استفاده: نگاشت معماری های کاندید به DACF، ارزیابی QA ها با استفاده از معیارها و مقایسه معماری ها بر اساس مقادیر متریک QAsاهداف آنالیز شده: مستندات معماری. نمای خاصی توصیه نمی شود.تضمین کیفیت (QAهای آدرس داده شده):QAs چندگانه3.1.2. ارزیابی معماری نرم ­افزار مبتنی بر مدل ریاضیاکثر روش‌های ارزیابی معماری نرم‌افزار مبتنی بر سناریو (به استثنای ATAM و SBAR) از استدلال­ های کیفی برای ارزیابی ویژگی‌های کیفی در زمان توسعه، استفاده می‌کنند. با این حال، برای اندازه‌گیری تناسب سیستم‌های نرم‌افزاری حیاتی، مانند نرم افزارهای حوزه ­های پزشکی، هواپیما، و مأموریت­ های فضایی، ارزیابی کمی ویژگی‌های کیفی عملیاتی نیز مهم است. بنابراین، تعدادی از روش‌های ارزیابی معماری نرم‌افزار مبتنی بر مدل ریاضی ایجاد شده‌اند. این روش ­ها معماری نرم­ افزار را با استفاده از معادلات ریاضی شناخته شده مدل می­ کنند. این روش ­ها از مدل­ ها برای به دست آوردن آمار و ارقام معماری، به عنوان مثال، میانگین زمان اجرای یک مولفه استفاده می­ کنند. این آمارهای معماری برای برآورد ویژگی­ های کیفی عملیاتی استفاده می­ شوند. Reliability و performance دو ویژگی کیفی مهم عملیاتی هستند. برای ارزیابی این دو ویژگی کیفی، طیف وسیعی از مدل‌های ریاضی ایجاد شده‌اند. دو رویکرد مختلف برای ارزیابی Reliability معماری نرم ­افزار به کار می­ رود که مبتنی بر مسیر و حالت هستند. SPE، WS، PASA، CM، BIM، ABI، AABI نیز رویکردهایی برای پیش‌بینی کارایی در سطح معماری می­ باشند.شکل - 2: تجزیه کارایی (performance) مبتنی بر معماری نرم افزار3.2. متدهای ارزیابی دیرهنگامسیستم های نرم افزاری برای رفع مشکلات و سازگاری با نیازهای جدید، به صورت مداوم اصلاح می شوند. توسعه دهندگانی که تحت فشار زمانی شدید و بار کاری سنگین فعالیت می کنند، همیشه نمی توانند بهترین راه را برای اعمال تغییرات دنبال کنند. در نتیجه معماری واقعی ممکن است نسبت به معماری برنامه ریزی شده دچار انحراف شود. روش‌های ارزیابی معماری نرم‌افزار دیرهنگام دستورالعمل­ های مفیدی را در مورد چگونگی بازسازی معماری واقعی ارائه می دهند تا با معماری برنامه­ ریزی شده مطابقت داشته باشد. در طول مرحله تست، روش‌های ارزیابی دیرهنگام معماری نرم‌افزار نیز برای بررسی انطباق کد منبع با طراحی برنامه‌ریزی شده اعمال می‌شوند. اقتصادی بودن فرآیند تأیید انطباق کد طراحی نه تنها باعث صرفه جویی در زمان به روز رسانی طرح ها می شود، بلکه مصنوعات طراحی و همچنین فرآیندهای توسعه و نگهداری نرم افزار را بهبود می بخشد. ارزیابی دیرهنگام معماری نرم ­افزار می­ تواند از داده­ های اندازه­ گیری شده در اجرای معماری نرم­ افزار استفاده کند. معیارها را می توان برای بازسازی معماری واقعی نرم افزار مورد استفاده قرار داد و به آن اجازه داد تا با معماری برنامه ریزی شده مقایسه شوند. شکل - 3: فعالیت های مربوط به ارزیابی دیرهنگام معماری نرم افزار3.2.1. مقایسه روش ­های مختلف ارزیابی دیرهنگام معمارینام رویکرد: رویکرد Tvedt و همکارانهدف اصلی: جلوگیری از انحطاط سیستم با شناسایی فعال و سیستماتیک و اصلاح انحرافات معماری واقعی نرم افزار از معماری برنامه ریزی شده.رویکرد مورد استفاده: بررسی نیازمندی­ های عملکردی و غیر عملکردیمراحل در ارزیابی دیرهنگام: شناسایی معماری واقعی، بررسی انحراف معماری واقعی نسبت به معماری برنامه ریزی شده، در نظر گرفتن توصیه های مربوط به تغییرات.تخلف شناسایی شده: الگوی طراحی، کلاس های نامناسب و تخلفات جزئینام رویکرد: رویکرد لیندوال و همکارانهدف اصلی: شناسایی مشکلات نگهداری در سیستم نرم افزاری و سیستمی که به عنوان سیستم مبتنی بر مولفه بازسازی شده است، استفاده از الگوی طراحی جدید.رویکرد مورد استفاده: طراحی یک سیستم مبتنی بر مؤلفه (EMS) برای رسیدگی به مشکلات قابلیت نگهداری در سیستم نرم افزاریمراحل در ارزیابی دیرهنگام: معماری واقعی جدید را با معماری واقعی قبلی و معماری واقعی برنامه ریزی شده مقایسه کنید.تخلف شناسایی شده: نقض اتصال بین ماژولینام رویکرد: رویکرد Fiutem و Antoniol (مبتنی بر ابزار)هدف اصلی: تعیین ناهماهنگیرویکرد مورد استفاده: طراحی بازیابی شده را با طراحی برنامه ریزی شده مقایسه می کند.مراحل در ارزیابی دیرهنگام: مقایسه و تعیین ناسازگاری هاتخلف شناسایی شده: برخی موارد نقض کدنام رویکرد: رویکرد Murphy و همکاران (مبتنی بر ابزار)هدف اصلی: به منظور بررسی انطباق کد منبع با معماری برنامه ریزی شده.رویکرد مورد استفاده: به کار بردن دنباله ای از مدل های بازتابی برای مقایسه طراحی معماری لایه.مراحل در ارزیابی دیرهنگام: بررسی اینکه آیا مدل سطح بالا با کد منبع موافق است یا مخالف. نگاشت اعلامی بین دو مدل را بررسی می کند.تخلف شناسایی شده: نقض فراخوانی بین ماژول هانام رویکرد: رویکرد Sefika و همکاران (مبتنی بر ابزار)هدف اصلی: تعیین همخوانی طراحی و اجرا در سطوح مختلف انتزاع. یک رویکرد ترکیبی است که تجسم های استاتیک و پویا مبتنی بر منطق را یکپارچه می کند.رویکرد مورد استفاده: رویکرد هیبریدمراحل در ارزیابی دیرهنگام: تجسم های منطقی، ایستا و پویا را یکپارچه می کند.تخلف شناسایی شده: نقض الگوی طراحی3.3. مباحثه در مورد روش های ارزیابی معماری گفته شده در این مقالهاکثر روش های مبتنی بر سناریو در سطوح درشت دانه مشابه هستند. اما تفاوت های قابل توجهی در سطوح ریز دانه­ تر بین آنها وجود دارد. روش های مختلف، سناریوها را به صورت متفاوت طبقه بندی می کنند. برخی از روش ها سناریوها را به صورت مستقیم و غیرمستقیم طبقه بندی می کنند، در حالی که برخی دیگر از سناریوهای مورد کاربرد یا سناریوهای رشد استفاده می کنند. یک روش ممکن است تعداد مؤلفه های تحت تأثیر یک سناریوی خاص را شمارش کند، در حالی که دیگری ممکن است از معیارها برای هر ویژگی کیفی استفاده نماید. از تحلیل تطبیقی چنین برداشت می شود کهبرخی از روش های مبتنی بر سناریو، به ویژه SAAM، ATAM و ALMA، با موفقیت در محیط های مختلف صنعتی به کار گرفته شده اند. روش‌های ارزیابی مبتنی بر سناریو اساساً از سناریوهای تغییر و سناریو تعاملات برای افشای مناطق مربوط به مشکل در معماری استفاده می‌کنند.این روش ها خطرات یک سیستم نرم افزاری را با تخمین درجه تغییراتی که معماری نرم افزار برای اجرای یک سناریو نیاز دارد، اندازه گیری می کنند.در روش های مبتنی بر سناریو، ارزیابی پوشش سناریو دشوار است. توسعه یک چارچوب یا روش‌شناسی به تعیین پوشش سناریو کمک می‌کند.رویکرد SAAMCS گام خوبی به سمت چارچوب است.تعداد بسیار کمی از روش‌های مبتنی بر سناریو توسط ابزار پشتیبانی می‌شوند. به عنوان مثال، فقط فعالیت های SAAM و ATAM تا حدی توسط ابزار پشتیبانی می شوند.به نظر می رسد رویکردهای ارزیابی مبتنی بر Performance نسبت به reliability ، بالغ تر هستند.رویکردهای مبتنی بر Performance عمدتاً بوسیله­ ی ابزار پشتیبانی می‌شوند، اگرچه هیچ یک از ابزارها نمی‌توانند فرآیند تحلیل کامل معماری را پشتیبانی کنند.رویکردهای ارزیابی مبتنی بر Performance رفتار همزمان و غیر قطعی مولفه­ های نرم افزار را در نظر می گیرند.رویکردهای ارزیابی مبتنی بر reliability از پشتیبانی ابزار چندانی برخوردار نیستند و این روش‌ها هنوز برای حمایت از رفتارهای همزمان و غیر قطعی مولفه­ های نرم‌افزار در حال تکامل هستند. ارزیابی مبتنی بر مدل ریاضی برای سیستم نرم افزاری مبتنی بر مولفه مناسب هستند.تبدیل معماری نرم افزار به یک مدل ریاضی دشوار است و استفاده از روش های ارزیابی معماری مبتنی بر مدل ریاضی نسبتاً کمتر از روش های ارزیابی مبتنی بر سناریو هستند.در ارزیابی معماری نرم‌افزار دیرهنگام، هدف اصلی ارائه ابزاری ارزان و سریع برای تشخیص تخلفات در معماری نرم‌افزار با تکامل سیستم‌های نرم‌افزاری است. بنابراین، این روش‌های ارزیابی بیشتر با ابزار پشتیبانی می‌شوند. رویکردهای مبتنی بر معیارها تنها برای ارزیابی معماری نرم‌افزار با توجه به دیدگاه قابلیت نگهداری استفاده شده‌اند. ارزیابی دیرهنگام معماری نرم افزار تا حد زیادی به تحلیل سازگاری طراحی-کد می پردازد.ارزیابی دیرهنگام معماری نرم‌افزار فاقد چارچوب رسمی و طبقه‌بندی شده برای تحلیل ناهماهنگی‌های طراحی و کد و اولویت‌بندی مداخلات برای طراحی است.4. دسته بندی اهداف کسب و کارهمانطور که در شکل 3 نشان داده شده است، پنج طبقه­ بندي برای اهداف کسب و کار براساس منبع [7] وجود دارد: (1) کاهش کل هزینه مالکیت(2) بهبود قابلیت/کیفیت سیستم(3) بهبود موقعیت بازار(4) پشتیبانی از فرآیندهای بهبود یافته كسب­ و كار (5) افزایش اعتماد و درک سیستم. شکل 4: طبقه ندي اهداف كسب وكار 4.1. کاهش کل هزینه مالکیت کاهش هزینه­ ها یکي از اهداف كسب ­وكار است که اغلب در ارزیابی­ های ATAM ذکر مي­ گردد. در برخی موارد کاهش هزینه به عنوان یک هدف کلی ذکر مي­ شود. در موارد دیگر، کاهش هزینه در بخش خاصی از چرخه عمر شناسایی مي­ گردد. در دسته بندی ارائه شده در منبع [7] این گروه بندی از اهداف تحت عنوان کاهش کل هزینه مالکیت نام گذاری شده و شامل زیر گروه های زیر می باشد:کاهش هزینه های توسعه کاهش هزینه های استقرار و عملیاتکاهش هزینه های نگهداری کاهش هزینه های بازنشستگی / انتقال به یک سیستم جدید انواع اهداف كسب­ و كاري که این گروه ­ها را تشکیل می دهند به شرح زیر می باشند:کاهش هزینه های توسعه- مديريت انعطاف­ پذیری- توسعه توزیع شده- قابل حمل بودن- سیستم ­ها/استانداردهای باز- تست­ پذیری- خطوط تولید- قابلیت یکپارچگی- تعامل­ پذیریکاهش هزینه استقرار و عملیات- سهولت نصب- سهولت تعمیر کاهش هزینه ­های نگهداری- انعطاف­ پذیری/قابلیت پیکربندیکاهش هزینه بازنشستگی / انتقال به یک سیستم جدید- بازنشستگی سیستم­ ها- انتقال تدریجی به سیستم ­های بعدی- جایگزین کردن سیستم­ های قدیمیتوجه داشته باشید که بسیاری از این اهداف تجاری ویژگی ­های کیفی هستند [8]. همه ویژگی ­های کیفی به طور بالقوه اهداف کسب­ و کار هستند، اما همه اهداف کسب­ و کار ویژگی­ های کیفیت محسوب نمی­شوند [7]­.4.2. بهبود قابلیت/کیفیت سیستمبهبود قابلیت/ کیفیت سیستم گروه دیگری از اهداف کسب ­و کار هستند که اغلب به بهبود قابلیت یا کیفیت یک سیستم در مقایسه با نسخه های قبلی همان سیستم یا در تضاد با سیستم(های) در حال جایگزینی اشاره دارند. گاهی اوقات اهداف کسب­ و کار فقط نیازمندی­ های سیستم فعلی را بدون ارجاع به سیستم های قبلی مشخص می کند. این طبقه­ بندی به شرح زیر است:کارایی (performance)قابلیت اطمینان/در دسترس بودنخطوط تولید سهولت استفاده امنیت (security) ایمنی (safety)مقیاس پذیری/توسعه پذیری (scalability/extendibility) عملکرد (functionality) محدودیت­ های سیستمبین­ المللی شدن (internationalization)4.3. بهبود موقعیت بازاربرخی از اهداف تجاری که از ارزیابی های تجاری ATAM به وجود آمده اند، با موقعیت یا زمان بندی بازار مرتبط هستند. زیرگروه های اهداف زیربنایی این دسته به شرح زیر است:گسترش یا حفظ سهم بازارحفظ یا بهبود اعتبارورود به بازارهای جدیدکاهش زمان ورود به بازار4.4. پشتیبانی از فرآیندهای کسب ­و کار بهبود یافتهدسته قابل توجه دیگری از اهداف کسب و کار مربوط به بهبود فرآیندهای داخلی کسب و کار و ساختار سازمان است. زیر گروه های اساسی اهداف به شرح زیر است:پشتیبانی از توسعه توزیع شدهحفظ مشاغل نیروی کار در سیستم های قدیمی4.5. بهبود اعتماد و درک سیستمدسته نهایی شامل اهدافی است که برای ارتقای اعتبار سازمان در حال توسعه در نظر گرفته شده است. یک زیر گروه از اهداف در این دسته بیشتر وجود ندارد: حفظ/ گسترش اعتبار5. کاربرد دسته بندی اهداف کسب و کاردر مجموعه اهداف کسب­ و کار استخراج شده از ارزیابی‌های گذشته ATAM، سازمان‌ها معمولاً در ایجاد درخت سودمندی سطح بالا و ارائه اهداف کسب­ و کار با مشکل مواجه بودند. علاوه بر این، اهداف کسب­ و کاری که آنها ارائه می­ کردند کیفیت های بسیار متفاوتی داشت. اغلب، سازمان ها به سادگی یک ارائه موجود را بهبود می بخشیدند. این ارائه معمولاً به خوبی با نیازهای ATAM تنظیم نشده بود و از این رو نتایج ضعیفی به همراه داشت. در نتیجه در منبع [5] دو کاربرد اساسی و مهم برای دسته بندی اهداف کسب و کار معرفی گردید: سازمان ها را قادر می سازد تا اهداف کسب­ و کار خود را متمرکزتر و کامل تر ارائه دهند: یک سازمان می‌تواند با استفاده از این طبقه‌بندی، اطمینان حاصل کند که مجموعه کامل و جامعی از اهداف کسب­ و کار را ایجاد کرده است. ساده سازی تولید درخت سودمندی از طریق درج اهداف کسب­ و کار در سطوح بالاتر درخت و ارائه سناریوهای نمونه برای هر هدف کسب­ و کار: درخت مطلوبیت یک ابزار استخراج و ساختاردهی مفید بالا به پایین است که سال‌ها با موفقیت در ارزیابی‌های ATAM استفاده می­شد. با این حال، معمولاً ذینفعان در شروع فرآیند با مشکل مواجه می شدند. داشتن اهداف کسب ­و کار نمونه برای نمایش به ذینفعان، همراه با سناریوهای نمونه ای که برگرفته از این اهداف هستند، شروع فرآیند را تسهیل می­ بخشد. از منظر ارزیابی ATAM، اهدف کسب‌وکار دو جنبه دارد: 1. منتهی به سناریوهای ویژگی کیفی شود و 2. مضامین ریسک از نظر تهدیدات اهداف کسب­ و کار را بیان کند. در ادامه سناریوهای منتهی به ویژگی های کیفی را برای هر یک از طبقه بندی های ارائه شده برای اهداف کسب و کار و زیر گروه های آنها ارائه می کنیم: کاهش هزینه توسعه- هدف کسب و کار: مدیریت انعطاف پذیری- سناریو ویژگی ­های کیفی: یک پارامتر اضافی به سیستم اضافه می شود. مقدار این پارامتر برای سازگاری و مقادیر نادرست احتمالی در عرض 10 دقیقه بررسی می شود.- هدف کسب و کار: توسعه توزیع شده- سناریو ویژگی ­های کیفی: مؤلفه A در مکان X و مؤلفه B در مکان Y در حال توسعه هستند. یک ضرب­ العجل (deadline) برای هر دو مؤلفه A و B تعیین می شود. علت ضرب­ العجل مشخص می شود و راه حلی در عرض دو نفر-روز پیشنهاد می شود.- هدف کسب و کار: قابل حمل بودن (portability)- سناریو ویژگی ­های کیفی: سیستم A از پلتفرم B به پلتفرم C بدون از دست دادن عملکرد در عرض دو نفر-هفته منتقل می شود.- هدف کسب و کار: سیستم­ ها/استانداردهای باز- سناریو ویژگی ­های کیفی:مولفه­ای که به استاندارد X پایبند است طی دو نفر-روز در سیستم یکپارچه می­شود.- هدف کسب و کار: تست­ پذیر بودن- سناریو ویژگی ­های کیفی: یک تغییر در یک ویژگی به صورت کامل در عرض دو نفر-روز تست می­شود.- هدف کسب و کار: خطوط تولید- سناریو ویژگی ­های کیفی: محصول جدید تولید می­شود. این محصول باید از بیش از 80 درصد از دارایی های اصلی مجدداً استفاده کند و تکمیل آن بیش از هشت نفر سال طول نمی کشد.- هدف کسب و کار: یکپارچگی- سناریو ویژگی ­های کیفی: یکپارچگی زیرسیستم های A، B، و C در مدت دو نفر-ماه تکمیل می شود.- هدف کسب و کار: تعامل پذیری- سناریو ویژگی ­های کیفی: در صورت استقرار، سیستم A می‌تواند با سیستم‌های B و C موجود با استفاده از پروتکل D بدون تغییر زیادی کار کند. کاهش هزینه استقرار و عملیات- هدف کسب و کار: سهولت نصب و تعمیر- سناریو ویژگی ­های کیفی: نسخه جدید سیستم A را می توان در عرض دو روز بر روی دسکتاپ همه کاربران نصب و مستقر کرد.- سناریو ویژگی ­های کیفی: تعداد اپراتورهای مورد نیاز برای راه اندازی سیستم A نصف تعداد مورد نیاز برای راه اندازی سیستم B موجود خواهد بود. کاهش هزینه تعمیر و نگهداری- هدف کسب و کار: انعطاف پذیری/پیکربندی- سناریو ویژگی ­های کیفی: یک ویژگی جدید را می توان در عرض دو روز به سیستم A اضافه کرد. کاهش هزینه بازنشستگی/ انتقال به سیستم جدید- هدف کسب و کار: بازنشستگی سیستم ­ها، انتقال تدریجی به سیستم ­های بعدی و جایگزینی سیستم ­های قدیمی- سناریو ویژگی ­های کیفی: در پایان عمر مفید، سیستم A را می توان بازنشسته کرد و عملکردهای آن را می توان در عرض دو نفر روز به یک سیستم جدید منتقل کرد، به استثنای تغییرات سخت افزاری. بهبود قابلیت/کیفیت سیستم- هدف کسب و کار: کارایی (performance)- سناریو ویژگی ­های کیفی: کاربر یک درخواست یک نقشه را از طریق اینترنت در طول عملیات عادی وارد می کند و نقشه کامل در عرض دو ثانیه برای کاربر ارسال می شود.- هدف کسب و کار: قابلیت اطمینان/در دسترس بودن- سناریو ویژگی ­های کیفی:هنگامی که یک سنسور پاسخگو نیست، سیستم حسگر معیوب را تشخیص می دهد، وضعیت آن را به در دسترس نیستتنظیم می­کند و وضعیت را در عرض 100 میلی ثانیه به اپراتور گزارش می دهد.- هدف کسب و کار: خطوط تولید- سناریو ویژگی ­های کیفی: محصول جدید تولید می شود. این محصول باید بیش از 80 درصد از دارایی های اصلی را مجدداً استفاده کند و تکمیل آن بیش از هشت نفر سال طول نمی کشد.- هدف کسب و کار: سهولت استفاده- سناریو ویژگی ­های کیفی: بدون آموزش، یک کاربر تازه کار می تواند با استفاده از ابزار ترسیم یک ترسیم ساده ایجاد کند.- هدف کسب و کار: امنیت- سناریو ویژگی ­های کیفی: هنگامی که یک کاربر نهایی سعی می کند با پیمایش مستقیم به یک صفحه وب غیرمجاز بدون ورود به سیستم، دسترسی پیدا کند، دسترسی رد می شود و تلاشش ثبت می شود.- هدف کسب و کار: ایمنی- سناریو ویژگی ­های کیفی: یک خلبان سعی می کند یک هواپیما را بدون پایین آوردن ارابه فرود فرود آورد. سیستم به خلبان هشدار می دهد و اقدامات اصلاحی انجام می شود.- هدف کسب و کار: مقیاس پذیری/توسعه پذیری- سناریو ویژگی ­های کیفی: دو سرور داده جدید را می توان در دو نفر روز به سیستم اضافه کرد، بدون اینکه سیستم از کار بیفتد.- هدف کسب و کار: عملکرد (functionality)- سناریو ویژگی ­های کیفی: اضافه کردن قابلیت هایی جدید به یک وب سایت، مانند توانایی کاربران نهایی برای محاسبه زمان­بندی استهلاک شخصی.- هدف کسب و کار: محدودیت­ های سیستم- سناریو ویژگی ­های کیفی: این سیستم با استفاده از PHP 5، MySQL 4.1 و Apache 2.0 پیاده سازی خواهد شد.- هدف کسب و کار: بین المللی شدن- سناریو ویژگی ­های کیفی: با این فرض که فایل‌های رشته متنی قبلا ترجمه شده‌اند، سیستم با یک نفر روز تلاش برای توسعه به یک زبان جدید منتقل می‌شود. بهبود موقعیت بازار- هدف کسب و کار: گسترش یا حفظ سهم بازار- سناریو ویژگی ­های کیفی: سیستم A را می توان در عرض یک نفر هفته به پلتفرم B منتقل کرد.- هدف کسب و کار: حفظ یا بهبود اعتبار- سناریو ویژگی ­های کیفی: سیستم A بیست درصد زمان پاسخ بهتری را در مورد کاربری X با 10٪ خطاهای کمتر نسبت به رقبای خود ارائه می دهد.- هدف کسب و کار: ورود بازارهای جدید- سناریو ویژگی ­های کیفی: سیستم A سازمان B را قادر می سازد تا محصولات را در بازار جدید C بفروشد.- هدف کسب و کار: کاهش ورود به بازار- سناریو ویژگی ­های کیفی: سیستم A ظرف دو سال تکمیل خواهد شد. پشتیبانی از فرآیندهای کسب­وکار بهبود یافته- هدف کسب و کار: توسعه­ ی توزیع شده- سناریو ویژگی ­های کیفی: سیستم A به صورت مشترک توسط تیم‌هایی در مکان‌های B، C و D در مدت 20 نفر سال و ظرف شش ماه توسعه می‌یابد.- هدف کسب و کار: حفظ مشاغل نیروی کار در سیستم های قدیمی- سناریو ویژگی ­های کیفی: سیستم A توسط تیم های موجود در مکان های A و B برای دو سال آینده نگهداری می شود. بهبود اعتماد و درک سیستم- هدف کسب و کار: حفظ یا بهبود اعتبار- سناریو ویژگی ­های کیفی: سیستم A بیست درصد زمان پاسخ بهتری را در مورد کاربری X با 10٪ خطاهای کمتر نسبت به رقبای خود ارائه می دهد. 6. نتیجه گیریارزیابی معماری نرم افزار یکی از مهم ترین شیوه های توسعه یک نرم افزار با کیفیت می باشد. ارزیابی معماری تلاش و هزینه‌های توسعه نرم‌افزار را کاهش می‌دهد و کیفیت نرم‌افزار را با در نظر گرفتن نیازمندی­ های کیفی و شناسایی خطرات احتمالی افزایش می‌دهد و همچنین این اطمینان را به توسعه دهندگان می­دهد که معماری انتخابی آنها هم نیازمندی­های عملکردی و هم غیرعملکردی و کیفی را برآورده می کند. این مقاله مروری بر روش‌ها و تکنیک‌های مختلف ارزیابی معماری نرم‌افزار ارائه نمود و بر خلاصه‌ای از اهمیت روش‌های مختلف ارزیابی زودهنگام و دیرهنگام، شباهت‌ها و تفاوت‌های بین آنها، کاربرد، نقاط قوت و ضعف آنها تمرکز داشت. همچنین با توجه به اهمیت شناخت اهداف کسب و کار و نقش و ماموریت آنها در تحلیل، توجیه و ارزیابی معماری نرم افزار در سازمان ها، در بخش پایانی این تحقیق به طبقه بندی این اهداف پرداختیم و برای هر طبقه بندی سناریویی مبتنی بر ویژگی های کیفی ارائه نمودیم. همچنین ذکر کردیم که این طبقه بندی ها به دو شیوه به ارزیابی معماری کمک می کنند: 1. سازمان ها را قادر می سازد تا اهداف کسب­ وکار خود را متمرکزتر و کامل تر ارائه دهند. 2. ساده سازی تولید درخت سودمندی از طریق درج اهداف کسب­ وکار در سطوح بالاتر درخت و ارائه سناریوهای نمونه برای هر هدف کسب­ وکار منابع:[1] L. Bass, J. Bergey, P. Clements, P. Merson, I. Ozkaya, and R. Sangwan, "A Comparison of Requirements Specification Methods from a Software Architecture Perspective," SEI CMU, Pittsburgh, Technical Report CMU/SEI-2006-TR-013, 2006.[2] R. Kazman and L. Bass, "Categorizing Business Goals for Software Architectures", 2005.[3] A. Patidar, U. Suman, A Survey on Software Architecture Evaluation Methods, 49(2015) , pp. 967–972. (Accessed July 5, 2016) http://ieeexplore.ieee.org/xpls/ abs_all.jsp?arnumber=7100391.[4] S Kadri, S Aouag, D Hedjazi, , "MS-QuAAF: A generic evaluation framework for monitoring software architecture quality", Information and Software Technology, 2021 – Elsevier.[5] Kilova K, Lazarova V, Kitova T, Bakova D, Kirkova-Bogdanova A. Modern Models and Approaches for Design of Architecture of a Software Application for Monitoring and Quality Assessment in Higher Education. CBU International Conference Proceedings: Innovations in Science and Education. 2017, vol.5.[6] Shanmugapriya, P., and R. M. Suresh. "Software architecture evaluation methods-a survey." International Journal of Computer Applications 49.16 (2012).[7] Kazman, Rick, and Len Bass. Categorizing business goals for software architectures. CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, 2005.[8] Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003 (ISBN 0-321-15495-9).(این مطلب، بخشی از تمرین های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است)