MODULO

LENGUAJE UNIFICADO DE MODELADO UML

ING. HAROLD CABRERA MEZA

UNIVERSIDAD NACIONAL ABIERTA Y A

DISTANCIA
SAN JUAN DE PASTO, 2006

1
 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
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
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
 PRIMERA UNIDAD

INTRODUCCIÓN AL LENGUAJE UNIFICADO DE

MODELADO

5
 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
 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
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
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
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
 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
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
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
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
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
 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
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
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
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
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
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
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
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
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
• 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
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
• 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
• 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
 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
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
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
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
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
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
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
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
 SEGUNDA UNIDAD

CARACTERISTICAS DEL MODELADO UML

37
 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
 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
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
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
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
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
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
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
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
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
 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
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
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
 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
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
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
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
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}
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
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
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
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
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
 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
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
 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
 <<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
 TERCERA UNIDAD

DESARROLLO ORIENTADO A OBJETOS CON UML

65
3. DESARROLLO ORIENTADO A OBJETOS CON UML

Cuando se va a construir un sistema software es necesario conocer un lenguaje

de programación, pero con eso no basta. Si se quiere que el sistema sea robusto y
mantenible es necesario que el problema sea analizado y la solución sea
cuidadosamente diseñada. Se debe seguir un proceso robusto, que incluya las
actividades principales. Si se sigue un proceso de desarrollo que se ocupa de
plantear cómo se realiza el análisis y el diseño, y cómo se relacionan los
productos de ambos, entonces la construcción de sistemas software va a poder
ser planificable y repetible, y la probabilidad de obtener un sistema de mejor
calidad al final del proceso aumenta considerablemente, especialmente cuando se
trata de un equipo de desarrollo formado por varias personas.

La notación que se usa para los distintos modelos, tal y como se ha dicho
anteriormente, es la proporcionada por UML, que se ha convertido en el estándar
de facto en cuanto a notación orientada a objetos. El uso de UML permite integrar
con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con
otros equipos la documentación, pues es de esperar que cualquier desarrollador
versado en orientación a objetos conozca y use UML (o se esté planteando su
uso).

Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en

el sistema funcionando, proporcionando así una visión completa y coherente de la
producción de sistemas software. El enfoque que toma es el de un ciclo de vida
iterativo incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a
un proyecto y a un equipo de desarrollo específicos. El ciclo de vida está dirigido
por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros
usuarios del mismo. Así no se pierde de vista la motivación principal que debería
estar en cualquier proceso de construcción de software: el resolver una necesidad
del usuario/cliente.

Visión General

El proceso a seguir para realizar desarrollo orientado a objetos es complejo,

debido a la complejidad que nos vamos a encontrar al intentar desarrollar
cualquier sistema software de tamaño medio-alto. El proceso está formado por
una serie de actividades y subactividades, cuya realización se va repitiendo en el
tiempo aplicadas a distintos elementos.

66
En este apartado se va a presentar una visión general para poder tener una idea
del proceso a alto nivel, y más adelante se verán los pasos que componen cada
fase.

Las tres fases al nivel más alto son las siguientes:

• Planificación y Especificación de Requisitos: Planificación, definición de

requisitos, construcción de prototipos, etc.

• Construcción: La construcción del sistema. Las fases dentro de esta etapa son
las siguientes:

- Diseño de Alto Nivel: Se analiza el problema a resolver desde la perspectiva de

los usuarios y de las entidades externas que van a solicitar servicios al sistema.

- Diseño de Bajo Nivel: El sistema se especifica en detalle, describiendo cómo va

a funcionar internamente para satisfacer lo especificado en el Diseño de Alto
Nivel.

- Implementación: Se lleva lo especificado en el Diseño de Bajo Nivel a un

lenguaje de programación.

- Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software
funciona correctamente y que satisface lo especificado en la etapa de
Planificación y Especificación de Requisitos.

- Instalación: La puesta en marcha del sistema en el entorno previsto de uso.

De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo

y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un
enfoque iterativo, tomando en cada iteración un subconjunto de los requisitos
(agrupados según casos de uso) y llevándolo a través del diseño de alto y al de
bajo nivel, para llegar a la implementación y pruebas.

El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximación

se consigue disminuir el grado de complejidad que se trata en cada ciclo, y se
tiene pronto en el proceso una parte del sistema funcionando que se puede
contrastar con el usuario/cliente

67
3.2. Fase de Planificación y Especificación de Requisitos

Esta fase se corresponde con la Especificación de Requisitos tradicional ampliada

con un Borrador de Modelo Conceptual y con una definición de Casos de Uso de
alto nivel. En esta fase se decidiría si se aborda la construcción del sistema
mediante desarrollo orientado a objetos o no, por lo que, en principio, es
independiente del paradigma empleado posteriormente.

3.2.1 Actividades

