DESARROLLO DE SOLUCIONES EN SOFTWARE LIBRE - ASESORIA

METODOLOGA ICONIX

Ing. Agustn Ulln

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

Ms informacin en la pgina:
http://www.iconix.com

Mtodo ICONIX Por qu esta versin?

El texto original incluye muchas disgresiones, generalmente obsoletas El texto supone ciertos conocimientos, que no siempre tienen los alumnos El tratamiento de algunos temas es insuficiente para los usos modernos Por ello se realiz esta versin, que sirva para un primer curso de desarrollo orientado a objetos y usando UML.

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

Preguntas iniciales
Quines son los usuarios (actores) del sistema y qu tratan de hacer? Cules son los objetos del mundo real (dominio del problema) y las asociaciones entre ellos? Qu objetos son necesarios para cada caso de uso? Cmo colaboran los objetos en cada caso de uso? Cmo se manejan aspectos de tiempo real? Cmo se construir realmente el sistema a nivel de piezas?

Caractersticas

Flexible para diferentes estilos y clases de problemas Apoyo a la manera de trabajo de la gente Gua para los menos experimentados Expone los productos anteriores al cdigo de manera estndar y comprensible

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

Captulo 2 Modelando el dominio

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

Modelando el dominio

Fuentes de informacin:
Descripcin de alto nivel del problema Requerimientos de bajo nivel Conocimiento de expertos Literatura

Clases y objetos

Objeto:
Algo tangible o visible Algo que puede aprehenderse intelectualmente Algo hacia lo cual se dirigen pensamientos o acciones

Un objeto tiene:
Estado Comportamiento Identidad

Clases y objetos
Estado: propiedades y sus valores particulares Comportamiento: cmo acta y responde (a cambios de estado y paso de mensajes)

Clases y objetos

Clase:
Descripcin de un conjunto de objetos que comparten una estructura, un comportamiento, relaciones y semntica comunes

Interfaz:
Vista exterior de una clase; permite contrato acerca de las responsabilidades que ofrece y exige; asla el interior. Es el QU hace

Implementacin:
Vista interior, particular; CMO lo hace

Clase y objeto en notacin UML

Nombre Atributos Para objetos, el nombre:

Nomobj:nomclase
:nomclase

CLASE

Mtodos

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

Procedimiento:
Tomar documentos disponibles y hacer una lectura rpida, subrayando los sustantivos y notando frases posesivas y verbos (uso posterior) Los sustantivos y frases nominales se convertirn en objetos y atributos Los verbos y frases verbales se convertirn en operaciones y relaciones Las frases posesivas indican los sustantivos que son atributos y no objetos

Modelando el dominio

Procedimiento (II)
Formar una lista con los sustantivos y frases nominales identificados, evitando los plurales y las repeticiones y ordenndola alfabticamente Revisar la lista eliminando los elementos innecesarios (irrelevantes o redundantes) o incorrectos (vagos o conceptos fuera del alcance del modelo o representan acciones an cuando parezcan sustantivos) Volver a revisar textos, leyendo entre lneas

Modelado del dominio procedimiento

TEXTO ----------Subrayar sustantivos y frases nominales LISTA INICIAL

-----------

Subrayar verbos y frases verbales

Para usar en diseo (operaciones) y para identificar relaciones entre clases

Modelado del dominio procedimiento

Eliminar sinnimos y repetidos, dejar en singular, ordenar; LISTA INICIAL Quitar verbos disfrazados, vaguedades y elementos externos al dominio

Identificar Actores

Separar posibles atributos (identificados por frases posesivas) y valores de atributos discretos textuales

SEGUNDA LISTA (reducida)

Modelando el dominio
Procedimiento (III) 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
Procedimiento (III) 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
A

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

B
B

asociacin m

uno o ms B B cero o un B cero o ms B

A
A A

B
B B B

multiplicidad en la relacin entre m y n B A asociacin B exactamente n B

