طراحی نرم‌افزار: تفاوت میان نسخه‌ها

طراحی نرم‌افزار فرایندی است که توسط آن یک عامل ،مشخصه یی از نرم‌افزار را طراحی می کندمی‌کند که هدف آن، به انجام رساندن اهداف از پیش تعیین شده با استفاده از مجموعه ای از اجزای اولیه و با توجه به محدودیت هامحدودیت‌ها است.<ref>Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., [[John Mylopoulos|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}}.</ref> طراحی نرم‌افزار می تواندمی‌تواند به عنوان "تمام فعالیت های مربوط به مفهوم سازی، طراحی، اجرا، راه اندازی و در نهایت اصلاح سیستم های پیچیده" یا "فعالیت های مشخص مورد نیاز و قبل از برنامه نویسی و ... [در] یک پروسه مهندسی نرم‌افزار.

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

تفاوت اصلی بین تجزیه و تحلیل نرم‌افزار و طراحی نرم‌افزار این است که خروجی یک تجزیه و تحلیل نرم‌افزاری از مشکلات کوچکتر برای حل مسئله تشکیل شده استشده‌است. علاوه بر این، تجزیه و تحلیل نباید با تفوت زیادی در میان اعضای تیم یا گروه هایگروه‌های مختلف ،طراحی شود. در مقابل، طراحی بر قابلیت هاقابلیت‌ها متمرکز است و بنابراین طرح هایطرح‌های متعددی برای یک مشکل مشابه می تواندمی‌تواند وجود داشته باشد. بسته به محیط ،محیط، طراحی اغلب متفاوت است، چه از طریق چارچوب ([[Software framework|frameworks]])های قابل اعتماد چه با الگوهای طراحی([[design patterns]]) مناسب پیاده سازیپیاده‌سازی شده باشد. نمونه هاینمونه‌های طراحی شامل سیستم هایسیستم‌های عملیاتی، صفحات وب، دستگاه هایدستگاه‌های تلفن همراه یا حتی پارادایم ابری جدید است.

طراحی نرم‌افزار هم یک فرایند و هم یک مدل است. فرایند طراحی یک دنباله ای از مراحل است که طراح را قادر می سازدمی‌سازد که تمام جنبه هایجنبه‌های ساخت نرم‌افزار را توصیف کند. مهارت خلاقیت، تجربیات گذشته، حس اینکه چه چیزی نرم‌افزار «خوب» را میسازد و تعهد کلی به کیفیت، نمونه هایینمونه‌هایی از عوامل موفقیت قطعی برای یک طراحی مناسب است. با این وجود مهم است که توجه داشته باشید که فرایند طراحی همیشه یک روش ساده نیست؛ مدل طراحی را می توانمی‌توان با طراحی معماری خانه مقایسه کرد. با نشان دادن کلییت چیزی که باید ساخته شود آغاز می شودمی‌شود (به عنوان مثال، ارائه سه بعدی خانه)؛ و به آرامی، این برای ساخت هر جزئی (به عنوان مثال، نصب لوله کشی) اراِیه شده.است به طوربه‌طور مشابه، مدل طراحی که برای نرم‌افزار ایجاد شده است، دیدگاهشده‌است، هایدیدگاه‌های مختلفی از نرم‌افزارهای کامپیوتری را فراهم می کندمی‌کند. اصول طراحی اولیه، مهندس نرم‌افزار را قادر می سازدمی‌سازد تا در فرایند طراحی حرکت کند. دیویس <ref>Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.</ref> مجموعه ای از اصول طراحی نرم‌افزار را پیشنهاد می کندمی‌کند که در لیست زیر ارائه شده و گسترش یافته استیافته‌است:

* '''فرایند طراحی نباید از "دید تونلی" رنج ببرد.''' یک طراح خوب باید روش هایروش‌های جایگزین را در نظر بگیرد و هر کدام را براساس نیازمندی هاینیازمندی‌های سئله و منابع موجود برای انجام کار، بررسی کند.

