MANUAL BREVE PARA EL DESARROLLO CON UML

1. Introducción
Esta asignatura, además de introducir qué es y qué comprende la Ingeniería de Software,
presenta una serie de modelos, técnicas y metodologías para el desarrollo (fabricación)
de productos software.
La mayor parte de las notaciones y diagramas que se exponen en el libro para ilustrar
los 'artefactos' o subproductos, obtenidos en el recorrido por las distintas fases de un
ciclo de vida clásico (en cascada), se corresponden con un estilo de desarrollo 'dirigido
por los datos'. De esta forma, cuando se emplean otros modelos (ciclos de vida) o
paradigmas de desarrollo (OO, dirigido por la funcionalidad, 'por casos de uso', etc.),
algunas de esas notaciones quedan obsoletas o evolucionan hacia otro tipo de
diagramas. La mayor parte de esos modelos y paradigmas de desarrollo se pueden
adecuar al sistema de representación más extendido actualmente: UML. Sin embargo,
el contraste más notable del libro de esta asignatura es que no ofrece un mapa para
traducir las notaciones ni los diagramas de los temas 3, 4 y 5 (del análisis y el diseño), a
los correspondientes, en otros tipos de desarrollo, con la representación en UML. Por
este motivo, lo más importante es entender qué se representa en cada diagrama, en
un caso (temas 3, 4 y 5) y otro (tema 6, UML).
En los modelos de desarrollo clásicos (cascada) se cumplimentan, casi definitivamente,
los objetivos de cada fase para todo el producto que se está desarrollando. Por el
contrario, en los modelos incrementales y evolutivos (los más utilizados actualmente),
se afronta el desarrollo de sólo una parte del producto (o de sus necesidades
funcionales) en cada ciclo. Es decir, en estos últimos modelos de ciclo de vida, la
elaboración se divide en distintas partes, pero, en cada una, se sigue haciendo análisis,
diseño, codificación y pruebas. Por consiguiente, el significado y los objetivos de estas
actividades (análisis, diseño...), ineludibles, son universales para cualquier modelo o
paradigma de desarrollo:
• El análisis pretende la comprensión de las necesidades planteadas por el cliente
(especialmente las funcionales): el dominio del negocio. No consiste en una
sensación subjetiva e individual de que se han comprendido esas necesidades,
sino que requiere elaborar la propuesta de un modelo del funcionamiento
requerido, comprensible y validable, y, por tanto, con un determinado grado de
formalismo en su representación; llámese modelo conceptual o de la lógica del
funcionamiento deseado.
• El diseño consiste en la especificación de cada elemento de la solución software
definitiva, la del funcionamiento individual y la del funcionamiento que resulta
de la colaboración entre esos elementos. Por tanto, constituye una descripción
pormenorizada, rigurosa y exacta, de cada 'pieza' del código, de cómo funciona,
de cómo se relaciona con otras y de cómo, mediante ese funcionamiento
colaborativo entre las partes, se alcanza el comportamiento deseado. El diseño
arquitectónico y el diseño detallado describen el funcionamiento de una misma
cosa, del código que resuelve (o no) las necesidades planteadas en el análisis,
por lo que sus únicas diferencias se refieren a la perspectiva con la que afrontan

1
 MANUAL BREVE PARA EL DESARROLLO CON UML

la granularidad de lo que describen. De esta manera, el diseño arquitectónico no

es nada sin la descripción detallada del contenido de sus partes (de sus módulos
o componentes) y, recíprocamente, el diseño detallado de una parte es una
descripción incompleta del funcionamiento del 'todo', por lo que es insuficiente.
En este sentido, un diseño (bueno o malo) es incorrecto si:
a. Es incompleto. Es decir, si no describe, completa y unívocamente, el
código cuyo comportamiento representa (no hay una representación
adecuada que se pueda valorar).
b. Aunque la especificación esté completa, el funcionamiento que describe
no satisface las necesidades planteadas (no funciona como debería, o no
resuelve el problema).

