Anlisis y Diseo OO con UML y Herramientas Rational

Noviembre 2007

Agenda
Introduccin conceptos y elementos del paradigma orientado a objetos. UML Modelo Conceptual. Proceso Unificado de Desarrollo Modelado de Requerimientos con UML Diagramas de clases Diagramas de caso de uso Especificacin de Casos de Uso Prototipado Patrones de Casos de Uso Modelado de Anlisis con UML Diagramas de Interaccin Diagrama de Clases de Anlisis Modelado de Diseo con UML Diagramas de Interaccin Clases de Diseo Patrones de Diseo Herramientas de modelado Rational
2

Orientacin a Objetos...
La Orientacin a Objetos como medio para la generacin de Programas, tiene varias ventajas: Fomenta una metodologa basada en componentes para el desarrollo del SW, de manera que: Se genera un sistema mediante un conjunto de objetos... Luego, se puede ampliar el sistema: Agregndole funcionalidad a los componentes que ya haba generado. Agregndole componentes nuevos. Finalmente, podr volver a utilizar los objetos que gener para el sistema cuando cree uno nuevo... Con lo cual reducir sustancialmente el TIEMPO de desarrollo de un sistema.
3

OBJETOS, Objetos por doquier!!!

En el mundo estamos rodeados de OBJETOS. El Software actual simula al mundo (o una parte de l). Los Programas, por lo general, imitan a los OBJETOS del mundo.

Cajero (Persona) Software Tarjeta

4

Cajero Automtico Beneficiado Cuenta

Qu es un Objeto?
Cualquier entidad real o conceptual con un rol bien definido en el dominio del Problema. Un Objeto es una Instancia de una Clase... Clase
ELECTRODOMESTICOS

Objeto LAVARROPAS

Objeto Objeto LICUADORA Heladera

Objeto MICROONDAS

Lavarropas Marca Model o Numero de Serie Capacidad AgregarRopa() AgregarJabon EnPolvo() SacarR opa()

Atributos - Caractersticas Acciones - Mtodos

Lavarropas Marca Modelo NumeroSerie Capacidad VolumenTambor CronometroInterno Motor VelocidadMotor AgregarRopa() AgregarJabonEnPolvo() SacarRopa() AgregarBlanqueador() CronometrarRemojo() CronometrarLavado() CronometrarEnjuague() CronometrarCentrifugado()

Ms atributos y acciones Asemejan al Objeto mucho Mas a la realidad...

Abstraccin

La abstraccin centra su atencin en las caractersticas esenciales de un objeto en relacin a la perspectiva del observador. (Manejo de la Complejidad)
7

Encapsulamiento

El Encapsulamiento oculta detalles de implementacin de un objeto (Separamos el Qu del Cmo Ej. Interfaz de la Implementacin)

Modularidad
Pedidos
DetallePedido

Artculos

Articulo

Rubro

Origen

Artculos

PedidoHis t

Pedido

Pedidos

Clientes

Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes.

9

Contabilidad

Ventas

Jerarqua de Partes: Agregacin

Es el orden de las abstracciones organizado por niveles.

10

Jerarqua de Clases: Herencia

La herencia es una herramienta que permite definir nuevas clases en base a otras clases existentes.

11

Tipificacin
Es la definicin 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?
Un modelo es una simplificacin de la realidad
Es una representacin a bajo costo de la realidad.

Construimos modelos para poder comprender mejor el sistema que estamos desarrollando...
13

Objetivos del modelado

Los modelos ayudan a visualizar cmo 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 gua en la construccin del software. Los modelos documentan las decisiones que se han adoptado.

Los modelos nos sirven para simplificar la complejidad

14

El Modelado visual
Haba una vez un Proyecto...

lo que solicit el cliente

lo que se presupuest

lo que entendi el analista

lo que se dise

lo que construy el desarrollador

cmo qued finalmente 15

LO QUE REALMENTE SE NECESITABA

UML
Unified Modeling Language Lenguaje de Modelado Unificado

16

Por qu UML?
UML es un lenguaje estndar 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 Mtodo Proceso

Lenguaje Proceso Mtodo Notacin + Reglas Pasos a seguir Qu + Cmo + Porqu
17

Qu NO es UML?
Un lenguaje de programacin visual. La especificacin de una herramienta o un repositorio. UNA METODOLOGA, MTODO O PROCESO.

18

Por qu UML es un Lenguaje?

