UNIVERSIDAD NACIONAL DE

TRUJILLO FACULTAD DE CIENCIAS

FÍSICAS Y MATEMÁTICAS
ESCUELA DE INFORMÁTICA

METODOLOGÍA FUSION

CURSO: Sistemas Orientados a Objetos

PROFESOR: Ms. Carlos Castillo Diestra.

AUTORES: Barrantes Goicochea, Josué David

Cabrera Sanchez, Cristian

Castillo Quispe, Samuel

CICLO: IX

TRUJILLO-PERÚ
- 13 de febrero de 2018-
 RESUMEN

La metodología fusion se presenta como una metodología de segunda generación

que une las metodologías OMT, Booch, entre otras, para seleccionar lo mejor de

estas metodologías e intentar expandirlas; teniendo un ciclo de vida de tres fases

que comprende, análisis, diseño e implementación, las cuales ofrecen

documentación y test de pruebas en cada fase. A la vez se realiza un estudio

comparativo de Fusion con OMT y Booch, en donde se descubre las diferencias y

semejanzas entre cada una de ellas logrando establecer sus fortalezas y debilidades

para cada una de estas

 Índice

RESUMEN ........................................................................................................................................... 2
INTRODUCCIÓN .................................................................................................................................. 4
CAPITULO 1 ........................................................................................................................................ 5
ACERCA DE LA METODOLOGIA .......................................................................................................... 5
1.1 ¿Qué es la metodología Fusion? ........................................................................................ 5
1.2 Objetivos de una metodología orientada a objetos. ......................................................... 6
1.3 Características básicas de un Proceso Orientado a Objetos .............................................. 8
1.4 El proceso de Fusion........................................................................................................... 9
CAPITULO 2 ...................................................................................................................................... 10
CICLO DE VIDA DE LA METODOLOGIA FUSION ................................................................................ 10
CAPITULO 3 ...................................................................................................................................... 11
COMPARACION DESCRIPTIVA ENTRE LAS METODOLOGIAS OMT Y BOOCH.................................... 11
3.1 Comparación entre OMT .................................................................................................. 11
3.1.1 Comparación de los modelos de objetos. ................................................................ 11
3.2 Comparación con Booch .................................................................................................. 15
3.2.1 Gráfico de interacción de objetos versus diagrama de objetos ............................... 15
3.2.2 Otros gráficos de Fusion versus otros diagramas de Booch .................................... 16
3.2.3 Texto descriptivo versus plantillas ........................................................................... 17
CONCLUSIONES ................................................................................................................................ 18
BIBLIOGRAFIA ................................................................................................................................... 19
 INTRODUCCIÓN

El presente informe detalla la unión de los mejores componentes de las

metodologías OMT, Booch, entre otras, naciendo así la metodología Fusion.

También se realizará un estudio comparativo entre Fusion y las metodologías

OMT y Booch, haciendo énfasis entre sus características principales de cada

de ellas y como difiere el termino de primera y segunda generación entre

estas.
 CAPITULO 1
ACERCA DE LA METODOLOGIA

1.1 ¿Qué es la metodología Fusion?

En la actualidad, existen muchos métodos de desarrollo específicos para el

software orientado a objetos. A estos se les puede denominar de forma

general como métodos orientados a objetos de primera generación, porque

surgió al aplicar las nociones de orientación de objetos a los existentes no

orientados a objetos métodos. En este informe presentamos Fusion, un

software orientado a objetos de segunda generación método de desarrollo.

Fusion fue desarrollado para proporcionar un enfoque sistemático de

orientado a objetos al desarrollo de software. Integra y extiende los mejores

aspectos de varios métodos. La figura 1 muestra las principales influencias

en Fusion. (Ibrahim & Golder, 1994)

 Figura 1. Influencias de Fusion

1.2 Objetivos de una metodología orientada a objetos.

Los objetivos clave del diseño orientado al objeto son:

A. Aumentar la productividad: Según algunos estudios, el diseño

orientado al objeto logra aumentar la productividad de un desarrollo en un

20 %, lo cual no es mucho. Sin embargo, sabemos que entre el 75% y el

80% del coste de un sistema se produce después del desarrollo inicial. Pues

bien, es precisamente en esta fase donde el diseño orientado al objeto puede

ayudarnos a aumentar de forma espectacular la productividad.

B. Incrementar calidad: Cuando hacemos referencia al término calidad no

solo nos estamos refiriendo a la ausencia de errores, sino también a otros

aspectos quizás no tan fáciles de medir como son la facilidad de uso, la

portabilidad o la facilidad de modificación.

C. Facilidad de mantenimiento: Debemos partir de la base que es

imposible prever cambios que se producirán en meses o quizás años

