تحقیق معماری نرم افزار


دنلود مقاله و پروژه و پایان نامه دانشجوئی

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

 فهرست

چکیده    ۱
فصل اول
معرفی موضوع تحقیق
۱-۱- مقدمه   ۳
۱-۲- طرح مسئله   ۵
۱-۳- تمرکز تحقیق    ۶
۱-۴-  فعالیت های مرتبط    ۷
۱-۵- ساختار تحقیق   ۸
فصل دوم
آشنایی با ادبیات تحقیق
۲-۱- معماری   ۱۱
۲-۱-۱- معماری نرم افزار    ۱۲
۲-۱-۲-مراحل فرآیند معماری نرم افزار   ۱۵
۲-۱-۳- اهمیت معماری نرم افزار   ۱۷
۲-۲- تصمیمات معماری   ۱۸
۲-۳- ویژگیهای کیفی در معماری نرم افزار    ۲۰
۲-۳-۱ -انواع ویژگیهای کیفی در معماری نرم افزار   ۲۲
۲-۳- ۱-۱- صفات کیفیتی سیستمی   ۲۲
۲-۳-۱-۲- صفات کیفیتی تجاری   ۳۰
۲-۳-۱-۳-  صفات کیفیتی وابسته  به معماری   ۳۱
۲-۳-۲- ویژگی های کیفی معماری نرم افزار از نگاهی دیگر   ۳۲
۲-۳-۳- مدل های کیفیت    ۳۳
۲-۳ -۴-وجود مصالحه میان ویژگیهای کیفی   ۳۶
۲-۴- ارزیابی و تحلیل معماری   ۳۷
۲-۵- دلایل ارزیابی معماری نرم افزار   ۴۰
۲-۶- نتیجه گیری      ۴۳
فصل سوم
مروری بر روش¬های تصمیم¬گیری
۳-۱- فرآیند تصمیم گیری    ۴۵
۳-۲- یک معیار در مقابل چند معیار، تعداد پایان¬پذیری گزینه در مقابل تعداد بی¬پایان گزینه    ۴۸
۳-۳-  توابع تصمیم¬گیری بر مبنای چندویژگی   ۴۹
۳-۳-۱- تحلیل سود و هزینه    ۵۰
۳-۳-۲- روش های ابتدایی    ۵۱
۳-۳-۲-۱- تحلیل موافقان و مخالفان    ۵۱
۳-۳-۲-۲- روش¬های بیش¬کم و بیش¬بیش   ۵۱
۳-۳-۲-۳- روش¬های ربطی و گسسته   ۵۱
۳-۳-۲-۴- روش واژه¬نگاری   ۵۲
۳-۳-۳- روش هایMAUT    ۵۲
۳-۳-۳-۱- شیوه ساده رتبه¬بندی بر مبنای چندویژگی   ۵۲
۳-۳-۳-۲- میانگین¬های کلی   ۵۳
۳-۳-۳-۳- فرایند سلسله مراتبی تحلیلی   ۵۴
۳-۳-۴- روش های برتری داشتن   ۵۶
۳-۳-۴-۱- روشELECTERE   ¬۵۶
۳-۳-۴-۲- روشPROMETHE   ¬۵۷
۳-۳-۵- تصمیم گیری گروهی   ۵۹
۳-۴ نتیجه گیری   ۶۱
فصل چهارم
ارائه روشی جهت انتخاب معماری نرم افزار مناسب از میان معماری های کاندید بر اساس مصالحه بین ویژگی های کیفی
۴-۱- روش پیشنهادی    ۶۶
۴-۲- مراحل روش پیشنهادی   ۶۸
۴-۲-۱- شناسایی تصمیمات طراحی و نیازهای کیفی   ۷۰
۴-۲-۲- شناسایی کاندیدهای مختلف برای هر تصمیم طراحی   ۷۰
۴-۲-۳- مقایسه نسبی کاندیدهای مختلف در تأمین هر یک از ویژگیهای کیفی برای هر تصمیم
طراحی    ۷۱
۴-۲-۴- مقایسه نسبی ویژگیهای کیفی از لحاظ تأمین شدن هر یک از کاندیدها برای هر تصمیم
طراحی   ۷۳
۴-۲-۵- تعدیل ماتریس QA توسط ماتریس AC برای هر تصیم طراحی   ۷۴
۴-۲-۶- الویت دهی به نیازهای کیفی    ۷۷
۴-۲-۷- اعمال اولویت نیازهای کیفی   ۷۸
۴-۲-۸- محاسبه عدم اطمینان    ۷۸
۴-۲-۹- نرمالسازی   ۷۹
۴-۲-۱۰- انتخاب کاندید مناسب   ۷۹
۴-۳- نتیجه گیری   ۸۰
۱-۳-۴- منافع و محدودیت های بدست آمده   ۸۰
فصل پنجم
مطالعه موردی
۵-۱- پروژه Glass Box    ۸۳
۵-۲-  تحلیل و بررسی مساله موردی   ۸۵
۵-۳- به کار گیری روش پیشنهادی   ۸۷
۵-۳-۱- مرحله ۱و۲    ۸۷
۵-۳-۲- مرحله ۳    ۸۸
۵-۳-۳- مرحله۴    ۸۹
۵-۳-۴- مرحله ۵: تعدیل ماتریس QA توسط ماتریس AC برای هر تصمیم طراحی   ۹۰
۵-۳-۴-۱- تعدیل ماتریس QA مربوط به تصمیم طراحی ARCH   ۹۰
۵-۳-۴-۲- تعدیل ماتریس QA مربوط به تصمیم طراحی EVNT   ۹۳
۵-۳-۴-۳- تعدیل ماتریس QA مربوط به تصمیم طراحی AUHT   ۹۴
۵-۳-۵- مرحله ۶و۷ : الویت دهی به نیازهای کیفی و اعمال اولویت بر QAO   ۹۵
۵-۳-۶- مرحله ۸: تخمین عدم اطمینان   ۹۶
۵-۳-۷- مرحله ۹: نرمالسازی   ۹۸
۵-۳-۸- مرحله ۱۰: انتخاب کاندید مناسب   ۹۸
۵-۴- نتیجه گیری   ۹۹
فصل ششم
نتیجه گیری و کارهای آینده
۶-۱ مروری بر تحقیق   ۱۰۱
۶-۲ دسته بندی روش های متداول در ارزیابی ویژگی های کیفی از لحاظ زمان ارزیابی   ۱۰۲
۶-۳ جایگاه روش ارائه شده در تحقیق   ۱۰۳
۶-۴ کارهای آینده   ۱۰۶
فهرست منابع و مراجع   ۱۰۸

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

