Metodologías Rumbaugh,

Shlaer-Mellor y MDA
Objetos y Abstracción de Datos
David Coronado - Julio Chicas

09

1
 Model Driven Architecture
Metodología de Rumbaugh
Metodología Shlaer-Mellor

Por Julio R. Chicas Sett

David E. Coronado R.
Objetos y Abstracción de Datos

Universidad del Valle de Guatemala

Facultad de Ingeniería
26 de febrero de 2009

2
 Índice
Capítulos Página

1. Caratula.……………………………………………………………………………………….1
2. Caratula con Licencia……………………………………………………………………..…2
3. Abstract……………………………………………………………………………………..…3
4. Creative Commons……………………………………………………………………..……4
5. Introduccion…………………………………………………………………………..……… 6
6. MDA…………………………………………………………………………..……………..…7
a. Historia……………………………………………………………………………..…………..…... 7
b. Definición………………………………………………………………………………...…..…..... 7
c. Funcionamiento…………………………………………………………………………….…..… 7
d. ¿Para qué sirve?.................................................................................................................. 8
e. Diagrama………………………………………………………………………..…………………..9
7. Metodología de Rumbaugh………………………………………………………….…....10
a. Modelo de Objetos…………………………………………………………….…………………..11
b. Modelo Dinámico……………………………………………………………………………….....12
c. Modelo Funcional…………………………………………………………………………………13
d. Fase de Análisis…………………………………………………………………….…………….13
e. Fase de Diseño de Sistema…………………………….…………………….…………………14
f. Fase de Diseño de Objetos……………………….…………………………..…………………15
g. Ventajas……………………………………………………………………………………………16
h. Desventajas………………………………………………………………………………….……17
i. Aplicaciones…………………………………………………………………………….…………18
8. Metodología Shlaer y Mellor……………………………………………….………….…19
a. Historia…………………………………………………………………………………………….19
b. ¿Qué es? …………………………………………………………………………………………20
c. ¿Cómo funciona? ……………………………………………………………………….……….21
d. ¿Para que funciona? …………………………………………………………………………….22
9. Conclusiones…………………………..……………………………………………….….23
10. Bibliografía………………………………………………………………………….......... 24

3
 ABSTRACT
Las metodología Shlaer & Mellor, MDA y Rumbaugh son una de las metodologías mas antiguas, estas
metodología al principio no podía ser considerada para objetos dado que no tenia referencia alguna a la
herencia, sin embargo en su segunda publicación ya poseía una notación para la herencia de objetos. Esta
metodología tiene su mayor implicación en el desarrollo de software en tiempo real, es decir que en el
instante en que se está creando el diagrama se puede obtener el código que es realmente su fin. Este tipo de
metodología es una de las maneras mas antiguas de representar software de manera grafica. La metodología
básicamente consiste en : Particionar el sistema en dominios,Analizar el dominio de aplicación usando
modelos de objetos de información, modelos de estados, y especificaciones de acciones (diagramas de flujo
de acciones – un diagrama no-UML),Confirme el análisis mediante verificación estática y verificación
dinámica (simulación),Extraer los requerimientos del dominio de servicio, Analizar el dominio de servicio,
Especificar los componentes del dominio arquitectural, Construir los componentes arquitecturales, Traducir
los modelos para cada dominio usando los componentes arquitecturales. Un dominio lo podemos definir
como un area de asunto, es decir que en un dominio podemos unir a los componentes con características
similares. Esta metodología es bastante complicada por lo que la utilización de esta es bastante larga sin
embargo tiene bastante herramientas utiles.

4
5
 1. Introducción

El día a día nos presenta una serie de retos para superar, es por eso que muchas veces nos vemos en la
necesidad de encontrar salidas fáciles, eficientes, y correctas para poder continuar en el trabajo diario. Para esto
es necesario buscar metodologías que hagan que un problema pueda ser visto de una manera mas sencilla y
objetiva para de esta manera encontrar soluciones eficientes para el problema. De una manera similar funciona el
área de la programación, la cual tiene que verse en la necesidad de buscar metodologías que permita solucionar
problemas de programación de una mejor manera.

Es para esto que se creo el UML que es un sistema de modelado universal con el cual cualquier persona que
lo vea, con tener un poco de conocimiento sobre el tema, podrá entender que es lo que sucede, y podrá
interpretar el fin del programa. Sin embargo existen muchos tipos de metodologías para poder manejar el UML y
una de ellas es la que será estudiada en las paginas subsiguientes llamada metodología Shlaer & Mellor, MDA y
Rumbaugh, la cual tiene ciertos aspectos muy interesantes los cuales tiene relevancia, por lo que es importante
estudiarlos de manera detallada.

6
 2. Model Driven Architecture
a) Historia:

El OMG estandarizó el ORB (Object Request Broker) y un conjunto de servicios de objeto. Este trabajo fue guiado
por OMA (Object Management Architecture), la cual provee un framework para sistemas distribuidos y por
Common ORB Architecture (CORBA), una parte de ese framework. En el año 2001, el OMG estableció el
framework MDA como arquitectura para el desarrollo de aplicaciones. MDA representa un nuevo paradigma de
desarrollo de software en el que los modelos guían todo el proceso de desarrollo. Este nuevo paradigma se ha
denominado Ingeniería de modelos o Desarrollo basado en modelos. A lo largo de la historia del desarrollo de
software, se ha evolucionado desde los lenguajes ensambladores de los años 50 hasta los lenguajes orientados a
objetos y de cuarta generación (4GLs) de nuestros días. La ingeniería de modelos es considerada como un nuevo
paso en el camino hacia lenguajes de programación más expresivos y hacia una mayor automatización.

b) Definición:

MDA es una especificación detallada por el OMG (Object Management Group) y que integra a su vez diferentes
especificaciones y estándares ya definidos por esta misma organización. El framework MDA nos permite el
desarrollo de aplicaciones empresariales potencialmente en cualquier plataforma existente, abierta o propietaria
(servicios Web, J2EE, CORBA,.Net u otras). Para lograrlo MDA plantea el siguiente proceso de desarrollo: De los
requerimientos se obtiene un Modelo Independiente de la Plataforma (PIM), luego este modelo se “transforma”
en uno a más Modelos Específicos de la Plataforma (PSM), y finalmente cada PSM se “transforma” en código.

c) Funcionamiento:

Para entender MDA y sus características, así como su funcionamiento y su aplicación al proceso de desarrollo, se
mencionarán algunos conceptos básicos de MDA entre los cuales están:

• Sistema
Los conceptos de MDA se definen centrados en la existencia o planteamiento de un sistema, que
puede contener un simple sistema informático, o combinaciones de componentes en diferentes
sistemas informáticos, o diferentes sistemas en diferentes organizaciones.

• Modelo
Un modelo de un sistema es una descripción o una especificación de ese sistema y su entorno para
desempeñar un determinado objetivo. Los modelos se presentan normalmente como una
combinación de texto y dibujos. El texto se puede presentar en lenguaje de modelado, o en lenguaje
natural.

• Dirigido por modelos

MDA es dirigido por modelos porque usa los modelos para dirigir el ámbito del desarrollo, el diseño,
la construcción, el despliegue (deployment), la operación, el mantenimiento y la modificación de los
sistemas.

• Arquitectura

7
 La arquitectura de un sistema es la especificación de las partes del mismo, las conexiones entre
ellos, y las normas de interacción entre las partes del sistema haciendo uso de las conexiones
especificadas. MDA determina los tipos de modelos que deben ser usados, como preparar dichos
modelos y las relaciones que existen entre los diferentes modelos.

• Punto de vista
Un punto de vista es una abstracción que hace uso de un conjunto de conceptos de arquitectura y
reglas estructurales para centrarse en aspectos particulares del sistema, obteniendo un modelo
simplificado.

• Vista
Representación del sistema desde un determinado punto de vista.

• Plataforma
Una plataforma es un conjunto de subsistemas y tecnologías que aportan un conjunto coherente de
funcionalidades a través de interfaces y determinados patrones de uso, que cualquier aplicación que
se construya para esa plataforma puede usar sin preocuparse por los detalles de la implementación o
como se lleva a cabo la misma dentro de la plataforma.

• Aplicación
En MDA se define el término aplicación como una funcionalidad que tiene que ser desarrollada. Por
tanto podemos definir un sistema en términos de la implementación de una o más aplicaciones,
soportadas por una o más plataformas.

El modelo de origen es el CIM, con el que se modelan los requisitos del sistema, describiendo la situación en que
será usado el sistema y que aplicaciones se espera que el sistema lleve a cabo, sirviendo de ayuda para
entender el problema como una base de vocabulario para usar en los demás modelos. Los requisitos recogidos
en el CIM han de ser trazables a lo largo de los modelos PIM y PSM que los implementan. El CIM puede consistir
en un par de modelos UML que muestren tanto la distribución de los procesos (ODP, Open Distributed
Processing) como la información a tratar. También puede contener algunos modelos UML adicionales que
especifiquen en más detalle los anteriores. A partir del CIM, se construye un PIM, que muestra una descripción
del sistema, sin hacer referencia a ningún detalle de la plataforma. Debe presentar especificaciones desde el
punto de vista de la empresa, información y ODP. Un PIM se puede ajustar a un determinado estilo de
arquitectura, o a varios. Después de la elaboración del PIM, el arquitecto debe escoger una plataforma (o varias)
que satisfagan los requisitos de calidad.

d) ¿Para qué sirve MDA?

La funcionalidad del sistema se define como un modelo independiente de la plataforma (PIM), totalmente
separado y aislado de la tecnología de implementación, usando un adecuado Lenguaje Específico del Dominio y
luego traducido (mediante el uso de herramientas CASE automáticas) a uno o más modelos específicos de
plataforma (PSM) para su implementación o incluso lenguajes de propósito general, como Java, C#, Python, etc.

