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

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

توسعه نرم‌افزار
فعالیت‌های اصلی
پارادایم‌ها و مدل‌ها
متدولوژی‌ها و چارچوب‌ها
رشته‌های مورد حمایت
کاربردهای عملی
ابزار
استانداردها و بدنه‌های دانش
واژه‌نامه‌ها
  • Artificial intelligence
  • Computer science
  • Electrical and electronics engineering
رئوس مطالب
  • Outline of software development

بررسی اجمالی

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

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

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

مفهوم طراحی

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

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

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

ملاحظات طراحی

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

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

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

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

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

(Service-oriented modeling framework (SOMF[6]

الگوهای طراحی

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

استفاده

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

جستارهای وابسته

منابع
  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-0-12-801397-7. 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
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.