Contexto de La Arquitectura de Software

UNIVERSIDAD TECNOLÓGICA DE PEREIRA
FACULTAD DE INGENIERÍAS
PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
INGENIERÍA DE SOFTWARE III
CONTEXTO DE LA ARQUITECTURA DE SOFTWARE
La arquitectura de software representa la estructura o las estructuras del sistema,

que consta de componentes de software, las propiedades visibles externamente y
las relaciones entre ellas.
La arquitectura de software es un concepto fácil de entender y que la mayoría de

los ingenieros aprecian intuitivamente, sobre todo los que tienen un poco de
experiencia, pero resulta difícil definirlo con precisión. En concreto, es difícil dibujar
una línea precisa entre el diseño y la arquitectura, la arquitectura es un aspecto de
diseño que se concentra en algunas características específicas.
En An Introduction to Software Architecture, David Garlan y Mary Shaw sugieren

que la arquitectura es un nivel de diseño que se centra en aspectos: " Más allá de
los algoritmos y estructuras de datos de la computación; el diseño y la
especificación de la estructura general del sistema emergen como una clase nueva
de problema. Los aspectos estructurales incluyen la estructura global de control y la
organización general; protocolos de comunicación, sincronización y acceso de
datos; asignación de funciones para diseñar elementos; distribución física,
composición de elementos de diseño; ajuste y rendimiento; y selección entre otras
alternativas de diseño”.
Pero la arquitectura es algo más que una estructura; el IEEE Working Group on
Architecture la define como "el concepto de más alto nivel de un sistema en su
entorno”. También incluye el "ajuste" con la integridad del sistema, con las
restricciones económicas, con las preocupaciones estéticas y con el estilo. No se
limita a un enfoque interior, si no que tiene en cuenta el sistema en su totalidad
dentro del entorno de usuario y el entorno de desarrollo, un enfoque exterior.
La arquitectura de un sistema de software es la organización o la estructura de los

componentes importantes del sistema que interactúan mediante interfaces, con
componentes compuestos de interfaces y componentes cada vez más pequeños.
Contexto de la Arquitectura de Software

Ing. Ivonne Castaño Osorio 10
DESCRIPCIÓN DE LA ARQUITECTURA
Para poder hablar y razonar sobre la arquitectura de software, antes se debe definir
una representación arquitectónica, una manera de describir aspectos importantes
de una arquitectura. Esta descripción se captura en un documento de arquitectura
de software, que proporciona una visión general arquitectónica completa del
sistema, mediante una serie de vistas arquitectónicas diferentes para representar
diferentes aspectos del sistema.
VISTAS DE LA ARQUITECTURA
Se representa la arquitectura de software en varias vistas de la arquitectura.

Cada vista de la arquitectura trata un conjunto concreto de problemas, específico
de interesados en el proceso de desarrollo: usuarios, diseñadores, gestores,
ingenieros de sistemas, mantenedores, etc.
Las vistas capturan las principales decisiones de diseño estructural y muestran

cómo se descompone la estructura de software en componentes y cómo se
conectan los componentes mediante conectores para producir formas útiles. Estas
elecciones de diseño deben estar unidas a los requisitos funcionales y
suplementarios y otras restricciones. Aunque, a su vez, añaden más restricciones a
los requisitos y a las próximas decisiones de diseño en un nivel inferior.
La arquitectura se representa mediante un número diferente de vistas de la

arquitectura, que, esencialmente, son extractos que ilustran los elementos
"significativos arquitectónicamente" de los modelos. Estas son:
 La Vista de guión de uso, que contiene guiones de uso y casos de ejemplo

que abarcan riesgos técnicos, de clases o de comportamiento significativos
arquitectónicamente. Es un subconjunto del Modelo de guión de uso.

 La Vista lógica, que contiene las clases de diseño más importantes y su

organización en paquetes y subsistemas, y la organización de estos paquetes y
subsistemas en capas. También contiene algunas realizaciones de guiones de
uso. Es un subconjunto del Modelo de diseño.
 La Vista de implementación, que contiene una visión general del Modelo de
implementación y su organización en términos de módulos en paquetes y capas.
También se describe la asignación de paquetes y clases (de la vista lógica) a los
paquetes y módulos de la vista de implementación. Es un subconjunto
del Modelo de implementación.
 La Vista de proceso, que contiene la descripción de las tareas (proceso y
hebras) implicadas, sus interacciones y configuraciones y la asignación de clases
y objetos de diseño a tareas. Esta vista sólo debe utilizarse si el sistema tiene
un grado significativo de Concurrencia. En RUP, es un subconjunto del Modelo
de diseño.
 La Vista de despliegue, que contiene la descripción de los diferentes nodos
físicos para la mayoría de las configuraciones típicas de la plataforma y la
asignación de tareas (de la vista de proceso) a los nodos físicos. Esta vista sólo
debe utilizarse si el sistema es distribuido. Es un subconjunto del Modelo de
despliegue.
Las vistas de la arquitectura se muestran en el documento de arquitectura de

software. Se puede visualizar vistas adicionales para expresar diferentes
preocupaciones especiales: vista de interfaz de usuario, vista de seguridad, vista de
datos, etc. En sistemas simples se puede omitir algunas de las vistas básicas.
Las vistas de la arquitectura son, esencialmente, abstracciones o simplificaciones de

todo el diseño, en las que las características importantes pasan a ser más visibles y
se dejan de lado los detalles. Estas características son importantes cuando se
razona sobre:
 La evolución del sistema, el paso al siguiente ciclo de desarrollo.

 La reutilización de la arquitectura, o partes de ella, en el contexto de una línea
de productos.
 La evaluación de calidades suplementarias, como rendimiento, disponibilidad,
portabilidad y seguridad.
 La asignación de trabajo de desarrollo a equipos y subcontratistas.

 Las decisiones sobre la inclusión de componentes asequibles.

 La inserción en un sistema más amplio.
Estilo de la arquitectura
Una arquitectura de software, o simplemente una vista de la arquitectura, puede

tener un atributo llamado estilo de la arquitectura, que reduce el conjunto de
formatos posibles para escoger e impone un cierto grado de uniformidad con la
arquitectura. El estilo puede definirse mediante un conjunto de patrones, o
mediante la elección de componentes o conectores específicos como bloques de
compilación básicos. Para un sistema dado, el estilo se puede capturar como parte
de la descripción de la arquitectura en una guía de estilo de la arquitectura, que
se proporciona a través del producto de trabajo Directrices específicas del

proyecto en RUP. El estilo desempeña un papel principal en la comprensibilidad y la
integridad de la arquitectura.
Anteproyecto de arquitectura
La representación gráfica de una vista de la arquitectura se llama anteproyecto

de arquitectura. Para las diferentes vistas que se describen arriba, los
anteproyectos constan de los siguientes diagramas de lenguaje unificado de
modelado [UML01]:
 Vista de guión de uso. Diagramas de guión de uso que representan guiones
de uso, actores y clases de diseño ordinarias; diagramas de secuencia que
representan objetos de diseño y su colaboración
Una vista de la arquitectura llamada vista de guión de uso se utiliza en la

disciplina Requisitos para proporcionar una base para planificar el contenido
técnico de las iteraciones.
Para proporcionar una base para planificar el contenido técnico de las

iteraciones, se utiliza una vista de la arquitectura denominada vista de guión

de uso en los siguientes disciplina de Requisitos . Sólo hay una vista de guión
de uso del sistema, que ilustra los guiones de uso y los escenarios que implican
riesgos técnicos, de clase o de comportamiento significativos
arquitectónicamente. La vista de guión de uso se perfecciona y se contempla
inicialmente en todas las iteraciones.
La vista de guión de uso muestra un subconjunto significativo

arquitectónicamente del modelo de guión de uso, un subconjunto de guiones de
uso y actores.
Las actividades de análisis, diseño e implementación posteriores a los requisitos
se centran en la noción de una arquitectura. La producción y la validación de
esta arquitectura son el foco principal de las primeras iteraciones,
especialmente durante la fase de Elaboración. La arquitectura se representa
mediante un número diferente de vistas de la arquitectura, que, esencialmente,
son extractos que ilustran los elementos "significativos arquitectónicamente" de
los modelos.
Priorizar los guiones de uso: En esta tarea se priorizan los guiones de uso, para
que se pueda decidir su orden de desarrollo. En esta tarea es donde se
identifican y priorizan los guiones de uso significativos arquitectónicamente.
El objetivo de esta actividad es:
 Definir entradas en la selección del conjunto de casos de ejemplo y guiones
de uso que se van a analizar en la iteración actual.
 Definir el conjunto de casos de ejemplo y guiones de uso que representan
alguna funcionalidad significativa o central.

 Definir el conjunto de casos de ejemplo y guiones de uso que tienen una

cobertura arquitectónica sustancial (que ejercen muchos elementos
arquitectónicos)o que presionan o ilustran un punto específico, delicado, de
la arquitectura.
Algunos de los factores que se utilizan para determinar la prioridad de los
guiones de uso se pueden capturar como atributos de Requisitos de software .
Las prioridades resultantes de los guiones de uso también se pueden capturar
como atributos de requisitos, para que se puedan gestionar de manera eficaz.
La vista de guión de uso se documenta en el apartado Vista de guión de uso
del Documento de arquitectura de software. Este apartado contiene una lista de
los guiones de uso y casos de ejemplo significativos en cada paquete del modelo
de guión de uso, junto con propiedades significativas como, por ejemplo,
descripciones del flujo de sucesos, relaciones, diagramas de guión de uso y
requisitos especiales relacionados con cada guión de uso. Tenga en cuenta que
si la vista de guión de uso se desarrolla al principio de la iteración, puede que
algunas de estas propiedades no existan todavía.
 Vista lógica. Diagramas de clase, máquinas de estado y diagramas de objeto
Una vista de la arquitectura llamada vista lógica proporciona la base para

comprender la estructura y la organización del diseño del sistema.
Para proporcionar una base para comprender la estructura y la organización del
diseño del sistema, se utiliza una vista de la arquitectura llamada Vista
lógica en el flujo de trabajo de análisis y diseño. Sólo hay una vista lógica del
sistema, que ilustra las realizaciones de guiones de uso clave, subsistemas,
paquetes y clases que abarcan el comportamiento significativo
arquitectónicamente. La vista lógica se perfecciona durante las iteraciones.

La vista lógica muestra un subconjunto significativo arquitectónicamente del

modelo de diseño, es decir, un subconjunto de las clases, subsistemas y
paquetes, y realizaciones de guiones de uso.
 Vista de proceso. Diagramas de clase y diagramas de objeto (tareas

contenedoras, procesos y hebras)
Una vista de la arquitectura llamada vista de proceso ilustra la descomposición

de procesos del sistema, incluida la correlación de clases y subsistemas con
procesos y hebras.
Para proporcionar una base para comprender la organización de procesos del

sistema, se utiliza una vista llamada Vista de proceso en la disciplina de
análisis y diseño. Sólo hay una vista de proceso del sistema, que ilustra la
descomposición de procesos del sistema, incluida la correlación de claves y
subsistemas con procesos y hebras. La vista de proceso se perfecciona durante
las iteraciones. Como se declara en [BOO98]: "Con UML, los aspectos estáticos
y dinámicos de esta vista se capturan en las mismas clases de diagramas que
para la vista de diseño (es decir, diagramas de clase, diagramas de interacción,
diagramas de actividad y diagramas de gráfico de estados), aunque se centran
en las clases activas que representan estas hebras y estos procesos." Cuando se

construye y se utiliza la vista de proceso, son importantes, por ejemplo, los

problemas de concurrencia, el tiempo de respuesta, el punto muerto, el
rendimiento, la tolerancia a errores y la escalabilidad.
Se pueden realizar diseños para la concurrencia sin utilizar el soporte del
sistema operativo subyacente directo y utilizando, por ejemplo, un planificador
grabado especialmente u otro soporte de tiempo de ejecución. En estos casos,
la concurrencia se simula en el nivel de infraestructura de la aplicación, en vez
de en el sistema operativo. Si es necesario, se pueden utilizar otros estereotipos
(además de las hebras y procesos estándar) para hacer esta distinción (para
guiar la implementación). Por ejemplo, el lenguaje de programación Ada
contiene su propio modelo de concurrencia, basado en tareas Ada; el tiempo de
ejecución Ada debe proporcionar este modelo, independientemente de que el
sistema operativo en el que se ejecuta tenga un equivalente adecuado -hebras,
por ejemplo- que se pueda utilizar para soportar las tareas Ada.
En sistemas en tiempo real, Rational Unified Process recomienda la utilización
de Cápsulas para representar las clases activas en la vista de proceso. Las

cápsulas tienen una semántica fuerte para simplificar el modelado de
concurrencia:
 Utilizan una comunicación basada en mensajes asíncronos a través de
Puertos que utilizan Protocolos bien definidos.

 Utilizan una semántica de ejecución hasta el final para el procesado de
mensajes.
 Encapsulan objetos pasivos (asegurándose de que no se pueden producir
interferencias de hebras).

La vista de proceso muestra la organización de procesos del sistema.
 Vista de implementación. Diagramas de componentes
Una vista de la arquitectura llamada vista de implementación suele capturar la

enumeración de todos los subsistemas del modelo de implementación, los
diagramas de componentes que ilustran la organización de los subsistemas en
capas y jerarquías e ilustraciones de dependencias de importación entre
subsistemas.
La vista de implementación es una de las cinco vistas de la arquitectura de un

sistema. Las otras vistas de la arquitectura son la vista lógica, la vista de caso
de uso , la vista de proceso y la vista de despliegue.
El objetivo de la vista de implementación es capturar las decisiones
arquitectónicas tomadas para la implementación. Normalmente, la vista de
implementación contiene:
 Una enumeración de todos los subsistemas del modelo de implementación
 Diagramas de componentes que ilustran cómo se organizan los subsistemas
en capas y jerarquías
 Ilustraciones de dependencias de importación entre subsistemas
La vista de implementación es útil para lo siguiente:
 Asignar trabajo de implementación a individuos y equipos, o subcontratistas
 Evaluar la cantidad de código que se debe desarrollar, modificar o suprimir
 Razonar la reutilización a gran escala
 Tener en cuenta las estrategias de liberación

La vista de implementación y otras vistas de la arquitectura se atestiguan en el

documento sobre arquitectura de software.
 Vista de despliegue. Diagramas de despliegue
Una vista de la arquitectura llamada vista de despliegue ilustra la distribución de

procesos en un conjunto de nodos del sistema, incluida la distribución física de
procesos y hebras.
Para proporcionar una base para comprender la distribución física del sistema
en un conjunto de nodos de proceso, se utiliza una vista de la arquitectura
llamada vista de despliegue en el flujo de trabajo de análisis y diseño. La
vista de despliegue (una de las cinco vistas, que se muestran a continuación)
ilustra la distribución de procesos en un conjunto de nodos del sistema, incluida
la distribución física de procesos y hebras. La vista de despliegue se perfecciona
durante las iteraciones.

La vista de despliegue muestra la distribución física de procesos del sistema.
Las vistas de la arquitectura se muestran en el Documento de arquitectura de

software. Se puede añadir vistas diferentes, como una vista de seguridad, para
representar otros aspectos específicos de la arquitectura de software.
Esencialmente, las vistas de la arquitectura se pueden ver como abstracciones o

simplificaciones de los modelos construidos en las que se hacen más visibles las
características importantes, y se dejan de lado los detalles. La arquitectura es un
método relevante para aumentar la calidad de cualquier compilación de modelo
durante el desarrollo del sistema.
Documento de arquitectura de software
Este producto de trabajo proporciona una visión general arquitectónica completa

del sistema, mediante una serie de vistas arquitectónicas diferentes para
representar diferentes aspectos del sistema.
El documento de arquitectura de software proporciona una visión general completa

de la arquitectura del sistema de software. Sirve como medio de comunicación
entre el arquitecto de software y otros miembros del equipo de
proyectos respecto a las decisiones significativas para la arquitectura que se llevan
a cabo en el proyecto.
Representación UML: Un conjunto de vistas de arquitectura relevantes: guión de

uso, lógica, proceso, despliegue, implementación, datos.
Debe ajustar la esquematización del Documento de arquitectura de
software para que se adecue a la naturaleza del software:
 Algunas vistas arquitectónicas pueden ser irrelevantes:
 La vista de despliegue no es necesaria para sistemas de CPU única.
 La vista de proceso no es necesaria si el sistema utiliza solo una
hebra única de control.
 La vista de datos no es necesaria a menos que la permanencia de un
objeto sea un aspecto significativo del sistema y el mecanismo de

permanencia requiera una correlación entre objetos permanentes y

no permanentes.
 Algunos aspectos específicos del software pueden requerir su propia sección;
por ejemplo, aspectos relacionados con la gestión de datos o cuestiones de
utilización.
 Es posible que necesite apéndices adicionales para explicar ciertos aspectos,
como los fundamentos de ciertas elecciones críticas, junto con las soluciones
que se han eliminado, o para definir acrónimos o abreviaturas, o principios
de diseño generales presentes.
 El orden de las diferentes secciones puede variar, dependiendo de los
interesados del sistema y sus enfoques o intereses.
A continuación se muestran las ventajas e inconvenientes de cada vista de la
arquitectura:
Vista de guión de uso
Esta vista es obligatoria.
Vista lógica
Esta vista es obligatoria.
Vista de proceso
Esta vista es opcional. Utilice esta vista sólo si el sistema tiene más de una hebra
de control, y las hebras separadas interactúan o son dependientes entre sí.
Vista de despliegue
Esta vista es opcional. Utilice esta vista sólo si el sistema está distribuido entre
más de un nodo. Incluso en estos casos, utilice sólo la vista de despliegue donde la
distribución tenga implicaciones arquitectónicas. Por ejemplo, en los casos en que
existe un único servidor y muchos clientes, una vista de despliegue sólo es
necesaria para delinear las responsabilidades del servidor y los clientes como una
clase de nodos; no es necesario mostrar cada nodo cliente si todos tienen las
mismas posibilidades.
Vista de implementación
Esta vista es opcional. Utilice esta vista sólo en los casos en que la
implementación no esté dirigida estrictamente a partir del diseño, es decir, donde
haya una distribución diferente de responsabilidades entre los paquetes
correspondientes en los modelos de diseño e implementación. Si los paquetes de
los modelos de diseño e implementación son idénticos, esta vista se puede omitir.
Vista de datos

