لینک دانلود و خرید پایین توضیحات
فرمت فایل word و قابل ویرایش و پرینت
تعداد صفحات: 46
فصل اول
1- 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 به طور کاربردی کار کرد.
دانلود آموزی uml 47 ص