[۱]     L. Bass, P. Clements, and R. Kazman, “Software Architecture in Practice”, ۲ ed: Addison-Wesley, 2003.

[2]     M. Lindvall, R.T. Tvedt, P. Costa, “An Empirically-BasedProcess for Software Architecture Evaluation”, in Empirical Software Engineering, 8(1), p.83-108, 2003.

[3]     J.A McCall, “Quality factors”,in Encyclopedia of Software Engineering, J.I. Marciniak (ed),John Wiley &Sons,New York, P. 958-969,1994.

[4]     C. Hofmeister, R. Nord, D. Soni, “Applied Software Architecture”, Addison-Wesley, Reading MA., 2000.

[5]     I. Jacobson, G. Booch, J. Rumbaugh, “The Unified Software Development Process”, Addison-Wesley, Reading MA, 1999.

[6]     J. Bosch, “Design & Use of Software Architectures – Adoptingand Evolving a Product Line Approach“, Addison-Wesley, Harlow UK, 2000.

[7]     L. Lundberg, et al. “Quality Attributes in Software Architecture Design”, Proceedings of the IASTED 3rd International Conference on Software Engineering andApplications. Oct, 1999.

[8]     S.M.Sharafi,” Extending Team Automata to Evaluate Software Architectural Design”. COMPSAC,  p. 393-400, (2008).

