UML

صفحه 1:
Use case UML درس :مهندسی نرم افزار ۱ استاد : خانم مهندس معادی کرد آوری و اراثه: نگار رضانی اردیبهشت ‎٩۲‏ 

صفحه 2:
#كت وكا أثر بخش الیستر کاکبرن:«مورد استفاده .قرار دادی است ... (که ] رفتار سیستم را تحت شرایط گوناگون در پاسخ گویی به درخواستی از سوی یکی از طرف های ذی نفع توصیف می کند ..» اه ود تنس رم كو سيا وحن اوم جوتي -عا مات از می تواند شامل: خلاصه ای از وظایف و تعامل ها توصیفی مبتنی بر قالب تمایش نضودار خونه باشد . 

صفحه 3:
تعریف مجموعه ای از كنش كران است . یعنی همان بازیگران : صحه کنش گر: هرچیزی است که با سیستم یا محصول ارتباط بوقرار می كت و ازج از خود سیستم قرار دارد. 

صفحه 4:
ا * کنش گر و کاربر نهایی یکی نیستند . * یک کاربر معمولی می تواند چند نقش را برعهده بگیرد و ‎Cal BSNS Gul‏ که یک کنش گر تنهازیک نقش ,را در حیطه ۲22 ۱۳۶ می تواند بر عهده بگیرد . 

صفحه 5:
۴ استخراج خواسته ها یک فعالیت تکاملی است . ۳ همه کنش گر ها در اولین دور تکرار شناسایی نمی شوند . * شناسایی کنش گر های نوع اول طی نخستین دور تکرار امکان پذیر است . * و کنش گر های نوع دوم با کسب اطلاعات عر درباره ی سیستم می توان شناسایی کرد. * کنش گرهای نوع اول : با هم در تعامل هستند آنها به طور مستقیم و غالبا با نرم افزار کار می کنند . * کنش كر هاى نوع دوم :سيستم را پشتیبانی می کنند به طوری که کنش گر های نوع اول بتوانند کار خود را انجام دهند . 

صفحه 6:
می توان 7ت دو را توسعه داد با چند سوال می توان شروع کرد کنش گر نوع اول و نوع دوم چه کسانی هستند ؟ * اهداف کنش گر چیست ؟ قبل از شروع داستان چه پیش شرط هایی باید وجود داشته باشد ؟ * چه وظایف اصلی توسط کنش گر اجرا می شود؟ *_چه استثناهایی را باید با توصیف داستان در نظر داشت ؟ * جه تغييراتى در تعامل کنش گران امکان پذیر است ؟ * کنش كر جه اطلاعاتى را به دست مى آورد .توليد مى كند يا تغيير مى دهد ؟ * آيا كنش كر بايد سيستم را از تغييرات به عمل اورده در محيط خارجى آكاه سازد؟ كنش گر چه اطلاعاتی را از سیتم می خواهد ؟ *_آیا کنش گر می خواهد درباره تغییرات غیر منتظره مطلع شود ؟ 

صفحه 7:
جهار کنش گر ؛ عم << صاحب خانه (کاربر) مدیر راه اتذاز (احتمالا همان صاحب خانه ,ولی با نقش متفاوت ) حس گرها (دستگاه های متصل به سیستم ) زبر سیستم پایش و پاسخ (ایستگاه مرگزی که عملکرد ایمنی منزل در محصول را پایش می کند .) 

صفحه 8:
شکل ۵-۱ باتل کنترل 5۵/60۳6 كنش كر اول : صاحب خانه 

صفحه 9:
ابزار هاى ‎roe)‏ افزارى توسعه ‎SE DUS‏ ™ هدف : کمک به توسعه 52 5 با فراهم ساختن قالب های خودکار و سازو کارهایی جهت ارزیابی وضوح و سازگاری ABE aL. * به شکل فرم های پر کردن جای خالی فراهم می آورند که نتیجه آن ها ‎hoy Shuse vase oly!‏ است . 

صفحه 10:
اکثر ابزار های مدل سازی تحلیل مبتنی بر .۲11[]آهر دو نوع پشتیبانی متنی و گرافیکی را برای توسعه و مدل سازی 6356 1156 فراهم می سازد . 

صفحه 11:
نماد كذارى ‎OOL‏ " عملكرد در يك مستطيل قرار مى كيرد كه درداخل آن نيز بيضى هايى قرار مى كيرد . بیضی ها هر کدام نشان دهنده یکی ازجم حص هستند .که آنها را به صورت متنی در داخل بیضی ها می نویسیم . * آدمک ها کنش گر ها را نشان می دهند . * برای کنش گرهای غیر انسانی از چهار گوش های نشان دار استفاده می برای مثال در پروژه :سا << حسگرها هستند. 

صفحه 12:


صفحه 13:
هدف از مدل تحلیل: فراهم ساختن توصیفی از دامنه اطلاعاتی .عملیاتی و رفتاری مورد نیاز برای سیستم کامپیوتری است مدل تحلیل :در هر زمان به مثابه عکس فوری از خواسته هاست . يعد بايد انتظار تغييرات را داشته باشيد يعنى در همان حال كه مدل خواسته ها به تكامل مى رسد عناصر معينى به يايدارى نسبى مى رسند ولى ساير عناصر مدل ممكن است فرار باشند و اين نشان مى دهد كه طرف هاى ذى نفع هنوز به طور كامل خواسته هاى سسيتم را درك نكرده اند 