8
 e) Diagrama:

El método MDA para el desarrollo de software describe tres vistas:

• Computation Independent Model (CIM) para especificación de requerimientos

• Platform Independent Model (PIM) para diseño del sistema independiente de la tecnología

• Platform Specific Model (PSM) transformación del PIM para una plataforma específica o código
directamente

9
 3. Metodología de Rumbaugh:
La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991,
mientras James dirigía un equipo de investigación de los laboratorios General Electric. (Chávez y Olivares. 1999)

Es una metodología de análisis y diseño, orientada a objetos. Se utiliza para producir software de manera
organizada. Se basa en etapas de desarrollo y una colección de técnicas coordinadas y convenciones de
notación predefinidas. (Fachal, 2005)

Las fases que conforman a la metodología OMT son:

• Análisis: se construye todo lo relevante al problema, mostrando las propiedades más importantes. Se
precisa en lo que el sistema debe hacer y no en la forma en la que se hará. Los elementos del modelo
deben ser todos conceptos pertenecientes al ámbito de aplicación.
• Diseño del sistema: Se diseña la arquitectura del sistema y se organiza todo en subsistemas,
basándose en la estructura del análisis. En esta fase se selecciona la estrategia para la resolución del
problema planteado.
• Diseño de objetos: Este diseño se basa en el análisis y se centra en las estructuras de datos y
algoritmos que son necesarios para la implementación de cada clase.
• Implementación: traducción concreta de las clases de objetos y las relaciones desarrolladas durante el
análisis de objetos. Es importante que el sistema cuente los principios de la ingeniería de software, tales
como que el sistema implementado sea flexible y extensible.

La metodología suele presentarse como una serie de pasos organizados en un ciclo de vida que consta de varias
fases de desarrollo. (Chávez y Olivares. 1999)

La metodología OMT está basada en el desarrollo de un modelo del sistema separado en tres aspectos:

 un modelo de objetos
 un modelo dinámico
 un modelo funcional

a) Modelo de Objetos

Describe la estructura estática de los objetos del sistema, es decir, su identidad, atributos, operaciones, así como
también las relaciones con otros objetos. La definición clara de las entidades que intervienen en el sistema es un
paso fundamental para poder definir que transformaciones ocurren en ellas y cuando se producen estas
transformaciones. Este modelo es representado gráficamente mediante diagramas de objetos. Los diagramas de
objetos permiten representar, de manera grafica, las clases, objetos, y sus relaciones. Existen dos tipos de
diagramas para este modelo: los diagramas de clases y los diagramas de casos concretos. El primero ilustra y
describe las clases que se encuentran en el sistema y su relación estática. Los diagramas de casos concretos
describen la manera en que los objetos del sistema se relacionan. (Fachal, 2005)

Para entender mejor el concepto del modelo, definiremos los conceptos básicos necesarios.

• Objetos: se define como un concepto o abstracción con propiedades definidas.

10
 • Clase: describe un grupo de objetos con propiedades similares y relaciones comunes con otros.
• Atributos: Los objetos que pertenecen a una clase poseen estas características.

Otro concepto fundamental en el modelado de objetos es el de las relaciones entre las clases del sistema, las
cuales determinan el comportamiento de este y definen la forma en que los objetos se comunican entre sí. Las
relaciones tienen una serie de características:
• Se identifican a través de enlaces, es decir, conexiones físicas entre objetos.
• Tienen multiplicidad, término que indica el número de casos concretos de una clase que puede
relacionarse con otro caso.
• Los enlaces, así como los objetos, pueden tener atributos los cuales nos indican las propiedades de la
asociación.
• Agregación: es de tipo “es parte de”, y se establece en los objetos compuestos (objetos que contienen
otros objetos). (Chávez y Olivares. 1999)

En el modelo de objetos, se trata con uno de los elementos más importantes de la orientación a objetos, la
herencia. La herencia está definida como la cualidad que permite que los objetos hereden las características y las
operaciones dentro de una estructura jerárquica. Esto permite y facilita la reutilización de las clases y del código
implementado. (Fachal, 2005)

Existen una serie de reglas para implementar la herencia:

• Las operaciones que no modifican los valores de atributos (consulta), se heredan por todas las
subclases.
• Las operaciones que si modifican los valores de atributos (actualización), se heredan por todas las
subclases y se añaden las nuevas operaciones para las que añadan atributos.
• Las operaciones de actualización que se realizan sobre atributos que tengan algún tipo de restricción o
asociación, se bloquean para nuevas subclases.
• Todos los métodos concretos de una operación deben de tener el mismo protocolo.

Todos los elementos descritos se pueden agrupar para formar el modelo completo, así, las clases, las
asociaciones y las generalizaciones forman lo que se denomina modulo, y varios módulos forman el modelo de
objetos. (Chávez y Olivares. 1999)

A continuación se presenta una serie de pasos para la construcción de un modelo de objetos.

• Identificar las clases de objetos

