~ F E

DEL S®FTWARE
Un enfoque practico

• •
•
•
•
•
•
--- - •
•
• I
I l· •

•
.' "-- ~\'I.,
 CAPiTU LO

MODELADO
,
DEL ANALISIS

E
CONCEPTOS n el ambito tecnico. la ingenieria de software comienza con una serie de
CLAVE tareas de mo del ado que conducen a una especificaci6n de requisitos y a
ooiI"'del una representaci6n completa del disef\o del software que se construira. EI
IIooinIo .... .. 194 modelo de analisis, qu e en realidad es una serie de modelos, es la primera repre-
ooiIsi. sentaci6n tecnica de un sistem a.
_urado ... 196 En un libra sobre metodos de model ado del analisis, Tom DeMarco [OEM 79]
dose••. •••• •219 describe el praceso de la siguiente manera:
..,..... de
Al observar los problemas y fallas reconocidas de la rase de analisis es necesario agre-
IIojo de datos . •211
garle los siguientes objetivos:
IIOIIoIado

.......
.......1. • 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-

.......
dose• •••••• 219

_ • ••. 202
eRe •••• •••• 225
de dolo• ••••• 197
•
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-

_.10 ....
del CDlftpor·
234
plementaci6n) ..
Como minima se necesita ..
•sptdf"Kodo.
de ,onlrol •••• 215 • Algo que ayude a hacer una partici6n de los requisitos y a documentarla antes
orietolado de Ja especificaci6n ..
alliujo ••• ••• 211
• Algunos medios para el seguimiento y evaluaci6n de las interfases ..
objoto. de
dato• •..• .. .• 198 • Herramientas nuevas para describir la 16gica y la tactica, algo mejor que un
texto narrativ~.
reglas pt'actkas 194
Aunque DeMarco escribi6 acerca de los atributos del modelado del analisis hace
mas de un cuarto de siglo, sus contribuciones se siguen aplicando en la notaci6n
y los metodos modernos de model ado del analisis.

