1. MODULO
LENGUAJE UNIFICADO DE MODELADO UML
ING. HAROLD CABRERA MEZA
UNIVERSIDAD NACIONAL ABIERTA Y A
DISTANCIA
SAN JUAN DE PASTO, 2006
1

2. TABLA DE CONTENIDO
INTRODUCCION .................................................................................................... 6
1. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO ..................... 7
1.1. QUÉ ES UML?................................................................................................. 7
1.1.2. UML NO ES UN MÉTODO ........................................................................... 8
1.1.3. MODELOS .................................................................................................... 9
1.1.4. ELEMENTOS COMUNES A TODOS LOS DIAGRAMAS .......................... 10
1.2. MODELADO ESTRUCTURADO ................................................................... 11
1.2.1. BLOQUES DE CONSTRUCCIÓN DE UML................................................ 11
1.2.2. CLASES...................................................................................................... 15
1.2.3. OBJETOS ................................................................................................... 17
1.2.4. ASOCIACIONES......................................................................................... 18
1.2.5. DIAGRAMAS .............................................................................................. 20
1.2.6. DIAGRAMAS DE CLASE ........................................................................... 23
1.2.7. CARACTERÍSTICAS AVANZADAS DE LAS CLASES Y RELACIONES . 26
1.2.8. INTERFACES, TIPOS Y ROLES ................................................................ 31
1.2.9 PAQUETES E INSTANCIAS ...................................................................... 35
1.2.10. HERENCIA Y POLIMORFISMO ............................................................... 36
2. CARACTERISTICAS DEL MODELADO UML ................................................. 38
2.1. DIAGRAMAS UTILIZADOS EN UML ............................................................ 38
2

3. 2.1.1. DIAGRAMAS DE OBJETOS ...................................................................... 38
2.1.2. DIAGRAMAS DE CASOS DE USO............................................................ 40
2.1.3. DIAGRAMAS DE INTERACCIÓN .............................................................. 45
2.1.4. DIAGRAMAS DE ACTIVIDADES ............................................................... 47
2.2. MODELADO DINÁMICO ............................................................................... 51
2.2.1 EVENTOS Y SEÑALES............................................................................... 51
2.3.2 MÁQUINAS DE ESTADO............................................................................ 53
2.4.3 TIEMPO Y ESPACIO ................................................................................... 55
2.4.4 DIAGRAMAS DE ESTADO ......................................................................... 56
2.3. MODELADO ARQUITECTÓNICO................................................................. 57
2.3.1. COMPONENTES, DESPLIEGUE, COLABORACIONES Y PATRONES... 57
2.3.2. DIAGRAMAS DE COMPONENTES ........................................................... 61
2.3.3. DIAGRAMAS DE DESPLIEGUE ................................................................ 62
2.3.4. SISTEMAS Y MODELOS ........................................................................... 63
3. DESARROLLO ORIENTADO A OBJETOS CON UML ................................... 66
3.2. FASE DE PLANIFICACIÓN Y ESPECIFICACIÓN DE REQUISITOS ........... 68
3.2.1 ACTIVIDADES ............................................................................................. 68
3.2.2. REQUISITOS .............................................................................................. 68
3.2.3. CONSTRUCCIÓN DEL MODELO DE CASOS DE USO............................ 74
3.2.4. PLANIFICACIÓN DE CASOS DE USO SEGÚN CICLOS DE
3

4. DESARROLLO ..................................................................................................... 75
3.3. DISEÑO DE ALTO NIVEL ............................................................................. 76
3.3.1 ACTIVIDADES ............................................................................................. 77
3.3.2. MODELO CONCEPTUAL........................................................................... 77
3.3.3. DIAGRAMAS DE SECUENCIA DEL SISTEMA ......................................... 79
3.3.4. DIAGRAMAS DE ESTADOS ...................................................................... 81
3.4. DISEÑO DE BAJO NIVEL ............................................................................. 82
3.4.1 ACTIVIDADES ............................................................................................. 82
3.4.2. CASOS DE USO REALES ......................................................................... 82
3.4.3. DIAGRAMAS DE INTERACCIÓN .............................................................. 83
3.4.4. CONSTRUCCIÓN DIAGRAMAS DE DISEÑO ........................................... 88
3.5. FASES DE IMPLEMENTACIÓN Y PRUEBAS .............................................. 90
4

5. PRIMERA UNIDAD
INTRODUCCIÓN AL LENGUAJE UNIFICADO DE
MODELADO
5

6. INTRODUCCION
Unas de las etapas vitales para un diseñador de software, es el análisis y diseño
de sistemas, el análisis de sistemas es el proceso de clasificación e interpretación
de hechos, diagnóstico de problemas y manejo de la información para hacer
mejoras al sistema, siendo el diseño la fase de planificación, reemplazo o
complementación de un sistema organizacional existen. Para estas fases del
desarrollado de software se han desarrollado diferentes modelos con los cuales se
han obtenido resultados satisfactorios, mas no óptimos puesto que se han
sesgado unos con otros.
Es entonces cuando se plantea la necesidad de crear un mismo lenguaje que
permita modelar sistemas, de manera que se pueda en cualquier momento
construir software partiendo de un solo esquema de modelado, tanto estructural
como orientado a objetos
El Lenguaje Unificado de Modelado (Unified Modelin Language UML), es un
lenguaje estándar para escribir planos de software, UML se puede utilizarse para
visualizar, especificar, construir y documentar los artefactos de un sistema que
involucra una gran cantidad de software. UML 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.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real. UML ofrece
nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo,
que cubre todas las vistas necesarias para desarrollar y luego desplegar tales
sistemas.
El curso académico denominado Lenguaje de Modelado -UML- Electiva, esta
orientado a hacia el manejo adecuado de las herramientas que ofrece el lenguaje
de modelado orientado a objetos, desde la construcción de los diagramas de
interacción del sistema hasta la aplicación del modelo en un caso real de
desarrollo.
6

7. 1. INTRODUCCIÓN AL LENGUAJE UNIFICADO DE MODELADO
1.1. Qué es Uml?
El Lenguaje Unificado de Modelado (Unifield Modelin Language UML), es un
lenguaje estándar para escribir planos de software, UML se puede utilizarse para
visualizar, especificar, construir y documentar los artefactos de un sistema que
involucra una gran cantidad de software. UML 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.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real. UML ofrece
nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo,
que cubre todas las vistas necesarias para desarrollar y luego desplegar tales
sistemas .
UML es sólo un lenguaje y por tanto es tan solo una parte de un método de
desarrollo de software, además, es independiente del proceso, aunque para
utilizar óptimamente se debería usar en procesos que fuese dirigido por los casos
de uso, centrado en la arquitectura, interactivo e incremental
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, en 1996, el Object Management Group
(OMG), publicó una petición con propósito de un metamodelo orientado a objetos
de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como
una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas
rivales. Durante el transcurso de 1997, los seis promotores de las propuestas,
unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado
UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de
1997. El OMG llama a este documento OMG UML versión 1.1. El OMG estaba
actualmente en proceso de mejorar una edición técnica de esta
especificación, prevista su finalización para el 1 de abril de 1999.
7