[9]     PO.Bengtsson, “Architecture-Level Modifiability Analysis”, ISBN 91-7295-007-2, Blekinge Institute of Technology, Dissertation SeriesNo2002-2, 2002.

[10] M. Svahnberg, C. Wholin, and L. Lundberg, “A Quality-Driven Decision-Support Method for Identifying Software Architecture Candidates”, Int. Journal of Software Engineeringand Knowledge Engineering. 13(5),  p. 547-573, , 2003.

[11] T.Al-Neem, I.Gorton, M.A.Babar, F.Rabhi and B.Benatalah, “A quality-driven Systematic Approach for Architecting Distributed SoftwareApplications”, In Proceedings of the 27th International Conference on Software Engineering (ICSE), st.louis, USA,( 2005).

[12] L.Dobrica, E. Niemela, “A Survey on software architecture analysis methods ”, IEEE Transaction on software engineering, Vol 28,NO-7,July 2002.

[13] D.E. Perry and A.L. Wolf, “How Do You Define Software Architecture”, Software Engineering Institute (SEI), Carnegie Mellon University, 1989.

[14] D.Garlan, M.Shaw, “An Introduction to Software Architecture”, Technical Report, CMU/SEI-94-TR-21, 1994.

[15] Technical Report IEEE, “Recommended Practice for Architectural Description of Software Intensive Systems”, IEEE Standards Department, The Architecture Working Group of the Software EngineeringCommittee, P1471-2000, September 2000.

[16] J.McGovern, SW.Ambler, ME.Stevens, J.Linn, V.Sharan, EK.Jo, “A Practical Guide to Enterprise Architecture”, Prentice Hall PTR , October 28, 2003.

[17] Frederick , Brooks,  “The Mythical Man-Month: Essays on Software Engineering: Anniversary Edition”, Addison-Wesley, ISBN ۰-۲۰۱-۸۳۵۹۵-۹,  A republication of The Mythical Man-Month with four extra chapters, 1995.

[18]  H.Astudillo, “Five Ontological Levels to Describe and Evaluate Software Architecture”, Department de Informatics, Universidad Technical Federico Santa Maria Avda.España 1680, Valparaiso, Chile, 2004.

[19]  S.Thiel, “A Framework to Improve the Architecture Quality of Software-Intensive Systems”, ۲۰۰۵٫

[۲۰]  R.Harris, “Introduction to Decision Making”, VirtualSalt, 1998.

[21]  D.Baker, D.Bridges, R.Hunter, G.Johnson, J.Krupa, J.Murphy and K.Sorenson, “Guidebook to Decision-Making Methods”, WSRC-IM-2002-00002, Department of Energy, USA, 2002.

[22] UK DTLR, “Multi Criteria Analysis: A Manual”, Department for Transport, Local Government and the Regions, UK, 2001.

[23] RL.Keeney and H.Raiffa, “Decisions with Multiple Objectives” Performances and Value Trade-Offs, Wiley,New York, 1976.

[24] R.E.Steuer, “Multiple Criteria Optimization” Theory, Computation and Application, Wiley, New York, 1986.

[25] B.Roy, “Classement et choix en présence de points de vue multiple (la méthode electre)”, RAIRO, 2, p.57-75, 1968.

[26] I.Linkov, A.Varghese, S.Jamil,T.P.Seager, G.Kiker and T.Bridges, “Multi-criteria decision analysis: A framework for structuring remedial decisions at the contaminated sites”, In: Linkov, I. and Ramadan, A.B. (Eds.) Comparative Risk Assessment and Environmental Decision Making, Springer, New York, p. 15-54,  ۲۰۰۴٫