Las actividades de esta fase son las siguientes:

• Definir el Plan-Borrador.
• Crear el Informe de Investigación Preliminar.
• Definir los Requisitos.
• Registrar Términos en el Glosario. (continuado en posteriores fases)
• Implementar un Prototipo. (opcional)
• Definir Casos de Uso (de alto nivel y esenciales).
• Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase
posterior)
• Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una
fase posterior)
• Refinar el Plan.

El orden no es estricto, lo normal es que las distintas actividades se solapen en el

tiempo. Esto sucede también en las actividades de las fases de diseño, que se
verán más adelante.

De estas actividades no se va a entrar en las que corresponden al campo de la

planificación de proyectos software, como las correspondientes a creación de
planes e informes preliminares.

3.2.2. Requisitos

El formato del documento de Especificación de Requisitos no está definido en

UML, pero se ha incluido este punto para resaltar que la actividad de definición de

68
requisitos es un paso clave en la creación de cualquier producto software. Para
entender y describir los requisitos la técnica de casos de uso constituye una
valiosa ayuda.

Casos de Uso

Un Caso de Uso es un documento narrativo que describe a los actores utilizando

un sistema para satisfacer un objetivo. Es una historia o una forma particular de
usar un sistema. Los casos de uso son requisitos, en particular requisitos
funcionales.

Nótese que UML no define un formato para describir un caso de uso. Tan sólo
define la manera de representar la relación entre actores y casos de uso en un
diagrama. Sin embargo, un caso de uso individual no es un diagrama, es un
documento de texto. En la siguiente sección se define el formato textual para la
descripción de un caso de uso que se va a utilizar en este documento..

Un escenario es un camino concreto a través del caso de uso, una secuencia

específica de acciones e interacciones entre los actores y el sistema. Más
adelante se verá la representación de los escenarios correspondientes a un caso
de uso por medio de Diagramas de Secuencia.

En un primer momento interesa abordar un caso de uso desde un nivel de

abstracción alto, utilizando el formato de alto nivel. Cuando se quiere describir un
caso de uso con más detalle se usa el formato expandido.

Casos de Uso de Alto Nivel

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando
se está usando un cajero automático:

- Caso de Uso: Realizar Reintegro

- Actores: Cliente
- Tipo: primario
- Descripción: Un Cliente llega al cajero automático, introduce la tarjeta, se
identifica y solicita realizar una operación de reintegro por una cantidad específica.
El cajero le da el dinero solicitado tras comprobar que la operación puede
realizarse. El Cliente coge el dinero y la tarjeta y se va.

69
En un caso de uso descrito a alto nivel la descripción es muy general,
normalmente se condensa en dos o tres frases. Es útil para comprender el ámbito
y el grado de complejidad del sistema.

Casos de Uso Expandidos

Los casos de uso que se consideren los más importantes y que se considere que
son los que más influencian al resto, se describen a un nivel más detallado: en el
formato expandido.

La principal diferencia con un caso de uso de alto nivel está en que incluye un
apartado de Curso Típico de Eventos, pero también incluye otros apartados como
se ve en el siguiente ejemplo:

- Caso de Uso: Realizar Reintegro

- Actores: Cliente (iniciador)
- Propósito: Realizar una operación de reintegro de una cuenta del banco
- Visión General: Un Cliente llega al cajero automático, introduce la tarjeta, se
identifica y solicita realizar una operación de reintegro por una cantidad específica.
El cajero le da el dinero solicitado tras comprobar que la operación puede
realizarse. El Cliente coge el dinero y la tarjeta y se va.

-Tipo: primario y esencial

-Curso Típico de Eventos: Acción del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero.
2. Pide la clave de identificación.
3. Introduce la clave.
4. Presenta las opciones de operaciones disponibles.
5. Selecciona la operación de Reintegro.
6. Pide la cantidad a retirar.
7. Introduce la cantidad requerida.
8. Procesa la petición y da el dinero solicitado. Devuelve la tarjeta y genera un
recibo.
9. Recoge la tarjeta.
10. Recoge el recibo.
11. Recoge el dinero y se va.

70
Cursos Alternativas:

Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación.

Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la
operación.

Identificación de Casos de Uso

La identificación de casos de uso requiere un conocimiento medio acerca de los

requisitos, y se basa en la revisión de los documentos de requisitos existentes, y
en el uso de la técnica de brainstorming entre los miembros del equipo de
desarrollo.

Como guía para la identificación inicial de casos de uso hay dos métodos:

a) Basado en Actores

1. Identificar los actores relacionados con el sistema y/o la organización.

2. Para cada actor, identificar los procesos que inicia o en los que participa.

b) Basado en Eventos

1. Identificar los eventos externos a los que el sistema va a tener que responder.
2. Relacionar los eventos con actores y casos de uso.

Ejemplos de casos de uso:

• Pedir un producto.
• Matricularse en un curso de la facultad.
• Comprobar la ortografía de un documento en un procesador de textos.
• Comprar un libro en una tienda de libros en Internet

Identificación de los Límites del Sistema

En la descripción de un caso de uso se hace referencia en todo momento al

“sistema”. Para que los casos de uso tengan un significado completo es necesario
que el sistema esté definido con precisión.

71
Al definir los límites del sistema se establece una diferenciación entre lo que es
interno y lo que es externo al sistema. El entorno exterior se representa mediante
los actores.

Ejemplos de sistemas son:

• El hardware y software de un sistema informático.

• Un departamento de una organización.
• Una organización entera.

Si no se está haciendo reingeniería del proceso de negocio lo más normal es

escoger como sistema el primero de los ejemplos: el hardware y el software del
sistema que se quiere construir.

Tipos de Casos de Uso

a) Según su Importancia

Para establecer una primera aproximación a la priorización de casos de uso que

identifiquemos los vamos a distinguir entre:

• Primarios: Representan los procesos principales, los más comunes, como

Realizar Reintegro en el caso del cajero automático.
• Secundarios: Representan casos de uso menores, que van a necesitarse
raramente, tales como Añadir Nueva Operación.
• Opcionales: Representan procesos que pueden no ser abordados en el presente
proyecto.

b) Según el Grado de Compromiso con el Diseño

En las descripciones que se han visto anteriormente no se han hecho apenas

compromisos con la solución, se han descrito los casos de uso a un nivel
abstracto, independiente de la tecnología y de la implementación. Un caso de uso
definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto
nivel son siempre esenciales por naturaleza, debido a su brevedad y abstracción.

Por el contrario, un caso de uso real describe concretamente el proceso en

términos del diseño real, de la solución específica que se va a llevar a cabo. Se
ajusta a un tipo de interfaz específica, y se baja a detalles como pantallas y
objetos en las mismas.

72
Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en
un cajero automático tenemos la siguiente descripción del Curso Típico de

Eventos: Acción del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura
para tarjetas.
2. Pide el PIN (Personal Identification Number).
3. Introduce el PIN a través del teclado numérico.
4. Presenta las opciones de operaciones disponibles.
5. etc.

En principio, los casos de uso reales deberían ser creados en la fase de Diseño de
Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definición
de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte
del contrato. En este caso se pueden definir algunos o todos los casos de uso
reales, a pesar de que suponen tomar decisiones de diseño muy pronto en el ciclo
de vida. No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real,
el grado de compromiso con el diseño es un continuo, y una descripción específica
de un caso de uso estará situada en algún punto de la línea entre Casos de Uso
Esenciales y Reales, normalmente más cercano a un extremo que al otro, pero es
raro encontrar Casos de Uso Esenciales o Reales puros.

Consejos Relativos a Casos de Uso

• Nombre: El nombre de un Caso de Uso debería ser un verbo, para enfatizar que
se trata de un proceso, por ejemplo: Comprar Artículos o Realizar Pedido.
• Alternativas equiprobables: Cuando se tiene una alternativa que ocurre de
manera relativamente ocasional, se indica en el apartado Cursos Alternativos.
Pero cuando se tienen distintas opciones, todas ellas consideradas normales se
puede completar el Curso Típico de Eventos con secciones adicionales.

Así, si en un determinado número de línea hay una bifurcación se pueden poner

opciones que dirigen el caso de uso a una sección que se detalla al final del Curso

Un caso Típico de Eventos, en la siguiente forma:

- Curso Típico de Eventos:

- Sección: Principal Acción del Actor Respuesta del Sistema

1. Este caso de uso empieza cuando Actor llega al sistema.

73
2. Pide la operación a realizar.
3. Escoge la operación A.
4. Presenta las opciones de pago.
5. Selecciona el tipo de pago: Si se paga al contado ver sección Pago al Contado.
O si se paga con tarjeta ver sección Pago con Tarjeta.
6. Genera recibo.
7. Recoge el recibo y se va.

Cursos Alternativos:

Líneas 3 y 5: Selecciona Cancelar. Se cancela la operación.

Sección: Pago al Contado

Acción del Actor Respuesta del Sistema

1. Mete los billetes correspondientes

2. Coge los billetes y sigue pidiendo dinero hasta que la cantidad está satisfecha
3. Devuelve el cambio.

Cursos Alternativos:

Línea 3: No hay cambio suficiente. Se cancela la operación.

3.2.3. Construcción del Modelo de Casos de Uso

Para construir el Modelo de Casos de Uso en la fase de Planificación y

especificación de Requisitos se siguen los siguientes pasos:

1. Después de listar las funciones del sistema, se definen los límites del sistema y
se identifican los actores y los casos de uso.
2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan
como primarios, secundarios u opcionales.
3. Se dibuja el Diagrama de Casos de Uso.
4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se
ilustran tales relaciones en el Diagrama de Casos de Uso.
5. Los casos de uso más críticos, importantes y que conllevan un mayor riesgo, se
describen en el formato expandido esencial. Se deja la definición en formato
expandido esencial del resto de casos de uso para cuando sean tratados en
posteriores ciclos de desarrollo, para no tratar toda la complejidad del problema
de una sola vez.

74
6. Se crean casos de uso reales sólo cuando:
• Descripciones más detalladas ayudan significativamente a incrementar la
comprensión del problema.
• El cliente pide que los procesos se describan de esta forma.
7. Ordenar según prioridad los casos de uso (este paso se va a ver a
continuación).

3.2.4. Planificación de Casos de Uso según Ciclos de Desarrollo

La decisión de qué partes del sistema abordar en cada ciclo de desarrollo se va a

tomar basándose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va
a asignar la implementación de uno o más casos de uso, o versiones simplificadas
de casos de uso. Se asigna una versión simplificada cuando el caso de uso
completo es demasiado complejo para ser tratado en un solo ciclo

Figura 63.

Para tomar la decisión de qué casos de uso se van a tratar primero es necesario
ordenarlos según prioridad. Las características de un caso de uso específico que
van a hacer que un caso de uso tenga una prioridad alta son las siguientes:

75
• Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta
muchas clases al modelo del dominio o requiere persistencia en los datos.
• Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo
relativamente bajo.
• Incluye funciones complejas, críticas en el tiempo o de nivel elevado de riesgo.
• Implica bien un trabajo de investigación significante, o bien el uso de una
tecnología nueva o arriesgada.
• Representa un proceso de gran importancia en la línea de negocio.
• Supone directamente un aumento de beneficios o una disminución de costos.

Para realizar la clasificación se puede asignar a cada caso de uso una valoración
numérica de cada uno de estos puntos, para conseguir una puntuación total
aplicando pesos a cada apartado.

Caso de Uso de Inicialización

Prácticamente todos los sistemas van a tener un caso de uso de Inicialización.

Aunque puede ser que no tenga una prioridad alta en la clasificación realizada
según el punto anterior, normalmente va a interesar que sea desarrollado desde el
principio. Inicialmente se desarrolla una versión simplificada, que se va
completando en cada ciclo de desarrollo para satisfacer las necesidades de
inicialización de los casos de uso que se tratan en dicho ciclo. Así se tiene un
sistema en cada ciclo de desarrollo que puede funcionar.

3.3. Diseño de Alto Nivel

En la fase de Diseño de Alto Nivel de un ciclo de desarrollo se investiga sobre el

problema, sobre los conceptos relacionados con el subconjunto de casos de uso
que se esté tratando. Se intenta llegar a una buena comprensión del problema por
parte del equipo de desarrollo, sin entrar en cómo va a ser la solución en cuanto a
detalles de implementación.

Cuando el ciclo de desarrollo no es el primero, antes de la fase de Diseño de Alto

Nivel hay una serie de actividades de planificación. Estas actividades consisten en
actualizar los modelos que se tengan según lo que se haya implementado, pues
siempre se producen desviaciones entre lo que se ha analizado y diseñado y lo
que finalmente se construye. Una vez se tienen los modelos acordes con lo
implementado se empieza el nuevo ciclo de desarrollo con la fase de Diseño de
Alto Nivel.

76
En esta fase se trabaja con los modelos de Diseño de Alto Nivel construidos en la
fase anterior, ampliándolos con los conceptos correspondientes a los casos de uso
que se traten en el ciclo de desarrollo actual.

3.3.1 Actividades

Las actividades de la fase de Diseño de Alto Nivel son las siguientes:

1. Definir Casos de Uso Esenciales en formato expandido. (si no están definidos )

2. Refinar los Diagramas de Casos de Uso.
3. Refinar el Modelo Conceptual.
4. Refinar el Glosario. (continuado en posteriores fases)
5. Definir los Diagramas de Secuencia del Sistema.
6. Definir Contratos de Operación.
7. Definir Diagramas de Estados. (opcional)

3.3.2. Modelo Conceptual

Una parte de la investigación sobre el dominio del problema consiste en identificar

los conceptos que lo conforman. Para representar estos conceptos se va a usar un
Diagrama de Estructura Estática de UML, al que se va a llamar Modelo
Conceptual. En el Modelo Conceptual se tiene una representación de conceptos
del mundo real, no de componentes software. El objetivo de la creación de un
Modelo Conceptual es aumentar la comprensión del problema. Por tanto, a la hora
de incluir conceptos en el modelo, es mejor crear un modelo con muchos
conceptos que quedarse corto y olvidar algún concepto importante.

Identificación de Conceptos

Para identificar conceptos hay que basarse en el documento de especificación de

