ICONIX

Ms. Ing Carlos Castillo Diestra, Dr(c)

Mtodo ICONIX Referencia

El mtodo original se encuentra en:
Rosenberg, Doug, with Kendall Scott Use case driven object modeling with UML. A practical approach Addison Wesley, 1999

Enfoque ICONIX
Modelado de objetos conducido por casos de uso Centrado en datos: se descompone en fronteras de datos Basado en escenarios que descomponen los casos de uso Enfoque iterativo e incremental Ofrece trazabilidad Uso directo de UML (estndar del Object Management Group)

DINMICA

Prototipo de interfaz de usuario

Modelo de casos de uso Diagrama de secuencia

Enfoque
Diagrama de robustez ESTTICA

Cdigo Modelo de dominio Diagrama de clases

Pasos principales I Anlisis de requerimientos

Identificar objetos del dominio y relaciones de agregacin y generalizacin Prototipo rpido Identificar casos de uso Organizar casos de uso en grupos (paquetes) Asignar requerimientos funcionales a casos de uso y objetos del dominio META: revisin de requerimientos

Pasos principales II Anlisis y diseo preliminar

Escribir descripciones de casos de uso
cursos bsico y alternos

Anlisis de robustez
Identificar grupos de objetos que realizan escenario Actualizar diagramas de clases del dominio

Finalizar diagramas de clases META: revisin del diseo preliminar

De usuarios hacia sistema De datos hacia sistema Detallar a partir de modelos de alto nivel

Pasos principales III Diseo

Asignar comportamiento Para cada caso de uso
Identificar mensajes y mtodos Dibujar diagramas de secuencia Actualizar clases (opcional) diagramas de colaboracin (opcional) Diagramas de estados

Terminar modelo esttico Verificar cumplimiento de requerimientos META: revisin crtica del diseo

Pasos principales IV Implementacin

Producir diagramas necesarios
Despliegue Componentes

Escribir el cdigo Pruebas de unidad e integracin Pruebas de sistema y aceptacin basadas en casos de uso META: entrega del sistema

Modelado del Dominio

Dominio del problema: rea que cubre las cosas y conceptos relacionados con el problema que el sistema deber resolver Modelando el dominio: tarea de descubrir objetos (en realidad clases) que representan esas cosas y conceptos A partir de los datos asociados con requerimientos se llegar a construir modelo esttico del dominio

Clase y objeto en notacin UML

Nombre Atributos CLASE Mtodos Para objetos, el nombre: Nomobj:nomclase :nomclase

cuenta saldo clave dimesaldo() deposita(cant) retira(cant) Ejemplo de clase

Micuenta:cuenta saldo clave dimesaldo() deposita(cant) retira(cant) Ejemplo de objeto

Modelando el dominio
Construir relaciones de generalizacin
Una generalizacin es una relacin en la cual una clase es una generalizacin de otra. Tambin se le llama tipo-de o es-una. La clase ms general se llama Antecesor o Superclase y la otra (refinamiento de la primera) Descendiente o Subclase. La subclase hereda los atributos y mtodos de la superclase y las asociaciones en que participa. Las puede modificar.

Relacin de agregacin en UML

A

La clase A es una generalizacin de las clases B y C

Las clases B y C son particularizaciones de la clase A

Las clases B y C heredan de la clase A

cuenta

aPlazo

Cheques

Ejemplo

Modelando el dominio
Establecer asociaciones entre clases
Una asociacin es una relacin esttica entre dos clases; indican dependencia, pero no accin (aunque se las nombre con un verbo) Deben ser persistentes (es modelo esttico)

Asociaciones con UML

A asociacin Multiplicidad B Se lee as: A se relaciona con un B A n asociacin m uno o ms B B cero o un B multiplicidad en la relacin A asociacin B cero o ms B entre m y n B exactamente n B A A A A A A 1 B B B B B B

1..* 0..1 * m..n n

(siempre del lado de B) Navegabilidad: la flecha indica que podemos hallar a B a partir de A. Sin flecha puede indicar doble sentido o indefinido Lo mismo en sentido de B a A

Modelando el dominio
Establecer relaciones de agregacin
Una agregacin es una relacin en la cual una clase est formada por otras (sus partes) A veces se le llama parte-de En UML se distingue una forma ms fuerte llamada Composicin, pero para este mtodo no se har diferencia

Agregacin con UML

D E Relacin de Agregacin o Contencin: la clase D contiene a la clase E, es decir, la clase E se agreg a la clase D. Tambin llamada parte-de: E es parte de D

Gra

Brazo

Gancho

Ejemplo

Modelando el dominio
Clases de asociacin
Una clase de asociacin es una variante de las asociaciones muy til cuando hay relaciones muchas-a-muchas entre clases

