The Unified Modelling Language UML - PowerPoint PPT Presentation

1 / 17
About This Presentation
Title:

The Unified Modelling Language UML

Description:

This is a conventional University lending library where potential borrowers must ... as the three amigos. Jacobson's Use-Case approach. Booch's OOD. Rumbaugh's OMT ... – PowerPoint PPT presentation

Number of Views:73
Avg rating:3.0/5.0
Slides: 18
Provided by: petem7
Category:

less

Transcript and Presenter's Notes

Title: The Unified Modelling Language UML


1
Introduction
1
The Unified Modelling Language (UML)
Introduction to library case study Origins of
the UML What the UML is and is not Overview of
notations Development process and life cycle
2
Library System
The Unified Modelling Language
2
This is a conventional University lending library
where potential borrowers must first register to
obtain a library card and may then borrow or
reserve books. Student borrowers may borrow up
to 5 books at a time for up to 20 days. Staff
borrowers may borrow up to 20 books for periods
up to 40 days. Borrowers may not borrow books if
their loan limit has been reached, there are any
unpaid fines for a late returns or if the book
has already been reserved by another
borrower. Reservations are held, on return by
the previous borrower for 5 days and the reserver
notified. The librarian is responsible for the
addition of new books into the library stock and
their eventual disposal once they have become
worn out and also for the registration of new
members. The counter clerk is responsible for
processing the day-to-day lending, returning and
reserving of books and for dealing with overdue
notifications and fines. When a new book is
added to the stock it is given a unique
acquisition number and a location reference. When
a member is registered they also are allocated a
unique membership number. These numbers are
printed as bar codes and attached to the book and
membership cards respectively. Anyone is allowed
to browse the catalogue regardless of being a
member or not.
3
The origins of UML
3
The Unified Modelling Language
UML resulted from the merging of three very
popular OOD methods - Objectory by Jacobsen,
Boochs OOD and OMT by Rumbaugh. These authors
worked together on the development of UML - now
referred to as the three amigos.
Jacobsons Use-Case approach
This focused on the external actors interacting
with the system and their functional
requirements. Has a strong functional basis and
has some similarity to the context diagrams of
SASD. A CASE tool called Objectory is available.
Boochs OOD
Boochs method developed originally in 1989 and
later extended in 1991 was targeted initially at
Ada development but later broadened to apply to
OO languages. Diagrams rather complex and CASE
tool support essential. The emphasis here was on
design and implementation.
Rumbaughs OMT
Object modeling technique supported initially by
a case tool OMTool and later by others. Very
straightforward approach with an excellent text
book. Widely adopted in academia and industry
alike. Focus very much on analysis rather than
design and implementation.
4
What UML is and is not.
The Unified Modelling Language
4
UML is A set of standardised diagramatic
notations for representing different aspects of
a system. Containing static structural views,
dynamic behavioural views and functional
views. UML is not A design method or
process, neither is it a methodology. There is
no provision for project management,
specification of deliverables or life cycle or
provision for estimation. This was intended to
allow users to apply whatever process and
life cycle - RAD, prototyping, incremental
development, waterfall or spiral - they wished
and provide their own project management and
QA framework.
5
Overview of diagrams
The Unified Modelling Language
5
UML diagram provide a variety of different
perspectives on a system. These can be divided
into static, structural diagrams,
interaction diagrams and dynamic behaviour
description as follows - Static, structure
diagrams Class and instance diagrams
These depict the components (classes or
instances) within the system, their
attributes and methods and their relationships
with each other. The class diagram in
particular is the most important single diagram
in the design. Component and
subsystem diagrams These show the way
classes are grouped to form large assemblies -
reusable components, sub-systems or
packages of classes. Deployment diagrams
These show how the software components
are deployed across a set of hardware
components.
6
Overview of diagrams
The Unified Modelling Language
6
Interaction diagrams Use-case diagrams
These show the interface between the
system and the outside world and
identify the actors in the system and their
required functionality. Sequence diagrams
These show the functionality of the
system is achieved by message passing
between objects. Each sequence diagram shows the
implementation of one scenario.
Collaboration diagrams Based on the
instance diagram, this shows how specific
scenarios are implemented by message
sequence. Similar to sequence diagrams.
Activity diagrams Similar to
petri-nets, these provide a view of the way the
ways objects interact and undergo
mutual changes of state in so doing.
7
Overview of diagrams
The Unified Modelling Language
7
Dynamic behaviour of the system Activity
diagrams Similar to petri-nets, these
provide a view of the way objects interact
and undergo mutual changes of state in so
doing. The emphasis here is on system
functionality as perceived by users and different
areas of responsibility can be
demarcated. Statecharts Harel
statecharts are a development from finite state
notation and show the dynamic behaviour
of objects. i.e. the way in which an object
evolves through time in reponse to
external events.
8
The Unified Modelling Language
8
The development process
As has already been stated, the UML does not
specify a process to be followed. A number of
possible processes could be adopted depending on
the experience of the personnel and the nature of
the project. Additionally, a number of
different life-cycles could be adopted
- Water-fall approach This never really
worked in the days of structured analysis and
design and there is every reason to believe
that it would be less successful with the
iterative nature of OOD. Prototyping and RAD
OO is highly suited to this approach and aids
it by the provision of reusable, pluggable
components. Incremental development and
iterative development Again both highly
suitable for OO, bringing rapid benefits with low
risk.
9
The Unified Modelling Language
9
Overview of the OOD process
Analysis of current system (if any) new
requirements leading to - Conceptual model. Most
diagram types are involved, but principally -
Create a use-case diagram - identify actors