posteriores, pero lo que si podemos hacer es separar las partes del sistema
que son intrínsecamente volátiles de aquellas que pueden ser estables. Los

aspectos más volátiles podrían ser el interface externo, los atributos que

describen ítems en el dominio del problema;... Mientras que los más estables

deben ser las clases.

D. Continuidad en la representación: Uno de los problemas más

importantes que presentan las metodologías estructuradas clásicas es el

problema de comunicación existente entre las fases de Análisis y Diseño, e

incluso dentro de la primera, entre los DFD (Diagramas de Flujo de Datos) y

los DER (Diagramas Entidad-Relación). Las técnicas orientadas a objetos

resuelven este problema, de manera que: ¨

- No hay diferencias entre la notación empleada en el análisis y la que se usa

en el diseño.

- No hay etapa de transición al diseño.

- Es posible intercalar tareas del Análisis Orientado a Objetos y del Diseño

Orientado a Objetos en el ciclo de desarrollo de la aplicación.

- Sin embargo, análisis y diseño usan técnicas diferentes. Mientras que el

AOO utiliza técnicas que ayudan a identificar y definir clases y objetos del

dominio del problema, el diseño orientado al objeto emplea técnicas que

ayudan a identificar y definir clases y objetos que reflejen la implementación

de requerimientos.
 - La representación es uniforme desde el AOO hasta el DOO y la POO,

constituyendo un marco de trabajo para la comprensibilidad, reusabilidad y

extensibilidad.

1.3 Características básicas de un Proceso Orientado a Objetos

1. Los entregables producidos durante el desarrollo del software se

consideran objetos con diversos atributos y métodos.

2. Hay una distinción estricta entre el entregable y su representación.

Utilizamos el término modelo para el entregable y el diagrama para su

representación si se puede representar gráficamente. El modelo determina

con qué información trabajamos, y el diagrama determina cómo se

representa. Un modelo de clase, por ejemplo, se representa típicamente por

uno o más diagramas de clase. Sin embargo, un modelo de caso de uso

puede representarse mediante un diagrama de casos de uso, una lista de

casos de uso (texto), esquemas de casos de uso, texto que describe

escenarios de muestras, etc. Un modelo de interacción del sistema puede

representarse mediante uno o más diagramas de secuencia, diagramas de

colaboración, diagramas de estados, en forma de Backus-Naur (ciclo de vida

de Fusion), y así sucesivamente. Para cada clase de entregable, hay un tipo

de representación recomendado.

3. Cada incremento (una pequeña pieza de funcionalidad añadida al producto

existente) se define mediante un único entregable llamado documento de

contexto de tareas, que corresponde a una tarea que se puede registrar en

Microsoft Project. El documento de contexto de la tarea contiene información

 general sobre el incremento, como una sinopsis, requisitos, métricas

(estimaciones de tiempo), desarrolladores responsables, etc. El documento

de contexto de tarea existe a lo largo de todo el ciclo de vida del incremento

(desde el análisis de requisitos hasta la implementación y prueba). La fase

de desarrollo del incremento se representa como un valor de uno de los

atributos del documento de contexto de la tarea (Hruby, SF)

1.4 El proceso de Fusion

Fusion promete ayudar a sus usuarios a través del ciclo de vida del desarrollo

de manera integral. Durante este proceso provee una variedad de modelos

o documentos que son creados en las etapas individuales y cuales son

llevados a la siguiente etapa para construir sus modelos respectivamente.

Fusion también provee de un número de mecanismos que ayudan al

desarrollador a incrementar la calidad general del sistema que será creado.

Esto suministra una serie de comprobaciones que ayuda a detectar

inconsistencias entre los diferentes modelos. Esto sugiere una serie de

heurísticas que guía en cada etapa lo que hay que hacer o no en la

ingeniería de software orientado a objetos.

El proceso de Fusion en conjunto está claramente particionada entre la fase

de análisis, fase de diseño y la fase de implementación. Fusion provee una

lista de tareas para cada fase, así el usuario está encargado de crear

apropiadamente las salidas durante las fases y el resultado de test antes de

continuar a la siguiente fase. Cada fase está muy bien estructurada y

descrita, con sus respectivos test y entregables. (Diedrichsen J. , 1995)

 CAPITULO 2
CICLO DE VIDA DE LA METODOLOGIA FUSION
 CAPITULO 3
COMPARACION DESCRIPTIVA ENTRE LAS METODOLOGIAS OMT Y
BOOCH

3.1 Comparación entre OMT

3.1.1 Comparación de los modelos de objetos.

Esta sección compara el modelo de objeto utilizado en fusión con el de OMT.

A pesar de que estos dos modelos de objetos se describen allí como similares

"aparte de las diferencias de notación relativamente menores", es instructivo

