4.4 SEMÁNTICA 4.4.1 Propósito El documento presenta la

Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
4.4 SEMÁNTICA
4.4.1 Propósito
El documento presenta la especificación de la semántica del UML. Utilizando lenguaje
natural y formal para hacerlo fácil de entender.
4.4.2 Alcance
Este documento especifica la semántica para 2 modelos:
!
!
Modelo estático
Modelo dinámico
El modelo estático hace referencia a la estructura de los objetos dentro del sistema (clases,
interfaces y relaciones).
El modelo dinámico hace referencia al comportamiento de los objetos dentro del sistema
(métodos, interacciones, colaboraciones, estados).
La especificación de la semántica abarca todas las notaciones del modelado descritas en
el documento de notación del UML.
4.4.3 Enfoque
La especificación hace hincapié en la arquitectura y formalismo del lenguaje.
La arquitectura del lenguaje del UML esta basado en 4 capas las cuales son: objetos del
usuario, modelo, metamodelo y meta-metamodelo.
Haciendo mayor referencia a la capa del metamodelo, la cual es una instancia de la capa
del meta-metamodelo. Por ejemplo: un atributo en el metamodelo es una instancia del metaatributo en el meta-metamodelo.
La arquitectura del metamodelo del UML se discute en la sección arquitectura del lenguaje
en el documento del UML. El metamodelo es un modelo lógico y no físico, la ventaja de un
metamodelo lógico es que hace énfasis en la semántica declarativa suprimiendo los detalles de
implementación.
El lenguaje esta fundamentado en varios paquetes lógicos; fundamento, elementos del
comportamiento y mecanismos generales. Estos paquetes también contienen subpaquetes.
Por ejemplo el paquete fundamento consiste de los siguientes subpaquetes: núcleo,
elementos auxiliares, mecanismos de extensión y tipos de datos. La estructura del lenguaje esta
descrita en la sección arquitectura de lenguaje en el documento del UML.
El metamodelo esta descrito de una manera semiformal usando tres vistas:
•
•
•
Sintaxis abstracta: Es documentada como un modelo descrito en un subconjunto del
UML, y consiste en un diagrama de clases y una descripción en lenguaje natural.
Formalización de reglas: Son documentadas usando un lenguaje formal (OCL) y un
lenguaje natural.
Semántica: Esta especificada en lenguaje natural, pero puede incluir alguna notación
adicional dependiendo de la parte del modelo que esta siendo descrita. La adaptación de
Paola Romero Guillén
104
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
técnicas formales para especificar el lenguaje esta descrita en la sección Formalismo del
Lenguaje en el documento del UML.
4.4.4 Organización del documento del UML
El documento se describe en varias partes:
Parte 1: Antecedentes
Parte 2: Fundamento
Parte 3: Elementos de comportamiento
Parte 4: Mecanismo general
Parte 1: Explica como el UML es estructurado y especificado y cuenta con los siguientes
subpaquetes. La sección arquitectura del lenguaje describe la estructura del lenguaje y explica la
arquitectura del metamodelo. La sección de especificación del lenguaje describe como el lenguaje
es definido usando múltiples vistas.
Parte 2: El paquete fundamento describe la infraestructura del UML. Este paquete esta
descompuesto en varios subpaquetes:
!
Núcleo: especifica los conceptos básicos requeridos para un metamodelo elemental y
define una arquitectura para ligar constructores adicionales del lenguaje, como metaclases, meta-asociaciones y meta-atributos.
!
Elementos auxiliares: definen constructores adicionales que extienden el núcleo para
soportar conceptos avanzados como dependencias, plantillas, estructuras físicas,
elementos tipos vista.
!
Mecanismo de extensión: especifica como los elementos del modelo son separados y
extendidos con nuevas semánticas.
!
Tipos de datos: define las estructuras de los datos básicos del lenguajes.
Elemento
Auxiliar
Núcleo
Mecanismos de
Extensión
Tipos de Datos
Figura # 3 Paquetes de Fundamento
Parte 3: El paquete elementos del comportamiento define la superestructura para modelar el
comportamiento del UML. Este paquete consiste en 4 paquetes de bajo nivel:
!
Comportamiento común: especifica conceptos del núcleo requeridos por los elementos
dinámicos.
Paola Romero Guillén
105
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
!
Colaboraciones: especifica un contexto del comportamiento para los elementos del modelo
que cumplen una tarea en particular.
!
Casos de uso: especifica el comportamiento usando actores y casos de uso.
!
Maquina de estados: define el comportamiento usando sistemas de transición de estados
finitos.
Colaboración
Casos de Uso
Máquinas de
Estado
Comportamiento
Común
Figura # 4 Paquetes de elementos de comportamiento
Parte 4: En esta versión del UML se maneja un paquete de mecanismos generales que define
mecanismos de aplicación general a los modelos, llamado administrador del modelo, que
especifica como los elementos del modelo son organizados en modelos, paquetes y sistemas.
Elementos de
comportamiento
Administrador del
modelo
Fundamento
Figura # 5 Paquete de nivel superior
4.4.5 Documentos relacionados al metamodelo
Los siguientes documentos son importantes para extender el metamodelo del UML.
! El resumen del UML provee una introducción al UML discutiendo sus objetivos e historia.
! La guía de notación del UML, define la sintaxis grafica para expresar la semántica descrita
por el metamodelo del UML. Por lo tanto, la Guía Notación del UML deberá ser leída en
conjunto con el documento Semántica del UML.
! El lenguaje de especificación de objetos describe la sintaxis, semántica y gramática del
OCL. Todas las características del OCL están descritas en términos de conceptos a partir
del documento semántica del UML.
Paola Romero Guillén
106
Instituto Tecnológico
de la Laguna
!
!
Análisis y Diseño Orientado
a Objetos
El UML CORBAfacility especifica una herramienta para una interfase usando CORBAL IDL.
Un resumen de propuesta que sintetiza la propuesta del UML y discute la relación del UML
con otras tecnologías.
4.4.6 Antecedentes
Profundizando en la parte 1 del documento del UML con la finalidad de facilitar la lectura
de cómo esta estructurado y especificado éste. La arquitectura del lenguaje describe la estructura
del lenguaje y explica la arquitectura del metamodelo de 4 capas.
Arquitectura del lenguaje
El metamodelo del UML define la semántica de una forma circular para representar
modelos de objetos usando el UML. El metamodelo del UML es una de las capas, de las 4 capas
que conforman la arquitectura del metamodelo. Como la capa del metamodelo es relativamente
compleja esta es descompuesta en paquetes lógicos. Las siguientes secciones proporcionan una
revisión a la arquitectura del metamodelo y describe la estructura de sus paquetes.
Arquitectura del metamodelo (4 capas)
Esta arquitectura proporciona una infraestructura para definir la semántica exacta
requerida para modelos complejos. Las ventajas de esta sección son las siguientes:
! Valida constructores del núcleo que mediante recursividad se aplican a ellos mismos en
metacapas sucesivas.
! Proporciona una estructura básica para definir futuras extensiones del metamodelo del
UML.
! Proporciona una arquitectura base para relacionar el metamodelo del UML con otros
estándares basados en la misma arquitectura.
La arquitectura esta basada en las siguientes 4 capas:
!
!
!
!
Meta-metamodelo
Metamodelo
Modelo
Objetos de usuario
Las funciones de estas capas están suministradas en la siguiente tabla:
ETAPA
META-METAMODELO
METAMODELO
MODELO
OBJETOS DEL
USUARIO
DESCRIPCIÓN
La
infraestructura
para
la
arquitectura
del
metamodelo.
Define el lenguaje para especificar
metamodelos.
Una instancia de un metamodelo.
Define el lenguaje para especificar
un modelo.
Una instancia de un metamodelo.
Define un lenguaje para describir
la información del dominio.
Una instancia de un modelo.
Define una información especifica
del dominio.
EJEMPLO
Metaclase,
Metaatributo,
Metaoperación
Clase, Atributo,
Componente.
Operación,
Fruta, velocidad
Fresa, 100
Tabla # 14
Paola Romero Guillén
107
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
La capa del meta-metamodelo es la capa fundamental de la arquitectura para el
metamodelo. La principal responsabilidad de esta etapa es definir el lenguaje para especificar
un metamodelo. Un meta-metamodelo define un modelo en un alto nivel de abstracción mayor
que un metamodelo. Un meta-metamodelo puede definir múltiples metamodelos y pueden ser
asociados múltiples meta-metamodelos con cada metamodelo. Ejemplo: meta-metaobjetos en
la capa del metamodelado son: meta-clase, meta-atributo, meta-operación.
Un metamodelo es una instancia de un meta-metamodelo. La principal
responsabilidad de la capa del metamodelo es definir un lenguaje para especificar modelos.
Ejemplo: de meta objetos en la capa del metamodelo son: clases, atributos, operaciones,
componentes.
Modelo es una instancia de un metamodelo. La principal responsabilidad de la capa
del modelo es definir un lenguaje que describe la información del dominio.
Objetos de usuario son una instancia de un modelo. Su primera responsabilidad es
describir la información del dominio.
Formalismo del lenguaje
La sección contiene técnicas para describir el UML. Las técnicas formales son usadas por
la especificación para incrementar la precisión mientras se mantiene la legibilidad.
La técnica describe el metamodelo del UML en 3 vistas usando presentación textual y
grafica.
Ventajas de usar técnicas formales:
! La exactitud de la descripción es mejorada
! La ambigüedad y las inconsistencias se reducen
! La arquitectura del metamodelo esta validada por una técnica complementaria,
! La legibilidad de la descripción es incrementada.
Niveles del formalismo
La técnica más común para la especificación de lenguajes consiste en definir primero
la sintaxis del lenguaje y luego describir la semántica estática y dinámica. La sintaxis define
que estructuras existen en el lenguaje y como las estructuras están construidas en términos
de otras estructuras. Algunas veces, especialmente si el lenguaje tiene una sintaxis gráfica, es
importante definir la sintaxis en una notación de manera independiente (sintaxis abstracta). La
sintaxis concreta es definida mapeando la notación sobre la sintaxis abstracta. La sintaxis esta
descrita en secciones con el encabezado sintaxis abstracta en el documento del UML..
La semántica estática de un lenguaje define como una instancia de una estructura
debe ser conectada a otras instancias para ser significativa. Y la semántica dinámica define el
significado de una estructura bien formada.
El significado de una descripción escrita en un cierto lenguaje esta definido solamente
si la descripción esta bien formada (si cumple reglas definidas en la semántica estática). La
semántica estática se encuentra en las secciones bajo el encabezado Formalización de reglas.
La semántica dinámica esta descrita bajo el encabezado semántica. En algunos casos partes
de la semántica estática esta también explicada en la sección semántica.
La especificación usa una combinación de lenguajes para describir la sintaxis abstracta
y la semántica del UML, como sigue:
!
Un subconjunto del UML
Paola Romero Guillén
108
Instituto Tecnológico
de la Laguna
!
!
Análisis y Diseño Orientado
a Objetos
El Lenguaje OCL
Un Lenguaje natural
En la construcción del metamodelo del UML han sido usadas diferentes técnicas para
especificar las estructuras del lenguaje usando algunas de las capacidades del UML. Las
estructuras principales están dentro de las meta-clases en el metamodelo. Otras estructuras,
en esencia son variantes de otras y son definidas como estereotipos de meta-clases en el
metamodelo. Este mecanismo permite que la semántica de la estructura variante sea
significativamente diferente a la meta-clase base. Otra forma mas sencilla de definir variante es
usar los meta-atributos. Un ejemplo, la estructura agregación esta especificada por un atributo
de la meta-clase AssociationEnd, la cual es usada para indicar si una asociación es una
agregación ordinaria, un agregado compuesto o una simple asociación.
Especificación de la estructura de los paquetes
El documento tiene una sección para cada paquete del metamodelo del UML. Cada
una de estas secciones tiene las siguientes subsecciones.
Sintaxis Abstracta
La sintaxis abstracta se presenta en un diagrama mostrando las meta-clases,
definiendo los constructores y sus relaciones. El diagrama también presenta algunas de las
reglas formadas, principalmente los requerimientos de multiplicidad de las relaciones y
quizás algunas instancias de un sub-constructor, en particular deberán ser ordenadas. Se
proporciona, una descripción informal en lenguaje natural para definir cada constructor. El
primer párrafo de cada una de estas descripciones es una presentación general del
constructor para situarse en el contexto, mientras los siguientes párrafos ofrecen una
definición informal de las meta-clases especificando el constructor usando el UML. Para
cada meta-clase, sus atributos son enumerados juntos con una pequeña explicación. Por
otra parte, el nombre del rol contrario de las asociaciones conectado a la meta-clase es
también listado de la misma forma.
Formalización de reglas
La semántica estática de cada constructor en el lenguaje UML, excepto para la
multiplicidad y restricciones, es definida como un conjunto de invariantes de una instancia
de la meta-clase. Esas invariantes tienen que ser satisfechas por el constructor para que
tenga sentido. De esta manera las reglas especifican restricciones sobre atributos y
asociaciones definidas en el metamodelo.
Cada invariante es definida por una expresión OCL junto con una explicación
informal de la expresión. En muchos casos, operaciones adicionales sobre las meta-clases
son necesarias para explicar las expresiones OCL. Estas están definidas en una
subseccion aparte, después de la sección Formalización de reglas, para la estructura se
usa el mismo enfoque como en la sección de sintaxis abstracta: una explicación informal
seguida por la expresión OCL definiendo la operación.
El enunciado “No extra Formalización de reglas” significa que todas las
descripciones de la semántica estática actual son expresadas en la superclase junto con la
multiplicidad y el tipo expresado en los diagramas.
Semántica
El lenguaje natural es usado para definir el significado de las estructuras. Las
estructuras son agrupadas en partes lógicas y definidas en conjunto.
Paola Romero Guillén
109
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
Elementos estándares
Estereotipos de las meta-clases definidos previamente en la sección son listados
con una definición informal en lenguaje natural. Los estereotipos también son definidos de
la misma forma como en la subseccion de Formalización de reglas. Otros tipos de
elementos estándar son listados y están definidos en el apéndice; Estándar de Elementos
del documento del UML.
Notas
Esta subsección puede contener decisiones razonables para el metamodelo, pragmática
para el uso de la estructura y ejemplos escritos en lenguaje natural.
Uso de OCL
Se usa el OCL para expresar la Formalización de reglas. Las siguientes convenciones
son usadas para garantizar su legibilidad:
Self, el cual puede ser omitido como una referencia a la meta-clase definiendo el
contexto de la invariante, ha sido puesto para mayor claridad.
En expresiones donde una colección es iterada, un iterador es usado para dar claridad.
El tipo del iterados es omitido, pero puede incluirse cuando facilita el entendimiento.
La operación collect es implícita en esta práctica.
Uso del lenguaje natural
El lenguaje natural es usado para dar explicaciones de los constructores, el mas usado
es el Inglés, pero para nuestro caso será el Español.
4.4.7 Ejemplo de la especificación anterior: casos de uso.
(Paquete Elementos de Comportamiento)
El paquete CASOS DE USO es un subpaquete del paquete Elementos de
Comportamiento. Este especifica los conceptos usados para la definición de la funcionalidad de
una entidad como un sistema. El subpaquete usa constructores definidos en el paquete
Fundamento del UML, así como en el paquete Comportamiento Común.
Los elementos en el subpaquete CASOS DE USO son empleados principalmente para
definir el comportamiento de una entidad, como un sistema o subsistema, sin especificar su
estructura interna. Los principales elementos en este subpaquete son:
Casos de usos y Actores: Instancias de casos de uso e instancias de actores interactúan
cuando los servicios de una entidad son usados. Como un caso de uso es manejado en términos
de cooperación de objetos, definidos por clases encerradas en la entidad, pueden ser
especificados con una Colaboración. Un caso de uso de una entidad puede ser definido como un
conjunto de casos de uso de los elementos contenidos en la entidad. Como esos casos de uso
subordinados interactúan también pueden ser expresados en una Colaboración. La especificación
de la funcionalidad del sistema en si mismo esta usualmente expresada en un modelo de casos de
uso separado. Un modelo estereotipado <<use case model>>. Los casos de uso y los actores en el
modelo de casos de uso son equivalentes a los paquetes del sistema.
Paola Romero Guillén
110
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
Sintaxis abstracta
La sintaxis abstracta para el paquete de casos de uso es expresado en la siguiente
notación gráfica
*
Realización
*
Especificación
Actor
Clasificador
(de Núcleo)
Clasificador
1..*
Instancia
(de Comportamiento Común)
*
Caso de Uso
PuntoExtension:lista de String
Instancia de Caso de
Uso
Figura # 6, Subpaquete de Casos de Uso.
Las siguientes metaclases están contenidas en el paquete casos de uso.
Actor
Un actor define un conjunto coherente de roles que los usuarios de una entidad pueden
jugar cuando interactúan con la entidad. Un actor tiene un rol para cada caso de uso con el cual se
comunica. El metamodelo actor es una subclase de Classifier, un actor tiene un nombre y puede
comunicarse con un conjunto de casos de uso, y en un nivel de realización, con Classifiers
tomando parte en la realización de esos casos de uso. Un actor puede también tener un conjunto
de interfaces, las cuales describen como otros elementos pueden comunicarse con el actor. Un
actor puede heredar a otros actores. Esto significa que la herencia de un actor será capaz de jugar
los mismos roles como el actor heredado, comunicarse con el mismo conjunto de casos de uso.
Caso de uso
El constructor del caso de uso es empleado para definir el comportamiento de un sistema u
otra entidad semántica sin revelar su parte interna, cada caso de uso especifica una secuencia de
acciones, incluyendo variantes que la entidad puede hacer interactuando con actores de la entidad.
En el metamodelo, caso de uso es una subclase de Classifier, contiene un conjunto de
operaciones y atributos especificando las secuencias de acciones hechas por una instancia de un
caso de uso. Las acciones incluyen cambios del estado y comunicaciones con el ambiente del
caso de uso.
Pueden existir asociaciones entre caso de usos y los actores de los casos de uso. Como
una asociación sitúa (declara) que instancias del caso de uso y un usuario jugando uno de los roles
del actor comunicando con otros. Los casos de uso pueden ser relacionado a otros casos de uso
solamente por relaciones Extends y Uses, estas son relaciones de generalización estereotipadas
<<extends>> o <<uses>>. Una relación Extends denota la extensión de la secuencia de un caso
Paola Romero Guillén
111
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
de uso con la secuencia de otro, mientras que la relación uses denota que el caso de uso
comparte un comportamiento común.
La realización de un caso de uso puede ser especificada por un conjunto de
colaboraciones, las colaboraciones se definen como instancias en el sistema, que interactúan para
realizar la secuencia del caso de uso.
Atributos:
ExtenssionPoint: Es una lista de cadenas representando puntos de extensión definidos dentro del
caso de uso. Un punto de extensión es una situación a la cual el caso de uso puede ser extendido
con comportamiento adicional.
Instancia de caso de uso
Una instancia de caso de uso es la representación de una secuencia de acciones
especificadas en un caso de uso.
En el metamodelo Instancia Caso de Uso es una subclase de Instance. Cada método
ejecutado por una instancia de caso de uso es llevado a cabo en una transacción atómica y no es
interrumpida por otra instancia de caso de uso.
Formalización de reglas
Las siguientes reglas se aplican solamente en el paquete de casos de uso.
Actor
Actores solamente pueden tener Asociaciones a Casos de Uso y Clases, dichas Asociaciones
son binarias:
self.associations->forAll(a|a.connection->size = 2 and a.allConnections>exists(r |r.type.oclIsKindOf(Actor)) and a.allConnections>exists(r|r.type.oclIsKindOf(UseCase) or r.type.oclIsKindOf(Class))
Actores no pueden contener cualquier clasificadores
self.contents->isEmpty
Para cada operación en una interfase el actor debe tener su correspondiente operación
self.specification.allOperations->forAll (interOp) | self.allOperations>exists(op|op.hasSameSignature (interOp)))
Caso de uso
Los Casos de uso solo pueden tener asociaciones binarias
self.associations->forAll(a|a.connection->size=2)
Casos de uso no pueden tener asociaciones a casos de uso que especifican la misma entidad
self.associations->forAll(a|a.allConnections->forAll(s,
o|s.type.specificationPath->isEmpty and o type.specificacionPath->isEmpty
or (not s.type.specificationPath->includesAll(o.type.specificationPath)
Paola Romero Guillén
112
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
and not o type.specificationPath>includesAll(s.type.specificationsPath))))
Un caso de uso solamente puede tener Generalizaciones <<uses>> o <<extends>>
self.generalization->forAll(g|g.stereotype.name=’Uses’ or
g.stereotype.name=’Extends’)
Un caso de uso no puede contener ningún clasificador
self.contents->isEmpty
Para cada operación en una interfase el caso de uso debe tener una operación correspondiente
self.specification.allOperations->forAll (interOp|self.alloperations>exists(op|op.hasSameSignature (interOp)))
Operaciones adicionales
La operación specificationPath resulta en un conjunto conteniendo todos los Namespaces que no
son instancias de Package.
SpecificationPath:Set(Namespace)specificationPath=self.allSurroundingName
spaces->selext(n|n.oclIsKindOf(subsytem) or n.oclIsKindOf(Class)
Instancia de Caso de Uso
No hay Formalización de reglas.
Semántica
Esta sección proporciona una descripción de la semántica de los elementos en el paquete
casos de uso y sus relaciones con otros elementos del paquete, elementos del comportamiento.
Actor
Asociación
Namespace
Interfase
*
1
2..*
*
Asociación End
Actor
*
1
1
1
*
*
Generalizaciòn
Figura # 7, Actor
Los actores modelan partes fuera de la entidad, como un sistema, subsistema o una clase,
las cuales interactúan con la entidad. Cada actor modela un conjunto coherente de roles que los
usuarios de la entidad pueden jugar cuando interactúan con la entidad. En cada momento un
usuario especifico interactúa con la entidad jugando uno de sus roles. Una instancia de un actor es
un usuario específico que interactúa con la entidad. Cualquier instancia que se ajusta conforma a
Paola Romero Guillén
113
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
un actor puede actuar como una instancia del actor. Si la entidad es un sistema, los actores
representan a usuarios u otros sistemas.
Algunos de los actores de un subsistema de bajo nivel o una clase pueden coincidir con
actores del sistema, mientras otros actúan dentro del sistema. Los roles definidos por el último tipo
de actores son jugados por instancias de clasificadores en otros paquetes o subsistemas, cuando
en el ultimo caso el clasificador puede corresponder a uno u otro la especificación parte de un
contenido del subsistema. Cuando un actor esta fuera de la entidad, su estructura interna no esta
definida pero solo su vista externa se define como se ve desde la entidad. Instancias de actores se
comunican con la entidad enviando y recibiendo instancias de mensajes a instancias de casos de
uso. Esto es expresado por asociaciones entre el actor y el caso de uso o clase.
Además, las interfaces pueden ser conectadas a un actor definiendo como otros elementos
pueden interactuar con el actor.
Dos o mas actores pueden tener casos de uso en común, se comunican con el mismo
conjunto de casos de uso de la misma forma. Esta semejanza es expresada con generalización a
otro actor, el cual modela el rol común. Una instancia de un heredero puede siempre ser usada
donde una instancia del ancestro es esperada.
Casos de uso
En el siguiente texto el término entidad es usado cuando se refiere a un sistema, un subsistema o
una clase y el término elemento del modelo o elemento denota un subsistema o una clase.
Atributo
Namespace
Interface
1
*
*
*
Operación
Caso de Uso
Generalización
*
*
*
<<Uses>> o <<Extends>>
*
InstanciaCasodeUso
*
FinalAsociación
Asociación
2..*
Figura # 8, Casos de Uso.
El propósito de un caso de uso es definir una pieza del comportamiento de una entidad sin
revelar la estructura interna de la entidad. La entidad especificada en esta forma puede ser un
sistema o cualquier elemento del modelo que contiene comportamiento, como un subsistema o una
clase en un modelo de un sistema. Cada caso de uso especifica un servicio que la entidad provee
a los usuarios (una forma especifica de usar la entidad). Esto especifica una secuencia completa
iniciada por un usuario, las interacciones entre los usuarios y la entidad, así como las respuestas
hechas por la entidad. Un caso de uso también incluye posibles variantes de su secuencia,
(secuencias alternativas, comportamiento excepcional, manejo de errores, etc.).
Paola Romero Guillén
114
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
El conjunto completo de casos de uso especifica todas las formas de usar la entidad (todo
el comportamiento de la entidad es expresado por sus casos de uso). Los casos de uso pueden
ser agrupados en paquetes según convenga.
Desde un punto de vista pragmático, lo casos de uso pueden ser usados para la
especificación de los requerimientos en una entidad y para la especificación de la funcionalidad
proporcionada por una entidad. Además los casos de uso también declaran indirectamente los
requerimientos, la entidad especificada indica a sus usuarios como deben interactuar, así la
entidad será capaz de proporcionar sus servicios.
Los usuarios de casos de uso siempre son externos a la entidad especifica, ellos están
representados por actores de la entidad. Así, si la entidad especificada es un sistema o un
subsistema en el mas alto nivel (el paquete de mayor nivel), los usuarios de este caso de uso están
modelados por los actores del sistema.
Los actores de un subsistema de bajo nivel o una clase que son internos a el sistema son
definidos no explícitamente, en cambio los casos de uso relacionados directamente a los
elementos del modelo se ajustan a actores implícitos (cuyas instancias juegan esos roles en
interacción con los casos de uso). Esos elementos están contenidos en otros paquetes o
subsistemas, donde los casos de uso en el subsistema pueden estar contenidos en la parte de
especificación o en la parte de contenido. No hay distinción entre actor y elemento, ambos se
refieren al mismo término Actor.
Pueden existir asociaciones entre casos de uso y actores, principalmente si las instancias
del caso de uso y del actor se comunican. Un actor puede comunicarse con varios casos de uso de
una entidad (el actor puede requerir varios servicios de la entidad) y un caso de uso puede
comunicarse con uno o varios actores cuando proveen este servicio. Note que dos casos de uso
que especifican la misma entidad no pueden comunicarse con otros debido a que cada uno de
ellos describe individualmente un uso completo de la entidad. Además, los casos de uso siempre
usan señales cuando se comunican con los actores fuera del sistema, mientras este puede usar
otra semántica de comunicación cuando se comunica con elementos dentro del sistema.
La interacción entre actores y casos de uso puede estar definida con interfases. La
interfase entonces define un subconjunto de la interacción entera definida en el caso de uso.
Una instancia de un caso de uso es un objeto de un caso de uso, iniciado por un mensaje
desde una instancia de un actor. Como una respuesta a el mensaje, la instancia del caso de uso
hace una secuencia de acciones especificadas por el mismo caso de uso, enviando mensajes a
instancias de actores. La instancia del actor puede enviar nuevos mensajes a la instancia del caso
de uso y la interacción continua hasta que la instancia ha respondido a todas las entradas y
cuando no espera mas, termina. Cada método hecho por una instancia de caso de uso esta hecho
como una transacción atómica (no es ejecutada por ninguna otra instancia de caso de uso).
Un caso de uso puede estar descrito en texto, usando operaciones, en diagramas de
actividad, por una máquina de estados, o por otras técnicas de descripción del comportamiento y
como pre y post-condiciones. La interacción entre el caso de uso y los actores pueden también
estar presentada en diagramas de colaboración.
En el caso donde son usados subsistemas para modelar el paquete heredado, el sistema
puede estar especificado con casos de uso de todos los niveles, un caso de uso puede emplearse
para especificar cada subsistema y cada clase. Un caso de uso que especifica un elemento del
modelo es entonces remitido dentro de un conjunto pequeño de casos de uso.
Las semejanzas entre casos de uso son expresadas con relaciones “uses” (generalización
con el estereotipo <<uses>>). La relación significa que la secuencia de comportamiento descrito en
un caso de uso es incluido en la secuencia de otro caso de uso. El último caso de uso puede
introducir nuevas piezas de comportamiento en cualquier lugar de la secuencia, haciéndola mas
Paola Romero Guillén
115
Instituto Tecnológico
de la Laguna
Análisis y Diseño Orientado
a Objetos
grande pero sin cambiar el orden de la secuencia original. Además, si un caso de uso tiene varias
relaciones, esta secuencia será el resultado de las salidas de las secuencias usadas junto con
nuevas piezas de comportamiento. Estas partes están combinadas para formar la nueva secuencia
que esta defina usando un caso de uso.
Una relación “extends” (generalización con el estereotipo <<extends>>), define que el caso
de uso puede ser expandido con algún comportamiento adicional definido en otro caso de uso. Las
relaciones extends incluyen una condición para la extensión y una referencia a un punto de
extensión en el caso de uso relacionado (una posición en el caso de uso donde las adiciones
pueden ser hechas). Una vez que una instancia de un caso de uso alcanza un punto de extensión
en el cual una relación extends esta referida, la condición de la relación es evaluada. Si la
condición se cumple, la secuencia acatada por el caso de uso es extendida. Diferentes partes de la
secuencia del caso de uso extendido pueden ser insertadas en diferentes puntos de extensión en
la secuencia original. Si todavía se cumple la condición (si la condición de la relación extends es
cumplida en el primer punto de extensión), entonces el comportamiento extendido es insertado en
la secuencia original.
Elementos estándar
Consultar el apéndice Elementos Estándar en el documento del UML para las definiciones
de los estereotipos <<extends>> y <<modelo de caso de uso>>.
Notas
Una regla pragmática de uso, cuando se definen casos de uso, indica que cada uno de
ellos deberá entregar algún tipo de resultado de valor a uno de sus actores. Esto asegura que el
caso de uso esta completo y por lo tanto no tiene fragmentos.
Paola Romero Guillén
116