1 / 65

سيستمهاي اطلاعات مديريت

سيستمهاي اطلاعات مديريت. http://www.Beiki.info. جلسه يازدهم. UML چيست؟ نمودارهاي UML نمودارهاي درخواست سيستم ( Use Case Diagrams ) نمودارهاي كلاس ( Class Diagrams ) نمودارهاي توالي ( Sequence Diagrams ) نمودارهاي همكاري ( Collaboration Diagrams )

melosa
Download Presentation

سيستمهاي اطلاعات مديريت

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. سيستمهاي اطلاعات مديريت http://www.Beiki.info

  2. جلسه يازدهم • UML چيست؟ • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • نمودارهاي كلاس (Class Diagrams) • نمودارهاي توالي (Sequence Diagrams) • نمودارهاي همكاري (Collaboration Diagrams) • نمودارهاي انتقال حالت ( State Transition Diagrams) • نمودارهاي فعاليت (مدل سازي پردازشي) ( Activity Diagrams) • نمودار اجزاء (Component Diagram) • نمودار استقرار ( Deployment Diagram) • مقايسه نمودارهاي متدولوژي هاي شيي گرا و ساخت يافته • توانائي هاي UML • مثال

  3. جلسه يازدهم • UML چيست؟ • يك موضوع مهم در مدلسازي بصري اين است كه از چه نماد گرافيكي براي نشان دادن چهره هاي مختلف يك سيستم استفاده شود. • لازم است كه اين نماد براي همه بخشهاي وابسته و درگير با سيستم مفهوم باشد در غير اين صورت مدل خيلي مفيد نخواهد بود. • بسياري از افراد نمادهايي را براي مدل سازي بصري پيشنهاد نموده اند. • بعضي از اين نمادها كه محبوب هستند و پشتيباني قوي دارند عبارتند از : • Booch • OMT ( Object Modeling Technology) • UML ( Unified Modeling Language) • برنامه Rational Rose از اين سه نماد پشتيباني مي كند.

  4. جلسه يازدهم • UML چيست؟ • متد 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 كار مي كنند

  5. جلسه يازدهم • UML چيست؟ • اين سه بر روي استاندارد سازي و اصلاح UML متمركز شده اند. سمبل هاي UML تقريبا با نمادهاي Booch وOMT متناسب است و همچنين شامل عناصري از نمادهاي ديگر نيز مي باشد. • ادغام مدلها به منظور ايجاد UML در سال 1993 آغاز گرديد. • هريك از اين سه تفنگدار شروع به آميختن ايده هاي متدولوژي هاي ديگر با هم نمودند. • يكپارچه سازي رسمي متدولوژي ها تا سال 1995 ادامه داشت. در اين سال نسخه 0.8 Unified Method معرفي شد. • اين نسخه ، اصلاح شده و در سال 1996 به Unified Modeling Language تغيير يافت.

  6. جلسه يازدهم • UML چيست؟ • نسخه UML 1.0تاييد شد و در سال 1997 به گروه تكنولوژي آبجكت( Object Group Technology ) داده شد. • شركتهاي توليد كننده نرم افزار شروع به سازگار شدن با آننمودند. • سرانجام در نوامبر 1997 OMG نسخه UML 1.1را به عنوانيك استاندارد صنعتي معرفي نمود.

  7. جلسه يازدهم • نمودارهاي UML • UML به افراد اجازه مي دهد تا چندين نوع مختلف از نمودارهاي بصري رابه وجود آورند كه جنبه هاي مختلف سيستم را نمايش مي دهد. نرم افزار Rational Roseاز ايجاد اكثر اين مدلها پشتيباني مي كند. اين نمودارها به قرار زير هستند : • نمودارهاي درخواست سيستم يا موردهاي استفاده (Use Case Diagrams) • نمودارهاي كلاس (Class Diagrams) • نمودارهاي توالي (Sequence Diagrams) • نمودارهاي همكاري (Collaboration Diagrams) • نمودارهاي انتقال حالت ( State Transition Diagrams) • نمودارهاي فعاليت (مدل سازي پردازشي) ( Activity Diagrams) • نمودار اجزاء (Component Diagram) • نمودار استقرار ( Deployment Diagram)

  8. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • نمودارهاي درخواست سيستم براي تحليل نيازمندي هاي وظيفه اي سيستم تهيهمي شود. نمودارهاي درخواست سيستم در فاز تحليلسيستم تهيه مي شود و اينديد را به توسعه دهندگان سيستم مي دهد كه سيستم جديد چيست و چهكارهايي انجام مي دهد؟ • با اين نمودار يك ارتباط متقابل با كاربر برقرار مي شود كه پس از بحث وبررسي و حصول توافق نيازمندي هاي وظيفه اي سيستم نهايي مي شود.

  9. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • نمودارهايUse Caseمحاورات ميان Use Case ها را نشان مي دهند و عمليات سيستمي و عامل ها ( Actors ) را بيان مي كنند. • Actor ها نشان دهنده افراد يا سيستم هايي هستند كه اطلاعات را براي سيستم فراهم كرده و يا از آن دريافت مي كنند. (مشابه نهاد هاي خارجي در DFD) • نمودارهاي Use Case محاورات بين Use Caseها و Actorها را نشان مي دهند. • Use Caseها درخواستهاي سيستم را از ديد كاربر نشان مي دهند بنابراينUse Caseها عمليات سطح بالايي هستند كه سيستم فراهم مي كند. در واقع Use Caseها توالي از اقدامات به هم مرتبط است كه توسط يكActor در سيستم راه اندازي مي شود تا به يك هدف مشخصي برسد يا به عبارت ديگر هرUse Caseيك راه مشخص استفاده از سيستم است.

  10. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • توجه داشته باشيد كه كاربر(user)با آكتور(Actor)متفاوت است. كاربركسي است كه از سيستم استفاده مي كند وليActorبيانگر نقشي است كه يككاربر ايفا مي كند. نام Actor بايد بيانگر نقش آن باشد. • Actorيك نوع يا مجموعه اي از كاربران خواهد بود. در واقع يك كاربر يكنمونه خاص ازActorخواهد بود كه آن نقش را بازي مي كند. توجه داشتهباشيد كه يككاربر مي تواند چندين نقش بازي كند. • به عنوان مثال : علي در سيستم هم مربي است و هم استاد راهنما لذا علي يك نمونه ازActorمربي و همين طور يك نمونه از Actorاستاد راهنما است. • براي اينكهActorها خارج از سيستم هستند نيازي به تشريح تفضيلي آنها نيستولي مزيت تعريف آنها اين است كهUse Caseها مشخص مي شوند.

  11. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • براي تعريف Use Case ها جاكوبسن در سال 1992 پرسش هاي ذيل را مطرح نمود كه با پاسخ به آنها Use Case ها به دست مي آيند: • فعاليت هاي اصلي كه توسط هرActorانجام مي شوند چيست ؟ • آيا Actorاطلاعاتي را از سيستم خوانده يا بروزآوري مي كند ؟ • آيا Actorبايد در مورد تغييرات بيروني، سيستم را مطلع سازد ؟ • آيا Actorها بايد در خصوص تغييرات غير منتظره مطلع شوند ؟

  12. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • مثال: نمودار Use Case سيستم ATM بانك

  13. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • ادامه مثال: نمودار Use Case سيستم ATM بانك • مورد استفاده(Use Case): برداشت پول • پيام احوالپرسي در ATM ظاهر مي شود. • مشتري كارت خود را در ماشين قرار مي دهد. • ATM از مشتري PIN را مي پرسد. • مشتري PIN را وارد مي كند. • ATM حسابهاي مشتري را نشان مي دهد تا انتخاب كند. • مشتري حسابي را انتخاب مي كند. • ماشين حدود حساب را نشان مي دهد. • مشتري مقدار برداشت را مشخص مي كند. • صورتحساب تنظيم مي شود. • كارت خارج شده و رسيد نيز صادر مي شود.

  14. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • مثال: سيستم ثبت نام در دانشگاه

  15. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • ارتباط بين Use Case ها • اگر در Use Caseتوالي از فعاليت ها وجود دارند كه در حالت هاي خاص و بطور اضافه انجام مي شوند و Actor ديگري در آن نقش دارند با عملگر extend آن Use Case تجزيه مي شود.

  16. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • ارتباط بين Use Case ها • اگر يك Use Case به Use Case هاي ديگر ارجاع دهد (رفرنس دهد) از ارتباط include استفاده مي شود.

  17. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • مثال: سيستم غذاي حاضري (سريع)

  18. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • اگر شما براي استفاده از روابطinclude و extendدر مدل اطمينان نداريدبه معيار ذيل كه توسط جاكوبسن ارايه شده توجه نماييد: • اگر Use Caseهاي مختلفي هستند كه مي توانند به عنوان بسط يافته يكUse Caseكامل در نظر گرفته شوند از رابطهextend استفاده نماييد. • به عنوان مثالUse Case ثبت نام به دو Use Caseمستقل ثبت نام درسويژه و ثبت نام درس هايي كه پيشنيازي آنها تكميل نشده اند تقسيم مي شود بهطوري كهUse Caseثبت نام، كامل است و بسط يافته آن ثبت نام درسهاي ويژه و ثبت نام درس هايي كه پيشنياز آنها تكميل نشده اند است.

  19. جلسه يازدهم • نمودارهاي UML • نمودارهاي درخواست سيستم (Use Case Diagrams) • اگر شما براي استفاده از روابطinclude و extendدر مدل اطمينان نداريدبه معيار ذيل كه توسط جاكوبسن ارايه شده توجه نماييد: • اگر يك رفتار مشترك در دو يا چند Use Case استفاده مي شود مي توان از ارتباط include استفاده كرد كه مرجع رفتارهاي Use Caseهايي كه به آن ارجاع مي شود است. • به عنوان مثال در Use Case بازنگري سفارش و تهيه گزارش مديريتي داده هاي سفارش و موجودي پيگيري مي شود لذا براي بيان اين وضعيت يك Use Case به نام پيگيري داده هاي سفارش و موجودي به مدل اضافه شده و Use Case هاي بازنگري سفارش و تهيه گزارش مديريتي به آن ارجاع داده مي شوند.

  20. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • ساختار ايستا (ثابت) مدل موجوديت گرا را نشان مي دهد. يعني بيانگر كلاس هاي موجوديت، ساختار داخلي آنها و ارتباطي كه آنها با هم مشاركت دارند است. • در UMLكلاس موجوديت با يك مستطيل كه داراي سه قسمت است نشان داده مي شود. در قسمت اول نام كلاس موجوديت، در قسمت دوم مشخصه ها (حالت) كلاس موجوديت و در قسمت سوم عملگر (عمليات) كلاس موجوديت كه توسط آنها عمل و عكس العمل نشان مي دهد بيان مي شود.

  21. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • تعاريف پايه نمودارهاي كلاس

  22. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • انواع عملگر در كلاس موجوديت • عمليات سازنده(Constructive operation):يك نمونه از كلاس موجوديت توليد مي كند. به عنوان مثالCreate Account در كلاس موجوديت حساب يك موجوديت حساب توليد مي كند و حالت (وضعيت) آن را راه اندازي مي كند. اين نوع عمليات معمولا در تمام كلاس موجوديت ها وجود دارد و نيازي به تعريف آن در نمودار كلاس نيست. • عمليات پرس و جو(Query operation):اين عمليات دسترسي به حالت يا وضعيت يك موجوديت را مهيا مي كند اما حالت را تغيير نمي دهد. اين نوع عمليات معمولا در تمام كلاس موجوديت ها وجود دارد و نيازي به تعريف آن در نمودار كلاس نيست. • عمليات به روزآوري(Update operation):اين عمليات حالت موجوديت را تغيير مي دهد. • عمليات محدوده(Scope operation): اين عمليات براي يك موجوديت خاص نيست بلكه براي كل مجموعه موجوديت ها (كلاس)است به عنوان مثال ميانگين معدل دانشجويان كه براي كلاس دانشجو اعمال مي شود

  23. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • نمودارهاي Class ارتباطات بين كلاسها را در سيستم نشان مي دهد. • كلاسها مي توانند به عنوان طرحي كلي براي آبجكت ها ديده شوند. مثلا حساب يك كلاس است در حاليكه حساب Joe يك آبجكت است. • كلاسها شامل اطلاعات و رفتارهايي هستند كه برروي اطلاعات عمل مي كنند. كلاس حساب شامل PIN مشتري و رفتاري كه PIN را كنترل مي كند مي باشد. • در نمودار Class براي هر نوع آبجكتي در نمودارهاي Sequence و Collaboration يك كلاس ايجاد شده است. هر آبجكتي به يك كلاس منحصربه فرد تعلق دارد در حاليكه يك كلاس معمولا چندين آبجكت را در بردارد.

  24. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • نمودار Class مثال ATM در زير نشان داده شده است:

  25. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • در يك نمودار Class هر كلاس با مستطيلي نشان داده شده كه به 3 بخش تقسيم شده است. • بخش اول نام كلاس را نشان مي دهد. نام كلاس مي بايست دربرگيرنده مفهوم كليه آبجكت هايي باشد كه به آن كلاس نگاشت خواهند شد. • بخش دوم صفات(Attributes) كلاس را نشان مي دهد. يك صفت ، قطعه اي از اطلاعات است كه با يك كلاس مرتبط مي باشد. • مثلا كلاس حساب(Account) شامل سه صفت است : • شماره حساب(Account Number) • PIN • تراز موجودي(Balance)

  26. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • آخرين بخش شامل عملگرهاي كلاس(Operations) مي باشد. • يك عملگر ، تعدادي رفتار است كه توسط كلاس آماده خواهد شد. • مثلا كلاس حساب شامل چهار عملگر است: • باز كردن(Open) • برداشت وجه(Withdraw Funds) • كسر موجودي(Deduct Funds) • تاييد موجودي(Verify Funds) • خطوط بين كلاسها ، وابستگي ارتباطات بين كلاسها را نشان مي دهد.

  27. جلسه يازدهم 1 Employee Works For Department Employee Works For Department Employee Customer Customer Makes Has Makes 0..* * 0..1 Spouse Payment Payment • نمودارهاي كلاس (Class Diagrams) • نمادهاي نمايش وابستگي ها (ارتباطات) در نمودار كلاس

  28. جلسه يازدهم University Team Offers Has Scheduled 1..* 7..9 Course Game Student * Registered for * Course • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • نمادهاي نمايش وابستگي ها (ارتباطات) در نمودار كلاس

  29. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • مثال

  30. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • كلاس وابستگي(ارتباط)(Association Class) • وقتي وابستگي يا ارتباط بين كلاس موجوديت ها داراي مشخصه اطلاعاتي(Attribute) باشد از كلاس وابستگي استفاده مي شود كه در واقع دو نقش بازي مي كند هم به عنوان يك كلاس و هم به عنوان يك رابطه عمل مي كند. • اين حالت در وابستگي هاي چند به چند مي تواند بوجود آيد و مي توان با استفاده از كلاس وابستگي وابستگي چند به چند را به دو وابستگي يك به چند تبديل كرد.

  31. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • وابستگي چندگانه(ارتباط)(N-ary Association): • وقتي بين بيش از دو كلاس وابستگي ايجاد شود وابستگي چندگانه مطرح مي شود. • سيستم توليدي را در نظر بگيريد كه پرسنل مختلف ، مجموعه قطعات مختلف را مونتاژ مي كنند كه درتوليد محصولات نهايي استفاده مي شوند. لذا در اين سيستم سه كلاس وجود دارد : • پرسنل • مجموعه قطعات • محصول • نمودار كلاس به شرح ذيل خواهد بود :

  32. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • وابستگي چندگانه(ارتباط)(N-ary Association): • اين وابستگي هاي چند به چند مي تواند در پايگاه مشكلاتي را به بار بياورد. • در اين سيستم پرسنل مختلف روي مجموعه قطعات مختلف و محصولات نهايي مختلف كار مي كنند اگر بخواهيم رديابي كنيم كه روي كدام مجموعه قطعات و محصول نهايي كدام كارگر كار كرده است امكان پذير نيست. ولي اگر اين وابستگي ها را به يك به چند تبديل كنيم اين امر ميسر مي شود.

  33. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • وابستگي چندگانه(ارتباط)(N-ary Association):

  34. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • نمايش مشخصه ها و وابستگي هاي منتج شده • يك مشخصه يا وابستگي (ارتباط) منتج شده مي تواند از ساير مشخصه ها يا ارتباطات منتج شود (به دست آيد). براي نمايش آن از يك (slash) ( / ) قبل از آن استفاده مي شود. به مثال ذيل توجه نماييد

  35. جلسه يازدهم • نمودارهاي كلاس (Class Diagrams) • نمايش عمومي سازي(Generalization) • در متدولوژي شيء گرا شما مي توانيد مشخصه ها و عملگرهاي مشترك را در يك كلاس خلاصه كرده و ساير كلاس هاي مرتبط كه داراي اين ويژگي ها و عملگرها هستند را به اين كلاس عمومي شده ارجاع دهيد. به كلاس عمومي شده كلاس مافوق (والد) و به كلاس هاي مرتبط با آن كلاس هاي زيرمجموعه يا فرزند گفته مي شود.

  36. جلسه يازدهم • نمودارهاي UML • نمودارهاي كلاس (Class Diagrams) • نمايش ادغام (تركيب) كلاس ها در نمودار كلاس(Composition)

  37. جلسه يازدهم • نمودارهاي UML • نمودارهاي توالي (Sequence Diagrams) • Sequence طرح معمولي برداشت 20 دلار پول بدون هيچ مشكلي مانند وارد کردن PIN اشتباه يا وجوه ناکافي در حساب در ادامه نشان داده شده است. • نمودار Sequence جريان پردازش را در Use Case برداشت پول نشان مي دهد. عامل هاي وابسته در بالاي نمودار نشان داده شده اند. • در اين نمودار تنها عامل مرتبط با Use Case ، مشتري مي باشد. • همچنين آبجکت هايي که سيستم نياز دارد تا Use Case برداشت پول را به نتيجه برساند در بالاترين نقطه نمودار نشان داده مي شود. • هر فلش يک پيغام ارسالي بين عامل و آبجکت يا بين آبجکت و آبجکت را نمايش مي دهد تا عمليات مورد نياز را به انجام برساند.

  38. جلسه يازدهم • نمودارهاي UML • نمودارهاي توالي (Sequence Diagrams)

  39. جلسه يازدهم • نمودارهاي UML • نمودارهاي توالي (Sequence Diagrams) • نکته ديگر درباره نمودارهاي Sequence ، اين است که اين نمودار ، آبجکت ها را نمايش مي دهد نه کلاسها را. • هر کلاسي حالت کلي تر يا چند آبجکت را نشان مي دهد. در اين نمودار براي اينکه Use Case برداشت پول از حساب طبق سناريوي عادي بدون هيچ مشکلي به انجام برسد بايد آبجکت هاي ذکر شده در نمودار را داشته باشيم. • هر Use Case مي تواند چندين نمودار Sequence داشته باشد. هر نمودار Sequence در حالت خاص فقط يکي از حالات Use Case را نشان مي دهد و سعي مي شود عبارت شرطي در آن نشان داده نشود تا نمودار واضح تر باشد و آبجکت هاي مورد نياز بهتر مشخص شوند.

  40. جلسه يازدهم • نمودارهاي UML • نمودارهاي توالي (Sequence Diagrams) • نمودارهاي توالي براي نشان دادن جريان عمليات در يک Use Case استفاده مي شود. • مثلا Use Case برداشت پول از حساب، چند توالي (Sequence) دارد مانند: • برداشت پول • تلاش براي برداشت پول از حساب بدون موجودي • تلاش براي برداشت پول از PIN اشتباه • و غيره • براي هر يک از اين حالت ها يک نمودار توالي جداگانه رسم مي شود و ممکن است هر يک از اين نمودارها شامل آبجکت هاي متفاوتي باشند اما عموما بسياري از آبجکت ها در نمودار هاي توالي که به يک Use Case خاص مربوط مي شوند مشترک هستند.

  41. جلسه يازدهم • نمودارهاي UML • نمودارهاي توالي (Sequence Diagrams) • يک نمودار توالي، ارتباطات بين موجوديت هاي سيستم را در يک بازه زماني براي يک Use Case خاص نشان مي دهد. • موجوديت هايي که براي انجام عمليات Use Case مشارکت دارند در نمودار توالي نشان داده شده است و ارتباط بين آنها با ارسال پيام بين آنها بيان مي شود. • نمودار توالي مي تواند براي حالت عمومي يا حالت خاص (يک سناريو خاص از Use Case ) ترسيم شود.

  42. جلسه يازدهم • نمودارهاي UML • نمودارهاي همكاري (Collaboration Diagrams) • نمودارهايCollaboration دقيقا همان اطلاعات نمودارهاي Sequence را نشان مي دهند. وليكن نمودارهايCollaboration اطلاعات را به روشي متفاوت به نمايش مي گذارند. • در نمودار Collaboration مانند نمودار Sequence معادل آن ، آبجكت ها به شكل مستطيل هايي نشان داده شده اند و عامل ها به شكل هاي آدمك مي باشند. • در حاليكه در نمودار Sequence آبجكت ها و ارتباطات آنها با عامل ها ، به ترتيب زمان توضيح داده شده اند ، نمودار Collaboration آبجكت ها و فعل و انفعالات عامل ها را بدون توجه به زمان نشان مي دهد. • آبجكت هايي كه مستقيما با هم ارتباط برقرار مي كنند با خطوطي كه بين آنها كشيده شده نشان داده مي شوند. بنابراين اگر دو آبجكت و يا يك آبجكت و يك عامل مستقيما با هم رابطه داشته باشند ، بايد خطي بين آنها كشيده شده باشد. نبودن اين خط بدين معني است كه هيچ ارتباط مستقيمي بين اين دو آبجكت وجود ندارد. • بنابراين نمودارهاي Collaboration همان اطلاعات نمودارهاي Sequence را بدون توجه به زمان نشان مي دهند.

  43. جلسه يازدهم • نمودارهاي UML • نمودارهاي همكاري (Collaboration Diagrams)

  44. جلسه يازدهم • نمودارهاي UML • نمودارهاي انتقال حالت ( State Transition Diagrams) • نمودارهاي حالت راهي را آماده مي كنند تا حالتهاي مختلف يك آبجكت را مدل كنند. • در حاليكه نمودارهاي Class يك تصوير ثابت از كلاسها و وابستگي آنها را نشان مي دهند. • نمودارهاي حالت استفاده مي شوند تا بيشتر رفتارهاي پوياي يك سيستم را نمايش دهند. يك نمودار حالت ، رفتار يك آبجكت را نشان مي دهد. • مثلا يك حساب بانكي مي تواند به چندين حالت متفاوت وجود داشته باشد. مي تواند باز شود ، بسته شود يا بطور اضافي ازحساب برداشت شود. يك حساب ممكن است در هريك از اين حالتها بطور اتفاقي رفتار كند. از نمودارهاي حالت براي نشان دادن اين اطلاعات استفاده مي شود. مثالي از يك نمودار حالت براي يك حساب بانكي در زير نشان داده شده است

  45. جلسه يازدهم • نمودارهاي UML • نمودارهاي انتقال حالت ( State Transition Diagrams)

  46. جلسه يازدهم • نمودارهاي UML • نمودارهاي انتقال حالت ( State Transition Diagrams) • در اين نمودار مي توانيم حالتهاي مختلف يك حساب را ببينيم. همچنين مي توانيم ببينيم كه چگونه يك حساب از يك حالت به حالت ديگر منتقل مي شود. مثلا وقتي يك حساب در حالت باز است و مشتري درخواست بستن حساب را مي كند ، حساب به حالت بسته منتقل مي شود. • درخواست مشتري ، رخداد(Event) ناميده مي شود و رخداد چيزي است كه موجب مي شود يك انتقال از حالتي به حالت ديگر صورت گيرد. اگر حساب باز است و مشتري برداشت از حساب را انتخاب مي كند ، حساب ممكن است به حالت برداشت اضافه(Overdrawn) برود. اين فقط زماني اتفاق خواهد افتاد كه تراز موجودي كمتر از صفر باشد. بنابراين يك شرط را خواهيم داشت كه در براكت محصور شده است و شرط حفاظتي(Guard Condition) ناميده مي شود و وقوع يك انتقال ( اينكه بتواند يا نتواند اتفاق بيفتد ) را كنترل مي كند. • حالت يك موجوديت تغيير نمي كند مگر اينكه مشخصه اي از آن تغيير مقدار (ارزش) دهد. • در UMLهر حالت با يك مستطيل كه گوشه هاي آن منحني است نشان داده مي شود.

  47. جلسه يازدهم • نمودارهاي UML • نمودارهاي انتقال حالت ( State Transition Diagrams) • دو حالت ويژه ، حالت شروع (Start State) و حالت پايان (Finish State) وجود دارد. • حالت شروع با يك دايره توپر سياه درروي نمودار نمايش داده شده است و نشان مي دهد چه حالتي از آبجكت در ابتدا ايجاد شده است. • حالت پاياني به وسيله يك خال هدف نمايش داده شده است و نشان مي دهد كه آبجكت درست قبل از اينكه از بين برود ، در چه حالتي مي باشد. • روي يك نمودار حالت ، فقط و فقط يك حالت شروع وجود دارد در حاليكه شما مي توانيد حالت پاياني نداشته باشيد يا اينكه هرچند حالت پاياني كه نياز داريد را داشته باشيد. • ممكن است زمانيكه آبجكت درون يك حالت ويژه است چيزهاي مشخصي اتفاق بيفتد. در اين مثال وقتي كه از يك حساب زيادي برداشت شود ، يك اخطار به مشتري فرستاده مي شود. پردازشهايي كه در حالت مشخصي از آبجكت اتفاق مي افتند Actions ناميده مي شوند. اين پردازشها غير از، عملگرهاي كلاس آبجكت مي باشند.

  48. جلسه يازدهم • نمودارهاي UML • نمودارهاي انتقال حالت ( State Transition Diagrams) • يك آبجكت ممكن است چندين نمودار حالت داشته باشد و يا اينكه اصلا نمودار حالتي نداشته باشد. • نمودارهاي حالت براي هر كلاس ايجاد نمي شوند. آنها فقط براي كلاسهاي پيچيده استفاده مي شوند. • اگر آبجكتي از يك كلاس مي تواند در چند حالت وجود داشته باشد و در هر حالت خيلي متفاوت رفتار نمايد ، ممكن است لازم باشد يك نمودار حالت براي آن ايجاد نماييد.

  49. جلسه يازدهم • نمودارهاي انتقال حالت ( State Transition Diagrams) • مثال : نمودار انتقال حالت براي موجوديت دانشجو

  50. جلسه يازدهم • نمودارهاي UML • نمودارهاي فعاليت (مدل سازي پردازشي) (Activity Diagrams) • همانطور كه ملاحظه كرديد يك نمودار توالي ارتباطات بين موجوديت ها را براي انجام يك وظيفه يا فعاليت سيستم را نشان مي داد. يك نمودار حالت پيشرفت موجوديت را در حالت هاي مختلف در طول دوره زندگي را نشان مي دهد. • يك نمودار فعاليت : منطق شرطي را براي يك توالي از فعاليت هاي سيستم كه لازم هستند انجام شوند تا يك فرايند سازمان تكميل شود را نشان مي دهد. • هر فعاليت مي تواند دستي يا مكانيزه باشد و معمولا بيانگر اقداماتي است كه براي تبديل حالت موجوديت انجام مي شود و همينطور هر فعاليت يكي از مسئوليت هاي سيستم است. • بنابراين يك نمودار فعاليت يك نگاه يا مدل ديگري براي سيستم است كه تركيب شده جنبه هاي نمودار توالي و نمودار حالت است و مشابه DFD در متدولوژي ساخت يافته است.

More Related