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

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

طراحی نرم‌افزار معمولاً شامل حل مسئله و برنامه ریزیبرنامه‌ریزی یک راه حل نرم‌افزاری است که شامل طراحی جزئی اجزا و طراحی الگوریتم و طراحی معماری سطح بالا می باشدمی‌باشد."<ref>{{cite journal|last=Freeman|first=Peter|author2=David Hart |title=A Science of design for software-intensive systems|journal=Communications of the ACM|year=2004|volume=47|issue=8|pages=19–21 [20]|doi=10.1145/1012037.1012054}}</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،Abstraction, Encapsulation،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-01280139770-12-801397-7|pages=258|url=https://www.amazon.com/Refactoring-Software-Design-Smells-Technical/dp/0128013974|accessdate=31 January 2015}}</ref>

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

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

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

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

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

* '''قابلیت اطمینان'''(دوام نرم‌افزار)- نرم‌افزار قادر به انجام یک تابع مورد نیاز در شرایط مشخص شده برای یک دوره مشخص از زمان است.

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

== زبان مدل سازیمدل‌سازی ==

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

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

(Service-oriented modeling framework (SOMF <ref name="Bell">{{cite book |last=Bell |first=Michael|title=Service-Oriented Modeling: Service Analysis, Design, and Architecture|year= 2008 |publisher=Wiley & Sons|isbn=978-0-470-14111-3 |chapter=Introduction to Service-Oriented Modeling}}</ref>

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

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