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 modo

sistemtico la construccin de software.

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
Registrar prestmo Reportar Multas

Libro Biblioteca
Agregar recursos

A/D orientado a objetos 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
2001 ? UML 2.0

2000 ? UML 1.4

1999 UML 1.3

Revisiones menores
1998
UML 1.2
Nov 97 UML aprobado por el OMG
Participantes en UML 1.0

Rational Software MCI Systemhouse

(Grady Booch, Jim Rumbaugh y Ivar
Jacobson)
Microsoft
Digital Equipment ObjecTime
Hewlett-Packard Oracle
i-Logix (David Harel) Platinium Technology
IBM Sterling Software
ICON Computing Taskon
(Desmond DSouza) Texas Instruments
Intellicorp and James Martin Unisys
& co. (James Odell)
 UML aglutina enfoques OO
Rumbaugh
Booch Jacobson

Odell
Meyer
Pre- and Post-conditions

Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusin
Operation descriptions,
message numbering
 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 Cliente
pagoAdelantado? : Boolean
nombre
numero : String
direccion
precio : Dinero
* 1..1
tipo:String()
entregar()
cerrar()
1..1
Empresa Personal
Nombre tarjetaCredito
if Pedido.cliente.tipo="Pobre"
tipo
then Pedido.pagoAdelantado?
creditoLimite
= true

+linea items facturar()

* avisar()
LineaPedido * { tipo()="pobre"}
cantidad : Integer
precio : Dinero 0..1
+repr ventas
esSatisfecho : Boolean
Empleado
*
1..1 Producto
 Cliente

Servidor + FormularioPedido
+ FormularioDeSeguimiento
+ BaseDeDatos - Pedido
+ ServicioDeRegistro

import

Politicas
+ ReglasPedidos
+ GUI:Ventana

import
GUI
+ Ventana
+ Formulario

Paquetes
# GestorEventos
 Diagrama de Secuencia
:Interface :Pedido :LineaDe :Item
Entrada Pedido Pedido
preparar
*preparar
hayStock:=comprobar

[hayStock] eliminar
pedir?:=necesarioPedir

[pedir?]<<create>>
PedidoItem

[hayStock] <<create>> ItemEntregado

 Diagrama de Colaboracin
1: preparar 2: *preparar
:Interface Entrada :Pedido :LineaDe
Pedido Pedido

7:
5: pedir?:=necesarioPedir 8: [hayStock] <<create>>
3: hayStock:=comprobar
4: [hayStock] eliminar

:Item Item
Entregado

6: [pedir?]<<create>>
Pedido
Item
 Diagrama de Estados

introducirProducto

Espera Venta introducirProducto Introduccion

Productos

Terminar Venta

manejarRespuesta
efectuar Pago Efectivo Espera
Pago

Autorizacion
Pago
efectuar Pago Tarjeta
 Diagrama de
Actividades
Solicitar Producto

Procesar Pedido
Extraer Artculos

Enviar Pedido

Recibir Producto Facturar al cliente

Pagar Factura
Cerrar Pedido
Componentes

explorador.java JerarquaElementos arbol.java

 internet

Modem

<<procesador>>
servidor cache

<<red>> red local

<<procesador> <<procesador> <<procesador>> <<procesador>>

servidor servidor servidor servidor
principal

Diagrama de Despliegue
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
State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de Casos de Uso
Diagrams Diagrams
Objetos
Diagrams
Secuencia

Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboracin Modelo Componentes

Scenario Component
Scenario Component
Diagramas
Diagrams de
Diagramas de
Diagrams Diagrams
Diagrams Distribucin
Estados Diagramas de
Actividad

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 Diseo Implemen

de Diseo detallado tacin y
requerimi pruebas
entos
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 empresa,
alternativas, motivacin.
Planificacin, recursos, presupuesto.
Anlisis de riesgos
MODELO DE REQUISITOS
Funciones del sistema
Metas
Procesos
Datos
 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 Incrementar las Reducir tiempo de
...
de cliente ventas un 25% fabricacin un 15%

Subobjetivos
Procesos
del Negocio Registrar Fabricar Gestionar Realizar
pedido de productos almacn de pedidos a
cliente pedidos materiales proveedores
Casos de Uso
del Negocio
Generar
Registrar Fabricar Gestionar pedidos a
pedido productos almacn proveedor
 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 : JefeProduccion

