Implementación

La etapa final de la metodología de Fusión es la conversión del diseño en una implementación efectiva.  La transición es relativamente sencilla ya que las decisiones más complejas en cuanto al diseño ya han sido tomadas.  La implementación debe ser correcta, debe satisfacer los requerimientos, al mismo tiempo debe ser económica y no debe hacer uso excesivo de los recursos ni exceder el tiempo y el almacenamiento estipulado.

El resultado de la fase de implementación es el software que satisface los requisitos funcionales y no funcionales.

El proceso de implementación se encuentra dividido en tres partes: codificación, desempeño y revisión.

1. Codificación: En esta etapa existen cuatro elementos a traducir: El ciclo de vida, la descripción de las clases, el contenido de los métodos y el diccionario de datos.




2. Desempeño: El desempeño de una aplicación debe ser considerado desde el análisis, diseño y proceso de implementación.  No es necesario ser obsesivo con respecto al mismo, si la aplicación carece de velocidad se debe examinar cada componente de forma individual para saber en dónde focalizar los esfuerzos.  La depuración de partes individuales puede beneficiar a la aplicación cuando ésta se ejecute de forme integrada.  Los sistemas pueden ser eficientes más no así perfectos, se puede llegar a una condición ideal en el cual la aplicación sea lo suficientemente rápida que satisfaga la demanda de muchos usuarios en cuánto a velocidad y lo suficientemente robusta para que soporte inserciones masivas y/o procesos complejos.  Todo esto es un proceso de suficientes recursos a nivel de hardware (memoria, espacio y conectividad) y el uso adecuado de los mismo.
3. Revisión: Una vez que el código ha sido producido, este debe ser revisado.  Las inspecciones requieren que el código sea leído y entendido por personas distintas a sus autores.  Se revisa el comportamiento actual del sistema o partes del sistema, contra los requerimientos y especificaciones.  El objetivo de esto es detectar errores antes de que éstos entren en producción.

En la IV y ultima parte presentare un cuadro resumen sobre la Adaptación de la Metodologia de Fusión y ejemplos.

El diseño consiste en desarrollar un modelo abstracto de cómo un sistema lleva a cabo el comportamiento especificado en el análisis.

El diseñador escoge como se va a construir el sistema. Durante este proceso, los métodos se
unen a las clases. El diseñador también escoge cómo los objetos se relacionan entre ellos y qué relaciones de herencia entre estas clases son apropiadas.

La fase de diseño de Fusión se basa en las CRC y los métodos de Booch.

La salida del diseño es una estructura de software orientado a objeto que contiene la misma información y mantiene las relaciones definidas en el modelo de objetos del sistema.¹

Durante esta fase se desarrollan los tres modelos siguientes:

• Gráficos de Interacción de Objetos. Describen cómo los objetos interactúan en tiempo de ejecución para conseguir la funcionalidad especificada en el modelo de funcionamiento en la fase
  de análisis.

• Descripciones de Clases. Proporciona una especificación de la interface de la clase, atributos de referencia a objetos, y signaturas de los métodos para todas las clases en el sistema.

• Gráficos de Herencia. Describen las estructuras de herencia clases/subclases.

Quisiera compartir esta metodologia, que use con mis compañeros en la monografia, cuando nos la recomendaron solo articulos en inglés, muy poca información en español y de manera extensa, la ire proporcionando en partes, al ser bastante grande. Espero sirva a los desarrolladores de sistemas, sobre todo a los que necesitan una manera rápida de desarrollar Orientado a Objetos.

a. Introducción

Fusión, proporciona un método de desarrollo de software orientado a objeto, que abarca desde la definición de requisitos a la implementación en un lenguaje de programación.

Es considerada como una metodología de segunda generación, porque proviene de:

• OMT: modelo de objetos.
• CRC: interacción de objetos.
• BOOCH: visibilidad.

Los métodos formales: pre y post condiciones.

• Proporciona un proceso de desarrollo, que se divide en: Análisis, Diseño e Implementación.
• Ofrece notaciones para los modelos, que describen varios aspectos del software.
• Proporciona herramientas de gestión.

