آموزش توسعه نرم افزار های شیء گرا توسط UML

[Identifier]

روش Unifiedدر طراحی شیءگرا
در طول فاز مدلسازی تحلیلی، دیدهای مدل کاربر و مدل ساختاری ارائه می شوند. این مدلها بینشی از سیستم را در قالب سناریو های کاربردی جهت هدایت مدلسازی رفتاری سیستم ارائه می دهند و همچنین اصولی را برای دیدهای پیاده سازی و محیط پیاده سازی با شناسایی و توصیف عناصر ایستای ساختاری از سیستم، فراهم می کنند. همچنانکه در بالا اشاره شدUML نیز فعالیتهای لازم در فاز طراحی را به دو دسته کلی تقسیم می کند که شامل طراحی سیستم و طراحی شئ بود.


طراحی سیستم معماری نرم افزار را نشان می دهد درحالیکه طراحی شی روی تعریف اشیاء و تعامل آن با اشیاء دیگر متمرکز می شود. جزئیات مشخص سازی داده ساختارهای صفات و طراحی رویه های مربوط به اعمال در طول فاز طراحی شیء انجام می شود. در این فاز دید برای هر یک از صفات کلاس ها و واسط بین اشیاء جهت تعیین جزئیات یک مدل کامل پیام بطور مفصل بررسی می شود.
طراحی شئ و سیستم درUML به منظور توصیف طراحی واسط های کاربری ، مدیریت داده ها برای سیستمی که باید ساخته شود و مدیریت وظایف زیر سیستم های مشخص شده ، توسعه داده شده است. فرآیند طراحی واسط های کاربری با توجه به دید مدل کاربرتهیه می شود. طراحی مدیریت داده برمجموعه ای از کلاسها و همکاریهایی استوار است که به سیستم اجازه مدیریت داده های ماندگار می دهند. طراحی مدیریت وظایف با ایجاد فراساختارهایی انجام می شود که وظایف زیر سیستم ها را سازماندهی و همروندی وظایف را کنترل می نماید. شکل 2-3 جریان کار را در فاز طراحی نشان میدهد.



در فرآیند طر احی با UML، دید های مدل کاربر و مدل ساختاری حاصل از تحلیل سیستم به تفصیل بررسی شده و نمایشی پیرامون این دیدها بطور دقیق در فاز طراحی ارائه می شود.

فرآیند طراحی سیستم
طراحی سیستم جزئیات معماری مورد نیاز برای ساختن سیستم را توضیح می دهد، این فرآیند شامل فعالیت های زیر است:
ــ تقسیم مدل تحلیلی به زیر سیستمها
ــ شناسایی همروندهایی که درتعریف مسئله قید شده است
ــ تخصیص زیر سیستم ها به پردازه ها و وظایف
ــ توسعه طرح برای واسط کاربری
ــ انتخاب یک استراتژی اساسی برای پیاده سازی مدیریت داده ها
ــ شناسایی منابع عمومی و درنظر گرفتن یک مکانیزم کنترلی برای دسترسی به آنها
ــ طراحی یک مکانیزم کنترلی مناسب برای سیستم برای مدیریت وظایف
ــ تعیین چگونگی برخورد با شرایط مرزی
درزیر روال طراحی هریک از مراحل فوق الذکر را با جزئیات بیشتری می آوریم.

افراز مدل تحلیلی
در طراحی سیستم شئ گرا، افرازی از مدل تحلیلی انجام می دهیم بطوریکه مدل را به مجموعه هایی از کلاس های مرتبط- از نظر تعامل با هم و رفتار- افراز می کنیم. هر یک از این مجموعه ها یک زیر سیستم بشمار می روند. بطور کلی تمام عناصر زیر سیستم برخی از ویژگی ها را به بصورت مشترک در خود دارند. همه این عناصر ممکن است در انجام یک عمل دخیل باشند، یا اینکه همه در یک محصول سخت افزاری مقیم باشند ویا ممکن است همه عناصر، یک کلاس ازمنابع را مدیریت کنند.
زیرسیستم ها به وسیله مسؤلیتهایشان مشخص می شوند، یعنی یک زیر سیستم را می- توان بوسیله سرویسهایی که فراهم می کند، شناسایی کرد. در طراحی سیستم شئ گرا، سرویس به معنای جمعی از اعمال است که یک عمل مشخص را انجام می دهند(مانند مدیریت یک پردازشگر لغت، تبدیل یک سیگنال آنالوگ به دیجیتال و...) .
در این مرحله زیر سیستم هایی که تعریف و طراحی شده اند باید با معیارهای طراحی زیر مطابقت داشته باشند.

1. زیر سیستم باید واسط کاربری تعریف شده ای داشته باشد تا ارتباط با بقیه سیستم بتواند از طریق این واسط انجام شود.

2. بجز تعداد کمی از کلاس های ارتباطی بقیة کلاس های زیرسیستم فقط می- توانند باکلاس های آن زیر سیستم همکاری داشته باشند.

3. باید تلاش شود که تعداد زیر سیستمها کمترین مقدار ممکن داشته باشند.

4. یک زیر سیستم می تواند بمنظور کاهش پیچیدگی به زیر سیستم های داخلی افراز شود.
وقتی دو زیر سیستم با هم در ارتباط باشند آنها می توانند رابطه سرویس دهنده /مشتری یا اتصال نقطه به نقطه باهم داشته باشند. درحالت سرویس دهنده / مشتری هر سیستم در یکی از این دو نقش - سرویس دهنده یا مشتری - عمل می کند و جریان ارائه سرویس یکطرفه و از سرویس دهنده به مشتری می باشد. درحالت نقطه به نقطه جریان ارائه سیستم ممکن است دو طرفه باشد.

هنگامی که سیستم به زیر سیستمها افراز می شود، یک عمل طراحی دیگر به نام لایه بندی صورت می گیرد. هر لایه از سیستم شئ گرا شامل یک یا چند زیر سیتسم است، این لایه ها سطوح مختلف مجرد سازی یا عملیاتی مورد نیاز برای انجام دادن عمل زیر سیستم را نشان می دهند. غالباً سطوح مجرد سازی بوسیله میزان قابل رویت بودن عملکرد زیر سیستم از نظر کاربر نهایی تعیین می شود.

بعنوان مثال یک معماری چهار لایه ای ممکن است بصورت زیر باشد:

1. لایه ارائهpresentation layer (زیر سیستم های متناظر با واسط کاربری)

2. لایه کاربردی application layer (زیر سیستم هایی که پردازش های مربوط به برنامه کاربردی را انجام می دهند)

3. لایه قالب بندی داده ها data formatting layer (زیر سیستم هایی که داده را برای پردازش آماده می کنند.)

4. لایه پایگاه داده ای data base layer (زیرسیستم های مربوط به مدیریت دادها)
بطور کلی روش زیر برای لایه بندی توصیه می شود:

