Introduccin a la modelizacin de

sistemas orientados a Objetos,

usando UML
por:
BLANCA IBARRA MURRIETA
bibarra_murrieta@hotmail.com

Contenido
Por qu Modelizar?
El Paradigma Orientado a Objetos
Introduccion UML
Captura de Requisitos
Modelado de Interacciones
Modelado de la Estructura del Sistema
Diagramas de Estados
Modelado de Componentes
Modelado de Distribucin
Hacia un proceso de Desarrollo usando UML
RUP Proceso Desarrollo Unificado
Conclusiones

Construir software es difcil

Mtodos

Mtodo
Establece

cmo abordar de un
sistemtico la construccin de software.

modo

Se describe el problema y la solucin mediante

un conjunto de modelos.

Mtodo
Importante conocer las limitaciones y beneficios

de los mtodos.
Los mtodos pueden ayudar pero no aseguran
el xito.
Un mtodo ofrece guas mediante ejemplos de
aplicacin.
Un mtodo es fruto de la experiencia en
proyectos.
No sustituye a la necesidad creativa

Proceso Software
Un proceso bien definido es necesario para
desarrollar sistemas software de manera
repetible y predecible
Permite un negocio sostenible y que puede
mejorar en cada nuevo proyecto,
incrementando la eficiencia y productividad de
la organizacin
G. Booch

Proceso Software
Un proceso de software debe especificar:

la secuencia de actividades a realizar por el

equipo de desarrollo: flujo de actividades
productos que deben crearse: qu y cundo
asignacin de tareas a cada miembro del
equipo y al equipo como un todo
proporcionar heursticas
criterios para controlar el proceso

Proceso Software
Un proceso debe ser iterativo e incremental.
Conviene centrarse en los aspectos crticos en las

primeras iteraciones para minimizar riesgos.

Un mtodo debera describir procesos por
defecto y sugerir documentacin: Uno debe
crearse su propio proceso.

Abstraccin - Modelado Visual

El modelado captura las
partes esenciales del sistema
Pedido
Artculo

envo

Proceso de Negocios
Sistema Computacional

MODELO DE LA
INFORMACION
Sistema de
informacion
BIBLIOTECA

Sistema
Catlogo

Bibliotecario

Libro

Biblioteca

A/D orientado a objetos

Registrar prestmo

Reportar Multas

Agregar recursos

A/D estructurados

DESARROLLO SW
TECNOLOGIA
(OO, UML, Rational Rose)

ORGANIZACION

PROCESO
(RUP)

Por qu modelar?
Proporcionar la estructura para la resolucin

de los problemas
Experimentar diversas soluciones
Reducir el tiempo de venta
Disminuir los costes de desarrollo
Gestionar el riesgo de cometer errores

Por qu modelamos?
Una empresa software con xito es aquella
que produce de manera consistente software
de calidad que satisface las necesidades de
los usuarios

El modelado es la parte central de todas las

actividades que conducen a la produccin
de software de calidad

Por qu modelamos?

Un modelo es una simplificacin de la realidad

Construimos modelos para comprender mejor el sistema

que estamos modelando

Cuatro utilidades de los modelos:
Visualizar cmo es o queremos que sea el sistema

Especificar la estructura y comportamiento del sistema

Proporcionan plantillas que guan la construccin del sistem
Documentan las decisiones
Validar el software

Por qu las empresas no hacen

modelado?
La mayor parte de las empresas de software no

realizan ningn modelado.

El modelado requiere:
aplicar un proceso de desarrollo
formacin del equipo en la tcnicas
tiempo?

Se obtienen beneficios con el modelado?

Utilidad del modelado

Se facilita la comunicacin entre el equipo

al existir un lenguaje comn.

Se dispone de documentacin que
trasciende al proyecto.
Hay estructuras que trascienden lo
representable en un lenguaje de
programacin.

MV para definir la Arquitectura del

Software
Interface de Usuario
(Visual Basic,
Java, ..)
Lgica del Negocio
(C++, Java, ..)

Servidor de BDs
(C++ & SQL, ..)

Modelar el sistema independientemente

del lenguaje de implementacin

MV promueve la reutilizacin
Multiples Sistemas

Componentes
Reutilizados

El Paradigma
Orientado a Objetos

Por qu la Orientacin a Objetos?

Proximidad de los conceptos de modelado respecto

de las entidades del mundo real

Mejora captura y validacin de requisitos

Acerca el espacio del problema y el espacio de

la solucin

Modelado integra las propiedades estticas y

dinmicas del mbito del problema

Facilita construccin, mantenimiento y

reutilizacin

Por qu la Orientacin a Objetos?

Conceptos comunes de modelado durante el

anlisis, diseo e implementacin

Facilita la transicin entre distintas fases

