Tutorial UML (página 2)

En donde se destaca que:

?? Un Almacen posee Clientes y Cuentas (los
rombos van en el objeto que posee las referencias).

? Cuando se destruye el Objeto
Almacén también son destruidos los objetos
Cuenta

asociados, en cambio no son afectados los
objetos Cliente asociados.

? La composición se destaca por un
rombo relleno.

? La agregación se destaca por un
rombo transparente.

La flecha en este tipo de relación
indica la navegabilidad del objeto referenciado. Cuando no existe
este tipo de particularidad la flecha se elimina.

Dependencia o Instanciación
(uso):

Representa un tipo de relación muy particular, en
la que una clase es instanciada (su instanciación es
dependiente de otro objeto/clase).

Es una relación de uso, es decir una clase usa a
otra, que la necesita para su cometido. Se representa con una
flecha discontinua va desde la clase utilizadora a la clase
utilizada. Con la dependencia mostramos que un cambio en la clase
utilizada puede afectar al funcionamiento de la clase
utilizadora, pero no al contrario.

El uso más particular de este tipo
de relación es para denotar la dependencia que tiene una
clase

de otra, como por ejemplo una
aplicación gráfica que instancia una ventana (la
creación del Objeto

Ventana esta condicionado a la
instanciación proveniente desde el objeto
Aplicación):

Cabe destacar que el objeto creado (en este caso la
Ventana gráfica) no se almacena dentro d el objeto que lo
crea (en este caso la Aplicación).

Ejemplo utilizando relaciones, cardinalidad,
etc.

Ejemplo: La clase Persona tiene un Nombre,
Dirección, y Número del Seguro Social. Una persona
puede trabajar en algún proyecto y ganar un salario. Una
Compañía tiene un Nombre, Dirección,
Número de Teléfono, y Producto Primario. Una
Compañía contrata y despide Personas. Persona y
Compañía tienen una relación
"muchos-muchos".

El título del trabajo depende de la persona y de
la compañía. Hay dos tipos de Personas:
Trabajadores y Administradores. Cada Trabajador está
involucrado en varios Proyectos; cada Administrador es

responsable de varios proyectos. En un proyecto pueden
trabajar varios trabajadores y un solo administrador. Cada
proyecto tiene un Nombre, Presupuesto, y una Prioridad Interna
para asegurar recursos. Además una Compañía
está compuesta de múltiples Departamentos; cada
departamento dentro de una compañía se identifica
de forma única por su Nombre.

Un departamento usualmente tiene un administrador. La
mayoría de los administradores manejan un departamento; y
algunos administradores no están asignados a ningún
departamento. Cada departamento manufactura varios productos;
mientras que cada producto está hecho por un solo
departamento. Un producto tiene Nombre, Costo, y Peso.

El diagrama es el siguiente:

Diagrama de objetos

Pertenece a la clasificación de los
diagramas que dan una vista estática del
sistema.

Contiene un conjunto de instancias de los elementos
encontrados en un Diagrama de Clases. Por lo tanto, expresa la
parte estática de una interacción, consistiendo en
los objetos que colaboran, pero son ninguno de los mensajes
enviados entre ellos.

Para realizarlo primero se debe decidir que
situación queremos representar del sistema, en un momento
concreto del mismo, permitiendo así mostrar los objetos y
sus relaciones

En los diagramas de objetos también se pueden
incorporar clases, para mostrar la clase de la que es un objeto
representado.

Con los Diagrama de Objetos no se puede
especificar completamente la estructura de objetos del

sistema. Puede existir una multitud de posibles
instancias de una clase particular, y para un conjunto de clases
con relaciones entre ellas, pueden existir muchas más
configuraciones posibles de esos objetos.

Diagrama

Al momento de construir el Diagrama de Objetos hay que
tener bien en claro dos concepto muy importantes.

En primer lugar saber a que nos referimos
cuando hablamos de objeto.

Los objetos son las entidades básicas del modelo
de objeto. La palabra objeto proviene del latín objectus,
donde ob significa hacia, y jacere significa arrojar; o sea, que
teóricamente un objeto es cualquier cosa que se pueda
arrojar.

Ejemplo: Una pelota o un libro se pueden arrojar,
por lo tanto estos son objetos. Por otro lado, un avión o
un elefante también se consideran objetos, aunque sean
bastante pesados para ser arrojados.