[۲۷] W.Edwards, “How to use multiattribute utility measurement for social decisionmaking”, IEEE Transactions on Systems, Man, and Cybernetics, SMC-7, p.  ۳۲۶-۳۴۰,  ۱۹۷۷٫

[۲۸] Cs. Mészáros and T. Rapcsák, “On sensitivity analysis for a class of decision systems”, Decision Support Systems 16, p.231-240, 1996.

[29] T. L. Saaty, “The Analytic Hierarchy Process”, McGraw Hill, Inc., New York NY, 1980.

[30] T.L. Saaty and L.G.Vargas, Comparison of eigenvalue, logarithmic least squares and least squares methods in estimating ratios., Mathematical Modelling, 5, p. 309-324, 1984.

[31] J.Figueira, S.Greco and M.Ehrgott, (Eds), “Multiple Criteria Decision Analysis” State of the Art Surveys, Springer, New York,  ۲۰۰۴٫

[۳۲] J.P. Brans and Ph.Vincke, “A preference ranking organization method”, Management Science, 31,p. 647-656, 1985.

[33] J.P.Brans, Ph.Vincke and B.Marechal, “How to select and how to rank projects: The PROMETHEEmethod”, European Journal of Operational Research, 24, p.228- 238, 1986.

[34] J.P.Brans and B.Mareschal, “The PROMCALC & GAIA decision support system for multicriteria decision aid”, Decision Support Systems, 12, p.297-310, 1994.

[35] P.Csáki, T.Rapcsák, P.Turchányi  and M.Vermes, “Research and development for group decision aid in Hungary by WINGDSS”, a Microsoft Windows based group decision support system., Decision Support Systems 14,p.  ۲۰۵-۲۱, ۱۹۹۵٫

[۳۶] R.F.Dyer and E.H.Forman, “Group decision support with the Analytic Hierarchy Process”, Decision Support Systems, 8, p. 99-124, 1992.

[37] V.S.Lai, K.W.Bo and W.Cheung, “Group decision making in a multiple criteria environment: A case using the AHP in software selection”., European Journal of Operational Research, 137, p. 134-144, 2002.

[38] C.Macharis, J.P.  Brans, and B. Mareschal, “The GDSS PROMETHEE Procedure”, Journal of Decision Systems, 7, p.283-307, 1998.

[39] T.A. Al-Naeem, et al., “Towards Systemtic Approaches for Designing B2B Applications”, International Journal of Electronic Commerce, Accepted to appear in 2004.

[40] K.P. Yoon and C. Hwang, “Multiple Attribute Decision Making: An Introduction: Sage Publications”, ۱۹۹۵٫

[۴۱] I. Gorton and J. Haack, “Architecting in the Face of Uncertainty: An Experience Report”, Proc. International Conference on Software Engineering,. Edinburgh, Scotland, 2004.

[42] سید مهران شرفی ، “ارائه روشی جهت استخراج و ارزیابی ویژگی های غیر وظیفه مندی مبتی بر توصیفات رسمی معماری نرم افزار”،پایان نامه دکتری ، دانشگاه آزاد اسلامی واحد علوم تحقیقات، ۱۳۸۶٫

[۴۳] وفایی جهان مجید ،فریدون شمس،سعید ستایش”روش احتمالی سنجش ارزش تصمیم های معماری برای ارزیابی معماری نرم افزار”،دوازدهمین کنفرانس بین المللی انجمن کامپیوتر ایران۱۳۸۵٫

[۴۴] مربم پور کمالی انارکی، “بهبود روش های ارزیابی صفات کیفتی معماری نرم افزار”، پایان نامه کارشناسی ارشد، دانشگاه آزاد اسلامی واحد علوم تحقیقات، ۱۳۸۴٫

۲-۱) معماری

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

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

 به طور کلی یک معماری خوب بایستی ویژگی های زیر را دارا باشد[۱] :

۱-     مستندات معماری روشن و قابل فهم باشد.

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

۳-     قابلیت تغییر بالایی داشته باشد.

۴-     نیازهای تمام سهامداران را تا حد امکان برآورد سازد.

