گزارش سمینار روش های ارزیابی معماری نرم افزار

دانشگاه صنعتی شیراز دانشکده مهندسی کامپیوتر و فناوری اطالعات گروه نرم

افزار

گزارش سمینار کارشناسی ارشددر رشته مهندسی کامپیوتر گرایش نرم افزار

روش های ارزیابی معماری نرم افزار

نگارش:آرش رضوانی

استاد راهنما:دکتر سید رئوف خیامی

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

93زمستان

چکیده

امروزه ارزیابی معماری نرم افزار برای نرم افزار های بزرگ و پیچیده یک امر مهم و ضروری است. پیش زمینه ارزیابی معماری نرم افزار

همانطور که از اسم آن پیداست، داشتن یک معمــــاری برای نرم افزار است. امروزه نرم افزارها هر روز پیچیده و بزرگتر می شود، و برای

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

سیستم دارد. برای صفات کیفیتی در معماری نرم افزار روش های متعددی ارائه شده است. بیشتر روش های ارزیابی روی صفات غیروظیفه مندی مانور می دهند، که بهترین معماری را انتخاب کنند یا اینکه مشخص شود

معماری موجود اهداف ذی نفعان سیستم را براورده میکند یا خیر. در این تحقیق ابتدا مقدمه ای راجع به تعریف معماری و معماری نرم افزار پرداخته شده است. در ادامه اهداف و کاربرد های ارزیابی معماری

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

ارزیابـی معماری نرم افزار پرداخته شده است، بدین منظور، چند سبک صفات کیفیتی معماری نرم افزار تفضیل شده است. صفات کیفیتی نرم

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

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

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

است.

فهرست مطالب

10.فصل اول: مقدمه111...................................................................- مقدمه1-111.................................................................- معماری1-212....................................................- معماری نرم افزار1-315....................................................- تصميمات معماري1-416.............................................................- نتیجه گیری1-5

17.فصل دوم: اهداف و کاربرد ها218...................................................................- مقدمه2-118...................................................- اهداف و کاربرد ها2-219..............................................................- نتيجه گيري2-3

20.فصل سوم: چالش های مرتبط با موضوع321...................................................................- مقدمه3-121..................................................................- چالشها3-2

21........................- ويژگيهاي كيفيتي معماري نرم افزار3-2-124...................- مروري بر مدلهاي معروف كيفيت نرم افزار3-3

McCall......................................................25- مدل 3-3-1ISO/IEC.....................................................27- مدل 3-3-2IEEE.........................................................28- مدل 3-3-3

29.............................................................- نتیجه گیری3-430.فصل چهارم: راه حل های ارائه شده4

31...................................................................- مقدمه4-131........................................- توضیح کامل صفات کیفیتی4-2

31.............................................................- كارايي4-2-132..............................................................- امنيت4-2-233...............................................- در دسترس بودن4-2-334..............................- قابليت عملكرد يا وظيفه مندي4-2-434..................................................- قابليت استفاده4-2-535............................................- قابليت اصالح پذيري4-2-637......................................................- قابليت حمل4-2-737..........................................- قابليت استفادة مجدد4-2-838............................................- قابليت تجميع پذيري4-2-9

39................................................- قابليت آزمايش4-2-1039..................- روش های مشهور ارزیابی معماری نرم افزار4-3

ATAM...........40- روش تحليل معماري از طريق مصالحه 4-3-1CBAM.............................41- روش تحليل هزينه- سود 4-3-2ALMA....43- روش تحليل قابليت اصالح در سطح معماري 4-3-3HoPLAA.....45- روش کل نگر ارزیابی معماری خط تولید 4-3-4

47.............................................................- نتیجه گیری4-448.فصل پنجم: مقایسه و نتیجه گیری5

49...................................................................- مقدمه5-149......................- مقايسه روشهاي ارزيابي مبتني بر سناريو5-2

53مراجع

و

فهرست شکل ها

.[.1 مراحل تبديل نيازمنديهاي كاربر به معماري نرم افزار]1-1شکل .13

15..........................[.2 مراحل تولید معماری نرم افزار]2-1شکل ....Mc call [1] ساختار دسته بندي خصوصيات كيفيتي در مدل 1-3شکل

26Mc call [1]...........................................27 مدل کیفیتی 2-3شکل HoPLAA................................46 ورودی خروجی روش 1-4شکل 50....................[.1 ارتباط سيستم مورد نياز با معماري]1-5شکل

ز

فهرست جدول ها

52............ مقایسه روش های ارزیابی معماری نرم افزار1-5جدول

ح

فهرست کلمات اختصاری

ATAM Architecture Trade-off Analysis MethodCBAM Cost Benefit Analysis MethodALMA Architecture Level Modifiability AnalysisSAAM Software Architecture Analysis MethodIEEE Institute of Electrical and Electronics EngineersERD Entity Relationship DiagramIA Information ArchitectureSA Software ArchitectureSEI Software Engineering Institute

ط

1.فصل اول: مقدمه

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

..........................................................................................ر..............فصل اول: مقدمه

مقدمه-1-1

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

ارزیابی معماری نرم افزار پرداختیم در ابتدا باید با چند مفهوم آشناشویم.

معماری-1-2

تجربه هاي به دست آمده از ساير رشته هاي فني و مهندسي نشان داده است كه عواملي مانند ابعاد بزرگ، پيچيدگي زياد، قابليت گسترش

و ايجاد تغييرات در طي زمان، طول عمر زياد و نيازمنديهاي خاص از مهمترين عوامل تصميم گيري در رابطه با لزوم هر نوع معماري مي

باشد. به عبارت ديگر تجربه نشان داده است كه هر گاه نياز به طراحي موجوديتي )ساختمان، مدار، سيستم و...( با ابعداد و پيچيدگي هاي زياد يا نيازمنديهاي خاص باشد، نگرش خاص و همه جانبه اي مورد نياز است كه

[.2در اصطالح به آن گفته معماري مي شود] به طور كلي يك معماري خوب الزم است كه مشخصات زير را

فراهم نمايد:- قابل فهم باشد.1- مولفه هاي آن قابل استفادة مجدد باشند.2- موارد اصلي كاربري سيستم را در بگيرد.3- نسبت به تغييرات انعطاف پذير باشد.4 - واسط های بين زيرسيستمها را به نحوي تعريف كرده باشد تا5

[.2زيرسيستمها كمترين وابستگي را به يگديگر داشته باشند ]

معماری نرم افزار -1-3

معماري نرم افزار از موضوعات روز مورد توجه محققين و متخصصين مهندسي نرم افزار در دو دهه اخير مي باشد. تجربه نشان داده است كه

11


..........................................................................................ر..............فصل اول: مقدمه

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

به آن معماري گفته مي شود. منظور از معماري تبيين ساختار كلي يك سيستم است به گونه اي كه صفات و ويژگیهاي رفتاري الزم، در آن

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

باشد. معماري يكريشه التين بوده و به معني استادي در ساختن مي سيستم مجموعه نقشه هاي فني از جنبه هاي مختلف آن سيستم را

.[1]نشان ميدهد در واقع يك توصيف سطح باال از سيستم بوده كه اهداف و عملكرد

سيستم را براي طراحان و سازندگان و همچنين استفاده كنندگان آن هاي مشتري مي باشد. بهبيان داشته و نشان دهنده مطابقت با نيازمندي

بيان ديگر معماري يك توصيف مجرد از پياده سازي سيستم نرم افزاريرا نشان مي هد.

در حالت كلي تمركز معماري در نقطه اي بعد از تحليل و قبل از طراحي است، و از طريق تجزيه مدل تحليلي به زيرسيستمها و واسطه

هاي آنها و در نهايت تعيين قسمتهاي اصلي و عينيت بخشيدن به فرآيندهاي سيستم مشخص مي شود. در واقع معماري يك طراحي

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

گردد. به طور كلي به هر معماري يك سيستم مي توان گفت طراحي،[. 2ولي هر طراحي را نمي توان معماري ناميد]

1 معماري اولين مرحله تبديل سيستم بيان شده توسط ذينفعان مسئله به توصيفي است كه در آن عملكرد عناصر تكنيكي سيستم

نشان داده شده يك نمونه1لمشخص شده باشد همانگونه كه در شك فرآيند تبديل و سپس با2كاري بيان شده توسط كاربر به نمودار توالي

و دقيق تر نمودن آن اين نمودار در سطح معماري سيستم بيان3پااليشمي شود.

[.1ار]هاي كاربر به معماري نرم افزمراحل تبديل نيازمندي1-1شکل

1 Stockholder2 Sequence Diagrams

3 Refinement

12


..........................................................................................ر..............فصل اول: مقدمه

تصميماتي كه از ديدكلي سيستم اتخاذ شده و دامنه وسيعي را در بر مي گيرند، تصميمات معماري محسوب مي شوند. ولي تصميماتي كه در

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

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

مثال انتخاب سبك، انتخاب تعداد مولفه ها، يا مولفه هاي قابل رويت از]بيرون، صفات كيفيتي مورد نظر، هر كدام يك تصميم معماري هستند

1]. تعريف دقيق و يكتائي براي معماري نرم افزار ارائه نگرديده است كه اين خود يكي ازمشكالت اصلي بر سر تحقيقات در اين زمينه است

تعريف ذكر شده است. تعدادي از تعاريف100در بعضي منابع بيش از معروف تر در ذيل بيان شده است:

معماري نرم افزار مجموعه اي از اجزاء معماري )طراحي( است- دسته اند. اجزاء3كه شكل خاصي دارند. اين اجزاء معماري

.3، اجزاء اتصالی2، اجزاء داده اي1پردازشي معماري نرم افزار مجموعه اي است از مولفه ها و اتصال دهنده-

ها به همراه توصيف تعامالت بين آنها. معماري نرم افزار براي يك برنامه يا سيستم محاسباتي، ساختار يا-

ساختارهاي آن سيستم است كه شامل مولفه هاي نرم افزاري،خصوصيات بارز خارجي آن مولفه ها و ارتباطات ميان آنها است.

سازماندهي اساسي يك سيستم كه شامل مولفه ها، ارتباط هر- يك از آنها با يكديگر و محيط، و اصول حاكم بر طراحي و تكامل

آنها.

اجزاء معماري نرم افزار به صورت Garlan و Shawبر طبق نظر مفهومي به موارد ذيل طبقه بندي مي شود:

مولفه: يك موجوديت محاسباتيمتصل كننده: يك اثر متقابل و تعامل بين مولفه ها

واسط: يك نقطه تعامل بين مولفه ها و متصل كننده ها يا محيط هايخارجي

در واقع مي توان گفت كه معماري نرم افزار، بخشهاي اصلي نرم افزار را در قالب مؤلفه ها شناسايي مي كند، اما به اجزاء دروني و

ساختمان داده هاي خود مؤلفه ها نمي پردازد. معماري عالوه بر ساختار،

1 Processing Elements2 Data Elements

3 Connecting Elements

13


..........................................................................................ر..............فصل اول: مقدمه

به رفتار سيستم نيز نگاه مي كند. معماري در نرم افزار بدنبال تحليل هاي كليدي كه در نظرهاي كليدي می باشد معموال ويژگييكسري ويژگي

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

م افزار، رابطه اي بين ساختار و رفتار مؤلفه ها ايجاد مي نمايد. ارائة سيستم از ديدگاههاي مختلف براي درك بهتر آن، مفيد خواهد

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

[.2فناوري، هزينه ها و زيبايي شناختي نيز مورد توجه مي باشد] معماري نرم افزار يك سيستم را مي توان ديد مشترك همة صاحبان

سهام و توسعه دهندگان دخيل در يك سيستم نرم افزاري دانست كه همگي روي آن اتفاق نظر دارند يا حداقل آنرا پذيرفته اند. معماري نرمافزار يك سيستم، اطالعات زير را در مورد آن سيستم ارائه مي دهد:

سازماندهي سيستم نرم افزاري•عناصر ساختاري و واسطهاي آنها•تركيب عناصر ساختاري و رفتاري درون زير سيستمها•

معماري نرم افزار مرحله اي از فرآيند مهندسي است كه نمي توان به صورت دقيق مشخص كرد كه در كدام نقطه از اين فرآيند تعبيه شده

است، ولي در حالت كلي تمركز معماري در نقطه هاي بعد از تحليل و قبل از طراحي است و از طريق تجزية مدل تحليلي به زير سيستمها،

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

اخير، معماري نرم افزار به عنوان يك محدوده تحقيقاتي مهم و اصلي در مهندسي نرم افزار خود را نشان داده است. بسياري از زبانهاي توصيف

معماري پيشنهاد داده شده اند و بعضي از تكنيكهاي تحليل كشف شده[.2اند]

14


..........................................................................................ر..............فصل اول: مقدمه

[.2مراحل تولید معماری نرم افزار] 2-1شکل

تصميمات معماري-1-4

تصميماتي كه بايد از ديد كلي سيستم اتخاذ شوند و دامنه وسيعي را در بر مي گيرند، تصميمات معماري محسوب مي شوند، ولي تصميماتي كه در سطح محدودي گرفته مي شوند و ديد محلي دارند، تصميم معماري

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

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

كيفيتي مورد نظر، هر كدام يك تصميم معماري هستند. تصميمات[.1معماري در همان مرحله اوليه معماري اتفاق مي افتد]

به صورت خالصه معماري نرم افزار يعني بيان ساختار يا ساختارهائي هاي قابل رويت از خارجاز سيستم كه مولفه هاي نرم افزاري، و ويژگي

اين مولفه ها و روابط بين آنها را نشان مي دهد. به عبارت ديگر معماري نرم افزار عبارت است از ساختار مولفه ها در يك سيستم،رابطه داخلي

آنها و اصول و خطوط راهنمائي كه طراحي و ارزيابي سيستم در طيزمان را امكان پذير مي كند.

اگر بخواهيم اهميت معماري نرم افزار را از منظر فني مورد بررسي

15


..........................................................................................ر..............فصل اول: مقدمه

قرار دهيم مي توان سه دليل در اين رابطه بيان نمود: الف: معماري بعنوان وسيله اي جهت ارتباط ميان ذينفعان سيستم: معماري نرم افزار يك سيستم را مي توان ديد مشترك همه ذينفعان

سيستم دانست. در صورتي كه همه يا اكثر آنها روي آن اتفاق نظر داشته باشند، مي توان آنرا به عنوان پايه اي براي درك متقابل،

مشورت و رايزني و همچنين عامل ارتباط ميان آنها قرار داد. همانطور كه قبال هم بيان شد در واقع معماري يك زبان مشترك ميان

تمام آنها برقرار مي كند كه براي همه قابل فهم بوده و به دركصحيح تر سيستم كمك مي كند.

ب: امكان تصميمات زود هنگام طراحي: معماري نرم افزار شامل هاي سطح باال و زود هنگام در طراحي است،1تصميمات و مصالحه

كه منجر به توليد سيستم نرم افزاري مي شود و صفات آن را تعيين مي كند. مطالعات در اين زمينه نشان مي دهد كه هزينه تصحيح يك

ها يا در فاز معماريخطاي كشف شده در خالل فاز شناخت نيازمندي بسيار كمتر از هزينه تصحيح همان خطا در حالتي است كه خطا در

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

ها و خصوصيات، بتوان مولفه هايسيستمي مشابه، با همان نيازمندي ايجاد شده را مورد استفاده مجدد قرار داد و همانطور كه مي دانيم

اين موضوع در فرآيند توليد و توسعه سيستمهاي نرم افزاري از[.2اهميت خاصي برخوردار است]

نتیجه گیری-1-5

همانطور که مطالعه کردیم در این فصل با مفاهیم معماری و مفهوم معماری نرم افزار اشنا شدیم و در فصل بعدی به بررسی اهداف و

کاربرد های ارزیابی معماری نرم افزار می پردازیم.

1 Trade-off

16

2. اهداف و کاربردفصل دوم:

ها

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

.................................................................................فصل.دوم: اهداف و کاربرد ها

مقدمه-2-1

در این فصل به بیان هدف و کاربرد معماری نرم افزار و ارزیابی معماری نرم افزار می پردازیم. با توجه به اینکه برای ارزیابی معماری

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

کیفی در معماری نرم افزار و در اخر از اهداف ارزیابی معماری نرمافزار پرداخته می شود.

اهداف و کاربرد ها-2-2

استفاده از معماری نرم افزار باعث میشود که مدیریت نرم افزار های بزرگ و پیچیده خیلی ساده و اسانتر شود و داشتن مستندات و معماری

نرم افزار باعث این امر میشود. همچنین استفاده از مدل های کیفیتی در معماری نرم افزار باعث

رضایت و امنیت و کاربرد بهتر نرم افزار های ساخته شده میشود. و همچنین بکار بردن صفات کیفیتی در معماری نرم افزار باعث یک سطح

قابل قبول از صفات کیفی در نرم افزار داشته باشیم که صفات کیفی درفصل اتی مفصل تر بحث خواهد شد.

با ساخت معماری موثر شما می توانید با شناسایی طراحی ریسک در[.9اوایل روند توسعه ریسک ها را کاهش دهید]

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

[.13اندازه معماری یکی شده بدست اورد] در ارزیابی معماری نرم افزار میتوان به این سواالت رسید و این

سواالت بعضی اهداف و کاربرد های ارزیابی معماری نرم افزار است. چگونه مي توان تصميمات معماري را اندازه گيري كرده و مفاهيم هزينه

ها و سودها را استخراج نمود و آنها را با هم مقايسه كرد؟ چگونه مي توان صفات كيفيتي را تحليل نموده و با در نظر گرفتن هزينه

18

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

.................................................................................فصل.دوم: اهداف و کاربرد ها

ها و سودها مصالحه هاي مورد نياز را انجام داد؟چگونه مي توان ميزان احتمال هزينه و سود را مشخص نمود؟

و موارد زیر دیگر اهداف و کاربرد های ارزیابی معماری نرم افزارهستند:

سهامداران بصورت كامال روشن و واضح معماري را مي فهمند.ارتباط بين سهامداران افزايش مي يابد.

مستندات معماري در جريان ارزيابي بهبود مي يابد ودر صورت لزومدوباره ايجاد مي شود.

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

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

هاي منطقي در زمينة بكار گيريمي تواند اصولي را براي تصميم گيريهاي معماري تهيه نمايد.استراتژي

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

دارد.مفروضات مهم و كليدي به صورت صريحي بيان مي شوند.

استفاده از تكنيكهاي قابل تكرار براي ارزیابی در مراحل مختلف

نتيجه گيري-2-3

در این فصل به اهداف و کاربرد های معماری نرم افزار و ارزیابی معماری نرم افزار پرداختیم که در فصل بعد به چالشهای معماری نرم

افزار و ارزیابی معماری نرم افزار می پردازیم.

19

3. چالش های مرتبطفصل سوم:

با موضوع

ارزیابی معماری نرم ......................................................فصل سوم: روشافزار.

پیشنهادی برای حل مساله

مقدمه-3-1

در این فصل به چالشهای معماری نرم افزار و چالشهای ازریابی معماری پرداخته می شود. یکی از چالشهاینرم افزار که با هم گره خورداند

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

دانستن خود این صفات کیفیتی یک چالش می باشد. انتخاب کدام ترکیب صفات های کیفیتی مختلف با هم یک چالش به حساب می آید. که در این

فصل به چند مورد از سبک های معماری نرم افزار و روش های کیفی معماری نرم افزار پرداخته شده است. در روش های ارزیابی معماری

نرم افزار باید صفات کیفیتی شرح داده شده را مورد ازریابی قرار دهند.

چالشها-3-2

تاكنون روشهاي بسياري براي ارزيابي معماري نرم افزار پيشنهاد و بكار گرفته شده است. اما بيشتر اين روشها امكان واضح و مستقيمي براي

مقايسه دو معماري ارائه نميدهند. هاي كيفيمعماري نرم افزار نقش مهمي در دستيابي به ويژگي

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

انتخاب شده، جهت دستيابي به استعداد برآورده نمودن نيازهاي كيفي و.[9شناخت ريسك هاي بالقوه ميباشد]

هاي كيفيتي معماري نرم افزارويژگي- 3-2-1

هاي كيفيتي، همان نيازمنديهاي غيروظيفه مندي سيستم مي باشندويژگي هايكه تا حد زيادي تعيين كننده سبك معماري نيز مي باشند. ويژگي

هاي غير وظيفه مندي هستند، بايستيكيفيتي كه در واقع همان نيازمندي در نرم افزار به صورت يكسري پارامترهاي فني، در نظر گرفته شوند و

ها را به صورت قابل فهم براي سايربراي همين معمار بايد اين ويژگي صاحبان سهام ليست نمايد تا آنان در مورد اين ليست امكان اظهار نظر

21


پیشنهادی برای حل مساله داشته باشند و در نهايت سيستم داراي كيفيت مورد نظر باشد. معماري

اولين قدم توليد نرم افزار بوده كه نيازهاي كيفيتي در آن قابل رديابي است. صفات كيفيتي در تمام مراحل طراحي، پياده سازي و انتقال

مطرح مي باشند و در نتيجه اگر توسط معماري پشتيباني شوند، راحتتر قابل رديابي خواهند بود.

هاي كيفيتي از نظر ارزيابي به دو دسته تقسيم ميويژگيشوند:

اين صفات نشانصفات كيفيتي قابل مشاهده در زمان اجرا:-1 مي دهند كه در طول مدت اجرا، يك سيستم چقدر خوب مي تواند

هاي رفتاري خودش را تامين كند. يعني به لحاظ رفتاري معيننيازمندي مي كند كه آيا سيستم نتايج را برآورده مي كند و آيا اين نتايج را در زمان درست برآورده مي سازد يا خير؟ در واقع اين صفات كيفيتي

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

هايي فراهم مي شوند يا خير؟ ويژگي مورد مي باشند:5صفات كيفتي قابل مشاهده در زمان اجرا

1كارايي

2امنيت3در دسترس بودن

4قابليت عملكرد يا وظيفه مندي 5قابليت كاربرد و استفاده

اين صفات بهصفات كيفيتي غير قابل مشاهد در زمان اجرا:-2 گونه اي هستند كه با اجراي آن نمي توان تشخيص داد كه به آن

دست يافته ايم يا خير و به عبارت ديگر نمي توان آن را در زمان اجرا ديد و بايد بعدا ارزيابي شود. اين دسته از صفات نشان مي دهند كه

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

و... خود را نشان مي دهند. مورد مي باشند:5صفات كيفيتي غير قابل مشاهده در زمان اجرا

6قابليت اصالح پذيري

1 Performance2 Security

3 Availability4 Functionality

5 Usability6 Modifiability

22


پیشنهادی برای حل مساله 1قابليت حمل

2قابليت تجميع پذيري 3قابليت استفاده مجدد

4قابليت آزمايش البته هر دو دسته صفات كيفيتي معرفي شده در باال، چه قابل

مشاهده در زمان اجرا و چه غير قابل مشاهد در زمان اجرا، مربوط به خود سيستم و برنامه كاربردي مي باشند و به آنها صفات كيفيتي مرتبط

هاي كيفيتي مرتبط با حرفه همبا سيستم مي گويند ولي يك سري ويژگي داريم، كه آنها نيز در معماري اثرگذار هستند، كه از آن جمله مي توان به

مسائلي مانند قيمت تمام شده، زمان پايان و... اشاره كرد.

دو نكته در رابطه با صفات كيفيتي از اهميت زيادي برخوردار است: معماري براي تحقق بسياري از صفات كيفيتي مهم و بحراني در-1

سيستم مي باشد و اين كيفيت هاي مورد نظر مي بايستي در سطح معماري طراحي و ارزيابي شوند، يعني در سطح معماري

ها هستند كه بايد مورد طراحي و ارزيابي قراريكسري از ويژگيگيرند.

برخي از اين صفات كيفي وابسته به معماري نيستند و تحقيق در-2 زمينه دستيابي به اين كيفيتها در معماري كار درستي نيست و

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

براي بعضي از صفات كيفيتي معماري بايد معماري را اجرا نموديعني آزمايش آنها به زمان اجرای معماري موكول مي شود.

بحث صفات كيفيتي در سيستمهاي پيچيده مطرح مي شود و برآورده كردن اين صفات به صورت مجرد امكان پذير نيست، يعني بايد ابتدا

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

را باال ببريم، امنيت را پايين آوريم، يعني ممكن است كه همة صفات كيفيتي را نتوانيم با هم برآورده سازيم. مثال فرض كنيد امنيت و تحمل

خطا بصورت انحصاري قابل دستيابي باشند ولي اگر توام با هم بخواهيم آنها را داشته باشيم بايد مصالحه انجام دهيم. يكي از مسائلي كه در

هاي كيفيتي داريم اين است كه بايد اهلارتباط با بحث معماري و ويژگي سازش باشيم، يعني همه صفات كيفيتي را ممكن است نتوانيم همزمان

فراهم كنيم ولي بايد ببينيم كه كدام يك از اين شرايط براي ما حائز اهميت بيشتر است. مثال ببينيم كه كارايي براي ما اهميت بيشتري دارد يا

1 Portability2 Integritability

3 Reusability4 Testability

23


پیشنهادی برای حل مساله قابليت استفادة مجدد، چرا كه اين دو صفت را نمي توان به طور كامل با هم به دست آورد، يعني بايد كمي از كارايي صرف نظر كنيم تا كمي

.[2]قابليت استفادة مجدد داشته باشيم و...

مروري بر مدلهاي معروف كيفيت نرم افزار-3-3

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

معروف کیفیتی معمار نرم افزار پرداخته می شود. براي توصيف و مشخص نمودن صفات كيفيتي معموال از مدلهاي كيفيتي

استفاده مي شود. اين مدلها عموما به صورت ساختاري درختي از صفات كيفيتي و ارتباطات آنها بيان شده اند. بررسي مدلهاي معروف و

اصلي، صفات كيفيتي مناسب در يك سيستم نرم افزاري را بهتر مشخص مي نمايد. ذينفعان مسئله با مطالعه اين مدلها مي توانند

خواسته هاي خود را دقيق تر و مشخص تر بيان دارند، و بدانند كه چه چيزهاي را بايد در توصيف خواسته هاي خود در اين زمينه مشخص

[.1نمايند]

McCallمدل - 3-3-1

هايي كه كيفيت نرم1در اين مدل يك گروه بندي مفيد براي فاكتور افزار را تحت تاثير قرار مي دهند، پيشنهاد شده است. اين روش كيفيت

،3، توانائي اصالح2نرم افزار را براساس سه جنبه خصوصيات عملياتي بيان مي دارد.4توانائي انتقال

:Cavanoدسته بندي فاكتورها به صورت ذيل مي باشد

1 Factor2 Operations

3 Revision4 Transition

24


پیشنهادی برای حل مساله ،3، كارائي2، قابليت اطمينان1- خصوصيات عملياتي: صحت و درستي

.5 و قابليت استفاده4درستي و امانت ، آزمون7، انعطاف پذيري6- خصوصيات توانائي اصالح: قابليت نگهداري

.8پذيري ،10، قابليت استفاده مجدد9- خصوصيات توانائي انتقال: قابليت حمل

.11قابليت تعامل پذيري

.Mc call [1]ساختار دسته بندي خصوصيات كيفيتي در مدل 1-3شکل

هر يك از فاكتورها در اين مدل براساس پرسشي از طرف يكي از نكته قوت اين.3ذينفعان مطرح مي باشد، طراحي گرديده است شکل

كيفيتي محصول مي13 با مالكهاي12مدل ارتباط فاكتورهاي كيفيت خارجي

1 Correctness2 Reliability3 Efficiency

4 Integrity5 Usability

6 Maintainability7 Flexibility8 Testability9 Portability10 Reusability

11 Interoperability12 External Quality

13 Criteria

25


پیشنهادی برای حل مساله باشد. كيفيت خارجي عبارتست از كيفيتي كه توسط خصوصيات پوياي كد

در حال اجرا اندازه گيري شده و كيفيتي كه توسط خصوصيات ثابت كدتوسط برنامه نويسان اندازه گيري ميشود را كيفيت داخلي مي گويند.

.Mc call [1]مدل کیفیتی 2-3شکل

ISO/IECمدل - 3-3-2

، قابليت اطمينان، قابليت1اين مدل شش ويژگي قابليت كاركردي استفاده، كارآئي، قابليت نگهداري و قابليت حمل شدن را به عنوان

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

:ISO/IECيك ويژگي در نظر گرفته شده اند

1 Functionality

26


پیشنهادی برای حل مساله 3، تعامل پذيري و امنيت2، دقت1- عملكرد: مناسب بودن

5 و قابليت بازگشت از خطا4- قابليت اطمينان: قابليت تحمل خطا 6- قابليت استفاده: قابليت درك سيستم، يادگيري و بكارگيري

8، و رفتار منابعي7- فاكتور كارائي: رفتار زماني

12، ميزان تثبيت11، تغييرپذيري10: قابليت تجزيه وتحليل9- قابليت نگهداريوقابليت آزمايش.

، قابليت نصب و قابليت همزيستي.13- قابليت حمل: تطابق پذيري

IEEEمدل - 3-3-3

در واقع استانداردي براي ايجاد مدل كيفيتي بيان داشته، و IEEEمؤسسه مدل كيفيتي صريحي پيشنهاد نداده است. ساختار درختي را براي مدل

كيفيتي بيان داشته و بيشتر تاكيد بر چگونگي طراحي روشهاي اندازه گيري فاكتورهاي كيفيتي دارد. ساختار پيشنهادي شبه درختي با سه

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

از سطح اول، معيارهائي براي هر يك از فاكتورهاي كيفيتي مشخص شودIEEE .

به عنوان پيشنهاد اوليه يك درخت با فاكتورها و زير فاكتورهائي به شكلذيل پيشنهاد نموده است:

زماني و صرفه جوئي منابع.14- كارائي: صرفه جوئي و در دسترس بودن.16، تحمل خطا15- قابليت اطمينان: بدون نقص بودن

1 Suitability2 Accuracy

3 Security4 Fault Tolerance

5 Recovery6 Operability

7 Time Behaviour8 Resource Behaviour

9 Maintainability10 Analyzability11 Changeability

12 Stability13 Adaptability

14 Economy

27


پیشنهادی برای حل مساله و تعامل پذيري.17- عملكرد: كامل بودن، صحت، امنيت، سازگاري

.2- قابليت پشتيباني: قابليت آزمايش، توسعه پذيري و اصالح پذيري - قابليت حمل: استقالل از سخت افزار، استقالل از نرم افزار و قابليت

نصب و قابليت استفاده مجدد. - قابليت استفاده: قابليت درك، سادگي يادگيري، قابليت بكارگيري و

.3قابليت ارتباط با كاربر


در این فصل به بیان صفات کیفیتی در نرم افزار و بعضی چالشهای دیگر ارزیابی معماری نرم افزار پرداختیم که در فصل اتی به بیان راه حلی

برای رفع این چالشها می پردازیم.

15 Nondeficiency16 Error Tolerance

17 Compatibility2 Correctability

3 Communicativeness

28

4. راه حل هایفصل چهارم:

ارائه شده

مقدمه-4-1

در فصل قبل به چالش های که در ارزیابی معماری نرم افزار وجود دارد پرداخته شد و صفات کیفتی مورد توجه قرار گرفت، در این فصل به

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

زمینه انجام داده شده است پرداخته می شود.

توضیح کامل صفات کیفیتی-4-2

در این بخش به توضیح کاملتر صفات کیفیتی پرداخته می شود و بصورت مفصلتر صفات کیفیتی شرح داده شده است که در اخر این

بخش به شناخت کامل و درک مفهوم دقیق صفات کیفیتی می رسیم و[ استفاده می شود.2از منبع ]

كارايي- 4-2-1

كارايي مربوط به زمان پاسخ سيستم يا پاسخگو بودن سيستم مي باشد. در واقع مي توان گفت كه كارايي به زمان مورد نظر براي پاسخگويي

سيستم به تعدادي از رخدادها در يك پريود زماني مربوط مي شود. ( از طريق ميزان پاسخ1كارايي را از دو روش مي توان محاسبه كرد: )

( تعداد رخدادهايي كه در واحد زمان مورد2گويي به يك رخداد خاص و ) پاسخگويي قرار مي گيرند. پس كارايي به ما مي گويد كه به چه ميزان

توانسته ايم زمان پاسخگويي را كم كنيم. اغلب اين ويژگي كيفي را بوسيلة محاسبة مقدار زمان الزم براي اجراي كامل يك تراكنش، اندازه

گيري مي كنيم. چون ارتباط با سيستم بيشتر از خود محاسبات زمان مي برد، در

نتيجه كارايي نشان مي دهد كه چقدر تعامالت بين اجزاي سيستم تدوين شده و به چه ميزان اين اجزاء شناسايي و تعبيه شده، تا زمان بااليي را

به عنوان زمان پرت براي سيستمها و يا زير سيستمها نداشته باشيم. ميزان تعامالتي كه در فراخواني توابع يا رويه ها و يا در همگام سازي

فرآيندها يا مكانيسمهاي ارتباطي ديگر وجود دارد، روي كارايي سيستم تأثير مي گذارد و باعث مي شود كه كارايي به عنوان تابعي از معماري

ارزیابی معماری نرم ......................................................................فصلافزار.

چهارم: راه حل های ارئه شده مطرح شود، پس كارايي را مي توان در سطح معماري درك كرد و

تحليل و مدل نمود. با نرخ وروديها و تقاضاي سرويس و اندازة صفها و تأخيرهايي كه در

زمان اجرا مشاهده مي كنيم، مي توانيم كارايي را ارزيابي نماييم. به طور كلي كارايي يك سيستم را با ايجاد يك مدل تخميني صف شبيه سازي مي كنيم. براي شبیه سازي كارايي سعي مي كنيم كه ميزان

انتظار را براي هر كاري كه در سيستم است و براي هر مشتري كه وارد سيستم مي شود، بررسي كنيم و با استفاده از يك تابع نرخ ورود و

همچنين توزيع تقاضاي سرويس بين پردازنده هاي مختلف و تخمين زمان پردازش و ميزان صف هاي توليد شده براي هر پردازنده، ميزان كارايي

را محاسبه كنيم. پس براي محاسبة كارايي بايد زمان پردازش هر كدام از تراكنشهاي

سيستم را تخمين بزنيم و بر اساس شبيه سازي، كارايي سيستم را مشخص نماييم، مثال مشخص كنيم كه اگر يك خادم به سيستم اضافه كنيم، به چه ميزان بر روي كارايي تأثير مي گذارد، و آيا وجود يا عدم

وجود اين خادم اضافه بر روي كارايي تاثير مي گذارد يا خير؟ در مجموع مي توان گفت كه كارايي يك فاكتور مهم و برنده در معماري است و

ارزش رسيدن به آن بسيار باال است.

امنيت- 4-2-2

امنيت واحدي از سيستم است كه توانايي يك سيستم را براي مقاومت در برابر مسائل ناخواسته و تالشهاي غيرمجاز و همچنين امتناع از

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

و... و همچنين از نظر عوامل انساني و مسائل فيزيكي، مثل آتشسوزي و دزدي و...

و DOSمسائلي كه به طور عمده در امنيت با آن روبه رو هستيم Spoogfing.مي باشد

1-DOSنتيجه سرازير شدن درخواست هاي ناخواسته زياد به : سيستم مي باشد كه سيستم را از پاسخگويي به درخواستهاي

حقيقي باز مي دارد، يعني آنقدر به طور غيرواقعي كار توليد مي كنيم كه باعث زيادي بار شدن سيستم شده و خود اين كار باعث

مي شود كه سيستم نتواند وظايف واقعي خود را انجام دهد.2-IP Source Spoofing بر اساس كپي كردن آدرس :IPمي باشد. اين

حمله براي رسيدن به آدرس مقصد، از مسير كامپيوتر ميزبان


چهارم: راه حل های ارئه شده و نام يك كامپيوتر را جعل ميIPاست. يعني اينكه يك نفر آدرس

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

سمت مقصد را كم مي كند و بعد از طريق اعتبار كامپيوتر ميزبانوارد عمل مي شود.

در دسترس بودن- 4-2-3

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

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

اين صفت اينگونه اندازه گيري مي شود كه مدت زمان بين مشكالت بوجود آمده در نظر گرفته مي شود و مشخص مي شود كه در

اين بازة زماني تا چه ميزان به سرعت به مشكالت پاسخ داده شده، و سيستم به حالت طبيعي برگشته است. آن كسري از زمان كه سيستم

سر پا است و سوالها را جواب مي دهد و به درخواستها پاسخ مي گويد،ميزان در دسترس بودن را نشان مي دهد است.

در دسترس بودن رابطه نزديكي با قابليت اطمينان دارد، يعني هر چه قابليت اطمينان در سيستمي زياد باشد، آن سيستم در دسترس تر

خواهد بود و بالعكس. قابل اطمينان بودن يعني توانايي سيستم برايادامة عمليات در طول زمان.

در دسترس بودن و قابليت اطمينان، وابستگي كامل با معماري دارند. چون از تكنيكهاي معماري استفاده مي كنيم تا اين دو صفت كيفي

را افزايش دهيم، در واقع با استفاده از سخت افزارهاي اضافي و يا پشتيبان گيري و... مي توان اين دو صفت كيفي را افزايش داد، كه همة

اينها از تصميمات معماري هستند. نصب مولفه هاي اضافي براي اجرا در زمان بروز خطا و باال بردن

دقت و برخورد كردن با خطاها در بهبود اين دو صفت كيفيتي و در نتيجه در معماري اثرگذار مي باشند و بايد در معماري از پيش ديده شوند.

پارامترهايي كه در اين دو صفت دخالت دارند هر دو وابسته به معماري می باشند و عبارتند از متوسط زمان شكت كه عمدتا با ايجاد معماري با

تحمل خطاهاي باالتر، اين عدد بيشتر مي شود يعني متوسط زمان شكست اگر معماري با تحمل خطاي باال داشته باشيم تغيير مي كند ولي

در عوض تحمل خطا با تكرار عناصر پردازشي مهم و اتصاالت در معماري بدست مي آيد. پارامتر بعدي متوسط زمان اصالح مي باشد. هر

چه معماري بهتر باشد، متوسط زمان خرابي باالتر مي رود و اضافه


چهارم: راه حل های ارئه شده كردن عناصر پردازشي براي وقتي كه بحراني اتفاق مي افتد روي

معماري اثر مي گذارد.

قابليت عملكرد يا وظيفه مندي- 4-2-4

اين صفت توانايي سيستم براي انجام كاري كه سيستم به منظور آن ايجاد شده است، را نشان مي دهد. اين صفت نشان مي دهد كه به چه ميزان سيستم توانمند است. براي انجام يك كار بايد اجزاء سيستم در

يك مسير هماهنگ براي تكميل آن كار پيش روند. اگر به اين اجزاء مسئوليتهاي درست و واقعي واگذار نشود و يا تسهيالت الزم براي انجام

اين كار و هماهنگي با بقيه مولفه ها را نداشته باشد، سيستم قادر بهايجاد قابليت عملكرد مورد نياز نخواهد بود.

قابليت عملكرد ذاتا به معماري مربوط نيست و يك صفت غير معماري است و جزو مسائلي كه به تصميم گيري معماري نياز دارند، نمي باشد، اما چون اين صفت به ويژگيهايي مربوط مي شود كه آنها

تاثيرگذار روي معماري هستند خود قابليت عملكرد بحثي است كه مجزا از ساير صفات كيفيتي قابل بررسي است و از طرف ديگر چون بستر

اوليه يك سيستم نرم افزاري را نيازهاي وظيفه مندي تعيين مي كند، پسمي توان گفت كه اين صفت به معماري مربوط مي شود.

قابليت استفاده- 4-2-5

اين صفت به اجزاء زير شكسته مي شود: 1يادگيري2كارايي

3قابل يادداشت بودن

4جلوگيري و اجتناب از خطا

5رسيدگي به خطا

6رضايت

1Learnability2Efficiency

3Memorability4Error Avoidance

5Error Handling6Satisfaction


چهارم: راه حل های ارئه شده پس اگر بخواهيم قابليت استفاده يك محصول نرم افزاري را اندازه

گيري نماييم بايد آن را در اين اجزاء خالصه نماييم. - اينكه چقدر قابل يادگيري است و چقدر راحت و سريع يك1

كاربر مي تواند استفاده از واسط كاربر را فرا بگيرد. - آيا سيستم در زمان كم و با سرعت مناسب به تقاضاي2

كاربر پاسخ مي دهد. - چقدر سيستم قابل حفظ شدن است، يعني كاربر به ياد مي3

آورد كه چگونه سيستم را بايد بكار بگيرد. يعني اينگونه نيست كه كاربر سريع آن را از ياد ببرد و اگر يكبار از سيستم استفاده كرد دفعه ديگر با نگاه كردن، سريع به ياد بياورد كه چگونه بايد از آن

استفاده كند. - آيا سيستم خطاهاي معمول كاربر را پيش بيني مي كند و از4

آنها جلوگيري مي كند.- آيا سيستم به كاربر براي رهايي از مشكالت كمك مي كند )5

