Universidad del Valle de Guatemala

Facultad de Ingeniería
Departamento de Ciencia de la Computación
Objetos y abstracción de datos
Catedrático: Douglas Barrios
Sección: 10

INVESTIGACIÓN FORMAL 1
Metodologías para análisis y desarrollo
orientado a objetos y MDA (Model Driven Architecture)

Martín Guzmán, Carné: 08041

Karen Tojin, Carné: 08091
Héctor Hurtarte, Carné: 08119
Kevin Sánchez, Carné: 08302
 Investigación formal 1
Metodologías para análisis y diseño orientado
a objetos y MDA (Model Driven Architecture)

Por
Martín Guzmán, 08041
Karen Andrea Tojin, 08091
Héctor Antonio Hurtarte, 08119
Kevin Sánchez, 08302
Objetos y abstracción de datos

Universidad del Valle de Guatemala

Facultad de Ingeniería
Guatemala 26 de febrero de 2009

Metodologías para análisis y diseño orientado a objetos y MDA (Model

Driven Architecture) is licensed under Creative commons Attribution-
Noncommercial-Share Alike 3.0 Guatemala License
 Índice

SECCIÓN PÁGINA

1. Resumen 4

2. Introducción 5

3. Desarrollo 6

a. Metodología de Booch 6

b. Metodología de Rumbaugh 10

c. MDA 13

4. Conclusiones 15

5. Bibliografía 16
 1. RESUMEN

Es posible observar que en los últimos años se ha tomado mayor interés e

importancia al modelado en el desarrollo de cualquier tipo de software, debido a
la facilidad que ofrece un buen diseño tanto a la hora de desarrollar como al
hacer la integración y mantenimiento de sistemas de software. Debido a esto, se
hace cada vez más necesario el conocer acerca de los proceso de modelado (y
posterior desarrollo) que proponen distintos autores en la creacion de software
(llamados metodologías). Es a estos temas a los que se orienta la presente
investigación.

La metodología de Booch, desarrollada por Grady Booch en 1994, se orienta

a analizar el modo, documentos y requisitos del sistema en desarrollo. Para esto,
ésta metodología se basa en un desarrollo iterativo e incremental de un
sistemaen el cual se mira el desarrollo del producto como una serie de despachos
que evolucionan hacia el sistema final. Por otro lado, en ésta metodología los
riesgos técnicos son evaluados y priorizados en una fase temprana del ciclo de
vida; y el desarrollo se divide en un Macro-proceso (que engloba la planificación,
agrupación de similitudes, identificación de situaciones relevantes y creación y
validación de un prototio) y un Micro-proceso (que define un conjunto de reglas
que regulan el uso de operaciones, atributos y politicas de manejo de memoria,
errores y funciones).

La metodología OMT (Object Modeling Technique) desarrollada por James

Rumbaugh que es utilizada para el desarrollo de sistemas, posee cuatro etapas:
análisis, diseño del sistema, diseño de objetos e implementación. Estas etapas
están definidas por tres modelos: el modelo de objetos, que es representado por
diagramas de clases; el modelo dinámico, representado por diagramas de estado
y el modelo funcional, representado por diagramas de flujo de datos. Juntos estos
modelos facilitan la transición entre las diferentes etapas desde el análisis,
pasando por el diseño hasta la implementación de un sistema.

MDA (Model Driven Architecture) es un marco o metodología de trabajo que

propone la definición y uso de modelos a diferente nivel de abstracción (Modelo
independiente de la plataforma, modelo específico a la plataforma), así como la
posibilidad de la generación automática de código a partir de modelos definidos y
de las reglas de transformación de dichos modelos. MDA facilita los procesos y
requerimientos de la creación de una aplicación, ayuda a que las empresas a
obtener un mejor manejo de recursos, además separa los negocios de la lógica de
la aplicación gracias a su trabajo con modelos de distinto nivel de abstracción.
Específicamente para el lenguaje de programación JAVA, existen aplicaciones que
permiten la generación de código a partir de los modelos; por ejemplo: Eclipse
Modeling Framework, que es un set de herramientas bajo la ideología Open
Source.

4
 2. INTRODUCCION

En su libro Object-Oriented Modeling and Design, Rumbaugh y otros autores definen

