UNIT 2 Object Oriented Analysis and Design with

UNIT 2 Object Oriented Analysis and Design with UML 1

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 2

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

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

UNIT 2 The Unified Modelling Language 5

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

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

Unified Modeling Language 4 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 4 To end the OO method wars – Lack of standardization : every method, tool, practice has their own set of symbols and terminology 4 Became the formal and de facto standard 8

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

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

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

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

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

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

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

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

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

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

Use-Case Diagram 19

Class Diagram 20

Object Diagram 21

State Diagram 22

Sequence Diagram 23

Collaboration Diagram 24

Activity Diagram 25

Component Diagram 26

Deployment Diagram 27

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 28

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

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

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

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

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

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

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

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

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

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

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

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

Parts of a Use Case Diagram. . . 4 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 ! 41

Parts of a Use Case Diagram. . . 4 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 42

Parts of a Use Case Diagram. 4 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 43

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

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

Describing a Use Case… 4 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 46

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? 47

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

Relationships. . . 4 Uses relationship – The entire use case is used 49

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

Example : Recycling Machine. . . Print Daily Report Return Item Customer Change Item Data Operator 51

Example : Recycling Machine. . . When the customer returns a deposit item, it is measured by the system. Return Item IF accepted, the customer’s total is incremented and. . IF the item is rejected. . . The following information is printed on a receipt form: name, number returned, . . . 52

Example : Recycling Machine. Return Item extends Item stuck When an item gets stuck, the alarm is activated to call the operator. When the Operator has removed the stuck item he resets the alarm and the Customer can continu to return items. 53

Summary 4 A technique to describe the functional requirements of a system 4 Described in terms of external actors, use cases and the system modeled 4 Use cases can be related to each other : extended, used, grouped. 54

Unit 2 : Outline 4 The History of the UML 4 General overview of the UML 4 Use Case Diagram 4 Class Diagram 55

Class Diagrams 4 Perspectives – Conceptual • No relation with the software – Specification • Interfaces of the software – Implementation • The real classes 56

Class Diagrams 4 Static model type – A view of the system in terms of classes and relationships (associations – subtypes - …) 4 Classes not only describe information but also behaviour ! 4 Description of object types. Attributes and behaviour of a type of objects – All objects are instances of a certain class 57

Examples of Classes… 4 In business and information systems : – Customer – Agreement – Invoice – Debt – Asset – Quotation 58

Examples of Classes… 4 In technical systems – Sensor – Display – I/O card – Engine – Button – Control class 59

Examples of Classes. 4 In system software : – File – Executable program – Device – Icon – Window – Scrollbar à Actually everything that has certain properties and behaviour 60

A Class in UML… 4 A rectangle divided into 3 compartments : – name, attributes, operations 61

A Class in UML… 4 The name compartment – Starts with an uppercase – Boldface – Most of the time a noun 62

A Class in UML… 4 The attributes compartment – Starts with a lowercase – Has a type e. g. String, Integer, … – Has a visibility (language depended) • public (+), private (-), protected (#) – Default values can be specified – Allowed values can be specified ({. . . }) – Class scope is possible (underlined) 63

A Class in UML… 64

A Class in UML… Public class Invoice { public double amount; public Date date = new Date(); public String customer; static private int number_of_invoices = 0; // Constructor, called every time an object is created public Invoice() { // Other initialization number_of_invoices++; //increment the class attribute } // Other methods go here }; 65

A Class in UML… 4 The operation compartment : – Contains the signature of the operation • a return type • a name • zero or more parameters – Has a visibility • public (+), private (-), protected (#) 66

A Class in UML… 67

A Class in UML. Public class Figure { private int x = 0; private int y = 0; public void draw() { // Java code for drawing the figure } }; 68

Finding Classes 4 Do we have information that should be stored or analysed? 4 Do we have an external system? 4 Do we have any patterns, class libraries, components from earlier projects? 4 Are there devices that the system should handle? 4 Do we have organizational parts? 4 Which roles do the actors play? à Information comes from requirements ! 69

Relationships Between Classes 4 An association is a connection between classes 4 A generalization is a relationship between a more general and a more specific element 4 A dependency is a relationship between elements, one independent another dependent 4 A refinement is a relationship between two descriptions of the same thing but at different levels of abstraction 70

Association Relationship… 4 Normally bidirectional 4 Could contain multiplicity – a range that tells us how many objects are linked Association name Association direction 71

Association Relationship… Multiplicities A Person Owns 0 or many Cars A Car is Owned by 1 or many Persons 72

Associations Insurance policy 0. . 1 1 has refers to 0. . * is expressed in an expressed an Insurance company Insurance contract 0. . * has refers to 1. . * Customer 73

Recursive Associations 4 Connecting a class to itself 74

Roles in Associations Insurance policy 4 Specifies the context Insurance company 1 has 0. . * refers to is expressed in an expressed an Insurance contract 0. . * 1. . * has refers to of a class and its objects. 4 Role names are part of the association not of the class 0. . 1 policyholder wife Person husband married to 75

Qualified Associations 4 Specifies how a certain object at the many end is identified (+/- a key) A Canvas contains many Figures which are identified by a figure id 76

‘OR’ Associations 4 In some models not all combinations are valid An Insurance contract belongs to a Person OR a Company 77

Ordered Association 78

Association Classes The class Queue is needed for the association 79

Ternary Associations 80

Aggregation 4 A part-off association 4 What is the difference with an association ? 4 Only use it when it is clear why you use it ! 81

Composition 4 Stronger variety of aggregation 4 The parts can only exist if the whole exists ) 3 / 1 ( n o i t a t o N 82

Composition Aggregation… ) 3 / 2 ( tion Nota 83

Composition Aggregation. ) 3 / 3 ( tion Nota 84

Generalization… 4 Inheritance, ‘is-a’ relationship 4 The more specific may be used where the more general is allowed 4 Private vs. protected Remember : Using Inheritance for code reuse, or just because it looks nice is a dangerous practice ! 85

Generalization. 4 Abstract classes & Polymorphism gh u o r h t d e t a g t i n l i i d c n a i F B c i m Dyna 86

General Example ite s o p m o C. r rn e t Cf t a P n g i s De 87

Dependency Relationship Class A depends on Class B (important to know for maintainability) 88

Refinement Relationship A Design Class is a refinement of an Analysis Class (important to know for abstraction levels) 89

Extensibility of UML. . . 4 Stereotypes – Allows to define a new kind of model element based on an existing one – Basically adds extra semantics – There are predefined stereotypes in UML • simplicity ! Stereotype name Stereotype icon 90

Extensibility of UML (2) 4 Tagged values – Name-value pairs of information – Hold additional information about elements 4 Constraints – Restrictions that limit the usage of an element or the semantics of an element 91