help.)- آيا سيستم كار را براي كاربر آسانتر كرده است يا خير؟6

قابليت اصالح پذيري- 4-2-6

مي توانيم ادعا كنيم كه اين قابليت در هر شكلي كه باشد بهترين ارتباط را با معماري دارد. توانايي اينكه تغييرات را با سرعت و كارايي باال و هزينه كم ايجاد كنيم همان قابليت اصالح پذيري است كه بستگي به

معماري دارد. يكي از ويژگيهايي كه كامال با معماري قابل انطباق است قابليت اصالح است كه آن منعكس كننده معماري قابل اصالح است.

قابليت اصالح تابعي از چگونگي تغيير است، يعني دانستن و يا شناساييمحل تغيير.

در شرايط مساوي ايجاد تغيير بزرگ در يك سيستم نسبت به تغيير در يك مولفه كوچك هزينه بيشتري را در بردارد، زيرا اعمال تغيير در

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

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

است كه ما در توليد سيستم بر مي داريم تا مولفه را تعريف كنيم و چون در متن معماري نهفته است و همچنين در معماري قابليتها و

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

شرايط بتواند تغيير كند، چيست؟ دسته تقسيم مي كند.3تمام تغييرات ممكن را معماري به


چهارم: راه حل های ارئه شده تغييراتي كه موجب ايجاد قابليت تغيير فقط در يك مولفه مي-1

