Amirkabir University of Technology Department of Computer engineering & IT Software Engineering II Unified modeling

1. In the Name of GOD Amirkabir University of TechnologyDepartment of Computer engineering & ITSoftware Engineering IIUnified modeling Language(UML) April 2006

2. Table of Contents • References • OO Paradigm • Modeling • Overview of UML

3. References 1- “The Unified Modeling Language User Guide”, Grady Booch, James Rumbaugh, Ivar Jacobson 2- “The Unified Modeling Language Reference Guide”, Grady Booch, James Rumbaugh, Ivar Jacobson 3- “Mastering UML with Rational Rose 2002”, Wendey Rogss, 2002, Cybex

4. OO Paradigm در شي گرايي واحد برنامه ما کلاس است که طي آن اطلاعات و رفتار يک موجوديت پياده سازي مي شود.اصول: • Encapsulation: کپسوله کردن بخشي از اطلاعات و رفتارهايي که بر اساس آن اطلاعات صورت مي گيرد درون يک شيء. مزايا: محدود کردن تاثيرات تغييرات سيستم مخفي کردن اطلاعات

5. OO Paradigm • Inheritance: در شي گرايي ارث بري مکانيزمي است که بر اساس آن مي توان يک شي بر اساس شي ديگر ايجاد کرد که در آن شي فرزند کيفيت شي پدر را به ارث خواهد برد. تغييرات در پدر بر فرزندان موثر است و نه بالعکس. • Polymorphism: چند ريختي به معني داشتن چند شکل مختلف براي پياده سازي يک عملکرد است.

6. Modeling • Model: تعريف:تکنيک ثابت شده و صوری برای نمايش و بازنمايي اطلاعات هدف:نمايش ساده واقعيت • Why Modeling: Big Problem  n Smaller Problem اهداف: 1- نمايش وضعيت فعلي / آتي 2- تعيين ساختار و عملکرد سيستم 3- مبنايي براي توليد (نرم افزار) 4-مستند سازي

7. Modeling • اصول مدلسازي: 1- انتخاب مدل در نتيجه نهايي تاثير دارد. 2- هر مدل محدوديت برای ميزان نمايش دارد. 3- بهترين مدل : شبيه ترين به واقعيت 4- ديدگاه هاي مختلف درباره سيستم وجود دارد

8. Modeling ديدگاه هاي مختلف سيستم در UML: 1- Use Case View: - Requirements and Features - Analyst 2- Design View: - Problem and Solution - Designer and Programmer 3- Process View: - Multithreading - Programmer 4- Implementation View: - Technologies - Programmer 5- Deployment View: - Hardware and Topology - Designer and Technologist نکته:بر حسب نوع برنامه، ممکن است بعضي view ها مهمتر باشند.

9. Modeling

10. Modeling ديدگاه هاي مختلف سيستم در Rational Rose: 1- Use Case View:  Use Case View in UML Standard 2- Logic View:  Design View and Process View in UML Standard 3- Component View:  Implementation View in UML Standard 4- Deployment View:  Deployment View in UML Standard

11. Overview of UML سه مورد زير مباحث اصلي UML هستند: 1- Basic Building Blocks:  The Vocabulary of the UML 2- Rules:  Specify the Well-formed Model: Semantically Self-consistent and in harmony with all its related models. 3- Common Mechanisms:  An UML model is made simpler by presence of common mechanisms

12. Basic Building Blocks 1- Things  Structural Things: - Class - Interface - Collaboration - Use Case - Active Class - Component - Node  Behavioral Things: - Message - State  Grouping Things: - Package  Annotational Things: - Note

13. Basic Building Blocks 2- Relationships  Dependencyرابطه استفاده چيزی از ديگري  Association رابطه ساختاري  Generalization(is-a)رابطه تعميم  Realization رابطه تحقق بخشيدن

14. Basic Building Blocks 3- Diagrams 1- Class Diagram 2- Object Diagram 3- Use case Diagram 4- Sequence Diagram 5- Collaboration Diagram 6- Statechart Diagram 7- Activity Diagram 8- Component Diagram 9- Deployment Diagram

15. Basic Building Blocks - structural things 1- Class تعريف: اشياء که دارای خصوصيات مشابه، عملکرد مشابه، رابطه مشابه يا مفهوم مشابه هستند. نکته: اگر تعداد عملکردها زياد و نامرتبط با هم باشند، بهتر است کلاس به کلاسهاي ديگر شکسته شود.

16. Basic Building Blocks - structural things 2- Interface تعريف: External Behavior Visible فقط تعيين مشخصات (Specification) بدون پياده سازي نکته: در کلاسهاي عادي که فقط يک قسمت Public دارند و از بيرون قابل دسترسي هستند. Interface مشخص نمي کنيم.