Favorece el desarrollo iterativo del

sistema
Disipa la barrera entre el qu y el
cmo
Sin embargo, existen problemas ...

Problemas en OO
...Los conceptos bsicos de la OO se conocen
desde hace dos dcadas, pero su aceptacin
todava no est tan extendida como los
beneficios que esta tecnologa puede sugerir
...La mayora de los usuarios de la OO no
utilizan los conceptos de la OO de forma
purista, como inicialmente se pretenda.
Esta prctica ha sido promovida por muchas
herramientas y lenguajes que intentan
utilizar los conceptos en diversos
grados
--Wolfgang
Strigel

Introduccin a UML

UML y el modelado
UML es un lenguaje para visualizar, especificar,
construir y documentar los artefactos de un sistema
que involucra una gran cantidad de software, desde
una perspectiva OO.

UML es una notacin, no es un proceso

Se estn definiendo muchos procesos para UML.
Rational ha ideado RUP, proceso unificado.

Qu es UML?

Unified Modeling Language

Lenguaje unificado para la construccin de

mdelos ( orientado a objetos )

Objetivos de UML
Ser un lenguaje estndar 1997 OMG (Object
Management Group) version 1.1

Definir un lenguaje visual de modelado fcil de

aprender y a la vez rico semnticamente.

Unificar los mtodos Booch, Objetory y OMT
Incluir ideas de otros sistemas de modelado
Incorporar la experiencias prcticas
Responder a las necesidades actuales de los desarrollos
de software.
Vlido para diferentes procesos de desarrollo

Historia de UML
Comenz como el Mtodo Unificado, con la

participacin de Grady Booch y Jim Rumbaugh. Se

present en 1995.

El mismo ao se uni Ivar Jacobson. Los Tres

Amigos son socios en la compaa Rational

Software. Herramienta CASE Rational Rose.

Historia de UML
UML 2.0

2001 ?

UML 1.4

2000 ?
1999
1998
Nov 97

UML 1.3
UML aprobado por el OMG

UML 1.2

Revisiones
menores

Participantes en UML 1.0

Rational Software

MCI Systemhouse
(Grady Booch, Jim Rumbaugh y Ivar
Microsoft
Jacobson)
ObjecTime
Digital Equipment
Oracle
Hewlett-Packard
Platinium Technology
i-Logix (David Harel)
Sterling Software
IBM
Taskon
ICON Computing
Texas Instruments
(Desmond DSouza)
Intellicorp and James Martin
Unisys

& co. (James Odell)

UML aglutina enfoques OO

Rumbaugh
Booch

Jacobson

Odell

Meyer
Pre- and Post-conditions

Shlaer-Mellor
Object life cycles

UML
Harel

State Charts

Gamma et. al.

Frameworks, patterns,
notes

Embly
Singleton classes

Wirfs-Brock
Fusin
Operation descriptions,
message numbering

Responsabilities

Inconvenientes en UML?
Definicin del proceso de desarrollo usando UML.

UML no es una metodologa

Falta integracin con respecto de otras tcnicas

tales como patrones de diseo, interfaces de

usuario, documentacin, etc.
Ejemplos aislados

Perspectivas de UML
UML ser el lenguaje de modelizacin de objetos

estndar predominante los prximos aos

Razones:

Participacin de metodlogos influyentes

Participacin de importantes empresas
Aceptacin del OMG como notacin estndar

Evidencias:
Herramientas que proveen la notacin UML
Edicin de libros
Congresos, cursos, camisetas, etc.

Uso de UML
El objetivo de UML es describir cualquier tipo de

sistema en trminos de diagramas orientados a

objetos
Algunas categoras de Sistemas
Sistemas de Informacin
Sistemas de Tiempo Real
Sistemas Embebidos
Sistemas Distribuidos
Software de Sistemas
Sistemas de Negocios

Tipos de Diagramas UML

Diagrama de Casos de Uso
Diagrama de Clase (incluyendo Diagrama de
Objetos)
Diagramas de Comportamiento
Diagrama de Estados
Diagrama de Actividad
Diagramas de Interaccin
Diagrama de Secuencia
Diagrama de Colaboracin
Diagramas de implementacin
Diagrama de Componentes
Diagrama de Despliegue

Diagrama de Casos de Uso

Realizar transaccin con tarjeta
Cliente

Comercio

Procesar factura cliente

Cliente Individual
Cliente Corporativo

Ajustar transacciones
Entidad financiera

Gestionar cuentas clientes

Diagrama de Clases

Pedido
info
pagoAdelantado? : Boolean
numero : String
precio : Dinero

Cliente
nombre
direccion
*

1..1

entregar()
cerrar()

tipo:String()

1..1

if Pedido.cliente.tipo="Pobre"
then Pedido.pagoAdelantado?
= true

