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

Registrar prestmo
Libro Biblioteca

Reportar Multas

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 sistem Proporcionan plantillas que guan la construccin del sistema 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 ?
1999 1998 Nov 97
UML aprobado por el OMG

UML 1.4 UML 1.3

Revisiones menores

UML 1.2

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 (Desmond DSouza) Texas Instruments Intellicorp and James Martin Unisys

& co. (James Odell)

UML aglutina enfoques OO

Rumbaugh Booch Odell Shlaer-Mellor
Object life cycles

Jacobson Meyer
Pre- and Post-conditions

UML
State Charts

Harel

Gamma et. al.

Frameworks, patterns, notes

Embly
Singleton classes

Wirfs-Brock Fusin
Responsabilities 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

Cliente Servidor + BaseDeDatos + ServicioDeRegistro

+ FormularioPedido + FormularioDeSeguimiento - Pedido

import
Politicas + ReglasPedidos + GUI:Ventana

GUI + Ventana + Formulario # GestorEventos

import

Paquetes

Diagrama de Secuencia
:Interface Entrada Pedido preparar *preparar hayStock:=comprobar [hayStock] eliminar pedir?:=necesarioPedir [pedir?]<<create>> :Pedido :LineaDe Pedido :Item

PedidoItem ItemEntregado

[hayStock] <<create>>

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

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

:Item

Item Entregado Pedido Item

6: [pedir?]<<create>>

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> servidor principal

<<procesador> servidor

<<procesador>> servidor

<<procesador>> servidor

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

Use Case Use Case Diagramas Diagrams de Diagrams Secuencia Scenario Scenario Diagramas Diagrams de Diagrams Colaboracin Scenario Scenario Diagramas Diagrams de Diagrams Estados Use Case Use Case Diagramas Diagrams de Diagrams Casos de Uso State State Diagramas Diagrams de Diagrams Clases State State Diagramas Diagrams de Diagrams Objetos State State Diagramas Diagrams de Diagrams Componentes
Component Component Diagrams Diagramas de Diagrams

Modelo

Diagramas de Actividad

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 detallado

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 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 tarea3 tarea4 tarea5

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 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 Incrementar las ventas un 25% Reducir tiempo de fabricacin un 15% ...

Registrar pedido de cliente

Fabricar productos pedidos

Gestionar almacn de materiales

Realizar pedidos a proveedores

Casos de Uso del Negocio

Registrar pedido Fabricar productos Gestionar almacn
Generar pedidos a 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 :Catalogo Rellenar pedido p: Pedido [propuesto] :Plantilla de Fabricacion Cursar pedido p: Pedido [en_evaluacion] Analizar viabilidad : JefeTecnico

Demasiado compleja: Descomposicin Jerrquica

: JefeProduccion

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

: Producto Especial

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

[ SI ] :Plantilla de Fabricacion

Ordenar fabricacion

:Orden de Trabajo [pendiente]

p: Pedido [aceptado]

Planificar produccion

Fin OK

Plantilla de Descripcin Registrar pedido

Proceso de Negocio Objetivo Descripcin
Registrar Pedido Registrar Pedido de Cliente 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 Riesgos Posibilidades Tiempo Ejec. Coste Ejec.

Bsico ... ... ... ...

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 : 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
Atributos Codigo de pedido Fecha de solicitud Fecha lmite de entrega Conjunto de {Producto} Cliente Importe total Estado Actual

...
Actividad: Ordenar fabricacion

Reglas de Estmulo-Respuesta Origen: Analizar viabilidad

Agente: Jefe Tecnico Precondiciones: La fabricacion de todos los productos

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 -

Reglas Estructurales, de Derivacin y Restricciones - El cdigo de pedido identificarExistencia el de unvocamente el pedido, y ser asignado automticamente por

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
actividad actor
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: 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
extend
Hacer Pedido
(establecer prioridad)

Relacin de extensin

Hacer Pedido Urgente

include
Relacin de inclusin

Comprobar clave

Validar Usuario

Generalizacin

Seguir Pedido

include

Examinar retina

Introducir Pedido de Cliente Analizar Produccion Productos

Cliente Cursar Pedido Ordenar Fabricacion Productos

JefeTecnico

Aceptar Pedido de Cliente Comercial

Planificar Produccion

JefeProduccion

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 1..* es solicitado en Plantilla de Produccion

base de 0..* genera 0..* Orden de Trabajo

0..* Pedido 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
Gerente Inicia

Gestion Usuarios

Administrador Sistema

Modelo Conceptual
Descrita por

Registra venta de

1 Catalogo Productos 1 0..1 Tienda direccion nombre 1 Almacena 0..n Contiene 1..n Describe 0..n 1 Item Lineas Venta cantidad 1..n Contenidas en 1 Venta 1 1 pagado por 1 Pago 1 iniciada por 1 Cliente capturada en 1 1 Registra Ventas 1 Cajero TPV 1 Iniciado por 1 Gerente 0..n Producto

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)

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

:Sistema

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

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

7: crear(esp,cant)

: Catalogo Productos

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

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