نمونه سوالات مهندسی نرم افزار همراه جواب تشریحی

سوالات مهندسی نرم افزار

فرمت پی دی اف

همراه پاسخ تشریحی

دانلود فایل

استخدامی علمی کاربردی دانشگاه پیام نور کارشناسی ارشد پرسمن

اصلاح گام به گام، یک استراتژی طراحی از ‌‌()، ‌()، () “()” –()، () : “‌[طرح] ” خودکار تغییرات کد و “ایجاد یک مجموعه آزمایشی مناسب برای تشخیص تغییرات کارکردی، استفاده می شوند.”

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

نمونه سوالات

10-3-9 طبقات طراحی
مدل تجزیه و تحلیل، مجموعه ای از کلاس های تجزیه و تحلیل را تعریف می کند (فصل 8). هر یک از این طبقات، برخی از عناصر فضای مشکل را توضیح می دهد و بر جنبه های قابل مشاهده مشکل توسط کاربر، تمرکز می کند. سطح انتزاع طبقه تجزیه و تحلیل، نسبتاً بالا است. همزمان با تکامل مدل طراحی، مجموعه ای از طبقات طراحی را تعریف خواهید کرد که با ارائه جزئیات طراحی اجراکننده طبقات و سازنده زیرساخت نرم افزاری پشتیبان راه حل تجاری، طبقات تجزیه و تحلیل را اصلاح می کنند. با شکل گیری معماری نرم افزار، سطح انتزاع هر یک کاهش می یابد؛ چرا که طبقه تجزیه و تحلیل (فصل 8)، به نمایشی از طراحی تبدیل می شود. به عبارت دیگر، طبقه تجزیه و تحلیل، نمایانگر اشیاء داده و خدمات مرتبط با آن‌ها خواهد بود. طبقات طراحی، جزئیات فنی بیشتری را به عنوان راهنمای پیاده سازی ارائه می دهند. آرلو و نوستاد، پیشنهاد می کنند که برای اطمینان از تشکیل صحیح طبقه طراحی، آن را مورد بازبینی قرار دهید.آن‌ها همچنین، چهار ویژگی یک طبقه طراحی که درست تشکیل یافته را تعریف می کنند:
کامل و کافی بودن: یک طبقه طراحی، باید چکیده‌ای کامل از همه ویژگی ها و روش هایی که می توان به طور منطقی انتظار داشت (بر اساس دانش تفسیر نام طبقه)، تا در طبقه موردنظر وجود داشته باشد، ارائه دهد. به عنوان مثال، طبقه FloorPlan (تصویر 3-9)، که برای نرم افزار چیدمان اتاق SafeHome تعریف شده است، تنها در صورتی کامل خواهد بود که شامل تمام ویژگی ها و روش های مرتبط با طرح طبقه باشد. همچنین باید تضمین شود که طبقه طراحی، فقط شامل
روش‌های لازم برای دستیابی به هدف طبقه باشد، نه بیشتر و نه کمتر.
ابتدایی بودن: روش های مرتبط با طبقه طراحی، باید روی انجام خدماتی برای طبقه موردنظر، متمرکز شوند. با اجرای خدمات با روش موردنظر،
طبقه مذکور نباید راه دیگری برای انجام این کار، ارائه دهد. به عنوان مثال، بخشی از طبقه (تصویر 3-9) که مورد استفاده نرم افزار چیدمان اتاق قرار می گیرد، می تواند برای نشان دادن نقاط شروع و پایان بخش مورد نظر، دارای ویژگی های startCoordinate و endCoordinate باشد.روش setCoordinates () تنها وسیله ای را برای تعیین نقاط شروع و پایان بخش فراهم می کند.
انسجام بالا: یک طبقه طراحی منسجم، دارای مجموعه ای کوچک و متمرکز از مسئولیت ها است و به صورت یک جانبه، این ویژگی ها و روش ها را برای پیاده سازی آن مسئولیت ها به کار می گیرد. به عنوان مثال، طبقه FloorPlan (تصویر 3-9)، می تواند مجموعه ای از روش های ویرایش نقشه طبقه خانه را شامل شود. تا زمانی که هر روش، صرفاً بر ویژگی های مرتبط با طرح طبقه تمرکز کند، انسجام حفظ می شود.
تصویر 3-9
اتصال پایین: در مدل طراحی، لازم است که طبقات طراحی، با یکدیگر همکاری کنند. با این حال، همکاری باید در کمترین حد قابل قبولی، حفظ شود. اگر قابلیت اتصال یک مدل طراحی بسیار بالا باشد (همه طبقات طراحی با سایر طبقات طراحی همکاری می کنند)، پیاده سازی، آزمایش و نگهداری سیستم در طول زمان، دشوار خواهد بود. به طور کلی، طبقات طراحی در یک سیستم فرعی، باید تنها آگاهی محدودی از سایر طبقات، داشته باشد. این محدودیت ، که قانون دمیتر نامیده می شود، بیان می کند که یک روش، تنها باید به روش های طبقات مجاور، پیام ارسال کند.