b. Análisis

El análisis se basa más en describir lo que hace un sistema en lugar de cómo lo hace. Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la perspectiva de la máquina. El análisis casa con el dominio del problema y se preocupa por el comportamiento visible externamente.

La meta de la fase de análisis es capturar tantos requisitos del sistema como sea posible. Se producen los siguientes modelos del sistema.

• Modelo de Objetos
• Modelo de la Interfase
• Modelo del funcionamiento.
• Modelo del ciclo de vida.

Estos modelos describen:

1. Clases de objetos que existen en el sistema.
2. Relaciones entre esas clases.
3. Operaciones que puedan realizarse en el sistema.
4. Secuencias permitidas de estas operaciones.

Figura 2. Metodología de Fusión – Análisis

La entrada para la fase de análisis es un documento de definición de requisitos en lenguaje natural.

i) Modelo de Objetos

La finalidad del modelo de objeto en Fusión es:

• Capturar los conceptos que existen en el dominio del problema y las relaciones entre ellos.
• Mostrar clases y sus relaciones, (no mostrar objetos)
• El modelo de objeto representa:
  • La estructura estática de la información en el sistema.
  • Las clases y las relaciones entre ellas.
  • Atributos de las clases.
  • Agregación
  • Especialización/generalización

Definiciones

Un objeto es cualquier cosa que puede ser identificada. Puede tener una serie de valores nombrados, llamados atributos.

Los objetos se agrupan en conjuntos, llamados clases.

Las relaciones se usan para modelar la idea de la asociación o correspondencia entre objetos que pertenecen a clases.

Para describir una relación, se consideran los puntos siguientes:

• Restricciones de Cardinalidad. Cardinalidad es el número de clases que pueden asociarse entre sí en una relación.
• Invariantes. Restricciones de que alguna propiedad se debe cumplir.
• Roles. Las clases que participan en una relación tienen roles. Los nombres para los roles o papeles en una relación deben ser únicos.
• Atributos de la relación. Las relaciones, como los objetos, pueden tener atributos.
• Relaciones ternarias y más altas. Las relaciones ternarias relacionan tres objetos separados. Las que involucran más de tres objetos se llaman relaciones n-arias.
  • La agregación es un mecanismo para estructurar el modelo de objetos. Permite la construcción de una clase agregada a partir de las otras clases componentes. La agregación modela las relaciones todo/parte.
  • La generalización permite a una clase, llamada supertipo, ser formada sacando las propiedades comunes de varias clases, llamadas subtipos. La especialización es el caso inverso en el que un nuevo subtipo se define como una versión más especializada de un supertipo.
  • La especialización múltiple permite definir un nuevo subtipo como una especialización de más de un supertipo inmediato. La subclase hereda los atributos y relaciones de todas las superclases.

Un diagrama de modelado de objetos puede ser dividido en subdiagramas.

ii) Modelo de Objetos del Sistema

El modelo de objetos del sistema es un subconjunto del modelo de objetos que describe el sistema a ser construido. Se forma excluyendo todas las clases y relaciones que pertenecen al entorno.

Usa la información sobre la interface del sistema para indicar qué clases y qué relaciones pertenecen al estado del sistema, y no a su entorno.

Las clases que quedan fuera del modelo de objetos del sistema no participan en las relaciones dentro del modelo de objetos del sistema. El modelo de objetos del sistema es la base en la que se hace el resto del desarrollo.

iii) Modelo de la Interface

El modelo de la interfaz describe el comportamiento de un sistema, por ejemplo, define la comunicación de entrada y salida del sistema. La descripción está en términos de eventos y el cambio de estado que ellos causan.

Un sistema se modela como una entidad activa que interactúa con otras entidades activas llamadas agentes. Los agentes modelan a los usuarios humanos, u otros sistemas hardware o software. Las características importantes de un agente son que es activo y se comunica con el sistema.

Un modelo de la interfaz utiliza dos modelos para diferentes aspectos del comportamiento:

• Modelo de Funcionamiento
• Modelo de Ciclo de Vida

1. Modelo del Funcionamiento

El modelo de funcionamiento (modelo funcional) especifica el comportamiento de las operaciones del sistema utilizando un Esquema de Modelado de Funcionamiento.
Define efectos del funcionamiento en términos de cambios de estado, eventos que son salida.

Una operación del sistema es un evento de entrada y su efecto en un sistema. Las operaciones del sistema son invocadas por agentes en el entorno. Una operación del sistema puede:

• Crear una nueva instancia de una clase
• Cambiar el valor de un atributo de un objeto existente
• Agregar o anular alguna tupla de objetos de una relación
• Enviar un evento a un agente

En este modelado definimos la semántica todas las operaciones del sistema y que fueron utilizadas en el modelo de ciclo de vida usando un esquema de modelo de funcionamiento.

2. Modelo del Ciclo de Vida

El modelo del ciclo de vida del sistema describe como el sistema se comunica con su entorno desde su creación hasta su muerte. Consiste en expresiones del ciclo de vida. Una expresión del ciclo de vida define las secuencias aceptables de interacciones en las que un sistema puede participar en su tiempo de vida. Es algo parecido al modo en que una gramática describe las secuencias aceptables de símbolos que son aceptados por un compilador.

iv) Proceso de Análisis

El análisis no es un proceso anárquico: hay una sucesión definida de pasos que pueden aplicarse iterativamente para producir una especificación completa y consistente que capture los requisitos.

El análisis es una actividad incremental e iterativa que formaliza los requisitos. Puede llevarse a cabo de una manera sistemática.

En Fusión, el proceso de análisis se define como sigue:

1. Desarrolle un modelo de objetos para el dominio del problema.
2. Determine la interfase del sistema.
3. Identifique los agentes, operaciones del sistema, y eventos.
4. Produzca el modelo de objetos del sistema agregando el límite al modelo de objetos.
5. Desarrolle un modelo de interfase.
6. Desarrolle un modelo de ciclo de vida.
7. Desarrolle un modelo de funcionamiento.
8. Verifique el modelo de análisis.

Desarrollo del modelo de objetos

El análisis debe empezarse con un alto nivel de abstracción. Es mejor utilizar los requisitos para una tormenta de ideas de posibles clases y relaciones. Solo después de que su estructura global sea satisfactoria deben añadirse los detalles. Se debe recordar que el modelo de objetos utiliza clases, mientras que un documento de requisitos es expresado principalmente en términos de objetos específicos.

Casi cualquier nombre puede dar lugar a una clase. Sin embargo, para serlo, el nombre debe pertenecer a un concepto que sea importante para la comprensión del dominio. Posibles fuentes de clases candidatas son:

• Objetos Físicos.
• Personas y organizaciones.
• Abstracciones.

Para definir las relaciones se deben modelar correspondencias entre objetos. Comunicaciones, asociaciones físicas, contenciones, y acciones son todas las posibles fuentes para relaciones candidatas. Una vez que las listas candidatas se han hecho, deben racionalizarse. En este punto deben de usarse las clases y relacionar las mismas considerando aspectos como:

• Generalización
• Agregación
• Atributos
• Cardinalidades
• Invariantes

Determinación de la Interface del Sistema

Durante el análisis, un sistema es modelado como una entidad activa que coopera con otras entidades activas, llamadas agentes. El sistema y los agentes se comunican enviando y recibiendo eventos. Cuando los eventos recibidos por el sistema, pued
en causar un cambio de estado y eventos de salida. Un evento de la entrada y su efecto asociado son conocidos como una operación del sistema.
La interfase de un sistema es el conjunto de operaciones del sistema a las que puede responder y los eventos que puede enviar.

Una operación del sistema siempre es invocada por un agente, no por un objeto; la fase del análisis no se preocupa por mensajes internos entre los objetos.

La información obtenida en la determinación de la interfase del sistema es el punto de partida para desarrollar el modelo de la interfase.

