عنوان :

پایان نامه معماری نرم افزار

تعداد صفحات :۱۲۰

نوع فایل : ورد و قابل ویرایش

چکیده

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

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

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

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

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

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

   درفصل پنجم یک مطالعه کاربردی ارائه شده و روش ارائه شده در این پروژه (فصل چهارم) بر این مطالعه کاربردی اعمال شد و نتیجه آن بررسی وتحلیل شد.

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

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

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

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

کلمات کلیدی: ارزیابی معماری نرم افزار، ویژگی های کیفی، تصمیمات طراحی، سهامداران

فهرست مطالب

چکیده    ۱
فصل اول
معرفی موضوع تحقیق
۱-۱- مقدمه   ۳
۱-۲- طرح مسئله   ۵
۱-۳- تمرکز تحقیق    ۶
۱-۴-  فعالیت های مرتبط    ۷
۱-۵- ساختار تحقیق   ۸
فصل دوم
آشنایی با ادبیات تحقیق
۲-۱- معماری   ۱۱
۲-۱-۱- معماری نرم افزار    ۱۲
۲-۱-۲-مراحل فرآیند معماری نرم افزار   ۱۵
۲-۱-۳- اهمیت معماری نرم افزار   ۱۷
۲-۲- تصمیمات معماری   ۱۸
۲-۳- ویژگیهای کیفی در معماری نرم افزار    ۲۰
۲-۳-۱ -انواع ویژگیهای کیفی در معماری نرم افزار   ۲۲
۲-۳- ۱-۱- صفات کیفیتی سیستمی   ۲۲
۲-۳-۱-۲- صفات کیفیتی تجاری   ۳۰
۲-۳-۱-۳-  صفات کیفیتی وابسته  به معماری   ۳۱
۲-۳-۲- ویژگی های کیفی معماری نرم افزار از نگاهی دیگر   ۳۲
۲-۳-۳- مدل های کیفیت    ۳۳
۲-۳ -۴-وجود مصالحه میان ویژگیهای کیفی   ۳۶
۲-۴- ارزیابی و تحلیل معماری   ۳۷
۲-۵- دلایل ارزیابی معماری نرم افزار   ۴۰
۲-۶- نتیجه گیری      ۴۳
فصل سوم
مروری بر روش¬های تصمیم¬گیری
۳-۱- فرآیند تصمیم گیری    ۴۵
۳-۲- یک معیار در مقابل چند معیار، تعداد پایان¬پذیری گزینه در مقابل تعداد بی¬پایان گزینه    ۴۸
۳-۳-  توابع تصمیم¬گیری بر مبنای چندویژگی   ۴۹
۳-۳-۱- تحلیل سود و هزینه    ۵۰
۳-۳-۲- روش های ابتدایی    ۵۱
۳-۳-۲-۱- تحلیل موافقان و مخالفان    ۵۱
۳-۳-۲-۲- روش¬های بیش¬کم و بیش¬بیش   ۵۱
۳-۳-۲-۳- روش¬های ربطی و گسسته   ۵۱
۳-۳-۲-۴- روش واژه¬نگاری   ۵۲
۳-۳-۳- روش های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.

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

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

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

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

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

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

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

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

[۱۰]  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.

[۱۱]  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).

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

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

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

[۱۵]  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.

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

[۱۷]  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.

[۱۸]   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.

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

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

[۲۱]   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.

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

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

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

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

[۲۶]  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.

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

[۳۰]  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.

[۳۱]  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.

[۳۳]  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.

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

[۳۵]  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.

[۳۷]  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.

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

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

[۴۰]  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.

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

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

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

۱-۱) مقدمه

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

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

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

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

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

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

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

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

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

۱-۲) طرح مسئله

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

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

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

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

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

۱-۳) تمرکز تحقیق

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

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

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

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

۱-۴)  فعالیتهای مرتبط

   در زمینه‌های معماری نرم‌افزار و ارزیابی معماری نرم‌افزار فعالیت ‌های ارزشمندی صورت گرفته است. در برخی مقالات به بررسی و تحلیل انواع نیازهای کیفی یا غیر وظیفه‌مندی پرداخته شده است. برای مثال امسی کال در سال ۱۹۹۴ علاوه بر بررسی و بیان نحوه یافتن ویژگی‌های کیفی، مکانیزم‌های اولویت دهی به صفات نیز مورد بررسی قرار داده است[۳]. در برخی دیگر از روش ها به بررسی و تحلیل نیازهای وظیفه‌مندی می‌پردازد. برای مثال روش ارائه شده توسط هامیستر و نورد وسونی[۴] در سال ۲۰۰۰ و روش ارائه شده توسط جکبسون و بوش و رامبوگ[۵]  در سال۱۹۹۹ و روش طراحی ارائه شده توسط بوش  [۶] در سال ۲۰۰۰  از این دسته می باشند. در واقع این روشها برای ساخت معماری نرم‌افزار مناسب ارائه شده است. علاوه بر این طبق تحقیقات صورت گرفته برخی از ویژگی‌های کیفی در تضاد با یکدیگرند، برای مثال طبق گفته لاند برگ[۷]  در سال ۱۹۹۹ بین کارایی و قابلیت پیکربندی برخورد وجود دارد و همچنین طبق گفته بیس و کلمنت و کازمن [۱] در سال ۲۰۰۳بین کارایی و قابلیت تغییر و بین هر ویژگی کیفی و هزینه برخورد وجود دارد.

