دانلود کامل ترین جزوه برنامه سازی سیستم

جزوه تایپ شده برنامه سازی سیستم

دانلود فایل

استاد میترا کریم زاده کارشناسی ناپیوسته دانشگاه علم و صنعت ایران دانشگاه علمی کاربردی محسن عسکری دانشگاه آزاد داریوش نیک‌مهر دانشگاه

: () () ‌() : () –“” ‌”” “” -:
ً () (-8) عملیاتی به نام validatePassword() است که به یک رمز عبور دسترسی پیدا کرده و برای بررسی اعتبار رمز عبور، یک مقایسه‌ی رقم به رقم را انجام می دهد.

3-5-8 نمودارهای فعالیت UML
نمودار فعالیت UML با ارائه یک نمایش گرافیکی از جریان تعامل در یک فیلمنامه خاص، مورد کاربری را تکمیل می کند. برنامه سازی از مهندسان نرم افزار، نمودارهای فعالیت را راهی برای نمایش نحوه واکنش سیستم، به رویدادهای داخلی توصیف می کنند.در تصویر 9-8، نمودار فعالیت برای مورد کاربری ACS-DCV، نشان داده شده است. توجه کنید که نمودار فعالیت، جزئیات بیشتری را که مستقیماً توسط مورد استفاده ذکر نشده است (اما به صورت ضمنی به آن، اشاره شده است)، اضافه می کند. برای مثال، یک کاربر ممکن است تنها چند مرتبه‌ی محدود، برای وارد کردن شناسه کاربری و رمز عبور، جزوه برنامه سازی سیستم کند.در ادامه، نمایی لوزی شکل از تصمیم گیری، این موضوع را نشان می دهد: “درخواست بازگشت مجدد”.

دانلود رایگان خلاصه جزوه برنامه سازی سیستم کتاب پی دی اف pdf کامل

نمودار خط شنا UML، نوع کارآمدی از نمودار فعالیت است و به شما امکان می دهد تا جریان فعالیت های توصیف شده توسط مورد کاربری راارائه دهید و در عین حال، مشخص کنید که کدام بازیگر (در صورتی که چندین بازیگر در یک مورد کاربری خاص دخیل باشند)، یا طبقه تجزیه و تحلیل (بخش 1-3-8)، مسئولیت اقدامات شرح داده شده توسط یک مستطیل فعالیت را بر عهده دارد. مسئولیت ها، به عنوان بخش هایی موازی نمایش داده می شوند، که نمودار را به صورت عمودی، مانند خطوط موجود در استخر شنا، از یکدیگر جدا می کنند. سه طبقه تجزیه و تحلیل ( صاحب خانه، دوربین و رابط)، مسئولیت های مستقیم یا غیر برنامه سازی در زمینه نمودار فعالیت جزوه برنامه سازی سیستم داده شده در تصویر 9-8 را به عهده دارند. با توجه به تصویر 10-8، نمودار فعالیت به گونه ای تنظیم شده است که فعالیت های مرتبط با یک طبقه تجزیه و تحلیل، در داخل خط شنای آن طبقه قرار گیرد. به عنوان مثال، طبقه Interface، نشان دهنده رابط کاربری است که توسط صاحب خانه مشاهده شده است. نمودار فعالیت، دو درخواست را نشان می دهد که وظیفه رابط کاربری است: “درخواست ورود مجدد” و “درخواست نمای دیگر”.این درخواست ها و تصمیمات مربوط به آن ها، در داخل خط شنای Interface قرار می گیرد. در هر صورت، پیکان ها از آن خط شنای Interface به خط شنای صاحب خانه منتقل می شوند، یعنی محلی که اقدامات صاحب خانه در آن رخ می دهد. موارد کاربری، همراه با فعالیت ها و نمودارهای خط شنا، رویه محور هستند و در مجموع می توان از آن ها برای نشان دادن نحوه استناد بازیگران مختلف به عملکردهایی مشخص (یا سایر مراحل رویه‌ای)، برای برآوردن الزامات سیستم استفاده کرد.