“خانه‌ی امن: اصلاح یک طبقه تجزیه و تحلیل، به یک طبقه طراحی”
صحنه: اتاقک اد، همزمان با شروع مدل سازی طراحی.
گفتگوکنندگان: وینود و اد، اعضای
تیم مهندسی نرم افزار SafeHome.
مکالمه:
[اد روی طبقه FloorPlan کار می کند (مبحث فرعی در بخش 3-3-8 و تصویر 4-8 را ببینید) و آن را برای مدل طراحی اصلاح کرده است.]
اد: خب، طبقه FloorPlan رو یادتونه، درسته؟ از این طبقه، به عنوان بخشی از نظارت و عملکردهای مدیریت خانه استفاده میشه.
وینود (سر تکان می دهد): درسته، فکر می کنم یادمه که ازش به عنوان بخشی از بحث CRC برای مدیریت خانه استفاده کردیم.
اد: درسته، در هر صورت، دارم برای طراحی اصلاحش می کنم.می خوام نحوه پیاده سازی طبقه FloorPlan رو نشون بدم.به نظرم بهتره تحت عنوان مجموعه‌ای از فهرست های پیوندی [یک ساختار داده خاص]،
اجراش کنیم. بنابراین باید طبقه تحلیل FloorPlan (تصویر 4-8) رو اصلاح کنم و به نوعی تسهیلش کنم.
وینود: طبقه تجطیه و تحلیل، فقط مسائل مربوط به فضای مشکل رو ارائه کرد، خب در واقع، این مسائل، روی صفحه رایانه برای کاربر نهایی قابل مشاهده بود، درسته؟
اد: بله، اما در مورد طبقه طراحی FloorPlan، باید موارد خاصی رو به پیاده سازیش اضافه کنم.باید نشون می دادم که FloorPlan، مجموعه ای از بخش هاست (طبقه Segment)، و طبقه Segment، از فهرست هایی برای بخش های دیوار، پنجره ها، درها و غیره تشکیل شده. طبقه Camera (دوربین)،
با FloorPlan همکاری می کنه، و بدیهیه که ممکنه دوربین های زیادی در نقشه ساختمون وجود داشته باشن.
وینود: اوه، بیا تصویری از این طبقه طراحی FloorPlan جدید رو ببینیم. (اد، طرح نشان داده شده در تصویر 3-9 را به اد نشان می دهد.)
وینود: خب، می دونم چکار باید کرد؛ و با انجام این کارها، تغییر نقشه ساختمون خیلی ساده میشه، چون می تونیم موارد جدیدی رو به فهرست، اضافه یا ازش کم کنیم، و نمونه سوالات مهندسی نرم افزار هم پیش نمیاد.
اد (سر تکان می دهد): بله، فکر می کنم این کار، شدنیه.
وینود: من هم همینطور.