Empresa
Nombre
tipo
creditoLimite
facturar()
avisar()
*

+linea items

*
LineaPedido
cantidad : Integer
precio : Dinero
esSatisfecho : Boolean

+repr ventas

0..1

Empleado

*
1..1

Producto

Personal
tarjetaCredito

{ tipo()="pobre"}

Cliente
+ FormularioPedido
+ FormularioDeSeguimiento
- Pedido

Servidor
+ BaseDeDatos
+ ServicioDeRegistro

import
Politicas
+ ReglasPedidos
+ GUI:Ventana

GUI
+ Ventana
+ Formulario
# GestorEventos

import

Paquetes

Diagrama de Secuencia
:Interface
Entrada Pedido
preparar

:Pedido

:LineaDe
Pedido

:Item

*preparar
hayStock:=comprobar
[hayStock] eliminar
pedir?:=necesarioPedir
[pedir?]<<create>>

PedidoItem

[hayStock] <<create>>

ItemEntregado

Diagrama de Colaboracin
1: preparar
:Interface Entrada
Pedido

2: *preparar
:Pedido

:LineaDe
Pedido

7:
5: pedir?:=necesarioPedir

8: [hayStock] <<create>>
3: hayStock:=comprobar
4: [hayStock] eliminar

:Item

6: [pedir?]<<create>>

Item
Entregado
Pedido
Item

Diagrama de Estados
introducirProducto

Espera Venta

introducirProducto

Introduccion
Productos

Terminar Venta
manejarRespuesta
efectuar Pago Efectivo

Autorizacion
Pago
efectuar Pago Tarjeta

Espera
Pago

Solicitar Producto

Diagrama de
Actividades
Procesar Pedido

Extraer Artculos

Enviar Pedido

Recibir Producto

Pagar Factura

Facturar al cliente

Cerrar Pedido

Componentes

explorador.java

JerarquaElementos

arbol.java

internet
Modem
<<procesador>>
servidor cache

<<red>> red local

<<procesador>
servidor
principal

<<procesador>
servidor

<<procesador>>
servidor

Diagrama de Despliegue

<<procesador>>
servidor

Modelado con UML

Modelado del Negocio
Diagramas de actividades

Modelado de Requisitos
Diagramas de casos de uso

Modelado Estructural
Diagramas de clases
Diagramas de objetos

Modelado del Comportamiento

Diagramas de secuencia
Diagramas de Colaboracin

Modelado con UML

Modelado Dinmico
Diagramas de estados

Modelado Arquitectnico
Diagramas de componentes
Diagramas de despliegue
Paquetes

Modelado con UML

Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Secuencia

Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Casos de Uso

Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Colaboracin
Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Estados

State
State
Diagramas de
Diagrams
Diagrams
Clases

Modelo

Diagramas de
Actividad

State
State
Diagramas de
Diagrams
Diagrams
Objetos
State
State
Diagramas de
Diagrams
Diagrams
Componentes

Component
Component
Diagrams
Diagramas
Diagrams de

Distribucin

Un modelo es una descripcin completa de un sistema desde una perspectiva concreta

Metodologa desarrollo
Una metodologa de desarrollo de software
OO consta de los siguientes elementos:
Diagramas y conceptos ( Modelado)
Etapas y definicin de entrega en cada una
de ellas.
Actividades y recomendaciones.

RUP
Proceso de Desarrollo Unificado
Etapas

Anlisis
de
requerimi
entos

Diseo

Diseo
detallad
o

Implemen
tacin y
pruebas

Anlisis de requerimientos
Actividades tcnicas
1. Identificar Casos de Uso del sistema
2. Dar detalle a los casos de uso descritos
3. Definir una interfaz inicial del sistema (si es aplicable)
4. Desarrollar el modelo del mundo
5. Validar los modelos
Documentos Entregables
Diagrama actividades,Casos de uso iniciales ,borradores
de interfaz, Modelo del mundo inicial (D.Clases)

Etapas del modelo del negocio

Anlisis de requerimientos
MODELO DEL NEGOCIO
Definicin de objetivos, necesidades de la
alternativas, motivacin.
Planificacin, recursos, presupuesto.
Anlisis de riesgos
MODELO DE REQUISITOS
Funciones del sistema
Metas
Procesos
Datos

empresa,

Etapas del modelo del negocio

Anlisis de requerimientos

Comprender el conjunto de procesos de

negocio que tienen lugar dentro de una
empresa, como paso previo a establecer los
requisitos del sistema a desarrollar.
Cmo consigue la empresa sus objetivos?

Etapas del modelo del negocio

Anlisis de requerimientos
Procesos del Negocio
datos
tarea2
tarea1

tarea4

tarea5

tarea3

Reglas del Negocio

determinan polticas y estructura de la
informacin