برنامه سازی سیستم

هدف مدل سازی الزامات، ایجاد انواع نمایش های توصیف کننده نیازهای مشتری، فراهم کردن مبنایی برای ایجاد یک طرح نرم افزاری و تعیین مجموعه ای از الزامات است که به محض ساخت نرم افزار، قابل تأیید باشند. مدل الزامات، فاصله بین یک توصیف در سطح سیستم، که عملکرد کلی سیستم و مشاغل را توصیف می کند، و یک طرح نرم افزاری که معماری برنامه نرم افزار، رابط کاربری و ساختاری در سطح اجزا را توصیف می کند، پر می کند. مدل های مبتنی بر فیلمنامه، الزامات نرم افزاری را از نظر کاربر نشان می دهند. مورد کاربری ( یک توصیف روایی یا الگو محور از یک تعامل بین بازیگر و نرم افزار ) عنصر اصلی مدل سازی است. همزمان با استنباط برنامه سازی ، مورد کاربری مراحل کلیدی را برای یک عملکرد یا تعامل خاص تعریف می کند. میزان رسمیت و جزئیات موارد کاربری، متفاوت است، اما این موارد، می توانند ورودی لازم برای سایر فعالیت های مدل سازی تجزیه و تحلیل را ارائه کنند. فیلمنامه ها را همچنین می توان با استفاده از یک نمودار فعالیت ( یک نمای گرافیکی که جریان پردازش در یک فیلمنامه خاص را نشان می دهد)، توصیف کرد. روابط موقتی در یک مورد کاربری را می توان با استفاده از نمودارهای توالی، مدل سازی کرد. مدل سازی مبتنی بر گروه، از اطلاعات به دست آمده از موارد کاربری و سایر توضیحات کتبی برنامه، برای شناسایی طبقات تجزیه و تحلیل، استفاده می کند. ممکن است از یک تحلیل دستوری برای استخراج طبقات، ویژگی ها و عملیات‌های داوطلب، از میان روایت های مبتنی بر متن، استفاده شود. معیارهای تعریف طبقات، با استفاده از نتایج تجزیه و تحلیل، تعریف می شود. برای جزوه برنامه سازی سیستم روابط بین طبقات، می توان از مجموعه ای از کارت های شاخص طبقه-مسئولیت0همکار، استفاده کرد. علاوه بر این، می توان از انواع مدل سازی UML، برای تعریف سلسله مراتب، روابط، ارتباطات، تجمعات و وابستگی های بین طبقات، استفاده کرد. مدل سازی کارکردی در طول تجزیه و تحلیل الزامات، کارکرد پربازده نرم افزار را به تصویر می کشد. مدل کارکردی، از ورودی های اجزای مبتنی بر فیلمنامه یا مبتنی بر گروه، برای نشان دادن حالات طبقات تجزیه و تحلیل، استفاده می کند. برای تحقق این امر، برنامه سازی ها مشخص می شوند، رویدادهایی که منجر به انتقال یک طبقه (یا سیستم) از یک وضعیت به وضعیتی دیگر می‌شوند، تعریف می شوند، و اقداماتی که با انجام انتقال، صورت می گیرند نیز مشخص می شوند.برای مدل سازی، می توان از نمودارهای وضعیت UML، نمودارهای فعالیت، نمودارهای خط شنا ونمودارهای توالی استفاده کرد.
مسائل و نکات قابل تأمل
1-8 آیا می توان بلافاصله پس از ایجاد مدل الزامات کدگذاری را شروع کرد؟ پاسخ خود را توضیح دهید و سپس در مورد خلاف آن نیز بحث کنید.
8-2 یکی از قوانین کلی تجزیه و تحلیل، این است که مدل “باید بر الزامات قابل مشاهده در محدوده مشکل یا حوزه کسب و کار تمرکز کند.” چه نوع الزاماتی در این موارد قابل مشاهده نیستند؟ چند مثال بزنید.
3-8 بخش مربوط به امور عمومی یک شهر بزرگ، تصمیم گرفته است که یک سیستم ردیابی مبتنی بر وب و تعمیر چاله ها ایجاد کند.شرح این کار، چنین است: شهروندان می توانند وارد یک وب سایت شوند و موقعیت و شدت حفره ها را گزارش دهند. با گزارش چاله ها، آن‌ها در یک “سیستم تعمیراتی در بخش امور عمومی” وارد می شوند و یک شماره شناسایی به آن‌ها اختصاص داده می شود، و آدرس خیابان، اندازه (در مقیاس 1 تا 10)، محل (مختصات حدودی، محدوده، و غیره)، منطقه (با توجه به آدرس خیابان مشخص می شود)، و اولویت تعمیر(با توجه به اندازه چاله تعیین می شود)، ذخیره خواهد شد. داده های سفارش کار، با چاله‌ی مورذنظر، مرتبط است و شامل محل و اندازه چاله، شماره شناسایی خدمه تعمیر، تعداد خدمه، تجهیزات اختصاص داده شده، ساعات اعمال شده برای تعمیر، وضعیت سوراخ (کار در حال انجام، تعمیر، تعمیر موقت، تعمیر نشده)، مقدار مواد پرکننده مورد استفاده و هزینه تعمیر (با توجه به ساعات اختصاص داده شده به کار، تعداد افراد، مواد و تجهیزات استفاده شده محاسبه می شود) می شود. در نهایت، یک فایل خرابی ایجاد می شود که حاوی اطلاعات مربوط به آسیب های گزارش شده ناشی از حفره و
شامل نام شهروند، آدرس، شماره تلفن، نوع خسارت و مبلغ خسارت به دلار است. PHTRS یک برنامه سازی آنلاین است. همه پرس و جوها باید به صورت تعاملی انجام شوند.
یک سیستم PHTRS نمودار مورد کاربری UML ترسیم کنید. شما باید تعدادی فرضیه در مورد نحوه تعامل کاربر با این سیستم، مطرح کنید.
4-8 دو یا سه مورد کاربری بنویسید که نقش بازیگران مختلف در PHTRS را که در قسمت 3-8 توضیح داده شد، توصیف کند.
5-8 یک نمودار فعالیت برای یک جنبه از PHTRS ایجاد کنید.
6-8 یک نمودار خط شنا برای یک یا چند جنبه از PHTRS ایجاد کنید.
7-8 یک مدل مبتنی بر گروه، برای سیستم PHTRS ارائه شده در قسمت 3-8 ایجاد کنید.
8-8 مجموعه کاملی از کارت های شاخص مدل CRC را روی محصول یا سیستمی که به عنوان بخشی از قسمت 3-8 انتخاب کرده اید، تهیه کنید.
9-8 کارت های شاخص CRC را با همکاران خود بررسی کنید.در نتیجه بررسی، چند طبقه، مسئولیت و همکار،اضافه شدند؟
10-8 نمودار توالی چه تفاوت‌ها و شباهت‌هایی با نمودار وضعیت دارد؟
فصل نهم: مفاهیم طراحی
نگاهی سریع
مفاهیم طراحی چه هستند؟ طراحی کاری است که تقریباً هر برنامه سازی می خواهد انجام دهد.در طراحی، قوانین خلاقیت، الزامات و بررسی‌های فنی، در قالب فرمول بندی یک محصول یا سیستم، در کنار یکدیگر جمع می شوند. طراحی نمایش یا مدلی از نرم افزار ایجاد می کند و جزئیاتی در مورد معماری نرم افزار، ساختار داده، رابط و اجزای لازم برای پیاده سازی سیستم را ارائه می دهد.
چه کسی مسئول این کار است؟ مهندسان نرم افزار، هر یک از وظایف طراحی را در حین ادامه
ارتباط با سهامداران، انجام می دهند.
اهمیت مفاهیم طراحی در چیست؟ در مرحله طراحی،
شما مدلی از سیستم یا محصول در حال ساخت تهیه می کنید.قبل از کدنویسی، انجام آزمایش و مشارکت جزوه برنامه سازی سیستم نهایی، می توان کیفیت مدل طراحی را ارزیابی کرد و آن را ارتقا داد.
مراحل کار چیست؟ در طراحی، از چندین نمای مختلف نرم افزار استفاده می شود. ابتدا، معماری سیستم یا محصول باید مدل سازی شود. سپس، رابط هایی که نرم افزار را به کاربران نهایی، سایر سیستم ها و دستگاه ها و به اجزای خود متصل می کنند، نشان داده می شوند. در نهایت، اجزای نرم افزاری مورد استفاده برای ساخت سیستم، طراحی می شوند.
محصولات این کار، چیست؟ یک مدل برنامه سازی ، که شامل نمایشی از معماری، رابط، اجزا، و استقرار محصول اصلی کار است که در حین طراحی نرم افزار، تولید می شود.
چگونه از صحت انجام کار، اطمینان حاصل کنم؟ مدل طراحی توسط تیم نرم افزار (از جمله سهامداران مربوطه) ارزیابی می شود تا تعیین شود که آیا دارای خطا، ناسازگاری یا حذف می باشد یا خیر؛ آیا جایگزین های بهتری وجود دارد؛ و اینکه آیا این مدل را می توان در محدودیت ها، و مطابق برنامه و هزینه ای که قبلاً برآورد شده است، پیاده سازی کرد یا خیر.
اساس مهندسی نرم افزار موفق، طراحی است. برخی از توسعه دهندگان وسوسه می شوند تا پس از ایجاد موارد کاربری، بدون در نظر گرفتن نحوه ارتباط اجزای نرم افزاری مورد نیاز برای پیاده سازی موارد کاربری با یکدیگر، شروع به برنامه نویسی کنند. با ایجاد چندین افزونه نرم افزاری، می توان برنامه سازی و تحلیل، طراحی و پیاده سازی را انجام داد. نادیده گرفتن نکات طراحی مورد نیاز جهت ایجاد معماری مناسب برای محصول نرم افزاری در حال توسعه، ایده بدی است. بدهی فنی، مفهومی در توسعه نرم جزوه برنامه سازی سیستم است که به هزینه های مربوط به کار مجدد ناشی از انتخاب راه حل “راحت و بی دردسر”، به جای استفاده از رویکرد بهتر که زمان بیشتری می برد، اشاره دارد. هنگام ساخت تدریجی یک محصول نرم افزاری، نمی توان از ایجاد بدهی فنی جلوگیری کرد. با این حال، یک تیم توسعه خوب، باید تلاش کند تا این بدهی فنی را با اصلاح مجدد نرم افزار (بخش 9-3-9)، به طور منظم پرداخت کند. درست مانند گرفتن وام، می توانید تا زمان برنامه سازی وام صبر کنید و مقدار زیادی از بهره آن را بپردازید، یا می توانید کمی از وام را پرداخت کنید و در کل، سود کمتری بپردازید. یکی از راهکارهای کنترل بدهی فنی بدون تأخیر در برنامه نویسی، استفاده از شیوه های طراحی جزوه برنامه سازی سیستم و همگرا می باشد. تنوع، به شناسایی گزینه های طراحی احتمالی پیشنهاد شده توسط اجزای مدل الزامات کمک می کند. منظور از همگرایی، فرایند ارزیابی و رد گزینه های طراحی است که محدودیت های اعمال شده توسط الزامات غیرعملی تعریف شده برای راه حل نرم افزار را برآورده نمی کنند. تنوع و همگرایی :(1) شهود و قضاوت را براساس تجربه در ایجاد واحدهای مشابه، با یکدیگر ترکیب می کنند، (2) مجموعه ای از اصول و/یا ابتکارات راهنمای سیر تکامل مدل را با هم ترکیب می کنند، (3) مجموعه ای از معیارها را مهیا می کنند که کیفیت را به حدی می‌رسانند که بتواند مورد قضاوت قرار بگیرد و (4) با ایجاد فرآیندی تکراشونده، نهایتاً منجر به نمایش یک طرح نهایی می شوند. هنگامی که یک جایگزین طراحی مناسب از این طریق مشخص شد، توسعه دهندگان در موقعیت خوبی برای ایجاد افزونه نرم افزاری قرار می گیرند و احتمالاً نمونه اولیه، دور ریختنی نخواهد بود. طراحی نرم افزار، با تکامل روش های جدید، تجزیه و تحلیل بهتر و درک گسترده تر، به طور مداوم تغییر می کند. حتی امروزه، اکثر روش های طراحی نرم افزار فاقد عمق، انعطاف پذیری و ماهیت کمی هستند، که معمولاً با رشته های طراحی مهندسی قدیمی‌تر مرتبط است. با این حال، روش هایی برای طراحی نرم افزار وجود دارد، معیارهایی برای کیفیت طراحی موجود است و می توان از علامت طراحی نیز استفاده کرد. در این فصل، مفاهیم و اصولی اساسی قابل استفاده برای همه نوع طراحی نرم افزار ، اجزای مدل طراحی و تأثیر الگوها بر روند طراحی را بررسی می کنیم. در فصل های 10 تا 14، انواع مختلفی از روش های طراحی نرم افزار و نحوه اجرای آن‌ها برای طراحی معماری، رابط و اجزا و رویکردهای طراحی مبتنی بر الگو، تلفن همراه و تجربه کاربر، ارائه می شود.
طراحی در چارچوب مهندسی نرم افزار
طراحی نرم افزار در هسته فنی مهندسی نرم افزار قرار دارد و صرف نظر از مدل فرآیند نرم برنامه سازی مورد استفاده، اعمال می شود.پس از تجزیه و تحلیل الزامات نرم افزار و مدل سازی آن‌ها، طراحی نرم افزار، آخرین اقدام مهندسی نرم افزار در فعالیت مدل سازی است و زمینه را برای ساخت و ساز(تولید و آزمایش کد)، آماده می کند. هر یک از عناصر مدل الزامات (فصل 8) اطلاعات لازم برای ایجاد چهار مدل طراحی مورد نیاز برای ذکر کامل مشخصات طرح را ارائه می دهند. جریان اطلاعات در حین طراحی نرم افزار در تصویر 1-9 نشان داده شده است. مدل الزامات نشان داده شده با اجزای مبتنی بر فیلمنامه و مبتنی بر گروه، به طراحی کمک می کند.در طراحی، با استفاده از نماد طراحی و روش های طراحی مطرح شده در فصل های بعدی، یک طراحی داده/طبقه، طراحی معماری، طراحی رابط و طرحی از اجزا تولید می شود. طراحی داده/طبقه، مدل های طبقه (فصل 8) را به مفاهیم طبقه طراحی و ساختارهای داده مورد نیاز برای پیاده سازی نرم افزار تبدیل می کند. اشیاء و روابط تعریف شده در مدل CRC و محتوای داده های دقیق ترسیم شده توسط ویژگی های طبقه و سایر نشانه ها، اساس فعالیت طراحی داده را فراهم می کنند. بخشی از طراحی طبقه، می تواند همراه با طراحی معماری نرم افزار رخ دهد. با طراحی هر جزء نرم افزاری ، طبقه با جزئیات بیشتری طراحی می شود. طراحی معماری، رابطه بین عناصر ساختاری اصلی نرم افزار، سبک معماری و الگوهای مورد استفاده برای دستیابی به
الزامات تعریف شده برای سیستم (فصل 14)، و محدودیت های مؤثر بر معماری قابل اجرا، را مشخص می کند. بازنمایی طراحی معماری ( چارچوب یک سیستم مبتنی بر رایانه)، از مدل الزامات مشتق شده است. طراحی رابط، نحوه ارتباط نرم افزار با سیستم‌های در تعامل با آن و افرادی که از آن استفاده می کنند، را توضیح می دهد. یک رابط به جریان اطلاعات (به عنوان مثال، داده ها و/یا کنترل) و نوع خاصی از برنامه سازی ، دلالت دارد. بنابراین ، فیلمنامه های کاربری و مدل های کارکردی، بسیاری از اطلاعات مورد نیاز برای طراحی رابط را ارائه می دهند. طراحی انجام شده در سطح اجزاء، عناصر ساختاری معماری نرم افزار را به یک جزوه برنامه سازی سیستم رویه ای از اجزای نرم افزار تبدیل می کند. اطلاعات به‌دست آمده از مدل های مبتنی بر طبقه و مدل های کارکردی، به عنوان پایه ای برای طراحی اجزا عمل می کنند.

