1 مقدمهusecase ها
با توجه به مفاهیم کلاسها مورد مهمی در uml را بررسی میکنیم که همان usecase ها هستند.
دراین فصل موضوعات زیر مطرح می‌شوند :
• usecase چیست
• ساختن یک usecase
• محتویات یک usecase
• extend یک usecase
• تحلیل یک usecase
در گذشته با دیاگرام‌هایی برخورد کردیم که دیدگاه ثابتی در مورد کلاسهای سیستم ارائه می‌کرد.
به سراغ دیاگرام‌هایی می‌رویم که دیدگاهی پویا ارائه می‌کند ونشان میدهد چگونه سیستم و کلاس‌هایش با گذشت زمان تغییر میکنند .دیدگاه ثابت به روابط بین تحلیلگر و طراحان سیستم کمک می‌کند و دیدگاه پویا به روابط بین تحلیلگر وگروه طراحان کمک می‌کند و به طراحان اجازه میدهد که برنامه بنویسند .
مشتری و تیم طراحان یک مجموعه مهم از امینان سیستم را تشکیل می دهند.
نه دیدگاه ثابت و نه دیدگاه پویا، کارکرد سیستم را از نقطه نظر کاربر نشان نمی‌دهند.
فهمیدن این دیدگاه کلیدی است برای ساختن سیستمی که مفید وقابل استفاده باشد.
این دیدگاه تقاضاها را بررسی می‌کند وکار کردن با آن آسان (و حتی جالب است) است.
مدل کردن سیستم از دیدگاه کاربر آن، کار usecase است .
در این فصل درباره اینکه usecase چیست و چه کاری انجام میدهد صحبت میکنیم و همچنین درباره چگونگی استفاده از دیاگرام usecase در تصویرسازی در UML بحث میکنیم .
2- 1 usecase ها چه هستند ؟
چندین سال قبل من یک فاکس خریدم.
وقتی که برای خرید به دفتر تهیه‌کننده رفته بودم با سطح وسیعی از انتخاب ها برخورد کردم.
چگونه باید تصمیم خوبی می‌گرفتم؟
از خودم پرسیدم می‌خواهم با فاکس چه کاری انجام بدهم؟
چه مواردی را نیاز دارم، چه اعمالی را می‌خواهم با فاکس انجام بدهم؟
آیا می‌خواهم کپی بگیرم؟
به کامپیوتر متصلش کنم؟
به عنوان scanner از آن استفاده کنم؟
می‌خواهم فاکس‌ها را به سرعت بفرستم، که به سرعت شماره‌گیر احتیاج داشته باشم؟می‌خواهم تشخیص بدهم که fax آمده یا کسی تلفن کرده است ؟
از مراحل یک پردازش مانند مراحل بالا وقتی‌که یک خرید بدون انگیزه را ترتیب دادیم گذشتیم.
در تحلیل یک فرم از usecase چه کاری انجام می‌دهیم ؟
از خود می‌پرسیم چگونه از یک محصول یا سیستم استفاده میکنیم، تا پول خود را به خوبی خرج کنیم.
بنابراین مهم‌ترین چیز این است که نیازها را بشناسیم .
این نوع پردازش مخصوصاً برای بخش آنالیز سیستم طراحی شده است .چگونه کاربرها از درایور سیستم از همان راهی که شما طراحی کرده‌اید و سیستم را ساخته‌اید استفاده می کنند ؟
usecase یک ساختار است که به تحلیلگر سیستم که با کاربر کار می‌کند، کمک می‌کند تا سیستم کاربردیی را طراحی کند .
اصطلاح جدید : usecase مجموعه‌ای از سناریوها است که سیستم از آنها استفاده می‌کند.
هر سناریو یک ترتیب زمانی از وقایع را شرح میدهد.
هر ترتیب زمانی به وسیله شخصی یا سیستمی دیگر یا یک قطعه‌ای از سخت‌افزار و یا به‌وسیله گذر زمان بنا نهاده میشود.
موجودیت‌های که ترتیب زمانی را شروع میکنند actor نامیده می‌شوند.
ترتیب زمانی باعث میشود که استفاده‌های دیگری از actor توسط کسانی که actor را بنا گذاشته‌اند و یا توسط دیگر actor ها بشود .
3- 1 چراusecase ها مهم هستند ؟
تنها یک راه با ارزش برای تحریک مشتری به صحبت در مورد دیدگاهش درباره سیستم وجود دارد.
usecase یک ابزار عالی برای تحریک مشتری است.
معمولاً تحریک مشتری برای صحبت مفصل در مورد چگونگی استفاده‌ا‌ش از سیستم کار آسانی نیست.
چراکه توسعه سیستم‌های قدیمی اغلب یک پردازش اتفاقی است، که در تحلیل بسیار کوتاه است.
کاربرها برخی مواقع وقتی در مورد ورودی‌هایشان از آنها سوال میشود، گیج می‌شوند .
ایده‌ای موجود این است که سیستمی که کاربرها با آن کار میکنند را در مراحل اولیه آنالیز و تحلیل سیستم در نظر بگیریم.
این کار احتمال اینکه سیستم در نهایت برای کاربر بهتر شود را بالا می‌برد ، مثل تعویض مفاهیم محاسباتی یک سیستم قدیمی که باعث گیج شدن کاربران برای کار با آن میشود.
4- 1 یک مثال : ماشین نوشابه
فرض کنید که می‌خواهیم یک ماشین نوشابه طراحی کنیم.
برای بدست آوردن دیدگاه کاربران باید با چند نفر از کاربران برای دانستن نحوه برخوردشان باسیستم مصاحبه کنیم.
زیرا عمل اصلی ماشین این است که به مشتری اجازه میدهد یک قوطی نوشابه بخرد ، بنابراین کاربران سریعاً به ما می‌گویند که مجموعه‌ای از سناریوها(به عبارتیusecase ها)را داریم که احتمالاً عنوان ”خرید نوشابه“ را دارند.
بنابراین هر سناریو ممکن را بررسی میکنیم.
توجه داریم که در طراحی سیستم معمولی سناریوها در اثر صحبت با کاربر به وجود می‌آیند.
1-4- 1 usecase خرید نوشابه
actor این usecaseمشتری است، که می‌خواهد یک قوطی نوشابه بخرد.
مشتری سناریو را با انداختن پول آغاز می‌کند.
سپس او امکان انتخاب دارد.
اگر همه چیز به خوبی پیش برود دست کم یک قوطی نوشابه به مشتری تحویل داده میشود.
با توجه به مراحل ترتیب زمانی باید به تصویر دیگری از سناریو توجه شود.
چه پیش زمینه‌ای باعث تحریک مشتری برای آغاز کردنusecase خرید نوشابه میشود؟
تشنگی یکی از شرایط آشکار است.
چه شرایط بعدی لازمه مراحل سناریو است؟
دوباره آشکارترین مورد این است که مشتری یک نوشابه دارد.
آیا سناریویی که تعریف کردیم تنها سناریو ممکن برای این مسئله است؟
موارد دیگری هم سریعاً به ذهن می‌آین .
ممکن است نوشابه دیگری غیر از آنچه مشتری خواسته تحویل داده شود.
ممکن است مشتری پول کافی برای قیمت نوشابه را وارد نکرده باشد.
چگونه می‌توان ماشین را با این سناریو طراحی کرد؟
به مرحله دیگر از usecase خرید نوشابه می‌رویم.
به سراغ سناریو alternative می‌رویم.
مشتری usecase را با انداختن پول به داخل ماشین آغاز می‌کند.
سپس امکان انتخاب دارد، اما ماشین در انتها قوطی نوشابه‌ای که انتخاب شده را تحویل نمی‌دهد و به مشتری پیام میدهد که پول خارج از محدوده ماشین است.
پیام باید به گونه‌ای باشد که مشتری را برای انتخاب دیگر تحریک کند.
همچنین ماشین باید پیشنهادی برای پس دادن پول به مشتری بدهد.
در این جا، مشتری نوشابه دیگری را انتخاب می‌کند و ماشین آن را تحویل میدهد (اگر انتخاب جدیدی صورت نگیرد نوشابه نیز فروخته نمی‌شود) و یا عمل تحویل پول اتفاق می‌افت .
شرایط بعدی، تحویل یک قوطی نوشابه یا تحویل پول است.
سناریو دیگری نیز ممکن است اتفاق بیفتد.
”خارج از محدوده“ پیامی است که زمانی‌که ماشین موجودی نداشته باشد نمایان میشود و در این مرحله باقی می‌ماند تا زمانی که دوباره پر شود و بتواند نوشابه را تحویل دهد.
در این مرحله ممکن است که مشتری پول را نیانداخته باشد.
مشتری که ما ماشین را برایش طراحی کرده‌ایم ممکن است سناریو اول را ترجیح بدهد.
اگر مشتری پول را وارد ماشین کرده ممکن است مایل باشد انتخاب دیگری انجام بدهد، تا اینکه در مورد پس دادن پول از او سوال شود.
سناریو دیگری نیز ممکن است اتفاق بیفتد.
اگر مشتری پول را وارد ماشین کرده ممکن است مایل باشد انتخاب دیگری انجام بدهد، تا اینکه در مورد پس دادن پول از او سوال شود.
سناریوی دیگری را بررسی میکنیم که مقدار پول به اندازه قیمت نوشابه نباشد.
دوباره مشتری usecase را آغاز می‌کند، که مراحل معمولی را تکرار می‌کند و یک انتخاب می‌کن .
فرض میکنیم نوشابه انتخابی موجود باشد.
اگر ماشین اندوخته پولی داشته باشد تا بتوند پول را خرد کند، بقیه پول را پس میدهد و نوشابه را هم تحویل میدهد.
حال اگر اندوخته پول نداشته باشد، پول را برمی‌گرداند و پیامی میدهد که از مشتری می‌خواهد پول کافی را وارد کند.
شرایط قبلی حالات معمولی است.
شرایط بعدی تحویل نوشابه با مابقی پول است و هم ماشین کل پول را پس میدهد، می‌باشد.
امکان دیگر این است که اندوخته پول ماشین تمام شده باشد.
یک پیام از مشتری می‌خواهد که پول کافی را وارد کند.
ممکن است این پیام تا هنگامی که اندوخته ماشین پر شود نمایان باشد.
2-4- 1 Usecaseهای اضافی ماشین خرید نوشابه را از دیدگاه مشتری بررسی کردیم.
علاوه بر مشتری کاربران دیگری هم وجود دارند .
یکی از آنها تهیه‌کننده است که در ماشین نوشابه می‌گذارد و دیگری تحصیلدار است، (ممکن است همان تهیه‌کننده باشد) که پول‌های جمع شده در ماشین را جمع آوری می‌کن .
این مورد روشن می‌کند که حداقل دو usecase ،اضافه‌تر باید ساخته شود.
موجودی داخل ماشین گذاشتن وجمع‌آوری پول ماشین که جزئیات آنها در اثر صحبت با تهیه‌کننده و تحصیلدار روشن میشود.
usecase گذاشتن نوشابه داخل ماشین را بررسی میکنیم.
تهیه‌کننده یک usecaseرا آغاز می‌کند، زیرا مدتی از کارکرد ماشین گذشته است.
تهیه‌کننده قفل ماشین را باز می‌کند (که پیاده‌سازی نمی‌شود)، قسمت جلویی ماشین باز می‌کند و ظرفیت ماشین را پر می‌کند.
تهیه‌کننده اغلب اندوخته پول را هم خالی می‌کند.
سپس قسمت جلویی ماشین را می‌بندد و ماشین را قفل می‌کند.
شرایط قبلی در مدت قبلی اجرا میشود، شرایط بعدی این است که تهیه‌کننده مجموعه جدیدی از اجناس را داشته باشد.
برای usecase جمع‌آوری پول، تحصیلدار یک usecase را آغاز می‌کند، زیرا مدتی از کار ماشین گذشته است.
تحصیلدار مراحلی را که برای موجودی گذاشتن داخل ماشین وجود داشت را با باز کردن قفل و قسمت جلویی ماشین طی می‌کند.
سپس تحصیلدار پول را بر‌می‌دارد و مراحل بستن قسمت جلویی ماشین و قفل کردن آن را مانند مراحل usecase گذاشتن نوشابه داخل ماشین طی می‌کند.
شرایط قبلی گذشتن مدتی از کار ماشین و شرایط بعدی برداشتن پول توسط تحصیلدار است.
توجه داریم که هنگامی‌که یک usecase را می‌سازیم نباید نگران تکمیل آن باشیم.
در مثالی که زدیم به داخل ماشین توجهی نکردیم.
به اینکه یخچال ماشین چگونه کار می‌کند توجهی نداشتیم، یا در جریان پول داخل ماشین نبودیم.
ما فقط تلاش کردیم که ببینیم یک ماشین نوشابه با فردی که می‌خواهد از آن استفاده کند چگونه رفتار می‌کند.
هدف گرفتن مجموعه‌ای از usecaseها است که سرانجام به افرادی که می‌خواهند ماشین را طراحی کنند و افرادی که می خواهند ماشین را بسازند ارائه میشود.
گسترش دادن usecaseها برآنچه مشتری، تهیه‌کننده و تحصیلدار می‌خواهند تاثیر می‌گذارد و نتیجه ماشینی است که تمام این گروه‌ها به راحتی می‌توانند از آن استفاده کنند.
5- 1 Include یک usecase در usecase قرار دادن نوشابه در ماشین وusecase جمع‌آوری پول باید به یک سری مراحل عمومی توجه شود.
هر دو با باز کردن قفل و در ماشین آغاز می‌شوند و با بستن قفل و در ماشین پایان می‌یابند.
آیا میشود یکی از دو نسخه مراحل را از یکی از دو usecase حذف کرد؟
راه ممکن برای انجام این کار این است که هر کدام از مراحل زمانی عمومی را گرفته و یک usecase اضافی برای هر کدام بگیریم.
سپس مراحل باز کردن قفل و در ماشین را در یک usecase با نام نمایش داخل ماشین ترکیب کرده و مراحل بستن در و قفل ماشین را در یک usecase با نام پنهان کردن داخل ماشین ترکیب می‌کنی .
با این usecaseهای جدید گذاشتن نوشابه داخل ماشین با usecase نمایش داخل ماشین آغاز میشود.
تهیه‌کننده مراحل قبل را طی کرده و با usecase پنهان کردن داخل ماشین به انتها می‌رسد.
همچنین usecase جمع‌آوری پول با usecase نمایش داخل ماشین آغاز شده و مراحل قبلی را طی می‌کند و با usecase پنهان کردن داخل ماشین تمام میشود.
همانطور که دیدیم قرار دادن نوشابه و جمع‌آوری پول در یک usecase جمع شده‌اند، بنابراین با این روش استفاده دوباره از usecase به محتویات آن برمی‌گردد.
نسخه جدید uml به include،usecase به عنوان usecase استفاده شده تعبیر می‌کند.
ممکن است هنوز روش قدیمی موجود باشد.
including دو مزیت دارد .
اول : واضح‌تر است.
مراحل usecase اول شامل مراحل دیگری هم هست.
دوم : از آشفتگی و شلوغی جلوگیری می‌کند.
این راه را نباید به عنوان استفاده دوباره از usecase به وسیله خودش تلقی کرد.
6- 1 توسعه دادن usecase می‌توان از usecase در روش دیگری غیر از include استفاده کرد.
بعضی اوقات می‌توان یک usecase جدید را با اضافه کردن بعضی مراحل به usecase موجود ساخت.
به usecase قرار دادن نوشابه برمیگردیم.
قبل از قرار دادن قوطی‌ها در ماشین، فرض میکنیم تهیه‌کننده به نوشابه‌ای که خوب فروش می‌رود و نوشابه‌ای که خوب فروش نمی‌رود توجه کند.
به جای روش معمول موجودی گذاشتن تمام نوشابه‌ها، تهیه‌کننده باید نوشابه‌هایی را که خوب فروخته نشده‌اند را جایگزین آنها کند.
سپس مجموعه جدیدی از نوشابه‌ها را تعین می‌کند.
اگر این مراحل را به گذاشتن نوشابه داخل ماشین اضافه کنیم، میتوانیم usecase جدید را قرار دادن نوشابه بر اساس فروش بنامیم.
این usecase جدید extend یا گسترش usecase اصلی است و این روش extending یا گسترش usecase نامیده میشود.
7- 1 شروع تحلیل usecase در مثالی که زدیم از روی یک سری usecaseها گذشتیم و روی بعضی تمرکز کردیم.
در معنای واقعی هنگامی که می‌خواهیم تحلیل usecase را آغاز کنیم معمولاً از یک سری از رویه‌ها پیروی میکنیم.
با صحبت با مشتری(یا کارشناس)شروع میکنیم، که منتهی به بنا نهادن دیاگرام کلاسها میشود.
این کار یک ایده در مورد ناحیه‌ای که می‌خواهیم با آن کار کنیم میدهد و همچنین آشنایی با اصطلاحاتی که قرار است از آنها استفاده کنیم میدهد.
پس یک پایه برای صحبت با کاربران داریم.
با کاربران صحبت میکنیم (ترجیحاً در یک گروه) و از آنها می‌خواهیم درباره تمام مواردی که با سیستمی که می‌خواهیم طراحی کتیم، می‌خواهند انجام دهند را توضیح دهند.
جواب های آنها مجموعه‌ای از usecaseهای ابتدایی را تشکیل میدهد.
سپس مهم این است که هر usecase را مختصراً توضیح دهیم.
اغلب یک لیست از actorهایی که usecase را بنا می‌دهند یا از آن استفاده میکنند را باید در نظر بگیریم.
اگر اطلاعات بیشتری در این قسمت بگیریم، توانایی خود را در صحبت با کاربران به زبان خودشان بالاتر می‌بریم.
usecase ها در مراحل مختلف توسعه پردازش پدیدار می‌شوند.
این usecaseها به طراحی سیستم از نظر تقابل کاربر با سیستم کمک میکنند و منابعی را برای امتحان کردن سیستم جدید ساخته شده آماده میکنند.
برای تحلیل usecase ها باید با UML به طور کاربردی کار کرد.
فصل دوم 1- 2 دیاگرامusecase usecaseیک مفهوم مؤثر برای کمک به تحلیلگر است که بفهمد یک سیستم جگونه باید رفتار کند.
همچنین به جمع‌آوری نیازها از دید کاربران نیز کمک می‌کند.
در این فصل مفاهیم usecase را که در فصل پیش مطرح شد تصویر سازی میکنیم.
مباحث این فصل : نمایش مدل usecase تصویر سازی ارتباط بین usecaseها قوانین دیاگرامهای usecase در توسعه پردازش ساختن و کاربرد مدل usecase مفهوم مهم usecase این است که usecase بسیار بیشتر از آنچه در UMLبرای تصویر سازی استفاده می شود قدرتمند است .
تصویرسازی اجازه میدهد که usecaseها را به کاربرانی که می توانند اطلاعات بیشتر به ما بدهند نشان بدهیم.
در واقع، کاربران اغلب بیشتر از آنچه می‌توانند در موردش صحبت کنند اطلاعات دارند.
بنابراین نمایش تصویر اجازه میدهد که دیاگرام usecae را با انواع دیگر دیاگرام‌ها مقایسه کنیم.
یکی از اهداف پردازش تحلیلی سیستم ایجاد مجموعه‌ای ازusecase ها است.
این ایده می‌تواند به عنوان راهنما و مرجع مجموعهusecaeها قرار گیرد که هنگامی که زمان بهینه کردن سیستم باشد، به جای دید هر کاربر نسبت به سیستم به کار می‌رود.
راهنمای usecaseها به عنوان منبعی برای جمع‌آوری نیازها برای بهتر کردن سیستم به کار می‌رود.
2-2 نمایش مدل usecase actor یک usecase را آغاز می‌کند وactor (ممکن است آغاز کننده باشد اما لازم نباشد)مقادیری از usecase را می‌گیرد.
نمایش گرافیکی آن ساده است.
یک بیضی نمایش دهنده usecase و آدمک نمایش دهنده actor است.
actor آغاز کننده usecase در سمت چپ و actorی که اطلاعات از usecase می‌گیرد در سمت راست است.
اسم actor درپایین آن نمایش داده میشود.
اسم usecase در داخل بیضی یا در زیر آن نوشته می شود.
خط ممتد که actor و usecase را به مربوط می کند، ارتباط بین actor و usecase را نشان میدهد.
این خط ممتد مثل خط ممتد در کلاسهاست که روابط بین آنها را مشخص می‌کرد.
یکی از مزایای تحلیل usecaseها این است که مرز بین سیستم ومحیط خارج را نشان میدهد.
به طور نمونه actorها خارج از سیستم هستند در حالیکه usecaseها درون سیستم هستند.
با استفاده از یک مستطیل (با اسم سیستم در داخل آن) مرز سیستم را می‌توان نشان داد.
این مستطیل usecaseهای سیستم را احاطه می‌کند.
اصطلاح جدید : actorها، usecaseها و خطوط روابط مدل usecase را تشکیل می‌دهند.
شکل 1-2 این نشانه را نمایش میدهد.
1-2-2 بازبینی ماشین نوشابه حال نمودارهای مثال قبل را نمایش می‌دهیم.
با توجه به فصل قبل usecaseهای ماشین نوشابه را طراحی کردیم.
usecaseهای خرید نوشابه و قرار دادن نوشابه و جمع‌آوری پول همه داخل سیستم قرار می‌گیرند.
actorها مشتری، تهیه‌کننده و تحصیلدار هستند.
شکل 2-2 مدل UML، usecase ماشین نوشابه را نمایش میدهد.
2-2-2 دنبال کردن مراحل سناریو هر usecase مجموعه‌ای از سناریوهاست و هر سناریو سلسله مراتبی از مراحل مختلف است.
همان طور که در شکل پیدا است این مراحل در دیاگرام نمایش داده نمی‌شود.
سناریوها در usecaseها پیوست نمی‌شوند.
اگرچه UML نوشتن سناریو در usecase را منع نمی‌‌کند.
واضح بودن کلید ساختن هر دیاگرامی است و اضافه کردن توضیحات به هر usecase باعث شلوغ شدن دیاگرام‌ها میشود و به راحتی نمی‌توان مراحل را دنبال کرد.
دیاگرامهای هرusecase معمولاً قسمتی از مدارک طراحی هستند که هم مشتری و هم طراحان سیستم به آن رجوع میکنند .
هر دیاگرام صفحه خودش را دارد و هر سناریو هر usecase معمولاً یک صفحه برای خود دارد که دارای موارد زیر است : actorی که usecase را آغاز می‌کند شرایط قبلی usecase مراحل سناریو شرایط بعدی وقتی که سناریو کامل میشود actorی که از usecase مواردی را دریافت می‌کند اغلب فرضیات را برای سناریو لیست میکنیم (برای مثال مشتری از ماشین در یک زمانی استفاده می‌کند)، و یک با جمله مختصر و مفید سناریو را تشریح میکنیم.
در فصل قبل قسمت ساخت یک usecase چند سناریو alternative ارائه شد.
می‌توان لیست دیگری از سناریوها را جداگانه گرفت (نبودن موجودی و درست نبودن پول) یا می‌توان سناریوها را به عنوان استثنا در سناریو اول بررسی کرد.
این کارها به عهده ما، مشتری و کاربران است.
برای نمایش مراحل سناریو در UML از دیاگرام های فعال استفاده میشود.
3-2 تصویرسازی روابط بین usecaseها اصطلاح جدید : مثال فصل قبل دو راه را نشان داد که usecaseها می‌توانند با هم ارتباط داشته باشند.
یک راه include کردن بود که اجازه استفاده از یک usecase در درون usecase دیگر را می‌داد.
راه دیگر extension است که اجازه میدهد یک usecase جدید را با اضافه کردن مراحلی به usecase موجود بسازیم.
اصطلاح جدید : دو نوع رابطه دیگر generalization و grouping هستند.
شبیه generalization در کلاسها، یک usecase از usecase دیگر ارث می‌برد.
grouping یک راه ساده برای مرتب کردن و سازمان دهی کردن مجموعه‌ای از usecaseها است.
1-3-2 Inclusion Usecaseهای قرار دادن نوشابه در ماشین و جمع‌آوری پول را از مثال ماشین نوشابه بررسی میکنیم.
هر دو با باز کردن قفل و در ماشین شروع می‌شوند و با بستن در ماشین وقفل آن پایان می‌یابند.
usecase نمایش داخل ماشین دو مرحله اول را تسخیر می‌کند و usecase پنهان کردن داخل ماشین دو مرحله بعد را تسخیر می‌کند.
هر دو usecase قرار دادن نوشابه و جمع‌آوری پول شامل این دو usecase است.
برای نمایش inclusion ، از نمادی که برای نشان دادن وابستگی کلاسها به هم استفاده می‌شد، استفاده میکنیم و آن یک خط چین با داشتن پیکانی در سرش است که این پیکان به کلاسی که وابستگی دارد اشاره می‌کند.
در بالای خط‌چین stereotype که کلمه inclusion در داخل گیومه است، اضافه میکنیم.
شکل 3-2 رابطه inclusion بین usecaseها را در مثال ماشین نشان میدهد.
به خاطر داریم که usecaseی که include شده یعنی پیکان inclusion به آن مربوط شده به تنهایی نمی‌تواند موجود باشد، بلکه تنها به عنوان قسمتی از usecaseی که include شده کار می‌کند.
در یادداشتی که سلسله مراتب را دنبال می‌کند usecaseهای include شده مشخص می‌شوند.
مرحله اول usecase قرار دادن نوشابه در ماشین باید include شود.
(usecase نمایش داخل ماشین) 2-3-2 Extension اصطلاح جدید : در فصل قبل نشان داده شد که usecase قرار دادن نوشابه داخل ماشین می‌تواند پایه‌ای برای usecase دیگری به نام قرار دادن نوشابه بر اساس فروش باشد.
به جای اینکه فقط نوشابه های فروخته شده را تکمیل کنیم، تهیه‌کننده می‌تواند یادداشتی از نوشابه‌هایی که خوب فروش رفته‌اند و آنهایی که خوب فروش نمی‌‌روند داشته باشد و مطابق آن نوشابه داخل ماشین بگذارد.
usecase جدید extend ، usecase اصلی است.
زیرا مرحله جدیدی به سلسله مراتب usecase اصلی که اغلب usecaseپایه نامیده میشود اضافه کرده است.
اصطلاح جدید : extension فقط در نقاط ویژه تعیین شده در سلسله مراتب usecase پایه می تواند اتفاق بیفتد.
این نقاط extension نامیده می‌شوند.
در usecase قرار دادن نوشابه مراحل جدید (توجه به فروش و تعویض بر این اساس)، بعد از اینکه تهیه‌کننده در ماشین را باز کرد و آماده گذاشتن نوشابه داخل ماشین شد رخ میدهد.
برای مثال نقطه extension پر کردن ماشین است.
مانند inlusion ،extension را می توان با یک خط وابستگی (خط چین با پیکان) که بر روی آن stereotype ، extend وجود دارد نمایش داد.
درون usecase پایه نقطه extension در زیر اسم می‌آید.
شکل 4-2 رابطه extension برای usecaseهای گذاشتن نوشابه وگذاشتن نوشابه براساس فروش را با رابطه inclusion بین usecaseهای گذاشتن نوشابه و جمع‌آوری پول نشان میدهد.
3-3-2Generalization ( عمومیت دادن ) کلاسها می‌توانند از یکدیگر ارث ببرند، همچنین usecaseها هم از یکدیگر ارث ببرند.
در وراثت usecaseها ، usecase فرزند رفتار و مفاهیم و معانی را از پدر خود به ارث می‌برد و به رفتارهای خود اضافه می‌کند.
می‌توان در هر جایی که از usecase پدر استفاده میشود، usecase فرزند را به کار برد.
در مثال ماشن نوشابه ممکن است تصور شود که usecase خرید یک قوطی نوشابه از usecase خرید نوشابه ارث می‌برد.
فرزند رفتارهایی مثل اضافه کردن یخ و مخلوط کردن قوطی‌های نوشابه را به usecase اصلی اضافه می‌کند.
generalization را برای usecaseها می توان به همان ترتیب کلاسها generalize کرد، که باید با یک خط ممتد که یک مثلث تو خالی به پدر اشاره می کند، مدل کرد .
رابطه generalization همان طور که بین usecaseها وجود دارد، می تواند مابین actorها هم باشد.
می‌توان هر دو actor تهیه‌کننده و تحصیلدار را با actor تهیه‌کننده نمایش داد.
اگر تهیه‌کننده را به نام جایگزین کننده نوشابه تغییر نام بدهیم، جایگزین‌کننده و تحصیلدار هر دو فرزندان actor تهیه‌کننده هستند.
4-3-2 Grouping (دسته بندی) در بعضی از دیاگرامهای usecase ، تعداد بسیاری از usecaseها وجود دارند که باید سازماندهی شوند.
سازماندهی usecaseها زمانی اتفاق می‌افتد که سیستم از چند زیر سیستم تشکیل شده باشد.
احتمال دیگر این است که در زمانی که با کاربران برای جمع‌آوری نیازهای سیتم صحبت میکنیم، احتیاج به سازماندهی usecaseها داشته باشیم.
هر نیاز سیستم در یک usecase جداگانه نمایش داده میشود.
پس به راهی برای دسته‌بندی نیازها احتیاج داریم.
ساده‌ترین راه این است که usecaseهایی که با هم ارتباط دارند را در گروههایی در یک بسته (package) سازماندهی میکنیم.
بسته، یک folder نشانه گذاری شده است.
گروههای usecase را داخلfolder نمایش می‌دهند.
4-2 دیاگرام usecase در پردازش تحلیلی در مثال ماشین نوشابه تفحص کردیم و از نمادهای usecase استفاده کردیم.
حال به عقب برمیگردیم و usecaseها را از نظر مفهومی تحلیل میکنیم.
تحلیل باید با صحبت با مشتری آغاز شود.
این مصاحبه دیاگرام کلاسها را بدست میدهد که به عنوان اساس دانش ما در مورد قلمرو سیستم به کار می‌رود(قلمرو ناحیه‌ای است که مسائل در آن حل میشود).
بعد از اینکه اصطلاحات مشتری را شناختیم آماده صحبت با کاربران می‌شویم.
مصاحبه با اصطلاحات مشتری آغاز میشود اما بعداُ باید به اصطلاحات کاربران تبدیل شود.
نتیجه اولیه این صحبت‌ها باید actorها وusecaseهای سطح بالا که نیازهای عملی را در اصطلاحات اصلی توصیف می‌کند، آشکار‌کند.
این اطلاعات مرزها واهداف سیستم را ارائه میکنند.
بعد از صحبت با کاربران نیازهای سیستم را عمیق‌تر بررسی میکنیم، usecase نهایی سناریوها و سلسله مراتب جزئیات را نمایش میدهد.
ممکن است در usecase نهایی روابط inclusion و extension وجود داشته باشد.
در این قسمت، مهم است که بر مفاهیم قلمرو تکیه کنیم.
اگر مفهوم قلمرو را خوب درک نکرده باشیم، usecasهای بسیار و جزئیات زیادی را می‌سازیم که مانع طراحی میشود.
5-2 کاربرد دیاگرام usecase : یک مثال برای بهتر فهمیدن مدل usecase و چگونگی به کاربردن آن درباره مثال پیچیده‌تری نسبت به ماشین نوشابه صحبت میکنیم .
فرض میکنیم می‌خواهیم یک شبکه محلی (LAN) برای مشاور یک شرکت طراحی کنیم و باید عملکردهایی را به حساب آوریم.
چگونه باید شروع کنیم؟
شبکه محلی یک شبکه ارتباطی است که یک سازمان بدون مرز از آن استفاده می‌کند.
این شبکه به کاربران اجازه میدهد که منابع اطلاعاتی را بین خودشان تقسیم کنند.
1-5-2 مفهوم قلمرو (domain) با صحبت با مشتری برای ساختن دیاگرام‌ها کلاسها شروع میکنیم.
دیاگرام کلاسها ممکن است شامل کلاسهای مشاور، مشتری، پروژه، پیشنهادات، داده ها و گزارشات باشد.
شکل 7-2 نشان میدهد که این دیاگرام باید چگونه باشد.
شکل7-2 2-5-2 مفهوم کاربران اکنون که قلمرو را بدست آوردیم، توجه خود را به کاربران معطوف میکنیم زیرا هدف به حساب آوردن انواعی از عملکردها برای ساختن سیستم است .
در معنای واقعی باید با کاربران صحبت کنیم.
برای مثال باید افکار خود را بر پایه یک سری اطلاعات کلی در مورد شبکه محلی و قلمرو بگذاریم.
باید توجه داشته باشیم که در هر جا هیچ نمی‌تواند جای صحبت با افراد را در معنای واقعی تحلیل سیستم بگیرد.
گروهی از کاربران مشاور هستند و برخی دیگر اعضا دفتری.
بعضی دیگر از کاربران شامل مشاور حقوقی، فروشندگان، مدیر شبکه، مدیر دفتر و مدیران پروژه هستند.
دراینجا نشان دادن کاربران در یک سلسله مراتب generalization مفید است .
همان طور که در شکل 8-2 نشان داده شده است.
3-5-2 مفهوم usecaseها برای usecaseهای مثال طراحی شبکه محلی چند احتمال وجود دارد.
تهیه کردن سطوح امنیتی، ساختن یک طرح ،ذخیره طرح، استفاده از e-mail، تقسیم کردن اطلاعات بانک اطلاعاتی، نمایش دادن حسابها، ارتباط پیدا کردن با شبکه از خارج آن، ارتباط با اینترنت، کاتالوگ طرح، استفاده از طرح‌های قبلی و تقسیم چاپگرها بر اساس این اطلاعات شکل9-2 دیاگرامهای سطوح بالا را که باید بسازیم نمایش میدهد .
4-5-2 dirilling down usecaseهای سطح بالا را بررسی میکنیم ، تا مدل usecase را بسازیم .
عمل بسیار مهم دنوشتن پیشنهادات است .
پس usecase ساختن طرح را بررسی میکنیم .
شکل9-2 صحبت با مشاورین ممکن است چند مرحله به usecaseها اضافه می‌کند.
قبل از همه actor مشاور آغاز کننده usecase است.
مشاور به عنوان یک کاربر مهم وارد شبکه میشود.
سپس مشاور از سوئیت نرم‌افزاری دفتر (واژه‌پرداز و گرافیک) برای نوشتن طرح‌ها استفاده می‌کند.
در این تحلیل مشاور از جزئیات طرح‌های قبلی استفاده می‌کند.
مشاور شرکت ممکن است سیاستی داشته باشد که مامور حقوقی و دو مشاور دیگر طرح را قبل از اینکه به مشتری ارائه شود بررسی کنند.
برای اجرا این سیاست مشاور طرح‌ها را در یک انبار مرکزی قابل دسترس برای شبکه محلی ذخیره می‌کند و e-mail دوره سوم با یک پیام می‌گوید که طرح آماده است.
بعد از دریافت و بازخورد و اصطلاحات لازم (دوباره استفاده از سوئیت نرم‌افزار دفتر) مشاور از طرح‌ها پرینت می‌گیرد و برای مشتری ارسال می‌کند.
بعد از تمام شدن این مراحل مشاور از شبکه خارج میشود.
هنگامی که یک مصاحبه بعضی چیزها را مانند سیاست سه دوره نام برده شده، آشکار می‌کند باید متوجه یادداشتها باشیم.
یعنی باید آماده شنیدن مواردی در باره منطق تجاری کمپانی باشیم که این منطق مجموعه‌ای از قوانین برای چگونگی رفتار آنهاست.
اگر به عنوان یک تحلیلگر فکر نکنیم بهتر میتوانیم فرهنگ مشتری و نیازهای سازماندهی شده را بفهمیم.
با توجه به سلسله مراتب قبلی واضح است که برخی از مراحل یک usecase در دیگری تکرار شده‌اند.
بنابراین در مورد usecaseهای دیگر (ممکن است include شده باشند) ممکن است قبلاً چیزی نیاموخته باشیم.
وصل شدن به شبکه و تصدیق شدن دو مرحله‌ای هستند که usecaseهای متعددی می‌توانند include آنها باشند.
بنابراین usecaseی با نام ”تصدیق کاربر“ می‌سازیم که از usecase ساختن طرح include میشود.
دو usecase ، include شده دیگر با نامهای استفاده از سوئت نرم‌افزار دفتر و خارج شدن از شبکه نام گذاری می‌شوند.
با توجه به پردازش طرح‌ها ممکن است متوجه شویم که طرحی که برای مشتری جدید نوشته میشود متفاوت از طرحی است که برای مشتری موجود نوشته میشود.
در حقیقت طرح مشتری جدید ممکن است اطلاعات پیشرفته‌تری راجع به شرکت ارائه دهد.
بنابراین usecase جدید دیگری به نام ساختن طرح برای مشتری جدید به usecase ساختن طرح extend میشود.
این مثال یک نکته مهم را ثابت می کند، نقطه‌ای که قبلاً روی آن تمرکز کردیم.
تحلیل usecase رفتار سیستم را توصیف می‌کند.
شکل 10-2 فصل سوم 1-3 دیاگرامهای ثابت (state diagram) در مورد مهم‌ترین عناصر ساختاری UML صحبت کردیم.
حال در مورد عنصری که چگونگی تغییر را در طول زمان نمایش میدهد صحبت میکنیم.
در این فصل درباره موضوعات زیر صحبت می کنیم دیاگرام state چیست اتفاقات ، اعمال و شرایط محافظت زیرحالت‌ها : پی‌درپی و همزمان اصطلاح جدید : در این فصل در مورد طبقه بندی که قبلاً با آن کار نکردیم صحبت میکنیم.
این گروه جدید با نام عناصر رفتاری نشان میدهد که قسمت هایی از مدل های UML با گذشت زمان چگونه تغییر می کنند.
پس در مورد عضو مهم این گروه با نام دیاگرامهای state صحبت می کنیم.
هر ساله مدل های جدیدی برای ماشین ولباس‌ها ارائه می‌شوند.
فصل ها رنگ برگ‌ها را تغییر می‌دهند و با گذشت سال ها بچه ها بزرگ می شوند، حوادث اتفاق می‌افتد و اطراف تغییر میکنند.
گذر زمان در مورد هر سیستمی صادق است.
در تقابل سیستم با کاربران یا دیگر سیستم ها ممکن است تغییر کند.
اگر بخواهیم سیستمی را مدل کنیم باید مکانیسمی برای این کار داشته باشیم.
2-3 دیاگرام state چیست یک راه برای توصیف کردن تغییرات در یک سیستم این است که بگوییم objectهای سیستم در پاسخ به حوادث و اتفاقات و زمان حالتشان تغییر می‌کند.
چند مثال ساده می‌زنیم : وقتی کلید برق را می‌زنیم چراغ تغییر حالت می دهد و از حالت خاموش به حالت روشن در می‌آید .
وقتی دکمه تلویزیون را می‌زنیم، تلویزیون از نشان دادن یک کانال به نشان دادن کانال دیگر تغییر حالت میدهد.
بعد از گذشتن زمان مشخصی ماشین لباسشویی از حالت شستن به حالت آبکشی می‌رسد.
اصطلاح جدید : دیاگرام state ، این نوع تغییرات را نمایش میدهد.
این دیاگرام‌ها حالت های یک object را در انتقال حالت‌ها و نقطه شروع وپایان را در سلسله مراتب تغییر حالات نمایش میدهد.
اصطلاح جدید : یک دیاگرام state معمولاً به ماشین state نسبت داده میشود.
توجه میکنیم که دیاگرام state ذاتاً متفاوت از دیاگرام object و دیاگرام usecase در بسیاری از موارد مهم است.
دیاگرامی که اکنون می‌خواهیم آن را بررسی کنیم، رفتار سیستم یا حداقل گروهی از کلاسها، objectها و یا usecaseها را مدل می‌کند.
دیاگرام state حالت های یک object را نمایش می‌ده .
مرسوم است که حرف ابتدایی نام state بزرگ نوشته میشود و اغلب هر کجا امکان باشد نام state به ing ختم میشود(به طور مثال ”dialing “ و ”faxing “) که در بعضی موارد امکان پذیر نیست (به طور مثال ”idle “ را نمی توان با ing نوشت) 1-2-3مجموعه نمادها شکل 1-3 یک مستطیل که گوشه‌های آن گرد شده است را نمایش میدهد که نماد state است.
خط ممتد با داشتن پیکان بر سرش نشان دهنده انتقال از یک state به state دیگر است.
سر پیکان stateی که انتقال به آن صورت گرفته را نشان میدهد.
شکل همچنین نقطه شروع را با دایره توپر سیاه ونقطه پایان را با نقطه توخالی نمایش میدهد.
2-2-3 اضافه کردن جزئیات به نماد state UML اجازه میدهد که جزئیات را به نمادها اضافه کنیم.
همان طور که میتوانیم نماد کلاس را به سه قسمت تقسیم کنیم(نام ، صفات خاصه و عملیات) ، میتوانیم نماد state را به سه قسمت کنیم.
قسمت بالایی نام state را دارد، ناحیه میانی متغیرهای ثابت هستند و قسمت پایینی فعالیت‌ها قرار دارند.
شکل 2-3 این سه ناحیه را نمایش میدهد.
متغیرهای ثابت مثل شمارنده‌ها و تایمرها برخی مواقع مفید هستند.
فعالیت‌ها شامل اتفاقات و عملیات هستند.
سه مورد از فعالیت‌هایی که اغلب مورد استفاده هستند، ورود (وقتی سیستم وارد state میشود چه اتفاقی می افتد) ، خروج (وقتی سیستم از state خارج می شود چه اتفاقی می‌افتد) و انجام (وقتی سیستم داخل state است چه اتفاقی می‌افتد) می‌توان موارد لازم دیگر را نیز اضافه کرد .