2. Diagramas clásicos a diagramas UML

En asignaturas precedentes se ha aprendido a manejar los lenguajes y recursos para
elaborar un código que realice una función determinada (lo que comúnmente se
denomina programación). En esta asignatura se aprende a organizar (secuenciar) las
actividades involucradas en esa elaboración (los modelos de desarrollo o ciclos de vida),
a identificar las ventajas y cualidades, obtenidas en el producto final, al realizarlas de
una determinada manera (mediante las técnicas de análisis, diseño, pruebas e
integración que se ven en la asignatura) y, por fin, a representar los resultados
intermedios de esas actividades (sus conclusiones y artefactos intermedios) de una
manera útil para el desarrollo global (mediante los diagramas y las diferentes
representaciones de los capítulos 3, 4 y 5 del libro).
En otro orden de cosas, el desarrollo por casos de uso establece un esquema de
elaboración diferente al mostrado en el libro, aunque, en principio, es compatible con
cualquier modelo de ciclo de vida: a partir de una valoración preliminar, el desarrollo se
bifurca en los de los casos de uso que componen la funcionalidad global del sistema
software, tanto por separado como en lo que se refiere a la coordinación entre ellos.
Obviamente, en cada caso de uso se realizan las actividades de análisis, diseño,
codificación, pruebas e integración con los demás. Esta paralelización del desarrollo es
mucho más fácil de implantar en un ciclo de vida evolutivo o incremental; para los que,
en cada ciclo, se planifica la elaboración de sólo un grupo de casos de uso, de
importancia estratégica en ese momento.
Con todo el planteamiento anterior, el modelado con UML está especialmente indicado
para el desarrollo por casos de uso y para el paradigma de la orientación a objetos.
Buena parte de los diagramas que presenta el libro (especialmente para el análisis,
capítulo 3: DFD y DER) no están reconocidos en la especificación de UML:
• DFD. Como tales, los DFD sólo se utilizan para representar un modelo del
comportamiento deseado, en el análisis. Con ese objetivo (el análisis) estos
diagramas se suelen sustituir, en UML, por los Diagramas de Actividad. En ningún
caso se utiliza esta notación (DFD) para representar el diseño. En el 'Diseño
Estructurado' (Yourdon) el análisis de los DFD se utiliza como herramienta para
obtener un Diagrama de Estructura (que sí es una representación del diseño,
especialmente del arquitectónico).

2
 MANUAL BREVE PARA EL DESARROLLO CON UML

• DER. Estos diagramas tampoco se incluyen en la especificación de UML. Otra

cosa es el modelado de los datos o el modelado Entidad-Relación que, en UML,
se realiza mediante un Diagrama de Clases y sus relaciones. En el análisis, esas
clases son objetos conceptuales (no clases software) y, para modelar las
relaciones entre las entidades que intervienen en el comportamiento deseado,
también se puede utilizar el Diagrama de Estructura (Composite Structure
Diagram). En el diseño también puede necesitarse modelar los datos, las
entidades de información y sus relaciones. Para ello, en UML también se utilizan
los Diagramas de Clases y los Diagramas de Estructura.
En definitiva, lo fundamental es conocer qué está representando cada diagrama de UML
(y su capacidad expresiva), para aplicarlo al objetivo de lo que se representa en cada
caso (en el análisis o en el diseño).

3. Elaboración del desarrollo con diagramas UML

En un caso general, si se utiliza el paradigma de la orientación a objetos y el desarrollo
por casos de uso, la representación coherente con UML más utilizada es:
1. Un planteamiento, previo al análisis, de los casos de uso primarios que
constituyen la funcionalidad principal del sistema software que se está
elaborando, los actores que los manejan, así como los sistemas de apoyo
externos, o actores secundarios, que interaccionan con esos casos de uso. Para
ello, en UML se utiliza el Diagrama de Casos de Uso. A partir de este punto, el
desarrollo se bifurca para cada uno de esos casos de uso.