Etapas del modelo del negocio

Anlisis de requerimientos

Identificar y delimitar los procesos de

negocio segn los objetivos de la

organizacin ( diagrama actividades)
Definir un caso de uso del negocio para
cada proceso del negocio, utilizando un
diagrama de casos de uso del negocio
para mostrar el contexto y los lmites de
la organizacin bajo estudio.

Etapas del modelo del negocio

Anlisis de requerimientos

Identificar los roles implicados en los

diferentes procesos del negocio y

describirlos en un diagrama de roles.

Establecer el modelo conceptual a partir

de las informaciones incluidas en los

diagramas de actividades.
( diagrama de clases )

Ejemplo
Empresa que fabrica productos bajo demanda
Objetivos
Estratgicos
Satisfacer pedido
de cliente
Subobjetivos
Procesos
del Negocio

Registrar
pedido de
cliente

Incrementar las
ventas un 25%

Fabricar
productos
pedidos

Reducir tiempo de
fabricacin un 15%

...

Gestionar
almacn de
materiales

Realizar
pedidos a
proveedores

Gestionar
almacn

Generar
pedidos a
proveedor

Casos de Uso
del Negocio
Registrar
pedido

Fabricar
productos

Etapas del modelo del negocio

Anlisis de requerimientos
Mostrar flujo del proceso mediante diagramas de

proceso
diagramas de actividades con calles que corresponden a
roles

Una actividad puede necesitar ser descrita mediante

otro diagrama de actividad: Objetivos y

Subobjetivos.
Pueden existir procesos de negocio que no
requieran interaccin entre agentes.

Diagrama de Proceso Registrar pedido

: Cliente

: Comercial

: JefeTecnico

:Catalogo
Rellenar pedido

p: Pedido
[propuesto]
:Plantilla de
Fabricacion
Cursar pedido

: JefeProduccion

Demasiado compleja:
Descomposicin
Jerrquica

p: Pedido
[en_evaluacion]
Analizar viabilidad

p:Pedido
[evaluado]
Notificar rechazo
de pedido

[ NO ]

Fin KO
p: Pedido
[rechazado]
Notificar aceptacin
de pedido

: Producto
Especial

Viable?
[ SI ]

:Plantilla de
Fabricacion

Ordenar fabricacion

:Orden de
Trabajo
[pendiente]

Planificar produccion

p: Pedido
[aceptado]

Fin OK

Plantilla de Descripcin Registrar pedido

Proceso de
Negocio

Registrar Pedido

Objetivo

Registrar Pedido de Cliente

Descripcin

1. El cliente enva una orden de pedido, que debe incluir la fecha de solicitud, datos del
cliente y productos solicitados. Es posible que sea un empleado del departamento comercial
quien introduzca el pedido, a peticin de un cliente que realiz su pedido por telfono o lo
envi por fax o correo ordinario al dpto. comercial de la empresa.
2. El empleado revisa el pedido (completndolo, si es necesario), y comienza su
procesamiento envindolo al jefe tcnico, encargado de su anlisis.
3. El jefe tcnico analiza la viabilidad de cada producto pedido por separado:
Si el producto pedido est en el catlogo, su fabricacin es aceptada.
En caso contrario es considerado un producto especial y estudia su produccin:
- Si es viable, la fabricacin del producto especial es aceptada;
- Si no es viable, el producto especial no ser fabricado.
4. Una vez estudiado el pedido completo, el jefe tcnico...
Informa al depto comercial de la aceptacin o rechazo de cada producto pedido;
Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo
para cada producto, a partir de una plantilla de fabricacin (la estndar si el producto
estaba catalogado, o una nueva, especficamente diseada para el producto, si ste no
estaba en el catlogo). Cada orden de trabajo es enviada al jefe de produccin, y queda
pendiente de su lanzamiento.
5. El comercial comunica al cliente el resultado final del anlisis de su pedido.

Rol Externo

Roles Internos

Prioridad

Bsico

Riesgos
Posibilidades
Tiempo Ejec.
Coste Ejec.

...
...
...
...

Casos de Uso del Negocio

<<initiator>>

Registrar pedido
Cliente

Fabricar producto

Gestionar almacen

Generar pedidos a proveedores

Proveedor

Caso de Uso del Negocio:

Registrar Pedido
El cliente realiza un pedido que incluir la
fecha del pedido, los datos del cliente y los
productos solicitados.
2. El comercial revisa el pedido
(completndolo si es necesario) y le da
curso, envindolo al jefe tcnico para que
realice el anlisis del mismo.
3. El jefe tcnico analiza la viabilidad de la
fabricacin de cada producto del pedido
por separado.
1.

Caso de Uso del Negocio:

Registrar Pedido
4. Una vez estudiado el pedido completo, el jefe
tcnico informa al departamento

