تحقیق درباره آموزی uml 47 ص

اختصاصی از کوشا فایل تحقیق درباره آموزی uml 47 ص دانلود با لینک مستقیم و پر سرعت .

لینک دانلود و خرید پایین توضیحات

فرمت فایل 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 معماری نرم‌افزار به مدل کارایی شبکه‌های صف QN

اختصاصی از کوشا فایل پاورپوبنت درمورد تبدیل توصیف UML معماری نرم‌افزار به مدل کارایی شبکه‌های صف QN دانلود با لینک مستقیم و پر سرعت .

دسته بندی : پاورپوینت 

نوع فایل:  ppt _ pptx

( قابلیت ویرایش )

---

 قسمتی از اسلاید پاورپوینت : 

تعداد اسلاید : 58 صفحه

تبدیل توصیف UML معماری نرم‌افزار به مدل کارایی شبکه‌های صف (QN) و تولید بازخورد از نتایج ارزیابی کاراییTransforming UML Specification of Software Architectures into Queuing Networks (QN) Performance Model and Feedback Provision from Performance Evaluation Results.
عناوین مورد بحث انگیزه‌ها و اصول عمومی پیش زمینه ضرورت و اهداف تشریح متدولوژی ارزیابی کارایی مثال کاربردی: سیستم خود پرداز بانکی(ATM) جمع بندی و نتیجه گیری عناوین مورد بحث انگیزه‌های تحلیل کارایی نرم افزار هزینه های هنگفت مالی، انسانی و زمانی تولید و توسعه یک سیستم نرم افزاری بزرگ کیفیت نرم‌افزار تا حدود زیادی توسط مشخصه‌های کارایی مثل زمان پاسخ، توان عملیاتی، و بهره‌وری منابع تعیین می‌شود شناسایی زود هنگام مشکلات کارایی در سطح معماری نرم‌افزار افزایش هزینه تغییر طراحی با جلو رفتن در فرایند تولید تأیید اعتبار انتخابهای طراحی یا مقایسه طراحی های مختلف از دیدگاه کارایی دو پرسش در اینجا مطرح است: چگونه کارایی را در فرایند تولید نرم‌افزار ارزیابی کنیم؟
کی کارایی باید ارزیابی شود؟
انگیزه‌ها و اصول عمومی کارایی چگونه ارزیابی می‌شود؟
رویکرد مبتنی بر اندازه‌گیری(Measurement-based) اندازه‌گیریهای مستقیمی روی سیستم درحال اجرا یا یک نمونه انجام می‌گیرد؛ این اندازه‌گیریها، برای شناسایی گلوگاه‌ها بکار می‌روند. رویکرد مبتنی بر مدل (Model-Based) یک مدل کارایی از سیستم نرم‌افزاری ساخته می‌شود؛ از این مدل برای تقلید رفتار سیستم و پیش‌بینی کارایی آن استفاده می‌گردد.
انگیزه‌ها و اصول عمومی ارزیابی کارایی مبتنی بر مدل مزایا: نیازی به یک سیستم در حال اجرا ندارد. از مراحل نخست طراحی قابل اعمال می‌باشد. معایب: دقت پیش‌بینی کارایی به دقت مدل نرم‌افزار بستگی دارد (به هرحال، دقت 100% لازم / منطقی نیست). گزارش دادن بازخورد، به خاطر ساختار متفاوت مدل کارایی نسبت به مدل نرم‌افزار، ممکن است دشوار باشد.
انگیزه‌ها و اصول عمومی تعریف نیازمندیها پیاده‌سازی و تست واحدها طراحی سیستم و نرم‌افزار بهره‌برداری و نگه‌داری تجمیع و تست سیستم ارزیابی کارایی مبتنی بر مدل ارزیابی کارایی مبتنی بر اندازه‌گیری کارایی در کدام مرحله از فرایند تولید نرم‌افزار می‌تواند ارزیابی گردد؟
انگیزه‌ها و اصول عمومی مدلسازی عمومی کارایی نرم‌افزار انگیزه‌ها و اصول عمومی مهندسی کارایی نرم افزار(SPE)[Smith90]: ترکیب و تجمیع ارزیابی کارایی از مراحل نخست تا کل چرخه حیات فرایند تولید نرم افزار در عمل SPE کمتر به کار گرفته می شود: فاصله شناختی بین قلمرو تولید نرم افزار و قلمرو ارزیابی کارایی فشار ”عرضه سریع به بازار“ وقتی برای SPE باقی نمی گذارد رویکردهای ارزیابی کارایی زیادی پیشنهاد شده اند: تحلیلی شبیه سازی از مدلهای نرم افزاری مختلف استفاده می کنند: ، جبر فرایندها(PA)، پتری نت ها(PN)، چارتهای توالی پیام(MSC)، UMLو ..... مدلهای کارایی مختلف مد نظر قرار گرفته اند: شبکه های صف و گسترشهایی از آنها مثل LQN و EQN، SPN، SPA و ....
پیش زمینه پیش زمینه مدلهای نرم افزار استفاده از مدلهای نرم افزار و نمادسازی های غیر استاندارد و مختص کاربرد خاص عدم پذیرش وسیع در جامعه مهندسی

  متن بالا فقط قسمتی از اسلاید پاورپوینت میباشد،شما بعد از پرداخت آنلاین ، فایل کامل را فورا دانلود نمایید 