صفحه 14:
1 * بعضی از دست اندر کاران نرم افزار استدلال می کنند که بهترین کار انتفاب wwe reer Jibs Gly Cun! ‏يك هالت نمايشى‎ * سایر بر این باورند که استفاده از چند حالت نمایشی متفاوت یرای به تصویر کشیدن مدل خواسته ها ارزشمند است . اين کار سبب می شود که مدل خواسته ها را از دیدگاه های متفاوت در نظر بگیرید در این رویکرد امتمال آشکار شدن مجارد جا افتاده . ناسازگاری ها و ابهامات بیشتر می شود . * در هر هال مجموعه ای از عناصر کلی در اکثر مدل ها مشتری هستند . 

صفحه 15:
‎wer owe‏ بايه و نمودار عدت عت مرتبط با آنيه مص «صلى مبتنی‌بر 3و و با مزییاتب یشتر تکاملی ید می‌کند. ‏عناصر مبتنی بر ستاریو در مدل خواسته ها غالبا نفستین بخش از مدلی هستند که توسعه می یایند . ‏این عناصر به عنوان ورودی برای ایجاد سایر عناصر مدل سازی عمل هی 

صفحه 16:
۱:۱۱ WAV COE E MeN re BRON URE) UNE) 1156 ©6356 ‏استفاده از‎ 

صفحه 17:
* هر سناریو کاربرد ء نشان گر مجموعه ای از اشیاست که با تعامل یک کنش گر با سیستم دستکاری می شود . * اشیاء در قالب چند کلاس طبقه بندی می شوند : مجموعه ای از چیزهایی که صفات و رفتار مشابه دارند . برای مثال کلاس هسکر ها 

صفحه 18:
* «فتار یک سیستم می تواند اثری عمیق ‎CHAT yy‏ طراحی و رویکرد مورد استفاده در پیاده سازی داشته باشد. * بنابراین مدل خواسته ها باید عناصر مدل سازی لازم برای تصویر کردن این رفتار را فراهم سازد . 

صفحه 19:
نمودار حالت یکی از روش های نمایش رفتار سیستم با به تصویر کشیدن حالات و رویداد هایی است که باعث می شوند سیستم تغییر حالت دهد . هالت: هر شیوه ی رختاری سیستم گفته می شود که از بیرون قابل مشاهده باشد . * نمودار مالت نشان گر کنش هایی (مثلا خفعال سازی فرایند /است که به عنوان پیامدی از یک رویداد خاص انجام می شوند . 

صفحه 20:
یک ۱ = = 5 3 3 

صفحه 21:
علاوه بر نمایش های رفتاری سیستم به عنوان یک کل رفتار تک تک کلاس ها را نیز می توان مدل سازی کرد . 

صفحه 22:
0 جيسك ؟ یک موضوع مهم در مدلسازی بصری اپن است که از چه نماد گرافیکی برای نشان دادن چهره های مختلف یک سیستم استفاده شود. ؟ لازم است که اين نماد برای همه بخشهای وابسته و درگیر با سیستم مفهوم باشد در غير اين صورت مدل خیلی مفید نخواهد بود. ؟ بسیاری از افراد نمادهایی را برای مدل سازی بصری پیشنهاد نموده اند. * بعضی از این نمادها که محبوب هستند و پشتیبانی قوی دارند عبار تند از : ‎®vvrk *‏ ‎OOP ( Object Dodekry Techooby) "‏ ‎OOD ( OoPed Ordetoy Loapuce) *‏ برنامه ؟) ات( از این سه نماد پشتیبانی می کند. ° 

صفحه 23:
‎rio‏ 00001 به خاطر مخترعش !۵۷) با۳() دانشمند ارشد شرکت نرم افزاري لس نامگذاري شده است. ‏متد 00 توسط دکتر ‎a2 hawes Ruwbanhk‏ وجود آمده است. ‎OOTP‏ ‏به نسبت 0۷ از گرافيك بيشتري برخوردار است تا سیستم ها را واضح تر نشان دهد. ‎rey ‏حاصل تلاش دست جمعي حول سوه‎ OOD ales ‎9 Rawbanhe var keoberw ‏مه(‎ (۲ Brock: Porter Yourdoa ‏افراد زياد ديكري مي باشد.‎ ‏عموما به بيعامه؟) ,2 و سول سه تفنگدار اطلاق مي شود که هر سه در شرکت نرم افزاري ابت؟) کار مي کنند. 

