Photo by Noticias TIC.
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.
- 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.
- 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.
- 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.
Enlaces Relacionados:
Metodologia Analisis de Fusión
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.1
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.
Figura: Metodología de Fusión - Diseño
Gráfico de Interacción de Objetos
La primera consideración en diseño orientado a objetos es la implementación de cada operación del sistema. El modelo de funcionamiento especifica la conducta de estas operaciones definiendo el efecto de cada operación en términos de cambios de estado del sistema y eventos de salida. El propósito de esta fase en diseño es construir las estructuras de mensajes entre objetos definidas en el modelo de funcionamiento.
El gráfico de interacción de objetos se construye para cada operación del sistema. Un gráfico de interacción de objetos es una colección de cajas unidas por flechas. Las cajas representan al objeto, y las flechas que representan el paso del mensaje. Hay dos tipos de cajas:
Director. Le llega una flecha que no viene de ninguna otra caja del gráfico; esta flecha se etiqueta con el nombre de la operación del sistema que implementa ese gráfico de interacción de objetos.
Colaboradores. El resto de las cajas se llaman colaboradores. El resto de las flechas, a excepción de la operación del sistema, van de una caja a otra dentro del gráfico.
Las sucesiones de mensajes entre los objetos determinan el comportamiento de los objetos declarados en el gráfico de interacción de objetos. Esto define la implementación a alto nivel de la funcionalidad a través de los objetos para una operación del sistema. Cada gráfico de interacción de objetos también lleva asociado un texto descriptivo en el diccionario de datos, en lenguaje natural, pseudo-código, o especificación formal, para dar significado a la operación del sistema y los mensajes definidos.
A continuación se detalla cada uno de los componentes del gráfico de interacción de objetos.
Colecciones de Objetos: Colecciones de objetos de la misma clase. Las implementaciones típicas de estas colecciones serán listas o arreglos.
Paso de Mensajes: El paso de mensajes es una comunicación punto a punto, y se realiza como una llamada a una función o método. La notación es una flecha directa con etiquetas. La dirección de la flecha es del remitente al receptor. También se llaman cliente y servidor.
Paso de mensajes a Colecciones: Un mensaje puede pasarse a colecciones de objetos. La notación es una flecha directa a una caja con líneas discontinuas.
Secuencia de Mensajes: Si una secuencia de pasos de mensajes es importante, se puede mostrar el orden de la secuencia introduciendo etiquetas de la secuencia entre paréntesis sobre el nombre del mensaje.
Creación dinámica de objetos: La palabra clave new indica que un objeto se crea como parte de la ejecución de un gráfico de interacción de objetos.
Descripciones de Clases
Después de desarrollar los gráficos de visibilidad para todas las clases, el siguiente paso es intercalar información del modelo de objetos del sistema, de los gráficos de interacción y de los gráficos de visibilidad en descripciones de clase, una para cada clase.
El proceso para construir descripciones de clases es como sigue:
Métodos y sus parámetros: se derivan métodos de los gráficos de interacción de objetos.
Atributos de Datos: La fuente para los atributos de datos es el modelo de sistema y el diccionario de datos.
Dependencias de Herencia: Las dependencias de herencia se documentan después de definir los gráficos de herencia.
Gráficos de Herencia
Una consideración importante en diseño orientado a objetos es la herencia, un mecanismo por cual una clase puede definirse como una especialización de otra. Los gráficos de herencia reflejan las relaciones de herencia entre las clases.
La notación usada para herencia es igual que la notación del modelo de objetos usado para la generalización y la especialización. Una caja representa una clase, con el nombre de clase indicado en la sección superior de la caja. Se nombran los atributos en la caja debajo de la línea.
Triángulo hueco: No se hace ninguna suposición de que las subclases sean disjuntas o que particionen a la superclase. Esto significa que pueden existir otras subclases que hereden de la superclase.
Triángulo Sólido: Esto indica que las clases son disjuntas y que su unión forma la superclase. Esto significa que no hay más subclases que hereden la superclase.
