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

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

دانلود فایل

در زمینه مدل سازی کارکردی، دو توصیف متفاوت از وضعیت، باید در نظر گرفته علمی کاربردی: (1) وضعیت هر طبقه هنگام عملکرد سیستم و (2) وضعیت بیرونی سیستم، هنگام عملکرد سیستم. وضعیت یک طبقه، هم ویژگی های منفعل و هم فعال را در بر می‌گیرد.جزوه برنامه سازی سیستم منفعل، همان مقادیر فعلی است که به ویژگی های یک شیء، اختصاص داده علمی کاربردی. وضعیت فعال یک شیء، وضعیت آن را تحت تحول یا پردازش مداوم، نشان استاد. یک رویداد (گاهی اوقات، محرک نامیده علمی کاربردی) باید اتفاق بیفتد تا یک شیء را مجبور به انتقال از یک وضعیت فعال، به وضعیتی دیگر لینک.
نمودارهای وضعیت دانشگاه طبقات تجزیه و تحلیل: یکی از اجزای یک مدل برنامه سازی، یک نمودار وضعیت UML است که نشان دهنده حالات فعال دانشگاه هر طبقه و رویدادهایی (محرک هایی) است که باعث تغییر بین این حالت های فعال هستم.تصویر 8-8، یک نمودار وضعیت را دانشگاه شیء صفحه کنترل در عملکرد امنیتی SafeHome نشان استاد. هر پیکان نشان داده شده در تصویر 8-8، نشان دهنده انتقال یک شیء، از یک وضعیت فعال، به جزوه برنامه سازی سیستم دیگر است. برچسب های نشان داده شده دانشگاه هر پیکان، نشان دهنده رویدادی است که منجر به انتقال وضعیت علمی کاربردی. اگرچه مدل حالت فعال، بینش مفیدی را در مورد “تاریخچه زندگی” یک شیء ارائه استاد، می توان اطلاعات بیشتری را دانشگاه درک بهتر کارکرد یک شیء، مشخص کرد. علاوه بر مشخص شدن رویدادی که منجر به وقوع انتقال علمی کاربردی، می توانید یک محافظ و یک عمل را نیز مشخص دارد.منظور از محافظ، یک شرایط گزاره‌ای است، که دانشگاه ایجاد انتقال باید رعایت علمی کاربردی. به عنوان مشکل، محافظ مربوط به انتقال از حالت “خواندن” به حالت “مقایسه” را در تصویر 8-8، می توان با بررسی مورد کاربری مشخص کرد:
پس از ورود رمز 4 رقمی، باید آن را با رمز ذخیره شده مقایسه کرد.
به طور کلی ، محافظ مربوط به انتقال، معمولاً به مقدار یک یا چند ویژگی مربوط به یک شیء، بستگی را.به عبارت دیگر، محافظ، به وضعیت منفعل شیء بستگی را. هر عمل، همزمان با تغییر وضعیت، یا به دنبال آن، رخ استاد و به طور کلی شامل یک یا چند عملیات (مسئولیت) شیء است. به عنوان مشکل، عمل متصل به رویداد ورود رمز عبور، (تصویر 8-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)، و محدودیت های مؤثر بر معماری قابل اجرا، را مشخص لینک. بازنمایی طراحی معماری ( چارچوب یک سیستم مبتنی بر رایانه)، از مدل الزامات مشتق شده است. طراحی رابط، نحوه ارتباط نرم افزار با سیستم‌های در تعامل با آن و افرادی که از آن استفاده هستم، را توضیح استاد. یک رابط به جریان اطلاعات (به عنوان مشکل، داده ها و/یا کنترل) و نوع خاصی از برنامه سازی ، دلالت را. بنادانشگاهن ، فیلمنامه های کاربری و مدل های کارکردی، بسیاری از اطلاعات مورد نیاز دانشگاه طراحی رابط را ارائه دارد. طراحی مشکل شده در سطح اجزاء، عناصر ساختاری معماری نرم افزار را به یک جزوه برنامه سازی سیستم رویه ای از اجزای نرم افزار تبدیل لینک. اطلاعات به‌دست آمده از مدل های مبتنی بر طبقه و مدل های کارکردی، به عنوان پایه ای دانشگاه طراحی اجزا عمل هستم.

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