4-9 مدل طراحی
مدل طراحی نرم افزار، معادل طرح های یک معمار برای یک خانه است و ساخت آن، با نشان دادن کلیت چیزی که باید ساخته شود (به عنوان مثال، نمایی سه بعدی از خانه)، شروع می شود و با اصلاح تدریجی، راهنمایی برای ساخت جزئیات (به عنوان مثال، طرح لوله کشی)، ایجاد می شود. به طور مشابه، مدل طراحی ایجاد شده برای نرم افزار، دیدگاه های مختلفی از سیستم را ارائه می دهد.

دانلود رایگان تست پی دی اف نمونه سوالات مهندسی نرم افزار + پاسخ تشریحی PDF با جواب

مطابق تصویر 4-9، مدل طراحی را می توان در دو بعد مختلف مشاهده کرد. بعد فرآیند، نشان دهنده تکامل مدل طراحی را حین اجرای وظایف طراحی، به عنوان بخشی از فرایند نرم افزار، نشان می دهد. بعد انتزاعی، سطح جزئيات را همزمان با تغيير هر جزء مدل تحليل، و تبدیل آن به یک طرح معادل و سپس اصلاح تکراشونده آن را نشان مي دهد. با اشاره به تصویر، خط تیره، مرز بین مدل های تحلیل و طراحی را نشان می دهد. در برخی در موارد، تمایز بین مدل های تحلیل و طراحی، امکان پذیر است. در سایر موارد، مدل تجزیه و تحلیل به آرامی با طرح ترکیب می شود و تمایز کمتری بین آن‌ها به چشم می خورد.
عناصر مدل طراحی از بسیاری از نمودارهای UML مشابه مورد استفاده در مدل تجزیه و تحلیل استفاده می کنند. تفاوت در این است که این نمودارها به عنوان بخشی از طراحی، اصلاح و استخراج شده‌اند؛ جزئیات بیشتری در رابطه با پیاده سازی ارائه شده است، و بر و ساختار و سبک معماری، اجزای موجود در معماری، و رابط بین اجزاء و با دنیای خارج، تأکید شده است. با این حال ، باید توجه داشته باشید که اجزایی از مدل که در امتداد محور افقی نشان داده شده اند، همیشه به صورت متوالی توسعه نمی یابند. در بیشتر موارد، طراحی اولیه معماری، مراحل کار را تنظیم می کند و سپس طراحی رابط و طراحی، که اغلب در یک راستا رخ می دهد، انجام می شود. مدل استقرار معمولاً به تأخیر می افتد تا طراحی به طور کامل انجام شود. در هر مرحله از طراحی، می توانید الگوهای طراحی (فصل 14) را اعمال کنید. به کمک این الگوها، می توانید دانش طراحی را برای مشکلات مربوط به حوزه ای که دیگران با آن روبرو شده و حل کرده اند، به کار بگیرید.

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

سوالات نرم افزار

2-4-9 اجزای طراحی داده
مانند سایر فعالیت های مهندسی نرم افزار، طراحی داده ها (گاهی اوقات به عنوان معماری داده نیز نامیده می شود) نیز یک مدل از داده ها و/یا اطلاعات ایجاد می کند که در بالاترین سطح انتزاع(دیدگاه مشتری یا کاربر از داده ها)، نمایش داده می شود. سپس این مدل داده، اصلاح شده و به نماهای اجرایی در حال تکاملی تبدیل می شود که می تواند توسط سیستم های مبتنی بر رایانه، پردازش شود. در بسیاری از نرم افزارهای کاربردی، معماری داده ها تأثیر عمیقی بر معماری نرم افزار پردازنده آن دارد. ساختار داده ها همیشه بخش مهمی از طراحی نرم افزار بوده است. در سطح اجزاء برنامه، طراحی ساختارهای داده و الگوریتم های مرتبط لازم برای دستکاری آن‌ها، برای ایجاد برنامه های با کیفیت بالا، ضروری است. در سطح کاربرد، ترجمه یک مدل داده (به عنوان بخشی از مهندسی الزامات) به یک پایگاه داده، برای دستیابی به اهداف تجاری مهم است. در سطح تجاری، جمع آوری اطلاعات ذخیره شده در پایگاه های اطلاعاتی متفاوت و سازماندهی مجدد آن به “انبار داده”، امکان استخراج داده یا اطلاعات مؤثر بر موفقیت کسب و کار را فراهم می کند. در هر مور ،
طراحی داده ها نقش مهمی ایفا می کند. در مورد طراحی داده ها، جزئیات بیشتری در فصل 10 مطرح شده است.