compararlos con cierto detalle. (Diedrichsen j. , 1995)

Clases y relaciones.

En "diferencias notacionales menores" notamos que Rumbaugh (autor de

OMT) y su co- los autores usan el término asociación de preferencia a

relación, ya que este último tiene connotaciones de base de datos. Los

métodos proporcionan notaciones similares para diagramar clases y

relaciones. Además, OMT proporciona, por ejemplo, diagramas, en los que

las instancias de objetos están relacionadas por enlaces, lo que parece ser

una distinción útil; Fusion pasa sin ningún equivalente.

Como se señaló anteriormente, las clases de Fusion no tienen una interfaz

de método durante el análisis, este no es el caso con las clases de OMT,

aunque la identificación de los métodos generalmente tiene lugar más tarde,

durante el modelado dinámico y funcional. Sin embargo, los objetos OMT

muestran un comportamiento dinámico durante su fase de análisis.

En Fusion, una relación entre (digamos) dos clases es un conjunto de tuplas,

un subconjunto del producto cartesiano de las dos clases, correspondiente a

la comprensión matemática de una relación. Una relación es total en una de

sus clases si todos los objetos en esa clase deben participar; Fusion

proporciona una notación de marcador total para indicar esta situación. En

Rumb91 se describen una serie de conceptos adicionales y más avanzados

con anotaciones asociadas que no tienen contrapartida en Fusion. Estos

incluyen metadatos (métodos de atributos de clases, etc.), objetos derivados,

atributos y enlaces, y homomorfismos. El homomorfismo es descrito por

Rumbaugh como un mapeo entre dos asociaciones.

Agregación

Más significativo es el enfoque diferente adoptado por los dos métodos para

la agregación; Rumbaugh considera esto como una parte especial de la forma

de asociación (relación), que corresponde a la contención física y, por lo

tanto, tiene propiedades adicionales, como la transitividad IRumb91] (página

57), además de la propagación de algunas propiedades del ensamblaje a sus

componentes. Incluso hay una notación especial para este último, más

heurística para decidir cuándo usar agregación antes que una asociación
simple. Para los autores de Fusion, la agregación también es "un mecanismo

para estructurar el modelo de objetos". Una clase puede aparecer dentro de

más de una clase agregada, ya que no hay ningún requisito de que la

agregación se corresponda necesariamente con una parte de relación.

También observamos que, mientras que OMT tiene una notación especial

para los casos en que una asociación debe ser tratada como una clase (quizás

porque participa en otra relación), la fusión utiliza una clase agregada como

un cuadro bastante artificial alrededor de una relación para lograr el mismo

efecto.

Generalización y herencia

En la generalización y la herencia, los dos métodos son muy similares (a

pesar de las notaciones contradictorias para distinguir las subclases que

dividen la superclase de las que no). Ambos recomiendan una adhesión

estricta a la herencia de subtipos durante el Análisis.

Empaquetado / agrupamiento de entidades

Otros métodos orientados a objetos proporcionan un mecanismo para

agrupar un conjunto de clases y relaciones estrechamente asociadas en una

sola unidad para proporcionar mayores niveles de mecanismo de abstracción

en sistemas grandes en [Your94]). Una construcción de módulo como un

componente lógico de un modelo de sistema, las Directrices para desarrollar

módulos se dan en OMT aunque no parece haber notaciones especiales para

documentar la interfaz externa de un solo módulo, o la composición de todo

el sistema en términos de módulos.

Fusion permite diagramas separados y proporciona reglas para cubrir casos

donde la misma clase y / o relación ocurre en más de uno.

Límite del sistema

Comparado con los métodos orientados a objetos anteriores, Fusion hace la

distinción entre el sistema y su entorno muy claro. Durante el modelado de

objetos, se identifican clases y relaciones de dominios de problemas. A partir

de esto, se deriva un modelo de objeto del sistema, excluyendo las clases

que corresponden a los agentes externos con los que el sistema interactúa

(la naturaleza de la interacción excesiva que se examina en el Modelo de

interfaz). Esta es una distinción útil, ya que la confusión (es decir, es parte

del sistema (es decir, sujeta a las decisiones de los desarrolladores y lo que

no es efectivamente inmutable), a menudo recurre a lo largo de m si no se

soluciona inicialmente. OMT no parece abordar esto en absoluto, aunque

tampoco lo hacen otros métodos orientados a objetos.

Esta es una distinción útil, ya que la confusión sobre lo que es parte del

sistema (es decir, sujeto a las decisiones de los desarrolladores) y lo que no

(es decir, por lo tanto, inmutable), a menudo recurre durante el modelado si

no se soluciona inicialmente.

OMT no parece para abordar esto en absoluto, aunque tampoco lo hacen

otros métodos orientados a objetos.

 Diccionario de datos

En línea con los enfoques estructurados más antiguos para el desarrollo,

Fusion aboga por el uso de un diccionario de datos para documentar las

entidades derivadas durante el Análisis (y Diseño), un repositorio central de

definiciones de términos y conceptos. Acerca de OMT también recomienda el

uso de un diccionario de datos (Rumb91), p156), pero dice muy poco al