Los objetos son más que simples cosas que se
puedan arrojar, son conceptos, pudiendo ser abstractos o
concretos.

Ejemplo: Una mesa es un objeto
concreto, mientras que un viaje es un objeto
abstracto.

Los objetos corresponden por lo general a
sustantivos, pero no a gerundios.

Ejemplo: Mesa y viaje son ambos sustantivos y por
lo tanto objetos. Trabajando y estudiando son gerundios por lo
cual no se consideran objetos.

Cualquier cosa que incorpore una estructura y un
comportamiento se le puede considerar como un objeto.

Ejemplo: Una pelota es sólida y redonda y
se le puede arrojar o atrapar. Un libro es rectangular y
sólido y se le puede abrir, cerrar, y leer.

Un objeto debe tener una identidad coherente, al que se
le puede asignar un nombre razonable y conciso.

Ejemplo: Se consideran manzanas
todas las frutas con un sabor, textura, y forma
similar.

La existencia de un objeto depende del contexto del
problema. Lo que puede ser un objeto apropiado en una
aplicación puede no ser apropiado en otra, y al
revés. Por lo general, existen muchos objetos en una
aplicación, y parte del desafío es
encontrarlos.

Ejemplo: La temperatura se puede considerar un
objeto abstracto, teniendo propiedades tales como el valor de la
temperatura y el tipo de la escala en que se mide (Celsius o
Fahrenheit). Por otro lado, si hablamos de un termómetro,
la temperatura pasa a ser una propiedad del
termómetro.

Los objetos se definen según el
contexto de la aplicación.

Ejemplo: Una persona llamada Juan Pérez se
considera un objeto para una compañía, mientras que
para un laboratorio el hígado de Juan Pérez es un
objeto. Una universidad como la UNLaR se considera un objeto,
mientras que dentro de la UNLaR los objetos serían las
aulas, los estudiantes y los profesores.

Los objetos deben ser entidades que existen de forma
independiente. Se debe distinguir entre los objetos, los cuales
contienen características o propiedades, y las propias
características.

Ejemplo: El color y la forma de una manzana no se
consideran propiamente objetos, sino propiedades del objeto
manzana. El nombre de una persona se considera una propiedad de
la persona.

Un grupo de cosas puede ser un objeto si
existe como una entidad independiente.

Ejemplo: Un automóvil se considera un
objeto el cual consiste de varias partes, como el motor y la
carrocería.

Los objetos deben tener nombres en
singular, y no en plural.

Ejemplo: Un automóvil es un objeto,
automóviles son simplemente muchos objetos y no un solo
objeto.

Parte de una cosa puede considerarse un
objeto.

Ejemplo: La rueda, la cual es parte del
automóvil, se puede considerar un objeto. Por otro lado,
el lado izquierdo del automóvil sería un mal
objeto.

Los objetos deben tener nombren razonables y concisos
para evitar la construcción de objetos que no tengan una
identidad coherente.

Ejemplo: Datos o información no son
nombres concisos de objetos. Por otro lado, un estudiante es un
objeto, ya que contiene propiedades como el número de
matrícula y nombre del estudiante, además incluye
un comportamiento tal como ir a clases, presentar
exámenes, y graduarse. Todos los estudiantes cuyos
apellidos comiencen con "A" sería un mal objeto ya que el
nombre del objeto no es conciso.

El objeto integra una estructura de datos
(atributos) y un comportamiento (operaciones). Y segundo lugar,
el termino identidad; aclarado a continuación.

Los objetos se distinguen por su propia
existencia, su identidad, aunque internamente los
valores

para todos sus datos sean iguales. Todos
los objetos se consideran diferentes.

Ejemplo: Si tenemos una biblioteca llena de
libros, cada uno de esos libros, como La Ilíada, Hamlet,
La Casa de los Espíritus, etc., se consideran e
identifican como objetos diferentes. Dos manzanas aunque sean
exactamente del mismo color y forma, son diferentes
objetos.

Los objetos tienen un nombre que puede no
ser único.

Ejemplo: Pueden existir múltiples copias
de un solo libro, lo cual requiere identificadores especiales
para distinguir entre diferentes objetos con propiedades
similares, como el código del libro en la
biblioteca.

