Ingeniera de Software

RESUMEN DE UML

Universidad de Playa Ancha

Facultad de Ingeniera
Departamento de Informtica y Computacin
Ingeniera Informtica

MODELO DE CASO DE USO

Un modelo de caso de uso describe la funcionalidad propuesta de un nuevo

sistema.
Un caso de uso representa una unidad discreta de interaccin entre un usuario

(humano o mquina) y el sistema.

Esta interaccin es una sola unidad de trabajo significativo, por ejemplo, Crear

Cuenta o Ver los Detalles de la Cuenta.

Cada caso de uso describe la funcionalidad que se construir en el sistema

propuesto, que puede incluir la funcionalidad de otro caso de uso o extender

otro caso de uso con su propio comportamiento.

MODELO DE CASO DE USO

MODELO DE CASO DE USO

Una descripcin general de casos de uso incluye:
Comentarios generales y notas que describen el caso de uso.
Requisitos
Requisitos funcionales formales sobre las cosas que un caso de uso debe

proporcionar al usuario final, tales como <capacidad para actualizar

pedido>.
Estos corresponden a las especificaciones funcionales que se encuentran
en las metodologas estructuradas, y constituyen un contrato que
establece que el caso de uso realiza alguna accin u ofrece algn valor al
sistema.

MODELO DE CASO DE USO

Restricciones reglas formales y limitaciones bajo las que un caso de uso

funciona definicin de lo que puede y no puede hacer.

Estas incluyen:
Pre-Condiciones que debe haber ocurrido antes de que el caso de uso se

ejecute, por ejemplo, <crear pedido> debe preceder a <Modificar pedido>

Post-condiciones que deben darse una vez que el caso de uso es

completado, por ejemplo, <pedido es modificado y es consistente>

Invariantes que deben ser siempre ciertas durante el tiempo que el caso

de uso opera, por ejemplo: un pedido debe tener siempre un nmero de

cliente.

MODELO DE CASO DE USO

Escenarios
Descripciones formales y secuenciales de los pasos tomados para llevar a

cabo el caso de uso, o el flujo de eventos que ocurre durante una instancia
de caso de uso.
Estos pueden incluir escenarios mltiples, para atender circunstancias
excepcionales y caminos alternativos de procesamiento. Estos
generalmente se crean en forma de texto y corresponden a una
representacin textual del diagrama de secuencia.
Diagramas de Escenario Diagramas de secuencia, similares a los escenarios

pero descritos grficamente.

Atributos adicionales, tales como la fase de implementacin, nmero de

versin, complejidad, estereotipo y estado.

ACTORES
Los casos de uso habitualmente se relacionan a actores, que son entidades

humanas o mquinas que usan o interactan con el sistema para ejecutar

una porcin de trabajo significativo que lo ayuda a lograr un propsito.
El conjunto de casos de uso a los que un actor tiene acceso define su rol

general en el sistema y el alcance de su accin.

RELACIONES INCLUDES/EXTENDS ENTRE CASOS DE USO

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su

procesamiento normal.
En general, se asume que el caso de uso incluido se llama cada vez que se

ejecuta el camino bsico. Por ejemplo, cuando se listan una serie de pedidos de
un cliente para seleccionarlos antes de modificar un pedido, el caso de uso
<Listar Pedidos> se debe incluir cada vez que el caso de uso <Modificar Pedido>
es ejecutado.
Un Caso de Uso puede ser incluido por uno o ms casos de uso, esto ayuda a

reducir la duplicacin de funcionalidad al factorizar un comportamiento comn

en los casos de uso que son reutilizados muchas veces.

RELACIONES INCLUDES/EXTENDS ENTRE CASOS DE USO

Un Caso de Uso puede extender el comportamiento de otro, por lo general

cuando se encuentran circunstancias excepcionales.

Por ejemplo, si un usuario debe obtener la aprobacin de alguna autoridad

superior antes de modificar un tipo particular de pedido de cliente, entonces