comercial de la aceptacin/rechazo de
cada producto integrante del pedido.
5. El comercial comunica al cliente el resultado
del anlisis de su pedido.

Etapas del modelo del negocio

Anlisis de requerimientos
Identificamos los agentes participantes

(trabajadores, departamentos,..): Cliente,

Comercial, Jefe Tcnico y Jefe Produccin.
Creamos escenarios para mostrar la colaboracin

entre los agentes, distinguimos entre flujos

bsicos y alternativos:
diagramas de secuencia: objetos son roles (agentes)
diagrama de roles: diagramas de clase pero con roles

Diagrama de roles Registrar Pedido

<<role>>
Cliente

<<role>>
Comercial

*
*

<<role>>
Jefe Tcnico.

<<role>>
Jefe Produccin

Diagrama de Secuencia Registrar Pedido

: Cliente

: Comercial
darCursoPedido()

: JefeTecnico

: JefeProduccion

estudiarPedido()
* analizarFabricacionProducto()
planificarFabricacion()

informarAnalisisPedido()
aceptarPedido()

Reglas de Negocio
Reglas de restriccin
Especifican polticas o condiciones que restringen la
estructura y comportamiento de las informaciones
Estmulo-Respuesta
Restriccin de operacin
Restriccin de estructura

Reglas de derivacin
Especifican polticas o condiciones para inferir nuevos
hechos a partir de otros.

Glosario
...

...
Objeto de Informacin: Pedido

Actividad: Ordenar fabricacion

Reglas de
Origen: Analizar
viabilidad
Estmulo-Respuesta

Atributos
Codigo de pedido
Fecha de solicitud
Fecha lmite de entrega
Conjunto de {Producto}
Cliente
Importe total
Estado Actual

Agente: Jefe Tecnico

Precondiciones: La fabricacion de todos los

Reglas
Estructurales,
de Derivacin y
Restricciones
- El cdigo de pedido identificar unvocamente
de Existencia
el pedido, y ser asignado automticamente
por el sistema
- La fecha de solicitud ser anterior a la fecha
lmite de entrega.
- Un pedido contendr al menos un producto; no
existe lmite mximo de productos.
- Un pedido siempre ser solicitado por uno y
solamente un cliente.
- El importe total ser calculado a partir del
precio de cada producto pedido.
Clase del Dominio : - por especificar -

productos pedidos es viable. Existe una plantilla de

fabricacin para cada uno de dichos productos.
Postcondiciones: Ha sido creada una orden de
trabajo para cada producto, con estado pendiente, y
ha sido enviada al jefe de produccin para su
planificacin.
Caso de Uso : - por especificar-

Reglas de
Operacin

Actividad: Notificar aceptacion de pedido

Origen: Analizar viabilidad
Agente: Comercial
Precondiciones: La fabricacin de todos los
productos pedidos es viable.
Postcondiciones: Se ha comunicad al cliente la
aceptacin de su pedido. El estado del pedido es
aceptado.
Caso de Uso : - por especificar-

Trazabilidad

...

Especificacin de las actividades

Contrato: nombre de la actividad realizada por los actores
Origen: Actividad/es precedente/s
Agente: Actor que realiza la actividad
Precondicin: Estado previo a la realizacin de la actividad
Postcondicin: Estado posterior a la realizacin de la actividad
Caso de uso: Nombre del caso de uso que se corresponde con la
actividad. Este campo no se rellenar hasta que no se
identifiquen los casos de uso.

Modelo de requisitos
Anlisis de requerimientos

Objetivo:
Se establecen los requisitos funcionales y no
funcionales del sistema.
A partir del modelo del negocio se
construye el modelo de casos de uso y el
modelo conceptual inicial.

Modelo de requisitos
Anlisis de requerimientos
De un modo muy simple e intuitivo se obtienen

los casos de uso, actores y clases.

Los casos de uso se extraen de las acciones.
Los actores se extraen de los roles que ejecutan
acciones.
Las clases se extraen de las informaciones.

Utilizar los diagramas de proceso

Modelo de requisitos
Anlisis de requerimientos
Se define un actor para cada rol del diagrama de

proceso que interacta con el sistema: actor

primario.
Se crea un caso de uso por cada actividad que es
soportada por el sistema: Un caso de uso produce
un resultado de valor a un actor.
Niveles de granularidad?
Posibilidad de establecer jerarquas de casos de uso
(jerarquas de actividades)

Modelo de requisitos
Anlisis de requerimientos
De los diagramas de proceso...
rol
actor

actividad

No siempre
objeto

Caso de
Uso
Clase del Dominio

Modelo de requisitos
Anlisis de requerimientos
Definicin de un CASO de USO
Un caso de uso especifica el comportamiento