Figura 1 Diagrama de Casos de Uso para un sistema de venta de billetes de

transporte urbano.

3
 MANUAL BREVE PARA EL DESARROLLO CON UML

2. Análisis: se trata de comprender los requisitos (sobre todo los funcionales) y

representar un modelo del funcionamiento deseado para cada caso de uso.
i. El primer paso para elaborar ese modelo del funcionamiento es
establecer una secuencia en las interacciones (eventos) entre el actor
principal y el sistema, pero considerándolo como una caja negra. Esta
secuencia acción—reacción se puede representar de alguna de estas 3
maneras:
 De manera textual: 'Escritura del Caso de Uso'. Consiste en relatar, de
manera esquemática la evolución de los acontecimientos en la
secuencia de acciones, estímulos o eventos que el actor dirige al
sistema (como una caja negra) y la respuesta, reacción o resultado que
observa (dicho actor).
 Mediante un 'Diagrama de Secuencia del Sistema'. La misma
secuencia acción—reacción anterior se expresa como intercambio de
mensajes entre la línea de tiempo del actor y la del sistema,
considerado como una caja negra. Ignorando la capa de presentación
(IU), los eventos, acciones o estímulos del actor se representan como
invocaciones a funciones o a métodos cuyos argumentos se refieren a
la información que proporciona al sistema. Por el contrario, las
reacciones del sistema no se representan como invocaciones a
funciones, puesto que el actor no es código, sino como mensajes
inteligibles para una persona, con la información que proporcionan.

Figura 2 Diagrama de Secuencia del Sistema.

4
 MANUAL BREVE PARA EL DESARROLLO CON UML

 Mediante un 'Diagrama de Transición de Estados'. En este caso, las

acciones o estímulos del actor se representan como los eventos
causantes de la misma secuencia de transiciones entre las
correspondientes situaciones (estados) en las que el sistema reacciona
a ellos (a los eventos) y produce una respuesta o resultado.
ii. El segundo paso es representar el modelo del funcionamiento deseado.
Se trata de elaborar un modelo que represente el comportamiento del
caso de uso al realizar la secuencia de interacciones construida en el paso
anterior. Por consiguiente, los elementos del modelo, que se comportan
de esa manera, son conceptuales; no representan código sino el
funcionamiento de cada uno, que, en conjunción con el de los demás,
produce el comportamiento deseado para este caso de uso. Aunque se
denomine 'diseño de la lógica del funcionamiento', este modelo se
corresponde con el objetivo de proporcionar una solución funcional
(conceptual, no del código) y pertenece al análisis. Es decir, al expresar la
lógica del funcionamiento, el sistema (que en el paso anterior era un
todo, una caja negra) se descompone en los elementos (conceptuales)
que, con su comportamiento particular y las relaciones entre ellos,
componen la lógica del funcionamiento del caso de uso. En el caso de OO
esos elementos son objetos conceptuales: con atributos, pero sin
métodos (es decir, sin responsabilidad para realizar ninguna acción
definida, más que la manipulación de su propio contenido); no
representan objetos o clases software. Este tipo de modelado se podría
asimilar al E-R Modeling y, en UML, se representa mediante un 'Diagrama
de Clases' especial denominado 'Modelo de Dominio'.

Figura 3 Diagrama del Modelo de Dominio para el caso de uso de una venta.

5
 MANUAL BREVE PARA EL DESARROLLO CON UML

Otro de los objetivos más importantes de esta asignatura es evidenciar la

