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

تعداد صفحات: 130 فرمت فایل: word کد فایل: 10002040
سال: 1384 مقطع: مشخص نشده دسته بندی: پایان نامه مهندسی کامپیوتر
قیمت قدیم:۱۹,۶۰۰ تومان
قیمت: ۱۷,۵۰۰ تومان
دانلود مقاله
  • خلاصه
  • فهرست و منابع
  • خلاصه گزارش سمینار روشهای ارزیابی معماری نرم افزار

     کامپیوتر

    گزارش سمینار کارشناسی ارشد

    چکیده

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

    معماری نرم افزار یعنی بیان ساختار یا ساختارهای سیستم که مولفه های نرم افزاری ، ویژگیهای قابل رویت از خارج این مولفه ها و روابط بین آنها را نشان می دهد. تعریف دیگری که برای معماری نرم افزار ارائه شده ، عبارت است از ساختار مولفه ها در یک سیستم ، رابطه داخلی آنها و اصول و خطوط راهنمایی که طراحی و ارزیابی سیستم را در طی زمان کنترل می کند. این تعریف جنبه های داخلی سیستم را در نظر می گیرد و بنابراین اکثر روشهای تحلیل و ارزیابی براساس آن عمل می کنند. تعریف معماری نرم افزار باید شامل دوقسمت ماکرو معماری ١و میکرو معماری ٢باشد که اولی روی محیِط سیستم متمرکز می شود و دومی ساختار داخلی یک سیستم را پوشش می دهد. البته تعاریف مختلفی برای معماری نرم افزار وجود دارد که ما در اینجا قصد ارائۀ همه آنها را نداریم و به دو تعریف فوق اکتفا می کنیم .

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

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

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

    در جواب به این نیازها که در بالا بیان شد، محققین مسئلۀ معماریهای قابل اجرا را مطرح نمودند.

    معماری قابل اجرا یک پیاده سازی جزئی از سیستم محسوب می شود که به منظور نمایش دادن چگونگی انجام عملیات ، وظایف و ویژگیهای سیستم مورد نظر می باشد، به خصوص در آن ویژگیهایی نمایش داده می شود که دربرگیرنده نیازمندیهای غیر وظیفه مندی می باشد. معماری قابل اجرا در طول فاز تشریح برای کاستن ریسکهای مرتبط با کارایی ، توان عملیاتی ، ظرفیت ، قابلیت اطمینان و ویژگیهای دیگر ایجاد می شود. بنابراین معماری قابل اجرا می تواند معماری نرم افزار را اعتبار سنجی نماید و همچنین معماری قابل اجرا قابلیت های وظیفه مندی سیستم را نمایش می دهد، تا با پایه و اساس قوی و بدون ترس از شکست وارد فاز ساخت شویم . در واقع قصد از معماری قابل اجرا، ساختن یک نمونۀ ١تکاملی با قابلیت ارضاء نیازمندیها می باشد. مدلهای زیادی برای نشان دادن معماری قابل اجرا وجود دارد، مانند شبکه های پتری رنگی که ابزار مناسبی برای مدلسازی سیستم و نمایش دادن صفات کیفیتی غیر وظیفه مندی می باشند، و به دلیل سادگی و قابلیت بالا، بسیار مورد توجه هستند. البته علاوه بر مدلهای موجود، زبانهایی نیز برای توصیف معماری وجود دارند که می توانند معماری قابل اجرا را نمایش دهند مانند زبان

    ADL و ADML.

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

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

    آنچه در این گزارش می خوانید عموماً برداشت مستقیم یا گزینشی از متون از پیش نوشته شده

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

    فصل اول

    مفاهیم بنیادی

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

    ١-١ معماری

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

    گفته می شود.

    منظور از معماری تعیین ساختار کلی یک سیستم است به گونه ای که صفات و ویژگیهای کیفیتی آن سیستم تأمین گردد. معماری یک دیدگاه واضح از همۀ سیستم به ما می دهد که برای کنترل توسعۀ آن لازم و ضروری است .

     

    فصل اول – مفاهیم بنیادی                                                                                         2

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

    ١- قابل فهم باشد.

    ٢- مولفه های آن قابل استفاده مجدد باشند.

    ٣- موارد اصلی کاربری سیستم را در بگیرد.

    ٤- نسبت به تغییرات انعطاف پذیر باشد.

    ٥- واسطهای بین زیرسیستمها را به نحوی تعریف کرده باشد تا زیرسیستمها کمترین وابستگی را به یگدیگر داشته باشند.

    ١-٢ معماری نرم افزار

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

    بر طبق نظر Shaw و Garlan [١٣]، اجزاء معماری نرم افزار به صورت مفهومی به موارد ذیل طبقه

    بندی می شود:

    مولفه : یک موجودیت محاسباتی

    متصل کننده : یک اثر متقابل و تعامل بین مولفه ها

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

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

    فصل اول – مفاهیم بنیادی                                                                                         

    معمولا ویژگیهای کلیدی که در نظر می گیریم ، جدا از نیازهای وظیفه مندی است و بیشتر در نیازهای غیروظیفه مندی خلاصه می شود. در واقع می توان گفت که معماری نرم افزار, رابطه ای بین ساختار و رفتار مؤلفه ها ایجاد می نماید.

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

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

    در یک سیستم نرم افزاری دانست که همگی روی آن اتفاق نظر دارند یا حداقل آنرا پذیرفته اند.

    معماری نرم افزار یک سیستم ، اطلاعات زیر را در مورد آن سیستم ارائه می دهد:

    μ سازماندهی سیستم نرم افزاری

    μ عناصر ساختاری و واسطهای آنها

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

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

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

    (نمودار و تصاویر د رفایل اصلی موجود است)

    -٣ تصمیمات معماری

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

    ١-٤ ویژگی های کیفیتی معماری نرم افزار

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

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

    فهرست:

    عنوان                                                                               شماره صفحه

    ١ مفاهیم بنیادی                                                                                  1

    ١-١ معماری                                                                           1

    ١-٢ معماری نرم افزار                                                               2

    ١-٣ تصمیمات معماری                                                               4

    ١-٤ ویژگیهای کیفیتی معماری نرم افزار                                           4

    ١-٤-١ کارایی                                                                  7

    ١-٤-٢ امنیت                                                                   8

    ١-٤-٣ در دسترس بودن                                                       9

    ١-٤-٤ قابلیت عملکرد یا وظیفه مندی                                         10

    ١-٤-٥ قابلیت استفاده                                                           11

    ١-٤-٦ قابلیت اصلاح پذیری                                                  12

    ١-٤-٧ قابلیت حمل                                                             14

    ١-٤-٨ قابلیت استفاده مجدد                                                    14

    ١-٤-٩ قابلیت تجمیع پذیری                                                    15

    ١-٤-١٠ قابلیت آزمایش                                                        16

    ١-٥ ارزیابی و تحلیل معماری                                                       16

    ١-٥- ١ تکنیکهای پرسشی                                                     18

    ١-٥-٢ تکنیکهای اندازه گیری                                                 20

    ٢ روشهای ارزیابی معماری نرم افزار مبتنی بر سناریو                                    21

    ٢-١ روش تحلیل معماری نرم افزار (SAAM )                                    21

    ٢-١-١ ورودیها و پیش شرطهای SAAM                                    22

    ٢-١-٢ مراحل نشست ارزیابی SAAM                                       22

    ٢-١-٣ نقشهای موجود در روش SAAM                                    24

    ٢-١-٤ محاسن و معایب روش SAAM                                       25

    ٢-١-٥ روش ارزیابی SAAM بنا شده برروی سناریوهای پیچیده (SAAMCS)   ٢٦

    ٢-١-٦ روش توسعه SAAM بوسیله یکپارچگی در دامنه (ESAAMI)     27

    ٢-١-٧ روش SAAM برای سیر تکاملی و استفاده مجدد (SAAMER)    29

    ٢-٢ روش تحلیل معماری از طریق مصالحه (ATAM )                           31

    ٢-٢-١ ورودیها و پیش شرطهای ATAM                                    32

    ٢-٢-٢ مراحل نشست ارزیابی ATAM                                       32

    ٢-٢-٣ نقشهای موجود در ATAM                                            35

    ٢-٢-٤ محاسن روش ATAM                                                 35

    ٢-٣ روش تحلیل هزینه - سود (CBAM )                                           36

    ٢-٣-١ ورودیها و پیش شرطهای CBAM                                    37

    ٢-٣-٢ مراحل نشست ارزیابی CBAM                                      38

    ٢-٣-٣ نقشهای CBAM                                                         40

    ٢-٣-٤ محاسن روش CBAM                                                  40

    ٢-٤ روش تحلیل قابلیت اصلاح در سطح معماری ( ALMA)                     41

    ٢-٤-١ ورودیها وپیش شرطهای ALMA                                     42

    ٢-٤-٢ مراحل نشست ارزیابی ALMA                                      43

    ٢-٤-٣ نقشهای موجود در روش ALMA                                    45

    ٢-٤-٤ محاسن و معایب ALMA                                              45

    ٢-٥ روش تحلیل خانواده معماری (FAAM )                                       46

    ٢-٥-١ ورودی ها و پیش شرطهای FAAM                                  47

    ٢-٥-٢ مراحل نشست ارزیابی FAAM                                       48

    ٢-٥-٣ نقشهای FAAM                                                         49

    ٢-٦ روش ارزیابی بازنگری فعالانه برای طراحی میانی (ARID)               50

    ٢-٦-١ مراحل نشست ارزیابی ARID                                        51

    ٢-٦-٢ نقشهای ARID                                                          52

    ٢-٦-٣ محاسن و معایب ARID                                               53

    ٣ روشهای ارزیابی معماری نرم افزار مبتنی بر شبکۀ پتری رنگی                       54

    ٣-١ اساس تئوری گراف و شبکه پتری                                              55

    ٣-١-١ تئوری گراف                                                           55

    ٣-١-٢ تعریف شبکه پتری                                                     57

    ٣-١-٣ تعریف رسمی شبکه پتری                                             59

    ٣-١-٤ توصیف شبکۀ پتری                                                    61

    ٣-١-٥ شبکه های پتری رنگی                                                 62

    ٣-٢ مدل معماری بر اساس شبکه پتری رنگی                                      65

    ٣-٣ صفات کیفیتی غیر وظیفه مندی و CPN ها                                     67

    ٣-٤ مشخص کردن صفات کیفی روی CPN ها                                     71

    ٣-٤-١ مدل شبکۀ پتری قابلیت اطمنیان                                       72

     

    ٣-٤-٢ مدل شبکۀ پتری امنیت در شبکه                                      72

    ٣-٤-٣ مدل شبکۀ پتری امنیت روی حافظه ها و فایل ها :                 73

    ٣-٤-٤ مدل شبکۀ پتری راندمان زمانی                                       74

    ٣-٤-٥ مدل شبکۀ پتری بهره وری منابع                                     75

    ٣-٥ ارزیابی صفات کیفیتی مبتنی بر CPN                                          76

    ٤ روش ارزیابی معماری نرم افزار SAM                                                    77

    ٤-١ مفاهیم اولیۀ SAM                                                                78

    ٤-١-١ شبکه های پتری زمان                                                  80

    ٤-١-٢ منطق درخت محاسباتی بی - درنگ                                 82

    ٤-٢ خصوصیات SAM                                                                82

    ٤-٣ مدل کردن رفتار معماریهای نرم افزار                                         84

    ٤-٤ پایه های SAM                                                                    84

    ٤-٥ مشخص کردن معماری نرم افزار یک سیستم C2                             92

    ٤-٥-١ نیازمندی های سیستم C2                                                 94

    ٤-٥-٢ رسمی کردن نیازمندیهای C2                                         95

    ٤-٥-٣ تعریف کردن مشخصات مولفه و متصل کننده                       98

    ٤-٥-٤ ساختن مدلهال رفتاری مولفه و متصل کننده                         100

    ٤-٥-٥ پشتیبانی از طراحی افزایشی سیستم C2                             107

    ٤-٦ تایید کردن سیستم C2                                                             113

    ٤-٦-١ تایید قیدهای ماژول (مولفه . متصل کننده )                           115

    ٤-٦-٢ تایید کردن قیدهای محیطی                                             119

    ٤-٦-٣ تایید کردن قیدهای ترکیبی                                             119

    ٤-٦-٤ تخطی از قیدها                                                         122

    ٤-٧ نتیجه گیری                                                                       123

    ٥ نتیجه گیری                                                                                   125

    کار آینده                                                                                 127

    فهرست منابع و مراجع                                                                129 

     

    منبع:

     

    [1] Len bass, Paul Clements, and Rick kazman, “software architecture in practice”

    second edition, Addison Wesely, April 2003

    [2] Mohammad  Ali  Babar,  Liming  Zhu,  Ross  Jeffery,  “A  Framework  for

    Classifiying  and  Comparing  Software  Architecture  Evaluation  Methods”,

    Australian Software Engineering Conference (ASWEC’04), IEEE 2004

    [3] Rami Bahsoon, Wolfgang Emmerich , “evaluating software architectures:

    development, stability, and evolution” , 2003

    [4] Liliana Dobrica & Eila Niemela, “A survey on software architecture analysis

    methods”, IEEE Transaction on softwae engineering, july 2002

    [5] PerOlof Bengtsson, Nico Lassing, Jan Bosch, Hans van Vliet, “Architectur-level

    modifiability analysis (ALMA), the journal of systems and software, June 2002

    [6] M. Lindvall, R. T. Tvedt, “An Empirically-Based Process for  Software

    Arhitecture Evaluation”, Empirical Software Architecture, 83-108, 2003.

    [7] Mugurel T.Ionita , Dieter K.Hammer , Henk Obbink , “Senario-Based Software

    Architecture Evaluation Methods : An Overview” , 2002

    [8] Sergey V. Korotikov, “Using of Petri Net Techniques in Information Systems

    Design”, IEEE 4th siberian russian workshop and tutorials EDM’2003, section

    II, ISBN 5-7782-0412-4 © 2003 NSTU

    [9] Roseanne Tesoriero Tvedt, Mikael Lindvall, Patricia Costa, “A Process for

    Software Architecture Evaluation using Metrics” , 27th Annual NASA Goddard.

    IEEE Software Engineering Workshop (SEW-27’02), © 2003 IEEE

    [10] Heeseok Choi, Keunhyuk Yeom, “A Approach to Software Architecture

    Evaluation with the 4+1 View Model of Architecture”, Ninth Asia-Pacific

    Software Engineering Confernce (APSEC’02), © 2002 IEEE

    [11] Huiqun Yu, Xudong He, Shu Gao, Yi Deng, “Modeling and Analyzing SMIL

    Document in SAM” , IEEE Fourth International Symposium on Multimedia

    Software Engineering (MSE’02), © 2002 IEEE

    [12] J. Wang, Y. Deng, and G. Xu , “Reachabilty analysis of real-time systems

    using time Petri nets” IEEE Transactions on Systems, Man, and Cybernetics -

    Part B: Cybernetics, 30(5):725–736, 2000.

    [13] J.Wang, X. He, and Y. Deng, “ Introducing software architecture specification

    and analysis in SAM through an example”, Information and Software

    Technology, 41:451–467, 1999.

    [14] H. Yu, X. He, Y. Deng, and L. Mo, “Formal analysis of realtime systems with

    SAM” , To appear in 4th International Conference on Formal Engineering

    Methods, 2002.

    [15] H. Yu, Xudong He, Yi Deng, Lian Mo, “A Formal Method for Analyzing

    Software Architecture Models in SAM”,  To appear in 26th Annual International

    Computer Software Applications Conference (COMPSAC’02), © 2002 IEEE

    [16] Ernesto Lopez-Mellado, Morma Villanueva-Paredes, Hugo Almeyda-Canepa,

    “Modelling of batch production systems using Petri nets with dynamic tokens”,

    Mathematics and Computers in Simulation, July 2004

    [17] Chun-Che Huang, Wen Yau Liang, “Object oriented development of the

    embedded system based on Petri-nets”, Computer Standards & Interfaces 26

    (2004) 187-203, 2004 

ثبت سفارش
عنوان محصول
قیمت