Uml

Software Engineering
UNIFIED MODELLING
LANGUAGE (UML)
Dr Adel Taweel
UML: Unified Modelling Language
Objectives
To explain unified modelling language as object
modelling tools.
To describe
Different
types of UML diagrams
UML modelling techniques/tools and their use
Dr Adel Taweel 2014

2

Covering!!
3

Dr Adel Taweel 2014

3

A tool for
4

Dr Adel Taweel 2014

4

The Unified Modelling Language
5

Several different notations for describing object

oriented designs were proposed in the 1980s and
1990s.
The Unified Modelling Language is an integration
of these notations.
It describes notations for a number of different
models that may be produced during OO analysis
and design.
It is now a de facto standard for OO modelling.
Dr Adel Taweel 2014

5

UML
Unified Modelling Language

Visualising and documenting analysis
and design effort.
Unified because it
Combines main preceding OO methods (Booch by Grady
Booch, OMT by Jim Rumbaugh and OOSE by Ivar Jacobson)
Modelling because it is
Primarily used for visually modelling systems. Many system
views are supported by different appropriate models
Language because
It offers a syntax through which to express modelled knowledge
Dr Adel Taweel 2014

6

UML Contributors
7

Dr Adel Taweel 2014

7

The Three Amigos!
Grady Booch,
Ivar Jacobson,
and Jim Rumbaugh historically and
fondly known in the UML community
as The Three Amigos are often
credited with the dominant
contribution to the Unified Modeling
Language
Dr Adel Taweel 2014
8

UML History
9

Dr Adel Taweel 2014

9

UML Diagrams
10

Dr Adel Taweel 2014

10

Models
11

The language of the designer

Representations of the system to-be-built or as
built
A complete description of a system from a
particular perspective
Tools for communication with various
stakeholders
Allow reasoning about some characteristics of a
system
Often captures both structural and behavioural
(e.g., interaction) information
Dr Adel Taweel 2014

11

UML Diagrams
12

Diagram: a view into the model

In UML, there are nine standard
diagrams
Behaviour/Interaction diagrams [Static
view ]: use case, class, object, component,
deployment
Structure diagrams [Dynamic view ]:
sequence, collaboration, state, activity
Dr Adel Taweel 2014
12

Model of UML Diagrams!
UML
UML Diagrams
Structure Diagrams Behaviour Diagrams

(Static View) (Dynamic View)
Dr Adel Taweel 2014

13

Summary of UML Diagrams (1): Structure
Use Case Diagram

Shows use cases, actors, and their interrelationships
Class Diagram
Shows a collection of static model elements such as classes and types,
their contents, and their relationships
Component Diagram
Depicts the components that compose an application, system, or
enterprise. The components, their interrelationships, interactions,
and their public interfaces are depicted
Deployment Diagram
Shows the execution architecture of systems. This includes nodes,
either hardware or software execution environments, as well as the
middleware connecting them
Object Diagram
Depicts objects and their relationships at a point in time, typically a
special case of either a class diagram or a communication diagram
Dr Adel Taweel 2014
14

Summary of UML Diagrams (2): Dynamic
Activity Diagram
Depicts high-level business processes, including data flow, or to model
the logic of complex logic within a system
Sequence Diagram
Models the sequential logic, in effect the time ordering of messages
between classifiers
Communication/Collaboration Diagram
Shows instances of classes, their interrelationships, and the message
flow between them. Communication diagrams typically focus on the
structural organization of objects that send and receive messages.
Formerly called a Collaboration Diagram
State (Machine) Diagrams Behavioral and Protocol
Describes the states an object or interaction may be in, as well as the
transitions between states. Formerly referred to as a state diagram,
state chart diagram, or a state-transition diagram. A behavioral state
machine examines the behavior of a class; a protocol state machine
illustrates the dependencies among the different interfaces of a class
Dr Adel Taweel 2014
15

Some UML Diagrams
16

Dr Adel Taweel 2014

16

UML Diagrams
17

Dr Adel Taweel 2014

17

Use Cases
18

What is use case modelling?

What are actors?
How to find actors?
What are use cases?
How to find use cases?
How to construct a use case diagram?
Detailing a use case
Dr Adel Taweel 2014

18

What is use case modelling?
19

Basis for a user-oriented approach to system
development
Identify the users of the system (actors)
Identify the tasks they must undertake with the system (use
cases)
Relate users & tasks (relationship) help identify boundary
Capture system functionality as seen by users
Dr Adel Taweel 2014