Provee un vocabulario y reglas para combinar los elementos del vocabulario con el propsito de comunicar. En un lenguaje de modelado esos vocabularios y reglas se focalizan en representaciones conceptuales y fsicas de un sistema.

19

UML se utiliza para

Visualizar: UML es un lenguajes grfico y es algo ms que un conjunto de smbolos grficos. Detrs de cada smbolo en la notacin UML hay una semntica bien definida. Especificar: tiene que ver con la construccin de modelos precisos, no ambiguos y completos. UML cubre la especificacin de todas las decisiones de anlisis, diseo e implementacin que deben realizarse al desarrollar y desplegar un sistema con gran cantidad de software. Construir: UML no es un lenguaje de programacin visual, pero sus modelos pueden conectarse de forma directa a una gran variedad de lenguajes de programacin, esto permite realizar ingeniera directa, es decir, la generacin de cdigo a partir de los modelos. Documentar: UML permite generar una serie de artefactos adems del cdigo fuente.
20

Modelo Conceptual de UML

Bloques de Construccin de UML - Elementos - Relaciones - Diagramas Reglas de UML - Reglas Semnticas - Para la Construccin de Modelos Mecanismos Comunes de UML
21

Bloques de Construccin: Elementos

Estructurales De Comportamiento De Agrupacin De Notacin

22

Elementos: Estructurales
Clase Interfaz Colaboracin Caso de Uso
Registrar Pedido

Cli ente

ICuenta Corriente
Cadena de Responsabilida d

Clase Activa Componente Nodo

23

form.java

Se rvidor

Elementos: de Comportamiento
Interaccin Mquina de Estados

mostrarDescripcin()

Pendiente

Cancelado

Fabricado

Entregado

24

Elementos de Agrupacin y Notacin

Paquetes

Ventas

De Comportamiento

Notas

De Agrupacin De Anotacin

Cont rol ar es te c om ponente luego de la s igui ente revis in de dis eo

texto simple

V er http://www.rational.c om para inform ac in adic ional s obre UM L

URL embebida

link a un documento
25

Ve r alg o r1.d o c p ara o b te ne r d eta lle s s o b re e s te pro ce s o

Bloques de Construccin: Relaciones

Dependencia Asociacin Generalizacin Realizacin

26

Bloques de Construccin: Diagramas

Clases Objetos Casos de Uso Componentes Despliegue Interaccin Colaboracin Secuencia Estados Actividades
27

Cubren la vista esttica de un sistema

Cubren la vista dinmica de un sistema

Reglas de UML: Semnticas

Nombres: Cmo llamar a los elementos,
relaciones y diagramas. Alcance: El contexto que da un significado especfico a un nombre. Visibilidad: Cmo se pueden ver y utilizar esos nombres por otros. Integridad: Cmo se relacionan apropiada y consistentemente unos elementos con otros. Ejecucin: Qu significa ejecutar o simular un modelo dinmico.

28

Reglas de UML: Construccin 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 ms que un lenguaje grfico. Detrs de cada elemento de notacin grfica hay una especificacin que proporciona una explicacin textual de la sintaxis y semntica de ese bloque de construccin Adornos
Adornos Persona
Nombre Domicilio Telfono Situacin IVA CUIT

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 diseo Vista de Casos de Uso Vista de procesos

Vista de implementacin

Definen la Arquitectura del Sistema

Vista de despliegue

31

DIAGRAMAS
Use Case Use Case Diagrams Secuencia Diagrams Scenario Scenario Diagrams Comunicacin Diagrams Scenario Scenario Mquina de Diagrams Estados Diagrams
(DTE)
Comportamiento Estructural nico Esttico que modela Comportamiento Interaccin

Use Case Use Case Diagrams Uso Casos de Diagrams

State State Diagrams Clases Diagrams

State State Diagrams Objetos Diagrams

MODELOS

State State Diagrams Componentes Diagrams

Component Component Diagrams Diagrams Despliegue

Actividad

32

Diagramas UML 2.0

Actividad Casos de Uso Paquetes Clases

Mquina de Estados
( DTE )

Colaboraci n

Objetos Secuencia Model os

Comunicaci n (Colaboraci n) Descripcin De Interaccin

Component es

Timing

Despliegue

Estructura Compuesta

33

Proceso Unificado de Desarrollo

Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En la ingeniera 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. Caractersticas

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 versin del producto para los clientes. Cada ciclo consta de cuatro fases: inicio, elaboracin, construccin y transicin. Cada fase a su vez puede tener varias iteraciones:

Inicio

Elaboracin

Construccin