caso de uso <Obtener Aprobacin> puede extender opcionalmente el caso de
uso normal <Modificar Pedido>.

DIAGRAMAS DE SECUENCIA
Los diagramas de secuencia proporcionan una representacin grfica de la

interaccin de objetos en el tiempo.

Estos generalmente muestran un usuario o actor, y los objetos y componentes

que interactan en la ejecucin de un caso de uso. Un diagrama de secuencia

generalmente representa un escenario nico de un caso de uso o el flujo de
eventos.
Los diagramas de secuencia son una excelente forma de documentar escenarios

de uso y capturar los objetos que se requieren tempranamente en el anlisis y

la verificacin de uso de esos objetos ms tarde en el diseo. Los diagramas
muestran el flujo de mensajes de un objeto a otro, y, como tal, corresponde a
los mtodos y eventos soportados por una clase / objeto.

10

DIAGRAMAS DE SECUENCIA
El siguiente ejemplo de un diagrama de secuencia muestra el usuario o el

agente de la izquierda iniciando un flujo de eventos y mensajes que

corresponde al escenario de un caso de uso. Los mensajes que pasan entre
objetos se convierten en operaciones de clase en el modelo final.

11

DIAGRAMAS DE IMPLEMENTACIN
Un caso de uso es una descripcin formal de la funcionalidad que el sistema

tendr cuando se construya.

Un diagrama de implementacin se asocia generalmente con un caso de uso

para documentar qu elementos de diseo (por ejemplo, componentes y

clases) implementarn la funcionalidad del caso de uso en el nuevo sistema.
Esto proporciona un alto nivel de trazabilidad para el diseador del sistema, el

cliente y el equipo que realmente va a construir el sistema. La lista de casos de

uso de un componente o clase est vinculada a los documentos de la
funcionalidad mnima que debe ser implementada por el componente.

12

DIAGRAMAS DE IMPLEMENTACIN
El ejemplo muestra que el caso de uso Login implementa el requisito formal

1 .01 Iniciar sesin en el sitio web. Tambin muestra que el componente

"lgica empresarial" y "pginas ASP" implementa alguna o toda la
funcionalidad de Login .
Un refinamiento adicional muestra la pantalla Login (una pgina web) como
la implementacin del caso de uso Login . Esta implementacin o link
realize define la trazabilidad desde el requerimiento formal a travs del caso
de uso sobre componentes y pantallas.

13

MODELO DINMICO
El modelo dinmico se utiliza para expresar y modelar el comportamiento del

sistema en el tiempo.
Incluye soporte para diagramas de actividad, diagramas de estado, diagramas

de secuencia y extensiones incluyendo modelado de procesos de negocio.

14

DIAGRAMA DE SECUENCIA
Los diagramas de secuencia se utilizan para mostrar la interaccin entre los usuarios,

pantallas, objetos y entidades del sistema.

Proporciona un mapa secuencial de paso de mensajes entre objetos en el tiempo.
Frecuentemente, estos diagramas se colocan debajo de los Casos de Uso en el modelo

para ilustrar el escenario de caso de uso - cmo un usuario interacta con el sistema y lo
que sucede internamente para hacer el trabajo.
A menudo, los objetos se representan usando iconos especiales estereotipados, como en

el ejemplo a continuacin.
El objeto etiquetado pantalla de Login se muestra mediante el cono de interfaz de

usuario.
El objeto etiquetado SecurityManager se indica mediante el cono de controlador.
El objeto que lleva la etiqueta de users se muestra con el cono de Entidad.
15

ESTEREOTIPOS
Entity Class: clase del dominio del problema
Control Class: clase que media entre clases boundary y clases entity actuando como

conmutador o central entre la capa de presentacin y la de dominio

Boundary or View Class: clase que existe en una frontera de automatizacin, como una

ventana de entrada

16

DIAGRAMA DE SECUENCIA - EJEMPLO

cono
Boundary

17

cono control

cono Entity

DIAGRAMA DE ACTIVIDAD