Los objetos necesitan un identificador interno
único cuando son implementados en un sistema de
computación para accesar y distinguir entre los objetos.
Estos identificadores no deben incluirse como una propiedad del
objeto, ya que solo son importantes en el momento de la
implementación.

Ejemplo: Los diferentes personas se
distinguirían internamente dentro de una computadora
por

los identificadores Persona1, Persona2, Persona3, etc.
Por otro lado, el número del seguro social de la persona
es un identificador externo válido, ya que existe fuera de
la implementación en una computadora.

La notación general para una objeto es una caja
rectangular conteniendo el nombre del objeto subrayado, el cual
sirve para identificar al objeto, como se muestra:

Notación para los objetos Juan
Pérez y UNLaR.

Como se menciono al principio de esta sección el
Diagrama de Objetos repres enta a los objetos y sus relaciones.
La pregunta ahora seria ¿de qué manera?. A
continuación se detalla los pasos a seguir para construir
un Diagrama de Objetos

Hay que identificar el mecanismo que se desea modelar.
Un mecanismo representa alguna función o comportamiento de
la parte del sistema que se está modelando, que resulta de
la interacción de una sociedad de clases, interfaces y
otros elementos.

Para cada mecanismo hay que identificar las clases,
interfaces y otros elementos que participan en esta
colaboración; identificar también las relaciones
entre estos elementos.

Hay que considerar un escenario en el que intervenga
este mecanismo. También hay que congelar este escenario en
un momento concreto, y representar cada objeto que participo en
el mecanismo.

Hay que mostrar el estado y valores de los atributos de
cada uno de esos objetos si son necesarios para comprender el
escenario.

Análogamente hay que mostrar los
enlaces entre esos objetos, que representan instancias
de

asociaciones entre ellos.

Por ejemplo, en la siguiente figura se representa un
conjunto de objetos extraídos de la implementación
de un robot autónomo. Esta figura se centra en algunos de
los objetos implicados en el mecanismo utilizado por el robot
para calcular un modelo del mundo en el que se mueve. Hay muchos
más objetos implicados en un sistema en ejecución,
pero este diagrama se centra sólo en aquellas
abstracciones implicadas directamente en la creación de
esta vista del mundo.

Como indica la figura, un objeto representa al propio
robot (r, una instancia de Robot), y r se encuentra actualmente
en el estado movimiento. Este objeto tiene un enlace con m, una
instancia de Mundo, que representa una abstracción del
modelo del mundo del robot. Este objeto tiene un enlace con un
multiobjeto que consiste en instancias de Elemento, que
representa entidades que el robot ha identificado, pero
aún no ha asignado en su vista del mundo. Estos elementos
se marcan como part e del estado global del robot.

En ese instante, m está enlazado a dos instancias
de Area. Una de ellas (a2) se muestra con sus propios enlaces a
tres objetos Pared y un objeto Puerta. Cada una de estas paredes
está etiquetada con su anchura actual, y cada una se
muestra enlazada a sus paredes vecinas. Como sugiere est e
diagrama de objetos, el robot ha reconocido el área que lo
contiene, que tiene paredes en tres lados y una puerta en el
cuarto.

Diagrama de Componentes

Un diagrama de componentes muestra las organizaciones y
dependencias lógicas entre componentes software,
sean éstos componentes de código fuente, binarios o
ejecutables. Los elementos de modelado dentro de un diagrama de
componentes serán componentes y paquetes. En cuanto a los
componentes, sólo aparecen tipos de componentes, ya que
las instancias específicas de cada tipo se encuentran en
el diagrama de despliegue.

Cada componente en el diagrama debe ser documentado con
un diagrama de componentes más detallado, un diagrama de
clases, o un diagrama de casos de uso.

Un paquete en un diagrama de componentes
representa una división física del sistema.
Los

paquetes se organizan en una jerarquía de capas
donde cada capa tiene una interfaz bien definida. Un diagrama de
componentes se representa como un grafo de componentes
software unidos por medio de relaciones de dependencia
(generalmente de compilación).

Normalmente los diagramas de componentes se utilizan
para modelar código fuente, versiones ejecutables, bases
de datos físicas, entre otros.

Código fuente: En el modelado de
código fuentes se suelen utilizar para representar las
dependencias entre los ficheros de código fuente, o para
modelar las diferentes versiones de estos fichero. Para ello se
deben identificar el conjunto de archivos de código fuente
de interés y estereotiparlos como archivos file,
agruparlos en paquetes, utilizar valores etiquetados para la
información de versiones y modelar las dependencias de
compilación.