17. Basic Building Blocks - structural things 3- Use Case تعريف: مجموعه عملياتهايي که نتيجه اي را در اختيار Actor قرار ميدهد نکته: - مفهموم Class و Use Case با هم متفاوتند. يک متد از يک کلاس اصلي مي تواند يک Use Case باشد. - Actor: کلاسي از سيستم که Active است و کار خاص مفيدي انجام ميدهد. ( فرد، سخت افزار، سيستم يا زير سيستم)

18. Basic Building Blocks - structural things 4- Collaboration تعريف: مجموعه از کلاسهايي که با هم همکاري مي کنند تا نتيجه اي بدست آيد. نکته: - معمولا رابطه Use Case و Collaboration يک به يک است. - اگر Use Case کلي تر باشد ميتواند به چند Collaboration تجزيه شود( رابطه کلي = 1به n ) - 1 Use Case --- 0 … n Collaboration - 1 Collaboration --- 1 … n Class • 1 Class --- 1 … n Collaboration - در Rational Rose از نام Use Case Realization استفاده ميشود.

19. Basic Building Blocks - structural things 5- Active Class تعريف: کلاسي که از ديدگاه کاربر نهايي خودکار اجرا ميشود و کنترل فعاليتهايش را خودش بر عهده دارد نه مثل کلاس عادي که با درخواست کلاس ديگر سرويسي ارائه کند. نکته: - معمولا برنامه هاي سيستمي مانند سيستم عامل و سيستم مديريت پايگاه داده، سرويسهايي از نوع Active Class دارند.

20. Basic Building Blocks - structural things 6- Component تعريف: يک عنصر فيزيکي و با قابليت جايگزيني که مجموعه اي از Interface را پشتيباني مي کند.

21. Basic Building Blocks - structural things 7- Node تعريف:عنصر سخت افزاری که امکان پردازش دارد.

22. Basic Building Blocks – Behavioral thing 1- Message تعريف: فراخواني Operation از شيء يک کلاس

23. Basic Building Blocks – Behavioral thing 2- State Machine تعريف: وضعيت های مختلف يک شيء را نشان ميدهد. متشکل از چهار جزء است: 1- State 2- Event 3- Response 4- شيء

24. Basic Building Blocks – Grouping Thing 1- Package تعريف: نوعي گروه بندي منطقي است که هر جزيي را شامل مي شود. Packageها داراي ساختار سلسله مراتبي هستند و ميتوانند تودرتو باشند.

25. Basic Building Blocks – Annotational Thing 1- Note تعريف:توضيحات درباره دياگرام ها و اجزاء آنها در Rational Rose می توان از گزينه هاي Document Window و Attach File نيز استفاده کرد.

26. Relationships 1- Association تعريف:رابطه ساختاري بين کلاس ها • a relationship between classes indicates some meaningful and interesting connection • a structural relationship that describes a set of links, a link being a connection between objects.

27. Relationships 1- Association Association Notation:

28. Relationships 1- Association Multiplicity:Multiplicity A defines how many instances of type A can be associated with one instance of type B at some point • حالت ها مختلف برای Multiplicity : • Exactly one - 1 • Zero or one - 0..1 • Many - 0..* or * • One or more - 1..* • Exact Number - e.g. 3..4 or 6 • Or a complex relationship – e.g. 0..1, 3..4,6..* would mean any number of objects other than 2 or 5 Game Player 1 2..6 Mother Child 1 1..* performs-in Actor Film * *

29. Relationships 1- Association Multiplicity:

30. Relationships 1- Association Aggregation: A Special Kind of Association تعريف: - Aggregation: whole/part relationships, Instances on one side are aggregates (or wholes) and the instances on the other side are their parts. - An association that models HAS-A relationships - The objects can exist independently or each other - No one object is more important than the other - An Aggregation relationship may be called isPartOf or consistsOF. School Student 1 0..*

31. Relationships 1- Association Composition: A Special Kind of Association تعريف: - Composition: Strangle relationship, If the parts in the part-whole relationship are non-shareable. - One can not exist without the other - Composition is a anti-symmetric and transitive relation. - In aggregation relationship, the part may be included in several aggregates and its owner may also change over time. School Department 1 1..*

32. Relationships 1- Association Examples for aggregation and composition relationships:

33. Relationships 2- Dependency تعريف: رابطه استفاده کلاسي از کلاس ديگر. تغيير در کلاس B ممکن است بر روي کلاس A تاثير بگذارد. - occurs when one object depends on another - if you change one object's interface, you need to change the dependent object Directed is optional and label is optional.