* '''طراحی باید قابل تبدیل به مدل هایمدل‌های تحلیلی باشد.''' از آنجایی که تنها یک عنصر از مدل طراحی اغلب می تواندمی‌تواند به تعدادی از نیازها برگردد، لازم است که وسیله ای برای ردیابی نحوه رعایت الزامات مدل طراحی داشته باشیم.

* '''طراحی باید طوری ساختاریافته باشد که به راحتی تخریب شود، حتی هنگامی که با داده هایداده‌های غیرمعمول، حوادث یا شرایط عملیاتی مواجه می شوندمی‌شوند.'''

* '''طراحی برنامه نویسیبرنامه‌نویسی نیست، برنامه نویسیبرنامه‌نویسی طراحی نیست. '''

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

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

#[[اصلاح]]-این روند تکامل است. یک سلسله مراتب بوسیلهبه وسیلهٔ تجزیه یک بیانیه ماکروسکوپیک از عملکرد به صورت گام به گام تا رسیدن به اظهارات زبان برنامه نویسیبرنامه‌نویسی به دست می آید. در هر مرحله یک یا چند دستورالعمل از یک برنامه مشخص به دستورالعمل هایدستورالعمل‌های دقیق تر تجزیه می شوندمی‌شوند. چکیده و اصلاح مفاهیم مکمل هستند.

#پیمانه ایی-معماری نرم‌افزار به اجزای به نام ماژول تقسیم می شودمی‌شود.

#[[معماری نرم‌افزار]]-این مورد به ساختار کلی نرم‌افزار اشاره دارد و راه هاییراه‌هایی که این ساختار یک سیستم یکپارچه مفهومی را فراهم می کندمی‌کند. معماری نرم‌افزار خوب با بازدهی خوب، سرمایه گذاریسرمایه‌گذاری را با توجه به نتیجه مطلوب پروژه، مثلاً از نظر عملکرد، کیفیت، برنامه و هزینه انجام میدهد.

#سلسله مراتب کنترل-یک ساختار برنامه ای که نشان دهنده سازمان یک جزء برنامه است و یک سلسله مراتب کنترل را نشان می دهدمی‌دهد.

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

#رویکرد نرم‌افزار-در این مورد تمرکز بر پردازش هر یک از ماژول هاماژول‌ها به صورت جداگانه است.

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