Código ejecutable: Se utiliza para modelar
la distribución de una nueva versión a los
usuarios. Para tal propósito se identifican el conjunto de
componentes ejecutables que intervienen, se utilizan estereotipos
para los diferentes tipos de componentes (ejecutables,
bibliotecas, tablas, archivos, documentos, etc.), se consideran
las relaciones entre dichos componentes que la mayoría de
las veces incluirán interfaces que son exportadas
(realizadas) por ciertos componentes e importadas (utilizadas)
por otros.

Bases de datos física: UML permite el
modelado de bases de datos físicas así como de los
esquemas lógicos de bases de datos.

Así si tenemos en cuenta las
dependencias asociadas al proceso de compilación un
componente

podría ser:

Código fuente: que depende de otros
componentes (no necesariamente código fuente) que deben
estar disponibles durante la compilación del
componente.

Código objeto binario: como por
ejemplo una librería, que puede depender de algún
código objeto con el que se linkea.

Código ejecutable: que puede
depender de otros programas ejecutables con los que

interaccionan en tiempo de
ejecución.

"El Diagrama de Componentes se usa para modelar la
estructura del software, incluyendo las dependencias entre los
componentes de software, los componentes de código
binario, y los componentes ejecutables. En el Diagrama de
Componentes se modela componentes del sistema, a veces agrupados
por paquetes, y las dependencias que existen entre componentes (y
paquetes de componentes)."

Diagramas de
Implementación

Los Diagramas de Implementación se usan para
modelar la configuración de los elementos de procesado en
tiempo de ejecución (run-time processing elements) y de
los componentes, procesos y objetos de software que viven en
ellos.

Los Diagramas de Implementación se usan para
modelar sólo componentes que existen como entidades en
tiempo de ejecución; no se usan para modelar componentes
solo de tiempo de compilación o de tiempo de enlazado.
Puedes también modelar componentes que migran de nodo a
nodo u objetos que migran de componente a componente usando una
relación de dependencia con el estereotipo 'becomes' (se
transforma)

Figura: Modelando la Distribución
del Sistema con el Diagrama de Implementación

Diagramas
dinámicos

Diagrama de Casos de Usos

Se emplea para visualizar el comportamiento del sistema,
una parte de él o de una sola clase; y como se relaciona
con su entorno. De ésta forma se puede conocer como
responde ésa parte del sistema ante un estímulo del
ambiente. El diagrama de uso es muy útil para definir como
debería ser el comportamiento de una parte del sistema, ya
que solo especifica como deben comportarse y no como están
implementadas las partes que define.

Un caso de uso especifica un requerimiento
funcional.

Elementos

Un diagrama de casos de uso consta de los
siguientes elementos:

Actor

Un actor es un rol que tiene un usuario con respecto al
sistema. Es decir, sería un usuario del sistema. Es
importante destacar el uso de la palabra "rol", ya que esto
especifica que un actor no necesariamente representa a una
persona en particular, si no la labor que realiza frente al
sistema.

Por ejemplo, en un sistema de ventas, el
rol de Vendedor con respecto al sistema puede ser

realizado por un Vendedor o bien por el
Jefe de Local.

Debe tener un nombre significativo y se
representa mediante el siguiente gráfico:

Caso de Uso

Es una operación o tarea específica que se
realiza tras una orden o estímulo de un agent e externo,
puede ser un actor o desde la invocación desde otro caso
de uso.

Se representa mediante el siguiente
gráfico:

Relaciones

Asociación

Es el tipo de relación más
básica, indica la invocación desde un actor o caso
de uso a otra operación (caso de uso). Dicha
relación se denota con una flecha simple:

Dependencia o
Instanciación

Es una forma muy particular de
relación entre clases, en la cual una clase depende de
otra, es decir, se instancia (se crea). Dicha relación se
denota con una flecha punteada:

Generalización

Este tipo de relación es una de las
más utilizadas, cumple una doble función
dependiendo de su estereotipo, que puede ser de Uso
(<<uses>>) o de Herencia
(<<extends>>).

Este tipo de relación esta orientado
exclusivamente para casos de uso.