8. 1.1.2. UML no es un método
Inicialmente los métodos son una técnica para llevar a cabo una acción, Uml es un
compendio de modelos que pueden ser interpretados de forma directa a una gran
variedad de lenguajes de programación como Java, C++ o Visual Basic, e incluso
a tablas en una base de datos relacional o una base de datos orientadas a objetos
UML se construye con modelos estándar sobre análisis y diseño de sistemas
orientados a objetos de las cuales las más populares se incluyen las siguientes:
Catálisis: Un método orientado a objetos que fusiona mucho del trabajo reciente
en métodos orientados a objetos, y además ofrece técnicas especificas para
modelar componentes distribuidos.
Objetory: Un método de Caso de Uso guiado para el desarrollo, creado por Ivar
Jacobson.
Shlaer/Mellor: El método para diseñar sistemas de tiempo real, puesto en marcha
por Sally Shlaer y Steven Mellor en dos libros de 1991, Ciclos de vida de Objetos,
modelando el Mundo en Estados y Ciclos de vida de Objetos, Modelando el
mundo en Datos (Prentice Hall). Shlaer/Mellor continúan actualizando su método
continuamente (la actualización más reciente es el OOA96 report), y
recientemente publicaron una guía sobre como usar la notación UML con
Shlaer/Mellor.
Fusión: Desarrollado en Hewlett Packard a mediados de los noventa como primer
intento de un método de diseño orientado a objetos estándar. Combina OMT y
Booch con tarjetas CRC y métodos formales.
(www.hpl.hp.com/fusion/file/teameps.pdf)
OMT: La Técnica de Modelado de Objetos fue desarrollada por James Rumbaugh
y otros, y publicada en el libro de gran influencia "Diseño y Modelado Orientado a
Objetos" (Prentice Hall, 1991). Un método que propone análisis y diseño
interactivo, más centrado en el lado del análisis.
Booch: Parecido al OMT, y también muy popular, la primera y segunda edición de
"Diseño Orientado a Objetos, con Aplicaciones" (Benjamin Cummings, 1991 y
8

9. 1994),
(Object-Oriented Design, With Applications), detallan un m odo ofreciendo
también diseño y análisis 'iterative', centrándose en el lado del diseño.
1.1.3. Modelos
Un modelo representa a un sistema software desde una perspectiva específica. Al
igual que la planta y el alzado de una figura en dibujo técnico nos muestran la
misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en
un aspecto distinto del sistema.
Los modelos de UML que se tratan en esta parte son los siguientes:
•Diagramas de clases: muestra un conjunto de clases, interfaces y
colaboraciones, así como sus relaciones, son los más comunes en el modelo
orientado a objetos y cubren las vistas de diseño estático de un sistema.
•Diagramas de Objetos: muestra un conjunto de objetos y sus relaciones,
representan instancias de los elementos encontrados en los diagramas de clases,
representado cubren las vistas de diseño estático de un sistema desde la
perspectiva de casos reales.
•Diagrama de Actividades: es un tipo especial de diagrama de estados que
muestra el flujo de actividades dentro de un sistema, cubren la vista dinámica de
un sistema. Son especialmente importantes al modelar el funcionamiento de un
sistema y resaltan el flujo de control de objetos.
•Diagrama de Componentes: muestra la organización y las dependencias entre
un conjunto de componentes, cubren la vista estática de un sistema.
•Diagrama de Despliegue: muestra la configuración de nodos de procesamiento
en tiempo de ejecución y los componentes que residen en ellos, cubren la vista de
despliegue estática de una arquitectura.
9

10. Diagrama de Casos de Uso: muestra un conjunto de casos de uso, actores y
relaciones, cubren la vista de casos de uso estática de un sistema.
•Diagrama de Secuencia: es un diagrama de interacción que resalta la
ordenación temporal de los mensajes.
•Diagrama de Colaboración: es un diagrama de interacción que resalta la
organización estructural de los objetos que envían y reciben mensaje.
•Diagrama de Estados: Muestra una máquina de estados, que consta de
estados, transiciones, eventos y actividades, cubren la vista dinámica de un
sistema, resaltan el comportamiento dirigido por eventos de un objeto.
1.1.4. Elementos comunes a todos los diagramas
Notas
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un
elemento de un diagrama. Es un modo de indicar información en un formato libre,
cuando la notación del diagrama en cuestión no nos permite expresar dicha
información de manera adecuada. Una nota se representa como un rectángulo
con una esquina doblada con texto en su interior. Puede aparecer en un diagrama
tanto sola como unida a un elemento por medio de una línea discontinua. Puede
contener restricciones, comentarios, el cuerpo de un procedimiento, etc.
Figura 1.
10

11. Dependencias
La relación de dependencia entre dos elementos de un diagrama significa que un
cambio en el elemento destino puede implicar un cambio en el elemento origen
(por tanto, si cambia el elemento destino habría que revisar el elemento origen).
Una dependencia se representa por medio de una línea de trazo discontinuo entre
los dos elementos con una flecha en su extremo. El elemento dependiente es el
origen de la flecha y el elemento del que depende es el destino (junto a él está la
flecha).
1.2. Modelado Estructurado
Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje y
esto requiere aprender tres elementos principales: los bloques básicos de
construcción de UML, las reglas que dictan cómo se pueden combinar estos
bloques básicos y algunos mecanismos comunes que se aplican a través de UML,
Una ves comprendida estas ideas, se pueden leer modelos UML y crear algunos
modelos básicos.
1.2.1. Bloques de Construcción de UML
El vocabulario de UML incluye tres clases de bloques de construcción
Elementos en UML
Hay 4 tipos de elementos en UML, elementos estructurales, elementos de
comportamiento, elementos de agrupación y elementos de anotación:
.
Figura 2.
11

12. Elementos Estructurales
Nombre Descripción Símbolo
Interfaz • Es una colección de operaciones que
especifica un servicio de una clase o
componente, representa el
comportamiento completo de una clase
o componente
Colaboración • Se definen como una interacción y es
una sociedad de roles y otros
elementos que colaboran para
proporcionar un comportamiento
cooperativo mayor que la suma de los
comportamientos de sus elementos
• las colaboración representan la
implementación de patrones que
forman un sistema
Caso de Uso • Es una descripción de secuencias de
acciones que un sistema ejecuta y que
produce un resultado observable de
interés para un actor particular
• Se utiliza para estructurar el
comportamiento en un modelo
Clase Activa • Es un clase objetos tienen uno o mas
procesos o hilos de ejecución y por lo
tanto pueden dar origen a actividades
de control
• Son iguales a las clases excepto en
que sus objetos representan elementos
cuyos comportamiento es concurrente
con otros elementos
Componente • Es una parte física y reemplazable de
un sistema que conforma con un
conjunto de interfaces y proporciona la
implementación de dicho conjunto
• Representa típicamente e
empaquetamiento físico de diferentes
elementos lógicos, como clases
interfaces y colaboraciones
Nodo • Es un elemento físico que existe en
Nodo1
tiempo de ejecución y representa un
rescursos computacional que dispone
de memoria y con frecuencia
capacidad de procesamiento
12

13. Estos siete elementos (clases, interfaces, colaboraciones, casos de uso, clases
activas, componentes y nodos) son los elementos estructurales básicos que se
pueden incluir en el modelo UML. También existen variaciones de estos siete
elementos, tales como actores, señales, procesos e hilos, y aplicaciones,
documentos, archivos, bibliotecas, páginas y tablas.
Los elementos de comportamiento son las partes dinámicas de los modelos
UML. Estos son los verbos de un modelo y representan comportamiento en el
tiempo y en el espacio.
• Interacción: Es un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos, dentro de un
contexto particular para alcanzar un propósito especifico
• Máquina de Estados: Es un comportamiento que especifica las secuencias
de estados por las que pasa un objeto o una interacción durante su vida en
respuesta a eventos
Estos dos elemento (interacciones y máquinas de estado) son los elementos de
comportamiento que se pueden incluir de un modelo UML, estos elementos están
conectados normalmente a diversos elementos estructurales, principalmente
clases, colaboraciones y objetos.
Los Elementos de agrupación son las partes organizativas de los modelos UML.
Estos son las cajas en las que pueden descomponerse un modelo
Paquete
• Es un mecanismo de propósito general para organizar elementos en grupos.
• En los paquetes se pueden agrupar los elementos estructurales, de
comportamiento e incluso otros elementos de agrupación
Los paquetes son los elementos de agrupación básicos con los cuales se puede
organizar un modelo UML. También hay variaciones, tales como los framework,
los modelos y los subsistemas
13

14. Relaciones
Existen cuatro tipos de la relaciones en UML
• Dependencias
• Asociaciones
• Generalizaciones
• Realización
Estas relaciones son los bloques básicos de construcción para las relaciones de
UML.
Relaciones en UML
Dependencia: Es una relación semántica entre dos elementos, en la cual un
cambio a un elemento pude afectar la semántica de otro elemento
Asociaciones: Es una relación estructural que describe un conjunto de enlaces,
los cuales son conexiones entre objeto y representa una relación estructural entre
un todo y sus partes
Diagramas
Un diagrama es la representación gráfica de un conjunto de elementos,
visualizando la mayoría de las veces como un grafo conexo de nodos (elementos)
y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde
diferentes perspectivas, de forma que un diagrama es una proyección de un
sistema, un diagrama representa una vista resumida de los elementos que
constituyen un sistema. (Los tipos de diagramas que utiliza UML se mencionan en
el Numeral 1.1.2. de este módulo).
14

15. 1.2.2. Clases
Una clase es una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semántica, las clases pueden
representar cosas que sean hardware, software o completamente conceptuales.
Las clases forman parte de una distribución equilibrada de responsabilidades en el
sistema
UML representa una representación gráfica de las clases como se muestra en la
figura ex,
Nombre Figura
Origen atributos
Mover()
Visualizar() operaciones
Figura 3.
Componentes de las Clases
Una clase es un descripción de un conjunto de objetos que comparten los mimos
atributo, operaciones, relaciones y semántica, gráficamente una clase se
representa como un rectángulo, en el cual se describen las características de los
objetos que representa, entre ellos tenemos
1. Nombre: una clase a de contener un nombre que la identifique, compuesto por
cualquier numero de letras y números exceptuado los dos puntos pues estos se
utilizan para separar el nombre de una clase y el paquete que lo contiene.
2. Atributos: es una propiedad de una clase identificada con un nombre, que
describe un rango de valores que pueden tomar las instancias de la propiedad.
Un atributo representa alguna propiedad del elemento que se está modelando
que es compartida por todos los objetos de esa clase, además, una clase puede
o no contener atributos. Por ejemplo un atributo de la clase estudiante es el
nombre, apellido, fecha Nacimiento, etc.
15

