Flujo de Trabajo Análisis y Diseño

Flujo de Trabajo Análisis y Diseño Concepto: Esta disciplina centra su atención al inicio de la fase de Elaboración. Contribuye a obtener una arquitectura estable y sólida y facilita una comprensión en profundidad de los requisitos

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.

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

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 e modelan 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.

Principales Artefactos 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:

Representación de las clases del análisis en la herramientas de modelado Rational Rose

-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ática de 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:

• Arquitecto de software
• Ingeniero de Casos de Uso
• Ingeniero de componentes

Disciplina de Diseño

El diseño tiene el propósito de formular los modelos que se centran en los requisitos no funcionales y en el dominio de la solución y que prepara para la Implementación y Prueba del sistema. Pretende crear un plano del modelo de implementación, por lo que el grueso del esfuerzo está en las últimas iteraciones de elaboración y las primeras de construcción.

• El papel del diseño en el ciclo de vida del software

RUP define el Análisis y el Diseño como un único Flujo de Trabajo en el que hay actividades que se realizan desde la fase de Inicio. Durante esta fase se analiza si es posible dar una solución que satisfaga a los requerimientos significadtivos de la arquitectura. En la fase de Elaboración se comienza con un análisis de los elementos significativos de la arquitectura como parte de la 1ra iteración de elaboración y en las siguientes iteraciones se refina la arquitectura hasta diseñar todos sus elementos. En las restantes fases se hace algo de análisis y diseño vinculado con nuevos requerimientos que sean definidos y se decida implementar y con los defectos que haya que corregir como consecuencia de las pruebas realizadas.
El modelo de diseño está muy cercano al de implementación, lo que es natural para guardar y mantener el modelo de diseño a través del ciclo de vida completo del software.
En el diseño se modela el sistema y se encuentra su forma (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los no funcionales y las restricciones que se le suponen. Una entrada esencial en el diseño es el resultado del análisis, o sea el modelo de análisis, que proporciona una comprensión detallada de los requisitos. Además impone una estructura del sistema que hay que esforzarse por conservar lo más fielmente posible cuando se de forma al sistema.
La Disciplina de Diseño tiene como propósito:
-Adquirir una comprensión de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con los lenguajes de programación, componentes reutilizables, sistemas operativos, tecnologías de distribución y concurrencia y tecnologías de interfaz de usuario.
-Crear una entrada apropiada y un punto de partida para actividades de implementación, capturando los requisitos o subsistemas individuales, interfaces y clases.
-Descomponer los trabajos de implementación en partes más manejables que puedan ser llevadas a cabo por diferentes equipos de desarrollo.
-Capturar las interfaces entre los subsistemas antes en el ciclo de vida del software, lo cual es muy útil cuando utilizamos interfaces como elementos de sincronización entre diferentes equipos de desarrollo.

Artefactos más importantes del Diseño

• Modelo de Diseño

El artefacto Modelo de Diseño está compuesto por:
-Diagramas de Clases del Diseño y Diagramas de interacción (Colaboración y/o Secuencia) del Diseño. Estos últimos también llamados realización de casos de uso.
-Paquetes y Subsistemas de Diseño representados en una jerarquía y una breve descripción de ellos.
-Clases, interfaces, relaciones, etc. contenidas en los Paquetes y una breve descripción de ellos.

• Diagramas de Clases del Diseño

Un Diagrama de Clases del Diseño está formado por dos elementos básicos: las Clases y las Relaciones entre ellas.

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)