۲-۱-۱) معماری نرم افزار

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

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

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

۱)      پری و ولف در سال ۱۹۹۲ معماری نرم افزاری را به این صورت تعریف کرده اند:[۱۳]

            معماری نرم افزار مجموعه ای از اجزاء معماری )طراحی( است که شکل خاصی دارند. این اجزاء معماری               ۳ دسته اند: پردازشی، داده ای و اتصالی.

 ۲)      شاو و گارلن در سال ۱۹۹۴ اجزاء معماری نرم افزار به صورت مفهومی به موارد ذیل طبقه بندی کردند[۱۴]:

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

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

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

۳)      بیس و همکاران در سال ۱۹۹۸ معماری را به صورت زیر تعریف کرده است[۱] :

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

۴)      جکبسون و همکاران در سال ۱۹۹۹ چنین تعریفی از معماری ارائه کردند[۵]:

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

۵)      IEEEدر سال ۲۰۰۰ از معماری نرم افزار چنین تعریفی ارائه نموده است :[۱۵]

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

۶)      امسی گاورن و همکاران در سال ۲۰۰۳ معماری نرم افزار را اینگونه معرفی می کند[۱۶]:

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

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

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

  معماری نرم افزار از عوامل متعددی تاثیر می پذیرد که در زیر ذکر شده است[۱] :

۱-     معماری از ذینفعان[۴] تاثیر می پذیرند  (مشتریان ، استفاده کننده گان نهایی ، توسعه دهندگان ، مدیر پروژه ، نگهدارندگان و…)

۲-     معماری از سازمانهای توسعه دهنده تاثیر می پزیرند.

۳-     معماری از تجارب معمار اثر می گیرند.

۴-     معماری از محیط تکنیکی اثر می پذیرند.

قابل ذکر است که معماری بر عواملی که از آنها تاثیر می پذیرد ، تاثیر می گذارد.

   یکی از مراحل فرایند در تولید سیستم های نرم افزاری ، معماری نرم افزار می باشد. اما نمی توان به صورت دقیق و قطعی مشخص کرد که این مرحله در کدام نقطه از این فرایند قرار دارد اما در حالت کلی معماری بعد از فاز تحلیل و قبل از طراحی می باشد و برای ساخت معماری نرم افزار یک سیستم باید آن را به زیر سیستم ها و واسط های آن ها و ارتباط بین آنها تجزیه کرد. در شکل۲-۱ فازهای فرایند تولید نرم افزار نشان داده شده است [۱].

   همانطور که در شکل ۱-۲ مشخص می باشد فاز معماری در مرکز فرآیند تولید نرم افزار قرار دارد و با پیشرفت فرایند ، در تکرار های مختلف ، نسخه های مختلفی از معماری ایجاد خواهد شد که هرنسخه جدید از نسخه قبلی خود کاملتر و دقیق تر خواهد بود.

    همانطور که در شکل می توان مشاهده کرد برای رسیدن به معماری مطلوب آگاهی از نیازها امری لازم و ضروری است و پس از امکان سنجی و تحلیل نیازها می توان وارد مرحله تولید معماری شد.

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

۲-۱-۲)  مراحل فرایند معماری نرم افزار

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

الف) ایجاد یک مورد کاری[۵] برای سیستم

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

۱-     هزینه محصول باید چقدر باشد ؟

۲-     هدف تجارت چیست ؟

۳-     آیا محدودیتی برای کار با سیستم وجود دارد ؟

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

ب) یافتن و فهم نیازمندی ها

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

   تکنیک دیگری که به ما کمک می کند که نیازها را پیدا کنیم ساختن یک مدل نمونه اولیه[۷]  می باشد ، مدل نمونه اول به مدل کردن ، طراحی واسطه کاربر و تحلیل بهره روی منابع کمک می کند. این روش کمک می کند که بتوانیم سیستم را برای سهامداران واقعی جلوه دهیم و به سرعت در مورد طراحی واسطه کاربر تصمیم بگیریم. علاوه بر فهم نیازمندیها ، ویژگی های کیفی مطلوب شکل معماری را تحت تاثیر قرار می دهد ، این ویژگی ها گاهی با هم در تضاد می باشند و بایستی یک معماری ارائه داده شود که بین این ویژگی ها مصالحه برقرار کند.

