Unified Modeling Language UML

1
Unified Modeling LanguageUML
2
Unified Modeling Language

• Is a notation
• Is a meta-model
• Is not a software process or method
• A meta-model is a rigorous definition of the
  notation and the rules governing relationships
  between its components

3
Tools of UML

• Class Diagrams
• Use Cases
• Interaction Diagrams
• Sequence Diagrams
• Collaboration Diagrams
• Package Diagrams
• State Diagrams
• Activity Diagrams
• Deployment Diagrams

4
Dependency

• A dependency is a relationship which indicates
  that a change in specification of one thing may
  affect another thing that uses it, but not
  necessarily the reverse
• Use dependency when you want to show one thing
  using another
• Often used to show that one class uses another as
  an argument to one of its operations

Event
Window
5
Constraints

• The elements of a class diagram (associations,
  attributes and generalization, etc.) are
  effectively placing constraints on the system
• e.g. an order must have a customer
• Other constraints are often necessary
• Place these constraints inside
• At the conceptual level, use simple statements
• Constraints are ideally implemented as assertions
• ordered and abstract are common constraints

6
Stereotypes

• Is a general extension mechanism for the UML
• Stereotypes are shown between ltlt gtgt
• A stereotype outlines certain responsibilities
  that a class will undertake

DataInput
ltltinterfacegtgt
7
Class
Class Name
8
Attributes and Operations

• We can choose to show various aspects of the
  classes
• At a conceptual level we have
• Attributes which indicate which data a class is
  going to keep conceptually
• Operations which indicate the responsibilities of
  a class

Customer
Class Name
Attributes are always single-valued at the
conceptual level and are small, simple
data types
name address
Attributes
creditRating
Operations
9
Associations

• The uses_a relationship
• Represent conceptual relationships between
  classes
• Each association has two roles
• A role has a direction on the association
• Customer to Order role
• Order to Customer role
• Each role can be explicitly named, if not named,
  then the role is called after the target class,
  i.e. the role from Order to Customer is called
  Customer
• Association should be named if it adds to
  understanding

10
Associations
Class Name
Class Name
Association Name
Role-1
Role-2
Association Name
Class Name
Class Name
qualifier
Role-1
Role-2
11
Multiplicity of Associations
Class Name
Exactly one
Class Name
Many (zero or more)
Class Name
Many (zero or one)
Class Name
1
One or more
1-2, 4
Class Name
Numerically specified
12
Generalization

• The is_a relationship
• Classification (Generalization or Specialization)
• Connections represents the hierarchy
• Employee is a specialization of person
• Vehicle is a generalization of car

13
Generalization(Inheritance)
14
Whole/Part Associations

• UML has special notation for two whole/part
  associations
• composition and aggregation
• There is disagreement about the exact meanings of
  these terms
• Coad and Yourdon - an organisation is an
  aggregation of its employees
• Rumbaugh - an organisation is not an aggregation
  of its employees
• The important thing is to choose a convention and
  be consistent

15
Aggregation

• The consists_of relationship
• Aggregation or Assembly
• Connections specify components and assemblies
• A car is made up of seats, doors, body etc. a
  flock is an aggregate of sheep
• Aggregation is a group/member association
• Three most important characteristics
• The aggregate object may potentially exist
  without its constituent objects (not always
  useful though)
• At any time, each object may be a constituent of
  more than one aggregate (e.g. a person may belong
  to several clubs)
• Constituent objects are typically of the same
  class

16
Aggregation
17
Composition

• Composition is a common structure in software
  systems, because many composite objects appear in
  real life
• a dog is a composite of a head, a body, a tail
  and 4 legs
• an email is composed of a header and a text
  message the header is composed of a From line a
  To line, etc.
• Three most important characteristics
• The composite object does not exists without its
  components
• At any time, each component may be part of only
  one composite
• Component objects are likely to be of mixed types

18
Aggregation(Composition)
19
Ordering
Usually the objects on the many side of an
association have no explicit order, and can be
regarded as a set. The use of ordered means
that the objects are explicitly ordered.
20
Link Attribute
21
Ternary Association
22
Association as Class

• Allow you to add attributes, operations and other
  features to associations
• Can only be one instance of the association
  between any two participating objects

23
Association as Class
24
Abstract Operation
Operation is abstract in the superclass.
Subclasses must provide concrete implementations
of operation.
25
Object Instances
(Class Name)
(Class Name) attribute_name value ...
26
Instantiation Relationships
(Class Name)
Class Name
27
Class Diagrams
28
Class Diagrams

• Initial use is to provide a conceptual model of
  the system