Grady Booch در مدل شیء خود، Abstraction، Encapsulation، Modularisation و سلسله مراتب را به عنوان اصول طراحی نرم‌افزار معرفی می کندمی‌کند.<ref>{{cite book|last1=Booch|first1=Grady|title=Object-Oriented Analysis and Design with Applications|date=2004|publisher=Addison Wesley|location=MA, USA|isbn=0-201-89551-X|edition=3rd|url=http://dl.acm.org/citation.cfm?id=975416|accessdate=30 January 2015|display-authors=etal}}</ref> The acronym PHAME (Principles of Hierarchy, Abstraction, Modularisation, and Encapsulation) is sometimes used to refer to these four fundamental principles.<ref>{{cite book|last1=Suryanarayana|first1=Girish|title=Refactoring for Software Design Smells|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258|url=https://www.amazon.com/Refactoring-Software-Design-Smells-Technical/dp/0128013974|accessdate=31 January 2015}}</ref>

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

*'''سازگاری'''- نرم‌افزار قادر به کار با سایر محصولات است که برای قابلیت همکاری با یک محصول دیگر طراحی شده اندشده‌اند.

*'''توسعه پذیری'''-قابلیت هایقابلیت‌های جدید می تواندمی‌تواند به نرم‌افزار بدون تغییرات عمده در معماری پایه اضافه شود.

*'''ماجول بودن'''-نرم‌افزار در نتیجه مستقل از اجزای مستقل است که منجر به بهبود قابلیت نگهداری می شودمی‌شود. سپس اجزاء می توانندمی‌توانند قبل از اینکه یک سیستم نرم‌افزاری مورد نظر یکپارچه شوند، به طوربه‌طور انفرادی اجرا و آزمایش شوند که اجازه می دهدمی‌دهد تا تقسیم کار در یک پروژه توسعه نرم‌افزار رخ دهد.

*'''[[تحمل خطا]]'''-نرم‌افزار مقاوم است و قادر به بازیابی شکستشکست‌های های قسمت هایقسمت‌های جزیی است.

*'''قابلیت نگهداری'''-اندازه گیریاندازه‌گیری اینکه چگونه رفع اشکالات و یا اصلاحات کاربردی می تواندمی‌تواند انجام شود. قابلیت نگهداری بالا می تواندمی‌تواند محصول ماجولار و توسعه پذیری باشد.

* '''قابل استفاده مجدد'''-توانایی استفاده از برخی یا تمام جنبه هایجنبه‌های نرم‌افزار پیشین در پروژه هایپروژه‌های دیگر با اصلاحات کمی و بدون تغییر.

* '''نیرومندی'''-این نرم‌افزار قادر به اجرا تحت فشار است و یا تحمل ورودی غیرغیرقابل قابل پیش بینیپیش‌بینی یا نامعتبر است. به عنوان مثال، می توانمی‌توان آن را با مقاومت در برابر شرایط کم حافظه طراحی کرد.

* '''[[کارایی]]'''- نرم‌افزار وظایف خود را در یک فریم زمان که برای کاربر قابل قبول است انجام می دهدمی‌دهد و به حافظه بیشمار نیاز ندارد.

* '''قابل حمل بودن'''-نرم‌افزار باید در شرایط مختلف و محیط هایمحیط‌های مختلف قابل استفاده باشد.

* '''[[مقیاس پذیری]]'''- نرم‌افزار به خوبی به افزایش داده هاداده‌ها یا تعداد کاربران کمک می کندمی‌کند.

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

* نشانه گذاری مدل سازیمدل‌سازی فرایند کسب و کار (BPMN) نمونه ای از زبان مدل سازیمدل‌سازی پردازش است.

* EXPRESS و (EXPRESS-G (ISO 10303-1 یک استاندارد همه منظوره بین‌الملللی برای مدل سازیمدل‌سازی داده هاست.

* زبان مدل سازیمدل‌سازی سازمانی توسعه یافته (EEML) است معمولاً برای مدل سازیمدل‌سازی فرایند کسب و کار در لایه هایلایه‌های زیادی استفاده می شودمی‌شود.

* [[فلوچارت]] نمایش شماتیک از الگوریتم یا فرایند محاسبات است.

* IDEF خانواده ایی از زبانزبان‌های های مدل سازیمدل‌سازی هستن که قابل توجهتوجه‌ترین ترین انهاآن‌ها عبارتند از IDEF0 برای مدل سازیمدل‌سازی عملکرد، IDEF1X برای مدل سازیمدل‌سازی اطلاعات، و IDEF5 برای مدل سازی هستیمدل‌سازی شناسیهستی‌شناسی (علم).

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

سند طراحی نرم‌افزار ممکن است مورد بررسی قرارگیرد و اجازه میمی‌دهد دهد محدودیت هامحدودیت‌ها و مشخصات و حتی نیاز هاینیازهای قبل از [[برنامه نویسی]] بررسی شود. طراحی مجدد ممکن است پس از بررسی برنامه ریزیبرنامه‌ریزی شبیه سازی یا [[پروتوتایپ]] رخ دهد. ممکن است طراحی نرم‌افزار در فرایند برنامه ریزی، بدون نیاز به برنامه و یا تجزیه و تحلیل باشد،<ref>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</ref> اما برای پروژه هایپروژه‌های پیچیده تر امکان پذیرامکان‌پذیر نخواهد بود.

* [[طراحی تعامل]]

* [[توسعه نرم‌افزار]]