عنوان :
پایان نامه معماری نرم افزار
تعداد صفحات :۸۵
نوع فایل : ورد و قابل ویرایش
چکیده
با گسترش روز افزون استفاده از مدلهای فرایند مبتنی بر معماری، طراحی معماری نرم افزار اهمیت ویژهای یافته است. در این گزارش، هدف بررسی روشهای موجود در طراحی معماری نرمافزار بر اساس ویژگیهای کیفی مورد نظر مشتریان و بررسی نحوه خودکار سازی فرایند طراحی معماری با ارائه ابزارهایی برای این منظور میباشد. ادامه مطالب گزارش به این صورت طبقه بندی شده اند. در بخش ۲ توضیح مختصری در ارتباط با معماری نرمافزار و مفاهیم مرتبط با آن ارائه میشود. این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد. در بخش ۳ طراحی معماری نرمافزار، ویژگیهای یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت. در بخش ۴ روشهای طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت. پس از بررسی روشهای گوناگون طراحی، ویژگی کیفی قابلیت تغییر به عنوان نمونهای از ویژگیهای کیفی اثرگذار در معماری نرم افزار معرفی گردید. و مواردی نظیر تاکتیکهای دستیابی و روش ارزیابی آن ارائه شد. سپس یک سیستم به عنوان مطالعه موردی انتخاب گردید و یک سناریو قابلیت تغییر در آن با استفاده از تاکتیکها و روشهای معرفی شده، طراحی شد. در طراحی سعی گردید از روشی استفاده گردد که امکان انجام خودکار آن بدون نیاز به دانش ویژه انسانی در زمینه ویژگی کیفی مورد نظر فراهم گردد.
واژه های کلیدی: معماری نرم افزار، الگوهای معماری ، مدل مرجع ، معماری مرجع، دیدگاه های معماری ،ویژگی کیفی
فهرست مطالب
چکیده………………….. ۱
مقدمه………. ۲
معماری نرم افزار چیست ؟ ۳
تعاریف پایه در معماری نرم افزار ۶
الگوهای معماری یا سبکهای معماری ۷
مدل مرجع……. ۷
معماری مرجع ۸
دیدگاه های معماری ۸
دیدگاه Bass ۹
دیدگاه ۴+۱ ۱۰
دیدگاه‌های دیگر ۱۱
طراحی معماری نرم افزار ۱۱
کارکردهای سیستم و معماری نرمافزار ۱۲
ویژگیهای کیفی ۱۲
ویژگیهای کیفی سیستم ۱۵
سناریو‌های ویژگی‌کیفی ۱۶
ویژگیهای کیفی کسب و کار ۱۷
ویژگیهای کیفی معماری ۱۹
دستیابی به ویژگیهای کیفی ۲۰
تاکتیکهای معماری ۲۰
الگوهای معماری ۲۲
ارتباط تاکتیکها و الگوهای معماری ۲۵
روشهای طراحی معماری نرم افزار ۲۶
طراحی مبتنی بر ویژگی ۲۶
طراحی به کمک سبک های معماری مبتنی بر ویژگی ۲۸
طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه ۳۳
ویژگی کیفی قابلیت تغییر ۴۰
تعریف قابلیت تغییر ۴۰
مشخص نمودن نیازهای قابلیت تغییر با استفاده از سناریو‌های کیفی ۴۱
مدل سازی قابلیت تغییر در سطح معماری نرم افزار ۴۲
تاکتیکهای قابلیت تغییر ۴۳
ارزیابی قابلیت تغییر ۴۹
ارزیابی نحوه اختصاص وظایف ۴۹
ارزیابی وابستگی بین ماژول‌ها ۵۰
انواع وابستگی ۵۰
نحوه بازنمایی وابستگی‌ها ۵۳
روش Brute-force ۵۴
استفاده از بستار انتقالی ۵۵
استفاده از روشهای بهینه سازی ۵۶
استفاده از جدول وابستگی‌ها ۵۶
تصمیم گیری نهایی در مورد طراحی ویژگی کیفی قابلیت تغییر ۵۷
مطالعه موردی ۵۸
تعداد وظایف تغییر یافته در ماژول ثانویه ۶۹
وابستگی نحوی ومعنایی ۷۲
استفاده از کامپایلر به عنوان واسط ۷۴
استفاده از سیستم‌عامل به عنوان واسط ۷۴
خلاصه و نتیجه گیری ۷۷
منابع ۷۸
منابع
[Asundi 01] J. Asundi, R. Kazman, and M. Klein, Using Economic Considerations to Choose Among Architecture Design Alternatives, Technical Report, CMU/SEI-2001-TR-035, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2001.
[Bachmann 02] F. Bachmann, L. Bass, and M. Klein, Illuminating the Fundamental Contributors to Software Architecture Quality, Technical Report, CMU/SEI-2002-TR-025, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2002.
[Bachmann 03] F. Bachmann, L. Bass, and M. Klein, Deriving Architectural Tactics: A Step Toward Methodical Architectural Design, Technical Report, CMU/SEI-2003-TR-004, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2003.
[Bass 01] L. Bass, M. Klein, F. Bachmann, “Quality Attribute Design Primitives and the Attribute Driven Design Method,” In proc. of the 4th International Workshop on Product Family Engineering, Bilbao, Spain, 3-5 October 2001, pp. 122 – 130.
[Bass 03] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition, Addison-Wesley, 2003.
[Booch 98] G. Booch, J. Rumbaugh, and I. Jacobson, UML User Guide, Addison-Wesley Longman, 1998.
[Chastek 05] G. Chastek, and R. Ferguson, Toward Measures for Software Architectures, Technical Report, CMU/SEI-2006-TN-013, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2005
[Garlan 93] D. Garlan, and M. Shaw. An Introduction to Software Architecture, Technical Report, CMU/SEI-94-TR-21, 1993.
[Garland 03] J. Garland, R. Anthony, Large-Scale Software Architecture, Wiley Press, 2003.
[IEEE 00] Recommended Practice for Architectural Description of Software Intensive Systems. Technical Report IEEE P1471-2000, IEEE Standards Department, The Architecture Working Group of the Software Engineering Committee, September 2000.
[Kazman 02] R. Kazman, J. Asundi, and M. Klein, Making Architecture Design Decisions: An Economic Approach, Technical Report, CMU/SEI-2002-TR-035, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2001.
[Klein 99] M. Klein, R. Kazman, Attribute-Based Architectural Styles, Technical Report, CMU/SEI-99-TR-022, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1999.
[Kruchten 95] P. Kruchten, “The 4+1 view model of architecture”, IEEE Software, 12, No. 5, 1995.
[RUP 03] P. Kruchten, The Rational Unified Process: An Introduction, Third Edition, Addison-Wesley, 2003.
[Shaw 96] M. Shaw, and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996.
[Shaw 06] M. Shaw, and P. Clements, “The Golden Age of Software Architecture,” IEEE Software, vol. ۲۳, no. ۲, pp. 31-39, Mar/Apr, ۲۰۰۶٫
[With 02] P. H.N. de With, and and G. J. van Dijk, “Architecture assessment for practical management of system architectures”, Proc. Workshop Embedded Systems (Progress02), Utrecht, NL, 2002.
مقدمه
امروزه یکی از مهمترین ویژگیهای هر سیستم نرم‌افزاری، کیفیت میباشد. با پیشرفت‌های انجام شده و گسترش ابزار‌های گوناگون برای توسعه نرمافزار، توسعه نرم‌افزار‌هایی که کارکردهای مورد نظر مشتریان را برآورده سازند، امری آسان و سریع گشته است. در حال حاضر، تفاوت بین دو نرمافزار را توانایی نرم‌افزار‌ها در برآورده ساختن ویژگیهای کیفی مورد انتظار تعیین می‌کند.
معماری نرم افزارِ یک برنامه یا سیستم کامپیوتری، ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد[Bass 03] . معماری نرمافزار شامل اولین تصمیمات طراحی سیستم میباشد و این تصمیمات زیربنای فعالیت‌های طراحی، پیاده‌سازی، استقرار و نگهداری سیستم میباشد. همچنین معماری نرمافزار، اولین عنصر قابل ارزیابی در فرایند توسعه نرمافزار میباشد[Bass 03] . بنابراین برای طراحی سیستمی که نیازهای کیفی مورد نظر را برآورده سازد، تولید معماری نرمافزار اولین گام در دستیابی به کیفیت در نرمافزار و همچنین ارزیابی ویژگیهای کیفی است.
در مدلهای فرایند توسعه نرمافزار مبتنی بر معماری[۱] معمولاً ابتدا نیازهای کیفی سیستم تعیین شده و سپس معماری نرمافزار مربوطه طراحی میگردد. پس از طراحی معماری، میتوان به ارزیابی آن پرداخت و تغییرات لازم را در طراحی مورد نظر ایجاد داد. بنابراین دو بخش اساسی در مدلهای فرایند توسعه نرمافزار مبتنی بر معماری، بخشهای طراحی و ارزیابی معماری نرم افزار میباشند. این دو بخش در ارتباط مستقیم با یکدیگر میباشند و هر یک مکمل دیگری میباشد. بنابراین فرایند طراحی معماری را میتوان شامل ساخت معماری نرمافزار، ارزیابی آن و اصلاح معماری پیشنهادی دانست.
در این گزارش، هدف بررسی روشهای موجود در طراحی معماری نرمافزار بر اساس ویژگیهای کیفی مورد نظر مشتریان و بررسی نحوه خودکار سازی فرایند طراحی معماری با ارائه ابزارهایی برای این منظور میباشد. ادامه مطالب گزارش به این صورت طبقه بندی شده اند. در بخش ۲ توضیح مختصری در ارتباط با معماری نرمافزار و مفاهیم مرتبط با آن ارائه میشود. این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد. در بخش ۳ طراحی معماری نرمافزار، ویژگیهای یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت. در بخش ۴ روشهای طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت. در بخش ۵ خلاصه و نتیجه گیری ارائه خواهد شد. در بخش ۶ مراجع مورد استفاده در این گزارش معرفی میگردد.
معماری نرم افزار چیست ؟
برای معماری نرمافزار، تعریفی که به طور عمومی پذیرفته شده باشد، وجود ندارد. افراد مختلف، معماری نرمافزار را به اشکال گوناگون تعریف کرده‌اند. این تعاریف، از لحاظ ظاهری متفاوتند ولی به مفهوم مشترکی اشاره می‌کنند.
در [Bass 03] معماری نرم افزار به صورت زیر تعریف شده است :
معماری نرم افزار یک برنامه یا سیستم کامپیوتری، ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد.
از تعریف فوق می توان به نتایج زیر دست یافت :
معماری، اجزای نرم افزار را تعریف می نماید. همچنین در این تعریف، از جزئیاتی از اجزا، که در نحوه استفاده و ارتباط با اجزای دیگر کاربردی ندارند؛ صرف نظر می گردد.
هر سیستم نرم افزار شامل چندین ساختار می باشد؛ و هیچ یک از این ساختارها، به تنهایی معماری نرم افزار نمیباشد. بلکه این ساختارها در کنار یکدیگر معماری نرم افزار را تشکیل می دهند.
هر سیستم نرم افزاری دارای یک معماری می باشد. (زیرا هر سیستم نرم افزاری دارای اجزایی است که این اجزا با یکدیگر دارای رابطه می باشند).
رفتار هریک از اجزاء، بخشی از معماری نرم افزار می باشد. (زیرا این رفتار در نحوه ارتباط بین اجزا تاثیرگذار است.)
معماری نرم افزار باید قابل ارزیابی باشد تا بتوان از روی آن تشخیص داد سیستم مورد نظر بر پایه معماری انتخاب شده نیازهای خود را برآورده خواهد کرد یا خیر.
علاوه بر تعاریف ارائه شده در [Bass03] تعاریف گوناگون دیگری نیز برای معماری نرم افزار ارائه شده است که در اینجا به برخی از آنها اشاره خواهیم کرد :
در [IEEE00]معماری نرم افزار به صورت زیر تعریف شده است :
معماری نرمافزار، سازمان زیربنایی سیستم میباشد، که در قالب اجزا و روابط بین آنها و همچنین روابط آنها با محیط، بیان شده است و برای طراحی و تکامل آن اصولی وجود دارد.
در این نوع تعریف، فرایند تولید معماری، عضوی از معماری در نظر گرفته شده است. ( زیرا قوائد و اصول طراحی و تکامل نیز عضوی از معماری در نظر گرفته شده اند.) در حالی که این موارد جزء معماری محسوب نمی‌گردند. معماری هر سیستم نرم‌افزاری می‌تواند بدون توجه به نحوه تولید آن مشخص و ارزیابی گردد.
در [Booch 98] معماری نرم افزار مجموعه‌ای از تصمیمات مهم درباره ساختار سیستم نرم‌افزاری ، انتخاب اجزاء ساختاری و ارتباطات بین آنها و همچنین مشخص نمودن نحوه همکاری این اجزاء با یکدیگر میباشد. وقتی این اجزاء در کنار یکدیگر سیستم بزرگی را تشکیل دهند معماری نرم افزار به وجود خواهد آمد.
در [Garlan 93]، معماری نرمافزار سطحی از طراحی تعریف شده است که دارای ویژگیهای زیر میباشد :
ورای الگوریتم و ساختمان داده طراحی شده باشد.
شامل ساختار کلی سیستم، ساختارهای کنترلی عمده، پروتکل‌های ارتباطی، اختصاص کارکرد‌ها به اجزاء، توزیع فیزیکی اجزاء باشد.
ترکیبی از اجزاء طراحی باشد که از بین گزینه‌های طراحی موجود انتخاب شده است.
در تعاریف ارائه شده توسط [Booch 98] و [Garlan 93]، از معماری به عنوان ساختار کلی سیستم نام برده شده است. باید توجه داشت، ضعف این تعریف نسبت به تعریف ارائه شده توسط [Bass 03] در محدود کردن ساختار سیستم به تنها یک ساختار میباشد. در حالی که سیستم برای مشخص کردن معماری، دارای ساختارهای گوناگون باشد.
در [RUP 03] معماری نرمافزار سازمان یا ساختار اجزاء اصلی سیستم که از طریق واسط‌هایی با هم ارتباط برقرار می‌کنند؛ میباشد به طوری که هر یک از اجزاء از اجزاء کوچکتری تشکیل شده که این اجزاء کوچک نیز با یکدیگر ارتباط دارند. در این تعریف نیز، به ساختارهای گوناگون اشاره نشده است. گرچه در [RUP 03] در مرحله طراحی معماری نرمافزار، ساختارها یا دیدگاه های مختلفی برای معماری معرفی شده است.
دیدگاه ما نسبت به معماری، دیدگاه [Bass 03] میباشد. یکی از نکات مهم در این تعریف، امکان ارائه ساختارهای گوناگون برای معماری میباشد. این ساختارها نباید محدود به چندین ساختار پیش فرض باشند. به عنوان مثال برای تولید معماری یک سیستم امن، میتوان مدل امنیتی سیستم را نیز عضو معماری قرار داد. زیر بررسی و ارزیابی آن قبل از مرحله پیاده سازی بسیار حیاتی میباشد.
تعاریف پایه در معماری نرم افزار
در این بخش به بررسی برخی از مفاهیم پایه در معماری نرم افزار خواهیم پرداخت. در بخش های بعدی از این مفاهیم پایه استفاده زیادی خواهد شد.
الگوهای معماری یا سبکهای معماری
الگوهای معماری[۲] یا سبک های معماری[۳] شامل شرحی از اجزاء و نوع روابط بین آنها می باشد به نحوی که تعدادی قانون برای معرفی اجزاء و نحوه ارتباط بین آنها، مشخص گردد. [Bass 03]
به عنوان مثال client-server یک الگوی معماری است که مشخص می کند سیستم دارای دو جزء می باشد و این دو جزء تحت پروتکل خاصی با یکدیگر ارتباط دارند.
هر الگوی معماری در برگیرنده تعدادی معیار کیفی[۴] می باشد و معمار نرم افزار بر اساس نیازهای کیفیتی مورد نظر، الگوی معماری مناسب را انتخاب می نماید.
در بسیاری از موارد از سبکهای معماری، به جای الگوهای معماری استفاده می گردد.
از دیدگاه ما الگوهای طراحی باید بتوانند یک یا چند نیاز کیفی را برآورده نمایند. زیرا درصورتی که تنها کارکرد مد نظر باشد بدون استفاده از الگوی خاصی میتوان به آن دست یافت.
مدل مرجع[۵]
مدل مرجع، تقسیم بندی و تجزیه کارکردهای مختلف یک سیستم به همراه جریان داده های بین هریک از بخش‌ها می باشد. در حقیقت مدل مرجع، تقسیم بندی یک مسئله مشخص به اجزاء میباشد به گونه ای که این اجزا توانایی حل مسئله را داشته باشند. به عنوان مثال، مدل مرجع برای یک نرم افزار سیستم عامل، شامل بخش‌هایی نظیر : مدیریت حافظه، مدیریت دیسک، مدیریت فعالیت‌ها و … میباشد.
معماری مرجع[۶]
معماری مرجع، مدل مرجعی می باشد که به اجزای نرم افزاری نگاشت شده است. در حقیقت در معماری مرجع، جایگاه هریک از کردهای سیستم در قالب اجزای نرم افزاری تشکیل دهنده سیستم مشخص شده است. هر جزء نرم افزار در این مدل ممکن است قسمتی از یک کارکرد یا چندین کارکرد را پیاده سازی نماید. به عنوان مثال برای یک سیستم‌عامل، مدیریت حافظه توسط جزء هسته انجام شود. مدیریت دیسک توسط جزء مدیر دیسک و هسته انجام شود و …
ارتباط بین الگوهای معماری، مدل مرجع و معماری مرجع در شکل ۱ نمایش داده شده است.
دیدگاه های معماری
سیستم های مدرن و امروزی به اندازه ای پیچیده هستند که یه ساختار و دیدگاه واحد، توانایی نمایش همه جنبه های آنها را ندارد.[Bass 03] بنابراین برای نمایش معماری یک سیستم نرم افزاری از دیدگاه های مختلف استفاده می کنیم. یک ساختار یا دیدگاه معماری، نمایش مجموعه ای از اجزای معماری مرتبط با یکدیگر و ارتباط بین این اجزا می باشد.
دیدگاه Bass
بر اساس طبقه بندی ارائه شده در [Bass 03] ساختارهای معماری نرم افزار قابل دسته بندی از سه گروه عمده به شرح زیر می باشند:
ساختار ماژول‌ها
در این ساختار، اجزاء تشکیل دهنده ماژول ها هستند. ماژول، یک واحد پیاده سازی شده از سیستم میباشد. ساختار ماژول‌ها نمایشی مبتنی بر کد از سیستم می باشد. هر ماژول شامل طیفی از وظایف میباشد. در ساختار ماژول‌ها، بیشترین تاکید بر نحوه پخش شدن وظایف مختلف بر روی ماژول‌ها و نحوه ارتباط ماژول‌ها با یکدیگر است. در این ساختار تاکید خاصی روی ساختارهای اجرایی نمی‌شود.
ساختار اجزاء و رابط‌ها
در این دیدگاه، اجزاء تشکیل دهنده واحد‌های در حال اجرا می باشند(واحد‌های محاسباتی). همچنین رابط‌ها نحوه ارتباط و گفتگوی بین اجزاء را نشان خواهند داد. این ساختار مشخص کننده اجزای مهم اجرایی و نحوه ارتباط آنها با یکدیگر است. همچنین این ساختار مواردی نظیر : مهمترین محل‌های ذخیره اطلاعات، نحوه تکرار داده‌ها، اجزایی که به طور موازی اجرا می‌گردند، میباشد.
ساختار تخصیص منابع
این ساختار ارتباط بین اجزاء نرم افزاری و اجزائی که در محیط خارجی تولید و استقرار نرم افزار وجود دارند را نشان می دهد. این ساختار، نحوه استقرار اجزاء برنامه روی پردازنده‌ها، فایلهای مربوط به هریک از بخشهای برنامه نرم‌افزاری در طول پیاده‌سازی، اجرا و تست و نحوه اختصاص وظایف پیاده‌سازی به تیم را مشخص می‌نماید.
در این دیدگاه، از ابزار UML استفاده نشده ولی از لحاظ مفهومی قابلیت پیاده سازی با استفاده از UML وجود دارد.
دیدگاه ۴+۱
این دیدگاه در [Kruchten 95] ارائه شده و امروزه به عنوان استاندارد در IEEE 1471 [IEEE 00] مطرح میباشد. در این دیدگاه، ساختارهای معماری به صورت زیر طبقه بندی شده اند :
Logical View
Process View
Deployment View
Implementation View
Use-case View
همچنین این دیدگاه در [RUP 03] نیز به عنوان استاندارد توسعه معماری نرم افزار معرفی گردیده است. پایه این دیدگاه متدولوژی شیء گرا و ابزار استفاده از آن UML می باشد. برای استفاده بهینه از این دیدگاه پیشنهاد می شود که مدل فرایند انتخابی به صورت تکراری و بر پایه RUP انتخاب گردد.
دیدگاه‌های دیگر
از دیگر دیدگاه هایی که در [Garland 03] معرفی گردیده شده می توان به :
دیدگاه RM-ODP (استاندارد ISO )
دیدگاه Hofmeister
اشاره نمود. برای جزئیات بیشتر به [Garland 03] مراجعه شود.
طراحی معماری نرم افزار
در این بخش به بررسی عوامل تاثیر گذار بر معماری نرمافزار و نحوه تولید معماری خواهیم پرداخت. با توجه به تعاریف انجام شده، معماری نرمافزار هر سیستم، پس از به دست آوردن نیازهای آن سیستم باید تولید شود. بنابراین در طراحی یک معماری، باید به دو عامل توجه داشت :
نیازهای کارکردی سیستم
ویژگیهای کیفی
بنابراین معماری باید به گونه ای طراحی شود که عوامل فوق را پوشش دهد. در ادامه هریک از دو ویژگی فوق را تعریف کرده و نقش آن را در طراحی معماری مورد بررسی قرار خواهیم داد.
کارکردهای سیستم و معماری نرمافزار
کارکردهای سیستم، توانایی‌های سیستم در انجام کارهای مختلف میباشد[Bass 03]. برای دستیابی به کارکردهای مورد نظر در یک سیستم نرم افزاری میتوان از ساختارهای گوناگون استفاده نمود. به بیانی دیگر در صورتی که در تولید نرم افزار تنها کارکرد مورد نظر می بود؛ امکان تولید نرم افزار در قالب یک واحد یکپارچه و مستقل امکان پذیر بود. اما معمولاً کارکرد، تنها نیاز نرم افزار نمی باشد. بنابراین برای برآورده کردن نیازهای دیگر که شامل نیازهای غیرکارکردی و کیفی میباشند؛ باید از ساختارهای خاصی در تولید نرم افزار استفاده نمود. به عنوان مثال، هنگامی که یک سیستم را مبتنی بر ماژول‌های مختلف پیاده سازی می‌کنیم، هدف دستیابی به کارکردی خاص نمیباشد. زیران کارکرد‌ها در قالب یک ماژول یکتا نیز قابل دستیابی است. هدف ما از پیاده سازی سیستم مبتنی بر ماژول‌ها دستیابی به تعداد ویژگی کیفی در نرمافزار میباشد.
همانطور که در بخشهای قبلی اشاره گردید، معماری نرمافزار شامل ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد. هدف از بیان سیستم نرم افزاری در قالب ساختارهای گوناگون که با هم دارای رابطه هستند، برآورده کردن نیازهای کیفی مورد نظر در سیستم نرمافزار میباشد.
ویژگیهای کیفی
ویژگیهای کیفی، نیاز‌هایی از سیستم هستند که جنبه غیر کارکردی دارند(نیازهای غیر کارکردی). این نیاز‌ها در مراحل طراحی، پیاده سازی و استقرار سیستم باید مد نظر قرار گیرند[Bass 03]. در حقیقت، برآورده کردن این ویژگیهای کیفی، مستلزم توجه به آنها در مرحله طراحی، پیاده سازی و استقرار است. به عنوان مثال ویژگی کیفی قابلیت استفاده دارای جنبه‌های گوناگون است. استفاده از دکمه‌ها و نحوه چینش اجزاء تشکیل دهنده واسط کاربر، فعالیتی مربوط به پیاده سازی محسوب میگردد. در حالی که قابلیت بازگرداندن تغییرات انجام شده، یا فراهم آوردن امکان Cancel کردن فعالیت‌های نرم افزار توسط کاربر از جنبه‌های مربوط به معماری این ویژگی کیفی محسوب میگردد. با توجه به مطالب مطرح شده دو نکته مهم در زمینه ارتباط ویژگیهای کیفی و معماری وجود دارد :
معماری نرمافزار یکی از اجزای حیاتی فرایند تولید نرمافزار برای برآورده نمودن ویژگیهای کیفی میباشد. معماری باید قابلیت بیان مهمترین ویژگیهای کیفی نرمافزار را داشته باشد و امکان ارزیابی آنها را در سطح معماری فراهم سازد.
معماری نرمافزار به تنهایی قادر به برآورده ساختن نیازهای کیفی نمیباشد، بلکه به عنوان بستری برای قرار دادن کیفیت در سیستم نرمافزار به کار می‌رود. ویژگیهای کیفی پس از معرفی در معماری نرمافزار، در مراحل بعدی توسعه نیز باید مد نظر قرار گیرند.
باید توجه داشت که برآورده ساختن یک نیاز کیفی، بر روی دیگر نیازهای کیفی اثرگذار است. به عنوان مثال، سیستم‌ای که دارای ویژگی کیفی امنیت میباشد، معمولاً دارای ویژگی قابلیت اطمینان نیز است. یا برای مثال سیستمی که دارای کارایی مناسبی میباشد، قابلیت تغییر پایین‌تری میباشد. در [With 02] ارتباط بین ویژگیهای کیفی گوناگون بیان شده است.
معیارهای کیفی را میتوان به دسته‌های گوناگون طبقه بندی نمود. در [Bass 03] معیارهای کیفی که در توسعه معماری نرم افزار تاثیر گذاراند در سه دسته زیر طبقه بندی شده اند :
کیفیت سیستم ( availability، modifiability، performance، security، testability و usability )
معیارهای کیفی کسب و کار ( زمان تحویل به بازار و … )
معیارهای کیفی نظیر یکپارچگی منطقی معماری که مستقیماً متوجه خود معماری میباشد و به طور غیر مستقیم بر روی کیفیت سیستم تاثیرگذار است.
همچنین در [Garland 03] معیارهایی علاوه بر معیارهای فوق ارائه گردیده است :
قابلیت انطباق با فرهنگ‌های مختلف
یکپارچگی داده ای
قابلیت نگهداری بالا
قابلیت سلامت ( Safety )
قابلیت مدیریت
در [With 02] فهرست کاملی از ویژگیهای کیفی گوناگون ارائه شده است.
معیارهای کیفی مورد توجه ما، معیارهای کیفی سیستم میباشد. زیرا در این گزارش، هدف طراحی معماری نرمافزار بوده و برای آن معماری سیستم باید مورد ارزیابی قرار گیرد.
ویژگیهای کیفی سیستم
[۱] Architecture Centric
[۲] Architectural Patterns
[۳] Architectural Styles
[۴] Quality Attribute
[۵] Reference Model
[۶] Reference Architecture
جهت دریافت و خرید متن کامل مقاله و تحقیق و پایان نامه مربوطه بر روی گزینه خرید انتهای هر تحقیق و پروژه کلیک نمائید و پس از وارد نمودن مشخصات خود به درگاه بانک متصل شده که از طریق کلیه کارت های عضو شتاب قادر به پرداخت می باشید و بلافاصله بعد از پرداخت آنلاین به صورت خودکار لینک دنلود مقاله و پایان نامه مربوطه فعال گردیده که قادر به دنلود فایل کامل آن می باشد .