• A class diagram shows
• Concepts
• Associations between concepts
• Attributes and methods
• Initially (conceptual level)
• Not a model of the software design
• Shows real world concepts
• Better to over-specify than to under-specify

29
A Class Diagram
Multiplicity
mandatory
Order
dateReceived
Customer
isPrepaid
name
1
0..
1
0..
number String
Class
address
price Money
creditRating () String
dispatch( )
Association
close( )
Generalization
1
1
Role name
Attributes
Corporate Customer
Personal Customer
contactName
line items
1..
1..
creditCardNumber
creditRating
creditLimit
OrderLine
quantity Integer
creditRating "poor"
remind( )
price Money
billForMonth( )
isSatisfied Boolean
Operations




Multiplicity
optional
0..1
0..1
1
1
sales rep
Multiplicity
many-valued
Product
Employee
30
Use-Cases
31
Requirements Capture

• Requirements elicitation
• important to spend time with users
• Requirements analysis
• Use Case Catalogue
• Use Case Descriptions
• Object Interaction Diagram
• Object Model
• Dynamic model

32
Use-Case Diagrams

• Use Cases - business processes
• A use case is a sequence of transactions in a
  system whose task is to yield a result of
  measurable value to an individual actor of the
  system
• External view of the system
• Actors - the external environment
• e.g. customers, suppliers, chef, accountant

33
Use Cases

• A Use Case is a narrative document that describes
  the sequence of events of an actor using a system
  to complete a process
• Properties of a Use Case
• it captures some user-visible function
• a use case is a relatively large end-to-end
  process
• it achieves some discrete goal for the user
• You need some understanding of the requirements
  before starting to develop your use cases
• Use cases are not really OO

34
Components of a Use Case

• NAME - start with a verb to emphasise that it is
  a process
• ACTOR - is a role that a user plays in respect
  to the system. Actors are generally shown when
  they are the ones who need the use case
• TYPE
• Primary - represent major common processes
• Secondary - represent minor or rare processes
• Optional - processes that may not be implemented
  in the system depending upon resources
• DESCRIPTION - short and essential

35
Identifying Use Cases

• Using the actors
• Identify the actors related to a system or
  organisation
• For each actor, identify the processes they
  initiate or participate in
• Using events
• Identify the external events that a system must
  respond to
• Relate the events to actors and use cases

36
Use Case Diagrams

• Illustrates a set of use cases for a system, the
  actors and the relationships between actors and
  use cases.
• Each use case diagram is for a particular subject
  area

Association between a use case and an actor
Icon for a use case
Icon for an actor
37
A Simple Use Case Diagram
38
Organizing Use Cases

• In many situations we find that use cases are
  very similar
• We need mechanisms to handle these similarities
• Three mechanisms in the UML
• Generalization
• Includes
• Extends

39
Generalisation

• This means that a child use case inherits the
  behaviour and meaning of the parent use case
• The child may add or override the behaviour of
  the parent
• The child may be substituted in any place the
  parent may appear in the system
• Generalization appears as

Parent Use Case
Child Use Case
40
Example of Generalisation in a Use Case Diagram
Check Password
Validate User
Retinal Scan
41
Includes

• This means that a particular use case explicitly
  incorporates the behaviour of another use case at
  a location specified in that use case
• An include use case never stands alone
• An include relationship is used to avoid
  describing the same flow of events several times,
  by putting the common behaviour in a use case of
  its own
• include appears as

ltltincludesgtgt
42
Example of Include in a Use Case Diagram
Place Order
ltltincludegtgt
Track Order
Validate User
ltltincludegtgt
43
Example of Include in a Track Order Use Case
Actor Action 1. Input order number Include
(Validate User) System Response 2. Verify Order
Number 3. For each part in the order, query its
status 4. Report back to user
Note includes should also be mentioned in the
overview section of the Use Case
44
Extends

• Extends is used to separate optional behaviour
  from mandatory behaviour
• The base use case implicitly incorporates the
  behaviour of another use case at a location
  specified indirectly by the extending use case
• The base use case may stand alone, but under
  certain conditions, it may be extended by another
  use case.
• It may be extended only at certain points known
  as extension points
• Extends appears

ltltextendsgtgt
45
Example of Extends in a Use Case Diagram
ltltextendsgtgt (set priority)
Place Order Extension Points Set Priority
Place Rush Order
46
Example of Extends in a Use Case
Actor Action 1. Ask for order to be placed System
Response 2. Verify customer details. Include
(Validate User) 3. Collect the users order
items. (set priority) 4. Submit order for
processing
Note extends should also be mentioned in the
overview section of the Use Case