1

09

Metodologías Rumbaugh, Shlaer-Mellor y MDA Objetos y Abstracción de Datos David Coronado - Julio Chicas

2

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

3

Í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

4

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.

5

6

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.

7

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

8

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.

9

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

10

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.

11

• 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.

12

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

13

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.

14

Diagrama 2: Ejemplo de Modelo Dinámico

15

c) Modelo Funcional

16

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:

17

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.

18

• 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

19

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)

20

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)

21

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.

22

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

23

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.

24

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&tbnid=e7IZ8hL0D4BNM:&tbnh=61&tbnw=134&prev=/images%3Fq%3DBuild%2BShlaer-Mellor%26um%3D1%26hl%3Des%26lr%3D%26client%3Dsafari%26rls%3Des-es%26sa%3DG