• Listar las descripciones de las clases tales como atributos y asociaciones.
• Agregar las asociaciones entre las clases.
• Agregar atributos a los objetos.
• Organizar las clases de objetos mediante la herencia.
• Probar los escenarios y las diferentes rutas de acceso.
• Agrupar las clases en módulos.

11
 Diagrama 1: Ejemplo de Modelo de Objetos

b) Modelo Dinámico:

Describe la conducta y reacción de los objetos del sistema frente a diferentes sucesos y las interacciones entre
ellos. También describe los aspectos de un sistema que tratar de la temporización y secuencia de operaciones,
secuencia y la organización de sucesos y estados. Como ya se menciono, los conceptos más importantes del
modelado dinámico son los sucesos y los estados. Los sucesos representan estímulos individuales provenientes
de un objeto y que llega a otro objeto, y los estados representan los valores de los objetos. Los valores de los
atributos de unos objetos son los que determinan su estado. A lo largo del tiempo, los objetos del sistema
interactúan con otros, dando lugar a una serie de cambios en sus estados. Este modelo es representado
gráficamente mediante una variedad de diagramas de estado. (Fachal, 2005)

• Suceso. Un suceso, o evento, es algo que transcurre durante un período de tiempo. Un suceso puede
preceder o seguir lógicamente a otro, o bien los dos sucesos pueden no estar relacionados. Se dice que
dos sucesos que no tienen relación causal son concurrentes; no tienen efecto entre sí. Un suceso es una
transmisión de información de dirección única entre un objeto y otro. Todo suceso aporta información de
un objeto a otro. Los valores de datos aportados por un suceso son sus atributos.
• Escenarios y seguimiento de sucesos. Un escenario es una secuencia de sucesos que se produce
durante una ejecución concreta de un sistema. El ámbito de un escenario es variable; puede incluir
todos los sucesos del sistema, o que sean generados por ellos. Todo suceso transmite información de un
objeto a otro.
• Estados. Un estado es una abstracción de los valores de los atributos y de los enlaces de un objeto. Los

12
 conjuntos de valores se agrupan dentro del estado de acuerdo con aquellas propiedades que afecten al
comportamiento del objeto. Un estado especifica la respuesta del objeto a los sucesos entrantes. La
respuesta a un suceso recibido por un objeto puede variar cuantitativamente, dependiendo de los valores
exactos de sus atributos, pero cualitativamente la respuesta es la misma para todos los valores dentro del
mismo estado, y puede ser distinta para valores de distintos estados. La respuesta de un objeto a un
suceso puede incluir una acción o un cambio de estado por parte del objeto.
• Escenarios y seguimiento de sucesos. Un escenario es una secuencia de sucesos que se produce
durante una ejecución concreta de un sistema. El ámbito de un escenario es variable; puede incluir
todos los sucesos del sistema, o que sean generados por ellos.

Condiciones
Una condición es una función Booleana lógica que tiene a objetos como valores. Las condiciones se pueden
utilizar como protecciones en las transiciones. Una transición con protección se dispara cuando se produce su
suceso, pero sólo si la condición de protección es verdadera. (Chávez y Olivares. 1999)

Operaciones
Los diagramas de estados tendrían muy poca utilidad si solamente describiesen tramas de sucesos. Una
descripción de un objeto debe especificar lo que hace el objeto como respuesta a los sucesos.
Una actividad es una operación cuya realización requiere un cierto tiempo. Toda actividad está asociada a un
estado. Entre las actividades se cuentan las operaciones continuas, tales como mostrar una imagen en una
pantalla, así como las operaciones secuenciales que terminan por sí mismas después de un cierto intervalo de
tiempo. Un estado puede controlar una actividad continua o una actividad secuencial que va avanzando hasta
que termina o hasta que se produce un suceso que la hace finalizar prematuramente. La anotación "hacer: X"
indica que la actividad secuencial X comienza al entrar en ese estado, y se detiene cuando ha finalizado. Si un
suceso da lugar a una transición que sale de ese estado antes de que haya finalizado la actividad, entonces, la
actividad finaliza de forma prematura. (Chávez y Olivares. 1999)
Una acción es una operación instantánea que va asociada a un suceso. Una acción representa a una operación
cuya duración es insignificante en comparación con la resolución del diagrama de estados. Realmente, no hay
operaciones que sean instantáneas, pero se modelan de esta manera aquellas operaciones de las que no nos
importa su estructura interna. (Chávez y Olivares. 1999)
• Las acciones también pueden representar operaciones internas de control, tales como dar valores a
atributos o generar otros sucesos. Estas acciones no tienen contrapartidas en el mundo real, sino que
son mecanismos para estructurar el control dentro de una implementación y un único estado de todas las
combinaciones de valores de atributos y de enlaces que tienen una misma respuesta a los sucesos. Por
supuesto, todo atributo tiene algún efecto sobre el comportamiento, o no tendría sentido, pero es
frecuente que algunos atributos no afecten a la trama de control, y que se pueda pensar en ellos como
valores de parámetros dentro de un estado. Tanto los sucesos como los estados dependen del nivel de
abstracción utilizado. Los estados se pueden caracterizar de diferentes maneras, pero normalmente cada
estado tiene un nombre y una descripción en la que se indica en la situación en la que se encuentra el
sistema.