16. Estudiante
nombre
apellido atributos
fecha Nacimiento
Figura 4.
3. Operaciones: Es una abstracción de de algo que se puede haber a un objeto y
que es compartido por todos los objetos de la clase, las clases pueden tener o
no operaciones. Ejemplo en la clase estudiante se puede a los objetos
generados por ella, matricular, evaluar, aprobar y estas operaciones son
comunes a todos los objetos que se describen a través de la clase estudiante.
Estudiante
Nombre
Apellido
Fecha nacimiento
Matricular()
Evaluar() Operaciones
Aprobar()
Figura 5.
4. Responsabilidades: Es una obligación de las clases, al crear una clase, se esta
expresando que todos los objetos de esa clase tienen el mismo tipo de estado y
el mismo tipo de comportamiento, de forma mas general los atributos y
operaciones son las características por medio de la cuales se llevan a cabo las
responsabilidades de la clase. Gráficamente las responsabilidades se pueden
expresar en un comportamiento separado al final del icono de la clase.
Estudiante
nombre
apellido
fecha Nacimiento
matricular()
evaluar()
aprobar()
Responsabilidades
Respetar el
Reglamento Responsabilidades
Estudiantil
Figura 6.
16

17. Usos Comunes de las Clases
Las clases se utilizan para modelar y representar el conjunto de elementos de un
sistema de manera general (abstracciones), para determinar los problemas que se
intenta resolver y así implementar una solución.
Para definir las clases que intervienen dentro de un sistema se recomienda como
puntos de partida las siguientes consideraciones:
• Identificar aquellas cosas que utilizan los usuarios o programadores para
describir el problema o la solución
• Identificar las responsabilidades de cada clase y asegurarse que cada clase
existe
• Identificar los atributos y operaciones necesarios para cumplir sus
responsabilidades
• Hacer del conjunto de clases y sus responsabilidades un modelo equilibrado
donde no existan clase demasiado grandes ni pequeñas
• Cuando se dibuje una clase hay que mostrar solo aquellas propiedades de la
clase que sean importantes, como también sus atributos y operaciones
1.2.3. Objetos
Un objeto se representa de la misma forma que una clase. En el compartimiento
superior aparecen el nombre del objeto junto con el nombre de la clase
subrayados, según la siguiente sintaxis: nombre_del_objeto:nombre_de_la_clase
Puede representarse un objeto sin un nombre específico, entonces sólo aparece el
nombre de la clase.
Figura 7.
17

18. 1.2.4. Asociaciones
Es una relación estructural que especifica que los objetos de un elemento están
conectados con los objetos de otro. Dada una asociación entre dos clases, se
puede navegar desde un objeto de una clase hasta el objeto de otra clase, y
viceversa. Una asociación que conecta dos clases se dice binaria, sí conecta más
de dos clases se denomina asociación n-arias, las asociaciones se utilizarán
cuando se quieren representar relaciones estructurales.
Características de las Asociaciones y operaciones
Nombre de la Asociación y Dirección
El nombre de la asociación se utiliza para describir la naturaleza de la relación, es
opcional y se muestra como un texto que está próximo a la línea. Se puede añadir
un pequeño triángulo negro sólido que indique la dirección en la cual leer el
nombre de la asociación. En el ejemplo se puede leer la asociación como “Director
manda sobre Empleado”.
Figura 8.
Los nombres de las asociaciones normalmente se incluyen en los modelos para
aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado
abundante la información que se presenta, con el consiguiente riesgo de
saturación. En ese caso se puede suprimir el nombre de las asociaciones
consideradas como suficientemente conocidas. En las asociaciones de tipo
agregación y de herencia no se suele poner el nombre.
18

19. Multiplicidad
La multiplicidad es una restricción que se pone a una asociación, que limita el
número de instancias de una clase que pueden tener esa asociación con una
instancia de la otra clase. Puede expresarse de las siguientes formas:
• Con un número fijo: 1.
• Con un intervalo de valores: 2.5.
• Con un rango en el cual uno de los extremos es un asterisco Significa que es
un intervalo abierto. Por ejemplo, 2..* significa 2 o más.
• Con una combinación de elementos como los anteriores separados por comas:
1, 3..5, 7, 15..*.
• Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero
o más).
Roles
Un rol es simplemente la cara que la clase de un extremo de la asociación
presenta a la clase del otro extremo.
Figura 9.
19

20. Para indicar el papel que juega una clase en una asociación se puede especificar
un nombre de rol. Se representa en el extremo de la asociación junto a la clase
que desempeña dicho rol.
Agregación
El símbolo de agregación es un diamante colocado en el extremo en el que está la
clase que representa el “todo”.
Figura 10.
1.2.5. Diagramas
Un diagrama es una presentación gráfica de un conjunto de elementos, que la
mayoría de la veces se dibuja como un conjunto de elementos relacionados, los
diagramas se utilizan para representar un sistema desde diferentes perspectivas,
por esto UML a definido varios diagramas que permiten centrarse en diferentes
aspectos del sistema independientemente.
Un diagrama es una proyección gráfica de los elementos que configuran un
sistema. Por ejemplo, se podría tener cientos de clases en el diseño de un sistema
de recursos humanos de un empresa, pero no se podría ver la estructura o el
comportamiento de ese sistema observando un gran diagrama con todas sus
clases y relaciones, es entonces preferible realizar varios diagramas que
especifiquen las vistas relevantes solamente a ese subsistema definido, este tipo
de manejo de diagramas representativos por clases permite realizar agrupaciones
que muestran el funcionamiento general del sistema de forma particular pero
denotando el funcionamiento general del sistema con todos sus elementos
constitutivos.
20

21. Con el modelado de sistemas se obtienen deferentes tipos de vistas, las vistas
estáticas de los sistemas en UML se representan con 4 tipos de diagramas que se
describen a continuación
Diagramas Estructurales
los cuales comprenden los siguientes diagramas
• Diagramas de Clases
Representa un conjunto de clases, interfaces y colaboraciones, y las relaciones
entre ellas. Los diagramas de clases los diagramas más comunes en el modelado
de sistemas orientados a objetos. Estos diagramas se utilizan para describir las
vista de diseño estática de un sistema, incluyen clases activas se utilizan para
cubrir la vista de procesos estática de un sistema
• Diagramas de Objetos
Representa un conjunto de objetos y sus relaciones. Se utiliza para describir
estructuras de datos y las instancias de los elementos encontrados en los
diagramas de clases. Cubren la vista de diseño estática o la vista de proceso
estática de un sistema al igual que los diagramas de clases. Pero desde la
perspectiva de casos reales prototipos.
• Diagramas de Componentes
Muestra un conjunto de componentes y relaciones, se utilizan para describir la
vista de implementación estática de un sistema, se relacionan con los diagramas
de clases en que un componente normalmente se corresponde con una más
clases. Interfaces o colaboraciones
• Diagramas de despliegue
Muestra un conjunto de nodos y sus relaciones, se utilizan para describir la vista
de despliegue estática de una arquitectura, se relacionan con los diagramas de
componentes en que un nodo normalmente incluye uno o más componentes.
21

22. Diagramas de Comportamiento
Los cuales están compuestos por los siguientes diagramas
Diagramas de casos de uso
En el modelado orientado a objetos los diagramas de casos de uso son los que
representan en general el funcionamiento del sistema siendo estos los mas
utilizados como base del desarrollo de un modelo real, representa casos de uso,
actores y relaciones, se utilizan especialmente para organizar y modelar el
comportamiento de un sistema.
Diagramas de Secuencia
Es un diagrama de interacción que resalta la ordenación temporal de los
mensajes, este presenta un conjunto de objetos y los mensajes enviados por ellos.
Los objetos suelen ser instancias con nombre, pueden representar instancias de
otros elementos, tales como colaboraciones, componentes y nodos, se utilizan
para describir las vista dinámica de un sistema.
Diagramas de colaboración
Es un diagrama de interacción que resalta la organización estructural de los
objetos que envían y reciben mensajes, pueden representar instancias de otros
elementos como colaboraciones, componentes y nodos. Se utilizan para describir
la vista dinámica de un sistema.
Diagramas de estado
Representa una máquina de estados constituida por estados, transacciones,
eventos y actividades, se utilizan para representar la vista dinámica de un sistema
son especialmente importantes para modelar el comportamiento de una interfaz,
clase o una colaboración, resaltan en comportamiento dirigido por eventos de un
objeto.
Diagrama de Actividades
Muestra el flujo de actividades en un sistema, muestra el flujo secuencial o
ramificado de actividades y los objetos en los que actúa, son importantes para
22