1. مشخص نمودن معیار های لایه بندی : این معیار ها تعین می کنند که چگونه زیر سیستم ها در یک لایه در معماری لایه ای گروهبندی شوند 2. تعین تعداد لایه ها :تعداد خیلی زیاد لایه ها (بیشتر از حدلازم) لزوماً از پیچیدگی سیستم نمی کاهد از طرف دیگر تعداد خیلی کم لایه ها ممکن است به استقلال عملیاتی زیر سیستم ها صدمه وارد کند. 3. نامگذاری لایه ها و تخصیص زیر سیستم ها (بهمراه کلاس های کپسوله شده)به لایه: باید توجه شود که تعامل بین زیر سیستم ها (کلاس ها) از یک لایه با زیر سیستم ها (کلاس ها) از لایه دیگر منطبق بر معماری مورد نظر باشد بطوریکه در یک معماری بسته پیام ها از یک لایه ممکن است فقط به لایه زیرین- لایه ای که بلافاصله در زیر لایة مورد نظر باشد- ارسال شود اما در یک معماری باز پیام ها به تمام لایه ها در سطوح پایینتر قابل ارسال است. 4. طراحی واسط برای هر لایه 5. بررسی زیر سیستمها به منظور بهینه کردن ساختار کلاس های هر لایه 6. تعریف یک مدل پیام رسانی برای تعامل لایه ها 7. بازنگری طراحی لایه جهت تامین کردن کمترین میزان وابستگی بین لایه ها 8 . تکرار کردن این مراحل جهت بهینه کردن لایه بندی .(تصفیه کردن معماری لایه ای)

[Identifier]

همروندی و تخصیص زیرسیستم
بررسی مدل رفتار شئ از نظر پویایی از وجود نوعی همروندی میان کلاس ها (یا زیر سیستم ها) نشان می دهد . اگر چند کلاس (یا زیر سیستم ) در یک زمان فعال نباشند، نیازی به پردازش همروند درسیستم نیست. و این بدین معناست که کلاس ها ( یا زیر سیستم ها ) را می توان بر روی یک پردازنده سخت افزاری پیاده سازی کرد. از طرف دیگر اگر کلاسها (ویا زیر سیستمها ) باید به صورت آسنکرون بر روی رویدادها دریک زمان عمل کنند، همروندی وجود دارد. هنگامی که زیر سیستم ها بصورت همروند فعال می شوند دو انتخاب تخصیصی وجود دارد: (1) تخصیص هر زیر سیستم به یک پردازنده مستقل (2) تخصیص زیر سیستم ها به یک پردازنده مشترک و فراهم نمودن ملزومات همروندی با استفاده از خواص سیستم عامل مورد استفاده.
همروندی وظایف با بررسی نمودار حالت هریک از اشیاء تعیین می شود. اگر جریان رویدادها و تراکنش ها نشان دهد که درهر زمان فقط یک شئ فعال است، یک بند کنترلی برقرار می شود یعنی هرگاه سیستم این محدودیت را داشته باشیم که وقتی یک شئ برای شیئی دیگر پیامی ارسال کرد، شئ اولی الزاماً منتظر جواب بماند، بند کنترلی بصورت پیوسته ادامه می یابد و در این صورت همروندی نداریم. اما اگر شئ اولی بعد از ارسال پیام به فعالیت خود ادامه دهد، بند کنترلی تقسیم می شود و همروندی بوجود می آید. برای تعیین اینکه کدام یک از دو انتخاب تخصیصی پردازنده برای سیستم موجود مناسب است، طراح باید نیازها ی کارایی، هزینه ها و سربار پردازش تحمیلی برای تعامل بین پردازنده ها را بررسی کند.

مؤلفه مدیریت وظیفه Task management component
غالب ویژگیهای یک وظیفه با معین نمودن چگونگی شروع آن وظیفه تعیین می شود، غالباً وظایف بصورت رویدادگرا یا زمانگرا (وظیفه در زمان های خاص شروع می شود )هستند. هردو نوع وظیفه بوسیله وقفه فعال می شوند اما نوع اول با دریافت یک پیام وقفه از منابع خارجی (مانند پردازندة دیگر ، حسگر) فعال می شود. ولی نوع دوم بوسیله ساعت سیستم سازماندهی می شود.
علاوه برچگونگی راه اندازی وظایف باید اولویت وظایف نیز تعیین شود. وظایف بااولویت بالا باید بلافاصله به منابع دسترسی پیدا کنند.برای طراحی اشیائی که وظایف همروند را مدیریت می کنند استراتژی زیر پیشنهاد می شود.
ــ تعیین ویژگیهای وظیفه
ــ تعریف وظیفه ناظر و اشیاء متناظر با آن
ــ مجتمع سازی وظیفه ناظر و وظایف دیگر.

مؤلفه واسط کاربری user interface component
اگر چه مؤلفه واسط کاربری در بطن دامنة مسئله پیاده سازی می شود، اما خود واسط زیر سیستمی خیلی مهم برای نرم افزارهای کاربردی مدرن است. مدل تحلیلی شامل سناریوهایی کاربردی (موارد قابل کاربرد) و مشخصات نقش هایی است که کاربران (کنشگران) درآن نقش ها با سیستم تعامل دارند و این همان اطلاعات ورودی فرآیند طراحی واسط کاربری است . بمحض این که کنشگر و سناریوهای مربوطه تعریف شد، سلسله مراتب دستورات مشخص می شود. سلسله مراتب دستورات قسمت های مهم منوی سیستم و زیر تابع های موجود در رابطه با هر قسمت منو را بیان می کند.
بدلیل وجود محیط های متنوع توسعه واسط کاربری، نیازی به طراحی عناصر گرافیکی نیست .کلاس های با قابلیت استفاده مجدد (با صفات و اعمال مناسب) برای پنجره ها ،آیکن ها ، عملکرد ماوس و تابع های تعاملی متنوع دیگر ، دراین محیطها در دسترس هستند. شخص پیاده ساز فقط باید ازکلاسهایی که ویژگی های مناسب را برای دامنة مسئله دارند، نمونه سازی کند.

مؤلفه مدیریت داده Data management coumponent
مؤلفة مدیریت داده شامل دو قسمت جدا ازهم می باشد: (‍1)مدیریت کردن داده ها که قسمت بحرانی نرم افزار کاربردی هستند و(‌2) ساختن فراساختاری برای ذخیره و بازیابی اشیاء. بطور کلی مدیریت داده به صورت لایه ای طراحی می شود و ایدة آن این است که نیازهای سطح پایین برای دستکاری ساختارهای داده را از نیازهای سطح بالا برای دستگیری از صفات سیستم جدا نماییم. این کار در عمل با استفاده از یک DBMS برای تمام زیر سیستمها انجام می شود، اشیائی که برای دستکاری پایگاه داده لازم است عضو همان کلاسهایی است که در هنگام تحلیل دامنه مشخص شده اند.