19

Use cases?
20

Built in early stages of development

Specify the context of a system
Plan iterations of development
Validate a systems architecture
Drive implementation & generate test cases
Developed by analysts & domain experts during
requirements analysis
Dr Adel Taweel 2014

20

How to identify Actors?
21

Observe direct users of the system- could be users or
systems
What role do they play?
Who provides information to the system?
Who receives information from the system?
Actors could be:
Principal
Secondary (External hardware, other systems, )
Describe each actor clearly and precisely (semantics)

Short name always a Noun
Description
Example:
BookBorrower: This actor represents some one that make
use of the library for borrowing books
Dr Adel Taweel 2014
21

Exercise!
22

Assume you have a requirements documents for a

library system: identify all actors that interact with a
system
For each actor, write down the name and provide a
brief textual description (i.e., describing the
semantics of the actor)
Dr Adel Taweel 2014

22

What are use cases?
23

Things actors do with the system

A task which an actor needs to perform with the help of a
system (e.g., Borrow a book)
A specific kind of a system
Describe the behaviour of the system from a users

standpoint
Represented by ellipses
Borrow Copy
of a book

Dr Adel Taweel 2014

23

How to find Use Cases?
24

Start with the list of actors and consider

What they need from the system (i.e. what use cases
there are which have value for them)
Any other interactions they expect to interact with the
system (i.e. which use cases they might take part in for
someones else benefit)
How do you know what is a use case?
Estimate frequency of use, examine differences between
use cases, distinguish between basic and alternative
course of events & create new uses when necessary
Dr Adel Taweel 2014

24

Describing use cases
25

Semantics should be described fully!

Always start a use case with a verb!
Borrow Copy
of a book

Example:
Use case: Borrow copy of book
A book borrower presents a book. The system checks that the
potential borrower is a member of the library & s/he does
not have the maximum number of books.
Dr Adel Taweel 2014

25

Possible use cases
26

Dr Adel Taweel 2014

26

Interaction with a System Boundary!
27

Dr Adel Taweel 2014

27

Transfer-data use case
28

A use case in the MHC-PMS
Transfer data
Medical receptionist Patient record system
Dr Adel Taweel 2014

28

Use cases for the MHC-PMS
29

Register Export
patient statistics
View Manager
personal info. Generate
Medical receptionist
report
View record
Nurse
Doctor
Edit record
Setup
consultation
Dr Adel Taweel 2014

29

Use cases in the MHC-PMS
Actor:Medical Receptionist 30

Register
patient
Unregister
patient
View patient
info.
Medical
receptionist
Transfer data
Contact
patient
Dr Adel Taweel 2014

30

Requirement Example
31

Multi-purpose recycling machine

must:
receive & check items for customers,
print out receipt for items received,
print total received items for operator,
change system information,
signal alarm when problems arise.
Reference: Anthony Finkelstein, UCL
Dr Adel Taweel 2014

31

Example: Scenario
32

Returning items is started by Customer when they want to

return cans, bottles or crates. With each item that the
Customer places in the recycling machine, the system will
increase the received number of items from the Customer
as well as the daily total of this particular type.
When a Customer has deposited all their items, they will

press a receipt button to get a receipt on which returned
items have been printed, as well as the total return sum.
or you can explain particular scenario i.e. particular instances of use would
be differente.g. morning after the party Sarah goes to the recycling with three
crates containing ....
Dr Adel Taweel 2014

32

Use case Diagram
33

Dr Adel Taweel 2014

33

Extensions
34

Extensions provide opportunities for :

optional parts
alternative complex cases
separate sub-cases
insertion of use cases
Dr Adel Taweel 2014

34

Refinement - <<extend>>
35

Dr Adel Taweel 2014

35

Refinement - <<extend>>
36

Dr Adel Taweel 2014

36

Use <<include>>
37

Use <<include>>
How the system can reuse pre-existing component
To show common functionality between use cases
To develop the fact that project from existing components!
Note: <<include>> and <<extend>>: are UML stereotypes

used to attach additional classification
Dr Adel Taweel 2014

37

Refinement - <<include>>
38

Dr Adel Taweel 2014

38

<<include>>
39

Dr Adel Taweel 2014

39

Refinement
40

Dr Adel Taweel 2014

40

