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