سلام به همه
من تحقیقی داشتم درباره طراحی مبتی بر ویژگی ولی خب سورس ایرانی برای این مورد نتوستم پیدا کنم برای همین تصمیم گرفتم نتیجه تحقیق ام رو اینجا هم بزارم که اگر کسی نیاز داشت استفاده کنه و اگرم مشکلی وجود داشت بهم بگید که بدونم . ?
طراحی مبتنی بر ویژگی یا Attribute Driven Design که به اختصار به آن ADD نیز گفته می شود یک روش گام به گام برای طراحی معماری نرم افزار است که برای سیستم فشرده-نرم افزاری استفاده می شود که می توان از این روش داخل سیستم های اطلاعاتی بزرگ تا سیستم های نهفته استفاده کرد .
فرآیند طراحی به کمک ADD بر اساس الزامات مهم معماری ( ASR) که شامل الزامات عملکرد، الزامات ویژگی کیفی و محدودیت ها است انجام می شود.
در آخر طراحی مل مجموعهای از طرحهای نما معماری داریم نه یک معماری با جزئیات کامل.
طراحی مبتنی بر ویژگی (ADD) روشی برای طراحی معماری نرم افزار هست توسط دانشگاه و موسسه مهندسی نرم افزار کارنگی ملون آمریکا توسعه داده شد.
و تا الان سه ورژن از آن عرضه شده است:
این ورژن سال 2000 منتشر شد و دارای 5 گام اصلی می باشد و 3 ورودی می باشد که به شرح زیر می باشد :
ورودیها: الزامات عملکرد - الزامات ویژگی کیفی - محدودیت ها
گامها:
1. یک کامپوننت یا بخش در سیستم را برای طراحی انتخاب می کنیم. برای سیستم هایی که از قبل وجود داشته اند فیچری که قرار است پیداه سازی شود انتخاب می شود.
2. نیازمندی های مربط با آن بخش یا همان ASRs را میابیم.
3. یک طراحی برای همان بخش ارایه می کنیم.
4. طراحی را پیادهسازی می کنیم و چک می کنیم که نیازمندیها برطرف شده باشند و آن را آنالیز می کنیم .
5. قدم های 1 الی 4 را برای بخشهای بعدی تکرار می کنیم.
این ورژن سال 2006 منتشر شد و مانند ورژن 1.0 داری همان 3 ورودی و 5 گام می باشد اما تفاوت آن با ورژن 1.0 این است که تمرکز اصلی در این وژن بر روی طراحی معماری مفهومی بوده است
این ورژن سال 2016 معرفی شد و بسیاری از مشکلات ورژن های قبل را برطرف کرده بود ، این ورژن دارای 2 ورودی بیشتر و چند گام اضافه تر نیز بود:
با توجه به عکس بالا ورودی ها ما شامل : الزامات عملکرد - الزامات ویژگی کیفی - محدودیت ها - اهداف طراحی - نگرانها می باشد
و گام های ما به صورت زیر تغییر می کند :
1. بررسی ورودی ها : که داخل این بخش سعی می کنیم ورودی ها را بررسی کنیم که داخل فرآیند به مشکل برنخوریم
2. تعیین اهداف و انتخاب ورودی ها
3. انتخاب یک یا چند از بخش ها و کامپوننت ها
4. انتخاب یک یا چند مفهموم طراحی که نیاز هدف و ورودی ها و ASRs را برآورده کند
5. پیاده سازی و برآورده کردن نیاز ها و ایجاد ارتباط ها و تعریف رابط ها
7. ثبت طراحی و اقدامات انجام شده
8. انجام مجدد تحلیل و درصورت نیاز بازگشت به گام 2 برای بخشهای بعدی
از جمله مشکلات این طراحی می توان به این مورد اشاره کرد که :
1. ثبت فرآیند هر بخش به صورت مسنتد که باید شامل برخی سوالات مانند : چه الزاماتی رعایت شده؟ ، چه کسی طراحی را انجام داده ؟ ، چه فرضیاتی رعایت شده است؟
2. ممکن است طراحی بدی برای آن بخش انتخاب شود که این مورد بر روی روابط نیز تاثیز گذار خواهد بود.
3. ممکن است مشکلات و انتخاب اشتباه طراحی زمان تست محصول مشخص شود و این مورد نیازمند هزینه کردن منابع بیشتر برای بازگشت و حل مشکل خواهد بود
4. ممکن است زمان شروع فرآیند الزامات و فرضیات را اشتباه یا به صورت کامل در نظر نگیریم یا حتی برخی از الزامات تغییر کنند که این باعث تغییر طراحی یک بخش و روابط آن شوند.
1. طراحان را قادر میسازد تا ویژگیها سیستم را در مراحل اولیه طراحی درک کنند.
2. طراحان را در طراحی معماری چابک تر می کند چون به بخش های کوچک تری تقسیم شده است.
2. طراحان را در طراحی معماری راهنمایی میکند که همه نیازمندی ها را برآورده کنند.
3. مجموعه ای از طرح های معماری است که به شما در شکل گیری معماری نهایی کمک می کند.
داخل مقاله ای که اخیرن برای ورژن 3.0 منتشر شده است یک چک لیستی گذاشته شده است که به شما در انجام این فرآیند کمک خواهد کرد که می توانید آن را از این لینک دانلود نمایید .
لغات به کار رفته در متن:
الزامات مهم معماری (Architecturally Significant Requirements :(ASR
الزامات عملکرد: Functional Requirements
الزامات ویژگی کیفی : Quality Attribute Requirements
محدودیت ها: Constraints
سیستم فشرده نرم افزار : Software-Intensive System
. تحقیق برای درس طراحی تحلیل و طراحی سیستمها استاد احمدیان ، نیمسال اول 1401 دانشگاه صنعتی شریف انجام شده است.