respecto.

3.2 Comparación con Booch

La mayor fortaleza del método Booch [Booch911 y [Booch94] es su notación

extensiva y expresiva. La debilidad de Booch es su "proceso muy mal definido

y suelto" como se observa en (Cole941). Sin embargo, los autores de Fusion

afirman en el capítulo 8-8.2 [Cole94] que la etapa de diseño de Fusion se

basa en parte en el método de Booch.

3.2.1 Gráfico de interacción de objetos versus diagrama de objetos

Al observar el proceso de fusión y su notación, se puede ver que el gráfico

de interacción de objetos de Fusion es una versión modificada del diagrama

de objetos de Booch.

Una diferencia es que Fusion cambió la masa amorfa de Booch a una forma

rectangular, que es un icono más amigable para las herramientas de dibujo

basadas en computadora. Una modificación más importante es que Fusion

incluye números en las rutas de mensajes. Los números indican el orden en

que los mensajes son enviados. Esto es básicamente una mejora del sentido
 común. Booch no dijo que dichos números no deberían incluirse en sus

diagramas de objetos, sino que omitió enfatizar su utilidad. En general, la

notación de Fusion proporciona menos detalles en esta comparación. Por

ejemplo, los símbolos de sincronización que se pueden unir a los arcos de

mensaje de Booch se han omitido. Además, los símbolos de visibilidad en la

notación Booch no están incluidos, sino que se extrajeron en un diagrama

separado dentro del proceso Fusion, es decir, el gráfico de visibilidad.

Para facilitar la comprensión de los gráficos de interacción de objetos, la

fusión fomenta el uso de comentarios descriptivos. Booch usa su plantilla de

objeto y plantilla de mensaje en su lugar, lo que le da a los comentarios más

estructura.

3.2.2 Otros gráficos de Fusion versus otros diagramas de Booch

El amplio conjunto de diagramas que ofrece la notación Booch ha sido

ignorado por Fusion. Además del diagrama de objeto, simplemente hay un

diagrama de transición de estado que se abrió paso en el proceso Fusion.

Esto, por supuesto, no es particular del método Booch. Los diagramas de

transición de estados se han usado ampliamente, tanto en el mundo

orientado a objetos como en el interior, por ejemplo en el método OMT de

Rumbaugh. El diagrama de tiempos, el diagrama de módulos y el diagrama

de procesos de Rumb9ij Booch no se han incluido en el método Fusion ni han

sido reemplazados por una notación equivalente. El diagrama de clase

también se ha omitido, pero en su lugar se ha utilizado el modelo de objetos

de OMT [Rumb91] que proporciona una cantidad comparable de detalles.

3.2.3 Texto descriptivo versus plantillas

La mayor parte del texto descriptivo utilizado en el método Booch se coloca

en plantillas separadas y no se incluye en los diagramas. El modelo operativo

de Fusion podría haber sido influenciado por la plantilla de operación de

Booch [Booch911. Sin embargo, la notación de Fusion para la información

textual proporciona muchos menos detalles que Booch. Esto es cierto para el

modelo operativo de Fusion en comparación con la plantilla de operación de

Booch. Además, la descripción de clase de Fusion no es tan detallada como

la plantilla de clase de Booch.

 CONCLUSIONES

- La metodología Fusion propone una metodología compuesta por los mejores

componentes de la metodología Booch, OMT, entre otras. Obteniendo una

metodología capaz de procesar las fases necesarias, para el desarrollo de

software orientado a objetos, de la mejor manera, pero que en algunos

puntos podría se desea acoplar algunas características adicionales a esta

metodología de segunda generación.

 BIBLIOGRAFIA

Diedrichsen, J. (Septiembre de 1995). The Fusion Method. A second generation

object.oriented software devlopment method. Obtenido de
http://uhra.herts.ac.uk/bitstream/handle/2299/5020/CSTR%2520231.pdf?s
equence=1
Hruby, P. (SF). The Fusion Process from an Object-Oriented Perspective. Navision
Software a/, 1.
Ibrahim, S., & Golder, P. (1 de Diciembre de 1994). Universidad UTM. Obtenido de
http://eprints.utm.my/32717/1/SuhaimiIbrahim1994_ObjectOrientedDevelo
pementUsingFusion.pdf