Distribucion Uml 5e2939

Introducción a la modelización de sistemas orientados a Objetos, usando UML por: BLANCA IBARRA MURRIETA [email protected]

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 Distribución  Hacia un proceso de Desarrollo usando UML  RUP Proceso Desarrollo Unificado  Conclusiones

Construir software es difícil

Métodos

Método  Establece cómo abordar de un sistemático la construcción de software.

modo

 Se describe el problema y la solución mediante un conjunto de modelos.

Método  Importante conocer las limitaciones y beneficios

de los métodos.  Los métodos pueden ayudar pero no aseguran el éxito.  Un método ofrece guías mediante ejemplos de aplicación.  Un método 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 organización” 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 cuándo – asignación de tareas a cada miembro del equipo y al equipo como un todo – proporcionar heurísticas – criterios para controlar el proceso

Proceso Software  Un proceso debe ser iterativo e incremental.

 Conviene centrarse en los aspectos críticos en las primeras iteraciones para minimizar riesgos.  Un método debería describir “procesos por

defecto” y sugerir documentación: “Uno debe crearse su propio proceso”.

Abstracción - Modelado Visual “El modelado captura las partes esenciales del sistema” Pedido Artículo

envío

Proceso de Negocios Sistema Computacional

MODELO DE LA INFORMACION Sistema de informacion BIBLIOTECA

Sistema Catálogo

Bibliotecario

Registrar prestámo Libro

Biblioteca

A/D orientado a objetos

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 resolución

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 s”

“El modelado es la parte central de todas las actividades que conducen a la producción de software de calidad”

¿Por qué modelamos? “Un modelo es una simplificación de la realidad”  Construimos modelos para comprender mejor el sistema que estamos modelando  Cuatro utilidades de los modelos: – Visualizar cómo es o queremos que sea el sistema

– Especificar la estructura y comportamiento del sistem – Proporcionan plantillas que guían la construcción 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 ningún modelado.  El modelado requiere:

– aplicar un proceso de desarrollo – formación del equipo en la técnicas – ¿tiempo?

¿Se obtienen beneficios con el modelado?

Utilidad del modelado Se facilita la comunicación entre el equipo

al existir un lenguaje común. Se dispone de documentación que trasciende al proyecto. Hay estructuras que trascienden lo representable en un lenguaje de programación.

MV para definir la Arquitectura del Software Interface de (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..)

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

“Modelar el sistema independientemente del lenguaje de implementación”

MV promueve la reutilización Multiples Sistemas

Componentes Reutilizados

El Paradigma Orientado a Objetos

¿Por qué la Orientación a Objetos?  Proximidad de los conceptos de modelado respecto de las entidades del mundo real  Mejora captura y validación de requisitos

Acerca el “espacio del problema” y el “espacio de la solución”  Modelado integra las propiedades estáticas y dinámicas del ámbito del problema  Facilita construcción, mantenimiento y

reutilización

¿Por qué la Orientación a Objetos?  Conceptos comunes de modelado durante el

análisis, diseño e implementación – Facilita la transición entre distintas fases – Favorece el desarrollo iterativo del

sistema – Disipa la barrera entre el “qué” y el “cómo”  Sin embargo, existen problemas ...

Problemas en OO “...Los conceptos básicos de la OO se conocen desde hace dos décadas, pero su aceptación todavía no está tan extendida como los beneficios que esta tecnología puede sugerir” “...La mayoría de los s de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretendía. Esta práctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados” --Wolfgang Strigel

Introducción 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 notación, no es un proceso  Se están definiendo muchos procesos para UML.  Rational ha ideado RUP, “proceso unificado”.

¿Qué es UML?

Unified Modeling Language

Lenguaje unificado para la construcción de módelos ( orientado a objetos )

Objetivos de UML  Ser un lenguaje estándar 1997 OMG (Object Management Group) version 1.1

 Definir un lenguaje visual de modelado fácil de aprender y a la vez rico semánticamente.  Unificar los métodos Booch, Objetory y OMT  Incluir ideas de otros sistemas de modelado  Incorporar la experiencias prácticas  Responder a las necesidades actuales de los desarrollos de software.  Válido para diferentes procesos de desarrollo