Los diagramas de actividad se utilizan para mostrar cmo se construyen diferentes flujos de trabajo
en el sistema, cmo se inician y los muchos caminos de decisin posibles que se pueden tomar
desde el principio hasta el final.

Tambin pueden ilustrar donde el procesamiento en paralelo puede ocurrir en la ejecucin de

algunas actividades.

18

DIAGRAMA DE ESTADO
Los diagramas de estado son usados para detallar la transicin o cambios de estado por

los cuales un objeto puede pasar en el sistema.

Ellos muestran como un objeto pasa desde un estado a otro y las reglas que gobiernan
estos cambios.
Los diagramas de estado habitualmente tienen una condicin de inicio y de fin.

19

MODELO LGICO
Un modelo lgico es una visin esttica de los objetos y las clases que

componen el espacio de anlisis/diseo.

Por lo general, un modelo de dominio es una vista ms pobre, una vista de alto

nivel de los objetos de negocio y entidades, mientras que el modelo de clases

es ms riguroso y centrado en el modelo de diseo.

20

MODELO DE CLASES
Una clase es un constructo estndar UML usado para especificar el patrn

desde el cual los objetos debe ser creados en tiempo de ejecucin.

Una clase es una especificacin - un objeto es una instancia de una clase.
Las clases pueden heredar de otras clases (es decir, heredan todo el

comportamiento y el estado de su padre y agregan nuevas funcionalidades de

su propiedad), pueden tener otras clases como atributos, y pueden delegar
responsabilidades a otras clases e implementar interfaces abstractas.

21

MODELO DE CLASES
El modelo de clases es el core del desarrollo orientado a objetos y del diseo

este expresa el estado persistente del sistema y el comportamiento del

sistema.
Una clase encapsula el estado (atributos) y ofrece servicios para manipular ese

estado (comportamiento).
Un buen diseo orientado a objetos limita el acceso directo a los atributos de la

clase y ofrece servicios que los manipulan en representacin del llamador.

Este ocultamiento de datos y exposicin de servicios asegura que la

actualizacin de los datos se realiza en un slo en un lugar y de acuerdo con

reglas especficas - para sistemas grandes la carga de mantencin del cdigo
que tiene acceso directo a los elementos de datos en muchos lugares es
extremadamente alta.
22

MODELO DE CLASES
Note que la clase tiene tres reas diferenciadas:
1.
2.
3.

El nombre de la clase (y estereotipo si se aplica)

El rea de atributos de la clase (elementos de dato internos)
El comportamiento - tanto pblico como privado

Los atributos y mtodos pueden ser:

Private: indicando que no son visibles para llamadas fuera de la clase
Protected: solo son visibles para los hijos de la clase

Public : son visibles para todos

23

HERENCIA
A continuacin se muestra la herencia de clases : una clase abstracta en este

caso, es la clase padre de dos clases hijas, cada una de las cuales hereda las
caractersticas de la clase base y la extiende con su propio comportamiento.

24

MODELO DE CLASES
El modelo de clase puede ser agrupado en paquetes de comportamiento y

estados relacionados.

25

MODELO DE COMPONENTES
El modelo de componentes ilustra los componentes de software que se usarn

para construir el sistema.

Estos pueden ser construido a partir del modelo de clases y escrito desde cero

para el nuevo sistema, o pueden ser trados desde otros proyectos y

proveedores de 3 Parte.
Los componentes son agregaciones de alto nivel de piezas de software ms

pequeas y proporcionan un enfoque de construccin de bloques de black

box (caja negra) para la construccin del software.

26

NOTACION DE COMPONENTES
Un componente puede ser algo as como un ActiveX control - ya sea un control

de interfaz de usuario o un servidor de reglas de negocio.

Los componentes se representan como muestra el siguiente diagrama:

27

DIAGRAMA DE COMPONENTES
El diagrama de componentes muestra la relacin entre los componentes de

software, sus dependencias, comunicacin, ubicacin y otras condiciones.

