PIAD-406

Modelado y diseño del

Software I
Ingeniería de Software con
Inteligencia Artificial
Semestre IV
 Índice
UML (UNIFIED MODELING LANGUAGE) ................................................................................................................... 3
DIFERENTES DEFINICIONES DE UML........................................................................................................................ 3
BREVE RESEÑA HISTÓRICA ........................................................................................................................................ 4
CARACTERÍSTICAS DE UML ........................................................................................................................................ 5
OBJETIVOS ....................................................................................................................................................................... 5
MODELO: NOCIONES GENERALES ............................................................................................................................ 6
DIAGRAMAS: VISTAZO GENERAL .............................................................................................................................. 7
CLASIFICACIÓN DE DIAGRAMAS ......................................................................................................................................... 8
DIAGRAMAS ESTÁTICOS .................................................................................................................................................. 10
Diagrama de Clases .................................................................................................................................................... 10
Elementos..................................................................................................................................................................................10
Clase .....................................................................................................................................................................................10
Atributos ...........................................................................................................................................................................11
Identificadores ..............................................................................................................................................................13
Atributos Derivados ......................................................................................................................................................13
Restricciones de Atributos .............................................................................................................................................14
Métodos ............................................................................................................................................................................15
Relaciones entre Clases..........................................................................................................................................................16
Herencia (Especialización/Generalización) .........................................................................................................................17
Asociación ........................................................................................................................................................................20
Grado de la Asociación..................................................................................................................................................20
Asociaciones Reflexivas ................................................................................................................................................21
Atributos de Liga (o Asociación) ...................................................................................................................................22
Ensamblados: Agregación y Composición ..........................................................................................................................23
Dependencia o Instanciación (uso): ...................................................................................................................................25
Diagrama de objetos ................................................................................................................................................... 28
Diagrama...................................................................................................................................................................................28
Diagrama de Componentes ......................................................................................................................................... 32
Diagramas de Implementación .................................................................................................................................... 33
DIAGRAMAS DINÁMICOS .................................................................................................................................................. 34
Diagrama de Casos de Usos........................................................................................................................................ 34
Elementos..................................................................................................................................................................................34
Actor.....................................................................................................................................................................................34
Caso de Uso ..........................................................................................................................................................................34
Relaciones .............................................................................................................................................................................34
Asociación ........................................................................................................................................................................34
Dependencia o Instanciación ..............................................................................................................................................35
Generalización ..................................................................................................................................................................35
Diagrama de Secuencia............................................................................................................................................... 36
Elementos..................................................................................................................................................................................36
Línea de vida .........................................................................................................................................................................36
Activación .............................................................................................................................................................................36
Mensajes ...............................................................................................................................................................................36
Diagrama de Colaboración ......................................................................................................................................... 38
Elementos..................................................................................................................................................................................38
Objeto ...................................................................................................................................................................................38
Enlace ...................................................................................................................................................................................38
Flujo de mensajes ..................................................................................................................................................................38
Diagrama de actividad ................................................................................................................................................ 39
Diagrama de estado .................................................................................................................................................... 39
HERRAMIENTAS CASE QUE SOPORTA UML .......................................................................................................... 40

IMPLEMENTACIÓN DE SISTEMAS MODELADOS EN UML ......................................................................................

BIBLIOGRAFÍA .............................................................................................................................................................. 44
SITIOS CONSULTADOS ..................................................................................................................................................... 44
 UML (Unified modeling language)
UML significa "Unified Modeling Language": Lenguaje de Modelado o Modelamiento Unificado.
El Lenguaje de Modelado Unificado es un lenguaje usado para especificar, visualizar y documentar los
diferentes aspectos relativos a un sistema de software bajo desarrollo, así como para modelado de
negocios y otros sistemas no software.
Puede ser utilizado con cualquier metodología, a lo largo del proceso de desarrollo de software, en
cualquier plataforma tecnológica de implementación (Unix, Windows etc.).
Es un sistema notacional (que, entre otras cosas, incluye el significado de sus notaciones) destinado
a los sistemas de modelado que utilizan conceptos orientados a objetos.
Los principales factores que motivaron la definición de UML fueron: la necesidad de modelar sistemas,
las tendencias en la industria del software, unificar los distintos lenguajes y métodos existentes e innovar
los modelos para adaptarse a la arquitectura distribuída.
Es importante resaltar que un modelo UML describe lo que supuestamente hará un sistema, pero no
dice como implementar dicho sistema.