Generalization
41

Dr Adel Taweel 2014

41

A generalization hierarchy
42

Doctor
Hospital General
doctor practitioner
Consultant Team doctor
Trainee Qualified
doctor doctor
Dr Adel Taweel 2014

42

A generalization hierarchy: Details
43

Doctor
Name
Phone #
Email
register ( )
de-register ( )
Hospital doctor General practitioner
Staff # Practice
Pager # Address
Dr Adel Taweel 2014

43

Detailing a use case
44

Writing a specification for the use case

Good Practice
Preconditions: the system state before the case begin (i.e.,
facts, things that must be true)
Flow of events; the steps in the use case (i.e. actions)
Postconditions: the system state after the case has been

completed
Dr Adel Taweel 2014

44

Detailing a use case: Example
45

Borrow a copy of book Borrow Copy

Precondition of a book

1. the BookBorrower is a member of the library
2. the BookBorrower has not got more than the permitted number of
books on loan
Flow of events
1. the use case starts when the BookBorrower attempts to borrow a
book
2. the librarian checks it is ok to borrow a book
3. If (indicate an alternative path of action)
Post-conditions
1. the system has updated the number of books the BookBorrower
has on loan Borrow a copy of book
Dr Adel Taweel 2014

45

Use Case Description: Example 1
46

Library System: Borrow a Copy of Book
Actors BookBorrower, Librarian
Description A BookBorrower may borrow a copy of a book from the library. A book
must exist in the library and available to borrow and will be issued by
Librarian. The status of the copy of the book will change to <on-loan>
and the loan period of the copy book will be decided by the type of the
book: ShortLoan: 2 days, MediumLoan: 2 weeks, LongLoan: 3 months.
Pre-conditions 1. the BookBorrower is a member of the library
2. the BookBorrower has not already borrowed more than the permitted
number of books on loan
Sequence/Flow of 1. the BookBorrower asks librarian to borrow a book
Events 2. the librarian checks if BookBorrow is allowed to borrow a book
3. If Yes, if No. (indicate an alternative path of action)
Data Book information, Borrow information, Book status information
Stimulus/Trigger User command issued by Librarian on behalf of BookBorrower
Post-conditions/ 1.the system has updated the number of books the BookBorrower has on
Response loan, if successful
2.Copy of book loan status updated to <on-loan>, if successful
Comments The librarian must have appropriate security permissions to access
BookBorrow information
Dr Adel Taweel 2014
46

Use Case Description: Example 2
47

Medical System: TRANSFER PATIENT DATA
Actors Medical receptionist, patient records system (PRS)
Description A receptionist may transfer data from the MHC-PMS to a general
patient record database that is maintained by a health authority. The
information transferred may either be updated personal information
(address, phone number, etc.) or a summary of the patients diagnosis
and treatment.
Pre-conditions 1. Patient is a member of the clinic
2. Patient information is access-able
Sequence/Flow of 1. the Medical receptionist select patient records to transfer
Events 2. Medical receptionist transfers selected patient records to authority
3. If successful, if not successful. (indicate an alternative path of
action)
Data Patients personal information, treatment summary
Stimulus/Trigger User command issued by medical receptionist
Post-conditions/ Confirmation that PRS has been updated
Response
Comments The receptionist must have appropriate security permissions to access
the patient information and the PRS.
Dr Adel Taweel 2014
47

Exercise
48

Select one of the use cases

identified for the library
system and create complete
specification of each
Use Structured English to
show at least one alternative
flow of events and at least
one repeated action
Dr Adel Taweel 2014

48

Scenarios
49

Each time an actor interacts with a system, the

triggered use cases instantiate a scenario
Each case corresponds to a specific path through a
use case with no branching
Scenarios are typically documented as text along
side the use case and activity diagrams
Dr Adel Taweel 2014

49

Write the scenarios for this diagram
50

Dr Adel Taweel 2014

50

Example: Borrow copy of a book
51

Scenario 1
BookBorrower Joe B borrows the librarys only
copy of Using UML, when he has no other book
on loan. The system is updated accordingly.
Scenario 2
BookBorrower Ann tries to borrow the librarys
second copy of Software Engineering, but is
refused because she has six books out on loan,
which is her maximum allowance.
Dr Adel Taweel 2014

51

UML Diagrams
52

Dr Adel Taweel 2014

52

Activity Diagram
53

Activity diagrams show the dependencies and