una metodología de ingeniería de software como “un proceso organizado para la
producción de software, utilizando una colección de técnicas predefinidas y convenciones
de notaciones. Una metodología usualmente se presenta como una serie de pasos, con
técnicas y notaciones asociadas con cada paso” 6. En otras palabras, una metodología, a
diferencia de un modelo de ciclo de vida que indica lo que se debe obtener a lo largo del
desarrollo, indica cómo hay que obtener los distintos productos parciales a manera de
obtener luego el producto final.

Las metodologías de desarrollo de software han seguido una evolución que podemos
resumir como sigue: Inicialmente desarrollo convencional (sin metodología), luego un
desarrollo estructurado y finalmente un desarrollo o análisis orientado a objetos13.

El desarrollar software utilizando el paradigma orientado a objetos se ha propuesto

como la tendencia general que deriva de la creciente complejidad de los sistemas
informáticos requeridos actualmente2. Esto debido, probablemente, a que promueve la
identificación y organización de conceptos del dominio de la aplicación y no tanto de su
representación final en un lenguaje de programación.

Tradicionalmente, el soporte metodológico para la construcción de software orientado

a objetos ha venido de la mano de alguno de los tres métodos más extendidos: OMT
(Object Modeling Technique) de James Rumbaugh, el Método de Booch de Grady Booch y
OOSE (Object-Oriented Software Engineering) de Ivar Jacobson.

La presente investigación pretende mostrar una descripción de dos de las

metodologías que soportan de manera central los conceptos de orientación a objetos
mencionadas anteriormente (Booch y OMT). Además, se presenta a seguidamente una
descripción de la Model Driven Architecture (Arquitectura dirigida por modelos), una
metodología considerablemente nueva y actualmente proporcionada y patrocinada por el
OMG (Object Managment Group), que propone independencia entre modelo de
funcionalidad, modelo de plataforma y modelo específico de implementación.

5
 3. CONTENIDO

a. Metodología de Booch (Análisis y Diseño Orientado a Objetos)

La popularidad de las tecnologías de objetos ha generado docenas de métodos de

análisis orientado a objetos desde finales de los 80 y durante los 901. El lenguaje
unificado de modelado o UML (Unified Modeling Language) es el sucesor de una gran
variedad de estos métodos 2. Cada uno de ellos introduce un proceso para el análisis de
un producto o sistema, un conjunto de modelos que evoluciona fuera del proceso, y una
notación que posibilita al ingeniero del software crear cada modelo de una manera
consistente 1.

El UML es un lenguaje de modelado, y no un método. La mayor parte de los

métodos consisten, al menos en principio, en un lenguaje y en un proceso para modelar.
El lenguaje de modelado es la notación de que se valen los métodos para expresar los
diseños2. El proceso es la orientación que nos dan sobre los pasos a seguir para hacer el
diseño. Así pues, en gran medida el lenguaje de modelado es la parte más importante
del método. Según Grady Booch: “Un proceso es un conjunto de pasos ordenados
parcialmente para alcanzar un objetivo” 2.

En la ingeniería del Software, el objetivo es entregar un producto Software que

satisfaga las necesidades del usuario, de forma eficiente y predecible. 2 Según Bjarne
Stroustrup, inventor de C++: “Our civilization runs on software” 3. Debido a esto surge
uno de estos métodos de análisis y diseño orientado a objetos, el llamado método de
Booch que abarca un «microproceso de desarrollo» y un «macroproceso de desarrollo».
Este método fue creado por Grady Booch en 1994, mientras estuvo en Rational Software
(que actualmente forma parte de IBM) 1,2.

El método de Booch define diferentes modelos para describir el sistema. El modelo

de lógica (problema de dominio) está representado en la estructura clase-objeto. En el
diagrama de clase se construye la arquitectura, el modelo estático. El diagrama de objeto
muestra cómo las clases interactúan unas con otras, porque captura algunos momentos
de la vida del sistema y ayuda a describir el comportamiento dinámico 4.

El método de Booch está orientado a analizar el modo, los documentos y requisitos