Pueden conseguirse clase del dominio a partir de entidades en bases de datos preexistentes Cuando una clase tiene demasiados atributos, conviene dividirla en clases auxiliares y usar agregacin para reunirlas

Clase de asociacin con UML

Alfa Beta

ClaAsoc

persona

patrn 0..1 empleo

compaa

Clase de asociacin; puede tener sus propios atributos

Modelado del Dominio

CASO: COMERCIAL PERU S.A. Nuestra compaa vende productos a travs del Per. As que dividimos al Per en cuatro regiones de ventas: La Regin Norte, la Regin Oriente, la Regin Centro y la Regin Sur. Cada Regin tiene un cdigo nico. Cada regin de ventas se divide en departamentos de ventas. Por ejemplo, la regin del Norte es dividida en los departamentos de Piura, Chiclayo, Cajamarca y La Libertad. Cada departamento tiene un cdigo nico. Cada departamento se conforma de distritos de Ventas. El departamento de La Libertad lo constituyen tres distritos: Trujillo, Pacasmayo y Otuzco. Cada distrito tiene un cdigo nico. A su vez, cada distrito de ventas se descompone en rea de ventas. Por ejemplo Trujillo est conformado por dos reas de ventas: rea Norte y rea Sur. Cada rea de venta tiene un cdigo nico de ventas. Cada vendedor es responsable de una o ms reas de ventas y tiene una cuota de venta especfica. Tambin tenemos gerentes de ventas que son responsables de uno o ms departamentos de ventas, y los directores de ventas quienes son responsables de una o ms regiones de ventas. Cada gerente de ventas es responsable de los distritos dentro de sus departamentos. Nosotros no traslapamos las responsabilidades de nuestros empleados. Un rea de ventas es siempre la responsabilidad de un slo vendedor y las responsabilidades de nuestros gerentes y directores tampoco se sobreponen. Algunas veces nuestros gerentes, vendedores y directores estn de viaje o tienen asignaciones especiales; por lo tanto, no tienen responsabilidades de ventas. Identificamos a todo nuestro personal de ventas por su identificador de empleado. Nuestros vendedores visitan a nuestros clientes una vez pos semana y toman nota de sus pedidos. Cada pedido es registrado y despus de 24 horas es atendido. Cada cliente es identificado por un identificador nico. Nuestros productos tambin tienen un identificador nico. Si un rea de ventas no cuenta con un producto es solicitado a un distrito, este a su vez solicita a un departamento, y este a la regin.

Requerimientos
Qu es un requerimiento? Criterio especifico de un usuario que un sistema tiene que satisfacer. Los requerimientos definen el comportamiento y funcionalidad requerida por el usuario para un sistema. Expresados por frases que incluyen: 1. shall tiene que, debe que 2. must debe de, haber de

10

Requerimientos
Tipos de requerimientos: 1. Funcionales: el sistema tiene que generar automaticamente . 2. De Datos: 3. De ejecucin (desempeo): El sistema debe de validar los datos que entran. 4. De capacidad: El sistema tiene que mostrar informacin de 10,000 transacciones. 5. De prueba: El sistema tiene que permitir hacer transacciones de 50 usuarios al mismo tiempo.

Casos de Uso <-> Requerimientos

Los casos de uso son Algunos o Todos los Requerimientos. Se sugiere hacer un caso de uso por cada requerimiento funcional, debido a que: Un caso de uso describe una unidad de comportamiento. Los requerimientos describen las reglas que rigen el comportamiento del sistema. Las funciones son acciones individuales que ocurren dentro del comportamiento.

Un caso de uso puede satisfacer mas de un requerimiento (funcional/no funcional), o bien la combinacin de varios casos de uso pueden satisfacer un solo requerimiento.

11

Modelado de casos de uso Casos de uso

Buscan capturar los requerimientos del usuario para sistema nuevo Puede ser desde cero o a partir de un sistema anterior Especifica escenarios detallados de lo que hace el usuario para lograr sus fines Es la base de todo lo que sigue en este mtodo y otros semejantes

Casos de uso
Definicin:
Un caso de uso es una secuencia de acciones que un actor (usualmente una persona, pero que puede ser una entidad externa, como otro sistema o un elemento de hardware) realiza dentro del sistema para lograr una meta

12

Casos de uso
Se describe mejor como una frase verbal en presente y en voz activa. Ejemplos:
Admite paciente, Realiza transaccin o Genera reporte

Especifica de manera precisa, no ambigua, un aspecto del uso del sistema sin suponer un diseo o implementacin particulares. Toda la funcionalidad del sistema debe estar expresada en casos de uso