13
Diagrama 2: Ejemplo de Modelo Dinámico

14
c) Modelo Funcional

15
El modelo funcional describe los cálculos existentes dentro del sistema siendo la tercera parte del modelado.
Dentro del modelado del sistema, el modelo funcional especifica lo que sucede, el modelo dinámico cuándo
sucede, y el modelo de objetos especifica a qué le sucede.
El modelo funcional muestra la forma en que se derivan los valores producidos en un cálculo a partir de los
valores introducidos, sin tener en cuenta el orden en el cual se calculan los valores. Consta de múltiples
diagramas de flujo de datos, que muestran el flujo de valores desde las entradas externas, a través de las
operaciones y almacenes internos de datos hasta las salidas externas. También incluyen restricciones entre
valores dentro del modelo de objetos. Los diagramas de flujo de datos no muestran el control ni tampoco
información acerca de la estructura de los objetos; todo esto pertenece a los modelos dinámico y de objetos.
(Fachal, 2005)

Construcción de un modelo funcional:

• Identificar valores de entrada y salida.
• Usar diagramas de flujo de datos para mostrar dependencias funcionales.
• Describir las funciones.
• Identificar restricciones.
• Especificar criterios de optimización.

d) Fase de Análisis.
El objetivo del análisis es desarrollar un modelo del funcionamiento del sistema. El modelo se expresa en
términos de objetos y relaciones, el control dinámico de flujo y las transformaciones funcionales. El proceso de
capturar los requerimientos y consultar con el solicitante debe ser continuo a través del análisis. A saber:
• Contar con una descripción inicial del problema (enunciado del problema).
• Construir un modelo de objetos.
• Desarrollar un modelo dinámico y construir un modelo funcional.
• Verificar, iterar y refinar los tres modelos.

e) Fase de Diseño de sistemas.

Durante el diseño de sistemas, se selecciona la estructura de alto nivel del sistema. Existen varias arquitecturas
canónicas que pueden servir como un punto de inicio adecuado. El paradigma orientado a objetos no introduce
vistas especiales en el diseño del sistema, pero se incluye para tener una cobertura completa del proceso de
desarrollo de software. Los pasos son:
• Organizar el sistema en subsistemas.
• Identificar la concurrencia inherente al problema.
• Asignar subsistemas a procesadores y tareas.
• Escoger la estrategia básica para implantar los almacenamientos de datos en términos de
estructuras de datos, archivos y bases de datos.
• Identificar recursos globales y determinar los mecanismos para controlar su acceso.
• Seleccionar un esquema para implantar el control del software.

f) Fase de Diseño de objetos.

Durante el diseño de objetos se elabora el modelo de análisis y se proporciona una base detallada para la
implantación. Se toman las decisiones necesarias para realizar un sistema sin entrar en los detalles particulares
de un lenguaje o base de datos particular. El diseño de objetos inicia un corrimiento en el enfoque de la
orientación del mundo real del modelo de análisis hacia la orientación en la computadora requerida para una
implantación práctica. Los pasos son:

16
 i. Obtener las operaciones para el modelo de objetos a partir de los otros modelos:
a. Encontrar una operación para cada proceso en el modelo funcional.
b. Definir una operación para cada evento en el modelo dinámico, dependiendo de la
implantación del control.
ii. Diseñar los algoritmos para implantar las operaciones:
a. Escoger los algoritmos que minimicen el costo de implementación de las
operaciones.
b. Seleccionar las estructuras de datos apropiadas para los algoritmos.
c. Definir clases internas y operaciones nuevas según sea necesario.
d. Asignar las responsabilidades para las operaciones que no están asociadas
claramente con una sola clase.
iii. Optimizar las rutas de acceso a los datos:
a. Agregar asociaciones redundantes para minimizar los costos de acceso y maximizar
la conveniencia.
b. Reacomodar los cálculos para una mayor eficiencia.
c. Guardar los valores derivados para evitar recalcular expresiones complicadas.
iv. Implantar el control del software introduciendo el esquema seleccionado durante el diseño de
sistemas.
v. Ajustar la estructura de clases para incrementar la herencia:
a. Reacomodar y ajustar las clases y las operaciones para incrementar la herencia.
b. Abstraer el comportamiento común de los grupos de clases.
c. Usar delegación para compartir comportamiento donde la herencia sea
semánticamente inválida.
vi. Diseñar la implantación de las asociaciones:
a. Analizar las travesías de las asociaciones.
b. Implantar cada asociación como un objeto distinto o agregando atributos objeto-valor
a una o ambas clases en la asociación.
vii. Determinar la representación de los atributos de los objetos.
viii. Empaquetar las clases y las asociaciones en módulos. (Chávez y Olivares. 1999)