Esta vista es opcional. Utilice esta vista sólo si la permanencia es un aspecto

significativo del sistema y la traducción del modelo de diseño al modelo de datos no
se efectúa automáticamente con el mecanismo de permanencia.

Modelos a los que pertenecen las Vistas
Estos productos de trabajo son un tipo de especificación especial. Son una

representación abstracta o simulación de un "sistema" que proporciona una
descripción completa del sistema desde una perspectiva determinada. Los modelos
se suelen utilizar para obtener una mejor comprensión de cómo funciona el sistema
o cómo documentar decisiones de diseño para la implementación real. Los modelos
suelen estar compuestos de diferentes tipos de componentes, categorizados como
elementos de modelo.

Modelo de guión de uso o caso de uso
Este artefacto es un modelo de las funciones deseadas para el sistema y su

entorno, y sirve como contrato entre el cliente y los desarrolladores. Se utiliza
como entrada esencial para las actividades de análisis, diseño y prueba.
Responsable:
 Analista de sistemas
El Modelo de caso de uso debe ser un medio de comunicación que puede servir

como contrato entre el cliente, los usuarios y los desarrolladores del sistema sobre
la funcionalidad del sistema, que permite:
 Que los clientes y usuarios validen que el sistema se convierta en lo que
esperaban.
 Que los desarrolladores del sistema construyan lo que se espera.
El modelo de caso de uso consta de casos de uso y actores. Cada caso de uso del
modelo se describe detalladamente, mostrando paso a paso el modo en que el
sistema interactúa con los actores y lo que el sistema hace en el caso de uso . Los
casos de uso funcionan como hebra unificadora en todo el ciclo vital del software; el
mismo modelo de caso de uso se utiliza en el análisis,
diseño, implementación y prueba del sistema.
Representación UML: Modelo, estereotipado como <<modelo de caso de uso >>

Un modelo de caso de uso puede tener las siguientes propiedades:
 Introducción: Descripción textual que sirve como breve introducción al
modelo.
 Descripción de inspección: Descripción textual que contiene información
no reflejada por el resto del modelo de caso de uso y que incluye secuencias
típicas en las que los usuarios emplean los casos de uso y funcionalidad no
manejada por el modelo de caso de uso .
 Paquetes de casos de uso : Paquetes del modelo, representando una
jerarquía.
 Casos de uso : Casos de uso del modelo, propiedad de los paquetes.

 Actores: Actores del modelo, propiedad de los paquetes.

 Relaciones: Relaciones del modelo, propiedad de los paquetes.
 Diagramas: Diagramas del modelo, propiedad de los paquetes.
 Vista de caso de uso : Vista de caso de uso del modelo, que es una vista
de arquitectura que muestra los casos de uso o los escenarios
significativos.
Personalice el modelo de caso de uso para que dé soporte a las necesidades del
proyecto. Puede consistir en incluir sólo un subconjunto de los productos subtrabajo
(propiedades), personalizar el nivel de formalidad en el que se crean y se gestionan
los productos subtrabajo y personalizar los productos subtrabajo individuales.
Las personas siguientes utilizan el modelo de caso de uso :
 El cliente aprueba el modelo de caso de uso . Cuando tenga la aprobación, sabe que el
sistema es lo que desea el cliente. También puede utilizar el modelo para discutir el
sistema con el cliente durante el desarrollo.
 Los usuarios potenciales utilizan el modelo de caso de uso para comprender mejor el
sistema.
 El arquitecto de software utiliza el modelo de caso de uso para identificar la
funcionalidad arquitectónicamente significativa.
 Los diseñadores utilizan el modelo de caso de uso para obtener una visión general del
sistema. Cuando perfeccione el sistema, por ejemplo, necesita documentación sobre el
modelo de caso de uso para ayudarle en ese trabajo.
 El gestor utiliza el modelo de caso de uso para planificar y hacer el seguimiento del
modelado de caso de uso y también del diseño posterior.
 Las personas externas al proyecto pero dentro de la organización, ejecutivos, y comités
directivos, utilizan el modelo de caso de uso para obtener una perspectiva en lo que se ha
llevado a cabo.
 Las personas revisan el modelo de caso de uso para proporcionar la información de
retorno apropiada a los desarrolladores de forma regular.
 Los diseñadores utilizan el modelo de caso de uso como base para su trabajo.
 Los verificadores utilizan el modelo de caso de uso para planear las actividades de
prueba (prueba de caso de uso y de integración) tan pronto como sea posible.
 Quienes desarrollarán la versión siguiente del sistema utilizan el modelo de caso de
uso para comprender como funciona la versión existente.
 Los escritores de documentación utilizan los casos de uso como base para escribir los
manuales de usuario del sistema.
Directriz: Modelo de caso de uso
Un modelo de guión de uso es un modelo de las funciones previstas del sistema

y su entorno, y sirve como un contrato entre el cliente y los desarrolladores.
Esta directriz proporciona un mapa para desarrollar un modelo de guión de uso.

Explicación
Un modelo de caso de uso es un modelo de las funciones previstas del sistema
y su entorno y sirve como un contrato entre el cliente y los desarrolladores. Los
casos de uso sirven como hebra de unión a lo largo del desarrollo del sistema.
El mismo modelo de caso de uso es el resultado de la disciplina de Requisitos y
se utiliza como entrada para disciplinas de Prueba, Diseño y Análisis.
En el diagrama que se incluye más abajo se muestra una parte de un modelo
de caso de uso para el Sistema de máquinas de reciclaje.
Diagrama de caso de uso que muestra un ejemplo de un modelo de caso de

uso con actores y casos de uso .
Hay muchos modos de modelar un sistema, y cada uno de ellos puede servir
para un objetivo diferente. Sin embargo, el objetivo más importante de un
modelo de caso de uso es comunicar el comportamiento del sistema al cliente o
usuario. Por lo tanto, el modelo debe ser fácil de comprender.
Los usuarios y cualquier otro sistema que pueda interactuar con el sistema son
los actores. Puesto que representan usuarios del sistema, los actores ayudan a
delimitar el sistema y a facilitar una imagen más clara de lo que se supone que
se debe hacer. Los casos de uso se desarrollan en base a las necesidades de
los actores, garantizando así que el sistema resulta ser lo que los usuarios
esperaban.
Cómo evoluciona el modelo de caso de uso
Los actores y los casos de uso se encuentran gracias a los requisitos de los
clientes y usuarios potenciales considerada como información vital. Cuando se
descubren, los casos de uso y los actores se deben describir brevemente. Antes
de describir los casos de uso con detalle, el cliente debe revisar el modelo de

caso de uso para verificar que se encuentren todos los casos de uso y los
actores y que, juntos, pueden facilitar lo que desea el cliente.
En el entorno de desarrollo iterativo, debe seleccionar un subconjunto de casos
de uso que se detallan en cada iteración. Consulte también el apartado Tarea:
Dar prioridad a los casos de uso .
Una vez que se han encontrado los actores y los casos de uso , se describe con
detalle el flujo de sucesos de cada caso de uso . Las descripciones muestran
cómo interactúa el sistema con los actores y lo que hace el sistema en cada
caso individual.
Por último, se revisa el modelo de guiíón de uso completado (incluidas las
descripciones de los casos de uso ) y lo utilizan los desarrolladores y los
clientes a fin de ponerse de acuerdo sobre lo que debe llevar a cabo el sistema.
Cómo evitar la descomposición funcional
No es extraño que el modelo de caso de uso degenere en una descomposición
funcional del sistema. Para evitarlo, fíjese en los síntomas siguientes:
 Casos de uso "pequeños", lo que significa que el flujo de sucesos sólo tiene
una o unas pocas sentencias.
 "Muchos" casos de uso , lo que significa que el número de casos de uso es
algún múltiplo de cien, en lugar de un múltiplo de diez.
 Nombres de casos de uso que son construcciones tales como "realice esta
operación en estos datos concretos", o bien, "realice esta función con estos
datos concretos". Por ejemplo, "Entre número de identificación personal en
un cajero automático" no se debe modelar como un caso de uso separado
para el cajero automático, puesto que nadie utiliza el sistema sólo para
hacer esto. Un caso de uso es un flujo de sucesos completo, cuyo resultado
es algo de valor para un actor.
A fin de evitar la descomposición, asegúrese de que el modelo de caso de uso
ayuda a responder preguntas como, por ejemplo:
 ¿Cuál es el contexto del sistema?
 ¿Por qué se ha construido el sistema?
 ¿Qué quiere conseguir el usuario al utilizar el sistema?
 ¿Qué valor añade el sistema a los usuarios?
Requisitos no funcionales
Resulta bastante fácil ver que los casos de uso son un procedimiento óptimo
para capturar requisitos funcionales en un sistema. Pero ¿qué sucede en el
caso de los requisitos no funcionales? ¿Qué son y dónde se capturan?

Con frecuencia, los requisitos no funcionales se clasifican por categorías como,

por ejemplo, utilización, rendimiento y requisitos sustituibles (consulte también
el apartado Concepto: Requisito). Suelen ser requisitos que especifican la
necesidad de satisfacer los requisitos legales y normativos. También pueden
ser restricciones de diseño debido al sistema operativo utilizado, el entorno de
plataforma, problemas de compatibilidad o los estándares aplicables de
cualquier aplicación. En general, cualquier requisito que no permita más de una
opción de diseño se debe considerar como una restricción de diseño.
Muchos requisitos no funcionales se aplican a un caso de uso individual y se
capturan en las propiedades de dicho caso de uso . En ese caso, se capturan en
el flujo de sucesos del caso de uso , o bien, como un requisito especial del caso
de uso (consulte el apartado Directriz: Caso de uso ).
Ejemplo:
En el Sistema de máquinas de reciclaje, un requisito no funcional específico del
caso de uso Devolver elementos de depósito podría ser:
La máquina debe poder reconocer elementos de depósito con una fiabilidad de
más del 95 por ciento.
A menudo, los requisitos funcionales se aplican al sistema completo. Este tipo
de requisitos se capturan en las Especificaciones suplementarias (consulte el
apartado Producto de trabajo: Especificaciones suplementarias).
Especificaciones suplementarias
Este artefacto captura los requisitos del sistema que todavía no se han
capturado en los artefactos de requisitos de comportamiento como las
especificaciones de guión de uso.
Las especificaciones suplementarias capturan los requisitos del sistema que

todavía no se han capturado en los guiones de uso del modelo de guión de uso.
Estos requisitos incluyen:
 Requisitos legales y normativos, y estándares de aplicación
 Los atributos de calidad del sistema que se debe construir, que incluyen la
utilización, la fiabilidad, el rendimiento y requisitos de capacidad de soporte
 Otros requisitos como los de los sistemas operativos y entornos, la
compatibilidad con otro software, y las restricciones de diseño.

Las especificaciones suplementarias son un complemento importante del Modelo

de guión de uso, puesto que conjuntamente capturan todos los requisitos de
software (funcionales y no funcionales) que se deben describir para servir como
una completa Especificación de requisitos de software.
Es recomendable que las especificaciones suplementarias se organicen de

acuerdo con las categorías de requisitos. Para ver una descripción de una
perspectiva de categorización utilizando el acrónimo "FURPS+", consulte el
apartado Concepto: Requisitos.
La especificación suplementaria captura todos los requisitos globales del