requisitos y en el conocimiento general acerca del dominio del problema. Otro
consejo para identificar conceptos consiste en buscar sustantivos en los
documentos de requisitos o, más concretamente, en la descripción de los casos
de uso. No es un método infalible, pero puede servir de guía para empezar.

77
Para poner nombre a los conceptos se puede usar la analogía con el cartógrafo,
resumida en los siguientes tres puntos:

• Usar los nombres existentes en el territorio: hay que usar el vocabulario del
dominio para nombrar conceptos y atributos.
• Excluir características irrelevantes: al igual que el cartógrafo elimina
características no relevantes según la finalidad del mapa (por ejemplo datos de
población en un mapa de carreteras), un Modelo Conceptual puede excluir
conceptos en el dominio que no son pertinentes en base a los requisitos.
• No añadir cosas que no están ahí: si algo no pertenece al dominio del problema
no se añade al modelo.

Creación del Modelo Conceptual

Para crear el Modelo Conceptual se siguen los siguientes pasos:

1. Hacer una lista de conceptos candidato usando la Lista de Categorías de

Conceptos y la búsqueda de sustantivos relacionados con los requisitos en
consideración en este ciclo.
2. Representarlos en un diagrama.
3. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos
que es necesario conocer.
4. Añadir los atributos necesarios para contener toda la información que se
necesite conocer de cada concepto.

Identificación de Asociaciones

Una asociación es una relación entre conceptos que indica una conexión con
sentido y que es de interés en el conjunto de casos de uso que se está tratando.
Se incluyen en el modelo las asociaciones siguientes:

• Asociaciones para las que el conocimiento de la relación necesita mantenerse

por un cierto período de tiempo (asociaciones “necesita-conocer”).

• Asociaciones derivadas de la Lista de Asociaciones

78
Identificación de Atributos

Es necesario incorporar al Modelo Conceptual los atributos necesarios para

satisfacer las necesidades de información de los casos de uso que se estén
desarrollando en ese momento.

Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los
tipos complejos deberían ser modelados como conceptos y ser relacionados
mediante asociaciones, incluso cuando un valor es de un tipo simple es más
conveniente representarlo como concepto en las siguientes ocasiones cuando:

• Se compone de distintas secciones. Por ejemplo: un número de teléfono, el

nombre de una persona, etc.
• Tiene operaciones asociadas, tales como validación. Ejemplo: número único de
identificación.
• Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin.
• Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesos,
dólares o en euros.
• Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo
no es un modelo definitivo, pues a lo largo del desarrollo se va refinando según
se le añaden conceptos que se habían pasado por alto.

Glosario

En el glosario debe aparecer una descripción textual de cualquier elemento de

cualquier modelo, para eliminar toda posible ambigüedad. Se ordena
alfabéticamente por término.

3.3.3. Diagramas de Secuencia del Sistema

Además de investigar sobre los conceptos del sistema y su estructura, también es

preciso investigar en el diseño de alto nivel sobre el comportamiento del sistema,
visto éste como una caja negra. Una parte de la descripción del comportamiento
del sistema se realiza mediante los Diagramas de Secuencia del Sistema.

En cada caso de uso se muestra una interacción de actores con el sistema. En

79
esta interacción los actores generan eventos, solicitando al sistema operaciones.
Por ejemplo, en el caso de una reserva de un billete de avión, el empleado de la
agencia de viajes solicita al sistema de reservas que realice una reserva. El evento
que supone esa solicitud inicia una operación en el sistema de reservas.

Los casos de uso representan una interacción genérica. Una instancia de un caso
de uso se denomina escenario, y muestra una ejecución real del caso de uso, con
las posibles bifurcaciones y alternativas resueltas de forma particular.

Un Diagrama de Secuencia de Sistema se representa usando la notación para

diagramas de secuencia de UML estudiadas en la unidad 2 de este módulo. En él
se muestra para un escenario particular de un caso de uso los eventos que los
actores generan, su orden, y los eventos que se intercambian entre sistemas.

Para cada caso de uso que se esté tratando se realiza un diagrama para el curso
típico de eventos, y además se realiza un diagrama para los cursos alternativos de
mayor interés. En la siguiente figura se muestra el Diagrama de Secuencia del
Sistema para el caso de uso Realizar Reintegro de un cajero automático.

Figura 64.

80
Construcción de un Diagrama de Secuencia del Sistema

Para construir un Diagrama de Secuencia del Sistema para el curso típico de

eventos de un caso de uso, se siguen los siguientes pasos:

1. Representar el sistema como un objeto con una línea debajo.

