SAAM روش ارزیابی معماری

Software Architecture Analysis Method

Intelligent Systems Laboratory

2

منابع1. R. Kazman, G. Abowd, L. Bass, P. Clements, “Scenario

Based Analysis of Software Architecture”, IEEE Software, IEEE Cmputer Society Publ., 257-266 (1996).

2. R. Kazman, L. Bass, G. Abowd, and M. Webb. “SAAM: A method for analyzingthe properties of software architectures”. In Proceedings of the 16th International Conference on Software Engineering, Sorrento, Italy, May 1994, pp. 81–90.

تحلیل و طراحی فرایند ارزیابی معماری ا. دل پیشه، 3.، پایان نامه کارشناسی ارشد سیستم های داده کاوی

مهندسی کامپیوتر، دانشکده مهندسی کامپیوتر و فناوری .1388اطالعات، دانشگاه صنعتی امیر کبیر،

3

انواع تکنیک های ارزیابی نرم افزارتجربه ایشبیه سازی (آزمایش نمونه اولیهPrototyping(اندازه گیریپرسشی

پرسشهایی در قالبcheck-list و سناریو ها مطرح می گرددجنبه کیفی دارند و پاسخ را به طور دقیق نداریم

بیشتر برای مقایسه چندین گزینه استفاده می کنیم

4

تفاوت آنالیز و ارزیابی :تجزیه یک کل به اجزای آنآنالیز

یک کار انتزاعی می باشد

1. cause 2. impact 3. consequence

:آزمایش بر روی یک سیستم پیچیده، المان های آن و رابطه بین آن هاارزیابیاحتیاج به نتیجه گیری و خروجی می باشیم

1. cause 2. impact 3. consequence 4. evaluate

.نیاز به یک مقیاس خاصی برای ارزیابی می باشد. همیشه کار آسانی نمی باشد

راه حل: نوشتن سناریو

5

سناریو سناریو تکنیکی برای مشخص کردن کیفیت مورد درخواست از

معماری می باشد. 6 معیار برای تطبیق و نرمال سازی سناریوهای مختلف به

سناریو استاندارد وجود دارد که کاربرد را آسان تر می کند:منبع محرک1.محرک2.محیط3.محصول4.پاسخ5.اندازه گیری پاسخ6.

6

روشهای ارزیابی معماریSAAM(Software Architecture Analysis Method)

اولین روش – مبتنی بر سناریو – ارزیابی معماری از منظر نیازمندی های غیرکارکردی

اهدافSAAM:ارزیابی ویژگی های کیفی معماری در مقابل مستندات موجود از نیاز های سیستم اگر برای یک معماری به کار رفته باشد، نقاط ضعف و قوت آن معماری برایمان آشکار

می گردد اگر برای چند معماری به کار رفته باشد، دو معماری را از لحاظ قابلیت تغییر بررسی

خواهد کرد در ارزیابی فاکتورهای کیفی مانند تغییر پذیری، قابلیت جابجایی، مقیاس پذیری و یکپارچه

پذیری مفید است

تیم ارزیابSAAM:ذینفعان خارجیذینفعان داخلی تیمSAAM

7

ورودی هایSAAM:سناریوهای غیر کارکردی که قصد پردازش بر رویشان را داریممعماری به طور خالصه معین شدهگسترش معماری در صورت احتیاج به جزییات بیشتر

خروجی هایSAAM: نگاشتی بین سناریو و معماری به منظور شناخت قسمت های حساس و

هزینه برمقایسه ای از معماری و میزان پشتیبانی آن ها از کارکرد سیستم

8

SAAMمراحل توسعه سناریوها1مرحله -

ازbrainstorm بین اعضای تیم و ذینفعان موارد زیر به دستمی آید:

نیازمندی های غیر کارکردی سیستممهمترین کارکردها و کاربران سیستم(فاز استفاده و تغییر) تمام تغییرات ممکن برای آیندهتاثیر اعمال آن تغییرات بر روی کارایی و یکپارچگی سیستم

سناریو بیشتر مطرح شدن ویژگی های بیشترتوسعه معماری

9

توصیف معماری2مرحله -

از زبان طبیعی/ نمودارUML زبان های توصیفی معماری /ADLاستفاده می شود

.نوع ارایه متناسب با حضار بایست باشد

10

طبقه بندی و اولویت بندی سناریوها3مرحله -

مستقیماعمال تغییرات می توانند سناریوهایی که معماری های کاندید بدون

اجرا نمایندغیر مستقیم

سناریوهایی که به طور مستقیم پشتیبانی نمی شوندتغییر در عملکرد مولفهافزودن مولفهاقزودن ارتباطات بین مولفه هاترکیبی از این تغییرات

11

ارزیابی سناریوها4مرحله -

شناسایی تغییرات الزم در هر سناریووزن دهی به میزان سختی این تغییراتارایه جدول نتایج ارزیابی

12

بدست آوردن ارتباطات بین سناریوها5مرحله -

دو سناریوی مرتبط: سناریو هایی که منجر به تغییر بر رویاجزای واحدی از معماری باشند

اگر سناریوهای غیر مرتبط یک مولفه را تحت تاثیر قرارlow cohesionدهند:

شاید نتوان با تغییر در ریزدانگی مولفه ها را با هم ترکیب یااز هم جدا نماییم

13

تهیه ارزیابی کلی6مرحله -

مقایسه معماری ها با اختصاص وزن به هر کدام

ارزیابی بایست بر اساس نظر تمامی ذینفعان انجام گیرد

14

15

SAAM

نقاط قوتSAAM:فرآیند تولید سناریو آسان می باشدبهبود ارزیابی نرم افزاردرگیر شدن با ذینفعان و ادراک بهتر نسبت به سیستمبه دست آوردن سناریوهای تغییر، هزینه و اثرگذاری هر یک

نقاط ضعف SAAM:معیار دقیقی به غیر از قابلیت تغییر نداریم ارزیابی نیازمندی ها، احتیاج به تجربه زیاد دارد+دانش دقیق تیم

ارزیابیSAAM معیار مناسبی را برای ارزیابی ویژگی های کیفی ارایه

نمی کندSAAM

توصیف معماری

Quality Requirements

Overall Evaluation