Casos de uso
Actor: es un papel realizado por una persona, base de datos externa, otro sistema. Los actores reflejan todas las entidades que deben intercambiar informacin con el sistema. Varias personas pueden realizar un mismo papel Una persona puede jugar varios papeles, en momentos distintos Diagrama de casos de uso: rene actores y casos de uso

13

Casos de uso

Registra transaccin

Genera reporte empleado Actualiza informacin

Usualmente, actores a derecha e izquierda, casos de uso al centro No cambie smbolos, son parte de un estndar internacional

Casos de uso cmo escribirlos

Escriba un prrafo o ms para cada caso de uso, describiendo su comportamiento Si slo hay una frase, quiz dividi demasiado finamente los casos de uso y deberan reunirse varios Si es demasiado extenso o complicado, quiz debe subdividirlo Importa ms identificar la mayora que refinarlos desde el principio Ms adelante se descubrirn otros y se refinarn

14

Casos de Uso
TRANSUPAO S. A. en una empresa que se dedica al transporte de pasajeros y el servicio de encomiendas, giros y valores a nivel nacional. Para la venta de pasajes, un empleado verifica la disponibilidad para el destino, fecha, hora, lugar y el precio respectivo. El usuario tiene como opcin un mximo de 15Kg. de equipaje, cobrndose el 10% del pasaje por cada kilogramo adicional. Para las encomiendas otro empleado, en funcin de una tabla de precios por peso, efecta el clculo del importe a pagar, registra la descripcin y el peso de la encomienda, as como la direccin y el nombre de la persona destinataria y del remitente. Para el caso de giros se verifica el monto y se registra los datos de la persona destinataria y del remitente; y para el caso de los valores se registra su descripcin, su valor aproximado y los datos de la persona destinataria y del remitente. Al aceptar el usuario el tipo de servicio brindado, el empleado procede a emitir un comprobante de pago (una boleta o una factura, si el usuario tiene RUC). En el comprobante se detalla la fecha, el cdigo del empleado, el total a pagar; tambin se registra el nombre del usuario, la hora y para el caso de los pasajes el nmero de asiento. Desarrolle el diagrama de casos de uso.

Anlisis de Robustez Identificacin de Objetos

Objetos que participan en cada caso de uso Clasificacin de objetos: Objetos Fronterizos (de limite): objetos con los cuales puede interactuar el usuario interfaz de usuario -. De Entidad: generalmente objetos del modelo de dominio De control (controles): intermediarios entre los fronterizos y de entidad.

Objeto fronterizo

Entidad

Control

15

Anlisis de Robustez Relaciones entre objetos

PERMITIDO NO PERMITIDO

Anlisis de Robustez Diagramas de Robustez

Representa el curso bsico y los alternos de cada caso de uso. Tener entre 2 y 5 objetos de control por caso de uso. Usar flechas en una o dos direcciones.

Curso Bsico
Actor: inicia la accin Interfaz de Usuario Funciones (acciones) Entidad (almacenes)

Curso Alterno

NO SON DIAGRAMAS DE FLUJO

16

Anlisis de Robustez Para qu sirven

Comprobacin de Sanidad: revisar las ideas de los casos de uso (comportamiento razonable). Comprobacin de entereza: asegurar que en los casos de uso se cubra el camino bsico y los posibles caminos alternos. Descubrir objetos (si son necesarios) Diseo preliminar: los diagramas son la primera vista del nuevo sistema.

Modelado de la Interaccin Objetivos

Construccin de hilos sobre el comportamiento de los objetos en los casos de uso. Tres objetivos: 1. Asignar el comportamiento de los objetos (fronterizos, entidades y de control). 2. Detallar la interaccin entre objetos (por medio de mensajes). 3. Ubicar los mtodos correspondientes a cada clase (responsabilidades).

17

Modelado de la Interaccin Diagramas de Secuencia

Consta de 4 elementos: 1. Texto del curso de accin (caso de uso). 2. Objetos - se representan con el nombre del objetos (opcional) y la clase. 3. Mensajes: flechas entre los objetos 4. Mtodos: operaciones (objetos de control) representados por rectngulos).

Modelado de la Interaccin Diagramas de Secuencia

L I
Actor: Alguien GUI: Botn :Alumno :Libros

N E

Caso de uso

Mtodo1( ) Mtodo( )

Narrativa del camino bsico y sus alternativos

D E

Respuesta

V I D A

18

Modelado de la Interaccin Asignacin de mtodos Tarjeta CRC

Una parte fundamental pero difcil del mtodo es la asignacin de responsabilidades para cada clase. Como ayuda existen las tarjetas Clase Responsabilidad Colaboracin (CRC). Estas tarjetas ayudan a decidir y aclarar cuales operaciones (mtodos) corresponden a cada clase.
Nombre de clase Responsabilidades Mtodos que estn a cargo de esta clase Colaboracin