coordination between activities within a system
the activity flow should not get stuck
they can be used during the requirements elicitation
process
help in identifying use cases of a system and operations
involved in the realization of a use case
Workflows and business processes
Can be attached to any model element to model its
dynamic behaviour
Dr Adel Taweel 2014

53

Activity Diagram: Example
54

Dr Adel Taweel 2014

54

55

Dr Adel Taweel 2014

55

56

Dr Adel Taweel 2014

56

UML Diagrams
57

Dr Adel Taweel 2014

57

Class diagrams
58

Class diagrams are used when developing an object-

oriented system model to show the classes in a system
and the associations between these classes.
An object class can be thought of as a general
definition of one kind of system object.
An association is a link between classes that indicates
that there is some relationship between these classes.
When you are developing models during the early
stages of the software engineering process, objects
represent something in the real world, such as a
patient, a prescription, doctor, etc.
Dr Adel Taweel 2014
58

Simple Class Diagram
59

Dr Adel Taweel 2014

59

UML Class Icons
60

Dr Adel Taweel 2014

60

+, #, -
61

+ means public: public members can be accessed by

any client of the class
# means protected: protected members can be
accessed by members of the class or any subclass
- means private: private members can only be
accessed by members of the same class
Dr Adel Taweel 2014

61

Analysis Class
62

An analysis class abstracts one or more classes and/or

subsystems in the systems design
Focuses on handling functional requirements
Defines responsibilities (cohesive subsets of behaviour defined
by the class)
Defines attributes
Expresses relationships the class is involved in
Dr Adel Taweel 2014

62

Approach: Data-Driven Design
63

Identify all the data in the system

Divide into classes before considering responsibilities
Common approach: noun identification
Identify candidate classes by selecting all the nouns and noun
phrases in the requirements document
Discard inappropriate candidates
Redundant or omnipotent entities
Vague entities
Events or operations
Meta-language
Entities outside system scope
Attributes
Verbs and verb phrases highlight candidate operations!
Dr Adel Taweel 2014

63

Data-Driven Design Approach
64

Some heuristics of what kind of things are classes

[Shlaer and Mellor; Booch]
Tangible or real-world things book, copy, course;
Roles- library member, student, director of studies,
Events- arrival, leaving, request;
Interactions- meeting, intersection
Dr Adel Taweel 2014

64

Exercise
65

Perform noun-verb analysis of a requirements

document (example from next slide);
Underline all the noun and noun phrases,
Create a list of candidate classes (in examining the discard
criteria, you may also identify some candidate attributes)
Identify all verb and verb phrases
Create a list of candidate operations and assign them
to classes
Dr Adel Taweel 2014

65

Noun/Verb Analysis
66

Books and journals:

The library contains books and journals. It may have several copies of a
given book. Some of the books are for short term loans only. All other books
may be borrowed by any library member for three weeks. Members of the
library can normally borrow up to six items at a time, but members of staff
may borrow up to 12 items at one time. Only members of staff may borrow
journals.

Borrowing:
The system must keep track of when books and journals are borrowed and
returned, enforcing the rules described above.
Dr Adel Taweel 2014

66

Noun/Verb Analysis
67

Dr Adel Taweel 2014

67

First-Cut Class Diagram: Class Model
68

Dr Adel Taweel 2014

68

Relationships/Associations
69

Relationships are connections between modelling elements

Improve understanding of the domain, describing how
objects work together
Act as a sanity check for good modelling
Associations are relationships between classes
Examples
Object of class A sends a message to object of class B
Object of class A creates an object of class B
Object of class A has attribute whose values are objects of class B
Object of class A receives a message with argument of class B
Links are relationships between objects
Links can be instances of associations (as in UML 1.4)
Allow one object to invoke operations on another object
Dr Adel Taweel 2014

69

UML Relationships Notations
70

Dr Adel Taweel 2014

70

UML classes and association
71

1 1 Patient
Patient record
Dr Adel Taweel 2014

71

Links Instantiate Associations
72

Dr Adel Taweel 2014

72

Multiplicity of an Association
73

Dr Adel Taweel 2014

73

Class diagram/Model of the MHC-PMS
74

Consultant
1
referred-to
1..*
1..* 1..* 1..* 1
Condition Patient General
referred-by practitioner
diagnosed-
with 1..*
attends
1..*
prescribes
Consultation Medication
1..* 1..*
1..*
runs prescribes
1..4 Treatment
1..*
Hospital
Doctor
Dr Adel Taweel 2014
74

