طراحی نرم‌افزار

از ویکی‌پدیا، دانشنامهٔ آزاد
پرش به ناوبری پرش به جستجو
توسعه نرم‌افزار
فعالیت‌های اصلی
Paradigms and models
متدولوژی‌ها و frameworks
رشته‌های مورد حمایت
Practices
ابزار توسعه نرم‌افزار
Standards and BOKs

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

بررسی اجمالی[ویرایش]

طراحی نرم افزار فرایند پیش بینی و تعریف راه حل های نرم افزاری به یک یا تعدادی از مشکلات است. یکی از اجزای اصلی طراحی نرم افزار ،نرم افزار مورد نیاز تجزیه و تحلیل software requirements analysis]]SRA]] است. SRA بخشي از فرآيند توسعه نرم افزار است که مشخصات مورد استفاده در مهندسي نرم افزار را فهرست مي کند. اگر نرم افزار به طور "کامل اتوماتیک" (به معنی بدون کاربر یا رابط کاربری) باشد، طراحی نرم افزاری ممکن است به اندازه یک فلوچارت یا متن توصیفی دنباله ای از رویدادهای برنامه ریزی شده ساده باشد. همچنین روش های نیمه استاندارد مانند زبان مدل سازی یکسان و مفاهیم مدل سازی اساسی وجود دارد. در هر صورت، بعضی مستندات این طرح معمولا محصول طراحی است. علاوه بر این، طراحی نرم افزار ممکن است یک پلت فرم_مستقل(platform-independent)یا پلت فرم_مشخص( platform-specific) باشد که بسته به دسترسی به تکنولوژی مورد استفاده برای طراحی دارد. تفاوت اصلی بین تجزیه و تحلیل نرم افزار و طراحی نرم افزار این است که خروجی یک تجزیه و تحلیل نرم افزاری از مشکلات کوچکتر برای حل مسئله تشکیل شده است. علاوه بر این، تجزیه و تحلیل نباید با تفوت زیادی در میان اعضای تیم یا گروه های مختلف ،طراحی شود. در مقابل، طراحی بر قابلیت ها متمرکز است و بنابراین طرح های متعددی برای یک مشکل مشابه می تواند وجود داشته باشد. بسته به محیط ، طراحی اغلب متفاوت است، چه از طریق چارچوب (frameworks)های قابل اعتماد چه با الگوهای طراحی(design patterns) مناسب پیاده سازی شده باشد. نمونه های طراحی شامل سیستم های عملیاتی، صفحات وب، دستگاه های تلفن همراه یا حتی پارادایم ابری جدید است.

طراحی نرم افزار هم یک فرآیند و هم یک مدل است. فرایند طراحی یک دنباله ای از مراحل است که طراح را قادر می سازد که تمام جنبه های ساخت نرم افزار را توصیف کند. مهارت خلاقیت، تجربیات گذشته، حس اینکه چه چیزی نرم افزار «خوب» را میسازد و تعهد کلی به کیفیت، نمونه هایی از عوامل موفقیت قطعی برای یک طراحی مناسب است. با این وجود مهم است که توجه داشته باشید که فرآیند طراحی همیشه یک روش ساده نیست؛ مدل طراحی را می توان با طراحی معماری خانه مقایسه کرد. با نشان دادن کلییت چیزی که باید ساخته شود آغاز می شود (به عنوان مثال، ارائه سه بعدی خانه)؛ و به آرامی، این برای ساخت هر جزئی (به عنوان مثال، نصب لوله کشی) اراِیه شده.است به طور مشابه، مدل طراحی که برای نرم افزار ایجاد شده است، دیدگاه های مختلفی از نرم افزارهای کامپیوتری را فراهم می کند. اصول طراحی اولیه، مهندس نرم افزار را قادر می سازد تا در فرایند طراحی حرکت کند. دیویس [۳] مجموعه ای از اصول طراحی نرم افزار را پیشنهاد می کند که در لیست زیر ارائه شده و گسترش یافته است:

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