مولفه مدیریت منابع Recourse management coumponent
در سیستم های شئ گرا منابع متنوعی وجود دارد که در بسیاری از موارد زیر سیستم ها بطور همزمان در دسترسی به این منابع رقابت می کنند. منابع عمومی سیستم می تواند موجودیتها ی خارجی مانند دیسک گردان ، پردازنده ، خطوط ارتباطی ، یا مجرداتی مانند پایگاه داده یا شئ باشد. بدون درنظر گرفتن نوع منبع، مهندس نرم افزار باید یک مکانیزم کنترلی برای این منابع طراحی نماید، پیشنهاد Rambaughبرای این مکانیزم این است که هر منبع باید با یک شئ محافظ (نگهبان) تصاحب شود، این شئ محافظ به عنوان یک دربان دسترسی به منبع را کنترل و از تصادم درخواست ها جلوگیری می- کند.

ارتباط بین زیر سیستم ها Intersubsystem communication
پس ازاینکه هر زیر سیستم مشخص شد، لازم است که همکاریهای موجود میان زیرسیستمها بصورت سیستماتیک تعریف شود. بصورت کلی مدلی که برای همکاری شئ- به- شئ استفاده می شود را می توان برای زیرسیستمها نیز توسعه داد. هنچنانکه قبلاً ذکر شد، ارتباط می تواند بصورت اتصال سرویس دهنده/ مشتری یا نقطه به نقطه باشد. شکل 2-4 این ارتباط را نشان می دهد، باتوجه به شکل باید قراردادهایی بین زیرسیستمها مشخص شود.قرارداد نشان می دهد که چگونه یک زیرسیستم می تواند با یک زیر سیستم دیگر تعامل داشته باشد.

[Identifier]

فرآیند طراحی شئ
در مرحله طراحی سیستم، معماری نرم افزار مشخص می شود و طرح هایی که برای سیستم در نظر گرفته می شود، طرح هایی کلی می باشند. حال وقت آن است که به جزئیات بپردازیم و برای این روی طراحی شئ متمرکز می شویم دراین مرحله با اصول و مفاهیم در سطح طراحی مؤلفه سرو کار داریم، داده ساختارهای محلی (برای صفات) تعریف می شوند و الگوریتم ها (برای اعمال) طراحی می شوند.

مشخصات شئ
طراحی مشخصات شئ به یکی از دو شکل زیر صورت می گیرد:
توصیف پروتکل که واسطی را برای شئ با تعریف هر یک از پیام هایی که شئ قادر به دریافت آنهاست و عملی که شئ در نتیجة دریافت یک پیام خاص انجام می دهد، برقرار می کند .
توصیف پیاده سازی که جزئیات پیاده سازی را برای هر یک از اعمال مربوط به پیام دریافتی را نشان می دهد. جزئیات پیاده سازی شامل بخش اطلاعات خصوصی شئ است، اما جزئیات داخلی مربوط است به داده ساختاری که صفات را بیان می کند و جزئیات رویه ای که اعمال را توصیف می کند. توصیف پروتکل چیزی جز مجمو عه ای از پیام ها و توضیحات مر بوط به هر پیام نمی باشد. برای سیستم های بزرگ با پیام- های زیاد می توان پیامها را طبقه بندی کرد. توصیف پیاده سازی شئ جزئیات داخلی (مخفی) مورد نیاز برای پیاده سازی را فراهم می کند اما این جزئیات برای درخواست لازم نیست. طراح شئ باید توصیف پیاده سازی را فراهم کند لذا باید جزئیات داخلی شئ را بررسی کند، اما طراح دیگر یا پیاده ساز که از شئ یا نمونه های دیگرِ آن استفاده می کنند فقط به توصیف پروتکل نیاز دارند و به توصیف پیاده سازی هیچ نیازی نیست.

توصیف پیاده سازی ترکیبی از اطلاعات زیر است؛

1. مشخص سازی نام شئ و ارجاع آن به یک کلاس.
2. مشخص سازی ساختمان دادة خصوصی که به داده ها و انواع اشاره دارد.
3. توصیف رویه هر عمل.
توصیف پیاده سازی باید اطلاعات کافی را برای دستگیری از تمام پیام های موجود در توصیف پروتکل، داشته باشد.

طراحی الگوریتمها و ساختمان داده ها
نمایش های متنوع در مدل تحلیلی و طراحی سیستم مشخصات تمامی اعمال و صفات را فراهم می کند، الگوریتم برای پیاده سازی مشخصات عمل ساخته می شود. در بسیاری از موارد الگوریتم شامل یک سری محاسبات ساده یا یک توالی رویه ای است که قابل پیاده سازی در یک ماژول نرم افزاری می باشد. اما اگر عمل دارای توصیف پیچیده ای باشد لازم است که عمل را بصورت پیمانه ای پیاده سازی کنیم.
ساختمان دادها بصورت همروند با الگوریتم ها طراحی می شوند. از آنجا که اعمال بطور یکنواخت و ثابت، صفات کلاس را دستکاری می کنند طراحی ساختمان داده ای که بتواند صفات را منعکس کند باید قویاً با طراحی الگوریتم مرتبط باشد.

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

طراحی الگو
طراحان خوب در هر زمینه دارای توانایی بالا در درک مسئله و تشخیص الگوهای مربوطه -که با ترکیب آنها می توان مشکل را حل نمود- می باشند. در طول فرآیند طراحی شئ گرا مهندس نرم افزار باید موقعیت هایی را جستجو کند که الگو های طراحی شده ای برای استفاده مجدد موجود باشد.

توصیف طراحی الگو
تمام طراحی الگوها را می توان بامشخص کردن اطلاعات زیر توصیف کرد:
1. نام الگو
2. هدف الگو
3. طراحی مواردی که الگو را تحریک می کنند
4. پاسخ های مربوط به هر محرک
5. کلاس های لازم برای پیاده سازی جواب
6. مسؤلیتها و همکاریهای بین کلاس های جواب
7. راهنمایی هایی جهت پیاده سازی مؤثر
8. کد منبع نمونه یا قالبهای کد منبع
9. مراجعه متقابل الگوهای طراحی مرتبط
نام الگو یک انتزاع است که معنی ویژه ای را برای درک هدف و توانایی الگو القا می- کند. طراحی محرک ها نیازمندیهای داده ای، عملی یا رفتاری متناظر با قسمت خاصی از نرم افزار را بیان می کنند که الگو در آن قسمت بکار برده می شود. در اساس این موارد محیط و شرایطی که در آن بتوان از الگو استفاده کرد، بیان می کنند.

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

[Identifier]

فصل سوم

