~ F E DEL S®FTWARE Un enfoque practico • • • • • • • --- - • • • I • I l · • . ' "-- ~\'I., CAPiTULO

MODELADO , DEL ANALISIS

CONCEPTOS n el ambito tecnico. la ingenieria de software comienza con una serie de CLAVE tareas de model ado que conducen a una especificaci6n de requisitos y a ooiI"'del Euna representaci6n completa del disef\o del software que se construira. EI IIooinIo ...... 194 modelo de analisis, que 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 quisitos de software)...... • Los problemas de gran tamafto deben tratarse con un metoda efectivo de par­ _ • ••. 202 tidon. La especificaci6n del tipo de las novelas victorianas ya no sirve. eRe •••• •••• 225 • Deben utilizarse graficas cuando sea posible. de dolo • ••••• 197 • Se debe diferenciar entre consideraciones J6gicas [esenciales) y fisicas [de im­ del CDlftpor· plementaci6n) .. _.10 .... 234 •sptdf"Kodo. Como minima se necesita .. 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 que eo relativamente fac il de entender y, aun mas vehiculo morovilloso parala comunl­ importante, conduce a una revision para Iograr la caci6n, pero no es, necesariament&, c:orrecci6n, la inlegridad y 10 consistencia. la mejor forma de rep~."" _ .Quilln 10 hac.? Un ingeniero de software [algu· requisitos para eI sofiwore1. cIe ~. nos vace. lIamado analistol conslruye el madelo putodora. EI modelado del anali.i. uIIIiza ImO empleanda requi sitas abtenidas del d iente. combinaci6n de formalo$ en 1exta y cliqpQlilOl tpor que .s importante? Pa ra validar los para representor los requisilo$ de 10. cIatoI, _ ..requisitos del software es necesario examinarlos funciones y el compartamiento de uno I1I(IiIjIIQ desde algunos puntos de visto diferenles. EI mode·

191 192 PARTE DOS PAAcnCA DE LA INGEN1ERlA DEL SOF1WARE

lado del aOOlisis represenla las requillitos en niul·_ Una vez que se han creacIo los modelos tiples U dimensiones#, con 10 que $& ~ fa ""'_.. ares, estos se refinon y analizan para probobilidad de encontrar errones,' de ~ sur- su calidad, integridad 'I cansistenda. jan'1'ncansistendas y de que se ~.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

8 r 1 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 utilizar ese modelo como base para diseiiar un incremento de software.2

8.1 .1 Filosofia y objetivos generales EI modelo de analisis debe cumplir tres 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 est ructura 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 co mienzan 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 va rias 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 "i nterconexion" es extremadamente alto se deben hacer esfuerzos para reducirlo. • Se debe tener la seguridad de que el modelo de andlisis proporciona valor a todos los interesados. Cada ci rcunscripcion tiene su propio uso del modelo. Por ejemplo, los interesados relacionados con los negocios deben utilizar el 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 cua nd a 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 ..... ,om/lngIi.h/ analisis a menudo ocurren de nuevo en muchas aplicaciones dentro de un dominic Software de negocio especifico. Si estos patrones se definen y se clasifican por categoria de Inglneerlog/ una manera que permi tan a1 in geniero 0 al analista de software reconoce rl os y reu ­ 51_","5 .•• , tilizarlos, la creacion del modelo de analisis se acelera. Un factor de mayor impor­ pueden enconrrorse mochos recursos atlles tancia es que la probabilidad de aplicar patrones de disefio reutilizables y compo­ pora eI onOlisis del nentes ejecutables 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 Aplicociones existentes / Estondares de reutilizadon Fuentes del \ Modelo Sondeos a los clientes Anal;.;. conocimienlo 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 y 10 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 orientados a objetos en forma predominante.

B[olnolisi l 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 representaciones Ie proporcionara a los interesados el mejor modelo de requisitos de software y el puente mas efectivo para el disefio de software. EI modelado del analisis conduce a la 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.

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

construir modelos de tal forma que resoltemos 0 enfaticemos dertos coracteristicas criticos de un 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 camDOrtamiento Diogromos de dose Diogromos de estodo Poquetes de o nal isis Diogromos de secuencio Modelos CRC Diogromos de coloborod6n

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 relaciones 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 datosS Par 10 tanto, el objeto de datos puede representarse como una tabla, tal como se muestra en la figura 8.4. Los Un objeto de datos es encabezados de la tabla reflejan los atributos del objeto. En este caso, un auto se uno represen toci6n de cuo lquier informacion define en te rminos de marca, modelo, numero de seri e, tipo de carrocerfa, color Y pt'Opieta­ 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

Une los obietos de dotos entre 5i, Representaclon Nombres en este coso, propielorio tabular de de otributos objetos de /r___ ~ A'-___~, ~ datos. Atributos Atributos idenlificodor descriptivos referencioles ~~ ~ - Morea Modelo # de id. Tipo Color Propietario lexus l5400 AB123. Sedan Blanco R5P Ins! oneie Chevy Corveffe X456. DeportivQ Roje CCD BMW 750il XZ765. Coupe Blanco Ul Ford Taurus Q12A45. .. Sedan Azul BlF

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 Los otribulos definen a objeto de datos, 2) describir la ocurrencia 0 3) hacer referencia a otra ocurrencia en un objeto de dotos, otra tabla. Ademas, se debe deflnir uno 0 mas atributos como un identiflcador; es describen ~s decir, el atributo identificador se convierte en una "clave" cuando se desea encontrar corocteristicos y, en algunos rosos, hocen una ocurrencia del objeto de datos. En algunos casos, los valores para el (los) iden­ referencio (] olro tiflcador(es) son (micas, aunque esto no es un requisito. En referencia al objeto de objeto. datos auto, un identiflcador razonable podria ser el numero de serie. EI canjunto de atributos apropiado para un objeto de datos se determina median­ ; ." ; te la comprensi6n del contexto del problema. Los atributos para auto sirven bien EI (oocepfo Ilomrn:lo "normoliloci6n· es para una aplicaci6n que utilice el Departamento de vehiculos de motor, pero estos importonte pam todos atributos se rian 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 atributos (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 tambien incorpora las operociones que manipulan los ~datos es comun que suria una pregunto: aun datos implicodos por dichos atributos. Ademes, 10 objeto de dotos es 10 mismo que una dose orientado a definicion de doses implico una infraestructura completa objetos? La respuesta es: "noN. que es parte del enfoque de la ingenierio de software Un objeto de dotos define un elemento compuesto de orientado a objetos. Las doses se comunican entre 51 a los datos' esto es incorpora una coleccion de elementos de troves de mensajes; pueden organizarse en jerorquios; datos individuale's (atributos) y do un nombre a 10 proporcionan caracteristicas heredadas para objetos que coleccion de elementos (el nombre del objeto de datos). son uno instancio para una dose. Uno dose 00 encapsula atributos de los datos, pero CAPiTULO 8 MODELADO DEL ANAuSIS 199

Relac10nes p."ono I IoUlomov;1 1 entre objetos 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 respuesta se determina entendiendo el papel de las personas (propietarios, en este ~ monelO en que los 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 relaciones posee y esla asegurada para conducir definen las co nexiones 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 relaci6n 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 obj e­ situation en 10 to (una relacion I : I ); un objeto puede relacionarse con muchos obj etos (una relacion que un objeto de I:N); un numero de ocurrencias de un obj eto puede relacionarse con algun otro datos esta rela~ donado (on 10 numero de ocurrencias de otro obj eto (una relacion M:N)6 La ca rdinalidad 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 obj eto 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 represenlan par medio de un rectangulo etiquelado. Los ~ del modele de datos. Estes porejas pueden relociones se representan mediante una linea etiquelada representorse de monero grcifica mediante el diagromo de que conedo objetos. En algunos variaciones del DER 10 enlidad-reloci6n (OERJ .7 EIDER 10 propu$O originalmente linea de conexion conliene un rombo que esta etiquelado Peter Chen [CHEll] para el diseno de sistema!. de bases con 10 relacion. Las conexiones entre objetos de datos y relacionale!., y despues otrmlo han ompliado. Con eiDER relaciones se establecen mediante una voriedod de se identifieo un caniunlo de componentes primarios: simbolos especioles que indican su cardinalidad y objetos de datos, atributos, relaciones e indicodores de modolidod. vorios tipos. EI propOsito primordial del DER es representor Para mas informacion sabre el modelodo de datos y el objetos de dotos y sus relaciones. diogromo de entidad-relacion ellector inleresado puede Ya se ha hecho una introduccion de 10 notacion consultor [THAOOj rudimentaria para eIDER. Los objetos de datos se

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 caraclerislicas y relaciones. Estas herramientas -que se ~ de datos proparcionon 01 ingeniero de sohware utilizan sabre lodo para grondes aplicaciones de bases de 10 copocidod de representor objetos de datos, sus 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 ANAuSIS 201 proporcionon un medio automatizodo para crear Oroefe/Designer, desarroll ado per Oracle Systems diagramas de entidad-relacion, diccionarios de objetos de (www.oracle.com). modelo procesos de negocios, datos y modelos relacionados. entidades de datos y relaciones que se transforman en Mecanica: las herramientas en esta categorla permiten disenos a partir de los cuales se generan aplicaciones 01 usuario describir objetos de datos y sus relaciones. En completas y bases de datos. algunos casos uti lizan 10 notacion del DER; en otras MetaScope, desa rrollado per Madrone Systems ocasiones modelan las relaciones por medio de otros (www.madronesystems.coml. es uno herramienta para mecanismos. Adem6s permiten 10 creacion de un modelo el modelado de datos de ba jo costo que do soperte a de base de datos 01 generar un e5quema de bose de datos 10 representacion gr6 fi ca de datos. pora 5MBD. Mode/Sphere, desarrollado per Magno Solutions GMBH 8 Herramientas representativas (www.mognosolutions.coml, do soporte a uno variedad AI/Fusion ERWin, desarrollado por Computes Associates de herromientas de modelado relocional. (WWVv'3.ca.com), oyuda en el disena de ob jetos de datos, Visib/eAno/yst, desorrollodo por Visible Systems estructuras propias y elementos clove para bases de datos. (www.visible.coml, do soporte a una va riedad de ER/Sfudio, desorrollado per Embarcadero Software fvnciones de modelado del analisis, incluido el (www.embarco dero.coml.brin do soporte 01 modelado modelado de datos. entidad-relaci6n.

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 comportamiento del objeto. 6. Las ta reas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo este completo.

8 Las herramientas mencionadas aqui son una muestra de esta categoria. En la mayoria de 105 casos los nombres estan regi strados par sus respectivos desarrolladores. 202 PARTE DOS pRAcnCA DE LA INGENIERlA DEL SOFIWARE

En lugar de examinar un problema mediante un modelo mas convencional del tipo entrada-procesamiento-salida (flujo de informacion) 0 un modelo derivado en forma exclusiva de las estructuras jerarquicas de informaci6n, el AOO construye un modelo orientado a las clases que se basa en la comprension de los conceptos 00.

Conceptos orientados a objetos , Los conceptos orientodos a objetos (00) est6n 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),

'[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 Jamie: ,Qui.. hoc.. eI flO!"" del odor en _, II1II""''' 'aultln'lela segundo junto para 10 recopilacion Moderador: Creo qu<>MenedHh luna penonCI de mercodotecnial he ..tado ft'abaiando en .... ~.CI!I,",S: Jamie Lazor, miembro del equipo de funcionalidod. ,Par que no hoces I!i eI pafMIIf Robbim, miembro del equipo de software; Meredith: ,Quieres que 10 hogamo. iguaI qu<> Ia 6IIima 'II~:~,'.::~:i~ngenierio del software; tres vez, no es asf? n de metcadotechio; un representonte de de producto; y un moderodor. Moderador: (orredo ... de 10 misma forma. Meredith: Bueno, es abvia que 10 raz6n pare Ia """,II6or: Es hora de que comencemos a hablar vigilancia es permitir que el propietario est6 peldente de de.1a n.nci6n de vigilancia de HagarSeguro. 10 coso mientras el 0 ella est6n £vera, grabar y reprodudr videos que se hoyon capturodo .. _ese tipo de CI desonollor un escenorio de usuorio para el cosas. "Ia funci6n de seguridad en .1 hagar.

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 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 De ocuerdo, entonces b6sicamente hay dos uno contrasena especifico. Y quiero fa opci6n de wr funci6n de vigilancia ... 10 primero pequenos ventanos que muestren vistas de todas los ~Vura.llislerna, induyendo el establecimiento de un comoros y despues ser capoz de selecxionc. Ia que -necesitomos herramientos que cyuden quiera destacar. rt;~:~:~ 0 hacerlo- y Ia segundo parte es 10 funci6n ':~i real en sf misma. Como eI establecimiento Jamie: Eso$ se lIaman vistas en miniatura. ~r.;;;~.• '~S parte de Ia octividod de conflguroci6n, me Meredith: Bien, entonces quiero vistas en minioturtl de . ~ Ia funci6n de vigilancio. 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 sea intuitiva; es decir, que no sea leer un .,. r I ....: Mm ... Quiero tener occeso a 10 funci6n de n&Ce$Orto manual para poder usorta. ~, yo sea a troves de 10 PC 0 de Internet. Siento 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 ve r. • 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 ca mara. • Repetir la salida de camara.

Con forme se realizan 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 estilo narrativo informal. Si se requiere mayor formalidad se rescribe el mismo caso de usa utilizando un formato estructu ­ rado similar al propuesto en el capitulo 7 y reproducido en esta seccian co mo 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 de vigilancia-despliegue de vistas de camara (ACV-DVC) Actor: propietario Si me encuentro en un lugar lejano puedo usar una PC con un soflware de navegad6n apropiado para en trar al sitio web de los productos HogarSeguro , Ingreso mi clave de usua­ rio y dos niveies de contrasenas y, despues de que estoy validado, tengo acceso a toda la funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una ca­ mara especifica selecciono "vigilancia" de los botones desplegados para las funciones mas importantes. Oespues escojo "seleccionar una camara" y se despliega un plano de planla de la casa. Entonces selecciono la camara en la que estoy interesado. En forma alterna, puedo ver simultaneamente una lista con vistas en miniatura de todas las camaras al se­ leccionar "todas las camaras" como mi opd6n de visualizaci6n. Una vez que he seleccio­ nado una camara, selecciono "vista" y una vista de un cuadro por segundo aparece en una ventana, a la cual identifica la camara clave. 5i quiero cambiar de camara, elijo "seleccio­ nar una camara" y la 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 inte racci6n 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 de vistas de camara (ACV-DVC) Actor: propietario 1. El propietario 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

Por supuesto, para una comptensi6n completa de la funci6n que se pretende des­ cribir es esendal una descripcion de las interacciones alternativas. Por 10 tanto, cada paso en el escenario primario se eva ilia realizando las siguientes preguntas [5CH98j:

,COmo se • LE I 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 el ige "se leccionar una camara". 7. EI sistema despliega el plano de planta de la casa.

tiEl actor puede ejecutQr aUa acdon en este punta? La respuesta es: "s i". 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 ca mara" 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 sec undario 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 formales 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 11 . EI sistema despliego 10 salida de video dentro de Ia de vigilancio-despliegue de vistas ventano de visuolizoci6n a un cuadro pot segundo. de comora (ACY·DVq. Excepciones: Actor primario: Propietorio 1. La 100 los contrasenos son incorrectos 0 no se Meta en conlexlo: Ver 10 solido de los comoros reconocen; vease el coso de uso: "volidar 10 y colocadas a 10 largo de 10 coso contrasei'ias" . desde cualquier ubicaci6n remota a traves de Internet. 2. lo fvnci6n de vigiloncia no esro configuroda para este sistema, aSI que el sistema despliega at mensaje Condiciones previas: EI sistema se debe configuror por de error opropiodo; veose el coso de usa: completo; se deben obtener 10 y "configurar 10 fvn ci6n de vigilancia". controsenas apropiadas para los usuarios. 3. EI propietario selecciono "Ver vistas en miniatura para todas las comoros"; vease el coso de uso: "Ver Disparodor: EI propietario decide echarle un vistas en miniatura para todas las comaras". vitam a su caso mientros se encuentra fuera de ella. 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 1. EI propielorio entra 01 sitio web de Productos "configurar plano de 10 coso". HogorSeguro. 5. Se encuentra una condici6n de olorma; vease eI n 2. a propietario introduce su 10 de usoorio. coso de uso: n condici6n de aIormo encontrado . 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: 3. ilo respuesta del sistema via Internet ser6 ac:epkIhIe 1. aCu61 es eI meconismo que protege contro el usc no dado el ancho de banda requerido para las vistas autorizado de esfa capacidad pa' parte de los de cornaro? empIeados de Ia campania? 4. iSe desorrollor6 uno capacidod para proporcionor pot' 2. ela seguridod $$ sofidente? EI ingreso no outorizodo video a una tosa mayor de cuodros segundo en esta carocteristico representario una invasi6n cuando esten disponibles conexiones con ~ impartanle de Ia privocidod . 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 intentos de entrada "miniatura... -A'-,"·,"· 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 en uno ventana eliquetodo..J "- para olro vista ) Solirde A .-=eslo funci6n ~ Ver olro cornaro

como segmentos paralelos que dividen el diagrama en forma vertical, como los carriles de una alberca. 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 dedsiones e indica al carril correspondiente a dicha clase. Por ejemplo, la clase Interfaz representa la 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 requisitos y el flujo del sistema. EI DFD tiene una vision del sistema del tipo entrada-proceso-salida. Esto es, los objetos de datos lluyen hacia el interior del software, se transforman mediante ele­ mentos de procesamiento, y los objetos de datos resultantes 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" y que 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 de contexto del panel de control del usuorio de informacion de control para la funcion de Tipo segurtdad de de alarmo HogarSeguro. B Estatus Linea $ensores numero telef6nico del sensor 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 .

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 Durante 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 wando existe alguna ~ para habjijtar 0 deshabi}jtar el sistema, y algunos numeros telef6nico$ ingresan para difiwl/ud para delinir marcarse cuando se presenta un even to en los sensores. abjetas de datas y las 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 telefonico se remarca cad a 20 segundos hasta que se abilene una conexion telef6nica, El propietario recibe informaci6n de seguridad a traves de un panel de control, la PC a un buscador que en forma colectiva se denomina una i.nt..e.rfaz.. La interfaz despliega men­ sajes de opcj6n e informacion del eslalus del sistema en eJ panel de control, la PC 0 la veo­ tana del buscador. La interacci6n del propietario asume la siguiente forma ..

En relacion can el analisis gramatical comienza a surgir un patron. Los verbos son los procesos de HogarSeguro; esto es. al final pueden representarse como burbujas en un DFD subsecuente. Los sustantivos son entidades externas (cajas), objetos de datos a de control (flechas), a almacenamientos de datos (lineas dob!es). Oespues debe observarse que los sustantivos y verbos se puedan asociar de distintas formas

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

Procesar Despliegue contrasena Mensal·e .....,===-1 del panel de ID va ido de control Configuraci6n de oatos =-__I~nf~o:r~m~O~C~i6~n~~::=: 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 del sensor Tonos de numeros telef6nicos

entre 51. Por ejemplo, a cada se nsor 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 se is 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 informaci6n 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 "in terruptores" 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 identificac i6n 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, "

8,6.3 Especificacion de control La especijicaci6n de control (EC) representa el comportamiento del sistema (en el nivel desde el cual esta referido) de dos maneras diferentes. 17 La EC contiene un dia­ grama de estado que es una especificacion secuencial del comportamiento. Tambien puede contener una tabla de activacion del programa, una especificacion combina­ toria del comportamiento. En la figura 8.12 se muestra un diagrama de estado preliminarl8 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 comportamiento especi ficado.

17 Despues, en este mismo capitulo, se presenta notaci6n adicional para el modelado del comporta- miento. 18 La notaci6n para el diagrama de estado se rrlUestra aqui de confonnidad con la notaci6n del UML. En el analisis estructurado se cuenta con un "diagrama de transici6n de estado", pero el formate del UML es superior en contenido y representaci6n de informaci6n. 216 PARTE DOS PAAcrTCA DE LA JNGENIERIA DEL SOITWARE

Diagrama de estado para la funcion de seguridad de HogarSeguro.

Reinido Sistema DesO(upodo correcto ~ Inlerruptor Entror/inicior E~loIussi$lemo ~inodivo' Enlrorjinicior Estoll.lssistemo "inocliVQ' in icie/para, Entrorjinicior despliegueMensoje 1 Reinicio Enlror/inicior despliegueMensojel "listo~ -encendido Nlniciondo sistemo" Entrar/ini<:ior despliegueMensaje2 ... Entrar/iniciar despliegueMensoje2 Entrar/iniciar despliegueEstatvs estable "POI" favor espere" GolpedetedolTedodemonejo Enlror/iniciar despliegueEstolus deslello lenlo Hoeer: correr diognoslicos apagado/control 1 • I Activor I Apogodo Fol loDetectodo/ inic iar despliegueMensaje2 "conlodar desoctivorControsena @ 01 Ye ndedor" I desactivorControseiio MonitoreoEstatusSistema AccionEnAlarma fa lsaAlarma Enlrm/inieiar EsloltJs$i~tema Entror/inicier EsloltJ!.!;istema ~monitoreo" Entrm/iniciar despliegueMensojel NArmado" tiempoFuero "moniloreoYAlarmo' Enlrar/inieiar despliegueMensojel Enlrer/inieior despliegueMensaje2 N. Enlrar/inieior despliegueEsfotus esloble ~ALARMK Haeer: monitorearYConlrolarSblema EOlrar/ioieiar despliegueMeosaje2 Golpedetedo/Tedademonejo sensorDisporodo/ 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 reinicia, 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 despliega 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) cuando se dispara un sen­ sor ocurre una transicion hacia el estado Acci6nEnAlarma. Durante 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 ~gu ros 8.9, 8.10, 8.11 Y 8.12 Y",los 1I\IJEISIro'l:I l!i1 i.~ 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

oslO un poco posado de modo, pero ,soben Ed: ,De verdad? "iI ~"" 'CIJIIda a dorificar las rosas. 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 No, esto es s6Io un modelo de Aujo con algunos que obordor elementos basodos en clases y tambien c..... II1Ic .. die comportomiento induidas. aspectos del comportamiento, ounque este diogromo de estodo hace olgo de eso. Ed: Tenemos mucho trobajo por hacer y no mucho tiempa para hacerlo. 11.'1. '"--- En!roda·proceso-solida. En ceot;dad los DFD son (Doug --el gerente de ingenierio del software- entra en el r ... ¥ .,lvitiv<>s ... Si los observos par un momento, cubfculo.) k:::'~ 10 forma en que los objetos Auyen a troves del Doug: Entonces, alas primeros dios estoron dedicados 01 c6mo $8 I estos transformon. desarrollo del modelo de on6lisls, eM Parece como si pudieromos convertir codo burbuja Jamie (con orgullo): Yo comenzomos. Ii" '""$O'"p'",ente ejecutobJe. .. . 01 menos en el nivel mas Doug: Bien, tenemos mucho trabajo par hacer y no 1iIii,&,..1o mejor porte, 51 '" puede. De hecho, mucho tiempo para hacerlo. forma de traducir los OFO a uno arquitectura (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­ tronsfo rmocion en el tara el proceso. nivel menos refi no do 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. 218 PARTE DOS PAAcnCA DE LA INGENIERiA DEL SOrtWARE

gu~ idad de HogarSegurb. El procesamiento de contraseila recibe una contrasena de cuatro digitos a partir de la funci6n de interacci6n con e/ usuario. La contrasei'ia se campara pri­ mera con la contrasefia maestra almacenada en el sistema. 5i la contrasefia maestra coin­ cide [Mensaje de ID 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 estructurado Objetivo: los herromientos del onolisis Herramientos representativas20 ~ estructurodo oyudon a un ingeniero de softwore o crear modelos de datos, modelos de Huio y modelos de AxiomSys, desarrollado por STG, Inc. (www.slgcase.comj, comportomiento de uno monero que permito 10 proporciona un paquete completo de herramientas verificocion de 10 conlinuidod y 10 consistencio, osl como pora el onolisis de 10 estructura que incluye extensiones su focil edicion y extension. Los modelos creados utilizondo de Hartley-Pirbhai para el modelado de sistemas en estos herramientos brindon 01 ingeniero de software una tiempo real. vision de 10 representoci6n del onolisis y oyudon 0 MacA&D, WinA&D, desarrollados par Excel Software eliminar errores ontes de que estos se propaguen en el (www.excelsoftware.coml, proporcionan un conjunto diseno 0 , oun pear, en 10 m'ismo implementocion. de herromientas simples y berotas para el anolisis y el Meccm ica : Los herramientas de esto categoria utilizon un disei'io en moquinas Mac y Windows. Ndiccionario de datosNcomo 10 bose de dotos centrol paro MetaCASE Workbench, desarrollado par Metocose 10 descripcion de todos los objetos de datos. Uno vez que Consulting (www.metacase.com) es uno los entrodos del diccionorio eston definidos, pueden metoherramiento uti lizada para definir un metodo de crearse diagramas de entidad-relacion y se pueden anolisis 0 diseno (incluide en onolisis estructurodo): sus desorrollor los jerorquias de obietos. Las corocteristicas de conceptos, reglos, notaciones y generadores. diagramacion del Huio de datos permiten crear focilmente este modelo grofico y tambien proporciona caracteristicos Sysfem Architect, desarrollado por Popkin Software para 10 creaci6n de especificaciones de control lEe) y (www.popkin.com). proporciena un amplie range de especificaciones de proceso (EPj. Las herromientas de herramientos de onolisis y disei'io, incluye herromientas onolisis tombien ayudon 01 ingeniero de software en 10 para el modelado de dolos y el onolisis estructurodo. creacion de modelos de compartamiento que usan los diagramas de estado como notacion operativa.

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 presentan una serie de directrices informales que ayudaran a identificarlos y representarlos.

8.7.1 Identificacion de clases de anruisis AI observar el interior de una habitaci6n se vera que existe un conjunto de objetos fisicos que pueden identifiearse. clasificarse y definirse con fac ilidad (e n 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 describir una soluci6n es parte del espacio del problema. "Que se debe buscar despues de que todos los sus­ tantivos han side aislados? Las clases se manifiestan en una de las siguientes formas:

,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 gramatica l" 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 extern a instolaci6n ocurrencia sistema lali as sis tema de seguridadJ coso numero, tipo no objetos, otributos del sensor contro sena maestro coso numero telef6nico coso evento del sensor ocurrenClo olarmo audible entidad extern o

servi cio de monitoreo unidod 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 si de

21 Olra categarizaci6n impartante -la cual define entidad. frontera y clases de controladar- se exa­ mina en la secci6n 8.7.4 . 22 Es importante notar que esta tecnica debe usarse tambien para todos los casas de uso desarro!la­ dos como parte de la actividad para la recopHaci6n de requisitos (obtenci6n). Esto es, los casos de uso pueden analizarse gramaticalmente para extraer clases de analisis potenciales. CAPiTuLo 8 MODELAOO DEL ANAuSIS 221

llamada como un objeto potencial. Cada uno de ellos debe considerarse a fonda antes de tomar una decision final.

"las clases luchan, algunos doses triunfan, otras son eliminodos." Mao Z.dong

Coad y You rdon [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 deflnir 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 definir un conjunto de operaciones para la clase potencial, y estas operaciones pueden aplicarse en todas las instancias de la clase. 6. Requisitos esenciales. Las entidades externas que aparecen en el espacio del problema, y que producen 0 consumen informacion esencial para la opera­ cion de cualquier solucion para el sistema, se definiran casi siempre como clases en el modele de requisitos.

Considerarla una clase legitima para incluirla en el modele de requisitos requiere que una clase potencial satisfaga todas (0 casi todas) estas caracteristicas. La deci­ sion de incluir clases potenciales en el 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 pO lenciales 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 fun ci6n de seguridodl aceptodo: lodos oplicon numera , tipo recha zada: falla 3, alributos del sensor conlrasena 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 fall an aunque oplico 6

Se debe senalar que I) la !ista anterior no esta com pi eta (se tendrian que agregar cla­ ses adicionales para terminar el modelo); 2) algunas de las clases potenciales recha­ zadas se convertiran en atributos para las clases aceptadas (por ejemplo, n"mero y iipo son atributos de sensor, y contrasena maestra y numero telef6nico se pueden conver­ tir en atributos de sistema); 3) la existencia de enunciados diferentes del problema pod ria ocasionar decisiones distintas de "aceptaci6n 0 rechalO" (por ejemplo, si cada propietario tuviera una contrasena diferente 0 si pudiera 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 cla se. 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 refinarse 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 se nsores son parte del sistema global de HogarSeguro , y aun asi no estan en ­ Iistados como elementos de datos 0 como atributos en la flgura 8.13. Ya se ha defl­ nido sensor como una ( lase, y varios objetos de sensor se asociarim con la clase sistema. En general, se evita la 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 operaciones 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 tudiar otra vez la narrativa de un procesa­ opefOciones para una dose de an6lisis, el mien to (0 caso de uso) y seleccionar aquellas operaciones que pertenezcan de 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 facilidad a una c1ase especiflca. Par ejemplo, en la narrativa del pro­ yno en los comportcr cesamiento presentada parrafos atras en este capitulo, se observa que "al sensor se mientos requeridos numero y 0 pora 10 implemenf~ Ie asigna un un tipo" 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 de estos paredes. ,C6mo sobe eI plono de pIan!o d&.d. comenzar el mocIelodo del anal isis. colocar esos objetos? Los adores: Jamie, Vinod y Ed, miembros del equipo Ed; No 10 sabe, pero las otros doses sf. Miren 10$ de ingenierfo del soft..vare de HogarSeguro. atributos de abajo, digomos, SegmentosdePared, los La conversacion: cuales se usan para construir uno pared. EI segmento de pared tiene unas coordenadas de inido y flnalAy Ie {Ed ho estodo trobojondo en 10 extracci6n de closes a operocion de dibuio( ) hace el resto. ~, partir de 10 plontillo de coso de uso para el U Acceso a la camara de vigilancia-despliegue de vistas Jamie: Y 10 mismo pasa para los poertas y venkJna$. de camara" Ipresentado en un recuadro anterior en Porece como si las comoros tuvieron unes pocOl de este capitulo 1 y esla mostrando a sus colegas las closes otributos extra. que ha extraido. Ed: 5i, los necesito para poder dar 10 informaciOn del Ed: Entonces, cuando el propietario quiere escoger una movimiento y el acercamiento. camara, el 0 ella debe elegirla de un plano de plonta. He Vinod: Tengo uno pregunla. iPor que 10 camara tiene definido una clase lIamada PlanodePlanta. Aquf esla uno ID, pero las otras clases no? el diagrama. Ed: Vamos 0 necesitar identificar coda camoro para (Todos miran 10 figura 8.1 A.J propOsitos del despliegue. Jamie: Entonces PlanodePlanta es uno close que se Jamie: Tiene sentido para mi, pero tengo algunos otras une a los paredes que estan compuestos por segmentos preguntos. (Jamie hace preguntas que resultan en de pared, puertas y ventonos, y tombien los comoros; modificaciones menores.) eso es 10 que significon esos Ifneas etiquetadas, ino? Vinod: iTienes tarjetas CRC para coda una de estas Ed: 5i, esas lineas se lIaman "asociaciones". las doses closes? 5i es asf, debemos seguirlos, s610 hay que estar estcin asociadas entre sf de ocuerdo con las asociaciones seguros de que no se ha omitido nada. que les he mostrado. [las asociaciones se estudian en 10 seccion 8.7.5.1 Ed: No estoy seguro de como hacerlas. l Vinod: Entonces el plono de planta real esta hecho de Vinod: No es diffeil, y los resultados son muy buenos. I paredes y contiene comoros y sensores colocodos dentro 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 ti reo 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 de Pared Ventana 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 despliegue 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 creacion 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

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 cuales, 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 responsabilidades 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 almace nar 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 siguientes c1ases: Jugador, CuerpoJugador, BrazosJugador, PiemasJuga­ dor, cabezaJugador. Cada una de estas c1ases tiene sus propios atributos (par ejemp!o, posici6n, orientaci6n, color, velocidad) y todos deben actualizarse 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( ). Colabo ra 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 utilizar 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 solicitudes que un cliente haee a un se rvidor con el fin de cumplir una responsabilidad. Una colaboraci6n es la materializaci6n del contrato en­ tre el cliente y el servidor. .. Se dice que un objeto cola bora con otro objeto si, para curn­ plir con una responsabilidad, necesita enviar algunos mensajes al otro 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 co labora 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 en de, 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 es lablecer 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 relaciones genericas diferentes enlre las clases [WIR90], I) la relacion es­ parte-de, 2) la relacion tiene-conocimiento-de, y 3) la relacion depende de. Cada una de las tres relaciones genericas se consid era 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 relacione,; se representan como la agregacion mostrada en la figura 8.16. . Cuando una clase debe obtener informacion de otra clase se establece la rela cion tiene-conocimiento-de. La responsabilidad determinar-estatus-sensor( ) mencionada antes 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­ cimiento directo del otro. Un atributo del objeto cabezaJugador lIamado posicion central esla determinado desde la posicion ce ntral de CuerpoJugador. Esta infor­ macion se obtiene a traves de un lercer objelo, Jugador, quien la adquiere de CuerpoJugador. Por ende, CabezaJugador depende-de CuerpoJugador. En lodos los casos, el nombre de la clase del colaborador se registra en la tarjeta indice del modelo eRC enseguida de la responsabilidad que ha producido la col abo­ racion. Por 10 tanto, la tarjeta in dice oontiene una Iista de responsabilidades y las co laboraciones correspondientes que permiten que las responsabilidades puedan cumplirse (figura 8.15). 230 PARTE DOS pRAcnCA DE LA INGENIERiA DEL SOFIWARE

Unaclase Jugador agregada compuesta.

T I I 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 revision lee el caso de uso en forma deliberada. Cuando ellider lIega a una cla se nombrada pasa una seiial a la persona que tiene la tarjeta indice de clase correspondiente. Par ejemplo, un caso de usa para HogarSe­ guro contiene la siguiente narrativa:

EI propietario obse rva 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 tarjeta 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 c1 ase sensor. 4. Cuando se pasa la seiial, la persona que posee la tarjeta de clase debe descri ­ bir las respon sabilidades anotadas en ella. EI grupo determina si una (0 mas) de las responsabilidades sa tisface el requisito del caso de uso. CAPITULO 8 MODELADO DEL ANALISIS 231

5. Si las resp onsabilidades y las colaboraciones 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 correspond en a las tarjetas de in dice de eRC) 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 continua con el modelado del analisis.

HOGARSEGURO

~ Modelos CRC

~ EI escenario: Cubiculo de Ed, Con uno solo selecdon, quiero ser capaz de configurar continuo eI modelodo del on6lisis. 10 coso complete para varias situaciones. Una es en a.o. actores: Vinod y Ed, miembros del equipo de coso; 10 otra, fuera de coso; uno tercero, salido po¥' Ia ingenierio del sohwore de HogarSeguro. noche, y uno cuorto, vioje largo. Todos estes situociones tendr6n configuraciones que se aplicorem a todos los Lac_ciOn. dispositivos. En los estados salida per 1a noche y via;e (\Iinod he decidido ensenorle 0 Ed romo desarrollar largo el sistema debe encender y apagar luces a tarjelas CRC medionte un eiemplo.1 intervolos a leotorios (para oparentar que alguien est6 en Vinod: Mientros tU has estodo trabajondo en 10 coso) y controlar el sistema de calefcccion yaire vigiloncia y Jamie ho estado involucrado con 10 acondicionado. Debe ser copaz de involidor estos seguridad, yo he estodo trabajando en la Nnden de configuradones a troves de Intemet con Ie protecd6n de ..dminislraci6n del hagor. una contraseno opropiada . lei: aCu61 es el estatus de esc? Mercodotecnia c~mbia su Ed: ,Lo gente de hordware nene cancebidos todotlo. punta de vista a coda momento. interfases inalombricas? V"mod: Aqui estO eI primer corte del coso de uso para Vinod (sonriendo). Est6n trobojondo en ellos, Iodo 10 funci6n ... to hemos refinodo un poco, pero digomos que no es un gran problema. De cuolquier puede dorte uno ideo generol. monera, extroie uno serie de doses poro 10 odministrod6n del hogar, y podemos utilizer alguno de ea.o de uso: Funci6n de odministrodon del hogor de elias como ejemplo. Usemos 10 dose HogorSeguro. InterfaxAdministraciemHogar. Narrativa: Queremos utilizor 10 interfaz de Ed: De ocuerdo .. . entonces, los responsobilidades odministroci6n del hogor en una PC 0 con una conexi6n son ... los atributos y operaciones pora Ie dose, y las de Internet para controlor dispositivos electronicos que coloborociones son las doses hado los que opunton las interfaz inal6mbricos. EI sistema tengan con~ de responsabilidades. debe permirume encender y opagor luces especificas, (reo que no entendiste 10 eRe. eontrOlOr OpIicociones conectodos a uno interfaz Vinod: inal6mbrico, conflguror los sistemas de colefocdon y eire Ed: Tal vez un poco, pero continua. ocondicionoclo con las temperaturas que yo defina; para Vinod: Entonces, oqui esta mi definicion de close para hocerIo quiero seleccionar los dispositivos de un plano de InteriazAdministracionHogar. pIonta de 10 coso. Coda dispositivo debe estor Atributos: identificado sabre.1 plono de 10 plonta. Como uno Ponelopciones: proporciona informoci6n en botones que eoroderlstico optional, quiero contralar todos los permiten al usuario seleccionor uno Funcionolidod. disposItivos oudiovisuoles: audio, television, DVD, grobodoras digitales, etcetera. Ponelsituaci6n: proporci6no informaciOn en botones que pe~m jte n 01 usuario selecdonor 10 situociOn. 232 PARTE DOS pRAcnCA DE LA INGENIERIA DEL SOFIWARE

PIonodepionta: el mismo que el obieto de vigiloncio, pero seleccionorSituoci6n PanelSituocibn (close) este despliego los dispositivos. entrarPlanodePlanta PlanodePlanta (close) 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. • Ed: Entonces cuondo se invoca la operacion Operaciones: entrarpfanodeP!anfa(), Elsto colaboro can el obieto DespfegarConlrof(J, sefeccionorControf(J, PlanodePianta como el que desorrollamos para 10 desplegarSituaci6n(}, seleccionarSituadon{}, vigilancia. Espero, oqui tengo su descripcion. {Yen 10 entrarPlanodepfanta(L seJeccionariconoDispositivo(), figura 8.14) clesplegorPanelDispositivo(}, entrar PoneIDispositivo(),. .. Vinod: Exoctame~te. Y si quisieramos revisor todo eI Close: InterfazAdministraci6nHogar modelo de close, podri"omos comenzar con esta carta ReJponsabilidad Colabarador indice, despues ir a 10 carta indice del colaboradort y de desplegorConti'ol Paneloperaciones (close) ahi, a uno de los colaboradores de los colaborodores, Y OS! sucesivomente. seleccionorControl Paneloperaciones (dose) Ed: Bueno forma de encontror omisiones 0 errores. despiegorSituoci6n PanelSituacion {close} 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 Se utiliza para Se utiliza para construir - • - construir Se utiliza para I . I . ·1 o. construir O. 5egmentoPared Ventana Puerta

Dependencias. Ventana Despliegue Camara «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 ejemplo, las escenas visuales que el usuario ve mientras se desarrolla el juego. Un poquete se u~liz(] 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. ma 0 producto. Para lograrlo el comportamiento del sistema debe presentarse como nalcion del soft­ una funci6n de los elementos especiflcos y el tiempo. war e 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 comportamiento para veriflcar su exactitud y consisten­ eflCootrar los puntas de cia. interccmbic de informociol1. Cad a uno de estos pasos se expone en las secciones siguientes. S.S.l Identlficaci6n de eventos con el caso de uso Como se menciono en la secci6n 8.5, el caso de usa representa una secuencia de actividades que 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 informaci6n 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 almacenada en el sistema 5i la contraselia es incorrecta, el panel 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­ tifi car a un autor para cada evento; la informaci6n intercambiada se debe anotar, y cualquier condici6n 0 restricci6n debe registrarse. Como ejemplo de un even to tipico, consi derese la Frase subrayada del caso de uso "el propietario utiliza el teclado para introducir una contrasei'ia de cuatro digitos". En el contexte del modele de analisis, el objeto, propietario," transmite 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 control. Por ejem­ plo, el even to introducci6n de contraseiia no cambia de manera explicita el flujo de control del caso de uso, pero los resultados del evento comparaci6n de contraseiia (derivado de la interacci6n "Ia contrasena se campara con la contrasena va lida 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 siguientes 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 siguientes 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 comportamiento 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 - Contrasefia = incorrecta r-- y numeroDelntentos < Intentosmaximos

Golpe Lectura L Comparacion numeroDelntentos > de tecla Intentosmaximos Contrasena - r-- introducida Hacer: validar - Contrasena Contrasena = correcta

Seleccion

I--

Aclivaci6n exi tosa

estos estados activos. En la flgura 8.20 se ilustra un diagrama de estado para la clase PaneldeControl en la funcion de seguridad de HogarSeguro. Cada flecha en la figura 8.20 representa una transicion desde un estado activo de una clase hasta otro. Las etiquetas mostradas para cad a flecha representan el even­ to que dispara la transicion. Aunque el modelo de estado activo proporciona un dis­ cernimiento activo de la "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 rep resento el delobjeto. comporlomienlo 01 Una acd6n sucede de manera concurrente con la transicion del estado 0 como describir 10 formo en que las closes se consecuencia de este, y por 10 general implica una 0 mas operaciones (responsabili ­ 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.

Sensor I Propietoria I I Panel de control I ~, , ... Sistema lecture , , -lislo CD , , Contrasena introducido r , , , Solicitud de busqueda ....L, , , Comparoci6n I I , , Resultado , , , Contrasena = correcto .1. , numerDe'ntentos > > ~ Solicitud de activacion , Intentosm6ximos , Cerrado , , Temporizador > , , A Tiempocerrodo , , , , , , , , , , Selecdon , , Activaci6n exitosa , Activaci6n exitoso I , ,

un objeto de contrasefia y realiza una comparacion digito par digito para validar 1a contrasena introducida. Diagramas de secuencia. El segundo tipo de representacion de comportamien­ to, Hamada un diagram a de secuencia en UML, indica como los eventos causan tran­ siciones de objeto a objeto. Una vez que se han identificado los eventos al examinar un caso de usa, el modelador crea un diagrama de secuencia: una representacion de c6mo los eventos causan un flujo de un even to a otro como una funci6n del tiempo. En esencia, eJ diagrama de secuencia es una versi6n abreviada del caso de uso. Representa c1ases clave y eventos que causan que el comportamiento Ouya de clase a clase. En la figura 8.21 se ilustra un diagrama de secuencia parcial de la funci6n de seguridad de HogarSeguro. Cada Oecha representa un even to (derivado de un caso de uso) e indica como el even to canaliza el comportamiento entre los objetos de HogarSeguro. EI tiempo se mide de manera vertical (hacia abajo), y los rectimgulos verticales delgados representan el tiempo invertido en procesar una actividad. Los est ados se pueden mostrar a 10 largo de una linea de tiempo vertical. EI primer evento, sistema /isto, se deriva del ambiente externo y canaliza el COffi­ portamiento a un objeto de propietario. EI propietario introduce una contrasena. Se pasa un even to de solicitud de bUsqueda al sistema, el cual busca la contrasefia en una base de datos simple y regresa un resultado (encontrado 0 no enconlrado) al PaneldeControl (ahara en el estado de comparacion). Una contraseiia valida resul· CAPiTuLo 8 MODELADO DEL ANAuSIS 239

ta en un evento contrasena=correcta para el Sistema, el cual activa los sensores can un evento de soJicitud de activaci6n. Por ultimo, el control se pasa de regreso al pro­ pietario con el evento activaci6n exitosa. Una vez que se ha desarrollado un diagrama de secuencia completo, todos los eventos que ocasionan transiciones entre objetos del sistema se pueden cotejar can un conjunto de eventos de entrada y eventos de salida (de un objeto). Esta informa­ ci6n es uti I en la creaci6n de un diseiio eficaz para el sistema que sera construido.

~ Modelado del anCrlisis generalizado en UML ~ Objetivo: los herromientas para el modelodo ArgoUML, uno herromiento de Fuente obierto del on61isis praporcionon 10 copacidod de (orgouml.tigris.org). desarrollor modelos bosados en escenarios, modelos Control Center, desorrollado por TogetherSoft basados en closes y modelos de comportomiento mediante (www.togethersoft.com). 10 notocian UMl. Enferprise Architect, desarrollado por Sparx Systems Mecanica: los herramientos en esta categoria soporton (www.sporxsystems.com .ou). el omplio rango de diagromas en UMl requeridos para Object Technology Workbench (OTW), de,arrollada por construir un modelo de an61isis (estes herramientos OTW Software (www.otwsoftwore.com). tombiim soporton el modelado del diseno). Adem6s de 10 creacion de diagromas, los herramientas en esta categoria Power Designer, desarrollado por Sybose (www.sybase.com). 1J realizan 10 verificacian de 10 consistencia y 10 correccian de todos los diagromos en UMl; 2) proporcionan vinculos Rational Rose, desarrollodo par Rational Corporation poro el diseno y la generacion de c6digo; 3) construyen (www.rationol.com). una base de datos que ayudan a 10 administracian y Sysfem Architect, desarrollado por Popkin Software evaluocion de grondes modelos en UMl requeridos para (www.popkin.com). sistemas complejos. UML Studio, desorrollado por Pragsoft Corporation Herramientas representativas27 {www.progsoft.coml. las siguientes herromientos soportan un rongo completo Visio, desarrollodo par Microsoft (www.microsoft.com). de diagramas en UMl requeridos para el modelado del Visual UML, desarrollodo par Visual Obiect Modelers an6lisis: (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 como un transformador de in for-

27 Las herramientas mencionadas aqui son una muestra de esta categoria. En la mayoria de los casos los nombres estan registrados par sus respectivos desarrolladores. 240 PARTE DOS pRAcnCA DE LA INGENIERiA DEL SOf1WARE

maci6n. Este ayuda al ingeniero de software a identiflcar los objetos de datos, sus relaci.ones y la manera en la cual estos objetos de datos se transforman mientras fiu­ yen a traves de las funciones de procesa miento 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 i1u stran 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 flujo, que se deriva n 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 flujo 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 flujo 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 sa bilidad-colabo­ rador puede usarse en la definicion de relaciones en tre 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, Prentice-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-Oriented 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] Thalheim, B., Entity Relationship Modeling, Springer-Verlag, 2000. ]TIL93] Ti!lmann, G., A Practical Guide to Logical Data Modeling, McGraW-Hill, 1993. [UML03] The UML Cafe, "Customers Don't Print Themselves", disponible en http://www. theumicafe.com/a0079.htm, mayo de 2003. [WIR90] Wirfs-Brock, R., B. Wilkerson y L. Weiner, Designing Object-Oriented Software, Prentice­ Hall, 1990.

8 . 1. ~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. Desarrollar un modelo de ciase para el sistema SRRB presentado en el problema 8.10.

8. 15. Desarrollar un conjunto completo de tarjetas indice del modele CRC para el sistema SRRB presentado en el problema 8.10. 8. 16 . Encabezar una revision de [as tarjetas indice de CRC con sus colegas. iCuantas clases adicionaies, responsabilidades y colaboradores fueron agregados como consecuencia de la revi­ si6n? 8. 17. Describir la diferencia entre una asociaci6n y una dependencia para una clase de anali­ sis. 8.IB. iQUe es un paquete de analisis y c6mo debe utilizarse? B.19 . .!oDe que manera difiere un diagrama de estado para c1ases de anal isis de los diagramas de estado presentados para el sistema completo?

PTRAS L"TyRAS X FUENTES DE INFORMACION

Se han pubJicado docenas de Iibros sobre analisis estructurado. En la mayoria se trata el tema de una manera adecuada, pero 5610 en unos cuantos se presenta un trabajo en verdad exce­ lente. DeMarco y PI auger (Structured Analysis and System Specification, Pearson, 1985) es un cJa­ sica que sigue siendo una buena introducci6n a la notaci6n basica. Los Jibros de Kendal y Kendal (Systems Anatysis and Design, 5a . ed. , Prentice-Hall, 2002) y Hoffer et al. (Modern Systems Anatysis and Design, Addison-Wesley, 3a. ed., 2001) son referencias valiosas. Ellibro de Yourdon (Modern Structured Ana!'ysis, Yourdon-Press, 1989) sobre el tema se conserva entre las publica­ ciones mas completas a la fecha. Allen (Data Modeling Jor Everyone, Wrox Press, 2002), Simpson y Witt (Dala Modeling Essentials, 2a. ed., Coriolis Group, 2000), Reingruber y Gregory (Data Modeling Handbook, Wiley, 1995) presentan 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­ rimientos. 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 actualizada de referencias de la red que son notables para el model ado del anaJisis: http://www.mhhe.com/pressman.