Generalisation and Inheritance
75

Dr Adel Taweel 2014

75

Complete class Description
76

Consultation
Doctors
Date
Time
Clinic
Reason
Medication prescribed
Treatment prescribed
Voice notes
Transcript
...
New ( )
Prescribe ( )
RecordNotes ( )
Transcribe ( )
...
Dr Adel Taweel 2014

76

Another Inheritance Example
77

Dr Adel Taweel 2014

77

Part/Whole Associations
(Aggregation) 78

a Module is part of a Course

In fact,
5 or more modules are part of one or more courses
Dr Adel Taweel 2014

78

Part/Whole Associations: Example
79

Dr Adel Taweel 2014

79

aggregation association: Example
80

Patient record
1 1
1 1..*
Patient Consultation
Dr Adel Taweel 2014

80

Association Classes
81

Used to attach attributes to an association itself

rather than the classes it associates
Class association line must have the same name!
Dr Adel Taweel 2014

81

Example: Class Model
82

Dr Adel Taweel 2014

82

Example: Class Diagram
83

Dr Adel Taweel 2014

83

Another Example
84

Classes Corporate Customer

and Personal Customer
may have some common
attributes/operations such
as name and address, but
each class has its own
attributes and operations.
The class Customer is a
general form of both the
Corporate Customer and
Personal Customer classes.
Dr Adel Taweel 2014

84

What Makes a Good Analysis Class..
85

Its name reflects its intent

It is a crisp abstraction that models one specific
element of the problem domain
It has a small but defined set of responsibilities
It has high cohesion
It has low coupling with other classes
Dr Adel Taweel 2014

85

UML Diagrams
86

Dr Adel Taweel 2014

86

Object Diagram
87

Objects are instances of Classes

Object Diagram captures objects and relationships
between then, in other words, it captures instances
of Classes and links between them.
Built during analysis & design

Illustrate data/object structures
Specify snapshots
Developed by analysts, designers and implementers
Dr Adel Taweel 2014

87

UML Object Icons
88

Dr Adel Taweel 2014

88

Object Diagram
89

Capture class instances and links between objects
Dr Adel Taweel 2014

89

Example: Object Diagram
90

Dr Adel Taweel 2014

90

UML Diagrams
91

Dr Adel Taweel 2014

91

Sequence diagrams
92

Sequence diagrams are used to model the

interactions between the actors and the objects
within a system.
A sequence diagram shows the sequence of
interactions that take place during a particular use
case or use case instance.
The objects and actors involved are listed along the
top of the diagram, with a dotted line drawn
vertically from these.
Interactions between objects are indicated by
annotated arrows.
Dr Adel Taweel 2014
92

Sequence diagrams
93

Sequence diagrams demonstrate the behaviour

of objects in a use case by describing the objects
and the messages they pass. the diagrams are
read left to right and descending.
Object interactions are arranged in a time
sequence (i.e. time-oriented)
Dr Adel Taweel 2014

93

Sequence diagram for View patient
information
94

Medical Receptionist
P: PatientInfo D: MHCPMS-DB AS: Authorization
ViewInfo (PID)
report (Info, PID,
UID)
authorize (Info,
UID)
authorization
alt
[authorization OK] Patient info
[authorization fail] Error (no access)
Dr Adel Taweel 2014

94

Sequence diagram for Transfer Data
Medical Receptionist PRS
95

P: PatientInfo D: MHCPMS-DB AS: Authorization
login ( )
ok
alt
[sendInfo]
updateInfo( ) updatePRS (UID )
authorize (TF, UID)
authorization
update (PID)
update OK
Message (OK)
[sendSummary]
UpdateSummary( )
summarize (UID )
authorize (TF, UID)
authorization
:summary
update (PID)
update OK
Message (OK)
logout ( )
Dr Adel Taweel 2014

95

Sequence diagrams
96

Dr Adel Taweel 2014

96

Sequence diagrams
97

The example shows an object of class 1 start the

behaviour by sending a message to an object of
class 2. Messages pass between the different
objects until the object of class 1 receives the
final message
Dr Adel Taweel 2014
97

Example
98

Self-service machine, three objects do the work we're