فرآیند توسعه
همانطور که در فصل اول اشاره کردیم برای تولید نرم افزار و توسعه آن متدلوژیهای مختلفی وجود دارد و متدلوژی را به عنوان یک فرآیند ساختارمند برای حل یک مسئله که بوسیله ابزارها و تکنیک هایی پشتیبانی می شود، تعریف کردیم. دراین فصل درباره فرآیند توسعه نرم افزار با جزئیات بیشتری بحث می کنیم.

فرآیند توسعه نرم افزار چیست؟
فرآیند مشخص می کند که چه کسی ، چه کاری را درچه موقعی و چگونه انجام دهد، تا به یک هدف خاص برسیم(who?, what?, when? And how?) . در مهندسی نرم افزار منظور از این هدف خاص، ساخت یک نرم افزار جدید یا بهبود یک نرم افزار موجود می باشد. یک فرآیند موثر مسیری را برای توسعه کارآمد نرم افزار فراهم می نماید، این فرآیند با توجه به شرایط موجود در سیستم تحت مطالعه نمونه های عملی متناسب را ارائه می دهد که بهترین راهکارهای موجود را برای شرایط جاری پیشنهاد می کند. در واقع فرآیند با ارائه راهنماییها و نمونه های عملی توسعه نرم افزار میزان ریسک را کاهش می دهد و به توانایی توسعه دهنده برای پیشگویی آینده پروژه می افزاید و بطور کلی یک دید و فرهنگ عمومی را برای توسعه نرم افزارهای مختلف ترویج می دهد.
ما به فرآیندی نیاز داریم که همه افراد دخیل در توسعه نرم افزار را هدایت کند - مشتریان ،کاربران،توسعه دهندگان و مدیران اجرایی. بنابراین فرآیند مذکور باید بصورت گسترده دردسترس باشند تا همه افراد ذینفع نقش آن را در توسعه نرم افزار درک کنند. نهایتاً فرآیند باید با توجه به تکنولوژی، ابزارها و ساختارهای سازمانی قابل تغییرباشد.
ابزارها(Tools): فرآیندها و ابزارها باید به صورت موازی گسترش یابند.
افراد: افراد برای کار با فرآیند نیاز به مهارت کمی داشته باشند و یا مهارت مورد نیاز را به سرعت و سهولت کسب کنند.
ساختارهای سازمانی : ساختارهای سازمانی در نحوه طراحی موثراست و باید فرآیند آن را درنظر بگیرد. مثلا توزیع تیم کاری در سطوح مختلف سازمانی ، کارمند پاره وقت بودن یا عامل قرارداد بودن .
با توجه به نوع پروژه می توان فرآیند متناسب را انتخاب نمود - برای یک پروژه می توان از چند فرآیند مختلف نیز استفاده کرد - و برای نشان دادن نتایج تحلیل و طراحی در هر فرآیند می توان ازUML استفاده کرد. عوامل مختلفی در توسعه نرم افزار بر فرآیندهای گوناگون اثر می گذارند، که شامل نوع نرم افزاری است که باید توسعه داده شود (بلادرنگ، سیستم اطلاعاتی یا یک محصول رومیزی ) ، اندازه (یک توسعه دهنده، گروه کوچک ،گروه بیش از 100 نفر)و غیره .
درواقع تیم توسعه دهنده باید با توجه به پروژه برای توسعه یک فرآیند خاص را با استفاده از فرآیند های موجود- به عنوان توصیه های مهم نه به عنوان یک فرآیند استاندارد که حتما باید آنرا دنبال کرد- گسترش دهند. شکل 3-1 یک دید سطح بالا را از فرآیند توسعه نشان می دهد. این فرآیند، یک فرآیند توسعه تکراری - افزایشی است. که درآن محصول نهایی پس از طی نمودن چندین مرحله - هر مرحله یک حالت میانی از محصول را تحویل مرحله بعد می دهد بطوری که خروجی هر مرحله از مرحله قبل کاملتراست - تولید می شود.مرحله ساخت دارای تکرارهای بیشتری است که در هر

تکرار یک ویژگی از نرم افزار تکمیل شده سپس تست و مجتمع سازی انجام می گیرد و زیر مجموعه ای از نیازهای پروژه را برآورده می شود . هرتکرار شامل تمام فازهای چرخة عمر یعنی تحلیل، طراحی، پیاده سازی و تست است.
مرحله اول مرحله شروع است، دراین مرحله یک امکان سنجی و بررسی مقدماتی سیستم و تعیین نیازمندیهای کلی کاربر برای تعیین محدوده سیستم انجام می شود ومجوز ادامه کار را از کاربر می گیریم .
مرحله بعدی مرحله تفصیل است، دراین مرحله تمام نیازمندیهای کاربر را جمع آوری می کنیم و تحلیل و طراحی سطح بالایی را برای ایجاد خطوط پایه معماری سیستم انجام می دهیم. سپس برای مرحله ساخت برنامه ریزی می کنیم . با این نوع فرآیند ها- فرآیندها ی تکراری - بعضی از کارها باید در آخرین مرحله یعنی مرحله انتقال انجام گیرد. مانند: بتا تست، آموزش کاربرو...
در شکل بالا فقط مرحله ساخت بصورت تکراری نشان داده شده است . درواقع در همه مراحل می توانیم تکرار داشته باشیم و این کار برای مراحل بزرگ خیلی مفید است. تا اینجا دید سطح بالایی از فرآیند توسعه نشان دادیم در زیر جرئیات کار را بررسی خواهیم کرد.

شروعInception
مرحله شروع با توجه به اهمیت و اندازه پروژه به شکل های مختلف انجام می گیرد. برای پروژه های کوچک و غیر رسمی ممکن است مرحله شروع ظرف چند ساعت گفتگو با مشتری و طرح یک نقشه کلی که پروژه را تصویر می کند، انجام شود اما در پروژه های با اهمیت و بزرگ با برگزاری جلسات متعدد رسمی و قراردادهای امضاء شده رسمی این مرحله طی می شود. در این حالت ممکن است مرحلة شروع ماهها طول بکشد. در طول فاز شروع به امکان سنجی می پردازیم و موارد کاری پروژه - ارزش تقریبی پروژه، زمان لازم برای پروژه و ... - را مشخص می کنیم و اساس کار سیستم و محدوده سیستم تعیین می شود و ممکن است برای انجام این کارها به یک تحلیل مقدماتی نیاز داشته باشیم در پایان پس از توافق با مشتری قرارداد منعقد می شود و رسماً باید کار را شروع کنیم.

