-
ANLISIS ORIENTADO AL OBJETO CON UML
Las actividades de anlisis son:
1. Identificar el mbito: investigando y documentando las
decisiones qu est fuera y qu dentro del sistema.
2. Identificar los conceptos del dominio claves: investigando y
documentando el vocabulario del negocio en ms detalle. Ayuda a
clarificar algunos de los trminos usados por el cliente, para
asegurar que todos tengan un mismo entendimiento del significado
de estos trminos.
3. Especificar los requerimientos detallados: investigando y
documentando las formas en que el usuario puede interactuar con el
sistema, y cmo este puede afectar el sistema.
4. Examinar el comportamiento de los objetos: investigando y
documentando el comportamiento dinmico de los objetos del negocio
en el sistema.
La salida de la etapa de anlisis consiste de:
1. Modelo de casos de uso del anlisis: compuesto de los casos de
uso de alto nivel y expandido, y de los diagramas correspondientes.
Responde a la pregunta: cules son los procesos del
dominio?.
2. Modelo conceptual: que corresponde al diagrama de estructura
esttica para los conceptos del dominio. Pregunta que responde:
cules son los conceptos, los trminos?.
3. Modelo del comportamiento del sistema: que engloba los
diagramas de secuencia del sistema, y los contratos de las
operaciones del sistema. Cules son los eventos y las operaciones
del
sistema?, qu hacen las operaciones del sistema?.
4. Modelo de estado del anlisis: que rene los diagramas de
estado para los conceptos y casos de uso.
-
Etapa de Planeacin y Elaboracin
(Modelo de casos de uso del anlisis: compuesto de los casos de
uso de alto nivel y expandido, y de
los diagramas correspondientes. Responde a la pregunta: cules
son los procesos del dominio?).
La primera actividad en el desarrollo de un sistema consiste en
definir el mbito del sistema en
estudio. Para llevarla a cabo es necesario:
Identificar los lmites del sistema: el lmite del sistema se
refiere al contexto en que se desarrolla el sistema, estableciendo
qu ocurre dentro de l, qu sucede fuera de l, qu hace y qu
no hace. En lugares donde el mbito no es establecido, los
usuarios y desarrolladores tienen distintas
interpretaciones, lo que atenta con el buen resultado esperado.
Por ende, es muy importante dejar
claro desde un comienzo el real contexto en que se desarrolla el
sistema.
Identificar los usuarios del sistema: stos corresponden a todas
las personas y agentes externos que necesitan interactuar con el
sistema. UML denomina como actor a cada tipo de
usuario. La adecuada identificacin de todos los actores es de
vital importancia pues asegura el que
se hayan capturado todos los requerimientos del sistema.
Identificar y manejar los usos del sistema: conociendo cules son
todos los actores, el paso siguiente es identificar todas y cada
una de las formas en que cada actor puede utilizar el sistema.
La especificacin del comportamiento del sistema puede sufrir de
inconvenientes como:
mbito implcito: la especificacin de requerimientos, a menudo,
asume que el mbito del sistema es ya entendido por todos los
participantes, por lo que se necesita ser establecido
explcitamente. Este sucede no con poca frecuencia, resultando en
sistemas que fallan en entregar la
funcionalidad realmente requerida.
Una definicin muy vaga: requerimientos ligeramente analizados
pueden ser mal entendidos.
Ambigedad y contradicciones: la diversidad y/o complejidad de
requerimientos puede llevar a contradicciones respecto de los
resultados esperados, como tambin llevar a ambigedades,
donde el requerimiento puede ser interpretado en forma distinta
e incorrecta a lo deseado.
Definicin de aspectos errneos: la definicin de los
requerimientos debiera especificar la funcionalidad del sistema, es
decir lo que el sistema debe hacer, no cmo el trabajo debiera
hacerse.
Si bien no es una herramienta creada por UML, la solucin que ste
propone son los casos
de uso. Los casos de uso son una forma de descomponer la
funcionalidad del sistema en partes ms
pequeas, cada una centrada en un uso nico del sistema. Existen
dos alternativas para especificar
los casos de uso de un sistema, una grfica y otra narrativa, las
cuales se complementan entre s.
-
Notacin: Caso de Uso Forma Grfica
Los casos de uso se pueden representar en forma grfica usando la
notacin descrita a
continuacin. Se representa mediante una elipse, y denota un
requerimiento solucionado por el
sistema. Cada caso de uso es una operacin completa desarrollada
por los actores y por el sistema en
un dilogo. El conjunto de casos representa la totalidad de
operaciones desarrolladas por el sistema.
Un caso de uso va acompaado de un nombre significativo.
Ejemplos:
Recibir Dinero Inscribir Asignatura
Figura 2.7: Ejemplo de Casos de Uso
Notacin: Actor
Se representa mediante un smbolo que personifica una persona, y
va acompaado de un
nombre significativo.
Comprador Alumno
Figura 2.8: Ejemplo de Actores
Notacin: Relaciones en un Diagrama de Casos de Uso
Comunica (communicates): relacin entre un actor y un caso de
uso, denota la participacin del actor en el caso de uso
determinado.
Inscribir Asignatura
Alumno
Figura 2.9: Ejemplo de relacin communicates.
Usa (uses): relacin entre dos casos de uso que denota la
inclusin del comportamiento de un escenario en otro.
Matricular Inscribir Asignatura
Figura 2.10: Ejemplo de relacin uses.
-
Extiende (extends): relacin entre dos casos de uso que se aplica
cuando un caso de uso es una especializacin de otro. Por ejemplo,
podra tenerse un caso de uso que extienda la forma
de pago a un cajero, la que podra ser al contado o con
cheque.
Pago al Contado
Pago
Pago con Cheque
Figura 2.11: Ejemplo de relacin extends.
Notacin: Caso de Uso Forma Narrativa
El caso de uso se puede ver como un documento narrativo que
describe la secuencia de
eventos de un actor que utiliza un sistema para completar un
proceso. Los casos de uso son historias
o casos de utilizacin de un sistema; no son exactamente los
requerimientos ni las especificaciones
funcionales, sino que ejemplifican e incluyen los requerimientos
en las historias que narran. El
siguiente ejemplo corresponde a un caso de uso de alto nivel,
que describe clara y concisamente el
proceso de comprar artculos en una tienda cuando se emplea una
caja una caja registradora en el
punto de venta.
Caso de Uso Comprar Productos
Actores Cliente (iniciador), Cajero
Tipo Principal
Descripcin Un Cliente llega a una caja con productos que desea
comprar.
El Cajero registra los productos y obtiene el pago. Al
terminar la transaccin, el Cliente se marcha con los
productos.
La explicacin del formato es:
Caso de uso: nombre del caso de uso.
Actores: lista de actores en la que se indica quin inicia el
caso de uso.
Tipo: que puede ser Primario, Secundario, Opcional, entre
otros.
Descripcin: repeticin del caso de uso de alto nivel o alguna
sntesis similar.
UML no especifica un formato rgido; puede modificarse para
atender las necesidades y
ajustarse al espritu de la documentacin: ante todo, una
combinacin clara.
Conviene comenzar con los casos de uso de alto nivel para lograr
rpidamente entender los
principales procesos globales. Posteriormente, se pasa al
llamado caso de uso expandido para
mostrar ms detalles, para lograr as un conocimiento ms profundo
de los procesos y de los
requerimientos. El caso de uso expandido del caso de uso de alto
nivel Comprar Productos se
entrega en la pgina que sigue.
-
La estructura del formato expandido agrega a la del alto nivel
lo siguiente:
Propsito: intencin del caso de uso.
Referencias Cruzadas: casos de uso y funciones relacionadas con
el sistema.
Curso Normal de los Eventos: es la parte medular del formato
expandido; describe los detalles de la conversin interactiva entre
los actores y el sistema. Un aspecto esencial de la
seccin es explicar la secuencia ms comn de eventos: la historia
normal de las actividades y el
trmino exitoso de un proceso. No incluye situaciones
alternativas.
Cursos Alternativos: describe importantes opciones o excepciones
que pueden presentarse en relacin al curso normal. Si son stas son
complejas, se pueden expandir y convertir en nuevos
casos de uso.
Caso de Uso Comprar Productos
Actores Cliente (iniciador), Cajero
Propsito Capturar una venta y su pago
Tipo Principal y esencial
Descripcin Un Cliente llega a una caja con productos que desea
comprar. El Cajero
registra los productos y obtiene el pago. Al terminar la
transaccin, el
Cliente se marcha con los productos.
Referencias Cruzadas Casos de Uso: el Cajero debe haber
terminado el caso de uso llamado
Registrar
Curso Normal de los Eventos
Accin de los Actores Respuesta del Sistema
1.- Este caso de uso comienza cuando un Cliente
llega a la caja con productos que desea comprar.
2.- El Cajero registra los productos. Si hay ms de
un producto, tambin puede introducir la cantidad.
3.- Determina el precio del producto y agrega la
informacin sobre l a la actual transaccin de venta.
4.- Al terminar el registro de los productos, el
Cajero indica al sistema que termin dicho proceso.
5.- Calcula y presenta el total de la venta.
6.- El Cajero le indica el total al Cliente.
7.- El Cliente escoge la forma de pago:
a) Si paga en efectivo, ver la seccin Pago en Efectivo
b) Si paga con tarjeta con crdito, ver la seccin Pago con
Tarjeta de Crdito
c) Si paga con cheque, ver la seccin Pago con Cheque
8.- Registra la venta terminada.
9.- Actualiza los niveles de inventario.
10.- Genera un recibo.
11.- El Cajero entrega el recibo al cliente.
12.- El Cliente se marcha con los productos
comprados.
Seccin: Pago en Efectivo
Curso Normal de los Eventos
Accin de los Actores Respuesta del Sistema
1.- El Cliente da un pago en efectivo, posiblemente
mayor que el total de la venta.
-
2.- El Cajero registra el efectivo recibido. 3.- Entrega la
diferencia al Cliente.
4.- El cajero guarda el efectivo recibido y saca la
diferencia. Luego, le entrega el vuelto al Cliente.
Cursos Alternativos Seccin Pago en Efectivo
- Lnea 1: el Cliente no tiene suficiente efectivo. Puede
cancelar o iniciar otro mtodo de pago.
- Lnea 4: la caja no tiene suficiente efectivo para pagar la
diferencia. El Cajero pide ms efectivo al supervisor
o le pide al Cliente otro billete de menor valor u otra forma de
pago.
Diagramas de Casos de Uso Ejemplo en Desarrollo
En la figura 2.12 se muestra el diagrama de caso de uso de alto
nivel del sistema; el
rectngulo grande el lmite del sistema; el nombre del sistema
aparece sobre el rectngulo. El cono
de persona representa un actor que es un usuario humano. El cono
rectangular del sistema de
respaldo representa un actor que es otro sistema. El nombre del
actor Sistema de Respaldo est
precedido por un string , el cual es llamado un estereotipo e
indica que el Sistema de
Respaldo es un actor. Este estereotipo y el cono de persona son
equivalentes; sin embargo,
comnmente, el primero se usa para representar sistemas y el
segundo, usuarios humanos. Las
elipses simbolizan casos de uso. Las lneas que conectan actores
y casos de uso indican que los
actores usan o participan en la funcionalidad provista por los
casos de uso. As, esta lnea es llamada
relacin comunica.
Administrar
Recursos
Administrador
de Recursos
Administrar
Proyectos Administrador
de Proyectos
Sistema
Sistema Administrador
de Respaldo
Administrador
del Sistema
Figura 2.12: Diagrama de Caso de Uso a Alto Nivel
Cada caso de uso de se puede detallar en nuevos diagramas del
mismo tipo, para mostrar
mayor profundidad sobre el tema. A continuacin se muestra los
diagramas de casos de uso de dos
de los tres subsistemas de la figura 2.12; en el primer caso
(figura 2.13), el diagrama de caso de uso
Administrar Recursos muestra las diversas funcionalidades que
ste provee; as, los administradores
de recursos pueden agregar, eliminar o actualizar informacin de
habilidades. Dado que una
habilidad debe ser encontrada en la base de datos de sistema
antes de que pueda ser eliminada o
-
actualizada, un caso de uso Actualiza Habilidad es usado. Las
flechas desde los casos de uso
Eliminar Habilidad y Actualizar Habilidad al caso de uso
Encontrar son rotuladas con el estereotipo
uses para indicar que este ltimo es llamado o incluido en los
dos primeros casos de uso anteriores.
Esta flecha es llamada una relacin uses. Tambin se puede ver que
los administradores de recursos
pueden agregar, eliminar y actualizar informacin de recursos, y
en particular, en el ltimo caso
pueden asignar o desasignar una habilidad a un recurso, lo que
se puede hacer usando las
operaciones que aparecen al final de la figura siguiente. Notar
que las flechas llevan el rtulo
extends, para indicar que los casos de uso son opcionales en su
utilizacin (en este caso, se usa uno u
otro, pero no ambas a la vez, de ah la opcionalidad).
Agregar
Habilidad
Eliminar Encontrar
Habilidad Habilidad
Actualizar
Habilidad
Administrador
de Recursos Agregar
Recurso
Eliminar Encontrar
Recurso Recurso
Actualizar
Recurso
Asignar Habilidad Desasignar Habilidad
a Recurso a Recurso
Figura 2.13: Diagrama de Caso de Uso Administrar Recursos
-
La figura 2.14 contiene el diagrama de caso de uso del Sistema
de Administracin.
Restaurar Datos Restaurar Datos
de Recursos de Proyectos
Restaurar
Datos
Sistema
de Inicio
Sistema de
Respaldo Administrador
del Sistema
Eliminar
Recurso
Actualizar
Recurso
Respaldar Datos Respaldar Datos
de Recursos de Proyectos
Figura 2.14: Diagrama de caso de uso del Sistema de
Administracin.
-
Modelo Conceptual Preliminar
(Modelo conceptual: que corresponde al diagrama de estructura
esttica para los conceptos del
dominio. Pregunta que responde: cules son los conceptos, los
trminos?.)
Los actores y casos de uso son definidos para capturar los
requerimientos de un sistema. La
idea del anlisis es traducir dichos requerimientos en un
diagrama de clases inicial, el cual describe
los principales tipos de objetos que existen en el sistema.
Un modelo de clases es un modelo del dominio del problema, que
captura todos los
requerimientos del sistema, este conocimiento es contenido en
las clases, atributos y operaciones de
las mismas, y en las asociaciones entre las mismas clases. En
otras palabras, describen la estructura
esttica de un sistema, o cmo est estructurado ms que cmo se
comporta, conteniendo:
Clases: representan entidades con caractersticas comunes. Estas
caractersticas incluyen atributos, operaciones y asociaciones.
Asociaciones: que simbolizan las relaciones entre dos o ms
clases, donde las
asociaciones tienen caractersticas comunes. Estas caractersticas
incluyen atributos y
operaciones.
En el caso particular de un modelo de clases para la etapa de
anlisis, el diagrama
correspondiente excluye las operaciones y otros elementos, hasta
la etapa de diseo.
No siempre resulta fcil decidir cules clases son requeridas en
el modelo. As, es
recomendable utilizar cierto nmero de heursticas que pueden
guiar el trabajo de definir las clases
necesarias y eliminar las innecesarias.
Cuando se define una clase, se debe identificar sus operaciones
(comportamiento) y los
atributos (datos). Algunos atributos son ms simples que otros;
por ejemplo, el saldo de una cuenta
bancaria es un valor simple, mientras que la lista de transaccin
de la misma cuenta es tan compleja
que seguramente deber ser representada por una segunda
clase.
Los casos de uso son un punto de partida ideal para la
identificacin de las clases. La
descripcin del caso de uso, la del curso normal y la de los
alternativos se pueden utilizar para
identificar cules son las cosas y frases relevantes al quehacer.
As, a modo de ejemplo, si el caso de uso para la compra de
productos tiene la siguiente definicin, probables clases pueden ser
las
cosas que aparecen subrayadas en el texto:
Un cliente llega a la caja con un canasto de productos. El
cajero chequea cada producto. El
precio de cada tem es determinado por el sistema, y el precio de
cada transaccin es presentado al
cliente y registrado. El total es sealado al cliente, quien
realiza el pago, en efectivo o cheque.
Algunos de los nombres subrayados estn duplicados y son
sinnimos, por lo que el paso
siguiente consiste en revisar la lista de nombres y descartar
los superfluos. Para el ejemplo anterior,
producto e tem son identifican el mismo concepto, y dado que
producto es el mejor trmino, tem es
dejado de lado. Por otra parte, hay trminos que estn fuera del
mbito del sistema o no son
relevantes, por lo que tambin deben de quedar fuera. Ejemplo:
canasto no es de importancia, por lo
que se debe dejar de lado.
Tras determinar los conceptos fundamentales a considerar, se
debe proceder a construir el
modelo conceptual del sistema. Para esto, UML provee un gran
nmero de smbolos destinados a
-
apoyar la labor a realizar, parte de la cual se presenta a
continuacin, sealando eso si que se explica
slo lo utilizable en un modelo conceptual, postergando elementos
adicionales para cuando se llegue
a la etapa de diseo.
Notacin: Clase
Las clases se representan por rectngulos con dos divisiones
internas. Cada clase describe un
conjunto de objetos con caractersticas y comportamiento similar.
En las tres partes anteriores se
ubican el nombre de la clase y sus atributos, respectivamente.
Un ejemplo de clase es:
Alumno
Nombre
Edad
Direccin
Notacin: Atributo
Generalmente son de tipos simples, ya que los atributos de tipos
compuestos se representan
mediante asociaciones de composicin con otras clases. La
sintaxis de un atributo es:
nombre = valor_inicial {propiedad}
donde:
nombre: si comienza con minscula se considera un atributo de
objeto.
Notacin: Asociacin (rol, multiplicidad, cualificador)
Una asociacin, en general, es una lnea que une dos o ms smbolos.
Pueden tener varios
tipos de adornos, que definen su semntica y caractersticas. Los
tipos de asociaciones entre clases
presentes en un diagrama de clases son:
Asociacin binaria: se identifica como una lnea slida que une dos
clases. Representa una relacin de algn tipo entre las dos clases,
que no exige dependencia existencial ni
encapsulamiento. Ejemplo:
Compaa Persona
-
Asociacin n-aria: es una forma de expresar una relacin entre
tres o ms clases. Se representa como un diamante del cual salen
lneas de asociacin a las clases. Ejemplo:
Ao
Equipo Jugador
Agregacin: al comienzo de la lnea que simboliza una asociacin se
puede ubicar un rombo que simbolice una asociacin de composicin o
agregacin compuesta (rombo
ennegrecido), lo que ocurre cuando la entidad determina la
existencia de la otra, o bien el
concepto de agregacin compartida (rombo blanco), si los objetos
pueden existir ms all de la
asociacin. Ejemplo:
Empleado Carga
Generalizacin: la relacin de generalizacin denota una relacin de
herencia entre clases. Se representa dibujando un tringulo sin
rellenar en el lado de la superclase. La subclase
hereda todos los atributos y mensajes descritos en la
superclase. Ejemplo:
Persona
Alumno Profesor
Cada asociacin puede presentar algunos elementos adicionales que
dan detalle a la relacin,
como son:
-
Multiplicidad: describe la cardinalidad de la asociacin. Cada
asociacin tiene, en ambos sentidos, una multiplicidad: 1 indica una
ocurrencia; * indica 0 o ms ocurrencias; 1..* seala una
o ms; 1..40 indica de 1 a 40 ocurrencias; 3,5,8 indica que hay 3
5 u 8 ocurrencias . Ejemplo:
1 1..*
Compaa Persona
Nombre: describe el significado de la relacin; se agrega al
nombre una punta de flecha que indica en qu sentido se debe leer la
frase para interpretarla adecuadamente. Ejemplo:
Compaa Persona
Trabaja_para
Rol: identificado como un nombre al final de la lnea, describe
la semntica de la relacin en el sentido indicado. Ejemplo:
empleador empleado
Compaa Persona
Trabaja_para
Atributos: como consecuencia de una relacin puede necesitarse
almacenar cierta informacin de detalle. sta se denota como una
clase relacionada por una lnea punteada a la
relacin. Ejemplo: considerar una relacin entre Muro y Ventana,
la cual tiene como detalle un
objeto de la clase Posicin; cabe notar que este objeto no podra
tomarse como atributo de
ninguna de las clases anteriores, ya que el contexto de su
existencia est dado precisamente por la
relacin entre las dos clases.
Pared Ventana
1 *
Posicin
x : int
y : int
En forma adicional, en algunas ocasiones es necesario describir
que una clase est
relacionada con un objeto de una clase o de otra, pero no de
ambas. Esto se denota por medio de una
relacin or exclusiva. Su representacin es una lnea punteada que
une dos asociaciones, junto con
la aclaracin (por medio de una propiedad) del tipo de asociacin.
Ejemplo: si un automvil tiene un
nico dueo, que puede ser una persona o una empresa, entonces
-
Empresa
Automvil {or}
Persona
Notacin: Restricciones
La asociacin exclusiva del ltimo ejemplo, expresada por el
elemento {or}, es una de las
tantas restricciones que se pueden incorporar en el modelo. El
nmero y tipo de restricciones no es
rgido o limitado, y puede tener tantas posibilidades como lo
requiera el sistema en estudio.
Ciertos autores extienden UML a travs del llamado Lenguaje de
Restricciones sobre
Objetos (OCL, Object Constraint Language), usado para expresar
condiciones atachados a
elementos de modelos. Cuando son incorporados a una clase, estas
expresiones especifican reglas a
los cuales los objetos de la clase deben adherirse. En algunos
casos, cuando la expresin es muy
compleja, se puede usar en su lugar lenguaje natural.
Empleado
edad
sexo
{sexo = hombre edad in [18,65]}
{sexo = mujer edad in [18,60]}
En general, se puede plantear situaciones como:
Cliente Factura Detalle Producto
Emite {ordered} registra
#Cliente {unique}
1 0..5 1 1..20 * 1
para sealar que el nmero de cliente es nico y que los detalles
de una factura deben respetar un
orden entre ellos, y
2..14 corre 1
Atleta 1 subset} gana 1 Carrera
1..14 pierde {or} 1
-
para sealar que un atleta gana o pierde una carrera pero no las
dos posibilidades a la vez, y que
quien gana debe ser alguien que corre la carrera.
Notacin: Observacin (comentario, nota)
Es un comentario dentro de un diagrama, es decir aclaraciones a
ste. Puede estar
relacionado con uno o ms elementos en el diagrama mediante lneas
punteadas. Se representa
mediante un rectngulo con su borde superior derecho doblado.
Modelo Conceptual Ejemplo en Desarrollo
Al construir el modelo conceptual para el sistema de
Administracin de Proyectos, se tiene:
Proyecto
1
1..*
Actividad
1
1..*
* Asignada a 1
Tarea Recurso
Figura 2.14: Diagrama de Clases de Alto Nivel para el SubSistema
de Administracin de Proyectos
-
Habilidad
*
Recurso-Habilidad
*
Recurso
Asalariado Part-time
Figura 2.15: Diagrama de Clases de Alto Nivel para el SubSistema
de Administracin de Recursos
En este ltimo caso, la flecha que relaciona las clases
asalariado y part-time con recurso,
representa una asociacin de generalizacin (o bien, relacin es
un).
Slo por simplicidad, se han omitido los atributos de cada clase.
Sin embargo, normalmente
stos se consideran, como por ejemplo:
PROYECTO
Nombre
Fecha de Inicio
1
1..*
ACTIVIDAD TAREA
NmeroActividad NmeroTarea
FechaInicio FechaInicio
Horas Horas
Figura 2.16: Diagrama de Clases de Alto Nivel para el SubSistema
de Administracin de Recursos
-
Escenarios e Interacciones entre los Objetos
(Modelo del comportamiento del sistema: que engloba los
diagramas de secuencia del sistema, y los
contratos de las operaciones del sistema. Cules son los eventos
y las operaciones del sistema?,
qu hacen las operaciones del sistema?).
Antes de iniciar el diseo lgico de cmo funcionar una aplicacin
de software, es necesario
investigar y definir cmo su comportamiento como una caja negra.
La identificacin del comportamiento de un sistema, a travs de los
llamados escenarios y las interacciones entre los
objetos, es una descripcin de lo que el sistema hace, sin
explicar la manera en que lo hace. Una
parte de la descripcin es son los diagramas de secuencia del
sistema.
Los casos de uso indican cmo los actores interactan con el
sistema que es lo que en
realidad se desea desarrollar. Durante la interaccin, un actor
genera eventos dirigidos a un sistema,
solicitando alguna operacin a cambio. Por ejemplo, cuando un
cajero ingresa el cdigo de barras de
un producto, est diciendo al sistema que registre la compra. Con
el evento se inicia una operacin
del sistema.
Los casos de uso dan descripciones de alto nivel; el modelo
conceptual provee informacin
preliminar de los tipos estticos del sistema. Sin embargo, se
requiere desarrollar un entendimiento
ms detallado del sistema, instanciando casos de uso usando las
clases ya identificadas, e identifi-
cando asociaciones, operaciones y nuevas clases. Esto es
resuelto por los escenarios, cada uno de los
cuales provee una secuencia especfica de interacciones entre los
actores y las entidades en el
sistema, basndose en la secuencia genrica de eventos que define
el caso de uso correspondiente.
As, un escenario es un camino a travs de un caso de uso, una
especie de ejemplo en accin
de un caso de uso; es uno de los muchos caminos posibles a travs
del caso de uso correspondiente
(un caso de uso tiene muchos escenarios). Un escenario es una
elaboracin textual de un caso de
uso, que puede ser representada grficamente mediante los
diagramas que provee UML, los que dan
una descripcin grfica de las interacciones del actor y de las
operaciones que dan origen.
Estos diagramas describen interacciones entre clases. Estas
interacciones son modeladas
como intercambios de mensajes. Estos diagramas se centran sobre
clases y los mensajes que ellas se
intercambian para cumplir algn comportamiento deseado. Los
diagramas de secuencia son un tipo
de diagrama de interaccin.
Los diagramas de interaccin contienen los siguientes
elementos:
Roles de Clases: representan roles que los objetos pueden jugar
en la interaccin.
Lneas de vida: simbolizan la existencia de un objeto sobre un
periodo de tiempo.
Activaciones (o regiones de control): representan el tiempo
durante el cual el objeto estn realizando una operacin.
Mensajes: simbolizan la comunicacin entre objetos.
En general, las acciones se consideran secuenciales o
concurrentes, dependiendo si estn a
diferente o a un mismo nivel respecto de la lnea de tiempo que
se maneje. Tambin est la
posibilidad de realizar iterativamente una misma accin tambin se
puede agregar a un diagrama de
secuencia. Esto se puede hacer de dos formas (alternativas entre
s):
Encerrar en un rectngulo aquel mensaje, con lo cual tanto este
mismo como las secuencias en su interior se repiten hasta que se
cumpla cierta condicin. Una condicin se
-
especifica al final del rectngulo, pero siempre en su interior.
Ejemplo de condicin de trmino es
[No ms tareas].
Establecer una lnea de vida adicional que comienza en el mensaje
que da inicio al ciclo, y que termina con el ltimo mensaje que se
encuentra en dicho ciclo. Tambin se incluye una
condicin de trmino, tal como [Hasta que no hayan ms Tareas].
Diagramas de Secuencia Ejemplo en Desarrollo
La figura 1.19 elabora el caso de uso Asignar Habilidad a
Recurso (de la figura 1.13).
Muestra cmo un administrador de recursos usa el sistema para
asignar una habilidad a un recurso, y
cmo las clases del sistema trabajan juntos para proveer esta
funcionalidad. Los objetos al tope de la
figura representan roles de clases; ellas se denominan as porque
representan los objetos que
participan en la interaccin. Las lneas punteadas que se
extienden desde cada objeto representan
lneas de vida, y los rectngulos ubicados sobre las lneas de vida
representan activaciones. Las
flechas horizontales entre lneas de vida indican los mensajes
intercambiados entre objetos, y son
rotulados con el mensaje que es enviado entre los roles de
clases. Un mensaje dispara una operacin
en el objeto receptor.
Un diagrama de secuencia muestra objetos, no clases. Difiere del
modelo conceptual dado
que ste contiene clases que significan la existencia de objetos.
Si ms de un objeto de una clase en
particular tiene que aparecer en un diagrama de secuencia,
mltiples roles de clases y lneas de vida
son requeridas en el diagrama.
:Administrador :Interfaz :Recurso :Habilidad
:Recurso-Habilidad
de Recursos
Encontrar Recurso
Encontrar Recurso
Por Nombre
Encontrar Habilidad
Encontrar Habilidad por Nombre
Asignar Habilidad
a Recurso [Recurso no tiene asignado la Habilidad]
Asignar Habilidad a Recurso
-
Figura 2.17: Diagrama de Secuencia para el Caso de Uso Asignar
Habilidad a Recurso
Un administrador de recursos usar la ventana del administrador
de recursos, la cual es una interfaz
para encontrar un recurso, encontrar una habilidad y asignar la
habilidad al recurso. Dicha ventana
encontrar un recurso que usa un objeto de la clase Recurso, y
una habilidad que usa un objeto de la
clase Habilidad. La ventana asignar una habilidad a un recurso
si la habilidad no est ya asignada al
recurso. Esta condicin es un guardia y se representa entre
parntesis cuadrados sobre el mensaje
que origina desde la lnea de vida de la ventana al rol de la
clase Recurso-Habilidad.
El siguiente diagrama muestra cmo representa el caso de uso
Eliminar Proyectos.
:Administrador :Interfaz :Proyecto :Actividad :Tarea
de Proyectos
Eliminar Proyecto
Encontrar Proyecto
Por Nombre
Eliminar Actividad por Proyecto
Encontrar Tarea por Actividad
Eliminar Tarea
[Hasta que no hayan Ms Tareas]
Eliminar Actividad
[Hasta que no hayan Ms Actividades]
Eliminar Proyecto
Figura 2.18: Diagrama de Secuencia para el Caso de Uso Eliminar
Proyectos
Contratos
Como se indicara en el captulo anterior, un contrato es un
documento que describe lo que una
operacin se propone lograr. Suele redactarse en un estilo
declarativo, enfatizando lo que suceder y
no cmo se conseguir. Los contratos suelen expresarse a partir de
los cambios de estado de las
-
precondiciones y de las postcondiciones. Puede elaborarse un
contrato para un mtodo de una clase
de software o para una operacin ms global del sistema.
En general, un contrato puede emplearse con una operacin de alto
nivel que se aplica al
sistema entero o con un mtodo de bajo nivel de una clase
particular. Por efectos de tiempo, se tratan
slo stos ltimos.
Para preparar el contrato de un caso de uso :
Identificar las operaciones del sistema a partir de los
diagramas de secuencia.
Elaborar un contrato en cada operacin del sistema.
Comenzar redactando la seccin de Responsabilidades; despus
escribir informalmente el objetivo de la operacin.
Completar, a continuacin, la seccin de PostCondiciones,
describiendo en forma declarativa los cambios de estado de los
objetos del modelo conceptual.
Para describir las postcondiciones, utilizar las siguientes
categoras: creacin y eliminacin de las instancias, modificacin de
los atributos, asociaciones formadas y canceladas.
Un ejemplo de contrato, aplicado a la captura de los datos de
uno de los productos a adquirir
por una persona al momento de comprar es el siguiente.
Nombre Introducir Producto (Cdigo: nmero, cantiad:
nmero)
Responsabilidades Registrar un producto y agregarlo a la
venta.
Desplegar la descripcin y el precio del mismo.
Tipo Referencias Cruzadas
Casos de Uso: Comprar Productos
Notas Utilizar el acceso sper rpido a la base de datos.
Salida Precondiciones El sistema conoce el cdigo del producto.
Postcondiciones Si se trata de una nueva venta, se cre una
instancia de la clase Venta.
Se cre una instancia de la clase Item de Venta.
Se asoci una instancia que vincula el Item de Venta con la
Venta.
Se asign un valor adecuado a Venta.Item de Venta.cantidad.
donde el significado de algunos de los componentes son:
Nombre: de la oepracin y sus (posibles) parmetros.
Responsabilidades: descripcin informal de las responsabilidades
que dbe cumplir la operacin.
Referencias Cruzadas: casos de uso y funciones relacionadas con
el sistema.
Notas: de diseo, algoritmos e informacin afn.
-
Modelamiento de Estados de Anlisis
(Modelo de estado del anlisis: que rene los diagramas de estado
para los conceptos y casos de
uso).
Un evento es un acontecimiento importante o digno de sealarse;
por ejemplo, levantar el
telfono. Un estado es la condicin de un objeto en un momento
determinado: el tiempo que
transcurre entre eventos; un telfono se encuentra en estado
ocioso una vez que el telfono es colgado y no es vuelto a usar.
Una transicin es una relacin entre dos estados; indica que,
cuando ocurre un evento, el
objeto pasa del estado anterior al siguiente. Por ejemplo:
cuando ocurre el evento de levantar el
telfono, el telfono realiza la transicin del estado ocioso al
estado activo.
Un diagrama de estados de UML describe visualmente los estados y
eventos ms interesantes
de un objeto, as como su comportamiento ante un evento. Las
transiciones se muestran con flechas
que llevan el nombre del evento respectivo. Los estados se
colocan en valos. Se acostumbra incluir
un pseudoestado inicial que cumple automticamente la transicin a
otro estado en el momento de
crear una instancia. As, para el caso del telfono:
Descolgar telfono
Ocioso Activo
Colgar telfono
Figura 2.19: Diagrama de Estados para un telfono.
Un diagrama de estados presenta el ciclo de vida de un objeto:
los eventos que le ocurren,
sus transiciones y los estados que median entre esos eventos. No
es necesario que muestre todos los
eventos posibles.
Un diagrama de estados puede aplicarse a varios elementos UML,
como las clases, conceptos
y casos de uso. En particular, para este ltimo caso su aplicacin
consisten en describir la secuencia
permitida de los eventos externos que reconoce y maneja un
sistema dentro del contexto de un caso
de uso. Por ejemplo, en el caso de uso Comprar Productos, no est
permitido efectuar la operacin
Pago con Tarjeta mientras no haya ocurrido el evento
TerminarVenta. El diagrama de estados de
Comprar Productos es:
-
Introducir Producto
En Espera Introduccin
de la Venta de Producto
Introducir Producto
Terminar Venta
Efectuar Pago
En espera del
Pago
Figura 2.20: Diagrama de Estados para el caso de uso Comprar
Productos.
Los diagramas de estado son buenos para describir el
comportamiento de un objeto a travs
de varios casos de uso. No son tan buenos para describir un
comportamiento que involucra cierto
nmero de objetos que colaboran entre ellos. As pues, es til
combinarlos con otras tcnicas. Por
ejemplo, con diagramas de interaccin (de secuencia, de
colaboracin) que describen el
comportamiento de varios objetos en un mismo caso de uso, y con
los diagramas de actividades que
muestran la secuencia general de las acciones de varios objetos
y casos de uso.
Si decide utilizar diagramas de estados, no trate utilizar
diagramas de estado, no hay que
dibujar uno por cada clase del sistema. Se recomienda su
aplicacin slo para aquellas clases que
presenten un comportamiento interesante, cuando la construccin
de los mismos ayude a
comprender lo que sucede. Muchos consideran que los objetos de
interfaz de usuario (GUI) y de
control tienen el tipo de comportamiento que es til describir
mediante estos diagramas.
-
Resumen
El siguiente diagrama resume las asociaciones entre los casos de
uso, modelo conceptual,
escenarios y diagramas de secuencia.
Caso de Uso
puebla
genera muchos
soporta
Escenario Diagrama de Clases
genera uno
soporta
Diagrama de
Secuencia
Figura 2.21: Relacin entre algunos de los diagramas del anlisis
orientado al objeto.
