Flujo de Trabajo Análisis y Diseño
| ||||||
Flujo de Trabajo Análisis y Diseño: Esta disciplina explica cómo transformar los productos de trabajo de los requisitos en los productos de trabajo que especifiquen el diseño del software que el proyecto va a desarrollar.
Aunque RUP contempla Análisis y Diseño en mismo Flujo de Trabajo por estar muy relacionadas, son actividades diferentes con artefactos diferentes.
Sumario
Objetivos del Análisis y Diseño
El Análisis y Diseño de un producto software tiene como finalidad:
* Transformar los requisitos en un diseño del sistema en creación. *Evolucionar una arquitectura sólida para el sistema.
*Adaptar el diseño para que se ajuste al entorno de implementación, con un diseño pensado para el rendimiento.
Relación del Flujo de Trabajo de Análisis y Diseño con otras disciplinas
La disciplina de Análisis y Diseño está relacionada con otras disciplinas de la siguiente forma:
*La disciplina de Requisitos proporciona una entrada fundamental para el análisis y diseño.
*La disciplina de Implementación implementa el diseño.
*La disciplina de Prueba prueba el sistema diseñado durante al análisis y diseño.
*La disciplina de entorno desarrolla y mantiene los artefactos de soporte que se utilizan durante el análisis y diseño.
*La disciplina de Gestión de Proyectos planifica el proyecto y las iteraciones (descritas en el plan de iteración).
Disciplina del Análisis
Análisis
Luego de identificados todos los requisitos que debe satisfacer el software que se va a desarrollar es importante realizar un Análisis de ellos, con el objetivo de tener una mejor comprensión antes de entrar al diseño de dicho software, garantizando así una arquitectura robusta, eficaz, eficiente y capaz de sobrevivir a cambios. Por esta razón existe esta Disciplina.
En los Flujos de Trabajo anteriores el Cliente jugaba un rol decisivo, por lo que el lenguaje utilizado estaba al alcance de todos, ya en esta Disciplina se comienza a hablar en un lenguaje propio de los desarrolladores y se separan a los Clientes del trabajo. También se comienza a ver el software de forma interna, en función de clases y paquetes que permiten el cumplimiento de todos los requisitos que deben ser cumplidos.
El Modelo de Análisis puede considerarse como una primera aproximación al Modelo de Diseño. Es una entrada fundamental cuando se da forma al sistema en el Diseño y en la Implementación.
Si se sigue un Paradigma Orientado a Objetos (OO) entonces en el Análisis obtendremos las primeras propuestas de Clases que se encarguen de garantizar los distintos servicios que el cliente necesita. Se dice que es una aproximación inicial, ya que en el Análisis modelamos solo 3 tipos de clases ( Interfaz, Control, Entidad) y estas no se encuentran especificadas en ningún lenguaje de programación en concreto, así que aun no podrían ser codificadas, ellas deben enriquecerse y profundizarse en flujos posteriores en aras de cumplir ese objetivo.
La Disciplina del Análisis tiene como propósito:
*Conseguir una comprensión más precisa de los requisitos, refinarlos y estructurarlos.
*Utilizar el lenguaje de los desarrolladores para analizar con profundidad los requisitos funcionales.
* Proporcionar una visión general del sistema.
Artefactos más importantes del Análisis
- Paquete del Análisis
Cuando se trabaja en sistemas medianamente complejos se necesita agrupar las Clases en módulos lógicos que permitan favorecer la reutilización, que se vuelva más fácil manipular la complejidad y distribuir el trabajo entre los miembros del equipo, por esta razón aparecen los Paquetes de Análisis.
Un paquete del análisis puede incluir clases del análisis, realizaciones de CU y otros paquetes del análisis (recursivamente). Todos los elementos que se encuentran dentro de un paquete del Análisis no son necesariamente visibles desde el exterior, es decir, un paquete encapsula a la vez que agrupa. Debe procurarse que los paquetes cumplan con el patrón de “ Alta Cohesión y Bajo Acoplamiento”.
- Clase del Análisis
Modelo conceptual temprano que describe las características y comportamiento comunes de un conjunto de cosas que existen en el sistema. Se indica que es conceptual pues pospone todos los elementos de diseño ya que no considera posibles tecnologías a emplear en el desarrollo del software. Constituyen un prototipo de las futuras clases que darán vida al mismo. Las clases del Análisis están siempre identificadas con uno de los tres estereotipos siguientes:
-Interfaz (Boundary): se encargan de la modelación de toda la interacción que puede existir entre los actores y el sistema. Constituyen las fronteras del sistema.
-Control: representan la coordinación, secuenciación, transacciones y a veces la lógica del [[|]] negocio. Se emplean a menudo para encapsular el control referido a un Caso de Uso (CU).
-Entidad: representa la información de larga duración y a menudo persistente que se maneja en el sistema.
- Diagrama de Colaboración
Se utilizan para ilustrar la realización de un Caso de Uso (CU). Muestra como los objetos interactúan para lograr el comportamiento de un CU o parte de este y de esta forma definen los roles de los mismos. A diferencia de los diagramas de secuencia su principal objetivo es mostrar la relación entre dichos objetos. Estos diagramas tienen una mayor utilidad cuando se utilizan en interacciones entre un número no muy grande de objetos, pues en caso contrario el número de mensajes entre estos crece y el diagrama se hace difícil de entender; en estos casos los diagramas de secuencia son una mejor elección.
- Diagrama de Secuencia
Al igual que los Diagramas de Colaboración los diagramas de secuencia se utilizan para ilustrar la realización de un CU. Son particularmente importantes para los diseñadores pues aclaran los roles jugados por los objetos en un flujo, lo cual le proporciona un gran valor para la determinación de las responsabilidades de las clases. A diferencia del Diagrama de Colaboración este incluye secuencia cronológica de los mensajes y no la relación entre los objetos, por lo que es mejor su utilización cuando el orden en el tiempo de los mensajes es de importancia.
- Diagrama de Clases del Análisis
Constituye una vista estáticade las Clases que conforman el Modelo del Análisis y las asociaciones entre las mismas. Es una vista de la futura composición de clases de software.
- Realización de Caso de Uso
Descripción de cómo se realiza un CU. Esta se expresa en términos de un Diagrama de Clases que muestra las Clases del Análisis participantes en la realización del CU y Diagramas de Interacción que muestran como se lleva a cabo la colaboración entre las clases para dar cumplimiento al mismo (tantos diagramas como sean necesarios para abarcar todas los posibles desenlaces ( escenarios) del CU).
Trabajadores del Análisis
En la Disciplina de Análisis aparecen involucrados principalmente los siguientes Roles:
Fuente
- JACOBSON, Ivar; RUMBAUGH, James; BOOCH, Grady, “El proceso unificado de desarrollo”.2000. Addison Wesley. capítulos 9
- RUMBAUGH, James, JACOBSON, Ivar; BOOCH, Grady, “El lenguaje unificado de modelado. Manual de referencia”.2000. Addison Wesley. Capítulos 8 y 13
- LARMAN, Craig “UML y patrones” 1999, Prentice Hall Iberoamericana. Capítulos 13, 16, 17, 18, 19, 21, 34 y 35.
- Bruegge, B. Y Dutoit, A. “Ingeniería de Software Orientado a Objetos”. 2002. Prentice Hall – Pearson Educación. Capítulos 5 y 6.
- GAMMA, E.; HELM, R.; JOHNSON, R. y VLISSIDES, J. “Patrones de diseño”.2000. http//www.vico.org/pages/PatronsDisseny.html.
- UML y la Modelación de datos.pdf. Whitepaper de Rational Rose.
- Rational Unified Process (de la Suite de Rational 2003)