تفصیل Elabboration
بعد از اینکه مجوز ادامه کار را از مسؤل پروژه گرفتیم، در این مرحله ما تنها لیستی ناقص از نیازهای کلی سیستم که مبهم و غیر گویا است، داریم در اینجا می خواهیم درک بهتری از مسئله داشته باشیم و بررسی می کنیم که: (1) واقعاً می خواهیم چه چیزی بسازیم؟ (2) چگونه سیستم موردنظر را بسازیم؟ درواقع دراین مرحله نیازهای کاربر بصورت دقیق، با جزئیات کامل در قالب موارد قابل کاربرد شناسایی می شود. این مرحله غالباً با ریسک همراه است، انواع ریسک های ممکن به چهار دسته تقسیم می- شوند:
ریسک نیازمندیها : نیازمندیهای سیستم کدامند؟ در تولید نرم افزار بدترین حالت هنگامی است که سیستم نادرستی تولید شود یعنی تفسیر نادرستی از نیازهای کاربر را در ساخت سیستم ملاک قرارداده ایم و سیستم تولید شده نیازهای کاربر را برآورده نمی- کند(درک نکردن سیستم مورد نیاز).
ریسک فنی: آیا تکنولوژیی که برای ساخت نرم افزار انتخاب شده واقعاً کار مورد نظر را انجام می دهد؟
ریسک مهارتها: آیا تخصص های لازم را برای انجام کار داریم؟
ریسک سیاسی: آیا انجام پروژه از نظر سیاسی مشکل ساز نیست؟
در زیر ریسک نیازمندیها به تفصیل بررسی می شود .

ریسک نیازمندیها
بررسی نیازمندیها درUML با موارد قابل کاربرد شروع می شود، کل فرآیند توسعه ازموارد قابل کاربرد مشتق می شود. مورد قابل کاربرد یک تعامل نوعی بین کاربر و سیستم برای دسترسی به یک هدف خاص می باشد. هرمورد قابل کاربرد یک عمل با ارزش را برای کاربر نشان می دهد. موارد قابل کاربرد عناصر پایه ای برای ارتباط مشتری با توسعه دهنده ، در طول برنامه ریزی پروژه است . یکی از مهم ترین کارهایی که در طول فاز تفصیل باید انجام بگیرد کشف تمام موارد قابل کاربرد بالقوه در سیستم در دست ساخت است. البته در عمل کشف همه موارد به یکباره غیر ممکن است اما در هر صورت باید موارد قابل کاربرد مهم که مواردی کلیدی هستند و ریسک را کاهش می دهند ، مشخص شوند و بهمین خاطر است که در طول فاز تفصیل باید نتایج میانی را به منظور جمع آوری بیشتر موارد قابل کاربرد با مشتری در میان بگذاریم . لازم نیست که موارد قابل کاربرد را بصورت خیلی ریز تشریح نماییم ، توصیف موارد قابل کاربرد در یک پاراگراف بطوریکه بروشنی ایده های اساسی را به کاربر نشان دهد و برای توسعه دهنده نیز کارهای پشت صحنه نمایان سازد،کافی است.

موارد قابل کاربرد کل سیستم را منعکس نمی کنند یعنی اسکلتِ یک مدل مفهومی از دامنه مسئله را نشان می دهند. بطور کلی برای بررسی و کشف دقیق نیازمندیها باید به مدل سازی دست بزنیم و با استفاده از مدل سازی دامنة مسئله را تصویر کنیم . مدلهای مختلفی وجود دارند که ماهیت سیستم مورد مطالعه را به روشنی نشان می دهند که تعدادی ازآنها عبارتند از(1) مدلها ی دامنة مسئله و موارد قابل کاربرد، (2) مدلهای تحلیلی و (3) مدلهای طراحی که در فصل قبل معرفی شد. درUML برای ایجاد مدلهای دامنة مسئله استفاده از نمودار های زیر پیشنهاد می شود:

ــ نمودارهای کلاس از چشم انداز مفهومی
ــ نمودارهای فعالیت ؛ این نمودارها در فصل بعد به تفصیل خواهد آمد.

ازمهمترین عناصر در کشف نیازمندیها میزان ارتباط با خبره های دامنة مسئله است. در پایان مرحله تفصیل معماری خط پایه سیستم مشخص می شود این معماری شامل (1) لیست تمامی موارد قابل کاربرد که نیازمندیهای سیستم را بیان می کند. (2) مدل دامنة مسئله که یک نقطه شروع برای کارهای بعدی است و (3) ساختار تکنولوژی انتخاب شده . به این معماری ، طرح اولیه گفته می شود.

[Identifier]

برنامه ریزی مرحله ساخت
برای برنامه ریزی مرحله ساخت، روشهای مختلفی وجود دارد که در زیر یک روش برنامه ریزی را توضیح می دهیم.
اساس برنامه ریزی تعیین تکرارها و همچنین موارد قابل کاربردی که باید در هر تکرار تحویل داده شود. بعضی از توسعه دهندگان موارد قابل کاربرد را در اندازه های کوچک دوست دارند بطوریکه بتوانند هر کدام از این موارد را در یک تکرار به اتمام برسانند اما برخی دیگر موارد قابل کاربرد بزرگتری را دوست دارند و در هر تکرار تعدادی از سناریوهای موجود در مورد قابل کاربرد را انجام می دهند و بقیه را به تکرار های بعدی محول می کنند. اساس کار یکی است و در این روش موارد با اندازه کوچک را درنظر می گیریم، در طول برنامه ریزی با دو گروه از افراد سرو کار داریم که عبارتند از: مشتری و توسعه دهنده
برای برنامه ریزی مرحله ساخت گامهای زیر توصیه می شود:
در قدم اول باید موارد قابل کاربرد طبقه بندی شود، مشتری موارد قابل کاربرد را با توجه به ارزش کار در سه سطح بالا، متوسط و پایین طبقه بندی می کند و به هر مورد قابل کاربرد یک اولویت نسبت داده می شود سپس مشتری مضمون هرطبقه را یادداشت میکند.
در قدم دوم توسعه دهندگان پس از تقسیم بندی مشتری موارد قابل کاربرد را با توجه به ریسک توسعه تقسیم بندی می کنند. ریسک بالا برای چیزهایی در نظر گرفته میشودکه انجام آنها مشکل و یا بدرستی برای توسعه دهنده درک نشده است.
در قدم بعدی توسعه دهنده باید زمان مورد نیاز برای هر مورد قابل کاربرد را تخمین بزند. در این تخمین فرض براین است که در هر تکرار به فازهای تحلیل، طراحی، کدنویسی، تست کردن، مجتمع سازی و مستند سازی نیاز داریم. تعدادی از این فازها در شکل 3-2 نشان داده شده است. توجه شود تخمین زدن را کارشناس توسعه انجام می- دهد نه مدیر.با تمام شدن تخمین زدن باید بررسی کنیم که آیا آمادگی لازم برای برنامه ریزی داریم . اگر موارد قابل کاربرد با میزان ریسک بالا زمان زیادی از زمان پروژه را لازم داشتند باید برای این موارد قابل کاربرد به مرحله تفصیل برگردیم .