شوند. يعني تغييري كه مي دهيم منحصر به اصالح يك مولفه ميشود. پس گاهي اوقات اثر تغيير بر روي يك مولفه است.

گاهي اوقات قابليت تغيير روي چند مولفه است.-23- اين تغيير چيزي فراتر از بحث قابليت اصالح پذيري است، مثال

تغيير در سبك معماري، كه يك تغيير بنيادي است. اغلب تغييراتي كه در نيازمنديهاي كاري سازمان و در نتيجه در

نيازمنديهاي كاري يك سيستم بوجود مي آيد، باعث مي شود كه ما بهسمت اصالح پذيري برويم، اين تغييرات به چند دسته تقسيم مي شوند:

توانايي در تغيير يا گسترش: اضافه كردن يك كارايي جديد، بهبود-1كارايي، اصالحات، ايجاد ساختارهاي جديد از اين نوع هستند.

توانايي هايي كه در حذف مسائل ناخواسته وجود دارد: همان-2 حذف توانمنديهاي ناخواسته مي باشد كه براي ساده سازي كارايي

يك كاربرد استفاده مي شود، يعني براي موثرتر كردن و ساده كردن يك وظيفه به كار مي رود. براي موثرتر كردن كارايي،

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

تطبيق با محيط كاري و محيط عملياتي جديد: مثال وقتي تغييراتي-3 روي پردازنده ها و وسايل ورودي و خروجي و دستگاههاي ديگر به