importancia de que el producto final software tenga determinadas
cualidades añadidas a que, estrictamente, satisfaga las necesidades de
funcionamiento planteadas por el cliente: la independencia funcional
(acoplamiento bajo y cohesión alta), la adaptabilidad (flexibilidad) y la
comprensibilidad. También es cierto que el estudio de cómo se elabora
el código para que contenga estas cualidades excede el ámbito de esta
asignatura. Aunque estas propiedades se introducen en el diseño, resulta
de vital importancia incluirlas en la elaboración desde el inicio del
análisis; especialmente en el desarrollo por casos de uso.
La estrategia global para obtener la independencia funcional, desde el
inicio, y para incorporarla al código, es separar la funcionalidad según los
ámbitos en los que actúa: en la capa de presentación (IU), en la capa de
gobierno de la aplicación, en la capa del negocio (el ámbito del
funcionamiento esencial del sistema, donde se desenvuelven los casos de
uso) y en la capa de los servicios técnicos, en la que se incluyen los
accesos a los datos y a los servicios de apoyo externos. Obviamente, esa
estrategia tiene como objetivo desacoplar el funcionamiento de una capa
(de su código) respecto al de las otras; pero dicho funcionamiento debe
estar perfectamente coordinado entre ellas. De todo ello (de mantener
los vínculos que desacoplan el código de una capa respecto al de las otras
y de coordinar tanto el funcionamiento global como la sincronía entre las
otras capas) se encarga el código de la capa del gobierno de la aplicación
(o el nivel de aplicación), que actúa como el mortero para las otras 3.

Capa de presentación (IU)

Capa de la lógica de la aplicación y su gobierno

Capa de la lógica del negocio

(funcionalidad pedida)

Capa de Servicios Técnicos.

(Acceso a datos almacenados,
adaptadores con servicios de
apoyo, etc.)

Figura 4 Separación de la funcionalidad del código en capas.

6
 MANUAL BREVE PARA EL DESARROLLO CON UML

De esta forma, tras diversificar el desarrollo en cada caso de uso, la

elaboración consiste (de forma simplificada) en:
a. Centrarse, exclusivamente, en la funcionalidad esencial del caso de
uso; la que se desarrolla en la capa de negocio. En este ámbito,
aunque teniendo en cuenta la influencia de la labor de la capa del
gobierno del sistema, la de la capa de presentación y la de la capa se
servicios técnicos, se realiza el análisis, diseño detallado, codificación
y pruebas de cada caso de uso. Además de que el código de cada caso
de uso funcione como se requiere, el criterio principal para
implementarlo es que esos elementos estén poco acoplados.
b. A continuación, se diseña y codifica la parte del software que, en la
capa de gobierno, desacopla y sincroniza el funcionamiento de los
elementos en la capa de negocio, respecto a las otras 2 capas: las
factorías que generan interfaces, con sus correspondientes
realizaciones en los adaptadores que puedan requerir los elementos
de cada caso de uso.
c. Tras esto, los elementos de código, de la capa de negocio y de los
diferentes casos de uso, se agrupan en módulos (partición en
módulos, diseño arquitectónico). Recíprocamente, los elementos de
código de las otras 2 capas también se agrupan de forma coherente
a los módulos obtenidos en la capa de negocio y a los servicios que
les prestan. El criterio principal para hacer estas agrupaciones es que
cada módulo tenga una cohesión alta y, sobre todo, que estén poco
acoplados entre sí.
d. Por último, se elabora el código que, en la capa de gobierno (nivel de
aplicación), se encarga de controlar el flujo de trabajo y organizar los
servicios que proporcionan los casos de uso.
Es decir, para cada caso de uso, la tarea de su análisis se sitúa en el paso
‘a.’ de la secuencia anterior y, por tanto, se refiere, exclusivamente, al
código de la capa de negocio. Además, al analizar el funcionamiento que
se requiere para un caso de uso y elaborar un Modelo de Dominio con los
objetos que lo realizan, aunque sean conceptuales, deben tener un
acoplamiento lo más débil posible.
3. Diseño detallado. Prosiguiendo la labor en un caso de uso, la siguiente tarea es
definir los elementos del código, y su funcionamiento, aún dentro de la capa de
negocio. Es decir, se trata de elaborar cada clase, las operaciones que realiza (sus
métodos) y los contenidos con los que puede realizarlas (sus atributos y
componentes). La descripción detallada de cómo se implementa este
funcionamiento, mediante el código, se denomina ‘diseño detallado de la
dinámica del funcionamiento’ y, para representarla, se necesita determinar
cómo, y en qué momento, cada instancia que interviene en el funcionamiento
intercambia un mensaje con otra (es decir, invoca un método de otra instancia,
con qué argumentos válidos, y qué resultado se obtiene tras la invocación). Los
únicos diagramas de representar ese contenido, y con ese nivel de detalle, son
los Diagramas de Interacción. En UML hay 2 diagramas, equivalentes, de este

