ANALISIS Y DISEÑO DE

SOFTWARE 1
ING. OTTO PARRA GONZALEZ
OCTUBRE DEL 2018
CHAPTER 4: UML
ANALISIS Y DISEÑO DE SOFTWARE 1
INTRODUCTION
Visual documentation: Software models are artefacts like …
Introduction
Visual modelling a business process
UML: a modelling language
A modelling language allows the specification, the visualization and the
documentation of a software development process
The models are artefacts which clients and developers use to communicate
The most used modelling languages are standard (e.g. UML is a standard by
OMG):
UML 1.* is a modelling language
UML 2.0 is also a programming language

Unified Modelling Language

An industrial standard (OMG) notation to:
o Model a business, its roles and processes o
Write the requirements of a software
system o Describe its software
architecture
o State the structure and behaviour of a
software artefact
o Document a software application o
Generate automatically an implementation

Object Management Group

Object Management Group (OMG):
 Consortium of industries and interested universities
Produces specifications of reference architectures, e.g. CORBA
UML has been adopted by OMG as standard de facto
Roots of UML
At the beginning of the ’90 there was a convergence:
The “tre amigos”
Booch: analysis by objects
Rumbaugh: Object Modelling Technique (OMT)
Jacobson: process Objectory
In 1994-95 they define for Rational both UML and UP
The three amigos: Grady Booch, Jim Rumbaugh, Ivar Jacobson
History of UML
.
Main UML specification documents
Superstructure: defines the UML elements (diagrams, etc)
Infrastructure: defines the UML metamodel
OCL (Object Constraint Language): formal language for writing
constraints and formulas
XMI (XML Metadata Interchange): DTD for UML models
UML Diagram Interchange: XMI + graphic info
Canonical diagrams (Superstructure
v2.0
Version 2.0 includes 13 canonical diagrams
Function
A software system is designed with some functional
requirements in mind.
UML has a specific diagram for this: Use Cases
Modelling Requirements in UML
Use case diagram
– Describes the main user stakeholders
– Describes the externally observable behaviour of system
functions, usually to define system requirements
– Describes interactions between the system and external
entities, including users and other systems
Use Case
“A use case specifies the behavior of a system or a part of a system, and is
a description of a set of sequences of actions, including variants, that a
system performs to yield an observable result of value to an actor.” - The
UML User Guide, [Booch,99]

“An actor is an idealization of an external person, process, or thing interacting with

a system, subsystem, or class. An actor characterizes the interactions that outside
users may have with the system.”
- The UML Reference Manual, [Rumbaugh,99]
Use Case: elements
.
Use Case
A use case is rendered as an ellipse in a use case
diagram. A use case is always labeled with its name.
An actor is rendered as a stick figure in a use case
diagram. Each actor participates in one or more use
cases.
Actors can participate in a generalization
relation with other actors.
Elements of a Use Case Diagram
Actor:
– Represents a role played by external entities (humans,
systems) that interact with the system Use case:
– Describes what the system does (i.e., functionality)
– Scenario: sequence of interactions between the actors
and the system Relationships:
– Association between actors and use cases
– Extension (or generalization) among actors
– Dependency among use cases: include and extend
UML: Example
.
Use Case Scenarios
.