34. Relationships 3- Generalization تعريف: رابطه تعميم يا رابطه is-a. در کلاس ها معني توارث مي دهد، اما براي بقيه اجزاء نيز مي تواند استفاده شود. - Objects of the Specialized element (the child) are substitutable for objects of the generalized element (the parent). - The child shares the structure and the behavior of the parent. Child class is a special case of the parent class

35. Relationships 4- Realization تعريف: رابطه تحقق يا عينيت بخشيدن. يکي از طرفين وظيفه پياده سازي طرف ديگرا را به عهده دارد. يک سمت، يک چيز واقعي و سمت ديگر چيز فرضي است. a semantic relationship between two elements, wherein one element guarantees to carry out what is expected by the other element. • Where? • Between interfaces and classes that realize them… • Between use cases and the collaborations that realize them...

36. Diagrams :Use Case تعريف: دياگرام مورد کاربرد بصورت گرافيکي رفتار سيستم را از منظر بيروني سيستم نشان مي دهد و بخشي يا تمام موارد کاربرد سيستم را نشان مي دهد. هدف: آناليز نيازمنديهاي سيستم براي اينکه نشان دهد سيستم چه کار ميکند البته توالي کار را نمايش نمي دهد. يک دياگرام مورد کاربرد عناصر زير را نشان مي دهد. 1- Actor: فرد، سيستم، خردسيستم، يا سخت افزاري که در سيستم نقش دارند. عملي را انجام داده يا نتيجه اي را دريافت ميکنند. 2- Use Case: مجموعه عملياتي که توسط Actor انجام ميشود تا نتيجه اي معيني را توليد کرده يا در اختيار Actor قرار دهد. - تعيين ”چه“ و عدم توجه به ”چگونگي“ What not How - فهرست امکانات سيستم، فهرست Use Case ها را نمايش ميدهد. - دياگرام مورد کاربرد در Use Case View کشيده ميشود. - دياگرام مورد کاربرد جزو دياگرام هايي است که جنبه ديناميکي سيستم را نشان ميدهد.

37. Diagrams :Use Case مراحل رسم نمودار مورد کاربرد: بصورت کلي در براي رسم نمودارهاي مورد کاربرد سيستم بايد سه مورد را انجام داد: -شناسايي Actor ها و ارتباط آنها -شناسايي Use Case ها و ارتباط آنها -تعيين ارتباط Actor ها و Use Case ها وظايف: 1- شناسايي Actor ها: مثال: سيستم فروش: مشتري، فروشنده، مدير فروش، سيستم حسابداري، Admin سيستم و ... 2- سازماندهي Actor ها: - گروه بندي (Packaging) - استفاده از رابطه Generalization در صورت لزوم - استفاده از Stereotype

38. Diagrams :Use Case وظايف: 3- شناسايي عمليات هر يک از Actor ها: --- > فهرست Use Case ها

39. Diagrams :Use Case وظايف: 4- سازماندهي UseCase ها: الف- استفاده از Package ب- استفاده از Stereotype ج-استفاده از Generalization

40. Diagrams :Use Case وظايف: 5- شناسايي ارتباط بين Actor ها و Use case ها: فقط رابطه Association رابطه Association در نمودار مورد کاربرد مي تواند دو طرفه باشد: - Actor کاري انجام ميدهد. - نتيجه کار انجام شده در اختيار Actor قرار مي گيرد.

41. Diagrams :Use Case وظايف: 6- شناسايي ارتباط Use case ها با کمک رابطه Dependency وقتي يک مورد کاربرد از ديگري استفاده مي کند، رابطه Dependency بين آنها برقرار است. جهت رابطه مهم است. در اين حالت دو Stereotype معروف استفاده ميشود: 1- <<include>>: عمليات B حين انجام عملياتA انجام ميشود. 2- <<Extend>>: عمليات B بصورت احتمالي (انتخاب کاربر، شرايط موجود و ...) پس از اجراي عمليات A انجام ميشود.

42. Diagrams :Use Case يک مثال براي کليه روابط ممکن در نمودار مورد کاربرد :

43. Diagrams :Activity Diagram تعريف: An Activity diagram shows the flow from activity to activity. An Activity is an ongoing nonatomic execution with in state machine. Activity result in some actions با استفاده از نمودار فعاليت ميتوان جريانهاي کاري را درسطوح مختلفي از سيستم مدل کرد. - جريان کاري در فرايند کل سيستم. - جريان کاري در فرآيند زير سيستم ها - جريان کاري در سطح موارد کاربرد (سناريوها) - جريان کاري در سطح کلاس ( يک متد از کلاس) - جنبه ديناميکي سيستم را مدل مي کند و اساسا مانند فلوچارت ميباشد. - براي مدل کردن جريانهاي کاري در سطح سيستم يا زيرسيستم ها بهتر است از نام موارد کاربرد براي نام فعاليتها استفاده کرد. - نمودارهاي Activity Diagram و ُStatechart با هم معادل هستند و هر دو حالت خاص از State Machine ها هستند. - Activity Diagram: Activity Centric Statechart: State Centric - Statechart براي مدل کردن رفتار Object در طول حيات آن استفاده ميشود.