DIFERENTES DEFINICIONES DE UML

− El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar para
modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas
y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño
orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.
− UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de
hardware, y organizaciones del mundo real.
− El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema
para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un
modelo a partir de una especificación. Un modelo es una abstracción de algo, que se elabora para
comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para
la comprensión del original y por lo tanto facilita dicha comprensión.
− UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a
objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar
Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.
 BREVE RESEÑA HISTÓRICA
El desarrollo de UML comenzó en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational
Software Corporation comenzaron a trabajar en la unificación de los lenguajes de modelado Booch y
OMT, desde este momento fueron reconocidos mundialmente en el desarrollo de metodologías
orientadas a objetos. Así, en octubre de 1995, terminaron su trabajo de unificación obteniendo el
borrador de la versión 0.8 del denominado Unified Method. Hacia fines de este mismo año, Ivar Jacobson
(creador de la metodología OOSE - Object Oriented Software Engineer) se unió con Rational Software
para obtener finalmente UML 0.9 y 0.91 en junio y octubre de 1996, respectivamente.
Igualmente, UML incorpora ideas de otros metodólogos entre los que podemos incluir a Peter Coad,
Derek Coleman, Ward Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor,
Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs-Brock
y Ed Yourdon.
Luego, muchas organizaciones como Microsoft, Hewlett-Packard, Oracle, Sterling Software MCI
Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjectTime, Platinum Technology,
Ptech, Taskon, Reich Technologies, Softeam se asociaron con Rational Software Corporation para dar
como resultado UML 1.0 y UML 1.1. Hoy en día llegamos hasta UML 1.4 y UML 2.0. En la siguiente
figura se muestra de forma gráfica y resumida la evolución de UML.
 CARACTERÍSTICAS DE UML
− UML es una especificación de notación orientada a objetos. Se basa en las anteriores
especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número
de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que
representa la arquitectura del proyecto.

− UML permite describir un sistema en diferentes niveles de abstracción, simplificando la complejidad

sin perder información, para que tanto usuarios, líderes y desarrolladores puedan comprender
claramente las características de la aplicación.

− UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los
componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un
aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino
únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling
Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes
según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación
en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un
ejemplo.
− El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.

OBJETIVOS

Como objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos
de sus predecesores, sus protagonistas se propusieron lo siguiente:

• El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de
sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a
objetos (OO).
• Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
• Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
• Manejar los problemas típicos de los sistemas complejos de misión crítica.

Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más
utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre
diferentes tipos de sistemas (no sólo software, sino también en el ámbito de los negocios), al aclarar las
fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos
de la OO.

El UML es un lenguaje para construir modelos; no guía al

desarrollador en la forma de realizar el análisis y diseño orientados a
objetos ni le indica cuál proceso de desarrollo adoptar.
 MODELO: Nociones Generales

El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema
para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo
a partir de una especificación. Un modelo es una abstracción de algo, que se elabora para comprender
ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión
del original y por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades de
la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la
música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de
empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos,
modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de
modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el
que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones
funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una
abstracción de la realidad que tiene en sí misma información sobre las principales características de
ésta.
Los modelos además, al no ser una representación que incluya todos los detalles de los originales,
permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en
la Metodología OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por
distintas razones:
• Es posible enseñar al cliente una posible aproximación de lo que será el producto final.
• Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el
resultado.
• Reducen la complejidad del original en subconjuntos que son fácilmente tratables por
separado.
Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes
del problema y omite el resto. Los lenguajes de programación que estamos acostumbrados a utilizar no
son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificación
total con detalles que no son importantes para el algoritmo que están implementando.
Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo
de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas
que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de
una colección de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que
conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los
elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para
obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.
 DIAGRAMAS: Vistazo General

En todos los ámbitos de la ingeniería se construyen modelos, en realidad, simplificaciones de la

