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

دانلود پروژه بررسی معماری نرم افزار ، بررسی انواع روشها و دیدگاه های معماری نرم افزار

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

فهرست مطالب
1   مقدمه 7
2  معماری نرم افزار چیست ؟ 9
2-1- تعاریف پایه در معماری نرم افزار 12
الگوهای معماری یا سبکهای معماری 12
مدل مراجع 13
معماري مرجع 13
2-2   دیدگاه های معماری 14
ديدگاه Bass 15
ديدگاه 4+1 16
ديدگاه‌هاي دیگر 17
3 طراحی معماری نرم افزار 17
3-1     كاركرد‌هاي سيستم و معماري نرم‌افزار 18
3-2   ويژگي‌هاي كيفي 19
3-3 ويژگي‌هاي كيفي سيستم 21
3-4   سناريو‌هاي ويژگي‌كيفي 22
3-5   ويژگي‌هاي كيفي كسب و كار 24
3-6   ويژگي‌هاي كيفي معماري 25
3-7     يك طراحی معماری خوب بايد داراي چه ويژگي‌هايي باشد؟‌ 26
3-8  دستیابی به ویژگیهای کیفی 27
تاکتیکهای معماری         27
الگوهای معماری 29
ارتباط تاکتیکها و الگوهای معماری 31
4 روشهای طراحی معماری نرم افزار 32
4-1 طراحی مبتنی بر ویژگی 32
4-2 طراحی به کمک سبک های معماری مبتنی بر ویژگی     34
4-3 طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه 39
5  ويژگي كيفي قابليت تغيير 47
5-1   تعريف قابليت تغيير 47
5-2   مشخص نمودن نياز‌هاي قابليت تغيير با استفاده از سناريو‌هاي كيفي 48
5-3   مدل سازي قابليت تغيير در سطح معماري نرم افزار   49
5-4   تاكتيك‌هاي قابليت تغيير 50
5-5  تاكتيك‌هايي كه تغييرات را محلي مي‌كنند. 52
5-6 تاكتيك‌هايي كه ميدان ديد وظايف را كاهش مي دهند. 53
5-7 تاكتيك‌هايي كه از پخش شدن تغييرات جلوگيري مي‌كنند. 54
5-8    ارزيابي قابليت تغيير 56
ارزيابي نحوه اختصاص وظايف 57
ارزيابي وابستگي بين ماژول‌ها 58
انواع وابستگي 58
نحوه بازنمايي وابستگي‌ها 61
روش Brute-force 62
استفاده از بستار انتقالی 63
استفاده از روش‌هاي بهينه سازي 64
استفاده از جدول وابستگي‌ها 64
5-9 تصميم گيري نهايي در مورد طراحي ويژگي كيفي قابليت تغيير 65
6 مطالعه موردي 66
6-1  مرحله 1 – انتخاب يك سناريو حقيقي 66
6-2  مرحله 2 – بررسي نوع سناريو حقيقي   67
6-3 مرحله 3 – انتخاب چهارچوب استدلال مناسب 70
6-4 مرحله 4 – مشخص نمودن پارامتر‌هاي محدود و آزاد     74
6-5 مرحله 5 –  مشخص كردن تاكتيك‌هاي وابسته به پارامتر‌هاي آزاد     75
6-6 مرحله 6 – اختصاص مقادير اوليه به پارامتر‌هاي آزاد       77
6-7 مرحله 7 – انتخاب تاكتيك‌ها و به كاربردن آنها براي دستيابي به پاسخ مناسب     78
استفاده از كامپايلر به عنوان واسط 82
استفاده از سيستم‌عامل به عنوان واسط 83
6-8 مرحله 8 : اختصاص مسئوليت‌ها به عناصر معماري 84
7   خلاصه و نتیجه گیری 86
8   مراجع 87

فهرست مطالب

