Análisis de Sistemas Administrativos

Análisis de Sistemas
Administrativos
Unidad 1.1
Análisis y Diseño OO
Facultad de Tecnología Informática UAI

Mg. Carlos Gerardo Neil
2008
Administrativos
Unidad 2.1
UML y el Proceso
de Desarrollo de Software

2008
Programa de la Asignatura
1.1. Análisis y diseño OO
2.1. Proceso de desarrollo de software. 1º parte
3.1. Casos de uso
3.2. Diagramas de clases.
3.3. Diagramas de comunicación.
3.4. Diagramas de secuencia.
4.1. Lenguaje de restricción de objetos.
5.1. Patrones de Diseño.
6.1. Transformación del Modelo de Clases al Modelo ER
7.1. Proceso de desarrollo de software 2º parte
Clase anterior – repaso general
• ¿Cuál la diferencia entre el análisis y diseño Estructurado y el OO?
• ¿Cuál es la diferencia entre análisis, diseño e implementación y que es lo que realizo en

cada una de estas actividades?
• ¿Vinculo la etapa de análisis con la descripción del modelo de dominio de la

aplicación?
• ¿Comprendo cual es el uso de las tarjetas CRC?
• ¿Cuál es el objetivo de la abstracción y el encapsulamiento?
• ¿Cuál es la diferencia entre mensajes, operaciones y método?
• ¿Qué diferencia existe entre asociación, agregación y composición?
• ¿Cuál es la diferencia entre generalización y herencia?

UML
• ¿Qué son los modelos?
• ¿Para qué sirven los modelos?
• Tipos de modelos y perspectivas
¿Cuáles son los modelos de UML?

¿Se usan todos...?
¿Qué son los modelos?
• Un modelo es una representación que capta los aspectos más importantes de
lo que estamos modelando y simplifica u omiten el resto
• Es la representación de una abstracción
• Un modelo de un sistema software está construido en un lenguaje de

modelado. Tiene semántica y notación. Incluye gráficos y texto
• El modelo es la columna vertebral de un lenguaje utilizado por todos los

integrantes del equipo:
 Desarrolladores
 Expertos del dominio
 Usuarios
 Analistas
¿Para qué sirven los modelos?
 Ayudan a la comprensión de sistemas complejos
 Indican QUÉ hará el sistema pero NO CÓMO lo hará
 Ayuda a la corrección de errores
 Ayuda a la evolución y reuso
 Esencial para la comunicación entre miembros de un equipo

Tipos de modelos y perspectivas
Usando la misma notación (UML) se pueden considerar tres

perspectivas:
• Esencial o conceptual: los diagramas describen cosas del mundo

real o dominio de interés
• De especificación: los diagramas describen abstracciones

software independientes de la implantación
• De implantación: los diagramas describen implementaciones

software en un lenguaje particular
Orígenes de UML
A mediados de los noventa existían muchos métodos de Análisis y Diseño OO
 Los mismos conceptos se representaban con distinta notación

 Existía mucha confusión
 No existía un lenguaje líder de modelado
G. Booch (Método Booch)

En 1994 J. Rumbaugh (OMT) deciden unificar sus métodos:
I. Jacobson (Proceso
Objectory)
Unified Modeling Language (UML)
El proceso de estandarización promovido por OMG comenzó en 1997

¿Qué es UML?
UML es un lenguaje estándar para:
 visualizar
 especificar
 construir
 documentar
los artefactos de un
sistema.
¿Dónde Usamos UML?
Usamos UML
en todas las
etapas del
proceso de
desarrollo
¿Para qué sirve UML?
UML permite:
– Definir los límites del sistema y sus principales funciones,
mediante Casos de Uso y actores.
– Ilustrar el funcionamiento de un caso de uso mediante Diagramas

de Interacción
– Representar la estructura de un sistema mediante Diagramas de

Clases.
– Modelar el comportamiento de los objetos mediante Diagramas

de Máquinas de Estados.
¿Cómo extendemos UML?
UML incluye tres construcciones principales de extensión:
Restricciones: una declaración textual de una relación

semántica expresada en un cierto lenguaje formal (OCL) ó en
lenguaje natural.
Estereotipos: una nueva clase de elemento del modelo, ideada

por el modelador, y basada en un tipo existente de elemento
del modelo.
Valores etiquetados: una porción de información con nombre,

unida a cualquier elemento del modelo.
Diagramas UML
State
State
Use Case Diagrams
Diagramas de
Use Case Diagrams State
Diagrams de
Use Case Diagramas Clases State
Diagrams
Use Case Casos de Uso Diagrams
Diagramas de
Diagrams de
Diagramas Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagrams de
Diagramas Diagrams de
Diagramas
Diagrams Diagrams
Comunicacion Modelo Componentes
Scenario Component
Scenario Component
Diagrams
Diagramas de
Diagrams de
Diagramas Diagrams
Diagrams
Estados Diagramas de Despliegue
Actividad
Diagrama de Casos de Uso
<<include>>
Reintegro Cuenta Corriente
Cliente Verificar Operación
<<include>>
Reintegro Cuenta de Crédito
Muestra las distintas operaciones que se esperan de un

sistema y cómo se relacionan con su entorno
Diagrama de Clases
Cliente
nombre
apellido
direccion
te
1 prof esion 1
usa tiene
1 0..*
CarritoCompra Ord enCom pra

es de
numero
1
tarjeta
1 1 direccionEntrega
opcionEntrega
tiene
1..*
EjemplarLibro
Items 0..* pertenecen
numero
cantidad
1 precio
1..* tiene
1
Lib ro
isbn
Autor
titulo esta esc rit o p or
editorial nomb re
soporte 1.. * 1..* ape llido
categoria
Muestra las distintas las clases atributos,

métodos y relaciones entre ellas
Diagramas de Secuencia (objetos)
: WInP réstamos :Socio :Video : Préstamo

: Encargado
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
Muestra la interacción de un conjunto de objetos

en una aplicación a través del tiempo
Diagrama de Comunicación (objetos)
:Socio
:Video
2: verificar situación socio
1: prestar(video, socio) 3: verificar situación video

:WInPréstamos
5: entregar recibo
: Encargado 4: registrar préstamo
:Préstamo
Muestra la forma de representar interacciones entre objetos,

Diagrama de Estados
fin
inicio alta baja
núm er o_prés tam os = 0

sin pr éstam os
estado
pres tar devol ver [ núm ero_p rést amo s = 1 ]
transición núm ero_prés t am os > 0
c on prés tam os
pres tar
devolver[ núm ero_prés tam os > 1 ]
Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una
aplicación, junto con los cambios que permiten pasar de un estado a otro
Diagrama de Actividad
Buscar Bebida [ no hay café ] [ no zumo ]
[ hay café ]
[ hay zumo ]
Poner café Añadir agua Coger taza

en filtro al depósito Coger
zumo
Poner filtro
en máquina
Encender
máquina
/ cafetera.On
Café en
preparación
indicador de fin
Servir café Beber
Muestran transiciones internas, sin hacer mucho énfasis en

transiciones o eventos externos.
Diagrama de Componentes
dependencias
Módulos
Servicios ofrecido por
Elementos otros componentes
físicos Inte rfaz de Termin al
Control y Análisis
por ejemplo
Archivos,
bibliotecas
Gestión de Cuentas Rutinas de conexión Acceso a BD
Muestra las dependencias lógicas entre componentes software

Diagrama de Despliegue
nodo
Servidor Central Control y Análisis
comunicación
Acceso a BD Comment
Comment
Rutinas de Coneccion
Comment
Terminal de Consulta
Interfaz de Terminal
Comment Comment
Punto de Venta
Comment
Gestión de Cuentas Interfaz de Terminal
Comment Comment
Muestran la organización de los componentes del sistema

Proceso de Unificado de
Desarrollo
Proceso Unificado de desarrollo
UML no es un proceso...
...UML es una notación
Por lo tanto precisa de un proceso de desarrollo (ciclo de

vida) que especifique la secuencia de actividades que
deben realizarse
Proceso Unificado de desarrollo/2
Ciclo de vida Ciclo de vida

en cascada en espiral
Proceso
Unificado
El Proceso Un
Proceso Unificado (PU)
<<include>>
Proceso de Desarrollo de Software

Conjunto de actividades para transformar los <<include>>
requisitos del usuario en un sistema software Reintegro Cuenta de Crédito
Proceso Unificado (UP) Cliente

nombre
apellido
direccion
te
1 prof esion 1
usa tiene
• Dirigido por Casos de Uso

1 0..*

es de
numero
1
tarjeta
• Centrado en la Arquitectura
opcionEntrega
tiene
1..*
• Iterativo e Incremental
EjemplarLibro
numero
cantidad
1 precio
1..* tiene
1
Lib ro
isbn
Autor
editorial nomb re
soporte 1.. * 1..* ape llido
categoria
El Proc
Dirigido por Casos de Uso
• Los casos de uso
representan los requisitos Reintegro Cuenta Corriente
<<include>>
funcionales y guían el
diseño, la implementación Cliente
<<include>>
Verificar Operación
y la prueba Reintegro Cuenta de Crédito
• Basándose en los casos

de uso los desarrollares Cliente
nombre
apellido
direccion
crean modelos de diseño e

te
1 prof esion 1
usa tiene
1 0..*
CarritoCompra
implementación que
Ord enCom pra
es de
numero
1
tarjeta
opcionEntrega
tiene
llevan a cabo los casos de

1..*
EjemplarLibro
numero
cantidad
1 precio
1..* tiene
uso
1
Lib ro
isbn
Autor
editorial n omb re
soporte 1.. * 1..* a pe llido
categoria
Centrado en la Arquitectura
• La arquitectura es una vista de
diseño con las características más
importantes, dejando los detalles ClienteOcacional ClienteEspecializado
profesion
de lado. Describe diferentes vistas

Client e
nombre
apellido
1 tiene OrdenCompra
direcci on 0..*
del sistema
te n umer o
ingresarDatos( ) 1 I ngr es arPre fer encia s()

1
es de 1 1
u sa 1
1
Car rito Com pra 1 1 1
• Constituyen la “forma del

1
Tarjeta DireccionCompra OpcionEntrega
agregarItem() tipo
n ombr e calle
v enta() n umer o numero
1
sistema”, incluye aspectos tiene
1..*
Ca teg ori a
tipo
estáticos y dinámicos
Ite ms
EjemplarLibro
cantidad 0..* pertenecen 1
nume ro
pertenec e
crear() 1 1..*
darPrecio()
subtotal() 1..*
tiene
1 Lib ro
Au tor isbn
1..* 1..* titulo
• La arquitectura y los casos de uso

nombre escrito por
apellido editorial
ConsultarLibro()
evolucionan en paralelo
Iterativo e Incremental/1
• Desarrollo iterativo:
El desarrollo se organiza en una serie de mini

proyectos de duración fija, llamados iteraciones (2 a 6
semanas)
• El resultado de cada uno es un sistema que puede ser

probado, integrado y ejecutado.
• Cada iteración incluye sus propias actividades de: análisis

de requisitos, diseño, implementación y prueba
Iterativo e Incremental/2
• El sistema crece incrementalmente a lo largo del tiempo,
iteración tras iteración.
• El resultado de cada iteración es un sistema ejecutable, pero

incompleto
• En general, cada iteración aborda nuevos requisitos y amplia el

sistema incrementalmente
• La salida de una iteración NO es un prototipo desechable, es un

subconjunto de calidad del sistema final
Disciplinas y fases
Disciplina: conjunto de actividades y
artefactos vinculados en una área
determinada: requisitos, diseño,
implementación, etc.
Fases: periodo de tiempo

entre dos hitos principales
de un proceso de
desarrollo
El P
Ciclo de desarrollo
punto en donde han de tomarse Sistema en ambiente de producción

decisiones importantes
Fases del Proceso Unificado
• Inicio: visión aproximada, incluye:
análisis del negocio, alcance,
estimaciones imprecisas
• Elaboración: visión refinada,

implementación iterativa del núcleo
central de la arquitectura,
resolución de riesgos altos,
identificación de más requisitos
• Construcción: implementación
iterativa del resto de requisitos de
El P
menor riesgo
• Transición: pruebas beta

Fase de inicio
Fase de inicio/1
Actividades a realizar (una o algunas)
• Visión y análisis del negocio (objetivos y restricciones de alto

nivel)
• Modelo de casos de uso (requisitos funcionales y no
funcionales relacionados)
• Especificaciones complementarias (otros requisitos)
• Listas de riesgos (del negocio, técnicos, etc.)
• Prototipos (para clarificar la visión)
• Plan de iteración (qué hacer en la primera iteración)
Fase de inicio/2
No se entendió la fase de inicio si...
• La duración es mayor a unas pocas semanas

• Se intenta definir la mayoría de los requisitos
• Se espera que los planes y la estimación sea fiable
• Se define la arquitectura
• No se identifican la mayoría de de los nombres de los
casos de uso y los actores
• Se escribieron todos los casos de uso en detalle
Fase de
elaboración
Fase de elaboración/1
Actividades a realizar
• Se descubren y estabilizan la mayoría de los casos de

uso
• Se reducen o eliminan los riesgos importantes
• Se implementan y prueban los elementos básicos de la
arquitectura
• Duración: 2 a 4 iteraciones con una duración de 2 a 6
semanas (dependiendo de la duración del proyecto)
Fase de Elaboración/2
Artefactos de la fase de elaboración
• Modelo del dominio (entidades del dominio)

• Modelo de diseño (diagramas de clases, de iteración.
etc)
• Modelo de datos
• Modelo de pruebas
• Modelos de implementación
El producto resultante no es un prototipo desechable

El código y el diseño son de calidad y se integran al sistema
final
Fase de Elaboración/3
No se entendió la fase de elaboración si...
• Sólo comprende una iteración

• La mayoría de los requisitos se definieron antes de la elaboración
• NO hay programación de código ejecutable
• Se intenta llevar a cabo un diseño completo antes de la codificación
• Los usuarios no se involucran en la evaluación
Fase de
construcción
Fase de Construcción
• Objetivos
• Terminar de construir la aplicación

• Realizar pruebas alfa
• Preparar pruebas beta (para la transición)
• Preparación de guías de usuario
• Preparación de materiales de aprendizaje
Fase de
transición
Fase de Transición
Objetivo: poner el sistema en producción
Actividades
• Realización de pruebas beta

• Reaccionar a la retroalimentación a partir de las pruebas beta
• Conversión de datos
• Cursos de entrenamiento
Bibliografía Básica
Larman C. UML y patrones. Una introducción al Análisis y

Diseño Orientado a Objetos y al Proceso Unificado. 2ª ed.
Madrid: Prentice-Hall; 2003.
Jacobson I. Booch G. Rumbaugh J. El Proceso de Desarrollo

Unificado. Addison-Wesley. 2000
Sugerencias
• Recuerde que cada fase, si bien pasa por todas las disciplinas (análisis, diseño, etc.) pone énfasis en
algunas de ellas más que en otras
• Valore la importancia de los casos de uso (unidad 3.1). A partir de ellos se crean todos los demás
modelos del sistema
• Tenga en cuenta que después de cada iteración (que corresponde aproximadamente a un ciclo de vida en
cascada) se va definiendo un sistema ejecutable, pero incompleto, que debe corroborar con el usuario
• Recuerde que inicio no es igual a requisitos, elaboración no es igual a análisis y construcción no es igual
a diseño, etc
• Recuerde que cada iteración tiene un duración fija de 2 a 6 semanas aproximadamente dependiendo de
la magnitud del proyecto
Auto evaluación/1
Comprendí los conceptos más importantes de la