“خانه‌ی امن: طراحی در مقایسه با برنامه نویسی”
صحنه: اتاقک جیمی، همزمان با آماده شدن تیم دانشگاه ترجمه الزامات در قالب طراحی.
گفتگوکنندگان: جیمی، وینود و اد، همگی از اعضای تیم مهندسی نرم افزار 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 تکامل طراحی نرم افزار
تکامل طراحی نرم افزار یک فرایند مستمر است که اکنون بیش از شش دهه علمی کاربردی که گسترش یافته است. کار طراحی اولیه بر معیارهای برنامه ها و روش های ساختاریافته جهت اصلاح ساختار نرم افزار به شیوه “ساختار یافته” از بالا به پایین، متمرکز است. رویکردهای طراحی جدیدتر، رویکردی شیء گرا را دانشگاه استخراج طراحی پیشنهاد هستم. اخیراً در طراحی نرم افزار، بر معماری نرم افزار و الگوهای طراحی قابل استفاده دانشگاه پیاده سازی معماری نرم افزار و سطوح پایین انتزاعات طراحی، تأکید علمی کاربردی. امروزه بر روش هاي جهت دار، توسعه‌های مدل محور و توسعه مبتنی بر آزمایش، که بر تکنیک های مؤثرتر سازمان دهی و ایجاد ساختار معماری در طرح های ایجاد برنامه سازی ، تمرکز لینک، شدیداً تأكيد علمی کاربردی. در 10 سال گذشته، تکنیک های مهندسی نرم افزار مبتنی بر جستجو(SBSE) دانشگاه همه مراحل چرخه عمر مهندسی نرم افزار، از جمله طراحی، کاربردی خلاصهه است. SBSE تلاش لینک تا ممشکلات مهندسی نرم افزار را با استفاده از تکنیک های جستجوی خودکار تقویت شده توسط تحقیقات عملیاتی و الگوریتم های یادگیری ماشین، حل لینک. بسیاری از سیستم های نرم افزاری مدرن باید درجه بالایی از تنوع را، هم در محیط استقرار و هم در تعداد جزوه برنامه سازی سیستم کاربری، در بر گیرند. طراحی متغیرهای سیستم‌های در حال تغییر، توسعه دهندگان را ملزم به پیش بینی تغییرات آینده در ویژگی هایی لینک که در برنامه سازی های بعدی محصول طراحی شده اعمال علمی کاربردی. بحث مفصل در مورد طراحی سیستم های متغیر، خارج از محدوده این کتاب است. چندین روش طراحی پیشرفته در اثر امور ذکر شده، در سراسر صنعت مورد استفاده قرار می گیرند. مانند روش های تجزیه و تحلیل ارائه شده در فصل 8، هر یک از روش های طراحی نرم افزار، ابتکارات و نشانه های منحصر به فرد و همچنین، نمایی تا حدی کلیشه‌ای از ویژگی های کیفیت طراحی را ارائه استاد. با این حال، هر یک از این روش ها دارای ویژگی های مشترکی هستم: (1) ساز و کاری دانشگاه تبدیل مدل الزامات به نمایشی از طراحی، (2) نمادی دانشگاه نمایش اجزای عملکردی و رابط های آن‌ها، (3) روش های اکتشافی دانشگاه اصلاح و تقسیم بندی، و (4) دستورالعمل های ارزیابی کیفیت. صرف نظر از روش طراحی مورد استفاده، باید مجموعه ای از اصول اولیه، در مفاهیم داده، معماری، رابط و طراحی اجزاء، اعمال علمی کاربردی. این مفاهیم در بخش های بعدی بررسی شده است.