deseado del sistema.

Representan los requisitos funcionales del
sistema.

Un caso de uso especifica una secuencia de

acciones, incluyendo variantes, que el sistema
puede ejecutar y que produce un resultado
observable de valor para un particular actor
Describe qu hace el sistema, no cmo lo hace.

Casos de Usos
Caso de uso
Documento narativo de un proceso de un
dominio del problema
Proceso
Describe de comienzo a fin una secuencia de
eventos para producir u obtener algo

Casos de Usos
Formato
Caso uso: Nombre
Actores: Lista actores
Propsito: Intencin caso uso
Resumen: Repeticin caso uso
Tipo: 1. Primario, secundario u opcional
2. de alto nvel Esencial o real
Referencias cruzadas: Casos relacionados usos y
funciones

Tipos de casos de uso

Segn el nivel de detalle
Alto nivel:
Expandido:

Descripcin en unas pocas lneas

Descripcin detallada (escenarios)

Segn la importancia
Primario, secundario u opcional

Segn el nivel de abstraccin

Esencial: No se consideran cuestiones de implementacin
Real: Se contemplan detalles de implementacin (interfaces)

CASOS DE USOS
EJEMPLO
Caso Uso: Comprar productos
Actores: Cliente, Cajero
Propsito: Capturar una venta y su pago
Resumen: Un cliente llega a la caja con los
productos que desea comprar. El cajero registra
los productos y recibe el pago. Al terminar la
transaccin, el cliente se marcha con el producto
Tipo: Primario y esencial
Referencias cruzadas R1.1, R1.2 y R1.3

Diagramas de casos Usos

Caso de uso

Actor
Relacin asociacin
Extend
Herencia
Extend

Ejemplo Caso de Uso

actor

caso de uso

Procesar Prstamo
ResponsablePrestamos

asociacion

Propiedades de los casos de uso

Son iniciados por un actor con un objetivo en

mente y es completado con xito cuando el

sistema lo satisface.
Puede incluir secuencias alternativas que llevan
al xito y fracaso en la consecucin del objetivo.
El sistema es considerado como una caja
negra y las interacciones se perciben desde
fuera.
El conjunto completo de casos de uso especifica
todas las posibles formas de usar el sistema, esto
es el comportamiento requerido.
80

Ejemplo

Relacin de extensin

extend
Hacer Pedido

(establecer
prioridad)

include
Relacin de
inclusin

Hacer Pedido
Urgente

Comprobar clave

Validar Usuario

Generalizacin

Seguir Pedido

include

Examinar retina

Introducir Pedido de Cliente Analizar Produccion Productos

Cliente

JefeTecnico
Cursar Pedido

Ordenar Fabricacion Productos

Aceptar Pedido de Cliente

Planificar Produccion

JefeProduccion

Comercial

Denegar Pedido de Cliente

Diagrama de Casos de Uso Registrar Pedido

Casos de uso e iteraciones

Asignarles prioridad
Establecer iteraciones del desarrollo a partir de

los casos de uso.

Varias versiones de un caso de uso complejo,
para aadir complejidad de modo incremental.
Un caso de uso se va refinado en cada iteracin.
Al final un caso de uso esencial se transforma en
su forma real.

Modelo de requisitos
Anlisis de requerimientos

Modelo conceptual
Los objetos informacin entrada y salida de las
actividades representan entidades y conceptos del
dominio.
Se utilizan para crear un modelo conceptual inicial.
Una clase para cada informacin que vaya a ser
tratada por el sistema software.
De la especificacin del diccionario se extraen:
atributos, asociaciones, responsabilidades, restricciones

Modelo de requisitos
Anlisis de requerimientos
Objeto informacin Pedido
Atributos: codigo, fechaRecepcion, importe,
estado, fechaTopeEntrega
Asociaciones: Pedido-Cliente y Pedido-Producto
Restricciones: {fechaTopeEntrega >
fechaRecepcion}
Responsabilidades: obtenerProductos,
cambiarEstado, calcularImporteTotal,
calcularFechaTopeEntrega
Con el conjunto de objetos se crea el modelo
conceptual

Producto Especial

Catalogo

Producto Catalogado

fabricado mediante
Plantilla de Produccion

Producto
1..*
es solicitado en

base de
0..*

0..*
Pedido

genera

0..*

Orden de Trabajo

1..*
realizado por

Cliente

Modelo conceptual inicial

Modelo Conceptual
En el diccionario de informaciones se establece

una conexin entre clase y la informacin que

representa.
No preocuparse en las relaciones entre clases.
Algunos clases pueden representar roles.
Es posible identificar del diagrama de procesos
objetos que pasan por varios estados: diagrama
de estados preliminar.

Modelo de requisitos
Anlisis de requerimientos