extends: se recomienda utilizar
cuando un caso de uso es similar a otro (en
características). uses: se recomienda utilizar
cuando se tiene un conjunto de características que son
similares en más de un caso de uso y no se desea mantener
copiada la descripción de la característica. Se
representa con la siguiente flecha:

Diagrama de Secuencia

Este diagrama (también llamado diagrama de
interacción) muestra las interacciones entre un conjunto
de objetos (clases, actores), ordenadas según el tiempo en
que tienen lugar. Es decir, muestra el orden de las llamadas en
el sistema. Se utiliza un diagrama para cada llamada a
representar. Es imposible representar en un solo diagrama la
secuencia de todas las llamadas posibles del sistema, es por ello
que se escoge un punto de partida. El diagrama se compone con los
objetos que forman parte de la secuencia, estos se sitúan
en la parte superior de la pantalla, normalmente a la izquierda
se sitúa el que inicia la acción. De estos objetos
sale una línea que indica su vida en el sistema. Esta
línea simple se convierte en una línea gruesa
cuando representa que el objeto tiene el foco del sistema, es
decir cuando él esta activo.

El objeto puede existir sólo durante la
ejecución de la interacción, se puede crear o puede
ser

destruido durante la ejecución de la
interacción.

En este tipo de diagramas también intervienen los
mensajes, que son la forma en que se comunican los objetos: el
objeto origen solicita (llama a) una operación del objeto
destino. El diagrama de secuencia puede ser obtenido de dos
partes, desde el Diagrama Estático de Clases o desde el de
Casos de Usos.

Elementos

Los componentes de un diagrama de interacción
son:

Línea de vida

Un objeto (o actor) se representa como una línea
vertical punteada con un rectángulo de encabezado y con
rectángulos a través de la línea principal
que denotan la ejecución de métodos
(activación). El rectángulo de encabezado contiene
el nombre del objeto y el de su clase.

Activación

Muestra el periodo de tiempo en el cual el objeto se
encuentra desarrollando alguna operación, bien sea por
sí mismo o por medio de delegación a alguno de sus
atributos. Se denota como un

rectángulo delgado sobre la línea de vida
del objeto.

Mensajes

El envío de mensajes entre objetos se denota
mediante una línea sólida dirigida, desde el objeto
que emite el mensaje hacia el objeto que lo ejecuta. Representa
la llamada de un método (operación) de un objeto en
particular.

También es posible visualizar llamadas a
métodos desde el mismo objeto en estudio.

El presente diagrama es útil para observar la
vida de los objetos en el sistema, identificar llamadas a
realizar o posibles errores del modelo estático, que
imposibiliten el flujo de información o de llamadas entre
los componentes del sistema.

Diagrama de
Colaboración

Este diagrama muestra la interacción entre varios
objetos y los enlaces que existen entre ellos. Representa las
interacciones entre objetos organizadas alrededor de los objetos
y sus vinculaciones. A diferencia de un diagrama de secuencias,
un diagrama de colaboraciones muestra las relaciones entre los
objetos, no la secuencia en el tiempo en que se producen los
mensajes. Los diagramas de secuencias y los diagramas de
colaboraciones expresan información similar, pero en una
forma diferente.

Elementos

Los elementos que intervienen en
éstos diagramas son: objetos, enlaces y flujos de
mensajes.

Objeto

Un objeto se representa con un rectángulo, que
contiene el nombre y la clase del objeto. Un objet o es una
instancia de una clase que participa como una interacción,
existen objetos simples y complejos. Un objeto es activo si posee
un thread o hilo de control y es capaz de iniciar la actividad de
control, mientras que un objeto es pasivo si mantiene datos pero
no inicia la actividad.

Enlace

Un enlace es una instancia de una asociación en
un diagrama de clases. Se representa como una línea
continua que une a dos objetos en este diagrama. Esta
acompañada por un número que indica el orden dentro
de la interacción y por un estereotipo que indica que tipo
de objeto recibe el mensaje. El enlace puede ser reflexivo si
conecta a un elemento consigo mismo. La existencia de un enlace
entre dos objetos indica que puede existir un intercambio de
mensajes entre los objetos conectados.

Flujo de mensajes

Expresa el envío de un mensaje. Se representa
mediante una flecha dirigida cercana a un enlace. Los mensajes
que se envían entre objetos pueden ser de distintos tipos,
también según como se producen en el tiempo;
existen mensajes simples, sincrónicos, balking, timeout y
asíncronos.