del sistema en desarrollo. Ha sido desarrollado por Grady Booch, sobre la base de más
de quince años de experiencia en desarrollo con grandes y complejas aplicaciones. Según
Robert C. Martin "La notación Booch es a la vez útil y bien conocida. De todas las
notaciones que he visto, contiene el mayor poder expresivo, porque contiene el mayor
repertorio de íconos y símbolos para la expresión de las relaciones, objetos, tipos de
clase, y sus modificadores" 1,3.

Booch, para desarrollar este método unió conceptos de su anterior trabajo con los
conceptos de Objectory, OMT, y otros métodos, como se muestra en la Figura No.1.

6
 Figura No1. Método de Booch: Desarrollada por otros métodos

La notación juega un papel importante en la metodología de Booch “es el

pegamento que mantiene unido el proceso”. Este método provee una notación bastante
robusta, que crece del análisis en el diseño. Ciertos elementos (como las clases,
asociaciones, agregaciones, herencias) de la notación son introducidos durante el
análisis. Otros elementos de la notación (como categorías de clases, indicadores) son
introducidos durante el diseño y evolución 2,3.

La notación cumple con tres funciones: 1

 Sirve como el idioma para comunicar las decisiones que no son obvias o no pueden
deducirse del código en sí.
 Proporciona semántica suficientemente rica para capturar todas las decisiones
estratégicas y tácticas.
 Ofrece una forma lo suficientemente concreta sobre la razón de utilizar las
herramientas y cómo manipularlas.

Proceso de desarrollo Orientado a Objetos

El método de Booch se basa en el desarrollo iterativo (es decir, repetitivo) e
incremental de un sistema. Esto implica que el método de Booch es un ciclo de vida
iterativo e incremental, en el cual se mira el desarrollo del producto como una serie de
despacho (releases) de arquitectura que evolucionan hacia el sistema final. Los
desarrolladores no asumen todos los requisitos que se conocen al comienzo del ciclo de
vida, de hecho, el cambio se prevee en todas las fases. Se trata de una reducción del
riesgo en el proceso impulsado 1. Los riesgos técnicos son evaluados y priorizados en una
fase temprana del ciclo de vida y se examinan durante el desarrollo de cada despacho de
arquitectura. Los riesgos se adjuntan a cada iteración de manera que se podría mitigar
con éxito los riesgos que se adjuntan. Las emisiones están previstas para garantizar que
los mayores riesgos se abordan en primer lugar. Creando el sistema de esta forma,
expone y mitiga los riesgos del sistema en una fase temprana del ciclo de vida, y la
integración de las "piezas" del sistema es constante. El resultado de este tipo de ciclo de
vida es menor el riesgo junto con una inversión mínima. 1,3
7
Macro-proceso
En el contexto del diseño, el macro-proceso engloba una actividad de planificación
arquitectónica, que agrupa objetos similares en particiones arquitectónicas separadas,
capas de objetos por nivel de abstracción, identifica situaciones relevantes, crea un
prototipo de diseño y valida el prototipo aplicándolo a situaciones de uso. 1

El macro-proceso es un proceso de alto nivel en el que se describen las actividades

de desarrollo del equipo de trabajo. Éste consiste en pasos, los cuales se muestran en la
Figura No.2.

Conceptualización Análisis
Establecer las Modelar un
comportamiento
necesidades básicas
deseado Diseño
Crear una
arquitectura
Mantenimiento Evolución
Gestionar la entrega Evolución de la
posterior evolución aplicación
(refinamientos
sucesivos)

Figura No.2 Macro-proceso: pasos

Micro-proceso
Por otro lado el micro-proceso define un conjunto de “reglas” que regulan el uso de
operaciones y atributos y las políticas del dominio específico para la administración de la
memoria, manejo de errores y otras funciones; desarrolla situaciones que describen la
semántica de las reglas y políticas; crea un prototipo para cada política; instrumenta y
refina el prototipo; y revisa cada política para así “transmitir su visión arquitectónica”. 1

El micro-proceso es un proceso de bajo nivel que representa las actividades

técnicas del equipo de desarrollo. Al igual que el macro-proceso, este consiste en una
serie de pasos, que se muestran en la Figura No.3.
Identificar clases
y objetos

Especificar la interfaz Identificar

e implementación de semántica de
estas clases y las clases y
objetos objetos
Identificar
relaciones entre
clases y objetos

