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