صفحه 24:
اين سه بر روی استاندارد سازی و اصلاح ,ا060) متمرکز شده اند. سمبل های :0601) تقریبا با نمادهای س) و 002/۳ متناسب است و همچنین شامل عناصری از نمادهای دیگر نیز می باشد. ادغام مدلها به منظور ایجاد 000 در سال ۱۹۹۳ آغاز گردید. هریک از این سه تفنگدار شروع به آمیختن ایده های متدولوژی های دیگر با هم نمودند. پکپارچه سازی رسمی متدولوژی ها تا سال ۱۹۹۵ ادامه داشت. در این سال نسخه ۰۸ 0244 ۳421( معرفی شد. این نسخه . اصلاح شده و در سال ۱۹۹۶ به جسمججا معاط() ل۳() تغییر یافت. 

صفحه 25:
؟ نسخه 0.0 ‎DOL‏ تایید شد و در سال ۱۹۹۷ به گروه تکنولوژی آبجکت ( روا( ‎ws oold (Obert Crow‏ * شرکتهای تولید کننده نرم افزار شروع به سازگار شدن با آن نمودند. * سرانجام در نوامبر ۱۹۹۷ ‎ODG‏ 4.5 4.0 060 را به عنوان یک استاندارد صنعتی معرفی نمود. 

صفحه 26:
نمودارهای ,ا(00) ‎٩‏ ,20 به لفراد!جازه می‌دهد تا چنسیرنوع مختلفاز نمودارهایب صریرا به وجود آویند که جنبه هایم ختلفسیستم را نمليشموههد نرملفزار 4055 أددحقه؟)) از لیجاد اک ثر لیر دلها پ‌شتیبلنی‌میک ند لیرنسمودارها بسه قرار زیر هستند: ‎Ose Ouse Dtagrenms) ‏نمودارهای درخواست سیستم پا موردهای استفاده‎ * (Chase Diagrams) oS (sa logos * ‏* نمودارهای توالی (عصمسچم0) مسهجءق1 ‎(Colborction Discos) 15 {Kae ‏تمودذارهاى‎ * ‏* نمودارهاى انتقال حالت ( به ‎(Grote Troustion‏ ‏* نمودارهای فعالیت (مدل سازی پردازشی) ( مم00 هو ‏۴ نمودار اجزاء (سمجم2) مسورسه06) ‎Qepbywedt Dig ( ‏نمودار استقرار‎ * 

صفحه 27:
* نمودارهای ‎MOL‏ ‏© نمودارهای درخواست سیستم (0166060 0666 ‎OGCE‏ "نمودارهای درخواست سیستم برای تحلیل نیازمندی های وظیفه ای سیستم تهیه می شود. نمودارهای درخواست سیستم در فاز تحلي سیستم تهیه می شود و لین دید رابه توسعه دهندگان سیستم می دهد که سیستم جدید چیست و چه کارهایی انجام می دهد؟ با لین نموداریک ارتباط متقلبل‌با کاربر برقرارمی شود که.پس از بعث و بررسی و حصول توافق نیازمندی های وظیفه ای سیستم نهاییی می شود. 

صفحه 28:
نمودارهای عع2) <2() محاورات میان ععو) ۶( ها را نشان می دهند و عملیات سیستمی و BES ‏را بیان می‎ (Botore ) ls fale ‏ن‌شان‌مهندصلفراد یا سیستم‌هلیی‌هستند که لطاها تا بسرلی‌سیستم فولهم کرشد.‎ be Brice ‏و یااز آندیافتمیک‌نند.‎ * نمودارهای جحه2) <«() محاورات بین عص) <و()ها و ج6ه()ها را نشان می دهند. عح2) <<( ها درخولستهای‌سیستم را از دید کایبر نسشان‌می‌دهند بستابولیرجه) «و() ها عملیاتسطح بل الی‌هستند که سیستم ف راهم‌می‌کسند در ولقع جح ‎SLL SW Oar‏ لقدلماتیه هم مرتبطلسنکه تسوسط یسک0۳6) در سیستم‌رلملندازی‌می‌شود تابسه یک هدفه شخصیس رسد یا بسه عبارتدیگر هر جج0 جو() ی _کوله مشخصاستفاده از سیستم ملست 

صفحه 29:
* توجه داشته باشید که کاربر (جص) با آکتور (0) متفاوت است: کازیز کسي است که از سچستم ايستفاده :من كتد ولت هه ببانگر نقشی است كه بك كارب ايقا مني کنده نام ‎gl Oo‏ بیانگر نقش آن باشد. * ۲) يك‌نوع يا مجموعه لیاز کاربران‌خواهد بود. در واقع يك ‎alge ts lS‏ جاض از جمن خواهد بود کم آری‌قشرا بانی ‎gambiae Saco‏ دلشته باشید کم ل کارت مم‌ولنه چینین نقش‌ب ازي‌کند. به عنوان مثال : علي در سیستم هم مربي است و هم استاد وراه 1الذا 40 يكا دونه ]از © هربي و همين طوز يك نموتة از و استاد راهنما است. براي اينكه 62 ها خارج از سیستم هستند نيازي به تشریح تقضيلي آنها نیست ولي مزیت تعریف آنها این است که ‎Ope‏ ‎Our‏ ها مشخص مي شوند. م 

صفحه 30:
* نمودارهاي 00 * نمودارهاي درخواست سیستم (01۵66606 0666 ۵86) * مثال: نمودار 00666 066 سیستم 00 بانك Co z ‏تسر مشاهده تراز موجودی‎ 6> |] ‏یت‎ : sy pone ‏واريز يول ب ب‎ 8 7 برداشت پول de Sit 90 

صفحه 31:
" ادامه مثال: نمودار 2)90808) 968)) سیستم 9/0) بانک ‎٩‏ مورد استفاده(صح0 «<(6 برداشت پول * پیام احوالپرسی در ۳00) ظاهر می شود. مشتری کارت خود را در ماشین قرار می دهد. * 07۳0 از مشتری(۳10) را می‌پسرسدد * مشتری 6۳10 را وارد می کند. * 09000 حسلبهاومشترورا نسشازمىدهد تا منتخابكند مشترى حسابى را انتخاب مى كند. ماشين حدود حساب را نشان مى دهد. مشتری مقدار برداشت را مشخص می کند. * صورتحساب تنظیم می شود. * کارت خارج شده و رسید نیز صادر می شود. 50 

