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
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 aAná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 se 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:
-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.
Principales artefactos 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.
Un Diagrama de Clases del Diseño está formado por dos elementos básicos: las Clases y las Relaciones entre ellas.
Una clase de UML se representa con un rectángulo dividido en 3 secciones. La primera sección o sección superior es empleada para indicar el nombre de la clase, la segunda o intermedia empleada para mostrar los atributos de la clase y la tercera para definir las responsabilidades de la clase.
Existen varios tipos de relaciones entre clases entre los que se encuentran:
-Dependencia “Dependency”
-Asociación “ Asociation ”
- Agregación “Agregation”
- Composición “Composition”
- Herencia “Hierarchy”
Subsistemas de diseño
Los subsistemas de diseño son una forma de organizar los artefactos del modelo de diseño en piezas más manejables. Puede contener clases del diseño, realizaciones de casos de uso, interfaces y otros subsistemas. Pueden proporcionar interfaces que representan la funcionalidad que exportan en términos de operaciones.
Un subsistema de diseño cumple la misma función que un paquete, pero tiene la diferencia que aquí el todo (subsistema) es mayor que la simple suma de las partes que lo componen, ya que estas se encuentran interrelacionadas de forma tal que puedan satisfacer ciertos servicios, el subsistema tiene una semántica, que lo hace algo más que una simple agrupación de elementos, el subsistema tiene “personalidad”, responsabilidades bien definidas, provee servicios que son empleados por otros subsistemas o sistemas en sí.
Los Servicios brindados por un subsistema, es decir, sus responsabilidades, las expone por un conjunto de interfaces, que es otro artefacto que resulta identificado en este punto, al igual que un sistema brinda funcionalidades a un actor a través de una interfaz, en este caso de usuario, el subsistema brinda su funcionalidad a través de una interfaz, pero de aplicación, es decir que cuando se refiere al artefacto “Interface” en la disciplina de diseño, no se esta hablando de una interfaz gráfica de usuario, sino de una interfaz a una aplicación o parte de ella.
Cuando la clase del análisis es demasiado compleja, tal que parece contener comportamientos que no deben ser responsabilidad de una sola clase actuando sola, dicha clase debe ser transformada en un subsistema de diseño. El subsistema de diseño se usa para encapsular las colaboraciones y el comportamiento en una forma tal que los clientes, (elementos que utilizan los servicios del subsistema) puedan permanecer completamente despreocupados de cómo se ha diseñado internamente el subsistema, no importando incluso si este cambia internamente, para ellos es de vital importancia el artefacto “Interface”.
Interfaz
Las interfaces se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas del diseño.
Una clase de diseño que proporcione una interfaz debe proporcionar también métodos que realicen las operaciones de la interfaz. Un subsistema que proporcione una interfaz debe contener también clases del diseño u otros subsistemas (recursivamente) que proporcionen la interfaz.
Paquetes de Diseño
Es una colección de clases, relaciones, realizaciones de casos de uso, diagramas y otros paquetes que estén de alguna forma relacionados. Es usado para estructurar el modelo de diseño dividiéndolo en partes más pequeñas. A diferencia de los subsistemas de diseño, los paquetes no ofrecen una interfaz formal.
Los paquetes de diseño deben usarse fundamentalmente como herramienta organizacional del modelo para agrupar elementos relacionados, si se requiere un comportamiento o semántica se deben usar subsistemas de diseño.
Realización de casos de uso del diseño
Es una colaboración en el modelo de diseño que describe como se realiza un caso de uso específico, y como se ejecuta en términos de casos de uso del diseño. Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso del análisis en el modelo de análisis
Cuando el modelo de análisis no va a mantenerse a lo largo del ciclo de vida del software pero en cambio se utiliza solo para crear un buen diseño, no tendría realización de caso de uso del análisis. La dependencia de traza de una realización de caso de uso del diseño irá en este caso directamente hasta el caso de uso en el modelo de casos de uso.
Una realización de caso de uso del diseño tiene una descripción de flujos de eventos textual, diagramas de clases que muestran sus clases de diseño participantes y diagramas de interacción que muestran la realización de un flujo o escenarios concretos de un caso de uso en términos de interacción entre objetos del diseño.
Proporciona una realización física de la realización de caso de uso de análisis y también gestiona muchos requisitos no funcionales capturados en la realización de casos de uso del análisis. Por consiguiente una realización de casos de uso de diseño puede posponer el manejo de algunos requisitos hasta las subsiguientes actividades de implementación anotándolas como requisitos de implementación en la realización.
Diagramas de interacción
Los diagramas de secuencia y los diagramas de colaboración (ambos llamados diagramas de interacción) son dos de los cinco tipos de diagramas UML que se utilizan para modelar los aspectos dinámicos de los sistemas. Un diagrama de interacción muestra una interacción, que consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos.
Un diagrama de secuencia es un diagrama de interacción que destaca la ordenación temporal de los mensajes; un diagrama de colaboración es un diagrama de interacción que destaca la organización estructural de los objetos que envían y reciben mensajes.
Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un sistema. La mayoría de las veces, esto implica modelar instancias concretas o prototípicas de clases, interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento.
Los diagramas de interacción no son sólo importantes para modelar los aspectos dinámicos de un sistema, sino también para construir sistemas ejecutables por medio de ingeniería directa e inversa.
Un diagrama de interacción es básicamente una proyección de los elementos de una interacción. La semántica del contexto de una interacción, los objetos y roles, enlaces, mensajes y secuenciación se aplican a los diagramas de interacción. Al igual que los demás diagramas, los diagramas de interacción pueden contener notas y restricciones.
- Modelo de despliegue.
El modelo de despliegue es utilizado para capturar los elementos de configuración del procesamiento y las conexiones entre esos elementos. También se utiliza para visualizar la distribución de los componentes de software en los nodos físicos.
El mismo está compuesto por:
-Nodos: Elementos de procesamiento con al menos un procesador, memoria, y posiblemente otros dispositivos.
-Dispositivos: Nodos estereotipados sin capacidad de procesamiento en el nivel de abstracción que se modela.
-Conectores: Expresan el tipo de conector o protocolo utilizado entre el resto de los elementos del modelo.
- Descripción de la arquitectura.
La Arquitectura es el esqueleto o base de una aplicación, en esta se analiza la aplicación desde varios puntos de vista. En la arquitectura aparecen los artefactos más importantes y diferentes, para establecer un esquema de cómo deben ser los próximos artefactos a construir, o sea es puramente un semi-molde al que se deben ajustar sin muchos cambios los restantes artefactos a construir en la aplicación o solución. De obtenerse un artefacto demasiado diferente a los demás, este formaría parte de la arquitectura. En RUP, esta se compone de 4+1 vistas: vista lógica, vista de procesos, vista de implementación, vista de despliegue y estas cuatro regidas por la vista de casos de uso.
Durante el FT análisis y diseño se incorpora la vista lógica, la cual toma varios elementos del modelo de diseño.
Suelen considerarse significativos para la arquitectura los siguientes artefactos del modelo de diseño:
1. La descomposición del modelo de diseño en subsistemas, sus interfaces, y las dependencias entre ellos. Esta descomposición es muy significativa para la arquitectura en general, debido a que los subsistemas y sus interfaces constituyen la estructura fundamental del sistema.
2. Clases de diseño fundamentales como clases que poseen una traza con clases del análisis significativas, clases activas, y clases del diseño que sean generales y centrales.
3. Realizaciones de casos de uso del diseño que describen alguna funcionalidad importante y crítica que debe desarrollarse pronto dentro del ciclo de vida.
La descripción de la arquitectura contiene una vista de la arquitectura del modelo de despliegue, que muestra sus artefactos relevantes para la arquitectura.
Debido a su importancia, deberían mostrarse todos los aspectos del modelo de despliegue en la vista arquitectónica, incluyendo la correspondencia de los componentes sobre los nodos tal como se identificará durante la implementación.
- Modelo de datos
Este modelo se obtiene como resultado de la actividad: “Diseño de la base de datos”
Trabajadores del Diseño
En la Disciplina de Diseño aparecen involucrados principalmente los siguientes Roles:
- El Arquitecto
- El Diseñador
- El Diseñador de Bases de Datos
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)