مفهوم طراحی[ویرایش]

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

  1. چکیده-چکیده فرآیند یا نتیجه تعمیم با کاهش محتوای اطلاعاتی یک مفهوم یا یک پدیده قابل مشاهده است، به طور معمول برای حفظ تنها اطلاعاتی که به یک هدف خاص مرتبط است. درواقع نمایانگر ویژگی های مهم بدون بیان جزییات است.
  2. اصلاح-این روند تکامل است. یک سلسله مراتب بوسیله تجزیه یک بیانیه ماکروسکوپیک از عملکرد به صورت گام به گام تا رسیدن به اظهارات زبان برنامه نویسی به دست می آید. در هر مرحله یک یا چند دستورالعمل از یک برنامه مشخص به دستورالعمل های دقیق تر تجزیه می شوند. چکیده و اصلاح مفاهیم مکمل هستند.
  3. پیمانه ایی-معماری نرم افزار به اجزای به نام ماژول تقسیم می شود.
  4. معماری نرم افزار-این مورد به ساختار کلی نرم افزار اشاره دارد و راه هایی که این ساختار یک سیستم یکپارچه مفهومی را فراهم می کند. معماری نرم افزار خوب با بازدهی خوب، سرمایه گذاری را با توجه به نتیجه مطلوب پروژه، مثلا از نظر عملکرد، کیفیت، برنامه و هزینه انجام میدهد.
  5. سلسله مراتب کنترل-یک ساختار برنامه ای که نشان دهنده سازمان یک جزء برنامه است و یک سلسله مراتب کنترل را نشان می دهد.
  6. تقسیم سازه-ساختار برنامه را می توان به صورت افقی و عمودی تقسیم کرد. پارتیشن های افقی، شاخه های جداگانه سلسله مراتبی ماجول ها را برای هر تابع برنامه اصلی تعریف می کنند. پارتیشن بندی عمودی نشان می دهد که کنترل و کار باید در ساختار برنامه توزیع شود.
  7. ساختار داده ها-این مورد نشان دهنده ارتباط منطقی میان عناصر داده ای است.
  8. رویکرد نرم افزار-در این مورد تمرکز بر پردازش هر یک از ماژول ها به صورت جداگانه است.
  9. مخفی کردن اطلاعات-ماژول ها باید طوری مشخص و طراحی شوند تا اطلاعات موجود در یک ماژول برای ماژول های دیگری که نیازی به چنین اطلاعاتی ندارند، غیرقابل دسترسی باشد.

Grady Booch در مدل شیء خود، Abstraction، Encapsulation، Modularisation و سلسله مراتب را به عنوان اصول طراحی نرم افزار معرفی می کند.[۴] The acronym PHAME (Principles of Hierarchy, Abstraction, Modularisation, and Encapsulation) is sometimes used to refer to these four fundamental principles.[۵]

ملاحظات طراحی[ویرایش]

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

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

زبان مدل سازی[ویرایش]

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

  • زبان توصیف معماری (ADL) زبان مورد استفاده برای توصیف و نمایندگی معماری نرم افزار یک سیستم نرم افزاری است.
  • نشانه گذاری مدل سازی فرآیند کسب و کار (BPMN) نمونه ای از زبان مدل سازی پردازش است.
  • EXPRESS و (EXPRESS-G (ISO 10303-1 یک استاندارد همه منظوره بین الملللی برای مدل سازی داده هاست.
  • زبان مدل سازی سازمانی توسعه یافته (EEML) است معمولا برای مدل سازی فرآیند کسب و کار در لایه های زیادی استفاده می شود.
  • فلوچارت نمایش شماتیک از الگوریتم یا فرآیند محاسبات است.
  • مفاهیم اساسی مدلسازی (FMC) زبان مدلسازی برای سیستم فشرده نرم افزار است.
  • IDEF خانواده ایی از زبان های مدل سازی هستن که قابل توجه ترین انها عبارتند از IDEF0 برای مدل سازی عملکرد، IDEF1X برای مدل سازی اطلاعات، و IDEF5 برای مدل سازی هستی شناسی (علم).

(Service-oriented modeling framework (SOMF [۶]

الگوهای طراحی[ویرایش]

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

استفاده[ویرایش]

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

جستارهای وابسته[ویرایش]

منابع[ویرایش]

  1. Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–136. Springer-Verlag, p. 109 doi:10.1007/978-3-540-92966-6_6.
  2. Freeman, Peter; David Hart (2004). "A Science of design for software-intensive systems". Communications of the ACM. 47 (8): 19–21 [20]. doi:10.1145/1012037.1012054. 
  3. Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.
  4. Booch, Grady; et al. (2004). Object-Oriented Analysis and Design with Applications (3rd ed.). MA, USA: Addison Wesley. ISBN 0-201-89551-X. Retrieved 30 January 2015. 
  5. Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977. Retrieved 31 January 2015. 
  6. Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3. 
  7. Judith Bishop. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from O'Reilly Media. Retrieved 2012-05-15. If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems. 
  8. Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136

^Roger S. Pressman. Software engineering: a practitioner’s approach. McGraw-Hill. ISBN 0-07-365578-3. 

  • (انگلیسی) (۴۰۰ ص) David Budgen, Software Design, Addison Wesley, 2003