Y
PATRONES
Introduccién al andlisis y disefio orientado a objetos
CRAIG LARMAN
PRENTICE
HALL UML Y PATRONES
INTRODUCCION AL ANALISIS
Y DISENO ORIENTADO A OBJETOS
CRAIG LARMAN
‘Versién en espafiol:
‘Luz Maria Hendndez Rodriguez
Traductora profesional
Con revisién técnica de:
Ing. Humberto Cardenas Anaya No. de Entrada x
Ditcwor dele Careradengentera en Sistemas Conpuaconaes "5, 3) 95 568 4
Profesor del Departamento de Sistemas de Informacién, =
Instinuo Teenolgico y de Estudios Superiores de Monterrey, Campus Estado de México
PRENTICE ‘ey
HALL ‘Longman
MEXICO + ARGENTINA + BOLIVIA « BRASIL.» COLOMBIA + COSTA RICA + CHILE * ECUADOR
EL SALVADOR + ESPANA + GUATEMALA + HONDURAS « NICARAGUA + PANAMA
PARAGUAY « PERU + PUERTO RICO + REPUBLICA DOMINICANA+ URUGUAY « VENEZUELA
[AMSTERDAM - HARLOW + MIAMI e MUNICH + NUEVA DELH+ MENLO PARK = NUEVA JERSEY
[NUEVA YORK - ONTARIO PARIS »SINGAPUR SYDNEY -TOKIO TORONTO ZURICH
SIBUR Ejemplo de actividades de desarrollo Patrones generales de software para asignar responsabilidades (GRASP)
1, Detitslan | 2 Croat ope | ~ (Patri Descripcién |
= 2Quién asumird la responsabilidad en el caso general?
3. efi 4. Rglsariosminos
| Asignar una responsabilidad al experto en informacién: la clase que posee la informacién necesaria para
ee | eee camp con a eaponsblidad
Pant Snags | aang — Rain rea? ~ |
yy elaboracion -@t prototipo. (de alto nivel y esenciaies)|
od 2 Asignar a la clase B la responsabilidad de crear una instancia de clase A, si se cumple una de las si-
iene omaione:
Tiamat | outa wien || ete —
contene sistraA
pened eared ee sbbnsp-meok 4 Becntine 5. Buti A muy de crea
eC
aiteraiognr ap F Contador {Rilnaininisra mn ent el stoma?
‘Asignar la eesponsabilidad de administrar un mensaje de eventos del sistema a una clase que represente
tuna de las siguientes opciones:
1, EI negocio o a organizacion global (un controlador de fachada)
2. El “sistema” global (un controlador de fachada).
3. Un ser animado del dominio que realice el trabajo (un controlador de papeles).
44. Una clase artificial (Fabricacion Pura) que represente el caso de uso (un controlador de casos de uso).
Bajo Acoplamiento | ;Cémo dar soporte a poca dependencia y a una mayor reutlizaciin?
(evaluativo) |
Asignar las responsabilidades de modo que se mantenga bajo acoplamiento.
{Como mantener controlable la complejidad?
[Asignar las responsabilidades de modo que se mantenga una alta cohesion?
2Quién, cudndo el comportamiento varia sequin el tipo?
Cuando varia el tipo (clase) de alternativas o comportamientos relacionados, asignar la responsabilidad
del comportamiento —mediante operaciones polimérficas— a los tipos en que varia el comportamiento
Fabricacin Pura | - : Desde el punto de vista del andlisis y del disefio orientados a objetos, esta activi-
. ; oe dad se parece al disefio orientado a objetos que pone de relieve la asignacién
15.3 ¢Cudles son los papeles o las funciones en la organizacion? de responsabilidades. La asignacion significa distribuir las funciones y las respon-
sabilidades entre varios objetos de software en la aplicacién, del mismo modo que
El siguiente paso consiste en identificar los papeles de las personas que intervendran se asignan a los papeles de los empleados. Los objetos de software normalmente
en los procesos: cliente, representante de ventas, ingeniero de software, etcétera colaboran o interactian para cumplir con sus responsabilidades, como lo hacen las
En la perspectiva del andlisis y del disefio orientados a objetos, este paso nos recuerda emma
al andlisis del dominio orientado a objetos que expresamos con un modelo con- La descripcién de la asignacién de las responsabilidades y las interacciones de objetos
ceptual, Este modelo presenta las diversas categorias de las cosas en el dominio; no a menudo se expresan grificamente con diagramas de disefio de clase y con dia-
solo los papeles de las personas sino también todas las cosas de interés, sey gramas de colaboracién; unos y otros muestran la definicién de clases y el flujo de
observa en la figura 1.4. mensajes entre los objetos de software. 1 ANALISIS ¥ DISESO ORIENTADOS A ORJETOS 1 - ANALISIS Y DISERO ORIENTADOS A ORJETOS
z z a Por ejemplo, en el juego de dados el caso de uso de Juega un Juego,
ieee |
a | | rie bak d ! Caso de uso: Juega un Juego.
: = - | Participantes: Jugador.
2Cuales son los ‘Anilisis de ea ;
procesos del negocio? requerimientos Casos de uso Descripeién: Este caso de uso comienza cuando el
jugador recoge y hace rodar los dados.
{Cuales son los papeles de Silos puntos suman siete, gana y
los empleados? Analisis del dominio Modelo conceptual pierde si suman cualquier otro
~ = — — niamero.
2Qué funciones cumplen los | Asignacion de Diagramas de diseno de
leados? 2cémo nsabilidades, clases, diagramas d pane
imeractan eos? diseho de interacclones | colaboracion .6.2 — Definicién de un modelo conceptual
anilisis orientado a objetos tiene por finalidad estipular una especificacién del
. . dominio del problema y los requerimientos desde la perspectiva de la clasifics por
1.6 Un ejemplo del andlisis y del disefio orientados a objetos objetos y desde el punto de vista de entender los términos empleados en el dominio,
Para descomponer el dominio del problema hay que identificar los conceptos, los
atributos y las asociaciones del dominio que se juzgan importantes. El resultado
ecesita abundante informacion para explicar cabalmente el puede expresarse en un modelo conceptual, el cual se muestra graficamente en un
grupo de diagramas que describen los conceptos (objetos).
Un simple ejemplo Se
nos permite ver todo anélisis y el diseto orientados a objetos. Para no perdernos en
el panorama, muchos detalles, ofrecemos al lector una explicacién sucinta
sobre algunos de los pasos y diagramas usando para ello un
‘ejemplo simple: un “juego de dados” en que un jugador lanza dos
dados. Si el total es siete, gana y de lo contrario pierde,
Las notaciones utilizadas forman parte del lenguaje UML.
Observe, por favor, que en el ejemplo no estan representados todos los pasos posibles
ni los diagramas; tan s6lo aparecen los mas comunes y esenciales. Por ejemplo, como se aprecia en la figura 1.5, en el dominio del juego de dados, una
parte del modelo conceptual muestra los conceptos Jugador, Dados y JuegodeDados,
1.6.1 Definicidn de los casos de uso sus asociaciones y atributos.
Para entender los requerimientos se necesita, en parte, conocer los procesos del dominio -—— —
yeel ambiente externo, 0 sca los factores externos que participan en los procesos. Dichos [agar ones Dados
procesos de dominio pueden expresarse en casos de uso, o sea, en descripciones narta- a ‘valorMostraco
tivas de los procesos del dominio en un formato estructurado de prosa, ; L >
J sce |
1
Detar ete pamiss| |
Defi os casos
el modo Jos diag iagremas de JuegodeDados
moet 2 | e oe ep
os casos de uso no son propiamente un elemento del andlisis orientado a objetos; se Figura 1.5 Modelo conceptual del juego de dados.
limitan a describir procesos y pueden ser igualmente eficaces en un proyecto de tec-
nologia no orientada a objetos. No obstante, constituyen un paso preliminar muy wil El modelo conceptual no es una descripcién de los componentes del software; repre-
porque describen las especificaciones de un sistema, senta los conceptos en e! dominio del problema en el mundo real
10 4 - 1.6.3
1 ANALISIS ¥ DISENO ORIENTADOS A OBJETOS
Definicién de los diagramas de colaboracién
E] disefio orientado a objetos tiene por objeto definir las especificaciones légicas del
software que cumplan con los requisitos funcionales, baséndose en la descomposicion
por clases de objetos. Un paso esencial de esta fase es la asignacién de responsabi-
lidades entre los objetos y mostrar como interactian a través de mensajes, expresados
en diagramas de colaboracién. Estos presentan el flujo de mensajes entre las ins-
tancias y la invocacién de métodos.
1 ANALISIS ¥ DISENO ORIENTADOS A ORJETOS
Por ejemplo, en el juego de dados, al examinar el diagrama de colaboracién, obtene-
‘mos el siguiente diagrama del disefio de clases. Puesto que tn mensaje juego se envia
a una instancia Jugador, Jugador requiere un método jugar, mientras que Dado
requiere un método lanzar.
A diferencia del modelo conceptual, este diagrama no muestra gréficamente concep-
tos del mundo real; describe inicamente los componentes del software.
Para indicar de qué manera los objetos se conectan entre sia través de atributos, una
linea con una flecha en la punta indicara un atributo. Por ejemplo, JuegodeDados posee
un atributo que apunta a una instancia de un Jugador.
Por ejemplo, supongamos que se desea una simulacién en el software del juego de
dados, El diagrama de colaboracién de la figura 1.6 muestra graficamente el paso
esencial del juego, enviando mensajes a las instancias de las clases Jugador y Dado. Jugador Dado
nombre, i Laren 2] waerMoatrado
- | veer ents Jugar() Janzar()
poet == pegey | tert it — (pirea / a
— 2
og
2aselana) — 1
12:bada
ogodedade
inte
Figura 1.6 Diagrama de colaboracién que muestra los mensajes entre lot obetos
ccootwne vaalzar)
1.6.4 Definicién del disefio de clases Figura 1.7 Diagrama del disefio de clases para los componentes de software.
El diagrama del disefio de clases de la figura 1.7 no esta completo; representa tinica-
mente el inicio de las especificaciones del software que se requieren para definir
cabalmente cada clase.
Para definir una clase es preciso contestar varias preguntas:
= .Cémo se conectan unos objetos a otros?
‘= | expands Be
> 83s
os Ge gon
Presupueso, james da Lae
‘rogram ‘te os tse Se jr?
BE 28g
PEEEEE EEE EEE EEE aks
1 Wega Qe cee
eee — gE BE
Dependenciarespecto a aeeSteet OWES
fs ‘losario a 8
Figura 3.2 Influencia de los artefactos en l fase de planeacién y de elaboracién,
1 Sise creaun artefacto que no tenga otros dependientes y si no se usa como entrada de otra
cosa, habré que poner en tela de jucio su valor yel tiempo que se dedicé a su creacién.
cee parte! FASE DE
PLANEACION Y
DE ELABORACION CASO DE ESTUDIO: EL PUNTO
DE VENTA
Objetivos
= Definir el caso de estudio que se emplea en el libro.
1 El sistema del punto de venta
‘Nuestro principal caso de estudio es el sistema de una terminal (POST) de punto de venta.’
Esta terminal es un sistema computarizado con el que se registran las ventas y se realizan
Jos pagos; normalmente se utiliza en las tiendas al detalle. Abarca componentes de hard-
‘ware (una computadora yun lector de cédigo de barras)y software para correr el sistema,
‘Suponga que se nos ha pedido crear un programa para una terminal de punto de
venta. Con una estrategia de desarrollo de incremento iterativo, vamos a realizar las
fases de requerimientos, andlisis y disefio orientados a objetos e implementacién.
>
Figura 4.1 Terminal de punto de venta,
1 Unproblema también examinado en [Coad95], aunque este trabajo se llevé a cabo de manera
independiente y mucho antes que el otro.
35___ 4 CASO DE ESTUDIO: EL PUNTO DE VENTA
¢Por qué escogimos este problema? Por ser representativo de muchos sistemas de
informacién y porque toca problemas comunes que puede encontrar un desarrollador.
Ahondaremos lo suficiente en el andlisis y en el disefto, para que el lector vea en forma
detallada cémo se abordan estos problemas y pueda aplicar el método a otros proyectos.
4.2 Capas arquitecténicas y el énfasis en el caso de estudio
Un sistema tipico de informacion que incluya una intertaz grafica del usuario y acceso
ala base de datos suele presentar un diseiio arquitectinico de varios niveles 0 capas
(figura 4.2) como las siguient
= Presentacién: interfaz gréfica; ventanas.
= Légica de aplicacién - Objetos del dominio del problema: objetos que repre-
sentan conceptos del dominio (os objetos de ventas, por ejemplo) que cumplen
con los requisitos de aplicacién.
= Légica de aplicacién - Objetos de servicio: objetos de dominio no relaciona-
dos con el problema que prestan servicios de soporte: por ejemplo, interfaz con
luna base de datos,
= Almacenamiento: un mecanismo persistente de almacenamiento; por ejemplo
una base de datos relacional u orientada a objetos.
| eranasixy dicho oietados objeto generalente son més les para moda
los niveles logicos de la aplicacion.
- —__|
Estudiaremos en el capitulo 22 el tema de una arquitectura de capas (o niveles).
El caso de estudio del punto de venta destaca principalmente los objetos del dominio
del problema, asignéndoles responsabilidades para cumplir con los requisitos de la
aplicacién. En el capitulo 38 nos serviremos del disefto orientado a objetos para crear
un conjunto de objetos del nivel de servicio para conectarnos con una base de datos.
En este método de disefio, la capa de presentacién tiene muy poca responsabilidad; se
dice que es delgada. Las ventanas no contienen un codigo que se encargue de la légica
© procesamiento de la aplicacién. Por el contrario, las solicitudes de tarea se envian al
dominio del problema y a las capas de servicio.
43 Nuestra estrategia: aprendizaje y desarrollo iterativos
Este libro esté organizado para seguir una estrategia de desarrollo iterativo. El andlisis
y el diseno orientados a objetos se aplican al sistema del punto de venta en dos ciclos
de desarrollo iterativo en que el primer ciclo se destina a una simple aplicacién de las
funciones basicas. El segundo amplia la funcionalidad del sistema (véase la figura 4.3).
36
4 CASO DE ESTUDIO: FI. PUNTO DE VENTA
Presentacién
punto menor expicar como Mh
‘onectarse a otras capas
Ee
Logica de aplicacion
-objetos del dominio fer | | ‘punto primaio »
‘el prob icceesamen |g etic” ater __alcaso de estusio
punto secundario
Gelcaso.deestudio |
Eniaprinea gran BY
Secon dl bro 80 | Se expican mas
| hablidades do
Figura 4.3 Ruta de aprendizaje que siguen los ciclos de desarrollo.
3. 4 CASO DF RSTUDIO: EL PUNTO DE VENTA
Ademis del desarrollo iterativo, también se expone de manera iterativa la presentacién
de los temas del andlisis y el disefio orientados a objetos, la notacién de UML y los
patrones. En el primer ciclo de desarrollo del sistema del punto de venta, se describe
un grupo basico de temas de andlisis y de disefio, asi como la notacién. El segundo
ciclo se expande y ofrece nuevas ideas, la notacién de UML y los patrones.
Esta estrategia tiene por objeto proponer un modelo de aprendizaje “justo a tiempo”,
EI modelo procura explicar primero las ideas de mayor uso, lo més cerca posible del
‘momento en que el lector perciba la necesidad de aprenderlos para poder continuar.
Al principio, el libro se centra en las ideas y habilidades fundamentales, sin saturarlo
‘con nueva informacién que no pueda aplicar de inmediato. Después se explican las
habilidades e ideas que se utilizan més raramente.
1
CONOCIMIENTO DE LOS
REQUERIMIENTOS
Objetivos
= Crear los artefactos de la fase de requerimientos; por ejemplo, las especifica-
ciones de funciones,
Identificar y clasificar las funciones del sistema
Identificar y clasificar los atributos del sistema y relacionarlos con las fun-
ciones.
Introduccién
Un proyecto no puede ser exitoso sin una especificacién correcta y exhaustiva de los,
requerimientos. Para ello se necesitan muchas habilidades; un examen riguroso de
cllas rebasa el Ambito de este libro, pues nuestro objetivo es que el lector domine el
andlisis y el disefio orientados a objetos. Pero se ofrece una introduccidn a los reque-
rimientos de la aplicacién punto de venta, porque en Ia practica es un paso decisivo, y
se mencionan otros artefactos relacionados con la fase de requerimientos, No duda-
mos en recomendar Exploring Requirements: Quality Before Design [GW89], obra que
se centra en las habilidades necesarias para dilucidar los requerimientos importantes.
Este capitulo se propone lograr que el lector pueda expresar los requerimientos, no en
convertirlo en un experto en el dominio de los sistemas de terminales para tiendas y
puntos de venta, Por eso, la lista de las funciones y atributos del sistema no es exhaus-
tiva, sino representativa. 5 - CONOCIMIENTO DE LOS REQUERIMIENTOS
notes
a. constante
opeonat
© aplazable
onsen
Actividades dela fase de planeacién y elaboracién,
~—
invorme | Especticacones
prliminar do de requerimentos
mwestgacion < z
(asos de uso:
1. todos de allo nivel
». aigunos esencialos
Protaipos
expandidos
Prosupuesto, ~~ Diagiamas de
Programa cease do Us0
Models conceptual — |
mS prolminar
Dependencia respecte a
y Giosario
Dependencias de los artefactos respecto a la fase de planeacién y elaboracion.
52
21
ps
5 - CONOCIMIENTO DE LOS REQUERIMIENTOS
Ninguno de los artefactos que se describen en la presente seccién son propios del
Ienguaje UML; se trata simplemente de documentos comunes de la fase de reque-
rimientos.
Los requerimientos
Los requerimientos son una descripcién de las necesidades o deseos de un pro-
ducto, La meta primaria de a fase de requerimientos es identificar y documentar lo
que en realidad se necesita, en una forma que claramente se lo comunique al cliente y
a los miembros del equipo de desarrollo. El reto consiste en definirlos de manera
inequivoca, de modo que se detecten los riesgos y no se presenten sorpresas al
momento de entregar el producto,
Se recomiendan los siguientes artefactos en la fase de requerimientos:
= panorama general
= clientes
a metas
= funciones del sistema
= atributos del sistema
Otros documentos pertinentes, que por cierto no examinaremos en el libro, se men:
cionan al final del capitulo.
Integracién de las piezas del rampecabezas
En nuestro caso de estudio, la definicién de los requerimientos aparece muy clara ¥
tajante: la realidad dista mucho de serlo. Por lo regular hay que reunir y asimilar
muchos estudios y documentos electrénicos, analizar los resultados de las entrevistas,
celebrar reuniones para definir los requerimientos en grupo, etcétera
Presentacion general
Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que
se utilizaré en las ventas al menudeo.
Clientes
ObjectStore, Inc., detallista multinacional de objetos.
41 5.5
5.6
5.6.1
42
5 - CoNOCTATENTO DE LOS REQUERIMIENTOS
Metas
En términos generales, la meta es una mayor automatizacién del pago en las cajas
registradoras, dar soporte a servicios mas répidos, més baratos y mejores y a los pro-
esos dle negocios. Mas concretamente, la meta incluye:
= Pago répido de los clientes.
= Audlisis rapido y exact de las ventas.
= Control automatico del inventario.
Funciones del sistema
Las funciones del sistema son lo que éste habra de hacer, por ejemplo autorizar los
pagos a crédito. Hay que identificarlas y listarlas en grupos cohesivos y légicos.
Con el objeto de verificar que algin X es de verdad una funcién del sistema, la
siguiente oracion deberd tener sentido:
El sistema deberd hacer .
Por ejemplo: El sistema deberé autorizar los pagos a crédito.
En cambio, los atributos del sistema son cualidades no funcionales —entre ellas la
facitidad de uso— que a menudo se confunden con las funciones. Notese que “faci
lidad de uso” no encaja en la oracién de verificacién: El sistema deberd hacer la facitidad
de uso. Los atributos no deben formar parte del documento de las especificaciones
funcionales del sistema, sino de un documento independiente que especifica sus
atributos,
Categorias de las funciones
Las funciones, como autorizar pagos a crédito, han de clasificarse a fin de establecer
prioridades entre ellas e identificar las que de lo contrario pasarian inadvertidas (pero
que consumen tiempo y otros recursos). Las categorias son:
3.6.2
5- CoNOCIIMENTO DE LOS REQUERIMIENTOS
Evidente Debe realizarse, y el usuario deberia saber que se ha
realizado.
Oculta Debe realizarse, aunque no es visible para los usuarios.
Esto se aplica a muchos servicios técnicos subyacentes,
como guardar informacion en un mecanismo persis-
tente de almacenamiento. Las funciones ocultas a
menudo se omiten (erréneamente) durante el proceso
de obtencién de los requerimientos.
onan
Superflua COpcionales; su inclusién no repercute significativa-
mente en el costo ni en otras funciones,
Funciones basicas
Las siguientes funciones del sistema en la aplicacién de la terminal del punto de venta son
luna muestra representativa; no pretenden en absoluto ser exhaustivas. Nuestro objetivo
es entender los detalles del analisis y del disefio, no el funcionamiento de una tienda,
| Registra la venta en proceso (actual): los productos | evidente
comprados.
R12 Calcula el total de la venta actual; se incluyen el evidente
impuesto y los calculos de cupén.
R13 Captura la informacién sobre el objeto comprado evidente
usando su cédigo de barras y un lector 0 usando una
| ‘captura manual de un cédigo del producto; por ejemplo,
tn cédigo universal de producto (UPC).
Ria Reduce las cantidades del inventario cuando se realiza_| oculta
una venta
R15 | Seregistran las ventas efectuadas. oculta
R16 El cajero debe introducir una identificacién y una con- | evidente
trasefia para poder utilizar el sistema.
RL (Ofrece un mecanismo de almacenamiento persistente. | oculta 5.6.3
5.7
'5- CONOCIMIENTO DE LOS REQUERIMIENTOS
Ref # Funcién | Categoria |
R18 Ofrece mecanismos de comunicacién entre los procesos | oculta
yentre los sistemas,
[Rig | Muestra la descripcion y el precio del producto |
registrado,
evidente
Funciones de pago
Ref # Funcion Categoria
R21 ‘Maneja los pagos en efectivo, capturando la cantidad | evidente |
ofrecida y calculando el saldo deudor. i
R22 ‘Maneja los pagos a crédito, capturando la informacion | evidente
| crediticia a partir de una lectora de tarjetas o mediante
captura manual, y autorizando los pagos con el servicio
de autorizacién (externa) de créditos de la tienda a |
través de una conexién por modem.
R23 Maneja los pagos con cheque, capturando la licenci
de conducir mediante captura manual, y autorizando
los pagos con el servicio de autorizacién (externa)
de cheques de la tienda a través de la conexion por
modem.
pt
R24 Registra los pagos en el sistema de cuentas por cobrar, oculta
pues el servicio de autorizacion de crédito debe a la
tienda el monto del pago.
evidente
Atributos del sistema
Los atributos del sistema son sus caracteristicas o dimensiones; no son funciones. Por
ejemplo:
facilidad de uso tolerancia a las fallas tiempo de respuesta
metifora de interfaz —_< costo al detalle plataformas
Los atributos del sistema pueden abarcar todas las funciones (por ejemplo, la plataforma
del sistema operative) o ser especificos de una funcién o grupo de funciones.
5 - CONOCIMIENTO DE LOS REQUERIMIENTOS.
Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden
ser valores discretos, confusos o simbélicos; por ejemplo:
tiempo de respues
Jcolégicamente correcto)
metafora de interfaz = (grafico, colorido, basado en formas)
Algunos atributos del sistema también pueden tener restricciones de frontera del
atributo, que son condiciones obligatorias de frontera, generalmente en un rango
numérico de los valores de un atributo; por ejemplo:
tiempo de respuesta = (cinco segundos como maximo)
He aqui algunos ejemplos mas:
Atributo Detalles y restricciones de frontera
tiempo de respuesta (restriccion de frontera) Cuando se registre un pro-
ducto vendido, la descripcién y el precio apareceran
en cinco segundos. |
metafora de interfaz (detalle) Ventanas orientadas a la metafora de una
forma y cuadros de dislogo.
(detalle) maximiza una navegacién facil con teclado
y no con apuntadores
tolerancia a fallas (restriccién de frontera) debe registrar los pagos a
crédito autorizados que se hagan a las cuentas por
cobrar en un plazo de 24 horas, aun cuando se
produzcan fallas de energia 0 del equipo.
plataformas del sistema _| (detalle) Microsoft Windows 95 y NT.
operativo
Atributos del sistema en las especificaciones de funciones
Conviene deseribir todos los atributos del sistema que se relacionen claramente con
las funciones dentro de la lista en que se especifican estas iiltimas. Ademés, los
detalles de los atributos y las restricciones de frontera pueden catalogarse como obli-
gatorios w opcionales.'
1 Una restriccién de frontera suele ser obligatoria, pues de lo contrario significaria que no era
sélida, 5 CONOCIMIENTO DE LOS REQUERIMTENTOS
R19 | Mostrar la descripcién yl pre- | evidente | tiempo de | 5 segundos como obliga-
cio del producto registrado. respuesta | maximo torio
metafora_ | pantallas basadas en | obliga-
de interfaz | formas torio
colorido: | opcional
R24 | Registrar los pagos a crédito en | oculto | tolerancia | debe registrar en las | obliga-
el sistema de cuentas por a fallas cuentas por cobrar en | torio
cobrar, pues el servicio de auto- un plazo de 24 horas,
rizacién de crédito debe a la aun cuando se produ:
tienda el importe del pago. can falas de energia
© del equipo
tiempo de | 10segundos como | obliga-
respuesta | maximo torio
5.8 Otros artefactos en la fase de los requerimientos
CASOS DE USO:
DESCRIPCION DE PROCESOS
Objetivos
= Identificar y escribir casos de uso.
= Disefiar diagramas de casos de uso.
En este libro se da una introduccién muy sucinta a los requerimientos; es un tema que
bien podria abarcar libros enteros. Las funciones y los atributos del sistema son los
documentos minimos de los requerimientos, de modo que se necesitan otros artefac-
tos importantes para atenuar el riesgo y entender el problema, a saber:
= Requerimientos y equipos de enlace: lista de los que deberian participar en la espe-
cificacién de las funciones y atributos del sistema, en la realizacién de entrevistas,
de pruebas, de negociaciones y de otras actividades.
= Grupos afectados: ios que reciben el impacto del desarrollo o aplicacién del
sistema.
= Suposiciones: las cosas cuya verdad se supone.
m= Riesgos: las cosas que pueden ocasionar el fracaso 0 retraso,
= Dependencias: otras personas, sistemas y productos de los cuales no puede
prescindir el proyecto para su terminacién.
= Glosario: definicién de los términos pertinentes; tema que se estudiar en capitu-
los subsecuentes.
= Casos de uso: descripciones narrativas de los procesos del dominio; tema que se
vera en capitulos posteriores.
= Modelo conceptual preliminar: modelo de conceptos importantes y de sus rela-
ciones; tema que se tratard en capitulos posteriores,
m= Contrastar los casos de uso de alto nivel con los expandidos.
m= Contrastar los casos de uso esenciales con los reales.
Introduccién
Una técnica excelente que permite mejorar la comprensién de los requerimientos es
la creacién de casos de uso, es decir, descripciones narrativas de los procesos del
dominio. En este capitulo se exponen los conceptos basicos de esta técnica y se dan
ejemplos para aplicarlos a la terminal de punto de venta.
En el siguiente capitulo clasificaremos los casos de uso y escogeremos los que utiliza-
remos en el primer ciclo de desarrollo.
EI UML incluye formalmente el concepto de casos de uso y sus diagramas de uso. {6 CASOS DE USO: DESCRIPCION DE PROCESOS
Notas
‘a.consiane MA
» epsional
© aplazable
4. orden variable
Actividades de la fase de planeacion y elaboracién,
Intorme | Especicaciones
prelimnar do io roquermientos
investigacén ———
Casas de uso:
Protest 2.10008 de alto nivel
algunos esonciales
cexpansidos
resupuesto, ~ Diegremas de
programa cases uso
| Mosel cononival
relma’
.
Dependencia respecto a
a Gosario
Dependencias de los artefactos respecto a la fase de planeacién y elaboracién.
48
6 - CASOS DE USO: DESCRIPCION DE PROCESOS
Actividades y dependencias
Los casos de uso requieren tener al menos un conocimiento parcial de los reque-
rimientos del sistema, en teoria expresados en el documento donde se especifican,
Casos de uso
El caso de uso es un documento narrativo que describe la secuencia de eventos de
un actor (agente externo) que utiliza un sistema para completar un proceso [Jacob-
son92]. Los casos de uso son historias 0 casos de utilizacién de un sistema; no son
exactamente los requerimientos ni las especificaciones funcionales, sino que ejempli-
fican e incluyen tacitamente los requerimientos en las historias que narran
‘Comprar productos
Figura 6.1. Icono del lenguaje UML para un caso de uso,
Ejemplo de un caso de uso de alto nivel: comprar productos
EI siguiente caso de uso de alto nivel describe clara y concisamente el proceso de
comprar articulos en una tienda cuando se emplea una terminal en el punto de venta.
Caso de uso: Comprar productos
Actores: Cliente, Cajero.
Tipo: Primario (que se explicard luego).
Un Cliente llega a la caja registradora con los articulos que
comprara, El Cajero registra los articulos y cobra el importe.
Al terminar la operacin, el Cliente se marcha con los pro-
ductos.
Los encabezados y la estructura de este caso de uso son representativos. Sin em-
bargo, el UML no especifica un formato rigido; puede modificarse para atender las
necesidades y ajustarse al espiritu de la documentacién: ante todo, una comunicacién
clara,
Conviene comenzar con los casos de uso de alto nivel para lograr rapidamente
entender los principales procesos globales.
49 {6- CASS DE. USO: DESCRIPCION DE PROCESOS 6 - CASOS DE US0: DESCRIPCION DE PROCESOS
6.3.2
Ejemplo de un caso expandido de uso:
comprar productos con efectivo
Curso normal de los eventos
Accién del actor Respuesta del sistema
Un caso expandido de uso muestra mas detalles que uno de alto nivel; este tipo de
casos suelen ser ttiles para alcanzar un conocimiento més profundo de los procesos y
de los requerimientos. A menudo se llevan a cabo en un estilo “coloquial” entre los
actores y el sistema [Wirfs-Brock93]. Damos en seguida un ejemplo de un caso expan-
dido de Comprar productos que ha sido simplificado para manejar tnicamente los
agos en efectivo y excluir la administracién del inventario (lo hemos hecho para sim-
plificar la explicacién en este primer ejemplo).
7. El Cliente efectia un pago en efec-
tivo —el “efectivo ofrecido”— posi-
blemente mayor que el total de la
venta,
8. El Cajero registra la cantidad de efec- 9, Muestra al cliente la diferencia.
tivo recibida. Genera un recibo.
10. El Cajero deposita el efectivo rect 11, Registra la venta concluida.
bido y extrae el cambio del pago.
Coo Comprar productos en efectivo EI Cajero da al Cliente el cambio y el
Actores: Cliente (niciador), Cajero. recibo impreso.
Propésito Capturar una venta y su pago en efectivo. 12, El Cliente se marcha con los articu-
‘Resumen: Un Cliente llega a la caja registradora con articulos que desea los comprados.
comprar. El Cajero registra los productos y recibe un pago en
efectivo. Al terminar Ia operacién, el Cliente se marcha con
los productos comprados.
Tipo: Primario y esencial. .
Funciones: R1.1, R1.2, R13, R17, RL9, R2d.
Cursos alternos
Linea 2: introduccién de identificador invalido. Indicar error.
Referencias
cruzadas:
mnte no tenfa suficiente dinero. Cancelar la transaccién de venta.
= Linea 7: el
3.3 Explicacién del formato expandido
Curso normal de los eventos
La parte superior de la forma expandida es informacién muy sucinta
Accién del actor Respuesta del sistema
1. Este caso de uso comienza cuando
un Cliente llega a una caja de TPDV as Nombre del caso de uso
(Terminal Punto de Venta) con pro- Actores: Lista de actores (agentes externos), en la cual se indica quién
ductos que desea comprar. inicia el caso de uso.
2, El Cajero registra el identificador de 3. Determina el precio del producto & ; ye
cada producto, corpora a la transaccién actual la Propésito reece
Si hay varios productos de una _ informacion correspondiente. Resumen: Repeticidn del caso de uso de alto nivel o alguna sintesis
misma categoria, el Cajero también _—_Se presentan la descripcién y el pre- cine!
puede introducir la cantidad, cio del producto actual. a 1 Primario, secundario u opcional (a explicar)
4. Al terminar de introducir el pro- 5. Calcula y presenta el total de la ee
ducto, el Cajero indica a TPDV que venta. 2. Esencial o real (a explicar).
se concluy6 la captura del producto, Referencias Casos relacionados de uso y funciones también relacionadas
6. El Cajero le indica el total al Cliente. cruzadas: del sistema, 6.4
52.
6 CASOS DE USO: DESCRIPCION DE PROCESS
La seccién intermedia, curso normal de los eventos, es la parte medular del formato
expandido; describe los detalles de la conversidn interactiva entre los actores y el
sistema, Un aspecto esencial de la seccion es que explica la secuencia més comin de
los eventos: Ia historia normal de las actividades y la terminacién exitosa de un pro-
ceso. No incluye situaciones alternas,
Curso normal de los eventos
Accién del actor Respuesta del sistema
Descripciones numeradas de las
respuestas del sistema.
Acciones numeradas de los actores.
opciones 0 excep-
‘son complejas,
La tiltima seceién, curso alterno de los eventos, describe important
ciones que pueden presentarse en relacién con el curso normal.
podemos expandirlas y convertirlas en nuestros casos de uso.
Cursos alternos
= Alternativas que pueden ocurrir en el ntimero de linea. Descripcién de excepciones.
Actores
Elactor es una entidad externa del sistema que de alguna manera participa en la histo-
ria del caso de uso. Por lo regular estimula el sistema con eventos de entrada 0 recibe
algo de él. Los actores estan representados por el papel que desempefian en el caso:
Cliente, Cajero u otro. Conviene escribir su nombre con mayuiscula en la narrativa del
caso para facilitar la identificacién.
Oo
Cliente
Figura 6.2. Icono del lenguaje UML que representa un actor de casos de uso!
1 Aunque el icono estindar es una figura humana estlizada, hay quienes prefieren utilizar un
icono con figura de computadora para designar los actores que son sistemas de computo y no
seres humanos,
5
6 - CASOS DE USO: DESCRIPCION DE PROCESOS
0 de uso hay un actor iniciador que produce la estimulacién incial y, posible-
wicar quién es el iniciador,
Enun
mente, otros actores participantes; tal vez convenga
Los actores suelen ser los papeles representados por seres humanos, pero pueden ser
cualquier tipo de sistema, como un sistema computarizado externo de bancos. He
aqui algunos tipos:
= papeles que desempefian las personas
= sistemas de cémputo
= aparatos eléctricos 0 mecénicos
Un error comun en los casos de uso
Un error comin en la identificacién de los casos de uso consiste en representar los
pasos, las operaciones o las transacciones individuales como casos. Por ejemplo, en el
dominio de la terminal del punto de venta, podemos definir (incorrectamente) un
denominado “Imprimir el recibo”, cuando en realidad esta operacidn no es mas que un
paso de un proceso mas amplio del caso Comprar productos.
Un caso de uso es una descripcién de un proceso de principio a fin relativamente
amplia, descripcién que suele abarcar muchos pasos 0 transacciones; normalmente no
@5 un paso ni una actividad individual del proceso, |
—
Es posible dividir las actividades o parte del caso en subcasos (denominados casos
abstractos de uso), incluso en pasos individuales; pero esto no es Jo habitual y lo
veremos en el capitulo 26.
Identificacion de los casos de uso
Los siguientes pasos de la identificacién de los casos de uso requieren una lluvia
de ideas y revisar los documentos actuales sobre la especificaci6n de los reque-
rimientos, {6- CASOS DE USO: DESCRIPCION DE PROCESOS 6 - CASOS DE US0: DESCRIPCION DE PROCESOS
“1 8 Casos de uso, funciones del sistema y rastreabilidad
Un método con que se identifican los casos de uso se basa en los actores,
1. Se identifican los actores relacionados con un sistema o empresa, Las funciones del sistema identificadas durante la especificacién previa de requerimien
tos deben asignarse a los casos de uso. Ademés, debe ser posible verificar, mediante la
seccién Referencias cruzadas, que todas las funciones hayan sido asignadas. Con ello se
Jogra un vinculo importante respecto a la rastreabilidad entre los artefactos, En defini-
tiva, todas las funciones y casos de uso del sistema deberian poder rastrearse hasta la
2. Encada actor, se identifican los procesos que inician en que participan.
Un segundo método de identificacién de los casos de uso se basa en eventos. implementacién y la aplicacién de pruebas.
4. Se identifican los eventos externos a los que un sistema ha de responder.
2. Se relacionan ls eventos con los actores y con los casos de uso. 9 Diagramas de los casos de uso
En la aplicacién del punto de venta, algunos actores posiblemente relevantes y los pro- En la figura 6.3 se muestra un diagrama de casos de uso para el sistema del punto de
ceesos que inician son: venta,
Cajero Registra A TROV
Entrega efectivo O Oo
Aw
| cliente Compra productos Calero Ctente
Paga los productos Registra los datos
Entega ol caro
toe pedacos
aa comprades
6.7 Caso de uso y procesos del dominio
Figura 6.3: Diagrama parcial de casos de uso.
Un caso de uso describe un proceso, un proceso de negocios por ejemplo, Un pro-
eso describe, de comienzo a fin, una secuencia de los eventos, de las acciones y las Un diagrama de casos de uso explica gréficamente un conjunto de casos de uso de un
transacciones que se requieren para producir u obtener algo de valor para una em- sistema, los actores y la relacién entre éstos y los casos de uso. Estos tiltimos se mues-
presa o actor. tran en dvalos y los actores son figuras estilizadas. Hay lineas de comunicaciones
\ entre los casos y los actores; las flechas indican el fio de la informacién o el estimulo,
A continuacién se mencionan algunos procesos: ° °
unos Pr El diagrama tiene por objeto ofrecer una clase de diagrama contextual que nos per-
= Retira efectivo en un cajero automatico mite conocer répidamente los actores externos de un sistema y las formas basicas en
ue lo utilizan,
= Ordena un producto :
m= Registra los cursos que se imparten en una escuela
10 Formatos de los casos de uso
= Verifica la ortografia de un documento con un procesador de palabras
ea a et tea En la préctica, los casos de uso pueden expresarse con diverso grado de detalle y de
aceptacion de las decisiones concernientes al disefto. En otras palabras, un mismo 6.10.1
6 - CASOS DE US0: DESCRIPCION DE PROCESOS
‘caso de uso pueden escribirse en diferentes formatos y con diversos niveles de detalle.
‘Mas adelante estudiaremos otras formas de clasificarlos y expresarlos en formatos;
pero por ahora nos concentraremos en una divisién fundamental: casos con formato
de alto nivel y expandido.
Formato de alto nivel
Un caso de uso de alto nivel describe un proceso muy brevemente, casi siempre en
dos 0 tres enunciados, Conviene servirse de este po de caso durante el examen ini
cial de los requerimientos y del proyecto, a fin de entender répidamente el grado de
complejidad y de funcionalidad del sistema. Estos casos son muy sucintos y vagos en
las dec
6.10.2 Formato expandido
6.11
Un easo de uso expandido describe un proceso mis a fondo que el de alto nivel. La
diferencia bisica con el caso de uso de alto nivel consiste en que tiene una seccién
destinada al curso normal de los eventos, que los describe paso por paso. Durante la
fase de especificacién de requerimientos, conviene escribir en el formato expandido
los casos mas importantes y de mayor influencia; en cambio, los menos importantes
pueden posponerse hasta el ciclo de desarrollo en el cual van a ser abordados.
Los sistemas y sus fronteras
Un caso de uso describe la interaccién con un “sistema”. Las fronteras ordinarias del
sistema son:
= la frontera hardware/software de un dispositivo o sistema de cémputo
= eldepartamento de una organizacion
= Ia organizacion entera
ED}
‘Actor
130 de uso.
Figura 6.4. Frontera de un
Es importante definir la frontera del sistema para identificar lo que es interno o
externo, asi como las responsabilidades del sistema. E] ambiente externo esta repre-
sentado tinicamente por actores.
6 - Cass DE USO: DESCRIPCION DE PROCESOS
Estudiaremos un ejemplo de la influencia que tiene seleccionar la frontera del sistema:
los pagos en la terminal del punto de venta y la tienda. Si elegimos como “el sistema” la
tienda entera o el negocio (figura 6.6), el tinico actor es el cliente y no el cajero, porque
este ultimo es un recurso del sistema del negocio que realiza las funciones. Pero si
escogemos como sistema el hardware y el software de la terminal del punto de venta
(figura 6.5), se trata como actores al cliente y al cajero.
O [o™ |
1 Geno ots) —|
Regaira
los precuctos
Entroga ol cambid
Figura 6.5, Casos de uso y actores cuando el sistema TPDV es la frontera.
Compre ross
>10
cee
Ex aca
ies
Nests
Figura 6.6 Casos de uso y actores cuando tienda es la frontera.
En Ia seleccién de una frontera del sistema influyen las necesidades de la investi-
gacién, Si estamos desarrollando un software de aplicacién o un dispositivo, sera
razonable establecer la frontera del sistema en la del hardware y en la del software;
or ejemplo, la terminal del punto de venta y sus programas constituye “el sistema”, y
el cliente y el cajero son los actores (agentes) externos,
Si estamos efectuando la reingenieria de procesos de la empresa —reorgani-
zando los procesos o la empresa para mejorar la competitividad o la calidad, Ia selec-
ce
87 6 - CAS0S DE USO: DESCRIPCION DE PROCESOS
cidn de la compafia o de la tienda entera como el sistema es importante. En el sistema
‘TPDY, definiremos “el sistema” como la terminal de punto de venta y su software.
6.12 Casos de uso primarios, secundarios y opcionales
Los casos deberian clasificarse en primarios, secundarios u opcionales. Mas adelante,
a partir de estas designaciones, clasificaremos nuestro conjunto de casos de uso para
establecer prioridades en su desarrollo.
Los casos primarios de uso representan los procesos comunes mas importantes,
como Comprar productos.
Los casos secundarios de uso representan procesos menores 0 raros; por ejemplo,
Solicitud de surtir el nuevo producto.
Los casos opcionales de uso representan procesos que pueden no abordarse.
6.13 Casos esenciales de uso comparados con los casos
reales de uso
6.13.1 Casos
58
Grado dela aceptacién del clseRo en un caso do uso
Caso esencial aso real
muy abstracto muy conereto
Figura 6.7. Los casos esenciales y reales de uso existen a lo argo de un continuo,
esenciales de uso
Los casos esenciales de uso [Constantine97] son casos expandidos que se expresan
‘en una forma tedrica que contiene poca tecnologia y pocos detalles de implemen-
tacién; las decisiones de disefio se posponen y se abstraen de la realidad, especial-
‘mente las concernientes a la interfaz para el ustario. Un caso de este tipo describe el
proceso a partir de sus actividades y motivos esenciales. El grado de abstraccidn con
que se describe existe en un continuo: la descripcidn puede ser més o menos esencial.
Los casos de alto nivel siempre son de caracter esencial, debido a su brevedad y
abstraccion.
En seguida se incluye un ejemplo de un caso de Retiro de efectivo en un cajero
automatico, que se expresa en una forma relativamente esencial.
6 - CASOS DE US0: DESCRIPCION DE PROCESOS
Esencial
Accién de los actores Respuesta del sistema
1. Ell Cliente se identifica, 2. Presenta opciones.
3. yasi sucesivamente. 4. yasi sucesivamente,
La manera en que un cliente se identifica cambia con el tiempo —es una decision de
diseio—, pero forma parte del proceso esencial de que la identificacién se realice
de alguna manera.
Conviene crear casos esenciales de uso al comenzar a investigar los requerimientos,
con el propésito de entender mejor el alcance del problema y las funciones necesarias.
Este tipo de casos son de gran utilidad porque permiten captar la esencia del proceso
y sus motivos fundamentales, sin verse abrumado con detalles de disefio. Suelen tam-
bién ser correctos durante largo tiempo, ya que excluye las decisiones de disefio y, por
lo mismo, su creacién favorece la comprensién y el registro de los factores que dan
vida a los procesos de un negocio. Una empresa puede recuperar y releer los casos
esenciales de uso mucho tiempo después, aplicandolos exitosamente a un nuevo
proyecto de desarrollo.
13.2 Casos reales de uso
En cambio, un caso real de uso describe concretamente el proceso a partir de su
disefio concreto actual, sujeto a las tecnologias especificas de entrada y de salida, etc.
Cuando se trata de la interfaz para el usuario, a menudo ofrece presentaciones de pan
talla y explica la interaccidn con los artefactos. A continuacién se incluye el caso Retiro
de efectivo expresado en una forma relativamente real.
Real
Accién de los actores Respuesta del sistema
1, El Cliente introduce su tarjeta, 2. Pide el niimero de identificacién
personal (NIP).
3. Introduce el NIP con un teckado 4, Muestra el mend de opciones.
5. yas{ sucesivamente 6. y asi sucesivamente,
Notese que la accién esencial del “Cliente se identifica a si mismo” del caso de uso se
realizé ahora concretamente en la serie de acciones comenzando con “El Cliente intro-
duce su tarjeta”,
59 6 - CASOS DE USO: DESCHIPCION DE PROCHSOS
En teorfa, los casos reales de uso se crean durante la fase de diseno en un ciclo de
desarrollo, por ser un artefacto del disefio. En algunos proyectos se prevén las primeras,
decisiones de disefio concernientes a la interfaz para el usuario; de ahi la necesidad de
crear casos reales en la fase inicial de elaboracién. Se recomienda hacerlo en la fase
de planeacién y elaboracién por la aceptacién prematura de un disefio y la abrumadora
complejidad. No obstante, algunas compafias aceptan un contrato de desarrollo,
basindose en las especificaciones de la interfaz para el usuario,
En el capitulo 19 se examinan los casos reales en la aplicacién al punto de venta.
6.13.3 El caso esencial de uso de la compra de productos
El-caso ampliado de uso Comprar productos que ya mencionamos tiende a ser un caso
esencial, Obsérvese que la descripcién no es muy especifica respecto a la realizacion
‘técnica. El caso esta escrito de manera que casi podemos imaginar su aplicabilidad
después de cien aitos 0 hace cien afios, lo cual manifiesta que es esencial
Esencial
Accién de los actores Respuesta del sistema
1. EI Cajero registra el identificador en 2. Determina el precio del producto y
cada producto. agrega la informacién sobre él a la
Sihay mis de un producto igual, e| tual transaccidn de venta.
Cajero puede introducir de igual Aparecen Ia descripcién y el precio
‘manera la cantidad. del producto actual.
3. yasi sucesivamente. 4. yasi sucesivamente.
6.13.4 El caso real de uso de la compra de productos
‘A diferencia de una version esencial del caso de uso, una versién real se compromete
ccon el disefio; una versin completa de ella se explicara en un capitulo posterior. En el
siguiente ejemplo de la versién real, nétese la decisién de utilizar un cédigo universal
de producto (CUP) con el identificador del producto! y una interfaz grafica para el
usuario.
En una fase temprana del andlisis no conviene tomar algunas decisiones, como lade utiliza
tun cédigo universal de producto (CUP) en el caso esencial de uso. El anilisis y disefo|
csencial y real son terminos a lo largo de un continuo de abstraccién més que extremos.
He aqui io mas importante: siempre que se adopta un compromiso durante la fase de andl
sis, existe la posibilidad de un error prematuro de diseflo, sobrecarga de informacion y|
‘menor flexibilidad,
{6 CASOS DE. USO: DESCRIPCION DE PROCESOS
Real
Accién de los actores
1. En cada producto, el Cajero teclea el
Cédigo Universal de Productos (CUP)
en el campo de entrada del CUP de la
Ventanal. Después oprime el botén
“Introducir producto” con el ratén
oprimiendo la tecla .
3. etcétera,
14 Sobre la notacién
Respuesta del sistema
2, Muestra el precio del producto y
agrega la informacion sobre él a la
actual transaccién de venta,
La descripcién y el precio del pro-
ducto actual se muestran en el cuadro
de Texto 2 de la Ventanal.
4, etcétera,
14.1 Asignacién de nombre a los casos de uso
‘Alcaso de uso se le asigna un nombre que comience con un verbo para subrayar que
se trata de un proceso. Por ejemplo:
= Comprar productos
= Introducir un pedido
14.2 Inicio de un caso expandido de uso
Comience un caso expandido con el siguiente esquema:
1, Este caso comienza cuando
Por ejemplo:
1. Este caso de uso comienza cuando un Cliente llega a un TPDV con productos que
desea comprar.
De este modo se estimula una identificacin clara del actor y del evento iniciadores.
14.3 Puntos sobre la decision de notacién y sobre la ramificacién
Un caso de uso puede contener puntos de decisién. Por ejemplo, en Comprar produc-
tos, el cliente puede optar por pagar con efectivo, a crédito o con cheque en el
‘momento del pago. Si una de estas trayectorias de decisién es un caso muy represen-
tativo y si las otras alternativas son raras, inusuales 0 excepcionales, el caso tipico .CASOS DE USO: DESCRIPCION DE PROCESOS
deberd ser el tinico acerca del cual se escribe en el Curso normal de los eventos y las
opciones han de escribirse en la seccién titulada Alternativas.
Pero en ocasiones el punto de decision representa opciones cuya probabilidad es rela
tivamente igual y normal; esto sucede con los tipos de pago en efectivo, con tarjeta de
crédito y con cheque. En este caso se utiliza la siguiente estructura notacional:
1. Ena seccién principal Curso normal de los eventos, indique las ramas de las sub-
secciones.
Escriba una subseccién en cada rama, utilizando otra vez un Curso normal de los
‘eventos. Inicie el evento numerando en 1 cada seccién.
3. Si las subsecciones tienen opciones, escribalas en una seccién de alternativas de
cada subseccién,
Seccién: principal
Curso normal de los eventos
Accién de los actores Respuesta del'sistema
1. Este caso de uso comienza cuando un Cliente
Tega a la caja TPDV con los productos que
compraré,
(Excluidos los pasos intermedios)...
El Cliente escoge el tipo de pago:
a. Sipaga en efectivo, constiltese la sec-
ccién Pago en efectivo.
b, Sipaga.a crédito, consiitese la seccién
Pago con tarjeta de crédito.
c. Sipaga con cheque, consiiltese la sec-
ccién Pago con cheque.
4, Registra la venta terminada,
5. Imprime un recibo.
6. El Cajero le entrega el recibo al Cliente.
7. El Cliente se marcha con los productos com-
prados.
‘C4808 DE USO: DESCRIPCION DE PROCESOS
Seccién: Pago en efectivo
Curso normal de los eventos
Accién de los actores Respuesta del sistema
1, El Cliente da un pago en efectivo —el
“efectivo ofrecido’—, posiblemente
mayor que el total de ia venta,
2. El Cajero registra el efectivo ofrecido. 3. Muestra al Cliente la diferencia.
4. El Cajero deposita el efectivo reci-
Dido y extrae la diferencia,
El Cajero entrega al Cliente el cambio
del pago.
Cursos alternativos
= Linea 4: efectivo insuficiente en la caja para pagar la diferencia. Se pide efectivo al
supervisor o se pide al Cliente un pago mas cercano al total de la venta,
Seccién: pago con tarjeta de crédito
Cursos normales y alternos de la historia de pago con tarjeta de crédito.
Seccién: pago con cheque
Cursos normales y alternos de la historia de pago con cheque.
Casos de uso dentro de un proceso de desarrollo
Pasos de la fase de planeacién y elaboracién
1. Después de haber listado las funciones del sistema, defina la frontera de éste y
Tuego identifique los actores y los casos de uso. {6- CASOS DE US0: DRSCRIPCION DE PROCESOS
2. Escriba todos los casos de uso en el formato de alto nivel. Clasifiquelos en prima-
ros, secundarios u opcionales,
8. Dibuje un diagrama de caso de uso,
4. Relacione los casos de uso y dé ejemplo de las relaciones en el diagrama corres-
Pondiente (més adelante se explican las relaciones de los casos).
5. Escriba en el formato esencial expandido los casos de uso més importantes, influ
yentes y riesgosos, a fin de entender y estimar mejor la naturaleza y las dimen-
ones del problema. Para evitar anilisis complejos posponga la escritura de la
forma esencial expandida de los casos de uso menos importantes hasta los ciclos
de desarrollo en que seran abordados.
6.
in teoria, los casos reales deberian posponerse hasta una fase de disefio en el
Ciclo de desarrollo, porque su creacién conlleva decisiones de disefio. Pese a ello,
a veces es necesario crear casos reales de uso durante la etapa inicial de los reque-
rimientos si:
9 Las descripciones concretas facilitan notablemente la comprensién.
9 Los Clientes exigen especificar sus procesos en esta forma,
7. Clasifique los casos de uso (que se expondrén en el siguiente capitulo)
6.15.2 Pasos de la fase del ciclo de desarrollo iterativo
1. Fase de andlisis: escriba casos esenciales de uso expandidos para los que se han
abordado, si todavia no se llevan a cabo.
2, Fase de disefio: escriba casos reales de uso para los que estin siendo abordados,
en caso de que todavia no se realicen.
6.16 Pasos del proceso en un sistema del punto de venta
Explicaremos algunas de las siguientes actividades en capitulos posteriores, ya
que requicren una exposicién amplia o pueden aplazarse para evitar una sobre-
carga de informacién. Como nuestra meta es adquirir la habilidad de aplicar los casos
y no convertirnos en expertos en tiendas, no escribiremos los detalles de todos los
casos.
6.16.1 Identifique los actores y los casos de uso
En la aplicacién del punto de venta, defina la frontera del sistema que seré el sistema
de hardware/software, el caso habitual. Un ejemplo de lista de los actores y procesos
relevantes a que dan inicio —que no pretende en absoluto ser completa— incluye:
6 - CASOS DE US0: DESCRIPCION DE PROCESOS
] Registra los productos
Entrega el cambio
Cliente | compra productos
Paga los productos
Gerente Inicia
Cierra
‘Administrador Incorpora nuevos
del sistema usuarios
6.16.2 Escriba casos de uso en el formato de alto nivel
‘Una muestra de casos de us
Caso de uso:
Actores:
Tipo:
Deseripeién:
de alto nivel comprende:
Comprar productos
Cliente (iniciador), Cajero.
Primario,
Un Cliente llega a una caja con productos que desea comprar.
sjero registra los productos y obtiene el pago. Al terminar
la transaccidn, el Cliente se marcha con los productos.
Inicio de operaciones
Gerente,
Primario.
Un gerente activa una TPDV a fin de preparla para que la usen
los Cajeros. El Gerente comprueba que la fecha y la hora sean
correctos; hecho esto, el sistema est listo para que lo utilice
el Cajero.
65 6 - CA80S DE USO: DESCRIPCION DE PROCESOS 6 - CASOS DE Us0: DESCRIPCION DE PROCESOS
6.16.3 Dibuje un diagrama de casos de uso Casos de uso: comprar productos
Seccién: princips
TPov
~
Coma C Caso de uso: Comprar productos
oma proaucos
a» Actores: Cliente (iniciador), Cajero.
Caro
" = Ciente Propésito: Capturar una venta y su pago.
Resumen: Un Cliente llega a la caja con productos que desea comprar.
El Cajero registra los productos y recibe el pago, que puede
ser autorizado. Al terminar la transaccién, el Cliente se marcha
con los productos.
Tipo: Primario y esencial.
——~ Referencias Funciones: R11, R1.2, R13, R17, RL9, R2.1, R2.2, R2.3, R24.
Ce =
O a Casos de uso: el Cajero debe haber terminado el caso de uso:
— Ga fags
ations
Admiistador
delsistoma |
Curso normal de los eventos
Figura 6.8 Diagrama parcial de un caso de uso, que representa la aplicacién TPDV,
Accién de los actores Respuesta del sistema
6.16.4 Relacione los casos de uso 1, Este caso de uso comienza cuando un
Cliente lega a la caja TPDV con pro-
Este tema lo trataremos en un capitulo posterior. ductos que desea comprar.
2. ElCajero registra los productos. 3. _Determina el precio del producto y
eat 4 1a informacién sobre ¢1 a la
ic i Si hay més de un producto, también a 5
6.16.5 Escriba algunos casos esenciales expandidos de uso puede introducir la cantidad actual transaccién de venta.
Se muestran la descripcién y el pre-
cio del producto actual,
Entre los casos primarios de uso realmente significativos figuran:
4, Alterminar la captura de los produc- 5. Calculay presenta el total de la venta.
= Comprar productos ar la cap
tos, el Cajero indica a TPDV que ter-
‘= Pagar los productos comprados miné la captura de los productos.
Escribir lo anterior en una forma esencial expandida suministrara una mayor infor- 6. EI Cajero le indica el total al Cliente.
‘macién y esclarecimiento de los requerimientos. A continuacién se presenta el caso de
uso Comprar productos en su forma esencial expandida completa: 68.
{6 - CASO$ DE USO: DESCRIPCION DE PROCESOS
Curso normal de los eventos
Accién de los actores Respuesta del sistema
7, El Cliente escoge la forma de pago:
a. Sipaga en efectivo, véase la sec-
cién Pagar en efectivo.
b. Sipaga con tarjeta de crédito,
véase la seccién Pagar con
tarjeta de crédito
cc. Sipaga con cheque, véase la
seccién Pagar 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. B] Cliente se marcha con los produe-
tos comprados,
Cursos alternos
‘= Linea 2: se introduce un identificador invalido del producto. Indique el error.
= Linea 7: el Cliente no pudo pagar. Cancele la transaccién de venta.
Seccién: pagar en efectivo
Curso normal de los eventos
Accién de los actores Respuesta del sistema
1. El Cliente da un pago en efectivo —el
“efectivo ofrecido"—, posiblemente
mayor que el total de la venta,
6 - CASOS DE Uso: DESCRIPCION DE PROCESOS
Curso normal de los eventos
Accién de los actores Respuesta del sistema
2. El Cajero registra el efectivo ofrecido, 3. Presenta la diferencia al Cliente.
El Cajero deposita el efectivo reci-
bido y extrae la diferencia.
El Cajero le entrega el cambio al
Cliente.
Cursos alternos
= Linea 1: el Cliente no tiene suficiente efectivo. Puede cancelar 0 iniciar otro método.
de pago,
m= Linea 4: la caja no contiene suficiente efectivo para pagar la diferencia. El Cajero
pide més efectivo al supervisor o le pide al Cliente otro billete de menor denomi-
nacién u otra forma de pago.
Secci6n: pago con tarjeta de crédito
Curso normal de los eventos
Accién de los actores Respuesta del sistema
1. El Cliente comunica su informacion 2. Genera una solicitud de pago con
de crédito para pagar con tarjeta. tarjeta de crédito y la envia a un Servir
cio externo de autorizacién de crédito,
Servicio de autorizacién de cré- 4, Recibe una respuesta aprobatoria de
dito autoriza el pago. crédito del Servicio de autorizacién
de crédito.
5. Enel sistema de Cuentas por cobrar
registra la informacién sobre el pago
con tarjeta de crédito y la respuesta
de aprobacién. El Servicio de auto-
rizacién de crédito debe dinero a la
‘Tienda; por tanto, Cuentas por
cobrar debe darle seguimiento.
6. Muestra el mensaje aprobatorio de
autorizacién, {6- CASOS DE USO: DESCRIPCION DE PROCESOS
Cursos alternos
= Linea 3: solicitud de crédi
poner otro método de pago.
negada por el Servicio de autorizacién de crédito, Pro-
Seccién: pago con cheque
Curso normal de los eventos
Accién de los actores Respuesta del sistema
1. El Cliente extiende un cheque y se
identific
2. El Cajero registra la informacién so- 3, Genera una solicitud de pago con
bre la identificacién y solicita la auto- cheque y la envia a un Servicio ex-
rizacién del pago con cheque. terno de autorizacién de cheques.
4. Verifica que el pago haya sido auto- 5, Recibe una respuesta aprobatoria del
rizado por el Servicio de autorizaciin _—_Servicio de autorizacidn de cheques.
ce cede 6. Indica la obtencién de la autorizacién,
Cursos alternos
= Linea 4: verificar solicitud negada por el Servicio de autori
poner otra forma de pago.
én de cheques. Pro
6.16.6 Si es necesario, escriba algunos casos reales de uso
No conviene 0 no es necesario crear casos de uso real en este momento; este trabajo
se realizara durante los ciclos de desarrollo.
6.16.7 Clasifique los casos de uso
Este tema se estudiard en el siguiente capitulo.
_70
{6- CASOS DE US0: DESCRIPCION DE PROCESOS
6.17 Modelos muestra
Los casos esenciales de alto nivel y los diagramas de casos de uso son miembros del
modelo de casos de uso del andlisis (figura 69).
— del ett BS
- - roan cnamico
Figura 6.9 Modelo de andlisis
pocUNeetAkoN YB
HBO - URUGUAY
a CLASIFICACION
Y PROGRAMACION
DE LOS CASOS DE USO
Objetivos
‘= Clasificar los casos de uso.
= Cuando sea necesario, preparar versiones simplificadas de los casos de uso.
= Asignar los casos de uso a los ciclos de desarrollo.
Introduccién
Las especificaciones de los requerimientos y los casos de uso se definen en la Fase de
Planeacién y Blaboracién. Ademas, puede crearse un Modelo conceptual preliminar y
disefiar una arquitectura también preliminar del sistema, aunque estas actividades se
pospondrén en nuestro estudio de casos para ofrecer una introduccién mas gradual a
los temas.
Suponiendo que todos los artefactos deseados hayan sido generados (por ejemplo, la
especificacién de los requerimientos y los casos de uso), el siguiente paso es iniciar
la fase de Construccién en el ciclo de desarrollo iterativo y comenzar a implementar el
sistema. En un ciclo de vida de desarrollo iterativo, la tarea de llenar los casos de uso
se distribuye entre varios ciclos.
En el presente capitulo se estudia la clasificacién y la programacién o calendariza.
cién de los casos de uso, Una vez concluida esta etapa, estaremos listos para comen-
zar el primer ciclo de desarrollo y examinar a fondo el anilisis y disefio orientados a
objetos. 17 - CLASIPICACION Y PROGRAMACION DE LOS CASOS DE USO
72
Actividades de la fase de planeacién y elaboracién,
Informe |
proiminer do
Investigacion
Protatpos
Prosupuest
programa
Dependonciarespecto @
7.2.1
Notas
a.consiante Mh
». opconal
©. plaza
4 orden varable
Especticacones
e requerimientos
casos de uso
todos de alto nivel
b. algunos esenciales 7.2.2
expandicos
Diagramas de
casos de uso
| Modelo conceptual
plminar
iosano
Dependencias de los artefactos respecto a la fase de planeacion y elaboracion,
1 CLASIFICACION Y PROGRAMACION DE. LOS CASOS DE USO
Programacién de los casos de uso en los ciclos de desarrollo
Casos de uso y los ciclos de desarrollo
Los ciclos de desarrollo se organizan en torno a los requerimientos de los casos de
uso. En otras palabras, se asigna un ciclo para implementar uno 0 mas casos de uso 0 sus
versiones simplificadas, cuando el caso integro resulta demasiado complejo para abor-
darlo en un ciclo (figura 7.1).
ow fD
de desaroio
=
Ciclo
de desarralio
Gases (azo de uso AS
version versén
smpiticada | integra
Figura 7.1. Asignacién de los casos de uso a los cilos de desarrollo,
Clasificacion de los casos de uso
Es necesario clasificar los casos de uso, y los casos de alto rango han de tratarse al ini-
cio de los ciclos de desarrollo. La estrategia general consiste en escoger primero los
casos que influyen profundamente en la arquitectura basica. He aqui algunas de las
cualidades que aumenta la clasificacién de un caso:
a. Tener una fuerte repercusién en el
muchas clases a la capa del dominio o requerir servicios de per
b. Con relativamente poco esfu
el diseno.
zo obtener informacién ¢ ideas importantes sobre
Incluir funciones riesgosas, urgentes o complejas.
Requerir una investigacién a fondo o tecnologia nueva y riesgosa.
Representar procesos primarios de la linea de negocios.
Apoyar directamente el aumento de ingresos o la reduccién de costos,
7. 1 CLASIFICACION Y PROGRAMACION DE L0S CASOS DE USO 1T- CLASIFICACION ¥ PROGRAMACION DE LOS CASOS DE USO
El esquema taxondmico puede servirse de una clasificacién simple y poco rigurosa: realiz6 incrementalmente para satisfacer las necesidades de arranque de otros
alto-mmediano-bajo ‘casos. No vamos a presentar de manera explicita la programacién de los pasos de
El esquema también puede aplicar puntuaciones (posiblemente incrementadas con pon- este caso de uso y supondremos que siempre se desarrolla en forma imph
deracién), basdndose en les cualidades que inciden en la clasificacién; por ejemplo ee
i wo | al biel a
75 Programacion de los casos de uso en la aplicacién
Comprar productos |5 3 |2|0 [5 |3 | 18 del punto de venta
Y asi sucesivamente
7 . 7 oe A partir de la clasificacién, el caso Comprar productos deberia incluirse en el primer
7.3 Clasificacion de los casos de uso en la aplicacion ciclo de desarrollo. Como hemos visto, también puede abordarse una versién simple
al punto de venta de Inicio para soportar los otros casos de uso.
Con base en los criterios anteriores de clasificacién, a continuacién se incluye una 75.1 Creacién de versiones multiples de los casos de uso complejos
clasificacién informal y poco rigurosa de los casos de uso de aplicacién al punto de
venta, De ninguna manera pretendemos dar una lista exhaustiva. Siempre que se asigne un caso de uso, es necesario estimar si es posible resolverlo
{ntegramente en el lapso limitado de un ciclo (cuatro semanas, por ejemplo) o si el tra-
bajo ha de ser distribuido en varios ciclos. En este caso, Comprar productos es extre-
‘Caso de uso , x ei & © s as 7
# = gt of madamente complejo y quizd requiere cinco o mas ciclos, suponiendo que cada uno
| Alto ‘Comprar Corresponde a los criterios de clasificacion mas ‘tendra una duracién de cuatro semanas exactamente. Se supone una estrategia de pro-
productos altos. gramacién de duracién o tiempo fijo, en la cual al ciclo de desarrollo se le establece
Mediano | Incorpora ‘Afecta al subdominio de la seguridad 4 tun plazo fi.
eeeeenynnssanat En esta situacién el caso se redefine a partir de varias versiones de él, que van abar-
Registra los pro- Afecta al subdominio de la seguridad. cando requerimientos cada vez mas exhaustivos. Cada versién se limita a incluir lo
ductos comprados que se estima una cantidad razonable de trabajo dentro de los confines de la duracién
| Paga los produc- Proceso importante; afecta a la contabilidad. fija del ciclo (digamos cuatro semanas). Por ejemplo:
tos comprados wo. ei a
: = —___ 2 = Comprar productos: versién 1 (pagos en efectivo, sin actualizaciones de inven-
Bajo Pagar Efecto minimo ena arquitectura: trio.)
Iniciar La defini
in depende de otros casos de uso.
iat = Comprar productos: versién 2 (permitir cualquier tipo de pago)
Cerrar Efe
minimo en la arquitectura.
= Comprar productos: versién 3 (versién completa, incluyendo entre otras cosas las,
actualizaciones del inventario, ..)
74 El caso de uso de arranque Las versiones anteriores se distribuyen después a lo largo de una serie de ciclos de
desarrollo, junto con otros casos de uso.
Practicamente todos los sistemas cuentan con un Caso de uso de inicio 0 arranque.
Aunque tal vez no ocupe un nivel alto conforme a otros criterios, es preciso estudiar 7.5.2 Asignacién de los casos de uso
al menos una version simplificada de él, al principiar el ciclo de desarrollo para pre-
sentar la inicializacién supuesta en otros casos. En cada ciclo de desarrollo, éste se
Si nos basamos en la clasificacién de los casos y de varias versiones de Comprar pro-
You might also like
- Economia - Sector ExternoDocument19 pagesEconomia - Sector ExternoIvan MokNo ratings yet
- RESUMEN FINAL ACO vFINALDocument44 pagesRESUMEN FINAL ACO vFINALIvan MokNo ratings yet
- Economia - SectorPúblicoDocument8 pagesEconomia - SectorPúblicoIvan MokNo ratings yet
- RESUMEN FINAL ACO vFINALDocument45 pagesRESUMEN FINAL ACO vFINALIvan MokNo ratings yet
- Deserción Escolar en La Comunidad de MadridDocument2 pagesDeserción Escolar en La Comunidad de MadridIvan MokNo ratings yet