---

  لطفا به نکات زیر در هنگام خرید دانلود پاورپوینت:  توجه فرمایید.

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

---

 « پرداخت آنلاین و دانلود در قسمت پایین »

تحقیق درباره آشنایی با UML

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

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 29

آشنایی با UML

زبان مدل سازی یکپارچه (UML) زبانی است برای مشخص سازی ، مجسم سازی ، ساخت و مستند سازی دست آوردهای سیستم های نرم افزاری و مدل سازی و کار و دیگر سیستمهای غیر نرم افزاری .

Uml مجموعه ای از بهترین تجربیات مهندسی که موفقیتشان در مدل سازی سیستمهای بزرگ و پیچیده به اثبات رسیده است را عرضه می دارد.

تعریف UML شامل اسناد زیر می گردد :

معنا شناسی UML : که مفاهیم غنی و دستور نگارش وعلا ئم زبان مدلسازی یکپارچه را تعریف می کند UMLبه وسیله بسته ها به صورت معماری گونه لا یه بندی و سازماندهی میشود . در هر بسته عناصر مدل بر حست دستور نگارش (با استفاده از متن و عبارت زبان محدودیت شیء معروف به OCL )و معانی (با استفاده از متن دقیق) تعریف می شوند .

راهنمای علائم UML : فکر و اندیشه را تعریف می کند و مثال های خوبی را ارائه می کند. علائم UML نحو گرافیکی را برای بیان معانی توصیف شده توسط فرا مدل های UML ارائه می کند.

توسعه ی UML برای فرایند شیءدر مهندسی نرم افزارو توسعه UML برای مدل سازی تچارت : این توسعه های UML شامل توسعه خاص فرایند و توسعه خاص حوزه مسئله در UML برحسب مکانیزم های توسعه ای شان و آیکون نمودار فرایند می گردد .

2) فراهم آوردن مکانیزم های توسعه و تخصیص برای بسط مفاهیم اساسی : بدین معنا که در عین آنکه انتظار میرود UML براساس نیازهای جدید در حوزه های خاص جفت و جور شود نمی خواهد اجبار کند تا مفاهیم اساسی و مشترک برای هر حوزه جدیدی دوباره تعریف شود و پیاده سازی گردد. البته مفاهیم اساسی نباید بیش از حد تغییر یابند. بنابراین کاربران نیازمندند که قادر باشند : 1- مدل ها را با استفاده از مفاهیم اساسی بسازند بدون آنکه مکانیزم های توسعه را برای بسیاری از برنامه های کاربردی نرمال بکار گیرند .

2- مفاهیم و علائم جدید را اضافه کنند البته برای مواردی که توسط اصول پوشیده نشده باشند .

3- زمانی که هیچ اتفاق نظر روشنی وجود ندارد تفاسیر مختلف را از مفاهیم موجود انتخاب کنند .

4- مفاهیم، علائم و محدودیت ها را برای حوزه های کاربردی خاص مشخص سازند .

3) استقلال از زبان های برنامه نویسی خاص و فرایندها ی توسعه .

4) فراهم آوردن پایه و اصولی رسمی برای درک زبان مدل سازی که برای این منظور UML تعریف رسمی از قالب استاتیک مدل را با استفاده از نمودار کلاس ارائه می کند این نمودار ، نموداری مشهور و مورد قبول در سطح وسیع برای تعییین قالب یک مدل است UML همچنین محدودیت هایی را بیا ن میدارد که در قالب زبان دقیق طبیعی و عبارات زبان محدودیت شیء (OCL ) بیان می شود .

5) تشویق به رشد بازار ابزارهای OO .

6) حمایت و پشتیبانی از مفاهیم توسعه سطح بالاتر نظیر : همکاری ها ، چهارچوب ها ،الگوها و اجزاء .

7) مجتمع سازی بهترین تجربیات : UML بدنبال آن است که بهترین تجربیات درصنعت

حوزه های مسئله ، معماری ها و … را یکجا بیاورد .

محدوده UML

زبان مدل سازی یکپارچه UML زبانی است برای مشخص سازی ساخت ،مجسم سازی و مستند سازی دست آوردهای یک سیستم متمرکز نرم افزاری اول آنکه این زبان از مفاهیم OOSE,OMT,BOOCH که متدولوژیهای متداول OOمیباشند متنج شده است . دوم ، UMLبر آنچه که در حال حاضر توسط روش های موجور فابل انجام همتند ، بان شده است . سوم زبا ن مدل سازی یکپارچه بر یک زبان مدل سازی استانارد تمرکز می کند و نه یک فرآیند استاندادر اگر چه UMLبایستی در زمینه یک فرایند به کارگیری شود تجرته نشان میدهد که در سازمان های مختلف و با حوزه های مسئله متفاوت فرایندهای متفاوتی مورد نیاز است بنابراین تلاش بر این است که ابتدا بر یک فرامدل مشترک (که معانی را یکپارچه میکند )تمرکز شود و در درجه دوم بر یک علامت گذاری مشترک (که برای فرد استنباط این معانی را فراهم میکند )تمرکز گردد مبدعین UMLبر فرایند توسعای تاکید میکنند که مورد کاربرد گرا معماری گرال و تکراری و افزایشی است .