در قدم چهارم طول هر تکرار را تعیین می نماییم، ما به یک طول ثابت برای تکرار در کل پروژه نیاز داریم با این کار یک ریتم منظم در اتمام تکرار خواهیم داشت. طول تکرار باید طوری انتخاب شود که بتوان مورد قابل کاربرد را دراین زمان انجام داد.حال باید به عنوان کار لازم برای انجام هر تکرار بیاندیشیم، سپس مشخص کنیم که با چه سرعتی می توانیم در پروژه پیشرفت کنیم.
قدم بعدی برنامه ریزی مرحله ساخت نسبت دادن موارد قابل کاربرد به تکرار هاست. این تخصیص با توجه به اولویتها نسبت داده شده در مراحل قبلی صورت می گیرد بطوریکه موارد با اولویت بالا اول انجام داده می شود، در این مرحله ممکن است موارد قابل کاربرد بزرگ به موارد کوچکتری تقسیم شوند ودر تخمین طولهای تکرار و زمان لازم تجدید نظر کنیم . برای پیش بینی مقدار زمان مورد نیاز در مرحله انتقال معمولا 10 تا 35 درصد از مرحله ساخت را بعنوان تخمین مرحله انتقال درنظر می گیرند.

مرحله ساخت
در مرحله ساخت سیستم با طی کردن یک سری تکرارها ساخته می شود. هر تکرار یک پروژه کوچک است باید تحلیل، طراحی، کدنویسی، تست و مجتمع سازی را برای تمام موارد قابل کاربرد منسوب به یک تکرار انجام دهیم و هر تکرار را با نشان دادن نمایی از کار به کاربر و تست کردن سیستم برای تایید اینکه موارد قابل کاربرد بدرستی ساخته شده اند، به پایان می رسانیم و هدف از این کار کاهش ریسک است . تکرارها در مرحله ساخت بصورت تکراری - افزایشی است : افزایشی بودن به این معنا است که درهر تکرار جزئی از کل ساخته می شود و به اجزاء ساخته شده درتکرار های قبلی اضافه می گردد.
تکراری بودن به فاز کدنویسی مر بوط می شود و چنین است که در هر تکرار دوباره نویسی در قسمتهایی از کدهای قبلی به منظور قابل انعطاف پذیرتر نمودن سیستم صورت می گیرد.

مرحله انتقال
در طول مرحله انتقال نرم افزار در اختیار جامعه کاربران قرار می گیرد و هیچ توسعه ای در افزایش عملکرد سیستم صورت نمی گیرد، مگر اینکه یک عمل کوچک یا یک عمل اساسی را به سیستم بیافزاییم، لذا تنها توسعه ممکن برطرف نمودن خطاهاست. یک مثال خوب برای مرحله انتقال فاصله زمانی بین محصول بتا و محصول نهایی است و تست بتا و بهینه سازی در این مرحله انجام می شود.
در پایان مرحله انتقال عملکرد فرآیند توسعة مورد استفاده را بررسی می نماییم و کم و کاستیهای فرآیند را بمنظور استفاده در پروژه های دیگر برطرف می کنیم.

[Identifier]

زبان مدل سازی یکپارچه
UML

مقدمه
UML یک زبان مدل سازی است، یک متد نیست، بسیاری از متدها حداقل شامل یک زبان مدلسازی و یک فرآیند هستند، زبان مدلسازی اصولاً شامل علائمی گرافیکی است که متدها با استفاده از این علائم مدل های طراحی شده را نمایش می دهند. اما فرآیند نشان می دهد که چه قدمهایی را باید در مرحله طراحی برداریم تا به هدف مورد نظر برسیم.
UML ترکیبی از سه روش مدلسازیOOSE, BOOCH, (Object Modeling Technique) OMT (Object-Oriented Software Engineering) است. این زبان یک استاندارد مدلسازی است، وجود یک زبان استاندارد خیلی مهم است اما لزومی ندارد که حتماً یک فرآیند استاندارد داشته باشیم . در دهه 1980 زبانهای شئ گرا مثل smal talk , C++‎ ابداع شدند، این زبانها باعث شدند که توسعه دهنده بتواند دنیای واقعی را بصورت مجموعه ای از اشیای مربوط به هم در نظر بگیرد و همان تصور ذهنی خود را با استفاده از یک زبان برنامه نویسی شئ گرا پیاده سازی کند، همین امر باعث شد که کتابهای زیادی در زمینه تحلیل و طراحی شئ گرا در سالهای 88 تا 92 منتشر شود. روش Booch در فازهای طراحی و ساخت پروژه به خوبی عمل می کرد وOOSE موارد قابل کاربرد را برای گرفتن نیازمندیهای کاربر و تحلیل و طراحی سطح بالا را بطور عالی پشتیبانی می کرد، روش OMTنیز برای تحلیل و تمرکز روی داده های سیستم اطلاعاتی(data intensive) بسیار مفید بود.
در اکتبر 1994 وقتی کهRambugh از شرکت جنرال الکتریک به Booch ازشرکت Rational پیوست، عملاً کار خود را برای ترکیب روشهای شخصی جهت ایجاد یک زبان مدلسازی واحد، شروع کردند. در اکتبر 1995 نسخة 0.8 روشUnified را ارائه دادند. در همین زمان Jacobson نیز برای شرکت دادن روش شخصیOOSE در پروژة UML با آنها به توافق رسید و مستندات نسخهUML 0.9 را در ژانویه 1996 آماده کردند. سر انجام در سال 1997 نسخه UML 1.0 ارائه شد و در همین سال به عنوان یک استاندارد توسط شرکتOMG شناخته شد.

علائم و فرامدل ها
علائم همان عناصر گرافیکی هستند که در مدلها دیده می شوند و نحو زبان مدلسازی را تشکیل می دهند. بعنوان مثال : علائم نمودار کلاس نمایشی را برای موارد و مفاهیمی نظیرکلاس، تناظر و چند تایی تعریف می کند.
در سازمانهای مختلف با حوزه های مسئله متفاوت، فرآیندهای متفاوتی مورد نیاز است، بنابراین تلاش بر این است که ابتدا بر یک فرامدل مشترک تمرکز شود و در درجه دوم بریک علامتگذاری مشترک تمرکز گردد. لذا فرامدل را چنین تعریف می- کنیم: نموداری- معمولا نمودار کلاس- است که علائم را تعریف می کند.

چرا مدلسازی می کنیم؟