3-4-9 عناصر طراحی معماری
طراحی معماری نرم افزار معادل نقشه ساختمان یک خانه است. نقشه ساختمان، طرح کلی اتاق ها را به تصویر می کشد؛ اندازه، شکل و رابطه آن‌ها با یکدیگر، و درها و پنجره هایی که به نمونه سوالات مهندسی نرم افزار و خارج اتاق ها باز می شوند را نشان می دهد نقشه طبقه نمای کلی خانه را نشان می دهد. طراحی معماری عناصر، یک دید کلی از نرم افزار ارائه می دهد. مدل معماری از سه منبع مشتق شده است: (1) اطلاعات مربوط به حوزه کاربردی نرم افزار در حال ساخت، (2) عناصر مشخصی از مدل الزامات، مانند موارد کاربری یا طبقات تجزیه و تحلیل، روابط و همکاری‌های آن‌ها برای مشکل موجود، و (3) در دسترس بودن سبک های معماری (فصل 10) و الگوها (فصل 14). عنصر طراحی معماری، معمولاً به عنوان مجموعه ای از زیر سیستم های به هم پیوسته به تصویر کشیده می شود که اغلب از بسته های تجزیه و تحلیل در مدل الزامات به دست می آید. هر زیر سیستم می تواند معماری خاص خود را داشته باشد (به عنوان مثال، یک رابط کاربری گرافیکی ممکن است با توجه به سبک معماری قبلی موجود برای رابط های کاربری، ساختار یافته باشد). در فصل 10، تکنیکی برای استخراج عناصر خاص مدل معماری ارائه شده است.

4-4-9 عناصر طراحی رابط
طراحی رابط کاربری نرم افزار، مشابه مجموعه ای از نقشه های دقیق (و مشخصات) برای دره ، پنجره ها و امکانات خارجی یک خانه است. نقشه های (و مشخصات) دقیق درها، پنجره ها و ابزارهای جانبی بیرونی، چگونگی جریان اشیاء و اطلاعات به داخل و خارج از خانه و در اتاق هایی که بخشی از نقشه ساختمان هستند را نشان می دهد. عناصر طراحی رابط برای نرم افزار، جریان اطلاعات به داخل و خارج از یک سیستم و نحوه ارتباط آن بین اجزایی که به عنوان بخشی از معماری تعریف شده‌اند را نشان می دهد. سه عنصر مهم در طراحی رابط وجود دارد: (1) رابط کاربری (UI)؛ (2) رابط های خارجی؛ به سایر سیستم ها، دستگاه ها، شبکه ها یا سایر تولید کنندگان یا مصرف کنندگان اطلاعات؛ و (3) رابط های داخلی بین اجزای مختلف طراحی. این عناصر طراحی رابط، به نرم افزار اجازه می دهد تا ارتباط خارجی داشته باشد و ارتباطات داخلی و همکاری بین اجزای اشغال کننده معماری نرم افزار را تسهیل می کنند. طراحی UI (که معمولاً UX یا طراحی تجربه کاربر نامیده می شود)، یک اقدام مهندسی نرم افزار اصلی است و به تفصیل در فصل 12 مورد بررسی قرار گرفته است. طراحی UX، بر اطمینان از قابلیت استفاده از طراحی UI تمرکز می کند. یک طراحی قابل استفاده، شامل عناصر ظریفی که با دقت انتخاب شده‌اند (به عنوان مثال، طرح، رنگ، گرافیک، طرح بندی اطلاعات)، عناصر ارگونومیک (به عنوان مثال، ساز و کارهای های تعامل، استقرار اطلاعات، استعاره ها، جهت یابی UI) و عناصر فنی (به عنوان مثال، الگوهای UX، اجزای قابل استفاده مجدد) می باشد. به طور کلی، UI، یک زیر سیستم منحصر به فرد در معماری کلی برنامه است که برای ارائه تجربه نهایی رضایت بخش به کاربر نهایی طراحی شده است. طراحی رابط های خارجی نیاز به اطلاعات قطعی در مورد ورودی دارد که اطلاعات، به آن ارسال یا از آن، دریافت می شود. در هر صورت، این اطلاعات باید در طول مهندسی الزامات (فصل 7) جمع آوری شده و همزمان با آغاز طراحی رابط، یکبار رابط، تأیید شود.در طراحی رابط های خارجی، باید بررسی خطا و ویژگی های امنیتی مناسب را در نظر گرفت. طراحی رابط های داخلی با طراحی اجزا (فصل 11) سازگار است.

