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