realidad, para comprender mejor el sistema que vamos a desarrollar: los arquitectos utilizan y construyen
planos (modelos) de los edificios, los grandes diseñadores de coches preparan modelos en sistemas
CAD/CAM con todos los detalles y los ingenieros de software deberían igualmente construir modelos de
los sistemas software.
Para la construcción de modelos, hay que centrarse en los detalles relevantes mientras se ignoran
los demás, por lo cual con un único modelo no tenemos bastante. Varios modelos aportan diferentes
vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes. Así, UML recomienda
la utilización de nueve diagramas para representar las distintas vistas de un sistema.

Los diagramas de UML son los siguientes:

Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola en descripciones de

acciones ejecutadas por un sistema para obtener un resultado.
Se utiliza para entender el uso del sistema
Muestra el conjunto de casos de uso y actores(Un actor puede ser tanto un sistema como una persona)
y sus relaciones: es decir, muestra quien puede hacer qué y las relaciones que existen entre acciones
(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

Diagrama de Clases: muestra las clases (descripciones de objetos que comparten características
comunes) que componen el sistema y cómo se relacionan entre sí.

Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. A
diferencia de los diagramas anteriores, estos diagramas se enfocan en la perspectiva de casos reales o
prototipos. Es un diagrama de instancias de las clases mostradas en el diagrama de clases.

Diagrama de Secuencia: enfatiza la interacción entre los objetos y los mensajes que intercambian entre
sí junto con el orden temporal de los mismos.

Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos resaltando la

organización estructural de los objetos en lugar del orden de los mensajes intercambiados.

El diagrama de secuencia y el diagrama de colaboración: muestran a los diferentes objetos y las

relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas
diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de
vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.

Diagrama de Estados: Se utiliza para analizar los cambios de estado de los objetos. Muestra los
estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que
reaccionen a eventos.

Diagrama de Actividades: Es un caso especial del diagrama de estados, simplifica el diagrama de

estados modelando el comportamiento mediante flujos de actividades. Muestra el flujo entre los objetos.
Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
Diagrama de Componentes: muestra la organización y las dependencias entre un conjunto de
componentes. Se usan para agrupar clases en componentes o módulos.

Diagrama de Despliegue (o implementación): muestra los dispositivos que se encuentran en un

sistema y su distribución en el mismo. Se utiliza para identificar Sistemas de Cooperación: Durante el
proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y que otros
sistemas dependerán de él.

Clasificación de Diagramas
Se dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que
dan una visión dinámica.

1. Diagramas de clase
Diagramas estáticos 2. Diagramas de objeto
o Estructurales 3. Diagramas de componentes
4. Diagramas de implementación

1. Diagrama de secuencia
2. Diagrama de colaboración
Diagramas dinámicos 3. Diagrama de estado
o de Comportamiento 4. Diagrama de actividad
5. Diagrama de casos de uso

La practica de crear diagramas para visualizar sistemas desde perspectivas o vistas diferentes no
está limitado a la industria de la construcción. En el contexto del software, existen cinco vistas
complementarias que son las más importantes para visualizar, especificar, construir y documentar la
arquitectura del software. En el UML las vistas existentes son:

1. Vista casos de uso: se forma con los diagramas de casos de uso, colaboración, estados y
actividades.
2. Vista de diseño: se forma con los diagramas de clases, objetos, colaboración, estados y
actividades.
3. Vista de procesos: se forma con los diagramas de la vista de diseño. Recalcando las clases y
objetos referentes a procesos.
4. Vista de implementación: se forma con los diagramas de componentes, colaboración, estados y
actividades.
5. Vista de despliegue: se forma con los diagramas de despliegue, interacción, estados y actividades.

Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y
UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos
UML esta pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y
debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de líneas
de código y ser realizados por equipos de centenares de programadores.
 En la práctica todos los diagramas son bidimensionales, pero el UML permite crear diagramas en tres
dimensiones como en modelos donde se puede "entrar" al modelo para poderlo visualizar por dentro.
Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este
representa una parte importante del sistema, pero solo representa una vista estática, es decir muestra
al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes
cuando el sistema empieza a funcionar.
 Diagramas Estáticos

Diagrama de Clases

En el diagrama de clases como ya hemos comentado será donde definiremos las características de
cada una de las clases y relaciones de dependencia y generalización. Es decir, es donde daremos rienda
suelta a nuestros conocimientos de diseño orientado a objetos, definiendo las clases e implementando
las ya típicas relaciones de herencia y agregación.
Este diagrama sirve para visualizar las relaciones entre las clases que involucran el sistema, las
cuales pueden ser asociativas, de herencia, de uso y de contenido.
Se utiliza cuando necesitamos realizar un Análisis de Dominio: El analista se entrevista con el cliente
con el objetivo de conocer las entidades principales en el dominio del cliente. Durante la conversación
entre el cliente y el analista se deben tomar apuntes. Desde estos apuntes, se buscarán las clases para
los objetos del modelo buscando los sustantivos (ej: proveedor, pedido, factura, etc.) y convirtiéndolos
en clases. Después se verá que algunos de estos sustantivos pueden ser atributos de otros en vez de
entidades por si mismas. También se buscarán los métodos para estas clases buscando los verbos (ej:
Calcular, imprimir, Agregar,..)

Elementos

Un diagrama de clases esta compuesto por los siguientes elementos:

• Clase: atributos, métodos y visibilidad.

• Relaciones: Herencia, Asociación, Ensamblado y Uso.

Clase
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de
una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta
Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:
• Superior: Contiene el nombre de la Clase
• Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden
ser private, protected o public).
 • Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto
con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

• Balance
Puede realizar las operaciones de:
• Depositar
• Girar
• y Balance

El diseño asociado es:

Atributos
Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la
clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo,
e incluso su valor por defecto.
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de
comunicación y visibilidad de ellos con el entorno, estos son:

• public : Indica que el atributo será visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.

• private : Indica que el atributo sólo será accesible desde dentro de la clase (sólo
sus métodos lo pueden accesar).

• protected : Indica que el atributo no será accesible desde fuera de la clase, pero
si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver
herencia).

Los atributos definen la estructura de una clase y de sus correspondientes objetos. El atributo define
el valor de un dato para todos los objetos pertenecientes a una clase.
Ejemplo: Nombre, edad, peso, son atributos de la clase persona. Color, precio, modelo, son atributos
de la clase automóvil.
Los atributos corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos.
Ejemplo: Nombre, edad, color, son sustantivos. Juan, 24, son sustantivos, y verde es un adjetivo.
 Se debe definir un valor para cada atributo de una clase. Los valores pueden ser iguales o distintos
en los diferentes objetos. No se puede dar un valor en un objeto si no existe un atributo correspondiente
en la clase.
Ejemplo: el valor del atributo edad puede ser "24" para los objetos Juan Pérez y María López, y "15"
para Ramón Martínez.
Dentro de una clase, los nombre de los atributos deben ser únicos (aunque puede aparecer el mismo
nombre de atributo en diferentes clases).
Ejemplo: Las clases persona y compañía pueden tener ambas un atributo dirección, en cambio no
pueden existir dos atributos llamados dirección dentro de la clase persona.
Los atributos no tienen ninguna identidad, al contrario de los objetos.
Ejemplo: Los atributos nombre y edad de la clase persona tienen valores simples. El valor para
nombre puede ser "Juan" o "María", mientras que el valor para edad puede ser "17" o "25". (Nótese que
pudieran existir dos objetos distintos con exactamente el mismo nombre y edad, donde estos
identificarían dos personas distintas.)
Un atributo como se ha definido en esta sección se conoce también como atributo básico.

Notación extendida

Diagrama de clases, para la clase Persona, conteniendo diferente nivel de detalle.

 Identificadores
En el momento de incluir atributos en la descripción de una clase se debe distinguir entre los
atributos los cuales reflejan las características de los objetos en el mundo real, y los identificadores los
cuales son utilizados exclusivamente por razones de implementación. Estos identificadores internos del
sistema no deben ser incluidos como atributos.
Ejemplo: Número del Seguro Social, o número de la licencia de conducir, son identificadores válidos
del mundo real, en cambio un identificador para distinguir entre objetos de tipo persona no se debe incluir
en el diagrama. En la siguiente figura se muestra la forma incorrecta de incluir un identificador
(“identificador : ID”) en la clase del objeto, seguido por la forma correcta (omitido).