Clases con las que va a colaborar (relacionadas)

Modelado de la Interaccin Responsabilidad (Puntos de criterio)

Al asignar los mtodos a cada una de las clases, toma en cuenta:
1. Reusabilidad: considera que las clases pueden ser utilizadas en otros proyectos. 2. Aplicabilidad: asignar los mtodos realmente necesarios para la clase y el proyecto. 3. Complejidad: mtodos fciles de construir y de entender. 4. Conocimiento de la implementacin

19

Modelado de la Colaboracin y Estados

Ayuda a agregar aspectos del comportamiento que tiene el nuevo sistema. Se disean comnmente para sistemas de tiempo real o sistemas distribuidos.

Diagramas de Colaboracin
Especifican mas los diagramas de robustez. Se apegan ms a la situacin real. nfasis en el orden de las operaciones entre los objetos del caso de uso. Agrega detalles extras al momento del paso de mensajes entre los objetos.

20

Diagramas de Colaboracin
1. Cuenta, cantidad :cajero :IUDeposito 2. Busca la cuenta Depositar 4. 3. Deposita en cuenta Cuenta

Se representan de igual forma que los diagramas de robustez, pero llevan un nmeros que determina o indica el orden de ejecucin sobre las flechas.

Diagramas de Estados
Diagramas de Estado = Mquinas de estado finito = Autmatas Solucionan la representacin del comportamiento dinmico de un objeto o grupo de objetos. Muestra el ciclo de vida de los objetos, mediante los diferentes estados que tiene o pasa un objeto.

21

Diagramas de Estados Elementos

Estado inicial. Estados del objeto = rectngulo redondeado, con el nombre del estado y las actividades (opcional). Tipos de actividades o eventos: a) Inicio Entrada (Enter): acciones cuando entra al estado. b) Hacer (Do): acciones mientras esta en el estado. c) Salida (Exit): acciones cuando sale del estado. Transiciones: cambio de estados. Estado final.

Diagramas de Estados Representacin

Estado inicial. Estados del objeto.

Estado

Estado
Entrar Hacer Salir

Transiciones. Estado final.

22

Diagramas de Estados Representacin - sugerencias

No cambios / cerrar
Terminando

Editando
Salvando Si cambios / cerrar

Nombre de estados = sustantivos o verbo en participio Las transiciones deben llevar: a) Qu la causa = {evento, mensaje, condicin, tiempo, terminacin natural} - OBLIGATORIO b) Accin opcional
Ejemplo: Si cambios / cerrar

Se permite anidar los diagramas de estado pero NO ES RECOMENDABLE

Diagramas de Actividades
Descienden de los diagramas de flujo, redes de Petri y de las mquinas de estado. Capturan las acciones y los resultados de estas acciones. Representan la secuencia de actividades que se realizan en un caso de uso (mas detallado, como un diagrama de flujo).

23

Ejemplo de Diagrama de Actividades

Actividad 1

Actividad 2 Actividad 4
cond

Actividad 3 Actividad 5 Actividad 6

Entregar

Actividad

Utiliza los mismos smbolos de los diagramas de estado. Permite representar las actividades que se pueden hacer en paralelo. Permite colocar los diferentes caminos (decisiones).

Diagramas de Actividades
Swimlanes (carriles) permiten agrupar las actividades dependiendo de quien las realizadas. Cada responsable (clase) de alguna actividad tiene un carril.
JEFE Saluda Carga datos Registra CAPTURISTA INVENTARIOS

Calcula total Autoriza Informa

24

Implementacin Administracin de Proyectos

Ser listo e ingenioso. No desconcentrarse y perder el enfoque en el proceso del proyecto. No utilizar herramientas visuales para generar pruebas tontas o simples del cdigo. Apreciar mas la calidad de cdigo que la cantidad.

Revisar el modelo de dominio

Finalizar los diagramas de secuencia y refinar el modelo de dominio (verificar que los mtodos sean concisos y atmicos). Realiza: Define una operaciones. lista de argumentos para tus

Define operaciones lgicas Asigna clases a componentes si es posible.

25

Pruebas
Para saber si tu sistema es aceptable, realiza pruebas: Caja Blanca Caja Negra casos de uso Prueba basado en estados (sistemas de tiempo real). Las pruebas deben involucrar grupos lgicos (paquetes) de casos de uso, pruebas de unidad, de integracin y de sistema.

Mtricas
1. Determinar el peso de tus clases, para saber la complejidad de tus clases. 2. Responsabilidad de una clase medir el nmero de metodos llamados en una clase. 3. Profundidad del rbol medicin de la forma de tu modelo de dominio (mientras mas profundo sea mas complejo es). 4. Numero de hijos tamao del modelo de dominio.

26