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