Iteracin Iteracin - - #1 # 2 ...

--- ---

Transicin Iteracin Iteracin --- --#n # n-1

Versiones

Cada ciclo produce una nueva versin del sistema que es un producto preparado para su entrega. Consta de cdigo 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 Anlisis

Realizado por

Distribudo por

Modelo de Diseo

Implementado por

Modelo de Despliegue
Verificado por

Modelo de Implementacin

X OK X OK

Modelo de Prueba

X OK

36

Fases de PUD
Fase de Inicio: Principalmente esta fase responde a las preguntas sobre cules son las principales funciones del sistema para sus usuarios ms importantes, cmo podra ser la arquitectura del sistema y cul es el plan del proyecto, adems de cunto costar desarrollar el sistema. Se realiza un modelo de casos de uso simplificado, con los ms crticos; la arquitectura es un esbozo que muestra los principales subsistemas, se identifican y priorizan los riesgos, se planifica en detalle la fase de elaboracin y se estima el proyecto. Fase de elaboracin: Se especifican en detalle la mayora de los casos de uso del producto y se disea 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 lnea base de la arquitectura. Fase de construccin: Aqu la lnea base de la arquitectura crece hasta convertirse en el sistema completo, obteniendo as un producto preparado para ser entregado a los usuarios. Fase de transicin: En esta fase el producto se convierte en versin una beta. Un nmero 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 adems las tareas de formacin del cliente, ayuda en lnea y asistencia.
37

Conceptos bsicos del PUD

Flujo de Trabajo (Workflow) Es un conjunto de actividades. Un flujo de trabajo determina cmo 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 cmo fluye el proceso a travs de los distintos trabajadores y cmo ellos crean, producen y utilizan los artefactos de los dems. Artefacto Es un trmino general para cualquier tipo de informacin 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 desempear 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 que acta como trabajador. 38

Flujos de trabajo fundamentales del PUD

Requisitos Anlisis Diseo Implementacin Prueba

39

Flujos de trabajo fundamentales del PUD

Fases Flujos de trabajo fundamentales Inicio Elaboracin Construccin Transicin Requisitos

Anlisis

Diseo

Implementacin

Prueba Iteracin Iteracin - - #1 # 2 ... --- --- --Iteraciones - - - Iteracin Iteracin #n # n-1

40

Modelado de Requerimientos con UML

Diagramas de clases Diagramas de caso de uso Especificacin de Casos de Uso Prototipado Patrones de Casos de Uso

41

Diagrama de Clases
CLASIFICACION: de Estructura, Esttico, Lgico. USO: Explorar conceptos del dominio. Analizar Requerimientos. Mostrar el diseo detallado del SW Orientado a Objetos. Muestra: un conjunto de clases, interfaces, colaboraciones y sus relaciones. Contiene comnmente: 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 comn y un comportamiento comn.

Artculo cdigoArtculo descripcin cantidadExistente cantidadMnima 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 anlisis, aquello que se necesita que el sistema administre y que pueden ser: cosas tangibles (producto, herramienta, automvil) lugares (Barrio, Provincia, Pas, Zona) transacciones o operaciones (Venta, Pago, Pedido) hechos o eventos (Reserva, Vuelo, Accidente, Incidente) roles de personas (Proveedor, Cliente, Empleado) contenedores de otras cosas (Almacn) catlogos (catalogo de productos) otras organizaciones u reas (Ministerio, Juzgado, dpto. de ventas)
44

Diagrama de Clases: Relaciones

Relacin de Asociacin
Asociacin multiplicidad

Gasto

Tipo de Gasto

navegabilidad

Asociacin

Describe un conjunto de conexiones entre Objetos.

45

Diagrama de Clases: Relaciones

Relacin de Agregacin
todo parte

Factura

1..*

DetalleFactura

Agregacin

Agregacin

El elemento destino es parte del elemento de origen, tipo especial de asociacin representa una relacin conceptual entre un todo y sus partes
46

Diagrama de Clases: Relaciones

Relacin de Generalizacin
V entana abrir() c errar() m over() m ax im iz ar()

Profesor

Alumno

Herencia Simple

V entana de Cons ola

Caja de Dilogo

Ayudante

Herencia Mltiple

Generalizacin El elemento origen es una especializacin del elemnto destino, ms generico y puede ser sustitudo por l.
47

Diagrama de Clases: Relaciones

Relacin de Dependencia
Ve n ta n a Eve n to a b rir() ce rra r() m ove r() m axim iza r()

