UD:INGENIERIA WEB - SESION N°02

SESION N Web
Ingeniería °2
02

FUNDAMENTOS DE LA INGENIERIA WEB
Ingeniería Web

El Lenguaje Unificado de Modelado.de
Tema 2: El Lenguaje Unificado UML 2

PT. Henry Gomez Sernaque ( hegomezsernaque@servigenhegs.com )

Ingeniería Web
El Lenguaje Unificado de Modelado

Contenidos

Introducción
Visión global de UML
Modelado de la estructura
Diagramas de clases
Estructuras compuestas
Arquitectura física
Modelado del comportamiento
Modelado de casos de uso
Diagramas de actividad
Modelado de las interacciones
Máquinas de estados
Referencias

Tema 2: El Lenguaje Unificado de Modelado

Ingeniería Web

Ingeniería Web

1. Introducción

Ingeniería Web

Introducción

En la vida real, se construyen muchas clases de modelos con
distintos propósitos antes de construirlos
Objetivos de los modelos
Probar una entidad física antes de construirla
Comunicación con el cliente
Visualización
Reducción de la complejidad
Estructurar las ideas
Un modelo es una abstracción de un sistema semánticamente
cerrada
Un lenguaje de modelado es un lenguaje para especificar,
construir, visualizar, y documentar ingenios software


Ingeniería Web

Ingeniería Web

¿Por qué es necesario un lenguaje de modelado?

Los sistemas complejos son
difíciles de entender si no se
cuenta con un modelo que los
describa
El conseguir un lenguaje de
modelado capaz de captar la
semántica de cualquier sistema
software, es esencial a la hora de
llevar a cabo un proyecto
software de una cierta
Método = Qué + Cómo + Porqué
complejidad
La representación de un modelo
• Sintácticas
en un lenguaje de modelado Lenguaje de
obviamente tiene un valor Modelado = Notación + Reglas • Semánticas

añadido si dicho lenguaje de • Pragmáticas
modelado es estándar

Ingeniería Web

Modelos basados en el paradigma objetual

Con la orientación a objetos se busca una suma sinérgica

¡Soy
¿Datos? orientado a ¿Procesos?
edad objetos! ladrar
raza comer
color dormir

¡Objetos! = características + comportamiento

6


Ingeniería Web

Ingeniería Web

Necesidad de la unificación en un estándar

Necesidad de estandarización a mediados de los noventa

Ingeniería Web

Caminos al estándar

UML
OMG Microsoft
Oracle
...
Estandarización
Prestigio
Reconocimiento


Ingeniería Web

Ingeniería Web

2. Visión global de UML

Ingeniería Web

¿Qué es UML?

Lenguaje para especificar, construir, visualizar y documentar ingenios
software, cuyo alcance pretende cubrir los conceptos de Booch, OMT y
OOSE resultando un lenguaje simple, común y ampliamente utilizable
por usuarios de otros métodos

UML es un lenguaje de modelado de objetos independiente del método que se
implemente
UML no es una notación propietaria
UML no es una metodología, método o proceso
La especificación UML se define usando el enfoque de metamodelado
La infraestructura de UML 2.0 se define en el
paquete InfrastructureLibrary:
Define un metalenguaje núcleo (core)
Permite la personalización de UML mediante
Perfiles (Profiles)


Ingeniería Web

Ingeniería Web

Modelos de representación
En UML 2 se definen 13 diagramas diferentes :
Modelado estructural
Diagrama de clases
Diagrama de estructuras compuestas
Diagrama de componentes
Diagrama de despliegue
Diagrama de objetos
Diagrama de paquetes
Modelado de comportamiento
Diagrama de casos de uso
Diagrama de actividad
Diagramas de interacción
Diagrama de secuencia
Diagrama de comunicación o colaboración
Diagrama de visión global de la interacción
Diagrama de tiempo
Diagrama de maquina de estados
13

Ingeniería Web

Elementos de modelado

Elemento: Clase Objeto

Constituyente del modelo que
Atributos Atributos
Estado
Métodos Métodos

tiene la capacidad de tener
otros elementos Interfaz

Un elemento de modelado Caso de
Uso
Nodo

puede tener su Actor
<<Component>>

correspondiente elemento de Nota
Componente
Paquete

representación (símbolo
gráfico utilizado para
Dependencia Generalización
representar el elemento en los
diagramas)
Asociación Agregación

Composición


Curso de Doctorado
Ingeniería Web

Ingeniería Web

Mecanismos de extensibilidad

Mecanismos de extensibilidad: mecanismos que permiten
ofrecer información extra y especializar los modelos
Mecanismos estándar:
Estereotipos: especializan las clases del metamodelo
Etiquetas: cadenas asociadas a un símbolo gráfico del modelo
Valores etiquetados: extienden los atributos de las clases del metamodelo
Restricciones: extienden la semántica del metamodelo
Perfiles: mecanismos para extender un metamodelo de referencia
con objeto de adaptarlo a las características específicas de una
plataforma (.NET, J2EE …) o de un dominio de aplicación (tiempo real,
modelado de procesos de negocio …)

Ingeniería Web

3. Modelado de la estructura


Ingeniería Web