2. Identificar los actores que directamente operan con el sistema, y dibujar una
línea para cada uno de ellos.
3. Partiendo del texto del curso típico de eventos del caso de uso, identificar los
eventos (externos) del sistema que cada actor genera y representarlos en el
diagrama.
4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama.
los eventos del sistema deberían expresarse en base a la noción de operación
que representan, en vez de en base a la interfaz particular. Por ejemplo, se
prefiere “finalizarOperación” a “presionadaTeclaEnter”, porque captura la
finalidad de la operación sin realizar compromisos en cuanto a la interfaz usada.

3.3.4. Diagramas de Estados

Para modelar el comportamiento del sistema pueden usarse los Diagramas de

Estados definidos en la unidad 2 de este módulo

Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes

elementos:

• Una clase software.

• Un concepto.
• Un caso de uso.

En la fase de Diseño de Alto Nivel sólo se haría para los dos últimos tipos de
elemento, pues una clase software pertenece al Diagrama de Clases de Diseño.

Puesto que el sistema entero puede ser representado por un concepto, también se
puede modelar el comportamiento del sistema completo mediante un Diagrama de
Estados.

La utilidad de un Diagrama de Estados en esta fase reside en mostrar la

secuencia permitida de eventos externos que pueden ser reconocidos y tratados
por el sistema. Por ejemplo, no se puede insertar una tarjeta en un cajero
automático si se está en el transcurso de una operación.

81
Para los casos de uso complejos se puede construir un Diagrama de Estados. El
Diagrama de Estados del sistema sería una combinación de los diagramas de
todos los casos de uso. El uso de Diagramas de Estados es opcional.

3.4. Diseño de Bajo Nivel

En la fase de Diseño de Bajo Nivel se crea una solución a nivel lógico para
satisfacer los requisitos, basándose en el conocimiento reunido en la fase de
Diseño de Alto Nivel. Los modelos más importantes en esta fase son el Diagrama
de Clases de Diseño y los Diagramas de Interacción, que se realizan en paralelo y
que definen los elementos que forman parte del sistema orientado a objetos que
se va a construir (clases y objetos) y cómo colaboran entre sí para realizar las
funciones que se piden al sistema, según éstas se definieron en los contratos de
operaciones del sistema.

3.4.1 Actividades

Las actividades que se realizan en la etapa de Diseño de Bajo Nivel son las
siguientes:

1. Definir los Casos de Uso Reales.

2. Definir Informes e Interfaz de Usuario.
3. Refinar la Arquitectura del Sistema.
4. Definir los Diagramas de Interacción.
5. Definir el Diagrama de Clases de Diseño. (en paralelo con los Diagramas de
Interacción).
6. Definir el Esquema de Base de Datos.
El paso de Refinar la Arquitectura del Sistema no tiene por qué realizarse en la
posición 3, puede realizarse antes o después.

3.4.2. Casos de Uso Reales

Un Caso de Uso Real describe el diseño real del caso de uso según una
tecnología concreta de entrada y de salida y su implementación. Si el caso de uso
implica una interfaz de usuario, el caso de uso real incluirá bocetos de las

82
ventanas y detalles de la interacción a bajo nivel con los widgets (botón, lista
seleccionable, campo editable, etc.) de la ventana.

Como alternativa a la creación de los Casos de Uso Reales, el desarrollador

puede crear bocetos de la interfaz en papel, y dejar los detalles para la fase de
implementación.

3.4.3. Diagramas de Interacción

Los Diagramas de Interacción muestran el intercambio de mensajes entre

instancias del modelo de clases para cumplir las post-condiciones establecidas en
un contrato Hay dos clases de Diagramas de Interacción:

1. Diagramas de Colaboración.
2. Diagramas de Secuencia.

La notación en UML para ambos es la definida unidad 2 de este módulo, los

Diagramas de Colaboración tienen una mayor expresividad y mayor economía
espacial (una interacción compleja puede ser muy larga en un Diagrama de
Secuencia), sin embargo en ellos la secuencia de interacción entre objetos es más
difícil de seguir que en un Diagrama de Secuencia. Ambos tipos de diagramas
expresan la misma información, por lo que se puede usar cualquiera de los dos
para expresar la interacción entre los objetos del sistema.

La creación de los Diagramas de Interacción de un sistema es una de las

actividades más importantes en el desarrollo orientado a objetos, pues al
construirlos se toman unas decisiones clave acerca del funcionamiento del futuro
sistema. La creación de estos diagramas, por tanto, debería ocupar un porcentaje
significativo en el esfuerzo dedicado al proyecto entero.

Creación de Diagramas de Interacción

Para crear los Diagramas de Colaboración o de Secuencia se pueden seguir los

siguientes consejos:

• Crear un diagrama separado para cada operación del sistema en desarrollo en

el ciclo de desarrollo actual. Para cada evento del sistema, hacer un diagrama
con él como mensaje inicial.