Dependencia El elemento origen depende del elemento destino y puede verse afectado por los cambios en l.

48

Ejemplo de Diagrama de Clases

S o ci o n ro S o ci o a u to ri za d o co n ce p to Alquiler n u m e ro A l q u i l e r fe ch a A l q u i l e r fe ch a De vo l u ci o n P re vi sta fe ch aD e vo l u ci o n Re a l fe ch a P a g o m o n to P a g o co n oc e rSo c i o () co n oc e rE j e m p l a r() co n o ce rE sta d o () 1 Ejem plar fe ch a In g re so fe ch a B a j a m o ti vo B a j a e sta d o co n o ce rE sta d o () a ctu a l i za rE sta d o () co n o ce rFe ch a In g re so () 1 ..* P e rso n a dni a p el l i d o n o mb re d o mi c i l i o te l efo n o n e w() d e l ete () g e tDn i () m o stra rDn i () 1

P e l i cu l a n o m b re P e l i cu l a n u m e ro P e l i cu l a a o E stre n o d i re cto r d u ra ci o n co n o ce rE j e m p l a re s() b u sca rE j e m p l a re s() m o stra rNo m b re P e l i cu l a () g e tNo m b re P e l i cu l a ()

Em pleadoVideo tu rn o fe ch a In g re so h o ra In i ci o T u rn o h o ra Fi n T u rn o co n oc e rT u rn o () co n o ce rHo ra In g re so () co n o ce rHo ra S a l i d a ()

Ca te g o ri a 1

1 Ca l i fi ca ci o n 1 Ru b ro

49

Pautas para la construccin de Diagramas de Clases

Encontrar las clases esenciales en el dominio del problema Pensar en aquello de lo que se necesita guardar informacin Realizar un listado de clases candidatas Determinar si las clases candidatas representar a un conjunto de objetos del mismo tipo. Definir la informacin que guardara cada clase Establecer cules seran 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 despus de haber establecido las relaciones
50

Diagrama de Objetos
CLASIFICACION: de Estructura, Esttico, Lgico. USO: Representar el estado de un sistema en un momento de tiempo. Muestra: un conjunto de objetos y sus relaciones. Contiene comnmente: Objetos Conexiones (Links)

51

Ejemplo de Diagrama de Objetos

S 1 : S o c io E 1 : E je m p la r

: A lq u il er

P 1 : P e lic u la

52

Diagrama de Casos de Uso

CLASIFICACION: de Comportamiento, Esttico, Lgico. USO: Comunicar el Alcance. Proveer descripcin de todo o una parte de los requerimientos de un sistema u organizacin. Muestra: un conjunto de casos de uso, actores y sus relaciones. Contiene comnmente: Casos de Uso Actores Relaciones de extensin, inclusin, generalizacin. Paquetes
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 anlisis, el diseo y las pruebas. Dos objetivos claves: Modelar el Contexto del Sistema Modelar los Requerimientos/Requisitos del Sistema
54

Notacin del Diagrama de Casos de Uso

Actor Caso de Uso Relaciones
Asociacin Generalizacin Inclusin Extensin

55

Actor
Un actor es el rol que juega un usuario en relacin 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 ms 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 informacin. Actor Secundario: Es de quin 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 especificacin. Especifica el comportamiento de cosasdinmicas, en este caso instancias de casos de uso. Una instancia de un caso de uso es la realizacin (o ejecucin) de un caso de uso del sistema de informacin. Los Casos de Uso pueden ser
Esenciales: describen la funcional principal o esencial con la que tiene que cumplir el sistema. Comprenden los principales procesos que debe ejecutar el sistema de informacin. De Soporte: comprenden la funcionalidad que surge a partir de 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 implementacin los lmites del sistema y las relaciones entre el sistema y el entorno el conjunto de requerimientos, atendiendo a la categora 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 debera poder entenderlos para realizar su validacin)
58

Qu asumimos para la definicin de Casos de Uso?

Propsito: Determinacin de REQUERIMIENTOS (Funcionales) Contenido: Descripcin por medio de PROSA CONSISTENTE Pluralidad: MULTIPLES ESCENARIOS Estructura: SEMIFORMAL
Escenario 1 Escenario 2 Escenario 3

Caso de Uso

59

Relacin de Generalizacin entre actores

Pueden definirse categoras generales de actores y especializarlos a travs de relaciones de generalizacin. 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 podra haber casos de uso que son instanciados por uno de los actores hijo en particular.

60

Relaciones Inclusin entre Casos de Uso

