Object Oriented Analysis and Design with UML

1. UNIT 2 Object OrientedAnalysis and Designwith UML

2. Summary Unit 1... Object-Oriented Approach • Is structured in terms of • Objects (state + behaviour + identity) • Messages • Methods • Supports sharing through • Classes and instances • Class hierarchies

3. Summary Unit 1... • Object-Oriented Techniques • Are based on • Encapsulating data and procedures • Inheritance • Polymorphism • Facilitate • Modularity • Reusability and sharing • Extensibility and change (maintainability)

4. Summary Unit 1. Problem Need for a Strategy Analysis Design Implementation Testing Exploitation Maintenance

5. UNIT 2 TheUnifiedModellingLanguage

6. Unit 2 : Outline • The History of the UML • General overview of the UML • Use Case Diagram • Class Diagram

7. Unit 2 : Outline • The History of the UML • General overview of the UML • Use Case Diagram • Class Diagram

8. Unified Modeling Language • Designed by G. Booch, J. Rumbaugh, I. Jacobson (3 amigos) • Started in 1994, version 1.0 finished in 1997 • They put aside their own methods and notations • To end the OO method wars • Lack of standardization : every method, tool, practice has their own set of symbols and terminology • Became the formal and de facto standard

9. The Evolution of UML Nov ‘97 UML approved by the OMG

10. HP Fusion Meyer Booch Operation descriptions and message numbering Before and after conditions Booch method Rumbaugh Embley Harel OMT Singleton classes and high-level view Statecharts Gamma, et al Wirfs-Brock Frameworks and patterns, Responsibilities Odell Shlaer - Mellor Jacobson Classification Object lifecycles OOSE Contributions to the UML

11. Unit 2 : Outline • The History of the UML • General overview of the UML • Use Case Diagram • Class Diagram

12. Why would you use UML • To learn OO • CRC cards Class-Responsibility-Collaboration • Class diagrams • Interaction diagrams • Design patterns • Communicate with domain experts • Use cases • Class diagrams (conceptual) • Activity diagrams

13. General Goals of UML • Model systems using OO concepts Information Systems System Software Real-time Systems Software Systems Distributed Systems Business Systems Technical Systems … • Establish an explicit coupling to conceptual as well as executable artefacts • To create a modelling language usable by both humans and machines

14. Different Types of Systems… • Information Systems • Store, retrieve, transform, present information to users • Large amounts of data, complex relationships, stored in databases • Technical Systems • Handle, control technical equipment • Special interfaces e.g. for telecommunications, military systems, industrial processes • Real-time

15. Different Types of Systems… • Embedded Real-Time Systems • Execute on simple hardware, e.g. mobile phone, vcr, microwave oven • Distributed Systems • Synchronize communication, ensure data integrity, security • CORBA, DOM/DCOM

16. Different Types of Systems… • System Software • Operating systems, DBMS, low level operations on HW • Business Systems • Describes goals, resources, rules, actual work in a business process

17. Different Types of Systems. • Combinations are possible • UML can be used to model all of these systems Even more : UML is described in UML

18. UML Diagrams... • Use-Case diagram • Class diagram • Object diagram • State diagram • Sequence diagram • Collaboration diagram • Activity diagram • Component diagram • Deployment diagram

19. Use-Case Diagram

20. Class Diagram

21. Object Diagram

22. State Diagram

23. Sequence Diagram

24. Collaboration Diagram

25. Activity Diagram

26. Component Diagram

27. Deployment Diagram

28. UML Views… • Each view is a projection of the complete system • Each view highlights particular aspects of the system • Views are described by a number of diagrams • No strict separation, so a diagram can be part of more than one view

29. UML Views… Logical View Component View Use Case View Deployment View Concurrency View

30. Use Case View… • Shows the functionality of the system as perceived by external actors • Actors can be users or other systems • Described by use case and activity diagrams • The central view which drives the development and planning of other views • Used by customers, designers, developers, testers