concerned with
the front: the interface the self-service machine presents to
the customer
the money register: part of the machine where moneys are
collected
the dispenser: which delivers the selected product to the
customer
Dr Adel Taweel 2014

98

Example
99

The instance sequence diagram may be sketched

by using this sequences:
1. The customer inserts money in the money slot
2. The customer makes a selection
3. The money travels to the register
4. The register checks to see whether the selected
product is in the dispenser
5. The register updates its cash reserve
6. The register has a dispenser which delivers the
product to the front of the machine
Dr Adel Taweel 2014

99

Example
100

Dr Adel Taweel 2014

100

However, note
101

We have seen an instance of an interaction

diagram- one possible sequence of messages
Since a use case can include many scenarios
There is a need to show conditional behaviour
There is a need to show possible iterations
A generic interaction diagram shows all possible

sequences of messages that can occur
Dr Adel Taweel 2014

101

Showing conditional behavior
102

A message may be guarded by a condition

Messages are only sent if the guard evaluates to
true at the time when the system reaches that
point in the interaction
Dr Adel Taweel 2014

102

alt(ernative): Operators in interactions
frames 103
UML 2.0
Dr Adel Taweel 2014

103

Iterations (i.e., loop) UML 1.0
104

* Indicates looping or iterations

i:=1..2 means 2 iterations.
Dr Adel Taweel 2014

104

Loop in UML 2.0
105

Loop: the fragment may execute multiple times, and the

guard indicates basis for iterations
Dr Adel Taweel 2014
105

Opt(ional) in UML 2.0
106

Opt: Optional; the fragment executes only if the supplied

condition is true. This is equivalent to an alt with one trace
Dr Adel Taweel 2014
106

Example/Exercise
107

Library system, three objects do the work we're

concerned with
BookBorrower: that will borrow the book
Copy: copy of abook
Librarian/LibraryStaff: which authorizes and register the

borrowing of the borrowed copy.
Dr Adel Taweel 2014

107

Sequence Diagram of a Library
System 108

Dr Adel Taweel 2014

108

UML Diagrams
109

Dr Adel Taweel 2014

109

Collaboration diagrams
110

Describe a specific scenario by showing the

movement of messages between the objects
Show a spatial organization of objects and their
interactions, rather than the sequence of the
interactions
Unlike a Sequence diagram, a collaboration diagram shows
the relationships among the objects. A collaboration
diagram does not show time (i.e., sequence)
Keep in mind:- Both are referred to as interaction diagrams
but with different focus!
Sequence diagrams message flows between objects based on time
(i.e., sequence)
Collaboration diagrams message flows between objects with no
reference to timing
Dr Adel Taweel 2014

110

Building a Collaboration Diagram
111

ATM: assume you have these objects
Dr Adel Taweel 2014

111

First: connect objects
112

Dr Adel Taweel 2014

112

Second: Draw flow of messages
113

Dr Adel Taweel 2014

113

Example- 1st:connect objects
114

Dr Adel Taweel 2014

114

Second: Draw interactions
115

Dr Adel Taweel 2014

115

UML Diagrams
116

Dr Adel Taweel 2014

116

State Diagrams
117

Also known as statecharts (invented by David Harel)

Used primarily to model state of an object
A class has at most one state machine diagram
Models how an objects reaction to a message depends on its
state
Objects of the same class may therefore receive the same message,
but respond differently
Dr Adel Taweel 2014

117

Use of State diagrams
118

Often used for modelling the behaviour of

components (subsystems) of real time and critical
systems.
Dr Adel Taweel 2014

118

Modelling states and events
119

Dr Adel Taweel 2014

119

Realising state diagrams
120

Dr Adel Taweel 2014

120

Conditional notions
121

Conditional notation is used if the value of an

objects attributes determines the change of
state( i.e., change the state under this condition.)
Important hint: For some guards use keywords like