ج) ساختن یا انتخاب معماری

   در کتاب Fred brooks,mythical man-month به طور واضح راجع به این موضوع بحث می کند که جامعیت معنای و جامعه نگری واژه کلیدی برای طراحی است و آن جامعیت تنها زمانی رخ می دهد که چند فکر برای طراحی معماری سیستم دور هم جمع شود ، یعنی چند معمار با هم در مورد طراحی معماری آن سیستم هم فکری کنند [۱۷].

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

د) نمایش و اعلام معماری

   یک معماری برا ی اینکه بتواند ستون یک طرح و پروژه باشد باید به طور واضح و روشن به همه سهامداران معرفی شود. توسعه دهندگان باید بخشی از کار را که به آن نیز دارند درک کنند ، تست کننده گان باید ساختار کاری که بر عهده گرفته اند را بفهمند و مدیران باید برنامه پیشنهادی برای کار خود را پیدا کنند و در پایان مستند سازی معماری باید آموزنده و روشن وخوانا باشد معمار نیز باید مطمئن باشد که معماری ارائه شونده نیازمندیهای کیفی و رفتاری مطلوب را برآورده می سازد. معماری را می توان به کمک زبان توصیف معماری[۸] نمایش داد.

ه) تحلیل و ارزیابی معماری

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

و)  پیاده سازی سیستم بر اساس معماری

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

ز) حصول اطمینان از تطبیق پیاده سازی با معماری

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

۲-۱-۳) اهمیت معماری نرم افزار

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

الف) ارتباط میان سهامداران

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

 ب) تصمیمات زود هنگام طراحی

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

 ج) قابلیت استفاده مجدد در معماری

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

۲-۲) تصمیمات معماری

   یکی از مسولیت ها معماری اتخاذ تصمیمات معماری است. به وسیله تصمیمات معماری ، معماری سیستم های نرم افزاری آشکار وروشن می شود. تصمیمات معماری ، تصمیماتی هستند که از دیدگاه کلی سیستم اتخاذ می شوند و دامنه وسیعی را در بر دارند ، هر تصمیمی که در محدوده کوچکی گرفته شود معماری نیست بنابراین سطح تصمیمات معماری با تصمیمات طراحی جزئی و پیاده سازی متفاوت است و در سطح بالاتری از تجربه رخ می دهد. در واقع تصمیمات معماری در برگیرنده ویژگی های کلیدی کلان و سطح بالای یک معماری می باشد. این تصمیمات عناصر ساختاری و کلیدی سیستم و همچنین صفات قابل روئیت آنها از خارج و روابط بین آنها را شناسایی می کند. همچنین تعریف می کنند که چگونه نیازمندیهای مهم وابسته به معماری به دست خواهند آمد. جدول ۲-۱ تصمیمات را بر اساس وسعت تاثیر آنها طبقه بندی می کند[۴۴].

تقسیم بندی از نظر وسعت :

   بخشی از تصمیمات در سطح تک تک مولفه هامی باشد و این تصمیمات مربوط به مولفه های محلی[۹] می باشد که در محدوده ی کوچکی ساخته می شود و یا از یک منظر محلی ساخته می شود این تصمیمات معماری نیستند ولی بخشی از تصمیمات در سطح کل مولفه ها یا به عبارتی در سطح کل سیستم می باشند[۱۰]. که در محدوده وسیعی ساخته می شوند که این تصمیمات معماری هستند مانند انتخاب سبک ، انتخاب صفات کیفی و…

