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

موضوع : طراحی معماری نرم افزار

توضیح : این فایل به صورت ورد و آماده چاپ می باشد

چکیده
با گسترش روز افزون استفاده از مدل¬های فرایند مبتنی بر معماری، طراحی معماری نرم افزار اهمیت ویژه¬ای یافته است. یک طراحی معماری خوب، طراحی است که نیاز¬های کیفی مورد انتظار مشتری را برآورده نماید. در این گزارش روش ¬های گوناگون طراحی معماری نرم افزار مورد بررسی قرار خواهد گرفت. سپس ویژگی کیفی قابلیت تغییر به طور دقیق و جزئیات معرفی خواهد شد و سپس معماری یک سیستم مطالعه موردی با دیدگاه دستیابی به قابلیت تغییر طراحی خواهد شد.
1    مقدمه
امروزه يكي از مهمترين ويژگي‌هاي هر سيستم نرم‌افزاري، كيفيت مي‌باشد. با پيشرفت‌هاي انجام شده و گسترش ابزار‌هاي گوناگون براي توسعه نرم‌افزار، توسعه نرم‌افزار‌هايي كه كاركرد‌هاي مورد نظر مشتريان را برآورده سازند، امري آسان و سريع گشته است. در حال حاضر، تفاوت بين دو نرم‌افزار را توانايي نرم‌افزار‌ها در برآورده ساختن ويژگي‌هاي كيفي مورد انتظار تعيين مي‌كند.
معماري نرم افزارِ يك برنامه يا سيستم كامپيوتري، ساختار يا ساختارهايي از سيستم مي باشد، كه در برگيرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بين آنها باشد[Bass 03]  . معماري نرم‌افزار شامل اولين تصميمات طراحي سيستم مي‌باشد و اين تصميمات زيربناي فعاليت‌هاي طراحي، پياده‌سازي، استقرار و نگهداري سيستم مي‌باشد. همچنين معماري نرم‌افزار، اولين عنصر قابل ارزيابي در فرايند توسعه نرم‌افزار مي‌باشد[Bass 03]  . بنابراين براي طراحي سيستمي كه نياز‌هاي كيفي مورد نظر را برآورده سازد، توليد معماري نرم‌افزار اولين گام در دستیابی به كيفيت در نرم‌افزار و همچنين ارزيابي ويژگي‌هاي كيفي است. 
در مدل¬های فرایند توسعه نرم¬افزار مبتنی بر معماری  معمولاً ابتدا نیاز¬های کیفی سیستم تعیین شده و سپس معماری نرم¬افزار مربوطه طراحی می¬گردد. پس از طراحی معماری، می¬توان به ارزیابی آن پرداخت و تغییرات لازم را در طراحی مورد نظر ایجاد داد. بنابراین دو بخش اساسی در مدل¬های فرایند توسعه نرم¬افزار مبتنی بر معماری، بخش¬های طراحی و ارزیابی معماری نرم افزار می¬باشند. این دو بخش در ارتباط مستقیم با یکدیگر می¬باشند و هر یک مکمل دیگری می¬باشد. بنابراین فرایند طراحی معماری را می¬توان شامل ساخت معماری نرم¬افزار، ارزیابی آن و اصلاح معماری پیشنهادی دانست.
در این گزارش، هدف بررسی روش¬های موجود در طراحی معماری نرم¬افزار بر اساس ویژگی-های کیفی مورد نظر مشتریان و بررسی نحوه خودکار سازی فرایند طراحی معماری با ارائه ابزار-هایی برای این منظور می¬باشد. ادامه مطالب گزارش به این صورت طبقه بندی شده اند. در بخش 2 توضیح مختصری در ارتباط با معماری نرم¬افزار و مفاهیم مرتبط با آن ارائه می¬شود. این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد. در بخش 3 طراحی معماری نرم¬افزار، ویژگی¬های یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت. در بخش 4 روش¬های طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت. در بخش 5 خلاصه و  نتیجه گیری ارائه خواهد شد. در بخش 6 مراجع مورد استفاده در این گزارش معرفی می¬گردد.
2    معماری نرم افزار چیست ؟
براي معماري نرم‌افزار، تعريفي كه به طور عمومي پذيرفته شده باشد، وجود ندارد. افراد مختلف، معماري نرم‌افزار را به اشكال گوناگون تعريف كرده‌اند. اين تعاريف، از لحاظ ظاهري متفاوتند ولي به مفهوم مشتركي اشاره مي‌كنند. 
در [Bass 03] معماري نرم افزار به صورت زير تعريف شده است :
معماري نرم افزار يك برنامه يا سيستم كامپيوتري، ساختار يا ساختارهايي از سيستم مي باشد، كه در برگيرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بين آنها باشد.
از تعريف فوق مي توان به نتايج زير دست يافت :
•    معماري، اجزاي نرم افزار را تعريف مي نمايد. همچنين در اين تعريف، از جزئياتي از اجزا، كه در نحوه استفاده و ارتباط با اجزاي ديگر كاربردي ندارند؛ صرف نظر مي گردد.
•    هر سيستم نرم افزار شامل چندين ساختار مي باشد؛ و هيچ يك از اين ساختارها، به تنهايي معماري نرم افزار نمي¬باشد. بلكه اين ساختارها در كنار يكديگر معماري نرم افزار را تشكيل مي دهند.
•    هر سيستم نرم افزاري داراي يك معماري مي باشد. (زيرا هر سيستم نرم افزاري داراي اجزايي است كه اين اجزا با يكديگر داراي رابطه مي باشند).
•    رفتار هريك از اجزاء، بخشي از معماري نرم افزار مي باشد. (زيرا اين رفتار در نحوه ارتباط بين اجزا تاثيرگذار است.)
•    معماري نرم افزار بايد قابل ارزيابي باشد تا بتوان از روي آن تشخيص داد سيستم مورد نظر بر پايه معماري انتخاب شده نيازهاي خود را برآورده خواهد كرد يا خير.
علاوه بر تعاریف ارائه شده در [Bass03] تعاریف گوناگون دیگری نیز برای معماری نرم افزار ارائه شده است که در اینجا به برخی از آنها اشاره خواهیم کرد :
در [IEEE00]معماري نرم افزار به صورت زير تعريف شده است :
معماري نرم‌افزار، سازمان زيربنايي سيستم مي‌باشد، كه در قالب اجزا  و روابط بين آنها و همچنين روابط آنها با محيط، بيان شده است و براي طراحي و تكامل آن اصولي وجود دارد.
در اين نوع تعريف، فرايند توليد معماري، عضوي از معماري در نظر گرفته شده است. ( زيرا قوائد و اصول طراحي و تكامل نيز عضوي از معماري در نظر گرفته شده اند.‌) در حالي كه اين موارد جزء معماري محسوب نمي‌گردند. معماري هر سيستم نرم‌افزاري مي‌تواند بدون توجه به نحوه توليد آن مشخص و ارزيابي گردد.
در [Booch 98]  معماري نرم افزار مجموعه‌اي از تصميمات مهم درباره ساختار سيستم نرم‌افزاري ، انتخاب اجزاء ساختاري و ارتباطات بين آنها و همچنين مشخص نمودن نحوه همكاري اين اجزاء با يكديگر مي‌باشد. وقتي اين اجزاء در كنار يكديگر سيستم بزرگي را تشكيل دهند معماري نرم افزار به وجود خواهد آمد.
در [Garlan 93]، معماري نرم‌افزار سطحي از طراحي تعريف شده است كه داراي ويژگي‌هاي زير مي‌باشد :
•     وراي الگوريتم و ساختمان داده طراحي شده باشد.
•     شامل ساختار كلي سيستم، ساختار‌هاي كنترلي عمده، پروتكل‌هاي ارتباطي، اختصاص كاركرد‌ها به اجزاء، توزيع فيزيكي اجزاء باشد.
•     تركيبي از اجزاء طراحي باشد كه از بين گزينه‌هاي طراحي موجود انتخاب شده است.
در تعاريف ارائه شده توسط [Booch 98] و [Garlan 93]، از معماري به عنوان ساختار كلي سيستم نام‌ برده شده است. بايد توجه داشت، ضعف اين تعريف نسبت به تعريف ارائه شده توسط [Bass 03] در محدود كردن ساختار سيستم به تنها يك ساختار مي‌باشد. در حالي كه سيستم براي مشخص كردن معماري، داراي ساختار‌هاي گوناگون باشد.
در [RUP 03] معماري نرم‌افزار سازمان يا ساختار اجزاء اصلي سيستم كه از طريق واسط‌هايي با هم ارتباط برقرار مي‌كنند؛ مي‌باشد به طوري كه هر يك از اجزاء از اجزاء كوچكتري تشكيل شده كه اين اجزاء كوچك نيز با يكديگر ارتباط دارند. در اين تعريف نيز، به ساختار‌هاي گوناگون اشاره نشده است. گرچه در [RUP 03] در مرحله طراحي معماري نرم‌افزار، ساختار‌ها يا ديدگاه هاي مختلفي براي معماري معرفي شده است.
ديدگاه ما نسبت به معماري، ديدگاه [Bass 03] مي‌باشد. يكي از نكات مهم در اين تعريف، امكان ارائه ساختار‌هاي گوناگون براي معماري مي‌باشد. اين ساختار‌ها نبايد محدود به چندين ساختار پيش فرض باشند. به عنوان مثال براي توليد معماري يك سيستم امن، مي‌توان مدل امنيتي سيستم را نيز عضو معماري قرار داد. زير بررسي و ارزيابي آن قبل از مرحله پياده سازي بسيار حياتي مي‌باشد.
2-1    تعاریف پایه در معماری نرم افزار
در این بخش به بررسی برخی از مفاهیم پایه در معماری نرم افزار خواهیم پرداخت. در بخش های بعدی از این مفاهیم پایه استفاده زیادی خواهد شد.
الگو¬های معماری یا سبک¬های معماری
الگوهاي معماري   یا سبک ¬های معماری  شامل شرحي از اجزاء و نوع روابط بين آنها مي باشد به نحوي كه تعدادي قانون براي معرفي اجزاء و نحوه ارتباط بين آنها، مشخص گردد. [Bass 03]
به عنوان مثال client-server يك الگوي معماري است كه مشخص مي كند سيستم داراي دو جزء مي باشد و اين دو جزء تحت پروتكل خاصي با يكديگر ارتباط دارند.
هر الگوي معماري در برگيرنده تعدادي معيار كيفي  مي باشد و معمار نرم افزار بر اساس نيازهاي كيفيتي مورد نظر، الگوي معماري مناسب را انتخاب مي نمايد.
در بسياري از موارد از سبك‌هاي معماري، به جاي الگوهاي معماري استفاده مي گردد.
از ديدگاه ما الگو‌هاي طراحي بايد بتوانند يك يا چند نياز كيفي را برآورده نمايند. زيرا درصورتي كه تنها كاركرد مد نظر باشد بدون استفاده از الگوي خاصي مي‌توان به آن دست يافت.
فهرست مطالب
1   مقدمه    4
2  معماری نرم افزار چیست ؟    5
2-1       تعاریف پایه در معماری نرم افزار    6
الگوهای معماری یا سبکهای معماری    6
مدل مراجع    6
معماري مرجع    6
2-2   دیدگاه های معماری    7
ديدگاه Bass    7
ديدگاه 4+1    8
ديدگاه‌هاي دیگر    8
3 طراحی معماری نرم افزار    9
3-1     كاركرد‌هاي سيستم و معماري نرم‌افزار    9
3-2   ويژگي‌هاي كيفي    9
3-3 ويژگي‌هاي كيفي سيستم    10
3-4   سناريو‌هاي ويژگي‌كيفي    10
3-5   ويژگي‌هاي كيفي كسب و كار    11
3-6   ويژگي‌هاي كيفي معماري    12
3-7     يك طراحی معماری خوب بايد داراي چه ويژگي‌هايي باشد؟‌    12
3-8  دستیابی به ویژگیهای کیفی    12
تاکتیکهای معماری            12
الگوهای معماری    14
ارتباط تاکتیکها و الگوهای معماری    15
4 روشهای طراحی معماری نرم افزار    16
4-1 طراحی مبتنی بر ویژگی    16
4-2 طراحی به کمک سبک های معماری مبتنی بر ویژگی        17
4-3 طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه    19
5  ويژگي كيفي قابليت تغيير    23
5-1   تعريف قابليت تغيير    23
5-2   مشخص نمودن نياز‌هاي قابليت تغيير با استفاده از سناريو‌هاي كيفي     23
5-3   مدل سازي قابليت تغيير در سطح معماري نرم افزار       24
5-4   تاكتيك‌هاي قابليت تغيير    24
5-5  تاكتيك‌هايي كه تغييرات را محلي مي‌كنند.    25
5-6 تاكتيك‌هايي كه ميدان ديد وظايف را كاهش مي دهند.    26
5-7 تاكتيك‌هايي كه از پخش شدن تغييرات جلوگيري مي‌كنند.    26
5-8    ارزيابي قابليت تغيير    27
ارزيابي نحوه اختصاص وظايف    27
ارزيابي وابستگي بين ماژول‌ها    27
انواع وابستگي    27
نحوه بازنمايي وابستگي‌ها    29
روش Brute-force    29
استفاده از بستار انتقالی    29
استفاده از روش‌هاي بهينه سازي    30
استفاده از جدول وابستگي‌ها    30
5-9 تصميم گيري نهايي در مورد طراحي ويژگي كيفي قابليت تغيير    30
6 مطالعه موردي    31
6-1  مرحله 1 - انتخاب يك سناريو حقيقي    31
6-2  مرحله 2 - بررسي نوع سناريو حقيقي       31
6-3 مرحله 3 - انتخاب چهارچوب استدلال مناسب    32
6-4 مرحله 4 - مشخص نمودن پارامتر‌هاي محدود و آزاد         34
6-5 مرحله 5 -  مشخص كردن تاكتيك‌هاي وابسته به پارامتر‌هاي آزاد        35
6-6 مرحله 6 - اختصاص مقادير اوليه به پارامتر‌هاي آزاد           36
6-7 مرحله 7 - انتخاب تاكتيك‌ها و به كاربردن آنها براي دستيابي به پاسخ مناسب        36
استفاده از كامپايلر به عنوان واسط    38
استفاده از سيستم‌عامل به عنوان واسط    38
6-8 مرحله 8 : اختصاص مسئوليت‌ها به عناصر معماري    38
7   خلاصه و نتیجه گیری    40
8   مراجع    41
شكل 1 -  ارتباط بين الگوي معماري، مدل مرجع و معماري مرجع    7
شكل 2 -   بخش‌هاي تشكيل دهنده سناريو ويژگي كيفي    11
شکل 3 – خلاصه¬ای از تاکتیک¬های قابلیت تغییر    11
شکل 4 – خلاصهای از تاکتیکهای کارایی    13
شکل 5 - مجموعه ای از مهمترین الگوهای معماری    14
شکل 6 – ورودیها و خروجیهای روش ADD    16
شکل 7 – الگوی معماری خط لوله همزمان    18
جدول 1 – پارامترهای الگوی خط لوله همزمان    18
جدول 2 – خروجی فاز اول روش CBAM    20
شكل 8 -  نمودار مقايسه ميزان كاربرد هر راهبرد در مقابل هزينه    20
شكل 9 -  انواع نمودار‌هاي ممكن براي سودمندي براساس پاسخ    21
شكل 10 - معماري سه لايه    24
جدول 3 - نحوه بازنمايي وابستگي بين دو ماژول    29
شكل 11 - نمودار جريان داده ( تغييرات به طور غير مستقيم از A به B منتقل مي‌شود)    30
جدول 4- سناريو حقيقي قابليت تغيير براي سيستم مورد مطالعه    31
جدول 5 - سناريو عمومي قابليت تغيير براي مسئله مورد بررسي    32
شكل 12 - نمايش سيستم به صورت دو ماژول وابسته    32
جدول 6 - چهارچوب استدلال براي ويژگي كيفي قابليت تغيير    33
شكل 13 - پارامتر‌هاي اثر گذار بر روي هزينه تغييرات    34
جدول 7 - پارامتر‌هاي قابليت تغيير و تاكتيك‌هاي اثر گذار بر روي آنها    35
جدول 8 - قانون‌هايي كه نحوه استفاده از تاكتيك‌ها را مشخص    36
شكل 14 - تكه طراحي تاكتيك شكستن زنجيره وابستگي    38
شکل 15 - اختصاص وظايف با توجه به تاكتيك‌هاي اعمال شده    39