After (followed by expression

When (followed by expression)

Dr Adel Taweel 2014
121

Conditional Notions
122

Means
If balance<0, then change the state to overdrawn
If balance>=0, then change the state to Incredit
Important hint:

For expressing some events use keywords like

After (followed by expression)


Dr Adel Taweel 2014
122

Conditional Notions
123

Important hint:

For expressing some events use keywords like

After (followed by expression)


Dr Adel Taweel 2014

123

Modelling states and substates
124

States of ATM machine itself
Dr Adel Taweel 2014

124

Modelling substates
125

States of ATM machine itself is rather trivial.

Let us see how we can model the sub state busy
Dr Adel Taweel 2014

125

Modelling substates of ATM
machine 126

Dr Adel Taweel 2014

126

Modelling substates of ATM
machine 127

Dr Adel Taweel 2014

127

Modelling concurrent states
128

Dr Adel Taweel 2014

128

Exercise: a State diagram of a video player
129

Dr Adel Taweel 2014

129

UML Diagrams
130

Dr Adel Taweel 2014

130

Component Diagrams
131

The component diagram's main purpose is to show the

structural relationships between the components of a
system
Component diagrams offer architects a natural format to
begin modelling a solution
Component diagrams allow an architect to verify that a
system's required functionality is being implemented by
components
Developers find the component diagram useful because it
provides them with a high-level, architectural view of the
system that they will be building
Dr Adel Taweel 2014

131

Component Diagrams
132

Dr Adel Taweel 2014

132

Required/Provide Interface
133

Dr Adel Taweel 2014

133

Component Diagrams
134

showing a component's relationship with other components, the

lollipop and socket notation must also include a dependency arrow
(as used in the class diagram). On a component diagram with
lollipops and sockets, note that the dependency arrow comes out of
the consuming (requiring) socket and its arrow head connects with
the provider's lollipop
Dr Adel Taweel 2014

134

Component Diagrams
135

Architectural connection in UML 2.0 is expressed

primarily in terms of interfaces
Interfaces are classifiers with operations but no
attributes
Components have provided and required interfaces
Component implementations are said to realize their provided
interfaces
A provided and required interface can be connected if the
operations in the latter are a subset of those in the former, and
the signatures of the associated operations are compatible
Ports provide access between external interfaces and
internal structure of components
UML components can be used to model complex
architectural connectors (like a CORBA ORB)
Dr Adel Taweel 2014
135

Component Diagrams
136

Dr Adel Taweel 2014

136

Composite Structure in Component Diagrams
137

Ref: David Rosenblum, UCL

A composite structure depicts the internal

realisation of component functionality
Dr Adel Taweel 2014

137

Ports
138


The ports and connectors specify how component interfaces are mapped to
internal functionality
Note that these connectors are rather limited, special cases of the ones in
software architectures
Dr Adel Taweel 2014

138

Ports
139


Connectors and ports also can be used to specify

structure of component instantiations
Dr Adel Taweel 2014
139

Example
140

Dr Adel Taweel 2014

140

Componentization Guidelines
141

Keep components cohesive. A component should

implement a single, related set of functionality.
This may be the user interface logic for a single user application,
business classes comprising a large-scale domain concept, or
technical classes representing a common infrastructure concept.
Assign user interface classes to application components.
User interface classes, those that implement screens, pages, or
reports, as well as those that implement glue logic.
Assign technical classes to infrastructure components.
Technical classes, such as those that implement system-level
services such as security, persistence, or middleware should be
assigned to components which have the infrastructure stereotype.
Dr Adel Taweel 2014

141

Example
142

Dr Adel Taweel 2014

142

143

Assign hierarchies to the same component.

99.9% of the time it makes sense to assign all of the classes of a
hierarchy, either an inheritance hierarchy or a composition
hierarchy, to the same component.
Identify business domain components.
Because you want to minimize network traffic to reduce the
response time of your application, you want to design your
business domain components in such a way that most of the
information flow occurs within the components and not between
them.
Business domain components = services
Identify the collaboration type of business classes.

Once you have identified the distribution type of each class, you
are in a position to start identifying potential business domain
components.
Dr Adel Taweel 2014

143

Example
144

Dr Adel Taweel 2014

144

145

Highly coupled classes belong in the same component.

When two classes collaborate frequently, this is an indication they
should be in the same domain business component to reduce the
network traffic between the two classes.
Minimize the size of the message flow between
components.
Merge a component into its only client. If you have a domain
component that is a server to only one other domain component,
you may decide to combine the two components.
Define component contracts.
Each component will offer services to its clients, each such service
is a component contract.
Dr Adel Taweel 2014

145

Example
146

Dr Adel Taweel 2014

146

UML Diagrams
147

Dr Adel Taweel 2014

147

Deployment Diagram
148

Models the run-time configuration in a static view

and visualizes the distribution of components in an
application
A component is deployed part of the software
system architecture
In most cases, it involves modelling the hardware
configurations together with the software
components that lived on
Dr Adel Taweel 2014

148

Deployment Diagram
149

Deployment diagram depicts a static view of the run-time

configuration of processing nodes and the components that
run on those nodes
Node: server, client etc.
Deployment diagrams show the hardware for your system,
the software that is installed on that hardware, and the
middleware used to connect the disparate machines to one
another!
Visualizes the distribution of components in an application
Shows the configuration of the hardware elements (nodes)
and shows how software elements and artifacts are mapped
onto those nodes.
Dr Adel Taweel 2014

149

Node
150

A Node is either a hardware or software element. It

is shown as a three-dimensional box shape, as
shown below.
Dr Adel Taweel 2014

150

Node Instance
151

An instance can be distinguished from a node by the fact that its

name is underlined and has a colon before its base node type. An
instance may or may not have a name before the colon.
The following diagram shows a named instance of a computer
Dr Adel Taweel 2014

151

Node Sterotypes
152

A number of standard stereotypes are provided for nodes, namely

cdrom, cd-rom, computer, disk array, pc, pc client,
pc server, secure, server, storage, unix server, user pc.
These will display an appropriate icon in the top right corner of the
node symbol
Dr Adel Taweel 2014

152

Artifact
153

An artifact is a product of the software development process. That

may include process models (e.g. use case models, design models
etc), source files, executables, design documents, test reports,
prototypes, user manuals, etc.
An artifact is denoted by a rectangle showing the artifact name, the
artifact keyword and a document icon, as shown below.
Dr Adel Taweel 2014

153

Association
154

In deployment diagram, an
association represents a
communication path
between nodes. The
following diagram shows a
deployment diagram for a
network, depicting network
protocols as stereotypes,
and multiplicities at the
association ends.
Dr Adel Taweel 2014

154

Node as Container
155

A node can contain other elements, such as components

or artifacts.
The following diagram shows a deployment diagram for
part of an embedded system, depicting an executable
artifact as being contained by the motherboard node.
Dr Adel Taweel 2014

155

Example of three-tiers architectures
156

Many of real life web applications have three tier

architectures
Dr Adel Taweel 2014
156

Deployment diagram for three tiers
157

Dr Adel Taweel 2014

157

Example: Client server architectures
158

Dr Adel Taweel 2014

158

Example: Deployment Diagram for
client server159

architectures
Dr Adel Taweel 2014

159

Covered!?
160

Dr Adel Taweel 2014

160

Key points
161

A model is an abstract view of a system that ignores system details.

Complementary system models can be developed to show the systems
context, interactions, structure and behaviour.
Context models show how a system that is being modeled is positioned
in an environment with other systems and processes.
Use case diagrams and sequence diagrams are used to describe the
interactions between users and systems in the system being designed.
Use cases describe interactions between a system and external actors;
sequence diagrams add more information to these by showing
interactions between system objects.
Structural models show the organization and architecture of a system.
Class diagrams are used to define the static structure of classes in a
system and their associations.
Dr Adel Taweel 2014

161

Uml

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Uml

Diunggah oleh

Hak Cipta:

Format Tersedia

Software Engineering

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Several different notations for describing object

Dr Adel Taweel 2014

Unified Modelling Language

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

The language of the designer

Dr Adel Taweel 2014

Diagram: a view into the model

Structure Diagrams Behaviour Diagrams

Dr Adel Taweel 2014

Use Case Diagram

Dr Adel Taweel 2014

Dr Adel Taweel 2014

What is use case modelling?

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Built in early stages of development

Dr Adel Taweel 2014

Describe each actor clearly and precisely (semantics)

Assume you have a requirements documents for a

Dr Adel Taweel 2014

Things actors do with the system

Describe the behaviour of the system from a users

Dr Adel Taweel 2014

Start with the list of actors and consider

Dr Adel Taweel 2014

Semantics should be described fully!

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

A use case in the MHC-PMS

Medical receptionist Patient record system

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Multi-purpose recycling machine

print total received items for operator,

change system information,

signal alarm when problems arise.

Reference: Anthony Finkelstein, UCL

Dr Adel Taweel 2014

Returning items is started by Customer when they want to

When a Customer has deposited all their items, they will

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Extensions provide opportunities for :

alternative complex cases

insertion of use cases

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Note: <<include>> and <<extend>>: are UML stereotypes

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Dr Adel Taweel 2014

Consultant Team doctor