:Catalogo
Demasiado compleja:
Rellenar pedido
p: Pedido
[propuesto] Descomposicin
:Plantilla de
Fabricacion Jerrquica
Cursar pedido p: Pedido
[en_evaluacion]

Analizar viabilidad

p:Pedido
[evaluado]
: Producto
Especial
Notificar rechazo [ NO ] Viable?
de pedido

[ SI ]
Fin KO
:Plantilla de
p: Pedido Fabricacion
[rechazado]

Notificar aceptacin :Orden de

de pedido Trabajo
Ordenar fabricacion [pendiente]

Planificar produccion
p: Pedido
[aceptado]

Fin OK
 Plantilla de Descripcin Registrar pedido
Proceso de
Registrar Pedido
Negocio
Objetivo Registrar Pedido de Cliente
Descripcin
Rol Externo
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.
Roles Internos
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.
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

1. 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.
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>> <<role>>
Cliente Comercial

*
*

<<role>> <<role>>
Jefe Tcnico. Jefe Produccin
 Diagrama de Secuencia Registrar Pedido

: Cliente : Comercial : JefeTecnico : JefeProduccion

darCursoPedido()
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
Atributos Origen: AnalizarEstmulo-Respuesta
viabilidad
Codigo de pedido Agente: Jefe Tecnico
Fecha de solicitud Precondiciones: La fabricacion de todos los productos
Fecha lmite de entrega pedidos es viable. Existe una plantilla de fabricacin para
Conjunto de {Producto}
Cliente Reglas
cada uno de dichos productos.
Reglas de
Postcondiciones: Ha sido creada una orden de trabajo
Importe total
Estructurales, Operacin
para cada producto, con estado pendiente, y ha sido enviada
al jefe de produccin para su planificacin.
Estado Actual
Restricciones de Derivacin y Caso de Uso : - por especificar-

de Existencia
- El cdigo de pedido identificar unvocamente el
pedido, y ser asignado automticamente por el
sistema Actividad: Notificar aceptacion de pedido
- La fecha de solicitud ser anterior a la fecha lmite de
entrega.
Origen: Analizar viabilidad
- Un pedido contendr al menos un producto; no existe
Agente: Comercial
lmite mximo de productos.
Precondiciones: La fabricacin de todos los productos
- Un pedido siempre ser solicitado por uno y pedidos es viable.
solamente un cliente. Postcondiciones: Se ha comunicad al cliente la
- El importe total ser calculado a partir del precio de aceptacin de su pedido. El estado del pedido es a ceptado.
cada producto pedido.
Caso de Uso : - por especificar-
Clase del Dominio : - 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 Caso de Uso

No siempre
objeto 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: Descripcin en unas pocas lneas
Expandido: 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

Hacer Pedido Urgente
(establecer
prioridad)

include
Comprobar clave
Relacin de
inclusin
Validar Usuario
Generalizacin

include
Seguir Pedido 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 Producto Catalogado Catalogo

fabricado mediante
Producto Plantilla de Produccion

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

Cajero Comprar Articulos 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
Inicia
Gerente

Gestion Usuarios
Administrador
Sistema
Modelo
Conceptual Registra venta de

Descrita por Contiene

Catalogo Productos Producto
1 1..n

Describe
0..1
0..n
Tienda Almacena 1
Item
Lineas Venta direccion
cantidad nombre 1 0..n
0..n
1..n
Contenidas en
1
capturada en Iniciado por
Venta TPV Gerente
1 1 1 1
1 1
1
iniciada por Registra Ventas
pagado por
1
1
1
Cliente Cajero
Pago
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)
Operacion
finalizarVenta()
Operacion
hacerPago(cantidad)
Operacion

CONTRATOS
 Diagrama de Secuencia del Sistema
(Caso de Uso Comprar Productos)

:Sistema
: Cajero

Introducir Producto (CUP, cantidad)

Terminar Venta ()

realizar Pago() Operaciones

del sistema

eventos 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) 6: AddLineaVenta(esp, cant)

GUI : TPV : Venta

4: esp:= especificacion(cup)
7: crear(esp,cant)
3: crear()
: Catalogo 8: add(lv)
Productos

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

: Lineas
Venta

:
Producto
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--)