Object Oriented Analysis and Design with UML

1
Object OrientedAnalysis and Designwith UML
UNIT 2
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
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
Technical Systems
Business 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
Component View
Logical 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
A Process for Making Models.
Verifying
Integrating
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
• Dont 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 dont 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)

51
Example Recycling Machine...
Print Daily Report
Return Item
Change Item Data
52
Example Recycling Machine...
When the customer returns a deposit item, it is
measured by the system. IF accepted, the
customers total is incremented and .... IF the
item is rejected ... The following information is
printed on a receipt form name, number returned,
...
Return Item
53
Example Recycling Machine.
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.
Return Item
extends
Item stuck
54
Summary

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

55
Unit 2 Outline

• The History of the UML
• General overview of the UML
• Use Case Diagram
• Class Diagram

56
Class Diagrams

• Perspectives
• Conceptual
• No relation with the software
• Specification
• Interfaces of the software
• Implementation
• The real classes

57
Class Diagrams

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

58
Examples of Classes

• In business and information systems
• Customer
• Agreement
• Invoice
• Debt
• Asset
• Quotation

59
Examples of Classes

• In technical systems
• Sensor
• Display
• I/O card
• Engine
• Button
• Control class

60
Examples of Classes.

• In system software
• File
• Executable program
• Device
• Icon
• Window
• Scrollbar
• Actually everything that has certain properties
  and behaviour

61
A Class in UML

• A rectangle divided into 3 compartments
• name, attributes, operations

62
A Class in UML

• The name compartment
• Starts with an uppercase
• Boldface
• Most of the time a noun

63
A Class in UML

• 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)

64
A Class in UML
65
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

66
A Class in UML

• The operation compartment
• Contains the signature of the operation
• a return type
• a name
• zero or more parameters
• Has a visibility
• public (), private (-), protected ()

67
A Class in UML
68
A Class in UML.

• Public class Figure
• private int x 0
• private int y 0
• public void draw()
• // Java code for drawing the figure

69
Finding Classes

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

70
Relationships Between Classes

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

71
Association Relationship

• Normally bidirectional
• Could contain multiplicity
• a range that tells us how many objects are linked

Association name
Association direction
Association
72
Association Relationship
Multiplicities
A Person Owns 0 or many CarsA Car is Owned by 1
or many Persons
73
Associations
Insurance
policy
0..1
expressed an
is expressed in an
0..
1
has
Insurance
Insurance
contract
company
refers to
0..
refers to
has
1..
Customer
74
Recursive Associations

• Connecting a class to itself

75
Roles in Associations
Insurance

• Specifies the contextof a class and its
  objects.
• Role names arepart of the association not of
  the class

policy
0..1
expressed an
is expressed in an
0..
1
has
Insurance
Insurance
contract
company
refers to
0..
refers to
has
1..
policyholder
wife
Person
husband
married to
76
Qualified Associations

• 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
77
OR Associations

• In some models not all combinations are valid

An Insurance contract belongs to a Person OR a
Company
78
Ordered Association
79
Association Classes
The class Queue is needed for the association
80
Ternary Associations
81
Aggregation

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

82
Composition

• Stronger variety of aggregation
• The parts can only exist if the whole exists

Notation (1/3)
83
Composition Aggregation
Notation (2/3)
84
Composition Aggregation.
Notation (3/3)
85
Generalization

• Inheritance, is-a relationship
• The more specific may be used where the more
  general is allowed
• Private vs. protected

Remember Using Inheritance for code reuse, or
just because it looks nice is a dangerous
practice !
86
Generalization.

• Abstract classes Polymorphism

Facilitated through Dynamic Binding
87
General Example
Cfr. Composite Design Pattern
88
Dependency Relationship
Class A depends on Class B (important to know for
maintainability)
89
Refinement Relationship
A Design Class is a refinement of an Analysis
Class (important to know for abstraction levels)
90
Extensibility of UML...

• 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
91
Extensibility of UML (2)

• Tagged values
• Name-value pairs of information
• Hold additional information about elements
• Constraints
• Restrictions that limit the usage of an element
  or the semantics of an element