Figura No.3 Micro-proceso: pasos

8
Conceptos y Diagramas de la metodología de Booch
La metodología de Booch se basa en los siguientes tipos de diagramas para
describir las decisiones de análisis y diseño, tácticas y estratégicas, que deben ser
hechas en la creación de un sistema orientado por objetos. 5

 Diagrama de Clases. Consiste en un conjunto de clases y relaciones entre ellas. Los

tipos de relaciones son asociaciones, contenencia, herencia, uso, instanciación y
superclase.
 Especificación de Clases. Es usado para capturar toda la información importante
acerca de una clase en formato texto.
 Diagrama de Categorías. Muestra clases agrupadas lógicamente bajo ciertas
categorías
 Diagramas de transición de estados.
 Diagramas de Objetos. Muestra objetos en el sistema y su relación lógica. Pueden
ser diagramas de escenario, donde se muestra cómo colaboran los objetos en cierta
operación; o diagramas de instancia, que muestra la existencia de los objetos y las
relaciones estructurales entre ellos.
 Diagramas de Tiempo. Aumenta un diagrama de objetos con información acerca de
eventos externos y tiempo de llegada de los mensajes.
 Diagramas de módulos. Muestra la localización de objetos y clases en módulos del
diseño físico de un sistema. Un diagrama de módulos representa parte o la totalidad
de la arquitectura de módulos del sistema.
 Subsistemas. Un subsistema es una agrupación de módulos, útil en modelos de gran
escala.
 Diagramas de procesos. Muestra la localización de los procesos en los distintos
procesadores de un ambiente distribuido. 5

El éxito de un proyecto cubre todos los ciclos de descubrimiento, la invención y la

aplicación que constituyen el eje central para el análisis y diseños de las diferentes fases
de los macro y micro procesos. 1,2

El descubrimiento de un método de análisis y diseño proporciona una comprensión

del comportamiento del sistema. Esta invención da lugar a la creación de una
arquitectura del sistema, durante la etapa de diseño, cuando las principales decisiones
estratégicas y tácticas se realizan.

El análisis y diseño orientado a objetos es utilizado en conjunción con un proceso

iterativo e incremental con el objetivo de proporcionar un buen software de proceso de
ingeniería para los analistas de sistemas, diseñadores y programadores. Se inicia con un
modelo de las necesidades de un punto de vista del usuario. El modelo se madura
durante el diseño, y se cambia a un punto de vista del desarrollador. 1,2,3

9
b. Metodología de Rumbaugh (OMT)

El Dr. James Rumbaugh es uno de los principales metodologistas de orientación a

objetos (OO). Él es el principal desarrollador de la Técnica de Modelación de Objetos
(OMT) y contribuyente importante del Lenguaje Unificado de Modelación (UML).
Rumbaugh trabajó por más de 25 años en el centro de la Investigación y Desarrollo de
General Electric en el Schenectady, Nueva York; en donde fue desarrollada la
metodología OMT con Michael Blaha, Bill Premerlani, Fred Eddy, y Bill Lorensen. 7

James Rumbaugh se unió a Rational Software en 1994, y trabajó allí con Ivar
Jacobson y Grady Booch ("los Tres Amigos") para desarrollar UML. Más tarde fusionaron
sus metodologías de desarrollo de software, OMT, OOSE y Booch en el Proceso Unificado
Racional (RUP). 8

OMT es una de las metodologías de análisis y diseño de desarrollo de software

orientado a objetos más eficiente que existe en la actualidad. Es uno de los precursores
de UML. La gran virtud que aporta esta metodología es su carácter de abierta (no
propietaria), que le permite ser de dominio público y, en consecuencia, sobrevivir con
enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades
actuales y futuras de la ingeniería de software. 11

Esta metodología se extiende del análisis, al diseño, a la implementación. Primero,

se construye un modelo de análisis para abstraer los aspectos esenciales de la aplicación
sin tomar en cuenta, por el momento, la implementación. Esté modelo contiene objetos
presentes en la aplicación, incluyendo una descripción de las propiedades del objeto y su
comportamiento. Luego son tomadas las decisiones del diseño de la aplicación y se
agregan detalles al modelo para optimizar la implementación. Finalmente el modelo de
diseño es implementado en un lenguaje de programación, base de datos o hardware.
Este acercamiento es llamado Técnica de Modelación de Objetos (OMT). 6