وجود مي آيد مي خواهيم نرم افزار آنها منطبق با امكانات جديد شود، اگر اين گونه باشد مي گوييم كه قابليت حمل داريم كه اين

قابليت حمل در واقع جزئي از قابليت اصالح پذيري است. ساختار بندي مجدد: در اين دسته از تغييرات طراحي دوباره-4

يمسرويسهاي سيستم و ماژولها را براي بهينه سازي انجام دهيم. مثال مولفه هاي قابل استفاده مجدد را جايگزين مولفه هاي قديمي سيستم مي كنيم كه اين كار به منظور توسعة آتي سيستم

انجام مي گيرد، پس مي توان به قابليت اصالح پذيري، قابليت نگهداشت گفت و اين دو نام از ديد عملياتي و اثرگذاري متفاوتند

ولي از نظر معماري اين دو اصطالح يكسان هستند.

قابليت حمل- 4-2-7

اين صفت توانايي اجرا تحت محيطهاي محاسباتي مختلف را براي سيستم فراهم مي كند. اين محيطها مي توانند سخت افزاري و يا نرم افزاري و يا تركيبي از اين دو باشند. يك سيستم به ميزاني قابل حمل است كه تمام فرضيات در مورد هر محيط محاسباتي را در يك مولفه

گردآوردي كرده باشد. پس به شرطي مي توانيم انتظار داشته باشيم كه نرم افزار بطور كامل قابل جابجايي باشد كه تمام فرضيات در مورد

محيط محاسباتي در يك يا چند مولفه خالصه شده باشد. با داشتن يك


چهارم: راه حل های ارئه شده معماري اليه بندي مي توان به اين قابليت دست يافت و از اين نظر مي توان گفت كه اين صفت به معماري مرتبط است. مثال اگر برنامة ما به

صورت مستقيم به امكانات سخت افزاري وابسته نباشد، بلكه اليه واسطي وجود داشته باشد، مثال ماشين مجازي كه نرم افزار ما روي آن ماشين مجازي اجرا شود و ماشين مجازي روي سخت افزارهاي مختلف

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

قابليت استفادة مجدد- 4-2-8

اين صفت معموال به معني طراحي سيستمي است كه كل ساختمان آن سيستم يا برخي از مولفه هاي آن بتواند دوباره در كاربردهاي آتي

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

سيستم طوري ساختاربندي شده باشد كه مولفه ها بعنوان محصوالتي انتخابي ساخته شده باشند، يعني انتخاب معني دار باشد. پس سيستم

بايد به گونه اي باشد كه مولفه هاي ما قابل انتخاب از محصوالتي كه قبال ساخته شده اند، باشد كه در اين حالت اين صفت مفهوم قابليت تجميع

را مي رساند. باشد و هر1 براي داشتن اين صفت بايد سيستم مبتني بر مولفه

كدام از اين مولفه ها به عنوان بخشي از خدمات يا محصوالتي كه در برنامه هاي مختلف مي توانند كار كنند، در نظر گرفته شوند و ميزان