unidad 2.1 si puedo definir y dar ejemplos de:
• Disciplinas / Fases
• Fase de inicio
• Fase de elaboración
• Fase de construcción
• Fase de transición
• Desarrollo iterativo e incremental
• Interpreto en el gráfico que significan las

“montañitas”
El Pr
Iterat
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 2.1, si
• Conozco por qué usamos modelos y no directamente codificamos
• Entiendo en qué etapas del proceso de desarrollo utilizo UML
• Entiendo la diferencia entre el ciclo de vida en cascada y el UP
• Comprendo la relación que existe entre disciplinas de UP y el ciclo de vida en cascada
• Entiendo qué tienen en común el ciclo de vida en espiral y el UP
• Comprendo en qué hacen énfasis cada una de las fases del UP
• Entiendo cuál es el producto final de cada iteración

2º parte
Proceso de desarrollo
“simplificado”
Comenzamos con
los casos de uso.
Inicialmente el nombre
y una descripción
El Proceso Reintegro Cuenta Corriente

<<include>>
Iterativo e
Primera Cliente
<<include>>
iteración Reintegro Cuenta de Crédito
ETAPA DE
INICIO
Describimos
los casos de uso con
mayor detalle.
<<include>>
<<include>>
El Proceso
Escenario principal
Iterativo e
El cliente ingresa a la pagina Web de CVLI
Primera iteración El cliente ingresa a la opción “registración “
El sistema solicita ingreso de los datos personales
ETAPA DE El sistema evalúa el país….
…..
ELABORACIÓN
Creamos los diagramas
de secuencia de sistemas
para cada caso de uso.
: SISTEMA
: cliente
ingresarSistema()
ingresarDatosPersonales ()
El Proceso
ingresarTarjetaCredito()
ingresarPreferenciasEnvio()
ingresarClaveContraseña()
DSS
"Registrarse
al sistema"
Iterativo e
Escenario principal
Primera iteración
ETAPA DE El cliente ingresa a la opción “registración “
ELABORACIÓN El sistema evalúa el país.
…..
Creamos el modelo
del dominio: CLASES,
ASOCIACIONES,
ATRIBUTOS
ClienteOcacional ClienteEspecia lizado
El Proceso
profesion
Client e
n ombre
a pellido
1 tiene OrdenCompra
d ireccion 0..*
te n umer o
ingresarDatos( ) 1 I ngr es arPre fer encia s()

1
es de 1 1
u sa 1
1
Car rito Com pra 1 1 1
1
Tarjeta DireccionCompra OpcionEntrega
agregarItem() tipo
n ombre calle
Iterativo e
v enta() n umero numero
1
tiene
Ca teg ori a
Primera iteración 1..*
Ite ms
cantidad 0..* pertenecen
EjemplarLibro
nume ro
tipo
1
pertenec e
crear() 1 1..*
darPrecio()
subtotal()
ETAPA DE
1..*
tiene
1 Lib ro
Au tor isbn
nombre 1..* 1..* titulo
escrito por
ELABORACIÓN
apellido editorial
ConsultarLibro()
Asignamos
responsabilidades
a las clases, asistidos
por los patrones de
ASIGNACION DE
RESPONSABILIDADES
El Proceso
: CarritoCompra
CarritoCompra
1: crear( parametros )
: Items
Iterativo e
venta()
Primera iteración
1
tiene
1..*
ETAPA DE
EjemplarLibro
Items
0..* pertenecen numero
cantidad
precio
1
ELABORACIÓN subtotal()
darPrecio()
Transformamos el
modelo de clases a
un modelo de
datos y luego al
modelo relacional
cod_ord
El Proceso
cod_cli
CLIENTE ORDENCOMPRA
1 N
1 1
cod_carro
1
1
CARRITOCOMPRA
Iterativo e
num_ejemp
N
N 1
Primera iteración
ITEMS EJEMPLARLIBRO
N
num_item
cod_autor cod_libro
ETAPA DE AUTOR
N N
1
LIBRO
ELABORACIÓN
Codificamos y
probamos.
Mostramos el ejecutable
al usuario
El Proceso
public class AdaptadorFigura extends Figura
{
Iterativo e
private int x;
Primera iteración public AdaptadorFigura()
{ variables
ETAPA DE x = 0; }
ELABORACIÓN }
Comenzamos una
nueva iteración
trabajando con
nuevos casos de
uso (o mejorando
los anteriores)
El Proceso
Segunda iteración
ETAPA DE
ELABORACIÓN
Iterativo e
Fin
3.1. Casos de uso
3.3. Diagramas de comunicación .
Introducción
Consideraciones Generales
EL paradigma OO se impuso por…
• Conceptos comunes de modelado a lo largo de todo el

ciclo de vida
• Reducción de la brecha entre el mundo de los problemas y

el mundo de los modelos
• Aumento de complejidad de los sistemas
• Aumento de la necesidad de reutilización
• Uso de patrones
Análisis, Diseño, Implantación
• El análisis OO pone énfasis en la investigación del problema y

los requisitos, en vez de ponerlo en la solución
• El diseño pone énfasis en una solución conceptual, que

satisface los requisitos, en vez de ponerlo en la implantación
• La implantación es la traducción de la solución a un lenguaje

de programación determinado
Análisis OO vs. Diseño OO
visualizacion de
• Durante el análisis OO se los conceptos
presta especial atención a concepto del del dominio
encontrar y describir los dominio
objetos (conceptos) del
dominio del problema Cliente
nombre
apellido
• Durante el diseño OO se
presta atención a la Cliente
definición de los objetos
software y en como
colaboran para satisfacer public class Cliente
los requisitos { private String nombre
representacion
private String apellido
en un lenguaje
de public void imprimirNombre()
programación …….. }
Análisis OO
• La finalidad del análisis OO es crear una descripción del

dominio desde una perspectiva de clasificación de objetos:
identificación de conceptos, atributos e interrelaciones
significativas
• El modelo del dominio NO es una descripción de los objetos

software, es una visualización de los conceptos del mundo
real y sus vinculaciones (se representan mediante diagrama
de clases, sin operaciones)
Abstracción y Encapsulamiento
La abstracción es la propiedad que permite representar las
características esenciales de un objeto, sin preocuparse de
las restantes características (no esenciales).
El Encapsulamiento es la propiedad que permite asegurar

que el contenido de la información de un objeto está
oculta al mundo exterior .
El encapsulamiento, al separar el comportamiento del objeto

de su implantación, permite la modificación de éste sin
que se tengan que modificar las aplicaciones que lo
utilizan
Clases conceptuales
• Una clase conceptual se puede Venta

considerar en términos de: fecha
hora
• Símbolo: palabras o imágenes que

representan la clase conceptual
Una venta representa

• Intensión: la definición de la clase
conceptual una transacción de
compra
• Extensión: el conjunto de ejemplos a

los que se aplica la clase conceptual
venta 1 venta 3
venta 2
Modelo del dominio
Análisis = descomposición de un dominio
de interés en clases conceptuales
Modelo del dominio = representación Especificacion

visual de las clases conceptuales del descripcion
mundo real precio
Se visualizan en el describe
modelo de dominio:
• Clases conceptuales Articulo
• Asociaciones entre clases conceptuales nroSerie
• Atributos de las clases conceptuales
Responsabilidades
• Una responsabilidad es un contrato u obligación de una clase
• Una clase puede tener cualquier numero de responsabilidades, pero

una clase bien estructurada debería tener al menos una y como mucho
unas pocas (alta cohesión)
• Las responsabilidades se describen inicialmente con texto libre
• Al ir refinando los modelos, las responsabilidades se traducirán en el

conjunto de atributos y operaciones que satisfagan esas
responsabilidades
(ver guía 5.1 Patrones de Diseño para Asignación de Responsabilidades)

Tarjetas CRC
(Colaboración-Responsabilidad-Clase)
Por cada clase describimos:
El nombre de la clase y su descripción

La responsabilidad de la clase
– Conocimiento interno de la clase
– Servicios brindados por la clase
Los colaboradores para las responsabilidades
– Un colaborador es una clase cuyos servicios son necesarios para una
responsabilidad
Usaremos una adaptación de las tarjetas CRC como primera aproximación

para luego refinar las clases en la etapa de diseño
Tarjetas CRC
El nombre de la clase: es importante que el nombre refleje la esencia de lo
que hace la clase
Las responsabilidades de la clase: determinan qué debe hacer. Estas
responsabilidades pertenecen, esencialmente, a dos categorías:
hacer y conocer
HACER
Hacer algo uno mismo.
Iniciar una acción en otros objetos.
Controlar y coordinar actividades en otros objetos
CONOCER
Conocer los datos privados encapsulados.
Conocer los objetos relacionados.
Conocer las cosas que se pueden derivar o calcular.
Las colaboraciones de la clase especifican con qué otras clases interactúan

Tarjetas CRC (adaptación)
Nombre de la clase: CURSO

Descripción: específica el curso….
RESPONSABILIDADES COLABORACIONES
HACER
Agregar un estudiante ESTUDIANTE
Conocer los prerrequisitos
Conocer cuándo el curso es dado

CONOCER
Conocer dónde es dado el curso
Diseño OO
• La finalidad del diseño OO es definir los objetos software

y sus colaboraciones (se utilizan en esta etapa diagramas
de interacción: comunicación y secuencia)
• A diferencia del modelo del dominio, este modelo no

muestra conceptos del mundo real, sino clases software,
con atributos operaciones y asociaciones
Objetos
“Un objeto es cualquier cosa real o abstracta, acerca de la

cual almacenamos datos y las operaciones que controlan
dichos datos”
Se opone al análisis estructurado donde los datos y el

comportamiento están débilmente relacionados
Tenemos que olvidarnos del modelo estructurado...

Propiedades de los Objetos
“El estado de un objeto abarca todas las propiedades
(normalmente estáticas) del mismo, más los valores actuales
(normalmente dinámicos) de cada una de esas propiedades”
“El comportamiento nos muestra como actúa y reacciona un

objeto, en términos de sus cambios de estado y paso de
mensajes”
“La identidad es aquella propiedad de un objeto que lo distingue

de todos los demás objetos”
Clases
Una clase especifica una estructura de datos y las operaciones
permisibles que se aplican a cada uno de sus objetos.
Los objetos se vinculan mediante enlaces enviando mensajes a operaciones

que activan los métodos
• Mensaje: es una solicitud para que se lleve a cabo la operación indicada
y se produzca el resultado.
• Operaciones: es una función o transformación que se aplica a un objeto

de una clase
• Métodos: es la implementación de una operación
“Un objeto es una instancia de una clase”

Relaciones de Asociación
“Se descompone (clases) para comprender, se une (asociación)
para contruir”
• Los enlaces entre objetos son instancias de la asociación

entre sus clases
• La asociación representa un acoplamiento débil, la

Agregación y la Composición expresa un acoplamiento más
fuerte en clases
Relaciones de Jerarquía
• La generalización consiste en factorizar los

elementos comunes de un conjunto de clases en
una clase más general llamada superclase
• La herencia es una técnica de los lenguajes de

programación para construir una clase a partir de
una o varias clases, compartiendo atributos y
operaciones
Polimorfismo/1
Permite la posibilidad de desencadenar operaciones diferentes en respuesta
a un mismo mensaje
Figura
Editor
dibujar()
mover()
Circulo Triangulo Rectangulo
dibujar() dibujar() dibujar()

mover() mover() mover()
el polimorfismo permite referirse a objetos de clases diferentes mediante el

mismo elemento de programa y realizar la misma operación de diferentes
formas, según sea el objeto que se referencia en ese momento.
Polimorfismo/2
La interacciones entre objetos se escriben según los términos de
las especificaciones definidas en las superclases
El método dibujar() no es igual

Figura para cada figura
Editor
dibujar()
mover()
Cada vez que se invoque el
método dibujar() dependerá de la
clase a la pertenece el objeto
dibujar()
unCirculo.dibujar();
dibujar() dibujar()
mover()
mover() mover() UnTriangulo.dibujar();
unRectangulo.dibujar();
Redefino en las subclases el

método dibujar()
Análisis Estructurado vs. Análisis
Orientado a Objetos
El enfoque tradicional del análisis y diseño

estructurados, se descompone el problema en
funciones o procesos y estructuras de datos
En un enfoque OO se busca descomponer el

problema, no en funciones, sino en unidades más
pequeñas denominadas objetos,
Beneficios del Enfoque OO
Disminución del bache semántico entre análisis y diseño
proveyendo una representación consistente en todo el ciclo de
vida
Enfoque OO
La transición del análisis al diseño es un refinamiento
Enfoque Estructurado
En la transición del análisis al diseño
pasamos del DFD al DE mediante un proceso heurístico no trivial

Sugerencias
• Cuando realice el análisis ponga énfasis en la investigación del problema y los requisitos
• Cuando realice el diseño ponga énfasis en una solución conceptual del problema
• En la etapa de análisis se realiza el Modelo del dominio (representación visual de las clases conceptuales
del mundo real)
• Realice una tarjeta CRC para comenzar a entender la clase propuesta (esta será refinada posteriormente
en la etapa de diseño)
• Si bien son conceptos vinculados, tenga presente la diferencia entre mensaje, operación y método
• Recuerde que la composición y la agregación son tipos particulares de asociaciones
• Tenga en cuenta que la generalización es un concepto que permite organizar estructuralmente las
abstracciones y la herencia es una técnica de los lenguajes de programación que permite implementarla
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 1.1 si puedo definir y dar
ejemplos de:
• Análisis OO / Diseño OO
• Modelo de dominio de la aplicación
• Abstracción / Encapsulamiento
• Estado / Comportamiento / Identidad
• Tarjetas CRC
• Mensaje / Operación / Método
• Asociación / Agregación / Composición
• Generalización / Herencia / Polimorfismo
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 1, si
• Comprendo la diferencia entre el análisis y diseño Estructurado y el OO
• Entiendo la diferencia entre análisis, diseño e implementación y que es lo que realizo en cada una de estas actividades
• Vinculo la etapa de análisis con la descripción del modelo de dominio de la aplicación
• Comprendo cual es el uso de las tarjetas CRC
• Entiendo cual es el objetivo de la abstracción y el encapsulamiento
• Entiendo la diferencia entre mensajes, operaciones y método
• Comprendo la diferencia entre asociación, agregación y composición
• Entiendo la diferencia entre generalización y herencia

Administrativos
Unidad 3.1 Casos de Uso

2008
3.1. Casos de uso
• ¿Por qué usamos modelos y no directamente codificamos?
• ¿En qué etapas del proceso de desarrollo utilizo UML?
• ¿Cuál es la diferencia entre el ciclo de vida en cascada y el UP?
• ¿Cuál es la relación que existe entre disciplinas de UP y el ciclo de vida en cascada?
• ¿Qué tienen en común el ciclo de vida en espiral y el UP?
• ¿En qué que hacen énfasis cada una de las fases del UP?
• ¿En qué termina cada iteración?

Casos de Uso
Ingeniería de Requisitos
• La Ingeniería de Requisitos direcciona el proceso de

elicitación, definición, modelado, análisis, especificación y
validación de los requisitos de un sistema y de su software,
basado en un enfoque sistemático, separando el "qué" del
"cómo" del diseño.
¿Qué es un Requisito?
• Flujo de trabajo fundamental cuyo proposito esencial es orientar el desarrollo

hacia el sistema correcto
• Esto se lleva a cabo mediante la descripcion de los requisitos del sistema de

forma tal que se pueda llegar a un acuerdo entre el cliente (usuario) y los
desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que
no
• El conjunto de todos los requisistos forman la base para el desarrollo del

