miércoles, 23 de diciembre de 2009

Especificación de Arquitectura de Software

Las siguientes lineas están dirigidas a las personas que se inician como Arquitectos de Software, trato de explicar que es lo que hace un Arquitecto y las actividades necesarias para especificar Arquitectura, el contenido es un punto de vista personal que no pretende ser una guía, para más detalles es mejor consultar el material de referencia que se anexa al final.

¿Por que la importancia de la Arquitectura?
La complejidad en el desarrollo de sistemas empresariales donde hay requerimientos de alta disponibilidad, de integración, componentes distribuidos y seguridad ha ocasionado que sea necesario contar con un desarrollador de software experimentado en la combinación de las tecnologías adecuadas para lograr que un sistema con estas características sea exitoso y cumpla así los objetivos del sistema.

¿Qué es Arquitectura?

Es la especificación de la estructura de un sistema para soportar correctamente su operación.

Metas de la arquitectura

  • Reducir los riesgos tecnológicos del proyecto asociados a sistemas de gran escala
  • Diseñar los componentes de software que soporten la operación del sistema y cumplan con los requerimientos no funcionales
  • Facilitar el diseño, implementación y despliegue de la aplicación.

¿Qué es un Arquitecto de Software?

Una persona como cualquiera de nosotros que cuenta con suficiente experiencia para poder proponer soluciones. Contrario a lo que podríamos pensar, un Arquitecto no es un gurú del desarrollo, no se centra en detalles de codificación y no tiene porque conocer los detalles codificación de todos los frameworks conocidos. El Arquitecto debe conocer cómo funcionan las diferentes opciones tecnológicas, sus ventajas y desventajas para poder proponer una o varias alternativas de solución que normalmente deben sujetarse a restricciones de presupuesto, tiempo y recursos. La elección debe ser cuidadosa ya que uno de sus objetivos es tratar de eliminar los riesgos del desarrollo sistema y garantizar la operación del sistema una vez liberado. Los proyectos siempre tienen variantes o requieren de ciertos frameworks que nunca habíamos utilizado, por ello también el Arquitecto debe saber investigar y entender rápidamente cómo funciona la tecnología.

Actividades del Arquitecto


El insumo de un Analista Funcional de Sistemas son los requerimientos de Negocio y Funcionales para encontrar ¿Qué funcionalidad debe proporcionar el sistema?. El insumo de un Arquitecto son los Requerimientos No Funcionales y las Restricciones Iniciales para determinar ¿Cómo debe ser construido el sistema para soportar tal funcionalidad?.
El Arquitecto al igual que el Analista de Sistemas debe realizar actividades de Análisis, Diseño y Construcción con la diferencia que su objetivo son los Requerimientos No Funcionales del Sistema, todo aquello que determina como debe funcionar el sistema.


¿Cómo proponer una solución?

El Arquitecto obtiene los requerimientos iniciales, las restricciones, los supuestos, identifica riesgos, analiza la información y formula una o varias propuestas de solución tomando en cuenta todo lo anterior. Dentro de la solución no elige un framework porque es el favorito del Arquitecto, no elige el lenguaje de desarrollo porque quiere aprenderlo o porque es el de moda, los elementos que conforman la solución deben elegidos de forma adecuada para que en conjunto cumplan con los requerimientos no funcionales y las restricciones de tiempo, costo y recursos.

¿Cuál es el resultado de las actividades de análisis de un Arquitecto?
El resultado es un entregable al que llamo en este artículo: Documento de Arquitectura, este documento puede tener diferentes nombres dependiendo de la metodología y de la empresa: Documento de Arquitectura (Vision Consulting), Service Level Agreement (SLA), TCH100 (GNP) etc.
Las siguientes son algunas de las actividades que debe realizar el Arquitecto para poder proponer una solución de Arquitectura.

Obtención y Análisis de Requerimientos


Requerimientos de Negocio
Al igual que el Analista Funcional, el arquitecto debe identificar y conocer cuáles son los objetivos de negocio que motivan el desarrollo del sistema. Esto permitirá proponer la solución más adecuada en función de estos objetivos y evitar cualquier desviación.