Atributos Derivados
Los atributos básicos son atributos independientes dentro del objeto. En contraste, los atributos
derivados son atributos que dependen de otros atributos. Los atributos derivados dependen de otros
atributos del objeto, los cuales pueden ser básicos o derivados. La notación es una diagonal como prefijo
del atributo, como se muestra en la siguiente figura:

Ejemplo: El Area de un Rectángulo se puede calcular conociendo su Ancho y Largo, por lo cual no
se define como una atributo básico de la caja, sino como un atributo derivado:
 Restricciones de Atributos
Los valores de los atributos de una clase pueden restringirse. La notación para una restricción es
incluir, por debajo de la clase y entre corchetes, la restricción para los valores del atributo, como se
muestra en la siguiente figura

Ejemplo: Un Rectángulo puede restringir que su Ancho y Largo sean siempre iguales, lo que es
equivalente a un Cuadrado. Así mismo, el Area del Rectángulo está definida como el Ancho por el Largo.
Las dos restricciones se muestran a continuación:
 Métodos

Un método u operación es la implementación de un servicio de la clase, que muestra un

comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de
la clase que hagan algo.
Las operaciones son funciones o transformaciones que se aplican a todos los objetos de una clase
particular. La operación puede ser una acción ejecutada por el objeto o sobre el objeto.
Ejemplo: Arrojar, atrapar, inflar, y patear, son operaciones para la clase pelota. Abrir, cerrar, ocultar,
y dibujar, son operaciones para la clase ventana.
Las operaciones deben ser únicas dentro de una misma clases, aunque no necesariamente para
diferentes clases.
Ejemplo: Las clases pelota y libro pueden las dos tener operaciones de comprar, pero no pueden
tener cada una dos operaciones comprar.
No se debe utilizar el mismo nombre para operaciones que tengan un significado totalmente
diferente.
Ejemplo: No se debe utilizar el mismo nombre invertir para la operación de invertir una figura y para
la operación de invertir una matriz, ya que son operaciones totalmente diferentes. Invertir una figura es
rotarla por 180 grados, mientras que invertir una matriz M es encontrar su inverso N, para que MxN = 1.
Se deben usar nombres diferentes, como invertir-figura e invertir-matriz.
Las operaciones pueden tener argumentos, o sea, una lista de parámetros, cada uno con un tipo, y
pueden también devolver resultados, cada uno con un tipo.
 Ejemplo: En la siguiente figura se muestra dos clases, Figura y Archivo, conteniendo atributos y
operaciones. Mover y Rotar son operaciones de Figura conteniendo los argumentos V de tipo vector y
Angulo, respectivamente. Ambas operaciones devuelven un resultado de tipo Booleano el cual devuelve
un valor de Cierto o Falso (True o False).
Imprimir es una operación de Archivo conteniendo un argumento D de tipo dispositivo que puede
ser el nombre de una impresora, y el número N de copias a imprimir. El resultado puede ser un valor
booleano.

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos
pueden tener las características:

• public : Indica que el método será visible tanto dentro como fuera de la clase,
es decir, es accsesible desde todos lados.

• private : Indica que el método sólo será accesible desde dentro de la clase
(sólo otros métodos de la clase lo pueden accesar).

• protected : Indica que el método no será accesible desde fuera de la clase,

pero si podrá ser accesado por métodos de la clase además de métodos de las
subclases que se deriven (ver herencia).

Relaciones entre Clases

Existen tres relaciones diferentes entre clases, Dependencias, Generalización y Asociación. En las
relaciones se habla de una clase destino y de una clase origen. La origen es desde la que se realiza la
acción de relacionar. Es decir desde la que parte la flecha, la destino es la que recibe la flecha.
Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos
o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de
las relaciones indica el grado y nivel de dependencia, es decir especifica cuantas instancias de una clase
se pueden relacionar a una sola instancia de otra clase.
 Se anotan en cada extremo de la relación y éstas pueden ser:

− uno-uno
− uno-muchos(1...*)
− muchos-muchos(* *)
− opcional (0..1 )
− número fijo: m (m denota el número).

Diagrama de clases describiendo una multiplicidad de "uno-uno".