Una relacin de inclusin entre casos de uso significa que un caso de uso base incorpora explcitamente 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 inclusin 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 Extensin entre Casos de Uso

La extensin puede verse como que el caso de uso que extiende incorpora su comportamiento en el caso de uso base. Una relacin de extensin 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. Tambin puede utilizarse para modelar un subflujo separado que slo se ejecuta bajo ciertas circunstancias. Se dibuja con una flecha cuya direccin va desde el Caso de Uso de extensin (adicional) al Caso de Uso base.
62

Relacin de Generalizacin entre casos de uso.

La generalizacin entre casos de uso es como la generalizacin 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

Construccin del Diagrama de Casos de Uso Requerimiento: Identificar y gestionar casos

Identificar los Actores Definir la funcionalidad esencial relacionada a cada actor a travs de casos de uso. Identificar parte de funcionalidad comn y opcional en los casos de uso, y agregar relaciones de inclusin, extensin y generalizacin. Definir casos de uso de soporte, que ayuden a que la funcionalidad principal se cumpla
de fraude en las llamadas

64

Especificacin 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 Realizacin: 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 llevara a cabo en el caso de uso, y las respectivas alternativas al curso normal. En la descripcin se deben detallar las acciones a realizar por el actor haciendo uso del sistema
65

Especificacin de Casos de Uso

66

Consideraciones para la descripcin de casos de uso.

El caso de uso debe en la mayora de los casos describir la interaccin entre el sistema y el actor, distinguiendo la accin que realiza cada uno en pasos diferentes. La descripcin 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 condicin, se debe indicar: Se cancela el Caso de Uso. Deben indicarse claramente las llamadas a otros casos de uso (de inclusin o de extensin) 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. - Seleccin de datos.
67

Consideraciones para la descripcin 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 descripcin a aspectos relacionados con el diseo de la interfaz o de implementacin. Rastreabilidad del CU: las ltimas lneas deben indicar las llamadas a los casos de uso correspondientes, indicados en la descripcin y que deben estar definidas en el diagrama de casos de uso del sistema. No se deben realizar saltos en la descripcin de casos de uso a pasos anteriores o posteriores. Para los casos de uso referidos al alta, baja y modificacin de datos se debe considerar: Para casos de uso que deben dar de alta baja o modificacin de datos correspondientes a un solo atributo como por ejemplo: localidad, barrio. Considerar un solo caso de uso para la gestin de los datos en cada caso: Por ejemplo: Actualizar Localidad (alta, baja, modificacin, consulta). Para los caso de uso en los que la actualizacin de los datos incluyen el ingreso y seleccin de muchos datos se debe realizar un caso de uso por cada accin a realizar: Por ejemplo: Registrar Cliente, Registrar Baja de Cliente, Modificar Cliente, Consultar Cliente.
68

Especificacin de Casos de Uso

Pre y Post Condiciones
Una pre-condicin es una restriccin sobre cundo un Caso de Uso puede empezar. No es el evento que inicia el Caso de Uso. Una pre-condicin de un Caso de Uso, no es una pre-condicin para un nico subflujo, aunque se pueda definir pre y post condiciones a nivel de subflujo. Una post-condicin para un Caso de Uso debe ser verdadera, independientemente de cual flujo sea ejecutado.

69

Ejemplo: Proceso de deteccin de Fraude

70

Diagrama de Clases

71

Ejemplo: Caso de Uso Detectar Fraude

Nombre del Caso de Uso: Detectar Fraude Objetivo del Caso de Uso:

Cdigo del Caso de Uso:

Identificar las llamadas que resultan sospechosas de fraude y gestionar la registracin de casos de fraude, los cuales son luego resueltos por el departamento de fraude.

Proceso al que pertenece:

Deteccin de Fraude.

Actor Principal: Timer Precondiciones:

No Aplica

Actor Secundario:
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
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 cul 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.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.

Alternativas

3. El sistema busca las llamadas correspondientes a GSM, y existen. 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. 6. Fin del caso de uso.

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.

73

Ejemplo: Caso de Uso Validar Llamadas

Nombre del Caso de Uso:
Validar Llamadas

Cdigo del Caso de Uso:

Objetivo del Caso de Uso:

Validar las llamadas recibidas e identificar posibles causas de fraude.

Proceso al que pertenece:

Deteccin de Fraude

Actor Principal:
Timer

Actor Secundario:
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
1.El Caso de Uso comienza cuando es llamado por otro Caso de Uso. 1.El sistema recibe una llamada a validar