تقسیم بندی از نظر اثر بخشی :

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

    طبق تقسیم بندی که در بالا ذکر شد می توان تصمیمات را به طور کلی در چهار گروه قرار داد:

۱-تصمیماتی که در سطح مولفه  می باشند و اهمیت تاثیر کم دارند که جزء تصمیمات معماری نمی باشند.

۲-تصمیماتی که در سطح کل سیستم می باشند ولی اهمیت کم دارند که جزء تصمیمات معماری نمی باشند.

۳-تصمیمات محلی که اثرات زیاد روی سیستم دارند که جزء تصمیمات معماری نمی باشند ولی به عنوان مجموعه خطوط راهنما در معماری به حساب می آیند.

۴-تصمیماتی که در محدوده وسیعی ساخته می شوند و در سطح کل سیستم می باشند و تاثیر زیادی روی سیستم دارند که جزء تصمیمات معماری می باشند. این گروه از تصمیمات تاثیر مهم و اساسی در سیستم دارند.

 تصمیمات معماری روی جنبه های مختلف که برخی ازآنها در زیر ذکر شده است اثر گذار است:

۱-     مشخص نمودن اولویت ها در سیستم  : طبق تصمیمات معماری مشخص می شود که کدام ویژگی کیفی و کدام سبک و کدام الگو و کدام از اولویت بالاتری نسبت به یکدیگر برخوردارند. و اگر بین آنها برخورد[۱۱] باشد بین آنها مصالحه بر قرار می شود و بهترین حالت انتخاب می شود.

۲-     تجزیه وترکیب سیستم :برای غلبه بر پیچیدگی های سیستم در حال تولید که این پیچیدگی ها توسط تصمیمات معماری مشخص شده است باید سیستم به اجزای کوچکتر تجزیه شود که این اجزاء همان مولفه ها می باشند سیستم بایستی به نحوی به مولفه ها تجزیه شود که هر مولفه به مولفه دیگر وابستگی نداشته باشد و ساختار داخلی هر مولفه مستقل از ساختار داخلی مولفه دیگر باشد مولفه ها می توانند از نتیجه مولفه دیگر استفاده نمایند و سپس با ترکیب این مولفه ها سیستم تولید می شود.

۳-     ویژگی های سیستم و راههای میانبر : زمانی که تصمیمات معماری اتخاذ می شود ویژگی های سیستم مشخص خواهد شد. در ضمن اخذ این تصمیمات باید سعی شود تصمیماتی که سریع تر ما را به سیستم مطلوب می رساند انتخاب شود.

۴-     جامعیت سیستم :تصمیمات معماری اگر به گونه ای باشند که مولفه های سیستم به صورت یک پارچه و هماهنگ باشند به جامعیت سیستم کمک می کند.

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

۲-۳) ویژگی های کیفی در معماری نرم افزار

   امروزه سیستم های کامپیوتری در بسیاری از برنامه های کاربردی مورد استفاده قرار می گیرند که باجان و مال انسانها سرو کار دارند ، بنابراین وقوع کوچکترین خطا حین کار در این سیستم ها ممکن است جان و مال بسیاری از انسانها را به خطر بیاندازد. توسعه دهندگان این سیستم ها مسئول درک و فهم نیازهای این برنامه های کاربردی می باشند و بایستی سیستم را به نحوی سازماندهی کنند که نیازهای تعیین شده را برآورده سازد، بر طبق گفته بیس و همکاران در سال ۲۰۰۳ نیازمندیهای سیستم به طور کلی به دو دسته زیر تقسیم می شوند[۱] :

۱- نیازهای وظیفه مندی [۱۲]

عبارت است از توانایی سیستم برای انجام کاری که به آن اختصاص داده شده است.

۲-نیازهای غیر وظیفه مندی [۱۳]

