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
| Página siguiente |