ارتباطات مولفه ها كم در نظر گرفته شود و در اين صورت سيستم هايبعدي مي تواند از مولفه هاي انتخابي درست شوند.

از اين نظر اين صفت به معماري مربوط مي شود كه بايد در مرحله اي از معماري كه مولفه ها انتخاب مي شود، وظايف مشترك مولفه ها

مشخص شود و در نتيجه به مولفه هاي ريزتري با ارتباط كم شكسته شوند و با انجام اين كار وظيفه مندي عوض مي شود. مولفه هاي

معماري واحدهاي استفاده مجدد هستند و اين استفادة مجدد به ميزان وابستگي بستگي دارد و بهتر است كه كمتر باشد. ما قابليت استفاده

مجدد را حالت خاصي از قابليت اصالح پذيري در نظر مي گيريم، يعني ما مولفه هايي داريم كه مي تواند با كمي تغييرات در محيطهاي ديگر هم

مورد استفاده قرار گيرند.

1 Component Base


چهارم: راه حل های ارئه شدهقابليت تجميع پذيري- 4-2-9

اين صفت نشان می دهد كه مولفه هايي كه جدا از هم ساخته شده اند، چقدر مي توانند با هم كار كنند و همديگر را تحمل نمايند. اين مطلب

بستگي به اين موضوع دارد كه به چه ميزان پيچيدگيهاي خارجي مولفه ها پنهان شده و تعامل و مكانيزم و سازوكارهاي ارتباطي شناخته شده و به صورت يك پروتكل تعريف شده است و همچنين به چه ميزان مسئوليتها

بين مولفه ها تقسيم شده است كه تمام اين تصميمات در سطح معماري هستند. همچنين قابليت تجميع به اين مطلب بستگي دارد كه

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

بين مي رود.

قابليت آزمايش- 4-2-10

قابليت آزمايش يك نرم افزار امكاني است كه نرم افزار بتواند اشتباهات خود را در حين تست به نمايش بگذارد. ممكن است سيستم بگونه اي

ساخته شود كه تست آن مشكل باشد ولي اگر از اول سيستم را به گونه اي بسازيم كه قطعات جدا از هم با وظيفة معين و اتصاالت معين شده تعريف شوند، خود به خود اين امكانات كمك مي كند كه اگر اشكالي در

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

بروز اشكال در يك سيستم، بسرعت بتوانيم مولفة داراي اشكال را پيدا نموده و اشكال آن مولفه را مشخص نموده و به نمايش بگذاريم. در

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

قابليت كنترل نيز وابسته است. بايد قابليت كنترل هر مولفه و ورودي هاي آن و مشاهدة خروجيهاي آن وجود داشته باشد، در واقع بايد بتوان

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

مستندسازي را يك اليه اي كنيم، اين ناقض قابليت آزمايش است و توليد تدريجي به همان ميزاني كه قابليت تجميع را ارتقاء مي دهد، قابليت

آزمايش را هم فراهم مي كند. اگر ما بتوانيم به صورت تدريجي كار توليدرا انجام دهيم، خود به خود قابليت آزمايش هم فراهم خواهد شد.


چهارم: راه حل های ارئه شدهروش های مشهور ارزیابی معماری نرم افزار-4-3

در این بخش به شرح روش های مهم ارزیابی معماری نرم افزار می هست که درSAAMپردازیم. از نظر تاریخچه اولین مدل ارزیابی مدل

ارائه شد و روش های زیادی از این سال به بعد ارائه شد،1993سال میATAM، CBAM، ALMA، HoPLAAدر ادامه به تشریح چهار روش

[ جمع اوری7[،]2[،]1پردازیم همچنین این چهار روش مورد بررسی از ]شده است.

ATAMروش تحليل معماري از طريق مصالحه - 4-3-1

يكي از روشهاي معروف مبتني بر سناريو روش تحليل معماري مبتني بر مصالحه مي باشد. اين روش به صورت كامال جدا از روشهاي قبلي

توسعه يافت و هدف از آن تحليل صفات كيفيتي خاص براساس معماري بر روي جنبه هاي كيفيتي معماري با جزئيات بيشتري ازATAMمي باشد.

SAAMروشهاي قبل بحث مي كند، و در عمل نسخه تقويت شده اي از

1998 به عنوان يك مدل مارپيچي ازريابي در سال ATAMمي باشد. .[ 3مطرح شد]

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

نمايد. سناريوها در اين روش بر سه نوع مي باشند. سناريوهاي مورد كاري كه يك وضعيت عادي از اجراي سيستم را تشريح مي كند.

سناريوهاي پيشرفت، شامل سناريوهائي مي باشند كه تغييرات قابل پيش بيني آينده سيستم را نشان مي دهند. سومين نوع سناريوها،

سناريوهاي اكتشافي بوده كه محدوديتهاي سيستم را نشان ميدهند. به عبارت ديگر سناريوهاي اكتشافي وضعيتهائي را بيان مي كنند كه سيستم

تحت فشار بوده و عملكردش به حد نهائي كاري خود رسيده باشد. جهت تامين اهداف كيفيتي اين روش پيشنهاد درست نمودن درخت

سودمندي سيستم توسط ذينفعان را ارائه نموده است. بدين شكل ذينفعان اهداف اصلي كيفيتي مورد نظر خود، به همراه مشخصه هاي


چهارم: راه حل های ارئه شده جزئي تر آن اهداف را بيان مي دارند. سپس براي تحقق آنها يك سري

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

[.4مصالحه و بيان روش ايجاد تعادل بين صفات كيفيتي است] فراهم كردن يك راه اصولي براي فهميدنATAMهدف روش ارزيابي

توانائي معماري نرم افزار با در نظر گرفتن چندين صفت كيفيتي كه با عالوه بر ارزيابي صفات كيفيتي،ATAMيك ديگر رقابت دارند، مي باشد.

وابستگي هاي اين صفات كيفيتي را نيز مشخص مي نمايد. در واقع اين روش قبل از توليد سيستم و وقتي كه معماري نرم افزار سيستم مشخص شد، ضرورت يك مصالحه را در بين چندين صفت كيفيتي تشخيص داده و مكانيسم هاي مصالحه را نيز مشخص مي سازد.

همچنين ريسك هاي معماري نرم افزار كه مانع رسيدن به اهداف كاريسازمان مي شوند، نيز در اين روش مشخص مي گردد.

شامل بخشهاي متفاوتي تقسيم مي شود:ATAMمراحل نشست ارزيابي ارائه و معرفي: معرفي روش ارزيابي، معرفي محرك ها و پيشبرانهاي

حرفه، معرفي معماري نرم افزار. تحليل و بررسي: معرفي معماريهاي پيشنهادي، ايجاد درخت سودمندي

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

مجدد معماري پيشنهادي.بخش گزارش: معرفي نتايج

ATAMمحاسن روش

به شرح زير مي باشد:ATAMمحاسن روش سهامداران بصورت كامال روشن و واضح معماري را مي فهمند.•ارتباط بين سهامداران زياد است و افزايش مي يابد.• مستندات معماري در جريان ارزيابي بهبود مي يابد ودر صورت•

لزوم دوباره ايجاد مي شود. نتايج معماري براساس سناريو هاي كيفيتي و موارد كاربري•

استخرا ج مي شود. سناريوهاي كيفيتي توليد شده بوسيله سهامداران يا بعضا تيم•

ATAM.براساس نيازمنديهاي غيروظيفه مندي كيفيتي است


چهارم: راه حل های ارئه شدهCBAMروش تحليل هزينه- سود - 4-3-2