23. modelar la función de un sistema así como para resaltar el flujo de control entre
objetos
1.2.6. Diagramas de Clase
Un diagrama de clases de uso muestra un conjunto de interfaces, colaboraciones
y sus relaciones. Gráficamente, un diagrama de clases es una colección de nodos
y arcos.
Los diagramas de clases contienen normalmente los siguientes elementos, clases,
interfaces, colaboraciones, relaciones de dependencia, generalización y
asociación. Los diagramas pueden también notas, restricciones, paquetes o
subsistemas, los cuales se usan para agrupar los elementos de un modelo en
partes más grandes.
Usos de los diagramas de clases
Se utilizan para modelar la vista estática de un sistema, muestra principalmente
los requisitos funcionales de un sistema y los servicios que el sistema debe
proporcionar a sus usuarios finales
Los diagramas de clases se utilizan cuado se modela la vista de diseño de un
sistema de la siguiente forma:
• Para modelar el vocabulario de un sistema
El modelado del vocabulario de un sistema implica tomar decisiones sobre que
abstracciones son parte del sistema en consideración y cuales caen fuera de sus
límites. Los diagramas de clases se utilizan para especificar estas abstracciones y
sus responsabilidades
• Para modelar colaboraciones simples
Una colaboración es una sociedad de clases, interfaces y otros elementos que
colaboran para proporcionar un comportamiento cooperativo mayor que la suma
de todos los elementos.
23

24. Cuando se crea un diagrama de clases, se esta modelando una parte de los
elementos y las relaciones que configuran la vista de diseño del sistema, por esta
razón cada diagrama de clases debe centrarse en una colaboración cada vez.
Para modelar una colaboración se debe tener en cuenta:
• Identificar los mecanismos que se quiere modelar, un mecanismo representa
una 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.
• Identificar las clases, interfaces y otras colaboraciones que participan en esta
colaboración identificando las relaciones entre estos elementos.
• Usar escenarios para recorrer la interacción entre estos elementos.
• Identificar las responsabilidades y hacer un reparto equilibrada de ellas en los
elementos que componen el sistema
Por ejemplo la siguiente figura muestra un conjunto de clases que muestran el
sistema de facturación y control de ventas de una empresa, las clases se centran
en la forma como se maneja la facturación de inmuebles y productos de consumo,
aparece una clase abstracta llamada factura que muestra a su vez 2 hijos
facturacomestibles y facturainmuebles a su vez las dos clases se muestran como
partes de otra clase denominada vendedor. La clase ventas tiene una asociación
uno a uno con vendedor y una asociación uno a muchos con controlvendedor no
se muestran atributos ni operaciones para la clase ventas pero sí se muestran sus
responsabilidades.
1 *
Ventas controlventas
1 1
Responsabilidad vendedor
Ventas promedio
Buscar clientes
1 1
facturacomestibles facturainmuebles
Factura
Registrar venta()
Registrar proveedor()
Registrar cliente()
Informes()
Figura 11.
24

25. • Para modelar un esquema lógico de base de datos
Este esquema representa el plano que permite el diseño conceptual de la base de
datos sea para una base de datos relacional o una base de datos orientada a
objetos. Para modelar un esquema tenemos en cuenta:
• Identificar las clases que van a ser persistentes en el diseño general de la
bases de datos.
• Crear un diagrama de clases que contenga estas clases y marcarlas como
persistentes.
• Expandir los detalles estructurales de estas clases, es decir, especificar los
detalles de sus atributos y centrar su atención en la asociaciones que
estructuran estas clases.
• Identificar las relaciones de las bases de datos sea uno a uno, uno a varios y
sus asociaciones.
• Definir de manera clara las reglas de negocio relativas a la manipulación de
datos dentro de la base de datos
La figura muestra un conjunto de clases extraídas de un sistema de información
que determina las relaciones entre los estudiantes, el profesor y el curso que el
estudiante va a estudiar
Universidad
Nombre: texto Departamento 0..1
Dirección: texto
Telefono: número tiene Nombre: texto
añadirProfesor()
añadirEstudiante() 1 1..* quitarProfesor ()
quitarEstudiante() obtenerProfesor ()
1..*
obtenerEstudiante()
añadirDepartamento() 1..*
quitarDepartamento()
obtenerDepartamento()
Asignado a
0..1
director
Estudiante Curso Profesor
* asiste * enseña
Nombre: texto Nombre: texto Nombre: texto
idEstudiante: número idCurso: número
* 1..*
Figura 12.
25

26. El anterior diagrama muestra en detalle cada una de las clases con sus
respectivos atributos, los cuales permiten construir la base de datos física,
comenzando por la parte inferior izquierda se encuentra las clases estudiantes,
curso y profesores, hay una asociación
Las clases se han marcado como persistentes, es decir, sus instancias se han
concebido para almacenar en una base de datos u otra forma de almacenamiento
persistente.
1.2.7. Características Avanzadas de las Clases y relaciones
El tipo más importante de clasificador en UML es la clase, una clase es una
descripción de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semántica. Sin embargo las clases no son el único tipo
de clasificador, existen otros tipos de clasificadores que ayudan a modelar:
• Interfaz: es una colección de operaciones que especifican un servicio de una
clase o componente
Figura 13.
• Tipos de datos: un tipo cuyos valores no tienen identidad, incluyendo los tipos
primitivos predefinidos.
<<type>>
int (valores entre -32000 y 320000)
Figura 14.
26

27. • Señal: la especificación de un estímulo asíncrono enviado entre instancias
<<signal>>
DisparoAlarma
Figura 15.
• Componente: una parte física y reemplazable de un sistema que conforma y
proporciona la realización de un conjunto de interfaces.
Kernell32
Figura 16.
• Nodo: un elemento físico que existe en tiempo de ejecución y representa un
recurso computacional, generalmente con alguna memoria y a menudo
capacidad de almacenamiento.
Figura 17.
• Caso de uso: descripción de una secuencia de acciones, incluye variantes, que
se ejecuta un sistema y produce un resultado observable para un actor
particular
Figura 18.
27

28. • Subsistema: agrupación de elementos, algunos de los cuales constituyen una
especificación del comportamiento de los otros elementos contenidos
<<subsystem>>
subsistema de servicio al
cliente
Figura 19.
Los clasificadores descritos anteriormente proporcionan al modelado de sistemas
una vista general de comportamiento del sistema mostrándolo en detalle en sus
atributos y operaciones
Generalidades de las clases
Es necesario saber que para el modelado de sistemas con Uml, las clases
muestran en la definición de sus atributos ciertos tipos de símbolos, los cuales
determinan si los elementos asociados a cada clase son públicos o privados por
ejemplo:
Si la marca de elemento es un +, indica que este elemento es de acceso público y
por lo tanto se pueden operar desde cualquier instancia del sistema. Por lo
contrario si el signo es -, indica que este elemento solo es de uso exclusivo de la
clase que lo contiene. Otro caso en los cuales los elementos de la clase son por
decirlo de alguna semi privados, solo se relacionan con las clases que han sido
descendientes de la clase padre se marcan con el símbolo #.
Cuando se usa una clase, es probable que se desee características de otras
clases y también permitir que otras clases más específicas hereden características
de ella. También se puede especificar que una clase no puede tener hijos, a este
elemento se le llama hoja y se especifica escribiendo la propiedad leaf bajo el
nombre de la clase. Otra característica de las clases es cuando esta no tiene
padres, este tipo de clases se denomina raíz y se denota escribiendo debajo del
nombre de la clase root.
Podemos observar el siguiente ejemplo de notación:
28

29. Factura(root)
Registrar venta()
Registrar proveedor()
Clase padre principal Registrar cliente()
Informes()
Facturacomestibles Facturainmuebles
Clases hijos
Mostrarusuario() Mostrarusuario() (leaf)
Clases hoja, no puede
tener mas hijos
Figura 20.
Las clases tienen muchas operaciones entre sí, las que se “heredan” entre clases
se denominan polimórficas esto ocurre cuando los objetos han ejecutado una
operación que esta definida en la clase que los contiene pero con la diferencia de
que la operación cambia de significado dependiendo del contexto donde se este
ejecutado.
Generalidades de las relaciones
Al modelar los elementos que constituyen el vocabulario de un sistema, también
hay que modelar cómo se relacionan entre sí estos elementos, las relaciones de
dependencia, las generalizaciones y las asociaciones son los tres bloques de
construcción de relaciones más importantes de UML. Observemos el
comportamiento de estas relaciones.
Relaciones de Dependencia:
Una dependencia es una relación de uso, la cual especifica que un cambio en la
especificación de un elemento puede afectar a otro elemento que lo utiliza, pero
no necesariamente a la inversa. Gráficamente, una dependencia se representa
29