صفحه 32:
‎DOL jglajlogai "‏ ۶ نمودارهای درخواست سیستم (016066608 0686 066 ‏* مثال: سیستم ثبت نام در دانشگاه ‏واحد مالی ‎ ‎ ‎ ‎ ‎ ‎ 

صفحه 33:
۴ نمودارهاي ‎OQOL‏ ‏© نمودارهاي درخواست سیستم (عه0 --2) ‎(Dtragraws‏ ‏" ارتباط , هل © اگر در حصن 022 توالي از فعاليت ها وجود دارند كه در حالت هاي خاص و بطور اضافه انجام مي شوند و 02 ديگري در آن نقنق دارند با عملگر له آن و 0 تجزیه مي شود. 

صفحه 34:
۴ نمودارهاي ‎OXON‏ ‏© نمودارهاي درخواست سیستم (عه0 --2) 7 (Drees 6 ‏با یاه‎ Owe Bh!" s s s << include>> , 35 © اگر يك ‎Owe‏ و0 به و0 »و0 هاي دیگر ارجاع دهد (رفرنس دهد) از ارتباط طعام استفاده مي شود. 

صفحه 35:
۴ نمودارهاي ‎OXON‏ ‏© نمودارهاي درخواست سیستم (عه0 --2) ‎(Dtragraws‏ ماه سیستم غاي چاضري ‎(eb)‏ + سفارش غذا شخص خدمت دهتده مقارش و موجودی 

صفحه 36:
* نمودارهای ,00 * نمودارهای کلاس (ع:) عصا)) "ساختار ایستا (ثابت) مدل موجودیت گرا را نشان می دهد. یعنی بیانگر کلاس های موجودیت. ساختار داخلی آنها و ارتباطی که آنها با هم مشارکت دارند است. "در ب060) کلاس موجودیت با یک مستطیل که دارای سه قسمت است نشان داده می شود. در قسمت اول نام کلاس موجودیت. در قسمت دوم مشخصه ها (حالت) کلاس موجودیت و در قسمت سوم عملگر (عملیات) کلاس موجودیت که توسط آنها عمل و عکس العمل نشان می دهد بیان مى شود. 

صفحه 37:
OOL ‏نمودارهاي‎ * * نمودارهاي کلاس (0۵1۵۵6006 ۵هره) * نمودار 0۷۵۵6 مثال ۵۳۵ در زیر نشان داده شده است: ‘AIM Screen’ Prompt) L_Accept Input) ١ Cash Balance Provide Cash) Provide Receipt) ead Card Reader ‘Card Number Accept Card) Eject Card) Read Card() pend) ‘Withdraw Funds Deduct Funds() Verify Funds, 

صفحه 38:
* نمودارهای ,6000 * نمودارهای کلاس (016660606 ههام "در یک نمودار عل) هر کلاس با مستطیلی نشان داده شده که به ۳ بخش تقسیم شده است. ۲بخش اول نام کلاس را نشان می دهد. نام کلاس می بایست دربرگیرنده مفهوم کلیه آبجکت هایی باشد که به آن کلاس نگاشت خواهند شد. ۷بخش دوم صفات(عصفط98)) کلاس را نشان می دهد. یک صفت . قطعه ای از اطلاعات است که با یک کلاس مرتبط می باشد. "مثلا کلاس حساب(ه()) شامل سه صفت است : © شماره حساب(مامی جیوه ‎PD °‏ © تراز موجودی(س) 90 

صفحه 39:
آخرین بخش شامل عملگرهای کلاس(عطل<۳()) می باشد. یک عملگر : تعدادی رفتار است که توسط کلاس آماده خواهد شد. مثلا کلاس حساب شامل چهار عملگر است: Open) gS jb ° © برداشت وجه(طمی<) سعطه0(۷) ‎٩‏ کسر موجودی(ط<) بسدع) © تایید موجودی(ط<) هب6 ‏خطوط بین کلاسها . وابستگی ارتباطات بین کلاسها را نشان می دهد. ‏مه 

صفحه 40:
کارمند ساعتی کارمند قراردادی = ق سالین فرخ ساعتی تماره ترارداد ‎anes‏ ‏نرخ مشاوره )( ‏محاسبه حق الزحمه‎ Ope oe aa : ae 

صفحه 41:
* انتقال اطلاعات با جریان یافتن در یک سیستم کامپیوتری صورت می پذیرد . در عمل می توانیم برای هر سیستم کامپوتری با هر اندازه و هرمیزان پیچیدگی .یک مدل جریان تولید کنیم. 

صفحه 42:
الگوهای تملیل راهکارهایی (مثْلا یک کلاس .یک عملکرد میک رفتار ادر این دامنه کاربزدی پیشنهاد می کنند .که در مدل سازی بسیاری از برنامه های کاربردی قابل استفاده مجدد است . 

صفحه 43:
که با به کار گیری الکو های تملیل می توان آن ها را مرتبط دانست : !)این الکو های تحلیل ,توسعه مدل های انتزاعی را سرعت می بخشند . )الکو های تملیل ,تبدیل مدل تحلیل به یک مدل طرامی را با پیشنهاد الکو های طراهی و راهکار های قابل اطمینان برای مسائل رایج تسهیل می کند . 

صفحه 44:
% ایده ال مهندسی خواسته ها ۷ مشامره با یک یا چند طرف ذی نفع ۷ هدف : مذاکره توسعه یک طرح پروژه است که نیاز های طرف ذی نفع را بر طرف سازد و در همان حال قيد و بند ‎Slo‏ جهان واقعی (مانن زمان ,آدم ها ءبودجه )۱ که تیم نرم افزار با آن مواجه است را منتعکس می کند . 