OMT se basa en las siguientes etapas: 6

1. Análisis: empezando desde la descripción del problema, el analista construye un
modelo de una situación real mostrando sus propiedades más importantes. El
modelo de análisis es una abstracción concisa y precisa de qué debe hacer el
sistema deseado, no cómo debe ser hecho. Los objetos en este modelo deben ser
objetos de aplicación, conceptos reales, no conceptos computacionales como
estructuras de datos. Estos modelos deben ser analizados y comprendidos por los
expertos en el tema que son programadores. El modelo de análisis no debe
contener detalles de implementación.

2. Diseño del Sistema: el diseñador del sistema toma decisiones de alto nivel de
toda la arquitectura del sistema. Durante el diseño del sistema, el objetivo es
organizar en subsistemas basándose en la estructura del análisis y la arquitectura
propuesta. En esta etapa se deben decidir las características del funcionamiento
para optimizar el sistema, así como escoger una estrategia para atacar el
problema.

3. Diseño de Objetos: el diseñador de objetos construye un modelo de diseño

basándose en el modelo de análisis, pero incluyendo detalles de implementación.
Se agregan los detalles de implementación al modelo de diseño basándose en la

10
 estrategia escogida durante el diseño del sistema. El objetivo del diseño de objetos
son las estructuras de datos y algoritmos necesitados para implementar cada
clase. Las clases de objetos definidas durante el análisis son reforzadas con las
estructuras de datos y algoritmos escogidos para optimizar el funcionamiento del
sistema.

4. Implementación: las clases de objetos y las relaciones entre ellas definidas

durante el diseño de objetos son trasladadas a un lenguaje de programación, a
una base de datos o implementación de hardware. La programación se vuelve un
proceso menor y mecánico del ciclo de desarrollo, ya que las decisiones fueron
tomadas con anterioridad durante el proceso de análisis y diseño.

Los conceptos de la orientación a objetos son aplicados durante el ciclo de vida de

desarrollo del sistema, de análisis, a diseño, a implementación. Las mismas clases son
llevadas durante todo el proceso sin cambiar de notación, solamente agregando detalles
de implementación. Todas las formas de visualizar una clase durante el proceso de
análisis y diseño son correctas, ya que se utilizan para diferentes propósitos; con lo que
denotan diferentes niveles de abstracción. 6

La metodología OMT utiliza tres tipos de modelos para describir un sistema: 6

 Modelo de Objetos: describe la estructura estática de los objetos de un sistema y
sus relaciones. El modelo de objetos contiene diagramas. Un diagrama de objeto
es una gráfica en la que los nodos son clases de objetos y los arcos entre nodos
son las relaciones entre las clases.

 Modelo Dinámico: describe los aspectos del sistema que cambian a través del
tiempo. El modelo dinámico es utilizado para especificar e implementar aspectos
del control del sistema. Utiliza diagramas de estado. Un diagrama de estado es
una gráfica en la que los nodos son estados y los arcos entre nodos son
transiciones entre estados, causadas por eventos.

 Modelo Funcional: describe las trasformaciones de los valores de los datos

dentro de un sistema. El modelo funcional contiene diagramas de flujo de datos.
Un diagrama de flujo de datos es una gráfica en la que los nodos son procesos y
los arcos entre procesos son flujo de datos.

Los modelos de objetos son fundamentales, ya que describen qué cambia en un

sistema, antes de describir cuándo y cómo cambia el sistema. 6

OMT es utilizado por medio de herramientas de diseño e ingeniería de software.

Toda herramienta que implemente los modelos de objetos, dinámicos y funcionales
puede ser utilizada para la realización de la metodología OMT. Algunas de las
herramientas que lo soportan son: 9
 SmartDraw, Software Design Center 10
 Excelerator II Intersolv Inc.
 MetaEdit MetaCASE Consulting YO
 ObjectMarker, Mark V Software
 BOCS, Berard Software Eng.
 ObjectTeam, Candre Technologies, Inc.
 OMTool, Martin Marietta.