7
 MANUAL BREVE PARA EL DESARROLLO CON UML

tipo (de interacción): el Diagrama de Secuencia detallado y el Diagrama de

Colaboración.

Figura 5 Diagrama de Secuencia detallado de la venta de un billete de transporte urbano (diseño

detallado de la dinámica del funcionamiento).

• A un caso de uso determinado le corresponde un único Diagrama de

Secuencia detallado (DS); en el que se representan las interacciones
estímulo—respuesta entre el actor principal y, en este caso, todas y cada una
de las instancias (software) que intervienen en el funcionamiento. Todas las

8
 MANUAL BREVE PARA EL DESARROLLO CON UML

interacciones (las que vienen del actor y las que se establecen entre los
objetos) se representan como paso de mensajes (invocación a métodos)
situados en la línea de tiempo del objeto correspondiente. En realidad, todos
los eventos del actor se reciben en un único objeto cuyo rol particular consiste
en organizar la reacción del sistema ante él y dirigir los mensajes a los objetos
adecuados para que el funcionamiento de dicha reacción sea el adecuado: el
rol del Controlador.
La especificación de la dinámica del funcionamiento se refiere a que cada
mensaje (o la creación de una instancia) se sitúa, exactamente, en el instante
que le corresponde en las líneas de tiempo de las instancias que lo envían y lo
reciben, respectivamente. Por este motivo, no es necesario numerar el orden
de los mensajes. El despliegue de esta representación es, por tanto, vertical,
a lo largo de las líneas de tiempo (sincronizadas) de las instancias que
intervienen.
Para elaborar la representación de este funcionamiento, se parte de los
objetos utilizados en el Diagrama de Dominio (el diseño de la lógica de este
mismo funcionamiento); pero ya no son ‘conceptuales’, sino instancias
software, concretas, a las que se les está asignando responsabilidades
funcionales específicas (los métodos correspondientes al mensaje o a la
invocación que reciben).
En la mayoría de las ocasiones, los objetos del Diagrama de Dominio no son
suficientes para representar, completamente y en detalle, el funcionamiento
del código al realizar algunas operaciones. En esos casos es imprescindible
incorporar nuevos objetos, puramente software, cuyo funcionamiento
complementa la especificación de esa operación (adaptadores, acceso a
servicios externos, especialización de operaciones en un polimorfismo, etc.)
• Diagramas de Colaboración de un caso de uso (Communication Diagram). El
funcionamiento que se deriva de cada evento del actor se puede representar
con un diagrama de colaboración; de manera que la unión de todos ellos
equivale al Diagrama de Secuencia detallado anterior y, por tanto, describe el
diseño detallado de la dinámica del funcionamiento del caso de uso. Además
de esa equivalencia, la sintaxis de ambos diagramas también es muy similar:
intercambio de mensajes (invocaciones a métodos) entre instancias.

9
 MANUAL BREVE PARA EL DESARROLLO CON UML

Figura 6 Diagrama de Colaboración del evento en bucle de ‘introducir un tramo del recorrido’, del caso de uso de la venta
de billetes de transporte urbano.

La principal diferencia entre ambos diagramas es que, en los de colaboración,