Diagrama de clases describiendo una multiplicidad de "uno-muchos".

Diagrama de clases describiendo una multiplicidad de "muchos-muchos".

La notación para representar una relación opcional, donde la multiplicidad es "uno" o "cero",
escribiendo una relación opcional, 0 o 1. Esto significa que dos objetos pueden o no estar conectados,
y si lo están corresponden a una multiplicidad de 1.

Diagrama de clases describiendo una multiplicidad "opcional".

Herencia (Especialización/Generalización)
Las clases con atributos y operaciones comunes se pueden organizar de forma jerárquica, mediante
la herencia. La herencia es una abstracción importante para compartir similitudes entre clases, donde
todos los atributos y operaciones comunes a varias clases se pueden compartir por medio de la
superclase, una clase más general. Las clases más refinadas se conocen como las subclases.
Ejemplo: Las Impresoras Láser, de Burbuja, y de Matriz, son todas subclases de la superclase
Impresora. Los atributos generales de una Impresora son el Modelo, Velocidad, y Resolución, mientras
que sus operaciones son Imprimir y Alimentar.
La Herencia es útil para el modelo conceptual al igual que para la implementación. Como modelo
conceptual da buena estructuración a las clases. Como modelo de implementación es un buen vehículo
para no replicar innecesariamente el código. Generalización define una relación entre una clase más
generalizada, y una o más versiones refinadas de ella.
Ejemplo: La clase Impresora es una generalización de las clases Impresoras Láser, de Burbuja, y
de Matriz.
Especialización define una relación entre una clase más general, y una o más versiones
especializadas de ella.
Ejemplo: Impresoras Láser, de Burbuja, y de Matriz, son todas especializaciones de Impresoras.
La superclase generaliza a sus subclases, y las subclases especializan a la superclase. El proceso
de especialización es el inverso de generalización. Una instancia de una subclase, o sea un objeto, es
también una instancia de su superclase.
Ejemplo: Cuando se crea un objeto de tipo Impresora Láser, este objeto incluye toda la información
descrita en la subclase Impresora Láser, al igual que en la superclase Impresora; por lo tanto se
considera que el objeto es una instancia de ambas.
La herencia es transitiva a través de un número arbitrario de niveles. Los ancestros de una clase
son las superclases de una clase en cualquier nivel superior de la jerarquía, y los descendientes de una
clase son las subclases de una clase en cualquier nivel inferior de la jerarquía.
Ejemplo: Si además de Impresora de Burbuja, se define una clase más especializada como
Impresora de Burbuja Portátil, entonces Impresora e Impresora de Burbuja son ancestros de la clase
Impresora de Burbuja Portátil, mientras que Impresora de Burbuja e Impresora de Burbuja Portátil son
descendientes de Impresora.
La herencia indica que una subclase hereda los métodos y atributos especificados por una Super
Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las
características y atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camioneta heredan de Vehículo, es decir, Auto posee las
Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable,
en cambio Camioneta también hereda las características de Vehículo (Precio, VelMax, etc) pero posee
como particularidad propia Tara y Carga.
Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a
instancias de Vehículo, Auto y Camioneta, pues tiene definición publica, en cambio atributos como
Descapotable no son visibles por ser privados.

(Los nombres de atributos y operaciones deben ser únicos en la jerarquía de herencia.)

Ejemplo: Una Impresora de Burbuja Portátil incorpora todas las características, primero de una
Impresora, y luego de una Impresora de Burbuja, conteniendo valores para todos los atributos
ancestrales y pudiéndose aplicar todas las operaciones ancestrales.
La generalización se puede extender a múltiples niveles de jerarquías, donde una clase hereda de
su superclase, que a su vez hereda de otra superclase, hacia arriba en la jerarquía. En otras palabras,
las relaciones entre subclases y superclases son relativas. La herencia define una jerarquía de clases
donde existen ancestros y descendientes, que pueden ser directos o no.