83
• Usando los apartados de responsabilidades y de post-condiciones del contrato
de operación, y la descripción del caso de uso como punto de partida, diseñar
un sistema de objetos que interaccionan para llevar a cabo las tareas
requeridas.
• Si el diagrama se complica, dividirlo en dos diagramas más pequeños. Para ello
se termina la secuencia de mensajes en un mensaje determinado, y en el
segundo diagrama se comienza con el mensaje que terminó el primero. Debe
indicarse en el primer diagrama que el resto de la interacción se detalla en el
segundo.

El comportamiento dinámico del sistema que se describe en un Diagrama de

Interacción debe ser acorde con la estructura estática del sistema que se refleja en
el Diagrama de Clases de Diseño. Es aconsejable realizar un Diagrama de Clases
de Diseño borrador antes de comenzar con los Diagramas de Interacción. La
capacidad de realizar una buena asignación de responsabilidades a los distintos
objetos es una habilidad clave, y se va adquiriendo según aumenta la experiencia
en el desarrollo orientado a objetos.

Responsabilidad es como un contrato u obligación de una clase o tipo. Las

responsabilidades están ligadas a las obligaciones de un objeto en cuanto a su
comportamiento. Básicamente, estas responsabilidades pueden ser de tipo
Conocer o de tipo Hacer:

Conocer:

• Conocer datos privados encapsulados.

• Conocer los objetos relacionados.
• Conocer las cosas que puede calcular o derivar.

Hacer

• Hacer algo él mismo.

• Iniciar una acción en otros objetos.
• Controlar y coordinar actividades en otros objetos.

Por ejemplo, puedo decir que “un Recibo es responsable de calcular el total” (tipo
hacer), o que “una Transacción es responsable de saber su fecha” (tipo conocer).
Las responsabilidades de tipo “conocer” se pueden inferir normalmente del Modelo
Conceptual y una responsabilidad no es lo mismo que un método, pero los
métodos se implementan para satisfacer responsabilidades.

84
Diagrama de Clases de Diseño

Un Diagrama de Clases de Diseño muestra la especificación para las clases

software de una aplicación. Incluye la siguiente información:

• Clases, asociaciones y atributos.

• Interfaces, con sus operaciones y constantes.
• Métodos.
• Navegabilidad.
• Dependencias.

A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra

definiciones de entidades software más que conceptos del mundo real. En la
siguiente figura se muestra un ejemplo de Diagrama de Clases de Diseño sencillo.

Figura 65.

85
Relaciones de Dependencia para Representar Visibilidad entre Clases

Cuando una clase conoce a otra por un medio que no es a través de un atributo
(una asociación con la navegabilidad adecuada), entonces es preciso indicar esta
situación por medio de una dependencia.

Un objeto debe conocer a otro para poder llamar a uno de sus métodos, se dice
entonces que el primer objeto tiene “visibilidad” sobre el segundo. La visibilidad
más directa es por medio de atributo, cuando hay una asociación entre ambas
clases y se puede navegar de la primera a la segunda (un atributo de la primera es
un puntero a un objeto de la segunda). Hay otros tres tipos de visibilidad que hay
que representar en el diagrama de clases mediante relaciones de dependencia:

- Parámetro: Cuando a un método de una clase se le pasa como parámetro un

objeto de otra clase, se dice que la primera tiene visibilidad de parámetro sobre la
segunda. La relación de dependencia entre ambas clases se etiqueta con el
estereotipo <>.

- Local: Cuando en un método de una clase se define una variable local que es un
objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda.
La relación de dependencia entre ambas clases se etiqueta con el estereotipo <>.

- Global: Cuando hay una variable global en el sistema, instancia de una clase A, y
un método de una clase B llama a un método de A, se dice que la clase B tiene
visibilidad global sobre la clase A. La relación de dependencia entre ambas clases
se etiqueta con el estereotipo <>.

No es necesario representar la relación de dependencia entre clases que ya están

relacionadas por medio de una asociación, que se trata de una “dependencia” más
fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qué
elementos hay que revisar cuando se realiza un cambio en el diseño de un
elemento del sistema.

Solitario: Caso Particular de Visibilidad global

El uso de variables globales no se aconseja por los efectos laterales que se

86
pueden presentar, pero hay un caso en el que sí hay cierta globalidad: las clases
que sólo van a tener una instancia. Suele tratarse de clases que se han creado en
el Diseño de Bajo Nivel, que no aparecían en el Modelo Conceptual.

Varias clases de nuestro sistema pueden querer llamar a los métodos de la única
instancia de una clase de ese tipo, entonces sí se considera que es beneficioso
que se pueda acceder a esa instancia como un valor accesible de forma global.

Una solución elegante para este caso se implementa mediante un método de

clase para obtener esa única instancia (los métodos de clase los permiten algunos
lenguajes orientados a objetos, por ejemplo Java), en vez de definirla directamente
como una variable global. Para indicar que una clase sólo va a tener una instancia,
se etiqueta la clase con el estereotipo <>, y las relaciones de dependencia entre
las clases que la usan y se etiquetan también <> en vez de <<>>.

