Modelo de Estructura de Objetos (OSM) UML: Diagrama de Clases (Class

Diagram)

El OSM es el modelo fundamental que provee un medio uniforme para
modelar el sistema desde la captura de requerimientos en la etapa inicial del
anlisis hasta la implementacin, atravesando todo el ciclo de desarrollo del
sistema.
Este modelo identifica:
Las clases de objetos en la aplicacin.
Como las clases de objetos se asocian unas con otras.
Como se comunican los objetos.
Los detalles de cada clase de objetos, incluyendo atributos y operaciones.
Durante el proceso de anlisis y diseo, el OSM es definido en sucesivos
niveles incrementales de detalle, hasta que el nivel necesario para la
implementacin es alcanzado. Todos los dems modelos capturan detalles que
alimentan este modelo.
El desarrollo de OSM es un proceso aditivo, diferencindose del enfoque
transformacional caracterstico de otros mtodos como el estructurado, donde los
DFD son transformados en diagramas de estructura, con los consiguientes
problemas que esto acarrea.
COMPONENTES DEL OSM.
1) Clases de Objetos.
Objetos Entidad.
Representan algo real o abstracto sobre el cual el sistema necesita
almacenar datos. Representa la memoria esencial del negocio. Los objetos del
negocio (business objects) son normalmente objetos entidad. Se representan en el
OSM con el siguiente smbolo:

Objetos Interface.
Representan los objetos tcnicos requeridos para vincular la aplicacin con
el entorno. Representan el vnculo a travs del cual el sistema recibe o suministra
NOMBRE CLASE
datos e informacin al entorno. Tpicamente incluyen interfaces con el usuario
(pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan en el
diagrama de estructura de objetos con el siguiente smbolo:


Objetos de Control.
Contienen comportamiento que no pertenece naturalmente ni a Objetos
Entidad ni de Interfaz. Son normalmente objetos transitorios, como ser un
controlador de reportes. Se representan en el diagrama de estructura de objetos
con el siguiente smbolo:


Clases abstractas y concretas.
Una clase de la cual pueden generarse instancias particulares (objetos), se
denominan clase concreta.
Una clase abstracta es aquella que no tiene instancias (objetos) propias.
Las clases abstractas son un poderoso mecanismo conceptual para definir
estructuras comunes de atributos, operaciones y restricciones, reutilizadas a
travs de la herencia por mltiples clases concretas.
En el diagrama de estructura de objetos una clase abstracta se representa
con un rectngulo punteado.
2) Caractersticas de las Clases de Objetos.
Operaciones.
Una operacin define un servicio ofrecido por un objeto junto con la
informacin que debe suministrarse cuando es invocado (nombre, argumentos de
entrada y/o salida). Tambin puede contener una especificacin de mtodo, el
cual especifica una implementacin para la operacin.
Durante la etapa de Anlisis o Diseo Lgico pueden utilizarse tpicamente
texto libre o pseudocdigo. Durante el Diseo Fsico dichas especificaciones son
trasladadas a un lenguaje de programacin especfico, como por ejemplo: C++,
Java, Visual Basic, etc.
Interface
Nombre Clase
<<PROCESS>>
NOMBRE CLASE
Algunas operaciones pueden asumirse que existen para cada clase de
objetos sin identificarlas formalmente. Estas son llamadas operaciones implcitas.
Las operaciones implcitas ms importantes son: Crear, Destruir, Leer y Actualizar.
Una operacin implcita debe ser formalmente definida cuando sus pre y post
condiciones no sean triviales.
La identificacin y especificacin de operaciones es una tarea clave durante
el Diseo Lgico.
Atributos.
Son valores de datos asociados a los objetos de una clase a la cual
describen. Estn fuertemente asociados con la clase de objetos que los contienen,
de tal forma que no tienen existencia independiente o identidad de objeto. La
decisin de cuando un tem debe considerarse como atributo o como clase vara
de sistema en sistema, dependiendo de su semntica en el dominio del problema,
es decir, lo que en un sistema se modela como atributo en otro puede modelarse
como una clase.
Cada atributo identificado debe ser atmico en el sentido de que debe ser
tratado como una unidad, es decir, puede ser un valor simple o un grupo de
valores tratados siempre como una unidad (PE. Direccin). Debe notarse que las
clases no se modelan en formas normales. La decisin sobre la estructura de
datos a utilizar se difiere hasta el Diseo Fsico.
Los atributos pueden basarse en definiciones de tipos de atributos, lo cual
provee una definicin estndar sobre formato, longitud y dominio de valores para
atributos del mismo tipo.
Restricciones.
Las restricciones pueden especificarse sobre los valores que un atributo
puede tomar. La implementacin de las restricciones puede realizarse de
diferentes formas:
Reglas de validacin durante los procesos de entrada de datos (user
inputs).
Database-level triggers
Lgica de control contenida en una o ms operaciones.
3. Asociaciones entre Objetos.
a) Relaciones Estticas.
Las relaciones estticas describen como los objetos se asocian unos con
otros en la misma forma que en el modelo Entidad-Relacin. Identifican as mismo
dependencias entre objetos, cuando un objeto requiere de la existencia de otro ya
sea de la misma clase o de otra. Las relaciones estticas se establecen
usualmente entre objetos de tipo entidad.
Al igual que los atributos, las relaciones modelan informacin sobre un
objeto (cosas que un objeto debe conocer sobre s mismo). Estas son propiedades
de un objeto. Los atributos son valores de datos. Las relaciones son valores que
se referencian otros objetos.
Una relacin esttica se representa en el diagrama de estructura de objetos
como una lnea slida entre las clases de objetos, con smbolos de cardinalidad en
sus extremos. Las relaciones pueden etiquetarse para identificar el propsito de la
asociacin. El diseador puede optar por:
Un nombre para cada direccin de la relacin.
Un nombre para una direccin de la relacin.
Un solo nombre que representa ambas direcciones de la relacin.
Sin nombre.
Por cuestiones de simplicidad, las relaciones son modeladas como binarias,
es decir, solo dos clases de objetos, no necesariamente distintas, participan en
relacin. Es posible que entre el mismo par de clases exista ms de una relacin.
La cardinalidad identifica el nmero mximo y mnimo de instancias de una
clase (objetos) que participan en una relacin dada, en el mismo sentido que lo
hacen en el modelo Entidad-Relacin. En el diagrama de estructura de objetos
utilizaremos la notacin de "pata de gallo" para especificar cardinalidades, aunque
puede utilizarse otras como ser pares ordenados, flechas (Bachmann), etc.
Pueden observarse las siguientes cardinalidades:

b) Herencia.
La herencia es el mecanismo a travs del cual los atributos, operaciones y
restricciones definidas para una clase, denominada superclase, pueden ser
heredados (reutilizados) por otra clase denominadas subclases. La herencia utiliza
el principio "es un tipo de.. Una subclase puede redefinir operaciones heredadas.
Adicionalmente, una subclase puede definir nuevos atributos y operaciones.
Se distingue entre herencia simple y mltiple. La herencia simple se da
cuando una subclase hereda de una nica superclase. En el caso de la herencia
mltiple, una subclase puede heredar de varias superclases.
En el OSM, la relacin de herencia se representa de la siguiente manera:

Por ejemplo:


c) Agregacin.
La agregacin es un tipo de asociacin fuerte, donde los objetos de una
clase se componen de objetos de otra(s) clase (s). Se diferencia de las relaciones
estticas en la fuerza semntica del vnculo. En una relacin de agregacin un
objeto compone otro. En la relacin esttica existe un vnculo pero no una
composicin. La agregacin es la aplicacin del principio el todo y sus partes
En el OSM, la relacin de agregacin se representa de la siguiente manera:

Por ejemplo:

d) Comunicacin por Mensajes.
Las asociaciones por comunicacin pueden utilizarse para mostrar que
objetos de una clase se comunican con objetos de otra clase o de la misma. Una
asociacin por comunicacin corresponde al conjunto de mensajes que son
enviados por los objetos de una clase a los objetos de otra clase o de la misma.
Tpicamente, la asociacin por comunicacin es la nica asociacin existente
entre objetos de los tres diferentes tipos.
En el OSM, la asociacin por comunicacin se representa de la siguiente
manera:

4. Consideraciones: Tcnicas avanzadas de OSM.
Visibilidad Define que objetos puede acceder y utilizar los atributos y
operaciones de un objeto dado.
Pblico: todos.
Protegido: Slo desde el objeto mismo y operaciones definidas en
subclases.
Privado: Slo desde el objeto mismo.
Atributos identificadores. Son atributos o grupos de atributos que
identifican unvocamente un objeto de una clase, se corresponde con el
concepto de Clave del modelo E-R.
Atributos Derivados. Son atributos cuyo valor puede obtenerse a partir de
los valores de otros atributos.
Relaciones Derivadas. Relaciones transitivas que se derivan de otras
relaciones estticas. En el OSM las relaciones derivadas se representan de
la siguiente manera:
Relaciones Ordenadas. Los objetos del extremo "muchos" de una relacin se
presentan en forma ordenada. Es particularmente til para especificar que los
objetos componentes de un agregado estn ordenados. Por ordenado,
entendemos que los objetos componentes sern accedidos en una secuencia
especfica predefinida. En el OSM las relaciones ordenadas se representan de la
siguiente manera:
Atributos y Operaciones de Clase. Definen el comportamiento de la clase misma
ms all del comportamiento de sus instancias. Los atributos de la clase son
utilizados para registrar datos comunes a todos los objetos (instancias) de una
misma clase. Las operaciones de clase actan sobre la clase misma como un
objeto. El caso tpico son las operaciones Crear y Destruir.
Modelo de Datos vs Modelo de Objetos
- Una BD se desarrolla mediante un Modelo de Datos.
1. Se construye el Modelo de Datos sobre el dominio de la
aplicacin.
2. Se transforma del Modelo de Datos en un Diseo de la
BD mediante la aplicacin de una serie de transformaciones
estndar (normalizacin).
- Un Sistema de Objetos se construye modelando mediante
tcnicas diferentes, pues las tcnicas del Modelo de Datos son bastante
limitadas para soportar el Modelo de Objetos.
Consejos prcticos
o No comenzar construyendo diagramas de clases; primero, es
necesario comprender el problema.
o Intentar mantener el Modelo sencillo.
o Seleccionar con cuidado los nombres.
o No introducir punteros o referencias a otros objetos como
atributos.
o Intentar evitar asociaciones n-arias.
o No intentar establecer el grado de multiplicidad perfecto al
principio.
o No introducir atributos de enlace dentro de la clase.
o Utilizar asociaciones cualificadas donde sea posible.
o Intentar evitar generalizaciones profundamente anidadas.
o Intentar asociaciones uno a uno.
o No se sorprenda si su modelo requiere una revisin.
o Documentar siempre los Modelos de Objetos.