g) Ventajas
• Proporciona una serie de pasos perfectamente definidos al desarrollador.
• Tratamiento especial de la herencia.
• Facilita el mantenimiento dada la gran cantidad de información que se genera en el análisis.
• Es fuerte en el análisis

h) Desventajas
• Hay pocos métodos para encontrar inconsistencias en los modelos.
• Interacción de objetos no soportada explícitamente en ninguna herramienta gráfica.
• Al ser un análisis iterativo es difícil de saber cuándo comenzar con el diseño.
• Es débil en el diseño

i) Aplicaciones
Esta Tecnología puede ser aplicada en varios aspectos de implementación incluyendo:
• Archivos.
• Base de datos relacionales.
• Base de datos orientados a objetos.
• Estructura de datos.

17
 • Multimedia.
• Interactivas.
• Web.
• Cliente/servidor.
• Distribuidas.

Y en general, en prácticamente cualquier actividad de ingeniería que requiera hacer un análisis de un problema
para poder resolver un problema. (Chávez y Olivares. 1999)

Herramientas CASE que soportan OMT:

• Excelerator II Intersolv Inc.

• MetaEdit MetaCASE Consulting YO.
• ObjectMarker, Mark V Software
• BOCS, Berard Software Eng.
• ObjectTeam, Candre Technologies, Inc.
• OMTool, Martin Marietta.
• Paradigm Plus, Protosoft.
• Software Through Pictures, Interactive Development Enviroment
• System Architect, Popkin Software.

Diagrama 3: Ejemplo Modelo Funcional

18
 4. Metodología Shlaer-Mellor

a) Historia
Cuando el análisis de Shlaer-Mellor OO apareció en 1988, representó uno de los ejemplos más tempranos de la
metodología OO y ha evolucionado positivamente desde entonces. Originalmente era una extensión del
modelado de datos basada en objetos, la metodología de Shlaer-Mellor inicia con un modelo de información que
describen los objetos, los atributos, y las relaciones. (Note que esto es más bien un modelo de datos que un
modelo de objetos.) Después, un modelo de estados documenta los estados de los objetos y las transiciones
entre ellos. Finalmente, un diagrama de flujo de datos muestra el modelo de proceso.

Esta metodología parece ser influenciada fuertemente por diseño relacional, pero no la he visto usada en el
desarrollo cliente/servidor. Esto no significa que no es útil para tal trabajo, pero las aplicaciones ocasionalmente
mencionadas como ejemplos de su uso parecen estar en las áreas de control en tiempo real o de proceso. Esto
puede tener que ver con el hecho de que una versión anterior, el enfoque de Ward/Mellor, está ampliamente
utilizada en el mundo de tiempo real. (Grahan, 1996)

b) ¿Qué es?

Uno de los primeros ejemplos del análisis orientado a objetos se debió a Shlaer y Mellor. Pero este método no
podía ser considerado realmente como orientado a objetos por varias razones, entre las cuales se incluyen la
completa ausencia de las ideas de herencia. Tal como estaba descrito en el libro de su propia autoría, era poco
más que una extensión basada en objetos dl modelado de datos. Sin embargo, el libro posterior de Shlaer y
Mellor (1991) presentaba la herencia (subtipos de entidades) y la idea de que se podía descubrir los métodos
modelando los ciclos vitales de entidades con STD. Aun con esto es sospechoso su punto de vista acerca de la
identidad de objetos, sin embargo, porque consideran a los identificadores como conjuntos de atributos o claves.
Además de las reglas de normalización (de atribución), se aplican a los objetos como si estos fuesen poco más
que tablas racionales. (Grahan, 1996)
El método Shlaer-Mellor está basado en un conjunto integrado de modelos que pueden ser ejecutados para
verificación, y en un enfoque innovador de diseño que produce un diseño de sistema a través de la traducción de
los modelos de análisis. El método está construido sobre un conjunto de reglas bien definidas para la
construcción de los diagramas y la traducción de dichos diagramas del análisis al diseño y finalmente a la
implementación. De hecho, la generación más reciente de herramientas de modelado como BridgePoint, han
creado la habilidad de generado 100 por ciento del código. (Grahan, 1996)

c) ¿Cómo funciona?

Este logro está por encima de la mayoría de las otras metodologías que generan la declaración de operación pero
que no pueden proporcionar el código de los métodos ni la implementación de la operación.
El riguroso conjunto de reglas también soporta verificación mediante simulación. Los diagramas pueden ser
ejecutados para comprobar si trabajan adecuadamente.
El dominio es uno de los conceptos primarios de Shlaer-Mellor. Un dominio es un área de asunto. (Universidad
Autonoma de Chihuahua, 2006) (SPIRES-HEP, 1996)
Shlaer-Mellor define tres tipos básicos de dominios: El dominio de aplicación, el dominio de servicio, y el dominio
arquitectural. Cada dominio tiene sus propios tipos de requerimientos únicos y diagramas. Ellos representan
juntos la especificación completa del sistema. (SPIRES-HEP, 1996)