Historia de UML  Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. Se presentó en 1995.  El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose.

Historia de UML UML 2.0

2001 ?

UML 1.4

2000 ? 1999 1998 Nov „97

UML 1.3 Revisiones menores UML aprobado por el OMG

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 D’Souza)  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 Object life cycles

UML Harel

State Charts

Gamma et. al. Frameworks, patterns, notes

Embly Singleton classes

Wirfs-Brock Fusión

Responsabilities

Operation descriptions, message numbering

¿Inconvenientes en UML?  Definición del proceso de desarrollo usando UML. UML no es una metodología

 Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de , documentación, etc.  Ejemplos aislados

Perspectivas de UML  UML será el lenguaje de modelización de objetos

estándar predominante los próximos años  Razones: – Participación de metodólogos influyentes – Participación de importantes empresas – Aceptación del OMG como notación estándar

 Evidencias: – Herramientas que proveen la notación UML – “Edición” de libros – Congresos, cursos, “camisetas”, etc.

Uso de UML  El objetivo de UML es describir cualquier tipo de sistema en términos de diagramas orientados a

objetos  Algunas categorías de Sistemas – Sistemas de Información – 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 Interacción Diagrama de Secuencia Diagrama de Colaboración Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue

Diagrama de Casos de Uso Realizar transacción con tarjeta Cliente

Comercio

Procesar factura cliente

Cliente Individual Cliente Corporativo

Ajustar transacciones Entidad financiera

Gestionar cuentas clientes

Diagrama de Clases

Cliente

+ FormularioPedido + FormularioDeSeguimiento - Pedido

Servidor + BaseDeDatos + ServicioDeRegistro

import Politicas + ReglasPedidos + GUI:Ventana

GUI + Ventana + Formulario # GestorEventos

import

Paquetes

Diagrama de Secuencia :Interface Entrada Pedido

:Pedido

:LineaDe Pedido

:Item

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

PedidoItem

[hayStock] < >

ItemEntregado

Diagrama de Colaboración 1: preparar :Interface Entrada Pedido

2: *preparar :Pedido

:LineaDe Pedido

7: 5: pedir?:=necesarioPedir

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

:Item

6: [pedir?]< >

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

Diagrama de Actividades Solicitar Producto

Procesar Pedido Extraer Artículos

Enviar Pedido

Recibir Producto

Pagar Factura

Facturar al cliente

Cerrar Pedido

Componentes

explorador.java

JerarquíaElementos

arbol.java

internet Modem <<procesador>> servidor cache

< > 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 Colaboración

Modelado con UML • Modelado Dinámico – Diagramas de estados

• Modelado Arquitectónico – 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 Colaboración 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

Distribución

“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

Metodología desarrollo Una metodología de desarrollo de software OO consta de los siguientes elementos:

Diagramas y conceptos ( Modelado)  Etapas y definición de entrega en cada una de ellas. Actividades y recomendaciones.

RUP Proceso de Desarrollo Unificado Etapas

Análisis de requerimi entos

Diseño

Diseño detallado

Implemen tación y pruebas

Análisis de requerimientos Actividades técnicas  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 Análisis de requerimientos MODELO DEL NEGOCIO Definición de objetivos, necesidades de la empresa, alternativas, motivación. Planificación, recursos, presupuesto. Análisis de riesgos MODELO DE REQUISITOS Funciones del sistema Metas Procesos Datos

Etapas del modelo del negocio Análisis 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. ¿Cómo consigue la empresa sus objetivos?

Etapas del modelo del negocio Análisis de requerimientos Procesos del Negocio datos tarea2 tarea1

tarea4

tarea5

tarea3

Reglas del Negocio determinan políticas y estructura de la información

Etapas del modelo del negocio Análisis de requerimientos

Identificar y delimitar los procesos de