Prototipo Inicial
Utilizar los casos de uso.
Incluye las interfaces de usuario

Sirve para validar los requisitos: analista y usuarios

llegan a un acuerdo sobre la funcionalidad y

vocabulario.
Prototipo desechable
Fcil de construir con herramientas visuales.

MODELO DEL ANALISIS

Objetivo:
A partir de los casos de uso obtener el diseo
preliminar del sistema que deber ser refinado
en el modelo del diseo.
Nivel de abstraccin ms alto que en el diseo.
Visin ideal del sistema.
Se define una arquitectura del sistema.
Llegar al sistema final de forma incremental,
mediante evolucin de prototipos.

MODELO DEL ANALISIS

Refinar los casos de uso de la etapa

anterior
(casos de uso esenciales pasarlos a
expandidos y a : primarios secundarios o
opcionales )
Crear los diagramas de casos de usos

MODELO DEL ANALISIS

Diagrama de secuencia del sistema
Para cada caso de uso se define un diagrama de
secuencia del sistema que muestra los eventos que
un actor genera durante la interaccin con el
sistema (caja negra)
Se representa mediante un diagrama de secuencia
en el que los objetos son el actor y el sistema.
Cada evento da origen a una operacin del sistema
El efecto de las operaciones se describen mediante
contratos especificados mediante una plantilla.

DIAGRAMA SECUENCIA DEL SISTEMA

Comprar Articulos

Cajero

Cliente

:Sistema

: Cajero
introducirItem(upc,cantidad)
finalizarVenta()
hacerPago(cantidad)

PLANTILLAS DE CONTRATOS
DE OPERACION
Nombre: signatura de la operacin
Responsabilidades: qu debe hacer la operacin
Tipo: clase controlador que realiza la operacin
Caso de uso: nombre del caso de uso al que pertenece
la operacin
Notas: requisitos no funcionales
Excepciones: casos excepcionales que debe detectar
Salidas: salidas fuera del sistema, sin tener en cuenta
las salidas por pantalla
Precondiciones: condiciones que han de cumplirse
para realizar la operacin
Postcondiciones: estado del sistema despus de
realizar la operacin

Requisitos no funcionales
Un sistema debe poseer caractersticas que no estn

especficamente relacionadas con la funcionalidad

del sistema.
Utilizacin del sistema
facilidad de uso, facilidad de aprendizaje, consistencia de la
interfaz de usuario, documentacin del usuario

Fiabilidad
Rendimiento
Facilidad de mantenimiento.
Entorno de implementacin

Ejemplo: Terminal Punto de Venta

Comprar Productos

Cajero

Cliente

Registrar Productos

Casos de Uso
Gerente

Inicia

Gestion Usuarios

Administrador
Sistema

Modelo
Conceptual

Registra venta de

1
Descrita por

Contiene

Catalogo Productos
1

Producto
1..n
Describe

0..1

0..n
Tienda
direccion
nombre 1

Lineas Venta
cantidad

0..n

Almacena

Item
0..n

1..n
Contenidas en
1
capturada en

Venta
1

1
1

1
pagado por
1
Pago

Iniciado por

TPV

iniciada por
1
Cliente

Gerente
1

Registra Ventas
1
Cajero

Caso de uso Comprar productos

Resumen: Un cliente llega al TPV con un conjunto de artculos. El Cajero

registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge

los artculos.

Pasos:
1. A: El cliente llega al TPV con los artculos.
2. A: El cajero registra el identificador de cada artculo.
3. S: El sistema obtiene el precio de cada artculo y aade la informacin a la
transaccin de venta.
4. A: Al acabar el cajero indica la finalizacin de la introduccin de artculos.
5. S: El sistema calcula el total de la compra y lo muestra.
6. A: El Cajero le dice al cliente el total.
7. A: El cliente realiza el pago.

Caso de uso Comprar productos

8. A: El cajero registra la cantidad de dinero recibida.
9. S: El sistema muestra la cantidad a retornar al cliente y genera un
recibo.
10. A: El cajero deposita el dinero recibido y saca la cantidad a
devolver que entrega al cliente junto al ticket de compra.
11. S: El sistema almacena la compra completada.
12. A: El cliente recoge los artculos comprados.

Variaciones:
Paso 2: Introducir identificador no vlido- Indicar error
Paso 7: El cliente no tiene dinero suficiente. Cancelar transaccin

Extensiones:
10. Diferentes formas de pago: efectivo, tarjeta

Modelo del anlisis

Objetivo:
A partir de los casos de uso obtener el diseo
preliminar del sistema que deber ser refinado en
el modelo del diseo.
Nivel de abstraccin ms alto que en el diseo.
Visin ideal del sistema.
Se define una arquitectura del sistema.
Llegar al sistema final de forma incremental,
mediante evolucin de prototipos.