Ejemplo: Un Barco tiene un Nombre, Fabricante, y Costo. Tipos especiales de Barco, como Velero,
tienen además de estas características básicas, un Número de Velas, mientras que otro tipo especial de
Barco, como Barco a Motor, tiene un Motor. Barco es la clase básica (la superclase) mientras que Velero
y Barco a Motor son las clases refinadas (las subclases). Se debe definir las características básicas de
los barcos una sola vez, y luego añadir detalles para veleros, barcos a motor, etc.
 Diagrama de clases describiendo diferentes tipos de Mueble, Asiento y Mesa, con sus
respectivas subclases.

Ejemplo: Una jerarquía conteniendo una superclase Mueble, y varias subclases Mesa y Asiento,
puede ser extendida con nuevas subclases, como Mesa Circular, Mesa Rectangular, mientras que un
Asiento puede extenderse con las subclases Silla, Sillón, y Taburete.
Cada clase tiene sus propios atributos los cuales se van especializando a medida que las clases
son cada vez más especializadas. Nótese que no necesariamente todas las clases tienen que incluir
atributos.

Asociación
La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si.
Una asociación describe la relación entre clases de objetos, y describe posibles ligas, donde una
liga es una instancia de una asociación, al igual que un objeto es una instancia de una clase.

Diagrama de clases conteniendo la asociación estudia-en entre Estudiante y Universidad.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra
solo puede tener asociado un cliente.

Grado de la Asociación
 El grado de una asociación se determina por el número de clases conectadas por la misma
asociación. Las asociaciones pueden ser binarias, ternarias, o de mayor grado. Las asociaciones se
consideran binarias si relacionan solo dos clases.
Ejemplo: La asociación entre Persona e Instituto es una asociación binaria.
Las asociaciones pueden ser de mayor grado si relacionan a la misma vez más de dos clases.
Aparte de relaciones binarias, lo más común son relaciones ternarias (entre tres clases), relaciones de
más alto nivel son mucho menos comunes. Mientras el grado de una relación aumenta, su comprensión
se dificulta, y se debe considerar partir las relaciones en varias relaciones binarias.
Ejemplo: Puede existir una relación ternaria entre Estudiante, Profesor, y Universidad donde "un
estudiante estudia con un profesor en una universidad".
El grado de las ligas corresponden al de las asociaciones.

Diagrama de clases describiendo una asociación ternaria entre Estudiante, Profesor y

Universidad.

Asociaciones Reflexivas
Las asociaciones pueden ser reflexivas, relacionando distintos objetos de una misma clase.
Ejemplo: Para una clase persona puede existir una asociación pariente que describe que dos objetos
de tipo persona, como Juan Pérez y Laura Pérez son parientes.
El grado de una asociación reflexiva puede ser binario, ternario, o de mayor grado, dependiendo del
número de objetos involucrados.
Ejemplo: Para la clase persona puede existir una asociación ternaria entre tres personas donde uno
es el abuelo, el otro es el hijo del abuelo, y el tercero es el nieto del abuelo.
Las asociaciones reflexivas relacionan distintos objetos de una misma clase.
Ejemplo: Juan Pérez es pariente-de Laura Pérez, donde ambos son objetos de tipo Persona, como
se muestra en la Figura

Diagrama de instancias describiendo una asociación reflexiva objetos de la clase Persona.

Ejemplo: La asociación reflexiva pariente-de para la clase Persona se muestra en la siguiente figura

Diagrama de clases describiendo una asociación reflexiva para la clase Persona.

 Atributos de Liga (o Asociación)
Al igual que un atributo de clase es propiedad de la clase, un atributo de asociación (o atributo de
liga) es propiedad de una asociación. La notación es similar a la usada para los atributos de clases,
excepto que se añade a la asociación, y no se incorpora un nombre de clase, como se muestra en la
siguiente figura:

Ejemplo: Para una asociación entre Persona y Compañía, se puede definir los atributos salario y
puesto como atributos de la asociación trabaja-para, como se muestra en la Figura de abajo:

Diagrama de clases para Persona y Compañía conteniendo los atributos de asociación salario y puesto.

Diagrama de objetos para Raúl González e IBM conteniendo el valor de $100,000 para el
atributo de asociación salario, y gerente para el atributo de liga puesto.
 Ensamblados: Agregación y Composición

Los ensamblados, en particular la agregación y composición, son formas especiales de asociación