- identify major functional requirements
Initial Class diagram - discover
principle classes
- represent important
relationships Event sequence diagrams
-examine possible object interactions
-
determine class protocols Design involves
consideration of non-functional requirements and
leads to Implementation model. Involves - adding
more detail, new classes.
- combining or
splitting classes,
- adding or removing
relationships,
- defining the
implementation of
relationships.
-
introducing generalisations, interface

implementation classes. Introduce Component,
sub-system and deployment models.
10
The Unified Modelling Language
10
Categories of model
The development process moves from analysis,
through design to implementation and review in a
cyclewhose length and number of characterises
the life cycle to be used - e.g. waterfall,
cyclic, prototyping, RAD, incremental
etc. During this process a number of different
categories of model can be identified -
Conceptual model - describing the essence of the
system in a low level
of detail. The nature of the
system. Specification model - describing
what the client requires in detail, and
forming a
blueprint for design. Implementation -
describing how the clients requirements are to be
met and
forming a blueprint for implementation.

11
The Unified Modelling Language
11
Categories of object
In identifying objects from which classes can be
derived in the design, three different levels of
object can be recognised - Domain objects
- these represent artefacts or concepts in the
application
domain. Interface objects - these are
systems related components which
provide an interface between
the system and
its actors, such as GUIs.
Implementation objects - these are low level
software components
needed to implement the
design, such as
various forms of data structure
etc. During early stages of design, only domain
objects should be considered. Later, in producing
a specification model, interface objects can be
included and finally, during implementation,
implementation objects are added.

12
12
The Unified Modelling Language (UML)
Use-case and class diagrams
Use-case diagrams Class diagrams - conceptual
model
13
The Unified Modelling Language
13
Use-case diagrams
These depict the Actors in the system and the
required functionality. Actors External
entities People interested in system
Other systems interfacing with the
system May or may not be represented by a
software component. Represented by stick people
or other graphic. Functions Primary
functionality of system seen from a users
perspective. Linked to the actors involved
with/interested in the function. Represented by
ovals.
14
The Unified Modelling Language
14
Use-case for library system
Check member status
ltltincludesgtgt
Borrow book
ltltincludesgtgt
Register member
Reserve book
Add book
Return book
Remove book
ltltextendsgtgt
Browse catalogue
15
The Unified Modelling Language
15
Relationships between classes
The UML recognizes four principle relationships
between classes as follows - Simple
association - usually annotated and interpreted
left to
right/top to bottom.
If meaning implies right to left
etc use
small arrows to indicate. Aggregation -
a part of relationship Composition - a
stronger - permanent ownership form
of aggregation.
Generalisation/specialisation - is a or is
like as
relationship. Composition and generalisation not
usually annotated and always 1 to 1. Others can
be 1 to 1 ( unmarked), 1 to many or many to
many. Multiplicity is shown as zero or more,
1.. one or more specifically e.g. 2..5 or 6
or 4,8,12
course
is enrolled on
student

race
horse
4
car
wheel
vehicle
car
16
The Unified Modelling Language
16
Class attributes and methods
During analysis, the conceptual class model is
developed, with the help of other diagrams,
through the following stages - Simple class
names with relationships Introduction of class
attributes Introduction of methods During
design, attribute and method detail will be
extended to include visibility indication, data
types, parameter and parameter types and return
types from methods.
Book
17
The Unified Modelling Language
37
Library system - conceptual class diagram
Library



has loans
is on loan
Book
Member
Loan
Student
Staff
Write a Comment
User Comments (0)
About PowerShow.com