A (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
Procedimiento (III) 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
Procedimiento (IV) Clases de asociacin

Una clase de asociacin es una variante de las asociaciones muy til cuando hay relaciones muchas-amuchas 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 procedimiento

SEGUNDA LISTA (reducida)
Disear clases bsicas, incluyendo los atributos identificados
Analizar si existen relaciones de generalizacin o agregarlas si es necesario

Identificar relaciones de agregacin

Identificar otras relaciones importantes

Incluir multiplicidad en las relaciones

DIAGRAMA DE CLASES

Advertencia
No se tarde demasiado en preparar la lista; ms adelante la refinar y completar

Captulo 3 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

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

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

Algunos autores separan los actores en dos:

Primarios: los que inician casos de uso Secundarios: responden a una necesidad del sistema que el software no puede resolver, no inician la accin.

Casos de uso
Existen dos tipos de caso de uso: De nivel de anlisis: representa comportamiento comn de un grupo de caos

De nivel de diseo: instancias del anterior, con comportamiento especfico

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

Casos de uso cmo escribirlos

Recomendacin importante: Deben guardar estrecha correlacin con manual de usuario y la Interfaz grfica de usuario (GUI) Primero se escribe el manual y luego se trabaja en el cdigo (como sea: dibujos, texto, prototipo rpido, objetos de utilera, etc)

Casos de uso cmo escribirlos

En la descripcin no detalle demasiado elementos que pueden cambiar ms tarde. Por ejemplo, no especifique tipo de botn si puede cambiar por un men desplegable o una lista para seleccionar. Otras fuentes para casos de uso:
Si existe un sistema anterior, use los manuales de usuario para extraer casos de uso

Asegrese que los casos de uso corresponden a lo que efectivamente hacen los usuarios

Captulo 4 Anlisis de Robustez

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

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

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.

CAPITULO 5 Modelado de la Interaccin

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).

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 Cmo crear un diagrama de Secuencia

1.

2.
3. 4.

5.

Copiar texto del caso de uso (parte izquierda). Agregar objetos entidad del diagrama de robustez (parte superior derecha). Agregar objetos fronterizos y actores (parte superior izquierda). Asignar mtodos y mensajes: los objetos de control pasan a ser mtodos de entidades o de objetos fronterizos (Responsabilidad). Si un objeto de control se necesita, se agrega (Cuando slo es intermediario sin actividad propia, se funde con fronterizo o entidad

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

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

CAPITULO 6 Modelado de la Colaboracin y Estados

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.

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.

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.

Diagramas de Estados Representacin - sugerencias

No cambios / cerrar Terminan do

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).

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

Capitulo 7 Requerimientos

 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

 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.

Trazabilidad de Requerimientos
Al iniciar un proyecto se pueden asignar algunos requerimientos a casos de uso; pero como avanza el proyecto estos se verifican/validan trazabilidad.
Asignacin/Trazabilidad son trminos importantes a travs de todo el ciclo de vida, debido a que nos ayudan a determinar si el anlisis, diseo cumplen con los requerimientos deseados.

Trazabilidad de Requerimientos
Antes de iniciar la codificacin hay que analizar estos aspectos: Captura de Datos: encontrar caminos efectivos para capturar los elementos de cada fase del ciclo de vida.(puedes actualizar o cambiar algunos elementos de fases del ciclo). Anlisis de datos y reduccin: asegurar que todos los puntos hechos/asignados son vlidos, que todos los requerimientos fueron asignados y realizados (trace). Reporte de datos: documentacin del proyecto (reporte de los resultados de la captura de datos y el anlisis y reduccin).

Puntos a realizar
Revisa los requerimientos asignados a cada uno de los casos de uso (todos los requerimientos deben estar asignados entre todos los casos de uso). Verificar que cada requerimiento es realizado en por lo menos una clase del modelo de dominio. Verificar que los requerimientos se satisfacen en por lo menos un casos de uso (busca entre la descripcin de los casos de uso y los diagramas de secuencia). Si realizaste diagramas de colaboracin o estado, verifica que el comportamiento de los diagramas (estados) cumplan con lo especificado por los requerimientos.

Capitulo 8 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.

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.

ANEXO Resumen de smbolos empleados

Casos de uso
Persona, mquina o programa externo al sistema que se va a realizar, que inician una accin o responden a una solicitud del sistema
ACTOR

Representa una accin o funcin que el actor desea realizar. Se describe con un verbo o con un verbo y un complemento.

CASO DE USO

Diagramas de clases
Nombre Atributos CLASE A D E Mtodos Abstraccin de un conjunto de objetos con comportamiento comn.

C 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

Relacin de Generalizacin: A generalizacin de las clases B y C.

es

una

Inversamente: B y C heredan de la clase A

Diagramas de clases estereotipos

Objeto fronterizo Relaciones permitidas

Objeto de control

Relaciones prohibidas Entidad

Diagramas de Secuencia
L I
Actor Froterizo :Entidad

N E

Mtodo( )
Mtodo( )

D E

Respuesta

V I D A

Diagramas de Estados

Estado inicial.
Estados del objeto.

Estado

Estado
Entrar Hacer Salir

Transiciones. Estado final.