Interfaces
Los componentes tambin pueden exponer interfaces. Estos son los puntos de

entrada visibles o servicios que un componente est ofreciendo y poniendo a

disposicin de otras clases y componentes de software.
Generalmente, un componente esta compuesto de muchas clases internas y

paquetes de clases. Incluso puede ser ensamblado a partir de una coleccin de

componentes ms pequeos.

28

COMPONENTES Y NODOS
Un diagrama de despliegue muestra la implementacin fsica del sistema

dentro de un entorno de produccin (o de prueba).

Muestra dnde los componentes sern ubicados, en qu servidores, mquinas
o hardware. Puede representar enlaces de red, ancho de banda de la LAN, etc.

29

COMPONENTES Y NODOS
Requisitos
Los componentes pueden tener requisitos adjuntos para indicar sus obligaciones

contractuales - es decir, que servicio proporcionarn en el modelo. Requisitos ayudan a

documentar el comportamiento funcional de los elementos de software.
Restricciones
Los componentes pueden tener restricciones asignadas que indican el entorno en el

que operan.
Pre-condiciones especifican que se debe cumplir antes de que un componente
puede ejecutar alguna funcin.
Post-condiciones indican lo que va a ser cierto despus de un componente ha hecho
algn trabajo
Invariantes especifican lo que debe seguir siendo vlido para la duracin de la vida
til de los componentes.
30

COMPONENTES Y NODOS
Escenarios
Los escenarios son descripciones procedurales/textuales de las acciones de un objeto

en el tiempo y describen la forma en que un componente funciona. Escenarios

mltiples puede ser creado para describir la ruta bsica (ejecucin perfecta), as como
excepciones, errores y otras condiciones.

Trazabilidad
La trazabilidad se puede indicar a travs de link de realizacin.
Un componente puede implementar otro elemento del modelo (por ejemplo, un caso

de uso) o un componente puede ser implementado por otro elemento (ej: un paquete
de clases).
A travs de los link de realizacin desde y hacia los componentes se pueden mapear las

dependencias entre los elementos del modelo y la trazabilidad de los requisitos

iniciales hasta la implementacin final.
31

EJEMPLO

El ejemplo muestra cmo los componentes

pueden estar relacionados para
proporcionar una vista lgico/ conceptual
de la construccin de un sistema.
Este ejemplo tiene que ver con el servidor y
los elementos de seguridad de una tienda
de libros en lnea.
Este incluye elementos tales como, servidor
web, firewall y pginas ASP, etc.

Este diagrama muestra la disposicin de los

componentes del lado del servidor principal
que se requieren para la construccin de
una tienda de libros en lnea.
Estos componentes son una mezcla de
elementos construidos personalizados y
adquiridos, que se ensamblaron para
proporcionar la funcionalidad requerida.

32

COMPONENTES DE SEGURIDAD
El diagrama de componentes de seguridad muestra como SW de

seguridad, tales como la Autoridad Certificadora, el Navegador, el

Servidor Web y otros elementos del modelo trabajan juntos para asegurar
normas de seguridad en el sistema propuesto.

33

MODELO FISICO
El Modelo Fsico/Implementacin ofrece un modelo detallado de la forma en

que los componentes sern implementados a travs de la infraestructura del

sistema.
En l se detallan las capacidades de la red, las especificaciones del servidor, los
requisitos de hardware y otra informacin relacionada con la implementacin
del sistema propuesto.

Deployment View

34

MODELO FISICO
El modelo fsico muestra dnde y cmo los componentes del sistema se

implementarn.
Es un mapa especfico de la disposicin fsica del sistema. Un diagrama
despliegue muestra la implementacin fsico del sistema en un entorno de
produccin (o prueba).
Muestra dnde se ubican los componentes, en qu servidores, mquinas o
hardware. Puede representar los enlaces de red, ancho de banda LAN, etc.

35

REVISAR MS DETALLE EN:

http://www.sparxsystems.com/resources/uml2_tutorial/

36