Alternativas

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 nmero marcado en la llamada buscando sI ste se encuentra dentro del rango de nmeros sospechosos, y no se encuentra.

4.A. El nmero marcado se encuentra dentro del rango de nmeros 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 nmero marcado y obtiene el rango, el grupo y la compaa. 6. El sistema verifica si el nmero marcado corresponde a un pas sospechoso, y no corresponde. 6.A. El sistema verifica si el nmero marcado corresponde a un pas 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.

7.

Se llama al Caso de Uso Buscar Ultima Llamada.

8.

El sistema verifica que el caso de uso se ejecut correctamente.

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 anlisis y si se encuentra excluida.

9.A El sistema verifica si el feature de la llamada indica que se encuentra excluida de anlisis, y no se encuentra excluida. 9.A.1 El sistema compara la duracin de la llamada actual con la inmediata anterior y verifica que no exista colisin entre las llamadas. Y no existe colisin. 9.A.1.A El sistema compara la duracin de la llamada actual con la inmediata anterior y verifica que no exista colisin entre las llamadas. Y si existe colisin. 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 ubicacin de las celdas. 9.A.3. El sistema determina utilizando frmulas, 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.

10.

Fin del Caso de Uso.

76

Ejemplo: Caso de Uso Gestionar Casos

Nombre del Caso de Uso:

Gestionar casos

Cdigo del Caso de Uso:

Objetivo del Caso de Uso:

Evaluar los casos que se generan con el proceso de deteccin de fraude, y actualizarlos en caso de ser necesario.

Proceso al que pertenece:

Deteccin de Fraude

Actor Principal:
Analista de Fraude

Actor Secundario:
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
1. El Caso de Uso comienza cuando el Analista de Fraude selecciona la opcin Gestionar Casos

Alternativas

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 situacin. 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 opcin 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 deteccin, Llamada asociada, Fecha de cierre, Datos auxiliares que componen el caso seleccionado. 8.A.4. El Analista de Fraude no selecciona la opcin para modificar/ingresar un evento nuevo al caso. 8.A.4.A. El Analista de Fraude selecciona la opcin 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 opcin 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, Descripcin celda, Nro. Marcado, Origen llamada, Features, Estado, ESN. Fecha, Direccin, Duracin, Duracin 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 opcin 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 definicin de la funcionalidad del sistema, que acompaa la descripcin de los casos de uso y es de gran importancia, ya que se puede mostrar a travs de ella al usuario la cara visible del sistema, es el prototipo de interfaz.
En la actividad de especificacin de requerimientos la funcin principal de los prototipos de interfaz es derivar y validar los requerimientos esenciales de informacin de los usuarios, manteniendo abiertas, al mismo tiempo, las opciones de implementacin.
81

Patrones de Casos de Uso

Como se describen los patrones: - Nombre - Grfico - Contexto - Definicin del Problema - Historia Metafrica - Fuerzas que afectan el problema - La solucin - Ejemplos
82

Patrones de Casos de Uso

Organizacin del lenguaje de los patrones:
-

Consiste en 31 patrones Conforman dos Categoras:

-

Patrones de Desarrollo: describen caractersticas de prctica 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 bsicos de los casos de uso, explicando cmo deberan ser organizados y ofrecen criterios para juzgar un caso de uso.
83

Las categoras se dividen en subcategorias

Patrones de Casos de Uso

84

Patrones de Casos de Uso

Ejemplos de Patrones Estructurales - De conjunto de Casos de Uso:
-

SharedClearVisin(Compartir una visin clara) : Definir claramente el propsito del sistema y enunciarlo. VerbPhraseName(Nombrar con una frase verbal): Verbo en infinitivo + objeto TechnologyNuetral(Tecnologa Neutral): escribir cada paso sin hacer referencia a tecnologa alguna CapturedAbstraction (Abstraccin Capturada) : considerar la construccin de casos de uso abstractos. 85

De Caso de Uso:
-

De Escenarios y Pasos:
-

Relaciones de Casos de Uso:

-

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 precisin y certeza del conjunto de casos de uso. 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

De Edicin:
-

Diagrama de Actividad
CLASIFICACION: de Comportamiento, Dinmico, Lgico. USO: Mostrar Una Operacin Compleja. Una regla de negocio compleja. Un caso de uso. Algunos casos de uso. Un proceso de negocio. Procesos de Software. Muestra el conjunto de actividades, y el flujo de secuencia o desglose de actividad en actividad, y los objetos que actan y que son afectados. Contiene comnmente: Nodos Flujos Objetos
88