El escenario es una técnica útil para definir la interfase del sistema.Un escenario es una sucesión de eventos que fluyen entre agentes y el sistema para algún propósito.

Un escenario se representa como un diagrama de secuencia, que muestra las órdenes temporales del sistema y los eventos que fluyen a los agentes. Los diagramas de secuencia no pueden mostrar caminos alternativos de comunicación. Por consiguiente, en general pueden necesitarse diagramas múltiples para un solo escenario.

Los diagramas de secuencia de escenario aportan una herramienta para intuir las consecuencias del diseño de la interfase y visualizar cómo se comporta el sistema. Son útiles al validar decisiones de la interfase con clientes porque son simples e intuitivos de entender.

Desarrollo del Modelo de la Interfase

El modelo de la interfase comprende un modelo del ciclo de vida y un modelo del funcionamiento. El orden del desarrollo no es fijo. Sin embargo, es mejor empezar con el modelo del ciclo de vida porque el ciclo de vida puede ser una ayuda al desarrollo del esquema del modelo de funcionamiento.

Para desarrollar el modelo de ciclo de vida se debe entender que éste es una expresión generalizada de los escenarios que se expresan en diagramas de secuencia. Las expresiones del ciclo de vida son más expresivas que el diagrama de secuencia, porque pueden expresar repetición, alternación y opcionalidad, así como el encadenamiento.

Una expresión del ciclo de vida puede definir un conjunto de escenarios, mientras que un diagrama de secuencia puede mostrar sólo un solo escenario.

El proceso para formar el modelo del ciclo de vida es:

1. Generalice los escenarios para formar expresiones del ciclo de vida nombradas.
2. Combine las expresiones del ciclo de vida para formar el modelo de ciclo de vida.

Para definir el modelo de funcionamiento se debe definir la semántica de cada operación del sistema en la interfase del sistema usando un esquema de modelo del funcionamiento.

El proceso para desarrollar un esquema puede resumirse de la siguiente manera:

1. Desarrolle las cláusulas Asume y Resultados.
2. Extraiga las cláusulas Envía, Lee, y Cambia de Asume y Resultados.

v) Verificando los Modelos del Análisis

La perfección es inasequible y normalmente no se requiere. Sin embargo, una especificación con errores graves no sirve. Verificar los modelos del análisis es una manera estos errores. Si los chequeos no revelan ningún problema entonces se puede pensar que la fase de análisis está completa.

Existen dos aspectos que deben ser verificados: completitud (integridad) y consistencia.

La integridad puede medirse contra los requisitos. Los modelos del análisis deben probarse contra los requisitos, y también el conocimiento y expectativas de los clientes y expertos del dominio.

1) Chequeo de la integridad contra los Requisitos
Hay que verificar que:

• Todos los posibles escenarios son cubiertos por el ciclo de vida.
• Todas las operaciones del sistema son definidas por un esquema.
• Toda la información estática es capturada por el modelo de objetos del sistema.

Un conjunto de modelos es consistente cuando los modelos no se contradicen entre ello, explícitamente o implícitamente. En un modelo debe verificarse su consistencia interna y también para esas áreas donde se solapa con otros modelos.

2) Chequeo de la Consistencia Simple

Estos chequeos tratan las áreas de solape entre los modelos del análisis. Verifica que todas las clases, relaciones y atributos mencionados en el modelo del funcionamiento aparecen en el modelo de objetos del sistema.

3) Chequeos de la Consistencia Semántica

Estos chequeos intentan agrupar que las implicaciones de los modelos son consistentes. Verificando que:

• La salida de eventos en el modelo de ciclo de vida y el modelo de funcionamiento deben ser consistentes. El esquema para una operación del sistema debe generar los eventos de salida que lo siguen en los escenarios del modelo de ciclo de vida.
• El modelo de funcionamiento debe conservar invariantes del modelo de objetos del sistema. Si existe alguna invariante acerca de una relación o clase, entonces cualquier operación que puede cambiarlo debe respetar el invariante en su esquema.
• Ejecutar los escenarios y verificar que los resultados son los esperados.