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
.