اين روشي يكي از روشهائي مي باشد كه بر مفاهيم بودجه )هزينه – سود( و زمان براي دستيابي به اهداف معماري بحث جدي مي نمايد. اين

شروع مي شود. در واقع اينATAMروش پس از انجام ارزيابي براساس روش از محصوالت روش مذكور استفاده نموده و براساس نتايج آن، ارزيابي را با توجه به نكات مالي و اقتصادي معماري انجام مي دهد.

CBAMپلي بين دو زمينه توليد و توسعه نرم افزار با اقتصاد سازمان در طول فرآيند معماري ايجاد مي نمايد. در روشهاي قبلي صفات كيفيتي

مانند اصالح پذيري، كارائي و يا قابليت استفاده مجدد تنها مبناي تصميم گيري بوده ولي در اين روش عوامل كيفيتي تجاري سيستم نيز به

ارزيابي تا حدودي اضافه شده است. از مزاياي اصلي اين روش مي توان ارائه يك مقياس اندازه گيري براي برگشت سرمايه، و كمك به تهيه

يك برنامه ارزيابي شده براي معماري و سرمايه گذاري بر روي آن، نام.[4]برد

آن ممكن است8 تا 2 مرحله تقسيم شده كه مراحل 9اين روش به [.3[]4چندين مرتبه تكرار]

مراحل اين روش عبارتند از: . انتخاب سناريوها: از مجموعه سناريوهاي تعريف شده در مراحل1

ATAMو سناريوهاي جديد كه توسط ذينفعان در شروع اين روش مشخص شده، براساس اولويت بندي، يك سوم از سناريوها براي

تحليل انتخاب مي شوند. . تشريح و دقيق نمودن سناريوها: در اين مرحله براساس نظر2

ذينفعان، محدوده وضعيتهاي بدترين، جاري، ايده آل و بهترين حالت رابراي هر يك از سناريوها مشخص مي شود.

راي به هر يك از ذينفعان،100. اولويت بندي سناريوها: با تخصيص 3 درجه اهميت هر يك از سناريوها مشخص مي شود. بدين شكل وزن

هر يك از سناريوها در محاسبه سودمندي، تعيين ميشود. . محاسبه سودمندي: براساس نظر ذينفعان امتيار سودمندي براي4

هريك از وضعيتهاي تك تك سناريوها )بدترين، جاري، ايده آل وبهترين( مشخص مي گردد.

. ايجاد استراتژيهاي معماري براي سناريوها و محاسبه سطح جواب5 مورد انتظار: در اين مرحله استراتژيهاي مختلف معماري نرم افزار مشخص شده و براساس نظر ذينفعان، سطح جواب گوئي جاري و


چهارم: راه حل های ارئه شدهمورد انتظار هر يك از استراتژيها، تعيين مي گردد.

. تعيين سودمندي سطح جواب سناريوهاي مرتبط با هر يك از6 استراتژيها: با استفاده از مقدار سودمندي استخراج شده )به كمك نمودار سودمندي( ، براي هر يك از استراتژيها، ميزان سطح جواب

جاري و مورد انتظار مشخص مي گردد. . محاسبه ميزان سودمندي هر يك از استراتژي معماري: در اين7

قسمت براساس امتياز وزن دار سطح جواب هر يك از سناريوها و سناريوهاي تحت تاثير هر يك از استراتژيها، مجموع امتياز سودمندي

استراتژيها مشخص مي شود. :1. انتخاب استراتژي برتر براساس ضريب بازگشت سرمايه8

براساس ضريب بازگشت سرمايه در هر يك از استراتژيها، آنها را مرتب نموده و بهترين استراتژي انتخاب مي شود. ضريب بازگشت

سرمايه براي هر استراتژي از تقسيم امتياز سودمندي محاسبه شدهدر مرحله قبل بر هزينه پيش بيني شده آن استراتژي بدست مي آيد.

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

كار، مورد تحليل شهودي قرار ميگيرد. از تماميATAMشركت كنندگان در جلسات ارزيابي مانند روش

ذينفعان سيستم تشكيل شده و فرض بر اين است كه در گروه شركت كننده قابليت محاسبه هزينه و سود مربوط به معماريها و سناريوها وجود

دارد.

CBAMمحاسن روش

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

اين روش به سازمانها كمك مي نمايد تا يك برنامة از پيش•ارزيابي شده براي سرمايه گزاريهاي خود تهيه نمايند.

اين روش مي تواند اصولي را براي تصميم گيريهاي منطقي در•زمينة بكار گيري استراتژيهاي معماري تهيه نمايد.

1 Return On Investment (ROI)


چهارم: راه حل های ارئه شدهALMAروش تحليل قابليت اصالح در سطح معماري - 4-3-3

در اكثر متون علمي قابليت اصالح پذيري و نگهداري يك سيستم نرم افزاري به عنوان اصلي ترين فاكتور كيفيت نام برده مي شود. در

هزينه چرخه70 تا %50تحقيقات انجام شده مشخص گرديده بيش از % حيات يك سيستم نرم افزاري به اصالحات انجام شده برروي نسخه اول

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

ALMAيك روش مبتني بر سناريو بوده كه براي ارزيابي ويژگيهاي كيفيتي نرم افزار كه روي قابليت اصالح پذيري موثر مي باشند، ايجاد گرديده

است. از اهداف اصلي اين روش مي توان از پيش بيني چگونگي نگهداري سيستم، مشخص نمودن ريسكها و مقايسه چند معماري با هم

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

در آنها به سختي امكان پذير مي باشد. مقايسه دو معماري به منظور انتخاب بين دو معماري پيشنهادي براي يك سيستم بوده و به منظور

مشخص نمودن معماري بهتر و مناسبتر انجام مي شود. مرحله طراحي گرديده شده است. مشخص كردن5اين روش در

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

ALMAكه بعضي از مراحل به صورت تكراري هم انجام شوند. روش

ساخته شده و به همين جهت پيش شرطهاي زيادي ازSAAMبراساس آن به ارث برده است. از جمله اينكه از ذينفعان خواسته مي شود كه

سناريوهاي تغيير را كه در طول تحوالت سيستم به نظرشان بوجود مي با استفاده از اين سناريوها، قابليت تغييرALMAآيند، را مشخص نمايند.

پذيري سيستم را مورد ارزيابي قرار مي دهد. تحليلگر همچنين بايد بتواند ميزان هزينه تامين اين تغييرات را مشخص ارزيابي قرار مي دهد.

تحليلگر همچنين بايد بتواند ميزان هزينه تامين اين تغييرات را مشخص.

ALMA محاسن و معايب


چهارم: راه حل های ارئه شدهعبارتست از: ALMAمحاسن روش ارزيابي

امكان ارزيابي قابليت اصالح پذيري از جنبه هاي متفاوت ارزيابي• ريسك، پيش بيني هزينه و همچنين نگهداري سيستم و انتخاب

معماري وجود دارد. مي توانند به دو روش باال به پايين و پايين بهALMAسهامداران •

باال، سناريوها را توليد نمايند و به همين دليل مرحلة توليدسناريوهاي تغيير نسبتا ساده مي باشد.

در اين روش مفروضات مهم و كليدي به صورت صريحي بيان مي•شوند.

وجود تكنيكهاي قابل تكرار براي انجام مراحل مختلف اين روش•عبارتست از: ALMAمعايب روش ارزيابي

اين روش فاقد تصميم گيري در مورد دقت و درستي نتايج تحليل•است.

اين روش نمي تواند اثبات كند كه ارزيابي ريسك كامل است.•اين روش نمي تواند تعداد پيش بيني هاي نگهداري را توجيه نمايد.•

HoPLAA 1خط تولید معماری ارزیابی کل نگر روش- 4-3-4

ATAMروش کل نگر ارزیابی معماری خط تولید گسترش یافته روش هست که برای ارزیابی معماری خط تولید می باشد.این روش در دو

مرحله به شناسایی خطرات در دو سطح معماری زیر انجام می پذیرد.این دو سطح معماری عبارتنداز:

ارزیابی معماری هسته.1ارزیابی معماری محصول منحصر به فرد..2

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

که حاوی3پذیر این است که یک نقطه حساسیت یا یک نقطه معاوضه حداقل یه نقطه تنوع است را تعیین می کند. شناسایی از نقاط تکامل

پذیر تضمین میکندکه صفات کیفیتی در سطوح محصوالت منحصر بفرد نیست.4معماری با صفات کیفیتی معماری هسته در تضاد و ناسازگاری

دستورالعمل های تکامل پذیر برای اطالع رسانی به طراحان درباره ناسازگاری های بالقوه و راهنمایی آنها به ساختن تصمیم گیری طرحی

].5مناسب در محصوالت بعدی فاز طراحی معماری استفاده می شود[

1 Holistic Product Line Architecture Assessment (HoPLAA) method

2 evolvability

3 tradeoff

4 conflict


چهارم: راه حل های ارئه شده نشات گرفته شده است و ورودی خروجی های اینATAMاین روش از

[ زیر بطورت کامل بیان شده5روش بر دو سطح معماری در شکل] مرحله دارد.7است دو سطح

HoPLAAورودی خروجی روش 1-4شکل

و در ادامه به توضیحی مختصری که شامل چند مقاله بروز در مورد بحثارزیابی معماری نرم افزار است می پردازیم

] یک مدل توسعه یافته ی مبتنی بر آتاماتا با عنوان8 درمقاله[ به این مدلUML 2.0آتاماتای تیمی برای تبدیل توصیفات معماری از

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

].8ارزیابی نموده و اصالحات الزم را جهت بهبود آن اعمال می نماید[ روشی پیشنهادی در مقاله خانم منتقمی امکان مقایسه دو معماری

را در تمام دوره چرخه حیات نرم افزار تضمین می کند. این روش بر سه مفهوم اهداف کسب و کار، مدل کیفی استاندارد و سرویس های در

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

یک فرآیند مبتنی بر معماری نرم افزار و اثبات بهبود حاصل از انجام].9تغییرات کلی یا جزئی بر معماری پیشین استفاده نمود[

در مقاله دیگر با عنوان بررسی سود از ترکیب کردن یک تجزیه و تحلیل معماری نرم افزار و یک ازریابی قابلیت استفاده ازیک موبایل

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

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


چهارم: راه حل های ارئه شده الزم است.در این پژوهش یک روش که در راستای بازرسی متد "تجزیه و تحلیل معماری نرم افزار از درک نیازمندی های قابل استفاده" و یک

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

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

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

].10راه جامع ارائه دهد[ در مقاله ی دیگر به بررسی ارزیابی بازبودن معماری نرم افزار

موبایل پرداخته اند که توسعه دهندگان پلت فرم نرم افزار بینشی نسبت به پیامد از تصمیم معماری ساخته شده در اهمیت باز بودن معماری

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

تحقیق در باز بودن و معماری از پنج پلت فرم موبایل که مقایسه می شوند استفاده می شود و بینش بیشتری داخل استراتژی های موفق باز

].11بودن برای رشد اکوسیستم نرم افزار ارائه گردید[ در مقاله ی با2012 همچنین آقای جانسن و آقای انوری در سال

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

(، روشAHPکه این روش ها عبارتند از: فرآیند تحلیل سلسله مراتبی ) ( اولویت بندی، پوکر اولویت، مدل هزینه سود، داشبوردARMتسریع نیاز )

COCOMO-II 1(، و پسوند امنیتیSIDDتصمیم سرمایه گذاری امنیتی )].12پراخته است[


در این فصل به بیان روش های متفاوت مدل های کیفی و همچنین روش های مهم ارزیابی نرم افزار و مبحث های بروز در این زمینه پرداخته شد

و در فصل اینده روش های اصلی این فصل را مقایسه و نتیجه گیریخواهیم کرد.

1 Security extension

5. مقایسه وفصل پنجم:

نتیجه گیری

زمستان93..........................................................................................

...فصل پنجم:جمع بندی و پیشنهادها

مقدمه-5-1

در این فصل که فصل پایانی گزارش سمینار است به بیان نتیجه گیری کلی از روش های اصلی ارائه شده در فصل چهار پرداخته ایم و یک

مقایسه روش های اصلی مورد بحث را انجام داده ایم از لحاظ متریکهای متفاوت که برتری متریک ها رو روش ها متخلف نشان داده است.

مقايسه روشهاي ارزيابي مبتني بر سناريو-5-2

در اين قسمت ابتدا به بررسي خصوصيات روش ارزيابي ويژگيهاي كيفيتي به طور كلي پرداخته و عمليات اصلي در ارزيابي را مورد تحليل

قرار داده شده است. سپس با توجه به اين اهداف عملياتي روشهاي ارزيابي مبتني بر سناريو مورد تجزيه و تحليل قرار مي گيرد. همچنين

براي مقايسه روشهاي مبتني بر سناريو آنها در يك چارچوب مقايسه ايمورد بررسي قرار خواهند گرفت.

از نظر كلي هر روش ارزيابي ويژگيهاي كيفيتي يك سيستم نرم افزاري،بايد سه كار اصلي را انجام دهد:

بدست آوردن ويژگيهاي كيفيتي درخواستي ذينفعان و اولويت بندي•آنها.

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

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

هاي ذينفعان محاسبه گردد. مشكل ترين قسمت، پيدا نمودن مشخصه هاي كامل و دقيق

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

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

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

است. از طرف ديگر به علت عدم آشنائي دقيق استفاده كنندگان

47

زمستان93..........................................................................................

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

ذينفعان واقعي سيستم در كار ارزيابي و بيان نمونه هاي شهودي از خواسته آنها، نيازمنديهاي واقعي آنها مشخص مي شود. اين روشها با بيان سناريوها توسط ذينفعان، سعي در تداعي شرايط عملي را براي

آنها داشته تا توقع خود را بهتر درك نموده و خارج از پيش فرضهاي معنائي كلمات موجود در مهندسي نرم افزار، نوع و ميزان رفتاري كه از

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

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

مشخص مي شود. بدين شكل مشخص مي باشد روشهاي مبتني بر سناريو به هر سه مرحله ارزيابي ويژگيهاي كيفيتي به ميزان مناسبي

اهميت داده و در روش خود آنها را در نظر گرفته است. همانگونه كه در شكل زیر نشان داده شده است، در واقع هدف

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

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

شود.

[.1ارتباط سيستم مورد نياز با معماري]1-5شکل

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

48

زمستان93..........................................................................................

...فصل پنجم:جمع بندی و پیشنهادها مي باشد، از جمله ميزان و مقدار منابعي كه در آن روش مصرف مي شود. مثال طول زماني مي باشد كه در روند توليد نرم افزار به مسئله

ارزيابي معماري اختصاص مي يابد و يا منابع نيروي انساني كه بايد بدين منظور صرف شود. بطور خالصه هزينه اي كه اجراي يك ارزيابي به هزينه هاي توليد نرم افزار اضافه ميكند، اعم از هزينه هاي زماني و

هزينه هاي پرسنلي مورد نظر مي باشد. البته اين نكته در كنار ميزان نتايجي كه از آن روش بدست مي آيد، بهتر قابل بررسي مي باشد.

روشهاي مبتني بر سناريو با توجه به اين موضوع سعي نموده اند با كم كردن هرچه بيشتر هزينه هاي تحميلي، با حداكثر دقت و صحت، سه

مرحله اصلي ارزيابي را انجام دهند. به طور معمول با توجه به اندازه روز الي يك هفته كاري و افراد شركت كننده2سيستم، زمان ارزيابي از

نفر در نظر گرفته شده است. بدين لحاظ از نظر15 الي 4در آن بين مقبوليت اين روشها در زمينه تجزيه و تحليل معماري نرم افزار در متون

عملي بيشتر از بقيه روشها مي باشد. اما نكته ضعف يا خطري كه در اين روشها وجود دارد اينستكه

موفقيت تمامي آنها، وابستگي بسياري به دانش و تجربيات ذينفعاني دارد كه در جلسه شركت نموده اند. تمامي تصميمات با توجه به نظرات اين

گروه گرفته شده و اگر اين افراد در مباحث كسب و كار مربوطه، معماري سيستم هاي نرم افزاري و مفهوم ارزيابي از دانش و تجربه

كافي برخوردار نباشند، احتمال عدم كسب نتيجه مناسب بسيار زياد مي باشد. افراد با تجربه و تبحر باال نيز ممكن است هميشه در دسترس

نبوده و يا هزينه پرسنلي را بسيار افزايش دهند. با توجه به خصوصيات روشهاي مورد بررسي مشخص مي باشد

عليرغم مطابقت جنبه هاي اصلي آنها با يكديگر، در بعضي از زمينه ها داراي تفاوتهائي مي باشند. از خصوصيات متمايز كننده روشها مي توان

از ويژگيهاي مورد ارزيابي، تعداد مراحل فرآيند ارزيابي، ابزارها و استراتژيها، ميزان مستند شدن و مشخص بودن جزئيات روندكار،

محدوده كاربر و نوع شركت كنندگان در جلسات را نام برد. مجموعه اين الف(.1378خصوصيات در جدول جمع آوري شده است )خيامي،

49

زمستان93..........................................................................................

...فصل پنجم:جمع بندی و پیشنهادهامقایسه روش های ارزیابی معماری نرم افزار1-5جدول

HoPLAAALAMCBAMATAM

تماميويژگيها

اصالح پذيري ونگهداری

صرفه جوئي ومنابع مالي

تماميويژگيها

ويژگيهايكيفيتي

7 فاز در 2مرحله

6 فاز و 2 فعاليت5فعاليت

فعاليت9 فاز2در

تعداد مراحلفرآيند

همه سيستمهاخط تولید

سيستمها ي كسب و

كار

همههمه سيستمهاسيستمها

محدودهكاربردي

نفره2تيم ارزيابي و

گروه ذينفعان

مشخصنشده

2 روز، تيم 2 نفره ارزيابي وگروه ذينفعان

روز، تيم2 نفره2

ارزيابي و گروه

ذينفعان

منابع زماني/انساني

نقاط تکاملپذیر

پيش بيني اثرات

تغييرات

تعيين منابع اقتصادي و

عملياتي

نقاط حساس و

مصالحه

اهداف ريزارزيابي

50

مراجع

مراجع

خیامی، سید رئوف، " ارزیابی و تحلیل معماری سازمانی"،تز دکترا،[1]1388دانشگاه شیراز، شیراز، شهریور

پورکماالتی، مریم، "بهبود روش های ارزیابی صفات کیفیتی معماری نرم[2] افزار"، پایان نامه کارشناسی ارشد، دانشگاه آزاد علوم تحقیقات تهران،

.1384تهران ، [3] Bahsoon R. & Emmerich W ، "Evaluating Software Architecture: Development ، Stability ،

and Evolution" ، ACS/IEEE ، 2003.

[4] Clements ، P. ، Kazman ، R. and Klein M. ، "Evaluating Software Architectures: Methods and Case Studies" ، 2002.

[5] H. P. Breivold ، I. Crnkovic ، and M. Larsson “، A systematic review of software architecture evolution research” ، Inf. Softw. Technol. ، vol. 54 ، no. 1 ، pp. 16–40 ، Jan. 2012.

[6] P. Clements ، R. Kazman ، M. Klein ، "Evaluating Software Architectures: Methods and Case Studies” ، Addison-Wesley ، ISBN 0-201-70482-x ، 2006.

[7] P. Shanmugapriya and R. M. Suresh “، Software architecture evaluation methods-A survey ” ،Int. J. Comput. Appl. ، vol. 49 ، no. 16 ، pp. 19–26 ، 2012.

شرفی ، مهران، "استفاده از آتاماتای تیمی در مدلسازی رفتاری و ارزیابی[8] معماری نرم افزار"، سیزدهمین کنفرانس ملی انجمن کامپیوتر ایران، ،

1386جزیزه کیش خلیج فارس، منتقمی، وجیه اله، "روشی برای مقایسه معماری های نرم افزار"، پایان[9]

1387نامه کارشناسی ارشد، دانشگاه صنعتی شریف تهران، تهران،.[10]B. Biel ، T. Grill ، and V. Gruhn “، Exploring the benefits of the combination of a software

architecture analysis and a usability evaluation of a mobile application ” ، J. Syst. Softw. ، vol. 83 ، no. 11 ، pp. 2031–2044 ، Nov. 2010.

[11]M. Anvaari and S. Jansen “، Evaluating architectural openness in mobile software platforms ”، in Proceedings of the Fourth European Conference on Software Architecture: Companion Volume ، 2010 ، pp. 85–92.

[12]Nancy R. Mead ، Travis Christian ، "An Evaluation of Cost-Benefit Using Security Requirements Prioritization" ، CERT ، SEI ، August 2013.

گزارش سمینار روش های ارزیابی معماری نرم افزار

Education