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

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 توالي از فعاليت ها وجود دارند كه در حالت هاي خاص و بطور اضافه انجام مي شوند و Actor ديگري در آن نقش دارند با عملگر extend آن Use Case تجزيه مي شود.

16. جلسه يازدهم نمودارهاي UML نمودارهاي درخواست سيستم (Use Case Diagrams)
اگر يك 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)
كلاسها مي توانند به عنوان طرحي كلي براي آبجكت ها ديده شوند. مثلا حساب يك كلاس است در حاليكه حساب Joe يك آبجكت است.
كلاسها شامل اطلاعات و رفتارهايي هستند كه برروي اطلاعات عمل مي كنند. كلاس حساب شامل PIN مشتري و رفتاري كه PIN را كنترل مي كند مي باشد.
در نمودار Class براي هر نوع آبجكتي در نمودارهاي Sequence و Collaboration يك كلاس ايجاد شده است. هر آبجكتي به يك كلاس منحصربه فرد تعلق دارد در حاليكه يك كلاس معمولا چندين آبجكت را در بردارد.

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

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

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

27. جلسه يازدهم نمودارهاي كلاس (Class Diagrams)
نمادهاي نمايش وابستگي ها (ارتباطات) در نمودار كلاس
نوع ارتباط
نماد در UML
نمايش ارتباط
شرح
Exactly 1 1
An employee
works for one
and only one
department.
Leave blank `
Zero or 1
0..1
An employee has
either one or no
spouse.
Zero or More
0..*
A customer can
make no payment
up to many
payments. *
Employee
Department
Works For 1
Employee
Department
Works For
Employee
Spouse
Has
0..1
Customer
Payment
Makes
0..*
Customer
Payment
Makes *

28. جلسه يازدهم نمودارهاي UML نمودارهاي كلاس (Class Diagrams)
نمادهاي نمايش وابستگي ها (ارتباطات) در نمودار كلاس
نوع ارتباط
نماد در UML
نمايش ارتباط
شرح
One or more
1..*
A university
offers at least 1
course up to
many courses.
Specific
range
7..9
A team has either
7,8 or 9 games
scheduled
many to
many *
University
Course
Offers
1..*
Team
Game
Has
Scheduled
7..9
Student
Course
Registered
for *

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)
هر کلاسي حالت کلي تر يا چند آبجکت را نشان مي دهد. در اين نمودار براي اينکه 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 در متدولوژي ساخت يافته است.

51. جلسه يازدهم نمودارهاي UML
نمودارهاي فعاليت (مدل سازي پردازشي) (Activity Diagrams)

52. جلسه يازدهم نمودارهاي UML نمودار اجزاء (Component Diagram)
نمودارهاي Component يك ديد فيزيكي از مدلتان را به شما نشان مي دهد. يك نمودار Component اجزاي نرم افزاري سيستم شما و روابط بين آنها را به شما نشان مي دهد.
دو نوع Component در نمودار وجود دارد، Component هاي قابل اجرا و كتابخانه هاي كد
در Rose، هريك از كلاسهاي موجود در مدل به يك Component كد منبع نگاشت شده اند. اولين باري كه Component ها ايجاد مي شوند ، آنها به نمودار Component اضافه مي گردند سپس وابستگي هاي ميان Componentها كشيده مي شود. وابستگي هاي Component ها، وابستگي هاي زمان اجرا و زمان ترجمه ميان Componentها را نشان مي دهد.

53. جلسه يازدهم نمودار اجزاء (Component Diagram)
شكل زير يكي از نمودارهاي Component را براي سيستم ATM نشان مي دهد:

54. جلسه يازدهم نمودارهاي UML نمودار اجزاء (Component Diagram)
اين نمودار Component، Componentهاي سرويس گيرنده(Client) را در سيستم ATM نشان مي دهد.
هر كلاسي فايل ابتداي برنامه(Header File) و فايل كتابخانه كد خودش را دارد، بنابراين هر كلاسي به Componentهاي خودش نگاشته شده است.
مثلا كلاس ATM Screen به يك Component به نام ATM Screen نگاشته شده است. كلاس ATM Screen همچنين به يك Component دوم ATM Screen نگاشت شده است.
Component سايه دار، بدنه فايل يا كتابخانه كد كلاس ATM Screen را نمايش مي دهد و يك Package Specification (مشخصات بسته) ناميده مي شود.Component غير سايه دار نيز فايل ابتدايي برنامه را نشان مي دهد.
Component با نام ATM.exe يك مشخصات وظيفه است و يك نسخه از پردازش را نشان مي دهد. در اين مورد نسخه پردازش برنامه قابل اجرا مي باشد.

55. جلسه يازدهم نمودارهاي UML نمودار اجزاء (Component Diagram)
بطور عمومي ، بسته ها مجموعه اي از آبجكت ها هستند. در اين مورد، بسته ها مجموعه اي از Componentها مي باشند. ATM شامل دو بسته است: ATM Client و ATM Server
نمودارهاي Component به وسيله هر شخصي كه مسئول تنظيم و تدوين سيستم است استفاده مي شود. نمودارهاي Component اين ويژگي را بيان مي كنند كه به چه منظوري نياز به كامپايل Componentها وجود دارد. همچنين نشان مي دهد كه چه Componentهايي در زمان اجرا به عنوان نتيجه كامپايل ايجاد خواهند شد. نمودارهاي Component، نگاشته شدن كلاسها به اجزاي اجرا شده را نشان مي دهند. اين نمودارها در جايي كه توليد كد تمام شده است رسم مي شوند.

56. جلسه يازدهم نمودارهاي UML نمودار استقرار ( Deployment Diagram)
نمودار Deployment آخرين نوع نمودارهايي است كه Rose براي ما ايجاد مي كند.
نمودار Deployment لايه فيزيكي شبكه و جايي كه Deployment هاي مختلف مقيم مي شوند را نشان مي دهد.
در مثال ATM، ATM از بسياري زيرسيستمهاي در حال اجرا بر روي وسايل فيزيكي مجزا يا گره ها تشكيل شده است.

57. جلسه يازدهم نمودارهاي UML نمودار استقرار ( Deployment Diagram)
نمودار ِDeployment براي مثال ATM در زير آمده است:

58. جلسه يازدهم نمودارهاي UML نمودار استقرار ( Deployment Diagram)
بنابراين اين نمودار به ما نصب فيزيكي سيستم را نشان مي دهد. سيستم ATM ما يك سبك معماري 3 طبقه دارد : يك طبقه پايگاه داده، سرويس دهنده اصلي و سرويس گيرنده.
نمودار Deployment به وسيله مدير پروژه ، كاربران ، طراح و برنامه نويسان استفاده مي شود تا لايه فيزيكي سيستم و جاي زير سيستم هاي مختلفي كه مقيم خواهند شد را بفهمند.
اين نمودار به مدير پروژه كمك مي كند كه بفهمد چه سيستمي مناسب كاربران خواهد بود. همچنين به پرسنلي كه مسئول برنامه نويسي هستند كمك مي كند تا فعاليتهاي برنامه نويسي آنها را برنامه ريزي نمايد.

59. جلسه يازدهم مقايسه نمودارهاي متدولوژي هاي شيي گرا و ساخت يافته
همه اين نمودارها با هم ، سيستم را از چند بعد متفاوت نشان مي دهد.
همانطور كه در تجزيه و تحليل و طراحي بخش دستي سيستم هاي اطلاعاتي با متدولوژي ساخت يافته ، ابزارهايي چون نمودارهاي جريان دادها (DFD)، نمودار ارتباط موجوديت ها (ERD)، نمودارهاي وظيفه اي سيستم (SPC)، نمودارهاي گردش فرم (MFC)، برگه هاي تشريح پردازش، برگه هاي تشريح بايگاني، ديكشنري داده ها(DD) و غيره به تحليلگر سيستم در تجزيه و تحليل آن كمك مي كند و تحليلگر مي تواند به كمك آنها سيستم را مدل نمايد.
در تجزيه و تحليل و طراحي بخش كامپيوتري سيستم هاي اطلاعاتي نيز Rational Rose يك نرم افزار قدرتمند است كه به تجزيه و تحليل و طراحي سيستم هاي نرم افزاري شيء گرا كمك مي كند.

60. جلسه يازدهم توانائي هاي UML
Rational Rose با كمك به تجزيه و تحليل و طراحي سيستم ها شما را قادر مي سازد تا Use Caseها و نمودارهاي Use Case را براي نشان دادن عمليات سطح بالاي سيستم طراحي نماييد.
به شما اجازه خواهد داد تا نمودارهاي Sequence و Collaboration را براي نشان دادن اينكه آبجكت ها چگونه با يكديگر كار مي كنند تا عمليات مورد نياز را فراهم كنند طراحي نماييد.
كلاسها و نمودارهاي Class ايجاد شده اند تا آبجكت هاي يك سيستم را نشان دهند و اينكه چگونه آنها با يكديگر ارتباط دارند.
نمودارهاي Component مي توانند ايجاد شوند تا نشان دهند كه چگونه كلاسها به اجزاي اسبابي و ابزاري نگاشت مي شوند.
در نهايت يك نمودار Deployment مي تواند توليد شود تا طرح شبكه اي سيستم را نشان دهد.

61. جلسه يازدهم
مثال: سيستم كتابخانه

62. جلسه يازدهم
مثال: سيستم كتابخانه

63. جلسه يازدهم
مثال: سيستم كتابخانه

64. جلسه يازدهم
مثال: سيستم كتابخانه

65. جلسه يازدهم
مثال: سيستم كتابخانه