صفحه 45:
هدف بهترین مذاکره ها نتیجه ای «برد-برد» است . 

صفحه 46:
۱ ١)شناسايى‏ طرف هاى ذى نفع مهم سیستم یا زیر سیستم «)تعيين شرايط برد براى طرف هاى ذى نفع ا)مذاكره بر سر شرايط برد طرف هاى ذى نفع براى رسائدن آنها به شرايط يرد -برد .براى تمامى طرف ها (از جمله تيم نرم افزار. با تكميل موفقيت آميز اين مراحل آغازى نتيجهى برد- برد حاصل خواهد شد که ملاک کلیدی برای پیش رفتن به فعالیت های بعدی در مهندسی نرم افزار است. 

صفحه 47:
اعتبار سنجی خواسته ها "از نظر "ناسا زکاری "ابهام 7"موارد جا افتاده 

فصل پنجم :مهندسی خواسته ها بخش دوم ‏Use case ‏UML درس :مهندسی نرم افزار 1 استاد :خانم مهندس معادی ‏Company گردآوری و ارائه :نگار رضائی ‏LOGO اردیبهشت 92 توسعه use case خش : use caseاثر ب الیستر کاکبرن«:مورد استفاده ،قرار دادی است {...که}رفتار سیستم را تحت شرایط گوناگون در پاسخ گویی به درخواستی از سوی یکی از طرف های ذی نفع توصیف می کند »... بک س یاقدرباره چ گون گیت عاملک اربر ت اس و use caseداس تان یاس ب عین حت جموعه ش رایطم . م هایی ا س یستمت ب ن می تواند شامل: متنی حکایتی خالصه ای از وظایف و تعامل ها توصیفی مبتنی بر قالب نمایش نمودار گونه باشد . گام نخست : تعریف مجموعه ای از کنش گران است . یعنی همان بازیگران actors : کنش گر :هرچیزی است که با سیستم یا محصول ارتباط برقرار می کند و خارج از خود سیستم قرار دارد . نکات کنش گر و کاربر نهایی یکی نیستند . یک کاربر معمولی می تواند چند نقش را برعهده بگیرد و این در صورتی است که یک کنش گر تنها یک نقش را در حیطه use caseمی تواند بر عهده بگیرد .  استخراج خواسته ها یک فعالیت تکاملی است . همه کنش گر ها در اولین دور تکرار شناسایی نمی شوند . شناسایی کنش گر های نوع اول طی نخستین دور تکرار امکان پذیر است . و کنش گر های نوع دوم با کسب اطالعات بیشتر درباره ی سیستم می توان شناسایی کرد. کنش گرهای نوع اول :با هم در تعامل هستند آنها به طور مستقیم و غالبا با نرم افزار کار می کنند . کنش گر های نوع دوم :سیستم را پشتیبانی می کنند به طوری که کنش گر های نوع اول بتوانند کار خود را انجام دهند . بعد از شناسایی کنش گر ها می توان use caseرا توسعه داد با چند سوال می توان شروع کرد : ‏ ‏ ‏ ‏ ‏ ‏ ‏ ‏ ‏ ‏ کنش گر نوع اول و نوع دوم چه کسانی هستند ؟ اهداف کنش گر چیست ؟ قبل از شروع داستان چه پیش شرط هایی باید وجود داشته باشد ؟ چه وظایف اصلی توسط کنش گر اجرا می شود؟ چه استثناهایی را باید با توصیف داستان در نظر داشت ؟ چه تغییراتی در تعامل کنش گران امکان پذیر است ؟ کنش گر چه اطالعاتی را به دست می آورد ،تولید می کند یا تغییر می دهد ؟ آیا کنش گر باید سیستم را از تغییرات به عمل اورده در محیط خارجی آگاه سازد؟ کنش گر چه اطالعاتی را از سیتم می خواهد ؟ آیا کنش گر می خواهد درباره تغییرات غیر منتظره مطلع شود ؟ مثال چهار کنش گر safe home : صاحب خانه (کاربر) مدیر راه انداز (احتماال همان صاحب خانه ،ولی با نقش متفاوت ) حس گرها (دستگاه های متصل به سیستم ) زیر سیستم پایش و پاسخ (ایستگاه مرگزی که عملکرد ایمنی منزل در محصول را پایش می کند ). کنش گر اول :صاحب خانه ابزار های نرم افزاری توسعه use case هدف : کمک به توسعه use caseبا فراهم ساختن قالب های خودکار و سازو کارهایی جهت ارزیابی وضوح و سازگاری سازو کارها : به شکل فرم های پر کردن جای خالی فراهم می آورند که نتیجه آن ها ایجاد use caseاثر بخش است . اکثر ابزار های مدل سازی تحلیل مبتنی بر UMLهر دو نوع پشتیبانی متنی و گرافیکی را برای توسعه و مدل سازی use caseفراهم می سازد . نماد گذاری UML عملکرد در یک مستطیل قرار می گیرد که درداخل آن نیز بیضی هایی قرار می گیرد . بیضی ها هر کدام نشان دهنده یکی از use caseهستند .که آنها را به صورت متنی در داخل بیضی ها می نویسیم . آدمک ها کنش گر ها را نشان می دهند . برای کنش گرهای غیر انسانی از چهار گوش های نشان دار استفاده می کنیم. برای مثال در پروژه safe Home:حسگرها هستند. هدف از مدل تحلیل :فراهم ساختن توصیفی از دامنه اطالعاتی ،عملیاتی و رفتاری مورد نیاز برای سیستم کامپیوتری است مدل تحلیل :در هر زمان به مثابه عکس فوری از خواسته هاست . یعنی : باید انتظار تغییرات را داشته باشید یعنی در همان حال که مدل خواسته ها به تکامل می رسد عناصر معینی به پایداری نسبی می رسند ولی سایر عناصر مدل ممکن است فرار باشند و این نشان می دهد که طرف های ذی نفع هنوز به طور کامل خواسته های سسیتم را درک نکرده اند عناصر مدل خواسته ها : بعضی از دست اندر کاران نرم افزار استدالل می کنند که بهترین کار انتخاب یک حالت نمایشی است برای مثال use case سایر بر این باورند که استفاده از چند حالت نمایشی متفاوت برای به تصویر کشیدن مدل خواسته ها ارزشمند است . این 8کار سبب می شود که مدل خواسته ها را از دیدگاه های متفاوت در نظر بگیرید در این رویکرد احتمال آشکار شدن موارد جا افتاده ،ناسازگاری ها و ابهامات بیشتر می شود . در هر حال مجموعه ای از عناصر کلی در اکثر مدل ها مشترک هستند .  use case پ88ای8ه و ن88مودار use caseم8رت8بط ب888ا آنب888ه use caseا8ی م8بتنیب888ر ا8لگو و ب888ا ج8زی8یاتب888یشتر ت888کام8لپ888یدا م8یک88ند . عناصر مبتنی بر سناریو در مدل خواسته ها غالبا نخستین بخش از مدلی هستند که توسعه می یابند . این عناصر به عنوان ورودی برای ایجاد سایر عناصر مدل سازی عمل می کنند. یک نمودار UMLاز فعالیت ها برای استخراج خواسته ها و نمایش آن ها با استفاده از use case سه سطح ازشناخت مشاهده می شود که در یک نمایش مبتنی به سناریو به اوج خود می رسد . عناصرمبتنی بر کالس : هر سناریو کاربرد ،نشان گر مجموعه ای از اشیاست که با تعامل یک کنش گر با سیستم دستکاری می شود . اشیاء در قالب چند کالس طبقه بندی می شوند : مجموعه ای از چیزهایی که صفات و رفتار مشابه دارند . برای مثال کالس حسگر ها عناصر رفتاری رفتار یک سیستم می تواند اثری عمیق بر انتخاب طراحی و رویکرد مورد استفاده در پیاده سازی داشته باشد. بنابراین مدل خواسته ها باید عناصر مدل سازی الزم برای تصویر کردن این رفتار را فراهم سازد . نمودار حالت نمودار حالت یکی از روش های نمایش رفتار سیستم با به تصویر کشیدن حاالت و رویداد هایی است که باعث می شوند سیستم تغییر حالت دهد . حالت :هر شیوه ی رفتاری سیستم گفته می شود که از بیرون قابل مشاهده باشد . نمودار حالت نشان گر کنش هایی (مثال فعال سازی فرایند )است که به عنوان پیامدی از یک رویداد خاص انجام می شوند . یک نموادارحالت UMLساده شده : عالوه بر نمایش های رفتاری سیستم به عنوان یک کل رفتار تک تک کالس ها را نیز می توان مدل سازی کرد . Iر بدانیم بیشت ‏UML ‏ ‏ ‏ ‏ يست چ ؟ يك موضوع مهم در مدلسازي بصري اين است كه از چه نماد گرافيكي براي نشان دادن چهره هاي مختلف يك سيستم استفاده شود. الزم است كه اين نماد براي همه بخشهاي وابسته و درگير با سيستم مفهوم باشد در غير اين صورت مدل خيلي مفيد نخواهد بود. بسياري از افراد نمادهايي را براي مدل سازي بصري پيشنهاد نموده اند. بعضي از اين نمادها كه محبوب هستند و پشتيباني قوي دارند عبارتند از : ‏Booch  ‏OMT ( Object Modeling Technology)  ‏UML ( Unified Modeling Language)  ‏ برنامه Rational Roseاز اين سه نماد پشتيباني مي كند. 22 Iر بدانیم بیشت ‏ متد BOOCHبه خاطر مخترعش Grady Boochدانشمند ارشد شركت نرم افزاري Rationalنامگذاري شده است. ‏ متد OMTتوسط دكتر James Rambaughبه وجود آمده استOMT . به نسبت Boochاز گرافيك بيشتري برخوردار است تا سيستم ها را واضح تر نشان دهد. ‏ نماد UMLحاصل تالش دست جمعي Grady Booch، James Rambaugh، Ivar Jacobson، Rebecca Wirfs Brock، Peter Yourdonو افراد زياد ديگري مي باشد. ‏ عموما به Booch، Rambaughو Jacobsonسه تفنگدار اطالق مي شود كه هر سه در شركت نرم افزاري Rationalكار مي كنند. 23 Iر بدانیم بیشت ‏ اين سه بر روي استاندارد سازي و اصالح UMLمتمركز شده اند .سمبل هاي UMLتقريبا با نمادهاي Boochو OMTمتناسب است و همچنين شامل عناصري از نمادهاي ديگر نيز مي باشد. ‏ ادغام مدلها به منظور ايجاد UMLدر سال 1993آغاز گرديد. ‏ هريك از اين سه تفنگدار شروع به آميختن ايده هاي متدولوژي هاي ديگر با هم نمودند. ‏ يكپارچه سازي رسمي متدولوژي ها تا سال 1995ادامه داشت .در اين سال نسخه 0.8 Unified Methodمعرفي شد. ‏ اين نسخه ،اصالح شده و در سال 1996به Unified Modeling Languageتغيير يافت. 24 Iر بدانیم بیشت ‏ نسخه UML 1.0تاييد شد و در سال 1997به گروه تكنولوژي آبجكت ( ) Object Group Technologyداده شد. ‏ شركتهاي توليد كننده نرم افزار شروع به سازگار شدن با آن نمودند. ‏ سرانجام در نوامبر OMG 1997نسخه UML 1.1را به عنوان يك استاندارد صنعتي معرفي نمود. 25 Iر بدانیم بیشت نمودارهاي UML ‏ مودارهاي صريرا ب ندين وع م ختلفاز ن ن UMLب ه افراد اجازه م يد هد ت ا چ به وجود آورند كه ج نبه هايم ختلفس يستمرا ن مايشم يد هد .ن رم افزار اين مودارها ب ه Rational Roseاز ايجاد اكثر اينم دل ها پ شتيبان يم يكند .ن ق رار زير هستند : ‏ ‏ ‏ ‏ ‏ ‏ ‏ ‏ 26 نمودارهاي درخواست سيستم يا موردهاي استفاده ()Use Case Diagrams نمودارهاي كالس ()Class Diagrams نمودارهاي توالي ()Sequence Diagrams نمودارهاي همكاري ()Collaboration Diagrams نمودارهاي انتقال حالت ( )State Transition Diagrams نمودارهاي فعاليت (مدل سازي پردازشي) ( )Activity Diagrams نمودار اجزاء ()Component Diagram نمودار استقرار ( )Deployment Diagram Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي درخواست سيستم ()USE CASE DIAGRAMS ‏نمودارهاي درخواس ت س يستم براي تحليل نيازمندي هاي وظيف ه اي س يستم تهيه م ي شود .نمودارهاي درخواس ت س يستم در فاز تحليل سيستم تهيه مي شود و اين ديد را به توسعه دهندگان سيستم مي دهد كه سيستم جديد چيست و چه كارهايي انجام مي دهد؟ ‏با اين نمودار يك ارتباط متقابل با كاربر برقرار مي شود كه پس از بحث و بررس ي و حص ول تواف ق نيازمندي هاي وظيف ه اي س يستم نهايي م ي شود. 27 Iر بدانیم بیشت نمودارهاي Use Caseمحاورات ميان Use Caseها را نشان مي دهند و عمليات سيستمي و عامل ها ( ) Actorsرا بيان مي كنند. Actor ها ن شاند هنده افراد يا س يستمهاييهستند كه اطالعاترا ب رايس يستمف راهمكرد ه دريافت يكنند. م و يا از آن نمودارهاي Use Caseمحاورات بين Use Caseها و Actorها را نشان مي دهند. Use Case ها درخواس تهايس يستمرا از د يد كاربر ن شانم يد هند ب نابراين Use Caseها ع ملياتس طح ب ا الييهستند كه س يستمف راهمم يكند .در واقع Use Caseها ت وا لياز امات ه همم رتبطاس تكه ت وس طيك Actorدر س يستمراه اندازيم يش ود ت ا ب ه يك اقد ب شخصي رسد يا ب ه ع بارتد يگر هر Use Caseيكراه م شخصاس تفاد ه از س يستم ب هدفم اس .ت Iر بدانیم بیشت ‏ ‏ ‏ ‏ توجه داشته باشيد كه كاربر ( )userبا آكتور ( )Actorمتفاوت است .كاربر كسي است كه از سيستم استفاده مي كند ولي Actorبيانگر نقشي است كه يك كاربر ايفا مي كند .نام Actorبايد بيانگر نقش آن باشد. ActorيBكنBBوع يBBا مBجموعه BاBياز كBارBبراBنخواBهد بBBود .در واBقBع يBBك كBارBبر يBBكنBBمونBه Bخاصاز Actor BخواBهد بBBود كBه BآBننBBقشرا بBBازBي مBيكBBند .تBBوBجه BداBشBته BباشBيد كBه BيBBككBارBبر مBيتBBواBند چنديBن نBBقشبBBازBيكBBند. به عنوان مثال :علي در سيستم هم مربي است و هم استاد راهنما لذا علي يك نمونه از Actorمربي و همين طور يك نمونه از Actorاستاد راهنما است. براي اينكه Actorها خارج از سيستم هستند نيازي به تشريح تفضيلي آنها نيست ولي مزيت تعريف آنها اين است كه Use Caseها مشخص مي شوند. 29 Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي درخواست سيستم ()USE CASE DIAGRAMS مثال :نمودار USE CASEسيستم ATMبانك 30 Iر بدانیم بیشت ادامه مثال :نمودار USE CASEسيستم ATMبانك ‏ 31 مورد استفاده( :)Use Caseبرداشت پول پيام احوالپرسي در ATMظاهر مي شود. مشتري كارت خود را در ماشين قرار مي دهد. ATM از م شتري PINرا م يپ رسد. مشتري PINرا وارد مي كند. ATM ح ساب هايم شتريرا ن شانم يد هد ت ا ان تخابكند. مشتري حسابي را انتخاب مي كند. ماشين حدود حساب را نشان مي دهد. مشتري مقدار برداشت را مشخص مي كند. صورتحساب تنظيم مي شود. كارت خارج شده و رسيد نيز صادر مي شود. Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي درخواست سيستم ()USE CASE DIAGRAMS مثال :سيستم ثبت نام در دانشگاه 32 Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي درخواست سيستم (Use Case )Diagrams ارتباط بين Use Caseها ‏ اگر در Use Caseتوالي از فعاليت ها وجود دارند كه در حالت هاي خاص و بطور اضافه انجام مي شوند و Actorديگري در آن 33 نقش دارند با عملگر extendآن Use Caseتجزيه مي شود. Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي درخواست سيستم (Use Case )Diagrams ارتباط بين Use Caseها ‏ 34 اگر يك Use Case Bبه Use Caseهاي ديگر ارجاع دهد (رفرنس دهد) از ارتباط includeاستفاده مي شود. Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي درخواست سيستم (Use Case )Diagrams مثال :سيستم غذاي حاضري (سريع) 35 Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي كالس ()Class Diagrams ‏ساختار ايستا (ثابت) مدل موجوديت گرا را نشان مي دهد .يعني بيانگر كالس هاي موجوديت ،ساختار داخلي آنها و ارتباطي كه آنها با هم مشاركت دارند است. ‏در UMLكالس موجوديت با يك مستطيل كه داراي سه قسمت است نشان داده مي شود .در قسمت اول نام كالس موجوديت ،در قسمت دوم مشخصه ها (حالت) كالس موجوديت و در قسمت سوم عملگر (عمليات) كالس موجوديت كه توسط آنها عمل و عكس العمل نشان مي دهد بيان مي شود. 36 Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي كالس ()CLASS DIAGRAMS نمودار CLASSمثال ATMدر زير نشان داده شده است: 37 Iر بدانیم بیشت نمودارهاي UML ‏ نمودارهاي كالس ()CLASS DIAGRAMS ‏در يك نمودار Classهر كالس با مستطيلي نشان داده شده كه به 3بخش تقسيم شده است. ‏بخش اول نام كالس را نشان مي دهد .نام كالس مي بايست دربرگيرنده مفهوم كليه آبجكت هايي باشد كه به آن كالس نگاشت خواهند شد. ‏بخش دوم صفات( )Attributesكالس را نشان مي دهد .يك صفت ،قطعه اي از اطالعات است كه با يك كالس مرتبط مي باشد. ‏مثال كالس حساب( )Accountشامل سه صفت است : 38 ‏ شماره حساب()Account Number ‏ ‏PIN ‏ تراز موجودي()Balance بیشتر بدانیم آخرين بخش شامل عملگرهاي كالس( )Operationsمي باشد. يك عملگر ،تعدادي رفتار است كه توسط كالس آماده خواهد شد. مثال كالس حساب شامل چهار عملگر است: ‏ باز كردن()Open ‏ برداشت وجه()Withdraw Funds ‏ كسر موجودي()Deduct Funds ‏ تاييد موجودي()Verify Funds خطوط بين كالسها ،وابستگي ارتباطات بين كالسها را نشان مي دهد. 39 مثال عناصر جریان گرا : انتقال اطالعات با جریان یافتن در یک سیستم کامپیوتری صورت می پذیرد . در عمل می توانیم برای هر سیستم کامپوتری با هر اندازه و هرمیزان پیچیدگی ،یک مدل جریان تولید کنیم. الگو های تحلیل : الگوهای تحلیل راهکارهایی (مثال یک کالس ،یک عملکرد ،یک رفتار )در این دامنه کاربردی پیشنهاد می کنند .که در مدل سازی بسیاری از برنامه های کاربردی قابل استفاده مجدد است . دو مزیت که با به کار گیری الگو های تحلیل می توان آن ها را مرتبط دانست : )1این 8الگو های تحلیل ،توسعه مدل های انتزاعی را سرعت می بخشند . )2الگو های تحلیل ،تبدیل مدل تحلیل به یک مدل طراحی را با پیشنهاد الگو های طراحی و راهکار های قابل اطمینان برای مسائل رایج تسهیل می کند . مذاکره بر سر خواسته ها ایده ال مهندسی خواسته ها مشاجره با یک یا چند طرف ذی نفع هدف :مذاکره توسعه یک طرح پروژه است که نیاز های طرف ذی نفع را بر طرف سازد و در همان حال قید و بند های جهان واقعی (مانن زمان ،آدم ها ،بودجه )را که تیم نرم افزار با ان مواجه است را منعکس می کند . هنر مذاکره هدف بهترین مذاکره ها نتیجه ای «برد-برد» است . مجموعه ای از فعالیت های مذاکره : )1شناسایی طرف های ذی نفع مهم سیستم یا زیر سیستم )2تعیین شرایط برد برای طرف های ذی نفع )3مذاکره بر سر شرایط برد طرف های ذی نفع برای رساندن آنها به شرایط برد –برد ،برای تمامی طرف ها (از جمله تیم نرم افزار. با تکمیل موفقیت آمیز این مراحل آغازی نتیجه ی برد -برد حاصل خواهد شد که مالک کلیدی برای پیش رفتن به فعالیت های بعدی در مهندسی نرم افزار است. اعتبار سنجی خواسته ها ‏از نظر ‏ناسازگاری ‏ابهام ‏موارد جا افتاده