تصویر 5-9
تحقق طراحی طبقات تجزیه و تحلیل، نشان دهنده تمام عملیات و طرح های پیام رسانی است که برای برقراری ارتباط و همکاری بین عملیات های طبقات مختلف، لازم است. هر پیام باید طوری طراحی شود که انتقال اطلاعات لازم و الزامات عملکردی خاص عملیات مورد نظر را در بر گیرد. در برخی موارد، یک رابط، تقریباً شبیه یک طبقه، مدل سازی می شود. رابط، مجموعه ای از عملیات‌هایی است که بخشی از کارکرد یک طبقه را توصیف می کند و دسترسی به این عملیات را فراهم می کند. به عنوان مثال ، عملکرد امنیتی SafeHome، از صفحه کنترلی استفاده می کند که به صاحب خانه اجازه می دهد تا ویژگی های خاصی از عملکرد امنیتی را کنترل کند. در یک نسخه پیشرفته از سیستم، عملکردهای صفحه کنترل ممکن است از طریق یک سیستم عامل تلفن همراه (به عنوان مثال، تلفن هوشمند یا رایانه لوحی)، اجرا شود و این موضوع، در تصویر 5-9 نشان داده شده است.

5-4-9 عناصر طراحی اجزاء
طراحی اجزاء برای نرم افزار، معادل مجموعه ای از نقشه های دقیق (و مشخصات) برای هر اتاق در یک خانه است. این نقشه ها، سیم کشی و لوله کشی داخل هر اتاق، محل پریزهای برقی و کلیدهای دیواری، شیرها، سینک ها، دوش ها، وان ها، فاضلاب ها، کابینت ها و کمد ها و سایر جزئیات مربوط به یک اتاق را نشان می دهند. طراحی اجزاء برای نرم افزار، به طور کامل جزئیات داخلی هر جزء نرم افزاری را توصیف می کند. برای این کار، طراحی اجزاء، ساختار داده ها را برای همه اشیاء داده داخلی و جزئیات الگوریتمی مربوط به همه پردازش های موجود در یک جزء را تعریف می کند و رابطی را فراهم می کند که امکان دسترسی به تمام عملیات‌های (کارکردهای) جزء موردنظر را می دهد.
تصویر 6-9
مطابق تصویر 6-9، در زمینه مهندسی نرم افزار شیء گرا، هر جزء، به شکل نمودار UML نشان داده می شود. در این تصویر، یک جزء به نام SensorManagement (بخشی از عملکرد امنیتی SafeHome)، نشان داده شده است. یک پیکان به صورت خط چین، جزء موردنظر را به طبقه‌ای با نام Sensor که به آن اختصاص داده شده، متصل می کند. جزء SensorManagement تمام عملکردهای مرتبط با سنسورهای SafeHome از جمله نظارت و پیکربندی آن‌ها را انجام می دهد. بحث بیشتر در مورد طراحی اجزاء، در فصل 11 ارائه شده است. جزئیات طراحی یک جزء را می توان در بسیاری از سطوح مختلف انتزاع، مدل سازی کرد. برای نمایش منطق پردازش، می توان از نمودار فعالیت UML استفاده کرد. جزئیات ساختار الگوریتمی مربوط به یک جزء را می توان با استفاده از شبه کد ( نمایی زبان مانند از برنامه نویسی، که در فصل 11 توضیح داده شده است) و همچنین برخی دیگر
از اشکال نموداری (به عنوان مثال، نمودار جریان)، نشان داد. جزئیات ساختار داده، معمولاً با استفاده از شبه کد یا زبان برنامه نویسی مورد استفاده برای پیاده سازی، مدل سازی می شود.