11
 Paradigm Plus, Protosoft.
 Software Through Pictures, Interactive Development Enviroment
 System Architect, Popkin Software. 11

12
c. MDA (Model Driven Architecture)

MDA es una manera (metodología, serie de pasos) o un marco de trabajo que

propone desarrollar usos y escribir especificaciones basadas en un modelo de plataforma
independiente de la aplicación (PIM) o especificaciones del negocio, su funcionalidad y su
comportamiento. Una especificación completa de MDA consiste en un modelo basado en
una definitiva plataforma independiente, mas un modelo específico a la plataforma (PSM)
y una serie de definiciones de interfaces, cada una describiendo cómo el modelo base es
implementado en una plataforma intermediaria independiente. Una aplicación completa
MDA funciona como un PIM definitivo, uno o mas PSMs e implementaciones completas en
cada una de las plataformas que la aplicación desarrollada decide soportar12.

La clave del MDA es la importancia que le da a los modelos en el proceso de

desarrollo de software. MDA propone la definición y uso de modelos a diferente nivel de
abstracción, así como la posibilidad de la generación automática de código a partir de los
modelos definidos y de las reglas de transformación entre dichos modelos. De esta
forma, el ciclo de vida del desarrollo de software, basandose en MDA se conforma de los
modelos mencionados en la manera siguiente14:

1. Modelo independiente de la plataforma

2. Modelo específico a la plataforma
3. Código

MDA Sirve para que empresas grandes obtengan muchos beneficios siendo los más
importantes:
 La atención se centra en primer lugar sobre la aplicación de la funcionalidad y el
comportamiento de las empresas, permitiendo que la inversión se concentre en los
aspectos críticos que afectan a los procesos de los negocios.
 La arquitectura basada en MDA está siempre lista para hacer frente a la "próxima
gran cosa" de ayer, de hoy y de mañana. Además hace más fácil la integración de
aplicaciones de middleware y servicios a través de las fronteras.
 El dominio de las instalaciones definidas en el MDA por OMG del control de grupos
de trabajo mucho más amplio facilitará la interoperabilidad de siempre estar
disponible en un dominio preferido de la plataforma, a través de múltiples
plataformas y cuando es necesario.

Surge en 1996 cuando OMG (Object Management Group) decide ampliar su

alcance para incluir el modelado, pero fue hasta 1997 cuando adoptaron la facilidad del
Lenguaje Unificado de Modelación (UML) y el de Facilidades del Meta-Objeto (MOF).
Aunque los UML se pueden ejecutar en cualquier plataforma, la proliferación de software
intermediario ha sugerido que un MOF – basado en una plataforma independiente- sea el
secreto de la estabilidad y del retorno de la inversión.

Algunos de los prouctos y empresas que soportan o utilizan MDA se enlistan a

continuación 12:

13
  Eclipse Modeling Framework (Permite generación de código en JAVA)
 BlueAge (Permite generación de código en .Net)
 Looking Glass Networks
 U.S Government Intelligence
 The Open System Architecture for Condition Based Monitoring (OSA-CBM) Proyect
 CGI
 BankHOST
 E-SoftSys
 Magnet Comunications, Inc.
 Credit Suisse
 Siemens Transportation Systems
 National Cancer Institute
 ABB Research Center
 ff-eCommerce
 Swisslog Software AG
 Unext
 Postgirot Bank AB
 Australian Railways
 National Services Industries
 M1 Global Solutions
 ObjectSecurity and Fraunhofer FOKUS: AD 4 Virtual Airspace Managment System
 Java EE
 Lockheed Martin
 Swedish Parliament
 Deutsche Bank Bauspar AG
 Carter Ground Fueling Ltd.
 Gothaer Versicherungen
 Danzas Group
 Daimler Chrysler
 Cube Model: MDA Meets Open Source
 .Net

MDA es una herramienta para facilitar los procesos y requerimientos de una aplicación,
software, análisis, etc. Ayuda a que las empresas recuperen no solo su inversión sino
también obtengan un mejor manejo de los recursos. Además, es una gran ayuda debido
a que separa los negocios de la lógica de la aplicación además cuenta con varios tipos de
diagrama que ayudan a que sea más eficiente y se pueda desarrollar de una manera más
ordenada12.

14
 4. CONCLUSIONES