دانلود رایگان خلاصه کتاب برنامه سازی سیستم PDF

در طول طراحی، تصمیماتی گرفته می شود که در نهایت، بر موفقیت ساخت نرم افزار و سهولت حفظ نرم افزار تأثیر می گذارد. اما چرا طراحی اینقدر مهم است؟ اهمیت طراحی نرم افزار را می توان با کلمه “کیفیت”، بیان کرد.در طراحی، کیفیت توسط مهندسی نرم افزار تقویت می شود و نرم افزارهایی ارائه می شوند که از نظر کیفیت، قابل ارزیابی هستند. طراحی، تنها راه
تبدیل الزامات سهامداران، به یک محصول نرم افزاری یا سیستم کامل است. طراحی نرم افزار، به عنوان پایه ای برای تمام اقدامات مهندسی نرم افزار و فعالیت های پشتیبانی نرم افزاری که در ادامه جزوه برنامه ریزی تولید می شود، محسوب می شود. بدون طراحی، احتمال ساخت یک سیستم ناپایدار ( برنامه سازی که در صورت ایجاد تغییرات کوچک، از کار می افتد؛ آزمایش آن دشوار است؛ و کیفیت آن تا اواخر فرآیند نرم افزار، قابل ارزیابی نیست)، وجود خواهد داشت.منظور از اواخر
پروژه، موقعی است که زمان کوتاه است و بسیاری از بودجه‌ها صرف انجام امور شده‌اند.