Diagrama de Actividad
Se utilizan normalmente para modelar los aspectos dinmicos del sistema. Puede utilizarse para mostrar el flujo de actividades dentro de un caso de uso. Notacin Estado inicial Estado Final Actividad Accin Decisin Divisin Concurrente
89

Diagrama de Actividad Ejemplo Caso de Uso Validar Llamadas

90

Diagrama de Comunicacin
CLASIFICACION: de Comportamiento, Dinmico, Lgico. USO: Proveer una vista de la colaboracin de objetos en un ambiente de tiempo real. Distribuir funcionalidad en las clases, explorando los aspectos comportamentales de un sistema. Modelar la implementacin lgica de una operacin compleja, particularmente la que interacta con muchos objetos. Diagrama que enfatiza la organizacin estructural de los objetos y conexiones entre esos objetos y los mensajes enviados y recibidos por esos objetos. Contiene comnmente: Objetos Links Mensajes
91

Ejemplo de Diagrama de Comunicacin

Ejemplo Caso de Uso: Gestionar Casos
1: OpcinGestionarCasosFraude( ) 6: tomarCri teri oConsul ta( ) 3: buscarCasos( ) 8: buscarCasosPorCriterio( ) 14: calcularTotalCasos( ) 4: existeCaso( ) 5: mostrarCaso( ) 9: existeCasoCriterio( ) 2: verificarExistenciaCasos( ) 7: criterioConsulta( ) 10: mostrarDatos( ) 15: mostrarTotalCasos( ) : InterfazGestionCasos : ManejadorDeCasosDeFraude : CasoFraude : CasoFraude

: Analista de Fraude

11: mostrarDatos( )

12: mostrarDatos( ) 13: mostrarNombre( ) : Llamada : Cliente : Celular

92

Diagrama de Secuencia
CLASIFICACION: de Comportamiento, Dinmico, Lgico. USO: Validar y describir la lgica de un escenario. Explorar el diseo controlando la invocacin de las operaciones definidas en las clases. Detectar cuellos de botella en un diseo orientado a objetos. Analizar qu clases son complejas en el sistema. Diagrama de secuencia que enfatiza el orden de los mensajes en funcin del tiempo. Muestra un conjunto de objetos y los mensajes enviados y recibidos por esos objetos. Contiene comnmente: Objetos Links Mensajes
93

Ejemplo de Diag. de Secuencia

: A n al i s ta d e F r au d e : In te r fa z G e s ti o n C a s o s : M an e j a d or D e C a s os D e .. . O p c i n G e s ti o n 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 lie n te ve r ific a r E xis te n c ia C a s o s ( ) b u s c a r C a s o s ( )

e xis te C a s o ( )

m o s tr a r C a s o ( )

t o m a r C r it e r io C o n s u lt a ( )

c r ite r io C o n s u lta ( )

b u s c a r C a s o s P o r C r i te r i o ( )

e x is te C a s o C

ri t e ri o( )

m o s tra r D a to s ( )

m o s tr a r D a to s ( )

m o s tr a r D a to s ( )

m o s tr a r N o m b r e ( )

c a lc u la r T o ta lC a s o s ( )

m o s tr a r T o ta lC a s o s ( )

94

Diagrama de Mquina de Estados

CLASIFICACION: de Comportamiento, Dinmico, Lgico. USO: Explorar el comportamiento complejo de un objeto, clase, actor, subsistema o componente. Modelar sistemas de tiempo real. Muestra una mquina de estados compuesta por estados, transiciones, eventos y actividades. Contiene comnmente: Estados Transiciones Eventos
95

Diagrama de Transicin de Estados: Clase Celular

96

Patrones de Diseo
.. cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, as como la solucin a ese problema, de tal modo que se puede aplicar esta solucin un milln de veces, sin hacer lo mismo dos veces .. (Cristopher Alexander) Los patrones de diseo son descripciones de clases y objetos relacionados que estn particularizados para resolver un problema de diseo general en un determinado contexto. (Gamma, Helm, Johnson,Vlissides GoF)
97

Patrones de Diseo
Elementos esenciales de un patrn de diseo: Nombre: Describe en una o dos palabras un problema de diseo. Problema: Describe cundo aplicar el patrn, explica el problema y su contexto. Solucin: Describe los elementos que constituyen el diseo, sus relaciones, responsabilidades y colaboraciones (descripcin abstracta). Consecuencias: Son los resultados, ventajas e inconvenientes de aplicar el patrn.
98