sistema, no solo los funcionales. Existe la creencia errónea de que todos los
requisitos funcionales residen en los productos de trabajo de Guión de uso y que
todos los requisitos no funcionales residen en el producto de trabajo de la
Especificación suplementaria. Esto no es exactamente así, puesto que algunos
requisitos funcionales son aplicables al sistema de forma global (como por
ejemplo un requisito de ayuda en línea). De forma similar, algunos requisitos no
funcionales sólo son aplicables a un guión de uso determinado (o un flujo dentro
de un guión de uso, en cuyo caso el requisito debería adjuntarse al guión de
uso, de lo contrario el sistema tendría un diseño excesivo.
Los tipos de requisitos suplementarios varían mucho entre un proyecto y otro,

de modo que debe aplicarse la personalización para definir las secciones
aplicables a su proyecto.
Ejemplo:
En el Sistema de máquinas de reciclaje, un requisito no funcional que se
aplique al sistema completo podría ser:
La máquina sólo permite un usuario a la vez.
El dilema del qué frente al cómo
Una de las cosas más difíciles es aprender cómo determinar el nivel de detalle
de los casos de uso para "empezar y terminar". ¿Dónde se inician las
características y empiezan los casos de uso , y dónde termina el caso de uso y

empieza el diseño? Con frecuencia se ha indicado que los casos de uso o los
requisitos de software debe indicar lo que hace el sistema, pero no cómo lo
lleva a cabo. Considere el gráfico siguiente:
El destino de una persona es el punto de inicio de otra.

Dependiendo del fondo, puede utilizar un contexto diferente para decidir lo que
considera que es "qué" y lo que es "cómo". Debe tener en cuenta estas
necesidades cuando vaya a determinar si un detalle concreto se debe quitar o
no del modelo de caso de uso .
Existe una distinción entre los casos de uso concretos y abstractos. Un actor
inicializa el caso de uso concreto y constituye un flujo de sucesos completo.
"Completo" significa que una instancia del caso de uso lleva a cabo toda la
operación a la que ha llamado el actor.
Una caso de uso abstracto nunca crea instancias de sí mismo. Los casos de
uso abstractos se incluyen en (consulte el apartado Directriz: Relación de
inclusión), se amplían en (consulte el apartado Directriz: Relación ampliada) o
bien se generalizan en (consulte el apartado Directriz de producto de trabajo:
Generalización de caso de uso ) otros casos de uso . Cuando se inicia un caso
de uso concreto, se crea una instancia del caso de uso . Dicha instancia
también muestra el comportamiento que especifican sus casos de uso
abstractos asociados. Por lo tanto, no se crean instancias separadas de los
casos de uso abstractos.
La distinción entre ambas es importante, puesto que lo que "ven" los actores
son casos de uso concretos, y se inician en el sistema.
Puede indicar que un caso de uso es abstracto escribiendo el nombre en
cursiva.
Ejemplo:

El caso de uso Crear tarea se incluye en el caso de uso Registrar pedido. Crear
tarea es un caso de uso abstracto.
En el Sistema de manipulación de almacén, el caso de uso abstracto Crear
tarea se incluye en el caso de uso Registrar pedido. Cuando se inicia Registrar
pedido, se crea una instancia de Registrar pedido que, aparte de seguir el flujo
de sucesos de Registrar pedido, también sigue el flujo de sucesos descrito en el
caso de uso Crear tarea incluido. Crear tarea nunca se ejecuta por sí mismo,
siempre como parte de Registrar pedido (o cualquier otro caso de uso en el que
se haya incluido). Por consiguiente, Crear tarea es un caso de uso abstracto.
Estructuración del modelo de caso de uso
Existen tres motivos principales para estructurar el modelo de caso de uso :
 Para simplificar la comprensión de los casos de uso .
 Para particionar el comportamiento común descrito en varios casos de uso .
 Para simplificar el mantenimiento del modelo de caso de uso .
No obstante, la estructuración no es la primera cosa que debe hacer. No es
necesario estructurar los casos de uso hasta que se sepa un poco más sobre su
comportamiento, más allá de una descripción breve de una frase. Debe haber
establecido, al menos, un esquema paso a paso para el flujo de sucesos del
caso de uso con el objeto de garantizar que las decisiones se basan en la
comprensión bastante precisa del comportamiento.
Para estructurar los casos de uso , existen tres tipos de relaciones. Debe
utilizar dichas relaciones para descomponer en factores fragmentos de los
casos de uso que se pueden reutilizar en otros casos de uso , o que son
especializaciones u opciones del caso de uso . El caso de uso que representa la
modificación se denomina caso de uso de adición. El caso de uso que se
modifica se denomina caso de uso de base.
 Si alguna parte del caso de uso de base representa una función y el caso de
uso sólo depende del resultado de ésta, no del método utilizado para
generar el resultado, puede descomponer en factores dicha parte en un caso

de uso de adición. La adición se inserta explícitamente en el caso de uso de

base utilizando la relación de inclusión. Consulte también el
apartado Directriz: Relación de inclusión.
 Si alguna parte del caso de uso es opcional o no se necesita para
comprender el objetivo principal del caso de uso , puede descomponerla en
factores en un caso de uso de adición con el objeto de simplificar la
estructura del caso de uso de base. La adición se inserta implícitamente en
el caso de uso de base utilizando la relación de ampliación. Consulte
también el apartado Directriz: Relación ampliada.
 Si hay casos de uso que tienen puntos comunes en el comportamiento y la
estructura y similitudes en el objetivo, sus partes comunes se pueden
descomponer en factores en un caso de uso de base (padre) que heredan
los casos de uso de adición (hijos). Los casos de uso hijos pueden insertar
nuevo comportamiento y modificar comportamiento existente en la
estructura que heredan del caso de uso padre. Consulte también el
apartado Directriz de producto de trabajo: Generación de caso de uso .
Puede utilizar la generalización de actor para mostrar cómo los actores son
especializaciones entre sí. Consulte también el apartado Directriz:
Generalización de actor.
Ejemplo:
Considere parte del modelo de caso de uso para un Sistema de gestión de
pedidos.
Resulta útil separar el Cliente común del Cliente de Internet, puesto que
propiedades ligeramente diferentes. No obstante, puesto que el Cliente de
Internet muestra todas las propiedades de un Cliente, el Cliente de Internet se
puede presentar como una especialización del Cliente, indicado con una
generalización de actor.
Los casos de uso concretos que se muestran en este diagrama son Pedido por
teléfono (que inicializa el actor Cliente) y Pedido por Internet (que inicializa el
Cliente de Internet). Ambos casos de uso son variaciones del caso de uso Hacer
pedido, más general, que en este ejemplo es abstracto. El caso de uso Solicitar
catálogo representa un segmento ce comportamiento opcional que no forma
parte del objetivo principal de Hacer pedido. Se ha descompuesto en factores
en un caso de uso abstracto a fin de simplificar el caso de uso Hacer pedido. El
caso de uso Suministrar datos de cliente representa un segmento de
comportamiento que se ha descompuesto en factores, puesto que es una

función separada de la que sólo el resultado afecta al caso de uso Hacer

pedido. El caso de uso Suministrar datos de cliente también se puede reutilizar
en otros casos de uso . En este ejemplo, tanto Solicitar catálogo como
Suministrar datos de cliente son abstractos.
El diagrama de caso de uso muestra parte del modelo de caso de uso para un
Sistema de gestión de pedidos.
En la tabla siguiente se muestra una comparación más detallada entre las tres
relaciones de casos de uso diferentes:
Generalizac
Pregunta Ampliación Inclusión
ión
El caso de
El caso de El caso de uso de
¿Cuál es
uso de uso de base adición
la
adición hace hace (hijo) hace
dirección
referencia al referencia al referencia al
de la
caso de uso caso de uso caso de uso
relación?
de base. de adición. de base
(padre).
¿La Sí, en la No. Si se No.
relación parte de la desea incluir

el mismo
segmento de
comportami
ento más de
tiene
una vez, se
multiplicid adición.
debe
ad?
establecer
en el caso
de uso de
base.
No. Si se
desea
expresar
una
¿La condición en
relación la inclusión,
Sí. No.
tiene una se debe
condición? indicar
explícitamen
te en el caso
de uso de
base.
Con
¿El caso Con
frecuencia
de uso de frecuencia
sí, pero no Sí.
adición es no, pero
necesariame
abstracto? puede serlo.
nte.
¿Modifica La La inclusión Las
la adición ampliación modifica instancias
el caso de modifica explícitamen que se crean
uso de implícitamen te el efecto del caso de
base? te el del caso de uso de base
comportamie uso de base. (padre) no
nto del caso afectan al
de uso de hijo. Para
base. obtener los

efectos de la
adición, se
deben crear
instancias
del caso de
uso de base
(hijo).
¿El caso
de uso de
base debe
Junto con Si es
ser
Sí. las abstracto,
completo
adiciones, sí. no.
y
significativ
o?
¿El caso
de uso de
adición Junto con el
debe ser caso de uso
No. No.
completo de base
y (padre), sí.
significativ
o?
¿El caso
de uso de
No. La
adición
inclusión Sí, por parte
puede
está de los
acceder a
Sí. encapsulada mecanismos
los
, y sólo se de herencia
atributos
"ve" a sí normales.
del caso
misma.
de uso de
base?
¿El caso No. El caso No. El caso No. En este
de uso de de uso de de uso de sentido, el

base caso de uso

base sólo
puede de base
base debe conoce el
acceder a (padre) debe
estar bien efecto de la
los estar bien
formado a adición. La
atributos formado a
falta de la adición está
del caso falta de la
adición. encapsulada
de uso de adición
.
adición? (hijo).
Otro aspecto de la organización del modelo de caso de uso para simplificar la

comprensión consiste en agrupar los casos de uso en paquetes. El modelo de
caso de uso se puede organizar como una jerarquía de paquetes de casos de
uso , con "hojas" que son actores o casos de uso . Consulte también Directriz:
Paquete de casos de uso .
Este gráfico muestra la jerarquía del modelo de caso de uso . Las flechas
indican posibles propiedades.
¿Los casos de uso siempre están relacionados con actores?
La ejecución de cada caso de uso incluye la comunicación con uno o más
actores. Un actor que solicita al sistema que lleve a cabo una acción
determinada inicia siempre las instancias de caso de uso . Esto implica que
todos los casos de uso deben tener asociaciones de comunicación con actores.
El motivo de esta regla es reforzar el sistema para proporcionar sólo la
funcionalidad que necesitan los usuarios, y nada más. Tener casos de uso que
nadie solicita, indica que existe algún error en el modelo de caso de uso o en
los requisitos.
Sin embargo, esta regla tiene algunas excepciones:

 Si el caso de uso es abstracto (no se pueden crear instancias del mismo por
separado), su comportamiento puede no incluir la interacción con actores.
En este caso, no existe ninguna asociación de comunicación con actores
desde el caso de uso abstracto.
 Un caso de uso hijo en una relación de generalización no necesita tener un
actor asociado al mismo si el caso de uso padre describe la comunicación
con todos los actores.
 Un caso de uso de base en una relación de inclusión no necesita tener un
actor asociado al mismo si el caso de uso de inclusión describe la
comunicación con todos los actores.
 Un caso de uso se puede iniciar según una planificación (por ejemplo, una
vez a la semana o una vez al día), lo que significa que el reloj del sistema es
el iniciador. El reloj del sistema es interno del sistema, y un actor no inicia el
caso de uso , sino que lo inicia un suceso interno del sistema. Si no se
produce ninguna otra interacción de los actores en el caso de uso , no tiene
ninguna asociación con los actores. Sin embargo, para mayor claridad,
puede utilizar un actor ficticio, "Hora", a fin de mostrar el modo en el que se
inicia el caso de uso en los diagramas de caso de uso .
Descripción de inspección
La descripción de inspección del modelo de caso de uso debe:
 Establecer cuáles son los casos de uso principales del sistema (el motivo por
el que se ha construido el sistema).
 Resumir hechos técnicos importantes sobre el sistema.
 Señalar las delimitaciones del sistema - cosas se espera que no haga el
sistema.
 Resumir el entorno del sistema, por ejemplo, las plataformas de destino y el
software existente.
 Describir todas las secuencias en las que se ejecutan normalmente los casos
de uso en el sistema.
 Especificar la funcionalidad que no maneja el modelo de caso de uso .
Ejemplo:
A continuación, se incluye un ejemplo de una descripción de inspección del
modelo de caso de uso de la Máquina de reciclaje:
Este modelo contiene tres actores y tres casos de uso . El caso de uso principal
es Elementos de reciclaje, que representa el objetivo más importante de la
máquina de reciclaje.

Los casos de uso de soporte son los siguientes:

 Imprimir informe diario, que permite que un operador obtenga un informe
sobre el número de elementos que se han reciclado.
 Administrar elemento de depósito, que permite que un operador cambie el
valor de reembolso por un tipo de elemento de depósito, o bien, que añada
nuevos tipos de elementos de depósito.
Directriz: Caso de uso
Un guión de uso describe lo que hace el sistema para satisfacer un requisito. En

esta directriz se explica cómo identificar y desarrollar guiones de uso.
Explicación
En esta definición hay numerosas palabras clave:
 Instancia de guión de uso. La secuencia a la que se hace referencia en la
definición es, en realidad, un flujo de sucesos específico a través del
sistema, o una instancia. Puede haber varios flujos de sucesos, y muchos de
ellos pueden ser muy similares. Para que el modelo de guiones de uso sea
comprensible, debe agrupar flujos de sucesos similares en un guión de uso.
Identificar y describir un guión de uso significa, en realidad, identificar y
describir un grupo de flujos de sucesos relacionados.
 Ejecuciones del sistema. Significa que el sistema proporciona el guión de
uso. Un actor se comunica con una instancia de guión de uso del sistema.
 Un valor de resultado observable. Puede transferir un valor en un guión
de uso ejecutado satisfactoriamente. Un guión de uso debe asegurarse de
que un actor puede realizar una tarea que tiene un valor identificable. Es
muy importante al identificar la granularidad o el nivel correcto para un
guión de uso. El nivel correcto hace referencia a conseguir guiones de uso
que no sean demasiado pequeños. En circunstancias determinadas, puede
utilizar un guión de uso como una unidad de planificación en una
organización que incluya personas que son actores en el sistema.

 Acciones. Una acción es un procedimiento algorítmico o computacional. Se

invoca cuando el actor proporciona una señal al sistema, o bien, cuando el
sistema obtiene un suceso de tiempo. Una acción puede implicar
transmisiones de señal al actor de la invocación o a otros actores. Una
acción es global, lo que significa que se realiza toda o no se lleva a cabo en
absoluto.
 Un actor determinado. Un actor es clave para buscar el guión de uso
correcto y, en especial, debido a que el actor ayuda a evitar guiones de uso
que sean demasiado grandes. Imagine, por ejemplo, una herramienta de
modelado visual. En realidad, hay dos actores para esta aplicación: un
desarrollador, es decir, alguien que desarrolla sistemas utilizando la
herramienta como soporte, y un administrador del sistema, es decir, una
persona que gestiona la herramienta. Cada uno de estos actores tiene sus
propias demandas del sistema y, por ello, necesitan un conjunto propio de
guiones de uso.
La funcionalidad de un sistema se define por medio de guiones de uso
diferentes, donde cada uno de ellos representa un flujo de sucesos específico. La
descripción de un guión de uso define lo que sucede en el sistema cuando se
ejecuta el guión de uso.
En un cajero automático el cliente puede, por ejemplo, retirar dinero de una

cuenta, transferir dinero a una cuenta o comprobar el saldo de una cuenta. Estas
funciones corresponden a flujos que se pueden representar con guiones de uso.
Cada guión de uso tiene una tarea propia que realizar. Los guiones de uso
recopilados constituyen todos los modos posibles de utilizar el sistema. Puede
obtener una idea de la tarea de un guión de uso sólo con observar su nombre.
Cómo buscar guiones de uso
A continuación, se incluye un conjunto de preguntas que pueden resultar útiles
al identificar guiones de uso:
 Para cada actor identificado, ¿en qué tareas se implica al sistema?

 ¿Se debe informar al actor sobre ciertas apariciones en el sistema?

 ¿Debe informar el actor sobre cambios externos repentinos al sistema?
 ¿Debe proporcionar el sistema el comportamiento correcto a la empresa?
 ¿Pueden realizar los guiones de uso identificados todas las características?
 ¿Qué guiones de uso dan soporte y mantienen el sistema?
 ¿Qué información se debe modificar o crear en el sistema?
Con frecuencia, los guiones de uso que se pasan por alto debido a que no
representan lo que son habitualmente las tareas principales del sistema, pueden
ser del tipo siguiente:
 Inicio y detención del sistema.
 Mantenimiento del sistema. Por ejemplo, añadir nuevos usuarios y
establecer perfiles de usuario.
 Mantenimiento de los datos almacenados en el sistema. Por ejemplo, el
sistema se construye para funcionar el paralelo con un sistema heredado y
se deben sincronizar los datos entre ambos.
 Funcionalidad necesaria para modificar el comportamiento del sistema. Un
ejemplo sería la funcionalidad para crear nuevos informes.
Si ha desarrollado un modelo de guión de uso empresarial y un modelo de
análisis empresarial, dichos artefactos constituyen un punto de partida adecuado
para identificar guiones de uso.
Cómo evoluciona un guión de uso
En iteraciones anteriores de la elaboración, sólo se han descrito algunos guiones
de uso (los que se consideraban significativos arquitectónicamente) con un poco
más de detalle, además de una descripción breve. En primer lugar, siempre debe
desarrollar un esquema del guión de uso (en formato de paso a paso) antes de
profundizar en los detalles. Este esquema paso a paso debe ser el primer intento
al definir la estructura del flujo de sucesos del guión de uso (consulte el
apartado Flujo de sucesos - Estructura que se incluye más abajo). Empiece
siempre por el flujo básico del guión de uso. Una vez que se haya llegado a
algún tipo de acuerdo sobre el esquema del flujo básico, puede añadir lo que
serán los flujos alternativos en relación con el flujo básico.
Hacia el final de la elaboración, debe haber completado todos los guiones de uso
que tenga previstos describir con detalle.
¿Se describen todos los guiones de uso con detalle?
Con frecuencia, en el modelo hay guiones de uso que son tan simples que no
necesitan una descripción detallada del flujo de sucesos, basta con un esquema

paso a paso. Los criterios para tomar esta decisión se basan en que no se
observan desacuerdos entre el tipo de lectores del usuario sobre lo que significa
el guión de uso, y que los diseñadores y los verificadores se siente satisfechos
con el nivel de detalle que proporciona el formato paso a paso. Por ejemplo, lo
guiones de uso que describen la recuperación o entrada simple de algunos datos
del sistema.
Ámbito de un guión de uso
A menudo resulta difícil decidir si un conjunto de interacciones de usuario-
sistema, o diálogo, son uno o varios guiones de uso. Considere el uso de una
máquina de reciclaje. El cliente inserta elementos de depósito como, por
ejemplo, latas, botellas y cajas en la máquina de reciclaje. Una vez que ha
insertado todos los elementos de depósito, pulsa un botón y se imprime un
recibo. A continuación, puede intercambiar el recibo por dinero.
¿Hay un guión de uso para insertar un elemento de depósito y otro guión de uso
para solicitar el recibo? O bien, ¿está todo en un guión de uso? Hay dos
acciones, pero la una sin la otra tienen escaso valor para el cliente. Más bien, lo
que tiene valor para el cliente (y tiene sentido para él), es un diálogo completo
con todas las inserciones y la obtención del recibo. Por ello, el diálogo completo,
desde la inserción del primer elemento de depósito hasta que pulsa el botón para
obtener el recibo, es un guión de uso completo, un solo guión de uso.
Además, es posible que desee mantener juntas las dos acciones, a fin de
revisarlas al mismo tiempo, modificarlas y probarlas juntas, escribir manuales y,
en general, gestionarlas como una unidad. Esto se convierte en una cuestión
obvia en los sistemas más grandes.
Cómo se realizan los guiones de uso
Un guión de uso describe lo que sucede en el sistema cuando un actor interactúa
con el sistema para ejecutar el guión de uso. El guión de uso no define cómo
ejecuta el sistema internamente sus tareas en términos de objetos de
colaboración. Este aspecto se deja para que lo muestren las realizaciones de los
guiones de uso.
Ejemplo:
En el ejemplo del teléfono, el guión de uso indica, entre otras cosas, que el
sistema emite una señal cuando se descuelga el receptor y que entonces el
sistema recibe dígitos, busca la parte receptora, llama a su teléfono, conecta la
llamada, transmite la conversación, y así sucesivamente.

En un sistema que se está ejecutando, una instancia de un guión de uso no

corresponde a ningún objeto concreto del modelo de implementación (por
ejemplo, una instancia de una clase en el código). En cambio, corresponde a un
flujo de sucesos específico que ha invocado un actor y ejecutado como una
secuencia de sucesos entre un conjunto de objetos. En otras palabras, las
instancias de los guiones de uso corresponden a comunicar instancias de objetos
implementados. Esto se llama la realización del guión de uso. A menudo, los
mismos objetos participan en realizaciones de más de un guión de uso. Por
ejemplo, ambos guiones de uso, Depósito y Retirada, de un sistema de banca
puede utilizar un objeto de cuenta concreto en su realización, lo que no significa
que los dos guiones de uso se comuniquen, sino que utilizan el mismo objeto en
su realización.
Un flujo de sucesos consta de varios subflujos que, unidos, producen el flujo
total de sucesos. Puede reutilizar la descripción de un subflujo en otros flujos de
sucesos de los guiones de uso. Los subflujos de la descripción del flujo de
sucesos del guión de uso pueden ser comunes a los de otros guiones de uso. En
el diseño, los mismos objetos deben ejecutar el comportamiento común para
todos los guiones de uso relevantes; es decir, sólo un conjunto de objetos debe
realizar este comportamiento, no importa el guión de uso que se ejecute.
Ejemplo:
En un sistema de cajeros automáticos, el subflujo inicial es el mismo que el flujo
de sucesos de los guiones de uso Retirar dinero y Comprobar saldo. El flujo de
sucesos de ambos guiones de uso empieza comprobando la identidad de la
tarjeta y el código de acceso personal de cliente.
Un guión de uso tiene varias instancias posibles
Una instancia de guión de uso puede seguir un número de vías de acceso casi
ilimitado, pero enumerable. Dichas vías de acceso representan opciones abiertas
para la instancia de guión de uso en la descripción de su flujo de sucesos. La vía
de acceso elegida depende de los sucesos. Los tipos de sucesos incluyen:
 Entrada de un actor. Por ejemplo, un actor puede decidir, entre varias
opciones, lo que desea hacer a continuación.
Ejemplo:
En el guión de uso Elementos de reciclaje del Sistema de máquinas de reciclaje,
el Cliente siempre tiene dos opciones: entregar otro elemento de depósito u
obtener el recibo de elementos devueltos.

 Una comprobación de valores o tipos de un atributo u objeto interno. Por

ejemplo, el flujo de sucesos puede ser distinto si un valor es mayor o menor
que un valor concreto.
Ejemplo:
En el guión de uso Retirar dinero de un sistema de cajeros automáticos, el flujo
de sucesos puede ser diferente si el Cliente solicita más dinero del que tiene en
la cuenta. Por lo tanto, la instancia de guión de uso permite vías de acceso
diferentes.
Concurrencia de instancias de guión de uso
Las instancias de varios guiones de uso y varias instancias del mismo guión de
uso funcionan simultáneamente si el sistema lo permite. En el modelado de
guiones de uso, puede suponer que instancias de guiones de uso pueden estar
activas de modo concurrente sin que existan conflictos. Se espera que el modelo
de diseño resuelva este problema, puesto que el modelado de guiones de uso no
describe cómo funcionan las cosas. Un modo de verlo es suponiendo que sólo
una instancia de guión de uso está activa a la vez, y que la ejecución de dicha
instancia es una acción global. En el modelado de guiones de uso, la "máquina
de interpretación" se considera infinitamente rápida, por lo que la serialización
de instancias de guiones de uso no supone ningún problema.
Nombre
Cada guión de uso debe tener un nombre que indique lo que se ha conseguido
por medio de su interacción con el actor. Es posible que el nombre deba constar
de varias palabras para que se comprenda. Dos guiones de uso no pueden tener
el mismo nombre.
Ejemplo:
A continuación, se incluyen ejemplos de variaciones del nombre para el guión de
uso Elementos de reciclaje del ejemplo Máquina de reciclaje:
 Recibir elementos de depósito
 Recibiendo elementos de depósito
 Devolver elementos de depósito
 Elementos de depósito
Descripción breve
La descripción breve del guión de uso debe reflejar su objetivo. Cuando escriba
la descripción, consulte a los actores implicados en el guión de uso, el glosario y,
si lo necesita, defina nuevos conceptos.
Ejemplo:

A continuación, se incluyen descripciones breves de los guiones de uso

Elementos de reciclaje y Añadir tipo de botella nuevo del Sistema de máquinas
de reciclaje:
Elementos de reciclaje: El usuario utiliza esta máquina para que se cuenten,
automáticamente, todos los elementos de devolución (botellas, latas y cajas), y
recibir un recibo. El recibo se debe hacer efectivo en una máquina registradora.
Añadir tipo de botella nuevo: Se pueden añadir nuevos tipos de botellas a la
máquina empezando en la "modalidad de aprendizaje" e insertando 5 muestras,
igual que al devolver elementos. De este modo, la máquina puede medir las
botellas y aprender a identificarlas. El gestor especifica el valor de reembolso
para el nuevo tipo de botella.
Flujo de sucesos - Contenido
El Flujo de sucesos de un guión de uso contiene la información más importante
derivada del trabajo de modelado del guión de uso. Debe describir el flujo de
sucesos del guión de uso de forma lo suficientemente clara como para que una
persona independiente lo comprenda con facilidad. Recuerde que el flujo de
sucesos debe presentar lo que hace el sistema, no cómo se ha diseñado el
sistema para ejecutar el comportamiento necesario.
Las directrices para el contenido del flujo de sucesos son las siguientes:
 Describa cómo se inicia y finaliza el guión de uso.
 Describa los datos que se intercambian entre el actor y el guión de uso.
 No describa los detalles de la interfaz de usuario, a menos que sea necesario
para comprender el comportamiento del sistema. Por ejemplo, suele ser
apropiado utilizar un conjunto limitado de terminología específica de la web
cuando se conoce de antemano que la aplicación se va a basar en web. Si no
es así, corre el riesgo de que el texto del guión de uso se perciba como
demasiado abstracto. En la terminología puede incluir, por ejemplo, las
palabras "navegar", "examinar", "hiperenlace" "página", "enviar" y
"navegador". Sin embargo, no se aconseja incluir referencias a "marcos" o
"páginas web" de modo que se establezcan supuestos sobre los límites entre
estas. Ésta es una decisión de diseño crítica.
 Describa el flujo de sucesos, no sólo la funcionalidad. Para reforzarlo,
empiece cada acción con "Cuando el actor ... ".
 Describa sólo los sucesos que pertenecen al guión de uso, y no lo que
sucede en otros guiones de uso o fuera del sistema.
 Evite terminología imprecisa.

 Detalle el flujo de sucesos. Se debe dar respuesta a todos los "qués".

Recuerde que los diseñadores de pruebas van a utilizar este texto para
identificar guiones de prueba.
Si ha utilizado términos concreto en otros guiones de uso, asegúrese de que
utiliza los mismos términos exactos en este guión de uso, y que su significado
quiere decir lo mismo. Para gestionar términos comunes, póngalos en un
glosario.
Flujo de sucesos - Estructura

Las dos partes principales del flujo de sucesos son flujo de sucesos
básico y flujo de sucesos alternativo. El flujo de sucesos básico debe abarcar
lo que ocurre "normalmente" cuando se ejecuta el guión de uso. Los flujos de
sucesos alternativos deben comprender el comportamiento de carácter opcional
o excepcional en relación con el comportamiento normal, y también las
variaciones del comportamiento normal. Puede considerar los flujos de sucesos
alternativos como "desvíos" del flujo de sucesos básico, algunos de los cuales
vuelven al flujo de sucesos básico y otros finalizan la ejecución del guión de uso.
La estructura típica del flujo de sucesos. La flecha recta representa el flujo básico
de sucesos y las curvas representan vías de acceso alternativas en relación con
lo normal. Algunas vías de acceso alternativas vuelven al flujo básico de sucesos,
mientras que otras finalizan el guión de uso.
Los flujos de sucesos básico y alternativo se deben estructurar más en pasos o
subflujos. Al hacerlo, el objetivo principal debe ser la legibilidad del texto
(consulte también el apartado Flujo de sucesos - Estilo, que se encuentra más
abajo). Como norma general, el subflujo debe ser un segmento de
comportamiento del guión de uso con un objetivo claro, y es global en el sentido
que se realizan o todas o ninguna de las acciones descritas. Es posible que
necesite varios niveles de subflujos, pero si puede lo debe evitar, puesto que el

texto resulta más complejo y difícil de comprender. Puede ilustrar la estructura

del flujo de sucesos con un diagrama de actividad. Consulte el apartado Directriz
de producto de trabajo: Diagrama de actividad en el guión de uso.
Este tipo de texto escrito y estructurado en subsecciones consecutivas, por su
naturaleza da a entender al lector que existe una secuencia entre los subflujos.
Para evitar malentendidos, siempre debe indicar si se ha fijado o no el orden de
los subflujos. Con frecuencia, las consideraciones de este tipo están relacionadas
con:
 Reglas empresariales. Por ejemplo, se debe haber autorizado al usuario para
que el sistema pueda hacer disponibles determinados datos.
 Diseño de la interfaz de usuario. Por ejemplo, el sistema no debe imponer
alguna secuencia de comportamiento que pueda resultar intuitiva para unos,
pero no para otros usuarios.
Para aclarar en qué lugar de la estructura se ajusta un flujo de sucesos
alternativo, debe describir lo siguiente para cada "desvío" del flujo de sucesos
básico:
 En qué lugar del flujo de sucesos básico se puede insertar el
comportamiento alternativo.
 La condición que se debe cumplir para que se inicie el comportamiento
alternativo.
 Cómo y dónde se reanuda el flujo de sucesos básico, o bien, cómo finaliza el
guión de uso.
Ejemplo:
Éste es un subflujo alternativo del guión de uso Devolver elementos del Sistema
de máquinas de reciclaje.
2.1. Atasco de botella
Si en el apartado 1.5, Insertar elementos de depósito, una botella se atasca en
la entrada, los sensores en torno a la entrada y la entrada de medición detectan
el problema. La cinta transportadora se detiene y la máquina emite una alarma
para llamar al operador. La máquina espera a que el operador indique que el
problema se ha resuelto. A continuación, la máquina continúa en la sección 1.9
del flujo básico.
En el ejemplo anterior, el flujo de sucesos alternativo se inserta en una ubicación
específica del flujo de sucesos básico. También hay flujos de sucesos alternativos
que se pueden insertar en más de una ubicación, algunos se pueden insertar
incluso en cualquier ubicación del flujo de sucesos básico.

Ejemplo:
Éste es un subflujo alternativo del guión de uso Devolver elementos del Sistema
de máquinas de reciclaje.
2.2. Desmontaje del panel frontal
Si alguien desmonta el panel frontal de la Máquina de reciclaje, la compresión de
latas se desactiva. Resulta imposible iniciar la compresión de latas con el panel
frontal extraído. La extracción también activa una alarma para el operador. Una
vez que se haya vuelto a cerrar el panel frontal, la máquina reinicia el
funcionamiento a partir de la ubicación del flujo de sucesos básico en el que se
había detenido.
Puede resultar tentador, si el flujo de sucesos alternativo es muy simple,
describirlo sólo en la sección del flujo de sucesos básico (utilizando alguna
construcción "si-entonces-lo otro" informal). Se debe evitar. Demasiadas
alternativas dificultan que se vea el comportamiento normal. Además, si se
incluyen vías de acceso alternativas en la sección del flujo de sucesos básico, el
texto es más "similar a un seudocódigo", por lo que resulta más complicado de
leer.
Por lo general, al extraer partes del flujo de sucesos y describir dichas partes por
separado, se puede mejorar la legibilidad del flujo de sucesos básico, así como la
estructura del guión de uso y del modelo de guión de uso. Puede modelar las
partes extraídas como:
 Un flujo de sucesos alternativo dentro del guión de uso de base si es una
variante, opción o excepción simple del flujo de sucesos básico.
 Como una inclusión explícita en el guión de uso de base (consulte el
apartado Directriz de producto de trabajo: Relación de inclusión), si desea
encapsularlo de modo que lo puedan reutilizar otros guiones de uso.
 Como una inclusión implícita en el guión de uso de base (consulte el
apartado Directriz de producto de trabajo: Relación ampliada), si el flujo de
sucesos básico está completo, es decir, tienen un principio y un final
definidos. La naturaleza del flujo de ampliación debe ser tal que se prefiera
ocultarlo en la descripción del guión de uso de base para convertirlo en
menos complejo.
 Un subflujo del flujo de sucesos básico, posiblemente como otra opción, si
no se aplica ninguna de las alternativas anteriores. Por ejemplo, en un guión
de uso Mantener información de los empleados, puede haber subflujos
separados para añadir, suprimir y modificar información de los empleados.

Flujo de sucesos - Estilo

Puede describir guiones de uso en varios estilos. Como ejemplo, se muestra el
flujo de sucesos básico del guión de uso Administrar orden descrito en tres
estilos diferentes, cuya principal variación es su formalidad. Se recomienda el
primer estilo, que se muestra más abajo, en el ejemplo 1, puesto que es fácil de
comprender y el orden en el que suceden las cosas es claramente evidente. El
texto se divide en subsecciones numeradas y denominadas. Se incluyen números
con el objeto de poder hacer referencia fácilmente a una subsección. Los
nombres de las subsecciones permiten que el lector disponga de una visión
general rápida del flujo de sucesos examinando el texto y leyendo sólo las
cabeceras.
Más abajo, en el ejemplo 2, la descripción del flujo de sucesos no aclara el orden
en el que suceden las cosas. Si escribe en este estilo, es posible que usted y los
demás pasen por alto cosas importantes que atañan al sistema.
En el Ejemplo 3 se muestra aún otro estilo, que puede resultar útil en caso de
que sea difícil expresar la secuencia de sucesos con claridad. Este seudoestilo es
más preciso, pero el texto resulta pesado de leer para una persona que no sea
técnica, especialmente, si se desea comprender el flujo de sucesos con rapidez.
Ejemplo 1:
1.1. Inicio del guión de uso

Este guión de uso se inicia cuando el actor Operador le indica al
sistema que cree una orden de medida. A continuación, el sistema
recupera todos los actores Elemento de red, sus objetos de medida
y las funciones de medida correspondientes que están disponibles
para este Operador concreto. Los Elementos de red disponibles son
aquellos que están en funcionamiento y para los que el Operador
tiene autorización de acceso. La disponibilidad de las funciones de
medida depende de lo que se haya establecido para un tipo
determinado de objeto de medida.
1.2. Configurar orden de medida
El sistema permite que el actor Operador seleccione los Elementos
de red que medir y, a continuación, muestra los objetos de medida
que están disponibles para los Elementos de red seleccionados. El
sistema permite que el Operador seleccione entre los objetos de
medida, y que después seleccione las funciones de medida que
establecer para cada objeto de medida.

El sistema permite que el Operador entre un comentario textual en

la orden de medida.
El Operador le indica al sistema que complete la orden de medida.
El sistema responde generando un nombre exclusivo para la orden
de medida y estableciendo valores por omisión para cuándo, con
qué frecuencia y durante cuánto tiempo se debe realizar la medida.
Los valores por omisión son exclusivos de cada Operador. A
continuación, el sistema permite que el Operador edite los valores
por omisión.
1.3. Inicializar orden
El Operador le indica al sistema que inicialice la orden de medida.
El sistema registra la identidad del Operador que la ha creado, la
fecha de creación y el estado "Planificada" de la orden de medida.
1.4. Finalización del guión de uso
El sistema confirma la inicialización de la orden de medida al
Operador, y la orden de medida se pone a disposición de otros
actores para su visualización.
Descripción del guión de uso: En este estilo, el texto resulta fácil de leer y el
flujo de sucesos es fácil de seguir. Propóngase este estilo en sus descripciones.
Ejemplo 2:
Los ordenantes pueden crear Órdenes para recopilar datos de

medida de los Elementos de red.
El sistema asigna a la Orden un nombre exclusivo, así como
valores por omisión que indiquen la longitud y el tiempo de la
medida, además de la frecuencia con la que se deben repetir. El
Ordenante puede editar dichos valores.
El Ordenante debe especificar también las funciones de medida, los
elementos de red y los objetos de medida que se aplican. El
Ordenante puede añadir, además, un comentario personal a la
orden.
Una vez que se ha definido la información necesaria, se crea e
inicializa una nueva Orden con los atributos definidos, el nombre
del creador y la fecha de creación. El estado de la orden se
establece en "planificada". (Los valores posibles para el estado
son: Planificada, Ejecutándose, Completada, Cancelada y Con

error).
A continuación, se notifica a la interfaz de usuario que se ha
creado una nueva Orden y recibe una referencia a la nueva orden a
fin de que se pueda visualizar.
Descripción de un guión de uso: Este estilo es legible, pero el flujo de sucesos no

se presenta de forma clara.
Ejemplo 3:
'Administrar orden' (Identidad de usuario)

REPEAT
<= 'Show administer order menu'
IF ( => 'Creación de una orden' (Función de
medida,
elemento de red, objeto de medida)) THEN
El sistema encuentra un nombre exclusivo,
valores por omisión
para cuándo y cuánto tiempo se debe ejecutar la
medida.
<= 'Show order' (Default attributes)
REPEAT
=> 'Editar orden' (Atributo a cambiar, Nuevo
valor de atributo)
<= 'Update screen' (New attributes)
UNTIL (All attributes are defined)
REPEAT
IF ( => 'Editar orden' (Atributo a cambiar,
Nuevo valor de atributo)
THEN <= 'Update screen' (New attributes)
ELSIF ( => 'Guardar orden' (Identidad de orden,
atributos)) THEN
La orden se crea e inicializa en el sistema con
los atributos definidos, el nombre del creador,
la fecha de creación y el estado 'planificada'.
<= 'New order created' (The order)
ENDIF

UNTIL (=> 'Abandonar')

ENDIF
UNTIL 'Abandonar administrar orden'
Descripción de un guión de uso: Aquí, el escritor ha elegido un estilo formal

utilizando seudocódigo. Este estilo dificulta la comprensión rápida de los pasos
del proceso, pero puede resultar útil si el flujo de sucesos es difícil de capturar
con precisión.
Flujo de sucesos - Ejemplo
La descripción completa del flujo de sucesos del guión de uso Administrar orden,
incluidos sus flujos alternativos, podría tener un aspecto similar al siguiente:
1. Flujo de sucesos básico
1.1. Inicio del guión de uso
Este guión de uso se inicia cuando el actor Operador le indica al sistema que
cree una orden de medida. A continuación, el sistema recupera todos los actores
Elemento de red, sus objetos de medida y las funciones de medida
correspondientes que están disponibles para este Operador concreto. Los
Elementos de red disponibles son aquellos que están en funcionamiento y para
los que el Operador tiene autorización de acceso. La disponibilidad de las
funciones de medida depende de lo que se haya establecido para un tipo
determinado de objeto de medida.
1.2. Configurar orden de medida
El sistema permite que el actor Operador seleccione los Elementos de red que
medir y, a continuación, muestra los objetos de medida que están disponibles
para los Elementos de red seleccionados. El sistema permite que el Operador
seleccione entre los objetos de medida, y que después seleccione las funciones
de medida que establecer para cada objeto de medida.
El sistema permite que el Operador entre un comentario textual en la orden de
medida.
El Operador le indica al sistema que complete la orden de medida. El sistema
responde generando un nombre exclusivo para la orden de medida y
estableciendo valores por omisión para cuándo, con qué frecuencia y durante
cuánto tiempo se debe realizar la medida. Los valores por omisión son exclusivos
de cada Operador. A continuación, el sistema permite que el Operador edite los
valores por omisión.

1.3. Inicializar orden

El Operador le indica al sistema que inicialice la orden de medida. El sistema
registra la identidad del Operador que la ha creado, la fecha de creación y el
estado "Planificada" de la orden de medida.
1.4. Finalización del guión de uso
El sistema confirma la inicialización de la orden de medida al Operador, y la
orden de medida se pone a disposición de otros actores para su visualización.
2. Flujos de sucesos alternativos
2.1. No hay elementos de red disponibles
Si en el punto 1.1, Inicio del guión de uso, resulta que no hay Elementos de red
disponibles que medir para este Operador, el sistema informa al Operador y, a
continuación, finaliza el guión de uso.
2.2. No hay funciones de medida disponibles
Si en el punto 1.2, Configurar orden de medida, no hay funciones de medida
disponibles para los elementos de red seleccionados, el sistema informa al
operador y permite que el operador seleccione otros elementos de red.
2.3. Cancelar orden de medida
El sistema permite que el Operador cancela todas las acciones en cualquier
punto durante la ejecución del guión de uso, a continuación, vuelve al estado en
el que se encontraba antes del inicio del guión de uso y finaliza el guión de uso.
Requisitos especiales
En los Requisitos especiales de un guión de uso, puede describir todos los
requisitos del guión de uso que no tratan los flujos de sucesos. Hay requisitos no
funcionales que influyen en el modelo de diseño. Consulte también la discusión
sobre requisitos no funcionales en el apartado Directriz de producto de trabajo:
Modelo de guión de uso. Si lo desea, puede organizar estos requisitos por
categorías como, por ejemplo, Utilización, Fiabilidad, Rendimiento y Condición de
sustitución pero, por lo general, hay tan pocos que este tipo de agrupación no
añade especialmente valor.
Ejemplo:
En el Sistema de máquinas de reciclaje, un requisito especial del guión de uso
Devolver elementos de depósito podría ser:
La máquina debe poder reconocer elementos de depósito con una fiabilidad de
más del 95 por ciento.
Condiciones previas y posteriores

Puede resultar útil usar las nociones de condición previa y condición

posterior para aclarar cómo se inicia y finaliza el flujo de sucesos. Sin embargo,
sólo las debe utilizar si se consideran como un valor añadido por parte de los
receptores del guión de uso.
Una condición previa es el estado del sistema y su entorno necesario para que se
pueda iniciar el guión de uso. Una condición posterior son los estados en los que
se puede encontrar el sistema una vez que ha finalizado el guión de uso.
Considere lo siguiente:
 Los estados que describen las condiciones previas y posteriores deben ser
estados que pueda observar el usuario. "El usuario ha iniciado la sesión en el
sistema", o bien, "El usuario ha abierto el documento" son ejemplos de
estados observables.
 Una condición previa es una restricción sobre el momento en el que se
iniciar un guión de uso. No es el suceso que inicia el guión de uso.
 Una condición previa para un guión de uso no es una condición previa sólo
para un subflujo, aunque se pueden definir condiciones previas y posteriores
a nivel del subflujo.
 Una condición posterior para un guión de uso debe ser verdadera,
independientemente de los flujos alternativos que se ejecuten: no debe ser
verdadera sólo para el flujo principal. Si algo diera error, se podría tratar en
la condición posterior indicando "La acción se ha completado, o bien, si algo
da error, la acción no se ha llevado a cabo", en lugar de indicar,
simplemente, "La acción se ha completado".

 Cuando utiliza condiciones posteriores junto con relaciones de ampliación,

debe prestar atención para que el guión de uso de ampliación no incluya un
subflujo que infrinja la condición posterior del guión de uso de base.
 Las condiciones posteriores pueden ser una herramienta eficaz para describir
guiones de uso. En primer lugar, debe definir lo que se supone que debe
conseguir el guión de uso - la condición posterior. A continuación, debe
describir cómo alcanzar dicha condición - el flujo de sucesos necesario.
Ejemplo:
Una condición previa para el guión de uso Retirada de dinero en el cajero
automático: El cliente dispone de una tarjeta emitida con carácter personal que
encaja en el lector de tarjetas, tiene un número de PIN emitido y está registrada
en el sistema de banca.
Una condición posterior para el guión de uso Retirada de dinero en el cajero
automático: Al final del guión de uso, se cuadran todos los registros de cuenta y
transacción, se reinicializa la comunicación con el sistema de banca y se
devuelve la tarjeta el cliente.
Puntos de ampliación
Un punto de ampliación ofrece la posibilidad de que el guión de uso disponga
de una ampliación. Tiene un nombre y una lista de referencias a una o más
ubicaciones del flujo de sucesos del guión de uso. Un punto de ampliación puede
hacer referencia a una sola ubicación entre dos pasos de comportamiento del
guión de uso. Puede, incluso, hacer referencia a un conjunto de ubicaciones
separadas.
Para utilizar puntos de ampliación denominados, le puede ayudar separar la
especificación del comportamiento del guión de uso de ampliación de los detalles
internos del guión de uso de base. El guión de uso de base se puede modificar o
reorganizar, siempre que los nombres de los puntos de ampliación sigan siendo
los mismos no afecta al guión de uso de ampliación. Al mismo tiempo, no cargue
el texto de describe el flujo de suceso del guión de uso de base con detalles
sobre dónde se puede ampliar el comportamiento. Consulte también el
apartado Directriz de producto de trabajo: Relación ampliada.
Ejemplo:
En un sistema telefónico, el guión de uso Mostrar identidad del llamador puede
ampliar el guión de uso Establecer llamada. Es un servicio opcional al que, con
frecuencia, se hace referencia como "ID de llamador", que puede haber

solicitado, o no, el receptor. Una descripción del punto de ampliación del guión
de uso Establecer llamada podría ser similar a la siguiente:
Nombre: Mostrar identidad
Ubicación: Después de la sección 1.9 Llamada al teléfono de la parte receptora.
Diagramas de guión de uso
Si lo desea, puede elegir un diagrama de guión de uso para ilustrar cómo se
relaciona un guión de uso con actores y otros guiones de uso (en casos
extraordinarios, más de un diagrama), propiedad del guión de uso. Resulta útil si
el guión de uso está relacionado con varios actores o tiene relaciones con otros
guiones de uso. Un diagrama de este tipo tiene carácter "local", puesto que
muestra el modelo de guión de uso desde la perspectiva de un solo guión de
uso, y su finalidad no es explicar ningún hecho general sobre el modelo de guión
de uso completo. Consulte también el apartado Directriz de producto de trabajo:
Diagrama de guión de uso.
Directriz: Diagrama de guión de uso
Los diagramas con actores, guiones de uso y relaciones entre ellos se denominan diagramas de
directriz se identifica donde utilizarlas.
Explicación
Los diagramas con actores, guiones de uso y relaciones entre ellos se
denominan diagramas de guión de uso e ilustran las relaciones en el modelo de
guión de uso.
Los diagramas de guión de uso se pueden organizar en (y ser propiedad de)
paquetes de guiones de uso, mostrando sólo lo que es relevante en un paquete
concreto.
Utilización
No existen reglas estrictas sobre qué ilustrar en los diagramas de guión de uso.
Muestre las relaciones que considere interesantes en el modelo. Los diagramas
siguientes pueden resultar interesantes:
 Actores que pertenecen al mismo paquete de guiones de uso.

 Un actor y todos los guiones de uso con los que interactúa. Un diagrama de
este tipo puede funcionar como diagrama local del actor, y es posible que
esté relacionado con este.
 Los guiones de uso que manejan la misma información.
 Los guiones de uso utilizados por el mismo grupo de actores.
 Los guiones de uso que se ejecutan a menudo en una secuencia.
 Los guiones de uso que pertenecen al mismo paquete de guiones de uso.
 Los guiones de uso más importantes. Un diagrama de este tipo puede
funcionar como resumen del modelo, y es posible que se incluya en la vista
de guión de uso.
 Los guiones de uso desarrollados juntos (dentro del mismo incremento).
 Un guión de uso específico y sus relaciones con actores y otros guiones de
uso. Un diagrama de este tipo puede funcionar como diagrama local del
guión de uso, y es posible que esté relacionado con este.
Se recomienda incluir todos los actores, guiones de uso y relaciones en, como
mínimo, uno de los diagramas. Si aclara el modelo de guión de uso, pueden
formar parte de varios diagramas y puede mostrarlos varias veces en el mismo
diagrama.
Directriz: Asociación-comunicar
Una asociación-comunicar modela como los guiones de uso y los actores
interactúan enviando señales entre si. En esta directriz se explica cómo
utilizar esta relación.
Explicación
Los guiones de uso y los actores interactúan enviando señales entre si. Para
indicar estas interacciones, utilizamos una asociación-comunicar entre
guión de uso y actor. Un guión de uso tiene, como máximo, una asociación-
comunicar con un actor específico, y un actor tiene, como máximo, una
asociación-comunicar con un guión de uso específico, sin importar cuantas
transmisiones de señal existen. La red completa de estas asociaciones es una
imagen estática de la comunicación entre el sistema y su entorno.
Las asociaciones-comunicar no son nombres. Como sólo puede existir una
asociación-comunicar entre un guión de uso y un actor, sólo debe especificar
los puntos de inicio y final para identificar una asociación-comunicar concreta.

Una línea o flecha entre un actor y un guión de uso indica que interactúan
enviando señales entre si.
Roles
Cada extremo de una asociación-comunicar es un rol que especifica la cara
que juega un guión de uso o un actor en la asociación. Los roles se utilizan
para especificar multiplicidades y direcciones de la asociación (vea a
continuación).
Multiplicidad
Cada rol de una asociación-comunicar indica la multiplicidad de su tipo, es
decir, cuántas instancias de ese actor o guión de uso se puede asociar con
una instancia del otro guión de uso o actor. La multiplicidad se indica con una
expresión de texto en el rol. La expresión es una lista de rangos enteros
separados por comas. Un rango se indica con un entero (el valor más bajo),
dos puntos y un entero (el valor más alto); un único entero es un rango
válido, y el símbolo '*' indica "muchos", es decir, un número de objetos
ilimitado. El símbolo '*' por si mismo equivale a '0..*', es decir, cualquier
número que incluya ninguno; el valor por omisión. Un rol escalar opcional
tiene la multiplicidad 0..1.
La multiplicidad se puede aumentar con una restricción de unidad de tiempo.
Esto se efectúa para indicar cuántas instancias se pueden asociar,
posiblemente por diferentes instancias, durante la unidad de tiempo. Esta
información resulta útil porque indica si el guión de uso se realiza a menudo,
y con qué frecuencia cada instancia de actor emplea el guión de uso.
Ejemplo:
Los clientes utilizan el guión de uso Efectuar transacciones 400.000 vueltas

diarias. Cada cliente emplea el guión de uso dos veces al mes.

Navegabilidad
Cada rol de una asociación-comunicar tiene una propiedad navegabilidad,
que indica quien inicia la comunicación en la interacción. La navegabilidad se
muestra con una punta de flecha abierta. Si la punta de flecha apunta a un
guión de uso, el actor del otro extremo de la asociación inicia la interacción
con el sistema. Si la punta de flecha apunta a un actor, el sistema inicia la
interacción con el actor. La navegabilidad en dos direcciones se muestra con
una línea sin puntas de flecha (dos puntas de flecha tienden a desordenar los
diagramas).
La flecha de comunicación define el actor que ha iniciado el guión de uso. Para

cada flecha de comunicación, se asume el mensaje de retorno. Una línea sin
cabezas de flecha asume la comunicación en las dos direcciones.
No confunda la navegabilidad con el flujo de datos; se utiliza para mostrar
únicamente la iniciación de la comunicación. Por ejemplo, la solicitud de
datos de un cliente se muestra con una flecha para el guión de uso que
representa el sistema, aunque la mayoría de datos fluyan desde el sistema
hacia el cliente.
Comunicación del actor al guión de uso

Los actores comunican con el sistema enviando señales. Para comprender
totalmente el rol del actor, debe conocer en qué guiones de uso está
implicado el actor. Esto se muestra en las asociaciones-comunicar entre el
actor y los guiones de uso.
La multiplicidad de la asociación muestra con cuantas instancias de un guión
de uso puede comunicar una instancia de un actor al mismo tiempo.
Ejemplo:
En el sistema de la máquina de reciclaje, cada vez que una instancia del actor
cliente entrega un elemento de depósito, envía una señal a la instancia

asociada del guión de uso Elementos de reciclaje. Cuando el actor ha

finalizado, el guión de uso imprime un recibo. Un cliente puede comunicar con
una sola instancia de Elementos de reciclaje. Por lo tanto, la multiplicidad de
la asociación es 1. El recibo devuelto desde el sistema se considera como una
respuesta de la instancia de guión de uso; como consecuencia, la asociación-
comunicar no necesita navegabilidad en la otra dirección.
Un cliente que desea devolver los elementos de depósito a una máquina de

reciclaje comunicará con el guión de uso Elementos de reciclaje.
Un actor comunica con los guiones de uso por varios motivos, que incluyen:
 Para invocar un guión de uso. La instancia de un actor siempre invoca una
instancia de guión de uso.
 Para solicitar algunos datos almacenados en el sistema, que el guión de uso
busca y presenta al actor.
 Para cambiar los datos almacenados en el sistema mediante un diálogo con
el sistema.
 Para informar de que ha sucedido algo especial en el entorno del sistema
que el sistema debe tener en cuenta.
Comunicación de guión de uso a actor
Un actor inicia un guión de uso. Sin embargo, una vez iniciado, el guión de
uso puede comunicar con varios actores. Puede utilizar asociaciones-
comunicar entre el guión de uso y los actores para mostrar con qué actores se
comunica el guión de uso. La multiplicidad de la asociación muestra con
cuantas instancias de un actor puede comunicar una instancia de un guión de
uso al mismo tiempo.
Los guiones de uso comunican con los actores por varios motivos, que
incluyen:
 Si ha ocurrido algo especial en el sistema, es posible que un actor necesite
saberlo.
 Un guión de uso puede necesitar la ayuda de un actor para tomar una
decisión si están disponibles varias opciones.
Es común, pero no siempre cierto, que el guión de uso espera una respuesta
cuando ha enviado una señal a un actor. Esto debe describirse de forma
explícita en el guión de uso.

Convenios opcionales
Los siguientes son convenios opcionales que aclaran qué actor inicia el guión
de uso.
 La punta de flecha que inicia el actor-a-guión-de-uso siempre se muestra,
incluso si el guión de uso posterior inicia la comunicación con el actor que lo
inicia. También es la única punta de flecha actor-a-guión-de-uso que se
muestra.
 Las puntas de flecha del guión de uso a los actores se pueden omitir, o
pueden incluirse como aclaración.
Directriz: Generalización de actor
Varios actores pueden realizar el mismo rol en un guión de uso concreto. En

esta directriz se muestra cómo modelar esta situación a través de las
relaciones generalizadas.
Explicación
Varios actores pueden realizar el mismo rol en un guión de uso concreto. Así,
un Cajero y un Contable, que comprueban el balance de una cuenta, se
consideran como la misma entidad externa del guión de uso que realiza la
comprobación. El rol compartido está modelado como actor, Supervisor de
balances, heredado de dos actores originales. Esta relación se muestra con las
generalizaciones de actor.
Los actores Cajero y Contable heredan todas las propiedades del Supervisor de
balances. Por lo tanto, estos actores pueden actuar como Supervisores de
balances.
Utilización
Un usuario puede desempeñar diferentes roles respecto al sistema, lo que
significa que el usuario puede, en realidad, corresponder a varios actores. Para
aclarar el modelo, puede representar al usuario como un actor que hereda
varios actores. Cada actor heredado representa uno de los roles del usuario
relativo al sistema.

Directriz: Generalización de guión de

uso
La generalización se utiliza cuando se encuentran dos o más guiones de uso

que tienen puntos comunes en el comportamiento, la estructura y el objetivo.
Esta directriz demuestra cómo utilizar esta relación.
Explicación
Un guión de uso padre se puede especializar en uno o más guiones de uso hijos
que representen formatos del padre más específicos. Ni el padre ni el hijo
tienen que ser, necesariamente, abstractos, aunque en la mayoría de casos el
padre es abstracto. Un hijo hereda toda la estructura, el comportamiento y las
relaciones del padre. Todos los hijos del mismo padre son especializaciones del
padre. Se trata de una generalización que se puede aplicar a los guiones de uso
(para obtener más información sobre el concepto de generalización tal como se
aplica a las clases, consulte el apartado Directriz: Generalización).
La generalización se utiliza cuando se encuentran dos o más guiones de uso
que tienen puntos comunes en el comportamiento, la estructura y el objetivo.
Cuando sucede, puede describir las partes compartidas en un nuevo guión de
uso, con frecuencia abstracto que, a continuación, se especializa por medio de
guiones de uso hijos.
Ejemplo:

Los guiones de uso Pedido por teléfono y Pedido por Internet son
especializaciones del guión de uso abstracto Hacer pedido.
En un sistema de Gestión de pedidos, los guiones de uso Pedido por teléfono y
Pedido por Internet comparten mucho en cuanto a estructura y
comportamiento. Un guión de uso general Hacer pedido se define en que se ha
definido la estructura y el comportamiento común. El guión de uso abstracto
Hacer pedido no tiene que completarse por sí mismo, pero proporciona una
infraestructura de comportamiento general que pueden completar los guiones
de uso hijos.
El guión de uso padre no siempre es abstracto.
Ejemplo:
Considere el sistema Gestión de pedidos del ejemplo anterior. Se puede añadir
un actor Encargado del registro de pedidos, que pueda entrar pedidos en el
sistema en nombre de un cliente. Este actor inicia el guión de uso Hacer pedido
general, que ahora debe tener un flujo de sucesos completo descrito. El guión
de uso hijo puede añadir comportamiento a la estructura que proporciona el
guión de uso padre, y también puede modificar comportamiento del padre.
El actor Encargado del registro de pedidos puede crear instancias el guión de

uso general Hacer pedido. Hacer pedido también se puede especializar por
medio de los guiones de uso Pedido por teléfono o Pedido por Internet.
El guión de uso hijo depende de la estructura (consulte el apartado Directriz:
Guión de uso, donde se trata la estructura del flujo de sucesos) del guión de
uso padre. El guión de uso hijo puede añadir comportamiento adicional al padre

por medio de la inserción de segmentos de comportamiento en el

comportamiento heredado, o bien, declarando relaciones de inclusión y
ampliación en el guión de uso hijo. El hijo puede modificar segmentos de
comportamiento heredados del padre , aunque se debe hacer con cuidado con
el objeto de mantener la intención del padre. El hijo mantiene la estructura del
guión de uso padre, lo que significa que todos los segmentos de
comportamiento, descritos en pasos o subflujos del flujo de sucesos del padre,
debe seguir existiendo, pero el hijo puede modificar contenido de dichos
segmentos de comportamiento.
Si el padre es un guión de uso abstracto, puede tener segmentos de
comportamiento incompletos. El hijo debe completarlos y convertirlos en
significativos para el actor.
Un guión de uso padre no necesita tener una relación a otro actor si es un
guión de uso abstracto.
Si dos guiones de uso hijos se especializan el mismo padre (o base), las
especializaciones son independientes entre sí, por lo que se pueden ejecutar en
instancia de guión de uso separadas. Se diferencia de las relaciones de
ampliación e inclusión, donde implícita o explícitamente varias adiciones
modifican una instancia de guión de uso ejecutando el mismo guión de uso de
base.
Tanto la inclusión como la generalización de guiones de uso se pueden utilizar
para reutilizar comportamiento entre guiones de uso en el modelo. La
diferencia es que con la generalización de guiones de uso, la ejecución de los
hijos depende de la estructura y el comportamiento del padre (la parte
reutilizada), mientras que en una relación de inclusión, la ejecución del guión
de uso de base sólo depende del resultado de la función que lleva a cabo el
guión de uso de inclusión (la parte reutilizada). Otra diferencia es que en una
generalización, los hijos comparten similitudes en cuanto al objetivo y la
estructura, mientras que en la relación de inclusión, los guiones de uso de base
que reutilizan la misma inclusión pueden tener objetivos totalmente diferentes,
pero necesitan que se lleve a cabo la misma función.
Ejecución de la generalización de guiones de uso
Una instancia de guión de uso que ejecute un guión de uso hijo sigue el flujo de
sucesos descritos para el guión de uso padre, insertando comportamiento
adicional y modificando comportamiento según se ha definido en el flujo de
sucesos del guión de uso hijo.

La instancia de guión de uso sigue al guión de uso padre, con comportamiento

insertado o modificado según se ha descrito en el guión de uso hijo.
Descripción de la generación de guiones de uso
Por lo general, no se describe la relación de generalización en sí misma. En vez
de ello, en el flujo de sucesos del guión de uso hijo se especifica cómo se
deben insertar los nuevos pasos en el comportamiento heredado, y cómo se
debe modificar el comportamiento heredado.
Si el hijo especializa más de un padre (herencia múltiple), en la especificación
del hijo debe establecer, explícitamente, cómo se deben intercalar las
secuencias de comportamiento de los padres en el hijo.
Ejemplo de uso
Considere los esquemas paso a paso siguientes de los guiones de uso para un
sistema telefónico simple:
Hacer llamada local
1. El llamador levanta el receptor.
2. El sistema presenta tono de marcado.
3. El llamador marca un dígito.
4. El sistema desactiva el tono de marcado.
5. El llamador marca el resto del número.
6. El sistema analiza el número.
7. El sistema busca la parte correspondiente.
8. El sistema conecta las partes.
9. Las partes se desconectan.
Hacer llamada internacional


6. El sistema analiza el número.
7. El sistema envía el número al otro sistema.
8. El sistema conecta las líneas.
9. Las partes se desconectan.
El texto en azul es muy similar en ambos guiones de uso. Si los dos guiones de
uso son tan parecidos, se debe considerar la posibilidad de fusionarlos en uno,
en el que subflujos alternativos muestren las diferencias entre las llamadas
locales e internacionales.
Sin embargo, si la diferencia entre ellos tiene cierta trascendencia, y muestra
claramente en el modelo de guión de uso la relación entre la llamada local e
internacional, se puede extraer comportamiento común en un guión de uso
nuevo y más general, denominado Hacer llamada.
En un diagrama de guión de uso, la relación de generalización creada se podría
mostrar del modo siguiente:
Los guiones de uso Hacer llamada local y Hacer llamada internacional heredan
del guión de uso abstracto Hacer llamada.
Directriz: Relación de inclusión

La relación de inclusión conecta un guión de uso de base a un guión de uso de
inclusión. Esta directriz demuestra cómo utilizar esta relación.
Explicación
La relación de inclusión conecta un guión de uso de base a un guión de uso de
inclusión. El guión de uso de inclusión siempre es abstracto. Describe un
segmento del comportamiento que se inserta en una instancia de guión de uso
que ejecuta el guión de uso de base. El guión de uso de base tiene control de la

relación para la inclusión y puede depender del resultado de que se lleve a cabo
la inclusión, pero ni la base ni la inclusión pueden acceder a los atributos entre
sí. En este sentido, la inclusión está encapsulada y representa el
comportamiento que se puede reutilizar en guiones de uso de base diferentes.
La relación de inclusión se puede utilizar para lo siguiente:
 Descomponer en factores el comportamiento del guión de uso de base que
no sea necesario para la comprensión del objetivo principal del guión de uso,
lo único importante es el resultado.
 Descomponer en factores el comportamiento que sea común a dos o más
guiones de uso.
Ejemplo:
En un sistema de cajero automático, los guiones de uso Retirar dinero, Ingresar
dinero en efectivo y Transferir fondos necesitan incluir cómo se identifica el
cliente en el sistema. Este comportamiento se puede extraer en un nuevo guión
de uso de inclusión llamado Identificar cliente, que incluyen los tres guiones de
uso de base. Los guiones de uso de base son independientes del método que se
utiliza para la identificación y, por este motivo, se encapsula en el guión de uso
de inclusión. Desde la perspectiva de los guiones de uso de base, no importa si
el método para la identificación va a leer una tarjeta bancaria magnética, o
bien, si va a realizar un reconocimiento de retina. Sólo dependen del resultado
de Identificar cliente, que es la identidad del cliente. Y viceversa, desde la
perspectiva del guión de uso Identificar cliente, no importa cómo utiliza el
guión de uso de base la identidad del cliente ni lo que sucede en el mismo
antes de ejecutar la inclusión; el método para la identificación sigue siendo
exactamente el mismo.
En el sistema de cajero automático, los guiones de uso Retirar dinero, Ingresar

dinero en efectivo y Transferir fondos incluyen el guión de uso Identificar
cliente.
Un guión de uso de base puede tener varias inclusiones. Un guión de uso de
inclusión se puede incluir en varios guiones de uso de base, lo que no indica

ninguna relación entre los guiones de uso de base. Pueden incluso existir varias
relaciones de inclusión entre el mismo guión de uso de inclusión y el guión de
uso de base, siempre que la inclusión se haya insertado en ubicaciones
diferentes del guión de uso de base. La relación de inclusión define la
ubicación. Se pueden anidar todas las adiciones, lo que significa que un guión
de uso de inclusión puede servir como guión de uso de base para otra
inclusión.
Puesto que los guiones de uso de inclusión son abstractos, no necesitan un
actor asociado. Sólo se necesita una asociación de comunicación con un actor si
el comportamiento en la inclusión implica, explícitamente, la interacción con un
actor.
Ejecución de la inclusión
El comportamiento de la inclusión se inserta en una ubicación del guión de uso
de base. Cuando una instancia de guión de uso que sigue la descripción de un
guión de uso de base llega a una ubicación del guión de uso de base del que se
ha definido la relación de inclusión, sigue la descripción del guión de uso de
inclusión. Una vez llevada a cabo la inclusión, la instancia de guión de uso se
reanuda a partir del punto en el que dejó el guión de uso de base.
Una instancia de guión de uso que sigue la descripción de un guión de uso de

base, incluida su inclusión.
La relación de inclusión no es condicional: si la instancia de guión de uso llega a
la ubicación del guión de uso de base para la que se ha definido, siempre se
ejecuta. Si desea expresar una condición, debe hacerlo como parte del guión
de uso de base. Si la instancia de guión de uso no llega nunca a la ubicación
para la que se ha definido la relación de inclusión, no se ejecuta.

La instancia de guión de uso Nº 1 llega a la ubicación del guión de uso de base

para la que se ha definido la relación de inclusión, y la inclusión se lleva a cabo.
La instancia de guión de uso Nº 2 no llega a dicha ubicación y, por
consiguiente, no se realiza la inclusión como parte de dicha instancia.
El guión de uso de inclusión es un segmento continuo de comportamiento, del
cual se incluye todo en una ubicación del guión de uso de base. Si tiene
segmento separados de comportamiento que se deben insertar en ubicaciones
diferentes, debe tener en cuenta la relación de ampliación (consulte el
apartado Producto de trabajo: Relación de ampliación), o bien, el
apartado Directriz de producto de trabajo: Generalización de guión de uso).
Descripción de la relación de inclusión
Para la relación de inclusión, debe definir la ubicación de la secuencia de
comportamiento del guión de uso de base en el que se va a insertar la
inclusión. La ubicación se puede definir haciendo referencia a un subflujo o
paso concreto del flujo de sucesos del guión de uso de base.
Ejemplo:
En el sistema de cajero automático, el guión de uso Retirar dinero incluye el
guión de uso Identificar cliente. La relación de inclusión de Retirar dinero a
Identificar cliente se puede describir tal como se indica a continuación:
Insertar Identificar cliente entre las secciones 1.1 Iniciar el guión de uso y 1.2
Solicitar importe del flujo de sucesos de Retirar dinero.
Con el objeto de ofrecer mayor claridad, también debe mencionar la inclusión
en el texto que describe el flujo de sucesos del guión de uso de base.
Ejemplo de uso
Si en un guión de uso existe un segmento del comportamiento en el que se
observe que el guión de uso no depende del modo en el que se llevan a cabo
las cosas, pero depende del resultado de la función, puede simplificar el guión

de uso extrayendo su comportamiento a un guión de uso de inclusión. El guión

de uso de inclusión se puede incluir en varios guiones de uso de base, lo que
significa que le permite reutilizar el comportamiento entre guiones de uso del
modelo. Considere los esquemas paso a paso siguientes de los guiones de uso
para un sistema telefónico simple:
Establecer llamada
2. El sistema presenta un tono de marcado.
6. El sistema analiza los dígitos y determina la dirección de red del receptor.
7. El sistema determina si se puede establecer un circuito virtual entre el
llamador y el receptor.
8. El sistema asigna todos los recursos al circuito virtual y establece la
conexión.
9. El sistema suena en el teléfono del receptor.
10. Y así sucesivamente.
Iniciar sistema
1. El operador activa el sistema.
2. El sistema realiza pruebas de diagnósticos en todos los componentes.
3. El sistema prueba las conexiones de todos los sistemas adyacentes. Para
cada sistema adyacente, el Sistema determina si se puede establecer un
circuito virtual entre sí mismo y el sistema adyacente. El Sistema asigna
todos los recursos al circuito virtual y establece la conexión.
4. El sistema responde que está preparado para la operación.
El texto listado en azul es muy similar; en ambos casos se lleva a cabo el
mismo comportamiento, aunque por motivos muy diferentes. Se puede
aprovechar la similitud, y extraer el comportamiento común a un nuevo guión
de uso, Gestionar circuitos virtuales.
Una vez que se ha extraído el comportamiento común, los guiones de uso se
convierten en:
Establecer llamada


6. El sistema analiza dígitos y determina la dirección de red del receptor.
7. Incluir el guión de uso Gestionar circuito virtual para establecer la
conectividad en la red.
8. El sistema suena en el teléfono del receptor.
Iniciar sistema
1. El operador activa el sistema.
2. El sistema realiza pruebas de diagnósticos en todos los componentes.
3. El sistema prueba las conexiones de todos los sistemas adyacentes. Para
cada sistema adyacente (bucle), incluir Gestionar circuito virtual para
establecer la conectividad en la red.
4. El sistema responde que está preparado para la operación.
En un diagrama de guión de uso, la relación de inclusión que se crea se ilustra
del modo siguiente:
Los guiones de uso Establecer llamada e Iniciar sistema incluyen el

comportamiento del guión de uso abstracto Gestionar circuito virtual.
Directriz: Relación ampliada
La relación de ampliación conecta un guión de uso de ampliación a un guión de

uso de base. Esta directriz demuestra cómo utilizar esta relación.
Explicación

La relación de ampliación conecta un guión de uso de ampliación a un guión de

uso de base. Debe definir el lugar de la base en el que insertar la ampliación
haciendo referencia a puntos de ampliación del guión de uso de base (consulte el
apartado Directriz de producto de trabajo: Guión de uso, donde se tratan los
puntos de ampliación). Por lo general, el guión de uso de ampliación es
abstracto, pero no es necesario.
Puede utilizar las ampliaciones con diferentes objetivos:
 Para mostrar que un componente de un guión de uso es un comportamiento
del sistema opcional, o potencialmente opcional. De este modo, separa el
comportamiento opcional del obligatorio en el modelo.
 Para mostrar que un subflujo se ejecuta sólo bajo ciertas condiciones (a
veces excepcionales), como desencadenar una alarma.
 Para mostrar que puede haber un conjunto de segmentos de
comportamiento de los cuales uno o varios pueden insertarse en un punto
de ampliación en un guión de uso de base. Los segmentos de
comportamiento que se insertan (y el orden en que se insertan) dependerán
de la interacción con los actores durante la ejecución del guión de uso de
base.
La ampliación es condicional, lo que significa que depende de lo que ocurra
durante la ejecución del guión de uso de base. El guión de uso de base no
controla las condiciones para la ejecución de la ampliación, las condiciones se
describen en la relación de ampliación. El guión de uso de ampliación puede
acceder y modificar atributos del guión de uso de base. Sin embargo, el guión de
uso de base no puede ver las ampliaciones, ni acceder a sus atributos.
Las extensiones modifican el guión de uso de base implícitamente. También se
puede considerar que el guión de uso de base define una infraestructura modular
en la que se pueden añadir extensiones, pero el guión de uso de base no tiene
visibilidad alguna de las extensiones específicas.
El guión de uso de base debe ser completo en y por sí mismo, lo que significa
que debe ser comprensible y significativo sin referencias a las extensiones. No
obstante, el guión de uso de base no es independiente de las extensiones,
puesto que no se puede ejecutar sin la posibilidad de seguir a las extensiones.
Ejemplo:

Los guiones de uso Establecer teleconferencia y Mostrar identidad del llamador

son extensiones del guión de uso de base Establecer llamada.
En un sistema telefónico, el guión de uso Establecer llamada proporciona el
servicio principal que se proporciona a los usuarios. Los ejemplos de servicios
opcionales son:
 Poder añadir una tercera parte a una llamada (Establecer teleconferencia).
 Permitir que el receptor vea la identidad del llamador (Mostrar identidad del
llamador).
Se pueden representar los comportamientos necesarios para los servicios
opcionales como guiones de uso de ampliación del guión de uso de base
Establecer llamada. Este el uso correcto de la relación de ampliación: puesto que
Establecer llamada es significativo en sí mismo, no es necesario leer las
descripciones de los guiones de uso de ampliación para comprender el objetivo
principal del guión de uso de base, y los guiones de uso de las extensiones
tienen carácter opcional.
Si se deben poder crear instancias de forma explícita tanto el guión de uso de
base como el guión de uso "base más ampliación", o bien, si se desea la adición
para modificar el comportamiento en el guión de uso de base, en su lugar se
debe utilizar la generalización de guiones de uso (consulte el apartado Directriz
de producto de trabajo: Generación de guiones de uso).
El guión de uso de ampliación puede constar de uno o más argumentos de
inserción, cada uno de los cuales puede tener vías de acceso alternativas
incorporadas. Los segmentos de inserción modifican de modo incremental el
comportamiento del guió de uso de base. Cada segmento de inserción del guión
de uso de ampliación se puede insertar en una ubicación separada del guión de
uso de base, lo que significa que la relación de ampliación tiene una lista de
referencias a puntos de ampliación, cuyo número es igual al número de

segmentos de inserción del guión de uso de ampliación. Cada punto de

ampliación se debe definir en el guión de uso de base.
Un guión de uso de base consta de varias relaciones de ampliación, lo que
significa que una instancia de guión de uso puede seguir a más de una
ampliación a o largo de su ciclo de vida. Un guión de uso de ampliación se puede
ampliar a varios guiones de uso de base, pero no implica ninguna dependencia
entre los guiones de uso de base. Pueden incluso existir varias relaciones de
ampliación entre el mismo guión de uso de ampliación y guión de uso de base,
siempre que la ampliación se haya insertado en ubicaciones diferentes de la
base, lo que significa que las diferentes relaciones de ampliación deben hacer
referencia a puntos de ampliación distintos del guión de uso de base. Un guión
de uso de ampliación puede, en sí mismo, ser la base en una relación de
ampliación, inclusión o generalización. Por ejemplo, lo guiones de uso de
ampliación pueden ampliar otros guiones de uso de ampliación de modo anidado.
Ejecución de la ampliación
Cuando una instancia de guión de uso que realiza el guión de uso de base llega a
una ubicación del guión de uso de base en la que se ha definido un punto de
ampliación, se evalúa la condición de la relación ampliada correspondiente. Si la
condición es verdadera o está ausente, la instancia de guión de uso sigue la
ampliación (o el segmento de inserción que corresponde al punto de ampliación).
Si la condición de la relación de ampliación es falsa, la ampliación no se ejecuta.
El guión de uso de ampliación puede, como sucede en cualquier guión de uso,
tener un flujo básico de sucesos y flujos alternativos de sucesos (consulte el
apartado Directriz de producto de trabajo: Guión de uso, donde se trata la
estructura del flujo de sucesos). La vía de acceso exacta que seguirá la instancia
de guión de uso a través de la ampliación depende de lo que suceda antes de la
ejecución (el estado de la instancia de guión de uso) y también de lo que suceda
en la interacción con actores cuando se ejecuta la ampliación. Una vez que la
instancia de guión de uso haya ejecutado la ampliación, la instancia de guión de
uso reanuda la ejecución del guión de uso de base a partir del punto en el que lo
dejó.

Una instancia de guión de uso siguiendo a un guión de uso de base y su

ampliación.
Un guión de uso de ampliación puede tener más de un segmento de inserción,
cada uno de ellos relacionado con su propio punto de ampliación en el guión de
uso de base. Si procede, la instancia de guión de uso reanuda el guión de uso de
base y continúa al punto de ampliación siguiente especificado en la relación de
ampliación. En dicho punto, ejecuta el segmento de inserción siguiente del guión
de uso de ampliación. Esto se repite hasta que se ejecuta el último segmento de
inserción. Tenga en cuenta que la relación de ampliación sólo se comprueba en
el primer punto de ampliación si la condición es verdadera, en cuyo caso la
instancia de guión de uso debe realizar todos los segmentos de inserción.
Una instancia de guión de uso siguiendo a un guión de uso de base y un guión

de uso de ampliación, el último con dos segmentos de inserción.
La multiplicidad de la relación de ampliación restringe el número de repeticiones
de la ampliación completa que se pueden producir. Observe que se repite la
ampliación completa (y que limita la multiplicidad), no sólo un segmento de
inserción.

Documentación de la relación de ampliación

Describa la condición de la ampliación en términos de atributos del guión de uso
de base. También puede elegir la omisión de la condición, en cuyo caso la
ampliación siempre se ejecuta.
Cada relación de ampliación tiene una lista de referencias a puntos de ampliación
(uno o más) en el guión de uso de base. Se hace referencia a los puntos de
ampliación por nombres. Si el guión de uso de ampliación tiene varios
segmentos de inserción, debe especificar el segmento que corresponde a un
punto de ampliación concreto. También debe especificar los pasos o los subflujos
del guión de uso de ampliación que constituyen cada segmento de inserción.
Ejemplo:
En un sistema telefónico, el guión de uso abstracto Mostrar identidad del
llamador puede ampliar el guión de uso Establecer llamada. Es un servicio
opcional al que, con frecuencia, se hace referencia como "ID de llamador", que
puede haber solicitado, o no, el receptor. Una descripción de la relación de
ampliación de Mostrar identidad del llamador a Establecer llamada podría ser
similar a la siguiente:
Condición: El receptor debe haber solicitado el servicio "ID de llamador".
Punto(s) de ampliación Mostrar identidad - inserte el guión de uso Mostrar
identidad del llamador completa.
Si lo desea, puede proporcionar multiplicidad a la relación de ampliación. Si se
omite la multiplicidad, se da por supuesto que es una.
Ejemplo de uso
Imagine el sistema telefónico simple siguiente:
El guión de uso abstracto Establecer teleconferencia es una ampliación del guión

de uso Establecer llamada.
En este modelo, una representación simple de nuestro sistema telefónico
familiar, el servicio de llamadas básico se describe en el guión de uso Establecer

llamada. Un esquema paso a paso del flujo de sucesos básico tendría un aspecto
similar al siguiente:
6. El sistema analiza dígitos, determina la dirección de red del receptor.
7. El sistema analiza los dígitos y determina la ubicación de la red en la que se
encuentra el receptor.
8. A continuación, el sistema determina si se puede establecer un circuito
virtual al receptor.
9. Si se puede establecer un circuito virtual, el sistema llama al teléfono del
receptor y presenta el tono de marcado en el teléfono del llamador.
10. Cuando el receptor responde al teléfono, el sistema inhabilita el tono de
marcado del teléfono del llamador, detiene tono de marcado del teléfono del
receptor y completa el circuito virtual.
11. El sistema inicia un registro de facturación, registra la hora de inicio de la
llamada, los puntos finales de la llamada y la información de cliente del
llamador.
12. La llamada continúa durante un lapso de tiempo determinado. Cuando o el
llamador o el receptor se desconectan de la llamada, el sistema registra la
hora final de la misma, libera todos los recursos necesarios para dar soporte
al circuito virtual y, a continuación, finaliza el guión de uso.
Para añadir funciones a este sistema de modo que permita que el llamador o el
receptor puedan conectar un tercero en la llamada (con frecuencia llamado
"teleconferencia"), se debe añadir comportamiento al flujo de sucesos. Una
alternativa, y la primera que se va a tener en cuenta, consiste en situar las
diferencias directamente en Establecer llamada. Dichas diferencias se podrían
modelar por medio de flujos de sucesos alternativos, tal como se describe en el
apartado Directriz de producto de trabajo: Guión de uso. La solución funciona
con las adiciones más sencillas, siempre que la funcionalidad añadida no
confunda ni oculte el significado original del guión de uso. La otra alternativa
consiste en separar las diferencias en un guión de uso de ampliación abstracto
denominado Establecer teleconferencia que amplíe el guión de uso de base.
El guió de uso Establecer llamada tendría la adición siguiente:

Puntos de ampliación:
Teleconferencia se produce después del paso 11.
El guión de uso de ampliación, Establecer teleconferencia, se podría describir del
modo siguiente:
Guión de uso Establecer teleconferencia
Este guión de uso amplia Establecer llamada. Se ha insertado en el punto de
ampliación Teleconferencia.
Flujo básico:
1. El llamador pulsa el botón de colgar, enlace o señal.
2. El sistema genera 3 pitidos cortos como confirmación.
3..12.<estos pasos son idénticos a los pasos 3..12 del guión de uso de base>
13. El llamador se vuelve a conectar al receptor del guión de uso Establecer
llamada.
Se desaconseja que los pasos 3..12 sean comunes con el guión de uso. Un
modo de resolverlo consiste en descomponer en factores la parte común como
un guión de uso de inclusión (consulte el apartado Directriz de producto de
trabajo: Relación de inclusión).

Modelo de análisis
Este producto de trabajo define un modelo de objeto que describe la realización de

guiones de uso, y sirve como una abstracción del modelo de diseño.
El modelo de análisis contiene las clases de análisis y cualquier producto de trabajo

asociados. El modelo de análisis puede ser un producto de trabajo temporal, como
cuando evoluciona hacia un modelo de diseño, o puede permanecer durante
algunos o todos los proyectos, y quizás más, sirviendo como visión general
conceptual del sistema.
Responsable:
 Arquitecto de software
El modelo de análisis define un modelo de objeto que describe la ejecución de

guiones de uso, y que sirve como abstracción del Producto de trabajo: Modelo de
diseño . El modelo de análisis contiene los resultados del análisis de guión de uso,
instancias de Producto de trabajo: Clase de análisis.
Representación UML: Modelo, estereotipado como <<modelo de análisis>>.

El modelo de análisis puede tener las siguientes propiedades:
 Introducción: Una descripción textual que sirve como breve introducción al
modelo.
 Paquetes de análisis: Los paquetes del modelo, que representan una
jerarquía.
 Clases: Las clases del modelo, propiedad de los paquetes.
 Relaciones: Las relaciones del modelo, propiedad de los paquetes.
 Realizaciones de guión de uso: las realizaciones de guión de uso del
modelo, propiedad de los paquetes.
 Diagramas : Los diagramas del modelo, propiedad de los paquetes.

Normalmente, las "clases de análisis" evolucionarán directamente en elementos en

el modelo de diseño: algunos se convierten en clases de diseño, otros se convierten
en subsistemas de diseño. El objetivo de un análisis es identificar una correlación
preliminar de comportamiento necesario en elementos de modelado del sistema. El
objetivo del diseño es transformar esta correlación preliminar (y algo idealizada) en
un conjunto de elementos de modelo que se pueden implementar. Como resultado,
existe un perfeccionamiento en el detalle y la precisión como uno de los
movimientos de análisis a través de diseño. Como resultado, las "clases de análisis"
suelen ser bastante fluidas, cambiables y evolucionan rápidamente antes de
solidificarse en las actividades de diseño.
Los puntos que hay que tener en cuenta al decidir si es necesario un modelo de
análisis separado:
 Un modelo de análisis puede resultar útil cuando el sistema debe diseñarse
para múltiples entornos de destino, con arquitecturas de diseño separadas.
El modelo de análisis es una abstracción, o una generalización, del modelo
de diseño. Omite la mayoría de detalles del diseño para proporcionar una
visión general de la funcionalidad del sistema.
 El diseño es complejo, así que es necesario un diseño simplificado,
abstraído, para presentar el diseño a nuevos miembros del equipo. Una vez
más, una arquitectura bien definida puede servir para el mismo objetivo.
 El trabajo extra necesario para garantizar que los modelos de diseño de &
análisis mantienen la coherencia se debe equilibrar con el beneficio de tener
una vista del sistema que representa sólo los detalles más importantes
sobre cómo el funcionamiento del sistema. Puede resultar muy costoso
mantener un nivel elevado de fidelidad entre el modelo de análisis y el
modelo de diseño. Un enfoque menos ambicioso puede ser mantener el
modelo de análisis con sólo las clases de dominio más importantes y las
abstracciones clave en el diseño. A medida que la complejidad del modelo de
análisis aumenta, también lo hace el coste para mantenerlo.
 Cuando el modelo de análisis ya no se mantiene, su valor decae
rápidamente. En algún momento, si no se mantiene, dejará de ser útil ya
que no reflejará con precisión el diseño actual del sistema. No mantener el
modelo de análisis puede resultar adecuado (puede haber servido para su
objetivo), pero la decisión debería ser consciente.
En algunas empresas, donde los sistemas duran décadas, o donde existen
diferentes variantes del sistema, un modelo de análisis separado resulta muy útil.

Clase de análisis
En este producto de trabajo se especifican los elementos de un modelo conceptual

temprano para 'cosas del sistema que tienen responsabilidades y comportamiento'.
Las clases de análisis se utilizan para capturar los principales "grupos de

responsabilidad" del sistema.
Responsable:
 Diseñador
Las clases de análisis especifican los elementos de un modelo casi conceptual para
'cosas del sistema que tienen responsabilidades y comportamiento'. Representan
clases prototípicas del sistema, y son un primer paso de las abstracciones
principales que el sistema debe manejar. Las clases de análisis se pueden mantener
por su propio derecho, si se desea una visión general de alto nivel y conceptual del
sistema. Las clases de análisis también ocasionan las principales abstracciones del
diseño del sistema: las clases de diseño y los subsistemas del sistema.
Representación UML: Clase, estereotipada como <<límite>>, <<entidad>> o

<<control>>.
Una clase de análisis puede tener las siguientes propiedades:
 nombre: nombre de la clase
 descripción: breve descripción del rol de la clase en el sistema
 responsabilidades: listado de las responsabilidades de la clase
 atributos: atributos de la clase
Las clases de análisis, tomadas conjuntamente, representan un modelo conceptual
temprano del sistema. Este modelo conceptual evoluciona rápidamente y
permanece fluido durante un tiempo mientras se exploran distintas
representaciones y sus implicaciones. La documentación formal puede impedir este
proceso, de modo que debe ir con cuidado con la energía que gasta para mantener
este "modelo" en un sentido formal. Puede perder mucho tiempo puliendo un
modelo que es ampliamente prescindible. Las clases de análisis raramente

sobreviven al diseño sin que se hayan modificado. La mayoría de ellos representan

colaboraciones completas de objetos, a menudo encapsuladas por subsistemas.
Normalmente, las tarjetas para notas, como en el ejemplo siguiente, son suficientes
(se basa en la conocida técnica de la tarjeta CRC; consulte el apartado [WIR90]
para obtener información detallada sobre esta técnica). En la parte frontal de la
tarjeta, capture el nombre y la descripción de la clase. A continuación se muestra
un ejemplo de un Curso en un sistema de inscripción en cursos:
Nombre de clase Curso

El curso es el responsable de mantener la información sobre
Descripción un conjunto de secciones de cursos que tienen un tema,
requisitos y programa.
Responsabilidades Para mantener la información sobre el curso.
Nombre Descripción Tipo

Título del cadena de
Nombre del curso
Atributos curso caracteres
Descripción corta del cadena de
Descripción
curso caracteres
En la parte posterior de la tarjeta, dibuje un diagrama de la clase:
Diagrama de clase para el curso

Hay una tarjeta de clase de análisis para cada clase descubierta durante el taller de
análisis de guiones de uso.
Directriz: Clase de análisis

Existen tres estereotipos de clase de análisis: Límite, Control y Entidad. En esta

directriz se explica su significado y uso.
Estereotipos de clase de análisis

Las clases de análisis se pueden estereotipar como una de las siguientes:
 Clases de límite
 Clases de control
 Clases de entidad
A parte de proporcionarle una orientación más específica del proceso para
encontrar las clases, estos estereotipos producen un modelo de objeto robusto
porque los cambios del modelo tienden a afectar sólo a un área específica. Los
cambios en la interfaz de usuario, por ejemplo, afectarán sólo a las clases de
límite. Los cambios en el flujo de control afectarán sólo a las clases de control.
Los cambios de la información a largo plazo afectarán sólo a las clases de
entidad. Sin embargo, estos estereotipos resultan especialmente útiles para
ayudar a identificar clases en análisis y en diseño temprano. Probablemente
debe considerar la utilización de un conjunto de estereotipos ligeramente
diferente en fases posteriores del diseño para mejorar la correlación con el
entorno de implementación, el tipo de aplicación, etc.
Clase de límite
Una clase de límite es una clase que se utiliza para modelar la interacción entre
el entorno del sistema y los trabajos internos. Tal interacción implica la
transformación y la traducción de sucesos y cambios de notación en la
presentación del sistema (como la interfaz).
Las clases de límite modelan los componentes del sistema que dependen del
entorno. Las clases de entidad y las de control modelan los componentes que
son independientes del entorno del sistema. Por lo tanto, cambiar la GUI o el
protocolo de comunicación debe significar cambiar sólo las clases de límite, no
las clases de control y de entidad.
Las clases de límite también facilitan la compresión del sistema porque aclaran
los límites del sistema. Ayudan en el diseño proporcionando un buen punto de
partida para identificar los servicios relacionados. Por ejemplo, si identifica una
interfaz de la impresora pronto en el diseño, podrá ver que también debe
modelar el formato de las salidas impresas.
Las clases de límites comunes incluyen ventanas, protocolos de comunicación,
interfaces de impresoras, sensores y terminales. No tiene que modelar

componentes de interfaces de rutinas, como botones, como clases de límites

separados. Generalmente, toda la ventana es el objeto de límite más pequeño.
Las clases de límite también resultan útiles para capturar interfaces para
posibilitar las API no orientadas a objetos, como por ejemplo código heredado.
Debe modelar las clases de límite de acuerdo con el tipo de límite que
representan. La comunicación con otro sistema y la comunicación con un actor
humano (mediante una interfaz de usuario) tienen diferentes objetivos. Para
comunicar con un actor humano, la preocupación más importante es cómo se
presentará la interfaz al usuario. Para comunicar con otro sistema, la
preocupación más importante es el protocolo de comunicación.
Un objeto de límite (una instancia de clase de límite) puede sobrevivir a una
instancia de guión de uso si, por ejemplo, debe aparecer en una pantalla entre el
rendimiento de dos guiones de uso. Normalmente, sin embargo, los objetos de
límite viven sólo durante la instancia de guión de uso.
Encontrar las clases de límite
Una clase de límite hace de intermediario entre la interfaz y algo fuera del
sistema. Los objetos de límite aíslan el sistema de los cambios del entorno (los
cambios en las interfaces a otros sistemas, cambios en los requisitos del usuario,
etc.), evitando que estos cambios afecten al resto del sistema.
Un sistema puede tener diferentes tipos de clases de límite:
 Clases de interfaz de usuario - clases que hacen de intermediario en la
comunicación con usuarios humanos del sistema.
 Clases de interfaz de sistema - clases que hacen de intermediario en la
comunicación con otros sistemas
 Clases de interfaz de dispositivo - clases que proporcionan la interfaz a
los dispositivos (como sensores), que detectan sucesos externos
Encontrar las clases de interfaz de usuario
Defina una clase de límite para cada par de actores de guión de uso. Esta clase
se puede visualizar si tiene la responsabilidad de coordinar la interacción con el
actor. También puede definir clases de límite adicionales para representar
clases subsidiarias a las que las clases de límite principales delegan algunas de
estas responsabilidades. Esto es especialmente cierto para aplicaciones GUI
basadas en ventanas, donde puede modelar un objeto de límite para cada
ventana, o uno para cada forma. Modele sólo las abstracciones de claves del
sistema; no modele todos los botones, las listas y los objetos gráficos de la GUI.
El objetivo del análisis es formar una buena imagen de cómo está compuesto el

sistema, no diseñar hasta el último detalle. En otras palabras, identificar las

clases de límite sólo para los fenómenos del sistema o para lo que se menciona
en el flujo de sucesos de la ejecución de guión de uso.
Haga esbozos, o utilice volcados de pantalla desde un Prototipo de interfaz de
usuario, que ilustra el comportamiento y la apariencia de las clases de límite.
Encontrar las clases de interfaz de sistema
Una clase de límite que comunica con un sistema externo es responsable de
gestionar el diálogo con el sistema externo; proporciona la interfaz de ese
sistema para el sistema que se está construyendo.
Ejemplo
En un cajero automático, la retirada de dinero debe verificarse a través de la red
de cajeros automáticos, un actor (que a su vez verifica la retirada con el sistema
de cuentas del banco). Se puede identificar un objeto denominado Interfaz de la
red de cajeros automáticos para proporcionar comunicación con la red de cajeros
automáticos.
Es posible que la interfaz a un sistema existente ya esté bien definida; si lo está,
las responsabilidades deben derivarse directamente desde la definición de
interfaz. Si existe una definición de interfaz formal, se puede revertir la
ingeniería y no es necesario definirla formalmente aquí; simplemente, tenga en
cuenta el hecho que la interfaz existente se reutilizará durante el diseño.
Encontrar las clases de interfaz de dispositivo
El sistema puede contener elementos que actúan como si fueran externos
(cambian de valor espontáneamente sin que les afecte ningún objeto del
sistema), como equipamiento sensor. Aunque es posible representar este tipo de
dispositivo externo mediante actores, los usuarios del sistema pueden
encontrarlo confuso, ya que tiende a colocar los dispositivos y los actores
humanos en el mismo nivel. Cuando nos apartamos de la recopilación de
requisitos, sin embargo, debemos tener en cuenta el origen de todos los sucesos
externos y asegurarnos de que disponemos del modo para que el sistema
detecte estos sucesos.
Si el dispositivo está representado como actor en el modelo de guión de uso, es
fácil de justificar mediante una clase de límite para que haga de intermediario
entre la comunicación entre el dispositivo y el sistema. Si el modelo de guión de
uso no incluye estos "dispositivos-actores", ahora es el momento apropiado para
añadirlos, actualizando las Descripciones suplementarias de los guiones de uso
cuando sea apropiado.

Para cada "dispositivo-actor", cree una clase de límite para capturar las
responsabilidades del dispositivo o sensor. Si ya existe una interfaz bien definida
para el dispositivo, téngala en cuenta para una posterior referencia durante el
diseño.
Clase de control
Una clase de control es una clase que se utiliza para modelar el
comportamiento de control específico a uno o a varios guiones de uso. Los
objetos de control (instancias de clases de control) a menudo controlan otros
objetos, para que el comportamiento sea de tipo de coordinación. Las clases de
control resumen el comportamiento de guión de uso específico.
El comportamiento de un objeto de control está estrechamente relacionado con
la ejecución de un guión de uso específico. En muchos casos de ejemplo, incluso
puede decir que los objetos de control "ejecutan" las ejecuciones de guión de
uso de análisis. Sin embargo, algunos objetos de control pueden participar en
más de una ejecución de guiones de uso de análisis si las tareas de guión de uso
están fuertemente relacionadas. Además, varios objetos de control de diferentes
clases de control pueden participar en un guión de uso. No todos los guiones de
uso requieren un objeto de control. Por ejemplo, si el flujo de sucesos en un
guión de uso está relacionado con un objeto de entidad, un objeto de límite
puede realizar el guión de uso en colaboración con el objeto de entidad. Puede
empezar identificando una clase de control por ejecución de guiones de uso de
análisis y, a continuación, perfeccionando esto a medida que se identifican más
ejecuciones de guiones de uso de análisis y se descubren más similitudes.
Las clases de control pueden contribuir en la comprensión del sistema porque
representan las dinámicas del sistema, gestionando las tareas principales y los
flujos de control.
Cuando el sistema efectúa el guión de uso, se crea un objeto de control. Los
objetos de control habitualmente mueren cuando el guión de uso
correspondiente se ha llevado a cabo.
Tenga en cuenta que una clase de control no maneja todo lo necesario en un
guión de uso. En cambio, coordina las tareas de otros objetos que implementan
la funcionalidad. La clase de control delega trabajo a los objetos que se han
asignado a la responsabilidad de la funcionalidad.
Encontrar las clases de control

Las clases de control proporcionan un comportamiento de coordinación en el

sistema. El sistema puede efectuar algunos guiones de uso sin objetos de control
(utilizando sólo objetos de entidad y de límite); especialmente los guiones de
uso que implican sólo la simple manipulación de información almacenada.
Los guiones de uso más complejos generalmente requieren una o más clases de
control para coordinar el comportamiento de los otros objetos del sistema. Los
ejemplos de objetos de control incluyen programas como gestores de
transacciones, coordinadores de recursos y manejadores de errores.
Las clases de control desacoplan de forma efectiva los objetos de entidad y de
límite entre ellos, haciendo que el sistema sea más tolerante a cambios en el
límite del sistema. También desacoplan el comportamiento específico de guión
de uso de los objetos de entidad, haciéndolos más reutilizables en los guiones de
uso y los sistemas.
Las clases de control proporcionan un comportamiento que:
 Es independiente del entorno (no cambia cuando el entorno cambia),
 Define la lógica de control (orden entre sucesos) y transacciones en un
guión de uso.
 Cambia poco si la estructura interna o el comportamiento de las clases de
entidad cambian,
 Utiliza o establece el contenido de diferentes clases de entidad y, por lo
tanto, necesita coordinar el comportamiento de estas clases de entidad.
 No se realiza del mismo modo cada vez que se activa (el flujo de sucesos
pasa por diferentes estados).
Determine si es necesaria una clase de control
El flujo de sucesos de un guión de uso define el orden en que se efectúan las
diferentes tareas. Empiece investigando si el flujo de puede gestionar con el
límite que ya está identificado y por las clases de entidad. Para flujos de
sucesos simples que principalmente entran, recuperan y muestran, o modifican
información, no está justificada una clase de control separada; las clases de
límite serán responsables de coordinar el guión de uso.
Los flujos de sucesos deben estar resumidos en una clase de control separada
cuando es complejo y consta de comportamiento dinámico que puede cambiar
independientemente de las interfaces (clases de límite) o los almacenes de
información (clases de entidad) del sistema. Resumiendo los flujos de sucesos,
la misma clase de control puede reutilizarse de forma potencial para una serie de

sistemas que pueden tener diferentes interfaces y diferentes almacenes de

información (o, como mínimo, las estructuras de datos subyacentes).
Ejemplo: gestión de una cola de tareas
Puede identificar una clase de control a partir del guión de uso Realizar tarea en
el Sistema de manipulación de almacén. Esta clase de control gestiona una cola
de Tareas, asegurando que las tareas se efectúan en el orden correcto. Efectúa
la tarea siguiente en la cola cuando el equipamiento de transporte adecuado está
asignado. El sistema puede, por lo tanto, llevar a cabo varias tareas al mismo
tiempo.
El comportamiento definido por el objeto de control correspondiente es más fácil
de describir si lo divide en dos clases de control, Realizador de tareas y
Manejador de colas. Un objeto Manejador de colas manejará sólo el orden de la
cola y la asignación de equipamiento de transporte. Un objeto Manejador de
colas es necesario para toda la cola. Cuando el sistema efectúe una tarea, creará
un nuevo objeto Realizador de tareas, que llevará a cabo la Tarea. Por lo tanto,
necesitamos un objeto Realizador de tareas para cada tarea que el sistema lleva
a cabo.
Las clases complejas deben dividirse en líneas de responsabilidades similares

El beneficio principal de esta división es que disponemos de responsabilidades de
manejo de colas separadas (algo genérico para muchos guiones de uso) desde
las tareas específicas de la gestión de tareas, que son específicas para este
guión de uso. Esto facilita la comprensión de las clases y las hace más fáciles de
adaptar a medida que el diseño madura. También tiene beneficios en el equilibrio
de la carga del sistema, ya que muchos Realizadores de tareas se pueden crear
cuando sea necesario para manejar la carga de trabajo.
Resumir el flujo principal de sucesos y los flujos
alternativos/excepcionales de sucesos en clases de control separadas
Para simplificar los cambios, se resume el flujo principal de sucesos y los flujos
alternativos de sucesos en diferentes clases de control. Si los flujos alternativos

y de excepción son totalmente independientes, sepárelos también. Esto facilitará

que el sistema se amplíe y se mantenga a lo largo del tiempo.
Dividir las clases de control donde dos actores comparten la misma clase
de control
También puede ser necesario dividir las clases de control cuando varios actores
utilizan la misma clase de control. De este modo, aislamos los cambios de los
requisitos de un actor del resto del sistema. En los casos en que el coste del
cambio es elevado o las consecuencias son problemáticas, debe identificar todas
las clases de control relacionadas con más de un actor y dividirlas. En el caso
ideal, cada clase de control debe interactuar (a través de algún objeto de límite)
con un actor, o ninguno.
Ejemplo: gestión de llamadas
Considere el guión de uso LLamada local. Inicialmente, podemos identificar una
clase de control para gestionar la misma llamada.
La clase de control que gestiona las llamadas telefónicas locales en un sistema

telefónico se pueden dividir rápidamente en dos clases de
control, Comportamiento-A y Comportamiento-B, una para cada actor
implicado.
En una llamada local, hay dos actores: el Suscriptor-A que inicia la llamada, y
el Suscriptor-B que la recibe. El Suscriptor-A levanta el receptor, oye el tono
de línea, y marca una serie de dígitos, que el sistema almacena y analiza.
Cuando el sistema ha recibido todos los dígitos, envía el tono de marcado
al Suscriptor-A, y la señal de llamada al Suscriptor-B. Cuando el Suscriptor-

B responde, el tono y la señal se detienen, y puede empezar la conversación

entre los suscriptores. La llamada finaliza cuando ambos suscriptores cuelgan.
Deben controlarse dos comportamientos: Qué sucede en el lugar del Suscriptor-
A y qué sucede en el lugar del Suscriptor-B. Por este motivo, el objeto de control
original se divide en dos objetos de control, Comportamiento-
A y Comportamiento-B.
No tiene que dividir una clase de control si:
 Puede asegurar de forma razonable que el comportamiento de los actores
relacionado con los objetos de la clase de control nunca cambiarán, o que
cambiarán muy poco.
 El comportamiento de un objeto de clase de control hacia un actor es
insignificante en comparación con el comportamiento hacia otro actor, un
único objeto puede mantener todo el comportamiento. Combinar los
comportamientos de este modo tendrá un efecto insignificante en la
capacidad de cambio.
Clase de entidad
Una clase de entidad es una clase que se utiliza para modelar información y el
comportamiento asociado que debe almacenarse. Los objetos de entidad
(instancias de clases de entidad) se utilizan para mantener y actualizar la
información sobre algún fenómeno, como un suceso, una persona, o algún
objeto real. Habitualmente son persistentes, teniendo atributos y relaciones
necesarias durante un periodo prolongado, a veces para toda la vida del sistema.
Un objeto de entidad no suele ser específico para una ejecución de guiones de
uso de análisis; a veces, un objeto de entidad no es ni siquiera específico del
mismo sistema. Los valores de los atributos y relaciones suelen venir de un
actor. Un objeto de entidad también puede ser necesario para ayudar a realizar
tareas internas del sistema. Los objetos de entidad pueden tener un
comportamiento tan complicado como el de otros estereotipos de objeto. Sin
embargo, a diferencia de otros objetos, este comportamiento está fuertemente
relacionado con el fenómeno que representa el objeto de entidad. Los objetos de
entidad son independientes del entorno (los actores).
Los objetos de entidad representan conceptos clave del sistema que se está
desarrollando. Ejemplos típicos de las clases de entidad en un sistema bancario
son Cuenta y Cliente. En un sistema de manejo de red, los ejemplos
son Nodo y Enlace.

Si ninguna otra clase utiliza el fenómeno que desea modelar, puede modelarlo
como un atributo de una clase de entidad, o incluso como una relación entre
clases de entidad. Por otra parte, si otra clase utiliza el fenómeno en el modelo
de diseño, debe modelarlo como clase.
Las clases de entidad proporcionan otro punto de vista desde el cual se
comprende el sistema porque muestran la estructura de datos lógica, que puede
ayudarle a comprender qué se supone que ofrece el sistema a los usuarios.
Encontrar las clases de entidad
Las clases de entidad representan almacenes de información en el sistema; se
utilizan habitualmente para representar los conceptos clave que gestiona el
sistema. Los objetos de entidad suelen ser pasivos y persistentes. Sus
principales responsabilidades son almacenar y gestionar información en el
sistema.
Una fuente de inspiración frecuente para las clases de entidad son el Glosario
(desarrollado durante los requisitos) y un modelo de dominio empresarial
(desarrollado durante el modelado empresarial, si se efectúa modelado
empresarial).
Restricciones de uso de los estereotipos de asociación
Restricciones para clases de límite
Se permite lo siguiente:
 Comunicar asociaciones entre dos clases de límite, por ejemplo, para
describir como una ventana específica está relacionada con otros objetos de
límite.
 Comunicar o suscribir asociaciones de una clase de límite a una clase de
entidad, porque los objetos de límite pueden necesitar el seguimiento de
ciertos objetos de entidad entre acciones en el objeto de límite, o estar
informados de los cambios de estado en el objeto de entidad.
 Comunicar asociaciones de una clase de límite a una clase de control, para
que el objeto de límite pueda desencadenar un comportamiento concreto.
Restricciones para clases de control
Se permite lo siguiente:
 Comunicar o suscribir asociaciones entre clases de control y clases de
entidad, porque los objetos de control pueden necesitar el seguimiento de
ciertos objetos de entidad entre acciones en el objeto de control, o estar
informados de los cambios de estado en el objeto de entidad.

 Comunicar asociaciones entre clases de control y de límite, permitiendo que

los resultados del comportamiento invocado se comuniquen al entorno.
 Comunicar asociaciones entre clase de control, permitiendo la construcción
de patrones de comportamiento más complejos.
Restricciones para clases de entidad
Las clases de entidad sólo deben ser el origen de las asociaciones (comunicar o
suscribir) a otras clases de entidad. Los objetos de clase de entidad tienden a
durar mucho; los objetos de clase de control y de límite tienden a tener una vida
más corta. Es coherente desde el punto de vista arquitectónico limitar la
visibilidad que un objeto de entidad tiene de su entorno; de este modo el
sistema es más sencillo de cambiar.
Resumen de restricciones
FromTo
Límite Entidad Control
(navegabilidad)
comunica
Límite comunica comunica
suscribe
comunica
Entidad
suscribe
comunica
Control comunica comunica
suscribe
Combinaciones de estereotipos de asociación válidos

Reforzar la coherencia
 Cuando se identifica un nuevo comportamiento, compruebe si existe alguna
clase que tenga unas responsabilidades similares, reutilizando las clases
donde sea posible. Sólo cuando esté seguro de que no hay ningún objeto
existente que puede efectuar el comportamiento, deberá crear las nuevas
clases.
 Cuando las clases se hayan identificado, examínelas para asegurarse de que
tienen responsabilidades coherentes. Cuando las responsabilidades de las
clases se desconecten, divida el objeto en dos o más clases. Actualice el
diagrama de interacción según corresponda.
 Si la clase se divide porque se descubren las responsabilidades
desconectadas, examine las colaboraciones en que la clase tiene un rol para
ver si la colaboración necesita una actualización. Actualice la colaboración si
fuera necesario.

 Una clase con sólo una responsabilidad no es un problema, per se, pero
puede generar preguntas sobre porqué es necesaria. Esté preparado para
solicitudes de identificación y para justificar la existencia de todas las clases.

Modelo de diseño
Este producto de trabajo es un modelo de objeto que describe la realización de

guiones de uso, y sirve como una abstracción del modelo de implementación y el
código fuente. El modelo de diseño se utiliza como entrada esencial para
actividades en implementación y prueba.
El modelo de diseño es una abstracción de la implementación del sistema. Se utiliza

para concebir y para documentar el diseño del sistema de software. Es un producto
de trabajo integral y compuesto que abarca todas las clases de diseño,
subsistemas, paquetes, colaboraciones y las relaciones entre ellos.
Responsable:
 Arquitecto de software
Representación UML: Clase, estereotipada como <<designModel>>.

Un modelo de diseño puede tener las siguientes propiedades:
 Introducción: Una descripción textual que sirve como breve introducción al
modelo.
 Paquetes de diseño / subsistemas de diseño: Los paquetes y
subsistemas del modelo, que representan una jerarquía.
 Clases: Las clases del modelo, propiedad de los paquetes.
 Cápsulas: Las cápsulas del modelo, propiedad de los paquetes.
 Interfaces: Las interfaces del modelo, propiedad de los paquetes.
 Protocolos: Los protocolos del modelo, propiedad de los paquetes.
 Sucesos y señales: Los sucesos y señales del modelo, propiedad de los
paquetes.
 Relaciones: Las relaciones del modelo, propiedad de los paquetes.
 Realizaciones de guión de uso: las realizaciones de guión de uso del
modelo, propiedad de los paquetes.
 Diagramas: Los diagramas del modelo, propiedad de los paquetes.

Decida sobre lo siguiente:

 las propiedades que desea incluir
 si son necesarias o no ampliaciones del Lenguaje unificado de modelado
(UML); por ejemplo, el proyecto puede requerir estereotipos adicionales
 el nivel de formalidad aplicada al modelo
 la personalización aplicable a subproductos de trabajo individuales
 cómo se correlaciona el modelo con el modelo de análisis (consulte el
apartado Directriz de producto de trabajo: Modelo de diseño)
 si se utilizará un modelo único o múltiples modelos
 si el modelo será una especificación abstracta, una especificación detallada,
un diseño detallado, o alguna combinación (consulte el apartado Directriz de
producto de trabajo: Modelo de diseño)
 cómo se correlaciona el modelo con el modelo de implementación (está
fuertemente afectado por la decisión de utilizar ingeniería inversa,
generación de código, o ingeniería directa e inversa); consulte el
apartado Técnica: Correlación de diseño a código

El proceso de arquitectura
En RUP, la arquitectura es principalmente un resultado del análisis y el flujo de

trabajo de diseño. A medida que el proyecto reactiva este flujo de trabajo, de
iteración e iteración, la arquitectura evoluciona hasta que está perfeccionada y
pulida. Dado que todas las iteraciones incluyen integración y pruebas, la
arquitectura es bastante robusta cuando se entrega el producto. Esta arquitectura
es uno de los focos principales de las iteraciones de la fase de Elaboración, al final
de cual la arquitectura suele tener su línea base.


Contexto de La Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

Contexto de La Arquitectura de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Contexto de La Arquitectura de Software

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

CONTEXTO DE LA ARQUITECTURA DE SOFTWARE

La arquitectura de software representa la estructura o las estructuras del sistema,

La arquitectura de software es un concepto fácil de entender y que la mayoría de

En An Introduction to Software Architecture, David Garlan y Mary Shaw sugieren

La arquitectura de un sistema de software es la organización o la estructura de los

Contexto de la Arquitectura de Software

Se representa la arquitectura de software en varias vistas de la arquitectura.

Las vistas capturan las principales decisiones de diseño estructural y muestran

La arquitectura se representa mediante un número diferente de vistas de la

 La Vista de guión de uso, que contiene guiones de uso y casos de ejemplo

Contexto de la Arquitectura de Software

 La Vista lógica, que contiene las clases de diseño más importantes y su

Las vistas de la arquitectura se muestran en el documento de arquitectura de

Las vistas de la arquitectura son, esencialmente, abstracciones o simplificaciones de

 La evolución del sistema, el paso al siguiente ciclo de desarrollo.

Contexto de la Arquitectura de Software

 Las decisiones sobre la inclusión de componentes asequibles.

Una arquitectura de software, o simplemente una vista de la arquitectura, puede

se proporciona a través del producto de trabajo Directrices específicas del

La representación gráfica de una vista de la arquitectura se llama anteproyecto

Una vista de la arquitectura llamada vista de guión de uso se utiliza en la

Para proporcionar una base para planificar el contenido técnico de las

Contexto de la Arquitectura de Software

La vista de guión de uso muestra un subconjunto significativo

Contexto de la Arquitectura de Software

 Definir el conjunto de casos de ejemplo y guiones de uso que tienen una

 Vista lógica. Diagramas de clase, máquinas de estado y diagramas de objeto

Una vista de la arquitectura llamada vista lógica proporciona la base para

Contexto de la Arquitectura de Software

La vista lógica muestra un subconjunto significativo arquitectónicamente del

 Vista de proceso. Diagramas de clase y diagramas de objeto (tareas

Una vista de la arquitectura llamada vista de proceso ilustra la descomposición

Para proporcionar una base para comprender la organización de procesos del

Contexto de la Arquitectura de Software

construye y se utiliza la vista de proceso, son importantes, por ejemplo, los

de Cápsulas para representar las clases activas en la vista de proceso. Las

 Utilizan una comunicación basada en mensajes asíncronos a través de

Puertos que utilizan Protocolos bien definidos.

Contexto de la Arquitectura de Software

La vista de proceso muestra la organización de procesos del sistema.

 Vista de implementación. Diagramas de componentes

Una vista de la arquitectura llamada vista de implementación suele capturar la

La vista de implementación es una de las cinco vistas de la arquitectura de un

Contexto de la Arquitectura de Software

La vista de implementación y otras vistas de la arquitectura se atestiguan en el

 Vista de despliegue. Diagramas de despliegue

Una vista de la arquitectura llamada vista de despliegue ilustra la distribución de

Contexto de la Arquitectura de Software

La vista de despliegue muestra la distribución física de procesos del sistema.

Las vistas de la arquitectura se muestran en el Documento de arquitectura de

Esencialmente, las vistas de la arquitectura se pueden ver como abstracciones o

Documento de arquitectura de software

Este producto de trabajo proporciona una visión general arquitectónica completa

El documento de arquitectura de software proporciona una visión general completa

Representación UML: Un conjunto de vistas de arquitectura relevantes: guión de

Contexto de la Arquitectura de Software

permanencia requiera una correlación entre objetos permanentes y

Contexto de la Arquitectura de Software