Requerimientos No Funcionales
Los Requerimientos No Funcionales (NFRs) son los niveles de servicio y restricciones que el sistema debe cumplir, cuando un cliente es experimentado puede definirlas por el mismo, en otras ocasiones es el arquitecto quien debe ayudar a identificarlas.
En el Documento de Arquitectura el listado de Requerimientos No funcionales puede ir en una tabla como la siguiente escritas con palabras propias del cliente.
Clave
Descripción
NFR01
Descripción del Requerimiento No Funcional
NFR 02


Estás características dictan Como?, Que tan bien? o Que tan rápido? se debe realizar la funcionalidad del sistema. Estas características técnicas están clasificadas y bien definidas, Sun Microsystems en su Metodología de Arquitectura, Sun Tone Methodology las llama Cualidades Sistémicas o Quality of Service (QoS)

Cualidades Sistémicas
Las cualidades sistémicas están definidas por Sun Microsystems de la siguiente manera:

Manifiestas u obvias para el usuario 
  • Desempeño (Performance)Que tan rápido el sistema debe cumplir la petición. 
  • Confiabilidad (Reliability) El sistema debe ser exacto. 
  • Disponibilidad (Availability) – Cantidad de tiempo en línea en el que el sistema puede procesar solicitudes. (De hecho el tema es más complejo) 
  • Usabilidad (Usability) – Que tan fácil es usar el sistema.  
 