sistema o el componente de sistema
Tipos de Requisitos
• Funcionales: especifica una acción que debe ser capaz de

realizar el sistema, sin considerar restricciones físicas
• No funcionales: especifica restricciones físicas sobre un

requisito funcional (rendimiento, plataforma, fiabilidad)
Requisitos y Casos de Uso
• Los casos de uso son una técnica para la especificación de

requisitos funcionales propuesta inicialmente por Jacobson
(1992)
• Los casos de uso presentan una ventaja sobre la descripción

textual de los requisitos funcionales
• Los casos de uso son, ante todo, requisitos funcionales
• A pesar de ser una técnica ampliamente aceptada, existen

múltiples propuestas para su realización
¿Qué es un caso de uso?
• Los casos de uso son una técnica que se utiliza para

documentar los requerimientos funcionales de un sistema desde
el punto de vista de los usuarios
• Los casos de uso responden a la pregunta: ¿Qué se supone que

el sistema debe hacer para los usuarios?
• Un caso de uso es un texto muy simple con cierto formato que

describe cómo se debería comportar un sistema ante la
interacción con uno o más usuarios
Los casos de uso no son “orientados a objetos”

Ventajas de los casos de uso
• Los casos de uso sirven como una forma de comunicación

entre personas de uno o varios equipos de trabajo, estimulando
la discusión acerca del comportamiento del sistema en
cuestión
• Los casos de uso sirven, por su simpleza, para validar los

requerimientos directamente con los (futuros) usuarios del
sistema
actor 2 <<extend>>
caso d e uso 2
caso de uso 1
<<include>> actor 1
caso de uso 4
caso de us o 3
El valor de los casos de uso está en su descripción detallada (no en

el dibujo…)
Casos de Uso
Describe tanto lo que hace el actor como lo que hace el sistema
cuando interactúa con él
Están acotados al uso de una determinada funcionalidad,

claramente diferenciada, del sistema
Un caso de uso realiza cierto trabajo cuyo efecto es tangible

para un actor
caso de uso
Actor
Casos de Uso - actores
Un actor es alguien o algo que interactúa con el sistema (una

persona, una organización, un programa o sistema de hardware o
software)
Un actor estimula al sistema con algún evento o recibe información

del sistema
Un actor es externo al sistema
Un actor cumple un rol definido (Ej.: Cliente, Banco, empleado)

Diagrama de Contexto
Permite determinar las fronteras del sistema
<< actor>>
TARJETA DE
0..1 CREDITO
0..*
secundario
Cliente
CVLI << actor>>
secundario
GESTOR
DE LIBROS
0..1
0..1
secundario << actor>>
Administrador Sistema 0..1 GESTOR

DE ENVIO
Tipo de Actores
Actores primarios: utilizan las funciones principales del sistema
Actores secundarios: efectúan tareas administrativas o de

mantenimiento
<< actor>>
TARJETA DE
0..1 CREDITO
0..*
secundario
Cliente
CVLI << actor>>
secundario
GESTOR
DE LIBROS
0..1
0..1

DE ENVIO
¿Cómo encontrar actores?
Una buena técnica para encontrar posibles actores es responder las

siguientes preguntas:
• ¿Quién usa el sistema?

• ¿Quién instala o mantiene al sistema?
• ¿Qué otros sistemas utilizan al sistema?
• ¿Quién recibe información del sistema?
• ¿Quién le provee información al sistema?
Caso de uso y Escenarios
Un caso de uso no trivial describe un conjunto de secuencias, no
una única secuencia. Es conveniente separar el flujo principal
de los flujos alternativos
Por ejemplo: el caso de uso Contratar Empleado podría tener variantes:

contratar externos (Escenario más frecuente) , traslado dentro de la misma
empresa, contratar extranjeros. Cada una de estas variantes se puede
expresar en una secuencia diferente
Cada secuencia específica del caso de uso se denomina

Escenario
Un escenario es una secuencia específica de acciones entre los

actores y el sistema (es una instancia de un caso de uso)
Caso de Uso y Colaboraciones
Un caso de uso captura el comportamiento esperado del sistema sin tener que
especificar cómo se implementará
Es importante separar el análisis (que especifica un comportamiento) de la

implementación (que especifica cómo se lleva a cabo ese comportamiento)
De todas maneras, un caso de uso deberá implantarse y esto lo hará mediante una
sociedad de clases (incluyendo su estructura estática y dinámica) que se modela
como una colaboración
Una realización especifica un contrato entre el caso de uso y su colaboración
Colaboración
hacer pedido
Caso de uso
gestion de Pedidos
Realización
Caso de Uso - asociación
Muestra la relación entre los actores y los casos de uso
Los actores sólo se pueden conectar a los casos de uso a través de

asociaciones que indican que el actor y el caso de uso se comunican
entre sí y que pueden enviar y recibir mensajes
• El actor inicia la • El actor recibe la

comunicación comunicación del
caso de uso
Relación <<include>>
Una relación de inclusión entre casos de uso especifica que un caso de
uso base incorpora explícitamente el comportamiento de otro caso de
uso en el lugar establecido en el caso de uso base
Una relación de inclusión se representa como una dependencia
Una dependencia es una relación de uso que declara que un caso de uso
utiliza información y servicios de otro
<<include>>
Caso de Uso A Ca so d e Uso B
El caso de uso A incluye en su

funcionalidad el caso uso B
¿Cuándo se utiliza include?
Cuando un caso de uso incorpora explicitamente el comportamiento de otro
caso de uso
Para evitar repeticiones de descripción de flujos de eventos
Cuando distintos casos de uso poseen un conjunto de eventos con la misma

funcionalidad, estos eventos se pueden factorizar en un nuevo caso de uso,
el cual se relacionará con los anteriores mediante la relación de inclusión
Cuando un caso de uso es muy extenso y difícil de leer
Se entiende que algunos de los pasos en una situación dentro de un Caso

de Uso son los mismos que los de otro Caso de Uso, y en lugar de listar
los mismos pasos, tan sólo indicamos el Caso de Uso de donde
provienen
Relación <<extend>>
Una relación de extensión entre casos de uso especifica que un caso de
uso base incorpora implícitamente el comportamiento de otro caso de
uso en el lugar especificado por el caso de uso base que extiende. Se
representa mediante una dependencia
La funcionalidad de un caso de uso incluye un conjunto de pasos que

ocurren sólo en algunas oportunidades
La excepción consiste en interrumpir el caso de uso B y pasar a ejecutar

otro caso de uso A
<<extend>>
Caso de Uso B Caso de Uso A
El caso de uso B (caso de uso base) incluye en su

funcionalidad (opcionalmente) el caso uso A
Relación <<extend>>
En la relación de extensión, existe un caso de uso base el cual puede se
extendido por otro caso de uso
La extensión se realiza a partir de los puntos de extensión y éste caso de uso es

utilizado en esos puntos si se cumple una condición
El caso de uso base no necesita nombrar al o a los casos de uso que lo

extienden
El caso de uso que extiende, nombra al caso de uso base, nombra al o a los
puntos de extensión e incluye la condición que determina si se toma o no
la extensión.
Se entiende que se agregan pasos a un Caso de Uso existente, y esto se hace

creando un nuevo Caso de Uso, que enriquece al existente, pero no lo
modifica.
¿Cuándo se utiliza extend?
Se puede utilizar para:
Cuando se desea describir una variación del comportamiento normal

de un caso de uso.
Para conjuntos de eventos que son ejecutados solamente en ciertos

casos.
Cuando la sección de flujos alternativos de un caso de uso se torna

muy grande y difícil de leer, es conveniente crear nuevos casos de
usos a partir de estos flujos alternativos que extiendan al caso de
uso original.
El caso de uso que
Ejemplo/1 extiende, nombra al
caso de uso base,
nombra a el o a los
puntos de extensión e
incluye la condición
Caso de uso que determina si se
base toma o no la extensión.
<<extend>>
Pago con Vale Regalo
Procesar Venta
El caso de uso base

no necesita caso de uso que
nombrar a el o a los extiende
casos de uso que lo
extienden
Ejemplo/2
Caso de
uso base
Caso de uso PROCESAR VENTA
Punto de extensión: pago, paso 7
Escenario principal
1. el cliente llega al puesto de venta con mercaderías para comprar
….
…. Puntos de
7. El cliente paga y gestiona el pago extensión
Caso de uso PAGO CON VALE REGALO

Condición: el cliente quiere pagar con vale regalo
Puntos de extensión: pago en PROCESAR VENTA
Escenario principal Caso de
1. el cliente le da el vale regalo al cajero
2. … Uso que
extiende
condición
Pre y Post Condiciones
Pre condiciones: establece lo que siempre debe cumplirse antes de

comenzar un caso de uso. No se prueban en el caso de uso, se
asumen que son verdaderas
Post condiciones: establece qué debe cumplirse cuando el caso de

uso se completa con éxito
Plantilla básico para descripción de CdeU
• Nombre de caso de uso

• Resumen
• Actores
• Fecha de creación:
• Fecha de actualización:
• Versión
• Pre condición
• [Punto de extensión] (si fuera necesario)
• [Condición] (si fuera necesario)
• Escenario principal
• Flujo alternativo
• Post condición
Los Casos de uso y las fases en el UP
• En la fase de inicio se reconocen

las mayoría de los casos de uso,
pero no su descripción detallada
• En la fase de elaboración, se
refinan en las sucesivas iteraciones
• En la fase de construcción, se
escriben casos de uso menores
• En la fase de transición, no se
describen casos de uso
El P
un ejemplo...
Consultar libros Consultar noveda des Consultar ofertas

en general
<<extend>>
<<extend>>
<<extend>>
Consultar libro
Cliente
un ejemplo...
Con sultar l ib ros Consultar novedades Consultar ofertas

e n gen eral
<<exte nd>>
<<e xtend>>
<<extend>>
<<include>> <<include>>
Consultar libro
buscar libros
comprar libro
Cliente
Comenzamos con el caso práctico...
Compañía de Ventas de Libros por Internet (CVLI)
(Descripción sintética del Sistema)
• El cliente accede a la información sobre los libros a través de la Web

• El cliente elegirá un nombre de usuario y una clave como método de
autentificación para efectuar las transacciones
• El cliente podrá realizar búsquedas por autor, título o ISBN
• El cliente debe estar previamente registrado
• El cliente puede establecer preferencias de envío
• El cliente puede introducir opciones de empaquetado
• La librería deberá recoger los datos de los pedidos
• La librería deberá rearmar en uno único los pedidos aislados que estén dentro
del plazo de 90 minutos
• La empresa puede realizar envíos parciales en función de la disponibilidad de
los ítems
Identificación de los actores
• Cliente (primario)
• Administrador del sistema (primario)
• Tarjeta de crédito (secundario)
• Gestor de libros (secundario)
• Gestor de envío (secundario)
Diagrama de Contexto
Permite determinar las fronteras del sistema
<< actor>>
TARJETA DE
0..1 CREDITO
0..*
secundario
Cliente
CVLI << actor>>
secundario
GESTOR
DE LIBROS
0..1
0..1

DE ENVIO
Identificación de los Casos de Uso
Cliente
Registrarse al sistema
Consultar libro
Comprar libro
Establecer preferencias de envío y empaquetado
Administrador del sistema

Armar pedidos
Rearmar pedidos
Registrarse al sistema
Gestor de Lib ros
Consultar libro
Tarjeta de Credito
Cliente
Comprar libro Armar pe dido s
Rearmar pe didos Administrador del

Establecer preferencias
Sis tema
de envío y empaquetado
Descripción de los Casos de Uso
Nombre de caso de uso: Registrarse al sistema

Resumen: el cliente, antes de realizar una primera transacción de
compra o búsqueda de libros, debe introducir todos sus datos
por única vez, los cuales serán guardados por el sistema y éste
le ofrecerá la posibilidad de tener una clave y contraseña que
utilizará para cada transacción que realice posteriormente, el
cliente tendrá la posibilidad de hacer cambios en los datos
introducidos, incluso en su clave y contraseña
Actores: cliente (primario), tarjeta de crédito (secundario)
Titulo: Consultar libro

Resumen: el cliente, una vez ingresado al sistema, podrá
navegar por el mismo en búsqueda de libros, novedades,
ofertas, etc.
Actores: cliente (primario), gestor de libros (secundario)
Titulo: Comprar libro

Resumen: el cliente, una vez ingresado al sistema, podrá
realizar compras de libros, eligiéndolo de una lista ofrecida
por la empresa, cada libro elegido, se sumará a una carrito
de compra, etc. El cliente informará el número y tipo de
tarjeta de crédito para realizar el pago. Deberá especificar
dirección de envió y forma de pago
Actores: cliente (primario), gestor de libros (secundario),
tarjeta de crédito (secundario)
Refinamiento: include y extend
Consultar libros Consultar novedades Co ns ultar o fertas

en general
<<e xtend>>
<<extend>>
<<extend>>
Gestor de Libros
Consultar libro
Cliente
<<include>>
Tarjeta de Credito
Comprar libro
<<extend>>
Establecer preferencias
de envío y em paqueta do
Desarrollo de un Caso de Uso
Nombre de caso de uso: Registrarse al sistema
Resumen: el cliente, antes de realizar una primera transacción de compra o

búsqueda de libros, debe introducir todos sus datos por única vez, los cuales
serán guardados por el sistema y éste le ofrecerá la posibilidad de tener una
clave y contraseña que utilizará para cada transacción que realice
posteriormente, el cliente tendrá la posibilidad de hacer cambios en los datos
introducidos, incluso en su clave y contraseña
Actores: cliente (primario), tarjeta de crédito (secundario)
Fecha de creación:
Fecha de actualización:
Versión:
Pre condición: el cliente ingresa al sistema por primera vez

Escenario principal
1. El cliente ingresa a la pagina Web de CVLI

2. El cliente ingresa a la opción “registración “
3. El sistema solicita ingreso de los datos personales: nombre y apellidos, dirección, localidad, código postal, país
4. El cliente ingresa los datos personales
5. El sistema evalúa el país de origen y solicita ingreso de los datos de la tarjeta de crédito: tipo de tarjeta, número,
fecha límite de validez
6. El cliente ingresa datos de la tarjeta de crédito
7. El sistema chequea el número de la tarjeta de crédito
8. El sistema (teniendo en cuenta el país de origen) solicita la opción de preferencia de envío por omisión, esta opción
puede modificarse en cada envío
9. El cliente ingresa preferencia de envío
10. El sistema solicita, para finalizar, el ingreso de la clave de acceso y la contraseña
11. El cliente ingresa clave y contraseña
12. El sistema solicita reingreso de contraseña
13. El cliente reingresa contraseña
14. El sistema informa que la transacción se realizo correctamente
Flujo alternativo
A1 Ingreso incorrecto de los números de los datos

La secuencia comienza en el punto 4 del escenario principal
5. El sistema informa que los datos ingresados son incorrectos
6. El sistema pide ingreso de números nuevamente
El escenario vuelve al punto 5
A2 Ingreso incorrecto de los números de la tarjeta de crédito

La secuencia comienza en el punto 7 del escenario principal
7. El sistema informa que los números ingresados son incorrectos
8. El sistema evalúa si la cantidad de veces que ingreso el numero de tarjeta en forma incorrecta es menor a
3
9. El sistema pide ingreso de números nuevamente
El escenario vuelve al punto 8
Poscondición: el cliente está registrado en el sistema

