Facultad de Ingeniería
Guatemala
2009
1
Índice
I. MDA ………………………………………………..3
A. Orígenes
E. Conclusiones
B. ¿Cómo funciona?
D. Conclusiones
C. Conclusiones
2
I. MDA (MODEL DRIVEN ARCHITECTURE)
A. Orígenes
En 1996 la empresa OMG (Object Management Group) expandió su visión a incluir
la modelación y en 1997 adopto el Lenguaje Unificado de Modelación (UML) y
Facilidad de Meta-Objeto (MOF). A pesar de que los modelos UML se pueden
implementar en cualquier plataforma, pero sugirieron que la modelación basada en
MOF es la clave de la estabilidad del software. El MDA une los estándares de
modelación de la empresa OMG con cada tecnología de middleware, para integrar
lo que se creo, con lo que se está creando, y con lo que se va a crear. (OMG, 2007)
3
plataforma MDA que es implementada por herramientas, facilitando el trabajo de
tener soporte a nuevas o diferentes tecnologías (OMG, 2007).
E. Conclusiones
1. El MDA es una nueva forma de desarrollo de software que aun esta siendo
desarrollada, el cual facilita la creación de aplicaciones subiendo los niveles
de abstracción.
2. En la actualidad ya se encuentran disponibles distintas herramientas que
tienen implementado generadores de código basados en MDA para distintos
lenguajes, lo cual lo requerimientos que se necesitan son modelos y
diagramas, principalmente UML.
4
II. LA METODOLOGÍA DE BOOCH
A. Aspectos Relevantes
El método de Booch difiere con otras metodologías orientadas a objetos porque se
centra en el desarrollo de 4 modelos fundamentales de un sistema. Estos modelos son
(Calpoly, 1997):
1. Modelo lógico
2. Modelo físico
3. Modelo estático
4. Modelo dinámico
B. ¿Cómo funciona?
En sus primeros textos de Ingeniería de Software (1987), Booch sugiere que se sigan
los siguientes pasos para analizar un sistema en preparación para diseñar una
solución en una manera orientada a objetos (Biggs, 1999):
1. Definir el problema
2. Crear una estrategia informal para la realización del software
3. Formalizar la estrategia
La notación para los diagramas utiliza diferentes tipos de flechas para dar
determinada información. Se sugiere que se use una notación básica en las primeras
etapas del diseño, y luego llenar los detalles. También existe una forma textual para
cada notación.
Este método provee una notación muy robusta, que crece del análisis al diseño.
Ciertos elementos de la notación se introducen durante el análisis, mientras que otros
elementos se introducen durante el diseño e implementación (Martin, 2002).
La notación tiene tres papeles importantes:
1. Sirve de lenguaje para comunicar decisiones que no son obvias o no se
reconocen fácilmente del código.
2. Provee semántica lo suficientemente completa para capturar todas las
decisiones importantes estratégicas y tácticas.
3. Ofrece una forma suficientemente concreta para la comprensión humana y
para la manipulación en herramientas.
D. Conclusiones
1. El método para diseño orientado a objetos nunca se ha desarrollado en un
proceso, pero en una colección de técnicas. Ideas forales que se pueden
utilizar en el desarrollo de sistemas.
2. Este método se preocupa más en el análisis y diseño que en la
implementación y evaluación.
6
III. METODOLOGÍA DE RUMBAUGH (OMT)
7
9. Definición de eventos y desarrollo de una traza de eventos para cada
escenario.
10. Construcción de un diagrama de flujos de datos.
11. Desarrollo de un diagrama de estado.
12. Revisión del comportamiento para comprobar consistencia y completitud.
13. Desarrollo de un modelo funcional.
14. Identificación de entradas y salidas.
15. Uso de diagramas de flujos de datos para representar transformaciones del
flujo.
16. Desarrollo de especificaciones de proceso para cada función.
17. Especificación de criterios de restricciones y optimización.
(U. Guadalajara))
(Romero)
C. Conclusión
Los sistemas construidos hoy en día son más complejos que los sistemas construidos en
los años 70s y 80s. La complejidad funcional es menos preocupante de como lo era
antes, lo que ahora ha tomado una prioridad alta es el modelar la comprensión del
dominio del problema y las responsabilidades del sistema, por lo que estas
metodologías se han convertido en una herramienta necesaria y de mucha
importancia para el desarrollo de software.
8
IV. BIBLIOGRAFÍA