Patrones de Diseo
Un patrn de diseo: Nomina, abstrae e identifica los aspectos clave de una estructura de diseo comn, lo que los hace tiles para crear un diseo OO reutilizable. Identifica las clases e instancias participantes, sus roles y colaboraciones y la distribucin de responsabilidades. Se centra en un problema concreto, describiendo cundo aplicarlo, consecuencias, ventajas e inconvenientes de su uso. 99

Patrones de Diseo
Plantilla de definicin: Nombre Propsito Sinnimos Motivacin Aplicabilidad Estructura Participantes
100

Patrones de Diseo
- Plantilla de definicin (continuacin) Colaboraciones Consecuencias Implementacin Ejemplo de Cdigo Usos conocidos Patrones relacionados

101

Patrones de Diseo Clasificacin Criterios:

Propsito: Refleja qu hace un patrn.
- Creacin: Tienen que ver con el proceso de creacin de
objetos.

- Estructural: Tratan con la composicin de clases u

objetos.

- Comportamiento: Caracterizan el modo en que las

clases y los objetos interactan 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

Patrones de Diseo Clasificacin

Propsito
De Creacin Estructurales De Comportamiento
mbito Clase Factory Method Adapter (de clases)
Interpreter Template Method

Objeto Abstract Factory Adapter(de objetos)Chain of Responsability

Builder Prototype Singleton Bridge Composite Decorator Facade Flyweight Proxy Command Iterator Mediator Memento Observer State Strategy Visitor

103

Patrones de Diseo Cmo usar un patrn?

1. 2. 3. 4. 5. 6. 7.

Leer el patrn, todos sus apartados, para tener una visin global. Estudiar la Estructura, Participantes y Colaboraciones Mirar el ejemplo de cdigo Asociar a cada participante del patrn un elemento de su aplicacin. Definir las clases. Definir nombres especficos de la aplicacin para las operaciones del patrn. Implementar las operaciones para llevar a cabo las responsabilidades y colaboraciones del patrn.
104

Patrones de Creacin
Abstraen el proceso de creacin de objetos. Ayudan a crear sistemas independientes de cmo se crean, se componen y se representan sus objetos. Patrn de Creacin asociado a Clases: usa herencia para variar la clase que es instanciada. Patrn de Creacin asociado a Objetos: delega la instanciacin a otro objeto
Clasificacin 105

Patrones de Creacin
Se encapsula:
qu clases concretas usa el sistema cmo se crean las instancias de esas clases

El sistema conoce sus interfaces tal como las definen las clases abstractas Flexibilidad en qu se crea, quin lo crea, cmo se crea y cundo se crea.

Clasificacin 106

Patrones de Creacin Abstract Factory (Factora Abstracta)

Propsito
Proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin especificar la clase concreta

Motivacin (escenario conocido)

Un toolkit interfaz de usuario que soporta diferentes formatos: Windows, Motif, X-Windows,..

107

Patrones de Creacin Abstract Factory (Factora Abstracta)

Aplicabilidad
Un sistema debera ser independiente de cmo sus productos son creados, compuestos y representados Un sistema debera ser configurado para una familia de productos. Una familia de objetos productos relacionados es diseada para ser utilizado juntos y se necesita forzar la restriccin. Se quiere proporcionar una librera de clases de productos y se quiere revelar slo la interfaz, no la implementacin.
108

Patrones de Creacin Abstract Factory (Factora Abstracta)

Estructura
<<Interface>> FactoriaAbstracta crearProductoA() crearProductoB() Cliente ProductoAbstractoA

FactoriaConcreta1 crearProductoA() crearProductoB()

FactoriaConcreta2 ProductoConcretoA2 crearProductoA() crearProductoB() ProductoAbstractoB ProductoConcretoA1

ProductoConcretoB2

ProductoConcretoB1

109

Patrones de Creacin Abstract Factory (Factora Abstracta)

Ejemplo:
..public Automotor crearAutomotor() {return new AutoNacional();} <<Interface>> FactoriaVehiculo crearAutomotor() : Automotor crearMoto() : Moto Automotor ..public Automotor crearAutomotor() {return new AutoImportado();}

FactVehicNacional crearAutomotor() : Automotor crearMoto() : Moto

FactVehicImportado AutoImportado crearAutomotor() : Automotor crearMoto() : Moto AutoNacional

Moto

MotoImportada

MotoNacional

110