30. como una línea continua dirigida hacia el elemento del que se depende. Las
dependencias se deben aplicar cuando se quiera representar que un elemento
utiliza a otro
Relaciones de Generalización
Una generalización es una relación entre un elemento (superclase o padre) y un
tipo mas efectivo de ese elemento (subclase o hijo). Por ejemplo, se puede
encontrar la clase general ventana junto a un tipo mas especifico ventaconmarco,
con una relación de generalización del hijo al padre, el hijo ventaconmarco
heredará la estructura y comportamiento del padre ventana, en una generalización
la instancia del hijo pueden usarse donde quiera que se puedan usar las
instancias del padre.
La generalización se manifiesta en la herencia simple que a veces es suficiente en
a mayoría de las veces, aunque, la herencia múltiple es mas adecuada,
gráficamente se muestra de la siguiente forma:
Figura 21.
En la figura anterior se muestra la clase activo con tres hijos: CuentaBancaria,
inmueble y valor dos de estos hijos (CuentaBancaria, Inmueble) tienen sus
propios hijos por ejemplo Accion y Bono son ambos hijos de valor
Dos de estos hijos (CuentaBancaria, Inmueble) heredan de varios padres
inmueble por ejemplo, es un tipo de activo, así como un tipo de Elemento-
Asegurable y CuentaBancaria, es un tipo de activo así como un
ElementoConInteres y un ElementoAsegurable
30

31. Relaciones de Asociación
Una asociación es una relación estructural que especifica que los objetos de un
elemento se conectan a los objetos de otro, por ejemplo, una clase biblioteca
podría tener una asociación uno a muchos con clase libro, indicando que cada
instanci de libro pertenece a una instancia de biblioteca, además, dado un libro, se
puede encontrar su biblioteca, y dando una biblioteca se puede navegar hacia
todos los libros, gráficamente, un asociaciones se representa con una línea
continua entre la misma o diferentes clases. Las relaciones se utilizan para
mostrar relaciones estructurales.
En la siguiente asociación simple se muestra como se hace la navegación entre
objetos por ejemplo al modelar una asociación entre 2 objetos como Usuario y
Clave se tiene que un dado un Usuario se puede encontrar las correspondientes
Claves, pero dada una Clave no se podría identificar al Usuario correspondiente.
1 *
Usuario Clave
La línea representa una asociación y la fecha indica la
dirección del recorrido
Figura 22.
1.2.8. Interfaces, Tipos y roles
Interfaz
El manejo de las interfaces dentro del UML es importante ya que proporcionan al
modelador un registro exacto de las fronteras existentes entre los diferentes
procesos del sistema, con lo cual se pretende observar al sistema en sus
componentes integrales para así determinar que procesos se pueden afectar sin
que se afecten los otros.
La construcción de interfaces permite también el manejo de librerías estándar
reutilizables sin tener que construirlas nuevamente, permitiendo reemplazos sin
necesidad de afectar el funcionamiento general del sistema. Se entiendo como
interfaz como una colección de operaciones que sirven para especificar un servicio
de una clase o un componente.
31

32. Cada interfaz ha de tener un nombre que la distingue de otras interfaces, el
nombre de la interfaz puede ser simple o de camino cuando en este se indica el
nombre de la interfaz y el paquete en el que se encuentre
Nombre elemental
IOrtografía
Nombre de camino
Red::IRouter
Figura 23.
Operaciones de las Interfaces
Al contrario de las clases y los tipos, las interfaces no especifican ninguna
estructura, las interfaces no incluyen atributos ni métodos, pero estas pueden
contener cualquier número de operaciones. La siguiente notación hace referencia
a una interfaz donde se manifiesta de manera gráfica su nombre y operaciones a
diferencia de la notación del círculo presentada anteriormente.
Proporciona un mecanismo para modelar la conformidad estática y dinámica de
una abstracción con una interfaz en un contexto específico
Nombre de la interfaz <<interface>>
FlujoURL
Abrirconexion()
EstablecerURL() Operaciones de la interfaz
Figura 24.
Notese en la representación el nombre <<interface>> como identificador de la
interfase definida.
32

33. Las relaciones entre interfaces se realizan de la misma manera como se
relacionan con las clases puesto que las relaciones son del mismo tipo, para
recordar: relaciones de generalización, relaciones de asociación y relaciones de
dependencia.
Como se mostró anteriormente las interfaces se pueden denotar mostrándose
como un círculo o con sus operaciones, dentro de un diagrama de interacción
entre clases los resultados para mostrar las relaciones entre las clases a través de
las interfaces se expresa de la siguiente manera:
Figura 25.
La primera forma es la sencilla en la cual se muestra la conexión de dos clases a
través de un circulo que representa la interfaz con la cual se comunican dichas
clases, la segunda forma muestra de manera mas detallada las operaciones con
las cuales interactúan las clases definidas antes y después de la interfase, nótese
como se representan las relaciones de dependencia de la misma forma como se
mostró en las relaciones entre clases.
33

34. Tipos y roles
Un rol representa un comportamiento de una entidad que participa en un contexto
particular, por ejemplo consideremos una instancia de una clase denominada
profesor, este profesor puede ser de matemáticas, sociales, informática, física, etc,
para cada rol generado de clase profesor, se deduce que las propiedades cada
rol son exclusivas y en ningún momento pueden tomar propiedades de un rol que
no le corresponda.
Para representar el rol que representa un objeto dentro de una relación de clases
en notación UML se tiene por ejemplo:
Figura 26.
Figura 27.
La figura anterior representa una asociación de clases con una interfaz especifica,
como se ve existe una asociación de entre las clases persona y empresa en cuyp
contexto persona juega un rol llamado e, cuyo tipo es empleado
34

35. 1.2.9 Paquetes e Instancias
Un paquete es un mecanismo de próposito general para organizar elementos en
grupos, graficamente un paquete se representa como una carpeta. Cada paquete
a de contener un nombre que lo distingue de los demás.
cliente Nombre del Paquete
+FormualarioDePedido
+FormularioDeSeguimiento
-Pedido
Elementos contenidos en el
paquete
Figura 28.
Un paquete puede contener otros elementos incluyendo clases, interfaces,
componentes, nodos, colaboraciones, casos de uso, diagramas en incluso otros
paquetes. Sí el paquete se destruye el elemento contenido en él es destruido,
pues cada elemento cada elemento pertenece exclusivamente a un único paquete.
Una instancia es una manifestación concreta de una abstracción a la que se
puede aplicar un conjunto de operaciones y que posee un estado que almacena el
efecto de las operaciones. gráficamente una instancia se representa subrayando
su nombre
teclasPulsadas: Colas Instancia con nombre
: Marco Instancia anónima
agente: Instancia huérfana
Figura 29.
35

36. Las instancias no aparecen aisladas, casi siempre están ligadas a una
abstracción. La mayoría de las instancias que se modelan en UML serán
instancias de clases (llamadas objetos), aunque se pueden tener instancias de
otros elementos, como componentes, nodos, casos de usos y asociaciones.
En sentido general, un objeto es algo que ocupa espacio en el mundo real o
conceptual y al que se le pueden hacer cosas. Por ejemplo, una instancia de un
nodo es normalmente un computador que se encuentra físicamente en una
habitación; una instancia de un componente ocupa algo de espacio en el sistema
de archivos; una instancia de un registro de un cliente consume algo de memoria
física, análogamente, una instancia de un billete de avión es algo sobre lo que se
pueden hacer cálculos.
1.2.10. Herencia y polimorfismo
Polimorfismo
Una de las características fundamentales de la OOP es el polimorfísmo, que no es
otra cosa que la posibilidad de construir varios métodos con el mismo nombre,
pero con relación a la clase a la que pertenece cada uno, con comportamientos
diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de
clases diferentes. Estos objetos recibirían el mismo mensaje global pero
responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto
ENTERO significaría suma, mientras que para un objeto STRING significaría
concatenación ("pegar" strings uno seguido al otro)
Herencia
En programación orientada a objetos, la herencia es un mecanismo que hace
posible que una clase herede todo el comportamiento y atributos de otra clase; a
través de la herencia, una clase tiene inmediatamente toda la funcionalidad de una
clase existente, debido a esto, las nuevas clases se pueden crear indicando
únicamente en que se diferencian de la clase existente, es decir, que toma la
definición previa de la cual es subclase, y que solo se le agrega características
especiales que la difieren de la clase de la cual procede. La relación de herencia
se representa mediante un triángulo en el extremo de la relación que corresponde
a la clase más general o clase “padre”.
36

37. SEGUNDA UNIDAD
CARACTERISTICAS DEL MODELADO UML
37