“خانه‌ی امن: طراحی در مقایسه با برنامه نویسی”
صحنه: اتاقک جیمی، همزمان با آماده شدن تیم برای ترجمه الزامات در قالب طراحی.
گفتگوکنندگان: جیمی، وینود و اد، همگی از اعضای تیم مهندسی نرم افزار SafeHome.
مکالمه:
جیمی: می دونی داگ ]مدیر تیم[ روی طراحی وسواس داره. بذار روراست باشم، کاری که عاشقشم کدنویسیه، اگه بهم C++ یا جاوا بدن، خوشحال می‌شم.
اد: نه…تو طراحی رو دوست داری.
جیمی: اصلاً به حرفام گوش نمی‌دی.من عاشق کدنویسیم.
وینود: فکر کنم منظور اد اینه که تو واقعاً کدنویسی رو دوست نداری؛ تو دوست داری طراحی کنی و اون رو به صورت کد، نشون بدی.کد، زبانیه که برای نشون دادن طرح، استفاده می کنی.
جیمی: خب، اشکالش چیه؟
وینود: سطح انتزاع.
جیمی: چی؟
اد: یه زبان برنامه نویسی برای نمایش جزئیاتی مثل ساختار داده ها و الگوریتم ها خوبه، اما برای نمایش معماری یا همکاری جزء به جزء و چیزهایی مثل اون، چندان خوب نیست.
وینود: و یه معماری پیچیده میتونه حتی بهترین کد رو جزوه برنامه سازی سیستم کند.
جیمی (یک دقیقه فکر می کند): بنابراین، دارین میگین که من نمی تونم معماری رو در قالب کد نشون بدم…این درست نیست.
وینود: مطمئناً میتونی معماری رو در قالب کد نمایش بدی، اما در بیشتر زبان‌های برنامه نویسی، خوندن سریع و دقیق معماری با بررسی کد، سخته.
اد: و این همون چیزیه که ما قبل از شروع کد نویسی می خوایم.
جیمی: باشه، شاید طراحی و کد نویسی متفاوت باشن، اما من هنوز برنامه نویسی رو بیشتر دوست دارم.

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

1-2-9 دستورالعمل ها و ویژگی های کیفیت نرم افزار
در طول فرایند طراحی، کیفیت طرح در حال تکامل با مجموعه ای از بررسی های فنی مورد بحث در فصل 16، ارزیابی می شود. مک گلاگلین، سه ویژگی که به عنوان راهنمای ارزیابی یک طرح، خوب عمل می کنند را پیشنهاد می کند:
• طراحی باید تمام الزامات صریح موجود در مدل الزامات را اجرا کند، و باید تمام الزامات ضمنی مورد نظر سهامداران را برآورده کند.
• طرح، باید راهنمایی خوانا و قابل درک برنامه نویسان و برنامه سازی  آزمایش و پشتیبانی از نرم افزار، باشد.
• در طراحی باید یک تصویر کامل از نرم افزار ارائه شود و داده ها، حوزه های عملکردی و کارکردی از دیدگاه اجرایی باید مشخص شوند.
هر یک از این ویژگی ها، یکی از اهداف فرایند طراحی است. اما هر کدام از این اهداف، چگونه برآورده می شوند؟
دستورالعمل کیفیت: برای ارزیابی کیفیت نمای طراحی، شما و سایر اعضای تیم نرم افزار باید معیارهای فنی یک طراحی خوب را تعیین کنید. در بخش 3-9، مفاهیم طراحی را که به عنوان معیارهای کیفیت نرم افزار عمل می کنند، مورد بحث قرار می دهیم. در حال حاضر ، دستورالعمل های زیر را در نظر بگیرید:
1. یک طرح باید معماری را نشان دهد که: (الف) با استفاده از سبک ها یا الگوهای جزوه برنامه سازی سیستم قابل تشخیص، ایجاد شده باشد، (ب) از اجزای تشکیل شده باشد که ویژگی های یک طراحی خوب را نشان می دهند( بعداً در این فصل مورد بحث قرار می گیرند)، و (ج) بتوان آن را به صورت تکاملی پیاده سازی کرد، و در نتیجه، پیاده سازی و آزمایش آن را تسهیل کرد.
2. یک طرح باید ساختاریافته باشد. یعنی نرم افزار باید به طور منطقی، به اجزا یا زیر سیستم ها تقسیم شود.
3. یک طرح باید شامل نماهایی متمایز از داده ها، معماری، رابط ها و اجزاء باشد.
4. یک طراحی باید منجر به ایجاد ساختار داده هایی شود که برای اجرای طبقات، مناسب باشد و از الگوهای داده قابل برنامه سازی ، گرفته شده باشد.
5. یک طراحی باید به ساخت اجزایی منجر شود که مشخصات عملکردی مستقلی از خود نشان دهند.
6. یک طراحی باید به رابط هایی منجر شود که پیچیدگی اتصالات بین اجزاء و با محیط خارجی را کاهش دهند.
7. یک طرح، باید با استفاده از یک روش تکرار شونده که توسط اطلاعات به دست آمده در طول تجزیه و تحلیل الزامات نرم افزاری هدایت می شود، گرفته شود.
8. یک طرح، باید با استفاده از نمادی نشان داده شود که به طور مؤثر با هدف آن، در ارتباط باشد.
تنها بر حسب شانس، نمی توان به این دستورالعمل های طراحی دست یافت.بلکه با استفاده از اصول اساسی طراحی، روشی سیستماتیک و کامل و از طریق بررسی، می توان به آن دست یافت.
دانستنی‌ها: ارزیابی کیفیت طراحی -بررسی فنی
اهمیت طراحی در این است که اجازه می دهد تا یک تیم نرم افزاری به ارزیابی کیفیت نرم افزار قبل از اجرای آن، بپردازد و هنگامی که تصحیح خطاها، حذف ها یا ناسازگاری ها آسان و کم هزینه است، به انجام آن اقدام کنند. اما ارزیابی کیفیت در طول طراحی چگونه انجام می شود؟ در این مرحله، امکان آزمایش نرم افزار وجود ندارد، زیرا هیچ نرم افزار اجرایی برای آزمایش وجود ندارد. چه باید کرد؟ در طول طراحی، می توان با انجام یک سری بررسی های فنی (TR)، کیفیت را ارزیابی کرد. TR ها به تفصیل در فصل 4 و 16 مورد بحث قرار گرفته اند، اما بد نیست در اینجا نیز خلاصه‌ای از این تکنیک برنامه سازی  کنیم. بررسی فنی، جلسه ای است که توسط اعضای تیم نرم افزاری انجام می شود و معمولاً بسته به محدوده اطلاعات طراحی مورد بررسی، دو، سه یا چهار نفر،
در آن شرکت می کنند. هر شخص در جلسه، نقشی ایفا می کند. رهبر جلسه، برای برگزاری آن برنامه ریزی می کند، دستور کار را تعیین می کند و جلسه را اداره می کند. مسئول ضبط، همه چیز را یادداشت می کند تا مطلبی از قلم نیفتد، و تهیه کننده، شخصی است که
محصول کارش (به عنوان مثال، طراحی یک جزء نرم افزاری) در حال بررسی است. قبل از جلسه ،
به هر یک از اعضای تیم بازبینی، یک نسخه از جزوه برنامه سازی سیستم کار طراحی داده می شود و از او خواسته می شود تا آن را بخواند، و به دنبال خطاها، حذف ها یا ابهامات بگردد. با شروع جلسه، هدف این است که همه مشکلات با محصول کار، یادداشت شود، تا بتوان قبل از شروع اجرا، آن‌ها را اصلاح کرد. TR معمولاً بین 60 تا 90 دقیقه طول می کشد. پس از پایان TR ، تیم بازبینی تعیین می کند که آیا قبل از تأیید محصول کار طراحی، اقدامات بیشتری از طرف تولید کننده، به عنوان بخشی از مدل طراحی نهایی، مورد نیاز است یا خیر.

2-2-9 تکامل طراحی نرم افزار
تکامل طراحی نرم افزار یک فرایند مستمر است که اکنون بیش از شش دهه می شود که گسترش یافته است. کار طراحی اولیه بر معیارهای برنامه ها و روش های ساختاریافته جهت اصلاح ساختار نرم افزار به شیوه “ساختار یافته” از بالا به پایین، متمرکز است. رویکردهای طراحی جدیدتر، رویکردی شیء گرا را برای استخراج طراحی پیشنهاد می کنند. اخیراً در طراحی نرم افزار، بر معماری نرم افزار و الگوهای طراحی قابل استفاده برای پیاده سازی معماری نرم افزار و سطوح پایین انتزاعات طراحی، تأکید می شود. امروزه بر روش هاي جهت دار، توسعه‌های مدل محور و توسعه مبتنی بر ً () ‌‌: () () ‌() ()