iconix
TRANSCRIPT
DESARROLLO DE SOLUCIONES EN SOFTWARE LIBRE - ASESORIAMETODOLOGA 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 ICONIXModelado 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
EnfoqueDiagrama de robustez ESTTICA
Cdigo Modelo de dominio Diagrama de clases
Preguntas inicialesQuines 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 requerimientosIdentificar 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 preliminarDe 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 objetosEstado: 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 UMLNombre 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 procedimientoTEXTO ----------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 procedimientoEliminar 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 dominioProcedimiento (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 UMLA
La clase A es una generalizacin de las clases B y C
B
C
Las clases B y C son particularizaciones de la clase A
Las clases B y C heredan de la clase Acuenta
aPlazo
Cheques
Ejemplo
Modelando el dominioProcedimiento (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 UMLAasociacin Multiplicidad
B Se lee as: A se relaciona conun B
AA
1 1..* 0..1 * m..n n
BB
A
n
asociacin m
uno o ms B B cero o un B cero o ms B
AA A
BB 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 dominioProcedimiento (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 UMLD 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 dominioProcedimiento (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 UMLAlfa Beta
ClaAsoc
persona
patrn 0..1 empleo
compaa
Clase de asociacin; puede tener sus propios atributos
Modelado del dominio procedimientoSEGUNDA LISTA (reducida)Disear clases bsicas, incluyendo los atributos identificadosAnalizar 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
AdvertenciaNo 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 usoActor: 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 usoExisten 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 escribirlosEscriba 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 escribirlosRecomendacin 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 objetosPERMITIDO 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 BsicoActor: 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 Secuencia1.
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 SecuenciaL IActor: Alguien GUI: Botn :Alumno :Libros
N E
Caso de uso
Mtodo1( )Mtodo( )
A
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 ColaboracinEspecifican 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 Colaboracin1. 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 EstadosDiagramas 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
EstadoEntrar Hacer Salir
Transiciones. Estado final.
Diagramas de Estados Representacin - sugerenciasNo cambios / cerrar Terminan do
EditandoSalvando 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 opcionalEjemplo: 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 ActividadesActividad 1
Actividad 2 Actividad 4cond
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 RequerimientosLos 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 RequerimientosAl 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 RequerimientosAntes 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 realizarRevisa 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 ProyectosSer 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.
Mtricas1. 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 usoPersona, mquina o programa externo al sistema que se va a realizar, que inician una accin o responden a una solicitud del sistemaACTOR
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 clasesNombre Atributos CLASE A D E Mtodos Abstraccin de un conjunto de objetos con comportamiento comn.
B
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 estereotiposObjeto fronterizo Relaciones permitidas
Objeto de control
Relaciones prohibidas Entidad
Diagramas de SecuenciaL IActor Froterizo :Entidad
N E
Mtodo( )Mtodo( )
A
D E
Respuesta
V I D A
Diagramas de Estados
Estado inicial.Estados del objeto.
Estado
EstadoEntrar Hacer Salir
Transiciones. Estado final.