Ingeniería Web

Introducción

El modelado estructural captura la vista estática del sistema
Constituye el fundamento de UML
Los elementos de la vista estática de un modelo son los conceptos
que tienen significado en una aplicación, incluyendo conceptos del
mundo real y conceptos computacionales
Los elementos clave de la vista estática son los clasificadores y sus
relaciones
Un clasificador es un elemento de modelado que describe cosas:
clases, interfaces, tipos de datos, casos de uso, paquetes...
Las relaciones entre clasificadores son asociación, generalización y
varias clases de dependencia entre las que se incluyen realización y
uso

Ingeniería Web

Concepto de clasificador

Un clasificador es un concepto discreto en el modelo, que tiene
identidad, estado, comportamiento y relaciones
Tiene un nombre único
Declara una colección de características como métodos, operaciones o
atributos
Un clasificador es un tipo y puede tener relaciones de generalización con
otros clasificadores

«caso de uso»
Obtener pedido

Representación de un clasificador de tipo “caso de uso”


Ingeniería Web

Ingeniería Web

Clases

Una clase representa un concepto discreto dentro de la aplicación que se está
modelando
Una clase es un descriptor de un conjunto de objetos con estructura,
comportamiento y relaciones similares
Un objeto es una entidad discreta con identidad, estado y comportamiento
invocable
Una clase define un conjunto de objetos que tienen un estado y comportamiento
El estado se describe por atributos y asociaciones
Los atributos se utilizan generalmente para los valores puros de los datos sin identidad
Las asociaciones se utilizan para las conexiones entre objetos con identidad
Las piezas individuales de comportamiento invocable se describen mediante
operaciones; un método es la implementación de una operación
Los diagramas que muestran la estructura estática del modelo son los diagramas
de clases
Las clases se representan por rectángulos compartimentados. El primero de ellos
contiene el nombre de la clase, que debe ser único en el paquete que la contiene.
El segundo contiene los atributos y el último los métodos

Ingeniería Web

Clases

Ejemplos de definición de clases <<controlador>>
PenTracker
{abstract}

