Universidad de Aquino Bolivia Facultad de Ciencia y Tecnolog a Ingenier a de Sistemas

Modelado de Objetos en la Metodolog a OMT

Taller de Sistemas
Docente Alumno Pialy Torrico Miguel G. Aguilar Ingali

Fecha de Entrega

7 de marzo de 2014

La Paz - Bolivia
1

Modelado de Objetos en la Metodolog a OMT

Miguel Gustavo Aguilar Ingali 7 de marzo de 2014

Indice
1. Introducci on 1.1. Metodolog a OMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Modelo de Objetos 2.1. Clases y Objetos . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Enlaces y Asociaciones . . . . . . . . . . . . . . . 2.1.2. Conceptos Avanzados de Enlaces y Asociaciones 2.1.3. Generalizaci on y Herencia . . . . . . . . . . . . . 2.1.4. Agrupaci on de entidades . . . . . . . . . . . . . . 2.1.5. Modelo Avanzado de Datos . . . . . . . . . . . . 2.1.6. Construcci on de un modelo de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 4 4 5 5 7 8 8 9

3. Ventajas y desventajas 9 3.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Conclusiones 10

UDABOL

Taller de Sistemas

1.
1.1.

Introducci on
Metodolog a OMT

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 on de los laboratorios General Electric. OMT es una de las metodolog as de an alisis y dise no orientadas a objetos, m as maduras y ecientes que existen en la actualidad. La gran virtud que aporta esta metodolog a es su car acter de abierta (no propietaria), que le permite ser de dominio p ublico y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evoluci on para acoplarse a todas las necesidades actuales y futuras de la ingenier a de software. Las fases que conforman a la metodolog a OMT son: An alisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades m as importantes. El modelo de an alisis es una abstracci on resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se har a. Los elementos del modelo deben ser conceptos del dominio de aplicaci on y no conceptos inform aticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos inform aticos. Dise no del sistema. El dise nador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas bas andose tanto en la estructura del an alisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema. Dise no de objetos. El dise nador de objetos construye un modelo de dise no bas andose en el modelo de an alisis, pero incorporando detalles de implementaci on. El dise no de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el dise no puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.). Implementaci on. Las clases de objetos y relaciones desarrolladas durante el an alisis de objetos se traducen nalmente a una implementaci on concreta. Durante la fase de implementaci on es importante tener en cuenta los principios de la ingenier a del software de forma que la correspondencia con el dise no sea directa y el sistema implementado sea exible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilizaci on de c odigo y la correspondencia entre el dominio del problema y el sistema inform atico, si luego perdemos todas estas ventajas con una implementaci on de mala calidad. La metodolog a OMT emplea tres clases de modelos para describir el sistema: Modelo de objetos. Describe la estructura est atica de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo din amico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicaci on. Se representa mediante diagramas de onjetos. Modelo din amico. Describe los aspectos de un sistema que tratan de la temporizaci on y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que denen el contexto para los sucesos) y la organizaci on de sucesos y estados.Captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que est an implementadas. Se representa gr acamente mediante diagramas de estado. Modelo funcional. Describe las transformaciones de valores de datos (funciones, correspondencias, restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace Miguel Aguilar Ingali 3

UDABOL

Taller de Sistemas

el sistema, independientemente de cuando se haga o de la forma en que se haga. Se representa mediante diagramas de ujo de datos

2.

Modelo de Objetos

Esta es la parte principal de la T ecnica para modelado ya que se fundamenta en la teor a de OO. La denici on clara de las entidades que intervienen en el sistema es un paso inicial necesario para poder denir qu e transformaciones ocurren en ellas y cu ando se producen estas transformaciones. Esta forma de pensar es inherente al paradigma de OO donde las clases y su jerarqu a determinan el sistema. Los diagramas de objetos permiten representar gr acamente los objetos, las clases y sus relaciones mediante dos tipos de diagramas: los diagramas de clases y los diagramas de casos concretos (instancias). Los diagramas de clases describen las clases que componen el sistema y que permitir an la creaci on de casos concretos, los diagramas de casos concretos describen la manera en que los objetos del sistema se relacionan y los casos concretos que existen en el sistema de cada clase. En los diagramas que componen este modelo se pueden representar los siguientes elementos del sistema: objetos y clases, atributos, operaciones, y relaciones o asociaciones.

2.1.

Clases y Objetos

Los objetos y sus componentes se representan gr acamente en OMT de forma que es posible obtener una idea de los elementos que intervienen en el sistema estudiando el model. Los elementos y sus caracter sticas con representaci on gr aca son los siguientes. Objetos. Un objeto es, sencillamente, algo que tiene sentido en el contexto de la aplicaci on. Se denir a un objeto como un concepto, abstracci on o cosa con l mites bien denidos y con signicado a efectos del problema que se tenga entre manos. Clases. Describe un grupo de objetos con propiedades (atributos) similares, con relaciones comunes con otros y con una sem antica com un. Diagramas de objetos. Proporcionan un anotaci on gr aca formal para el modelado de objetos, clases y sus relaciones entre s , son u tiles, tanto para el modelado abstracto como, para dise nar programas reales. Hay dos tipos de diagramas de objetos Diagrama de clases. Esquema, patr on o plantilla para describir muchas instancias de datos posibles. Diagrama de instancias. Describe la forma en que un cierto conjunto de objetos se relacionan entre s . Atributos. Los objetos pertenecientes a una clase presentan caracter sticas que en OMT se denominan atributos. Sin embargo, no se deben de confundir los atributos, que son caracter sticas que todos los objetos de una clase comparten, con otros objetos que pueden formar parte del objeto que estamos tratando. Operaciones y m etodos. Del mismo modo que los objetos en OMT se pueden representar las operaciones que se realizan sobre ellos o que estos realizan sobre otros objetos del sistema. Los objetos realizan acciones sobre otros objetos y denen acciones que se realizan sobre ellos mismos. Los objetos de una misma clase comparten estas operaciones, aunque tambi en pueden a nadir otras nuevas que no se denan en su clase a medida que se especializa el objeto en otras subclases. Tambi en pueden redenir las operaciones en estas especializaciones ignorando las deniciones realizadas en las superclases. Las operaciones pueden llevar impl cito el objeto sobre el que se realizan o que realiza la acci on, de forma que es posible tener una misma operaci on que se efect ue de manera distinta seg un el objeto sobre el que se aplique. La implementaci on Miguel Aguilar Ingali 4

UDABOL

Taller de Sistemas

de las operaciones para cada uno de los objetos diferentes (o subclases) se denomina m etodo. Los m etodos implementan en cada una de las clases de forma espec ca para los objetos que representa.

Figura 1: Ejemplo de Clase y Objeto con sus atributos, operaciones y m etodos

2.1.1.

Enlaces y Asociaciones

Las relaciones entre clases determinan el comportamiento del sistema y constituyen una parte muy importante del mismo ya que mediante las relaciones denimos la forma en que los objetos se comunican, lo que tambi en se conoce como comportamiento. Adem as las relaciones tienen una serie de caracter sticas que son de inter es para el modelado del sistema. Relaciones. En OMT se identican a trav es de enlaces: conexiones f sicas o conceptuales entre casos concretos de objetos. Una asociaci on en OMT abstrae un conjunto de enlaces con una estructura y un signicado comunes. Desde el punto de vista de la implementaci on, una asociaci on es un puntero que apunta desde un objeto a otro. Multiplicidad. Este t ermino se encuentra relacionado con las asociaciones e indica el n umero de casos concretos de una clase que puede relacionarse con otro caso concreto. Las relaciones m as frecuentes son las binarias, aunque pueden darse de cualquier orden.

Figura 2: Ejemplo de enlaces y asociaciones

2.1.2.

Conceptos Avanzados de Enlaces y Asociaciones

Atributos de los enlaces. Los enlaces as como los objetos pueden tener atributos, que son propiedades de los enlaces de una asociaci on. Miguel Aguilar Ingali 5

UDABOL

Taller de Sistemas

Modelado de una asociaci on en forma de clase. A veces resulta conveniente modelar las asociaciones como clases en lugar de c omo relaciones, cuando los enlaces pueden participar en asociaciones con otros objetos o est an sometidos a operaciones. Clasicaci on. Tambi en podemos encontrar en una asociaci on de objetos que pertenecen a una clase con multiplicidad muchos que deben estar ordenados. Esta caracter stica de los objetos es una restricci on, ya que implica una condici on que deben cumplir los elementos de la clase. Nombre de rol. Las asociaciones conectan clases u objetos que pertenecen a dichas clases, pero en ocasiones necesitamos restringir el conjunto de los objetos que se relacionan dentro de la clase. Mediante estas restricciones podemos especicar qu e objetos se relacionan. Podemos conseguir este objetivo mediante los llamados nombres de rol. Un nombre de rol es un atributo derivado de una clase cuyo valor es un conjunto de objetos relacionados. Los nombres de rol se utilizan cuando las asociaciones se producen entre objetos de la misma clase ya que suelen producirse entre subconjuntos de esas clases. Una asociaci on binaria puede tener dos roles, uno por cada extremo de la asociaci on que son identicados por sus nombres. Cualicaci on. Las asociaciones muchos a muchos y uno a muchos pueden ser calicadas mediante un elemento calicador que reduce el conjunto de objetos relacionados, indicando un subconjunto de la clase que se calica en la asociaci on. Las asociaciones que se pueden calicar son las de multiplicidad uno a muchos y muchos a muchos. Agregaci on. Las relaciones de agregaci on son para OMT formas de asociaci on del tipo es parte de, como tales se denen entre una clase agregado y una clase componente y se indican con un rombo en la parte de la clase que act ua como continente. Las relaciones de agregaci on se establecen en los llamados objetos compuestos que contienen otros objetos y estos pueden ser de dos tipos: aquellos que tienen existencia f sica m as all a del objeto agregado, y los que no pueden existir sin el objeto agregado.

Figura 3: Ejemplo de enlaces y asociaciones

Miguel Aguilar Ingali

UDABOL

Taller de Sistemas

2.1.3.

Generalizaci on y Herencia

En el paradigma de la orientaci on a objetos uno de los elementos m as importantes es la herencia. La cualidad que permite que los objetos hereden las caracter sticas (atributos) y las operaciones (m etodos) dentro de una estructura jer arquica conlleva una serie de consecuencias de m axima relevancia a la hora de dise nar un sistema inform atico. Los objetos heredan un comportamiento que puede ser modicado y unas estructuras de datos de forma que se permite y se facilita la reutilizaci on de las clases y del c odigo que implementa sus funcionalidades. Ambos conceptos van unidos: herencia y estructura jer arquica, de forma que la herencia se produce por la existencia de una estructura entre los componentes del sistema y la estructura se consigue en la implementaci on del c odigo a trav es de la herencia en los lenguajes OO. La herencia est a ntimamente relacionada con la forma concreta en que un lenguaje implementa la generalizaci on, que es un t ermino m as abstracto. La generalizaci on es la relaci on que existe entre una clase y las subclases que se derivan de la misma. A partir de una versi on en bruto se generan versiones m as especializadas de la misma que a naden caracter sticas y operaciones. La superclase es la versi on general y las subclases son Miguel Aguilar Ingali 7

UDABOL

Taller de Sistemas

especializaciones de la superclase. Las generalizaciones pueden tener discriminadores que indican qu e aspecto de la superclase est a siendo utilizado para obtener subclases m as concretas. Anulaci on. Al implementar la herencia nos encontramos en numerosas ocasiones que las subclases redenen operaciones que ya han sido denidas en las superclases. Las razones para esta nueva implementaci on de operaciones que existen en las superclases son variadas, a veces simplemente se le a naden nuevas acciones que van en consonancia con las nuevas caracter sticas que a nade la subclase; otras, se consigue optimizar las operaciones debido a que las subclases tienen caracter sticas nuevas que lo permiten, y a veces se produce por una mala pr actica de an alisis donde no se prev en las operaciones de manera optima. Se han propuesto una serie de reglas a la hora de implementar la herencia para minimizar los errores y maximizar la reutilizaci on de c odigo: 1. Las operaciones de consulta, aquellas que no modican valores de atributos, se heredan por todas las subclases. 2. Las operaciones de actualizaci on, que modican valores de atributos, se heredan por todas las subclases y se a naden las nuevas operaciones para aquellas que a nadan atributos. 3. Las operaciones de actualizaci on que se realizan sobre atributos que tengan alg un tipo de restricci on o asociaci on, se bloquean para nuevas subclases. 4. Las operaciones no pueden volver a denirse para hacer que se comporten de distinta manera de cara al exterior, es decir; todos los m etodos concretos de una operaci on deben tener el mismo protocolo. 5. Las operaciones se pueden renar a nadiendo comportamientos en las subclases. 2.1.4. Agrupaci on de entidades

Los elementos que hemos estudiado en el Modelo de Objetos se pueden agrupar para construir el modelo completo, as , las clases, las asociaciones y las generalizaciones forman lo que se denomina m odulo y varios m odulos forman el modelo de objetos. En un m odulo no se deben repetir los nombres de las clases y de las asociaciones, aunque se puede hacer referencia a la misma clase dentro de distintos m odulos. Tambi en se denen las denominadas hojas que se utilizan para descompones un Modelo de Objetos en unidades que podemos manejar. Una hoja es una parte de un m odulo que podemos manejar con facilidad, sea en el formato que sea. 2.1.5. Modelo Avanzado de Datos

Clases abstractas. En ocasiones puede ser de utilidad tener clases que denan propiedades y operaciones de forma general, dejando para sucesivos renamientos la implementaci on concreta de las mismas. Una clase abstracta es precisamente una clase donde se introducen m etodos y datos que se denir an en las subclases de la misma. Las clases abstractas siempre tienen que tener clases derivadas donde se especicar an las operaciones que no se hayan denido en la clase abstracta, nunca podr an tener objetos, se utilizan como clases bases o superclases de otras clases. La existencia de este tipo de clases facilita a un m as la posibilidad de abstracci on del modelo, dejando para posteriores renamientos del problema la denici on m as exhaustiva de operaciones y datos. La implementaci on concreta de las clases abstractas depende del lenguaje OO. En OMT una clase abstracta se identica cuando no tiene casos concretos (instancias) pero una subclase suya s los tiene. Por ejemplo, una clase abstracta n umeros podr a denir una operaci on multiplicar que no se implementara hasta la denici on de las subclases n umeros enteros, n umeros reales y n umeros complejos, teniendo la informaci on precisa en cada una de las subclases de la forma en que se multiplican los n umeros. Miguel Aguilar Ingali 8

UDABOL

Taller de Sistemas

Herencia m ultiple. La herencia m ultiple es una caracter stica que algunos sistemas OO poseen, mediante la cual es posible que una clase herede de varias superclases al mismo tiempo. Sin embargo, la herencia m ultiple aumenta radicalmente la complejidad de los sistemas que la implementan ya que la b usqueda de las operaciones se diculta cuando no se dene en la clase derivada y hay que realizarla en las superclases. Clave candidata. No es m as que un conjunto m nimo de atributos que dene de forma u nica un objeto o enlace. Es decir, mediante una clave candidata tenemos denido el objeto o el enlace con una serie de atributos de forma que se distingue del resto de objetos o enlaces. Las claves candidatas son restricciones y, por tanto, se representan como tales en OMT. Para encontrar una clave candidata en una asociaci on donde intervienen m as de dos clases, debemos denir qu e combinaciones de clases o enlaces en la asociaci on de los elementos denen la tercera clase o enlace de forma u nica. Restricciones. El modelo de objetos contiene diferentes entidades como son los objetos, las clases, los atributos, los enlaces y las asociaciones. Cada una de estas entidades tiene una serie de caracter sticas inherentes a su naturaleza dentro del sistema que estamos modelando. Las caracter sticas denen su signicado dentro del sistema y tambi en sus limitaciones. Estas limitaciones se denominan en el An alisis restricciones. Las restricciones pueden ser muy complejas y en este caso no pueden estudiarse en el modelo de objetos, sino que se especicar an en el modelo funcional. Las que intervienen en el modelo de objetos se representan mediante llaves junto a la entidad a que se reeran. Cuando la restricci on implica m as de una clase, se indica mediante una echa discontinua que une los elementos que se vean implicados en la restricci on. Las asociaciones tambi en pueden tener restricciones. 2.1.6. Construcci on de un modelo de objetos

1. Identicar las clases de objetos. 2. Iniciar un diccionario de datos que contenga descripciones de clases, atributos y asociaciones. 3. Agregar asociaciones entre clases. 4. Agregar atributos a objetos y ligas. 5. Organizar y simplicar las clases de objetos usando herencia. 6. Probar las rutas de acceso usando escenarios e iterar los pasos anteriores seg un sea necesario. 7. Agrupar las clases en m odulos, bas andose en acoplamiento cercano y funci on relacionada.

3.
3.1.

Ventajas y desventajas
Ventajas

1. Proporciona una serie de pasos perfectamente denidos al desarrollador. 2. Tratamiento especial de la herencia. 3. Facilita el mantenimiento dada la gran cantidad de informaci on que se genera en el an alisis. 4. Es fuerte en el an alisis

Miguel Aguilar Ingali

UDABOL

Taller de Sistemas

3.2.

Desventajas

1. Hay pocos m etodos para encontrar inconsistencias en los modelos. 2. Interacci on de objetos no soportada expl citamente en ninguna herramienta gr aca. 3. Al ser un an alisis iterativo es dif cil de saber cuando comenzar con el dise no. 4. Es d ebil en el dise no

4.

Conclusiones
Como parte de esta metodolog a sirvio para crear UML es recomendable su aprendizaje y uso. Al ser de dominio publico y tener bastante literatura de consulta en internet es garantizado su aprendizaje. El modelado de objetos es una parte fundamental en el desarrollo de sistemas de informaci on en OMT de esto dependen el modelado funcional y el modelado din amico.

Referencias
[1] http://www.willydev.net/descargas/prev/OMT2.pdf [2] http://www.monograas.com/trabajos6/meto/meto.shtml [3] http://aprendepooconjava.blogspot.com/2012/09/clases-y-objetos.html [4] http://programandoenjava.over-blog.es/article-el-uml-o-lenguaje-de-modelado-unicado-comoherramienta-en-el-modelado-de-objetos-53386438.html [5] http://www.monograas.com/trabajos13/metomt/metomt.shtml

Miguel Aguilar Ingali

10