19
El proceso Shlaer-Mellor se descompone en los siguientes pasos:

1. Particionar el sistema en dominios.

2. Analizar el dominio de aplicación usando modelos de objetos de información, modelos de
estados, y especificaciones de acciones (diagramas de flujo de acciones – un diagrama no-UML).
3. Confirme el análisis mediante verificación estática y verificación dinámica (simulación).
4. Extraer los requerimientos del dominio de servicio.
5. Analizar el dominio de servicio
6. Especificar los componentes del dominio arquitectural.
7. Construir los componentes arquitecturales.
8. Traducir los modelos para cada dominio usando los componentes arquitecturales.
(Universidad Autonoma de Chihuahua, 2006)

El progreso de paso a paso sigue un conjunto estricto de reglas para guiar la traducción desde cada versión de
los diagramas a la siguiente. El proceso establece un ritmo de construir un poco y probarlo, construir otro poco y
probar otro poco más, lo que ayuda a prevenir que surjan problemas sorpresa en lo profundo del proceso
(Universidad Autonoma de Chihuahua, 2006)
El método Shlaer-Mellor también pone un gran énfasis en el desarrollo iterativo e incremental. Pero esta
metodología reduce y controla las iteraciones en el análisis mediante confinarlas a un solo dominio a la vez. Las
iteraciones en el diseño son controladas de manera similar: Las modificaciones en el diseño se hacen
completamente en el dominio arquitectural y se propagan al sistema entero mediante los diagramas
estandarizados.
(Universidad Autonoma de Chihuahua, 2006) (SPIRES-HEP, 1996)

d) ¿Para que funciona?

El movimiento de un paso en el proceso hacia el siguiente (por ejemplo, de diagramas a nivel de análisis a
diagramas a nivel de diseño) es también definido con suficiente precisión para permitir la generación de
diagramas de diseño directamente de los diagramas de análisis. Esto es un gran ahorrador de tiempo y previene
errores en la traducción. Además acelera el proceso de aplicar cambios debido a que pueden ser propagados
automáticamente en los diagramas.
El método fue desarrollado para y mantiene un fuerte énfasis en diseño de sistemas de tiempo real. Como tal,
proporciona soporte que no está presente en otras metodologías, que olvidan las demandas únicas del tiempo
real en favor de la funcionalidad más común de los negocios. (Universidad Autonoma de Chihuahua, 2006)

El método de Shlaer-Mellor para el desarrollo de software describe un conjunto de modelos integrados y

diagramas que son utilizados para grandes proyectos de aplicación de software. Este sistema también es
conocido como el OOSA por sus siglas en ingles que significa análisis de sistemas orientados a objetos. El OOSA
contiene una gran variedad de diagramas incluyendo las tablas de dominio, los diagramas de modelo de
información de objetos, modelo de transición de estado, diagrama de flujo de datos de acción, diagrama de
clases, y tabla de estructura de clases. (SmartDraw., 2008)

Las tablas de dominios dividen el sistema en dominios y en subsistemas. Los dominios son diferentes, el sujeto
independiente importa dentro de la aplicación. (SmartDraw., 2008)

20
La notación de las tablas de dominio consta básicamente de las siguientes imágenes.

Dominio: existen 4 tipos de dominios: aplicación, servicio, arquitectura, e implementación.

Relaciones: los dominios son conectados por gruesas flechas que simbolizan relaciones cliente servidor o
puentes. La punta de la flecha apunta al servidor.
Por otro lado las notaciones del modelo de información de objeto son las siguientes
Objetos: son abstracciones de objetos del mundo real, roles, incidentes, o interacciones. Con instancias de
grupos más grandes llamadas clases.

Relaciones y multiplicidad: se usan flechas para ilustrar las relaciones entre objetos y representan la
multiplicidad con el número de cabezas de flecha como se muestra en la figura.

Herencia: la herencia es usada para describir relaciones en las cuales un objeto deriva algunos de sus atributos
de objetos superiores.
Los Diagramas de transición de estado describen el ciclo de vida de un objeto en la metodología Shlaer y
Mellor. Es similar a la tabla de estado que se usa en el UML. Un diagrama de flujo de datos ilustra el proceso
asociado con el diagrama de estado.

Estados: usan cajas que representan estado y usa arcos que representa transición entre estados.
NOTACION DEL DIAGRAMA DE FLUJO (SmartDraw., 2008)

Procesos: Un proceso es algo que manipula datos.

Flujo de Datos: Ilustra el flujo de datos o el control de flujo entre procesos

Almacenamiento de Datos: Almacena datos que representan un componente lógico del sistema donde la
información
Se pueden utilizar los diagramas de clases y las tablas de estructura de clase para analizar los dominios de
arquitectura del sistema. Son parte del lenguaje de diseño orientado a objetos del método de Shlaer-Mellor. Un
diagrama de clase muestra una vista externa de una clase. Una tabla de estructura de clases muestra la
estructura interna de una clase con código y operaciones.
NOTACION. (SmartDraw., 2008)
Clase: representan la traducción de un objeto desde su fase de análisis hasta su fase de diseño

