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