Cualidades operacionales que están ligadas al sistema en ejecución 
  • Rendimiento de trabajo (Throughput) – Cantidad de trabajo hecho por el sistema medido en operaciones por unidad de tiempo.  
  • Posibilidad de ser Administrado (Manageability).  
  • Seguridad (Security) – Prevención de uso no autorizado del sistema y su información.  
  • Serviceabilidad (Serviceability) – Esfuerso necesario para actualizar o reparar el sistema.  
  • Facilidad de hacer pruebas (Testeability) – Esfuerzo requerido para identificar y aislar una falla en el sistema.
    Cualidades Evolucionarias relacionadas de cómo se comporta el sistema cuando es modificado o actualizado. 
    • Escalabilidad (Scalability) – Capacidad de crecer y mantener buenos niveles de operación ante un incremento en el número de usuarios o peticiones.  
    • Mantenibilidad (Maintainability) – Que tan susceptible es de ser corregido o reparado.  
    • Extensibilidad (Extensibility) – Posibilidad de agregar funcionalidad nueva.  
    • Flexibilidad (Flexibility) – Costo de implementar una corrección o una funcionalidad nueva.  
    • Reusabilidad (Reusability) – Esfuerzo ahorrado apoyándose en componentes existentes  
    • Portabilidad (Portability) – Esfuerzo ahorrado cuando se migra a una infraestructura diferente.


    Cualidades de Desarrollo que afectan como se está construyendo 
    • Realizabilidad (Realizabilidad) – Probabilidad o confianza en que el sistema puede desarrollarse, se ve reflejado en la facilidad de estimación, planeación y construcción.  
    • Planeabilidad (Serviceability) – Confianza en que el sistema puede ser planeado en costo y esfuerzo.
      Algunas cualidades sistémicas son excluyentes entre sí, por ejemplo Desempeño Vs Seguridad, el cumplimiento de una minimiza a otra por lo que es necesaria una priorización en las cualidades sistémicas para poder decidir de entre varias opciones de solución cual es la más adecuada y que no comprometa el cumplimiento de una o varias cualidades.
      Las cualidades sistémicas identificadas se listan y priorizan en un listado como el siguiente:
      QoS
      Prioridad
      Descripción del Requerimiento
      Propuesta para cubrir el requerimiento
      Disponibilidad
      Alta
      El sistema no debe quedar fuera de línea en las horas pico o dentro de la ventana de servicio.
      Opción 1: Se propone escalar el sistema con XX Memoria RAM y mover las aplicaciones existentes a otro servidor con menos recursos

      Opción 2: Se propone el uso de 2 servidores YYY y 1 balanceador de carga.
      Seguridad
      Alta


      Tiempos de Respuesta
      Alto
      Ver tabla anexa



      Tiempos de respuesta esperados (Ejemplo)

      Tipo operación
      Respuesta en Hora Promedio


      Respuesta en Hora Pico
      Volumen promedio de datos
      Accesos concurrentes, (prom. futuro.)
      Latencia detectada hacia Server
      Latencia detectada hacia BD
      Escritura
      ¿?
      ¿?
      50k
      825
      Por probar
      Por probar
      Lectura
      ¿?
      ¿?
      50k
      300
      Por probar
      Por probar
      Reportes
      ¿?
      ¿?
      50k
      300
      Por probar
      Por probar
      General
      1seg
      5seg
      50k
      300
      Por probar
      Por probar


      Características operacionales

      Característica
      Operaciones del Sistema Detectadas
      Descripción
      Transaccional
      *Asignación del folio

      *Calculo de número de referencia
      Se desarrollarán los componentes de negocio con EJBs

      Los demás componentes de negocio se desarrollarán con POJOs para poder llegar a los tiempos de respuesta solicitados.
      Concurrencia
      * Registro de un solicitante

      * Consulta de reportes

      * Configuración de procesos de registro






      Restricciones

      Todo proyecto tiene restricciones, las más comunes son tiempo, recursos, presupuesto y tecnología a utilizar. El arquitecto debe proponer alternativas de solución que se muevan dentro de estas restricciones. En algunos casos será necesario sacrificar una buena opción porque no cumple alguna de estas.
      Es muy importante documentar las restricciones iniciales del proyecto y a lo largo del desarrollo documentar los cambios sobre estas restricciones. Al final del proyecto es común que alguien sin contexto cuestione: ¿Por qué se hizo de esta manera? La respuesta puede estar en las restricciones iniciales y los cambios a lo largo del proyecto.


      Suposiciones

      Al inicio del proyecto no siempre tenemos toda la información necesaria para poder plantar una propuesta, incluso el cliente puede no tenerla. Esta incertidumbre puede hacer que dudemos en proponer una solución porque no sabemos qué implicaciones puede tener ese faltante de información, pero por otro lado no podemos quedarnos inmóviles a esperar a que se defina ese faltante, esto puede resultar en la pérdida de un posible cliente. Ante estos casos se deben hacer supuestos y actuar en base a estos. Cuando por ejemplo se hace una propuesta estos supuestos se deben notificar a todos los involucrados y denotar que cierta solución es válida bajo ciertas consideraciones.
      Ejemplo. El cliente no tiene idea de cuantos reportes se tienen que generar en el sistema.
      Supuesto: Se realiza una propuesta suponiendo que solamente se requerirán 100 horas de construcción de reportes.


      Riesgos

      El manejo de riesgos es un tema importante en la administración de proyectos y de igual forma para la Actividad de Arquitectura. Unos de los objetivos de la arquitectura es precisamente disminuir los riesgos tecnológicos.
      La idea es identificar todos aquellas situaciones que pueden poner en riesgo el éxito del proyecto dentro de las restricciones de tiempo y presupuesto, crear un plan de mitigación y de contingencia en caso de que se de el problema.
      Riesgo
      Descripción
      Probabilidad
      Impacto
      Plan de mitigación
      Ejemplo:

      Diferente comportamiento entre el ambiente de desarrollo y de producción
      El ambiente de desarrollo es Windows y el de Producción es UNIX puede haber problemas de ambientación
      ALTA / MEDIA / BAJA
      ALTO / MEDIO / BAJO
      * Desarrollar en maquinas virtuales

      * Realizar deploys y revisiones periódicas del sistema en el ambiente AIX
      Ejemplo:

      El cliente propone el uso de un framework web open source que no ha sido probado en el servidor final
      La especificación dice que el servidor de aplicaciones que adquirirá el cliente cumple con le especificación XXX y el framework necesita de esa especificación para poder funcionar. Hay una probabilidad de que el framework no funcione correctamente
      BAJA
      ALTO
      RESUELTO

      Se realizaron pruebas de operaciones complejas con el framework usando la misma versión y sistema operativo del servidor de aplicaciones.
      Ejemplo:

      Tiempos de respuesta arriba del valor requerido
      Se está solicitando el tener tiempos de respuesta de máximo 5 segundos para operaciones de consulta en horario pico

      Dada la configuración de topología red donde se tiene … …
      MEDIO
      ALTO



      Es un criterio de aceptación para la liberación
      Se deben hacer pruebas de desempeño en el servidor de pruebas usando los mismos elementos de hardware e identificar posibles cuellos de botella fuera de la aplicación


      Esta tabla es un ejemplo y nos ayuda a identificar y prepararnos para saber que debe hacerse en caso de que se presente un problema previamente identificado.
      Esta lista de riesgos debe actualizarse y mantenerse durante todo el desarrollo del proyecto


      Sizing y Planeación de la Capacidad

      Dentro de este rubro se puede mencionar la medición del crecimiento de espacio en disco por elementos propios de la aplicación, información tales como archivos o datos de la base de datos o número de peticiones de clientes considerando cifras iniciales y a futuro.
      Esta recolección de cifras ayudará a determinar qué tipo y cantidad de hardware es necesaria para soportar la operación del sistema en un horizonte de tiempo dado.


      Numero de Accesos

      Operaciones más demandantes
      Accesos concurrentes Iníciales, Horario Pico

      (Operaciones / min)
      Accesos concurrentes

      Iníciales, Horario No Pico

      (Operaciones / min)
      Accesos concurrentes Futuros, Horario Pico

      (Operaciones / min)
      Accesos concurrentes

      Futuros, Horario No Pico

      (Operaciones / min)
      Registro de X
      750
      200
      825
      220
      Consulta de reportes
      300
      50
      330
      55
      Configuración de catalogos
      -
      -
      330

      A 1 año
      55

      A 1 año


      Crecimiento de espacio en Disco Duro

      Descripción del archivo
      Tipo de Archivo
      Cantidad inicial (6 meses) MB
      Tamaño al final del año (MB)
      Porcentaje semestral
      Periodicidad
      EARs, Wars de la aplicación
      Aplicación



      Archivos
      Archivos




      Base de datos
      Base de Datos




      Log
      Archivo de texto




      Esquema de Base de Datos
      Esquema



      Total







      Crecimiento de la base de datos

      Tabla
      Tamaño inicial en registros (primeros 6 meses)
      Incremento semestral (% o núm)
      Operación



      Consulta
      Actualización
      Nombre


      Oper
      Frec
      % o núm.
      Oper
      Frec
      % o núm.
      CSI_AREA
      13
      0%
      S
      DIA
      525
      -----
      -----
      0
      CSI_COLONIA
      91500
      0%
      S
      DIA
      525
      -----
      -----
      0
      CSI_DEPENDENCIA
      30
      0%
      S
      DIA
      525
      -----
      -----
      0
      CSI_ESTADO
      32
      0%
      S
      DIA
      525
      -----
      -----
      0










      Propuesta de Solución (Diseño)

      Tipo de Sistema

      Se debe especificar qué tipo de sistema se desarrollará.
      • Cliente / Servidor 
      • Multicapa 
      • Multicapa web

      Diagrama de Capas y Filas


      Este diagrama es un artefacto de la metodología Sun Tone Methodology, muestra la tecnología a utilizar en cada una de las capas del sistema y por cada capa define niveles de productos que participan en la solución. Cada una de las tecnologías elegidas da solución a los requerimientos detectados en la fase de Análisis.
      Ejemplo: Este es un diagrama de ejemplo, Algunas de las celdas pueden haber sido dadas de inicio por las restricciones tecnológicas del cliente y las otras se llenan con la propuesta tecnológica del Arquitecto
      Capa

      Nivel
      Capa Cliente
      Capa de Presentación
      Capa de Negocio
      Capa Integración o Acceso a Datos
      Capa de Recursos
      API, Framework
      *HTML ver. 4.01

      *CSS 2.1

      *DOM 2

      *Javascript

      *Plugins:

      *Adobe Reader PDF

      *Ajax Prototipe

      Presentación:

      *Web Components JSP1.2, Servlet 2.5,

      *Struts 1.3

      *JSE 6.0

      Reportes:

      *Jasper Reports

      *JFree Chart

      Utilerias:

      *apache-commons
      *POJOs con JSE 6.0

      *Hibernate 3.0

      *JSE 6.0

      *Webservices con JAX-WS

      *Correo con apache-mail

      *Java IO para lectura de archivos

      *WebServices con AXIS2.0
      BD:

      *Tablas

      *No Habra triggers, ni stored procedures
      Producto
      Explorer >=6.0, Mozilla>=2.0
      *JBoss 4.3.2GA con soporte para JEE5.0

      *Workflow: jBPM 3.3.2

      *SQL Server 2005 para la BD del sistema (En server 1)

      Sistema Operativo
      Cualquiera





      *Linux Ubuntu Server 8.04
      *Windows 2003 Server en server 1.
      Hardware
      Cualquiera





      *Servidor 2: Opteron AMD dual core serie 800
      *Servidor 1: intel xeon 3.2 MHZ



      Capa de Cliente: Es la capa donde se ejecuta una aplicación de consola, dispositivo móvil, pc desktop o con navegador web.
      Capa de Presentación: Aquí residen los componentes dinámicos de vista y control que generan una salida HTML, XML y los Reportes que se envían al cliente, por ejemplo JSP, Servlets.
      Capa de Negocio: Aquí residen los procesos de negocio, workflow, timers.
      Capa de Integración: Aquí residen los componentes que permiten la comunicación al exterior tal como componentes de acceso a base de datos, web services, correo, colas de mensajes, clientes de web service, conectores.
      Capa de Recursos: Aquí se encuentran todas las fuentes de información externas, tales como Bases de Datos, sistemas de Archivos, Content Managers, Mainframes.


      Diagrama de Componentes

      El diagrama de componentes inicial es una propuesta de que componentes de software intervendrán en la solución.

      Diagrama de Despliegue

      El Diagrama de Despliegue inicial nos ayuda a saber con qué otros sistemas interactuarán y convivirá el nuestro dentro.

      Prototipo

      Provee una demostración o implementación de principio a fin de los componentes tecnológicos primarios, demuestra la viabilidad de la solución y sirve como guía para el desarrollo del sistema.
      Estos prototipos pueden ser implementaciones base o presentaciones ppt dependiendo del nivel de cliente para el cual se desea hacer una prueba


      Usabilidad

      La usabilidad toma en cuenta el tipo de personas que serán usuarios del sistema para proporcionarles una interfaz de usuario que permita hacer productivo su trabajo y por ninguna circunstancia dañe su información. En este sentido es necesario al inicio del proyecto hacer pruebas de usabilidad ya sea con un demo o una presentación que muestre la forma en la que se interactuará con el sistema.
      Principios de Diseño a seguir:
      • Visibilidad – Claridad en la información a presentar.
      • Retroalimentación – Enviar información en respuesta a una acción del usuario.
      • Facilidad - Uso de elementos obvios y sencillos para el usuario.
      • Simplicidad – Mantener una interfaz simple.
      • Estructura – L a interfaz de usuario está dispuesta en una forma lógica y con sentido.
      • Consistencia – Uniformidad y la navegación hacen fácil el uso
      • Tolerancia – La aplicación debe tolerar los errores de usuario, (uso de confirmaciones, mensajes de error)
        El realizar esta exploración de los elementos de interfaz de usuario requeridos ayudará a elegir la tecnología de la capa de presentación que debe usarse desde el inicio del proyecto. No es lo mismo utilizar simples JSPs que utilizar AJAX, esta diferencia implica requerimientos del servidor de aplicaciones, de recursos humanos y de costos.

        Conclusión

        Si bien el Arquitecto de Sistemas es una persona experimentada, su responsabilidad no jugar el rol de Analista, Diseñador, Líder de Proyecto y Tester al mismo tiempo, más bien tiene como responsabilidad el asegurar que el sistema sea desarrollado minimizando riesgos tecnológicos y que el sistema una vez liberado opere sin poner en riesgo los objetivos de negocio para los cuales fue creado. Para esto es necesario que aplique su experiencia y buenas prácticas de diseño de sistemas.
        Así mismo el entregable del Arquitecto no es un "Si" "No" a capricho en la elección de la tecnología a usar. Todo el proceso de análisis, las alternativas de solución y la decisión final deben estar sustentados y plasmados en un Documento de Arquitectura que documente las decisiones de diseño y guie el desarrollo.


        Referencias

        Software Architecture in Practice
        http://books.google.com.mx/books?id=mdiIu8Kk1WMC

        The J2EE Architect's Handbook
        http://www.theserverside.com/tt/books/DVTPress/J2EEArchitectsHandbook/index.tss

        Developing Architectures for Enterprise Java Applications (SL-425) Course
        http://www.sun.com/training/catalog/courses/SL-425.xml

        Sun Tone Methodology
        http://rieck.dyndns.org/architecture/suntoneam_wp_5.24.pdf?version=1

        viernes, 6 de noviembre de 2009

        Material del Taller JEE 5

        Hola chicos de la UNACH

        Les coloco aqui un link al material del taller de desarrollo con JEE5.0.
        http://rapidshare.com/files/303442402/presentacionJEE.zip

        La solución del Taller aqui esta para Netbeans 6.5.1 y Tomcat 6.0.
        La de Glassfish 2.0 tengo que checarla.
        http://rapidshare.com/files/303446391/TallerJEE5.zip

        La liga correcta para la consulta de libros es la siguiente:
        http://www.flazx.com/search.php?p=java

        Otros links interesantes:

        Sun Developer Network
        http://developers.sun.com/

        Javapassion – Cursos online
        http://www.javapassion.com/

        Sitio oficial Netbeans
        http://www.netbeans.org/

        Javahispano
        http://www.javahispano.org/

        Comunidad de Desarrolladores en México
        http://www.javamexico.org/

        Bye.

        Simposio Internacional de Tecnologias de la informacion.

        Tuve el honor de participar en el 3er Simposio Internacional de Tecnologias de la Informacion celebrado en la Ciudad Tapachula Chiapas.
        http://simposio.fcp.unach.mx/programa.htm



        La experiencia fue realmente agradable, participe en un programa de television local (Todavia no me veo), Dí una platica de JEE en los procesos Administrativos de las Empresas e impartí un Taller de Desarrollo con JEE 5.0 a los estudiantes de los ultimos semestres de la carrera de Licenciatura en Sistemas. (Aunque aqui me fallo JPA y prometí enviar la solucion del taller)

        Aproveche para darme una vuelta por la ciudad y probar algunos platillos: cafe de Chiapas, tamal con chipilin, el pollo Campero no le pide nada al Feliz.


        Gracias a Cesar Guzman por invitarme, Christian Castillo, Julio Artigas, Flor de Maria por sus atenciones, a los asistentes por su entusiasmo, realmente me trataron de maravilla, espero me vuelvan a invitar.

        Técnicas de Analisis y Diseño Orientado a Objetos

        TECNICAS DE ADOO

        Para crear un sistema orientado a objetos es necesario analizar y diseñar orientado a objetos, UML no es suficiente, necesitamos usar técnicas adicionales para ayudarnos.

        Algunas de estas técnicas que podemos usar para detectar Clases, Secuencias y otros son:
        Narrativa de Casos de Uso – Técnica para describir la serie de pasos para llevar a cabo una funcionalidad en el sistema. No se tocará en este artículo.
        Análisis CRC – Técnica para descubrir los objetos de negocio, mas tarde en la etapa de diseño se convierten en clases.
        Análisis de Robustez o Modelo de Analisis – Técnica para encontrar la secuencia de llamadas entre los objetos involucrados en la solución de 1 caso de uso.
        Diagrama de Capas y Niveles – Técnica que le ayuda al arquitecto a identificar la tecnología requerida en un sistema multicapa. Por la extensión del tema lo abordare en el siguiente artículo.


        ANALISIS CLASE-RESPONSABILIDAD-COLABORACION (CRC)

        Te has preguntado: ¿Cómo obtengo las clases de negocio del sistema?

        Las clases core o de negocio pueden y deben obtenerse desde la fase de analisis, no se descubren hasta la construcción, para ello puedes aplicar la experiencia o usar esta técnica mientras te vuelves experto. No es la única técnica pero es muy efectiva.

        El producto es un diagrama de clases de negocio llamado Modelo de Dominio. No contiene detalles técnicos como getters o atributos estáticos, más bien tipos básicos, asociaciones, cardinalidad y navegación.

        Pasos para aplicar esta técnica:

        Identificar Abstracciones Clave (Objetos de negocio candidatos)
        1. Subrayar sustantivos en los documentos fuente de requerimientos: de Casos de Uso, Reportes, Requerimientos del SRS, minutas, etc.
        2. Colocar los sustantivos en la lista de Abstracciones Clave candidatas

        Identificar Responsabilidades: Atributos y Operaciones
        3. Crear una tarjeta CRC por cada abstracción
        4. Identificar propiedades de cada abstracción candidata
        · Identificar atributos simples y compuestos
        · Anotarlos en la sección de responsabilidades
        5. Identificar operaciones de cada abstracción candidata.
        · Identificar acciones, verbos que se aplican sobre la abstracción
        · Anotarlos en la sección de responsabilidades

        Identificar Colaboraciones
        6. Identificar si la abstracción mantiene una relación “tiene un” “depende de” “contiene a” con otra
        · Anotarla en la sección de colaboración
        · Si hay una propiedad compuesta crear otra tarjeta, sacarla de la lista de propiedades y anotar su colaboración en ambas tarjetas

        Eliminar abstracciones no clave
        8. De la lista de candidatos eliminar las abstracciones clave que no colaboran o no forman parte como propiedad con otra abstracción.
        · Colocar razones de eliminación.

        Documentar el resultado del análisis
        9. Crear diagrama de Objetos de Negocio (Modelo de Dominio)
        · Anotar el nombre del Objeto, Cardinalidad, Navegación
        · Introducir objetos intermedios para relaciones muchos a muchos




        ANALISIS DE ROBUSTEZ

        Ok ya tengo los objetos y ahora ¿Como entran en acción en cada caso de uso?
        El sistema no se forma solo de clases de negocio, ¿Como obtener las demas clases que intervienen en el sistema?

        Esta técnica no es muy conocida pero es muy útil, responde las preguntas anteriores y además ayuda a separar los elementos del sistema por capas, validar la narrativa del caso de uso y facilita la creación de los diagramas de secuencia.

        El resultado del análisis robusto es un diagrama de colaboracion con el detalle de la secuencia de llamadas entre objetos que participan en un caso de uso.


        Elementos del análisis robusto:




        Boundary o Interfaz de usuario – Son objetos “Que muestran o piden datos”. Representa una pantalla, ventana, página, reporte.
        Service o Control – Son objetos “Que hacen”. Son componentes que invocan, coordinan a otros objetos, realizan calculos, consultan o modifican objetos de negocio.
        Entity u Objeto de Negocio – Son objetos “Que son”. Son los objetos detectados en el modelo de dominio, casi siempre son persistentes, es decir, se guardan en un repositorio de datos.


        Reglas:
        • Para poder hacer este análisis es imprescindible tener la narrativa el caso de uso y las Clases de Negocio.
        • Se toma un caso de uso y se coloca el actor que inicia la funcionalidad del caso de uso.
        • Todo actor que inicie una interaccion con el sistema debe iniciar con un objeto Boundary.
        • Los Boundaries se detectan en la narrativa de casos de uso cuando se mencionan los conceptos: Pantalla, Página, Ventana. Si en la narrativa no se detecta un boundary inicial entonces hay un error en el caso de uso.
        • Los Servicios se detectan cuando en el caso de uso se menciona: “El Sistema realiza, El sistema ejecuta”
        • Los Entities son las clases de negocio u objetos del modelo de dominio que se detectaron con el análisis CRC
        • La interaccion se indica trazando una línea entre los objetos y se coloca un número y el nombre del mensaje a lado del la línea.
        • El acceso a un objeto entity se hace a través de un objeto service.Las operaciones CRUD son realizadas directamente por los objetos entity, mas adelante se refina el diseño y estas operaciones se asignan a un DAO.





        Por el momento no coloque un ejemplo pero se proporcionan links de referencia para más detalle.

        Analisis CRC
        http://www.agilemodeling.com/artifacts/crcModel.htm

        Análisis de Robustez
        http://www.codeproject.com/KB/architecture/ModelViewController.aspx http://www.agilemodeling.com/artifacts/robustnessDiagram.htm