el paso de mensajes no está anclado a las líneas de tiempo de las instancias;
por lo que este diagrama se desarrolla horizontalmente. Además, al no existir
líneas de tiempo, es imprescindible numerar el orden en el que se produce
el intercambio de cada mensaje entre las instancias.
En UML no hay otros diagramas con capacidad para representar la dinámica del
funcionamiento con este nivel de detalle. Sin embargo, el diseño detallado del
caso de uso se suele complementar con la representación estática de los
elementos funcionales mediante el Diagrama de Clases.
Al ser el mismo tipo de diagrama que el utilizado en el Diagrama de Dominio del
análisis, el Diagrama de Clases del diseño de este caso de uso también es similar.
Los objetos conceptuales del Diagrama de Dominio (ahora clases software) se
complementan con las clases, puramente software, que se han elaborado para
describir la dinámica del funcionamiento. Además, en todas las clases se
incorporan las responsabilidades (métodos) que se les ha asignado para su
funcionamiento. Así mismo, las relaciones entre clases también se
complementan con las encontradas al implementar el diseño dinámico detallado
(DS).

10
 MANUAL BREVE PARA EL DESARROLLO CON UML

Figura 7 Diagrama de Clases de Diseño (DCD), del caso de uso combinado ‘Alta Presa’ y ‘Alta
Sensor’, correspondiente al mismo sistema de la PEC 2018-2019 de esta asignatura (Gestión de
Recursos Hídricos).

4. Diseño arquitectónico. La descomposición modular de la descripción

arquitectónica de un sistema es ortogonal (transversal) al desarrollo de su
contenido ‘por casos de uso’. Por consiguiente, esa organización se puede
elaborar de forma descendente (top—down) o ascendente (botton—up). La
descomposición modular descendente requiere de mayor experiencia en el
diseño arquitectónico y en el comportamiento del tipo de sistema que se está
desarrollando.

11
 MANUAL BREVE PARA EL DESARROLLO CON UML

La organización arquitectónica ascendente consiste en agrupar en módulos los

elementos de código diseñados en el detalle, por lo que sí es compatible con el
desarrollo por casos de uso.
En cualquier caso, como en el resto de la elaboración, los criterios para realizar
ese agrupamiento son no entorpecer el funcionamiento (requisitos funcionales),
la independencia funcional de los módulos, su adaptabilidad y la
comprensibilidad tanto de su rol como de su funcionamiento.
Si se ha tenido cuidado en utilizar esos mismos criterios al diseñar en detalle la
dinámica del funcionamiento de cada caso de uso, su organización en módulos,
dentro de la capa de negocio (partición de la capa de negocio), tiene mayores
garantías para conservar esa independencia funcional.
En cuanto a la representación, en el ámbito modular del diseño arquitectónico
hay 2 aspectos que se deben describir:
• La estructura de los módulos y de las relaciones entre ellos (estática).
• El funcionamiento de la colaboración entre los módulos (dinámica).
Casi todas las notaciones de los diagramas que se muestran en el tema 4 del libro,
son variantes de diagramas de estructura. Por tanto, su adecuación se limita a la
descripción estática del diseño arquitectónico. Sin embargo, si a estos diagramas
se les dota de una semántica añadida para su ejecución (de menor –raíz— a
mayor nivel –hoja— y de izquierda a derecha, por ejemplo) se aumenta su
expresividad para describir la dinámica de la colaboración (Yourdon—
estructurado, HIPO, Jackson, incluso los de abstracciones o los de objetos).

12
 MANUAL BREVE PARA EL DESARROLLO CON UML

En UML, la descripción estática de la arquitectura se puede obtener con

Diagramas de Estructura (Composite Structure Diagram), Diagramas de
Componentes o, incluso, Diagramas de Clases.

Figura 8 Diagrama de estructura arquitectónica de un sistema genérico.

En el caso de la descripción del funcionamiento de las colaboraciones entre los

módulos de la arquitectura, los diagramas UML más adecuados serían los
Diagramas de Actividad o (según la naturaleza del sistema o esas
colaboraciones) los Diagramas de Transición de Estados.

13