Ventana
Ventana {abstract, Rectángulo
autor=Jose
estado=comprobada} P1: Punto
+tamaño: Área =(100,100)
P2: Punto
#visibilidad: Lógico= invisible <<constructor>>
Ventana +tamaño-por-defecto: Rectángulo Rectangulo (p1:Punto, p2:Punto)
#tamaño-máximo: Rectángulo <<consulta>>
-xptr: XWindows* área ():Real
Tamaño: Área
visibilidad: Lógico +display () aspecto (): Real
+hide () ...
display () +create () <<actualización>>
hide () -attrachXWindow(xwin:Xwindows*) mueve (delta: Punto
escala (ratio: Real)
...


Ingeniería Web

Ingeniería Web

Relaciones
Una relación es una conexión semántica entre elementos de un modelo
Pueden ser de varios tipos:
Asociación: relación que describe un conjunto de enlaces entre objetos
Generalización: relación entre un elemento más general y otro más
específicos
Dependencia: relación entre
Asociación
elementos, uno dependiente y otro
independiente. Un cambio en el
Generalización
independiente afectará al
dependiente
Dependencia
Abstracción/realización: relación
entre dos descripciones de una Realización
misma cosa a diferentes niveles

Ingeniería Web

Relaciones
Asociación: describe las conexiones semánticas entre objetos de diferentes
clases. Una instancia de una asociación es un enlace

multiplicidad nombre de rol

0..* nombre rol
ClaseA NombreCalificador:NombreClase ClaseB
nombre
asociación

agregación/
composición
ruta de indicador de calificador
nombre de
asociación navegación
asociación

Compañía 1..* w
Trabaja para 1..*
Persona
Empleador Empleado


Ingeniería Web

Ingeniería Web

Relaciones

* Reparto
Concierto

*

Asociación reflexiva
Orquesta *

Titular
* Intérprete
0..1

Suplente *
Suplente

Compañía 1..* 1..* Persona
Empleador Empleado

Trabajo
salario Jefe
0..1
trabajador * Dirige a...

Ingeniería Web

Relaciones

La multiplicidad al final de una asociación representa el número potencial de instancias,
cuando los otros n-1 están fijados. Es decir, la multiplicidad con que una clase participa
en una relación n-aria se define con respecto a las otras n-1 clases

Alumno

*

* 0..1
Curso Profesor

Registro

Asociación ternaria


Curso de Doctorado
Ingeniería Web

Ingeniería Web

Relaciones

{subsets <nombrePropiedad>} el extremo es un subconjunto
{subsets <nombrePropiedad>} el extremo es un subconjunto
de la propiedad llamada <nombrePropiedad>
de la propiedad llamada <nombrePropiedad>
{redefined <nombreExtremo>} el extremo redefine otro
{redefined <nombreExtremo>} el extremo redefine otro
extremo llamado <nombreExtremo>
extremo llamado <nombreExtremo>
{union} el extremo se deriva de la unión de sus subconjuntos
{union} el extremo se deriva de la unión de sus subconjuntos
{ordered} el extremo representa un conjunto ordenado
{ordered} el extremo representa un conjunto ordenado
{bag} el extremo representa una bolsa
{bag} el extremo representa una bolsa
{sequence} o {seq} el extremo representa una secuencia
{sequence} o {seq} el extremo representa una secuencia
Si el extremo es navegable se le puede aplicar cualquier
Si el extremo es navegable se le puede aplicar cualquier
cadena de propiedades aplicable a los atributos
cadena de propiedades aplicable a los atributos

Cadenas de propiedades aplicables a extremos de una asociación

Ingeniería Web

Relaciones

Ejemplo de propiedades aplicables a extremos de una asociación


Ingeniería Web

Ingeniería Web

Relaciones

Agregación: forma de asociación que representa una relación todo-parte
entre un agregado (el todo) y las partes que los componen
Composición: Forma de asociación de agregación con fuerte sentido
de posesión
Un objeto sólo puede ser parte de un compuesto a la vez
El objeto compuesto es el único responsable de la disponibilidad
de todas sus partes

MensajeCorreo

* *
* *
1 1 Compañía División Departamento

Dirección Cuerpo

Ingeniería Web

Relaciones
Propiedades de las agregaciones
La relación de agregación es transitiva y antisimétrica a través de los enlaces de
agregación (las relaciones entre objetos son acíclicas)
Una ruta dirigida de asociaciones de agregación de una clase a sí misma es
una recursividad
Propiedades de las composiciones:
Las partes tienen tiempo de vida coincidente con el conjunto (las partes con
multiplicidad no fija, se pueden crear después del elemento compuesto y se
pueden quitar explícitamente antes de la muerte del elemento compuesto)
La multiplicidad debe ser 1 ó 0..1 al lado del compuesto
1 0..1
Transacción Autentificación
*
Elemento

Icono Contenedor
Compra Venta

28


Ingeniería Web

Ingeniería Web

Relaciones

Generalización: Es una relación de taxonomía entre un elemento general y
otro más específico que es plenamente consistente con el primer elemento y
que le añade información adicional
Restricciones
Disjoint (disjunto) – Ningún elemento puede tener dos hijos en el conjunto como
antecesores (en una situación de generalización múltiple). Ninguna instancia
puede ser una instancia directa o indirecta de dos de los hijos (en una semántica
múltiple de la clasificación)
Overlapping (solapado) – Un elemento puede tener dos o más hijos en el conjunto
de antecesores. Una instancia puede ser una instancia de dos o más hijos
Complete (completo) – Todos los hijos posibles se han enumerado en el conjunto
y no puede ser agregado ninguna más
Incomplete (incompleto) – No se ha enumerado todavía todos los hijos posibles en
el conjunto. Se esperan más hijos o se conocen pero no se han declarado aún

Ingeniería Web

Relaciones
restricciones, se
Generalization set Trabajador aplican a todos los
hijos
ocupación {disjoint, incomplete}

Carnicero Panadero Pescadero

Atleta

{overlapping, incomplete}

Futbolista Nadador


Ingeniería Web

Ingeniería Web

Paquetes

Los paquetes constituyen un mecanismo de agrupación para organizar
elementos UML
Proporcionan un espacio de nombres a los elementos agrupados
Un elemento de modelado puede pertenecer a más de un paquete
La agrupación de elementos de modelado en un paquete no es necesario
que coincida con la agrupación física de elementos del sistema
Los paquetes se organizan jerárquicamente, siendo el paquete raíz el que
contiene todo el sistema

P
P

A B

A B

Ingeniería Web

Paquetes

Las relaciones permitidas entre paquetes
son generalización, dependencia y
refinamiento
Dependencias específicas para paquetes
Importación: permite a un paquete
importar los elementos de otro y
referenciarlos sin usar el nombre calificado.
Puede ser de dos tipos <<import>> o
<<access>>
Fusión (merge): relación entre dos
paquetes en la que el contenido del
paquete objetivo es fusionado con el
contenido del paquete fuente usando
generalizaciones y redefiniciones. Se utiliza
el estereotipo <<merge>>


Ingeniería Web

Ingeniería Web

Modelos y subsistemas

Un modelo es un paquete que recoge una descripción completa de una vista
particular del sistema
Un subsistema es un paquete que tiene partes separadas de especificación y de
realización. Es una unidad coherente del modelo que generalmente representa la
partición funcional del sistema

venta de billetes

<<model>>
VentaBilletes Servicio
Pedidos crédito

Análisis Diseño Precios
Selección
asientos

Ingeniería Web

Diagrama de estructuras compuestas

Representación de la estructura interna de un clasificador. Están
formados por:
Partes: roles de los clasificadores
Conectores: enlaces entre instancias de las partes conectadas.
El extremo de un conector puede ser un puerto

Coche

P
eje
posterior:Rueda [2] m:Motor


Ingeniería Web

Ingeniería Web


Arquitectura física: asignación de artefactos de software a nodos físicos
Diagramas de componentes
Componentes: empaquetamiento físico de una colección de elementos de modelado
Artefactos: Manifestación física de un componente
Diagramas de despliegue
Dispositivos: recursos computacionales (nodos)
Caminos de comunicación: mecanismos de comunicación entre nodos
Entornos de ejecución: subnodos de los dispositivos

Pedidos :Cuenta

<<manifest>>

<<artifact>>
Producto
Cuenta.jar

Diagrama de componentes

Ingeniería Web


<<T
:NodoClienteA CP
/IP >>

:ServidorBDBiblioteca
>
/IP>
:NodoClienteB CP
<<T

* 1
ServidorAplicacion ServidorBD

<<deploy>>
<<deploy>>

<<artifact>> <<artifact>>

GestorCompra.jar Pedido.jar

Diagramas de despliegue


Ingeniería Web

Ingeniería Web

5. Modelado del comportamiento

Ingeniería Web

Modelado de casos de uso

La vista de casos de uso captura la funcionalidad de un
sistema, de un subsistema, o de una clase, tal como se
muestra a un usuario exterior
Reparte la funcionalidad del sistema en transacciones
significativas para los usuarios ideales de un sistema
Los usuarios del sistema se denominan actores y las
particiones funcionales se conocen con el nombre de casos
de uso
La técnica que se utiliza para modelar esta vista es el
diagrama de casos de uso


Ingeniería Web

Ingeniería Web

Casos de uso
Los casos de uso son una técnica para la especificación de requisitos funcionales
propuesta inicialmente por Ivar Jacobson (Jacobson, 1987; Jacobson et al., 1992)
e incorporadas actualmente en UML (OMG, 2003)
No pertenecen estrictamente al enfoque orientado a objetos
Técnica de captura de requisitos
Los casos de uso cubren la carencia existente en métodos previos (OMT, Booch) en
cuanto a la determinación de requisitos
Están basados en el lenguaje natural
Accesibles a los usuarios
Presentan ventajas sobre la descripción meramente textual de los requisitos funcionales
Existen múltiples propuestas para la utilización concreta de los casos de uso como
técnica tanto de obtención como de especificación de los requisitos funcionales
del sistema
Para la descripción concreta de los casos de uso se proponen plantillas, en las que
las interacciones se numeran siguiendo diversas propuestas y se describen
usando lenguaje natural

Ingeniería Web

Casos de uso
CU-<id> <nombre descriptivo>
Versión <nº de la versión actual> (<fecha de la versión actual>)
Autores • <autor de la versión actual> (<organización del autor>)
Plantilla para requisitos funcionales

...
Fuentes • <fuente de la versión actual> (<organización de la fuente>)
...
Objetivos • OBJ-x <nombre del objetivo>
asociados ...
Requisitos • Rx-y <nombre del requisito>
asociados ...
Descripción El sistema debe comportarse tal como se describe en el siguiente caso
de uso {abstracto durante la realización de los siguientes casos de uso:
<lista de casos de uso>, cuando <evento de activación> [o durante la
realización de los siguientes casos de uso: <lista de casos de uso>]}
Precondición <precondición del caso de uso>
Secuencia Paso Acción
normal p1 {El actor <actor>, El sistema} <acción/es realizada/s por
actor/sistema>
p2 Se realiza el caso de uso <caso de uso (RF-x)>
p3 Si <condición>, {el actor <actor>, el sistema} <acción/es
realizada/s por actor/sistema>
p4 Si <condición>, se realiza el caso de uso <caso de uso (RF-x)>
... ...
Poscondición <poscondición del caso de uso>
Excepciones Paso Acción
pi Si <condición excepción>, {el actor <actor>, el sistema}
<acción/es realizada/s por actor/sistema>, a continuación este
caso de uso {continúa, queda sin efecto}
pj Si <condición excepción>, se realiza el caso de uso <caso de
uso (RF-x)>, a continuación este caso de uso {continúa, queda
sin efecto}
... ...
Rendimiento Paso Acción
q m <unidad de tiempo>
... ...
Frecuencia <nº de veces> veces / <unidad de tiempo>
Importancia <importancia del requisito>
Urgencia <urgencia del requisito> (Durán y Bernárdez, 2002)
Estado <estado del requisito>
Estabilidad <estabilidad del requisito>
Comentarios <comentarios adicionales sobre el requisito>


Ingeniería Web

Ingeniería Web

Diagramas de casos de uso

Un diagrama de casos de uso es un grafo de actores, un conjunto
de casos de uso encerrados por los límites de un sistema
(un rectángulo), asociaciones entre los actores y los casos de uso
y relaciones de generalización entre los actores
(Rumbaugh et al., 1999)

Depositar dinero

Actor Caso de uso

Ingeniería Web

nombre del sistema

Cajero automático caso de uso

sacar dinero

cliente transferencias
sistema del banco
actor
depositar dinero
comunicación entre
actor y caso de uso
administración
operador

límite del sistema nombre de caso de uso

Ejemplo de diagrama de casos de uso


Ingeniería Web

Ingeniería Web


Un actor es una idealización de una persona, un proceso o
una entidad externa que interacciona con un sistema,
subsistema o clase
Un actor abstrae y caracteriza a un usuario externo o a un
conjunto de usuarios externos relacionados que
interactúan con el sistema o clasificador
Cada actor define un conjunto de roles que los usuarios
de un sistema asumen cuando interactúan con el mismo
El conjunto completo de actores describe todas las diferentes
formas de comunicación entre los usuarios externos y el sistema

Ingeniería Web


Los actores se representan en UML con el icono estándar de los casos
de uso que es el “stick man” o “monigote” con el nombre del actor al
pie de la figura

Estereotipo de
actor
Cliente

Un actor también se puede representar mediante un símbolo de clase
con el estereotipo «actor»

«actor» Símbolo de clase
Cliente con estereotipo


Ingeniería Web

Ingeniería Web


Puede definirse en una jerarquía de generalización de
actores
Los actores descendientes heredan los roles y las relaciones con
los casos de uso del actor antecesor
Principio de capacidad de sustitución
Tomar
pedido

Vendedor

Generalización de
actores

Establecer
crédito

Supervisor

Ingeniería Web


Un caso de uso es una forma, patrón o ejemplo concreto de utilización,
un escenario que comienza con algún usuario del sistema que inicia
alguna transacción o secuencia de eventos interrelacionados
(Jacobson et al., 1992)

Un caso de uso es una unidad coherente de funcionalidad que proporciona
un clasificador (un sistema, un subsistema o clase) tal como lo manifiestan
las secuencias de mensajes que se intercambian entre el sistema y uno o más
usuarios externos (que se representan como actores), junto con acciones que
realiza el sistema
(Rumbaugh et al., 1999)


Ingeniería Web

Ingeniería Web


En general, las diferentes definiciones pueden catalogarse
en cuatro dimensiones (Cockburn, 1997a; Cockburn,
1997b)
Propósito Dimensión Valor
Contenido Propósito Requisitos funcionales
Pluralidad Contenidos Texto consistente
Estructura Pluralidad Múltiples escenarios por caso de uso
Estructura Semiformal
Enfoque de los casos de uso en UML

Ingeniería Web

El propósito de un caso de uso es definir un cierto comportamiento de
un clasificador sin revelar la estructura interna del clasificador
Cada caso de uso especifica un servicio que proporciona el
clasificador a sus usuarios
Describe una secuencia completa en términos de interacción entre los
usuarios y el clasificador, así como las respuestas ofrecidas por el
clasificador
Los casos de uso incluyen el comportamiento normal que se tiene
como respuesta a una solicitud del usuario
También incluyen las posibles variantes de la secuencia normal
Secuencias alternativas, comportamiento frente a excepciones y manejo de
errores
Un caso de uso es un descriptor que describe un comportamiento
potencial
La ejecución de un caso de uso es una instancia de un caso de uso


Ingeniería Web

Ingeniería Web


Los casos de uso se representan en UML por una elipse
conteniendo el nombre, aunque también puede dibujarse
como un rectángulo clasificador con la palabra reservada
«use case»

«use case»
hacer hacer pedido
pedido

símbolo de clase
caso de uso con estereotipo

Ingeniería Web


Un caso de uso puede participar en varias relaciones, además
de poderse asociar con actores
Relación Función Notación
Asociación Línea de comunicación entre un actor y un caso
de uso en el que participa
Extensión Inserción de comportamiento adicional en un
caso de uso base que no tiene conocimiento «extend»
sobre él
Generalización Una relación entre un caso de uso general y un
de casos de uso caso de uso más específico, que hereda y
añade propiedades al caso de uso base
Inclusión Inserción de comportamiento adicional en un
caso de uso base, que describe explícitamente «include»
la inserción

Tipos de relaciones en los diagramas de
casos de uso


Ingeniería Web

Ingeniería Web


Relación de generalización
Una relación de generalización relaciona un caso de uso especializado
con otro caso de uso más general
El hijo hereda los atributos, operaciones y secuencias de
comportamiento del padre, pudiendo agregar atributos y operaciones
propios
El caso de uso hijo añade comportamiento al caso de uso padre
insertando secuencias de acción adicionales en la secuencia del padre
en puntos arbitrarios
La capacidad de sustitución para los casos de uso significa que la
secuencia de comportamiento de un caso de uso hijo tiene que incluir
la secuencia de comportamiento de su padre
La notación empleada es la del símbolo normal de generalización

Ingeniería Web


Comportamiento de caso de uso para el padre, Verificar identidad
El padre es abstracto, no hay secuencia de comportamiento
Verficar identidad Un descendiente concreto tiene que proporcionar el comportamiento
Comportamiento de caso de uso para el hijo, Comprobar Contraseña
- Obtener la contraseña en BD maestra
- Pedir contraseña al usuario
- El usuario proporciona la contraseña
- Comparar contraseña con entrada del usuario

Comportamiento de caso de uso para el hijo, Explorar retina
Comprobar - Obtener signatura de la retina en BD maestra
Explorar retina
Contraseña - Explorar la retina del usuario y obtener su signatura
- Comparar la signatura maestra con la signatura explorada

Generalización de casos de uso


Ingeniería Web

Ingeniería Web


Relación de extensión
La relación de extensión es una especie de dependencia
El caso de uso cliente añade un comportamiento incremental al caso de uso base mediante la
inserción de secuencias de acción adicionales a la secuencia base
El caso de uso cliente contiene uno o más segmentos separados de secuencia de
comportamiento
La relación de extensión contiene una lista de nombres de puntos de extensión del caso
de uso base
Un punto de extensión representa una localización dentro del caso de uso base donde
se puede insertar la extensión
Una relación de extensión también puede tener asociada una condición
El caso de uso extensor no es necesariamente instanciable por separado
Consiste en uno o más segmentos que describen las secuencias adicionales de comportamiento
Cada segmento en un caso de uso extensor se puede insertar en una localización separada en
el caso de uso base
Cuando la ejecución de una instancia de un caso de uso alcanza una localización en el
caso de uso base referenciada por el punto de extensión y se cumple cualquier
condición en la extensión, entonces la ejecución de la instancia se puede transferir a la
secuencia de comportamiento del segmento correspondiente del caso de uso extensor

Ingeniería Web


Relación de extensión
Se pueden aplicar múltiples relaciones de extensión al mismo caso
de uso base
Un caso de uso extensor puede extender más de un caso de uso
base
Las extensiones pueden ampliar otras extensiones de una manera
jerarquizada
Un caso de uso extensor puede ser él mismo la base en una relación de
extensión, inclusión o generalización
La notación de la relación de extensión es una flecha discontinua
desde el caso de uso extensor al símbolo del caso de uso base con
una punta de flecha apuntando a la base, a la que se añade la
palabra clave «extend»


Ingeniería Web

Ingeniería Web


Condition: {petición de consulta}
Puntos de extensión: posible Caso de uso base para la sesión CA
Condition: {petición de reintegro}
transacción, detalles de recibo
Puntos de extensión: posible transacción, mostrar el anuncio del día
detalles de recibo incluye (identificar cliente) inclusión
incluye (validar cuenta) inclusión
<posible transacción> punto de extensión
imprimir cabecera del recibo
Sesión CA <detalles del recibo> punto de extensión
desconexión
Puntos de extensión
posible transacción
Caso de uso de extensión para la consulta
detalles del recibo
segmento primer segmento
recibir petición de consulta
<<extend>> mostrar información de la consulta
<<extend>>
(posible transacción,
(posible transacción, segmento segundo segmento
detalles del recibo)
detalles del recibo) imprimir la información sobre el reintegro
[petición de reintegro]
[petición de consulta]
Caso de uso de extensión para el reintegro

Reintegro segmento primer segmento
Consulta <<extend>> recibir petición de retirada de efectivo
(petición realizada) especificar cantidad
Puntos de extensión <petición realizada> punto de extensión
[historia sospechosa]
petición realizada
segmento segundo segmento
desembolsar efectivo

Condition: {historia sospechosa} Caso de uso de extensión para la retención de tarjetas
Puntos de extensión: petición realizada Retener tarjeta segmento segmento único
retener tarjeta
terminar la sesión

Extensión de casos de uso

Ingeniería Web

Relación de inclusión
Esta relación denota la inclusión de la secuencia de comportamiento del
caso de uso proveedor en la secuencia de interacción de un caso de uso
cliente, bajo el control del caso de uso cliente, en una localización que
especifique el cliente en su descripción
Se trata de una dependencia, no de una generalización
La instancia de caso de uso está ejecutando el caso de uso cliente
Cuando llega al punto de inclusión, comienza a ejecutar el caso de uso
proveedor hasta que éste finaliza
Después sigue ejecutando el caso de uso cliente más allá de la localización de
la inclusión
El caso de uso incluido no es un clasificador instanciable
independientemente

Universidad de Salamanca. Departamento de Informática y Automática 56


Ingeniería Web

Ingeniería Web

Relación de inclusión
A un mismo caso de uso se le pueden aplicar múltiples relaciones de inclusión
El mismo caso de uso proveedor puede incluirse en múltiples casos base
Las inclusiones se pueden anidar
Una inclusión puede servir como base para otra inclusión, extensión o generalización
posterior
La inclusión representa un comportamiento encapsulado que, potencialmente,
puede ser reutilizado en múltiples casos de uso base
La relación de inclusión posee la propiedad de localización, que se define como
una situación, dentro del cuerpo de la secuencia de comportamiento del caso
de uso base, en que se debe insertar la inclusión
La inclusión es una sentencia explícita situada dentro de la secuencia de
comportamiento del caso de uso base
La notación de la relación de inclusión es una flecha discontinua desde el caso
de uso base hasta el símbolo del caso de uso incluido o proveedor, con una
cabeza de flecha abierta en la inclusión, sobre la que se pone la palabra
reservada «include»

Ingeniería Web


Caso de uso base para la sesión CA

mostrar el anuncio del día
incluye (identificar cliente) inclusión
incluye (validar cuenta) inclusión
imprimir cabecera del recibo
desconexión

Usuario <<include>> Caso de uso incluido para Identificar cliente
Sesión CA
obtener nombre cliente
<<include>> incluye (verificar identidad)
si fracasa la verificación entonces abortar la sesión
obtener los números de cuenta del cliente

Ident ificar cliente
Validar cuenta Caso de uso incluido para Validar cuenta

establecer conexión con la BD de cuentas
obtener estado de cuenta y límites
Inclusión de casos de uso


Ingeniería Web

Ingeniería Web

Realización de casos de uso

Caso de uso Colaboración

«Participa» «Participa»
«Participa»

Objeto Objeto Objeto

Ingeniería Web


Un diagrama de actividad representa el comportamiento mediante un
modelo de flujo de datos y flujo de control
Actividad: especificación de un comportamiento parametrizado que se
expresa como un flujo de ejecución por medio de una secuencia de
unidades subordinadas
Acción: especificación de una unidad fundamental de comportamiento
que representa una transformación o procesamiento
Las acciones están contenidas en actividades que le proporcionan su contexto
Los diagramas de actividad capturan las acciones y sus resultados

Nodo acción Nodo objeto
Nodos de control


Ingeniería Web

Ingeniería Web


Tokens
Vehículos para mover información y eventos a través del sistema. Pueden
transportar objetos o valores
Arcos de actividad
Conexiones dirigidas entre nodos de actividad a través de las cuales fluyen los
tokens
Pueden tener condiciones de guarda para permitir o no el paso de los tokens
Nombre de la actividad Actividad
«precondition» Pedido completo
«postcondition» Pedido cerrado
Parámetro
[rechazado]

[aceptado]

Nodo de parámetro

Ingeniería Web


Particiones de actividad Cliente Ventas Almacén

(swinlanes): Particiones Solicitar producto
utilizadas para identificar acciones
que comparten características Procesar pedido

comunes.
Extraer artículos

Enviar pedido

Recibir pedido Facturar pedido

Pagar factura

Cerrar pedido
Representación de particiones
Multidimensionales


Ingeniería Web

Ingeniería Web


Región de expansión: región que se ejecuta múltiples veces
(concurrent, iterative o streaming) una vez por cada elemento de una
colección de elementos de entrada
Nodos de expansión:
De entrada: flujo de entrada a la región de expansión que contiene una
colección que se divide en elementos individuales dentro de la región
De salida: flujo de salida de la región de expansión que combina los
elementos individuales en una colección que se usa fuera de la región

Nodo de expansión
Región de de entrada
expansión

Nodos de expansión
de salida

Ingeniería Web

Modelado de las interacciones

Interacción: unidad de comportamiento que se centra en el
intercambio de información observable entre elementos que pueden
conectarse
La comunicación se realiza mediante mensajes
Viene dada por un par de conjuntos de trazas
Las interacciones se pueden especializar
Diagramas:
Diagrama de secuencia: hacen hincapié en la secuencia de intercambio de
mensajes entre objetos.
Diagrama de comunicación (colaboración): se centra en las
interacciones y enlaces entre objetos que colaboran
Diagrama de visión global de la interacción: variante del diagrama de
actividad que muestra el flujo de control de la interacción a alto nivel
Diagrama de tiempo: diagrama de interacción que muestra sobre un eje de
tiempo los cambios de estado o condición de una instancia o papel de
clasificador


Ingeniería Web

Ingeniería Web

Diagramas de secuencia
Un diagrama de secuencia representa las interacciones entre objetos
organizadas en una secuencia temporal
Muestra los objetos participantes en la interacción y la secuencia de mensajes
intercambiados
Pueden existir en forma de genérica, describiendo todos los posibles
escenarios, y en forma de instancia (describiendo un escenario real)
Notación
Es un diagrama bidimensional
La dimensión vertical es el eje de tiempos
La dimensión horizontal muestra la línea de vida de los objetos individuales en
la colaboración
Con frecuencia sólo son importantes las secuencias de mensajes, pero en
aplicaciones de tiempo real el eje temporal puede ser una métrica
Una ocurrencia de ejecución muestra el periodo durante el cual un objeto
realiza una acción bien directamente o a través de un procedimiento subordinado
Se representa como una banda vertical

Ingeniería Web


sd Reservas

:Ticket :Cuenta

Crea ( )
:Orden

reserva (fecha,cuenta )
creación cargo (coste)

bono (fecha,cuenta)
mensaje
Llamada recursiva

retorno
Ocurrencia de
ejecución

X destrucción


Ingeniería Web

Ingeniería Web


Fragmentos combinados objetos activos

Encapsulan porciones del emisor intercambio receptor
diagrama de secuencia restricciones a levantar auricular
mensaje
{b-a < 1 seg}
Tienen un operador de
tono de marcado
b
{c-b < 10 seg} loop
interacción que indica como c marcar dígito

se maneja el fragmento comentario
...
mensaje
d encaminar
alt: estructura alternativa La llamada se
encamina por
con duración
d’
opt: comportamiento opcional la red

loop: bucle {d’-d < 5 seg}
tono de llamada suena el teléfono

par: comportamientos paralelos se responde
critical: región crítica
En este punto los
interesados pueden tono de fin deja de sonar
hablar

Diagrama de secuencia con control asíncrono

Ingeniería Web

Diagramas de comunicación
Un diagrama de comunicación muestra cómo las instancias
específicas de las clases trabajan juntas para conseguir un
objetivo común
Implementa las asociaciones del diagrama de clases mediante el paso de
mensajes de un objeto a otro
Sintaxis de la etiqueta del mensaje :
[predecesor] [condición-guarda] [expresión-secuencia] [valor-retorno :=] nombre-
mensaje (argumentos)
Predecesor. lista de números de secuencia separados por comas y seguidos
por ‘/’
La condición de guarda es una expresión booleana encerrada entre
corchetes
La expresión de secuencia es una lista de términos de secuencia separada
por puntos y seguida de ‘:’


Ingeniería Web

Ingeniería Web

Diagramas de colaboración
sd Reservas

pedir(pedido, cliente)
2: coste:=reservar(pedido)

:EncargadoPedidos :BDEntradas
entradas
flujo de mensajes

Solicitante
1: revisarCrédito (cliente) 3: cargarCuenta (cliente, coste)

número de secuencia navegación en
sentido único
crédito

:OficinaCrédito

rol de clasificador

Diagrama de comunicación

Ingeniería Web

Diagramas de visión global de la interacción

Los diagramas de visión global de la interacción (Interaction Overview
Diagrams) son una variante de los diagramas de actividad en los que los
nodos son interacciones u ocurrencias de interacciones
Características de los diagramas de visión global de la interacción:
Para representarlos se utiliza un marco igual que el de cualquier diagrama de
interacción pero el texto de cabecera puede incluir una lista de las líneas de
vida que contiene precedida de la palabra reservada lifelines
Las interacciones u ocurrencias de interacción que contienen sustituyen a los
nodos objeto y se consideran formas especiales de invocación a actividades

Universidad de Salamanca. Departamento de Informática y Automática 70


Ingeniería Web

Ingeniería Web

Diagramas de tiempo

Los diagramas de tiempo (timing diagrams) proporcionan una forma
de mostrar los objetos activos y sus cambios de estado durante sus
interacciones con otros objetos activos y con otros recursos del
sistema

sd UsuarioAceptado
{d..3*d}

EsperandoAcceso
:Usuario

EsperandoTarjeta
TarjetaFuera {t..t+3}
Reposo {0..13}
código OK

SinTarjeta
:Sistema

ConTarjeta
t=ahora
d

0 1 2 t

Ingeniería Web


La vista de máquina de estados describe el comportamiento dinámico de los
objetos a través del tiempo mediante el modelado del ciclo de vida de los objetos
de cada clase
Cada objeto se trata como una entidad aislada que se relaciona con el resto del
mundo a través de la detección de eventos y su respuesta a ellos
Los eventos representan las clases de cambios que un objeto puede detectar
Recepción de llamadas o señales explícitas desde un objeto a otro
Cambio en ciertos valores
Paso del tiempo
Cualquier cosa que pueda afectar a un objeto se puede caracterizar como evento
Un estado es un conjunto de valores de un objeto para una clase dada, que
tienen la misma respuesta cualitativa a los eventos que ocurren
Cuando un objeto detecta un evento responde de diferente forma dependiendo
de su estado. La respuesta puede incluir la ejecución de una acción o un cambio
de estado


Ingeniería Web

Ingeniería Web


Una máquina de estados es un grafo de estados y transiciones que
describe la respuesta de una instancia de un clasificador frente a la
recepción de eventos (Rumbaugh et al., 1999)
Una máquina de estados completa es un estado compuesto que se ha
descompuesto recursivamente para formar subestados
Los estados más internos no poseen subestados

UML define dos tipos de máquinas de estados:
De comportamiento: capturan los ciclos de vida de los objetos,
subsistemas y sistemas
De protocolo: se usan para especificar las transformaciones legales
que pueden ocurrir en un clasificador abstracto como una interfaz o
un puerto

Ingeniería Web


Reposo
Estado: notación Estado: notación
tradicional Reposo con etiqueta

Notaciones utilizadas para representar los estados

X Y

exit / p entry / q
f/d
S T

Resultado efectivo -> f / p; d; q
Estados compuestos


Ingeniería Web

Ingeniería Web


Se permite
Estado inicial bifurcación condicional

Transición al Y
estado inicial [self.tamaño=0]
Z
e/a [else]
X W
entry / b

Equivale a tamaño != 0

Ingeniería Web


Compra Salida anormal
Estado inicial salida/expulsar tarjeta
Referencia de submáquina Estado final
insertar
tarjeta Incluir identificación
Transición de fallo
terminación
Salida normal Menú de selección Acción

Inactivo Seleccionando
elegir (asiento)/añadir a selección(asiento)
pulsar pulsar
“compra” “repetir”
pulsar Confirmando
“cancelar”
Transición pulsar “confirmar”
Transición exterior interior
Vendiendo
entrada/vender()
Acción
atómica
Transición de
finalización

Diagrama de transición de estados con un estado compuesto secuencial


Ingeniería Web

Ingeniería Web


Clase Elegida
Incompleto
laboratorio
laboratorio realizado
realizado
Laboratorio 1 Laboratorio 2

proyecto
Período de realizado
proyecto

aprobado
Prueba final

suspenso

Suspenso Aprobado

Diagrama de transición de estados con un estado compuesto concurrente


UD:INGENIERIA WEB - SESION N°02

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à UD:INGENIERIA WEB - SESION N°02

Similaire à UD:INGENIERIA WEB - SESION N°02 (20)

UD:INGENIERIA WEB - SESION N°02