Sugerencias
• Utilice la plantilla modelo de casos de uso. Ayuda a entender las partes
componentes
• Recuerde que los casos de uso son texto, el gráfico sólo nos brinda una visión
general
• Piense al caso de uso como una comunicación entre el actor y el sistema (no en
cómo resolverá el sistema el problema planteado)
• Los flujos alternativos pueden ser errores o excepciones (no relaciones de

extensión)
• Utilice las relaciones de extensión e inclusión en una etapa posterior de

refinamiento. Al principio céntrese en comprender bien el caso de uso
• Describa el flujo de eventos lo suficientemente claro para que alguien externo al

sistema lo pueda entender
• Amplíe la funcionalidad del caso de uso en cada iteración del proceso de
desarrollo
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 3.1 si puedo

definir y dar ejemplos de:
• Requisitos funcionales y no funcionales

• Escenarios
• Escenario principal
• Flujo alternativo
• Colaboraciones
• Relación de inclusión
• Relación de extensión
• Pre y post condiciones
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 3.1, si:
• Entiendo que lo más importante de los casos de usos es la descripción detallada de la

interacción actor-sistema. No el gráfico
• Comprendo qué es un escenario y lo vinculo con las relaciones de extensión e inclusión
• Entiendo qué es una colaboración y vinculo este concepto con la realización de un caso de uso
• Entiendo qué describe una pre y una post condición
• Comprendo cuándo usar una relación de inclusión y cuándo una extensión
• Comprendo que las relaciones de extensión e inclusión corresponden a una etapa de

refinamiento
• FIN
Administrativos
Unidad 3.2
Diagrama de Clases

2008
3.1. Casos de uso
3.3. Diagramas de colaboración.
• ¿Qué es un escenario y cómo lo vinculo con las relaciones de
extensión e inclusión?
• ¿Qué es una colaboración y cómo vinculo este concepto con la

realización de un caso de uso?
• ¿Qué describe una pre y una post condición?
• ¿Cuándo debo usar una relación de inclusión y cuándo una extensión?
• ¿Comprendo que las relaciones de extensión e inclusión corresponden

a una etapa de refinamiento?
Clases
Las clases representan los bloques de construcción más importantes de cualquier
sistema orientado a objetos.
Una clase es una descripción de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semántica.
Los lenguajes de programación OO soportan directamente el concepto de clase
public class Cliente

Cliente
{ private String nombre;
nombre
private String apellido;
apellido
public void imprimirNombre() { };
imprimirNombre() … }
Atributos y Operaciones
Un atributo es una propiedad de una clase
que es compartida por todos los
elementos de esa clase
Una clase puede tener cualquier número de

atributos o no tener ninguno Compartimiento para Nombre de Clase
nombre de clase
atributo 1
Compartimiento para atributo 2
atributos atributo n
Una operación es una abstracción de algo
que se puede hacer a un objeto y que es Compartimiento para operacion 1()
compartido por todos los objetos de la operaciones operacion 2()
clase operacion n()
Una clase puede tener cualquier numero de

