Programacin III

POO y
UML
Ing. Priscila Bernal

Indice
Perspectiva General
UML
Modelado Visual
Vistas UML

Diagramas UML

Modelo

Es un esquema simplificado que describe un

sistema o realidad desde un determinado

punto de vista que facilita su estudio y
compresin

Sistema Software
(complejo)

Modelo
(simplificado)
Los modelos de un sistema software se
expresan visualmente mediante el
lenguaje de modelado UML

Modelado en Ingeniera
Arquitectura/Ingeniera

de Estructuras
Vistas Edificio

Vista 3D
Alzado/Planta Perfil
Estructura del edificio
Instalacin Elctrica
Instalacin Aire Acc.
...

Ingeniera Software
Modelos UML del Sistema

Software
Modelo
Modelo
Modelo
Modelo
Diagramas
Modelo

DocumentList

FileMgr

add( )
delete( )

fetchDoc(
) )
sortByName(

FileList
fList
add( )
delete( ) 1

rep
File
Repository
(from Persistence) read( )
name : char * = 0
readDoc( )
readFile( )

Diagramas

Herramientas Modelado (ej)

Autocad

GrpFile

read( )
open( )
create( )
fillFile( )

Document
name : int
docid
: int: int
numField
get( )
open( )
close( )
read(
)
sortFileList(
)
create( )
fillDocument(

read() fill the

code..

de
de
de
de
de

user

Casos de uso
Lgico
Comportamiento
Implementacin
Despliegue
mainWfileMgr
nd document
:
gFile
repository
:
FileMgr
Document

Repository

1: Doc view request ( )

DocumentList

2: fetchDoc( )

3: create ( )

4: create ( )

FileManager

Document

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

GraphicFile

File

FileList

Herramientas Modelado (ej)

Rational Rose

Modelado Visual
Modelos que presentan grficamente alguna

vista del sistema.

Se crean mediante:
Lpiz y Papel
Herramienta Software especifica
(por ej: Rational Rose, Microsoft Office Visio)

UML
Es el lenguaje estndar de la industria para

el modelado visual de sistemas orientados a

objeto y/o basados en componentes

UML no es:
una metodologa o proceso
un lenguaje de programacin

Paradigma Orientado a
Objeto
Desarrollo de un sistema software mediante la

construccin de unidades reusables siguiendo

los principios de :
Abstraccin
Encapsulacin
Herencia
Polimorfismo

Paradigma Basado en
Componentes
Desarrollo de un sistema software mediante

en el emsablado de unidades reusables

siguiendo los principios de:
Componentes
Interfaces
Infraestructura

UML. Definicin Formal

Es un lenguaje estndar para

visualizar,especificar, construir y
documentar los artefactos que se generan
en el proceso de desarrollo de un sistema
software

Modelos UML
Modelos UML describen caractersticas:
Estticas o de Estructura
Dinmicas o de Comportamiento
Construcciones de implementacin
Organizacin del modelo

Estructura de UML

Estructura
(caractersticas estticas)

Modelos

capturan

Comportamiento
(caractersticas dinmicas)

Gestin del Modelo

Extensin UML
organizado en

visualizado en
Vistas Arquitectonicas

Vista de casos de uso

Vista Esttica
Vista de Implementacin
Vista de Despliegue
Vista de Mquina de estados
Vista de Actividad
Vista de Interaccin

Diagramas

Diagramas de Casos de Uso

Diagramas de Clases
Diagramas de Componentes
Diagramas de Estados
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboracin

Vista de Casos de Uso

Modela funcionalidad del sistema de acuerdo

a percepcin de usuarios externos (actores).

Propsito:

Enumerar actores y casos de uso

Demostrar qu actores participan en cada caso

de uso

En la vista de interaccin los casos de uso se

implementan como una colaboracin

Se muestra en el diagrama de casos de uso

MODELOS DE CASO DE USO

Los diagramas de casos de uso describen las
relaciones y las dependencias entre un grupo de casos
de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de
uso no estn pensados para representar el diseo y no
puede describir los elementos internos de un sistema.
Los diagramas de casos de uso sirven para facilitar la
comunicacin con los futuros usuarios del sistema, y
con el cliente, y resultan especialmente tiles para
determinar las caractersticas necesarias que tendr el
sistema. En otras palabras, los diagramas de casos de
uso describen qu es lo que debe hacer el
sistema, pero no cmo.

Para qu sirven los casos

de uso?
Para capturar el comportamiento deseado del

sistema sin tener que especificar como se

implementa ese comportamiento.
Como medio de comprensin para

desarrolladores.
Ayuda a validar la arqitectura y a verificar el

sistema en el transcurso de desarrollo de este.

MODELOS DE CASO DE USO

Actor
Un actor es una entidad externa (de fuera del
sistema) que interacciona con el sistema
participando (y normalmente iniciando) un caso
de uso. Los actores pueden ser gente real (por
ejemplo, los usuarios del sistema).

MODELOS DE CASO DE USO

Los actores no representan a personas fsicas o a
sistemas, sino su papel. Esto significa que cuando
una persona interacciona con el sistema de
diferentes
maneras
(asumiendo
diferentes
papeles), estar representado por varios actores.
Por ejemplo, una persona que proporciona
servicios de atencin al cliente telefnicamente y
realiza pedidos para los clientes estara
representada por un actor equipo de soporte y
por otro actor representante de ventas.

MODELOS DE CASO DE USO

Descripcin de casos de uso
Las descripciones de casos de uso son reseas
textuales del caso de uso. Normalmente tienen el
formato de una nota o un documento relacionado
de alguna manera con el caso de uso, y explica
los procesos o actividades que tienen lugar en el
caso de uso.

MODELOS DE CASO DE USO

Ejemplo de casos de uso

Relaciones entre casos

de uso
Las dos relaciones posibles y sus semnticas

segn UML son las siguientes:

Includes: Se dice que un caso de uso A

incluye al caso de uso B, cuando B es parte

del
caso
de
uso
A,
es
decir,
el
comportamiento expresado en B forma parte
del comportamiento de A. El caso de uso B se
realiza siempre dentro del caso de uso A.

Relaciones entre casos

de uso
Adems, siempre que ocurre A ocurre

tambin B, por lo que se dice que B es un

caso de uso abstracto. Un caso de uso es
abstracto si no puede ser realizado por s
mismo, por lo que slo tiene significado
cuando se utiliza para describir alguna
funcionalidad que es comn a otros casos de
uso
include
A

Ir al cine

Comprar
entrada

Relaciones entre casos

de uso
Extends: Un caso de uso A extiende a otro

caso de uso B, cuando A expresa un

comportamiento posible de B, que ocurre en
una determinada circunstancia. El caso de uso
A puede realizarse o no cuando se realiza el
caso de uso B, segn las circunstancias.

Diagrama de Casos de Uso

 Cmo identificar los

casos de uso?
Lluvia de ideas
Revisando documentos existentes de

Requerimientos.
BASADO EN ACTORES
1. Identificar los actores relacionados con el

sistema o la organizacin.
2. Para cada actor identidificar procesos que
ellos inician o en los que participan.

 Cmo se debe crear un

caso de uso?
Tras localizar los actores, procede el

describirlos.
Especificar describiendo un flujo de eventos.
Los actores solo pueden conectar a los casos
de uso a travs de asociaciones.
Generalmente hay pocos actores asociados a

cada caso de uso.

 Cmo se debe crear un

caso de uso?
Preguntas clave
Cales son las tareas del actor?
Qu informacin crea, guarda, modifica,
destruye o lee el actor?
Debe el actor notificar al sistema los cambios
externos?
Debe el sistema notificar al actor los cambios
internos?

 Cmo se debe crear un

caso de uso?
La descripcin del caso de uso comprende:
El inicio: cundo y que actor lo produce?
El fin: cundo se produce y que valores
devuelve?
La interaccin: que mensajes intercambian
actor-caso de uso.
Objetivos del CU: cronologa y origen de la
informacin. Repeticiones de comportamiento.
(qu operaciones son iteradas?).
Situaciones opcionales: qu ejecuciones
alternativas se presentan en el caso de uso?

Puntos clave
Las Precondiciones son los hechos que se

han de cumplir para que el flujo de eventos se

pueda llevar a cabo.
Flujo de eventos normal, que corresponde
a la ejecucion normal y exitosa del caso de
uso
Los flujos alternativos son los que nos
permiten indicar qu es lo que hace el
sistema en los casos menos frecuentes e
inesperados.
Las poscondiciones son los hechos que se

Ejemplo:
Caso de uso:
Descripcin:
Actores:
Precondicione
s:

Flujo Normal:
Flujo
Alternativo:
Poscondicione

Crear mensaje foro

Permite crear un mensaje en un foro de discusin
Usuario de internet logueado
El usuario debe haberse logueado en el sistema
1. El actor pulsa sobre el botn para crear un nuevo
mensaje
2. El sistema muestra una caja de texto para
introducir el titulo del mensaje y una zona de
mayor tamao para introducir el cuerpo del
mensaje.
3. El actor introduce el titulo y cuerpo del mensaje.
4. El sistema comprueba la validez de los datos y los
almacena.
4. El sistema comprueba la validez de los datos, si los
datos no son correctos, se avisa al actor de ello,
permitindole que los corrija.

Vista Esttica
Modela conceptos de dominio de aplicacin
Se muestra en el diagrama de clases
Componentes:
Clases y Relaciones

Clases
Las clases se representan por rectngulos,

divididos en tres partes:

Atributos y Mtodos:
ATRIBUTOS
Los atributos o caractersticas de una Clase pueden ser
de tres tipos, los que definen el grado de comunicacin
y visibilidad de ellos con el entorno, estos son:
pblico : Indica que el atributo ser visible tanto
dentro como fuera de la clase, es decir, es accesible
desde todos lados.
privado: Indica que el atributo slo ser accesible
desde dentro de la clase (slo sus mtodos lo
pueden accesar).
protegido: Indica que el atributo no ser accesible
desde fuera de la clase, pero si podr ser accesado
por mtodos de la clase adems de las subclases

Atributos y Mtodos:
MTODOS
Los mtodos u operaciones de una clase son la forma
en como sta interacta con su entorno, stos pueden
tener las caractersticas:
pblico: Indica que el mtodo ser visible tanto
dentro como fuera de la clase, es decir, es accesible
desde todos lados.
privado : Indica que el mtodo slo ser accesible
desde dentro de la clase (slo otros mtodos de la
clase lo pueden accesar).
protegido : Indica que el mtodo no ser accesible
desde fuera de la clase, pero si podr ser accesado
por mtodos de la clase adems de mtodos de las

Relaciones entre Clases

Es
necesario
explicar
como
se
pueden
interrelacionar dos o ms clases (cada uno con
caractersticas y objetivos diferentes).
El concepto de cardinalidad de relaciones: En
UML, la cardinalidad de las relaciones indica el
grado y nivel de dependencia, se anotan en cada
extremo de la relacin y stas pueden ser:

Relaciones entre Clases

Especificacin de multiplicidad:
(mnima...mxima)
1 Uno y slo uno
0..1 Cero o uno
M..N Desde M hasta N (enteros naturales)
* muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)

Relaciones entre Clases

RELACION DE GENERALIZACIN
Indica que una subclase hereda los mtodos y
atributos especificados por una Super Clase, por
ende la Subclase adems de poseer sus propios
mtodos y atributos, poseer las caractersticas y
atributos visibles de la Super Clase (public y
protected), ejemplo:

Relaciones entre Clases

RELACION DE GENERALIZACIN

En la figura se especifica que Auto y Camin heredan de

Vehculo, es decir, Auto posee las Caractersticas de Vehculo
(Precio, VelMax, etc) adems posee algo particular que es
Descapotable, en cambio Camin tambin hereda las
caractersticas de Vehiculo (Precio, VelMax, etc) pero posee
como particularidad propia Acoplado, Tara y Carga.

Relaciones entre Clases

RELACIN DE AGREGACIN
Para modelar objetos complejos, no bastan los
tipos de datos bsicos que proveen los lenguajes:
enteros, reales y secuencias de caracteres.
Cuando se requiere componer objetos que son
instancias de clases definidas por el desarrollador
de la aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en

donde el tiempo de vida del objeto incluido esta

condicionado por el tiempo de vida del que lo
incluye. Este tipo de relacin es comnmente
llamada Composicin (el Objeto base se
construye a partir del objeto incluido, es decir,

Relaciones entre Clases

RELACIN DE AGREGACIN
Por Referencia: Es un tipo de relacin dinmica, en

donde el tiempo de vida del objeto incluido es

independiente del que lo incluye. Este tipo de relacin es
comnmente llamada Agregacin (el objeto base utiliza
al incluido para su funcionamiento).
Un Ejemplo es el siguiente:

Relaciones entre Clases

RELACIN DE AGREGACIN
En donde se destaca que:
Un Almacn posee Clientes y Cuentas (los rombos
van en el objeto que posee las referencias).
Cuando se destruye el Objeto Almacn tambin son
destruidos los objetos Cuenta asociados, en cambio
no son afectados los objetos Cliente asociados.
La composicin (por Valor) se destaca por un
rombo relleno.
La agregacin (por Referencia) se destaca por
un rombo transparente.

Relaciones entre Clases

RELACIN DE AGREGACIN
La flecha en este tipo de relacin indica la navegabilidad
del objeto referenciado. Cuando no existe este tipo de
particularidad la flecha se elimina.
Ejemplo de agregacin: un ordenador y sus
perifricos. Los perifricos de un ordenador pueden
estar o no, se pueden compartir entre ordenadores y
no son propiedad de ningn ordenador.
Ejemplo de composicin: un rbol y sus hojas. Un
rbol est ntimamente ligado a sus hojas. Las hojas
son propiedad exactamente de un rbol, no se pueden
compartir entre rboles y cuando el rbol muere, las
hojas lo hacen con l.

Relaciones entre Clases

RELACIN DE ASOCIACIN
La relacin entre clases conocida como Asociacin,
permite asociar objetos que colaboran entre si.
Cabe destacar que no es una relacin fuerte, es
decir, el tiempo de vida de un objeto no depende
del otro.
Ejemplo:

Un cliente puede tener asociadas muchas Ordenes

de Compra, en cambio una orden de compra solo
puede tener asociado un cliente.

Relaciones entre Clases

RELACIN DE DEPENDENCIA O INSTANCIACIN
(USO):
Representa un tipo de relacin muy particular, en la
que una clase es instanciada (su instanciacin es
dependiente de otro objeto/clase). Se denota por
una flecha punteada.
El uso ms particular de este tipo de relacin es
para denotar la dependencia que tiene una clase
de otra, como por ejemplo una aplicacin grafica
que instancia una ventana (la creacin del Objeto
Ventana esta condicionado a la instanciacin
proveniente desde el objeto Aplicacin):

Relaciones entre Clases

RELACIN DE DEPENDENCIA O INSTANCIACIN
(USO):
Ejemplo:

Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se
almacena dentro del objeto que lo crea (en este caso la Aplicacin).

Diagrama de Clases

Diagrama de Clases