38. 2. CARACTERISTICAS DEL MODELADO UML
2.1. Diagramas Utilizados en UML
2.1.1. Diagramas de Objetos
Los diagramas de objetos modelan las instancias de elementos contenidos en los
diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y
sus relaciones en un momento concreto. En UML, los diagramas de clase se
utilizan para visualizar los aspectos estáticos del sistema y los diagramas de
interacción se utilizan para ver los aspectos dinámicos del sistemas, y constan de
instancias de los elementos del diagrama de clases y mensajes enviados entre
ellos. En un punto intermedio podemos situar los diagramas de objetos, que
contiene un conjunto de instancias de los elementos encontrados en el diagrama
de clases, representando sólo la parte estática de una interacción, consistiendo en
los objetos que colaboraran pero sin ninguno de los mensajes intercambiados
entre ellos.
Los diagramas de objetos se emplean para modelar la vista de diseño estática o la
vista de procesos estática de un sistema al igual que se hace con los diagramas
de clases, pero desde la perspectiva de instancias reales o prototípicas. Esta vista
sustenta principalmente los requisitos funcionales de un sistema. Los diagramas
de objetos permiten modelar estructuras de datos estáticas,
En general los diagramas de objetos se utilizan para modelar estructuras de
objetos, lo que implica tomar una instantánea de los objetos de un sistema en un
cierto momento. Un diagrama de objetos representa una escena estática dentro de
la historia representada por un diagrama de interacción. Los diagramas de objetos
se utilizan para visualizar, especificar, construir y documentar la existencia de
ciertas instancias en el sistema, junto a las relaciones entre ellas.
38

39. Figura 30.
En la figura anterior se representa un conjunto de objetos extraídos de la
implementación de un robot. Como indica la figura, un objeto representa al propio
robot, (r es una instancia de Robot), y r se encuentra actualmente en 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, un conjunto de instancias de Elemento, que
representan entidades que el robot ha identificado, pero aún no ha asignado en su
vista del mundo.
En este 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.
Como vemos los diagramas de objetos son especialmente útiles para modelar
estructuras de datos complejas. Evidentemente puede existir una multitud de
posibles instancias de una clase particular, y para un conjunto de clases con t
relaciones entre ellas, pueden existir muchas más configuraciones posibles de
39

40. estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar
significativamente conjuntos interesantes de objetos concretos o prototípicos.
2.1.2. Diagramas de Casos de Uso
El diagrama de casos de uso representa la forma en como un Cliente (Actor)
opera con el sistema en desarrollo, además de la forma, tipo y orden en como los
elementos interactúan (operaciones o casos de uso). Un diagrama de casos de
uso consta de los siguientes elementos:
• Actor.
• Casos de Uso.
• Relaciones de Uso, Herencia y Comunicación.
Elementos
Actor:
Figura 31.
Una definición previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto
se especifica que un Actor no necesariamente representa a una persona en
particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas
en que el rol de Vendedor con respecto al sistema puede ser realizado por un
Vendedor o bien por el Jefe de Local.
40

41. Caso de Uso:
Figura 32.
Es una operación o tarea específica que se realiza tras una orden de algún agente
externo, sea desde una petición de un actor o bien desde la invocación desde otro
caso de uso.
Relaciones:
Las relaciones se explicaron de manera especifica en el apartado 1.2.4 de este
modulo, ahora se explica de manera sencilla para observar su uso dentro de los
diagramas de casos de uso.
• Asociación
Es el tipo de relación más básica que 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.
41