6-4-9 عناصر طراحی در سطح استقرار
عناصر طراحی در سطح استقرار، نحوه اختصاص عملکرد نرم افزار و زیر سیستم ها در محیط محاسبات فیزیکی پشتیبان نرم افزار را نشان می دهد. به عنوان مثال ، عناصر محصول SafeHome طوری پیکربندی شده اند که در سه محیط محاسباتی اولیه ( یک دستگاه تلفن همراه ، و در این مورد، یک رایانه شخصی، صفحه کنترل SafeHome، و سروری در CPI Corp)، قابل راه اندازی باشند. ( دسترسی سیستم به اینترنت را فراهم می کند). در حین طراحی، نمودار استقرار UML ایجاد می شود و سپس مطابق تصویر 7-9، اصلاح می شود. در این تصویر، سه محیط محاسباتی نشان داده شده است (در طراحی کامل، جزئیات بیشتر در نظر گرفته می شود: سنسورها، دوربین ها و عملکرد ارائه شده توسط سیستم عامل های تلفن همراه). زیر سیستم های (قابلیت های) موجود در هر عنصر محاسباتی، نشان داده شده است. به عنوان مثال ، رایانه شخصی دارای زیرسیستم هایی است که امنیت، نظارت، مدیریت خانه و قابلیت های ارتباطات را پیاده سازی می کند. علاوه بر این، یک زیر سیستم با دسترسی خارجی نیز طراحی شده است که تمام تلاش های انجام شده برای دسترسی به سیستم SafeHome از یک منبع خارجی را مدیریت می کند. هر زیر سیستم، برای نشان دادن اجزایی که پیاده سازی می کند، ایجاد می شود. نمودار نشان داده شده در تصویر 7-9، به صورت توصیف کننده است. این بدان معناست که نمودار استقرار، محیط محاسبات را نشان می دهد، اما به صراحت جزئیات پیکربندی را نشان نمی دهد. به عنوان مثال، مشخصات بیشتری در مورد “رایانه شخصی” ارائه نشده است و این رایانه، می تواند یک مک، یک رایانه مبتنی بر ویندوز، یک جعبه Linux، یا یک پلتفرم تلفن همراه، با سیستم عامل مرتبط با آن باشد. این جزئیات، هنگام اصلاح نمودار استقرار به عنوان نمونه، در مراحل آخر طراحی یا همزمان با شروع ساخت و ساز، مورد بررسی قرار می گیرد. هر نمونه از استقرار (یک پیکربندی سخت افزاری مشخص و شناخته شده)، شناسایی می شود.
تصویر 7-9

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

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

فصل دهم: طراحی معماری – یک رویکرد ؟ ؟ “” ؟ ؟ ؛ ‌؛