که به آنها ویژگی های کیفی [۱۴]نیز گفته می شود.

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

   نیازهای وظیفه مندی و غیر وظیفه مندی (ویژگی های کیفی) متعامد هستند ویژگی های کیفی را می توان با پارامترهای خاص معرفی نمود. این ویژگی های کیفی بایستی توسط معمار لیست شود و به سهامداران معرفی شود تا سهامداران بتوانند در مورد آنها اظهار نظر کنند و اولویت های خود را به اطلاع معمار رسانند، در نهایت معمار معماری را معرفی کند که به بهترین شکل نیازهای سهامداران را تا حد ممکن برآورده سازد [۱۰].

   تمرکز ما  در این بخش بر روی ویژگی های کیفی می باشد. ویژگی ها ی کیفی از لحاظ ارزیابی به دو دسته تقسیم می شوند [۴۴]:

۱-ویژگی های کیفی قابل مشاهده در زمان اجرا [۱۵]

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

ویژگی های کیفی قابل مشاهده در زمان اجرا ۵ مورد می باشند که در زیر ذکر شده اند:

 – کارایی[۱۶]

 – امنیت[۱۷]

 – در دسترس بودن[۱۸]

 – قابلیت عملکرد یا وظیفه مندی[۱۹]

 –          قابلیت کاربرد و استفاده[۲۰]

۲-ویژگی های کیفی غیر قابل مشاهده در زمان اجرا[۲۱] :

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

 ویژگی های کیفی غیر قابل مشاهده در زمان اجرا ۵ مورد می باشند که در زیر ذکر شده اند:

  – قابلیت اصلاح پذیری[۲۲]

 – قابلیت حمل[۲۳]

 – قابلیت تجمیع پذیری[۲۴]

 – قابلیت استفاده مجدد[۲۵]

 – قابلیت آزمایش[۲۶]

دو نکته در رابطه با ویژگی های کیفی مطرح می باشد که در زیر توضیح داده شده است:

۱-     معماری برای تحقق و درک  بسیاری از ویژگی های کیفیِ مهم و بحرانی در سیستم می باشد و این ویژگی های مورد نظر می بایستی در سطح معماری طراحی و ارزیابی شوند.

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

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

۲-۳-۱)  انواع ویژگیهای کیفی در معماری نرم افزار


[۱]- Components

[2]- Connector

[3]- Interface

[4] – Stakholders

[5] – Business Case

[6] – Use Case

[7] – Prototype

[8] – Architecture Description Language (ADL)

[9] – Local

[10] – Systematic-broad scope

[11] – Confilict

[12] – Functional Requirements

[13] – None Functional Requirements

[14] – Quality Attributes

[15] – Observable via Execution

[16] – Performance

[17] – Security

[18] – Availability

[19] – Functionality

[20]- Usability

[21] – Not Observable via Execution

[22]- Modifiability

[23] – Portability

[24] – Integritability

[25] – Reusability

[26] – Testability

110,000 ریال – خرید
 

تمام مقالات و پایان نامه و پروژه ها به صورت فایل دنلودی می باشند و شما به محض پرداخت آنلاین مبلغ همان لحظه قادر به دریافت فایل خواهید بود. این عملیات کاملاً خودکار بوده و توسط سیستم انجام می پذیرد.

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

 

 

مطالب پیشنهادی:
  • مقاله معماری نرم افزار
  • برچسب ها : , , , , , , ,
    برای ثبت نظر خود کلیک کنید ...

    براي قرار دادن بنر خود در اين مکان کليک کنيد
    به راهنمایی نیاز دارید؟ کلیک کنید
    

    جستجو پیشرفته مقالات و پروژه

    سبد خرید

    • سبد خریدتان خالی است.

    دسته ها

    آخرین بروز رسانی

      پنجشنبه, ۱۸ آذر , ۱۳۹۵
    
    اولین پایگاه اینترنتی اشتراک و فروش فایلهای دیجیتال ایران
    wpdesign Group طراحی و پشتیبانی سایت توسط دیجیتال ایران digitaliran.ir صورت گرفته است
    تمامی حقوق برایdjkalaa.irمحفوظ می باشد.