مدلسازی قسمت عمدة فعالیتهایی است که مقدمه یک نرم افزار مناسب- نیازهای کاربر را برآورده کند- رافراهم می کند، بدین دلیل مدلسازی می کنیم که ساختار و رفتار مناسبی برای سیستم مرتبط با سیستم واقعی در نظر گرفته شود. می دانیم که زبان طبیعی برای این کار بعلت ابهام و پیچیدگی زیاد هنگام کار در سطوح پایین یک سیستم پیچیده مناسب نیست و کد نیز اگر چه دقیق است اما چون به جزئیات می پردازد و به یکباره نمی توانیم وارد این جزییات شویم، مناسب نیست. بنابراین برای اینکه سیستم را به صورت بصری ببینیم و معماری آن را کنترل نماییم و همچنین درک بهتری از سیستم داشته باشیم، مدلسازی می کنیم. یک مدل، نمایی ساده از دنیای واقعی است. بطور کلی مدلسازی از چهارجنبه زیر به ما کمک می کند:

1. مدلها به بصری سازی سیستم -آنچنانچه در دنیای واقعی وجود دارد یا آن طوریکه ما می خواهیم - کمک می کند .
2. مدل ها به ما اجازه می دهند که ساختار ورفتار سیستم را مشخص کنیم .
3. مدلها یک قالب را تعریف می کنند که مارا در مرحله ساخت هدایت می کند.
4. مدلها تصمیماتی که در مورد پروژه اخذ شده، بصورت مستند بیان می کند.

موارد قابل کاربرد Use cases
موارد قابل کاربرد با تکیه بر اینکه سیستم چه کاری را انجام می دهد یا اینکه سیستم جدید چه اعمالی را مضاف برکارهای قبلی باید انجام دهد، یک مدل از سیستم می دهد که مدل مورد قابل کاربرد نامیده می شود. این مدل برای تحلیل نیازهای عملیاتی سیستم بکار می رودکه این مدل درفاز تحلیل توسعه سیستم شئ گرا ایجاد می شود .
مدل کردن موارد قابل کاربرد در اولین مرحله توسعه سیستم برای کمک به توسعه دهنده جهت درک بهتر نیازهای عملیاتی سیستم بدون اینکه به چگونگی انجام این عملیات بپردازد، مفید واقع می شود. توسعه دهندة نرم افزار باید با کاربر در طول پروسه توسعه درارتباط باشد و در مشخصات نیازمندیها به توافق برسند . اگر نیازمندیهای کاربر در طول پریود توسعه نرم افزار تغییر کند، این تغییرات ابتدا در مدل مورد قابل کاربرد اعمال می شود . تغییرات در مورد قابل کاربرد منجر به تغییر در مدلهای دیگر می شود . این مدلها می توانند اثرات اجرایی را نشان دهند، مثلاً شما می توانید اثرات یک تغییر در طراحی یک مورد قابل کاربرد را مشاهده نمایید.مدل مورد قابل کاربرد شامل دو عنصر کنشگر و مورد قابل کاربرد است . کنشگر یک عنصر خارجی است که با سیستم تعامل دارد، در واقع کسی یا چیزی (یک سیستم خارجی ) که اطلاعات را در سیستم تغییر می دهد، کنشگر می باشد .
مورد قابل کاربرد نمایشی از مجموعه ای از اعمال مرتبط به هم است که با کنشگر مقدار دهی می شوند. برای تعریف دقیق مورد قابل کاربرد ابتدا مفهوم سناریو را تعریف می کنیم .
سناریو یک توالی از مواردی است که تعامل بین سیستم و کاربر را بیان می کند.
مورد قابل کاربرد مجموعه ای از سناریو های مرتبط به هم است که یک هدف کاربر را دنبال می کنند. تفاوتی که بین کاربر و کنشگر بتوان به آن اشاره کرد این است که کاربر کسی است که از سیستم استفاده می کند، اما کنشگر نشان دهنده نقشی است که کاربر در آن نقش عمل می کند، ممکن است که یک کاربر در چند نقش متفاوت از سیستم استفاده کند. نام کنشگر باید نشان دهنده نقش کاربر باشد، یک کنشگر کلاسی از کاربران را تعریف می کند و یک کاربر نمونه ای از کلاس کنشگر خاصی است. چون کنشگر ها در خارج از سیستم قرار دارند نیازی نیست که جزئیات آن را بررسی کنیم.
یک شکل ساده مورد قابل کاربرد شامل شرح سناریوی آن بصورت ترتیبی از مراحل شماره گذاری شده بهمراه راه حل های ترتیبی به ازای حالات مختلف مورد قابل کاربرد است.
مورد قابل کاربرد فقط آنچه یک سیستم انجام می دهد را توصیف می کند و از چگونگی انجام آن صحبتی نمی کند. برای این منظور، توصیف جریان وقایع یک مورد کاربرد کار مناسبی است. جریان وقایع عبارت است از متنی که در آن موارد زیر لحاظ می شود:

ــ مورد کاربرد کی و چگونه شروع و خاتمه می یابد؟
ــ چه زمانی تعامل با کنشگر صورت می گیرد؟
ــ چه اشیائی در چه زمانی مورد مبادله قرار می گیرند؟
ــ چه روالی عملیات اصلی و چه روالی عملیات استثنایی وجود دارد؟

متن زیر جریان کار یک مورد قابل کاربرد ساده را نشان می دهد.

Buy a product:
1. customer browses through catalog and selects items to buy
2. customer goes to check out
3. customer fills in shipping information ( address; next-day or 3-day delivery)
4. system presents full pricing information , including shipping
5. customer fills in credit card information
6. system authorizes purchase
7. system confirms sale immediately
8. system sends confirming email to customer
Alternative: Authurization failure
At step 6 , system fails to authorize credit purches
Allow customer to re-enter credit card information and re-try
Alternative: Regular customer
3a. system displays current shipping information , pricing information , and last fouur
digits of credit card information
3b. Customer may accept or override these defaults
Return to primary scenario at step 6

تا به حال به بررسی خصوصیات موارد قابل کاربرد پرداختیم . حال سوال این است که چگونه موارد قابل کاربرد را شناسایی کنیم ؟ برای مشخص کردن موارد قابل کاربرد Jacobson بررسی سوالات زیر را پیشنهاد می کند.

ــ آیا کنشگر اعمال خواندن و بروز رسانی اطلاعات را انجام خواهد داد؟
ــ وظیفه اصلی هر کنشگر چیست ؟
ــ آیا کنشگر الزاما تغییرات خارج از سیستم را باید به اطلاع سیستم برساند؟
ــ آیا کنشگر باید از تغییرات غیر منتظره آگاهی داشته باشد؟

[Identifier]

. نمودار مورد قابل کاربرد
موارد قابل کاربرد را بعنوان عناصر اولیه توسعه نرم افزار معرفی نمودیم، این عنصر اولیه باید حاوی اطلاعات سطح بالا در مورد پروژه باشد. Jacobson در سال 1994 نمودار مورد قابل کاربرد را برای بصری سازی این عناصر ارائه نمود. درUML ، کنشگر و مورد قابل کاربرد را بصورت شکل زیر نشان می دهند:


روابط بین موارد قابل کاربرد
سه نوع رابطه بین موارد قابل کاربرد می تواند وجود داشته باشد که عبارتند از :extend>> << و <<include>> و تعمیم . اگر قصد مدل کردن حالتی خاص از یک مورد قابل کاربرد را جهت توسعه سیستم داشته باشیم و موارد قابل کاربرد اصلی به تنهایی و بدرستی وجود داشته باشد، حالت خاص را در یک مورد قابل کاربرد جداگانه نشان می دهیم و از رابطه extend > > << استفاده می کنیم بطوریکه رابطه بین دو مورد قابل کاربرد بصورت یک پیکان با برچسب extend > > << که جهت آن به سمت مورد قابل کاربرد اصلی است، در نمودار مورد قابل کاربرد نمایش داده می شود. عمل مربوط به مورد جدید لزوماً در چرخة عمر مورد توسعه یافته صورت نمی گیرد. اما اگر بخواهیم یک رفتار مشابه بین دو یا چند مورد قابل کاربرد را بصورت یک مورد قابل کاربرد مجزا نشان دهیم و یا قسمتی از کارهای یک مورد قابل کاربرد را بمنظور کاهش پیچیدگی تحت عنوان یک مورد جدید در نمودار نشان دهیم، از رابطه <<include>> استفاده می کنیم بطوریکه از هر مورد قابل کاربرد شامل عملکرد مورد قابل کاربرد جدید، یک پیکان با برچسب <<include>> که به سمت مورد جدید نشانه می رود، نمایش داده می شود. در واقع رفتار مورد قابل کاربرد جدید قسمتی از رفتار مواردی را که با این مورد رابطة <<include>> دارند، تشکیل می دهد و لزوماً عمل مربوط به این مورد در چرخة عمر موارد تقسیم شده صورت می پذیرد. رفتار مورد قابل کاربرد جدید که با رابطه<<include>> به مدل اضافه می شود به منظور کامل کردن عملکرد موارد قابل کاربرد خاصی که از قبل وجود داشت و نیز عدم تکرار این رفتار درهر یک از آنها انجام می شود . هنگامی که تمام موارد قابل کاربرد در نمودار نشان داده شود مدل مورد قابل کاربرد کامل است. اما چگونگی تعامل کنشگر با مورد قابل کاربرد و همچنین نحوه عملکرد موارد قابل کاربرد را نشان نمی دهد. همانطور که اشاره شد، محتوای موارد قابل کاربرد بوسیله متن ساده بیان می شود و هنگام تشریح موارد قابل کاربرد باید به رفتار خارجی مورد بیاندیشیم نه به نحوه عملکرد درونی، و باید چگونگی تعامل کنشگر با مورد قابل کاربرد را از متن استخراج نماییم. دراینجا مثالی دیگر از بیان مورد قابل کاربرد را بررسی می- کنیم.
مثال: می توانیم مورد قابل کاربرد ثبت نام کلاس را بصورت زیر با متن ساده بیان نماییم.
1. دانشجو با وارد کردن اطلاعات زیر فرم ثبت نام را تکمیل می کند
cource number: section number :
year : term :
2. دانشجو فرم تکمیل شده ثبت نام را برای امضاء زدن به استاد راهنما می دهد، استاد راهنما نیز پس از بررسی اطلاعات وارد شده آن را امضاء می کند.
3. دانشجو فرم ثبت نام را به کارمندی که در اداره ثبت نام اطلاعات را وارد کامپیوتر می نماید، تحویل می دهد.
4. کارمند ثبت نام نیز پس از وارد کردن اطلاعات یک پرینت از کلاسهایی که دانشجو ثبت نام نموده است، در اختیار دانشجو قرار می دهد.
توصیف بالا شامل سه مؤلفه زیر می باشد:
ــ یک مورد قابل کاربرد که دانشجو را در کلاس ثبت نام می کند، قابل مشاهده است.
ــ کنشگر (دانشجو)که مورد قابل کاربرد را شروع و آن رامقدار دهی می نماید.
ــ تبادل اطلاعات بین کنشگرها ( دانشجو و کارمند ثبت نام )ومورد قابل کاربرد.
یک نوع رابطه دیگر که درمدل مورد قابل کاربرد قابل استفاده است، رابطه تعمیم می- باشد. از تعمیم زمانی استفاده می شود که یک مورد قابل کاربرد شبیه به موردی دیگر داشته باشیم که موردجدید همان کارهای مورد قبلی بعلاوه یکسری کار جزئی دیگر انجام دهد. تعمیم در موارد قابل کاربرد همانند تعمیم در کلاسهاست در اینجا موارد کاربردتخصیص رفتار را از موارد کاربرد تعمیم به ارث می برند.
در شکل 4-5 روابط <<include>> و <<extend>>و تعمیم نشان داده شده است. در این شکل کنترل رمز ورود و پویش شبکیه چشم تخصیص هایی از اعتبار سنجی کاربر هستندکه رفتار اعتبار سنجی کاربر را به ارث می برند و علاوه بر آن دارای رفتاری اضافه هم هستند. همچنین تسلیم سفارش فوری یک جریان استثنائی از تسلیم سفارش است که به صورت یک مورد قابل کاربرد با استفاده از رابطه<<extend>> با مورد تسلیم سفارش در ارتباط است. همین شکل به وضوح نشان می دهد که تسلیم سفارش شامل اعتبار سنجی کاربر است و از<<include>> استفاده شده است.

یک مورد قابل کاربرد ممکن است نقاط قابل توسعه زیادی داشته باشد و مورد قابل کاربرد نیز یکی یا چند تا از این وجوه توسعه را با تعریف یک مورد جدید توسعه دهد . روابط<<include>> ،<<extend>> و تعمیم به ما اجازه می دهند که مورد قابل کاربرد را به موارد کوچکتری تقسیم کنیم، در طول فاز تفصیل معمولا موارد قابل کاربردی که بسیار پیچیده اند به موارد ریزتری تقسیم خواهند شد. همچنین در فاز ساخت نیز اگر تشخیص بدهیم که در یک تکرار نمی توانیم کل مورد قابل کاربرد را بسازیم از تکنیک تقسیم استفاده خواهیم کرد . بعد از عمل تقسیم ابتدا مورد اصلی و سپس موارد اشتقاق شده را می سازیم.
بطور کلی قوانین زیر را برای روابط موارد کاربرد داریم :
ــ زمانی که رفتاری را بطور مشابه در دو یا چند مورد جدا از هم داریم برای پیشگیری از تکرار از رابطه <<include>> استفاده می کنیم .
ــ هنگامی که می خواهیم راههای متفاوت یک رفتار عادی را توصیف کنیم برای بیان همه این راهکارها از تعمیم استفاده می کنیم.
ــ برای بیان حالات استثنائی یک رفتار عادی ( یک فرم کنترل شده از رفتار عادی ) از رابطه << extend >> استفاده می کنیم .