فعالیتهای صورت گرفته در زمینه ارزیابی معماری نرم‌افزار را می‌توان به سه طریق دسته‌بندی کرد.

    روش اول به دو دسته زیر تقسیم می‌شود. دسته ی اول روشهایی که به ارزیابی معماری نرم‌افزار تنها بر اساس یک ویژگی می‌پردازد. برای مثال روش ارائه شده توسط شرفی [۸] در سال۲۰۰۸ به بررسی و ارزیابی معماری از لحاظ کارایی پرداخته است و روش ارائه شده توسط بنگستون [۹] در سال ۲۰۰۲ به بررسی و ارزیابی معماری از لحاظ میزان قابلیت تغییر پرداخته است.

    دسته‌دوم روش‌هایی که به ارزیابی معماری با در نظر گرفتن موضوع مصالحه trade – off بین ویژگی‌های کیفی مختلف پرداخته‌اند  برای مثال اسوان برگ و ولین و لاند برگ  [۱۰]در سال ۲۰۰۳ روشی جهت انتخاب مناسب‌ترین معماری نرم‌افزار از بین معماری‌های نرم‌افزار کاندید ارائه ‌ داده اند که با الویت‌دهی به ویژگی های کیفی به کمک روش‌ AHP و اعمال آن بر معماری‌های ارائه شده نتایج عددی جهت تصمیم‌گیری حاصل می‌شود. در مقاله ای دیگر آلنیم و گرتون و بابر [۱۱] در سال ۲۰۰۵ نیز روشی به نام Arch designer ارائه داده اند که علاوه بر اولویت‌دهی به ویژگی‌های کیفی به تصمیمات طراحی مختلف وزن اختصاص می‌دهد و به روش عددی معماری مناسب‌تر را انتخاب می‌کند. همچنین وفایی جهان و شمس و ستایش[۴۳]  در سال ۱۳۸۵ روشی احتمالی جهت انتخاب معماری مناسب‌تر از بین معماری‌های کاندیدا ارائه شده است که در این روش با ایجاد یک ماتریس ارزشی برای هر معماری اولویت‌دهی به هر ویژگی کیفی با استفاده از روش AHP و اعمال این الویت‌ها بر ماتریس‌های ارزش و در نهایت محاسبه چگالی بردارهای ارزش به معماری با بالاترین چگالی را به عنوان معماری برتر انتخاب می‌شود.

    در روش دوم طبق مروری که دبریکا و نیملا در سال ۲۰۰۲ صورت داده اند تکنیک‌های ارزیابی معماری نرم‌افزار به دو دسته پرسشی و اندازه‌گیری تقسیم می‌شوند[۱۲]. در تکنیک پرسشی با پاسخ به یک سری سؤالات یا سناریو‌ها میزان مقبولیت معماری مشخص می شود که خود به سه دسته تکنیک‌ها مبتنی بر پرسشنامه، لیست مرجع و سناریو تقسیم می‌شود که روش مبتنی بر سناریو به دلیل پوشاندن همه جوانب از همه کاملتر می‌باشد.

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

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

۱-۵)  ساختار تحقیق

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

۱-  فصل اول:مقدمه(همین فصل) این فصل به کلیات طرح اختصاص داده شده است. در این فصل انگیزه کار، تمرکز تحقیق و سابقه فعالیت های انجام شده در این زمینه بررسی شد.

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

 ۳-  فصل سوم: بررسی توابع مختلف تصمیم گیری: در این فصل مروری بر روش های مختلف تصمیم گیری خواهیم داشت. از آن جایی که در هنگام انتخاب معماری مناسب برای نرم افزار مورد نظر امکان تصمیم گیری های متفاوت در پیش روی معمار می باشد، می توان از روش های معرفی شده در این فصل استفاده کرد.

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

۵-  فصل پنجم: مطالعه موردی: در این فصل روش ارائه شده در فصل قبل بر روی یک مثال اعمال شده است وسپس نتایج حاصله مورد بحث و بررسی قرار گرفته است.

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

  فصل دوم

آشنایی با ادبیات تحقیق

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

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

۲-۱) معماری

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

جدول ۲-۱: دامنه و تاثیر تصمیمات در سیستم نرم افزاری[۴۴]

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

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

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

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

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

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

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

---

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