Durante la ejecución de un diagrama
de colaboración se crean y destruyen objetos y
enlaces.

Diagrama de actividad

Son similares a los diagramas de flujos de otras
metodologías OO. En realidad se corresponden con un caso
especial de los diagramas de estado donde los estados son estados
de acción (estados con una acción interna y una o
más transiciones que suceden al finalizar esta
acción, o lo que es lo mismo, un paso en la
ejecución de lo que será un procedimiento) y las
transiciones vienen provocadas por la finalización de las
acciones que tienen lugar en los estados de origen. Siempre van
unidos a una clase o a la implementación de un caso de uso
o de un método (que tiene el mismo significado que en
cualquier otra metodología OO). Los diagramas de actividad
se utilizan para mostrar el flujo de operaciones que se
desencadenan en un procedimiento interno del sistema.

Diagrama de estado

Representan la secuencia de estados por los que un
objeto o una interacción entre objetos pasa durante su
tiempo de vida en respuesta a estímulos recibidos.
Representa lo que podemos denominar en conjunto una
máquina de estados. Un estado en UML es cuando un objeto o
una interacción satisface una condición, desarrolla
alguna acción o se encuentra esperando un
evento.

Cuando un objeto o una interacción
pasa de un estado a otro por la ocurrencia de un estímulo
o

evento se dice que ha sufrido una transición,
existen varios tipos de transiciones entre objetos: simples
(normales y reflexivas) y complejas. Además una
transición puede ser interna si el estado del que parte el
objeto o interacción es el mismo que al que llega, no se
provoca un cambio de estado y se representan dentro del estado,
no de la transición.

Herramientas Case
que soporta UML

El Rational Unified Process describe cómo modelar
visualmente aplicaciones para capturar la estructura y el
comportamiento de la arquitectura y de los componentes.
Rational Rose es la mejor herramienta para llevar a cabo
el modelado visual. Permite ocultar y mostrar los detalles
según el nivel de abstracción requerido y escribir
la aplicación mediante bloques de construcción
gráficos. Las abstracciones visuales permiten comunicar
los diferentes aspectos del software; mostrar cómo los
elementos del sistema encajan entre sí; asegurar que los
bloques sean consistentes con el código; mantener la
consistencia entre el diseño y la implementación; y
promover una comunicación clara entre todos los
participantes del proyecto.

Rational Rose es la herramienta CASE que
comercializan los desarrolladores de UML y que soporta de forma
completa la especificación del UML.

Esta herramienta propone la utilización de cuatro
tipos de modelo para realizar un diseño del sistema,
utilizando una vista estática y otra dinámica de
los modelos del sistema, uno lógico y otro físico.
Permite crear y refinar estas vistas creando de esta forma un
modelo completo que representa el dominio del problema y el
sistema de software.

System Architect 2001

Popkin software ofrece soporte para modelar sistemas con
UML en System Architect 2001. Ofrece todas las
características descriptas arriba para permitir el
modelado eficiente de sistemas.

Implementación de Sistemas modelados
en UML

Durante el análisis se ha descrito el problema
mediante tres Diagramas, Diagrama de Objetos,
Diagrama de Actividades y Diagrama de Estados,
separados pero relacionados. En conjunto describen qué
hace el sistema con las mínimas restricciones de
cómo debe ser implementado.

Cuando un sistema de software se
diseña Orientado a Objeto, el Diagrama de Objetos
es la base

en torno a la cual se construye el diseño. Es por
esto, que el diseñador debe transferir las operaciones de
los Diagramas de Actividad y de Estado
al Diagrama de Objetos. De esta forma, cada proceso del
Diagrama de Actividad equivaldrá a una
operación asignada a una clase en el Diagrama de
Objetos; asimismo, los eventos del Diagrama de
Estado pueden convertirse en una operación sobre un
objeto, dependiendo de la implementación del control.
Obteniendo como resultado final un Diagrama de Objetos con
las operaciones de cada clase.

Durante el diseño debemos resolver aquellos temas
que han quedado abiertos y expandir los detalle de las
operaciones que no se han especificado completamente. Debemos
transformar y optimizar también el modelo de
análisis de tal forma que sea lo suficientemente eficiente
para la implementación.