UML یک زبان مدلسازی را مشخص می کند که اتفاق نظر جماعت شیگرا بر مفاهیم اساس مدل سازی است .

UMLبرای ایجار مدلها و نمرارهای حوزه مسئله هیچ توصیه ای نمیشود و این تجربیات و یادگیری افراد است که تشخیص استفاده از کدام نمودارها و مدل ها را به ایشان می دهد دریک دیدگاه مدل سازی UML نمودارهای گرافیکی زیر را تعریف می کند مورد کاربرد

نمودار مورد کاربرد diagram ) (use ca

نمودار کلاس (ClassDiagram)

نمودارهای رفتار: (BehaviorDiagra

نمودارهای حالت : (State Chart Diagram)

نمودار فعالیت : )Activity Diagram(

نمودارهای تعامل Interaction Diagrams ))

نمودار توالی ((Sequence Diagram

نمودار همکاری ((Collaboration Diagram

* نمودارهای پیاده سازی) (Implementation Diagram

نمودار اجزاء (Component Diagram )

نموداراستقرار (Deployment Diagram)

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

یک سوال که مکررا پرسیده می شود این است که چرا UML از نمودارهای جریان داده معروف به حمایت نمی

تحقیق درمورد نمودارهای UML

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

لینک دانلود و خرید پایین توضیحات

فرمت فایل word  و قابل ویرایش و پرینت

تعداد صفحات: 80

نمودارهای UML

UML به افراد اجازه می دهد تا چندین نوع مختلف از نمودارهای بصری را به وجود آورند که جنبه های مختلف سیستم را نمایش می دهد . Rational Rose از ایجاد اکثر این مدلها ، همانطور که در زیر آمده ، پشتیبانی می کند .

- نمودار Use Case

- نمودارهای Sequence(توالی)

- نمودار Collabration(همکاری)

- نمودار Class (کلاس)

- نمودار State Transition (حالت)

- نمودار Deployment

این نمودارهای مدل ، جنبه های مختلف سیستم را نشان می دهند . مثلاً نمودار Collaboration (همکاری محاورات ضروری میان آبجکت ها را نشان می دهد ، به این منظور که تعدادی از توابع سیستم را به انجام برساند . هر نمودار یک هدف و یک شنوندة در نظر گرفته شده دارد .

نمودارهای Use Case :

نمودارهای Use Case محاورات میان Use Case ها را نشان می‌دهند ، که عملیات سیستمی و عامل ها (Actor) که نشان دهندة افراد یا سیستم هایی که اطلاعات را برای سیستم فراهم کرده و یا از آن دریافت می کنند را نمایش می دهند . مثلاً نمودار Use Case سیستم Automated Teller Machine در شکل نشان داده شده است .

نمودار Use Case محاورات میان Use Case ها و عامل ها را نشان می دهند ، Use Case‌ها درخواستهای سیستم را از دید کاربرد نشان می دهند ، بنابراین Use Case ها عملیاتی هستند که سیستم فراهم می کند . عامل در واقع نگهدارنده پول (بانکدار) یک سیستم هستند . این نمودارها نشان می دهند که چه عامل هایی به Use Case ها مقدار اولیه می دهند . همچنین آنها نشان می دهند که چه موقع یک عامل ، اطلاعات را از یک Use Case دریافت می کند .

نمودار Use Case محاورات میان Use Case ها و عامل های یک سیستم Automate Teller (ATM)Machine را نشان می دهد . بر این اساس ، نمودار Use Case می‌تواند درخواستهای سیستم را نشان دهد . در این مثال مشتری بانک تعدادی از Use Case ها را مقداردهی می کند : برداشت پول (withdraw Money) ، واریز (Deposit Fands) ، انتقال از حساب (Transfer Fands) ، پرداخت (Make Payment) ، مشاهده تراز (موجودی) (View Balance) و تغییر PIN (Change PIN) .

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

ایجاد نمودارهای Use Case

در Rose ، نمودارهای Use Case در نمای Use Case ساخته می شوند . Rose یک نمودار Use Case پیش فرض به نام Main را برای شما می سازد . می توانید هر تعداد نمودارهای اضافی که برای مدل دهی به سیستم خود نیاز دارید را بسازید .

برای دستیابی به نمودار Main Use Case ، مراحل زیر را انجام دهید :

تحقیق درباره آموزی uml

اختصاصی از کوشا فایل تحقیق درباره آموزی uml دانلود با لینک مستقیم و پر سرعت .

لینک دانلود و خرید پایین توضیحات

فرمت فایل 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‌ به طور کاربردی کار کرد.