Modelo del anlisis

Para cada caso de uso se define un diagrama de

secuencia del sistema que muestra los eventos

que un actor genera durante la interaccin con el
sistema (caja negra)
Cada evento da origen a una operacin del
sistema
El efecto de las operaciones se describen mediante
contratos especificados mediante una plantilla.

Cajero

Comprar Articulos

Cliente

:Sistema

: Cajero
introducirItem(upc,cantidad)
finalizarVenta()
hacerPago(cantidad)

Operacion
Operacion
Operacion

CONTRATOS

Diagrama de Secuencia del Sistema

(Caso de Uso Comprar Productos)
:Sistema

: Cajero
Introducir Producto (CUP, cantidad)
Terminar Venta ()
realizar Pago()

eventos del
sistema

Operaciones
del sistema

Plantilla de un Contrato de
Operacin
Nombre: signatura de la operacin
Responsabilidades: qu debe hacer la operacin
Tipo: clase controlador que realiza la operacin
Caso de uso: nombre del caso de uso al que pertenece la operacin
Notas: requisitos no funcionales
Excepciones: casos excepcionales que debe detectar
Salidas: salidas fuera del sistema, sin tener en cuenta las salidas por pantalla
Precondiciones: condiciones que han de cumplirse para realizar la operacin
Postcondiciones: estado del sistema despus de realizar la operacin

Contrato Introducir producto

Nombre: introducirProducto (cup: numero, cantidad: integer)
Responsabilidades: Registrar la venta de un producto y agregarlo a la
venta. Desplegar la descripcin del producto y su precio.
Tipo: Sistema
Notas: Acceso rpido a la base de datos
Excepciones: Si CUP no vlido, indicar error.
Precondiciones: El sistema conoce el CUP
Postcondiciones:
- Si se trata de una nueva venta, un objeto Venta es creado
- Si se trata de una nueva venta, el objeto Venta creado se asocia
al objeto TPV.
- Se cre una instancia de LineasVenta y se asocia a la Venta.
- Se establece LineasVenta.cantidad con el valor cantidad

Modelo del anlisis

Para cada operacin del sistema se define un diagrama de

interaccin que muestra cmo deben colaborar los objetos

para satisfacer las responsabilidades y postcondicin
expresada en el contrato de dicha operacin.
Disear las colaboraciones, asignando responsabilidades a

las clases, es la actividad ms difcil del diseo orientado a

objetos. Utilizaremos patrones de diseo.

Diagrama de Colaboracin
2: [nuev venta] crear()
1: IntroducirProducto(cup, cant)
GUI

6: AddLineaVenta(esp, cant)
: TPV

: Venta

4: esp:= especificacion(cup)
3: crear()
8: add(lv)

: Catalogo
Productos

lv : Lineas
Venta

5: esp:= find(cup)
: Lineas
Venta

:
Producto

7: crear(esp,cant)

Diagramas de Interaccin
Para cada actor especificamos todas sus

interacciones con el sistema mediante este tipo de

diagrama.
Se define un entorno de trabajo para cada usuario.
Facilita la construccin de un prototipo de
validacin.
Son de utilidad para obtener el comportamiento de
las clases.

Modelo del anlisis

1) Se refina el modelo conceptual inicial que se
convierte en un modelo de clases del anlisis.
2) Se extrae comportamiento de las clases a partir de
los diagramas de interaccin.
3) Refinar los diagramas de interaccin de modo que
nuevos objetos participarn en la interaccin.
4) Refinar el diagrama de clases.

Modelo del anlisis

5) Definir los subsistemas
6) Emplear heursticas conocidas para distribuir la
funcionalidad entre las clases.
7) Para aquellas clases con muchos estados y
transiciones entre estados, construir un diagrama de
estados.

Modelo del diseo

Objetivo:
Refinar el diseo del sistema del modelo del anlisis
introduciendo los requisitos no funcionales y restricciones del
entorno de implementacin.
De manera iterativa se refina el diagrama de clase del anlisis

hasta obtener un diseo del sistema adecuado para pasar a la

implementacin:

nuevas clases, atributos, operaciones

mtodos
interfaces
visibilidad, dependencia, navegabilidad

Cuestiones del diseo

Definicin de la arquitectura del sistema
Subsistemas: Paquetes
Patrones de diseo
Estructuras de datos
Diseo del interfaz de usuario
Manejo de la persistencia
Distribucin

Etapas y actividades en un
desarrollo OO basado en UML
A finales de 1998 G. Booch, J.Rumbaugh
e I. Jacobson publican la versin
definitiva de la nueva metodologa de
desarrollo bajo la denominacin de
"Proceso Unificado de Desarrollo". Una
variante de este proceso (el RUP
--Rational Unified Process--)