44. Diagrams : Activity Diagram Elements: 1- Activity State: يک فعاليت طولاني و قابل اينتراپت که ممکن خردفعاليتهاي ديگري داشته باشد. 2- Action State: يک فعاليت کوتاه که حالت اتميک دارد. مانند يک Method Call يا Pure Computation در Rational Rose ميتوان درون State ها، Action هاي مربوطه را مشخص کرد. ضمنا در RR بجاي Activity State از نام Activity استفاده ميشود. َActivity: represents the performance of task or duty in a workflow. State: represents a condition or situation during the life of an object during which it satisfies some condition or waits for some event.

45. Diagrams : Activity Diagram Elements: در RR درون هريک از Activity ها يا State ها ميتوان Action تعريف کرد که در حالات زير اتفاق مي افتند. ·on entry: the task must be performed when the object enters the state or activity ·onexit: the task must be performed when the object exits the state or activity ·do: the task must be performed while in the state or activity until existing ·on event: the task triggers an action only if a specific event is received. 3- Start/End State: - حالت شروع فقط يکي - حالت پايان 0 تا n عدد

46. Diagrams : Activity Diagram Elements: 4- Transition: انتقال از فعاليت يا حالتي به فعاليت يا حالت ديگر. دو نوع دارد: - Trigger less: با اتمام عمل (فعاليت) قبلی، عمل بعدي شروع ميشود. بيشتر براي انتقال از Activity به Activity - Guarded: با کنترل شرط عمل بعدي آغاز ميشود. بيشتر براي انتقال از يک State 4- Branch Decision:زماني استفاده ميشود که مسير Transition بنابر حالات مختلف (Guard Conditions) فرق کند. پس شرط بر روي Transition گذاشته مي شود نه بر روي Decision.

47. Diagrams : Activity Diagram Elements: 4- Fork & Join(Synchronization): تعريف Fork: تقسيم کنترل يک جريان کاري به دو يا چند جريان کاري همزمان. (شروع عمليات همزمان) تعريف Join: يکي کردن دو يا چند جريان کاري به يک جريان کاري. (خاتمه همه عمليات هاي همزمان) در RR اين دو را با استفاده از Synchronization انجام مي دهيم. که داراي دو نوع افقي و عمودي است. - بايد در Swimlane هاي مختلف صورت بگيرد. - تعداد Fork ها و Join ها بايد متوازن باشند. - Activity هاي موازي الزاما مستقل نيستند و احتمال عمليات همزمان وجود دارد که اصطلاحا آنها را Co-Routine مي گويند. ميتوان با Object Flow آنها را نشان داد.

48. Diagrams : Activity Diagram Elements: 5- Swimlane: تعريف: براي جداسازي و تفکيک وظايف استفاده ميشود. - معمولا در مدلسازي Business براي تفکيک وظايف و مسئوليتها در جريان هاي کاري استفاده ميشود. - هر Swimlane ميتواند نام يک Actor، يک کلاس، يک Object، نقش يک کلاس، زيرسيستم ها، واحدهاي ومختلف سازمان و ... باشد که نشان ميدهد آن فعاليت را چه کسي انجام ميدهد. - در Statechart ظاهر نميشود. - بخش هاي مختلف سازمان کانديداهاي خوبي برای Swimlane ها هستند. (وظايف هر بخش و ارتباط بخش ها را نشان ميدهد)

49. Diagrams : Activity Diagram Activity Diagram Use Case Sample:

50. Diagrams : Class Diagram Definition: A class diagram is a diagram that shows a set of classes, and collaborations and their relationships - Class diagrams contain classes and object diagrams contain objects - Class diagrams are more prevalent than object diagrams. Normally you will build class diagrams plus occasional object diagrams illustrating complicated data structures - عمدتا در قسمت Logical view تهيه ميشود. جزو Structural Modeling ميباشد و جنبه Static سيستم را مدل ميکند. - در RR توصيه ميشود که دياگرام کلاس در سطح کل سيستم و نيز در سطح Package هاي منطقي تهيه شود. Use Class Diagrams To: Analysis: Show common roles and responsibilities of the entities that provide the system's behavior. Design:Capture the structure of the classes that form the system's architecture.