42. Generalización
Este tipo de relación es uno de los más utilizados, 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 (y no para
actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(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.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y
modelamiento de clases, en donde esta la duda clásica de usar o heredar.
Ejemplo:
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El
sistema debe controlar y/o aceptar lo siguiente:
• Registrar el número de ítemes ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total
• El usuario/cliente presiona el botón de comienzo
• Existe un operador que desea saber lo siguiente:
a. Cuantos ítemes han sido retornados en el día.
b. Al final de cada día el operador solicita un resumen de todo lo
depositado en el día.
• El operador debe además poder cambiar:
a. Información asociada a ítemes.
b. Dar una alarma en el caso de que:
• Item se atora.
• No hay más papel.
42

43. Como una primera aproximación identificamos a los actores que interactúan con el
sistema:
Figura 33.
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede
cambiar la información de un Item o bien puede Imprimir un informe:
Figura 34.
Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Figura 35.
43

44. Otro aspecto es la impresión de comprobantes, que puede ser realizada después
de depositar algún item por un cliente o bien puede ser realizada a petición de un
operador.
Figura 36.
Entonces, el diseño completo del diagrama casos de uso es:
Figura 37.
44

45. 2.1.3. Diagramas de Interacción
Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de
un sistema, lo que conlleva modelar instancias concretas o prototípicas de clases
interfaces, componentes y nodos, junto con los mensajes enviados entre ellos,
todo en el contexto de un escenario que ilustra un comportamiento. En el contexto
de las clases describen la forma en que grupos de objetos colaboran para proveer
un comportamiento.
En los diagramas de interacción se muestra un patrón de interacción entre objetos.
Hay dos tipos de diagrama de interacción, ambos basados en la misma
información, pero cada uno enfatizando un aspecto particular: Diagramas de
Secuencia y Diagramas de Colaboración.
Diagrama de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia
temporal de eventos. En particular, muestra los objetos participantes en la
interacción y los mensajes que intercambian ordenados según su secuencia en el
tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los
objetos y actores participantes en la interacción, sin un orden prefijado. Cada
objeto o actor tiene una línea vertical, y los mensajes se representan mediante
flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden
colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.)
bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que
se refieren.
Objetos
c : Cliente p : ProxyODBC
<<create>>
:Transacción
establecerAcciones(a,d,o) establecerValores(d,3,4)
Tiempo
establecerValores(a,”CO”)
éxito
Línea de vida
<<destroy>>
Foco de control
Figura 38.
45

46. Los diagramas de secuencia tienen 2 características que los distinguen de los
diagramas de colaboración, en primer lugar está la línea de vida de un objeto que
es la línea discontinua vertical que representa la existencia de un objeto a lo largo
de un periodo de tiempo. La mayoría de los objetos que aparecen en un diagrama
de secuencia existirán mientras dure la interacción, los objetos se colocan en la
parte superior del diagrama con sus líneas de vida dibujadas de arriba hasta
abajo. Pueden crearse objetos durante la interacción, sus líneas de vida
comienzan con la recepción de mensajes estereotipado como create. Los objetos
pueden destruirse durante la interacción, sus líneas de vida acaban con la
recepción del mensaje estereotipado como destroy, además, se muestra la señal
visual de una gran X que marca el final de sus vidas.
Diagrama de Colaboración
Un diagrama de colaboración destaca la organización de los objetos que
participan en una interacción, un diagrama de colaboración se construye
colocando en primer lugar los objetos que participan en la colaboración como
nodos de un grafo. A continuación se representa los enlaces que conectan esos
objetos como arcos de grafo, por último, estos enlaces se adorna con los
mensajes que envían y reciben los objetos, esto da la lector una señal visual clara
del flujo de control en el contexto de la organización estructural de los objetos que
colaboran
c : Cliente Objeto
1: <<create>>
2: establecerAcciones(a,d,o)
enlace 3: <<destroy>>
<<local>>
mensaje
<<global>>
:Transacción P : ProxyODBC
2.1:establecerValores(d,3,4)
2.2: establecerValores(a,”Co”)
Figura 39.
Los diagramas colaboración tienen dos características que los distinguen de los
diagramas de secuencia, el primero para indicar cómo se enlaza un objeto a otro,
se puede asociar un objeto al extremo mas lejano de un enlace con la palabra
local que indica que el objeto designado es local al emisor. En segundo lugar esta
el numero de secuencia, para indicar la ordenación temporal de los mensajes, se
46

47. precede de un numero iniciando con el numeral 1, que se incrementa
secuencialmente por cada nuevo mensaje en el flujo de control
2.1.4. Diagramas de Actividades
Un diagrama de actividades muestra el flujo de actividades, siendo un actividad
una ejecución general entre los objetos que se esta ejecutando en un momento
dado dentro de una máquina de estados, el resultado de un actividad es una
acción que producen un cambio en el estado del sistema o la devolución de un
valor. Las acciones incluyen llamadas a otras operaciones, envío de señales,
creación o destrucción de objetos o simples cálculos. Gráficamente un diagrama
de actividades será un conjunto de arcos y nodos. Desde un punto de vista
conceptual, el diagrama de actividades muestra cómo fluye el control de unas
clases a otras con la finalidad de culminar con un flujo de control total que se
corresponde con la consecución de un proceso más complejo. Por este motivo, en
un diagrama de actividades aparecerán acciones y actividades correspondientes a
distintas clases. Colaborando todas ellas para conseguir un mismo fin. Ejemplo:
Hacer un pedido.
Contenido del diagrama de actividades
Básicamente un diagrama de actividades contiene:
• Estados de actividad
• Estados de acción
• Transiciones
• Objetos
Estados de actividad y estados de acción
La representación de ambos es un rectángulo con las puntas redondeadas, en
cuyo interior se representa bien una actividad o bien una acción. La forma de
expresar tanto una actividad como una acción, no queda impuesta por UML, se
podría utilizar lenguaje natural, una especificación formal de expresiones, un
metalenguaje, etc. La idea central es la siguiente: “Un estado que represente una
acción es atómico, lo que significa que su ejecución se puede considerar
instantánea y no puede ser interrumpida” En la siguiente figura, podemos ver
ejemplos de estados de acción.
47

48. Figura 40.
En cambio un estado de actividad, sí puede descomponerse en más sub-
actividades representadas a través de otros diagramas de actividades. Además
estos estados sí pueden ser interrumpidos y tardan un cierto tiempo en
completarse. En los estados de actividad podemos encontrar otros elementos
adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en
cuestión, así como definición de submáquinas, como podemos ver en la figura
siguiente
ProcesarFactura(Fact)
Entry / SacarPrimeraFactura(Fact)
Figura 41.
Transiciones
Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de
acción. Esta transición se produce como resultado de la finalización del estado del
que parte el arco dirigido que marca la transición. Como todo flujo de control debe
empezar y terminar en algún momento, podemos indicar esto utilizando dos
disparadores de inicio y fin tal y como queda reflejado en el ejemplo siguiente
Figura 41.
Estado de Acción
48

49. Bifurcaciones
Un flujo de control no tiene porqué ser siempre secuencial, puede presentar
caminos alternativos. Para poder representar dichos caminos alternativos o
bifurcación se utilizará como símbolo el rombo. Dicha bifurcación tendrá una
transición de entrada y dos o más de salida. En cada transición de salida se
colocará una expresión booleana que será evaluada una vez al llegar a la
bifurcación, las guardas de la bifurcación han de ser excluyentes y contemplar
todos los casos ya que de otro modo la ejecución del flujo de control quedaría
interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra
ELSE, para indicar una transición obligada a un determinado estado cuando el
resto de guardas han fallado. Veamos un ejemplo de bifurcación.
Bifurcación secuencial
Figura 42.
División y unión
No sólo existe el flujo secuencial y la bifurcación, también hay algunos casos en
los que se requieren tareas concurrentes. UML representa gráficamente el
proceso de división, que representa la concurrencia, y el momento de la unión de
nuevo al flujo de control secuencial, por una línea horizontal ancha. Podemos ver
cómo se representa gráficamente.
Figura 43.
49

50. Calles
Cuando se modelan flujos de trabajo de organizaciones, es especialmente útil
dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto
y se denominan calles. Cada calle representa a la parte de la organización
responsable de las actividades que aparecen en esa calle. Gráficamente quedaría
como se muestra a continuación
clientes ventas almacén
Solic Producto
Procesar Pedido
Extraer Pedido
Enviar Pedido
Recibir Pedido Fact. Cliente
Pagar Factura
Cerrar Pedido
Figura 44.
50

51. 2.2. Modelado dinámico
2.2.1 Eventos y señales
Un evento es la especificación de un acontecimiento significativo que ocupa un
lugar en el tiempo y en el espacio. En el contexto de la máquinas de estado, un
evento es la aparición de un estímulo que puede disparar una transición de
estado. Un señal es un tipo de evento que representa la especificación de un
estímulo asíncrono que es transmitido entre instancias.
Señales
Una señal representa un objeto con nombre que es enviado (lanzado)
asíncronamente por un objeto y recibido(capturado) por otro. El tipo más común
de señal interna que se presenta dentro de los lenguajes de programación son las
excepciones.
Una señal puede enviarse como la acción de una transición de estado en una
máquina de estados, o como el envío de un mensaje en una interacción.. En UML,
la relación entre una operación y los eventos que puede enviar se modela con
realcion de dependencia, estereotipada como send.
Las señales y las excepciones se modelan como clases estereotipadas, se puede
utilizar una dependencia, estereotipada como send para indicar que la operación
envía una señal particular.
Señal AgenteDeMovimiento
Posición
Velocidad
<<signal>> <<send>>
colisión moverA()
fuerza : Float
parámetros Figura 44.
51

52. Eventos
Un evento de llamada representa una invocación de una operación, un evento
puede disparar una transición de estado de una máquina de estados. Cuando un
objeto invoca una operación sobre otro objeto que tiene una máquina de estados,
el control pasa del emisor al receptor, el evento dispara la transición, la operación
acaba, el receptor pasa a un nuevo estado y el control regresa al emisor.
Gráficamente se muestra al evento con sus parámetros, como el disparador de
una transición de estado.
evento
iniciarpilotoAutomático(normal)
Manual Automático
parámetro
Figura 45.
Un evento de tiempo es un evento que representa el paso del tiempo, en UML se
modela un evento de tiempo con la palabra alter seguida de alguna expresión que
se evalúa para producir algún periodo de tiempo.
Un evento de cambio es un evento que representa un cambio en el estado o e
cumplimiento de alguna condición, se modela con la palabra when seguida de
alguna expresión booleana.
when (11:49 PM) /AutoTest()
alter (2 Segundos)
Inactivo /cortarConexión() Activo
Evento de cambio
Evento de tiempo
Figura 46.
52

53. 2.3.2 Máquinas de Estado
Una máquina de estados es un comportamiento que especifica las secuencias de
estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos.
Un Estado es una condición o situación en la vida de un objeto durante la cual
satisface alguna condición, realiza una actividad o espera algún evento. Un evento
es la especificación de un aconecimietno significativo que ocupa un lugar en el
tiempo y el espacio, es la estimulación que puede disparar una transición de
estados
Un transición es una relación entre dos estados que indica que un objeto que esté
en el primer estado realizará ciertas acciones y entrará el segundo estado cuando
ocurra un evento específico y se satisfagan unas condiciones específicas y una
actividad es una ejecución no atómica en curso, dentro de una máquina de
estados.
Estados
Un estado es una condcion o situación enla vida de un objeto durante la cual
satisface alguna condición, realiza una actividad o espera un evento. Un objeto
puede estar en cualquier estado durante una cantidad de tiempo determinado, por
ejemplo un calentador de agua puede estar en cualquiera de los cuatro estados:
inactivo, en preparación (esperando alcanzar la temperatura adecuada),
activo(cuando el calentador alcanza la temperatura ideal para calentar el agua), y
pagado. Un estado tiene varias partes, nombre, acciones de entrada salida,
transiciones internas, subastados y eventos diferidos. Como se muestra a
continuación un estado se representa con un rectángulo con las esquinas
redondeadas.
apagar Estado final
Estado inicial
Inactivo teclaPulsada Funcionando
Terminado
nombre
nombre
Figura 47. estado
53

54. Como se observa en la grafica anterior en la máquina de estados de un objeto se
pueden definir dos estados especiales, en primer lugar e punto inicial que indica el
puno de comienzo por defecto para la máquina de estados o el subestado. En
segundo lugar, el estado final, que indica la ejecución de la máquina de estado o
del estado que lo contiene ha finalizado
Transiciones
Una transición es una relación entre dos estados que indica que un objeto que
esté en el primer lugar estado realizará ciertas acciones y entrará en el segundo
estado cuando ocurra un evento específico y se satisfagan unas condiciones
específicas, cuando se produce este cambio de estado, se dice que la transición
se ha disparado, hasta que se dispara la transición se dice que el objeto está en
el estado origen, después de dispararse se dice que esta en el estado destino.
Evento de tiempo Envío de señal
Evento de disparo
Transición sin disparador
alter (2 Segundos) /send c.estaActivo
autotransición
ruido
Inactivo Inactivo Inactivo
objetoEn(p)[representaAmenaza]/
t.añadirObjeto(p)
contactar
Inactivo Inactivo
Evento de disparo con parámetros
acción condicion de gurda
Figura 48.
Una transición tiene cinco partes, estado origen, evento disparado, condición de
guarda, acción y estado de destino; una transición se representa con una línea
continua dirigida desde el estado origen hacia el destino y una autotransición es
una transición cuyos estados origen y destino son los mimos
54

55. 2.4.3 Tiempo y Espacio
Una marca de tiempo denota el instante en el que ocurre un evento, gráficamente,
una marca de tiempo es una expresión obtenida a partir del nombre dado al
mensaje; una expresión de tiempo es una expresión que al evaluarse genera un
valor de tiempo absoluto o relativo. Una restricción de tiempo se representa como
cualquiera otra restricción, es decir, una cadena de texto entre llaves y
normalmente conectada a un electo mediante una relación de dependencia. La
localización es la asignación de un componente de un nodo. Gráficamente, la
localización se representa como un valor etiquetado, es decir, una cadena de texto
entra llaves colocada debajo del nombre del elemento, o mediante la inclusión de
componentes dentro de nodos.
Restricción de tiempo
{cada 1ms}
c1 : notasDePrueva
c : ControladorMIDI : ColecciónDeNotas Restricción de tiempo
{executeTime <10 ms}
c2 : notasDePrueba()
n: Nota
c3 : a ñadir(k)
b: BufferDeEventosMIDI t : TransmisionMIDI
Figura 49. t1 : quitar()
{cada 1 ms}
Restricción de tiempo
En el gráfico anterior se observa la manera como se representa el tiempo y el
siguiente gráfico se muestra la localización
Figura 50.
Localización por inclusión
55
t : TransmisionMIDI Valor etiquetado de localización
{location=Enrutador}

56. 2.4.4 Diagramas de Estado
Es un tipo especial de diagrama y comparte las propiedades comunes al resto de
los diagramas, lo que distingue a un diagrama de estados de los otros tipos de
diagramas es su contenido, normalmente los diagramas de estados contienen:
• Estados simples y compuestos
• Transiciones, incluyendo eventos y acciones
Observemos un diagrama de estados a continuación con todos sus componentes
Estado inicial
sonando
Inactivo cabeceraOK
Transición sin Conectando Procesando
disparador
enviarFax
colgar verificaciónOK
evento evento
entry/descolgar
Transmisión Limpiando
error/imprimirError exit/desconectar
estado
acción acción
Estado compuesto
Figura 51.
56

57. 2.3. Modelado Arquitectónico
2.3.1. Componentes, despliegue, colaboraciones y patrones
Componentes
Un componente es una parte física y reemplazable de un sistema que conforma
un conjunto de interfaces. Gráficamente, un componente se representa como un
rectángulo con pestañas, un componente debe tener un nombre que lo distinga del
resto de componentes. El nombre de un componente puede ser simple o de
camino que consta del nombre del componente precedido del nombre del paquete
en el que se encuentra, usualmente un componente se dibuja solamente con su
nombre pero se pueden adornar con valores, etiquetas o con algún
comportamiento que indique sus detalles. Como se muestra en la siguiente figura
Agentefraudes.dll Componente con nombre
simple
agenteFraudes PoliticaFraudes BusquedaDePatrones
clases
Figura 52.
Interfaz
Imagen.java Imagen.java
ObservadorDeImagen
Figura 53.
Relación de dependencia
realización
57

58. Despliegue
Un nodo es un elemento físico que existe en tiempo de ejecución y representa un
recurso computacional que generalmente tiene alguna memoria y a menudo
capacidad de procesamiento, gráficamente un nodo se representa como un cubo. .
El nombre de un componente puede ser simple o de camino que consta del
nombre del componente precedido del nombre del paquete en el que se
encuentra, usualmente un nodo se dibuja solamente con su nombre pero se
pueden adornar con valores, etiquetas o con algún comportamiento que indique
sus detalles. Como se muestra en la siguiente figura
nodo con nombre
simple
ventas
pos.exe Contactos.exe
componentes
Figura 54.
Colaboraciones
Una colaboración es una sociedad de clases, interfaces y otros elementos que
colaboran para proporcionar un comportamiento cooperativo mayor que la suma
de los comportamientos de sus elementos. Una colaboración es también la
especificación de cómo un elemento tal como un clasificador o un operación, es
realizado mediante un conjunto de clasificadores y asociaciones que juegan roles
específicos utilizados de una forma específica, gráficamente, una colaboración se
representa como una elipse con borde discontinua. El nombre de una colaboración
puede ser simple o de camino que consta del nombre de la colaboración
precedido del nombre del paquete en el que se encuentra, usualmente un nodo se
dibuja solamente con su nombre pero se pueden adornar con valores, etiquetas o
con algún comportamiento que indique sus detalles. Como se muestra en la
58

59. siguiente figura
Nombre
Paso de mensajes
entre nodos
Figura 55.
Patrones
Un patrón es una solución común a un problema común en un contexto dado. Los
patrones ayudan a visualizar, especificar, construir y documentar los artefactos de
un sistema con gran cantidad de software. Hay dos tipos de patrones, patrones de
diseño(Mecanismos) y frameworks.
Mecanismos
Un mecanismo simplemente muestra un conjunto de abstracciones que colaboran
entre si par llevar a cabo algún comportamiento común, estos mecanismo se
muestran como colaboraciones simples, ya que solamente dan el nombre a una
sociedad de clases.
frameworks <<framework>>
recepción de pedidos
facturación
comprobación
Figura 56.
mecanismos
59

60. Los mecanismos pueden nombrar una plantilla formada por un conjunto de de
abstracciones que colaboran entre sí para llevar a cabo algún comportamiento
común, se representan como colaboraciones parametrizadas que se muestran de
forma parecida a las clases plantilla, observe la siguiente figura
rol platilla
ColaTares Sujeto Sujeto
Observador
ligadura Observador
BarraDesplazamiento
Observador
colaboraciones
rol
Figura 57.
Frameworks
Un frameworks es un patrón arquitectónico que proporciona una plantilla
extensible para aplicaciones dentro de un dominio.
La siguiente figura ilustra un frameworks, llamado AdministradorCiclo entre otras
cosas, este frameworks incluye una colaboración EventosComunes que contiene
un conjunto de clases evento, junto con un mecanismo GestorDeEventos para
procesar estos eventos de forma cíclica. Un cliente que utilice este frameworks tal
como un Marcapasos podría construir sobre las abtracciones en EventosComunes
creando subclases y también podría emplear una instancia del mecanismo
GestorDeEventos
60

61. frameworks
ligaduras Pacificador
<<frameworks>>
AdministradorCiclico
Cliente
Gestor
GestorDeEvento
s
EventosComunes
colaboraciones
Figura 58.
2.3.2. Diagramas de Componentes
Lo que distingue a un diagrama de componentes de otros tipos de diagramas es
su contenido. Normalmente contienen componentes, interfaces y relaciones entre
ellos. Y como todos los diagramas, también puede contener paquetes utilizados
para agrupar elementos del modelo.
Un diagrama de componentes muestra las organizaciones y dependencias lógicas
entre componentes software, sean éstos componentes de código fuente, binarios
o ejecutables. Desde el punto de vista del diagrama de componentes se tienen en
consideración los requisitos relacionados con la facilidad de desarrollo, la gestión
del software, la reutilización, y las restricciones impuestas por los lenguajes de
programación y las herramientas utilizadas en el desarrollo. Los elementos de
modelado dentro de un diagrama de componentes serán componentes y
paquetes.
Dado que los diagramas de componentes muestran los componentes software que
constituyen una parte reusable, sus interfaces, y su interrelaciones, en muchos
aspectos se puede considerar que un diagrama de componentes es un diagrama
61

62. de clases a gran escala. 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 un 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 ejemplo típico de una jerarquía en capas de
este tipo es: Interfaz de usuario; Paquetes específicos de la aplicación; Paquetes
reusables; Mecanismos claves; y Paquetes hardware y del sistema operativo.
Un diagrama de componentes se representa como un grafo de componentes
software unidos por medio de relaciones de dependencia (generalmente de
compilación). Puede mostrar también que un componente software contiene una
interfaz, es decir, la soporta. Un ejemplo se muestra a continuación
find.html
página
find.exe
nateng.dll
componente
biblioteca
Figura 60.
2.3.3. Diagramas de Despliegue
Cuando se trata de hardware y el software del sistema, se utiliza los diagramas de
despliegue para razonar sobre la tipología de procesadores y dispositivos sobre
los que reejecuta el software. Los diagramas de despliegue se utilizan para
visualizar los aspectos estáticos de estos nodo físicos y sus relaciones y para
especificar sus detalles para la construcción, como se muestra a continuación
62

63. nodo
modem
<<procesadorr>> <<procesadorr>> nodo
servidor cache servidor cache
conexión
<<procesadorr>> <<procesadorr>> <<procesadorr>> <<procesadorr>>
servidor principal servidor servidor servidor
Figura 61.
Un diagrama de despliegue es un diagrama que muestra la configuración de los
nodos que participan en la ejecución y de los componentes que residen en ellos,
gráficamente, un diagrama de despliegue es una colección de nodos y arcos.
2.3.4. Sistemas y modelos
UML proporciona una representación gráfica de los sistemas y los subsistemas,
esta notación permite visualizar la descompensación de un sistema en
subsistemas más pequeños, gráficamente, un sistema y un subsistema se
representa con el símbolo de un paquete estereotipado. Observemos su
representación a continuación
63

64. <<system>>
sistema de
ventas
<<subsystem>> <<subsystem>> <<subsystem>>
subsistema de subsistema de subsistema de
servicio al gestión de gestión de
cliente almacén producción
Figura 62.
Un sistema posiblemente descompuesto en una colección de subsistemas, es un
conjunto de elementos organizados para lograr un propósito y descrito por un
conjunto de modelos. Un subsistema es una agrupación de elementos, algunos de
los cuales constituyen una especificación del comportamiento ofrecido por otros
elementos.
64

65. TERCERA UNIDAD
DESARROLLO ORIENTADO A OBJETOS CON UML
65