negocio según los objetivos de la organización ( 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 límites de la organización bajo estudio.

Etapas del modelo del negocio Análisis de requerimientos

Identificar los roles implicados en los

diferentes procesos del negocio describirlos en un diagrama de roles.

y

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 Estratégicos Satisfacer pedido de cliente Subobjetivos  Procesos del Negocio

Registrar pedido de cliente

Incrementar las ventas un 25%

Fabricar productos pedidos

Reducir tiempo de fabricación un 15%

...

Gestionar almacén de materiales

Realizar pedidos a proveedores

Gestionar almacén

Generar pedidos a proveedor

Casos de Uso del Negocio Registrar pedido

Fabricar productos

Etapas del modelo del negocio Análisis 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 interacción entre agentes.

Diagrama de Proceso “Registrar pedido” : Cliente

: Comercial

: JefeTecnico

:Catalogo Rellenar pedido

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

: JefeProduccion

Demasiado compleja: Descomposición Jerárquica

p: Pedido [en_evaluacion] Analizar viabilidad

p:Pedido [evaluado] Notificar rechazo de pedido

[ NO ]

Fin KO p: Pedido [rechazado] Notificar aceptación de pedido

: Producto Especial ¿Viable?

[ SI ] :Plantilla de Fabricacion

Ordenar fabricacion

:Orden de Trabajo [pendiente]

Planificar produccion

p: Pedido [aceptado]

Fin OK

Plantilla de Descripción “Registrar pedido” Proceso de Negocio

Registrar Pedido

Objetivo

Registrar Pedido de Cliente

Descripción

1. El cliente envía 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 petición de un cliente que realizó su pedido por teléfono o lo envió por fax o correo ordinario al dpto. comercial de la empresa. 2. El empleado revisa el pedido (completándolo, si es necesario), y comienza su procesamiento enviándolo al jefe técnico, encargado de su análisis. 3. El jefe técnico analiza la viabilidad de cada producto pedido por separado:  Si el producto pedido está en el catálogo, su fabricación es aceptada.  En caso contrario es considerado un producto especial y estudia su producción: - Si es viable, la fabricación del producto especial es aceptada; - Si no es viable, el producto especial no será fabricado. 4. Una vez estudiado el pedido completo, el jefe técnico...  Informa al depto comercial de la aceptación 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 fabricación (la estándar si el producto estaba catalogado, o una nueva, específicamente diseñada para el producto, si éste no estaba en el catálogo). Cada orden de trabajo es enviada al jefe de producción, y queda pendiente de su lanzamiento. 5. El comercial comunica al cliente el resultado final del análisis de su pedido.

Rol Externo

Roles Internos

Prioridad

Básico

Riesgos Posibilidades Tiempo Ejec. Coste Ejec.

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

Casos de Uso del Negocio < >

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 (completándolo si es necesario) y le da curso, enviándolo al jefe técnico para que realice el análisis del mismo. 3. El jefe técnico analiza la viabilidad de la fabricación de cada producto del pedido por separado. 1.

Caso de Uso del Negocio: “Registrar Pedido” 4. Una vez estudiado el pedido completo, el jefe técnico informa al departamento

comercial de la aceptación/rechazo de cada producto integrante del pedido. 5. El comercial comunica al cliente el resultado del análisis de su pedido.

Etapas del modelo del negocio Análisis de requerimientos  Identificamos los agentes participantes (trabajadores, departamentos,..): Cliente, Comercial, Jefe Técnico y Jefe Producción.  Creamos escenarios para mostrar la colaboración

entre los agentes, distinguimos entre flujos básicos y alternativos: – diagramas de secuencia: objetos son roles (agentes) – diagrama de roles: diagramas de clase pero con roles

Diagrama de roles “Registrar Pedido” < > Cliente

< > Comercial

*

*

< > Jefe Técnico.

< > Jefe Producción

Diagrama de Secuencia “Registrar Pedido” : Cliente

: Comercial

darCursoPedido()

: JefeTecnico

: JefeProduccion

estudiarPedido() * analizarFabricacionProducto() planificarFabricacion()

informarAnalisisPedido() aceptarPedido()

Reglas de Negocio  Reglas de restricción – Especifican políticas o condiciones que restringen la estructura y comportamiento de las informaciones • Estímulo-Respuesta • Restricción de operación • Restricción de estructura

 Reglas de derivación – Especifican políticas o condiciones para inferir nuevos hechos a partir de otros.

Glosario ...

... Objeto de Información: Pedido

Reglas de Estímulo-Respuesta Origen: Analizar viabilidad

Actividad: Ordenar fabricacion

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

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

Reglas Estructurales, de Derivación y Restricciones - El código de pedido identificará unívocamente el de Existencia pedido, y será asignado automáticamente por el

sistema - La fecha de solicitud será anterior a la fecha límite de entrega. - Un pedido contendrá al menos un producto; no existe límite máximo 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 -

…

pedidos es viable. Existe una plantilla de fabricación 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 producción para su planificación. Caso de Uso : - por especificar-

Reglas de Operación

Actividad: Notificar aceptacion de pedido Origen: Analizar viabilidad Agente: Comercial Precondiciones: La fabricación de todos los productos

pedidos es viable.

Postcondiciones: Se ha comunicad al cliente la aceptación de su pedido. El estado del pedido es aceptado. Caso de Uso : - por especificar-

Trazabilidad

...

Especificación de las actividades Contrato: nombre de la actividad realizada por los actores Origen: Actividad/es precedente/s Agente: Actor que realiza la actividad Precondición: Estado previo a la realización de la actividad Postcondición: Estado posterior a la realización 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 Análisis 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 Análisis 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 Análisis de requerimientos  Se define un actor para cada rol del diagrama de proceso que interactúa 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 jerarquías de casos de uso (jerarquías de actividades)

Modelo de requisitos Análisis de requerimientos  De los diagramas de proceso... rol actor

actividad

Caso de Uso

No siempre objeto

Clase del Dominio

Modelo de requisitos Análisis de requerimientos Definición 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 cómo 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 Propósito: Intención caso uso Resumen: Repetición caso uso Tipo: 1. Primario, secundario u opcional 2. de alto nível Esencial o real Referencias cruzadas: Casos relacionados usos y funciones

Tipos de casos de uso  Según el nivel de detalle – Alto nivel: – Expandido:

Descripción en unas pocas líneas Descripción detallada (escenarios)

 Según la importancia – Primario, secundario u opcional

 Según el nivel de abstracción – Esencial: No se consideran cuestiones de implementación – Real: Se contemplan detalles de implementación (interfaces)

CASOS DE USOS EJEMPLO Caso Uso: Comprar productos Actores: Cliente, Cajero Propósito: 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 transacción, 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 Relación asociación Extend

Herencia Extend

Ejemplo Caso de Uso actor

caso de uso

Procesar Préstamo 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 consecución 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

Relación de extensión

«extend» Hacer Pedido

(establecer prioridad)

«include» Relación de inclusión

Seguir Pedido

Validar

«include»

Hacer Pedido Urgente

Comprobar clave

Generalización

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 añadir complejidad de modo incremental.  Un caso de uso se va refinado en cada iteración.

 Al final un caso de uso esencial se transforma en su forma real.

Modelo de requisitos Análisis de requerimientos

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

Modelo de requisitos Análisis de requerimientos Objeto información “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 conexión entre clase y la información 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 Análisis de requerimientos

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

 Sirve para validar los requisitos: analista y s

llegan a un acuerdo sobre la funcionalidad y vocabulario.  Prototipo desechable  Fácil de construir con herramientas visuales.

MODELO DEL ANALISIS Objetivo: – A partir de los casos de uso obtener el diseño preliminar del sistema que deberá ser refinado en el modelo del diseño. – Nivel de abstracción más alto que en el diseño. Visión ideal del sistema. – Se define una arquitectura del sistema. – Llegar al sistema final de forma incremental, mediante evolución 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 interacción 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 operación 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 operación Responsabilidades: qué debe hacer la operación Tipo: clase controlador que realiza la operación Caso de uso: nombre del caso de uso al que pertenece la operación 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 operación Postcondiciones: estado del sistema después de realizar la operación

Requisitos no funcionales  Un sistema debe poseer características que no están específicamente relacionadas con la funcionalidad del sistema. – Utilización del sistema • facilidad de uso, facilidad de aprendizaje, consistencia de la interfaz de , documentación del

– – – –

Fiabilidad Rendimiento Facilidad de mantenimiento. Entorno de implementación

Ejemplo: Terminal Punto de Venta Comprar Productos

Cajero

Cliente

Registrar Productos

Casos de Uso Gerente

Inicia

Gestion s

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

1

Almacena

Item 0..n

1..n Contenidas en 1 capturada en

Venta 1

1

1 Pago

1

iniciada por 1 Cliente

Gerente 1

1

1

1 pagado por

Iniciado por

TPV

Registra Ventas 1 Cajero

Caso de uso “Comprar productos” Resumen: Un cliente llega al TPV con un conjunto de artículos. El Cajero registra los artículos y se genera un ticket. El cliente paga en efectivo y recoge los artículos.

Pasos: 1. A: El cliente llega al TPV con los artículos. 2. A: El cajero registra el identificador de cada artículo. 3. S: El sistema obtiene el precio de cada artículo y añade la información a la transacción de venta. 4. A: Al acabar el cajero indica la finalización de la introducción de artículos. 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 artículos comprados.

Variaciones: Paso 2: Introducir identificador no válido- Indicar error Paso 7: El cliente no tiene dinero suficiente. Cancelar transacción

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

Modelo del análisis Objetivo: – A partir de los casos de uso obtener el diseño preliminar del sistema que deberá ser refinado en el modelo del diseño. – Nivel de abstracción más alto que en el diseño. Visión ideal del sistema. – Se define una arquitectura del sistema. – Llegar al sistema final de forma incremental, mediante evolución de prototipos.

Modelo del análisis  Para cada caso de uso se define un diagrama de secuencia del sistema que muestra los eventos que un actor genera durante la interacción con el sistema (caja negra)  Cada evento da origen a una operación 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 Operación Nombre: signatura de la operación Responsabilidades: qué debe hacer la operación Tipo: clase controlador que realiza la operación Caso de uso: nombre del caso de uso al que pertenece la operación 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 operación Postcondiciones: estado del sistema después de realizar la operación

Contrato “Introducir producto” Nombre: introducirProducto (cup: numero, cantidad: integer) Responsabilidades: Registrar la venta de un producto y agregarlo a la venta. Desplegar la descripción del producto y su precio. Tipo: Sistema Notas: rápido a la base de datos Excepciones: Si CUP no válido, 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 análisis  Para cada operación del sistema se define un diagrama de

interacción que muestra cómo deben colaborar los objetos para satisfacer las responsabilidades y postcondición expresada en el contrato de dicha operación.  Diseñar las colaboraciones, asignando responsabilidades a

las clases, es la actividad más difícil del diseño orientado a objetos. Utilizaremos patrones de diseño.

Diagrama de Colaboración 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 Interacción  Para cada actor especificamos todas sus interacciones con el sistema mediante este tipo de diagrama.  Se define un entorno de trabajo para cada .  Facilita la construcción de un prototipo de validación.

 Son de utilidad para obtener el comportamiento de las clases.

Modelo del análisis 1) Se refina el modelo conceptual inicial que se convierte en un modelo de clases del análisis. 2) Se extrae comportamiento de las clases a partir de los diagramas de interacción. 3) Refinar los diagramas de interacción de modo que nuevos objetos participarán en la interacción. 4) Refinar el diagrama de clases.

Modelo del análisis 5) Definir los subsistemas 6) Emplear heurísticas 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 diseño Objetivo: Refinar el diseño del sistema del modelo del análisis introduciendo los requisitos no funcionales y restricciones del entorno de implementación.  De manera iterativa se refina el diagrama de clase del análisis

hasta obtener un diseño del sistema adecuado para pasar a la implementación: – – – –

nuevas clases, atributos, operaciones métodos interfaces visibilidad, dependencia, navegabilidad

Cuestiones del diseño  Definición de la arquitectura del sistema

 Subsistemas: Paquetes  Patrones de diseño  Estructuras de datos

 Diseño del interfaz de  Manejo de la persistencia  Distribución

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