A continuación se muestra un ejemplo del código en Java de una clase

solitario:

public class Solitario {

// se define la instancia como atributo de clase (static)
Solitario static instancia := null;
// método de clase que devuelve la instancia
public static Solitario dar_instancia() {
if (instancia = = null) {
// si no está creada la instancia la crea
instancia := new Solitario();
}
return instancia;
}
... // otros métodos de la clase
}

Cuando otra clase quiere llamar a un método de la instancia incluye el siguiente

código:
variable Solitario;
variable = Solitario.dar_instancia();
variable.método(); // llamada al método que necesitamos

87
3.4.4. Construcción Diagramas de Diseño

Normalmente se tiene una idea de un Diagrama de Clases, con una asignación de

responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases
Borrador, puede seguirse la siguiente estrategia:

1. Identificar todas las clases participantes en la solución software. Esto se lleva a

cabo analizando los Diagramas de Interacción.
2. Representarlas en un diagrama de clases.
3. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo
Conceptual.
4. Añadir los métodos, según aparecen en los Diagramas de Interacción.
5. Añadir información de tipo a los atributos y métodos.
6. Añadir las asociaciones necesarias para soportar la visibilidad de atributos
requerida.
7. Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de
visibilidad de los atributos.
8. Añadir relaciones de dependencia para indicar visibilidad no correspondiente a
atributos.

Algunos de estos pasos se van realizando según se vayan completando los

Diagramas de Interacción correspondientes. No existe precedencia entre la
realización del Diagrama de Clases de Diseño y los Diagramas de Interacción.
Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja
primero más en el de clases y otras veces se trabaja primero más en los de
interacción.

No todas las clases que aparecían en el Modelo Conceptual tienen por qué
aparecer en el Diagrama de Diseño. De hecho, tan solo se incluirán aquellas
clases que tengan interés en cuanto a que se les ha asignado algún tipo de
responsabilidad en el diseño del sistema. No hay, por tanto, un transición directa
entre el Modelo Conceptual y el Diagrama de Clases de Diseño, debido a que
ambos se basan en enfoques completamente distintos: el primero en comprensión
de un dominio, y el segundo en una solución software.

En el Diagrama de Clases de Diseño se añaden los detalles referentes al lenguaje

de programación que se vaya a usar. Por ejemplo, los tipos de los atributos y
parámetros se expresarán en el lenguaje de implementación escogido.

88
Navegabilidad

La navegabilidad es una propiedad de un rol (un extremo de una asociación) que

indica que es posible “navegar” unidireccionalmente a través de la asociación,
desde objetos de la clase origen a objetos de la clase destino. Como se vio en la
unidad 2 y se representa en UML mediante una flecha.

La navegabilidad implica visibilidad, normalmente visibilidad por medio de un

atributo en la clase origen. En la implementación se traducirá en la clase origen
como un atributo que sea una referencia a la clase destino.

Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una

función, deben ser necesarias, si no es así deben eliminarse. Las situaciones más
comunes en las que parece que se necesita definir una asociación con
navegabilidad de A a B son:

• A envía un mensaje a B.
• A crea una instancia B.
• A necesita mantener una conexión con B.

Visibilidad de Atributos y Métodos

Los atributos y los métodos deben tener una visibilidad asignada, que puede ser:
+ Visibilidad pública.
# Visibilidad protegida.
- Visibilidad privada.

También puede ser necesario incluir valores por defecto, y todos los detalles ya
cercanos a la implementación que sean necesarios para completar el Diagrama de
Clases.

Otros Aspectos en el Diseño del Sistema

En los puntos anteriores se ha hablado de decisiones de diseño a un nivel de

granularidad fina, con las clases y objetos como unidades de decisión. En el
diseño de un sistema es necesario también tomar decisiones a un nivel más alto
sobre la descomposición de un sistema en subsistemas y sobre la arquitectura del
sistema (definición de sistemas y subsistemas unidad 2). Esta parte del Diseño de

89
Bajo Nivel es lo que se denomina Diseño del Sistema. Estas decisiones no se
toman de forma distinta en un desarrollo orientado a objetos a como se llevan a
cabo en un desarrollo tradicional. Por tanto, no se va a entrar en este documento
en cómo se realiza esta actividad.

3.5. Fases de Implementación y Pruebas

Una vez se tiene completo el Diagrama de Clases de Diseño, se pasa a la

implementación en el lenguaje de programación elegido. El programa obtenido se
depura y prueba, y ya se tiene una parte del sistema funcionando que se puede
probar con los futuros usuarios, e incluso poner en producción si se ha planificado
una instalación gradual. Una vez se tiene una versión estable se pasa al siguiente
ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a
tal ciclo.

90