شكل 1 –  ارتباط بين الگوي معماري، مدل مرجع و معماري مرجع 14
شكل 2 –   بخش‌هاي تشكيل دهنده سناريو ويژگي كيفي 23
شکل 3 – خلاصه ای از تاکتیک های قابلیت تغییر 23
شکل 4 – خلاصهای از تاکتیکهای کارایی 28
شکل 5 – مجموعه ای از مهمترین الگوهای معماری 30
شکل 6 – ورودیها و خروجیهای روش ADD 33
شکل 7 – الگوی معماری خط لوله همزمان 37
جدول 1 – پارامترهای الگوی خط لوله همزمان 37
جدول 2 – خروجی فاز اول روش CBAM 41
شكل 8 –  نمودار مقايسه ميزان كاربرد هر راهبرد در مقابل هزينه 41
شكل 9 –  انواع نمودار‌هاي ممكن براي سودمندي براساس پاسخ 44
شكل 10 – معماري سه لايه 51
جدول 3 – نحوه بازنمايي وابستگي بين دو ماژول 61
شكل 11 – نمودار جريان داده ( تغييرات به طور غير مستقيم از A به B منتقل مي‌شود) 63
جدول 4- سناريو حقيقي قابليت تغيير براي سيستم مورد مطالعه 67
جدول 5 – سناريو عمومي قابليت تغيير براي مسئله مورد بررسي 68
شكل 12 – نمايش سيستم به صورت دو ماژول وابسته 69
جدول 6 – چهارچوب استدلال براي ويژگي كيفي قابليت تغيير 71
شكل 13 – پارامتر‌هاي اثر گذار بر روي هزينه تغييرات 73
جدول 7 – پارامتر‌هاي قابليت تغيير و تاكتيك‌هاي اثر گذار بر روي آنها 75
جدول 8 – قانون‌هايي كه نحوه استفاده از تاكتيك‌ها را مشخص 78
شكل 14 – تكه طراحي تاكتيك شكستن زنجيره وابستگي 84
شکل 15 – اختصاص وظايف با توجه به تاكتيك‌هاي اعمال شده 85
چکیده
با گسترش روز افزون استفاده از مدل های فرایند مبتنی بر معماری، طراحی معماری نرم افزار اهمیت ویژه ای یافته است. یک طراحی معماری خوب، طراحی است که نیاز های کیفی مورد انتظار مشتری را برآورده نماید. در این گزارش روش  های گوناگون طراحی معماری نرم افزار مورد بررسی قرار خواهد گرفت. سپس ویژگی کیفی قابلیت تغییر به طور دقیق و جزئیات معرفی خواهد شد و سپس معماری یک سیستم مطالعه موردی با دیدگاه دستیابی به قابلیت تغییر طراحی خواهد شد.
مقدمه
امروزه يكي از مهمترين ويژگي‌هاي هر سيستم نرم‌افزاري، كيفيت مي‌باشد. با پيشرفت‌هاي انجام شده و گسترش ابزار‌هاي گوناگون براي توسعه نرم‌افزار، توسعه نرم‌افزار‌هايي كه كاركرد‌هاي مورد نظر مشتريان را برآورده سازند، امري آسان و سريع گشته است. در حال حاضر، تفاوت بين دو نرم‌افزار را توانايي نرم‌افزار‌ها در برآورده ساختن ويژگي‌هاي كيفي مورد انتظار تعيين مي‌كند.
معماري نرم افزارِ يك برنامه يا سيستم كامپيوتري، ساختار يا ساختارهايي از سيستم مي باشد، كه در برگيرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بين آنها باشد[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 نمايش داده شده است.
شكل 1 –  ارتباط بين الگوي معماري، مدل مرجع و معماري مرجع

2-2 دیدگاه های معماری
سيستم هاي مدرن و امروزي به اندازه اي پيچيده هستند كه يه ساختار و ديدگاه واحد، توانايي نمايش همه جنبه هاي آنها را ندارد.[Bass 03] بنابراين براي نمايش معماري يك سيستم نرم افزاري از ديدگاه هاي مختلف استفاده مي كنيم. يك ساختار يا ديدگاه معماري، نمايش مجموعه اي از اجزاي معماري مرتبط با يكديگر و ارتباط بين اين اجزا مي باشد.

ديدگاه Bass
بر اساس طبقه بندي ارائه شده در [Bass 03] ساختارهاي معماري نرم افزار قابل دسته بندي از سه گروه عمده به شرح زير مي باشند:
• ساختار ماژول‌ها
در اين ساختار، اجزاء تشكيل دهنده ماژول ها هستند. ماژول، يك واحد پياده سازي شده از سيستم مي‌باشد. ساختار ماژول‌ها نمايشي مبتني بر كد  از سيستم مي باشد. هر ماژول شامل طيفي از وظايف  مي‌باشد. در ساختار ماژول‌ها، بيشترين تاكيد بر نحوه پخش شدن وظايف مختلف بر روي ماژول‌ها و نحوه ارتباط ماژول‌ها با يكديگر است. در اين ساختار تاكيد خاصي روي ساختار‌هاي اجرايي نمي‌شود.
• ساختار اجزاء و رابط‌ها
در اين ديدگاه، اجزاء تشكيل دهنده واحد‌هاي در حال اجرا  مي باشند(واحد‌هاي محاسباتي). همچنين رابط‌ها نحوه ارتباط و گفتگوي بين اجزاء را نشان خواهند داد. اين ساختار مشخص كننده اجزاي مهم اجرايي و نحوه ارتباط آنها با يكديگر است. همچنين اين ساختار مواردي نظير : مهمترين محل‌هاي ذخيره اطلاعات، نحوه تكرار داده‌ها، اجزايي كه به طور موازي اجرا مي‌گردند، مي‌باشد.
• ساختار تخصيص منابع
اين ساختار ارتباط بين اجزاء نرم افزاري و اجزائي كه در محيط خارجي توليد و استقرار نرم افزار وجود دارند را نشان مي دهد. اين ساختار، نحوه استقرار اجزاء برنامه روي پردازنده‌ها، فايل‌هاي مربوط به هريك از بخش‌هاي برنامه نرم‌افزاري در طول پياده‌سازي، اجرا و تست و نحوه اختصاص وظايف پياده‌سازي به تيم را مشخص مي‌نمايد.
در اين ديدگاه، از ابزار UML استفاده نشده ولي از لحاظ مفهومي قابليت پياده سازي با استفاده از UML وجود دارد.

ديدگاه 4+1
اين ديدگاه در [Kruchten 95] ارائه شده و امروزه به عنوان استاندارد در IEEE 1471 [IEEE 00] مطرح مي‌باشد. در اين ديدگاه، ساختارهاي معماري به صورت زير طبقه بندي شده اند :
• Logical View
• Process View
• Deployment View
• Implementation View
• Use-case View
همچنين اين ديدگاه در [RUP 03] نيز به عنوان استاندارد توسعه معماري نرم افزار معرفي گرديده است. پايه اين ديدگاه متدولوژي شيء گرا و ابزار استفاده از آن UML مي باشد. براي استفاده بهينه از اين ديدگاه پيشنهاد مي شود كه مدل فرايند انتخابي به صورت تكراري و بر پايه RUP انتخاب گردد.

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

    راهنما

    » فراموش نکنید! بخش پشتیبانی مقاله آنلاین ، در همه ساعات همراه شماست

    اطلاعات ارتباطی ما پست الکترونیکی: Article.university@gmail.com

    تماس با پشتیبانی 09383646575

    برای سفارشتان از سایت ما کمال تشکر را داریم.

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

    معادله فوق را حل نمایید *

    تمام حقوق مادی , معنوی , مطالب و طرح قالب برای این سایت محفوظ است