Análisis y Diseño OO con UML y Herramientas Rational
Noviembre 2007
1
Agenda • • • • •
•
•
•
Introducción conceptos y elementos del paradigma orientado a objetos. UML – Modelo Modelo Concept Conceptual. ual. Proceso Unificado de Desarrollo Modelado de Requerimientos con UML • Diagramas de clases • Diagramas de caso de uso • Especificación de Casos de Uso • Prototipado • Patrones de Casos de Uso Modelado de Análisis con UML • Diagramas de Interacción • Diagrama de Clases de Análisis Modelado de Diseño con UML • Diagramas de Interacción • Clases de Diseño • Patrones de Diseño Herramientas de modelado Rational 2
Orientación a Objetos... La Orientación a Objetos como medio para la generación de Programas, tiene varias ventajas: Fomenta una metodologí a basada basada en compon component entes es para el desarrollo del SW, de manera que: 9 Se genera genera un sistema sistema media mediante nte un un conjunto conjunto de de objetos... 9 Luego, se puede ampliar el sistema: 9 Agregándole funcionalidad a los componentes que ya había generado. 9 Agregándole componentes nuevos. 9 Finalmente, podrá volver volver a utiliz uti lizar ar los obje objetos tos utilizar que gener generó ó para el el sistema sistema cuando cuando cree cree uno nuevo... Con lo cual reducirá sustanc sustancial ialmen mente te el TIEM TIEMPO PO de desarrollo de un sistema. 3
OBJETOS, Objetos por doquier!!! 9 En el mundo estamos rodeados de OBJETOS.
El Software actual simula al mundo (o una parte de él). 9 Los Programas, por lo general, imitan a los OBJETOS del mundo. 9
4
Qué es un Objeto? 9 9
5
Lavarropas Marca Modelo Numero de S Serie erie Capacidad AgregarRopa() AgregarJabonEnPolvo() SacarRopa()
Atr Atribut ibutos os - Car Caracte acterrísti ística cas s Acciones - Métodos
Lavarropas Marca Modelo NumeroSerie Capacidad VolumenTambor CronometroInterno Motor VelocidadMotor AgregarRopa() AgregarJabonEnPolvo() SacarRopa() AgregarBlanqueador() CronometrarRemojo() CronometrarLavado() CronometrarEnjuague() CronometrarCentrifugado()
Más atributos y acciones Asemejan al Objeto mucho Mas a la realidad...
6
Abstracción
La abstracción centra su atención en las características esenciales de un objeto en relación a la perspectiva del observador. (Manejo de la Complejidad) 7
Encapsulamiento
El Encapsulamiento oculta detalles de implementación de un objeto (Separamos el Qué del Cómo – Ej. Interfaz de la Implementación)
8
Modularidad
Artículos Articulo
Pedidos
Rubro
Origen
DetallePedido
Artículos
PedidoHist
Pedido
Pedidos
Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes. 9
Contabilidad
Clientes
Ventas
Jerarquía de Partes: Agregación
Es el orden de las abstracciones organizado por niveles.
10
Jerarquía de Clases: Herencia
La herencia es una herramienta que permite definir nuevas clases en base a otras clases existentes.
11
Tipificación Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.
Concurrencia Es la propiedad que distingue un objeto que está activo de uno que no lo está. Permite a dos objetos actuar
al mismo tiempo.
Persistencia Es la propiedad de un objeto, por la cual su existencia trasciende el tiempo y/o el espacio. 12
Qué es un Modelo? U n m o d el o e s u n a s im p l if i c a c i ó n de la realidad Es una r e p r e s e n t a c i ó n a bajo costo de la r e a l i d a d .
Construimos modelos para poder comprender mejor el sistema que estamos desarrollando... 13
Objetivos del modelado
Los modelos ayudan a visualizar cómo es que queremos que sea un sistema. Los modelos permiten especificar la estructura o el comportamiento de un sistema. Los modelos proporcionan plantillas que sirven de guía en la construcción del software. Los modelos documentan las decisiones que se han adoptado.
“Los modelos nos sirven para simplificar la complejidad” 14
El Modelado visual Había una vez un Proyecto...
…lo que solicitó el cliente
…lo que se presupuestó
…lo que construyó el desarrollador
…lo que entendió el analista
…lo que se diseñó
…cómo quedó finalmente
LO QUE REALMENTE SE NECESITABA
15
UML
16
¿Por qué UML? UML es un lenguaje estándar para escribir “planos” de software. UML es un Lenguaje independiente del proceso de desarrollo aunque para que sea utilizado óptimamente se debe utilizar un proceso que sea dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.
Lenguaje Lenguaje
Método
Proceso
Notación + Reglas
Proceso
Pasos a seguir
Método
Qué + Cómo + Porqué 17
Qué NO es UML? 9 Un
lenguaje de programación visual.
9 La
especificación de una herramienta o un repositorio.
9 UNA
METODOLOGÍA, MÉTODO O PROCESO .
18
Por qué UML es un Lenguaje? 9
Pr o v e e u n v o ca b u l a r i o y r e g l as p a r a co m b i n a r l o s e le m e n t o s d e l v o c ab u l a r i o co n e l p r o p ó s i t o d e comunicar. 9
En u n l e n g u a j e d e m o d e l a d o e so s v o ca b u l a r i o s y r e g l a s se f o c al i za n e n r e p r e se n t a ci o n e s co n ce p t u a l es y f ís i ca s d e u n s i s t e m a .
19
UML se utiliza para …
Visualizar: UML es un lenguajes gráfico y es algo más que un conjunto de símbolos gráficos. Detrás de cada símbolo en la notación UML hay una semántica bien definida. Especificar: tiene que ver con la construcción de modelos precisos, no ambiguos y completos. UML cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar y desplegar un sistema con gran cantidad de software. Construir: UML no es un lenguaje de programación visual, pero sus modelos pueden conectarse de forma directa a una gran variedad de lenguajes de programación, esto permite realizar ingeniería directa, es decir, la generación de código a partir de los modelos. Documentar: UML permite generar una serie de artefactos además del código fuente. 20
Modelo Conceptual de UML
Bloques de Construcción de UML - Elementos - Relaciones - Diagramas Reglas de UML - Reglas Semánticas - Para la Construcción de Modelos Mecanismos Comunes de UML 21
Bloques de Construcción: Elementos
Estructurales
De Comportamiento
De Agrupación
De Notación
22
Elementos: Estructurales
Clase
Interfaz
Colaboración
Caso de Uso
Cliente
ICuenta Corriente Cadena de Responsabilida d
Registrar Pedido
Clase Activa
Componente
Nodo
23
form.java
Servidor
Elementos: de Comportamiento
Interacción
Máquina de Estados
mostrarDescripción()
Pendiente
Fabricado
Entregado
24
Cancelado
Elementos de Agrupación y Notación Paquetes
De Comportamiento
Notas
De Agrupación
Ventas
Controlar este com ponente luego de la sigui ente revisión de diseño
texto simple
De Anotación V er http://www.rational.com para informac ión adicional sobre UML
URL embebida
Ver a lgor1.doc para obtener detalles s obre este proceso
link a un documento 25
Bloques de Construcción: Relaciones
Dependencia
Asociación
Generalización
Realización
26
Bloques de Construcción: Diagramas
Clases Objetos Casos de Uso Componentes Despliegue
Interacción
Colaboración Secuencia Estados Actividades
27
Cubren la vista estática de un sistema
Cubren la vista dinámica de un sistema
Reglas de UML: Semánticas Nombres: Cómo llamar a los elementos, relaciones y diagramas. Alcance: El contexto que da un significado específico a un nombre. Visibilidad: Cómo se pueden ver y utilizar esos nombres por otros. Integridad: Cómo se relacionan apropiada y consistentemente unos elementos con otros. Ejecución: Qué significa ejecutar o simular un modelo dinámico.
28
Reglas de UML: Construcción de Modelos
Abreviados: Ciertos elementos se ocultan para simplificar la vista. Incompletos: Pueden estar ausentes algunos elementos, por lo menos en los tramos iniciales del desarrollo. Inconsistentes: En estos casos no se garantiza la integridad del modelo. 29
Mecanismos Comunes Especificaciones UML es más que un lenguaje gráfico. Detrás de cada elemento de notación gráfica hay una especificación que proporciona una explicación textual de la sintaxis y semántica de ese bloque de construcción
Adornos
Persona Nombre Domicilio Teléfono Situación IVA CUIT
Adornos
La letra en cursiva es un adorno que se usa para indicar que es una clase abstracta.
Divisiones Comunes Al modelar sistemas orientados a objetos las cosas pueden dividirse al menos en un par de formas Reglas de UML M. Comunes
Mecanismos de extensibilidad Estereotipos, Valores etiquetados, Restricciones 30
Vistas de un Sistema con UML
Vista de implementación
Vista de diseño
Definen la Arquitectura del Sistema
Vista de Casos de Uso Vista de procesos
Vista de despliegue
31
DIAGRAMAS Use Case Use Case Diagrams Diagrams
State State Diagrams Diagrams
Use Case Use Case Diagrams Diagrams
Scenario Scenario Diagrams Diagrams
State State Diagrams Diagrams
State State Diagrams Diagrams
Scenario Scenario Diagrams Diagrams
Component Component Diagrams Diagrams
32
Diagramas UML 2.0
33
Proceso Unificado de Desarrollo Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En la ingeniería de software el objetivo es entregar un producto de software que satisfaga las necesidades del usuario de forma eficiente y predecible. El Proceso Unificado es un proceso de desarrollo de software que utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema de software.
Características Proceso dirigido por casos de uso Proceso centrado en arquitectura Proceso iterativo e incremental
34
Ciclo de vida del Proceso Unificado El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo concluye con una versión del producto para los clientes. Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase a su vez puede tener varias iteraciones:
Inicio
Elaboración
Iteración Iteración - - #1 # 2 ...
Construcción
Transición Iteración Iteración --- --#n # n-1
--- ---
Versiones
Cada ciclo produce una nueva versión del sistema que es un producto preparado para su entrega. Consta de código fuente incluido en componentes que puede compilarse y ejecutarse, manuales y otros productos asociados. 35
Ciclo de vida del Proceso Unificado Modelo de Casos de Uso Especificado por
Modelo de Análisis
Realizado por
Distribuído por
Modelo de Diseño
Implementado por
Modelo de Despliegue Verificado por
Modelo de Implementación
Modelo de Prueba
36
X OK X OK
X OK
Fases de PUD
Fase de Inicio: Principalmente esta fase responde a las preguntas sobre
cuáles son las principales funciones del sistema para sus usuarios más importantes, cómo podría ser la arquitectura del sistema y cuál es el plan del proyecto, además de cuánto costará desarrollar el sistema. Se realiza un modelo de casos de uso simplificado, con los más críticos; la arquitectura es un esbozo que muestra los principales subsistemas, se identifican y priorizan los riesgos, se planifica en detalle la fase de elaboración y se estima el proyecto. Fase de elaboración: Se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema. La arquitectura se expresa en forma de vistas de todos los modelos del sistema (decimos vista de los modelos porque no son los modelos completos, ya que faltan incorporar casos de uso). Se crea una línea base de la arquitectura. Fase de construcción: Aquí la línea base de la arquitectura crece hasta convertirse en el sistema completo, obteniendo así un producto preparado para ser entregado a los usuarios. Fase de transición: En esta fase el producto se convierte en versión una beta . Un número reducido de usuarios, con experiencia, prueba el sistema e informa defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan las mejoras sugeridas. Esta fase incluye además las tareas de formación del cliente, ayuda en línea y asistencia. 37
Conceptos básicos del PUD Flujo de Trabajo (Workflow) Es un conjunto de actividades. Un flujo de trabajo determina cómo fluye el trabajo de un trabajador a otro. Para ello se ha identificado primero qué tipos de trabajadores participan en el proceso. Luego se identifica qué artefactos se necesitan crear durante el proceso por cada tipo de trabajador. Entonces se puede describir cómo fluye el proceso a través de los distintos trabajadores y cómo ellos crean, producen y utilizan los artefactos de los demás.
Artefacto Es un término general para cualquier tipo de información creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema. Por Ej: los diagramas UML y su texto asociado, los bocetos de la interfaz del usuario, etc.
Trabajador Se denomina así a los puestos a los cuales se pueden asignar personas. Un tipo de trabajador es un papel que una persona puede desempeñar en el desarrollo de software. Puede ser un especificador de casos de uso, un arquitecto, un ingeniero de componentes, un ingeniero de pruebas, etc. Cada trabajador es responsable de un conjunto completo de actividades.
Actividades Son trabajos significativos para una persona 3 8 que actúa como trabajador.
Flujos de trabajo fundamentales del PUD Requisitos Análisis Diseño Implementación Prueba
39
Flujos de trabajo fundamentales del PUD Fases Flujos de trabajo fundamentales
Inicio
Elaboración
Construcción
Transición
Requisitos
Análisis
Diseño
Implementación
Prueba Iteración Iteración #1 # 2 ...
---
--- --- ---
Iteraciones
40
- - - Iteración Iteración #n # n-1
Modelado de Requerimientos con UML •Diagramas de clases •Diagramas de caso de uso •Especificación de Casos de Uso •Prototipado •Patrones de Casos de Uso
41
Diagrama de Clases de Estructura, Estático, Lógico.
9 9
Explorar conceptos del dominio. 9 Analizar Requerimientos. 9 Mostrar el diseño detallado del SW Orientado a Objetos. 9
: un conjunto de clases, interfaces, colaboraciones y sus relaciones. 9
9 9 9 9
Clases Interfaces (tipo especial de clases) Relaciones 42
Diagrama de Clases: Conceptos Un objeto representa un elemento, unidad o entidad individual e identificable, real o abstracta, con un papel bien definido. Un objeto tiene: estado, comportamiento e identidad. Una clase es un conjunto de objetos que comparten una estructura común y un comportamiento común.
Artículo códigoArtículo descripción cantidadExistente cantidadMínima precioCompra precioVenta crear() mostrar() actualizarStock()
Nombre de la Clase Atributos de la Clase Operaciones de la Clase
43
Diagrama de Clases Para identificar clases se debe considerar identificar en el dominio de análisis, aquello que se necesita que el sistema administre y que pueden ser: • cosas tangibles (producto, herramienta, automóvil) • lugares (Barrio, Provincia, País, Zona) • transacciones o operaciones (Venta, Pago, Pedido) • hechos o eventos (Reserva, Vuelo, Accidente, Incidente) • roles de personas (Proveedor, Cliente, Empleado) • contenedores de otras cosas (Almacén) • catálogos (catalogo de productos) • otras organizaciones u áreas (Ministerio, Juzgado, dpto. de ventas) 44
Diagrama de Clases: Relaciones Relación de Asociación
1
Gasto
Tipo de Gasto
Asociación
45
Diagrama de Clases: Relaciones Relación de Agregación
1..*
Factura
DetalleFactura
Agregación
46
Diagrama de Clases: Relaciones Relación de Generalización Ventana
Alumno
Profesor
abrir() cerrar() mover() maximizar()
V entana de Consola
Ayudante
Caja de Diálogo
Generalización
47
Diagrama de Clases: Relaciones Relación de Dependencia Ven tan a Evento abrir() cerrar() m over() m axim izar()
Dependencia
48
Ejemplo de Diagrama de Clases Persona
nroSocio autorizado concepto
Ejemplar
Alquiler
Socio
fechaIngreso fechaBaja
numeroAlquiler fechaAlquiler fechaDevolucionPrevista fechaDevolu cionReal
1
dn i
motivoBaja estado
fechaPago montoPago
apellido nombre domicilio telefono
1
conocerEstado() actualizarEstado() conocerFechaIngreso()
conocerSocio() conocerEjemplar()
1..*
conocerEstado() new() delete() getDni() mostrarDni()
Pelicula nombrePelicula
EmpleadoVideo
numeroPelicula añoEstreno director
1
Categoria
duracion
turno fechaIngreso
1
conocerEjemplares() buscarEjemplares() mostrarNombrePelicula()
horaInicioTurno horaFinTurno
getNombrePelicula()
conocerTurno() conocerHoraIngreso() conocerHoraSalida()
1 Calificacion 1 Rubro
49
Pautas para la construcción de Diagramas de Clases •
Encontrar las clases esenciales en el dominio del problema
•
Pensar en aquello de lo que se necesita guardar información
•
Realizar un listado de clases candidatas
•
Determinar si las clases candidatas representar a un conjunto de objetos del mismo tipo.
•
Definir la información que guardaría cada clase
•
Establecer cuáles serían las operaciones de cada clase
•
Definir las relaciones.
•
Encontrar nuevas clases.
•
Agregar la multiplicidad y navegabilidad a las relaciones definidas.
•
Completar todo el diagrama con los atributos y operaciones faltantes después de haber establecido las relaciones 50
Diagrama de Objetos de Estructura, Estático, Lógico.
9 9
Representar el estado de un sistema en un momento de tiempo. 9
9
: un conjunto de objetos y sus relaciones.
9 9 9
Objetos Conexiones (Links)
51
Ejemplo de Diagrama de Objetos S1:Socio
E1:Ejemplar
:Alquiler
P1:Pelicula
52
Diagrama de Casos de Uso de Comportamiento, Estático, Lógico.
9 9
Comunicar el Alcance. 9 Proveer descripción de todo o una parte de los requerimientos de un sistema u organización. 9
: un conjunto de casos de uso, actores y sus relaciones. 9
9
Casos de Uso 9 Actores 9 Relaciones de extensión, inclusión, generalización. 9 Paquetes 9
53
Diagrama de Casos de Uso
Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema o un subsistema.
El diagrama de casos de uso permite que los desarrolladores y los clientes lleguen a un acuerdo sobre los requisitos, es decir sobre lo que debe cumplir el sistema y constituye la entrada principal para el análisis, el diseño y las pruebas.
D o s o b j e t i v o s c la v e s: Î M o d e la r e l Co n t e x t o d e l Si st e m a Î M o d e la r l o s Re q u e r i m i en t o s/ Re q u i s it o s d e l Si st e m a 54
Notación del Diagrama de Casos de Uso
Actor
Caso de Uso
Relaciones
Asociación Generalización Inclusión Extensión
55
Actor
Un actor es el rol que juega un usuario en relación al sistema. Normalmente, un actor representa un rol que es jugado por una persona, un dispositivo de hardware o incluso otro sistema al interactuar con nuestro sistema. El diagrama de casos de uso describe lo que hace el sistema para cada tipo de usuario. Cada usuario puede representarse por uno o más actores.
Los Actores pueden ser: Actor Primario: Tiene un objetivo claro que debe ser tenido en
cuenta y concretado con la ayuda del sistema de información. Actor Secundario: Es de quién el sistema necesita ayuda para cumplir con el objetivo del actor primario. 56
Casos de Uso
Un caso uso representa cada forma en que los actores usan el sistema. Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Un caso de uso es una “especificación”. Especifica el comportamiento de “cosas”dinámicas, en este caso instancias de casos de uso. Una instancia de un caso de uso es la realización (o ejecución) de un caso de uso del sistema de información.
Los Casos de Uso pueden ser
Esenciales: describen la funcional principal o esencial con la que tiene
De Soporte: comprenden la funcionalidad que surge a partir de
que cumplir el sistema. Comprenden los principales procesos que debe ejecutar el sistema de información. analizar aquello que se necesita para que pueden funcionar los casos de uso esenciales. 57
Los Casos de Uso son describen definen particionan
descripciones de la funcionalidad del sistema independientes de la implementación los límites del sistema y las relaciones
entre el sistema y el entorno el conjunto de requerimientos, atendiendo a la categoría de usuarios que participan en el mismo en forma de acciones y reacciones, el
comportamiento de un sistema desde el punto de vista del usuario (el usuario debería poder entenderlos para realizar su validación) 58
Qué asumimos para la definición de Casos de Uso? 9
: Determinación de REQUERIMIENTOS (Funcionales)
9
: Descripción por medio de PROSA CONSISTENTE
9
: MULTIPLES ESCENARIOS
9
: SEMIFORMAL
59
Relación de Generalización entre actores Pueden definirse categorías generales de actores y especializarlos a través de relaciones de generalización.
Los actores especializados (hijos) heredan el comportamiento del actor padre.
Si un caso de uso es instanciado por el actor “padre” puede ser instanciado por cualquiera de sus hijos. Ahora bien podría haber casos de uso que son instanciados por uno de los actores “hijo” en particular.
60
Relaciones Inclusión entre Casos de Uso Una relación de inclusión entre casos de uso significa que un caso de uso
base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado en el
caso base. Esto se realiza para reutilizar un mismo flujo de eventos desde distintos puntos del sistema. El caso de uso incluido nunca es instanciado por un actor, sino que es instanciado por el/los casos de uso que lo incluyen. Por ello, un caso de uso de inclusión es siempre un caso de uso abstracto . Se dibuja con una flecha desde el Caso de Uso concreto o base al use case abstracto (adicional). 61
Relaciones de Extensión entre Casos de Uso La extensión puede verse como que el caso de uso que
extiende incorpora su comportamiento en el caso de uso base. Una relación de
extensión se utiliza para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma se separa el comportamiento opcional del obligatorio. También puede utilizarse para modelar un subflujo separado que sólo se ejecuta bajo ciertas circunstancias. Se dibuja con una flecha cuya dirección va desde el Caso de Uso de extensión (adicional) al Caso de Uso base. 62
Relación de Generalización entre casos de uso. La generalización entre casos de uso es como la generalización entre clases. En este contexto significa que el caso de uso hijo hereda el comportamiento del caso de uso padre. El hijo puede modificar y/o agregar comportamiento al caso de uso heredado.
63
Construcción del Diagrama de Casos de Uso Requerimiento: Identificar y gestionar casos
Identificar los Actores Definir la funcionalidad esencial relacionada a cada actor a través de casos de uso. Identificar parte de funcionalidad común y opcional en los casos de uso, y agregar relaciones de inclusión, extensión y generalización. Definir casos de uso de soporte, que ayuden a que la funcionalidad principal se cumpla
de fraude en las llamadas
64
Especificación de Casos de Uso Describir para cada caso de uso identificado, la secuencia de acciones que se llevan a cabo para cumplir con el objetivo del mismo.
Formas de Realización: Trazo Grueso: describe en forma narrada y
general, las acciones principales que son realizadas en un caso de uso. Trazo Fino: describe en forma detallada la secuencia de acciones que se llevan a cabo, definiendo el curso normal que se llevaría a cabo en el caso de uso, y las respectivas alternativas al curso normal. En la descripción se deben detallar las acciones a realizar por el actor haciendo uso del sistema 65
Especificación de Casos de Uso
66
Consideraciones para la descripción de casos de uso.
El caso de uso debe en la mayoría de los casos describir la interacción entre el sistema y el actor, distinguiendo la acción que realiza cada uno en pasos diferentes. La descripción debe ser detallada y exhaustiva: deben especificarse el conjunto de acciones que se ejecutan por el curso normal y todas las alternativas que pudieran surgir. Cuando surge una alternativa indicar claramente posturas en cada camino. Por ejemplo: 3. El sistema verifica disponibilidad del producto, y existe disponibilidad. 3.A. No existe disponibilidad del producto. Cuando el caso de uso termina por el curso normal o por alguna alternativa, cumpliendo con el objetivo del mismo se indica : Fin del Caso de Uso. Cuando el caso de uso se interrumpe por una alternativa, no cumpliendo la condición, se debe indicar: Se cancela el Caso de Uso. Deben indicarse claramente las llamadas a otros casos de uso (de inclusión o de extensión) y al regresar del caso de uso se debe verificar si el caso de uso se ejecutó con éxito, y en caso contrario, el actual caso de uso se cancela. Al describir los casos de uso se debe diferenciar entre: - Ingreso de datos. - Selección de datos. 67
Consideraciones para la descripción de casos de uso.
Se debe precisar todo el detalle de los datos a ingresar, seleccionar, guardar o mostrar. No se debe hacer referencia en la descripción a aspectos relacionados con el diseño de la interfaz o de implementación. Rastreabilidad del CU: las últimas líneas deben indicar las llamadas a los casos de uso correspondientes, indicados en la descripción y que deben estar definidas en el diagrama de casos de uso del sistema. No se deben realizar saltos en la descripción de casos de uso a pasos anteriores o posteriores. Para los casos de uso referidos al alta, baja y modificación de datos se debe considerar: Para casos de uso que deben dar de alta baja o modificación de datos correspondientes a un solo atributo como por ejemplo: localidad, barrio. Considerar un solo caso de uso para la gestión de los datos en cada caso: Por ejemplo: Actualizar Localidad (alta, baja, modificación, consulta). Para los caso de uso en los que la actualización de los datos incluyen el ingreso y selección de muchos datos se debe realizar un caso de uso por cada acción a realizar: Por ejemplo: Registrar Cliente, Registrar Baja de Cliente, Modificar Cliente, Consultar Cliente. 68
Especificación de Casos de Uso Pre y Post Condiciones 9
Una pre-condición es una . el Caso de Uso.
9
Una pre-condición de un Caso de Uso, no es una pre-condición para un único subflujo, aunque se pueda definir pre y post condiciones a nivel de subflujo.
9
Una post-condición para un Caso de Uso debe ser verdadera, independientemente de cual flujo sea ejecutado.
69
Ejemplo: Proceso de detección de Fraude
70
Diagrama de Clases
71
Ejemplo: Caso de Uso “Detectar Fraude” Nombre del Caso de Uso:
Código del Caso de Uso:
Detectar Fraude
Objetivo del Caso de Uso : Identificar las llamadas que resultan sospechosas de fraude y gestionar la registración de casos de fraude, los cuales son luego resueltos por el departamento de fraude.
Proceso al que pertenece: Detección de Fraude.
Actor Principal: Timer
Actor Secundario: No Aplica
Precondiciones: No Aplica
Éxito: Se procesaron las llamadas insertadas por el proceso de formateo de llamadas.
Post- Condiciones:
Fracaso: El caso de uso se cancela cuando: no existen llamadas a validar de CDMA, no existen llamadas a validar de GSM.
72
Ejemplo: Caso de Uso “Detectar Fraude” Curso Normal
Alternativas
1. El Caso de Uso comienza cuando es el momento de investigar las llamadas insertadas por el proceso de formateo de llamadas 2. El sistema verifica si debe procesar las llamadas de tipo GSM o CDMA, y debe procesar las llamadas de GSM.
2.A. El sistema verifica que debe procesar las llamadas de CDMA. 2.A.1. El sistema consulta el rango de fechas a partir del cuál se van a validar las llamadas. 2.A.2. El sistema busca las llamadas correspondientes a CDMA utilizando el rango de fechas consultado, y existen llamadas. 2.A.2.A. El sistema busca las llamadas correspondientes a CDMA utilizando el rango de fechas consultado y no existen llamadas. 2.A.2.A.1. El sistema emite un mensaje informando lo ocurrido. 2.A.2.A.2. Se cancela el caso de uso. 2.A.3. El sistema para validar cada llamada de CDMA llama al Caso de Uso “Validar Llamadas”. 2.A.4. El sistema verifica para cada llamada si el caso de uso se ejecutó con éxito, y si se ejecutó con éxito. 2.A.4.A. El sistema verifica para cada llamada si el caso se ejecutó con éxito, y no se ejecutó con éxito. 2.A.4.A.1. El sistema registra lo ocurrido. 2.A.5. Fin del caso de uso.
3. El sistema busca las llamadas correspondientes a GSM, y existen.
3.A. El sistema busca las llamadas correspondientes a GSM, y no existen. 3.A.1. El sistema emite un mensaje informando lo ocurrido. 3.A.2. Se cancela el caso de uso.
4. El sistema para validar cada llamada de GSM llama al Caso de Uso “Validar Llamadas”. 5. El sistema verifica si para cada llamada el caso de uso se ejecutó con éxito, y si se ejecutó con éxito.
5.A. El sistema verifica si para cada llamada el caso de uso se ejecutó con éxito, y no se ejecutó con éxito. 5.A.1.El sistema registra lo ocurrido.
6. Fin del caso de uso.
73
Ejemplo: Caso de Uso “Validar Llamadas” Nombre del Caso de Uso:
Código del Caso de Uso:
Validar Llamadas
Objetivo del Caso de Uso: Validar las llamadas recibidas e identificar posibles causas de fraude.
Proceso al que pertenece: Detección de Fraude
Actor Principal:
Actor Secundario:
Timer
No Aplica
Precondiciones: No Aplica
Éxito: Se validaron las llamadas. Post- Condiciones:
Fracaso: El caso de uso se cancela cuando el caso de uso Registrar Fraude no se ejecutó correctamente.
Curso Normal
Alternativas
1.El Caso de Uso comienza cuando es llamado por otro Caso de Uso. 1.El sistema recibe una llamada a validar
1.El sistema analiza si el valor (tiempo) de la llamada supera un valor establecido, y no es mayor.
3.A. El sistema analiza si el valor de la llamada supera un valor establecido, y es mayor. 3.A.1. Se llama al Caso de Uso “Registrar Fraude”. 3.A.2. El sistema verifica que el caso de uso se ejecutó correctamente. 3.A.2.A. El sistema verifica que el caso de uso no se ejecutó correctamente. 3.A.2.A.1. El sistema registra el error ocurrido. 3.A.2.A.2. Se cancela el caso de uso.
74
4. El sistema analiza el número marcado en la llamada buscando sI éste se encuentra dentro del rango de números sospechosos, y no se encuentra.
4.A. El número marcado se encuentra dentro del rango de números sospechosos. 4.A.1. El sistema verifica si la fecha de la llamada se encuentra comprendida dentro de la vigencia del rango sospechoso, y no se encuentra. 4.A.1.A. La fecha de la llamada se encuentra dentro de la vigencia del rango sospechoso. 4.A.1.A.1. Se llama al Caso de Uso “Registrar Fraude”. 4.A.1.A.2. El sistema verifica que el caso de uso se ejecutó correctamente. 4.A.1.A.2.A. El sistema verifica que el caso de uso no se ejecutó correctamente. 4.A.1.A.2.A.1. El sistema registra el error ocurrido. 4.A.1.A.2.A.2. Se cancela el caso de uso.
5. El sistema busca el número marcado y obtiene el rango, el grupo y la compañía. 6. El sistema verifica si el número marcado corresponde a un país sospechoso, y no corresponde.
7.
Se llama al Caso de Uso “Buscar Ultima Llamada”.
8.
El sistema verifica que el caso de uso se ejecutó correctamente.
6.A. El sistema verifica si el número marcado corresponde a un país sospechoso, y corresponde. 6.A.1. Se llama al Caso de Uso “Registrar Fraude”. 6.A.2. El sistema verifica que el caso de uso se ejecutó correctamente. 6.A.1.A. El sistema verifica que el caso de uso no se ejecutó correctamente. 6.A.1.A.1. El sistema registra el error ocurrido. 6.A.1.A.2. Se cancela el caso de uso.
8.A. El sistema verifica que el caso de uso no se ejecutó correctamente. 8.A.1. El sistema registra el error ocurrido. 8.A.2. Se cancela el caso de uso.
75
9. El sistema verifica si el feature de la llamada indica que se encuentra excluida de análisis y si se encuentra excluida.
10.
9.A El sistema verifica si el feature de la llamada indica que se encuentra excluida de análisis, y no se encuentra excluida. 9.A.1 El sistema compara la duración de la llamada actual con la inmediata anterior y verifica que no exista colisión entre las llamadas. Y no existe colisión. 9.A.1.A El sistema compara la duración de la llamada actual con la inmediata anterior y verifica que no exista colisión entre las llamadas. Y si existe colisión. 9.A.1.A.1. Se llama al Caso de Uso “Registrar Fraude”. 9.A.1.A.2. El sistema verifica que el caso de uso se ejecutó correctamente. 9.A.1.A.2.A. El sistema verifica que el caso de uso no se ejecutó correctamente. 9.A.1.A.2.A.1. El sistema registra el error ocurrido. 9.A.1.A.2.A.2. Se cancela el caso de uso. 9.A.2 El sistema compara la llamada actual con la inmediata anterior y obtiene la ubicación de las celdas. 9.A.3. El sistema determina utilizando fórmulas, la distancia entre las dos celdas. 9.A.4. El sistema compara las fechas de las dos llamadas y obtiene un tiempo. 9.A.5. El sistema con la distancia y el tiempo obtiene una velocidad. 9.A.6. El sistema verifica si la velocidad obtenida supera la velocidad permitida, y no la superó. 9.A.6.A El sistema verifica si la velocidad obtenida supera la velocidad permitida, y no la superó. 9.A.6.A.1. Se llama al Caso de Uso “Registrar Fraude”. 9.A.6.A.2. El sistema verifica que el caso de uso se ejecutó correctamente. 9.A.6.A.2.A. El sistema verifica que el caso de uso no se ejecutó correctamente. 9.A.6.A.2.A.1. El sistema registra el error ocurrido. 9.A.6.A.2.A.2. Se cancela el caso de uso.
Fin del Caso de Uso.
76
Ejemplo: Caso de Uso “Gestionar Casos”
Nombre del Caso de Uso:
Código del Caso de Uso:
Gestionar casos
Objetivo del Caso de Uso: Evaluar los casos que se generan con el proceso de detección de fraude, y actualizarlos en caso de ser necesario.
Proceso al que pertenece: Detección de Fraude
Actor Principal:
Actor Secundario :
Analista de Fraude
No aplica
Precondiciones: No aplica
Éxito: Casos de fraude consultados y evaluados por el operador de fraudes.
Post- Condiciones:
Fracaso: El caso de uso se cancela cuando no existen casos registrados, cuando el Analista de Fraude no confirma los datos ingresados.
77
Ejemplo: Caso de Uso “Gestionar Casos” Curso Normal
Alternativas
1. El Caso de Uso comienza cuando el Analista de Fraude selecciona la opción “Gestionar Casos”
2. El sistema verifica que existan casos de fraude registrados, y existen
2.A. No existen casos de fraude registrados. 2.A.1. El sistema informa la situación. 2.A.2. Se cancela el caso de uso.
3. El sistema busca y muestra los CASOS a ser evaluados.
4. El sistema solicita se seleccione el/los criterio de consulta de los CASOS dentro de los siguientes: Todos Asociados a un celular Asociados a un caso en particular Fecha desde Fecha hasta
5. El Analista de Fraude selecciona el/los criterio de consulta con el que desea visualizar los CASOS.
6. El sistema muestra los CASOS que cumplen con el/los criterios indicados. 7. El sistema calcula y muestra la cantidad de casos consultados.
78
8. El Analista de Fraude no desea consultar el detalle de los eventos y llamadas de un caso.
8.A. El Analista de Fraude desea consultar el detalle de los eventos y/o llamadas de un caso. 8.A.1. El Analista de Fraude selecciona un caso. 8.A.2. El Analista de Fraude selecciona la opción para consultar los eventos relacionados al caso. 8.A.3. El sistema muestra los eventos relacionados al caso seleccionado, con los siguientes datos: Fecha de detección, Llamada asociada, Fecha de cierre, Datos auxiliares que componen el caso seleccionado. 8.A.4. El Analista de Fraude no selecciona la opción para modificar/ingresar un evento nuevo al caso. 8.A.4.A. El Analista de Fraude selecciona la opción para modificar/ingresar un evento nuevo al caso. 8.A.4.A.1. El sistema permite modificar/ingresar para el caso: Tipo de evento, Estado, Observaciones. 8.A.4.A.2. El Analista de Fraude ingresa/modifica los datos de un evento. 8.A.5. El Analista de Fraude no desea consultar las llamadas relacionadas al evento. 8.A.5.A. El Analista de Fraude desea consultar las llamadas relacionadas al evento. 8.A.5.A.1. El Analista de Fraude selecciona un evento y selecciona la opción para consultar las llamadas relacionadas al evento. 8.A.5.A.2. El sistema muestra las llamadas relacionadas al evento seleccionado con los siguientes datos: Celular, Nro. Transferido, ID Celda, Descripción celda, Nro. Marcado, Origen llamada, Features, Estado, ESN. Fecha, Dirección, Duración, Duración ext. 8.A.5.A.3. El Analista de Fraude no desea consultar los “Features” asociados a la llamada. 8.A.5.A.3.A. El Analista de Fraude desea consultar los “Features” asociados a la llamada. 8.A.5.A.3.A.1. El Analista de Fraude selecciona la llamada. 8.A.5.A.3.A.2. El sistema muestra los features asociados a la llamada. 8.A.6. El Analista de Fraude no desea cerrar un evento. 8.A.6.A. El Analista de Fraude desea cerrar un evento. 8.A.6.A.1. El Analista de Fraude selecciona un evento y selecciona la opción para cerrar el evento. 8.A.6.A.2. El sistema cambia el estado del evento a “Cerrado”.
79
9. El sistema verifica si se han realizado modificaciones a los caso y/o eventos asociados a los mismo, y no se han realizado modificaciones.
9.A. El sistema verifica si se han realizado modificaciones a los casos y/o eventos asociados a los mismo, y se han realizado modificaciones. 9.A.1. El sistema solicita se confirmen los datos ingresados. 9.A.2. El Analista de Fraude confirma los datos ingresados. 9.A.2.A. El Analista de Fraude no confirma los datos ingresados. 9.A.2.A.1. Se cancela el caso de uso. 9.A.3. El sistema verifica para cada caso si se han cerrado todos sus eventos, y no se han cerrado. 9.A.3.A. El sistema verifica para cada caso si se han cerrado todos sus eventos, y si se han cerrado. 9.A.3.A.1. El sistema cambia el estado del caso a “Cerrado”, y toma la fecha del sistema y responsable que cierra el caso. 9.A.4. El sistema guarda las actualizaciones realizadas sobre los casos.
10. Fin del Caso de Uso.
80
Prototipos de Interfaz de Usuario Otra de las herramientas que se utilizan para completar definición de la funcionalidad del sistema, que acompaña la descripción de los casos de uso y es de gran importancia, ya que se puede mostrar a través de ella al usuario la cara visible del sistema, es el prototipo de interfaz. En la actividad de especificación de requerimientos la función principal de los prototipos de interfaz es derivar y validar los requerimientos esenciales de información de los usuarios, manteniendo abiertas, al mismo tiempo, las opciones de implementación. 81
Patrones de Casos de Uso Como se describen los patrones: - Nombre - Gráfico - Contexto - Definición del Problema - Historia Metafórica - Fuerzas que afectan el problema - La solución - Ejemplos 82
Patrones de Casos de Uso Organización del lenguaje de los patrones: -
Consiste en 31 patrones Conforman dos Categorías: -
-
-
Patrones de Desarrollo: describen características de
práctica de escritura de casos de uso probadas, y ofrecen criterios para medir la calidad del proceso de escritura de casos de uso. Patrones Estructurales: describen los componentes básicos de los casos de uso, explicando cómo deberían ser organizados y ofrecen criterios para juzgar un caso de uso.
Las categorías se dividen en subcategorias 83
Patrones de Casos de Uso
84
Patrones de Casos de Uso Ejemplos de Patrones Estructurales -
De conjunto de Casos de Uso: - SharedClearVisión(Compartir una visión clara) : Definir claramente el propósito del sistema y enunciarlo.
-
De Caso de Uso: - VerbPhraseName(Nombrar con una frase verbal): Verbo en infinitivo + objeto
-
De Escenarios y Pasos: - TechnologyNuetral(Tecnología Neutral): escribir
cada paso sin hacer referencia a tecnología alguna
-
Relaciones de Casos de Uso: - CapturedAbstraction (Abstracción Capturada) : considerar la construcción de casos de uso abstractos. 85
Patrones de Casos de Uso
86
Patrones de Casos de Uso Ejemplos de Patrones de Desarrollo: - De Proceso: - SpiralDevelopment(Desarrollo en espiral):
desarrollar los casos de uso de manera iterativa, y progresivamente incrementar la precisión y certeza del conjunto de casos de uso.
-
De Edición: -
-
RedistrubuteTheWealth(Redistribuir la salud):
mover los pasajes complicados y/ovoluminosos a otros casos de uso. MergeDoplets(Mezclar Gotitas): unir casos de uso diminutos o fragmentos de casos de uso con objetivos relacionados. 87
Diagrama de Actividad 9 9
de Comportamiento, Dinámico, Lógico. Mostrar 9 Una Operación Compleja. 9 Una regla de negocio compleja. 9 Un caso de uso. 9 Algunos casos de uso. 9 Un proceso de negocio. 9 Procesos de Software.
9
9 9 9 9
Nodos Flujos Objetos
88
Diagrama de Actividad Se utilizan normalmente para modelar los aspectos dinámicos del sistema. Puede utilizarse para mostrar el flujo de actividades dentro de un caso de uso. Notación Estado inicial Estado Final Actividad Acción Decisión División Concurrente
89
Diagrama de Actividad Ejemplo Caso de Uso Validar Llamadas
90
Diagrama de Comunicación 9
de Comportamiento, Dinámico, Lógico.
9
Proveer una vista de la colaboración de objetos en un ambiente de tiempo real. 9 Distribuir funcionalidad en las clases, explorando los aspectos comportamentales de un sistema. 9 Modelar la implementación lógica de una operación compleja, particularmente la que interactúa con muchos objetos. 9
9
. 9 9 9 9
Objetos Links Mensajes 91
Ejemplo de Diagrama de Comunicación Ejemplo Caso de Uso: Gestionar Casos 1: OpciónGestionarCas osFraude( ) 6: tomarCriterioConsulta( )
3: buscarCasos( ) 8: buscarCasosPorCriterio( ) 14: calcularTotalCasos ( ) 4: exis teCaso( ) 5: mostrarCaso( ) 9: existeCas oCriterio( ) : CasoFraude
2: verificarExis tenciaCasos ( ) 7: criterioCons ulta( ) 10: mostr arDatos( )
: Analista de Fraude
15: mostrarTotalCasos( ) : InterfazGestionCasos : ManejadorDeCasosDeFraude : CasoFraude
11: mostrarDatos( )
12: mostrarDatos( ) 13: mostrarNombre( ) : Llamada : Cliente : Celular
92
Diagrama de Secuencia 9
de Comportamiento, Dinámico, Lógico.
9
Validar y describir la lógica de un escenario. 9 Explorar el diseño controlando la invocación de las operaciones definidas en las clases. 9 Detectar cuellos de botella en un diseño orientado a objetos. 9 Analizar qué clases son complejas en el sistema. 9
9
9 9 9 9
Objetos Links Mensajes 93
Ejemplo de Diag. de Secuencia : A n al i s t a d e
F r a u d e : I n t e r f a z G e s ti o n C a s o s : M a n e ja d o r D e C a s o s D e . . . O p c i ón G e s ti on a r C a s o s F r a u d e ( )
: C a s o F r a u d e
: C a s o F r a u d e
: L la m a d a
: C e lu la r
: C l i e n te
v e r i fi c a r E x i s t e n c i a C a s o s ( )
b u s c a rC a s o s ( )
e x is t e C a s o ( )
m o s t r a r C a s o (
)
t o m a r C r it e r io C o n s u l t a ( )
c r i t e r i o C o n s u l ta (
)
b u s c a r C a s o s P o r C r ite r io ( )
e x i s te C a s o C r i t e ri o ( )
m o s t ra r D a t o s ( )
m o s t r a r D a t o s ( )
m o s t r a r D a t o s ( )
m o s tr a r N o m b r e ( )
c a l c u l a r T o t a lC a s o s (
)
m o s t r a r T o ta l C a s o s ( )
94
Diagrama de Máquina de Estados de Comportamiento, Dinámico, Lógico.
9 9
Explorar el comportamiento complejo de un objeto, clase, actor, subsistema o componente. 9 Modelar sistemas de tiempo real. 9
9 9 9 9 9
Estados Transiciones Eventos
95
Diagrama de Transición de Estados: Clase Celular
96
Patrones de Diseño
“.. cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se puede aplicar esta solución un millón de veces, sin hacer lo mismo dos veces ..” (Cristopher Alexander)
Los patrones de diseño son descripciones de clases y objetos relacionados que están particularizados para resolver un problema de diseño general en un determinado contexto. (Gamma, Helm, Johnson,VlissidesÆ GoF) 97
Patrones de Diseño Elementos esenciales de un patrón de diseño: 9 Nombre: Describe en una o dos palabras un problema de diseño. 9 Problema: Describe cuándo aplicar el patrón, explica el problema y su contexto. 9 Solución: Describe los elementos que constituyen el diseño, sus relaciones, responsabilidades y colaboraciones (descripción abstracta). Son los resultados, ventajas e 9 Consecuencias: inconvenientes de aplicar el patrón. 98
Patrones de Diseño Un patrón de diseño: Nomina, abstrae e identifica los aspectos clave de una estructura de diseño común, lo que los hace útiles para crear un diseño OO reutilizable. Identifica las clases e instancias participantes, sus roles y colaboraciones y la distribución de responsabilidades. Se centra en un problema concreto, describiendo cuándo aplicarlo, consecuencias, ventajas e inconvenientes de su uso. 99
Patrones de Diseño Plantilla de definición: •
•
•
•
•
•
•
Nombre Propósito Sinónimos Motivación Aplicabilidad Estructura Participantes 100
Patrones de Diseño - Plantilla de definición (continuación)
Colaboraciones Consecuencias Implementación Ejemplo de Código Usos conocidos Patrones relacionados 101
Patrones de Diseño Clasificación Criterios:
Propósito: Refleja qué hace un patrón. - Creación: Tienen que ver con el proceso de creación de objetos.
- Estructural: Tratan con la composición de clases u objetos.
- Comportamiento: Caracterizan el modo en que las clases y los objetos interactúan y se reparten la responsabilidad.
Ámbito: - Clase: Se ocupan de las relaciones entre clases y sus subclases. - Objeto: Tratan con las relaciones entre objetos. 102
Patron Patr ones es de Di Dise seño ño Clasificación Propósito De Creación Estructurales De Comportamiento
Ámbito Clase
Fact Factor ory y Me Meth thod od
Adapte Adapterr (de clas clases) es)
Interpreter Templa Template te Met Method hod
Chai ain n of Re Resp spon onsa sabi bilility ty Abstract ct Factor Factory y Adapte Objeto Abstra Adapter(d r(de e objeto objetos) s)Ch Builder Prototype Singleton
Bridge Composite Decorator Facade Flyweight Proxy
103
Command Iterator Mediator Memento Observer State Strategy Visitor
Patrones de Diseño ¿Cómo usar un patrón? 1. 2. 3. 4. 5. 6. 7.
Leer el patrón, todos sus apartados, para tener una visión global. Estudiar la Estructura , Participantes y Colaboraciones Mirar el ejemplo de código Asociar a cada participante del patrón un elemento de su aplicación. Definir las clases. Definir nombres específicos de la aplicación para las operaciones del patrón. Implementar las operaciones para llevar a cabo las responsabilidades y colaboraciones del patrón. 104
Patrones de Creación
Abstraen el proceso de creación de objetos. Ayudan a crear sistemas independientes de cómo se crean, se componen y se representan sus objetos. Patrón de Creación asociado a Clases: usa herencia para variar la clase que es instanciada. Patrón de Creación asociado a Objetos: instanc nciac iación ión a otro otro obje objeto to delega la insta Clasificación
105
Patrones de Creación
Se encapsula: qué clases concretas usa el sistema cómo se crean las instancias de esas clases
El sistema conoce sus interfaces tal como las definen las clases abstractas Flexibilidad en qué se crea, quién lo crea, cómo se crea y cuándo se crea.
Clasificación
106
Patrones de Creación Abstract Factory (Factoría Abstracta)
Propósito
Proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin especificar la clase concreta
Motivación (escenario conocido)
Un toolkit interfaz de usuario que soporta diferentes formatos: Windows, Motif, X-Windows,..
107
Patrones de Creación Abstract Factory (Factoría Abstracta)
Aplicabilidad Un sistema debería ser independiente de cómo sus productos son creados, compuestos y representados Un sistema debería ser configurado para una familia de productos. Una familia de objetos “productos” relacionados es diseñada para ser utilizado juntos y se necesita forzar la restricción. Se quiere proporcionar una librería de clases de productos y se quiere revelar sólo la interfaz, no la implementación.
108
Patrones de Creación Abstract Factory (Factoría Abstracta)
Estructura
<> FactoriaAbstracta
Cliente
crearProductoA() crearProductoB()
FactoriaConcreta1 crearProductoA() crearProductoB()
ProductoAbstractoA
FactoriaConcreta2 ProductoConcretoA2
ProductoConcretoA1
crearProductoA() crearProductoB() ProductoAbstractoB
ProductoConcretoB2
109
ProductoConcretoB1
