UML
اسلاید 1: Use case UML فصل پنجم :مهندسی خواسته ها بخش دوم درس :مهندسی نرم افزار 1استاد : خانم مهندس معادی گردآوری و ارائه : نگار رضائیاردیبهشت 92
اسلاید 2: توسعه use caseuse case اثر بخش :الیستر کاکبرن:«مورد استفاده ،قرار دادی است ...{که}رفتار سیستم را تحت شرایط گوناگون در پاسخ گویی به درخواستی از سوی یکی از طرف های ذی نفع توصیف می کند ...»use case داستانی است با سبک و سیاق درباره چگونگی تعامل کاربر نهایی با سیستم تحت مجموعه شرایط معین .می تواند شامل:متنی حکایتی خلاصه ای از وظایف و تعامل هاتوصیفی مبتنی بر قالب نمایش نمودار گونه باشد .
اسلاید 3: گام نخست : تعریف مجموعه ای از کنش گران است . یعنی همان بازیگران : actorsکنش گر: هرچیزی است که با سیستم یا محصول ارتباط برقرار می کند و خارج از خود سیستم قرار دارد .
اسلاید 4: نکات کنش گر و کاربر نهایی یکی نیستند .یک کاربر معمولی می تواند چند نقش را برعهده بگیرد و این در صورتی است که یک کنش گر تنها یک نقش را در حیطه use case می تواند بر عهده بگیرد .
اسلاید 5: استخراج خواسته ها یک فعالیت تکاملی است .همه کنش گر ها در اولین دور تکرار شناسایی نمی شوند .شناسایی کنش گر های نوع اول طی نخستین دور تکرار امکان پذیر است .و کنش گر های نوع دوم با کسب اطلاعات بیشتر درباره ی سیستم می توان شناسایی کرد. کنش گرهای نوع اول : با هم در تعامل هستند آنها به طور مستقیم و غالبا با نرم افزار کار می کنند .کنش گر های نوع دوم :سیستم را پشتیبانی می کنند به طوری که کنش گر های نوع اول بتوانند کار خود را انجام دهند .
اسلاید 6: بعد از شناسایی کنش گر ها می توان use case را توسعه داد با چند سوال می توان شروع کرد :کنش گر نوع اول و نوع دوم چه کسانی هستند ؟اهداف کنش گر چیست ؟قبل از شروع داستان چه پیش شرط هایی باید وجود داشته باشد ؟چه وظایف اصلی توسط کنش گر اجرا می شود؟چه استثناهایی را باید با توصیف داستان در نظر داشت ؟چه تغییراتی در تعامل کنش گران امکان پذیر است ؟کنش گر چه اطلاعاتی را به دست می آورد ،تولید می کند یا تغییر می دهد ؟آیا کنش گر باید سیستم را از تغییرات به عمل اورده در محیط خارجی آگاه سازد؟کنش گر چه اطلاعاتی را از سیتم می خواهد ؟آیا کنش گر می خواهد درباره تغییرات غیر منتظره مطلع شود ؟
اسلاید 7: مثال چهار کنش گر : safe homeصاحب خانه (کاربر)مدیر راه انداز (احتمالا همان صاحب خانه ،ولی با نقش متفاوت )حس گرها (دستگاه های متصل به سیستم )زیر سیستم پایش و پاسخ (ایستگاه مرگزی که عملکرد ایمنی منزل در محصول را پایش می کند .)
اسلاید 8: کنش گر اول : صاحب خانه
اسلاید 9: ابزار های نرم افزاری توسعه use case هدف : کمک به توسعه use case با فراهم ساختن قالب های خودکار و سازو کارهایی جهت ارزیابی وضوح و سازگاری سازو کارها : به شکل فرم های پر کردن جای خالی فراهم می آورند که نتیجه آن ها ایجاد use case اثر بخش است .
اسلاید 10: اکثر ابزار های مدل سازی تحلیل مبتنی بر UMLهر دو نوع پشتیبانی متنی و گرافیکی را برای توسعه و مدل سازی use case فراهم می سازد .
اسلاید 11: نماد گذاری UMLعملکرد در یک مستطیل قرار می گیرد که درداخل آن نیز بیضی هایی قرار می گیرد .بیضی ها هر کدام نشان دهنده یکی ازuse case هستند .که آنها را به صورت متنی در داخل بیضی ها می نویسیم .آدمک ها کنش گر ها را نشان می دهند .برای کنش گرهای غیر انسانی از چهار گوش های نشان دار استفاده می کنیم. برای مثال در پروژه :safe Home حسگرها هستند.
اسلاید 12:
اسلاید 13: هدف از مدل تحلیل: فراهم ساختن توصیفی از دامنه اطلاعاتی ،عملیاتی و رفتاری مورد نیاز برای سیستم کامپیوتری است مدل تحلیل :در هر زمان به مثابه عکس فوری از خواسته هاست . یعنی :باید انتظار تغییرات را داشته باشید یعنی در همان حال که مدل خواسته ها به تکامل می رسد عناصر معینی به پایداری نسبی می رسند ولی سایر عناصر مدل ممکن است فرار باشند و این نشان می دهد که طرف های ذی نفع هنوز به طور کامل خواسته های سسیتم را درک نکرده اند
اسلاید 14: عناصر مدل خواسته ها : بعضی از دست اندر کاران نرم افزار استدلال می کنند که بهترین کار انتخاب یک حالت نمایشی است برای مثال use caseسایر بر این باورند که استفاده از چند حالت نمایشی متفاوت برای به تصویر کشیدن مدل خواسته ها ارزشمند است .این کار سبب می شود که مدل خواسته ها را از دیدگاه های متفاوت در نظر بگیرید در این رویکرد احتمال آشکار شدن موارد جا افتاده ، ناسازگاری ها و ابهامات بیشتر می شود .در هر حال مجموعه ای از عناصر کلی در اکثر مدل ها مشترک هستند .
اسلاید 15: use case پایه و نمودار use case مرتبط با آن به use caseای مبتنی بر الگو و با جزییات بیشتر تکامل پیدا می کند .عناصر مبتنی بر سناریو در مدل خواسته ها غالبا نخستین بخش از مدلی هستند که توسعه می یابند .این عناصر به عنوان ورودی برای ایجاد سایر عناصر مدل سازی عمل می کنند.
اسلاید 16: سه سطح ازشناخت مشاهده می شود که در یک نمایش مبتنی به سناریو به اوج خود می رسد . یک نمودار UML از فعالیت ها برای استخراج خواسته ها و نمایش آن ها با استفاده از use case
اسلاید 17: عناصرمبتنی بر کلاس : هر سناریو کاربرد ، نشان گر مجموعه ای از اشیاست که با تعامل یک کنش گر با سیستم دستکاری می شود .اشیاء در قالب چند کلاس طبقه بندی می شوند :مجموعه ای از چیزهایی که صفات و رفتار مشابه دارند .برای مثال کلاس حسگر ها
اسلاید 18: عناصر رفتاری رفتار یک سیستم می تواند اثری عمیق بر انتخاب طراحی و رویکرد مورد استفاده در پیاده سازی داشته باشد. بنابراین مدل خواسته ها باید عناصر مدل سازی لازم برای تصویر کردن این رفتار را فراهم سازد .
اسلاید 19: نمودار حالت یکی از روش های نمایش رفتار سیستم با به تصویر کشیدن حالات و رویداد هایی است که باعث می شوند سیستم تغییر حالت دهد .حالت: هر شیوه ی رفتاری سیستم گفته می شود که از بیرون قابل مشاهده باشد .نمودار حالت نشان گر کنش هایی (مثلا فعال سازی فرایند )است که به عنوان پیامدی از یک رویداد خاص انجام می شوند .نمودار حالت
اسلاید 20: یک نموادارحالت UML ساده شده :
اسلاید 21: علاوه بر نمایش های رفتاری سیستم به عنوان یک کل رفتار تک تک کلاس ها را نیز می توان مدل سازی کرد .
اسلاید 22: 22UML چيست؟يك موضوع مهم در مدلسازي بصري اين است كه از چه نماد گرافيكي براي نشان دادن چهره هاي مختلف يك سيستم استفاده شود. لازم است كه اين نماد براي همه بخشهاي وابسته و درگير با سيستم مفهوم باشد در غير اين صورت مدل خيلي مفيد نخواهد بود.بسياري از افراد نمادهايي را براي مدل سازي بصري پيشنهاد نموده اند.بعضي از اين نمادها كه محبوب هستند و پشتيباني قوي دارند عبارتند از :BoochOMT ( Object Modeling Technology)UML ( Unified Modeling Language)برنامه Rational Rose از اين سه نماد پشتيباني مي كند.بیشتر بدانیم
اسلاید 23: 23بیشتر بدانیم متد 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 كار مي كنند.
اسلاید 24: 24بیشتر بدانیم اين سه بر روي استاندارد سازي و اصلاح UML متمركز شده اند. سمبل هاي UML تقريبا با نمادهاي Booch وOMT متناسب است و همچنين شامل عناصري از نمادهاي ديگر نيز مي باشد.ادغام مدلها به منظور ايجاد UML در سال 1993 آغاز گرديد. هريك از اين سه تفنگدار شروع به آميختن ايده هاي متدولوژي هاي ديگر با هم نمودند.يكپارچه سازي رسمي متدولوژي ها تا سال 1995 ادامه داشت. در اين سال نسخه 0.8 Unified Method معرفي شد. اين نسخه ، اصلاح شده و در سال 1996 به Unified Modeling Language تغيير يافت.
اسلاید 25: 25بیشتر بدانیم نسخه UML 1.0 تاييد شد و در سال 1997 به گروه تكنولوژي آبجكت ( Object Group Technology ) داده شد.شركتهاي توليد كننده نرم افزار شروع به سازگار شدن با آن نمودند.سرانجام در نوامبر 1997 OMG نسخه UML 1.1 را به عنوان يك استاندارد صنعتي معرفي نمود.
اسلاید 26: 26بیشتر بدانیم نمودارهاي UMLUML به افراد اجازه مي دهد تا چندين نوع مختلف از نمودارهاي بصري را به وجود آورند كه جنبه هاي مختلف سيستم را نمايش مي دهد. نرم افزار Rational Rose از ايجاد اكثر اين مدلها پشتيباني مي كند. اين نمودارها به قرار زير هستند :نمودارهاي درخواست سيستم يا موردهاي استفاده (Use Case Diagrams)نمودارهاي كلاس (Class Diagrams)نمودارهاي توالي (Sequence Diagrams) نمودارهاي همكاري (Collaboration Diagrams) نمودارهاي انتقال حالت ( State Transition Diagrams) نمودارهاي فعاليت (مدل سازي پردازشي) ( Activity Diagrams) نمودار اجزاء (Component Diagram) نمودار استقرار ( Deployment Diagram)
اسلاید 27: 27بیشتر بدانیم نمودارهاي UMLنمودارهاي درخواست سيستم (Use Case Diagrams)نمودارهاي درخواست سيستم براي تحليل نيازمندي هاي وظيفه اي سيستم تهيه مي شود. نمودارهاي درخواست سيستم در فاز تحليل سيستم تهيه مي شود و اين ديد را به توسعه دهندگان سيستم مي دهد كه سيستم جديد چيست و چه كارهايي انجام مي دهد؟با اين نمودار يك ارتباط متقابل با كاربر برقرار مي شود كه پس از بحث و بررسي و حصول توافق نيازمندي هاي وظيفه اي سيستم نهايي مي شود.
اسلاید 28: بیشتر بدانیم نمودارهاي Use Case محاورات ميان Use Case ها را نشان مي دهند و عمليات سيستمي و عامل ها ( Actors ) را بيان مي كنند.Actor ها نشان دهنده افراد يا سيستم هايي هستند كه اطلاعات را براي سيستم فراهم كرده و يا از آن دريافت مي كنند. نمودارهاي Use Case محاورات بين Use Caseها و Actorها را نشان مي دهند.Use Case ها درخواستهاي سيستم را از ديد كاربر نشان مي دهند بنابراين Use Case ها عمليات سطح بالايي هستند كه سيستم فراهم مي كند. در واقع Use Case ها توالي از اقدامات به هم مرتبط است كه توسط يك Actor در سيستم راه اندازي مي شود تا به يك هدف مشخصي برسد يا به عبارت ديگر هر Use Case يك راه مشخص استفاده از سيستم است.
اسلاید 29: 29بیشتر بدانیم توجه داشته باشيد كه كاربر (user) با آكتور (Actor) متفاوت است. كاربر كسي است كه از سيستم استفاده مي كند ولي Actor بيانگر نقشي است كه يك كاربر ايفا مي كند. نام Actor بايد بيانگر نقش آن باشد. Actor يك نوع يا مجموعه اي از كاربران خواهد بود. در واقع يك كاربر يك نمونه خاص از Actor خواهد بود كه آن نقش را بازي مي كند. توجه داشته باشيد كه يك كاربر مي تواند چندين نقش بازي كند.به عنوان مثال : علي در سيستم هم مربي است و هم استاد راهنما لذا علي يك نمونه از Actor مربي و همين طور يك نمونه از Actor استاد راهنما است.براي اينكه Actor ها خارج از سيستم هستند نيازي به تشريح تفضيلي آنها نيست ولي مزيت تعريف آنها اين است كه Use Case ها مشخص مي شوند.
اسلاید 30: 30بیشتر بدانیم نمودارهاي UMLنمودارهاي درخواست سيستم (Use Case Diagrams)مثال: نمودار Use Case سيستم ATM بانك
اسلاید 31: 31بیشتر بدانیم ادامه مثال: نمودار Use Case سيستم ATM بانكمورد استفاده(Use Case): برداشت پولپيام احوالپرسي در ATM ظاهر مي شود.مشتري كارت خود را در ماشين قرار مي دهد.ATM از مشتري PIN را مي پرسد.مشتري PIN را وارد مي كند.ATM حسابهاي مشتري را نشان مي دهد تا انتخاب كند.مشتري حسابي را انتخاب مي كند.ماشين حدود حساب را نشان مي دهد.مشتري مقدار برداشت را مشخص مي كند.صورتحساب تنظيم مي شود.كارت خارج شده و رسيد نيز صادر مي شود.
اسلاید 32: 32بیشتر بدانیم نمودارهاي UMLنمودارهاي درخواست سيستم (Use Case Diagrams)مثال: سيستم ثبت نام در دانشگاه
اسلاید 33: 33بیشتر بدانیم نمودارهاي UMLنمودارهاي درخواست سيستم (Use Case Diagrams)ارتباط بين Use Case ها اگر در Use Case توالي از فعاليت ها وجود دارند كه در حالت هاي خاص و بطور اضافه انجام مي شوند و Actor ديگري در آن نقش دارند با عملگر extend آن Use Case تجزيه مي شود.
اسلاید 34: 34بیشتر بدانیم نمودارهاي UMLنمودارهاي درخواست سيستم (Use Case Diagrams)ارتباط بين Use Case ها اگر يك Use Case به Use Case هاي ديگر ارجاع دهد (رفرنس دهد) از ارتباط include استفاده مي شود.
اسلاید 35: 35بیشتر بدانیم نمودارهاي UMLنمودارهاي درخواست سيستم (Use Case Diagrams)مثال: سيستم غذاي حاضري (سريع)
اسلاید 36: 36بیشتر بدانیم نمودارهاي UMLنمودارهاي كلاس (Class Diagrams)ساختار ايستا (ثابت) مدل موجوديت گرا را نشان مي دهد. يعني بيانگر كلاس هاي موجوديت، ساختار داخلي آنها و ارتباطي كه آنها با هم مشاركت دارند است.در UML كلاس موجوديت با يك مستطيل كه داراي سه قسمت است نشان داده مي شود. در قسمت اول نام كلاس موجوديت، در قسمت دوم مشخصه ها (حالت) كلاس موجوديت و در قسمت سوم عملگر (عمليات) كلاس موجوديت كه توسط آنها عمل و عكس العمل نشان مي دهد بيان مي شود.
اسلاید 37: 37بیشتر بدانیم نمودارهاي UMLنمودارهاي كلاس (Class Diagrams)نمودار Class مثال ATM در زير نشان داده شده است:
اسلاید 38: 38بیشتر بدانیم نمودارهاي UMLنمودارهاي كلاس (Class Diagrams)در يك نمودار Class هر كلاس با مستطيلي نشان داده شده كه به 3 بخش تقسيم شده است.بخش اول نام كلاس را نشان مي دهد. نام كلاس مي بايست دربرگيرنده مفهوم كليه آبجكت هايي باشد كه به آن كلاس نگاشت خواهند شد.بخش دوم صفات(Attributes) كلاس را نشان مي دهد. يك صفت ، قطعه اي از اطلاعات است كه با يك كلاس مرتبط مي باشد.مثلا كلاس حساب(Account) شامل سه صفت است :شماره حساب(Account Number)PINتراز موجودي(Balance)
اسلاید 39: 39بیشتر بدانیم آخرين بخش شامل عملگرهاي كلاس(Operations) مي باشد.يك عملگر ، تعدادي رفتار است كه توسط كلاس آماده خواهد شد.مثلا كلاس حساب شامل چهار عملگر است:باز كردن(Open)برداشت وجه(Withdraw Funds)كسر موجودي(Deduct Funds)تاييد موجودي(Verify Funds)خطوط بين كلاسها ، وابستگي ارتباطات بين كلاسها را نشان مي دهد.
اسلاید 40: مثال
اسلاید 41: عناصر جریان گرا : انتقال اطلاعات با جریان یافتن در یک سیستم کامپیوتری صورت می پذیرد .در عمل می توانیم برای هر سیستم کامپوتری با هر اندازه و هرمیزان پیچیدگی ،یک مدل جریان تولید کنیم.
اسلاید 42: الگو های تحلیل : الگوهای تحلیل راهکارهایی (مثلا یک کلاس ،یک عملکرد ،یک رفتار )در این دامنه کاربردی پیشنهاد می کنند .که در مدل سازی بسیاری از برنامه های کاربردی قابل استفاده مجدد است .
اسلاید 43: دو مزیتکه با به کار گیری الگو های تحلیل می توان آن ها را مرتبط دانست :1)این الگو های تحلیل ،توسعه مدل های انتزاعی را سرعت می بخشند .2)الگو های تحلیل ،تبدیل مدل تحلیل به یک مدل طراحی را با پیشنهاد الگو های طراحی و راهکار های قابل اطمینان برای مسائل رایج تسهیل می کند .
اسلاید 44: مذاکره بر سر خواسته ها ایده ال مهندسی خواسته ها مشاجره با یک یا چند طرف ذی نفع هدف : مذاکره توسعه یک طرح پروژه است که نیاز های طرف ذی نفع را بر طرف سازد و در همان حال قید و بند های جهان واقعی (مانن زمان ،آدم ها ،بودجه )را که تیم نرم افزار با ان مواجه است را منعکس می کند .
اسلاید 45: هنر مذاکره هدف بهترین مذاکره ها نتیجه ای «برد-برد» است .
اسلاید 46: مجموعه ای از فعالیت های مذاکره : 1)شناسایی طرف های ذی نفع مهم سیستم یا زیر سیستم 2)تعیین شرایط برد برای طرف های ذی نفع 3)مذاکره بر سر شرایط برد طرف های ذی نفع برای رساندن آنها به شرایط برد –برد ،برای تمامی طرف ها (از جمله تیم نرم افزار.با تکمیل موفقیت آمیز این مراحل آغازی نتیجه ی برد- برد حاصل خواهد شد که ملاک کلیدی برای پیش رفتن به فعالیت های بعدی در مهندسی نرم افزار است.
اسلاید 47: اعتبار سنجی خواسته ها از نظر ناسازگاری ابهام موارد جا افتاده
نقد و بررسی ها
هیچ نظری برای این پاورپوینت نوشته نشده است.