Y por último, durante la implementación,
debemos pasar el diseño a un lenguaje de
programación específico y satisfacer todas las
reglas y convenciones del lenguaje escogido.

Veamos un ejemplo

Presentamos a continuación un Diagrama de
Objetos con las operaciones de cada clase, resultado de la
etapa de diseño. Lo suficientemente detallado para luego,
haciendo uso, en este caso, del Lenguaje de Programación
Clarion 5.5 – Enterprise Edition – de SoftVelocity Inc,
lograr construir una Base de Datos física.

En siguiente esquema se muestran 5 clases
extraídas de un sistema de información de una
universidad.

Una vez obtenido el diagrama presentado
anteriormente y conociendo el Lenguaje de

Programación a utilizar. Podemos
proceder con la implementación.

La siguiente imagen muestra el
diseño de las tablas necesarias para lograr obtener una
Base de

Datos física en el lenguaje ya
mencionado.

Como podrá observarse al comparar los dos
esquemas anteriores, en el segundo, al estar ya en la
implementación del sistema, aparecen identificadores que
hacen único a un objeto en un registro físico, y
atributos que me permiten relacionar las tablas.

Recordemos un caso prestado cuando se hablo de la
identidad de los objetos en la sección
Diagrama de Objetos.

? Los objetos se distinguen por su propia
existencia, su identidad, aunque internamente los

valores para todos sus datos sean iguales.
Todos los objetos se consideran diferentes.

Ejemplo: Si tenemos una biblioteca llena de
libros, cada uno de esos libros, como La Ilíada, Hamlet,
La Casa de los Espíritus, etc., se consideran e
identifican como objetos diferentes. Dos manzanas aunque sean
exactamente del mismo color y forma, son diferentes
objetos.

Esto no sucede en una Base de Datos física. Si
los libros de una biblioteca no tienen un atributo que los
identifique unívocamente, serán vistos por la Base
de Datos como un mismo objeto (libro), a pesar de que el resto de
sus atributos, conceptualmente, los muestre c omo objetos
distintos.

Recuérdese que las computadoras manejan 0 y 1, y
es por esto, que no comprenden la diferencia entre las
características de los libros de la biblioteca que para
nosotros (humanos) es tan simple hacerlo, necesitando así
un atributo que los identifique.

Bibliografía

El lenguaje de unificado de
modelado. de Grady Booch, James Rumbauch e Ivar Jacobson.
Edit:Addison Wesley. 1º edición en español
1999

Modelos y diseños orientados a
objetos – Metodología OMT – . De James Rumbaugh,
Michael Blaha, William Premeralni, Frederick Hedí y
William Lorensen. Editorial: PRENTICE HALL. 1996.

Curso de Ingeniería del Sofware –
Unidad 5.1 Diseño de Bases de Datos Relacionales y
Conceptos de la Orientación a Objetos – . De J.
Pedro Caraca, Valiente y Hernández. ITBA (Instituto
Tecnológico de Buenos Aires – Universidad Privada -).
1997.

Sitios Consultados

http://cavirtual.ing.ula.ve/JornadasVirtuales/XIIIJornadas/edu214/edu214.htm

http://lucas.hispalinux.es/Tutoriales/doc-modelado-sistemas-UML/multiple-html/index.html

http://sigma.poligran.edu.co/politecnico/apoyo/sistemas/inve/docs_012/uml_03/queesuml.htm

http://usuarios.lycos.es/oopere/uml.htm

http://www.creangel.com/uml/intro.html

http://www.cs.ualberta.ca/~pfiguero/soo/metod/uml
-met.html

http://www.dcc.uchile.cl/~psalinas/uml/interaccion.html

http://www.docirs.cl/uml.htm

http://www.dte.us.es/personal/pruiz/investigacion/trabajo_investigacion/html/node22.html

http://www.embarcadero.com/support/what_is_uml.asp

http://www.mcc.unam.mx/~cursos/Objetos/Cap8/cap8.html

http://www.monografias.com/trabajos5/insof/insof.shtml

http://www.omg.org/gettingstarted/what_is_uml.htm

http://www.rational.com/uml/index.jsp

http://www.sparxsystems.com.au/UML_Tutorial.htm

http://www.togethersoft.com/services/practical_guides/umlonlinecourse/index.html

http://www.vico.org

http://www25.brinkster.com/educarodo/articulos/articulo0031.asp

Autor:

Wilson Dueñas