operaciones o ninguna
Visibilidad de Atributos y Operaciones
• Visibilidad pública (Public +): cualquier
clase externa puede utilizar la
característica Nombre de Clase
atributo 1
• Visibilidad privada (Private -): solo la atributo 2
atributo n
propia clase puede utilizar la característica
operacion 1()
• Visibilidad protegida (Protected #): operacion 2()
cualquier descendiente de la clase puede operacion n()
utilizar la característica
• Visibilidad de paquete (package ~) solo los

que estén declarados dentro del paquete
pueden utilizar la característica (-) visibilidad privada
(#) visibilidad protegida
(+) visibilidad pública
(~) visibilidad paquete
Descripción de atributos y operaciones
Atributo
Visibilidad [/] nombre : tipo = valor inicial
ejemplo - temperatura : integer = 0
Calentador
Operación
temperatura : Integer = 0
Visibilidad nombre (lista parámetros ) : tipo de BuscarValor(n : integer) : Integer

expresión retornada
ejemplo +BuscarValor (n: integer) : integer

Instancias de clases: objetos
Una instancia es la manifestación concreta de una abstracción a la que se le

pueden aplicar un conjunto de operaciones y posee un estado que
almacena el efecto de las operaciones
Clase Usuario
¿Cómo se grafican los
objetos?: Usuario
dos puntos, nombre de la
clase, subrayado
:CLASE Objetos Usuario
: Usuario : Usuario
Clases abstractas
Son clases que no pueden ser instanciadas, se utilizan en jerarquías de

generalización. Las clases abstractas tienen, al menos, una operación
abstracta.
Una operación abstracta tiene que ser implementada por algún método en
un nivel más bajo de abstracción
Nombre en
cursiva
Figura
calcularSuperficie()
Cuadrado
Triangulo
calcularSuperficie()
Interfaz/1
Una interfaz es una colección de operaciones que especifican un servicio de una clase o un
componente
Específica el comportamiento visible externamente de la clase
Una interfaz define un conjunto de especificaciones de operaciones (su signatura) pero no

su implementación
La interfaz es parecida a la clase abstracta, ninguna de las dos pueden tener instancias
directas, no obstante una clase abstracta puede tener operaciones concretas.
Una interfaz es como una clase abstracta donde todas las operaciones también son abstractas
Interfaz/2
La realización es una relación entre clasificadores
La realización se emplea para especificar la relación que existe entre una interfaz
y la clase que proporciona la operación
Permite “simular” herencia múltiple

Defino la
operación <<Interfac e>>
imprimir para Matriz
Imprimible
muchas clases
im primir()
Realización
Vector MatrizCuadrada
Cada clase la
implementa imprimir() imprimir()
como
corresponde
Relaciones/1
• Las clases no se encuentran aisladas, existen tres tipos principales
de relaciones:
– Dependencias: relaciones de uso entre clases

– Asociaciones: relaciones estructurales entre clases
– Generalizaciones: conectan clases generales con sus
especializaciones
dependencia
Ventana
abrir() Evento
cerrar()
mover()
dibujar() asociación
generalización
VentanaDeConsola VentanaDE Dialogo Control

Relaciones/2
Asociación
Agregación
Composición
Generalización
Dependencia
Realización
Dependencias
• Una dependencia es un relación de uso que declara que un elemento utiliza
información de otro elemento
• En general se utilizan el contexto de las clases para indicar que una clase utiliza las
operaciones de otra o utiliza variables o parámetros cuyo tipo viene dado por la otra
clase
• En los diagramas de clase, se utilizan para describir la visibilidad entre clases que no
es de tipo atributo
la operacion reproducirEn utiliza

un parametro del tipo Canal
PeliculaDeVideo
nombre
Canal
reproducirEn(c : Canal)
iniciar()
parar()
Asociaciones
• Una asociación es una relación estructural que específica que los objetos
de una clase están conectados con objetos de otra (que puede ser la
misma)
• Son relaciones entre clases que indica alguna conexión significativa que
deseamos preservar durante algún tiempo
Nombre de rol
jefe empleado patron

Persona Empresa
1 1.. * *
trabaja Para >
1..* operario
Asociación binaria
dirige A > multiplicidad
Asociación unaria
Asociaciones – nombre de rol
Nombre de rol: cada objeto juega un rol específico en la asociación
por ejemplo, en la asociación binaria trabaja Para, un objeto Persona, juega el rol de empleado
En la asociación unaria dirige A, un objeto Persona puede jugar el rol de operario o de jefe
jefe empleado patron

Persona Empresa
1 1.. * *
trabaja Para >
1..* operario
dirige A >
Asociaciones – multiplicidad de rol/1
Multiplicidad: define cuántas instancias de una clase A pueden asociarse con
una instancia de una clase B
Representa un rango de enteros que especifican el tamaño posible del conjunto

de objetos relacionados (v gr.: 0..1; 1..1; 0..*; 1..*)
El valor de la multiplicidad indica cuántas instancias se pueden asociar con

otras en un momento concreto
Un artículo se vende en
una tienda
Tienda Articulo
1 1..*
una tienda puede tener uno o

muchos artículos
Asociaciones – multiplicidad de rol/2
1
Exactamente
Uno:
A B
0..1
Cero o Uno:
A B
0..*
Cero o Muchos: A B
1..*
Uno o Más: A B
Número Exacto: A B
0..1,3..5,7..9
Lista: A B
Rango: 3..6
A B
Asociaciones - Agregación
• Este tipo especial de asociación
Todo
modela una relación
TODO/PARTE
• Es un tipo de asociación más Computadora

fuerte
0..*
• Es una relación no simétrica
entre clases donde uno de los 0..1
extremos cumple un rol Impresora
dominante
Parte
Asociaciones - Composición
• La composición es una forma de agregación con una fuerte relación de pertenencia y
vidas coincidentes de la parte con el todo
• Dependencia existencial. El elemento dependiente desaparece al destruirse el que lo

contiene
• Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva
y vital del que lo contiene
• Los objetos contenidos no son compartidos
Computadora
1
1 1
CPU Monitor Teclado
Clase Asociación
Una asociación puede representarse por medio de una clase que permite
añadir, por ejemplo, atributos y operaciones
empleador
empresa 1..* empleado
1..* empleado
cargo
nombre
sueldo
Por ejemplo, debido a la multiplicidad, el nombre del cargo y el sueldo no pueden

pertenecer a la empresa o al empleado; son atributos de la asociación
Instancia de Asociación: enlace
asociación
empl eado empleado empleador empresa
trabaja para
1..* 1
(emp1, em) enlace

em : empresa
emp1 : empleado
emp2 : empleado (emp3, em)
emp3 : empleado
(emp2, em)
cada instancia de una asociación (enlace) es una tupla de

referencias a objetos
Asociaciones – navegación
La navegación indica que en una asociación es posible navegar de los objetos de un

tipo a los de otro. Esto es debido a que el objeto inicial almacena alguna
referencia del objeto navegable
La navegación es el enunciado del conocimiento de una clase respecto a otra
Dirección de
navegación
Usuario Clave
1 *
Asociaciones – visibilidad de rol
Dada una asociación entre clases, los objetos de una clase pueden ver y navegar hasta los objetos de
otra a menos que se restringa específicamente
La visibilidad privada indica que los objetos de ese extremo no son accesibles a ningún objeto
externo a la asociación
por ejemplo, un objeto Clave es accesible a un objeto Usuario pero no a un objeto GrupoUsuarios
GrupoUsuarios * * Usuario 1 * Clave
+usuario +propietario -clave

Generalización
La generalización es una relación entre un elemento general (llamado superclase o padre )
y un tipo más específico de ese elemento (llamado subclase o hijo)
El hijo puede añadir nueva estructura y comportamiento o modificar el comportamiento del

padre
La generalización consiste en factorizar los elementos comunes de un conjunto de clases en

una clase más general llamada superclase
superc lase Figura

color
dibujar()
mover() subclases
dibujar() dibujar() dibujar()

mover() mover() mover()
Paquetes/1
• Un paquete es un mecanismo de propósito general para organizar el modelo de
manera jerárquica
• Ayudan a organizar los elementos de modelado con el fin de comprenderlos.

Los paquetes pueden tener dentro otros paquetes
• Los paquetes tienen un nombre que los identifica, el nombre puede ser simple
o calificado (cuando le precede el nombre del paquete donde se encuentra)
Cliente Departamento::Cliente
Paquetes/2
¿Cuáles son las ventajas de utilizar Paquetes?
– Evitar conflictos de nombres.
– Facilitar el reconocimiento y búsqueda de elementos de

acuerdo a una funcionalidad específica.
– Controlar el acceso a sus contenidos.
– Todos los mecanismos de extensibilidad de UML se aplican

a los paquetes.
ejemplo
Autor Ubicacion
nombre estanter ia
apellido estante
fechaNacimiento tr amo
Soporte 1..*
situadoEn 1
1..*
registradoEn escritaPor
1..* 1
Ejemplar
1..* obra estaEditadoEn
numero
titulo
1 1..*
Libro Vi deo colocar()
1..* Prestamo
prestadoA fecha
duracion
1..*
Socio
nombre
apellido
ObraInterpretada ObraNoInterpretada direccion
prestar()
1..*
interpretadaPor
1..*
Interprete
Sugerencias
En la descripción de las clases del dominio del problema
– Identificar las clases y sus asociaciones más importantes

– Incluir los atributos más importantes
– No preocuparse inicialmente por las operaciones (corresponde a la etapa de diseño)
– No pensar en jerarquías (al principio...)
En una etapa de refinamiento (ver proceso de desarrollo) incluir
– Relaciones de jerarquía Clase/subclase

– Agregaciones y composiciones
– Patrones de diseño Larman
– Patrones de diseño Gamma (opcional)
– Restricciones OCL (opcional)
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 3.2. si puedo definir
y dar ejemplos de:
• Clase
• Clase abstracta
• Interfaz
• Operación y atributos de clases
• Dependencias
• nombre de rol y multiplicidad
• Asociación / agregación / composición
• Generalización
• Paquetes
Auto evaluación/2
• Entiendo las diferencias entre clase, clase abstracta e interfaz
• Comprendo cuál es el objetivo de establecer una visibilidad determinada en atributos y operaciones y lo relaciono
con el concepto de encapsulamiento
• Entiendo la diferencia conceptual entre agregación y composición y que ambas son tipos especiales de asociaciones
• Comprendo que el concepto de objeto y enlace son análogos
• Comprendo cómo y para qué utilizo las clases abstractas en las relaciones de generalización
• Entiendo cómo una clase hijo puede ampliar y/o modificar el comportamiento establecido en la clase padre
• Comprendo cómo usar los paquetes para organizar los elementos de modelado
Implementación básicas de las
abstracciones
Clases, clases abstractas, generalización
public abstract class A{

// definición de atributos
private tipo A;
A
// definición de operaciones
a
public void b1() {}
}
a1()
B
b
public class B extends A{
// definición de atributos b1()
private tipo b;
public void b1() {}
}
Interfaz
public interface A{
<<Interface>>
void operación();
A
}
operacion()
public class B implements A{
B // definición de atributos
private tipo b;
b
// definición e implementación
operacion() // de operaciones
public void operacion() {}
}
Asociación 1..1
A -rol-b B
a b
1 1
public class A{ public class B{

// definición de atributos // definición de atributos
private tipo a; private tipo b;
// referencia a B mediante un atributo }
// del tipo B
private B rol-b;
}
Asociación 1 a muchos
A -rol-b B
a b
1 1.. *
public class A{ public class A{

private tipo a; private tipo a;
// * opción 1 * // * opción 2 *
// referencia al conjunto de objetos B // referencia al conjunto de objetos B
// mediante un vector // mediante un arreglo
private Vector rol-b = new Vector(); private B rol-b[] = new B[n];
} // “n” valor a definir
}
public class B{
private tipo b;
}
Asociación muchos a muchos
(tienen problemas de integridad a resolver mediante código)
A B
a b
1..* 1..*
public class A{ public class B{

private tipo b; private tipo b;
// referencia al conjunto de objetos C // referencia al conjunto de objetos C
// mediante un arreglo // mediante un arreglo
private B a[] = new B[n]; private A a[]= new A[n];
} }
Clase asociación (una versión)
(tienen problemas de integridad a resolver mediante código)
A B
public class A{
a b
1..* 1.. * // definición de atributos
private tipo a;
C // referencia al conjunto de objetos C
c
// mediante un arreglo
private C c[] = new C[n];
}
A C B
a c b
1 1..* 1..* 1
public class C{
public class B{
private tipo c;
// referencia al objeto C
private tipo b;
// mediante atributos
// referencia al conjunto de objetos C
private B b;
// mediante un arreglo
private A a;
private C c[]= new C[n];
}
}
FIN
Administrativos
Unidad 3.3 - 3.4
Diagrama de Secuencia y Comunicación

2008
3.1. Casos de uso
• ¿Cuáles son las diferencias entre clase, clase abstracta e interfaz?
• ¿Cuál es el objetivo de establecer una visibilidad determinada en atributos y operaciones y lo

relaciono con el concepto de encapsulamiento?
• ¿Cuál es la diferencia conceptual entre agregación y composición y que ambas son tipos
especiales de asociaciones?
• ¿Porqué el concepto de objeto y enlace son análogos ?
• ¿Cómo y para qué utilizo las clases abstractas en las relaciones de generalización ?
• ¿Cómo una clase hijo puede ampliar y/o modificar el comportamiento establecido en la clase
padre?
• ¿Cómo uso los paquetes para organizar los elementos de modelado?

Diagramas de interacción
Muestran el modo en que los inst1 : 1: mensaje1

ClaseA
objetos se comunican entre sí,
enviándose mensajes
2: mensaje2 inst2 :
ClaseB
• DIAGRAMA DE
COMUNICACIÓN: enfatiza
la organización estructural de
los objetos inst1 : ClaseA inst2 : ClaseB
1: mensaje1
• DIAGRAMA DE
SECUENCIA: hace énfasis en 2: mensaje2
la ordenación temporal
Relación entre diagrama de clases y de
interacción
clase B
clase A
metodoA() Diagrama de secuencia
Diagrama de clases : clase A : clase B
1: metodoA( )
Si un objeto envía un mensaje a

otro objeto, quiere decir que sus
clases respectivas están
relacionadas en el diagrama de Diagrama de Comunicación
clases (asociación o 1: metodoA( )
dependencia) y debe haber : clase A : clase B
visibilidad de una hacia la otra

Notación general
: Empleado e1 : Empleado
Empleado
clase instancia Instancia

nombrada
Sintaxis de mensaje
Retorno:= mensaje(parametro:tipoParametro):tipoRetorno
Ejemplo
valor:= pago(cantidad:integer):integer
Diagrama de Secuencia
Diagrama de Secuencia/1
Definición:
Un diagrama de secuencia destaca la ordenación temporal de los mensajes.
Sintaxis:
[Número de secuencia] [condición] * [expresión iteración] [valor de retorno :=] nombre

del mensaje (parámetros)
Diagrama de Secuencia/2
• Muestran interacciones entre objetos según un punto de vista temporal.
• Representa una interacción entre objetos poniendo énfasis en la cronología

de los envíos de mensajes
Envió
sincrónico
objeto
(Emisor
mensaje bloqueado)
destinatario
Periodo de
actividad emisor
Mensaje al mismo
objeto
Iteración
v: Vendedor :LíneaProducto
*[1..8] verificarLínea()
Sintaxis:
* [expresión-iteración ]
mensaje
Creación de objetos
Mensaje de creación
de objetos
: Registro : Venta
1: realizarPago( )
2: create( ) : Pago
Ejemplo de diagrama de secuencia
Diagrama de Secuencia de Sistema (DSS)
• Los diagramas de secuencia de sistema se utilizan en la etapa de análisis
para documentar casos de uso
• El actor genera eventos sobre el sistema, normalmente solicitando alguna

operación como respuesta
• Deberíamos hacer un DSS por cada escenario…

Sistema representado
como un sólo objeto
Actor del (caja negra)
Caso de uso
Identifico mensajes
hacia el sistema
en el caso de uso
Diagrama de Secuencia del Sistema
• Muestra, para un escenario específico de un caso de uso, los
eventos que generan los actores externos
• Los sistemas se tratan como cajas negras
• Muestran los mensajes que podrían ser traducidos a

operaciones dentro del sistema
(y serán distribuidos, en la etapa de diseño, a los objetos del

sistema)
Ejemplo de DSS
A los mensajes
los extraemos
del caso de uso
Se puede mostrar,
opcionalmente, la
Los mensajes los respuesta del
nombramos sistema
independientemente de
la implementación
Seguimos con el ejemplo
• El sistema (si estuviera compuesto por una sóla clase) podría tener, por
ahora, las siguientes operaciones ...
Operaciones que
SISTEMA serán asignados
ingresarSistema() a las clases en la
ingresarDatosPersonales() etapa de diseño
ingresarClaveContraseña()
•Esto nos brinda una primera aproximación de las posibles operaciones,

no implica necesariamente que serán ellas las operaciones del sistema
(estamos en una epata inicial...)
Resumiendo…
: SISTEMA
SISTEMA
: cliente ingresarSistema()
ingresarSistema() ingresarDatosPersonales()
ingresarDatosPersonales () ingresarClaveContraseña()
ingresarClaveContraseña() Cliente
nombre
apellido
direccion
te
1 prof esion 1
DSS usa tiene
"Registrarse
1 0..*
al sistema"
es de
numero
1
tarjeta
opcionEntrega
tiene
Los operaciones de la “clase sistema”, deberán 1..*
estar distribuidas entre todas las clases del sistema

EjemplarLibro
numero
cantidad
1 precio
con los criterios que nos darán los patrones de 1..* tiene
asignación de responsabilidades 1
Lib ro
isbn
Autor
editorial n omb re
soporte 1.. * 1..* a pe llid o
categoria
Diagramas de Comunicación
Diagramas de Comunicación/1
Definición:
Un Diagrama de Comunicación destaca la organización
estructural de los objetos participantes y el envío de mensajes.
Sintaxis:
Número de secuencia [condición] *[expresión iteración]: [valor de retorno :=]
nombre del mensaje ([parámetros])
Diagramas de Comunicación/2
• Muestra las interacciones organizadas en torno a los objetos y los enlaces entre
ellos
• Lo utilizamos en la fase de diseño para asignar responsabilidades a las clases

(definir dónde ubicar las operaciones)
Enlaces
• Un enlace es una
conexión entre objetos,
indica que es posible
inst1 :
alguna forma de ClaseA
1: mensaje1
navegación o visibilidad enlace
entre los objetos
• Un enlace es una 2: mensaje2 inst2 :

ClaseB
instancia de una
asociación
Representación de los Mensajes
Representación de los Mensajes
Iteración sobre una colección
1: *st:=getSubtotal
: Venta : LineaDeVenta
Envió de mensajes a cada objeto de

la colección
Iteración
Sintaxis:
* [expresión-iteración ] mensaje
Ejemplo:
v:Vendedor 1 *[1..8]: verificarLínea()

:LíneaProducto
Ejemplo de Diagrama de Comunicación
Sugerencias
• Recuerde que para que un objeto se pueda comunicar con otro deben
tener algún tipo de relación (asociación o dependencia) entre ellos
• El diagrama de secuencia de sistema (DSS) lo utilizamos en la etapa

de análisis, conjuntamente con los casos de uso, para la identificación
de los mensajes
• Los diagramas de Comunicación lo utilizamos en la etapa de diseño,

conjuntamente con los patrones para asignación de responsabilidades,
para la distribución de operaciones en las clases
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 3.3 –

3.4 si puedo definir y dar ejemplos de:
• Diagrama de comunicación
• Diagrama de secuencia
• Enlace
• Menaje
• Itera ración
Auto evaluación/2
Comprendí los conceptos más importantes de la unidad 3.3, 3.4, si
• Entiendo que el diagrama de comunicación muestra lo mismo que el diagrama de secuencia
• Comprendo qué enfatiza el diagrama de secuencia y qué el de colaboración
• Comprendo el concepto de “caja negra” en los diagrama de secuencia de sistema
• Comprendo la diferencia entre un diagrama de secuencia (UML) y un diagrama de secuencia de sistema
• Entiendo la diferencia entre enlace y asociación y cómo se visualiza el enlace en los diagramas de iteración
• Comprendo cómo se visualiza la secuencia de mensajes en cada uno de los diagramas
• Entiendo que debo hacer un diagrama de secuencia de sistema por cada escenario del caso de uso
• FIN
Administrativos
Unidad 4.1 OCL

2008
3.1. Casos de uso
• ¿Qué muestran el diagrama de comunicación y el diagrama de secuencia?
• ¿Qué enfatiza el diagrama de secuencia y qué el de colaboración ?
• ¿Cuál es el concepto que se quiere representar con la “caja negra” en los diagrama de secuencia de
sistema?
• ¿Cuál es la diferencia entre un diagrama de secuencia (UML) y un diagrama de secuencia de sistema?
• ¿Cuál es la diferencia entre enlace y asociación y cómo se visualiza el enlace en los diagramas de
iteración?
• ¿Cómo se visualiza la secuencia de mensajes en cada uno de los diagramas?
• ¿Debo hacer un diagrama de secuencia de sistema por cada escenario del caso de uso o solamente
para el flujo principal?
Bibliografía usada para el curso
The Object Constraint Languaje

Second Edition
Getting Your Models Ready for MDA
Jos Warmer
Anneke Kleppe
Object Constraint Language

Versión 2.0
http://www.omg.org/
OCL
¿Por qué utilizar OCL?
• Un modelo es un conjunto consistente y coherente de elementos de la realidad que

tienen características y restricciones
• Un modelo gráfico como UML no es suficiente para una especificación no ambigua
• Existe la necesidad de establecer restricciones adicionales sobre el modelo
• Muchas veces las restricciones se escriben en lenguaje natural
¿Qué problemas surgen con este tipo de especificaciones?

¿Por qué utilizar OCL?
• Una solución: LENGUAJES FORMALES

– Problemas: necesidad de usuarios con una fuerte formación
matemática
• Una alternativa: OCL

– Lenguaje de características formales
– Fácil de leer
– Fácil de escribir
Características generales de OCL
• OCL es un lenguaje declarativo: establece qué debe ser hecho pero no cómo
debe ser hecho
• El estado del sistema no cambiará como consecuencia de una expresión OCL
• Cuando una expresión OCL es evaluada, simplemente devuelve un valor
• OCL es un lenguaje tipado, por lo tanto cada expresión OCL tiene un tipo,
por consiguiente todos los tipos deben concordar (no es posible comparar
enteros con literales)
¿Qué no es OCL?
• NO es un lenguaje de programación
• NO es posible escribir lógica de programación
• NO es posible invocar operaciones que no sean una consulta
• NO considera aspectos de implementación

¿Para que sirve OCL?
Sirve para:
• Especificar reglas de negocio
• Definir la semántica de UML
• Especificar PIM para MDA
• Especificar modelos precisos y completos a partir de la construcción de modelos UML/OCL combinados

Un ejemplo
<<Invariant>>
self.pasajeros->size() <= self.avion.tipoavion.cant_de_asientos
Avion
id_avion : Integer
+avion Tipo_Avión
Vuelo +tipo
1 1..* tipo : String
id_vuelo : Integer
serie : String
origen : String 1..* 1 cant_de_asientos : Integer
destino : String
cant_de_tripulantes : Integer
*
*
+pasajeros
1..* Pasajeros
id_pasajero : Integer
+tripulantes pasaporte : String
1..*
Restricción: la cantidad de pasajeros de un vuelo debe ser menor o igual

a la cantidad de asientos del tipo de avión que realiza el vuelo
Tipo contextual e instancia contextual
El tipo contextual de una expresión OCL se corresponde con la
entidad del modelo para la cual se define la expresión OCL.
Utilizaremos un término de UML estandard, denominado

Clasificador (classifier) para indicar con él que nos
referimos a una clase, una interfaz, un tipo de dato o un
componente.
El tipo contextual de una expresión OCL, se escribe luego

de la palabra reservada context.
Una expresión OCL se evalúa para un único objeto, el cual es

siempre una instancia del tipo contextual (instancia
contextual).
A veces es necesario referirnos explícitamente a la
instancia contextual, por ello utilizamos la palabra self
Contexto de una expresión
<<Invariant>>
Persona
edad > 18 context Persona
nombre: String
inv: edad > 18
edad: Integer
....
Las expresiones se pueden mostrar en un diagrama UML o no
El vínculo entre una entidad en un diagrama UML y una expresión OCL se

denomina definición de contexto de una expresión OCL
Contexto y tipo de expresión
Persona
nombre: String
edad: Integer
Tipo contextual
....
context Persona
inv: self.edad > 18
Instancia
contextual
etiqueta
Accediendo a
propiedades de objetos
propiedades
• Una propiedad es:
• Un atributo
• Un extremo de asociación
• Una operación/método libre de efectos laterales
Una operación o método se define como libre de efectos laterales si no
modifica el estado del sistema
• Notación “Punto”: El valor de una propiedad en un objeto se especifica en

una expresión OCL con un punto seguido del nombre de la propiedad
self.mEdad >= 17
self.obtenerprecio()
Propiedad: Atributo
Por ejemplo, la siguiente expresión OCL: “la edad de cliente es mayor o igual
a 17 años”:
context Cliente
inv: self.mEdad >= 17
Cliente
mNombre: String
mApellidos: String
mEdad: Integer
lim_max_mov:Integer
El valor de la subexpresión self.mEdad es el valor de mEdad en la instancia

particular de Cliente identificada por self.
El tipo de la subexpresión self.mEdad es el tipo del atributo mEdad, que es un
tipo Integer estándar.
Propiedad: Operaciones
Para referirnos a una operación, también se utiliza la

notación punto
Por ejemplo: Producto
context Producto obtenerprecio()
Inv: self.obtenerprecio() > 0

Operaciones de colecciones
OCL define muchas operaciones en tipos de colección. Estas
operaciones permiten contar con una manera flexible y
poderosa de proyectar nuevas colecciones desde colecciones
existentes.
Notación flecha “->”:
colección->operaciónDeColeccion()
Navegaciones
Las navegaciones nos permiten hacer referencia a objetos que

están asociados con la instancia contextual
Hay dos tipos de navegaciones: simples y combinadas
Habitación
Huésped
número_piso : Integer
* nombre : String
número_habitación : Integer
edad : Integer
número_de_camas : Integer
sexo : {hombre, mujer}
tipo : {A, B}
+huéspedes
Navegaciones
Requerimiento: la cantidad de huéspedes de una habitación no

debe superar la cantidad de camas de la habitación.
context Habitación
inv: self.huespedes->size() <= self.número_de_camas
Habitación
Huésped
* nombre : String
edad : Integer
tipo : {A, B}
+huéspedes
Se utiliza el nombre de rol (del extremo opuesto de una relación)

que vincula la clase donde se define la expresión con otra clase
del diagrama.
Navegaciones
Si se omite el nombre de rol, se usa como tal el nombre de la

clase
Habitación
Huésped
* nombre : String
edad : Integer
tipo : {A, B}
context Habitación
inv: self.Huesped->size() <= self.número_de_camas
Propiedad: extremos finales de asociaciones
A partir de un objeto específico, es posible navegar una asociación en el diagrama de
clase para referirnos a otros objetos y sus propiedades.
objeto.nombredelextremoFinal
El valor de la subexpresión es un objeto o conjuntos de objetos, dependiendo de la

multiplicidad del extremo final de la asociación.
context Compañia
inv: self.gerente.esDesocupado = false
inv: self.empleados->notEmpty()
+gerente
Persona 1
Compañia
nombre : String
edad : Integer nombre : String
esDesocupado : Boolean * +empleados
En self.empleados->notEmpty() estamos accediendo a la propiedad notEmpty en el
conjunto self.empleados
Extremo de Asociación y Navegación
Comenzando desde un objeto en particular, podemos
navegar una asociación en un diagrama de clases
para referirnos a otro objeto y a sus propiedades.
El valor de esta expresión es el conjunto de objetos que

están del otro lado de la asociación nombreDeRol
Para hacerlo, navegamos la asociación

usando su extremo opuesto:
gerente
Persona
esCasado : Boolean
esDesocupado : Boolean
1
edad : Integer compañiaGerenciada
esFeliz : Boolean 0..*
Compañia
context Persona inv: empleado
0..* nombre : String
cantidadDeEmpleados : Integer
self.empleador empleador
0..*
Si la multiplicidad del extremo es *, es una colección
Context Person inv:
self.employer ... (una colección)
Si la multiplicidad del extremo es 0 ó 1, es un
objeto
Context Company inv: Self.manager...
(Un objeto)
Combinando propiedades
Las propiedades se pueden combinar para escribir
expresiones más complejas.
Una regla importante es que una expresión OCL siempre se

evalúa a un objeto específico de un tipo especifico. Luego de
obtener el resultado, es posible aplicar otra propiedad para
obtener un nuevo resultado.
Cada expresión OCL puede ser leída y evaluada de izquierda a
derecha
context Cliente
inv: self.lim_max_mov >= self.cuentas.mMovs->size()

Cliente
Cuenta 0..* Movimiento
mNombre: String 0..*
mTitulares /msaldo: Real mImporte: Real
mApellidos: String
1..* cuentas mMovs mConcepto: String
mEdad: Integer
mFecha: Date
lim_max_mov:Integer
Tipos de expresiones OCL
Invariantes
Pre/post-condiciones
Valores iniciales
Valores derivados
De consulta
otros
Invariantes
Un invariante es una condición que debe ser verdadera para
todas las instancias de un tipo específico en cualquier
momento.
Su tipo contextual es un clasificador

context Habitación
inv: self.número_de_camas <= 10

Habitación
context Habitación número_de_camas : Integer
tipo : {A, B}
inv: número_de_camas <= 10
context h: Habitación
inv: h.número_de_camas <= 10

Pre y postcondiciones
Una precondición /postcondición es una condición que debe ser
verdadera antes /después de la ejecución de una operación.
La instancia contextual self es una instancia del tipo que es

dueño de la operación.
La declaración incluye la palabra context, seguida del contexto

y de la declaración de la operación y el tipo.
Las etiquetas pre y post declaran si se trata de una

pre/postcondición.
context Empleado::aumentarsalario( cantidad: Real ): Real
pre: salario > 0
post: self.salario = self.salario@pre + cantidad and
result = self.salario
Pre y postcondiciones
En una postcondición, nos podemos referir a los valores de cada
propiedad de un objeto en dos momentos en el tiempo:
El valor de la propiedad al comienzo de la operación o

método (utilizamos el postfijo @pre)
El valor de la propiedad una vez que la operación o método

se ha ejecutado.
Nota: ‘@pre’ solo se permite en expresiones del tipo

postcondicion !
context Empleado::aumentarsalario( cantidad: Real ): Real
pre: salario > 0
post: self.salario = self.salario@pre + cantidad and
result = self.salario
Expresiones para valores iniciales y
derivados
Una expresión OCL puede ser utilizada para indicar el valor
inicial (o derivado) de un atributo o un extremo de asociación.
La expresión debe ser conforme al tipo resultante del atributo,

ó
En el caso que el contexto es un extremo final de asociación la

expresión debe ser conforme con el clasificador en tal extremo
final
context Persona:: salario : Integer
Persona
init: 500
sal ari o : In tege r
a nti gueda d : Int eger
context Persona:: salario : Integer
derive: 500 + (50 * antigüedad)

Navegaciones Combinadas
Las navegaciones no se limitan a una única asociación. Las
expresiones OCL pueden estar encadenadas navegando un conjunto
de asociaciones
context Vuelo
inv: self.avion.tipo.cant_de_asientos >= self.pasajeros->size()

Avion
id_avion : Integer
+avion Tipo_Avión
Vuelo +tipo
1 1..* tipo : String
id_vuelo : Integer
serie : String
origen : String 1..* 1 cant_de_asientos : Integer
destino : String
cant_de_tripulantes : Integer
*
*
+pasajeros
1..* Pasajeros
id_pasajero : Integer
+tripulantes pasaporte : String
1..*
Navegaciones a clases de
asociación
Para especificar la navegación a clases de asociación, OCL utiliza

un punto y el nombre de la clase de asociación
context Persona
inv: self.job ....
Persona
Compañia
nombre : String +empleado +empleador nombre : String
edad : Integer
numerodeEmpleados : Integer
esDesocupado : Boolean 0..* 0..*
Job
titulo : String
diaComienzo : Date
salario : Integer
Navegaciones desde clases de
asociación
Es posible navegar desde la clase de asociación a los objetos que
participan en la asociación.
context Job
inv: self.empleado.edad > 21
Persona
Compañia
edad : Integer
esDesocupado : Boolean 0..* 0..*
Job
titulo : String
diaComienzo : Date
salario : Integer
El metamodelo de OCL
En el metamodelo de OCL se define la jerarquía de

colecciones de OCL y las operaciones de colección
Collection
size() : Integer
includes(object : T) : Boolean
excludes(object : T) : Boolean
count(object : T) : Integer
includesAll(c2 : Collection(T) : Boolean
excludesAll(c2 : Collection(T) : Boolean
collection isEmpty() : Boolean
set orderedset bag sequence

Colecciones
• El tipo Collection es un tipo abstracto, con tipos de
colección concretos como sus subtipos.
– Set (Conjunto)
– OrderedSet (Conjunto ordenado)
– Bag (Bolsa)
– Sequences (Secuencias)
Navegaciones y colecciones
Los tipos de colecciones juegan un importante rol en las

expresiones OCL !
– Una única navegación resulta en un conjunto (Set),
– navegaciones combinadas en un Bag,
– navegaciones sobre asociaciones adornadas con {ordered}

resultan en un OrderedSet.
Tipos Básicos
Tipos Básicos
• En OCL, se definen un número de tipos básicos, los cuales están
disponibles para el modelador en todo momento. Estos tipos son valores
predefinidos y son independientes de cualquier modelo de objetos.
• Tipos Básicos:
– Boolean: true, false
– Integer :1, -5, 2, 34, 26524, ...
– Real: 1.5, 3.14, ...
– String: ‘esto es un string‘
– Colecciones (definidas anteriormente)
• Operaciones definidas en los tipos

– Integer: *, +, -, /, abs(), etc.
– Real: *, +, -, /, etc.
– Boolean: and, or, xor, not, implies, if-then-else-endif
– String: concat(), size(), substring()

Tipos Básicos
Cada expresión OCL se escribe en el contexto de un modelo UML.
En UML un clasificador (classifier) es una clase, o una

interfaz, un tipo de dato.
Todos los clasificadores de un modelo UML son tipos que pueden

ser utilizados en las expresiones OCL que estén asociadas a dicho
modelo.
Tipos Enumerados
Las enumeraciones son tipos de datos en UML y tienen un nombre.

Una enumeración define un número de literales, que son valores
posibles de la enumeración.
En OCL podemos referirnos a los valores de una enumeración.
context Persona
inv: genero = Genero::masculino
Persona <<enumeration>>
nombre : String Genero
edad : Integer masculino
genero : Genero femenino
Navegaciones que resultan en un Set
Las navegaciones simples resultan en un Set
El valor de una navegacion simple es un objeto o conjuntos de objetos, dependiendo de la multiplicidad del
extremo final de la asociación.
context Compañia
inv: self.gerente.esDesocupado = false
inv: self.empleados->notEmpty()
+gerente
Persona 1
Compañia
nombre : String
edad : Integer nombre : String
esDesocupado : Boolean * +empleados
.... self.gerente->size() = 1
Navegaciones que resultan en Sets o Bags
W&K: When you navigate through more than one association with
multiplicity greater than 1, you end up with a bag.
OCL specification: combined navigations results in a Bag
+asociados +trabaja +obras_sociales
Medico ObraSocial +afiliados Afiliado
1..* 1..* 1..* 1..*
context Medico
...
self.trabaja.afiliados
Navegaciones que resultan en Sets o
Bags
Que sucede si queremos obtener el número de potenciales
pacientes de un médico, pero quisiéramos contar tantas
veces a un afiliado como obras sociales éste tenga.
1..* 1..* 1..* 1..*
Obra1 af1
med1
af2
Context Medico obra2
af3
...
self.trabaja.afiliados
Navegaciones que resultan en Sets o
Bags
Que sucede si queremos obtener el número de potenciales
pacientes de un médico, y pero NO quisiéramos contar
tantas veces a un afiliado como obras sociales éste
tenga.
1..* 1..* 1..* 1..*
Obra1 af1
med1
af2
obra2
Context Medico
af3
... self.trabaja.afiliados->asSet()
Colecciones y
operaciones de colección
Operaciones de colección
collection
set orderedset bag sequence

union append
count
= union prepend =
intersection append = insertAt union
- intersection
prepend subSequence flatten
including - asSet
insertAt including at
excluding asOrderedSet
indexOf
symmetricDifference subOrderedSet excluding
first asSequence
count at count
last asBag
flatten indexOf flatten
first asSet including
asSet
asOrderedSet excluding
asOrderedSet last
asSequence asSequence
asBag asBag
Operación Size()
La operación predefinida size() nos permite obtener la cantidad de elementos de una colección.
context Cliente
inv: self.mCuentas->size() < 10
mCuentas
Cuenta
0..*
mTitulares /msaldo: Real
1..*
Cliente
mNombre: String
mApellidos: String
mEdad: Integer
Sexo: Genero
Operación Select
Permite obtener un subconjunto específico de una colección.
select es una operación sobre una colección y es especificada

utilizando la sintaxis de flecha:
collection->select( expresión booleana)
El resultado es una colección que contiene todos los elementos de la

colección origen para los cuales es verdadera la expresión booleana.
Para encontrar el resultado de esta operación, se evalúa la

expresión para cada elemento de la colección. Si el resultado de la
evaluación es verdadero para un elemento, este se incluye en la
colección resultante.
Operación Select (cont.)
Empleado
nombre : String
Proyecto
apellido : String
nombre : String
edad : Integer
* +participa * presupuesto : Integer
esCasado : Boolean
+trabaja_en
diaNacimiento : Date
El contexto de la expresión en el argumento select es el del elemento de

la colección en el cual el select es invocado.
context Proyecto
inv: self.participa -> select (edad > 50) ->notEmpty()
context Proyecto
inv: self.participa-> select (e: Empleado | e.edad > 50) ->notEmpty()
context Proyecto
inv: self.participa-> select (e | e.edad > 50) ->notEmpty()

Operador reject
El operador reject permite obtener un subconjunto de todos los
elementos de una colección para el cual la expresión se evalúa a
falso.
context Proyecto
inv: self.participa -> reject ( esCasado )

->isEmpty()
Empleado
... colección
nombre : Stringde las personas que no están casadas
apellido : String
Proyecto es vacía.
nombre : String
edad : Integer
** +participa ** presupuesto : Integer
esCasado : Boolean
+trabaja_en
Select y reject
La operación reject está disponible en OCL por conveniencia,
debido a que cada reject se puede escribir como un select con la
expresión booleana negada.
collection->reject( v | expresión-booleana-utilizando-v )
collection->select( v | not (expresión-booleana-utilizando-v ) )
Operador collect
El operador collect se utiliza cuando queremos derivar una nueva
colección a partir de otra, pero que contiene objetos diferentes de la
colección original.
Por ejemplo: deseamos obtener una colección de las fechas de

cumpleaños de los empleados de la compañía:
self.empleados->collect( fechaNacimiento )
self.empleados->collect( emp : Empleado |

emp.fechaNacimiento )
Empleado
nombre : String
Proyecto
apellido : String
nombre : String
edad : Integer
esCasado : Boolean
+trabaja_en
Operación ForAll
Este operador permite especificar una expresión booleana que
debe ser verdadera para todos los elementos de una colección.
La exp. forAll tiene como resultado un valor booleano.
context Proyecto
inv: self.participa->forAll( p: Empleado |
p.edad <= 65)
Empleado
nombre : String
Proyecto
apellido : String
nombre : String
edad : Integer
esCasado : Boolean
+trabaja_en
Operación ForAll
El operador forAll tiene una variante extendida en el cual se utiliza más
de un iterador. Ambos iteradores iterarán sobre la colección completa.
Efectivamente esto constituye el operador forAll en el producto
cartesiano de la colección.
context Proyecto
inv: self.participa-> forAll (e1, e2: Empleado |
e1<> e2 implies e1.apellido <> e2.apellido)

Empleado
nombre : String
Proyecto
apellido : String
nombre : String
edad : Integer
esCasado : Boolean
+trabaja_en
Operación Exists
Muchas veces es importante saber si al menos para un elemento de
una colección se verifica una condición:
context Proyecto
inv: self.participa->exists( p | p.nombre = ‘Jack’)
Empleado
nombre : String
Proyecto
apellido : String
nombre : String
edad : Integer
esCasado : Boolean
+trabaja_en
mCuentas
Cuenta
0..*
1..*
Cliente
mNombre: String
mApellidos: String
mEdad: Integer
context Cuenta
Sexo: Genero
inv: self.mTitulares->exists(c:Cliente|
c.mEdad>=18)
notEmpty()
En el caso de una asociación con multiplicidad 0..1 es
útil verificar si existe un objeto o no cuando navegamos
la asociación
context Persona
inv: self.esposa->notEmpty() implies

self.esposa.genero = Genero::femenino
Persona <<enumeration>>
nombre : String +esposa Genero
edad : Integer masculino
genero : Genero 0..1
0..1 femenino
+marido 0..1
0..1
Operación count()
self-> count(object)
El número de veces que la colección (self) incluye el objeto
“object”
Bag{1, 2, 3, 2, 4, 2}->count(2) = 3
Diferencia entre count() y size()

Let y expresiones <<definition>>
Expresiones Let
A veces una subexpresión es utilizada más de una vez en una
restricción. La expresión let nos permite definir una variable la
cual puede ser utilizada en una restricción.
context Persona
inv: let sueldo : Integer = self.job.salario->sum() in
if esDesocupado then
sueldo < 100 Persona

Compañia
edad : Integer
else esDesocupado : Boolean 0..*
0..* 0..*
0..*
sueldo >= 100

Job
endif titulo : String
diaComienzo : Date
salario : Integer
expresiones <<definition>>
context Cuenta
def: msaldo : real = self.mMovs.mImporte->sum()
context Cuenta
mCuentas
inv: saldo > 0 Cuenta 0..*
0..*
1..*
Cliente
mNombre: String Movimiento
mApellidos: String 0..*
mImporte: Real
mEdad: Integer mConcepto: String
Sexo: Genero mMovs
mFecha: Fecha
Operadores Lógicos/1
b not b
• Operador not
false true
True false
• Operador and
b1 b2 B1 and b2
(bi and b2) = (b2 and b1) false false false
false true false
true false false
true true True

• Operador or b1 b2 b1 or b2
false false false
(bi or b2) = (b2 orb1) false true true
True false true
True true true
• Operador xor
b1 b2 b1 xor b2
(bi xor b2) = (b2 xorb1) false false false
false true true
True false true
true true false

• Operador implies
b1 implies b2
Si b1 es true, entonces b2 debe ser true (si b1 es false, nada puede decirse de b2)
context Person inv:

self.wife->notEmpty implies self.wife.age>=18 and self.husband-
>notEmpty implies self.husband.age>=18
• Expresión if
if b then e1 else e2 endif
b es una expresión booleana y e1 y e2 son expresiones OCL
if (count <= 100) then x/2 else 0 endif

Un ejemplo práctico
Customer
name : String
LoyaltyProgram
title : String
+programs name : String +participants
0..* isMale : Boolean
+programs dateOfBirth : Date
1..* enroll(c : Customer) 0..* / age : Integer
getServices() : Set(Services)
age() : Integer
+program 1 Membership
+owner 1
0..*
+partners 1..*
ProgramPartners +cards
+card
numOfCustomers : Integer 0..*
name : String CustomerCard
+currentLevel
+levels valid : Boolean
1..* 1
1 validFrom : Date
+partners 1
ServiceLevel goodThru : Date
name : String color : Color
1 / printedName : String
+delivered +account
Services +level 1
0..* LoyaltyAccount
0..* +card
points : Integer
Service number : Integer
condition : Boolean
pointsEarned : Integer 0..1 earn(i : Integer)
pointsBurned : Integer burn(i : Integer)
description : String +available
isEmpty() : Boolean
serviceNr : Integer Services
+account 1
calcPoints() : Integer +transactions
+transactions 0..*
+generatedBy 1 0..* Color
Transaction
silver
+transactions points : Integer
gold
date : Date
0..* amount : Real
Date
now : Date program() : LoyaltyProgram
isBefore(t : Date) : Boolean

isAfter(t : Date) : Boolean
fromYMD(t : Date) : Date
opname2() Earning
Burning
Sistema que administra programas de lealtad.
• Programas de Lealtad (LoyaltyProgram): Contiene los programas de lealtad.

• Socios del Programa (ProgramPartners): Representa a las compañías que
ofrece a sus clientes ser miembros de un programa de lealtad.
• Los clientes que pertenecen a un programa de lealtad pueden aprovechar los
servicios que ofrece cualquier compañía participante del programa al cual
pertenece el cliente.
• Todo cliente de un socio de programa puede pertenecer a un programa de
lealtad completando un formulario y obteniendo una tarjeta de membresía.
• La tarjeta de membresía, representada por la clase CustomerCard, se emite a
una persona. La mayoría de los programas permite a sus clientes obtener
puntos.
• Cada socio de programa decide de que forma se acumulan puntos y cuantos
puntos deben ser acumulados por una compra (servicios de los socios del
programa).
• Los puntos pueden ser utilizados para obtener servicios específicos de uno de
los socios del programa. Para que un cliente acumule puntos, toda membresía
puede estar asociada con una cuenta de lealtad.
• Existen transacciones para obtener puntos y para gastar puntos.
• Existen distintos niveles de servicio en cada programa de lealtad.
Ejercicios / 1
• La cantidad de puntos (points) iniciales de
la cuenta (LoyaltyAccount) debe ser 0
Context LoyaltyAccount::points
init :0
• La edad de los participantes debe ser mayor

a 18
Context Customer inv ofAge:

Age >= 18
Ejercicios / 2
• el programa debe ofrecer, al
menos, un servicio a los
clientes
Context LoyaltyProgram inv

minServices:
Partners.deliveredServices ->
size() >= 1
Ejercicios / 3
• La cantidad de tarjetas validas por cada usuario debe ser igual al
numero de programas en el que el usuario participa
Context Customer inv sizesAgree:

programs -> size() = cards -> select(valid = true) -> size()
Ahora a trabajar…
Customer
name : String
LoyaltyProgram
title : String
+programs name : String +participants
0..* isMale : Boolean
+programs dateOfBirth : Date
1..* enroll(c : Customer) 0..* / age : Integer
getServices() : Set(Services)
age() : Integer
+program 1 Membership
+owner 1
0..*
+partners 1..*
ProgramPartners +cards
+card
numOfCustomers : Integer 0..*
name : String CustomerCard
+currentLevel
+levels valid : Boolean
1..* 1
1 validFrom : Date
+partners 1
ServiceLevel goodThru : Date
name : String color : Color
1 / printedName : String
+delivered +account
Services +level 1
0..* LoyaltyAccount
0..* +card
points : Integer
Service number : Integer
condition : Boolean
pointsEarned : Integer 0..1 earn(i : Integer)
pointsBurned : Integer burn(i : Integer)
description : String +available
isEmpty() : Boolean
serviceNr : Integer Services
+account 1
calcPoints() : Integer +transactions
+transactions 0..*
+generatedBy 1 0..* Color
Transaction
silver
+transactions points : Integer
gold
date : Date
0..* amount : Real
Date
now : Date program() : LoyaltyProgram
isBefore(t : Date) : Boolean

isAfter(t : Date) : Boolean
fromYMD(t : Date) : Date
opname2() Earning
Burning
Escribir el enunciado…
context LoyaltyProgram
inv minServices: partners.deliveredServices -> size() >=1
context Customer
inv sizesAgree: programs ->size() =
card -> select(valid = true)->size()
inv: participants -> forAll (age() <= 70)
inv: self.participants -> forAll (c1, c2 |
c1 <> c2 implies c1.name <> c2.name)
Escribir el enunciado…
inv: points>0 implies transactions->exist(t | t.points > 0)
context LoyaltyAccount
inv: transactions -> collect (points)->exist(
p : Integer | p = 500)
context LoyaltyAccount
inv: transactions.points -> exist(
p : Integer | p = 500)
• Fin
Administrativos
Unidad 5.1 Patrones de Diseño

2008

3.1. Casos de uso
5.1. Patrones de Diseño Para Asignación de
Responsabilidades.
• ¿Cómo puedo complementar los modelos UML con sentencias OCL?
• ¿Cuál es la ventaja de usar OCL en lugar de un lenguaje informal?
• ¿Qué significa que OCL es un lenguaje declarativo?
• ¿Qué es un invariante en una clase?
• ¿Cómo se específica una propiedad (atributo, operación, nombre de rol) en un diagrama de clases?
• ¿Cómo navegar una asociación a partir de los nombres de rol?
• ¿Cómo sé si hago referencia a un conjunto o un objeto a partir de la multiplicidad del extremo

opuesto de una asociación?
• ¿Cuál es la diferencia entre los distintos tipos de colecciones?

Patrones de Diseño: otra forma de
reutilización...
Diseñar software orientado a objetos es difícil, más aún diseñar software

orientado a objetos reutilizables.
• Se deben encontrar las clases y relaciones apropiados entre ellas
• Se deben definir jerarquías de herencia y de interfaces y establecer

relaciones entre ellas.
• El diseño debe satisfacer las necesidades actuales del usuario,

además de contemplar futuros problemas o requerimientos.
Patrones de Diseño
El término patrón se utilizó inicialmente en el campo de la arquitectura,

por Christopher Alexander, a finales de los 70s.
Este conocimiento fue transportado al ámbito del desarrollo de software

orientado a objetos y aplicado al diseño.
el libro que inicio el camino fue:
“Design Patterns: Elements of Reusable Object-Oriented Software”

Gamma
Patrones de Diseño
Los patrones de diseño permiten la reutilización exitosa de diseños y

arquitecturas más rápidamente
Ayuda a elegir alternativas de diseño que hace a los sistemas reutilizables.
Un patrón es un par problema/solución con nombre que se puede aplicar a

nuevos contextos con consejos de cómo aplicarlo
Aprovechar las experiencia de los desarrolladores

Patrones de Diseño
elementos esenciales
El nombre del patrón: se usa para describir un problema de diseño, su

solución y las consecuencias, en una o dos palabras.
El problema: describe cuándo aplicar el patrón, explica el problema y su

contexto
La solución: describe los elementos que hacen al diseño, sus relaciones,

responsabilidades y colaboraciones
Las consecuencias: establecen los costos y beneficios de aplicar el patrón

Ejemplo: Patrón Adaptador
Convierte la interfaz de una clase en la interfaz que el cliente

espera.
“Un objeto Adaptador provee la funcionalidad prometida por

una interfaz, sin tener que asumir qué clase es usada para
implementar la interfaz”.
Permite trabajar juntas a dos clases con interfaces

incompatibles.
Interfaz: colección de operaciones que son utilizadas para especificar un

servicio de una clase
Ejemplo: Patrón Adaptador
Esta interfaz declara el
Clase que llama a método que una clase
un método de otra Client llama
clase a través de una
interfaz, sin asumir
que el objeto que
implementa el
método al que
llama, pertenezca a Esta clase implementa
una clase específica. el método que el
cliente llama, haciendo
un llamado a un
método de la clase
Adaptee, la cual no
implementa la interfaz.
Esta clase no
implementa el
método de la
interfaz, pero tiene
algún método que la
clase cliente quiere
llamar
Ejemplo: editor de gráficos
Figura
Editor
dibujar()
mover()
Rectangulo
dibujar()
mover()
Triangulo
3DFigura 3DAdapt ador Circulo
dibujar()
3Ddibujar() dibujar() dibujar() mover()
3Dmover() mover() mover()
La interacciones entre
objetos se escriben según los
términos de las
Esfera Paralelepipedo Piramide especificaciones definidas en
las superclases
3Ddibujar() 3Ddibujar() 3Ddibuj ar()
3Dmover() 3Dmover() 3Dm over()
Asignación de
Responsabilidades a las
Clases
Hasta ahora hemos llegado hasta acá …
Comenzamos con Describimos

los casos de uso. los casos de uso con
Inicialmente el nombre mayor detalle.
y una descripción
Escenario principal
<<include>>

Cliente
<<include>>
El cliente ingresa a la opción “registración “
El sistema evalúa el país….
…..
Hasta ahora hemos llegado hasta acá …
Creamos los diagramas

de secuencia de sistemas (DSS) Creamos el modelo
Para cada escenario de cada caso de uso. del dominio: CLASES,
ASOCIACIONES,
ATRIBUTOS
Escenario principal

El cliente ingresa a la opción “registración “
El sistema solicita ingreso de los datos personales Cliente
nombre
El sistema evalúa el país. apellido

direccion
te
….. 1 prof esion 1

tiene
usa
1 0..*
: SISTEMA
es de
numero
1
tarjeta
: cliente
ingresarSistema() 1 1 direccionEntrega
opcionEntrega
tiene
ingresarDatosPersonales ()
1..*
EjemplarLibro
ingresarTarjetaCredito() cantidad
numero
1 precio
ingresarPreferenciasEnvio() 1..* tiene
1
Lib ro
ingresarClaveContraseña() isbn
Autor
editorial n omb re
DSS categoria
"Registrarse
al sistema"
¿Cómo sigo?
¿En qué clases ubico a las operaciones que resuelven

la funcionalidad de cada caso de uso?
¿Qué criterios uso para tomar esas decisiones?

Asignación de responsabilidades a las clases
“Despues de la identificación de los requisitos de los usuarios y

de la creación del modelo del dominio, añada operaciones en
las clases de software y defina el paso de mensajes entre los
objetos para satisfacer los requisitos …”
Decisiones poco acertadas sobre la asignación de

responsabilidades de cada clase, dan origen a sistemas y
componentes frágiles y difíciles de mantener, entender,
reutilizar o extender
Responsabilidades
“Una responsabilidad es un
contrato u obligación de una clase”
Las responsabilidades se relacionan con las obligaciones de un objeto

respecto de su comportamiento.
La responsabilidad no es lo mismo que un método, pero los métodos se

implementan para llevar a cabo las responsabilidades
Estas responsabilidades pertenecen, esencialmente, a dos categorías:
• hacer
• conocer .
Responsabilidades
Entre las responsabilidades de un objeto relacionadas con el

hacer se encuentran:
• Hacer algo uno mismo.
• Iniciar una acción en otros objetos.
• Controlar y coordinar actividades en otros objetos.

Responsabilidades
Entre las responsabilidades de un objeto relacionadas con el conocer se
encuentran:
• Conocer los datos privados encapsulados.
• Conocer los objetos relacionados.
• Conocer las cosas que se pueden derivar

o calcular.
“las responsabilidades relevantes de conocer a menudo se pueden inferir

a partir del modelo del dominio”
Un ejemplo... (ver caso práctico)
Cliente
nombre
apellido
direccion
te
1 prof esion 1
usa tiene
1 0..*

es de
numero
1
tarjeta
opcionEntrega
tiene
1..*
EjemplarLibro
cantidad
numero
1 precio
1..* tiene
1
Lib ro
isbn
Autor
titulo esta esc rit o por
editorial n omb re
soporte 1.. * 1..* a pellid o
categoria
El Patrón “Experto” [Larman]
Nombre: Experto.
Problema: ¿Cuál es el principio fundamental en virtud del cual

se asignan las responsabilidades en el diseño orientado a
objetos?
Solución: Asignar una responsabilidad al experto en

información: la clase que cuenta con la información necesaria
para cumplir la responsabilidad.
El Patrón “Experto”
Ejemplo: ¿quién es el
responsable de conocer el total Nota: buscamos inicialmente en las
de una venta?. clases del modelo de dominio
Desde el punto de vista del patrón Experto,

deberíamos buscar la clase de objetos que CarritoCompra
posee información sobre los Items
vendidos 1
t iene
1..n
EjemplarLibro
Items 0..n pertenecen numero
can tidad
El objeto que conoce esto es 1 precio
CarritoCompra
El Patrón “Experto”
¿Qué información hace falta saber para

determinar la cantidad de Items vendidos y el
precio para saber la venta total?
CarritoCompra
La cantidad de Items vendidos está t iene
en la clase Items y el precio, en

1..n
EjemplarLibro, ambos tienen la EjemplarLibro
Items
información necesaria para 0..n pertenecen numero
can tidad
realizar la responsabilidad 1 precio
cantidad de items vendidos

Items.cantidad precio del libro
ejemplarLibro.precio
Seguimos con el ejemplo...
1: venta() 2 *: s := subtotal() 3: p := darPrecio()
: CarritoCompra : Items : EjemplarLibro

*
El * indica que es
iteración sobre una
colección
CarritoCompra
Envío el mensaje Envío el mensaje
venta() a venta() Envío el mensaje darPrecio() a
CarritoCompra 1 subtotal() a Items EjemplarLibro
tiene
1..*
EjemplarLibro
Items
0..* pertenecen numero
cantidad
precio
1
subtotal()
darPrecio()
El Patrón “Creador” [Larman]
El patrón Creador guía la asignación de responsabilidades relacionadas
con la creación de objetos, tarea muy frecuente en los sistemas
orientados a objetos.
El objetivo de este patrón es encontrar un creador que debemos conectar

con el objeto producido en cualquier evento
Estereotipo que indica que es un

mensaje de creación
<<create>>
1: crear( parametros )
: CarritoCompra : Items
Llamada a un constructor Variables de inicialización

El Patrón “Creador”
Problema: ¿Quién debería ser responsable de crear una nueva instancia de
alguna clase?
La creación de objetos es una de las actividades más frecuentes en un

sistema orientado a objetos. En consecuencia, conviene contar con un
principio general para asignar las responsabilidades concernientes a
ella.
: CarritoCompra Variables de inicialización
<<create>>
1: crear( parametros ) : Items
Llamada a un constructor
Solución: Asignarle a la clase B la responsabilidad de crear una instancia de

la clase A en uno de los siguientes casos:
· B agrega los objetos de A.

· B contiene los objetos de A.
· B registra las instancias de los objetos de A.
· B tiene los datos de inicialización que serán enviados a A cuando este
objeto sea creado (B es un experto respecto a la creación de A).
Beneficios: Se brinda apoyo a un bajo acoplamiento, lo cual supone menos

dependencias respecto al mantenimiento y mejores oportunidades de reutilización.
Ejemplo: En la aplicación ¿quién debería encargarse de crear una

instancia de items? CarritoCompra
contiene uno o más
Items
CarritoCompra
Desde el punto de vista del patrón
Creador, deberíamos buscar una agregarI tem()
v enta ()
clase que agregue, contenga, y
realice otras operaciones sobre este 1
tipo de instancias. tiene
1 ..*
Items
cantid ad
Cada vez que hago
una compra, cre ar( )
subtotal( )
agrego un nuevo
Item
Un CarritoCompra contiene (agrega) muchos objetos Items. Es por esto
que el patrón Creador sugiere que CarritoCompra es la clase idónea
para asumir la responsabilidad de crear las instancias de Items.
CarritoCompra
Envío el mensaje
agregarI tem()
agregarItem() a v enta ()
CarritoCompra
1
<<create>> tiene
1: agregarItem() 2: crear() 1 ..*
: CarritoCompra : Items Items

cantid ad
cre ar( )
subtotal( )
Envío el mensaje
crear() a Items Normalmente se invoca al
constructor de la clase
El Patrón “Bajo acoplamiento”
El acoplamiento es la medida de la fuerza con que un elemento está
conectado con otros.
Un alto acoplamiento implica que:
• Los cambios en las clases relacionadas fuerzan cambios en las clases

locales
• Son difíciles de entender de manera aislada
• Son difíciles de reutilizar, debido a que su uso requiere la presencia

adicional de las clases de las que depende
El Patrón “Bajo acoplamiento”
Problema: ¿cómo soportar bajas dependencias, bajo impacto en el cambio e

incremento en la reutilización?
Solución: asignar las responsabilidades a las clases de manera de mantener

el acoplamiento bajo
Beneficios: las clases son más independientes, lo que reduce el impacto al

cambio
El Patrón “Alta cohesión”
La cohesión es una medida de la especificidad de una responsabilidad
Una clase con baja cohesión hace muchas cosas no relacionadas y adolece
de los siguientes problemas:
Difíciles de entender, reutilizar y mantener
Regla empírica: una clase con alta cohesión tiene un número relativamente
pequeño de métodos con funcionalidad altamente relacionada
El Patrón “Alta cohesión”
Problema: ¿como mantener la complejidad manejable?
Solución: asignar las responsabilidades de manera que las cohesión

permanezca alta
Beneficios: se incrementa la claridad, se simplifica el mantenimiento y

las mejoras, implica generalmente bajo acoplamiento
El Patrón “Controlador”
Problema: ¿Quién debe ser el responsable de gestionar un evento de entrada al
sistema?
(Un evento del sistema de entrada es un evento generado por un actor externo)
Solución: asignar la responsabilidad de recibir o manejar un mensaje de evento del

sistema a una clase que:
a) represente el sistema global

b) represente un escenario de caso de uso donde tiene lugar el evento
Durante el análisis, las

operaciones del sistema pueden Sistema
asignarse a la clase “Sistema”,
eso no significa que una clase introducirArticulo()
software “Sistema” las lleve a realizarPago()
cabo
Durante el diseño, se le asignan las

responsabilidades de las operaciones
del sistema a una clase controlador (la
ProcesarVenta
clase controlador no es una clase del
dominio de la aplicación)
introducirArticulo()
realizarPago()
• Un objeto controlador no pertenece a la capa de interfaz
• Generalmente no hace trabajo, lo delega a otros objetos
• El controlador es una especie de fachada sobre la capa de dominio para

la capa de interfaz
• Durante el diseño se asignan a una o más clases controlador las

operaciones del sistema que se identifican durante el análisis
– Normalmente se utiliza una misma clase controlador para los eventos del
sistema de un caso de uso
– Si no hay muchos eventos al sistema puedo usar una única clase controlador
de fachada
El Patrón “Controlador” un ejemplo
Análisis Diseño
ProcesarVenta
Sistema finalizarVenta()
introducirArticulo()
introducirArticulo() crearNuevaVenta()
realizarPago() realizarPago()
crearNuevaVenta()
finalizarVenta()
crearNuevaDevolucion()
introducirArticuloDevuelto()
Asignación de operaciones
en la etapa de diseño
utilizando controladores
Operaciones del sistema
descubiertas en la etapa de
análisis
GestionarDevoluciones
introducirArticuloDevuelto()
crearNuevaDevolucion()
La capa de interfaz no maneja eventos del sistema
: Ventana Mensaje de evento del

sistema
Capa de Interfaz
1: IntroducirArticulo(ID,cant)
: Controlador
Controlador, asume la
Capa de Dominio responsabilidad de manejar
las operaciones del sistema
2: crearLineaVenta(ID, cant)
: CarritoCompra
Clase del dominio

Sugerencias
• Use los patrones de diseño para decidir en qué clases van qué operaciones
• Tómese el tiempo necesario para decidir la ubicación de las operaciones.

Marcaran la calidad del diseño
• Antes de aplicar los patrones, estudie bien el uso que se hace de ellos en la
bibliografía
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 5.1 si puedo definir y

dar ejemplos de:
• Patrón de diseño
• Responsabilidades
• Patrón de asignación de responsabilidades
• Patrón experto
• Patrón creador
• Patrón alta cohesión
• Patrón bajo acoplamiento
• Patrón controlador
Auto evaluación/2
• Entiendo cuál es el objetivo de usar un patrón para asignación de responsabilidades
• Entiendo en que disciplina del UP los utilizo
• Vinculo el concepto de realización de una colaboración en los casos de uso con el de diseño
utilizando patrones
• Comprendo la vinculación de los diagramas de secuencia de sistema (DSS) con el uso de

patrones de asignación de responsabilidades
• Entiendo por qué uso los patrones controladores
• Comprendo que normalmente utilizo más de un patrón para asignar responsabilidades a las
clases
FIN
Administrativos
Unidad 6.1 Persistencia de Objetos

2008

3.1. Casos de uso
5.1. Patrones de Diseño Para Asignación de Responsabil.
• ¿Cuál es el objetivo de usar un patrón para asignación de responsabilidades?
• ¿En qué disciplina del UP utilizo los patrones de diseño?
• ¿Cómo se vincula el concepto de realización de una colaboración en los casos de

uso con el de diseño utilizando patrones para asignacion de responsabilidades?
• ¿Cómo se vinculan los diagramas de secuencia de sistema (DSS) con el uso de

patrones de asignación de responsabilidades
• ¿Para qué uso los patrones controladores?

Modelo de Clases vs. Modelo de Datos
¿Cómo mantengo la persistencia • En el modelo de clases

de los objetos...? tenemos:
– Clases
– Asociaciones
– Clases Asociaciones
– Generalizaciones
...Mediante una base de datos – Atributos
• En el modelo de datos
tenemos:
¿Cómo se puede hacer – Entidades
corresponder un modelo de – Interrelaciones
objetos con un modelo de – Atributos
datos? – Identificadores
¿Cómo hago las transformaciones?
¿Todas las clases se transformarán en entidades? Alumno
?
¿Qué pasará con las asociaciones?

Alumno Materia
?
¿...y las clases asociaciones?

Alumno Materia
Nota ?
¿Cómo hago las transformaciones?/2
¿... Qué pasará con las

vehiculo
?
generalizaciones?
camion automovil
Materia
¿y con los atributos de las
clases?
nombre
año ?
Materia
nombre
¿Y con las operaciones?

año
darNombre()
darAño() ?
Transformación Básica - Clases
• Todas las clases se transforman
en entidades
Creo el Atributo
identificador
Los atributos de la codAlu

clase pasan a ser Alumno ALUMNO
atributos de la entidad
nombre
apellido nombre direccion
direccion apellido
Se crean nuevos atributos

identificadores para cada entidad el modelo de datos NO hay
(los objetos no precisan operaciones
Identificador único.)
Transformación Básica – Asociaciones
• Las asociaciones se
transforman en
Empresa 1 1..* Empleado
interrelaciones
Se mantiene, en el modelo de datos,

la misma multiplicidad de la
EMPRESA EMPLEADO
asociación (1, 1) (1, n)
Transformación Básica – Composición
• Las relaciones de
Factura Linea
composición NroFact ura nroItem
fecha cantidad
1..*
El “todo” se transforma en
entidad fuerte y la
“parte” y se transforman FACTURA
(1, 1) (1, n)
LINEA
en entidad débil
Transformación Básica – Clase Asociación
• La clase asociación se transforma en interrelación
– La multiplicidad es de M:N
– Los atributos de la clase asociación pasan a ser atributos de la
interrelación
EMPLEADO
(1, n)
Empleado Empresa FechaIngreso
1..* 1..* EMPRESA

(1, n)
PUESTO
sueldo
Puesto
fechaIngreso
sueldo
Transformación Básica – Generalización
vehiculo
• Las relaciones de clasificación (tres tipoCombustible
peso
opciones)
1. Se transforman en relaciones de automovil

cantidadPasajeros
camion
capacidad
clases y subclases en el modelo
entidad interrelación, o
codAut
codAut
AUTOMOVIL
CAMION
2. Se pasan los atributos de la peso tipoCombustible

peso tipoCombustible
superclase a las subclases

cntidadPasajeros
capacidad
(desaparece la superclase)
codAut Tengo que agregar

el atributo
VEHICULO
3. Se pasan los atributos de las capacidad identificador
subclases a la superclase (y
peso tipoCombustible
cntidadPasajeros
desaparecen aquellas)
Un ejemplo
superclase
Transformación del
ALUMNO PROFESOR
modelo de clases al
* modelo de datos
* *
*
1
NOTA *
CURSO nota MATERIA
fecha
supeclase
cod_alum
ALUMNO PROFESOR cod_prof

La transformación al N
N
N
modelo relacional es la nota
conocida... NOTA
1 fecha M
M
cod_mat
CURSO MATERIA
cod_cur
Otro ejemplo...
Cliente
nombre
apellido cod_cli cod_ord
direccion
te
1 prof esion 1 CLIENTE ORDENCOMPRA
usa tiene 1 N
1 1 1
0..*
CarritoCompra
Ord enCom pra
cod_carro
agregarItem() es de
1
numero 1
v enta() tarjeta
1 direccionEntrega 1
1 opcionEntrega CARRITOCOMPRA
tiene
1
1..*
Items EjemplarLibro num_ejemp

cantidad 0..* pertenecen n umer o
p recio N
crear() 1 N 1
subtotal() d arPre cio () ITEMS EJEMPLARLIBRO
1..* tiene
1
N
num_item
Lib ro
isbn
Autor
titulo esta esc rit o p or cod_autor cod_libro
editorial n ombre
1
categoria N N
AUTOR LIBRO
El modelo Relacional Asociado
Cliente(cod_cli, ...)
OrdenCompra(cod_ord, ..., cod_cli(Cliente))
CarritoCompra(cod_carro, ..., cod_cli(Cliente), cod_ord(OrdenCompra))
Items(num_item, ..., cod_carro(CarritoCompra), num_ejem(EjemplarLibro))
EjemplarLibro(num_ejem, ..., cod_libro(Libro))
Libro(cod_libro, ...)
Autor(cod_autor, ...)
LibroAutor(cod_libro(Libro), cod_autor(Autor))
Otro ejemplo
ConceptualModel ERModel
body
1..1
body IDst title date IDpr name address

Story Person
1.. 1..1
part -title
-date
* 1..1 -name
-address 1..n 1..1
-summary author -email Story Person
*
1.. * author
1..n 1..n participant
summary
1..
* participant part email
Essay Interview Essay Inteview

1..1
-illustration 1..1
1..1
illustration
1..1
1..n
1..
* IDqa answer
Q&A Q&A
question
-question
-answer
Sugerencias
• El modelo de datos es una consecuencia del modelo de clases, por lo

tanto se diseña después de este
• La transformación es del modelo de clases al modelo conceptual (DER)

y de éste al modelo lógico (relacional) – ver OED –
• Tenga en cuenta costos y beneficios de mantener en el modelo de datos

conceptual, las relaciones de generalización
• Existen otros mapeos entre el diagrama de clases y el modelo de datos

(ver bibliografía específica)
Auto evaluación/1
Comprendí los conceptos más importantes de la unidad 6.1 si
puedo definir y dar ejemplos de:
• Transformación de
– Clases
– Asociaciones
– Composiciones
– Generalizaciones
Auto evaluación/2
• Entiendo por qué utilizo una base de datos relacional y no, como parecería lógico,
una base de datos OO
• Entiendo por qué derivo el modelo de datos del modelo de clases y no a la inversa
• Comprendo que la transformación propuesto no es la única posible
• Entiendo por qué solo transformo datos y no operaciones
• Comprendo por qué por a cada clase transformada, además de los atributos, debo
añadirle, en el modelo de datos, un identificar único
FIN

Análisis de Sistemas Administrativos

Diunggah oleh

Informasi Dokumen

Judul Asli

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

Análisis de Sistemas Administrativos

Diunggah oleh

Hak Cipta:

Format Tersedia

Análisis de Sistemas

Facultad de Tecnología Informática UAI

Facultad de Tecnología Informática UAI

• ¿Cuál es la diferencia entre análisis, diseño e implementación y que es lo que realizo en

• ¿Vinculo la etapa de análisis con la descripción del modelo de dominio de la

• ¿Comprendo cual es el uso de las tarjetas CRC?

• ¿Cuál es el objetivo de la abstracción y el encapsulamiento?

• ¿Cuál es la diferencia entre mensajes, operaciones y método?

• ¿Qué diferencia existe entre asociación, agregación y composición?

• ¿Cuál es la diferencia entre generalización y herencia?

¿Cuáles son los modelos de UML?

• Es la representación de una abstracción

• Un modelo de un sistema software está construido en un lenguaje de

• El modelo es la columna vertebral de un lenguaje utilizado por todos los

 Ayudan a la comprensión de sistemas complejos

 Indican QUÉ hará el sistema pero NO CÓMO lo hará

 Ayuda a la corrección de errores

 Ayuda a la evolución y reuso

 Esencial para la comunicación entre miembros de un equipo

Usando la misma notación (UML) se pueden considerar tres

• Esencial o conceptual: los diagramas describen cosas del mundo

• De especificación: los diagramas describen abstracciones

• De implantación: los diagramas describen implementaciones

 Los mismos conceptos se representaban con distinta notación

G. Booch (Método Booch)

Unified Modeling Language (UML)

El proceso de estandarización promovido por OMG comenzó en 1997

UML es un lenguaje estándar para:

– Ilustrar el funcionamiento de un caso de uso mediante Diagramas

– Representar la estructura de un sistema mediante Diagramas de

– Modelar el comportamiento de los objetos mediante Diagramas

Restricciones: una declaración textual de una relación

Estereotipos: una nueva clase de elemento del modelo, ideada

Valores etiquetados: una porción de información con nombre,

Cliente Verificar Operación

Reintegro Cuenta de Crédito

Muestra las distintas operaciones que se esperan de un

CarritoCompra Ord enCom pra

Muestra las distintas las clases atributos,

: WInP réstamos :Socio :Video : Préstamo

verificar situación video

Muestra la interacción de un conjunto de objetos

2: verificar situación socio

1: prestar(video, socio) 3: verificar situación video

Muestra la forma de representar interacciones entre objetos,

núm er o_prés tam os = 0

transición núm ero_prés t am os > 0

devolver[ núm ero_prés tam os > 1 ]

Poner café Añadir agua Coger taza

Servir café Beber

Muestran transiciones internas, sin hacer mucho énfasis en

Gestión de Cuentas Rutinas de conexión Acceso a BD

Muestra las dependencias lógicas entre componentes software

Gestión de Cuentas Interfaz de Terminal

Muestran la organización de los componentes del sistema

...UML es una notación

Por lo tanto precisa de un proceso de desarrollo (ciclo de

Ciclo de vida Ciclo de vida

Proceso de Desarrollo de Software

Conjunto de actividades para transformar los <<include>>

requisitos del usuario en un sistema software Reintegro Cuenta de Crédito

Proceso Unificado (UP) Cliente

• Dirigido por Casos de Uso