Componente lógico: es parte del tipo de dato en una clase.

Parámetro condicional: es una característica o argumento que es restringido de alguna manera.

21
Excepción: adjunta a una clase o modulo este diamante representa un caso que no normal

NOTACION DE ESTRUCTURA DE CLASES:

Modulo: Se refiere al código llamado por uno o más módulos

Modulo Extranjero: Es una porción de código que no es parte de una clase.

Manejo de Excepciones: Un manejador de excepciones trata de corregir una condición anormal o notificar al
usuario que existe un error.

Elemento de dato: es código que guarda valores e información. (SmartDraw., 2008)

• Ejemplo grafico de la creacion de SHLAER-MELLOR

22
 5. Conclusiones:

• Detalles de implementación separados de la lógica de negocio.

• MDA posee una gama de generación automática de código para cualquier lenguaje.
• MDA provee una arquitectura que permite independencia de plataforma.
• MDA separa la lógica de negocio de la infraestructura que la implementa.
• Tiene un soporte completo para el ciclo de vida de la aplicación.
• La metodología desarrollada por Rumbaugh, enfatiza en la importancia del modelo y uso de este
modelo, en el cual el análisis está enfocado hacia un nivel de diseño, en el cual se modelan también
los recursos de la computadora.
• La metodología brinda facilidades para analizar y diseñar orientado a objetos, y nos sirve como
introducción para métodos profesionales y modernos como lo es UML.
• La tecnología orientada a objetos es algo más que una forma de programar, ya que para definir un
marco de trabajo, no es suficiente un simple uso de programación orientada a objetos, sino que es
muy importante el seguimiento de una metodología de desarrollo de software como las de OMT y
Shlaer y Mellor.
• Esta metodología puede ser aplicada en varios ámbitos de la implementación informática, tales como
bases de datos orientadas a objetos de todo tipo.
• La metodología desarrollada por Shlaer y Mellor es una metodología enfocada especialmente en el
en el diseño de sistemas en tiempo real.
• La metodología Shlaer y Mellor proporciona herramientas que anteriores metodologías no habías
proporcionado con el objetivo de lograr obtener código a partir de análisis de diagrama
• Esta es una metodología que requiere mucho tiempo para ser aprendida completamente, dada su
complejidad y su gran campo de aplicación
• Esta metodología tiene su mayor punto de atracción en el desarrollo de software en tiempo real.

23
 6. Bibliografía:

1. CiberaAUIOPula Villalobos, 135 - 28018 Madrid http://java.ciberaula.com/articulo/introduccion_mda/

2. MDA Guide Version 1.0.1. OMG. 2003 Arquitectura Dirigida por Modelos. María Victoria Di Libero.
Universidad Tecnológica Nacional, Buenos Aires, Argentina.
3. http://technology.amis.nl/blog/wp-content/images/MDAfigure_01.jpg

4. Víctor Manuel Chávez Gaona, Juan Carlos Olivares Rojas (1999). Metodología OMT (Rumbaugh).
Instituto Tecnológico de Morelia. Recuperado el 24 de febrero del 2009.
http://www.monografias.com/trabajos13/metomt/metomt.shtml.
5. Lic. Adriana Fachal. “Modelo OMT”. (2005). Recuperado el 23 de febrero del 2009.
www.centros.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/fachal9.pdf
Grahan, I. (1996). Metodos Orientados a Objetos. Ediciones Dias de Santos.

6. SmartDraw. (2008). SmartDraw, the World's Most Popular Business Graphics Software. Recuperado el 24 de
febrero de 2009, de http://www.smartdraw.com/about/

7. SPIRES-HEP. (1996). Fermiland-US Mirror. Recuperado el 22 de febrero de 2009, de

http://www.hep.net/chep95/papers/p84/p84.pdf

8. Universidad Autonoma de Chihuahua. (2006). Universidad Autonoma de CHihuahua. Recuperado el 23 de Febrero

de 2009, de comunidad.uach.mx/fmarisc/analisis/LecturasSesiones/LecturaSesion04Metodologias.doc –

9. EdrawSoft (2004 - 2009). Recuperda el 22 de Febrero de 2009,

hppt://images.google.com/imgres?imgurl=http://www.edrawsoft.com/images/shapes/soft-
shlaermellor.png&imgrefurl=http://www.edrawsoft.com/Shlaer-Mellor-
OOA.php&usg=__s9CJvowqXBX3VZM4x3GTd6EyE4=&h=263&w=579&sz=13&hl=es&start=7&um=1&tb
nid=e7IZ8hL0D4BNM:&tbnh=61&tbnw=134&prev=/images%3Fq%3DBuild%2BShlaer-
Mellor%26um%3D1%26hl%3Des%26lr%3D%26client%3Dsafari%26rls%3Des-es%26sa%3DG

24