entre un todo y sus partes, en donde el ensamblado está compuesto por sus componentes. El
ensamblado es el objeto central, y la estructura completa se describe como una jerarquía de contenido.

• Agregación:

(el objeto base utiliza al incluido para su funcionamiento). Es un tipo de relación dinámica, en
donde el tiempo de vida del objeto incluido es independiente del que lo incluye.

• Composición:

(el Objeto base se construye a partir del objeto incluido). Es un tipo de relación estática, en
donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo
incluye.

Un ensamblado puede componerse de varias partes, donde cada relación se considera una relación
separada. En el caso de agregación, las partes del ensamblado pueden aparecer en múltiples
ensamblados. En el caso de composición, las partes del ensamblado no pueden ser compartidas entre
ensamblados.
Ejemplo: Una Red de Computadoras se puede considerar un ensamblado, donde las Computadoras
son sus componentes. Este también es un ejemplo de agregación, ya que las Computadoras pudieran
ser partes de múltiples Redes de Computadoras a la vez. Adicionalmente, las Computadoras pueden
existir independientemente de la existencia de la Red de Computadoras.
Ejemplo: Un Automóvil se puede también considerar un ensamblado, donde el Motor y la Carrocería
son sus componentes. Este también es un ejemplo de composición, ya que el Motor y la Carrocería son
partes del Automóvil, y a diferencia de la agregación, no pueden ser compartidos entre distintos
Automóviles a la vez.
Adicionalmente, no tiene mucho sentido que el Motor y la Carrocería existan de manera
independiente al Automóvil, por lo cual la composición refleja de manera importante, el concepto de
propiedad.
El ensamblado tiene propiedades de transición: Si A es parte de B y B es parte de C; entonces A es
parte de C.
Ejemplo: Si el Motor es parte del Automóvil, entonces sus propiedades, como su posición y
velocidad, están dadas por la posición y velocidad del Automóvil.
El ensamblado es antisimétrico: Si A es parte de B, entonces B no es parte de A. Estas propiedades
se propagan entre el ensamblado y sus componentes.
Ejemplo: Si el Motor es parte del Automóvil, entonces el Automóvil no es parte del Motor.
− Se considera un ensamblado y no una asociación regular:
− Si se puede usar la frase "parte-de" o "consiste-de" o "tiene";
− Si algunas operaciones en el todo se pueden propagarse a sus partes;
− Si algunos atributos en el todo se pueden propagar a sus partes;
El ensamblado es común en los objetos interfaz. En un sistema de ventanas, por ejemplo, una
ventana puede consistir de botones, menús, y barras (“scrollbars”), cada una modelada por su propio
objeto interfaz. El resultado es una estructura de interfaz en forma de árbol. La decisión de usar
ensamblados es un poco arbitraria, y en la práctica no causa grandes problemas la distinción imprecisa
entre agregación, composición y asociación, aunque es bueno ser consistente.

La notación para un ensamblado, en particular para un agregado, es un diamante adherido al lado

del objeto correspondiente al ensamblado total, conectado por una línea a sus componentes, como se
muestra en la siguiente figura

Ejemplo: El Automóvil con sus componentes, Motor y Carrocería, se muestran en el siguiente

diagrama:

Ejemplo: Una computadora personal (PC) está compuesta por uno o varios monitores, un sistema, un
teclado y opcionalmente un ratón. El sistema tiene un chasis, un procesador central (CPU), varias
tarjetas de memoria (RAM), y opcionalmente un ventilador. El diagrama se muestra en la siguiente figura
 Otro Ejemplo:

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 del
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:

Nombre del
objeto

Notación para un objeto

objeto.
Ejemplo: Los objetos Juan Pérez y UNLaR se representan como se muestra.

Juan Pérez UNLaR

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

Como se menciono al principio de esta sección el Diagrama de Objetos representa 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.
 r:Robot
[movimiento]

<<global>>
m:Mundo :Elemento
sinAsignar

a1:Area a2:Area

p1:Pared p1:Pared d8:Puerta p1:Pared

Anchura = 36 Anchura = 96 Anchura = 36 Anchura = 96

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 parte
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 este 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 agente 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 d e 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 objeto
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 como 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

• http://www-gris.det.uvigo.es/~avilas/UML/node49.html