• La metodología OMT (Object Modeling Technique) desarrollada por James

Rumbaugh es base para el desarrollo de software orientado a objetos y se
extiende del análisis, al diseño, a la implementación

• La metodología OMT posee cuatro etapas: análisis, diseño del sistema, diseño de
objetos e implementación definidas por tres modelos: el modelo de objetos, el
modelo dinámico y el modelo funcional.

• La principal utilidad de MDA (Model Driven Architecture) es que separa los

negocios de la lógica de la aplicación, además de que cuenta con varios tipos de
diagramas que ayudan a que la aplicación sea más eficiente y se pueda desarrollar
de una manera más ordenada

• El método de Análisis y Diseño Orientado a Objetos, desarrollado por Grady Booch,

se basa en dividir un solo proceso en un microproceso y un macroproceso.

• Grady Booch para desarrollar el método de Análisis y Diseño Orientado a Objetos,

unió conceptos de otras metodologías, incluyendo su trabajo anterior, Objectory,
OMT, entre otros.

• El método de Booch se basa en el desarrollo iterativo de un sistema, en el cual se

mira el producto como una serie de arquitecturas que evolucionan hacia el sistema
el desarrollo final.

15
 5. BIBLIOGRAFÍA

1. Roger S Pressman. et al. 2002. Ingeniería del software. Un enfoque práctico.

Prentice Hall. España. 601 págs.

2. Manuel Antonio Rodríguez Fernández. et al. 2004. Universidad del Valle de México
Sistema de soporte informático aplicado a la estadística a través de Internet. [en
línea]. Sitio web: http://www.uvmnet.edu/investigacion/episteme/numero10-
07/reportes/a_sisVilla.asp

3. Alberto Pacheto. 2005. Instituto Tecnológico de Chihuahua. Facultad de Ingeniería.

Entrevista con Grady Booch. [en línea]. Sitio web:
http://expo.itchihuahua.edu.mx/view.php?f=lp6_19

4. Philipp Schneider. 2007. Korea Advanced Institute of Science and Technology.

Software Enfineering Group. Division of Computer Science. [en línea]. Sitio web:
http://salmosa.kaist.ac.kr/BoochReferenz/overview.html

5. Pablo Figueroa. 2005. University of Alberta, Canada. Object Oriented Design, for
Grady Booch. [en línea]. Sitio web:
http://www.cs.ualberta.ca/~pfiguero/soo/metod/ood.html

6. Rumbaugh, James, et al. 1991. Object-Oriented Modeling and Design. Prentice

Hall. Schenectady, New York. 500 págs.

7. Informit. 2009 James Rumbaugh. Pearson Education. Indianapolis, Indiana. [en

línea]. Sitio web: http://www.informit.com/authors/bio.aspx?a=D3DD9437-09E2-
448F-9EE3-6AAD01752522ç

8. Wikimedia Foundation, Inc. 2009. James Rumbaugh. [en línea]. Sitio web:
http://es.wikipedia.org/wiki/James_Rumbaugh

9. ACCU. 2009. Rumbaugh's OMT - The method behind C++ Designer. [en línea].
Sitio web: http://accu.org/index.php/journals/1337

10. SmartDraw.com. 2009. HOW TO DRAW RUMBAUGH (OMT) DIAGRAMS. [en línea].
Sitio web: http://www.smartdraw.com/tutorials/software/omt/tutorial_01.htm

11. Chávez Gaona, Víctor Manuel; Olivares Rojas, Juan Carlos. 2007. Metodología OMT
(Rumbaugh). Morelia, Michoacán. 35 págs. [en línea]. Sitio web:
http://www.willydev.net/DESCARGAS/PREV/OMT2.PDF

12. Object Management Group. MDA. [en línea]. Sitio web:

http://www.omg.org/mda/faq_mda.htm

13. Fernández-Medina, E. Escuela Superior de Informática de Ciudad Real.

Metodologías de desarrollo de software. [en línea]. Sitio web:
http://static.scribd.com/docs/dsmodb48dz9x5.swf?INITIAL_VIEW=width

16
14. CiberAula. 2006. Introducción a MDA. [en línea]. Sitio web:
http://java.ciberaula.com/articulo/introduccion_mda/

17