~ F E

DEL SFTWARE
Un enfoque practico







--- -


I
l

I
. '

"--
~ \ I . ,
CONCEPTOS
CLAVE
ooiI"'del
IIooinIo .... .. 194
ooiIsi.
_urado ... 196
dose . 219
..,. .... de
IIojo de datos . 211
IIOIIoIado
....... 1.
.......
dose 219
.......
_ . 202
eRe 225
de dolo 197
del CDlftpor
_.10 .... 234
sptdf"Kodo.
de ,onlrol 215
orietolado
alliujo 211
objoto. de
dato .. .. . 198
reglas pt'actkas 194
CAPiTULO
MODELADO
,
DEL ANALISIS
E
n el ambito tecnico. la ingenieria de software comi enza con una serie de
tareas de model ado que conducen a una especificaci6n de requisitos y a
una representaci6n completa del disef\o del software que se construira. EI
modelo de analisis, que en realidad es una seri e de modelos, es la primera repre-
sentaci6n tecnica de un sistema.
En un libra sobre metodos de model ado del analisis, Tom DeMarco [OEM 79]
describe el praceso de l a siguiente manera:
Al observar los problemas y fallas reconocidas de la rase de analisis es necesario agre-
garle los siguientes objetivos:
Los productos del analisis deben teneT una eJevacta facilidad de man ten i-
rniento. Esto se aplica en particular al documento final [especificaci6n de re-
quisitos de software).
Los problemas de gran tamafto deben tratarse con un metoda efectivo de par-
tidon. La especificaci6n del tipo de las novelas victorianas ya no sirve.
Deben utilizarse graficas cuando sea posible.
Se debe diferenciar entre consideraciones J6gicas [esenciales) y fisicas [de im-
plementaci6n) ..
Como minima se necesita ..
Algo que ayude a hacer una partici6n de los requisitos y a documentarla antes
de Ja especificaci6n ..
Algunos medios para el seguimiento y evaluaci6n de las interfases ..
Herramientas nuevas para describir la 16gica y la tactica, algo mejor que un
texto
Aunque DeMarco escribi 6 acerca de los atributos del model ado del analisis hace
mas de un cuarto de si glo, sus contri buciones se siguen aplicando en la notaci6n
y l os metodos modernos de model ado del analisi s.
que eo relativamente facil de entender y, aun mas
importante, conduce a una revi sion para Iograr la
c:orrecci6n, la inlegridad y 10 consistencia.
a,Qui ? La palabro eocriIa as un
vehiculo morovilloso parala comunl-
caci6n, pero no es, necesariament&,
la mejor forma de _
requisitos para eI sofiwore1. cIe
putodora. EI modelado del anali.i. uIIIiza ImO
combinaci6n de formalo$ en 1exta y cliqpQlilOl
para representor los requisilo$ de 10. cIatoI, _
funciones y el compartamiento de uno I1I(IiIjIIQ
.Quilln 10 hac.? Un ingeniero de software [algu
nos vace. lIamado analistol conslruye el madelo
empleanda requi sitas abtenidas del diente.
tpor que .s importante? Para validar los
..requisitos del software es necesario examinarlos
desde algunos puntos de visto diferenles. EI mode
191
192 PARTE DOS PAAcnCA DE LA INGEN1ERlA DEL SOF1WARE
lado del aOOlisis represenla las requillitos en niul_ Una vez que se han creacIo los modelos
tiples U dimensiones#, con 10 que $& fa ""'_ .. ares, estos se refinon y analizan para
probobilidad de encontrar errones,' de sur- su calidad, integridad 'I cansistenda.
jan'1'ncansistendas y de que se de anellisis 10 validan
sianes. ',. las
son los pasos? Los requisitosdell .. ,:,Cu61 .... producto obIenido? Para el
madan, funcionales y de .. 1IICde1o de anc'iIisis <i!sposible elegir una amplia
madelan mediante varies de diagramos . w -:VGriedad de tipos de diagrornas. Coda una de
madelada basado en escenarias representa .1' :, ," 'ISlas representaciones afrece una visian de uno
sistema desde eI punto de vista del usooria. las elementos del modeIa.
madelada orien!ado 01 Hujo indico c6ma se JMMIo eskIr seguro de que 10 he
transforman los objelas de datos allllQ!izarse hecho ._tamente? Los praductos de
las funcianes del del aOOlisis deb... revisar-
basado en doses define objetos, se en 10 nsIotiva a sue oarrecciOn, integridad y
ciones. EI madelada del comportomiento PflI" cansistencia. Estos deben reHejar las neeesida-
senta los estados del sistema y sus closes, <lSI' des de !ados 100 inleresadoo y eotablecer una
como el impodo de 10. eventoo sabre sus esto- base desde 10 cual pueda condudrse el di.eno.
8 r 1 ANi,LISIS DE RQyISIIOS
EI modelo de onolisis y
Ie especificoci6n de
requisitos proporciono
un media para evoluar
10 colidod uno vel que
el sohware este
conslruido.
El andlisis de requisitos genera la especificacion de caracterfsticas operacionales de
software; indica la interfaz del software con otros elementos del sistema. y estable-
ce las restricciones que debe tener el software. El anidisis de requisitos permite que
el ingeniero de software (a veces llamado en este contexto analisla 0 mode/ador) se
extienda sobre requerimientos basicos establecidos durante tareas anteriores a la
ingenieria de requisitos y construya modelos que representen escenarios del usua-
rio, actividades funcionales, clases de problemas y sus relaciones, el comportamien-
to de las clases y el sistema y, a medida que se transforma, el flujo de datos.
EI analisis de requisitos Ie proporciona al disenador de software una representa-
ci6n de informacion, funcion y comportamiento que puede trasladar a disefios arqui-
tectonicos, de interfaz y en el nivel de componentes. Por ultimo, el modele de ana-
lisis y la especificacion de requisitos ofrecen al desarrollador y al cliente los medios
para evaluar la calidad una vez construido el software.
Por medio del model ado del anal isis el ingeniero de software se centra primero
en ei que, no en el como. objetos manipuia ei Sistema, que funciones debe
desempeflar el sistema, que comportamientos muestra el sistema, que interfaces se
definen y que restricciones se aplican?l
En capitulos anteriores se estableci6 que en esta etapa tal vez no fuera posible
realizar una especificacion compieta de requisitos. Quiza el desarrollador no este
I Es necesario mencionar que con forme los clientes se vuelven mas refinados en el sentido tecnolo-
gico existe una tendencia hacia la especificacion tanto del c6mo como del que. Sin embargo, el en-
roque prima rio debe permanecer en el que.
Elmodelo de
cm6l1s1scomo
an puente
ae 1a
descrtpclon
del sistema y
I1modelo de
diseno.
CAPITULO 8 MODELADO DEL ANAusIS
De5Cripcion
del sistema
193
segura de que enfoque espedfico realizara la fund6n y si se desempefiara de mane-
ra apropiada. Estas realidades favoreeen un enfoque iterativo para el anal isis y el
mode I ado de requisitos. EI analista debe modelar 10 que se conoce y utili zar ese
modelo como base para diseiiar un incremento de software.
2
8.1 .1 Filosofia y objetivos generales
EI modelo de analisis debe cumplir tres objeti vos primari os: I ) describir 10 que
requiere el cli ente, 2) establecer una base para la creaci6n de un disefio de soflwa-
re, y 3) definir un conjunto de requisitos que puedan validarse una vez conslruido el
soflware. EI modelo de analisis Il ena el vacio entre una descripci6n al nivel de siste-
ma (capitul o 6) - que detalla la funcionalidad general del sistema, la eual se logra al
aplicar soflware, hardware, datos, humanos- y otros elementos del sistema y del
disefio de soflware (capitul o 9) - que detall an la arquitectura de aplicaci6n del sofl -
ware, la interraz con el usuario y la estructura en eI niveI de componentes-. Esta
relaci6n se i1ustra en la figura 8. 1.
'los problemas dignos de olaear demu"lran su volor devolvi.ndo el golp .
PietHein
Es importante puntualizar que algunos elementos del modelo de anal isis estan
presentes (en un grado mas alto de abstracci6n) en la descripci6n del sistema, y que
esas tareas de ingenieria de requisitos en realidad comienzan como parte de la inge-
nieria de sistemas. Ademas, todos los elementos del modelo de anali sis son identi -
ficables de manera directa en las partes del modelo del disefio. No siempre es posi-
ble una divisi6n clara de tareas de analisis y disefio entre estas dos importantes acti-
vidades del modelado. De modo invariable, como parte del analisis se reali za algun
disefio y algun analisis se efectua durante el disefio.
2 De manera alternativa, el equipo de software puede elegir la creaci6n de un prototipo (capitulo 3)
en un esfuerzo encaminado a entender mejor los requisitos para el sistema.
194
[n wwwJI .....
,om/lngIi.h/
Software
Inglneerlog/
51_","5 . ,
pueden enconrrorse
mochos recursos atlles
pora eI onOlisis del
dominio.
PARTE DOS PAAcnCA DE LA INGENIERlA DEL SOFTWARE
8. 1. 2 Reglas practicas de an6lisis
Arlow y Neustadt [ARL02[ sugieren varias reglas practicas que deben seguirse para
crear el modelo de analisis,
El modelo debe centrarse en los requisitos visibles dentro del problema a dominio
de negocio. EI grade de abstraccion debe ser alto de forma relativa. "No se debe
perder tiempo en detalles" IARL02] que tratan de explicar como funcionara el
sistema.
Cada elemento del modelo de analisis debe agregarse a un acuerdo general de los
requisitos de software y proporcionar una vision interna del dominio de informa -
cion, funcion y comportamiento del sistema.
Debe retrasarse la consideracion de la infraestructura y otros modelos no fun cio-
nales hasta el diseflO. Por ej emplo, es posible que se requiera una base de
datos, pero las clases necesarias para implementarla, las funciones que se
requieren para acceder a ell a y el comportamiento que se exhibira cuando se
uti li ce debe considerarse solo despues de que se haya completado el anali si s
de dominio del problema.
Se debe minimizar el acoplamiento de todo el sistema. Es importante repre-
sentar las relaciones entre clases y funciones. Sin embargo, si el nivel de
"i nterconexion" es extremadamente alto se deben hacer esfuerzos para
reducirlo.
Se debe tener la seguridad de que el modelo de andlisis proporciona valor a todos
los interesados. Cada ci rcunscripcion tiene su propio uso del modelo. Por
ejemplo, los interesados relacionados con los negocios deben utilizar el
model o para validar los requisitos; los disefiadores, como base para el disefio;
la gente de aseguramiento de la calidad, como ayuda para planear pruebas de
aceptacion.
EI modelo debe mantenerse tan simple como sea posible. No se deben agregar
diagramas adicionales cuanda estos no ofrezcan informacion nueva. No se
deben utilizar formas de notaci6n nuevas cuanda basta con una simple !isla.
8.1.3 An6lisis del dominio
AI examinar la ingenieria de requisi tos (capitulo 7) se establecio que los patrones de
analisis a menudo ocurren de nuevo en muchas aplicaciones dentro de un dominic
de negocio especifico. Si estos patrones se definen y se clasifican por categoria de
una manera que permi tan a1 ingeniero 0 al analista de software reconocerl os y reu-
tilizarl os, la creacion del modelo de analisis se acelera. Un factor de mayor impor-
tancia es que la probabilidad de aplicar patrones de disefio reutili zabl es y compo-
nentes ejecutabl es de software aumenta en forma sustancial. Esto ofrece tiempo al
mercado y reduce los costos del desarrollo.
Fuentes del
conocimienlo
del dominio
,.,iij!,! iih' &1
Enwww.sei
..... fslrf
descriptionsf
detIo.bhnl puede
enconlTorse una
exposici6n volioso
sobre el onlliisis y 10
ingenieno del dominio.
CAPiTULO 8 MODELADO DEL ANALISIS 195
Entrada y salida para el cmcl1isis del dominio.
Literatura tecnica
-
/
T axonomias de close
Aplicociones existentes
\ Estondares de reutilizadon
Modelo
Sondeos a los clientes
Anal;.;.
Modelos funcionales de an61isis
Recomendocion experto del dominio
del dominio
Requisitos octuoles/futuros
'\..
~
Lenguojes de dominio
--'
-
~ P e r o en primer lugar, como se reconocen los patrones de analisis? .;.Quienes los
definen, los asignan a una categoria y los preparan para aplicarlos en proyectos sub-
secuentes? Las respuestas a estas preguntas residen en e! analisis del dominio.
Firesmith [FIR93] describe el aniliisis del dominio de la siguiente manera,
El aniilisis del dominio de software es la identificacion, el analisis y la especificacion de re-
quisitos comunes de un dominio especifico de aplicacion para, de manera tipica, reutili-
zarlo en multiples proyectos dentro de ese dominio de aplicacion.. [EI anal isis del
dominio orientado a objetos es] la identificacion, el anal isis y la especificacion de capaci-
dades comunes reutilizables dentro de un dominic especifico de aplicacion, en terminos
de objetos, clases, subensamblajes y marcos de trabajo.
El "domini o de aplicacion especifico" puede variar desde aeronautica hasta servicios
bancarios, desde videojuegos en multimedia hasta software aplicado en instrumen-
tal medico. La meta del analisis 0 de dominio es directa: encontrar 0 crear aquel\as
clases de analisis 0 funciones y caracteri sticas comunes que se aplican ampli amen-
te para que puedan reutilizarse
3
/lEi gran arte del aprendizoie as entender poco a poco"
John l.ck.
En cierta forma, el papel de un analista de dominic es similar al de un maestro
forjador de herramientas en un ambiente de manufactura pesada. EI trabajo de este
ultimo es disefiar y fabricar instrumentos que puedan ser usados por much a gente
que realiza trabajos simi lares. EI papel del analista de dominio4 es descubrir y definir
3 Una vision complementaria del analisis del dominio "involucra el modelado del dominio de forma
que los ingenieros de software y otros interesados puedan aprender mas de el. .. no todas las clases
del dominio resultan necesariamente en el desarrollo de clases reutilizables"[LET03].
4 No debe suponerse que si se cuenta con la colaboraci6n de un analista del dominio, un ingeniero de
software no tiene por que comprender el dominio de aplicacion. Todos los miembros de un equipo
de software deben tener algun conocimiento del dominio en el cual se colocara el software.
196 PARTE DOS PAAcnCA DE LA lNGENIERlA DEL SOFJ'INARE
patrones de analisis reutjlizables, clases de analisis e informacion relacionada que
pueda usar mucha gente en aplicaciones parecidas.
La figura 8.2 [ARA89] ilustra entradas y salidas clave para el proceso de analisis
de dominio. Las fuentes de conocimiento del dominic se examinan en un intento por
identificar objetos que pueden ser reutilizados a traves del dominio.
Una visi6n del modelado del analisis, Ilamado analisis estructurado, considera que los
datos y el proceso que transforman los datos son entidades separadas. Los objetos
de datos se modelan en una forma que define sus atributos y relaciones. Los proce-
sos que manipulan los objetos de los datos se modelan de tal manera que muestran
c6mo transforman los datos, mientras los objetos de datos fluyen por el sistema.
Un segundo enfoque del modelado del anal isis, Ilamado analisis orientado a obje-
tos, se centra en la definicion de clases y en la manera en que estas colaboran entre
elias para efectuar los requisitos del cliente. EI UML Y el proceso unificado (capitulo
3) estan orientados a objetos en forma predominante.
B [olnolisil os frustronte, lIeno de relociones interperlonoles complejol, indefinido y dilll. En pocos polabros, 8\
foscinonte. Una vez que estos engonchado, el vieio placer de 10 construcdon de sistemas mmca sera 5uficiente pam
sotisfocert . "
T ... DeM.rco
Aunque el modele de analisis propuesto en este capitulo combina caracteristicas
de ambos enfoques, es com lin que los equipos de software elijan uno y excluyan
todas las representaciones del otro. El cuestionamiento no es ellal es el mejoT, sino
que combinaci6n de representaciones Ie proporcionara a los interesados el mejor
modelo de requisitos de software y el puente mas efectivo para el disefio de software.
EI modelado del analisis conduce a la deri vaci6n de cad a uno de los elementos de
modelado mostrados en la figura 8.3. No obstante, el contenido especifico de cada
elemento (por ejemplo, los diagramas con que se construyen el elemento y el mode-
10) puede diferir de proyecto a proyecto. Como ya se ha puntuaJizado muchas veces
en este libro, el equipo de software debe trabajar para mantenerlo simple. S610 se
deben utilizar aquellos elementos que agreguen valor al modelo.
If ,Por que debemos construir modelos? ,Por que no (onstruimos el sistema y yo? Lo respuesto es que podemos
construir modelos de tal forma que resoltemos 0 enfaticemos dertos coracteristicas criticos de un sistema
l
01 mismo
nempo que quitomos ;nlolil 0 otros' olpectol del liltema. "
Ed YOIrdon
Elementos
delmodelo
de anCilisis.
,Como se
manifiestan
a si mismos los
dalas denlra del
contexto de una
oplicadon?
Un objeto de datos es
uno representoci6n de
cuolquier informacion
compuesto que se
proceso (on software.
CAPITULO 8 MODELADO DEL ANAuSIS 197
basaOos Ele mentos on.ntados
en escenanos 01 fluio
Cosos de usa, redo
DiogfOmoS de Huio de dolos
Cosos de usa, diogromo$ Diogromos de Ruio de (onlrol
Diogromos de odividod NOffOlivos de proce$Omienlo
Diogromos de corril
Modelo de an61isis
Erementos basadas Ele mentos de
en closes camDOrtamiento
Diogromos de dose Diogromos de estodo
Poquetes de onal isis Diogromos de secuencio
Modelos CRC
Diogromos de coloborod6n
EI modelado del analisis a menudo comi enza con el mode/ado de datos. EI ingeni ero
o analista de software define todos los objetos de datos que se procesan dentro del
sistema y las relaciones entre los obj etos de datos, ademas de otra informacion per-
tinente para las relaciones.
8.3.1 Objetos de datos
Un objeto de datos es una representacion de casi cualquier informacion compuesta
que el software debe en tender. Informaci6n compuesla se refiere a al go que tiene
muchas propiedades a atributos diferentes. Por 10 tanto, "anchura" (un val or indivi -
dual) no seria un objeto de datos valido, pero las dimensiones (Ia incorporaci on de
altura, an chura y profundidadl podrian defi nirse como un objeto.
Un objeto de datos puede ser una entidad externa (por ejempl o, cualquier cosa que
produzca 0 consuma infonnacion). una cosa (por ejempl o, un reporte 0 un despliegue).
un suceso (como una lIamada telefonica) 0 un even to (como una alarma), un papel (por
ejemplo, un vendedor). una unidad organizacional (como un departamento de conta-
duria) , un lugar (como un almacen). 0 una estructura (como un archivo). Por ejemplo,
una persona 0 un auto pueden verse como un objeto de datos en el sentido de que cual-
quiera de elias puede definirse en tenninos de un conjunto de atributos. La descripcion
del objeto de datos incorpora el objeto y todos sus atributos.
Un objeto de datos encapsula solo datos: no existe alguna referenci a dentro de un
obj eto de datos a las operaciones actlien sobre los datos
S
Par 10 tanto, el obj eto de
datos puede representarse como una tabla, tal como se muestra en la figura 8.4. Los
encabezados de la tabla reflejan l os atributos del obj eto. En este caso, un auto se
define en terminos de marca, modelo, numero de seri e, tipo de carrocerfa, color Y pt'Opieta-
rio. EI contenido de la tabla representa ejempl os especificos del objeto de datos. Por
ejemplo, un Chevy Corvette es una muestra del objeto de datos auto.
5 Esta distinci6n separa los objetos de datos y las clases u objetos definidos como parte del enfoque
orientado a objetos.
198
Representaclon
tabular de
objetos de
datos.
Los otribulos definen a
un objeto de dotos,
describen
corocteristicos y, en
algunos rosos, hocen
referencio (] olro
objeto.
; ." ;
EI (oocepfo Ilomrn:lo
"normoliloci6n es
importonte pam todos
oquellos que intenton
realizer modelodo de
detos. En www.
d"amodel.Olg
puede encontrorse UflO
intJOducci6n om.
PARTE DOS PRAcnCA DE LA INGENIERiA DEL SOFTWARE
-
Ins! oneie
8.3,2 Atrlbutos
Nombres
de otributos
Une los obietos de dotos entre 5i,
en este coso, propielorio
/r ___ ___

Atributos Atributos
idenlificodor descriptivos

referencioles

Morea Modelo # de id. Tipo Color Propietario
lexus l5400 AB123. Sedan Blanco R5P
Chevy Corveffe X456. DeportivQ Roje CCD
BMW 750il XZ765. Coupe Blanco Ul
Ford Taurus Q12A45. .. Sedan Azul BlF
Los alribulas deflnen las propiedades de un objeto de datos y toman una de las tres
caracteristicas diferentes. Se pueden utilizar para l) nombrar una ocurrencia del
objeto de datos, 2) describir la ocurrencia 0 3) hacer referencia a otra ocurrencia en
otra tabla. Ademas, se debe deflnir uno 0 mas atributos como un i dentiflcador; es
decir, el atributo identificador se convierte en una "clave" cuando se desea encontrar
una ocurrenci a del objeto de datos. En algunos casos, los valores para el (l os) iden-
tiflcador(es) son (micas, aunque esto no es un requisito. En referencia al objeto de
datos auto, un i denti flcador razonable podria ser el numero de serie.
EI canjunto de atributos apropiado para un objeto de datos se determina median-
te la comprensi 6n del contexto del problema. Los atributos para auto sirven bien
para una aplicaci6n que utilice el Departamento de vehicul os de motor, pero estos
atributos serian inutil es para una compania automotriz que necesite un software
para el control de fabricaci6n. En este ultimo caso, l os atributos para auto tal vez
incluirian tambiE!n nurnero de serie, tipo de carrocerfa y color, pero ademas tendrian que
adicionarse much os mas atri butos (como c6digo interior, tipo de tren de rnanejo, designa-
dar de paquete de ajuste, tipo de transmisi6n) ,.para hacer de auto un objeto
en el contexto de control de fabricaci6n.

Objetos de datos y clases 00, "son 10 mismo?
(uando se debate ocerco de los objetos de tambien incorpora las operociones que manipulan los
datos es comun que suria una pregunto: aun datos implicodos por dichos atributos. Ademes, 10
objeto de dotos es 10 mismo que una dose orientado a definicion de doses implico una infraestructura completa
objetos? La respuesta es: "noN. que es parte del enfoque de la ingenierio de software
Un objeto de dotos define un elemento compuesto de orientado a objetos. Las doses se comunican entre 51 a
los datos' esto es incorpora una coleccion de elementos de troves de mensajes; pueden organizarse en jerorquios;
datos individuale's (atributos) y do un nombre a 10 proporcionan caracteristicas heredadas para objetos que
coleccion de elementos (el nombre del objeto de datos). son uno instancio para una dose.
Uno dose 00 encapsula atributos de los datos, pero
Relac10nes
entre objetos
de datos.
Los lelociones indicon
monelO en que los
objetos de dotos eston
conectodos entre sf.
CAPiTULO 8 MODELADO DEL ANAuSIS
8.3.3 Relaciones
p."ono I I oUlomov;1 1
0) Una conexion b6sica entre objetos
de dotos
b) Relaciones entre objetos
de datos
199
Los objetos de datos estan conectados entre si de muchas maneras diferentes. Por
ejemplo. dos obj etos de datos, persona y auto, pueden representarse con la simple
notaci6n ilustrada en la figura S.Sa. Se establece una conexi6n entre persona y
auto porque los objetos se relacionan entre sl. l.Pero, cuales son las relaciones? La
respuesta se determina entendiendo el papel de las personas (propietarios, en este
caso) y de l os autos dentro del contexte del software que se construira. Se puede
definir un conj unto de parejas objeto/ rel aci6n que definan las rel aciones relevantes.
Por ejemplo:
Una persona posee un auto,
Una persona esta asegurada para conducir un auto.
Las relaciones posee y esla asegurada para conducir definen las conexiones reI evan-
tes entre persona y auto. En la figura S.Sb se ilustran estas parejas objeto/relaci6n
de manera grafica. Las fiechas de la figura S.Sb ofrecen informaci6n importante
ace rca de la direccionalidad de la relaci6n y a menudo reducen la ambiguedad 0 las
malas interpretaciones.
8.3.4 Cardinalidad y modalidad
Los elementos del modelado de datos -objetos de datos, atributos y relaciones-
ofrecen la base para en tender el dominio de informaci6n de un problema. Sin
embargo, tam bien es necesario comprender informacion adicional relacionada con
estos elementos basi cos.
Hasta este punto se ha defini do un conjunto de objetos y se han representado las
parejas objeto/relaci6n que los limitan. Pero un simple par que establece que
objetoX se re/adona con objetoY no proporci ona suficiente informaci6n para los
prop6si tos de la ingeni eria del software. Se debe en tender cuantas ocurrencias del
objetoX estan relacionadas con cuantas ocurrencias del objetoY. Esto conduce al
concepto del model ado de datos llamado cardinalidad.
El modele de datos debe ser capaz de representar el numero de ocurrencias de
los objetos en una relaci6n dada. Tillmann [TIL93] define la cardinali dad de un par
objeto/ relaci6n de l a si guiente manera: "Cardinal idad es la especificaci6n del nume-
200
,COmo se
maneja una
situation en 10
que un objeto de
datos esta r e l ~
donado (on 10
o(urrencia de
muchos olros
objeto, de doto,?
PARTE DOS pRAcnCA DE LA INGENIERlA DEL SOFIWARE
ro de ocurrencias de un [objetoj que puede relacionarse con el numero de ocurren-
cias de otro [obj etoj". Por ejemplo, un objeto puede relacionarse solo con otro obj e-
to (una relacion I : I ); un objeto puede relacionarse con muchos obj etos (una relacion
I:N); un numero de ocurrencias de un obj eto puede relacionarse con algun otro
numero de ocurrencias de otro obj eto (una relacion M:N)6 La cardinalidad tambi en
defi ne "el numero maximo de objetos que puede participar en una relacion" [TIL93] .
Sin embargo, no indica si un obj eto parti cular de datos debe parti cipar 0 no en la
relacion. EI modele de datos agrega modalidad al par objeto/ relacion para especifi -
car esta informacion.
~
Diagramas de entidad-reJacion
La porejo objeto-relaci6n es 10 piedra angular
del modele de datos. Estes porejas pueden
representorse de monero grcifica mediante el diagromo de
enlidad-reloci6n (OERJ.
7
EIDER 10 propu$O originalmente
Peter Chen [CHEll] para el diseno de sistema!. de bases
relacionale!., y despues otrmlo han ompliado. Con eiDER
se identifieo un caniunlo de componentes primarios:
objetos de datos, atributos, relaciones e indicodores de
vorios tipos. EI propOsito primordial del DER es representor
objetos de dotos y sus relaciones.
represenlan par medio de un rectangulo etiquelado. Los
relociones se representan mediante una linea etiquelada
que conedo objetos. En algunos variaciones del DER 10
linea de conexion conliene un rombo que esta etiquelado
con 10 relacion. Las conexiones entre objetos de datos y
relaciones se establecen mediante una voriedod de
simbolos especioles que indican su cardinalidad y
modolidod.
Para mas informacion sabre el modelodo de datos y el
diogromo de entidad-relacion ellector inleresado puede
consultor [THAOOj
Ya se ha hecho una introduccion de 10 notacion
rudimentaria para eIDER. Los objetos de datos se
La modalidad de una relaci on es de 0 si no hay una necesidad explicita para que
ocurra la relaci6n 0 la relaci6n es opcional. La modalidad es 1 si una ocurrencia de
la relacion es obligatoria.
Pora que un sistemo de information seo util , "nfioble, odoptoble y economico debe es10r bosodo primero en 01
mocIeIodo de dol .. , y sOlo de monero ,e(Undorio en el onoli,i, del proceso ... porque 10 esInKIuro d. dot .. so roliore
de Ionno inherente a 10 verdod, mientro, que el proceso os relotivo 0 10 tirniro."
~
ModeJado de datos
Objetivo: Las herramientas para el modelodo
de datos proparcionon 01 ingeniero de sohware
10 copocidod de representor objetos de datos, sus
caraclerislicas y relaciones. Estas herramientas -que se
utilizan sabre lodo para grondes aplicaciones de bases de
datos y olres proyectos de sistemas de informacion-
6 Par ejempia, un tia puede tener muchos sobrinos y un sabri na puede tener muchos tias.
7 Aunque el DER todavia se usa en algunas aplicacianes para el disefio de bases de datos, en la ac-
tualidad la notacion en UML es la mas utilizada para el disefia de datos
CAPITULO 8 MODELADO DEL ANAuSIS
proporcionon un medio automatizodo para crear
diagramas de entidad-relacion, diccionarios de objetos de
datos y modelos relacionados.
Mecanica: las herramientas en esta categorla permiten
01 usuario describir objetos de datos y sus relaciones. En
algunos casos uti lizan 10 notacion del DER; en otras
ocasiones modelan las relaciones por medio de otros
mecanismos. Adem6s permiten 10 creacion de un modelo
de base de datos 01 generar un e5quema de bose de datos
pora 5MBD.
Herramientas representativas
8
AI/Fusion ERWin, desarrollado por Computes Associates
(WWVv'3.ca.com), oyuda en el disena de objetos de datos,
estructuras propias y elementos clove para bases de datos.
ER/Sfudio, desorrollado per Embarcadero Software
(www.embarcodero.coml.brindo soporte 01 modelado
entidad-relaci6n.
201
Oroefe/Designer, desarroll ado per Oracle Systems
(www.oracle.com). modelo procesos de negocios,
entidades de datos y relaciones que se transforman en
disenos a partir de los cuales se generan aplicaciones
completas y bases de datos.
MetaScope, desarrollado per Madrone Systems
(www.madronesystems.coml. es uno herramienta para
el modelado de datos de bajo costo que do soperte a
10 representacion gr6fi ca de datos.
Mode/Sphere, desarrollado per Magno Solutions GMBH
(www.mognosolutions.coml, do soporte a uno variedad
de herromientas de modelado relocional.
Visib/eAno/yst, desorrollodo por Visible Systems
(www.visible.coml, do soporte a una variedad de
fvnciones de modelado del analisis, incluido el
model ado de datos.
Cualquier estudio sobre el amilisis orientado a objetos deberia comenzar definiendo
el termino orientado a objetos. tQue es un punto de vista orientado a objetos? tPor
que un metodo se considera orienta do a objetos? tQue es un objeto? Cuando la 00
obtuvo una amplia variedad de adeptos durante l as decadas de 1980 y 1990, exist ie-
ron muchas opiniones diferentes (por ej emplo, [BER93], [TAY90], [STR88], [B0086]
acerca de las respuestas correctas a estas preguntas. En l a actuali dad ha surgido una
vision coherente de l a 00.
EI objetivo del amil i si s orientado a objetos (AOO) es definir todas las c1ases (ade-
mas de las relaciones y el comportamiento asociado con elias) relevantes para el
problema y que deben resolverse. Esto se logra lievando a cabo algunas tareas:
1. Deben comunicarse los requisitos basicos del usuario entre el cliente y el in-
geniero de software.
2. Deben identificarse las clases (es decir, se definen l os atributos y metodos).
3. Se define una jerarquia de c1ases.
4. Deben representarse las relaciones de objeto a objeto (conexiones entre objetos).
5. Debe modelarse el comportamiento del objeto.
6. Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo
este completo.
8 Las herramientas mencionadas aqui son una muestra de esta categoria. En la mayoria de 105 casos
los nombres estan regi strados par sus respectivos desarrolladores.
202 PARTE DOS pRAcnCA DE LA INGENIERlA DEL SOFIWARE
En lugar de examinar un problema mediante un modelo mas convencional del
tipo entrada-procesamiento-salida (flujo de informacion) 0 un modelo derivado en
forma exclusiva de las estructuras jerarquicas de informaci6n, el AOO construye un
modelo orientado a las clases que se basa en la comprension de los conceptos 00.

Conceptos orientados a objetos
, Los conceptos orientodos a objetos (00) est6n
bien establecidos en el mundo de 10 ingenieria
del sohware. A continuoci6n 5e presentan los descripciones
abreviodos de conceptos 00 que 5e encuentran con
frecuencia durante el modelado del ancilisis. En el capitulo
lOse presenton aIres objetos 00 que est6n alineados de
monero mas cercone 01 diseno de software.
plano de Irabajo) que describe una coleccion de objelos
similares.
Atributos: una colecci6n de valores de los datos que
describen una close.
Close: encapsulo los dotos y las abstracciones de
procedimiento requeridos para describir el contenido y el
comportomiento de alguna entidad del mundo real. Oicho
de olra manera, una clase es una descripcion
generolizada (por ejemplo, una plantilla, un patron 0 un
Objelos: inslancias de una close espedfica. los obielos
heredan los atributos y operaciones de una close.
Operaciones: tambiEln lIamodas mefodos y servicios,
proporcionan 10 representacion de uno de los
comportamientos de una close.
Subclase: una especializacion de 10 superclase. Uno
subclose puede heredar tanto los atributos como las
operaciones de una superclase.
Superclase: tambien lIamada uno close basico, es una
generalizacion de un conjunto de closes que estan
relacionadas con ella.
Aunque el exito de un sistema 0 producto basado en computadora se mide en
much as formas, la satisfaccion del usuario encabeza la lista. Si los ingenieros de
software entienden la manera en que los usuarios finales (y otros acto res) quieren
interactuar con el sistema, el equipo de software sera mas capaz de caracteri zar en
forma apropiada los requisitos y construir modelos significativos de analisis y dise-
no. Por 10 tanto, el modelado del analisis con UML comienza con 1a creaci6n de esce-
narios en la forma de casos de uso, diagramas de actividad y diagramas de carril.
8.5.1 Escritura de casos de uso
Un caso de uso captura las interacciones que ocurren entre los productores y con-
sumidores de informaci6n y del sistema en sf mismo. En esta secci6n se examina 1a
forma en que se desarrollan los casos de usa como una parte de la actividad del
modelado del amilisis
9
El concepto de un caso de uso (capitulo 7) es relativamente facil de entender: des-
cribe un escenario de uso especifico en un lenguaje directo desde el punto de vista
9 Los casos de uso son una parte particularmente importante del modelado del analisis para las in-
terfases con el usuario. El analisis de la interfaz se trata con detalle en el capitulo 12.
,
En afgunas situa-
(ianes, fos casas de
usa se vuefven ef
mecanismo
dominante de fa inge-
nierfa de requisifos.
Sin embargo, esto no
signifiea que deban
descof/Voe los
mnceptos y temicas
eslud/odos en el
copilulo 7.
CAPITULO 8 MODELADO DEL ANALlSIS 203
de un actor definido.lO Pero como puede saberse 1) .;.sobre que escribi r? 2). .;.cuanto
escribir acerca de ella' 3), <que tan detallada debe ser la descripcion', y 4) <coma orga-
nizar la descripcion? Estas son las preguntas que deben contestarse para que los casas
de usa tengan un valar como herramienta para el modelada del anillisis.
'[los!ll!OS d. usa) son simplemente uno oyuda para delinif 10 que existe luera del sistema (odoresl y 10 que deberi.
reaIiw eI sisfemo (OOIOS de usol."
1.0' JtKObsoo
lSobre que escribir? Las primeras dos tareas de la ingenieria de requisitos 11 -ini -
cia y obtenci6n- proporcionan la informaci6n necesaria para comenzar a escribir
casas de usa. Las reuniones para la recapilacion de requisitas, despliegue de la fun-
cion de calidad (QFD) y atros mecanismas para la ingenierla de requisitas se utilizan
para identificar a las interesados, definir el ambito del problema, especificar las
metas aperat ivas glabales, esquematizar todas las requisitas funcianales canacidos
y describir las casas (abjetas) que manipulara el sistema.
El desarrollo de una serie de casos de uso se comienza haciendo una lista de las
funciones a actividades que realiza un actar especifico. Estas pueden abtenerse de
una lista de funciones requeridas del sistema par medio de conversaciones can los
clientes a usuarios finales, 0 mediante una evaluaci6n de los diagramas de actividad
(seccion 8.5.2) desarrolladas camo parte del madelada del anali sis.
Desarrollo de otro escenario de uso preUmlnar
II escenario: Uno sola de
II1II""''' 'aultln'lela segundo junto para 10 recopilacion
Jamie: ,Qui .. hoc.. eI flO!"" del odor en _,
Moderador: Creo qu<>MenedHh luna penonCI de
mercodotecnial he .. tado ft'abaiando en ....
funcionalidod. ,Par que no hoces I!i eI pafMIIf Jamie Lazor, miembro del equipo de
Robbim, miembro del equipo de software;
del software; tres
n de metcadotechio; un representonte de
de producto; y un moderodor.
""",II6or: Es hora de que comencemos a hablar
de.1a n.nci6n de vigilancia de HagarSeguro.
CI desonollor un escenorio de usuorio para el
"Ia funci6n de seguridad en .1 hagar.
Meredith: ,Quieres que 10 hogamo. iguaI qu<> Ia 6IIima
vez, no es asf?
Moderador: (orredo ... de 10 misma forma.
Meredith: Bueno, es abvia que 10 raz6n pare Ia
vigilancia es permitir que el propietario est6 peldente de
10 coso mientras el 0 ella est6n vera, grabar y
reprodudr videos que se hoyon capturodo .. _ ese tipo de
cosas.
10 Un actor no es una persona especifica, sino el papel que desempeiia una persona (0 dispositivo) den-
tro de un contexto especifico. Un actor "llama al sistema para entregar uno de sus servicios"
[CaCOII
II Estas tareas de la ingenieria de requisitos se examinan con detalle en el capitulo 7.
204 PARTE DOS pRAcnCA DE LA !NGENIERiA DEI.. SOFIWARE
De ocuerdo, entonces b6sicamente hay dos
funci6n de vigilancia ... 10 primero
induyendo el establecimiento de un
-necesitomos herramientos que cyuden
movimiento y los acercamienlos de una c:6maro
10 camara seleccionada doodo ..
plano de 10 coso. Ouiero grabar y nepraduclr Ia saIidco
de los comoros de manera seIectivo. Tombi," quiero ..
copaz de bloqueor ej occeso a uno 0 mas c6maros con
uno contrasena especifico. Y quiero fa opci6n de wr
pequenos ventanos que muestren vistas de todas los
comoros y despues ser capoz de selecxionc. Ia que
quiera destacar.
0 hacerlo- y Ia segundo parte es 10 funci6n
real en sf misma. Como eI establecimiento
Jamie: Eso$ se lIaman vistas en miniatura.
. parte de Ia octividod de conflguroci6n, me
Ia funci6n de vigilancio.
Meredith: Bien, entonces quiero vistas en minioturtl de
todas las comaras. Tambier, quiero que Ia interfaz can Ia
funci6n de vigilancia tengo Ie misma opariencia que
todas las otras inlerloses de HogarSeguro. OUi .... que
sea intuitiva; es decir, que no sea n&Ce$Orto leer un
manual para poder usorta.
... _ ..... ( ..... riencIo): Me quilasfe las palabras
boca.
.,. r I .... : Mm ... Quiero tener occeso a 10 funci6n de
yo sea a troves de 10 PC 0 de Internet. Siento
que eI ocxeso por Internet serio eI de uso mas frecuente.
De ........ ier monera, quiero ser capaz de desplegor
Wtos de las c6ma1'O> en uno PC y cantrolar el
Moderador: Suen trabajo, ahara entremos en esta
funci6n con un poco m6s de detalle ...
La funcian de vigilancia en el hagar de HogarSeguro que se examina en el recua-
dro identifica las siguientes funciones (una li sta abreviadal que realiza el actor iden-
ti ficado como propietario de 1a casa:
Tener acceso a la camara de vigilancia via Internet.
Selecci onar la camara que desea ver.
Solicitar vistas en miniatura de tadas las camaras.
Desplegar vi stas de 1a camara en una ventana de una Pc.
Controlar la visi6n panoramica y de acercamiento en una camara especifica.
Registrar en forma select iva la salida de camara.
Repet ir la salida de camara.
Con forme se reali zan las conversaciones posteriores con el interesado (qui en
desempef\a el papel de un propi etario), el equipo de recopilaci an de requisitos desa-
rrolla casos de uso para cada una de las funciones mencionadas. En general , los
casos de uso se escriben primero en un estil o narrativo informal. Si se requiere
mayor formalidad se rescribe el mi smo caso de usa utilizando un formato estructu-
rado similar al propuesto en el capitulo 7 y reproducido en esta seccian como un
recuadro.
Con fines i1ustrativos, considerese la fundon "acceso a camara de vigilancia-des-
pliegue de vistas de camara (ACV-DVC)". EI interesado que desempef\a el papel del
propietario pod ria escribir el sigui ente rel ata:
,
CAPITULO 8 MODELADO DEL ANAuSIS 205
caso de uso: Acceso a camara de vigilancia-des pliegue de vistas de camara
(ACV-DVC)
Actor: propietario
Si me encuentro en un lugar lejano puedo usar una PC con un soflware de navegad6n
apropiado para entrar al sitio web de los productos HogarSeguro, Ingreso mi clave de usua-
rio y dos niveies de contrasenas y, despues de que estoy validado, tengo acceso a toda la
funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una ca-
mara especifica selecciono "vigilancia" de los botones desplegados para las funciones mas
importantes. Oespues escojo "seleccionar una camara" y se despli ega un plano de planla
de la casa. Entonces selecciono la camara en la que estoy interesado. En forma alterna,
puedo ver simultaneamente una lista con vistas en miniatura de todas las camaras al se-
leccionar "todas las camaras" como mi opd6n de visualizaci6n. Una vez que he seleccio-
nado una camara, selecciono "vista" y una vista de un cuadro por segundo aparece en una
ventana, a la cual identifica la camara clave. 5i quiero cambiar de camara, elijo "seleccio-
nar una camara" y la ventana de visi6n original desaparece y se despliega de nuevo el
plano de planta de la casa.
Una variaci6n del caso de usa relatada presenta la interacci6n como una secuencia
orden ada de las acciones del usuario. Cada acci6n se representa como un enuncia-
do declarativo. Despues de vi si tar la funci6n ACV-DVC, se puede escribir:
Caso de uso: Acceso a camara de vigilancia-despliegue de vistas de camara
(ACV-DVC)
Actor: propietario
1. El propi etario entra en el sitio Web de HogarSeguro.
2. EI propietario introduce su clave de usuario.
3. EI propietario introduce dos contrasenas (cada una de a1 menos ocho caracteres).
4. EI sistema despJiega todos los botones de las funciones mas importantes.
5. EI propietario selecdona "vigilancia" de los botones de funci ones mas importantes.
6. EI propietario elige "seleccionar una camara".
7. EI sistema despliega el plano de planta de la casa.
8. El propietario seiecciona un icono de camara del plano de pianta,
9. EI propietario selecciona el boton "vista",
10. Ei sistema despliega una ventana de visi6n, identificado por la clave de la camara.
11. El sistema muestra salida de video dentro de la ventana de visi6n con una veloci-
dad de un marco por segundo.
Es importante destacar que esta presentacion secuencial no considera algunas inte-
racciones aiternativas (la narrativa tiene un flujo mas Iibre y representa unas cuan-
tas alternativas). Los casos de uso de este tipo se refieren al gunas veces como esce-
narios primarios [SCH98] .
"Los msos de UIO pueden UIOIW en muchos p,o<osos [de softwnre]. Nuestr. levoril. es un PC"'" que sea iIwaIiYo Y
anIu<ido pot eI 'iesgo: -
Geri SdooeIder Y ...... WIIItn
206
,COmo se
examinan
(ursos
alternativo5 de
acci6n mientras
se desarrollo un
coso de usa?
PARTE DOS pRAcnCA DE LA INGENIERlA DEL SOFlWARE
Por supuesto, para una comptensi6n completa de la funci6n que se pretende des-
cribir es esendal una descripcion de las interacciones alternativas. Por 10 tanto, cada
paso en el escenario primario se eva ilia realizando las siguientes preguntas [5CH98j:
LEI acto puede ejecutar atra acd6n en este punto?
"Es posible que el actor encuentre alguna condici6n de error en este punto? 5i
es asi, l..cual podria ser?
"Es posible que el actor encuentre algun otro comportamiento provocado por
algun evento fuera de su control? 5i es aS1, Lcual podria ser?
EI resultado de las respuestas a estas preguntas es la creaci6n de un conjunto de
escenarios secundarios que son parte del caso de uso original, pero que representan
comportami entos alternativos.
Por ejemplo, considerense los pasos 6 y 7 en el escenario primario presentado
Iineas atras:
6. EI propietario el ige "seleccionar una camara".
7. EI sistema despliega el plano de planta de la casa.
tiEl actor puede ejecutQr aUa acdon en este punta? La respuesta es: "si". Con referen-
cia al relato de flujo libre, el actor puede elegir ver las vistas en miniatura de todas
las camaras de manera simultanea. Por ende, un escenario secundario podria seT:
"Ver las vistas en miniatura de todas las camaras".
,Es posible que eI actor encuenlre alguna condici6n de error en este punto' Cuando
un sistema basado en computadora esta en funcionamiento puede ocurrir cualquier
cantidad de condiciones de error. En este contexte se consideran s6lo las condicio-
nes de error que pueden ocurrir como resultado directo de las acciones descritas en
los pasos 6 0 7. De nuevo, la respuesta a la pregunta es: "si". Puede ser que nunca
se haya configurado un plano de planta con iconos de las camaras. Por 10 tanto, al
elegir "seleccionar una camara" se produce una condici6n de error: "no existe un
plano de planta configurado para esta casa"Y Esta condici6n de error se convierte
en un escenario secunda rio.
,Es posible que eI actor encuentre algun OIrO comportamiento en este punto' De
nuevo, la respuesta a la pregunta es: "si". Cuando se realizan los pasos 6 y 7 el sis-
tema puede encontrar una condici6n de alarma. Esto pod ria resultar en que el siste-
ma desplegara una notificaci6n especial de alarma (tipo, ubicaci6n, acci6n del sis-
tema) y Ie proporcione al actor una serie de opciones relacionadas con la naturale-
za de la alarma. Como este escenario secundario puede ocurrir para casi todas las
interacciones, no se convertira en una parte del caso de uso para el ACV-OVC. En
12 En este caso, otro actor, el administrador del sistema, tendria que configurar el plano de planta,
instalar e inicializar (es decir. aSignar una [D a cada equipo) para todas las camaras, aSl como rea-
lizar pruebas para estar seguro de que cada una de elias es accesible por medio del sistema y a tra
ves del plano de planta.
CAPiTULO 8 MODELADO DEL ANAuSIS 207
vez de eso, se desarrollara un caso de uso par separado - "condici6n de alarma
encontrada"-, el cual estara referenciado a otros casos de uso, segun se requiera.
En relaci6n con las plantillas formal es para los casas de usa que se muest ran en
el recuadro, los escenarios secundarios se representan como excepciones a la
secuencia basica descrita respecto al ACV-DVC.
HOGARSEGURO
Plantilla de caso de usa para la vigilanda
Actor primario:
Meta en conlexlo:
Coso de uso: Acceso a la camara
de vigilancio-despliegue de vistas
de comora (ACYDVq.
Propietorio
Ver 10 solido de los comoros
colocadas a 10 largo de 10 coso
desde cualquier ubicaci6n remota
a traves de Internet.
Condiciones previas: EI sistema se debe configuror por
completo; se deben obtener 10 y
controsenas apropiadas para los
Disparodor:
usuarios.
EI propietario decide echarle un
vitam a su caso mientros se
encuentra fuera de ella.
1. EI propielorio entra 01 sitio web de Productos
HogorSeguro.
2. a propietario introduce su 10 de usoorio.
3. EI propietorio introduce dos controsenas (cada una
de aI monos acha coracte,.., .
... EI sistema despliega todos 10. botones de las
Iunciones me. impartante .
5. EI propietario selecciona "vigilancia" de los botones
'de las, funciones mOs importontes.
6. EI propietario seiecciona "escoger uno coma ron .
7. EI sistema despliega el plano de 10 cosa.
8. Et propietario selecciono el icono de una camara del
plano de planlQ.
9. EI propietario selecciona el boron "vista".
10. EI sislemo despliega una ventana de visualizaci6n
que est6 identificodo can 10 10 de la comaro.
11 . EI sistema despliego 10 salida de video dentro de Ia
ventano de visuolizoci6n a un cuadro pot segundo.
Excepciones:
1. La 100 los contrasenos son incorrectos 0 no se
reconocen; vease el coso de uso: "volidar 10 y
contrasei'ias" .
2. lo fvnci6n de vigiloncia no esro configuroda para
este sistema, aSI que el sistema despliega at mensaje
de error opropiodo; veose el coso de usa:
"configurar 10 fvnci6n de vigilancia".
3. EI propietario selecciono "Ver vistas en miniatura
para todas las comoros"; vease el coso de uso: "Ver
vistas en miniatura para todas las comaras".
4. No esta disponible un plano de planta 0 este no se
ha configurodo, asi que el sistema despliego eI
mensoje de error apropiaclo; vease eI coso de U50
"configurar plano de 10 coso".
5. Se encuentra una condici6n de olorma; vease eI
coso de uso: n condici6n de aIormo encontrado
n
.
Prioridod:
Oisponible en;
Prioridad moderacla, que se
impiemenlQr6 despue. de 10.
Funciones b6sicos.
EI tercer incremento.
Frecuencia de uso: Poco frecuente.
Conal hacio el odor: A troves de un browser bosodo en
PC y conexi6n de Internet al sitio
web de HogarSeguro.
Adores secundarios: Administrodor del sistema,
comoros.
Canales hacia los adores secundarios:
1. Admi[listrador del sistema: ~ i s t m o basodo en PC.
2. Camaras: conectividad inalombrica
208 PARTE DOS pRACTICA DE LA INGENIERlA DEL SOFrVVARE
Aspectos pencli.nles: 3. ilo respuesta del sistema via Internet ser6 ac:epkIhIe
dado el ancho de banda requerido para las vistas
de cornaro?
1. aCu61 es eI meconismo que protege contro el usc no
autorizado de esfa capacidad pa' parte de los
empIeados de Ia campania? 4. iSe desorrollor6 uno capacidod para proporcionor
video a una tosa mayor de cuodros pot' segundo
cuando esten disponibles conexiones con
oncho de banda?
2. ela seguridod $$ sofidente? EI ingreso no outorizodo
en esta carocteristico representario una invasi6n
impartanle de Ia privocidod .
. MI,}!.!!,) &1
t (uando se han
terminodo de escribir los
(Osos de usa? POf{! uno
exposici6n volioso de
asle t6piro, veose
ootips.org/

hlmloo!ip org/
use-cases'1ione.
hlml.
Diagrama
prellminar de
casode uso
para el
sistema
HogarSeguro.
En muchos casas no es necesario crear una representacion gratica de un escena-
rio de lisa. Sin embargo, la representacion diagramatica puede facilitar 1a compren-
sian, en particular cuando el escenario es complejo. Como se mendono en el capi-
tulo 7, el UML proporciona una capacidad para hacer diagram as de casos de uso pre-
liminar para eJ producto HogarSeguro. Cada caso de uso se representa mediante un
6valo. En esta secci6n 5610 se ha examinado en detalle el caso de uso para eJ ACV-
DVe.
8.5.2 Desarrollo de un diagrama de actividad
EI diagrama de actividad en UML (que se trat6 en forma breve en los capitulos 6 y 7)
complementa el caso de uso aJ proporcionar una representaci6n gni.fica del flujo de inte-
raedon dentro de un escenario especifico. De manera similar al diagrama de flujo,
un diagrama de actividad utili za rectimgulos redondeados para indicar una funcian
especifica del sistema, flechas para representar el flujo a traves del sistema, rombos
de decision para mostrar una ramificacian por decision (cada flecha que sale del
rombo se eliqueta), y lineas horizontales s6lidas para indicar que ocurren activida-
des paralelas.
\
Propielario
de 10
coso
HogorSeguro
Camoras
,
Diagrama de
actlvidad
para la
funcionde
acceso a la
cCanara de
vigUancia-
despliegue
de vistas de
camara.
Un diagrama de
ocnvidad en UMl
representa las acciones
y decisiones que
ocurren mientros se
realiza alguna fund6n.
CAPITULO 8 MODELAOO DEL ANALISIS
Introducir contrasefia }-______ ---,
e ID del usuario
Contrasefias/ID v61idas Contrasefias/ID no validas
Opcion para
Tambien se pueden
seleccionar
otras funciones
Vistas en miniatura
Solir de esta funci6n
No reston
intentos de entrada
Seleccionar una
camara especifico
Ver olro camara
209
En la figura 8.7 se muestra un diagrama de actividad para la funci6n de ACV-
DVC. Se debe resaltar que el diagrama de actividad agrega detalles adicionales que
no se men cion an de manera directa (pero si implicita) en el caso de uso. Por ejem-
pIo, un usuario puede intentar ingresar la IDusuario y la contrasefta s610 un nume-
ro limitado de veces. Esto se representa mediante un rombo de decisi6n debajo de
opcion para reingreso.
8.5.3 Diagramas de ccmil
El diagrama de earni de UML es una variaci6n util del diagrama de actividad, ya que
permite al modelador la representaci6n del flujo de actividades descritas por el caso
de usc y, al mismo tiempo, indicar que aClor (si hay multiples actores involucrados
en una funci6n especifica) 0 clase de analisis tiene la responsabilidad de la acci6n
descrita mediante un rectangulo de actividad. Las responsabilidades se representan
210 PARTE DOS PAAcnCA DE LA INGENIERiA DEL SOFIWARE
Diagrama de carrU para la func16n de Acceso a la c6:mara de vigilancia-despUegue de
vistas de camara.
Propietario Comara Interfaz
,
Introducir controseno'\.
e 10 del usuorio
.J
Conlrosenas/IO volidas

Conlraseiias/ID
( Seleccionor una no validas
funci6n importante J
Tambien se ___
I
(oPCi6n para reingres<)
pueden

inlenlos
olras
Seleccionor
@
e enlrodo
funciones
No reston
intentos de entrada
" ... -A'-,","
miniatura cornaro especifico
I (Seleccionar una camara
Selecdonar un )
espedfica-vislas
kono de camara
I \. en
I I
r Generor solido
)
( Visto de salida de camara

de video
Opci6n
)
en uno ventana eliquetodo..J
"-
para olro vista
Solirde A
.-=eslo funci6n

Ver olro
cornaro
como segmentos paralelos que dividen el diagrama en forma vertical, como los
carriles de una alberca.
Un diDgtamD d,
wniles en UMl
representD ,I fluiD d,
las acciones y las
dedsiones e indica
cuales oelores reolizon
woo uno de ,liDS.
Existen tres clases de analisis - Propietario, Interfaz y Camara- con responsa-
bi lidades directas 0 indirectas en el contexto del diagrama de actividad representado
en la figura 8.7. Respecto de la figura 8.8, el diagrama de actividad se reorganiza de
forma que las actividades asociadas con una c1ase de analisis particular pertenezcan
al carril correspondiente a dicha clase. Por ejemplo, la clase Interfaz representa la
interfaz con el usuario de acuerdo con la vision del propietario. El diagrama de activi-
dad considera dos opciones que son responsabilidad de la interfaz: opcion para eJ rein-
tc'ONSUO.
JJgunas pe5anas
sogieren que elOFO
es de "I"ieia
escue/a" y que no
hene siha en hJ
prodico I1Klfieml1.
Es10 es uno vision que
exdaye uno forma de
representocion poten-
cialmente uhl 01 nivel
de analisis. 5i es de
oyudo, se recomiendo
desempleor el om
CAPiTuLo 8 MODELADQ DEL ANALISIS 211
greso y opeion para otra vista. Estas opciones y las decisiones asociadas con elias per-
tenecen al carril de Interfaz. Sin embargo, las fiechas conducen desde ese carril de
regreso al carril de propietario, don de ocurren las acciones del propietario.
EI modelado de datos orientado al fiujo es una de las notaciones de analisis utiliza-
das con mayor amplitud en la actualidad.
13
Aunque el diagrama de jlujo de datos
(DFD) y los diagramas y la informacion relacionados no son una parte formal de
UML, pueden utilizarse para complementar los diagramas en UML y proporcionar un
conocimiento adicional de los requisitos y el flujo del sistema.
EI DFD tiene una vision del sistema del tipo entrada-proceso-salida. Esto es, los
objetos de datos lluyen hacia el interior del software, se transforman mediante ele-
mentos de procesamiento, y los objetos de datos resultantes ll uyen al exterior del
software. Los objetos de datos se representan mediante fiechas rotuladas y las trans-
formaciones se representan por medio de circulos (tambien Ilamadas burbujas). EI
DFD se presenta en una forma jerarquica. Esto es, el primer modelo de flujo de datos
(algunas veces Ilamado un DFD de niveJ 0 0 diagrama de contexto) representa el sis-
tema como un todo. Los diagramas de fiuj o de datos subsecuentes refinan el dia-
grama de contexto, ya que proporcionan una cantidad creciente de detalles con cada
nivel subsiguiente.
-0 prop6silo de los diagramas de fluio de datos as proporcionar un puente semantico entre los usuarios y los
desorrolladores de sistemas."
8.6.1 Creaci6n de un modelo de flujo de datos
EI diagrama de fiujo de datos permi te que el ingeniero de software desarrolle mode-
los del dominio de informacion y del dominio funcional al mismo tiempo. A medida
que el DFD se refina hacia grados mayores de detalle, el analista desempeiia una
descomposici6n funci onal implicita del sistema. Al mismo tiempo, el refinamiento
del DFD resulta en un correspondiente refinamiento de datos mientras se mueve
hacia los procesos que incorporan la aplicacion
Unas pocas directrices simples permiten obtener una ayuda invaluable durante la
creacion de un diagrama de flujo de datos, I ) el nivel 0 del diagrama de flujo de datos
debe representar al software/ sistema como una sola burbuja; 2) la entrada y la sali -
da prima ria deben establecerse con cuidado; 3) la refinacion debe comenzar por el
aislamiento de procesos, objetos de datos y almacenamientos de datos candidatos a
ser representados en el siguiente nivel; 4) todas las flechas y burbujas se deben rotu-
lar con nombres significativos; 5) se debe m ~ n t n r la continuidad del flujo de infor-
13 EJ modelo de flujo de datos es una actividad de modelado esenciaJ en el andlisis estructurado.
212
DFD aI nlve1
de contexto
para la
funcion de
segurtdad de
HogarSeguro.
L, connnuid,d del flui'
de informnci;n debe
montenerse conforme
se renna coda nivel del
OFO. Est, signinco que
I, entr,d, y solid, en
un nivel deben ser los
mismos que 10 entrada
y solido en un nivel
rennod,.
PARTE DOS pRAcnCA DE LA rNGENIERlA DEL SOITWARE
Ponel
Comondos y dolos Despliegue
Despliegue
del panel
de control
del usuorio de informacion
de control
Tipo
B
de alarmo
Estatus
Linea
$ensores
del sensor
numero telef6nico
telefOnica
macion al cambiar de nivel a nivel; 14 y 6) la refinacion de las burbujas debe hacerse
una por una. Existe una tendencia natural a complicar de mas el diagrama de Oujo
de datos. Esto ocurre cuando el analista intenta mostrar muchos detalles demasia-
do pronto 0 representar aspectos de procedimiento del software en lugar de ele-
mentos del Oujo de informacion.
EI uso del DFD y de la notacion rel acionada se ilustra de nuevo considerando la
funcion de seguridad en el hogar de HogarSeguro. En la figura 8.9 se muestra un DFD
al nivel de contexto para la funcion de seguridad. Las entidades externas primarias
(cajas) producen informacion para el usa del sistema y consumen informacion que
este genera. Las fiechas rotuladas representan objetos de datos a jerarquias de obje-
tos de datos. Por ejemplo, comandos y datos del usuario abarcan todos los
comandos de configuraci6n, todos los comandos de activacion/desactivacion, todas
las interacciones y todos los datos que se ingresan para cali ficar a expandir un
camando.
EI DFD de nivel 0 ahara se expande a un modelo de flujo de datos de nivel I . <Pero
como se logra esto? Un enfoque simple, pero efectivo, es realizar un "analisis gra-
matical" [ABB83] sabre la narrativa que describe la burbuja al nivel de contexto. Esto
es, se aislan todos los sustantivos y verbos en la narrativa de procesamiento de
HogarSegurol5 obtenida durante la primera reunion para la recopilacion de requisi-
tos. Can propositos ilustrativos, considerese el siguiente texto narrativo de procesa-
mien to can la primera aparicion de todos los sustantivos subrayados y la primera
aparici6n de todos los verbos en italicas.
16
14 Esto es, los objetos de datos que fluyen hacia el sistema 0 eualquier transformaci6n en algun nivel,
deben ser los mismos objetos de datos (0 sus partes eonstituyentes) que fluyen hacia la transfor-
maei6n en un nivel mas refinado.
15 Una narrativa del proeesamiento es similar en estilo al easo de usc, pero algo diferente en prop6-
sito. La narrativa del proeesamiento proporeiona una descripci6n general de la funci6n que sera de-
sarrollada. No es un eseenario eserito desde el punto de vista de alguno de los aetores.
16 Debe notarse que se omiten los sustantivos 0 verbos que son sin6nimos 0 que no tienen una inge-
rencia direeta en el proeeso de modelaci6n. Tambien se debe notar que, euando se eonsidere el mo-
delado basado en clases de la seeci6n 8.7, se usara un analisis gramatieal similar
tc'ONSEJO"
EI analisis gromancal
no 85 a pruebo de
errores, pero puede
proporcionar un
excefente paso inicial
wando existe alguna
difiwl/ud para delinir
abjetas de datas y las
transformociones que
operon sabre elias.
DFD de nivel 1
para la funci6n
de seguridad de
HogarSeguro.
CAPiTULO 8 MODELADQ DEL ANALISIS 213
La funci6n de seguridad de HogarSeguro pennite al pro12ietarjo configurar el sistema de se-
cuando este se instala, monitorear todos los sensores que se coneclan al sistema
de seguridad y que inleracluan can el propietario a traves de In.t..e.r.nct, una K 0 un
de controL
Durante la instalaci6n, la PC de HogarSeguro se utiliza para programar y configurar el
A cada sensor se Ie asigna un m!m..e.m y tipQ, se programa una coolrasena ma-
para habjijtar 0 deshabi}jtar el sistema, y algunos numeros telef6nico$ ingresan para
marcarse cuando se presenta un even to en los sensores.
Cuando se reconoce un even to en los sensores, el software soJicita una alarma audible
que el propietario especifica durante las actividades de configuracion del sistema, el soft-
ware marca el numero telefonico de un servicio de monitoreo, proporciona informacion
acerca de la ubicacjOn, reporla la naturaleza del evento que se ha detectado. El numero
telefonico se remarca cad a 20 segundos hasta que se abilene una conexion telef6nica,
El propietario recibe informaci6n de seguridad a traves de un panel de control, la PC a
un buscador que en forma colectiva se denomina una i.nt..e.rfaz.. La interfaz despliega men-
sajes de opcj6n e informacion del eslalus del sistema en eJ panel de control, la PC 0 la veo-
tana del buscador. La interacci6n del propietario asume la siguiente forma ..
En relacion can el analisis gramatical comienza a surgir un patron. Los verbos son
los procesos de HogarSeguro; esto es. al final pueden representarse como burbujas
en un DFD subsecuente. Los sustantivos son entidades externas (cajas), objetos de
datos a de control (flechas), a almacenamientos de datos (lineas dob!es). Oespues
debe observarse que los sustantivos y verbos se puedan asociar de distintas formas
......_ ... , ........ Configuraci6n
de aatos
Procesar
contrasena
Mensale
de ID va ido
Configuraci6n
de oatos
Sensores 1---."...,...,---1
Estatus
del sensor
sensores
Configuraci6n de informaci6n
Despliegue
.....,===-1 del panel
de control
\
=-__ __ del sensor
Tipo de cilarma
T onos del numero
telefonico
linea
telefonica
214
OFD de nivel 2
que refina el
procesode
monitoreo
de sensores.
fl'ONSlJO"
Se debe tener 10
segur;dod de que rodo
fo narrafiva de prOCfr
samiento Que se
intenta anolizar e5th
escrifa con el mismo
grado de obslro((;On.
PARTE DOS PAAcnCA DE LA LNGENIERiA DEL SOFTWARE
Informacion de configuroci6n
Datos
de configuraci6n
Estatus
del sensor
ID,Iipo
de sensor
Informacion
del sensor
Numero
telef6nico
Mercer
lelMono
T;r.
alorma
Tonos de numeros
telef6nicos
entre 51. Por ejemplo, a cada sensor se Ie asigna un numero y un tipo; por 10 tanto,
el numero y el tipo son atributos del objeto de datos sensor. Entonces, al realizar un
anali sis gramatical sobre la narrativa de procesamiento para una burbuja en cual-
quier nivel del DFD, se puede generar mucha informaci6n uti I acerca de c6mo pro-
ceder con la reflnaci6n para el siguiente nivel. En la figura 8.10 se presenta un DFD
de nivel I para el cual se ha utilizado esta informaci6n. EI proceso al nivel de con-
texto mostrado en la figura 8.9 se ha expandido a seis procesos obtenidos de un exa-
men del analisis gramatical. De manera similar, el flujo de informaci6n entre los pro-
cesos en el nivel I ha sido obtenido del analisis. Ademas, se mantiene la continui-
dad del flujo de informaci6n entre los nivel es 0 y I.
Los procesos representados en el DFD de nivel I se refinan despues hacia niveles
mas bajos. Por ejemplo, es posible reflnar el proceso monitorear sensares hacia un
DFD de nivel 2 como se muestra en la figura 8. 1 I . De nuevo, debe sefialarse que se
mantiene la continuidad del flujo de informaci6n entre los niveles.
La refinaci6n de los DFD continua hasta que cada burbuja reali za una sola fun-
ci6n; es decir, hasta que el proceso que representa la burbuja desempefie una funci6n
que podria implementarse con facilidad como un componente de programa. En el
capitulo 9 se examina un concepto, lIamado cohesion, con el cual se evalua la si m-
plicidad de una funci6n dada. Por ahora, se busca refinar los DFD hasta que cada
burbuja tenga "un solo significado".
8.6.2 Creaci6n de un modelo de control del flujo
En muchos tipos de apli caciones el modelo de datos y el diagrama de flujo de datos
son todo 10 que se necesita para obtener una visi6n significativa de los requisitos del
lComo se
seleccionan
105 eventos
pOlencioles para
un diagrama de
,onlrol delll.jo,
un diagrama de
eSlado 0 una
especificacion de
(antral?
CAPITULO 8 MODELADO DEL ANAuSIS 215
software. Sin embargo, como ya se ha mencionado, existe una clase muy grande de
aplicaciones que estan guiadas por eventos en lugar de datos, que producen infor-
macion de control en lugar de reportes 0 despliegues, y que procesan informacion
con un especial interes por el tiempo y el rendimiento. Dichas aplicaciones requie-
ren apli car el modelado de control del flujo, ademas del model ado del flujo de datos.
Va se ha mencionado que un even to 0 elemento de control se implementa como
un valor booleano (por ejemplo, verdadero 0 falso, encendido 0 apagado, 1 0 0) 0
una lista discreta de condiciones (vacio, saturado, lIeno). En la seleccion de los even-
tos que son candidatos potenciales se sugieren las siguientes directrices,
Hacer una lista de todos los sensores que el software "lee".
Listar todas las condiciones de interrupcion.
Li star todos los "interruptores" que maneja un operador.
Ustar todas las condiciones de datos.
De acuerdo con el analisis de sustant ivos y verbos aplicado a la narrativa de
procesamiento, revisar todos los "elementos de control" como posibiJidades
de entradas y salidas del control de flujo.
Describir el compartamiento de un sistema mediante la identificaci6n de sus
estados; determinar el grado en el que se alcanza cada estado, y definir las
transiciones entre los estados.
Enfocarse en posibles omisiones - un error muy camon al especificar el
control-; por ejemplo, se puede preguntar, "<existe alguna otra manera de
alcanzar este estado 0 salir de eI
7
" .
8,6.3 Especificacion de control
La especijicaci6n de control (EC) representa el comportamiento del sistema (en el
nivel desde el cual esta referido) de dos maneras diferentes. 17 La EC contiene un dia-
grama de estado que es una especificacion secuencial del comportamiento. Tambien
puede contener una tabla de activacion del programa, una especificacion combina-
toria del comportamiento.
En la figura 8.12 se muestra un diagrama de estado preliminar
l8
para el modelo
de control del flujo en el nivel 1 para HogarSeguro. EI diagrama indica como responde
el sistema a diferentes eventos conforme este atraviesa los cuatro estados definidos
en este nivel. AI revisar el diagrama de estado, un ingeniero de software puede
determinar el comportamiento del sistema y, aim mas importante. puede encontrar
si existen "hoyos" en el comportamiento especi ficado.
17 Despues, en este mismo capitulo, se presenta notaci6n adicional para el modelado del comporta-
miento.
18 La notaci6n para el diagrama de estado se rrlUestra aqui de confonnidad con la notaci6n del UML.
En el analisis estructurado se cuenta con un "diagrama de transici6n de estado", pero el formate del
UML es superior en contenido y representaci 6n de informaci6n.
216 PARTE DOS PAAcrTCA DE LA JNGENIERIA DEL SOITWARE
Di agrama de estado para la funcion de seguridad de HogarSeguro.
-
Reinido Sistema DesO(upodo
correcto
Inlerruptor
Entror/inicior
Enlrorjinicior Estoll.lssistemo "inocliVQ'
in icie/para,
Entrorjinicior despliegueMensoje 1
Reinicio
Enlror/inicior despliegueMensojel
encendido
Nlniciondo sistemo"
Entrar/ini<:ior despliegueMensaje2 ...
Entrar/iniciar despliegueMensoje2
Entrar/iniciar despl iegueEstatvs estable
"POI" favor espere"
GolpedetedolTedodemonejo
Enlror/iniciar despliegueEstolus deslello
lenlo
Hoeer: correr diognoslicos
I Activor
I
apagado/control 1
Apogodo
Fol loDetectodo/ inic iar
I
despliegueMensaje2 "conlodar
01 Yendedor"
MonitoreoEstatusSistema
Entror/inicier EsloltJ!.!;istema
Entrm/iniciar despliegueMensojel NArmado"
Enlrer/inieior despliegueMensaje2 N.
Enlrar/inieior despliegueEsfotus esloble
Haeer: monitorearYConlrolarSblema
Golpedetedo/Tedademonejo
desoctivorControsena @
fa lsaAlarma
tiempoFuero
sensorDisporodo/
ioie io Temporizodor
desact ivorControseiio
AccionEnAlarma
Enlrm/inieiar
"moniloreoYAlarmo'
Enlrar/inieiar despliegueMensojel

EOlrar/ioieiar despliegueMeosaje2
disporadordeSensor
Entrar /inicior despliegueEstotus
Destellorapido
Hoeer: mon[loreorYConlrolarSi5lemo
Hoeer: sooidodeAlorma
Haeer: notifiearRespuestoAiormo
GolpedetedofTeclodemanejo
U
sensorDisparodo/
reinieio Tern porizador
Por ejemplo, el diagrama de estado (figura 8.1 2) indi ca que las transi ciones desde
el estado desocupado pueden ocurrir si el sistema se rei nicia, acti va 0 apaga. Si el sis-
tema se activa (es decir, se enci ende el si stema de ai arma) ocurre una transicion
haci a el estado MonitoreoEstatusSistema, los mensajes que se despli egan cambi an,
como se muestra, y se solicita el proceso SistemaControiyMonitoreo. Con el estado
Monitoreo Stratus Sistema ocurren dos transiciones: 1) al desacti var el sistema se pre-
senta una transicion de regreso al estado desocupado; 2) cuando se dispara un sen-
sor ocurre una transicion hacia el estado Acci6nEnAlarma. Durante la revision se
consideran todas las transici ones y el contenido de todos los estados.
HOGARSEGURO
Modelado del flujo de datos

EI escenario: Cubfculo de Jamie,
despues de que ho conduido 10 ultimo reuni6n para 10
recopilaci6n de requisilos.
La conversaciOn:
Los actores: Jamie, Vinod y Ed, miembros del equipo
de ingenierfo del soHwore de HogorSeguro.
(Jamie ho bosquejodo los modelos que ",fIIUIIISInm_ ;
los 8.9, 8.10, 8.11 Y 8.12 Y ",los
Vinod).
Jamie: Tome un curso de ingenierio det software en to
universidad, y ahl aprendl estos cosos. EI profewr dijo
CAPITULO 8 MODELADO DEL ANALISIS 217
oslO un poco posado de modo, pero ,soben
"iI 'CIJIIda a dorificar las rosas.
Ed: ,De verdad?
Jamie: Sf, pero primero debemos desorroUar un modelo
de anolisis completo, y este no 10 es.
No, esto es s6Io un modelo de Aujo con algunos
c ..... II1Ic .. die comportomiento induidas.
Vinod: Bueno, es un primer paso. Pero vamos a tener
que obordor elementos basodos en clases y tambien
aspectos del comportamiento, ounque este diogromo de
estodo hace olgo de eso.
Ed: Tenemos mucho trobajo por hacer y no mucho
tiempa para hacerlo.
11.'1. '"--- En!rodaproceso-solida. En ceot;dad los DFD son
r ... .,lvitiv<>s ... Si los observos par un momento,
(Doug --el gerente de ingenierio del software- entra en el
cubfculo.)
I
k : : : ' ~ 10 forma en que los objetos Auyen a troves del
c6mo estos $8 transformon.
Doug: Entonces, alas primeros dios estoron dedicados 01
desarrollo del modelo de on6lisls, eM
Parece como si pudieromos convertir codo burbuja
Ii" '""$O'"p'",ente ejecutobJe. .. . 01 menos en el nivel mas
Jamie (con orgullo): Yo comenzomos.
Doug: Bien, tenemos mucho trabajo par hacer y no
mucho tiempo para hacerlo.
1iIii,&,..1o mejor porte, 51 '" puede. De hecho,
forma de traducir los OFO a uno arquitectura (los tres ingenieros de software se miran entre Sl y
sonden.)
lo especificocion de
proceso es uno
a miniespecificocion"
poro codo
tronsformocion en el
nivel menos refi nodo
de un OFD.
La EC describe el comportamiento del sistema, pero no brinda informacion acer-
ca del trabajo interior de los procesos que activa. La notaci6n de modelado que pro-
porciona esta informaci on se estudia en la seccion 8.6.4.
8.6.4 Especificacion de proceso
La especijicacion de pmceso (EP) se utiliza para describir todos los procesos del
modelo de flujo que aparecen en el nivel final de refInaci6n. EI contenido de la espe-
cificacion de proceso puede incluir texto narrativo, una descripcion en lenguaje de
diseno de programas (LDP) 19 del algoritmo del proceso, ecuaciones matematicas,
tab las, diagramas 0 grafIcas. AI proporcionar una EP para acompanar cada burbuja
en el modelo de flujo, el ingeniero de software crea una "miniespecificacion" que
puede servir como guia para el diseno del componente del software que implemen-
tara el proceso.
Para ilustrar el uso de la EP, considerese la transformacion procesamiento de con-
traseila representada en el modelo de flujo para HogarSeguro (fIgura 8. 10). La EP para
esta funcion pod ria tomar la forma:
EP: procesamiento de contraseii.a (en el panel de control). La transformacion pro-
cesamiento de contrasena valida la contrasena en el panel de control para la funci6n de se-
19 El lenguaje de diseno de programas (LOP) mezcla la sintaxis dellenguaje de programaci6n con la
narrativa en texto para proporcionar detalles del diseno de! procedimiento El LDP se estudia en el
capitulo 11.
218 PARTE DOS PAAcnCA DE LA INGENIERiA DEL SOrtWARE
de HogarSegurb. El procesamiento de contraseila recibe una contrasena de cuatro
digitos a partir de la funci6n de interacci6n con e/ usuario. La contrasei'ia se campara pri -
mera con la contrasefia maestra almacenada en el sistema. 5i la contrasefia maestra coin-
cide [Mensaje de ID valida = verdaderoj se pasa a la funcion de mensajey despliegue deJ
estatus. Sf \a contrasefia maestra no coincide, se campa ran los cuatro digitos con una ta-
bla de contrasefias secundarias (estas se pueden aSignar a invitados 0 trabaj adores que
necesitan entrar en 1a casa cuanda el propietario no Si \a contrasena coincide con
alguna entrada dentro de la tabla [mensaje de Id valida = verdaderoL se pasa a 1a funci6n
de mensaje y despliegue del estatus. Si no existe alguna coinci dencia [mensaje de Id valida
= fa Iso], se pasa a la funci6n de mensaje y despliegue del estatus.
Si en esta etapa se desean tener detalles algoritmicos adicionales, se pod ria incluir
tambien una representaci6n en lenguaje de diseiio de program as como parte de la
EP. Sin embargo, muchos profesionales del software creen que la versi 6n en LDP se
puede posponer hasta que comience el diseiio de componentes.

AnCrIisis estructurado
Objetivo: los herromientos del onolisis
estructurodo oyudon a un ingeniero de softwore
o crear modelos de datos, modelos de Huio y modelos de
comportomiento de uno monero que permito 10
verificocion de 10 conlinuidod y 10 consistencio, osl como
su focil edicion y extension. Los modelos creados utilizondo
estos herramientos brindon 01 ingeniero de software una
vision de 10 representoci6n del onolisis y oyudon 0
eliminar errores ontes de que estos se propaguen en el
diseno 0 , oun pear, en 10 m'ismo implementocion.
Meccmica: Los herramientas de esto categoria utilizon un
Ndiccionario de datos
N
como 10 bose de dotos centrol paro
10 descripcion de todos los objetos de datos. Uno vez que
los entrodos del diccionorio eston definidos, pueden
crearse diagramas de entidad-relacion y se pueden
desorrollor los jerorquias de obietos. Las corocteristicas de
diagramacion del Huio de datos permiten crear focilmente
este modelo grofico y tambien proporciona caracteristicos
para 10 creaci6n de especificaciones de control lEe) y
especificaciones de proceso (EPj. Las herromientas de
onolisis tombien ayudon 01 ingeniero de software en 10
creacion de modelos de compartamiento que usan los
diagramas de estado como notacion operativa.
Herramientos representativas
20
AxiomSys, desarrollado por STG, Inc. (www.slgcase.comj,
proporciona un paquete completo de herramientas
pora el onolisis de 10 estructura que incluye extensiones
de Hartley-Pirbhai para el modelado de sistemas en
tiempo real.
MacA&D, WinA&D, desarrollados par Excel Software
(www.excelsoftware.coml, proporcionan un conjunto
de herromientas simples y berotas para el anolisis y el
disei'io en moquinas Mac y Windows.
MetaCASE Workbench, desarrollado par Metocose
Consulting (www.metacase.com) es uno
metoherramiento uti lizada para definir un metodo de
anol isis 0 diseno (incluide en onolisis estructurodo): sus
conceptos, reglos, notaciones y generadores.
Sysfem Architect, desarrollado por Popkin Software
(www.popkin.com). proporciena un amplie range de
herramientos de onolisis y disei'io, incluye herromientas
para el modelado de dolos y el onolisis estructurodo.
20 Las herramientas mencionadas aqui representan una muestra de esta categoria. En la mayoria de
los casas los nombres estan registrados par sus respectivos desarrolladores.
CAPITULO 8 MODELADO DEL ANAuSlS 219
8.7 MOnlLAnO DASAnO IN eLASls
,De qui
forma se
manifiestan a si
mismos las doses
de analisis (omo
elementos del
espa,io de solu-
cion?
"Que se debe hacer para desarrollar los elementos basados en clases de un modelo
de analisis, clases y objetos, atributos, operaciones, paquetes, model os CRC y dia-
gramas de colaboraci6n? Las secciones siguientes presentan una serie de directrices
informales que ayudaran a identificarlos y representarlos.
8.7.1 Identificacion de clases de anruisis
AI observar el interior de una habitaci6n se vera que existe un conjunto de objetos
fisicos que pueden identifiearse. clasificarse y definirse con facilidad (en terminos de
atributos y operaci ones) . Pero cuando se "observa" el espacio del probl ema de una
aplicaci6n de software, quiza las clases IY los objetos) sean mas dificiles de com-
prender.
' 8 problemo reolmente difidl es dOSl.brir lUales son los objelDS ,0"ectDS [doses] en primer lugor:
Se puede iniciar la identificaci6n de clases al examinar el enunciado del proble-
ma 0 (de acuerdo con la terminologia aplicada previamente en este capi tul o) al rea-
lizar un "analisis gramatical" sobre las narrativas desarrolladas para el sistema que
se va a construir 0 de los casos de uso. Las clases se determinan al subrayar cada
sustantivo e introduciendolas en una simple tabla. Los sin6nimos deben anotarse. Si
la clase se requiere I?ara implementar una soluci6n, entonces es parte del espacio de
solucion; por otro lado, si una c1ase solo se necesita para describi r una soluci6n es
parte del espacio del problema. "Que se debe buscar despues de que todos los sus-
tantivos han side aislados? Las clases se manifiestan en una de las siguientes formas:
Entidades externas (por ejemplo, otros sistemas, dispositivos, personas) que
producen 0 consumen informacion que usara un sistema basado en compu-
tadora.
Casas (por ejemplo, reportes, despliegues, letras, senales) que son parte del
dominio de l a informaci6n para el probl ema.
Sucesas a eventos (por ejemplo, una transferencia de propiedad 0 la consecu-
cion de una serie de movimientos de robot) que ocurren dentro del contexto
de la operaci6n del sistema.
PapeJes (por ej emplo, gerente, ingeniero, personal de ventas) que desempenan
personas que interactuan con el si stema.
Unidades organizaci onales (por ejemplo, divisi6n, grupo, equipo) relevantes
para alguna aplicaci6n.
Sitios (por ejemplo, el piso de manufactura 0 el puerto de cargal que esta-
blecen el contexto del problema y la funci6n global del sistema.
220 PARTE DOS PAAcnCA DE LA INGENIERlA DEL SOITWARE
Estructuras (por ejemplo,.sensores, vehiculos de cuatro ruedas 0 computadoras)
que dennen una clase de objetos 0 clases de objetos relacionadas.
Esta categorizacion es una de las muchas que se han propuesto en la bibliografia.
21
Por ejemplo, si los desarrolladores del software para un sistema de observacion
medica definen un objeto con el nombre de Imagenlnvertida 0 Inversi6ndeImagen,
podrian estar cometiendo un error suti!. La Imagen obtenida del software podria,
par supuesto, ser una clase (es una cosa integrante del dominic de la informacion) .
La inversion de la imagen es una operaci6n que se aplica a 1a c1ase. Probable mente,
1a inversion( ) se definiria como una operaci6n para la clase Imagen, pero no se esta-
bleceria como una clase diferente para connotar "inversion de imagen". Como esta-
blece Cashman [CAS89] : "EI objetivo de la orientacion hacia los objetos es encapsu-
lar, pero aun as! mantener separados, los datos y las operaciones sabre los datos".
Para ilustrar 1a forma en que las clases de analisis pueden definirse durante las
primeras eta pas del model ado, se utili za de nuevo la funcion de seguri dad de
HogarSeguro. En la seccion 8.6.1 se realizo un "anali sis gramatical" sobre la narrati -
va del procesamiento
22
para 1a funci6n de seguridad. Al extraer los sustantivos se
puede proponer una serie de clases potenciales:
Clase potencial
propietario
sensor
panel de control
instolaci6n
sistema lali as sistema de seguridadJ
numero, tipo
controsena maestro
numero telef6nico
evento del sensor
olarmo audible
servi cio de moni toreo
Clasificacion general
popel 0 entidad externa
entidad externa
entidad externa
ocurrencia
coso
no objetos, otributos del sensor
coso
coso
ocurrenClo
entidad externo
unidod organizocionol 0 entidod externa
La lista pod ria extenderse hasta que todos los sustantivos en la narrativa del proce-
sami ento hayan side considerados. Observese que cada entrada en 1a !ista ha si de
21 Olra categarizaci6n impartante -la cual define entidad. frontera y clases de controladar- se exa-
mina en la secci6n 8.7.4.
22 Es importante notar que esta tecnica debe usarse tambien para todos los casas de uso desarro!la-
dos como parte de la actividad para la recopHaci6n de requisitos (obtenci6n). Esto es, los casos de
uso pueden analizarse gramaticalmente para extraer clases de analisis potenciales.
,Como se
determina
si una clase
pOlencial debe,
d. hecho,
(onvertirse en una
dase de analisis?
CAPiTuLo 8 MODELAOO DEL ANAuSIS 221
llamada como un objeto potencial. Cada uno de ellos debe considerarse a fonda
antes de tomar una decision final.
"las clases luchan, algunos doses triunfan, otras son eliminodos."
Mao Z.dong
Coad y Yourdon [COA9 11 sugieren seis caracteristicas de seleccion que se deben
usar cuando un analista considera cada clase potencial para incluirlas en el modelo
de anal isis:
1. Informacion referida. La clase potenci al sera uti! durante el analisis solo si la
informacion ace rca de ella debe recordarse para que el sistema pueda funcio-
nar.
2 . Servicios requeridos. La clase potencial debe tener un conjunto de operaciones
identiflcables que puedan cambiar el valor de sus atributos de alguna manera.
3. Alribulos muJlipJes. Durante el analisis de requisitos el enfoque debe estar en
l a informacion "importante"; una clase con un solo atributo puede, de hecho,
ser uti! durante el diseno, pero probablemente es mejor representarla como
un atributo de otra clase durante la actividad de anal isis.
4 . Alribulos comunes. Es posible deflnir un conjunlo de atributos para la clase
potencial , y estes atributos pueden apli carse en todas las instancias de la
clase.
5. Operaciones comunes. Es posible defini r un conjunto de operaciones para la
clase potencial , y estas operaciones pueden aplicarse en todas las instancias
de la clase.
6. Requisitos esenciales. Las entidades externas que aparecen en el espacio del
problema, y que producen 0 consumen informacion esencial para la opera-
cion de cualquier solucion para el sistema, se definiran casi siempre como
clases en el modele de requisitos.
Considerarla una clase legitima para incluirla en el modele de requisitos requiere
que una clase potencial satisfaga todas (0 casi todas) estas caracteristicas. La deci -
sion de incluir clases potenciales en el model e de analisis es alga subjetiva, y una
evaluacion posterior puede ocasionar que se descarte 0 reinstale una cJase. Sin
embargo, el primer paso del modelado basado en clases es la definicion de clases, y
se deben lomar decisiones (incluso subjetivas). Con eslo en mente, se aplican las
caracterislicas de seleccion a la lisla de clases pOl encial es de HogarSeguro:
Clase potencial
propietorio
sensor
ponel de control
Numero de caracteristica que aplica
rechozodo; 1 y 2 fallon ounque oplico 6
oceptodo todos oplicon
oceptodo: todos oplicon
222
los olribulos son al
coniunlo de obielas de
dolos que delinen por
o m ~ e l o 10 close
denho del conlexto del
problemo.
PARTE DOS pRAcnCA DE LA INGEN[ERJA DEL SOfTWARE
instoloci6n
sistema (olios funci6n de seguridodl
numera, tipo
conlrasena maestro
numero telef6nico
evenlo del sensor
olarmo audible
servicio de moniloreo
rechozodo:
aceptodo: lodos oplicon
rechazada: falla 3, alributos del sensor
rechozodo: folio 3
rechozodo: folio 3
oceplodo: lodos oplicon
aceplodo: aplicon 2, 3, 4, 5, 6
rechozodo: 1 y 2 fall an aunque oplico 6
Se debe senalar que I) la !ista anterior no esta com pi eta (se tendrian que agregar cla-
ses adicionales para terminar el modelo); 2) algunas de las clases potenciales recha-
zadas se convertiran en atributos para las clases aceptadas (por ejemplo, n"mero y
iipo son atributos de sensor, y contrasena maestra y numero telef6nico se pueden conver-
tir en atributos de sistema); 3) la existencia de enunciados diferentes del problema
pod ria ocasionar decisiones distintas de "aceptaci6n 0 rechalO" (por ejemplo, si cada
propietario tuviera una contrasena diferente 0 si pudiera identifi carse par su voz, la
clase Propietario satisfaria las caracteristi cas I y 2 Y esta habria sido aceptada) .
8.7.2 Especificacion de atributos
Los atributos describen una clase que ha side seleccionada para incluirla en el
modele de ana !isis. En esencia, los atributos son los que definen la clase, 10 cual cla-
rifi ca que significa la clase en el contexto del espacio del problema.
En el desarrollo de un conjunto de atributos significativo para una clase de ana!i-
sis un ingeniero de software puede estudiar de nuevo un casa de usa y seieccionar
aquellas "cosas" que "pertenecen" de manera razonable a la clase. Ademas, se debe
contestar la siguiente pregunta para cada clase: "Cuales elementos de datos (com-
puestos 0 elementales) definen esta clase en el contexto del problema?
Esto se ilustra considerando la clase sistema definida para Hogm5eguro. Se ha
mencionado que el propietario puede configurar la funci6n de seguridad para refle-
jar la informaci6n del sensor, informaci6n de la respuesta de alarma, informaci6n de
la activacion/ctesactivacion, informacion de la identificacion, y asi sucesivamente.
Estos elementos de datos compuestos se pueden representar de la siguiente manera:
informaci6n de idenfificaci6n = 10 del sistema + verificaci6n del numero telef6nico + estatus
del sistema
informaci6n de Ie respuesta de alarma = Hampo de raftaso + numera telef6nico
informaci6n de 18 activ8ci6nJdesactiv8ci6n = contrasene maestra + numera de intentos permi-
sibles + oontrasene temporal
Algunos de los datos a la derecha del signo de igual podrian refinarse hasta un nivel
elemental , pero para los prop6si tos de este capitulo constituyen una !ista razonable
de atributos para la clase sistema (parte sombreada de la figura 8.13) .
(uanda se delinen los
opefOciones para una
dose de an6lisis, el
enfaque debe eslar en
el comportamiento
"ienlada 01 fXobiema
y no en los comportcr
mientos requeridos
pora 10
dOn.
Diagramade
close para 10
clase del
sistema.
CAPiTULO 8 MODELADO DEL ANAuSIS 223
Los sensores son parte del sistema global de HogarSeguro, y aun asi no estan en-
Ii stados como elementos de datos 0 como atributos en la flgura 8.13. Ya se ha defl-
nido sensor como una ( lase, y varios objetos de sensor se asociarim con la clase
sistema. En general, se evita la defini cion de un elemento como un atributo si mas
de uno de los elementos se asociara con la clase.
8.7.3 Definicion de operaciones
Las operaci ones deflnen el comportamiento de un obj eto. Aunque existen muchos
tipos distintos de operaciones, "stas se pueden dividir, por 10 general, en Ires gran-
des categorias: I ) operaciones que manipulan l os datos de al guna manera (por ejem-
plo, al agregar, borrar, reformatear, sel eccionar), 2) operaciones que rea Ii zan un
computo, 3) operaciones que preguntan acerca del estado de un obj eto, y 4) opera-
ciones que monitorean un objeto para la ocurrencia de un evento de controL Estas
funciones se ejecutan al operar sobre atributos 0 asociaciones (seccion 8.7.5). Por 10
tanto, una operacion debe tener "conoci mi ento" de la natural eza de los atributos y
asociaciones de la clase.
Como una primera iteraci6n en la obtenci6n de un can junto de operaciones para
una clase de analisis, el analista puede estudi ar otra vez la narrativa de un procesa-
mien to (0 caso de uso) y seleccionar aquellas operaci ones que pertenezcan de
manera razonabl e a la c1ase. Esto se l ogra estudiando de nuevo el analisis gramati -
cal y aislando los verbos. Al gunos de estes verbos seran opciones legitimas y pod ran
conectarse con faci lidad a una c1ase especiflca. Par ejemplo, en l a narrativa del pro-
cesamiento presentada parrafos atras en este capi tulo, se observa que "al sensor se
Ie asigna un numero y un tipo" 0 lise programa una contrasena maestra para habiH-
tar y deshabilitar el sistema". Estas frases indican algunos hechos:
,
Sistema
ID sistema
verificaci6nNumeroTelef6nico
Eslatussistema
Tiemporelraso
Numerotelef6nico
Controseiiamaestra
Contraseiiatemporal
Numerodeintentos
programor( )
desplegarl)
reiniciar( J
buscor( )
.
modificor( J
lIamarl)
224 PARTE DOS pRAcnCA DE LA INGENlERIA DEL SOFTWARE
Que una operacion de asignar( ) es relevante para la clase sensor.
Que una operacion de programar( ) esta encapsulada por 1a clase sistema.
Que habililar( ) y deshabiIilar( ) son operaciones que se aplican a la clase
sistema.
En una investigacion posterior tal vez la operacion programar( ) sea dividida en una
serie de 5uboperaciones mas especificas que se requieren para configurar el sistema.
Par ejemplo, programar( ) implica la especificaci6n de numeros telefonicos, la confI -
guraci6n de caracteristicas del sistema (como al crear la tabla de sensores, al intro-
ducir las caracteristicas de la aiarma) y la introducci6n de contrasena(s). Sin embar-
go, par ahara programar( ) se especifica como una sola operacion.
HOGARSEGURO
..
Modelos de c1ase
B.
.. I .' EI escenario: Cubfculo de Ed, 01
comenzar el mocIelodo del anal isis.
Los adores: Jamie, Vinod y Ed, miembros del equipo
de ingenierfo del soft..vare de HogarSeguro.
La conversacion:
{Ed ho estodo trobojondo en 10 extracci6n de closes a
partir de 10 plontillo de coso de uso para el U Acceso a
la camara de vigilancia-despliegue de vistas
de camara" Ipresentado en un recuadro anterior en
este capitulo 1 y esla mostrando a sus colegas las closes
que ha extraido.
Ed: Entonces, cuando el propietario quiere escoger una
camara, el 0 ella debe elegirla de un plano de plonta. He
definido una clase lIamada PlanodePlanta. Aquf esla
el diagrama.
(Todos miran 10 figura 8.1 A.J
Jamie: Entonces PlanodePlanta es uno close que se
une a los paredes que estan compuestos por segmentos
de pared, puertas y ventonos, y tombien los comoros;
eso es 10 que significon esos Ifneas etiquetadas, ino?
Ed: 5i, esas lineas se lIaman "asociaciones". las doses
estcin asociadas entre sf de ocuerdo con las asociaciones
que les he mostrado. [las asociaciones se estudian en 10
seccion 8.7.5.1
l Vinod: Entonces el plono de planta real esta hecho de
I paredes y contiene comoros y sensores colocodos dentro
de estos paredes. ,C6mo sobe eI plono de pIan!o d&.d.
colocar esos objetos?
Ed; No 10 sabe, pero las otros doses sf. Miren 10$
atributos de abajo, digomos, SegmentosdePared, los
cuales se usan para construir uno pared. EI segmento de
pared tiene unas coordenadas de inido y flnalAy Ie
operocion de dibuio( ) hace el resto. ~
Jamie: Y 10 mismo pasa para los poertas y venkJna$.
Porece como si las comoros tuvieron unes pocOl de
otributos extra.
Ed: 5i, los necesito para poder dar 10 informaciOn del
movimiento y el acercamiento.
Vinod: Tengo uno pregunla. iPor que 10 camara tiene
uno ID, pero las otras clases no?
Ed: Vamos 0 necesitar identificar coda camoro para
propOsitos del despliegue.
Jamie: Tiene sentido para mi, pero tengo algunos otras
preguntos. (Jamie hace preguntas que resultan en
modificaciones menores.)
Vinod: iTienes tarjetas CRC para coda una de estas
closes? 5i es asf, debemos seguirlos, s610 hay que estar
seguros de que no se ha omitido nada.
Ed: No estoy seguro de como hacerlas.
Vinod: No es diffeil, y los resultados son muy buenos.
les mostrore.
Diagrama de
clasepara
PlanodePlanta
(Vease el
an6:l.isis en el
recuadro).
CAPITULO 8 MODELADO DEL ANAuSIS 225
,
PlanodePlanta
"po
nombra
Dimensionesexlernas
delerminarTIpo( )
posicionarPlanodePlantal )
escalar( )
cambiar color( )
Se ubica dentro de
~ I

Es parte de
Camara
Pared
reo
ti
Wmensionespared
ubicad6n
campodeVisi6n
Angulode Torno
Configurad6n
determinarTIpo( I
Acercamiento
calcularDimensiones( )
determinarTIpo{j
traducirUbicaClon( )
desplegarlD( )
Se usa para
desplegarVisto( )
construir
Se usa para
deplegarAcercamiento( J
~ ~ constru!r
I

Se usa para construir
I
~ m e n t o
de Pared
Ventana Ventana
tipo tipo tipo
Coordenadasinicio Coordenadasinido Coordenadasinicio
Coordenodasfinal Coordenadosfinal Coordenadasfinal
Siguienle$egmenlo
Pared
SiguienteVentano SiguienlePuerta
determinarnpo( ) delerminarTIpo( ) determinarTipo( J
dibujor dibujar dibujar
8.7.4 Modelado de Clase-Responsabilidad-Colaborador (CRC)
EI modelado de Clase-Responsabilidad-CoJaborador (CRC) [WIR90] proporciona un
medio simple para identificar y organizar las c1ases relevantes para los requisitos del
sistema 0 producto. Ambler [AMB95] describe el modelado CRe de la siguiente
forma,
Un modelo CRe en realidad es una colecci6n de tarjetas indice estandar que representan
clases. Las tarjetas se dividen en tres secciones. A 10 largo del borde superior de la tarjeta
se escribe el nombre de la c1ase. En el cuerpo de la tarjeta se listan las responsabilidades
de la clase a la izquierda y los colaboradores a ~ derecha.
En realidad, el modelo eRe puede utilizar tarjetas indice reales 0 virtuales. EI objeti-
vo es desarrollar una representacion organizada de las c1ases. Las responsabilidades
226
, !
Enwww.
IheuonkaIt._1
aG079 ..... puede
eJ]controrse uno
Gxcelenfe exposid6n
de e,1e ,po de (osos.
Una carta
indice del
modeloCRC.
PARTE DOS PAACTICA DE LA INGENlERlA DEL SOITWARE
son los atributos y las relevantes para la c1ase. Dicho de manera mas
simple, una responsabi!idad es "cualguier cosa gue la clase sabe 0 hace" [AMB95J.
Los colaboradores son aguellas c1ases gue se reguieren para gue una c1ase reciba la
informacion necesaria para completar una responsabilidad. En general, una colabo-
radon implica ya sea una solicitud de informacion 0 la solicitud de alguna acci6n.
Uno de los propOsilos de los torjetas CRC os follor 01 inieio, follor (On,tontemente y follor 'in que sea (0(0. Es mudlO
mils borata firor un bulla de Inrielos que reorganizar uno gran confided de (odigo Fuente."
En la figura 8.15 se i1ustra una tarjeta indice CRC simple para la c1ase Planode-
planta. La !ista de responsabilidades gue se muestra en la tarjeta CRC es preliminar
y esta sujeta a adiciones 0 modificaciones. Las c1ases Pared y Camara se anotan
enseguida de la responsabilidad gue reguerira su colaboracion.
Clases. Las directrices basicas para identificar c1ases y objetos ya se han presen-
tado en este mismo capitulo. La taxonomia de los tipos de clases gue se presento en
la seccion 8.7.1 se puede extender considerando las siguientes categorias:
Closes de entidad, tambien lIamadas c1ases de modele 0 negocios, se extraen
de manera directa del enunciado del problema (por ejemplo, Planodeplanta
y Sensor). De manera tipica, estas c1ases representan c1ases gue se almace-
naran en una base de datos y gue persisten durante la ap!icacion (a menos
gue se borren de manera especifica).
Closes de frontera. Se utilizan para crear la interfaz (por ejemplo, pantallas
interactivas 0 reportes impresos) que el usuario ve y con la cual interactua
cuando se utiliza el software. Las clases de entidad contienen informaci6n
Close: PlanodePlanta
Descripcion
Respansabilidad
Colabarador
Define el nombre/tipo del plano de planta
Maneja 10 posicion del plano de planta
Escala el plano de planta para su despliegue
Escala el plano de planta para su despl iegue
Incorpora paredes, puertas y ventanas Pared
Muestra la posicion de las camaras de video Camara
(uale,
directrices
pueden apli,arse
para la asignacion
de re'pon,abilida-
de, a la, d.,e,?
CAPiTuLo 8 MODELADQ DEL ANAuSIS 227
importante para los usuarios, pero no se despliegan a sl mismas. Las clases
de frontera estan disefiadas con la responsabilidad de manejar la forma en
que los objetos de entidad se presentan a los usuarios. Por ejemplo, una clase
de frontera lIamada VentanadeCamara tend ria la responsabilidad de
desplegar la salida de una camara de vigi l an cia para el sistema HogarSeguro.
Las closes de contra/odor manejan una "unidad de trabajo" IUML03j desde el
inicio hasta el finaL Esto es, las clases de controlador se pueden disefiar para
manejar 1)la creaci on 0 actualizacion de los objetos de ent idad; 2) la inme-
diatez de objetos de frontera conforme ,;stos obtienen informacion de objetos
de entidad; 3) la comunicacion compleja entre conjuntos de objetos; y 4)la
validacion de datos comunicados entre los obj etos 0 entre el usuario y la apli-
cacion. En general , las clases de controlador no se consideran si no hasta que
ha comenzado el disefio.
"Los objelOS pueden dosificorse de monerD cientifico en Ires grandes categories: los que no func:ionan, los que se
d05<Ompone. y las que so pierd :
IlSseI .....
Responsabilidades. En las secciones 8.7.2 y 8.7.3 se han presentado las directri-
ces basicas para identificar responsabilidades (atributos y operaciones). Wirfs-Brock
y sus colegas [WIR90j sugieren cinco directrices para determinar las responsabilida-
des de las clases:
1. La inteligencia del sistema se debe distribuir entre las c\ases para
abordar de mejor manera las necesidades del problema. Cada aplica-
cion abarca un cierto grado de inteligencia; esto es, 10 que el sistema sabe y
puede hacer. Esta inteligencia puede distribuirse entre las clases de varias
maneras diferentes. Las clases "poco inteligentes" (aquellas que tienen menos
responsabilidades) pueden modelarse para actuar al servicio de unas cuantas
clases "muy inteligentes" (las que tienen muchas responsabilidades). Aunque
este enfoque hace que el flujo de control en un sistema sea directo, tiene unas
cuantas desventajas: a) concentra toda la inteligencia en unas pocas clases, 10
que dificulta los cambios, y b) tiende a requerir mas clases, y por ende, un me-
jor esfuerzo de desarrollo.
5i la inteligencia del sistema se distribuye con mayor amplitud entre las
clases de una aplicacion, cada objeto sabe y hace solo unas cuantas cosas (las
cual es, por 10 general, son bien enfocadasl, y la cohesion del sistema mejora.
Lo anterior aumenta la facilidad de mantenimiento del software y reduce el
impacto de los efectos colaterales debidos al cambio.
Para determinar si la inteligencia "del sistema esta bien distribuida las res-
ponsabi li dades anotadas en cada tarjeta In dice del modelo CRC deben eva-
luarse y asl comprobar si alguna clase tiene una li sta de responsabilidades
228 PARTE DOS PRAcnCA DE LA lNGENIERiA DEL SOITWARE
demasiado larga. Est01ndica una concentraci6n de inteligencia." Ademas, las
responsabilidades para cada c1ase deben mostrar el mismo grado de abstracci6n.
2. Cada responsabilidad debe establecerse tan general como sea posi-
ble. Esta directriz implica que las responsabi li dades generales (tanto atribu-
tos como operaciones) deben estar en la parte alta de la jerarquia de la c1ase
(debido a que son generi cas son aplicables en todas las subclases) .
3. La informaci6n y el comportarniento relacionado con ella deben estar
dentro de la misma clase. Con esto se logra el principio 00 lIamado encap-
sulaci6n. Los datos y los procesos que manipulan los datos deben empaque-
tarse como una unidad cohesiva.
4. La informaci6n relativa a una cosa debe localizarse con una sola
clase, no distribuirse entre muchas de elias. Una sol a c1ase debe tomar
la responsabilidad de almacenar y manipular un tipo especifico de informa-
ci6n. En general, esta responsabi lidad no se puede compartir entre varias cla-
ses. Si la informaci6n se distribuye, el software se vuelve mas dificil de
mantener y mas desafiante de probar.
5. Las responsabilidades pueden compartirse entre clases relacionadas
cuando esto es apropiado. Exi sten muchos casas en los que una variedad
de objetos relacionados deben mostrar el mismo comportami ento al mi smo
tiempo. Como un ej emplo, considerese un videojuego que debe desplegar las
siguientes c1ases: Jugador, CuerpoJugador, BrazosJugador, PiemasJuga-
dor, cabezaJugador. Cada una de estas c1ases tiene sus propios atributos
(par ejemp!o, posici6n, orientaci6n, color, velocidad) y todos deben actuali zarse y
desplegarse cuando el usuario manipula un joystick. Por 10 tanto, las respon-
sabilidades actualizar( ) y desplegar( ) deben comparti rlas cada uno de los obj e-
tos mencionados. EI Jugador sabe cuando algo ha cambiado y se requiere
actualizar( ). Col a bora con l os otros objetos para lograr una nueva posici 6n u
orientaci6n, pero cad a objeto controla su propio despliegue.
Colaboraciones. Las c1ases cumpl en sus responsabilidades en una de dos formas:
I) una c1ase puede utili zar sus propias operaci ones para manipular sus propios atri-
butos, y con ello cumplir con una responsabilidad particular, 0 2) una c1ase puede
col aborar con otras c1ases.
Wirfs-Brock y sus colegas [WIR90] definen l as colaboraciones de la siguiente
manera:
Las colaboraciones representan las solici tudes que un cliente haee a un servidor con el fin
de cumplir una responsabilidad. Una colaboraci 6n es la materi alizaci6n del contrato en-
tre el cliente y el servidor. .. Se dice que un objeto cola bora con otro objeto si, para curn-
plir con una responsabilidad, necesita enviar algunos mensajes al ot ro objeto. Una
23 En tales casos puede ser necesario dividir las clases en multiples clases 0 subsistemas completos
para distribuir la inteligencia de manera mas eficaz.
Si uno dose no puede
rumplir todos sus
obligcciones por s[
mismo, entonces se
re{juiere uno
millborocion.
CAPiTULO 8 MOOELAOO DEL ANAuSIS 229
colaboraci6n sencil la fluye en una direccion, 10 que representa una solicitud del cliente al
servidor. Desde el punta de vista del diente, cada una de sus colaboracianes esta asociada
can una responsabilidad parti cular que ha implementado el servidar.
Las colaboraciones identifican las relaciones entre clases. Cuando un conjunto de
clases colabora para lograr algun requisito, este puede organizarse en un sllbsiste-
ma (un aspeclo de diseno).
Las colaboraciones se identifican al determinar si una clase puede cumpli r cada
responsabilidad par si misma. 5i no es asi, entonces se reqlliere de la interaccion can
olra clase y, por ende, una colaboracion.
Como un ejemplo, considerese l a funcion de seguridad de HogarSeguro. Como
parl e del procedimienlo de aclivacion, el objelo PaneldeControl debe determinar
si algun sensor esta abierlo. Se define una responsabilidad lIamada determinar-eSia-
tus-sensor( ). Si los sensores estan abiertos, PaneldeControl debe esl ablecer un
atributo de estatus como "no listo". La informacion de los sensores se obti ene de
cada objeto sensor. Por 10 tanlo, la responsabilidad determinar-estatus-contro/( ) tra-
baja en colaboraci6n can sensor.
Para ayudarse en la identificacion de los coiaboradores, el analista puede exami-
nar tres relaciones genericas diferentes enlre las clases [WIR90], I) l a relacion es-
parte-de, 2) la relacion tiene-conocimiento-de, y 3) l a relacion depende de. Cada una
de las tres relaciones genericas se considera can brevedad en los siguientes parra-
fos.
Todas las clases que son parle de una clase agregada se conectan a esta a traves
de una relacion del tipo es-parte-de. Consi derense las clases definidas para el viqeo-
juego ya mencionado, la clase cuerpoJugador es-parte-de )ugador, al igual que
BrazosJugador, PiemasJugador y CabezaJugador. En UML estas relaci one,; se
representan como la agregacion mostrada en la figura 8.16. .
Cuando una clase debe obtener informacion de ot ra clase se establece la relacion
tiene-conocimiento-de. La responsabilidad determinar-estatus-sensor( ) mencionada
antes ejemplifica una relacion del tipo liene-conocimiento-de.
La relacion depende-de impli ca que dos clases li enen una dependencia que no se
logra mediante las relaciones tiene-conocimiento-de 0 es-parte-de. Por ejemplo,
cabezaJugador siempre debe estar conecl ada a CuerpoJugador (a menos que el
videojuego sea violento en particular). Aun asi, cada objeto puede existir sin el cono-
cimiento directo del otro. Un atributo del objeto cabezaJugador lIamado posicion
central esla determinado desde la posicion central de CuerpoJugador. Esta infor-
macion se obti ene a traves de un lercer objelo, Jugador, quien la adquiere de
CuerpoJugador. Por ende, CabezaJugador depende-de CuerpoJugador.
En lodos los casos, el nombre de la clase del colaborador se registra en la tarjeta
indice del modelo eRC enseguida de la responsabilidad que ha producido la col abo-
racion. Por 10 tanto, la tarjeta in dice oontiene una Ii sta de responsabilidades y l as
colaboraciones correspondientes que permiten que las responsabilidades puedan
cumplirse (figura 8.15).
230
Unaclase
agregada
compuesta.
PARTE DOS pRAcnCA DE LA INGENIERiA DEL SOFIWARE
Jugador
T
I I I I
CabezaJugadOl CuerpaJugadot BrazasJugada PiemasJugacior
Cuando se ha desarrollado un modele CRC completo, los representantes del cli en-
tes y la ingenieria del soltware pueden revisar el modele utilizando el siguiente enfo-
que [AMB9SI :
I. Todos los participantes en la revision (del modele CRC) reciben un subcon-
junto de las larjelas indice del modele CRe. Las tarjetas que col abo ran se de-
ben separar (es decir, ningun revisor debe tener dos que colaboren).
2. Todos los escenarios de caso de uso (y los diagramas de caso de uso corres-
pondientes) deben organizarse en categorias.
3. Ellider de la revi sion lee el caso de uso en forma deliberada. Cuando ellider
lIega a una clase nombrada pasa una seiial a la persona que tiene la tarj eta
indice de clase correspondi ente. Par ejemplo, un caso de usa para HogarSe-
guro contiene la siguiente narrativa:
EI propietario observa el panel de control de HogarSeguro para determinar si el sistema
esta Iisla para la entrada. Si no 10 esta. el propietario podra cerrar I1sicamente venta-
nas y puertas para que se presente el indicador de li sla. IUn indicador de no-Iislo im-
plica que un sensor esta abierto; es decir, que esa puerta 0 ventana esta abierta.]
Cuando ellider de la revision lIega a "panel de control", en la narrativa del caso
de uso, la seiial se pasa a la persona que posee la carta indice del Panelde-
control La frase "implica que un sensor esta abierto" requiere que la tarj eta
indice contenga una responsabilidad que validara esta implicacion (10 cual se
logra mediante la responsabilidad delerminar-eslalus-sensor( i) . Enseguida de
la responsabilidad escrita en la tarjeta esta el colaborador sensor. Entonces, la
seiial se pasa a la c1ase sensor.
4. Cuando se pasa la seiial , la persona que posee la tarjeta de clase debe descri -
bir las responsabil idades anotadas en ella. EI grupo determina si una (0 mas)
de las responsabilidades sati sface el requisito del caso de uso.
CAPITULO 8 MODELADO DEL ANALISIS 231
5. Si las responsabili dades y las colaboraciones anotadas en las tarjetas indice
no sat isfacen el caso de usa, se hacen las modificaci ones necesari as a l a
jeta. Esto puede incluir la deflnici6n de cl ases nuevas (y correspond en a las
tarjetas de in dice de eRC) 0 l a especi flcaci6n de responsabilidades 0 colabora-
ciones nuevas revisadas sobre las tarjetas exi stentes.
Esta forma de operaci on continua hasta que se t ermina con el caso de uso. Cuando
se han revisado t odos l os casos de uso se continua con el model ado del anali sis.
HOGARSEGURO
Modelos CRC
EI escenario: Cubiculo de Ed,
continuo eI modelodo del on6lisis.
a.o. actores: Vinod y Ed, miembros del equipo de
ingenierio del sohwore de HogarSeguro.
Lac_ciOn.
(\Iinod he decidido ensenorle 0 Ed romo desarrollar
tarjelas CRC medionte un eiemplo.1
Vinod: Mientros tU has estodo trabajondo en 10
vigiloncia y Jamie ho estado involucrado con 10
seguridad, yo he estodo trabajando en la Nnden de
..dminislraci6n del hagor.
lei: aCu61 es el estatus de esc? Mercodotecnia su
punta de vista a coda momento.
V"mod: Aqui estO eI primer corte del coso de uso para
Iodo 10 funci6n ... to hemos refinodo un poco, pero
puede dorte uno ideo generol.
ea.o de uso: Funci6n de odministrodon del hogor de
HogorSeguro.
Narrativa: Queremos utilizor 10 interfaz de
odministroci6n del hogor en una PC 0 con una conexi6n
de Internet para controlor dispositivos electronicos que
tengan de interfaz inal6mbricos. EI sistema
debe permirume encender y opagor luces especificas,
eontrOlOr OpIicociones conectodos a uno interfaz
inal6mbrico, conflguror los sistemas de colefocdon y eire
ocondicionoclo con las temperaturas que yo defina; para
hocerIo quiero seleccionar los dispositivos de un plano de
pIonta de 10 coso. Coda dispositivo debe estor
identificado sabre.1 plono de 10 plonta. Como uno
eoroderlstico optional, quiero contralar todos los
disposItivos oudiovisuoles: audio, television, DVD,
grobodoras digitales, etcetera.
Con uno solo selecdon, quiero ser capaz de configurar
10 coso complete para varias situaciones. Una es en
coso; 10 otra, fuera de coso; uno tercero, salido po' Ia
noche, y uno cuorto, vioje largo. Todos estes situociones
tendr6n configuraciones que se aplicorem a todos los
dispositivos. En los estados salida per 1a noche y via;e
largo el sistema debe encender y apagar luces a
intervolos a leotorios (para oparentar que alguien est6 en
coso) y controlar el sistema de calefcccion yaire
acondicionado. Debe ser copaz de involidor estos
configuradones a troves de Intemet con Ie protecd6n de
una contraseno opropiada .
Ed: ,Lo gente de hordware nene cancebidos todotlo.
interfases inalombricas?
Vinod (sonriendo). Est6n trobojondo en ellos,
digomos que no es un gran problema. De cuolquier
monera, extroie uno serie de doses poro 10
odministrod6n del hogar, y podemos utilizer alguno de
elias como ejemplo. Usemos 10 dose
InterfaxAdministraciemHogar.
Ed: De ocuerdo .. . entonces, los responsobilidades
son ... los atributos y operaciones pora Ie dose, y las
coloborociones son las doses hado los que opunton las
responsabilidades.
Vinod: (reo que no entendiste 10 eRe.
Ed: Tal vez un poco, pero continua.
Vinod: Entonces, oqui esta mi definicion de close para
InteriazAdministracionHogar.
Atributos:
Ponelopciones: proporciona informoci6n en botones que
permiten al usuario seleccionor uno Funcionolidod.
Ponelsituaci6n: proporci6no informaciOn en botones que
01 usuario selecdonor 10 situociOn.
232 PARTE DOS pRAcnCA DE LA INGENIERIA DEL SOFIWARE
PIonodepionta: el mismo que el obieto de vigiloncio, pero seleccionorSituoci6n PanelSituocibn (close)
PlanodePlanta (close)
este despliego los dispositivos. entrarPlanodePlanta
lconosdeDispm.itivo: infonnaci6n sabre leonos que
represe,nton luces, oplicociones, comoros, etcetera.


PanelesdeDisposltivo: simulocion de uno oplicocion 0
panel de control de un dispositivo; permite el control.
Operaciones:

Ed: Entonces cuondo se invoca la operacion
entrarpfanodeP!anfa(), Elsto colaboro can el obieto
PlanodePianta como el que desorrollamos para 10
vigilancia. Espero, oqui tengo su descripcion. {Yen 10
figura 8.14)
DespfegarConlrof(J, sefeccionorControf(J,
desplegarSituaci6n(}, seleccionarSituadon{},
entrarPlanodepfanta(L seJeccionariconoDispositivo(),
clesplegorPanelDispositivo(}, entrar PoneIDispositivo(),. ..
Close: InterfazAdministraci6nHogar
Vinod: Y si quisieramos revisor todo eI
modelo de close, podri"omos comenzar con esta carta
indice, despues ir a 10 carta indice del colaboradort y de
ahi, a uno de los colaboradores de los colaborodores, Y
OS! sucesivomente.
ReJponsabilidad Colabarador
desplegorConti'ol
seleccionorControl
despiegorSituoci6n
Paneloperaciones (close)
Paneloperaciones (dose)
PanelSituacion {close}
Ed: Bueno forma de encontror omisiones 0 errores.
Vinod: 51.
Una aSOciocion define
uno reloci6n entre
doses. La multiplicidad
define cuontos de uno
dose eston
relocianadas can
cuontas de atro close.
,Que es un
estereotipo?
8.7.5 Asociaciones y dependencias
En muchos casos, dos c1ases de analisis se relacionan entre S1 de alguna manera, pare-
cida a la fonna en que se relacionan dos objetos de datos (seccian 8.3.3). En UML estas
reJaciones se Haman asociaciones. Vease de nuevo la figura 8.14; la clase PlanodePlanta
se define al identificar un conjunto de asociaciones entre PianodePIanta y otras dos c1a-
ses, camara y Pared. La clase Pared se asocia con tres clases que penniten que se
construya una pared, SegmentodePared. Ventana y Puerta.
En algunos casos, una asociaci6n se puede definir en forma mas extensa al indi-
car muftipficidad (el terminG cardinalidad ya se usa antes en este capitulo). En refe
rencia a la figura 8.14, un objeto de Pared se construye con uno 0 mas objetos de
SegmentosdePared. Ademas, el objeto Pared puede contener 0 0 mas objetos
de Ventana y 0 0 mas objetos de Puerta. Estas restricciones de multiplicidad se ilus
tran en 1a figura 8. I 7, donde "uno 0 mas" se representa mediante 1 .. * Y "0 0 mas" por
medio 0 .. *. En UML el asterisco indica una frontera superior ilimitada en el rango.24
En muchos casos existe una relaci6n cliente-servidor entre dos c1ases de analisis.
En tales casos, una clase de cliente depende de alguna manera de la clase de servi-
dor y se establece una felacion independencia. Las dependencias se definen median-
te un estereotipo. Un estereotipo es un "mecanismo de extensibilidad" [ARL02] den-
24 Otras relaciones de multiplicidad - una a una, una a muchas, muchas a muchas, una a un rango es-
pedfico con hmites inferior y superior, y otras- se pueden indicar como parte de una asociacion.
Multiplicidad.
Dependencias.
CAPITULO 8 MODELAOO DEL ANALlSIS
Pared
I I I
Se utiliza para Se utiliza para
construir
I
1
5egmentoPared
Ventana
Despliegue
-

-
construir
o .
.
Se utiliza para I
construir O .
.
Ventana Puerta
Camara
acceso
...................
(contrasenal
233
tra del UML que permite a un ingeniera de software definir un elemento de modela-
do especial cuya semimtica define el cliente. En UML los estereotipos se representan
dentro de comillas angulares (por ejemplo, estereotipo).
Como una ilustraci6n de una dependencia simple dentro del sistema de vigilan
cia de HogarSeguro, un objeto de Camara (en este caso, la clase de servidor) pro
porciona una imagen de video 0 un abjeta de VentanadeDespliegue (en este casa,
la del cliente). La relaci6n entre estos dos objetos no es una asociaci6n simple, aun asi
existe una asociaci6n de dependencia. En un caso de uso escrilo para la vigilancia
(que no se muestra), el modelador aprende que se debe praporcionar una contrasefia
especial para ver ubicaciones espedficas de camara. Una forma de iograr esto es que
camara pida una contrasena y despues de permisa a VentanadeDespliegue para
producir la imagen de video. Esto se puede representar cama se muestra en la figura
8.18, dande accesa implica que el usa de la salida de la camara esta controlada
mediante una contrasefia especial.
8.7.6 Paquetes de ancl!isis
Una parte importante del madelada del analisis es la categarizaci6n. Esta es, los
diferentes elementas del madela de analisis (par ejemplo, casos de usa, clases de
234
Paquetes.
Un poquete se u ~ l i z ]
para ensomblar uno
coleccion de closes
relocionodos.
PARTE DOS PAAcnCA DE LA INGENIERlA DEL SOfTINARE
...,.,.....,,.-,,.-,..,.._ .......... Nombre del paquete
MedioAmbiente ! \.
+Arbol ! \.
+Paisaje
+Comino
+Pared
+Puenle
+Edificio
+EfectoVi
+Esceno
: ..
, .
, ..
R""lasDeUu-o I
+ReglasDeMovimiento
sua I
+RestriccionesEnAcci6n
Personaies
+Jugodor
+Protogonista
+Antagonista
+Papelde$oporte
ana lis is) se clasifican de una manera que los empaquete como una agrupaci6n - lJa-
mada un paquete de analisis-, a la cual se Ie asigna un nombre representativo.
Para ilustrar la utilizaci6n de paquetes de anal isis considerese el videojuego que
se present6 parrafos atras. Al desarrollar el modele de analisis para el videojuego se
obtiene un gran numero de clases. Algunas se enfocan en el ambiente del juego; par
ejemplo, las escenas visuales que el usuario ve mientras se desarrolla el juego.
Clases como Arbol, Paisaje, Camino, Pared, Puente, Edificio, EfectoVisual,
podrian estar dentro de esta categoria. Otras se enfocan en los personajes dentro del
juego al describir sus caracteristicas fisicas, acciones y restricciones. Se podrian defi-
nir clases como Jugador (la cual se describi6 can ante riori dad I. Protagonista,
Antagonista y PapelesdeSoporte. Ademas, otras describen las reglas del juego:
como navega el juga dar a traves del ambiente. Aqui son candidatas clases como
ReglasDeMovimiento y RestriccionesEnAcci6n. Pueden existir muchas otras
categorias. Estas clases pueden representarse como los paquetes de analisis que se
muestran en la figura 8.19.
EI signa de mas que precede al nombre de la clase de analisis en cada paquete
indica que las clases tienen visibilidad publica y que, par 10 tanto, son accesibles
desde otros paquetes. Aunque no se muestran en esta figura, hay otros simbolos que
pueden preceder a un elemento dentro de un paquete. Un signa de menos indica que un
elemento esta oculto de todos los otros paquetes, y un simbolo # indica que un ele-
mento es accesible 5610 a las clases contenidas dentro de un paquete dado.
Los diagramas de clase, las tarjetas indice CRC y otros modelos orientados a las cla-
ses tratados en la secci6n 8.7 representan elementos estaticos del modele de anali-
, Como se
model. I.
nalcion del soft-
ware a alglln
pento externo?
los (osos de uso se
anolizan poro definir
"",los. POlO logrorlo,
kiI (osos de uso se
exominon con el fin de
eflCootrar los puntas de
interccmbic de
informociol1.
CAPITULO 8 MODELADO DEl ANAuSIS 235
sis. Ahora es tiempo de hacer una transici6n al comportamiento dinamico del siste-
ma 0 producto. Para lograrlo el comportamiento del sistema debe presentarse como
una funci6n de los elementos especiflcos y el ti empo.
EI modelo de comportamiento indica la fonna en que el software responde,,; a los even-
tos 0 estimulos extemos. En la creaci6n del modele el analista debe realizar los siguien-
tes pasos:
1. Evaluar todos l os casos de uso para entender por completo la secuencia de
interacci6n dentro del sistema.
2. l denti ficar los eventos que conducen la secuencia de interaccion y entender la
forma en que estos eventos se relaci onan con las c1ases especificas.
3. Crear una secuencia para cada caso de uso.
4. Construir un diagrama de estado para eI sistema.
5_ Revisar el modele de comportamiento para veriflcar su exactitud y consisten-
cia.
Cad a uno de estos pasos se expone en las secciones siguientes.
S.S.l Identlficaci6n de eventos con el caso de uso
Como se menciono en la secci6n 8.5, el caso de usa representa una secuencia de
actividades que impli ca a l os actores y al sistema. En general, siempre que el siste-
ma y un actor intercambian informaci6n ocurre un evento. Si se recuerda la expli-
caci6n anterior acerca del model ado del comport amiento en la secci6n 8.6.3, sera
importante puntualizar que el even to no es la informaci6n que se ha intercambia-
do, sino el hecho de que l a informaci6n haya sido intercambiada.
Los puntos del intercambio de informacion se obtienen exami nando un caso de
uso. A manera de ilustracion, se reconsiderara el caso de uso para una pequena
parte de la funci6n de seguridad de HogarSeguro.
E! propietarjo Uljljza el teclado para jntroducjr una contrasefta de cuatro digitos. La mn.:.
trasefta se compara can !a conlraselia yalida almacenada en el sistema 5i la contraselia
es incorrecta, el panel de control emjtira un sonido por una sola vez y se reinici ara para
esperar otra entrada. 5i la contraselia es correcta, el panel de control esperara 1a acci6n
posterior.
Las partes subrayadas del escenario del caso de usa indi can eventos. Se debe iden-
ti fi car a un autor para cada evento; la informaci6n intercambiada se debe anotar, y
cualquier condici6n 0 restricci6n debe registrarse.
Como ejemplo de un even to tipico, consi derese la Frase subrayada del caso de uso
"el propietario utiliza el teclado para introducir una cont rasei'ia de cuatro digitos". En
el contexte del modele de analisis, el objeto, propietario," transmi te un evento al
25 En este ejemplo se asume que cada usuario (propietario) que interactua con HogarSeguro tiene una
contrasena de identjficaci6n y que, por 10 tanto, es un objeto legitimo.
,
236
EI sistema ~ e n e
estodos que
representon un
(omporlomiento
espeeilico observtlble
desde el exterior; uno
dose liene eslodos que
represenlon su
comportomienlo
wando el sistema
reolizG sus iunciones.
PARTE DOS pRAcnCA DE LA tNGENIERiA DEL SOF1WARE
objeto PaneldeControl. EL evento podria lIamarse introducci6n de contraseiia. La
informacion transferida son los cuatro dlgltos que constituyen la contrasena, pero
esta no es una parte esencial del modelo de comportamiento. Es importante senalar
que algunos eventos tienen un impacto explicito sobre el flujo de control del caso de
uso, mienlras que otros no tienen impacto directo sobre el flujo de control. Por ejem-
plo, el even to introducci6n de contraseiia no cambia de manera explicita el flujo de
control del caso de uso, pero los resultados del evento comparaci6n de contraseiia
(derivado de la interacci6n "Ia contrasena se campara con la contrasena valida
almacenada en eI sistema") tendra un impacto explicito sobre la informacion y el
flujo de control del software de HogarSeguro.
Una vez que se han identiflcado todos los eventos, estos se ubican con los obj e-
tos involucrados. Los objetos pueden ser responsables de generar eventos (por ejem-
plo, Propietario genera el even to de introducci6n de contraseiia) 0 de reconocer
eventos que han ocurrido en cualquier sit io (por ejemplo, PaneldeControl recono-
ce el result ado binari o del even to comparaci6n de contraseiia).
8.8.2 Representaciones de estado
En el contexto del modelado del comportamiento se pueden considerar dos diferen-
tes caracterizaciones de los estados: I) el estado de (ada clase conforme el sistema
realiza su funcion, y 2) el estado del sistema como se observa desde el exteri or con-
forme el sistema realiza su funcion.
26
EI estado de una clase implica caracteristicas tanto pasivas como activas [CHA93].
Un estado pasivo es simplemente el estatus actual de todos los atributos de un objeto.
Por ejemplo, el estado pasivo de la cl ase Jugador (en la aplicacion de videojuego
estudiada con anterioridad) incluiria los atributos de posicion y orientaci6n del Jugador,
asl como otras caracterlsticas relevantes para el juego (por ejemplo, un atributo que
indique la existencia de deseos magicos). EI eslado activo de un objeto indica el estatus
actual del objeto cuando este esta sujelo a una transformacion 0 a un procesamien-
to continuos. La clase Jugador pod ria tener los siguientes estados activos: en movi-
miento, en descanso, herido, en curacion, atrapado, perdido, etcetera. Debe ocurrir un
even to (algunas veces lIamado un disparador) para obligar a un objeto a hacer una
transici6n de un estado activo a otro.
En los parrafos siguientes se explican dos diferentes representaciones del com-
porta mien to. La primera indica la forma en que una clase individual cambia sus esta-
do con base en eventos exlernos, y la segunda muestra el comportami ento del soft-
ware como una funci6n del tiempo.
Diagramas de estado para c\ases de analisis, Un componente de un modelo
del comportamiento es un diagrama de estado en UML que representa l os estados
activos para cad a clase y los eventos (disparadores) que ocasionan cam bios entre
26 Los diagramas de estado presentados en la secci6n 8 ~ 3 muestran el estado del sistema. La expo-
sicion en esta secci6n se enfocarit al estado de cada clase dentro del modelo de anitlisis.
CAPITULO 8 MODELADO DEL ANALlSIS 237
Oicgrama de estado
para la clase
PaneldeControl.
Temporizador .::; TiempoCerrado
A Merencio de un
diograma de eslodo
que represento el
comportomienlo sin
mencionar las closes
involucrodos, un
diogmma de secuencio
represento el
comporlomienlo 01
describir 10 formo en
que las closes se
mueven de estodo a
"tudo.
Temporizador > TiempoCerrado -
Cerrado
-
Contrasefia = incorrecta
r--
y numeroDelntentos < Intentosmaximos
Golpe
Lectura L
Comparacion numeroDelntentos >
-
de tecla Intentosmaximos
-
Contrasena
r--
introducida Hacer: validar
Contrasena
Contrasena = correcta
Seleccion
I--
Aclivaci6n exi tosa
estos estados activos. En la flgura 8.20 se ilustra un diagrama de estado para la clase
PaneldeControl en la funcion de seguridad de HogarSeguro.
Cada flecha en la figura 8.20 representa una transicion desde un estado activo de
una clase hasta otro. Las etiquetas mostradas para cad a flecha representan el even-
to que dispara la transicion. Aunque el modelo de estado activo proporciona un dis-
cernimiento activo de la "hi storia de vida" de una c1ase, es posible especificar infor-
macion adicional para proporcionar mayor profundidad en la comprension del com-
portamiento de una c1ase. Ademas de especificar el evento que ocasiona la transi -
cion, el analista puede especiflcar una guardia y una accion [CHA93]. Una guardia es
una condicion booleana que debe satisfacerse para que ocurra !a transicion. Por
ejemplo, la guardia para la transicion desde el estado de "\ectura" al est ado de "com-
paracion" de la figura 8.20 se puede determinar al examinar el caso de uso:
si (introducci6n de contrasena = 4 dfgitos), entonces comparar con contrasena almacenada
En general, la guardia para una transi cion por 10 regular depende del valor de uno 0
mas atributos de un objeto. En otras palabras, la guardia depende del estado pasivo
delobjeto.
Una acd6n sucede de manera concurrente con la transicion del estado 0 como
consecuencia de este, y por 10 general implica una 0 mas operaciones (responsabili -
dades) del objeto. Por ejemplo, una accion conectada con el even to contrasefja intro-
ducida (figura 8.20) es una operacion llamada ValidarContrasena( ) que da acceso a
238 PARTE DOS pRAcnCA DE LA iNGENIERfA DEL SOFTWARE
de e c u e n c i (parciaIrpara la funcion de seguridad de HogarSeguro.
I Propietoria I I Panel de control I
~
Sensor
-
... Sistema
lislo
r
,
,
,
,
,
,
,
,
,
,
,
,
,
I
CD
lecture
, ,
, ,
Contrasena introducido
, ,
, ,
Solicitud de busqueda ....L, ,
Comparoci6n
I I
,
Resultado
, ,
numerDe'ntentos > >
Contrasena = correcto
.1.
,
Intentosm6ximos
Solicitud de activacion
Temporizador >
Cerrado
,
A Tiempocerrodo
,
,
, ,
, ,
Selecdon
,
,
Activaci6n exitosa
,
Activaci6n exitoso
,
,
un objeto de contrasefia y realiza una comparacion digito par digito para validar 1a
contrasena introducida.
Diagramas de secuencia. El segundo tipo de representacion de comportamien-
to, Hamada un diagram a de secuencia en UML, indica como los eventos causan tran-
siciones de objeto a objeto. Una vez que se han identificado los eventos al examinar
un caso de usa, el modelador crea un diagrama de secuencia: una representacion de
c6mo los eventos causan un flujo de un even to a otro como una funci6n del tiempo.
En esencia, eJ diagrama de secuencia es una versi6n abreviada del caso de uso.
Representa c1ases clave y eventos que causan que el comportamiento Ouya de clase
a clase.
En la figura 8.21 se ilustra un diagrama de secuencia parcial de la funci6n de
seguridad de HogarSeguro. Cada Oecha representa un even to (derivado de un caso
de uso) e indica como el even to canaliza el comportamiento entre los objetos de
HogarSeguro. EI tiempo se mide de manera vertical (hacia abajo), y los rectimgulos
verticales delgados representan el tiempo invertido en procesar una actividad. Los
est ados se pueden mostrar a 10 largo de una linea de tiempo vertical.
EI primer evento, sistema /isto, se deriva del ambiente externo y canaliza el COffi-
portamiento a un objeto de propietario. EI propietario introduce una contrasena. Se
pasa un even to de solicitud de bUsqueda al sistema, el cual busca la contrasefia en
una base de datos simple y regresa un resultado (encontrado 0 no enconlrado) al
PaneldeControl (ahara en el estado de comparacion). Una contraseiia valida resul
CAPiTuLo 8 MODELADO DEL ANAuSIS 239
ta en un evento contrasena=correcta para el Sistema, el cual activa los sensores can
un evento de soJicitud de activaci6n. Por ultimo, el control se pasa de regreso al pro-
pietario con el evento activaci6n exitosa.
Una vez que se ha desarrollado un diagrama de secuencia completo, todos los
eventos que ocasionan transiciones entre objetos del sistema se pueden cotejar can
un conjunto de eventos de entrada y eventos de salida (de un objeto). Esta informa-
ci6n es uti I en la creaci6n de un diseiio eficaz para el sistema que sera construido.
Modelado del anCrlisis generalizado en UML
Objetivo: los herromientas para el modelodo ArgoUML, uno herromiento de Fuente obierto
del on61isis praporcionon 10 copacidod de (orgouml.tigris.org).
desarrollor modelos bosados en escenarios, modelos Control Center, desorrollado por TogetherSoft
basados en closes y modelos de comportomiento mediante (www.togethersoft.com).
10 notocian UMl.
Mecanica: los herramientos en esta categoria soporton
el omplio rango de diagromas en UMl requeridos para
construir un modelo de an61isis (estes herramientos
tombiim soporton el modelado del diseno). Adem6s de 10
creacion de diagromas, los herramientas en esta categoria
1 J realizan 10 verificacian de 10 consistencia y 10 correccian
de todos los diagromos en UMl; 2) proporcionan vinculos
poro el diseno y la generacion de c6digo; 3) construyen
una base de datos que ayudan a 10 administracian y
evaluocion de grondes modelos en UMl requeridos para
sistemas complejos.
Herramientas representativas
27
las siguientes herromientos soportan un rongo completo
de diagramas en UMl requeridos para el modelado del
an6lisis:
89 RlsyMEN
Enferprise Architect, desarrollado por Sparx Systems
(www.sporxsystems.com.ou).
Object Technology Workbench (OTW), de,arrollada por
OTW Software (www.otwsoftwore.com).
Power Designer, desarrollado por Sybose
(www.sybase.com).
Rational Rose, desarrollodo par Rational Corporation
(www.rationol.com).
Sysfem Architect, desarrollado por Popkin Software
(www.popkin.com).
UML Studio, desorrollado por Pragsoft Corporation
{www.progsoft.coml.
Visio, desarrollodo par Microsoft (www.microsoft.com).
Visual UML, desarrollodo par Visual Obiect Modelers
(www.visuoluml .coml.
EI objetivo del modelado del anal isis es crear una varied ad de representaciones que
muestran los requisitos del software para la informaci6n, la funci6n y el comporta-
miento. Esto se logra aplicando dos diferentes filosofias de model ado (pero poten-
cialmente complementarias): el anal isis estructurado y el analisis orientado a obje-
tos. El analisis estructurado considera al software como un transformador de in for-
27 Las herramientas mencionadas aqui son una muestra de esta categoria. En la mayoria de los casos
los nombres estan registrados par sus respectivos desarrolladores.
240 PARTE DOS pRAcnCA DE LA INGENIERiA DEL SOf1WARE
maci6n. Este ayuda al ingeniero de software a identiflcar los objetos de datos, sus
relaci.ones y la manera en la cual estos objetos de datos se transforman mientras fiu-
yen a traves de las funciones de procesamiento del software. EI analisis orientado a
objetos examina un dominic de problema definido como un conjunto de casos de
uso en un esfuerzo por ex traer clases que deflnen el problema. Cada clase tiene un
conjunto de atributos y operaciones. Las clases esttm relacionadas entre si en una
variedad de formas diferentes y se moldean mediante la aplicacion de diagramas de
UML. EI modele de am\ lisis 10 componen cuatro elementos de modelado: modelos
basados en escenarios, modelos de flujo, modelos basados en clases y modelos de
comportamiento.
Los modelos basados en escenarios muestran los requisitos del software desde el
punto de vista del usuario. EI caso de usc - una descripcion narrativa 0 basad a en
una plantilla de una interaccion entre un actor y el software- es el elemento pri -
mario del model ado. EI caso de usc, derivado durante la obtencion de requisitos,
define los casos clave para una funcion 0 interacci on especifica. EI grado de forma-
lidad y detalle del caso de usc varia, pero el resultado final proporci ona la entrada
necesaria a las otras actividades de model ado del analisis. Los escenarios tambien
pueden describirse por medio de un diagrama de actividad: una representacion gra-
fi ca del tipo de un diagrama de flujo que muestra el flujo del procesamiento dentro
de un escenario especiflco. Los diagramas de carril i1ustran la forma en que el flujo
de procesamiento incumbe a varios actores 0 clases.
Los modelos de flujo se enfocan en el flujo de objetos de datos con forme las fun-
ciones de procesamiento los transforman. Los modelos de fluj o, que se deri van del
anal isis estructurado, utilizan el diagrama de flujo de datos; esta es una notacion de
modelado que muestra la manera en que una entrada se transform a en una sali da
conforme los objetos de datos se mueven a traves del sistema. Cada funcion del soft-
ware que transforma datos se describe mediante una especiflcaci6n del proceso 0
narrativa. Ademas del flujo de datos, este elemento de model ado tam bien muestra
el fluj o de control (una representacion que ilustra la forma en que los eventos afec-
tan el comportamiento del sistema) .
EI modelado basado en cJases utiliza informacion deri vada de elementos de
model ado orientado al fluj o y basado en escenarios para extraer clases candidatas,
atributos y operaciones de las narrativas basadas en texto. Se establecen los crite-
rios para la definicion de una cJase. La tarjeta indice clase-responsabilidad-colabo-
rador puede usarse en la definicion de relaciones entre las clases. Ademas, se puede
aplicar una variedad de notaciones de modelado en UML para defl nir jerarquias,
reJaciones, asociaciones, agregaciones y dependencias entre las clases. Los paque-
tes de analisis se utili zan para categori zar y agrupar c\ases de manera que sean mas
manejables para los sistemas gran des.
Los primeros tres elementos del model ado del analisis proporcionan una vision
estatica del software. Los model os de comportamiento muestran un desempeno
dinamico. EI modele de comportamiento utiliza la entrada de elementos basad os en
CAPITULO 8 MODELADO DEL ANAuSIS 241
escenarios, orientados al flujo y basados en clases para representar los estados de
las clases de analisis y del sistema como un todo. Esto se logra identificando los
estados, defInienda los eventas que acasionan que una clase (a sistema) tenga una
transici6n de un estado a otro, e identifIcando las acciones que suceden cuanda se
realiza l a transici6n. En el madelada del comportamiento se utiliza la notaci6n en
UML de los diagram as de estado y los diagramas de secuencia.
[ABB83] Abbott, R., "Program Design by Informal English Descriptions", en CACM, vol. 26, num.
11. noviembre de 1983, pp. 892-894
IAMB95] Ambler, S., "Using Use-Cases", en Software Development, julio de 1995, pp. 53-61.
[ARA89] Arango, G. y R. Prieto-Diaz, "Domain Analysis: Concepts and Research Directions", en
Domain Analysis: Acquisition oJReusable Information Jor Software Construction, (Arango, G. y
R. Prieto-Diaz, eds.J. IEEE Computer Society Press, 1989.
[ARL02j Arlow, J. e 1. Neustadt, UML and the Unified Process, Addison-Wesley, 2002.
[BER931 Berard. E. v., Essays on Objetc-Oriented Software Engineering, Addison-Wesley, 1993.
IB0086] Booch, G., "Object-Oriented Development", en lEE Trans. Software Engineering, vol. SE-
12, num. 2, febrero de 1986, pp. 211ff.
fBUD96j Budd, T, An Introduction to Objetc-Oriented Programming, 2a. ed., Addison-Wesley,
1996
[CAS89] Cashman, M., "Object-Oriented Domain Analysis", en ACM Software Engineering Notes,
vol. 14, num. 6, octubre de 1989, p. 67.
[CHA93] de Champeau x, D., D. Lea y P. Faure, Object -Oriented System Development, Addison-
Wesley. 1993.
[CHE77] Chen, P., The Entity-Relationship Approach to Logical Database Design, QED Information
Systems, 1977.
[COA91] Coad, P. y E. Yourdon, Object-Oriented Analysis, 2a. ed., Prentice-Hall, 1991.
[COC01J Cockburn, A., Writing Effective Use Cases, Addi son-Wesley, 2001.
[DAV93j Davis, A., Software Requirements: Objects, Functions and States, Prentice-Hall, 1993.
[DEM79] DeMarco, T, Structured Analysis and System Specification, Prent ice-Hall, 1979
[FIR93] Firesmith, D. G., Object-Oriented Requirements Analysis and Logical Design, Wiley, 1993.
[LET03] Lethbridge, T, comunicaci6n personal sobre el analisis del dominio, mayo de 2003.
[OMG03] Object Management Group, OMG Unified Modeling Language Specification, version
1.5, marzo de 2003, disponible en http://www.rational.com/um!/resources/documenta-
tion/.
[SCH02l Schmuller, 1., Teach YourseJfUML in 24 Hours, 2a. ed., SAMS Publishing 2002.
[SCH98] Schneider, G. y J. Winters, Applying Use Cases, Addi son-Wesley, 1998.
[STR88] Stroustrup, B., "What is Object-Oriented Programming?", en IEEE software, vol 5, num.
3, mayo de 1988, pp. 10-20.
[TAY90] Taylor, D. A., Object-Onented Technology: A Manager's Guide, Addison-Wes!ey, 1990.
[THAOO] Thal heim, B., Entity Relationship Modeling, Springer-Verlag, 2000.
]TIL93] Ti!lmann, G., A Practical Guide to Logical Data Modeling, McGraW-Hill, 1993.
[UML03] The UML Cafe, "Customers Don't Print Themselves", disponible en http://www.
theumicafe.com/a0079.htm, mayo de 2003.
[WIR90] Wirfs-Brock, R., B. Wilkerson y L. Weiner, Designing Object-Oriented Software, Prentice-
Hall, 1990.
8 . 1. ~ s posible comenzar a codificar inmediatamente despues de haber creado el mode!o de
analisis? Explicar !a respuesta y despues justificar los puntos en contra.
242 PARTE DOS PAACTICA DE LA INGENIERiA DEL SOF1WARE
8.2. Un analisis practico es aquel en el eua! el modele "debe enfocarse en los requisitos que
son visibles dentro de los domini6s del problema 0 del negocio". ,:.Cuaies tipos de requisitos no
son visibles en estos dominios? Dar algunos ejemplos.
8.3. ,-Cual es el prop6sito del analisis del dominio? GComo se relaciona con el concepto de los
patrones de requisitos?
8.4. En unas cuantas !ineas, tratese de describir las diferencias primordiales entre el analisis
estructurado y el amllisis orienta do a objetos.
8.5 ..... Es posible desarrollar un modelo de analisis eficaz sin desarrollar los cuatro elementos
que se muestran en 1a figura 8.3? Explicar la respuesta.
8.6. Sup6ngase que han pedido construir uno de los siguientes sistemas.
a) Un registro de cursos basado en red para una universidad.
b) Un sistema procesador de 6rdenes basado en Internet para una tienda de computadoras.
C) Un sistema simple de facturaci6n para un negocio pequeno.
d) El software que reemplace un Rolodex y que se encuentre dentro de un telefono inalam-
brico.
e) Un libro de cocina automatico que este construido dentro de un horno electrico 0 de
microondas.
Selecci6nese el sistema que se considere interesante y describanse sus objetos de datos, rela-
ciones y atributos.
8.7. Dibujar un modelo al nivel de contexte (DFD de nivel 0) para uno de los cinco sistemas que
se listan en el problema 8.6. Escribir una narrativa del procesamiento para el sistema al nivel de
contexto.
8.8. Utilizar el DFD al nivel de contexte desarrollado en el problema 8.7 para dibujar los dia-
gramas de flujo de los niveles 1 y 2. Para comenzar, utilicese un "anal isis gramatical" en la
narrativa del procesamiento al nivel de contexto. Recuerdese especificar todo el fluido de infor-
macion mientras rotula todas las flechas que se encuentran entre las burbujas. 0sense nombres
significalivos para cada transformaci6n.
8.9. Desarr61lense especificaciones de control (EC) y especificaciones de proceso (EP) para el
sistema que seleccion6 en el problema 8.6. Tratese de que el modele sea 10 mas completo posi-
ble.
8.10. El departamento de obras publicas de una ciudad grande ha decidido desarrollar un sis-
tema de rastreo y reparaci6n de baches basado en la Web (SRRB). Se incluye la siguiente des-
cripci6n:
Los ciudadanos pueden entrar al siUo Web y reportar la ubicaci6n y severidad de los
baches. Cuando estos se reportan entran a un "sistema de reparacion del departamento de
obras publicas", donde se les asigna un numero de identificaci6n, junto con la direccion de la
calle, el tamafto (en una escala de 0 a 10), la ubicaci6n (en la orilla de la calle, en medio,
etcetera), el distrito (determinado por la direcci6n de la calle), y la urgencia de Ja repara-
cion (determinada por el tamafto del bache). Los datos de la orden de trabajo estan aso-
ciados con cada bache e incluyen la ubicacion y el tamafto del bache, numero de identifi-
caci6n de la reparaci6n, cantidad de personal necesario, horas aplicadas a la reparaci6n,
estado del bache (trabajo en progreso, reparado, reparado en forma temporal, no repara-
do), cantidad de material de relleno utilizado, y costo de!a reparacion (calculo de las horas
aplicadas, numero de personas, material y equipo utilizados). Por ultimo, se crea un archi-
vo de danos para registrar informaci6n sobre averias reportadas debido a los baches, el
cual incluye nombre del ciudadano, direcci6n, numero telef6nico, tipo de dano, precio del
dano en doJares. El SRRB es un sistema basado en la web; todas las peticiones se hacen
en forma interactiva.
Con base en una notacion de analisis estructurada, desarrolle un modelo de analisis para eJ
SRR6.
CAPiTULO 8 MODELADQ DEL ANAUS(S 243
8. 11. Describir los terminos orientados a objetos encapsulaci6n y herencia.
8.1 2. Escribir un caso de uso basado en una plantilla para el sistema de gesti6n para el hogar
HogarSeguro, descrito de manera informal en un recuadro ubicado enseguida de la secci6n
8.7.4.
8.1 3. Dibujar un diagrama de caso de usa en UML para el sistema SRRB presentado en el pro-
blema 8. 10. Tendran que hacerse varios supuestos sobre la manera en que el usuario interac-
tua can este sistema.
8. 14. Desarroll ar un modelo de ciase para el sistema SRRB presentado en el problema 8.10.
8. 15. Desarrollar un conj unto completo de tarjetas indice del modele CRC para el sistema SRRB
presentado en el problema 8.10.
8. 16. Encabezar una revision de [as tarjetas indice de CRC con sus colegas. iCuantas clases
adicionaies, responsabilidades y colaboradores fueron agregados como consecuencia de la revi-
si6n?
8. 17. Describir la diferencia entre una asociaci6n y una dependencia para una clase de anali-
sis.
8.IB. iQUe es un paquete de analisis y c6mo debe utilizarse?
B. 19 . .!oDe que manera di fi ere un diagrama de estado para c1ases de anal isis de los diagramas
de estado presentados para el sistema completo?
PTRAS L"TyRAS X FUENTES DE INFORMACION
Se han pubJicado docenas de Iibros sobre analisis estructurado. En la mayoria se trata el tema
de una manera adecuada, pero 5610 en unos cuantos se presenta un trabajo en verdad exce-
lente. DeMarco y PI auger (Structured Analysis and System Specification, Pearson, 1985) es un cJa-
sica que sigue siendo una buena introducci6n a la notaci6n basica. Los Jibros de Kendal y
Kendal (Systems Anatysis and Design, 5a. ed. , Prentice-Hall, 2002) y Hoffer et al. (Modern Systems
Anatysis and Design, Addison-Wesley, 3a. ed., 2001) son referencias valiosas. Ellibro de Yourdon
(Modern Structured Ana!'ysis, Yourdon-Press, 1989) sobre el tema se conserva entre las publica-
ciones mas completas a la fecha.
Allen (Data Modeling Jor Everyone, Wrox Press, 2002), Simpson y Witt (Dala Modeling
Essentials, 2a. ed., Coriol is Group, 2000), Reingruber y Gregory (Data Modeling Handbook, Wiley,
1995) presentan guias detalladas para crear modelos de datos relacionados con la calidad
industriaL Un interesante libro de Hay (Data Modeling Patterns, Dorset House, 1995) presenta
patrones de modelos de datos tipicos que se encuentran en muchos negocios diferentes. Un tra-
tamiento detallado del modelado del comportamienlo puede encontrarse en Kowal (Behavior
Models: SpeciJjting User's Expeclations, Prentice-Hall, 1992).
Los casos de usa son 1a base del anal isis orientado a objetos. Los libros de Bittner y Spence
(Use Case Modeling, Addison-Wesley, 2002), Cockburn [COC01 LArmour y Miller (Advanced Use-
Case Modeling: Software Systems, Addison-Wesley, 2000) y Rosemberg y Scot (Use-Case Driven
Object Modeling with UML: A Practical Approach, Addison-Wesley, 1999) proporcionan una guia
valiosa en la creaci6n y usa de este importante mecanismo de representacion y lagro de reque-
rimi entos.
Arlow y Neustadt han escrito apreciables analisis del UML [ARL02], Schmuller [SCH02l,
Fowler y Scott (UML Distilled, 2a. ed., Addison-Wesley, 1999), Booch y sus colegas (The UML User
Guide, Addison-Wesley, 1998) y Rumbaugh y sus cOlegas (The Unified Modeling Language
ReJerence Manual, Addison-Wesley, 1998).
Los metodos de analisis y diseiio que apoyan el proceso . unificado los explica Larman
(Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified
process, 2a. ed. ;"" Prentice-Hall, 2001), Dennis y sus cOlegas (System Analysis and Design: An
Object-Oriented Approach with UML, Wiley, 2001), y Rosenberg y Scott (Use-Case Driven Objecl
Modeling with UML, Addison-Wesley, 1999), Balcer y Mellor (Executable UML: A FoundationJor
244 PARTE DOS pRACTICA DE LA INGENIERlA DEL SOFlWARE
Model Driven Architecture, Addison-Wesley, 2002) exponen la semimtica general del UML, los
modelos que se pueden crear, y una forma de considerar el UML como un lenguaje ejecutable.
Starr (Executable UML: How Io Build Class Models, Prentice-Han, 200 I) ofrece una guia uti! y
sugerencias detalladas para crear clases de diseiio y analisis efectivos.
En Internet se dispone de una gran varied ad de fuentes de informacion sabre el modelado
del analisis. En el sitio SEPA se puede encontrar una lista actuali zada de referencias de la red
que son notables para el model ado del anaJisis:
http: //www.mhhe.com/pressman.