a,Qui ••? La palabro eocriIa as un
vehiculo morovilloso parala comunl-
caci6n, pero no es,
la mejor forma de rep~.""
requisitos para eI sofiwore1. cIe ~.
_
necesariament&,
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
que eo relativamente facil de entender y, aun mas
importante, conduce a una revision para Iograr la
c:orrecci6n, la inlegridad y 10 consistencia.
.Quilln 10 hac.? Un ingeniero de software [algu·
nos vace. lIamado analistol conslruye el madelo
empleanda requisitas abtenidas del d iente.
tpor que .s importante? Para validar los
..requisitos del software es necesa rio 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 dimensiones#, con 10 que $& ~ fa
U ""'_..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 ~.omi·madeIa de anellisis ~nal 10 validan
sianes. ',. las inlel~
~Cuales son los pasos? Los requisitosdell. . ,:,Cu61 .... producto obIenido? Para el
madan, funcionales y de comportamienlO;.:.;~.•.1IICde1o de anc'iIisis <i!sposible elegir una amplia
madelan mediante varies ~pos 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. EI.~de 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 pracescimlerliO,;~.~1eIado ~.Jj\!KWado del aOOlisis deb... revisar-
basado en doses define objetos, ~t-- 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 1 r ANi,LISIS DE R§QyISIIOS

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
EI modelo de onolisis y
Ie especificoci6n de para evaluar la calidad una vez construido el software.
requisitos proporciono Por medio del model ado del anal isis el ingeniero de software se centra primero
un media para evoluar en ei que, no en el como. ~Que objetos manipuia ei Sistema, que funciones debe
10 colidod uno vel que desempeflar el sistema, que comportamientos muestra el sistema, que interfaces se
el sohware este
conslruido. 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.
 CAPITULO 8 MODELADO DEL ANAusIS 193

Elmodelo de
cm6l1s1scomo
an puente De5Cripcion
ae 1a del sistema
descrtpclon
del sistema y
I1modelo de
diseno.

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 Iado de requisitos. EI analista debe modelar 10 que se conoce y utili zar ese
modelo como base para diseiiar un incremen to de software. 2

8.1 .1 Filosofia y objetivos generales

EI modelo de analisis debe cumplir tres objetivos primari os: I ) describir 10 que
requiere el cliente, 2) establecer una base para la creaci6n de un disefio de so flwa -
re, y 3) definir un conjunto de requisitos que puedan validarse una vez conslruido el
soflware. EI modelo de analisis Ilena el vacio entre una descripci6n al nivel de siste -
ma (capitulo 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 (capitulo 9) - que detallan la arquitectura de aplicaci6n del so fl -
ware, la interraz con el usuario y la estructura en eI nive I 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 analisis 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 realiza 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 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 ejemplo, es posible que se requiera una base de
datos, pero las clases necesarias para implementarla, las funciones que se
requieren para acceder a ella y el comportamiento que se exhibira cuando se
utilice debe considerarse solo despues de que se haya completado el analisis
de dominio del problema.

• Se debe minimizar el acoplamiento de todo el sistema. Es importante repre-

sentar las relaciones en tre clases y funciones. Sin embargo, si el nivel de
"interconexion" 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 rcun scripcion tiene su propio uso del modelo. Por
ejemplo, los interesados relacionados con los negocios deben utilizar el
modelo para validar los requisitos; los disefiadores, como base para el disefio;
la gente de asegu ramiento 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 requisitos (capitulo 7) se establecio que los patrones de
[n wwwJI.....
analisis a menudo ocurren de nuevo en muchas aplicaciones dentro de un dominic
,om/lngIi.h/
Software de negocio especifico. Si estos patrones se definen y se clasifican por categoria de
Inglneerlog/ una manera que permitan a1 ingeniero 0 al analista de software reconocerl os y reu -
51_","5.••,
pueden enconrrorse
tilizarlos, la creacion del modelo de analisis se acelera. Un factor de mayor impor-
mochos recursos atlles tancia es que la probabilidad de aplicar patrones de disefio reutili zables y compo-
pora eI onOlisis del nentes ejecutabl es de software aumenta en forma sustancial. Esto ofrece tiempo al
dominio.
mercado y reduce los costos del desarrollo.
 CAPiTULO 8 MODELADO DEL ANALISIS 195

Entrada y salida para el cmcl1isis del dominio.

Literatura tecnica
- Taxonomias de close

Fuentes del
Aplicociones existentes / \ Estondares de reutilizadon
Sondeos a los clientes Modelo
conocimienlo Anal;.;. Modelos funcionales de an61isis
del dominio Recomendocion experto del dominio del dominio
~ Lenguojes de dominio
Requisitos octuoles/futuros '\..
- --'

~Pero, 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 "dominio 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"

,.,iij!,! iih' &1 John l.ck.
Enwww.sei•
.....fslrf
descriptionsf
detIo.bhnl puede En cierta forma, el papel de un analista de dominic es similar al de un maestro
enconlTorse una forjador de herramientas en un ambiente de manufactura pesada. EI trabajo de este
exposici6n volioso
sobre el onlliisis y10 ultimo es disefiar y fabricar instrumentos que puedan ser usados por much a gente
ingenieno del dominio. 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 colab·oraci6n 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 orien tados a objetos en forma predominan te.

B[olnolisil os frustronte, lIeno de relociones interperlonoles complejol, indefinido y dill«l. 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 represe ntaciones 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 derivaci6n 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.

,Por que debemos construir modelos? ,Por que no (onstruimos el sistema y yo? Lo respuesto es que podemos
If

construir modelos de tal forma que resoltemos 0 enfaticemos dertos coracteristicas criticos de un sistemal 01 mismo
nempo que quitomos ;nlolil 0 otros' olpectol del liltema."
Ed YOIrdon
 CAPITULO 8 MODELADO DEL ANAuSIS 197

E~mentos basaOos Ele mentos on.ntados

Elementos en escenanos 01 fluio
delmodelo Cosos de usa, redo DiogfOmoS de Huio de dolos
Cosos de usa, diogromo$ Diogromos de Ruio de (onlrol
de anCilisis. Diogromos de odividod NOffOlivos de proce$Omienlo
Diogromos de corril

Modelo de an61isis

Erementos basadas Ele mentos de

en closes
Diogromos de dose
Poquetes de o nalisis
Modelos CRC
Diogromos de coloborod6n
camDOrtamiento
Diogromos de estodo
Diogromos de secuencio

EI modelado del analisis a menudo comienza con el mode/ado de datos . EI ingeniero

o analista de software define todos los objetos de datos que se procesan dentro del
sistema y las rela ciones entre los objetos 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 so ftware debe en tender. Informaci6n compuesla se refiere a algo que tiene
muchas propiedades a atributos diferentes. Por 10 tanto, "anchura" (un valor 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 .
,Como se Un objeto de datos puede ser una entidad externa (por ejemplo, cualquier cosa que
manifiestan produzca 0 consuma infonnacion). una cosa (por ejemplo, un reporte 0 un despliegue).
a si mismos los
un suceso (como una lIamada telefonica) 0 un even to (como una alarma), un papel (por
dalas denlra del
contexto de una ejemplo, un vendedor). una unidad organizacional (como un departamento de conta -
oplicadon? 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 referencia dentro de un
objeto de datos a las operaciones actlien sobre los datos S Par 10 tan to, el objeto de
datos puede representarse como una tabla, tal como se muestra en la figura 8.4. Los
Un objetode datos es encabezados de la tabla reflejan los atributos del objeto. En este caso, un auto se
uno representoci6n de
define en te rminos de marca, modelo, numero de serie, tipo de carrocerfa, color Y pt'Opieta-
cuolquier informacion
compuesto que se rio. EI contenido de la tabla representa ejemplos especificos del objeto de datos. Por
proceso (on software. ejemplo, un Chevy Corvette es una muestra del objeto de datos auto.

5 Esta distinci6n sepa ra los objetos de datos y las clases u objetos definidos como parte del enfoque
orientado a objetos.
198 PARTE DOS PRAcnCA DE LA INGENIERiA DEL SOFTWARE

Representaclon Une los obietos de dotos entre 5i,

Nombres
tabular de en este coso, propielorio
de otributos
objetos de
datos.
/ r_ _ _~A'-_ _ _~,

Atributos
~
Atributos
idenlificodor descriptivos referencioles
~~ ~

- Morea
lexus
Modelo # de id.
l5400 AB123.
Tipo
Sedan
Color
Blanco
Propietario
R5P
Ins! oneie Chevy Corveffe X456. DeportivQ Roje CCD
BMW 750il XZ765. Coupe Blanco Ul
Ford Taurus Q12A45. .. Sedan Azul BlF

Los otribulos definen a
un objeto de dotos,
describen ~s
corocteristicos y, en
algunos rosos, hocen
referencio (] olro
objeto.
8.3,2 Atrlbutos
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 identiflcador; es
decir, el atributo identificador se convierte en una "clave" cuando se desea encontrar
una ocurrencia del objeto de datos. En algunos casos, los valores para el (los) iden-
tiflcador(es) son (micas, aunque esto no es un requisito. En referencia al objeto de
datos auto, un identiflcador razonable podria ser el numero de serie.

; ." ;

EI (oocepfo Ilomrn:lo
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
"normoliloci6n· es para una aplicaci6n que utilice el Departamento de vehiculos de motor, pero estos
importonte pam todos atribu tos serian inutiles para una compania automotriz que necesite un software
oquellos que intenton para el control de fabricaci6n . En este ultimo caso, los atributos para auto tal vez
realizer modelodo de
detos. En www. incluirian tambiE!n nurnero de serie, tipo de carrocerfa y color, pero ademas tendrian que
d"amodel.Olg adicionarse much os mas atri butos (como c6digo interior, tipo de tren de rnanejo, designa-
puede encontrorse UflO dar de paquete de ajuste, tipo de transmisi6n),.para hacer de auto un objeto s i gnificativ~
intJOducci6n om.
en el contexto de control de fabricaci6n.

~
Objetos de datos y clases 00, "son 10 mismo?
(uando se debate ocerco de los objetos de
datos es comun que suria una pregunto: aun
ob jeto de dotos es 10 mismo que una dose orientado a
ob jetos? La respuesta es: "noN.
Un objeto de dotos define un elemento compuesto de
los datos' esto es incorpora una coleccion de elementos de
datos individuale's (atributos) y do un nombre a 10
coleccion de elementos (el nombre del objeto de datos).
Uno dose 00 encapsula atributos de los datos, pero
tambien incorpora las operociones que manipulan los
datos implicodos por dichos atributos. Ademes, 10
definicion de doses implico una infraestructura completa
que es parte del enfoque de la ingenierio de software
orientado a objetos. Las doses se comunican entre 51 a
troves de mensajes; pueden organizarse en jerorquios;
proporcionan caracteristicas heredadas para objetos que
son uno instancio para una dose .
 CAPiTULO 8 MODELADO DEL ANAuSIS 199

Relac10nes
entre objetos
p."ono I IoUlomov;1 1
de datos.
0) Una conexion b6sica entre objetos
de dotos

b) Relaciones entre objetos

de datos

8 .3.3 Relaciones
Los objetos de datos estan conectados entre si de muchas maneras diferentes. Por
ejemplo. dos objetos 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
Los lelociones indicon
~ monelO en que los
respuesta se determina entendiendo el papel de las personas (propietarios, en este
objetos de dotos eston caso) y de los autos dentro del contexte del software que se construira. Se puede
conectodos entre sf. definir un conjunto de parejas objeto/ relaci6n que definan las relaciones re levantes.
Por ejemplo:
• Una persona posee un auto,
• Una persona esta asegurada para conducir un auto.
Las relacionesposee 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 definido 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 proporciona suficiente informaci6n para los
prop6sitos de la ingenieria 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 relac i6n dada. Tillmann [TIL93] define la cardinali dad de un par
objeto/ re laci6n de la siguiente manera: "Cardinalidad es la especificaci6n del nume-
200 PARTE DOS pRAcnCA DE LA INGENIERlA DEL SOFIWARE

,COmo se ro de ocurrencias de un [objetoj que puede relacionarse con el numero de ocurren -

maneja una cias de otro [objetoj". Por ejemplo, un objeto puede relacionarse solo con otro obje-
situation en 10 to (una relacion I : I ); un objeto puede relacionarse con muchos objetos (una relacion
que un objeto de
I:N); un numero de ocurrencias de un objeto puede relacionarse con algun otro
datos esta rela~
donado (on 10 numero de ocurrencias de otro objeto (una relacion M:N)6 La cardin alidad tambien
o(urrencia de define "el numero maximo de objetos que puede participar en una relacion" [TIL93] .
muchos olros Sin embargo, no indica si un objeto particular de datos debe participar 0 no en la
objeto, de doto,? relacion. EI modele de datos agrega modalidad al par objeto/ rela cion 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
relacio nale!., 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.
Ya se ha hecho una introduccion de 10 notacion
rudimentaria para eIDER. Los objetos de datos se
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 re lacion. 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

La modalidad de una relacion 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 tene r muchos sobrinos y un sabrina puede tene r 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 ANAuS IS 201

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 01modelado
entidad-relaci6n.
Oroefe/Designer, desarrollado 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, desa rrollado per Madrone Systems
(www.madronesystems.coml. es uno herramienta para
el modelado de datos de bajo costo que do soperte a
10 representacion gr6fica 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 va riedad de
fvnciones de modelado del analisis, incluido el
modelado 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 las decadas de 1980 y 1990, existie-
ron muchas opiniones diferentes (por ejemplo, [BER93], [TAY90], [STR88], [B0086]
acerca de las respuestas correctas a estas preguntas. En la actualidad ha surgido una
vision coherente de la 00.
EI objetivo del amilisis 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 req uisitos basicos del usuario entre el cliente y el in-
geniero de software.
2 . Deben identificarse las clases (es decir, se definen los 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 comportamien to del objeto.
6 . Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo
este comple to.

8 Las herramientas mencionadas aqui son una muestra de esta categoria. En la mayoria de 105 casos
los nombres estan registrados 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 plano de Irabajo) que describe una coleccion de objelos
bien establecidos en el mundo de 10 ingenieria similares.
del sohware. A continuoci6n 5e presentan los descripciones Objelos: inslancias de una close espedfica. los obielos ,
abreviodos de conceptos 00 que 5e encuentran con heredan los atributos y operaciones de una close.
frecuencia durante el modelado del ancilisis. En el capitulo
Operaciones: tambiEln lIamodas mefodos y servicios,
lOse presenton aIres objetos 00 que est6n alineados de
proporcionan 10 representacion de uno de los
monero mas cercone 01 diseno de software.
comportamientos de una close.
Atributos: una colecci6n de valores de los datos que
Subclase: una especializacion de 10 superclase. Uno
describen una close.
subclose puede heredar tanto los atributos como las
Close: encapsulo los dotos y las abstracciones de operaciones de una superclase.
procedimiento requeridos para describir el contenido y el
Superclase: tambien lIamada uno close basico, es una
comportomiento de alguna entidad del mundo real. Oicho
generalizacion de un conjunto de closes que estan
de olra manera, una clase es una descripcion
relacionadas con ella.
generolizada (por ejemplo, una plantilla, un patron 0 un

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 caracterizar 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.
 CAPITULO 8 MODELADO DEL ANALlSIS 203

de un actor definido.lO Pero como puede saberse 1) .;.sobre que escribir? 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
En afgunas situa- casas de usa. Las reuniones para la recapilacion de requisitas, despliegue de la fun-
(ianes, fos casas de cion de calidad (QFD) y atros mecanismas para la ingenierla de requisitas se utilizan
usa se vuefven ef
para identificar a las interesados, definir el ambito del problema, especificar las
mecanismo
dominante de fa inge- metas aperativas glabales, esquematizar todas las requisitas funcianales canacidos
nierfa de requisifos. y describir las casas (abjetas) que manipulara el sistema.
Sin embargo, esto no El desarrollo de una serie de casos de uso se comienza haciendo una lista de las
signifiea que deban funciones a actividades que realiza un actar especifico. Estas pueden abtenerse de
descof/Voe los
una lista de funciones requeridas del sistema par medio de conversaciones can los
mnceptos y temicas
eslud/odos en el clientes a usuarios finales, 0 mediante una evaluaci6n de los diagramas de actividad
copilulo 7. (seccion 8.5.2) desarrolladas camo parte del madelada del analisis.

Desarrollo de otro escenario de uso preUmlnar

II escenario: Uno sola de
II1II""'' ' 'aultln'lela segundo junto para 10 recopilacion
~.CI!I,",S: Jamie Lazor, miembro del equipo de
Robbim, miembro del equipo de software;
'II~:~,'.::~:i~ngenierio 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.
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
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

movimiento y los acercamienlos de una c:6maro

De ocuerdo, entonces b6sicamente hay dos
funci6n de vigilancia ... 10 primero
~Vura.llislerna, induyendo el establecimiento de un
-necesitomos herramientos que cyuden
rt;~:~:~ 0 hacerlo- y Ia segundo parte es 10 funci6n
':~i real en sf misma. Como eI establecimiento
especi~ca. Especi~co 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.
Jamie: Eso$ se lIaman vistas en miniatura.

.~
.•
~r.;;;~ '~S 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
. . ._ ..... (.....riencIo): Me quilasfe las palabras funci6n de vigilancia tengo Ie misma opariencia que
boca. todas las otras inlerloses de HogarSeguro. OUi.... que
.,. r I ....: Mm ... Quiero tener occeso a 10 funci6n de sea intuitiva; es decir, que no sea n&Ce$Orto leer un
~, yo sea a troves de 10 PC 0 de Internet. Siento
manual para poder usorta.
que eI ocxeso por Internet serio eI de uso mas frecuente. Moderador: Suen trabajo, ahara entremos en esta
De ........ier monera, quiero ser capaz de desplegor funci6n con un poco m6s de detalle ...
Wtos de las c6ma1'O> en uno PC y cantrolar el

La funcian de vigilancia en el hagar de HogarSeguro que se examina en el recua -

dro identifica las siguientes funciones (una lista abreviadal que realiza el ac tor iden-
tificado como propietario de 1a casa:

• Tener acceso a la camara de vigilancia via Internet.

• Seleccionar la camara que desea ver.
• Solicitar vistas en miniatura de tadas las camaras.
• Desplegar vistas de 1a cama ra en una ventana de una Pc.
• Controlar la visi6n panoramica y de acercamiento en una camara especifica.
• Registra r en forma select iva la salida de camara.
• Repetir la salida de camara.

Con forme se reali zan las conversaciones posteriores con el interesado (quien
desempef\a el papel de un propietario), el equipo de recopilacian 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 mismo caso de usa utilizando un formato estructu -
rado similar al propuesto en el capitu lo 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 siguiente rel ata:
 CAPITULO 8 MODELADO DEL ANAuSIS 205

caso de uso: Acceso a camara d e vigilancia-des plie gue de vis tas de camara
(ACV-DVC)
Actor: propietario
Si me encuentro en un lugar lejano puedo usar una PC con un soflware de navegad6n
apropiado para en trar al sitio web de los productos HogarSeguro , Ingreso mi clave de usua -
rio y dos niveies de con trasenas y, despues de que estoy validado, tengo acceso a toda la
funciona lidad 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 cua l identifica la camara clave. 5i quiero cambiar de camara, elijo "seleccio-
nar una camara" y la ven tana 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 in teracci6n como una secuencia
orden ada de las acciones del usuario. Cada acci6n se representa como un enuncia-
do declarativo. Despues de vi sitar la funci6n ACV-DVC, se puede escribir:
Caso de uso: Acceso a camara de vigilancia-despliegue d e vis tas de camara
(ACV-DVC)
Actor: pro pietario
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 funciones 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 algunas 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 PARTE DOS pRAcnCA DE LA INGENIERlA DEL SOFlWARE

Por supuesto, para una comptensi6n comple ta 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:

,COmo se • LEI acto puede ejecutar atra acd6n en este punto?

examinan
(ursos • "Es posible que el actor encuentre alguna condici6n de error en este punto? 5i
alternativo5 de es asi, l..cual podria ser?
acci6n mientras • "Es posible que el actor encuentre algun otro comportamiento provocado por
se desarrollo un
algun evento fuera de su control? 5i es aS1, Lcual podria ser?
coso de usa?
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 elige "seleccionar una cama ra".

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 cond ici6n 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 muestran 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

Coso de uso: Acceso a la camara
de vigilancio-despliegue de vistas
de comora (ACY·DVq.
Actor primario: Propietorio
Meta en conlexlo: 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
usuarios.
Disparodor: 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.
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 fvn ci6n 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.

3. EI propietorio introduce dos controsenas (cada una Prioridod: Prioridad moderacla, que se
de aI monos acha coracte,..,. impiemenlQr6 despue. de 10.
... EI sistema despliega todos 10. botones de las Funciones b6sicos.
Iunciones me. impartante•. Oisponible en; EI tercer incremento.
5. EI propietario selecciona "vigilancia" de los botones Frecuencia de uso: Poco frecuente.
'de las, funciones mOs importontes. Conal hacio el odor: A troves de un browser bosodo en
6. EI propietario seiecciona "escoger uno coma ron. PC y conexi6n de Internet al sitio
7. EI sistema despliega el plano de 10 cosa. web de HogarSeguro.
8. Et propietario selecciono el icono de una camara del Adores secundarios: Administrodor del sistema,
plano de planlQ. comoros.
9. EI propietario selecciona el boron "vista". Canales hacia los adores secundarios:
10. EI sislemo despliega una ventana de visualizaci6n 1. Admi[listrador del sistema: ~istemo basodo en PC.
que est6 identificodo can 10 10 de la comaro.
2 . Camaras: conectividad inalombrica
208 PARTE DOS pRACTICA DE LA INGENIERlA DEL SOFrVVARE

Aspectos pencli.nles:
1. aCu61 es eI meconismo que protege contro el usc no
autorizado de esfa capacidad pa' parte de los
empIeados de Ia campania?
2. ela seguridod $$ sofidente? EI ingreso no outorizodo
en esta carocteristico representario una invasi6n
impartanle de Ia privocidod .
3. ilo respuesta del sistema via Internet ser6 ac:epkIhIe
dado el ancho de banda requerido para las vistas
de cornaro?
4. iSe desorrollor6 uno capacidod para proporcionor
video a una tosa mayor de cuodros pot' segundo
cuando esten disponibles conexiones con ~
oncho de banda?

•. MI,}!.!!,) &1 En muchos casas no es necesario crear una representacion gratica de un escena- ,
t(uando se han rio de lisa. Sin embargo, la representacion diagramatica puede facilitar 1a compren-
terminodo de escribir los sian, en particular cuando el escenario es complejo. Como se mendono en el capi-
(Osos de usa? POf{! uno
exposici6n volioso de tulo 7, el UML proporciona una capacidad para hacer diagram as de casos de uso pre-
asle t6piro, veose liminar para eJ producto HogarSeguro. Cada caso de uso se representa mediante un
ootips.org/ 6valo. En esta secci6n 5610 se ha examinado en detalle el caso de uso para eJ ACV-
use~cases'1loae.
hlmloo!ip••org/ DVe.
use-cases'1ione.
hlml. 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 utiliza 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.

Diagrama HogorSeguro
prellminar de
casode uso
para el Camoras
sistema
HogarSeguro.

~ \
Propielario
de 10
coso
 CAPITULO 8 MODELAOO DEL ANALISIS 209

Diagrama de
actlvidad
Introducir contrasefia }-_ _ _ _ _ _---,
para la
e ID del usuario
funcionde
acceso a la
cCanara de
vigUancia-
despliegue Contrasefias/ID v61idas Contrasefias/ID no validas
de vistas de
camara. Opcion para
Tambien se pueden _":::::='-7':;';';";;'~~
seleccionar
otras funciones

No reston
intentos de entrada

Vistas en miniatura Seleccionar una

camara especifico

Solir de esta funci6n Ver olro camara

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-
Un diagrama de pIo, un usuario puede intentar ingresar la IDusuario y la contrasefta s610 un nume-
ocnvidad en UMl ro limitado de veces. Esto se representa mediante un rombo de decisi6n debajo de
representa las acciones opcion para reingreso.
y decisiones que
ocurren mientros se 8.5.3 Diagramas de ccmil
realiza alguna fund6n.
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 ___ (oPCi6n para reingres<)
pueden
~Ieccionar I ~:on inlenlos
olras Seleccionor vi9ilonci~ @ e enlrodo
funciones
No reston

". .-A'-,"·,"·
intentos de entrada

miniatura cornaro especifico

I(Seleccionar una camara

Selecdonar un )
espedfica-vislas
kono de camara
I \. en miniatur~
I I
r Generor solido
)
~ de video

( Visto de salida de camara ~ Opci6n

para olro vista )
"-
A
en uno ventana eliquetodo..J
Solirde
.-=eslo funci6n
~ Ver olro
cornaro

como segmentos paralelos que dividen el diagrama en forma vertical, como los
ca rriles de una alberca.
Existen tres clases de analisis - Propietario, Interfaz y Camara- con responsa -
Un diDgtamD d, bilidades directas 0 indirectas en el contexto del diagrama de actividad representado
wniles en UMl en la figura 8.7. Respecto de la figura 8.8, el diagrama de actividad se reorganiza de
representD ,I fluiD d, forma que las actividades asociadas con una c1ase de analisis particular pertenezcan
las acciones y las
al carril correspondiente a dicha clase. Por ejemplo, la clase Interfaz representa la
dedsiones e indica
cuales oelores reolizon interfaz con el usuario de acuerdo con la vision del propietario. El diagrama de activi-
woo uno de ,liDS. dad considera dos opciones que son responsabilidad de la interfaz: opcion para eJ rein -
 CAPiTuLo 8 M ODELADQ 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 UM L y proporcionar un
conocimiento adicional de los requ isitos 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 lluyen 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 fiujo 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 permite que el ingeniero de software desarrolle mode-
tc'ONSUO. los del dominio de informacion y del dominio funcional al mismo tiempo. A medida
JJgunas pe5anas que el DFD se refina hacia grados mayores de detalle, el analista desempeiia una
sogieren que elOFO descomposici6n fun ci onal implicita del sistema. Al mismo tiempo, el refinamiento
es de "I"ieia del DFD resulta en un correspondiente refinamiento de datos mientras se mueve
escue/a" yque no
hacia los procesos que incorporan la aplicacion
hene siha en hJ
prodico I1Klfieml1. Unas pocas directrices simples permiten obtener una ayuda invaluable durante la
Es10 es uno vision que creacion de un diagrama de flujo de datos, I ) el nivel 0 del diagrama de flujo de datos
exdaye uno forma de debe representar al software / sistema como una sola burbuja; 2) la entrada y la sali-
representocion poten- da prima ria deben establecerse con cuidado; 3) la refinacion debe comenzar por el
cialmente uhl 01 nivel
de analisis. 5i es de aislamiento de procesos, objetos de datos y almacenamientos de datos candidatos a
oyudo, se recomiendo ser representados en el siguiente nivel; 4) todas las flechas y burbujas se deben rotu-
desempleor el om lar con nombres significativos; 5) se debe m~ntener la continuidad del flujo de infor-

13 EJ modelo de flujo de datos es una actividad de modelado esenciaJ en el andlisis estructurado.

212 PARTE DOS pRAcnCA DE LA rNGENIERlA DEL SOITWARE

DFD aI nlve1 Despliegue

Ponel Comondos y dolos Despliegue del panel
de contexto de control del usuorio de informacion de control
para la
funcion de Tipo
segurtdad de
HogarSeguro.

$ensores
Estatus
de alarmo

B Linea
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 relacionada 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 calificar a expandir un
camando.
L, connnuid,d del flui' EI DFD de nivel 0 ahara se expande a un modelo de flujo de datos de nivel I . <Pero
de informnci;n debe
como se logra esto? Un enfoque simple, pero efectivo, es realizar un "analisis gra-
montenerse conforme
se renna coda nivel del matical" [ABB83] sabre la narrativa que describe la burbuja al nivel de contexto. Esto
OFO. Est, signinco que es, se aislan todos los sustantivos y verbos en la narrativa de procesamiento de
I, entr,d, y solid, en HogarSegurol5 obtenida durante la primera reunion para la recopilacion de requisi-
un nivel deben ser los
tos. Can propositos ilustrativos, considerese el siguiente texto narrativo de procesa-
mismos que 10 entrada
y solido en un nivel mien to can la primera aparicion de todos los sustantivos subrayados y la primera
rennod,. 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
 CAPiTULO 8 MODELADQ DEL ANALISIS 213

La funci6n de seguridad de HogarSeguro pennite al pro12ietarjo configurar el sistema de se-

tc'ONSEJO" ~ cuando este se instala, monitorear todos los sensores que se coneclan al sistema
EI analisis gromancal de seguridad y que inleracluan can el propietario a traves de In.t..e.r.nct, una K 0 un ~
no 85 apruebo de de controL
errores, pero puede Duran te la instalaci6n, la PC de HogarSeguro se utiliza para programar y configurar el
proporcionar un ~. A cada sensor se Ie asigna un m!m..e.m y tipQ, se programa una coolrasena ma-
excefente paso inicial
~ para habjijtar 0 deshabi}jtar el sistema, y algunos numeros telef6nico$ ingresan para
wando existe alguna
difiwl/ud para delinir marcarse cuando se presenta un even to en los sensores.
abjetas de datas ylas Cuando se reconoce un even to en los sensores, el software soJicita una alarma audible
transformociones que que el propietario especifica durante las actividades de configuracion del sistema, el soft-
operon sabre elias. 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
telefon ico 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

DFD de nivel 1
para la funci6n
de seguridad de
HogarSeguro.
......_..., ........Confi g uraci6n
de aatos
Configuraci6n de informaci6n

Procesar Despliegue
contrasena Mensal·e .....,===-1 del panel
de ID va ido de control
Configu raci6n

\=-__I~nf~o:r~m~O~C~i6~n~~::=: --------~
de oatos
del sensor __ ~
Sensores 1---."...,...,---1 Tipo de cilarma
Estatus sensores
del sensor linea
Tonos del numero telefonica
telefonico
214 PARTE DOS PAAcnCA DE LA LNGENIERiA DEL SOFTWARE

OFD de nivel 2
Informacion
que refina el del sensor
procesode
monitoreo
de sensores. T;r.
Informacion de configuroci6n alorma

Datos
de configuraci6n

Numero
telef6nico
ID,Iipo
de sensor
Mercer
lelMono

Estatus
d el sensor Tonos de numeros
telef6nicos

entre 51. Por ejemplo, a cada sensor se Ie asigna un numero y un tipo; por 10 tanto,
fl'ONSlJO" el numero y el tipo son atributos del objeto de datos sensor. Entonces, al realizar un
Se debe tener 10 analisis gramatical sobre la narrativa de procesamiento para una burbuja en cual-
segur;dod de que rodo quier nivel del DFD, se puede generar mucha informaci6n uti I acerca de c6mo pro-
fo narrafiva de prOCfr ceder con la reflnaci6n para el siguiente nivel. En la figura 8.10 se presenta un DFD
samiento Que se
intenta anolizar e5th de nivel I para el cual se ha utilizado esta informaci6n. EI proceso al nivel de con-
escrifa con el mismo texto mostrado en la figura 8.9 se ha expandido a seis procesos obtenidos de un exa-
grado de obslro((;On. 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 inform aci6n entre los niveles 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 aplicaciones el modelo de datos y el diagrama de flujo de datos
son todo 10 que se necesita para obtener una visi6n significa tiva de los requisitos del
 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 aplicar 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 cond iciones (vacio, saturado, lIeno). En la seleccion de los even-
tos que son candidatos potenciales se sugieren las siguientes directrices,

lComo se • Hacer una lista de todos los sensores que el so ftware "lee".
seleccionan
• Listar todas las condiciones de interrupcion.
105 eventos
pOlencioles para • Li star todos los "interruptores" que maneja un operador.
un diagrama de
• Ustar todas las condiciones de datos.
,onlrol delll.jo,
un diagrama de • De acuerdo con el analisis de sustantivos y verbos aplicado a la narrativa de
eSlado 0 una procesamiento, revisar todos los "elementos de control" como posibiJidades
especificacion de de entradas y salidas del control de flujo.
(antral?
• 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 comportam iento. 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 encon trar
si existen "hoyos" en el comportamien to 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 representaci6n de informaci6n.
216 PARTE DOS PAAcrTCA DE LA JNGENIERIA DEL SOITWARE

Di agrama de estado para la funcion de seguridad de HogarSeguro.

-
~ Inlerruptor
in icie/para,
encendido
Entror/inicior
Reinido

E~loIussi$lemo ~inodivo'
Entrorjinicior despliegueMensoje 1
Nlniciondo sistemo"
Entrar/iniciar despliegueMensoje2
"POI" favor espere"
Sistema
correcto

Reinic io
DesO(upodo

Enlrorjinicio r Estoll.lssistemo "inocliVQ'

Enlror/inicior despliegueMensojel
Entrar/ini<:ior despliegueMensaje2 ...
"listo~

Entrar/iniciar despl iegueEstatvs estable

GolpedetedolTedodemonejo
Enlror/iniciar despliegueEstolus deslello
lenlo
Hoeer: correr diognoslicos

• I
FolloDetectodo/ inic iar
Activor I apagado/control
Apogodo
1
despliegueMensaje2 "conlodar
01 Yendedo r"

MonitoreoEstatusSistema
I desoctivorControsena
desact ivorCon troseiio

AccionEnAlarma
@
fa lsaAlarma
Entror/inicier EsloltJ!.!;istema ~monitoreo" Enlrm/inieiar EsloltJs$i~tema
Entrm/iniciar despliegueMensojel NArmado" tiempoFuero "moniloreoYAlarmo'
Enlrer/inieior despliegueMensaje2 N. Enlrar/inieiar despliegueMensojel
~ALARMK
Enlrar/inieior despliegueEsfotus esloble
Haeer: monitorearYConlrolarSblema EOlrar/ioieiar despliegueMeosaje2
Golpedetedo/Tedademonejo senso rDispo rodo/ disporadordeSensor
ioie io Temporizodor 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) indica que las transiciones desde
el estado desocupado pueden ocurrir si el sistema se rei nicia, activa 0 apaga . Si el sis-
tema se activa (es decir, se enciende el sistema de aiarma) ocurre una transicion
hacia el estado MonitoreoEstatusSistema, los mensajes que se despli ega n cambian,
como se muestra, y se solicita el proceso SistemaControiyMonitoreo . Con el estado
Monitoreo Stratus Sistema ocurren dos transiciones: 1) al desactivar el sistema se pre-
senta una transicion de regreso al estado desocupado; 2) cuan do se dispara un sen-
sor ocurre una transicion hacia el estado Acci6nEnAlarma. Duran te la revision se
consideran todas las transiciones y el contenido de todos los estados.

HOGARSEGURO

Modelado del flujo de datos

~
~ EI escenario: Cubfculo de Jamie, La conversaciOn:
despues de que ho conduido 10 ultimo reuni6n para 10 (Jamie ho bosquejodo los modelos que ",fIIUIIISInm_ ·;
recopilaci6n de requisilos. los ~guros 8.9, 8.10, 8.11 Y 8.12 Y",los 1I\IJEISIro'l:Il!i1i.~
Los actores: Jamie, Vinod y Ed, miembros del equipo Vinod).
de ingenierfo del soHwore de HogorSeguro. 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

"iI oslO un poco posado de modo, pero ,soben

~"" 'CIJIIda a dorificar las rosas.
No, esto es s6Io un modelo de Aujo con algunos
c.....II1Ic.. die comportomiento induidas.
11.'1. '"--- En!roda·proceso-solida. En ceot;dad los DFD son
r ...¥ .,lvitiv<>s... Si los observos par un momento,
Ed: ,De verdad?
Jamie: Sf, pero primero debemos desorroUar un modelo
de anolisis completo, y este no 10 es.
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.
(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.
Parece como si pudieromos convertir codo burbuja
Ii" '""$O'"p'",ente ejecutobJe... . 01 menos en el nivel mas
1iIii,&,..1o mejor porte, 51 '" puede. De hecho,
forma de traducir los OFO a uno arquitectura
Doug: Entonces, alas primeros dios estoron dedicados 01
desarrollo del modelo de on6lisls, eM
Jamie (con orgullo): Yo comenzomos.
Doug: Bien, tenemos mucho trabajo par hacer y no
mucho tiempo para hacerlo.
(los tres ingenieros de software se miran entre Sl y
sonden.)

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 informacion 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,
lo especificocion de tab las, diagramas 0 grafIcas. AI proporcionar una EP para acompanar cada burbuja
proceso es uno
en el modelo de flujo, el ingeniero de software crea una "miniespecificacion" que
a miniespecificocion"

poro codo puede servir como guia para el diseno del componente del software que implemen-
tronsformocion en el tara el proceso.
nivel menos refinodo Para ilustrar el uso de la EP, considerese la transformacion procesamiento de con-
de un OFD. 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.
2 18 PARTE DOS PAAcnCA DE LA INGENIERiA DEL SOrtWARE

gu~ idad de HogarSegurb. El procesamiento de contraseila recibe una contrase na 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 va lida = verdaderoj se pasa a la funcion de mensajey despliegue deJ
estatus. Sf \a contrasefia maestra no coincide, se camparan los cuatro digitos con una ta -
bla de contrasefias secundarias (estas se pueden aSignar a invitados 0 trabajadores que
necesitan entrar en 1a casa cuanda el propietario no estc~). 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 coincidencia [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 so ftware creen que la versi6n en LDP se
puede posponer hasta que comience el diseiio de componentes.

~
AnCrIisis estruc turado
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.
Meccm ica : Los herramientas de esto categoria utilizon un
Ndiccionario de datos Ncomo 10 bose de dotos centrol paro
10 descripcion de todos los ob jetos 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 repre sentativas 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 he rromientas 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
metoherram iento uti lizada para definir un metodo de
anol isis 0 diseno (incluide en ono lisis 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

"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 presen tan 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 iden tifiearse. clasificarse y definirse con fac ilidad (en terminos de
atributos y operaciones) . Pero cuando se "observa" el espacio del problema 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 capitulo) 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 prob lem a. "Que se debe buscar despues de que todos los sus-
tantivos han side aislados? Las clases se manifiestan en una de las siguientes formas:

,De qui • Entidades externas (por ejemplo, otros sistemas, dispositivos, personas) que
forma se producen 0 consumen informacion que usara un sistema basado en compu-
manifiestan a si
tadora.
mismos las doses
de analisis (omo • Casas (por ejemplo, reportes, despliegues, letras, senales) que son parte del
elementos del dominio de la informaci6n para el problema.
espa,io de solu-
cion? • 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 ejemplo, gerente, ingeniero, personal de ventas) que desempenan
personas que interactuan con el sistema.
• Unidades organizacionales (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 utiliza de nuevo la funcion de seguridad de
HogarSeguro . En la seccion 8.6.1 se realizo un "analisis gramatical" sobre la narra ti-
va del procesamiento22 para 1a fu nci6n de seguridad. Al extraer los sustantivos se
puede proponer una serie de clases potenciales:

Clase potencial Clasificacion general

propietario popel 0 entidad externa

sensor entidad externa

panel de control entidad externa

instolaci6n ocurrencia

sistema la li as sistema de seguridadJ coso

numero, tipo no objetos, otributos del sensor

controsena maestro coso

numero telef6nico coso
evento del sensor ocurrenClo
ola rmo audible entidad externo
servi cio de monitoreo unid od organizocionol 0 entidod externa

La lista pod ria extenderse hasta que todos los sustantivos en la narrativa del proce-
samien to hayan side considerados. Observese que cada entrada en 1a !ista ha side

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.
 CAPiTuLo 8 MO DELAOO DEL AN AuSIS 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:

,Como se 1. Informacion referida. La clase potencial sera uti! durante el analisis solo si la
determina informacion ace rca de ella debe recordarse para que el sistema pueda funcio-
si una clase
nar.
pOlencial debe,
d. hecho, 2. Servicios requeridos. La clase potencial debe tener un conjunto de operaciones
(onvertirse en una identiflcables que puedan cambiar el valor de sus atributos de alguna manera.
dase de analisis?
3. Alribulos muJlipJes. Durante el analisis de requisitos el enfoque debe estar en
la 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 defln ir un conjunlo de atributos para la clase
potencial, y estes atributos pueden aplicarse 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 com o
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 modele 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 pOlenciales de HogarSeguro:

Clase potencial Numero de caracteristica que aplica

propietorio rechozodo; 1 y 2 fallon ounque oplico 6
sensor oceptodo · todos oplicon
ponel de control oceptodo: todos oplicon
222 PARTE DOS pRAcnCA DE LA INGEN[ERJA DEL SOfTWARE

instoloci6n rechozodo:
sistema (olios funci6n de seguridodl aceptodo: lodos oplicon
numera , tipo rechazada: falla 3, alributos del sensor
conlra sena maestro rechozodo: fo lio 3
numero telef6nico rechozodo: folio 3
evenlo del sensor oceplodo : lodos oplicon
olarmo audible aceplodo: aplicon 2, 3, 4 , 5, 6
servicio de moniloreo rechozodo: 1 y 2 fallan 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 identificarse par su voz, la
clase Propietario satisfaria las caracteristicas 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-
rifica 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
los olribulos son al aquellas "cosas" que "pertenecen" de manera razonable a la clase. Ademas, se debe
coniunlo de obielas de contestar la siguiente pregunta para cada clase: "Cuales elementos de datos (com-
dolos que delinen por
puestos 0 elementales) definen esta clase en el contexto del problema?
com~elo 10 close
denho del conlexto del Esto se ilustra considerando la clase sistema definida para Hogm5eguro. Se ha
problemo. 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 refin arse hasta un nivel
elemental, pero para los prop6sitos de este capitulo constituyen una !ista razonable
de atributos para la clase sistema (parte sombreada de la figura 8.13) .
 CAPiTULO 8 MODELADO DEL ANAuSIS 223

Los sensores son parte del sistema global de HogarSeguro , y aun asi no estan en-
Iistados como elementos de datos como atributos en la flgura 8.13. Ya se ha defl-
0
nido sensor como una ( lase, y varios objetos de sensor se asociarim con la clase
sistema. En general, se evita la definicion de un elemento co mo 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 objeto. Aunque existen muchos
tipos distintos de operaciones, "stas se pueden dividir, por 10 general, en Ires gran -
des categorias: I ) operaciones que manipulan los datos de alguna manera (por ejem-
plo, al agregar, borrar, reformatear, seleccionar), 2) operaciones que rea Ii zan un
computo, 3) operaciones que preguntan acerca del estado de un objeto, 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 "conocimiento" de la naturaleza de los atributos y
asociaciones de la clase .
Como una primera iteraci6n en la obtenci6n de un can junto de operaciones para
(uanda se delinen los una clase de analisis, el analista puede es tudi ar otra vez la narrativa de un procesa-
opefOciones para una
mien to (0 caso de uso) y seleccionar aquellas operaciones que pertenezcan de
dose de an6lisis, el
enfaque debe eslar en manera razonable a la c1ase. Esto se logra estudiando de nuevo el analisis gramati-
el comportamiento cal y aislando los verbos. Algunos de estes verbos seran opciones legitimas y pod ran
"ienlada 01 fXobiema conectarse con faci lidad a una c1ase especiflca. Par ejemplo, en la narrativa del pro-
yno en los comportcr
cesamiento presentada parrafos atras en este capi tulo, se observa que "al sensor se
mientos requeridos
pora 10 implemenf~ Ie asigna un numero y un tipo" 0 lise programa una contrasena maestra para habiH-
dOn. tar y deshabilitar el sistema". Estas frases indican algunos hechos:

,
Diagramade Sistema
close para 10
clase del ID sistema
sistema. verificaci6nNumeroTelef6nico
Eslatussistema
Tiemporelra so
Numerotelef6n ico
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

B. Modelos de c1ase

. .. 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
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.

lI Vinod: Entonces el plono de planta real esta hecho de

paredes y contiene comoros y sensores colocodos dentro
Vinod: No es diffeil, y los resultados son muy buenos.
les mostrore.
 CAPITULO 8 MODELADO DEL ANAuSIS 225

,
Diagrama de PlanodePlanta
clasepara
"po
PlanodePlanta nombra
(Vease el Dimensionesexlernas
an6:l.isis en el
recuadro). delerminarTIpo( )
posicionarPlanodePlantal )
escalar( )
cambiar color( )

Se ubica dentro de ~ I •
Es parte de

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

• ~

I Se usa para construir

I
~mento Ventana Ventana
de Pared
tipo tipo tipo
Coordenadasinicio Coordenadasinido Coordenadasinicio
Coordenodasfinal Coordenadosfinal Coordenadasfinal
Siguienle$egmenlo SiguienteVentano SiguienlePuerta
Pared

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 I~ 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 PARTE DOS PAACTICA DE LA INGENlERlA DEL SOITWARE

son los atributos y las op~raciones 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
Enwww. de manera directa del enunciado del problema (por ejemplo, Planodeplanta
IheuonkaIt._1 y Sensor). De manera tipica, estas c1ases representan c1ases gue se almace-
aG079..... puede
eJ]controrse uno naran en una base de datos y gue persisten durante la ap!icacion (a menos
Gxcelenfe exposid6n gue se borren de manera especifica).
de e,1e ,po de (osos.
• 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

Una carta
indice del
modeloCRC. 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
 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 vigil 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 entidad; 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 objetos 0 entre el usuario y la apli-
cacion. En general, las clases de controlador no se consideran sino hasta que
ha comenzado el disefio.

"Los objelOS pueden dosificorse de monerD cientifico en Iresgrandes 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:

·(uale, 1. La inteligencia del sistema se debe distribuir entre las c\ases para
directrices abordar de mejor manera las necesidades del problema. Cada aplica-
pueden apli,arse
cion abarca un cierto grado de inteligencia; esto es, 10 que el sistema sabe y
para la asignacion
de re'pon,abilida- puede hacer. Esta inteligencia puede distribuirse entre las clases de varias
de, a la, d.,e,? 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-
ponsabilidades anotadas en cada tarjeta In dice del modelo CRC deben eva-
luarse y asl comprobar si alguna clase tiene una lista 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 lidades 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 sola c1ase debe tomar
la responsabilidad de almacenar y manipular un tipo especifico de informa-
ci6n. En general, esta responsabilidad 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. Existen muchos casas en los que una variedad
de objetos relacionados deben mostrar el mismo comportamiento al mismo
tiempo. Como un ejemplo, considerese un videojuego que debe desplegar las
siguien tes 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 za rse y
desplegarse cuando el usuario manipula un joystick. Por 10 tanto, las respon-
sabilidades actualizar( ) y desplegar( ) deben compartirlas cada uno de los obje-
tos mencionados. EI Jugador sabe cuando algo ha cambiado y se requiere
actualizar( ). Colabora con los otros objetos para lograr una nueva posici6n u
orientaci6n, pero cad a objeto controla su propio despliegue.

Colaboraciones. Las c1ases cumplen sus responsabilidades en una de dos formas:

I) una c1ase puede utili zar sus propias operaciones para manipular sus propios atri-
butos, y con ello cumplir con una responsabilidad particular, 0 2) una c1ase puede
colaborar con otras c1ases.
Wirfs-Brock y sus colegas [WIR90] definen las colaboraciones de la siguiente
manera:
Las colaboraciones representan las solici tudes que un cliente haee a un se rvidor con el fin
de cumplir una responsabilidad. Una colaboraci6n es la materializaci6n de l contrato en-
tre el clien te 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.
 CAPiTULO 8 MOOELAOO DEL ANAuSIS 229

colaboraci6n senc il 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 pa rticular que ha implementado el servidar.

Las colaboraciones identifican las relaciones entre clases. Cuando un conjun to de

clases colabora para lograr algun requ isito, este puede organizarse en un sllbsiste-
ma (u n 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 la funcion de seguridad de HogarSeguro. Como
Si uno dose no puede
rumplir todos sus parle del procedimienlo de aclivacion, el objelo PaneldeControl debe determinar
obligcciones por s[ si algun sensor esta abierlo. Se define una responsabilidad lIamada determinar-eSia-
mismo, entonces se tus-sensor( ). Si los sensores estan abiertos, PaneldeControl debe eslablecer un
re{juiere uno atributo de estatus como "no listo". La informacion de los sensores se ob ti ene de
millborocion.
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 relac iones genericas diferentes enlre las clases [WIR90], I) la relacion es-
parte-de, 2) la relacion tiene-conocimiento-de, y 3) la relac ion 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. Considerense las clases definidas para el viqeo-
juego ya mencionado, la clase cuerpoJugador es-parte-de )ugador, al igual que
BrazosJugador, PiemasJugador y CabezaJugador. En UM L estas relaci one,; se
representan como la agregacion mostrada en la figura 8.16. .
Cuando una clase debe obtener informacion de otra clase se establece la relacion
tiene-conocimiento-de. La responsabilidad determinar-estatus-sensor( ) mencionada
an tes ejemplifica una relacion del tipo liene-conocimiento-de.
La relacion depende-de implica que dos clases lienen una dependencia que no se
logra mediante las relaciones tiene-conocimiento-de 0 es-parte-de. Por ejemplo,
cabezaJugador siempre debe estar coneclada a CuerpoJugador (a menos que el
videojuego sea violento en particular). Aun asi, cada objeto puede existir sin el cono-
cim iento 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 tarje ta
indice del modelo eRC enseguida de la responsabilidad que ha producido la colabo-
racion . Por 10 tanto, la tarjeta in dice oontiene una Iista de responsabilidades y las
colaboraciones correspondientes que permiten que las responsabilidades puedan
cumplirse (figura 8.15).
230 PARTE DOS pRAcnCA DE LA INGENIERiA DEL SOFIWARE

Unaclase Jugador
agregada
compuesta.

I I
T I I
CabezaJugadOl CuerpaJugadot BrazasJugada PiemasJugacior

Cuando se ha desarrollado un modele CRC completo, los representantes del clien-

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 ca tegorias.
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 con trol 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 ven tana 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 respon sabil idades anotadas en ella. EI grupo determina si una (0 mas)
de las responsabilidades sa ti sface el requisito del caso de uso.
 CAPITULO 8 MODELADO DEL ANALISIS 231

5. Si las resp onsabilidades y las co laboraciones anotadas en las tarjetas indice

no satisfacen el caso de usa, se hacen las modificaciones necesarias a la tar ~
jeta . Esto puede incluir la deflnici6n de clases nuevas (y correspon den a las
tarjetas de in dice de e RC) 0 la especiflcaci6n de responsabilidades 0 colabora-
ciones nuevas revisadas sobre las tarjetas existentes.

Esta forma de operacion continua hasta que se termina con el caso de uso. Cuando
se han revisado todos los casos de uso se contin ua con el modelado del analisis.

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 c~mbia 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 con~ 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,
d igomos 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
pe~mjten 01usuario selecdonor 10 situociOn.
232 PARTE DOS pRAcnCA DE LA INGENIERIA DEL SOFIWARE

PIonodepionta: el mismo que el obieto de vigiloncio, pero seleccionorSituoci6n PanelSituocibn (close)

este despliego los dispositivos.
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:
DespfegarConlrof(J, sefeccionorControf(J,
desplegarSituaci6n(}, seleccionarSituadon{},
entrarPlanodepfanta(L seJeccionariconoDispositivo(),
clesplegorPanelDispositivo(}, entrar PoneIDispositivo(),. ..
Close: InterfazAdministraci6nHogar
ReJponsabilidad Colabarador
desplegorConti'ol Paneloperaciones (close)
seleccionorControl Paneloperaciones (dose)
despiegorSituoci6n PanelSituacion {close}
entrarPlanodePlanta PlanodePlanta (close)
•
•
•
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)
Vinod: Exoctame~te. 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.
Ed: Bueno forma de encontror omisiones 0 errores.
Vinod: 51.

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
Una aSOciocion define reJaciones se Haman asociaciones. Vease de nuevo la figura 8.14; la clase PlanodePlanta
uno reloci6n entre se define al identificar un conjunto de asociaciones entre PianodePIanta y otras dos c1a-
doses. La multiplicidad ses, camara y Pared. La clase Pared se asocia con tres clases que penniten que se
define cuontos de uno
dose eston construya una pared, SegmentodePared. Ventana y Puerta.
relocianadas can En algunos casos, una asociaci6n se puede definir en forma mas extensa al indi-
cuontas de atro close. 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.
,Que es un En tales casos, una clase de cliente depende de alguna manera de la clase de servi-
• estereotipo? 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.
 CAPITULO 8 MODELAOO DEL ANALlSIS 233

Multiplicidad. Pared

I I I

- o. . • -
Se utiliza para Se utiliza para
construir construir

I ·1 Se utiliza para
construir
I .
O.
5egmentoPared Ventana Puerta

Dependencias. Ventana
Camara
Despliegue
«acceso»
...................•
(contrasenal

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 PARTE DOS PAAcnCA DE LA INGENIERlA DEL SOfTINARE

Paquetes. ...,.,.....,,.-,,.-,..,.._.......... Nombre del paquete

MedioAmbiente ! \.
+Arbol !: \...
+Paisaje
+Comino
,
,
...
+Pared R""lasDeUu-o I
+Puenle
+ReglasDeMovimiento
+Edificio +RestriccionesEnAcci6n
+EfectoVi sua I
+Esceno

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
Un poquete se u~liz(] ejemplo, las escenas visuales que el usuario ve mientras se desarrolla el juego.
para ensomblar uno Clases como Arbol, Paisaje, Camino, Pared, Puente, Edificio, EfectoVisual,
coleccion de closes podrian estar dentro de esta categoria. Otras se enfocan en los personajes dentro del
relocionodos. 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-
 CAPITULO 8 MODELADO DEl ANAuSIS 235

, Como se sis. Ahora es tiempo de hacer una transici6n al comportamiento dinamico del siste-
model. I. m a 0 producto. Para lograrlo el com portam ien to del sistema debe presentarse como
nalcion del soft- una funci6n de los elementos especiflcos y el tiempo.
ware a alglln EI modelo de comportamiento indica la fonna en que el software responde,,; a los even-
pento externo?
tos 0 estimulos extemos. En la creaci6n del modele el analista debe realizar los siguien-
tes pasos:

1. Evaluar todos los casos de uso para entender por completo la secuencia de
interacci6n dentro del sistema.
2. ldentificar los eventos que conducen la secuencia de interaccion y entender la
forma en que estos eventos se relacionan con las c1ases especificas.
los (osos de uso se
anolizan poro definir 3. Crear una secuencia para cada caso de uso.
"",los. POlO logrorlo,
4 . Construir un diagrama de estado para eI sistema .
kiI (osos de uso se
exominon con el fin de 5_ Revisar el modele de comportamien to para veriflcar su exactitud y consisten -
eflCootrar los puntas de cia.
interccmbic de
informociol1. Cad a uno de estos pasos se expone en las seccion es sigu ientes.

S.S.l Identlficaci6n de eventos con el caso de uso

Como se menciono en la secci6n 8.5, el caso de usa represen ta una secuencia de
actividades que implica a los actores y al sistem a. 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 comportamiento en la secci6n 8.6.3, sera
importante puntualizar que el even to no es la in formaci6n que se ha intercambia -
do, sino el hecho de que la informaci6n haya sido intercambiada .
Los puntos del intercambio de informacion se obtienen examinando 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 alm acenada en el sistema 5i la contraselia
es incorrecta, el pan el de control emjtira un sonido por una sola vez y se reiniciara 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 indican eventos. Se debe iden-
ti fi car a un autor para cada evento; la informaci6n intercambiada se debe anotar, y
cua lquier condici6n 0 restricci6n debe registrarse.
Como ejem plo 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 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 con trol. Por ejem-
plo, el even to introducci6n de contraseiia no cambia de manera explicita el flujo de
control del caso de uso, pero los resu ltados del evento comparaci6n de contraseiia
(derivado de la interacci6n "Ia contrasena se campara con la contrasena valida
almacenada en eI sistema") tendra un impac to 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 obje-
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 sitio (por ejemplo, PaneldeControl recono-

, ce el result ado binario 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 ex terior 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 clase Jugador (en la aplicacion de videojuego
estudiada con anterioridad) incluiria los atributos de posicion y orientaci6n del Jugador,
EI sistema ~ene
estodos que asl como otras caracterlsticas relevantes para el juego (por ejemplo, un atributo que
representon un indique la existencia de deseos magicos). EI eslado activo de un objeto indica el estatus
(omporlomiento actual del objeto cuando este esta sujelo a una transformacion 0 a un procesamien-
espeeilico observtlble to continuos. La clase Jugador pod ria tener los siguien tes estados activos: en movi-
desde el exterior; uno
dose liene eslodos que miento, en descanso, herido, en curacion, atrapado, perdido, etcetera. Debe ocurrir un
represenlon su even to (algunas veces lIamado un disparador) para obligar a un objeto a hacer una
comportomienlo transici6n de un estado activo a otro.
wando el sistema En los parrafos siguien tes se explican dos diferentes representaciones del com-
reolizG sus iunciones.
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 los 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

Temporizador .::; TiempoCerrado

Oicgrama de estado
para la clase
PaneldeControl.
Temporizador > TiempoCerrado - Cerrado

r--
-
Contrasefia = incorrecta
y numeroDelntentos < Intentosmaximos

L
-- Golpe Lectura 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 "historia 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-
AMerencio de un paracion" de la figura 8.20 se puede determinar al examinar el caso de uso:
diograma de eslodo
que represento el si (introducci6n de contrasena =4 dfgitos), entonces comparar con contrasena almacenada
comportomienlo sin
mencionar las closes
involucrodos, un En general, la guardia para una transicion por 10 regular depende del valor de uno 0
diogmma de secuencio mas atributos de un objeto. En otras palabras, la guardia depende del estado pasivo
represento el delobjeto.
comporlomienlo 01 Una acd6n sucede de manera concurrente con la transicion del estado 0 como
describir10 formo en
consecuencia de este, y por 10 general implica una 0 mas operaciones (responsabili -
que las closes se
mueven de estodo a dades) del objeto. Por ejemplo, una accion conectada con el even to contrasefja intro-
"tudo. ducida (figura 8.20) es una operacion llamada ValidarContrasena( ) que da acceso a
238 PARTE DOS pRAcnCA DE LA iNGENIERfA DEL SOFTWARE

de ~ecuencia (parciaIrpara la funcion de seguridad de HogarSeguro.

- I Propietoria I
. .. Sistema
lislo

r
,
CD
Contrasena introducido
I Panel de control I
lecture
~
,

Solicitud de busqueda
,
,
,
....L,
Sensor

,
,
,
,
,
, Comparoci6n I I ,
, , ,
, Resultado
,
, numerDe'ntentos > > ~
Contrasena = correcto .1. Solicitud de activacion
, Intentosm6ximos
,
, Temporizador >
Cerrado
,
, A Tiempocerrodo
,
, , ,
, , ,
, ,
, Selecdon
,
, ,
I
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
del on61isis praporcionon 10 copacidod de
desarrollor modelos bosados en escenarios, modelos
basados en closes y modelos de comportomiento mediante
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
1J 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:
ArgoUML, uno herromiento de Fuente obierto
(orgouml.tigris.org).
Control Center, desorrollado por TogetherSoft
(www.togethersoft.com).
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.

89 RlsyMEN
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 com o 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 exam ina 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 interaccion especifica. EI grado de forma-
lidad y detalle del caso de usc varia, pero el resultado final proporciona 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 ac tores 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 derivan 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 salida
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 derivada 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-respon sabilidad-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 modelos 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 la 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, Addison-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, Addison-Wesley, 1998.
[STR88] Stroustrup, B., "What is Object-Orien ted Programming?", en IEEE software, vol 5, num.
3, mayo de 1988, pp. 10-20.
[TAY90] Taylor, D. A., Object-On·ented Technology: A Manager's Guide, Addison-Wes!ey, 1990.
[THAOO] Thal heim, B., Entity Relationship Modeling, Springer-Ve rlag, 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.~Es 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 sob re la manera en que el usuario interac-
tua can este siste ma.
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 mane ra di fiere un diagrama de estado para c1ases de ana l 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) presen tan guias detalladas para crear modelos de datos relacionados con la ca lidad
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 cO legas (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 SE PA 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.