31. Logical View… • Shows how the functionality of the system is designed / provided • Uses class and object diagrams to represent the static structure • Uses state, sequence, collaboration, and activity diagrams for dynamic behaviour • Used by designers and developers

32. Component View… • Shows the organization of the code components and their dependencies • Described by component diagrams • Used by developers

33. Concurrency View… • Addresses the problems with communication and synchronization for a concurrent system • Described by state, sequence, collaboration, activity, deployment, and component diagrams • Used by developers and system integrators

34. Deployment View. • Shows the deployment of the system into the physical architecture with computers and devices • Represented by the deployment diagram • Used by developers, system integrators, and testers

35. A Process for Making Models... Use informal tools: - Whiteboard - Post-it notes Brainstorming Sketching Input Knowledge, Experience, Problem Description, Goals, … Organize the informal sketch in a tool to produce a formal diagram Organizing Specify the details of the diagram, as more and more is learned (iterative) Specifying

36. Check the diagram , verify/validate against req. Make a prototype and test… Evaluate result go back and correct any deficiencies A Process for Making Models. Integrating Verifying Validating Prototyped & Tested Evaluate

37. Unit 2 : Outline • The History of the UML • General overview of the UML • Use Case Diagram • Class Diagram

38. Primary Purpose • Decide and describe functional requirements • Resulting in an agreement and planning • Clear description of what the system should do • Looks at the system as a black box • Used throughout entire development • Communication of requirements to all developers • Basis for design, system tests, verification

39. Who has Interest in Use Cases? • Customers and end users • Specification of the functionality of the system and how it can and will be used • Developers • Understanding of what the system should do and a foundation for future work • System integrators and testers • Basis to check wether the system performs as required • Anyone involved in activities of the system Very Informal Formal Very Formal

40. Parts of a Use Case Diagram... • The system • The actors • The use cases

41. Parts of a Use Case Diagram... • The system • Could be any system, not just SW systems • Define clear and precise boundaries • Don’t be too ambitious - think small ! • Identify the basic functionality and concentrate on defining a stable and well-defined system architecture • More functionality can always be added in future versions • Compile a catalog of central concepts or entities and describe them !

42. Parts of a Use Case Diagram... • The actors • Who or what uses the system • Represents a role, not an individual user of the system ! • Communicates with the system by sending and receiving messages • Actors are in control and initiate actions • Actors can be ranked : • Primary and secondary actors

43. Parts of a Use Case Diagram. • Use cases • A set of sequences of actions a system performs • A textual description ! • Always initiated by an actor • Always delivers an observable result of value to an actor • ”receive a bill for service” ? • A use case is connected to an actor through associations • Normally undirected one-to-one relations

44. Steps for Building a Use Case Model • Define the boundaries of the system • Divide into subsystems • Find the actors and use cases • For big systems define the actors first • Define the relationships between the use cases • extends • uses • Validate and verify the model • Highly interactive with the end users ! • Should include discussions

45. How to Find Actors ? • Who will use the main functionality of the system? • Who will need support from the system to do their daily tasks? • Who needs to maintain, administrate and keep the system working? • Which HW devices does the system need to handle? • With which other systems does the system interact? • Who or what has an interest in the produced results?

46. Describing a Use Case… • Use cases are goal oriented ! • What is it trying to achieve • Which functions does the actor require, what does he need to do? • Which actor initiates the use case and in which situations? • Which messages or events are necessary

47. Describing a Use Case. • What is the flow of messages between actors and the use case? • Depends on conditions and exceptions • Be cautious : don’t be too detailed • Specific exceptions can be clarified by scenarios • Which entities are modified and/or used? • When is the use case considered to be finished and what kind of value is delivered to the actor?

48. Relationships... • Extends relationship • The extension may use parts of the generalization • Difficult to define thereused parts • Use cases are written in natural language ! Signing Insurance Policy «extends» Client under 21

49. Relationships... • Uses relationship • The entire use case is used

50. Relationships. • Grouping into a package • Use cases with similar or related functionality can be grouped (cfr Java packages)