نیوشا شفیعی
نیوشا شفیعی
خواندن ۲۷ دقیقه·۳ سال پیش

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


عنوان تحقیق: تبیین الزامات معماری نرم­ افزار و معیارهای ارزیابی آنها در محورهای مختلف معماری جهت استفاده به منظور نظارت بر پیمانکاران نرم ­افزاری در سازمان­ های بزرگ

چکیده:

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

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: رفتار رایج در روش های ارزیابی مبتنی بر سناریو
شکل - 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) مبتنی بر معماری نرم افزار
شکل - 2: تجزیه کارایی (performance) مبتنی بر معماری نرم افزار


3.2. متدهای ارزیابی دیرهنگام

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

شکل - 3: فعالیت های مربوط به ارزیابی دیرهنگام معماری نرم افزار
شکل - 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: طبقه ندي اهداف كسب وكار


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] دو کاربرد اساسی و مهم برای دسته بندی اهداف کسب و کار معرفی گردید:

  1. سازمان ها را قادر می سازد تا اهداف کسب­ و کار خود را متمرکزتر و کامل تر ارائه دهند: یک سازمان می‌تواند با استفاده از این طبقه‌بندی، اطمینان حاصل کند که مجموعه کامل و جامعی از اهداف کسب­ و کار را ایجاد کرده است.
  2. ساده سازی تولید درخت سودمندی از طریق درج اهداف کسب­ و کار در سطوح بالاتر درخت و ارائه سناریوهای نمونه برای هر هدف کسب­ و کار: درخت مطلوبیت یک ابزار استخراج و ساختاردهی مفید بالا به پایین است که سال‌ها با موفقیت در ارزیابی‌های 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).


(این مطلب، بخشی از تمرین های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است)









معماری_نرم_افزار_بهشتی
شاید از این پست‌ها خوشتان بیاید