Manual de UML - Paul Kimmel

www.FreeLibros.me

MANUAL DE UML

00 KIMMEL Preliminares.indd 1 11/5/07 12:09:59 AM

www.FreeLibros.me


www.FreeLibros.me

MANUAL DE UML

PAUL KIMMEL

MXICO BOGOT BUENOS AIRES CARACAS GUATEMALA LISBOA MADRID NUEVA YORK SAN JUAN SANTIAGO

AUCKLAND LONDRES MILN MONTREAL NUEVA DELHI SAN FRANCISCO SINGAPUR ST. LOUIS SIDNEY TORONTO

Traduccin

Jos Hernn Prez CastellanosTraductor profesional


www.FreeLibros.me

Prohibida la reproduccin total o parcial de esta obra, por cualquier medio, sin autorizacin escrita del editor.

DERECHOS RESERVADOS 2008 respecto a la primera edicin en espaol porMcGRAW-HILL INTERAMERICANA EDITORES, S.A. de C.V.A Subsidiary of The McGraw-Hill Companies, Inc.

Corporativo Punta Santa FeProlongacin Paseo de la Reforma 1015 Torre APiso 17, Col. Desarrollo Santa Fe,Delegacin lvaro ObregnC.P. 01376, Mxico, D.F.Miembro de la Cmara Nacional de la Industria Editorial Mexicana, Reg. nm. 736

ISBN 970-10-5899-2

Translated from the 1st English edition ofUML DEMYSTIFIEDBy: Paul KimmelCopyright MMVI by The McGraw-Hill Companies, Inc. All rights reserved.

ISBN: 0-07-226182-X

1234567890 09765432108

Impreso en Mxico Printed in Mexico

Director Editorial: Fernando Castellanos RodrguezEditor de desarrollo: Cristina Tapia Montes de OcaSupervisor de produccin: Jacqueline Brieo lvarezDiagramacin: By Color Soluciones Grficas

MANUAL DE UML


www.FreeLibros.me

A la memoria de mi hermana Jennifer Anne a quien slo se le concedieron 35 aos.


www.FreeLibros.me

ACERCA DEL AUTOR

Paul Kimmel es arquitecto en jefe y uno de los fundadores de Software Concep-tions, Inc. Ha estado diseando e implementando software orientado a objetos desde 1990, tiene ms de 12 aos de experiencia con los lenguajes de modelado, y fue uno de los primeros en adoptar el Unied Modeling Language. Paul ha ayu-dado a disear e implementar soluciones con el uso del uml para algunas de las ms grandes corporaciones del mundo, desde bancos internacionales, empresas multinacionales de telecomunicaciones, empresas de logstica y embarque, o-cinas del Departamento de Defensa hasta grupos gubernamentales, nacionales e internacionales.


www.FreeLibros.me

vii

CONTENIDO BREVE

CAPTULO 1 Una imagen vale ms que mil lneas de cdigo 1

CAPTULO 2 El principio con casos de uso 17

CAPTULO 3 Diagramacin de caractersticas como procesos 47

CAPTULO 4 Comportamientos con diagramas de interaccin 81

CAPTULO 5 Cules son las cosas que describen mi problema? 101

CAPTULO 6 Cmo se relacionan las clases 131

CAPTULO 7 Uso de los diagramas de esquemas de estado 157

CAPTULO 8 Modelado de componentes 175

CAPTULO 9 Ajuste y nalizacin 185

CAPTULO 10 Visualizacin de su topologa de despliegue 197

APNDICE A Examen nal 209

Bibliografa seleccionada 225

ndice 227


www.FreeLibros.me


www.FreeLibros.me

ix

CONTENIDO

Reconocimientos xv

Introduccin xvii


Comprensin de los modelos 2

Comprensin del UML 3

La evolucin del diseo de software 3

Si nadie est modelando, por qu debe hacerlo usted? 5

Modelado y el futuro del desarrollo de software 5

Herramientas para modelado 5

Uso de los modelos 6

Creacin de diagramas 7

Revisin de los tipos de diagramas 7

Hallar la lnea nal 12

Cuntos diagramas debo crear? 12

Cun grande debe ser un diagrama? 13

Cunto texto debe complementar mis modelos? 13

Obtenga una segunda opinin 13


www.FreeLibros.me

Manual de UML x

Contraste de los lenguajes de modelado con el proceso 14

Examen 14

Respuestas 16


Cmo hacer el caso para los casos de uso 18

Establecimiento de prioridad de las capacidades 19

Comunicacin con los no tecnlos 20

Uso de los smbolos de los casos de uso 21

Smbolos de actores 21

Casos de uso 21

Conectores 22

Casos de uso de inclusin y de extensin 25

Anotaciones en los diagramas de casos de uso 27

Creacin de los diagramas de casos de uso 32

Cuntos diagramas son sucientes? 34

Ejemplos de diagramas de casos de uso 34

Diseo controlado con casos de uso 43

Examen 44

Respuestas 46

CAPTULO 3 Diagramacin de caractersticas como procesos 47

Elaboracin de las caractersticas como procesos 48

Un viaje hacia el cdigo 48

Comprensin de los usos de los diagramas de actividades 49

Uso de lo smbolos de los diagramas de actividades 51

Nodo inicial 52

Flujo de control 52

Acciones 56


www.FreeLibros.me

xi

Nodos de decisin y de fusin 62

Bifurcaciones y uniones de transicin 63

Particin de la responsabilidad con carriles 63

Indicacin de las seales cronometradas 67

Conguracin de los parmetros de entrada 70

Forma de mostrar las excepciones en los diagramas de actividades 70

Terminacin de los diagramas de actividades 71

Creacin de los diagramas de actividades 72

Reingeniera del proceso 73

Reingeniera de una subactividad 74

Saber cundo renunciar 77

Examen 77

Respuestas 79

CAPTULO 4 Comportamientos con diagramas de interaccin 81

Elementos de los diagramas de secuencia 82

Uso de las lneas de vida de objetos 83

Activacin de una lnea de vida 84

Envo de mensajes 85

Adicin de restricciones y notas 87

Uso de marcos de interaccin 87

Comprensin de lo que nos dicen las secuencias 91

Descubrimiento de objetos y mensajes 92

Elementos de los diagramas de colaboracin (o comunicacin) 94

Igualacin del diseo con el cdigo 96

Examen 97

Respuestas 99

CONTENIDO


www.FreeLibros.me

Manual de UML xii

CAPTULO 5 Cules son las cosas que describen mi problema? 101

Elementos de los diagramas bsicos de clase 102

Comprensin de las clases y los objetos 103

Modelado de relaciones en los diagramas de clases 112

Estereotipado de las clases 117

Uso de paquetes 118

Uso de notas y comentarios 118

Restricciones 118

Modelado de primitivos 120

Modelado de enumeraciones 121

Indicacin de espacios de nombres 122

Cmo saber qu clases necesita 123

Uso de un enfoque ingenuo 124

Descubra otros benecios del anlisis de dominios 124

Examen 128

Respuestas 130

CAPTULO 6 Cmo se relacionan las clases 131

Modelado de la herencia 132

Uso de la herencia simple 132

Uso de la herencia mltiple 135

Modelado de la herencia de interfaces 139

Boceto de diagrama 139

Uso de la realizacin 140

Descripcin de la agregacin y la composicin 143

Asociaciones y las clases asociaciones 145

Examen de las relaciones de dependencia 150

Adicin de detalles a las clases 153


www.FreeLibros.me

xiii

Examen 153

Respuestas 155

CAPTULO 7 Uso de los diagramas de esquemas de estado 157

Elementos de un diagrama de estado 158

Examen de los smbolos de estado 159

Examen de las transiciones 164

Creacin de mquinas de estado de comportamiento 166

Creacin de mquinas de estado de protocolo 167

Implementacin de diagramas de estado 168

Examen 172

Respuestas 174

CAPTULO 8 Modelado de componentes 175

Introduccin del diseo basado en componentes 177

Diseo componentes-interfaz 177

Diseo a partir de las clases 177

Modelado de un componente 178

Especicacin de las interfaces proporcionadas y requeridas 179

Examen de los estilos de modelado de componentes 180

Trazado de los diagramas de componentes para consumidores 180

Trazado de los diagramas de componentes para productores 182

Examen 183

Respuestas 184

CAPTULO 9 Ajuste y nalizacin 185

Modelado de los hacer y los no hacer 186

No tenga esperando a los programadores 187

CONTENIDO


www.FreeLibros.me

Manual de UML xiv

Trabaje de una macrovista hacia una microvista 187

Documente en forma econmica 187

Encuentre un editor 188

Sea selectivo acerca de los diagramas que elige crear 188

No dependa de la generacin del cdigo 188

Modele y estructure disminuyendo el riesgo 188

Si es obvio, no lo modele 189

Haga hincapi en la especializacin 189

Uso de patrones de estado conocidos 189

Refactorizacin de su modelo 192

Modo de agregar documentacin de soporte 192

Validacin de su modelo 193

Examen 193

Respuestas 195

CAPTULO 10 Visualizacin de su topologa de despliegue 197

Modelado de nodos 198

Manera de mostrar artefactos en nodos 201

Adicin de trayectorias de comunicacin 204

Examen 206

Respuestas 207

APNDICE A Examen nal 209

Respuestas 223

Bibliografa seleccionada 225

ndice 227


www.FreeLibros.me

xv

Bien entrada mi segunda dcada como escritor, tengo que agradecer a Wendy Ri-naldi, de McGraw-Hill/Osborne, junto con Alexander McDonald y a mi agente Da-vid Fugate, de Waterside, por esta oportunidad de escribir lo que creo que el lector encontrar como un libro informativo, entretenido y fcil de seguir sobre el Unied Modeling Language.

Tambin quiero manifestar mi agradecimiento a Eric Cotter, de Portland, Ore-gon, al ofrecerse para proporcionar la edicin tcnica para el Manual de uml. Eric realiz un trabajo excelente al hallar mis equivocaciones y omisiones, as como al mejorar las explicaciones.

Doy las gracias a mis antriones en el Ministry of Transportation Ontario, de St. Catharines, Ontario; colaborar con ustedes en el CIMS fue un proceso agradable y el examen de mis modelos y diseos con ustedes proporcion una excelente base para este libro. Gracias tambin a Novica Kovacevic, Jennifer Fang, Rod, Mar-co Snchez, Chris Chartrand, Sergey Khudoyarov, Dalibor Skacic, Michael Lam, Howard Bertrand y David He de Microsoft; fue un placer trabajar con y aprender de todos ustedes.

En 2004, junto con Bill Maas, Paul Emery, Sainney Drammeh, Bunmi Akin-yemichu y Ryan Doom, se form el rea Greater Lansing de .NET Users Group (glugnet.org) y me gustara mandar un saludo a todos los grandes miembros y pro-motores de glugnet. Nos reunimos el tercer jueves de cada mes a las 6:00 p.m., en el bello campus de la Michigan State University. Gracias a la MSU por permitir el uso de sus excelentes instalaciones en el Engineering Building y el Anthony Hall.

Mientras estaba trabajando en Ontario, mi sustento me fue graciosamente su-ministrado en Prudhommes, en Vineland, Ontario, en las salidas 55 y 57, y en el Honest Lawyer, en St. Catharines, Ontario, Canad. Gracias a Lis, Jen, Cheriton, Everett, Kathryn y Kim por los alimentos y la bebida para adultos, as como al per-sonal del Honest Lawyer, por el acceso inalmbrico.

RECONOCIMIENTOS


www.FreeLibros.me

Por ltimo, pero no porque sean los menos importantes, tengo una deuda de gratitud con mi esposa Lori y mis cuatro hijos, Trevor, Douglas, Alex y Noah, que representan el papel de mis ms importantes admiradores y partidarios. Una familia es la ms grande de las bendiciones. (Tambin me gustara presentar al miembro ms reciente de nuestra familia, Leda, un eciente laboratorio de chocolate, quien espera con paciencia a mis pies como un sutil recuerdo para empujarme de regreso a la computadora e ir a hacer algo ms una que otra vez.)


www.FreeLibros.me

xvii

A menudo, los nuevos inventos nacen sin necesidad y se documentan sobre serville-tas mucho antes, si acaso, de que se proporcione una denicin autorizada y formal. El Unied Modeling Language (uml) es precisamente uno de esos ejemplos. Los aspectos individuales de lo que al nal se convirti en el uml los denieron Ivar Jacobson, James Rumbaugh y Grady Booch, sin necesidad, mucho antes de que sus colaboraciones individuales se consolidaran en una sola denicin.

Existe un problema mixto con las especicaciones formales y estndar. En gene-ral, para que un cuerpo augusto de cientcos ratique algo debe estar denido sin ambigedad y con rigor. Si busca la denicin del uml, encontrar metamodelos que describen hasta el ms mnimo detalle lo que es y lo que no es. El efecto es muy semejante a leer informes del congreso: extensos, ridos, tediosos y con un poquito de jugo ocasional. Piense en las deniciones formales, en comparacin con las aplicaciones prcticas, como esto: existen reglas rigurosas especcas que denen algo tan sencillo como el lgebra, pero usted no necesita conocerlas, aun cuando realizamos lgebra sencilla o nos apoyamos en ella en tareas cotidianas, como bombear gasolina. Por ejemplo, precio por litro multiplicado por el nmero de litros = precio total. Con una simple sustitucin de texto por carcter, podemos crear ecuaciones aritmticas, p * g = t, que empiezan por parecerse a esas confusas ecuaciones de la escuela, pero que las hacen convenientes, desde el punto de vista rotacional, para determinar cualquier cantidad de ella. Lo que quiero decir es que incluso las personas que se identicaran como desaadas por las matemticas las aplican todos los das para nes prcticos, sin siquiera pensar que lo que estn ha-ciendo es resolver problemas matemticos.

se es el objetivo de este libro. Hay deniciones formales y rigurosas del uml y existen por buenas razones, pero usted no necesita conocerlas para usar este lengua-je de una manera prctica. Los lingistas del uml deben conocerlo en lo ms ntimo, para denir con rigor, precisamente como los profesores de un idioma conocen la

INTRODUCCIN


www.FreeLibros.me

Manual de UML xviii

gramtica hasta lo ms profundo para poder ensearlo, pero usted no necesita ser un profesor de su idioma para comunicarse con ecacia. Esto es verdad tambin para el uml; no necesita conocer todos los detalles acerca de l para usarlo con ecacia.

uml DesMiticado est escrito de manera sencilla y est diseado para hacer que este lenguaje sea prctico, as como una herramienta ecaz para comunicar anlisis y diseo de software.

Hay muchos libros sobre proceso, y el uml no dene un proceso. Sin embargo, este libro est organizado de tal manera que si usted crea los tipos de modelos se-gn se necesita, en el orden en el que aparecen en l, entonces puede contar con un inicio prctico de un proceso susceptible de usarse.

uml DesMiticado es un libro de tamao modesto, pero es una recopilacin de ms de una docena de aos de experiencia prctica trabajando con algunas de las mayores y mejor conocidas empresas del mundo, as como con muchas bien cono-cidas y no tan grandes empresas. El uml descrito en este libro es pragmtico, prc-tico y aplicable, ya sea que usted se encuentre estructurando aplicaciones pequeas, medianas o muy grandes. En pocas palabras, uml DesMiticado deja la pelusa y el rigor de torre de marl a otros textos y le dice a usted lo que necesita saber para usar con xito el uml al describir software.


www.FreeLibros.me

1CAPTULO

Las imgenes de pequeas personas formadas por palillos representan la forma de comunicacin ms antigua registrada en la historia humana. Algo de este arte rupestre se remonta a pocas tan antiguas como hace 75,000 aos. Lo que resulta bastante extrao es que nos encontramos al principio del moderno siglo xxi y to-dava estamos usando pequeas guras de lnea para transmitir informacin. Eso es correcto; un pequeo hombre formado por palillos que llamamos Esaw es el carcter central en uno de los lenguajes ms recientes desarrollado por los humanos (gura 1-1).

1

Una imagen vale ms que mil lneas de cdigo

1

01 KIMMEL.indd 1 11/4/07 7:00:18 PM

www.FreeLibros.me

Manual de UML 2

El lenguaje acerca del cual estoy hablando se llama Unied Modeling Language (Len-guaje unicado de modelado), o uml. El uml es un lenguaje tanto como Pascal, C# (C sharp), el alemn, el ingls y el latn; y el uml posiblemente es uno de los lenguajes ms recientes inventados por la humanidad, alrededor de 1997.

Como sucede con otros lenguajes, el uml fue inventado por necesidad. Es ms, como con muchos lenguajes, en el uml se usan smbolos para transmitir signicado. Sin embar-go, a diferencia de los lenguajes orgnicos, como el ingls y el alemn, que evolucionan con el transcurso del tiempo a partir del uso comn y la adaptacin, el uml fue inventado por cientcos, lo cual, por desgracia, es un problema. Los cientcos son muy inteli-gentes pero con frecuencia no son muy buenos para explicar las cosas a aquellos menos cientcos. Aqu es en donde intervengo.

En este captulo, revisaremos el origen y la evolucin del uml; tambin hablaremos acerca de cmo crear imgenes usando el uml, cuntas imgenes crear y qu tipos de ellas, qu deben transmitir esas imgenes y, lo ms importante, cundo suspender el di-bujo de imgenes y empezar a escribir cdigo.

Comprensin de los modelosUn modelo es una coleccin de imgenes y texto que representa algo; para nuestros -nes, software. (Los modelos no tienen que representar software, pero ahora reduciremos nuestro mbito a los modelos de software.) Un modelo es para el software lo que un plano azul es para una casa.

Los modelos son valiosos por muchas razones especcas; en gran parte, constan de imgenes e, incluso, las imgenes simples pueden transmitir ms informacin que una gran cantidad de texto; por ejemplo, cdigo. Esto resulta coherente con el viejo adagio un tanto modicado de que una imagen expresa un millar de lneas de cdigo. Los modelos son valiosos porque es ms fcil dibujar algunas imgenes sencillas que escribir cdigo o incluso texto que describan lo mismo. Los modelos son valiosos porque es ms barato, rpido y fcil cambiar modelos que cambiar cdigo. La verdad simple es que barato, r-pido, fcil y exible es lo que usted quiere cuando est resolviendo problemas.

Figura 1-1 Esaw, a quien se menciona como actor en el uml.

Esaw

01 KIMMEL.indd 2 11/4/07 7:00:19 PM

www.FreeLibros.me


Desafortunadamente, si cada uno usa imgenes diferentes para dar a entender lo mis-mo, entonces las imgenes se agregan a la confusin, en lugar de mitigarla. Aqu es en donde entra el uml.

Comprensin del UMLEl uml es una denicin ocial de un lenguaje pictrico con smbolos y relaciones co-munes que tienen un signicado comn. Si todos los participantes hablan uml, entonces las imgenes tienen el mismo signicado para todos aquellos que las observen. Por lo tanto, aprender uml es esencial para ser capaz de usar imgenes para experimentar bara-ta, exible y rpidamente con las soluciones.

Es importante reiterar aqu que es ms rpido, ms barato y ms fcil resolver proble-mas con imgenes que con cdigo. La nica barrera para obtener benecios del modela-do es aprender el lenguaje del mismo.

El uml es un lenguaje precisamente como lo son el ingls o el afrikaans. El uml comprende smbolos y una gramtica que dene la manera en que se pueden usar estos smbolos. Aprenda los smbolos y la gramtica, y sus imgenes sern comprensibles para todo aquel que reconozca estos smbolos y conozca la gramtica.

Aunque, por qu el uml? Usted podra usar cualesquiera smbolos y reglas con el n de crear su propio lenguaje de modelado, pero el truco estara en hacer que otros tambin lo usaran. Si sus aspiraciones son inventar un mejor lenguaje de modelado, entonces no me corresponde detenerlo. Debe saber que el uml se considera un estndar y que lo que este lenguaje es o no es lo dene un consorcio de empresas que constituyen el Object Management Group (omg, Grupo de Administracin de Objetos). La especicacin del uml est denida y ha sido publicada por el omg en www.omg.org.

La evolucin del diseo de softwareSi siente que ha llegado tarde a la esta del uml, no se inquiete; en realidad, ha llegado temprano. La verdad es que el uml ha llegado tarde a la esta de desarrollo del software. Trabajo en todo Estados Unidos y converso con una gran cantidad de gente en muchas empresas muy grandes de software, y el uml y el modelado apenas estn empezando a ponerse de moda. Esto queda ejemplicado de la mejor manera en las propias palabras de Bill Gates despus de su famosa semana de reexin en 2004, en donde se informa que habl acerca de la importancia creciente del anlisis y diseo formales (lase uml) en el futuro. Este sentimiento lo apoya tambin la muy reciente compra de Visio, que incluye las capacidades de modelado de uml, por parte de Microsoft.

01 KIMMEL.indd 3 11/4/07 7:00:19 PM

www.FreeLibros.me

Manual de UML 4

El uml representa una formalizacin del anlisis y el diseo, y la formalizacin siem-pre parece llegar tarde. Considere los fabricantes de automviles del siglo pasado. Al principio del siglo pasado, todos los fabricantes de coches en Flint, Michigan, estaban convirtiendo los carruajes ligeros tirados por un solo caballo en automviles. Esto ocu-rri mucho antes de que las grandes universidades, como la Michigan State University (msu), graduaran ingenieros mecnicos capacitados para construir automviles y herra-mientas de software, como programas para diseo con ayuda de computadora (cad) que son especialmente buenos en el dibujo de artculos complejos, como las partes de los au-tomviles. La evolucin de la ingeniera formalizada de los automviles es consecuente con la evolucin de la ingeniera formalizada del software.

Hace alrededor de 5000 aos, los chinos crearon una de las primeras computadoras: el baco. Hace cerca de 150 aos, Charles Babbage invent una mquina mecnica de clculo. En 1940, Alan Turing deni la mquina Turing de clculo, y Presper Eckert y John Mauchly inventaron la Eniac. Despus de las mquinas de clculo, vinieron las tarjetas perforadas y el anlisis y diseo estructurados de Grace Hopper para apoyar el desarrollo de Cobol. En la dcada de 1960, se invent Smalltalk, un lenguaje orientado a objetos, y en 1986, Bjarne Stroustrop invent lo que ahora se conoce como C++. No fue sino hasta alrededor de este mismo periodo la dcada de 1980 cuando hombres muy inteligentes, como Ivar Jacobson, James Rumbaugh y Grady Booch, empezaron a denir los elementos del anlisis y diseo modernos de software, lo que ahora llamamos el uml.

A nales de la dcada de 1980 y principios de la de 1990, las guerras sobre la nota-cin del modelado estaban plenamente entabladas, con diferentes facciones apoyando a Jacobson, Rumbaugh o Booch. Recuerde, no fue sino hasta 1980 cuando la persona promedio pudo comprar y poseer una computadora personal (pc), y hacer algo til con ella. Jacobson, Rumbaugh y Booch, cada uno por su lado, usaron smbolos y reglas di-ferentes para crear sus modelos. Finalmente, Rumbaugh y Booch empezaron a colaborar en relacin con los elementos de sus respectivos lenguajes de modelado, y Jacobson se les uni en Rational Software.

A mediados de la dcada de 1990, se fusionaron los elementos de modelado de Rum-baugh [Object Modeling Technique (omt, tcnica de modelado de objetos)], Booch (mtodo de Booch) y Jacobson (Objectory and Use Cases, cajas objetos y de usos) a Rumbaugh, Jacobson y Booch se les mencionaba como los tres amigos para formar el proceso unicado de modelado. Poco tiempo despus, se elimin proceso de la espe-cicacin del modelado y naci el uml. Esto ocurri hace muy poco tiempo, apenas en 1997. La especicacin uml 2.0 se estabiliz en octubre de 2004. Es correcto, ahora slo estamos en la versin 2.

Esto lleva a la pregunta: precisamente cuntas empresas estn usando el uml y, en realidad, diseando software con modelos? La respuesta es todava muy pocas. Traba-jo en toda Norteamrica y personalmente conozco ejecutivos en algunas empresas de software con mucho xito, y cuando les pregunto si estructuran el software con uml, la respuesta es, casi siempre, no.

01 KIMMEL.indd 4 11/4/07 7:00:19 PM

www.FreeLibros.me


Si nadie est modelando, por qu debe hacerlo usted?

Una persona racional podra preguntar: por qu entonces, si Bill Gates est ganando miles de millones escribiendo software sin hacer un hincapi signicativo en el modelado for-mal, debo preocuparme acerca del uml? La respuesta es que casi el 80% de todos los pro-yectos de software fallan. Estos proyectos sobrepasan sus presupuestos, no proporcionan las caractersticas que los clientes necesitan o desean o, lo que es peor, nunca se entregan.

La tendencia actual es llevar al exterior el desarrollo del software, hacia las naciones en desarrollo o del tercer mundo. La idea bsica es que si los ingenieros estadouniden-ses especializados en software estn fallando, entonces si se paga una quinta parte a un desarrollador euroasitico de software esto permitir a las empresas intentar tener xito con una frecuencia cinco veces mayor. Qu estn hallando estas empresas que estn llevando el desarrollo hacia el exterior? Estn descubriendo que Estados Unidos tiene algunos de los mejores talentos y recursos disponibles, y que la mano de obra barata en lugares alejados slo introduce problemas adicionales y tampoco es garanta de xito. La respuesta real que se necesita consumir ms tiempo en el anlisis y el diseo del software, y esto signica modelos.

Modelado y el futuro del desarrollo de software

Un nfasis creciente en el anlisis y diseo formales no signica el n del crecimiento de la industria del software; signica que los das del salvaje, salvaje oeste de las dcadas de 1980 y 1990 llegarn al momento en que terminen; pero todava est el salvaje, salvaje oeste de los hackers, all en la tierra del software, y estar por algn tiempo.

Lo que un nfasis creciente en el anlisis y diseo del software signica precisamente ahora es que los profesionales capacitados en uml tienen una oportunidad nica para capitalizar este inters creciente en este lenguaje; tambin signica que, de manera gra-dual, menos proyectos fallarn, la calidad del software mejorar y se esperar que ms ingenieros en software aprendan el uml.

Herramientas para modeladoHasta hace muy poco, el modelado ha sido un cautivo en una torre de marl rodeada por una guarnicin impenetrable de cientcos armados con metamodelos y herramien-tas para modelar ridculamente caras. El costo de una licencia para una herramienta popular para modelar estaba en los miles de dlares, lo que signic que el profesional promedio deba gastar por una aplicacin para modelar tanto como lo que gast por toda una computadora. Esto es ridculo.

01 KIMMEL.indd 5 11/4/07 7:00:19 PM

www.FreeLibros.me

Manual de UML 6

Las herramientas para modelar pueden ser muy tiles, pero es posible modelar sobre trozos de papel. Por fortuna, usted no necesita ir tan lejos. La ame o la odie, Microsoft es muy buena para bajar el costo del software. Si tiene una copia de msdn, entonces tiene una herramienta casi gratuita para modelar: Visio. sta es una buena herramienta, capaz de producir de manera competente modelos uml de alta calidad, y no le destrozar su presupuesto.1

Para mantenernos en el tema de este libro desmiticar uml, en lugar de hacer saltar la banca en Together o Rose, usaremos el Visio de precio adecuado. Si el lector quiere usar Rose xde, Together o algn otro producto, sea bienvenido para hacerlo, pero despus de leer este libro ver que puede usar Visio y crear modelos profesionales, y ahorrarse cientos o incluso miles de dlares.

Uso de los modelosLos modelos consisten en diagramas o imgenes. Lo que se intenta con los modelos es que sean ms baratos para producir y experimentar que con el cdigo. Sin embargo, si usted trabaja arduamente sobre qu modelos trazar, cundo suspender el dibujo y empe-zar a codicar, o en si sus modelos son perfectos o no, entonces con lentitud observar reducirse el costo y el valor en tiempo de los modelos.

Puede usar texto llano para describir un sistema, pero se puede transmitir ms informa-cin con imgenes. Podra seguir con ahnco la mxima de la eXtreme Programming (xp, programacin extrema) y codicar, volviendo a descomponer en factores conforme avan-ce, pero los detalles de las lneas de cdigo son mucho ms complejos que las imgenes, y los programadores se adhieren al cdigo pero no a las imgenes. (Yo no comprendo por completo la psicologa de esta adhesin al cdigo, pero en realidad existe. Slo trate de criticar en forma constructiva el cdigo de alguien ms y observe cmo se deteriora la conversacin con rapidez hasta llegar al insulto.) Esto signica que una vez que se escribe el cdigo, es muy difcil obtener la aceptacin de su codicador o de un admi-nistrador para hacerle modicaciones, en especial si el cdigo se percibe para trabajar. Inversamente, la gente trabajar con mucho gusto de manera informal con los modelos y aceptar sugerencias.

Por ltimo, debido a que en los modelos se usan smbolos sencillos, ms personas interesadas pueden participar en el diseo del sistema. Muestre a un usuario nal un cen-tenar de lneas de cdigo y escuchar el chillar de los grillos; muestre a ese usuario nal un diagrama de actividades, y esa misma persona le dir si ha captado usted la esencia de cmo se realiza correctamente esa tarea.

1 Microsoft tiene un nuevo programa que le permite comprar msdn Universal, el cual incluye Visio, por 375 dlares. ste es un valor especialmente bueno.

01 KIMMEL.indd 6 11/4/07 7:00:19 PM

www.FreeLibros.me


Creacin de diagramasLa primera regla de la creacin de modelos es que el cdigo y el texto consumen tiempo, y no queremos pasar una gran cantidad de tiempo creando documentos de texto que nadie leer. Lo que s queremos hacer es captar con exactitud las partes importantes del pro-blema y una solucin. Desafortunadamente, sta no es una prescripcin para el nmero o la diversidad de diagramas que necesitamos crear y no indica cunto detalle necesitamos agregar a esos diagramas.

Hacia el nal de este captulo, en la seccin Hallar la lnea nal, hablar ms acerca de cmo se sabe que se ha completado el modelado. En este momento, hablemos acerca de los tipos de diagramas que tal vez queramos crear.

Revisin de los tipos de diagramas

Existen varios tipos de diagramas que usted puede crear. Revisar con rapidez los tipos de diagramas que puede crear y los tipos de informacin que se pretende transmitir con cada uno de estos diagramas.

Diagramas de casos de usoLos diagramas de casos de uso son el equivalente del arte rupestre moderno. Los smbo-los principales de un caso de uso son el actor (nuestro amigo Esaw) y el valo del caso de uso (gura 1-2).

Los diagramas de casos de uso son responsables principalmente de documentar los macrorrequisitos del sistema. Piense en los diagramas de casos de uso como la lista de las capacidades que debe proporcionar el sistema.

Diagramas de actividadesUn diagrama de actividades es la versin uml de un diagrama de ujo. Los diagramas de actividades se usan para analizar los procesos y, si es necesario, volver a realizar la ingeniera de los procesos (gura 1-3).

Figura 1-2 El caso de uso Hallar alimento.

Hallar alimento

01 KIMMEL.indd 7 11/4/07 7:00:20 PM

www.FreeLibros.me

Manual de UML 8

Un diagrama de actividades es una herramienta excelente para analizar problemas que, al nal, el sistema deber resolver. Como una herramienta de anlisis, no queremos em-pezar resolviendo el problema en un nivel tcnico mediante la asignacin de clases, pero podemos usar los diagramas de actividades para entender el problema e incluso renar los procesos que comprenden el problema.

Diagramas de clasesLos diagramas de clases se usan para mostrar las clases de un sistema y las relaciones entre ellas (gura 1-4). Una sola clase puede mostrarse en ms de un diagrama de clases y no es necesario mostrar todas las clases en un solo diagrama monoltico de clases. El mayor valor es mostrar las clases y sus relaciones desde varias perspectivas, de una ma-nera que ayudar a transmitir la comprensin ms til.

Figura 1-3 Un diagrama de actividades en el que se muestra la manera en que Esaw camina para hallar alimento.

Salir de la cueva

Vagar

Buscar alimento

Evitar los depredadores

(Necesitar ms alimento)

Regresar a la cueva

01 KIMMEL.indd 8 11/4/07 7:00:20 PM

www.FreeLibros.me


Los diagramas de clases muestran una vista esttica del sistema; no describen los comportamientos o cmo interactan los ejemplos de las clases. Para describir los com-portamientos y las interacciones entre los objetos de un sistema, podemos revisar los diagramas de interaccin.

Diagramas de interaccinExisten dos tipos de diagramas de interaccin: la secuencia y la colaboracin. Ambos transmiten la misma informacin, empleando una perspectiva un poco diferente. Los diagramas de secuencia muestran las clases a lo largo de la parte superior y los mensajes enviados entre esas clases, modelando un solo ujo a travs de los objetos del siste-ma. Los diagramas de colaboracin usan las mismas clases y mensajes, pero organiza-dos en una disposicin espacial. La gura 1-5 muestra un ejemplo sencillo de diagrama de secuencia, y la 1-6 transmite la misma informacin con el uso de un diagrama de colaboracin.

Un diagrama de secuencia implica un ordenamiento en el tiempo al seguir la secuen-cia de mensajes desde arriba a la izquierda hasta abajo a la derecha. Debido a que en el diagrama de colaboracin no se indica en forma visual un ordenamiento en el tiempo, numeramos los mensajes para indicar el orden en el cual se presentan.

Algunas herramientas convertirn de manera automtica los diagramas de interaccin entre secuencia y colaboracin, pero no es necesario crear los dos tipos de diagramas. En general, se percibe que un diagrama de secuencia es ms fcil de leer y ms comn.

Figura 1-4 Un diagrama sencillo de clases, quizs uno de muchos, que transmite una faceta del sistema que se est diseando.

Sustento Esaw

Agua Alimento

01 KIMMEL.indd 9 11/4/07 7:00:20 PM

www.FreeLibros.me

Manual de UML 10

Diagramas de estadoMientras que los diagramas de interaccin muestran los objetos y los mensajes que se pasan entre ellos, un diagrama de estado muestra el estado cambiante de un solo objeto, conforme ste pasa por un sistema. Si continuamos con nuestro ejemplo, entonces nos enfocaremos sobre Esaw y cmo est cambiando su estado a medida que busca con afn el alimento, lo encuentra y lo consume (gura 1-7).

RECUERDE Desmiticado: el UML es un lenguaje. Como programar o hablar idiomas, si no se usan con frecuencia, se pueden olvidar un poco. Es perfectamente aceptable mejorar un idioma particular. La meta del modelado es captar la esencia del mismo y disear con pericia y, nalmente, con tanta exactitud como sea posible, sin quedarse atascado decidiendo acerca de los elementos del lenguaje. Desafortunadamente, las he-rramientas del UML no son tan exactas como los compiladores en la descripcin de los errores del lenguaje.

Figura 1-5 Diagrama sencillo de secuencia en el que se demuestra cmo se recoge y prepara el alimento.

Esaw Canasta Fuego

Adquirir el alimento

Caminar hacia la cueva

Abrir

Tomar el alimento

Cocinar (alimento)

Trasladar (alimento)

Comer

Vaciar a la (alimento)

Alimento cocinado

01 KIMMEL.indd 10 11/4/07 7:00:20 PM

www.FreeLibros.me


Diagramas de componentesEl uml dene varios tipos de modelos, incluyendo modelos para anlisis, para diseo y para implementacin. Sin embargo, nada hay que le fuerce a crear o mantener tres mode-los para una aplicacin. Un ejemplo de un diagrama que podra encontrar en un modelo de implementacin es de componentes. En un diagrama de componentes, stos se mues-tran piense en subsistemas en el producto nal.

Figura 1-6 Diagrama de colaboracin que transmite el mismo comportamiento de adquisicin y consumo.

Figura 1-7 Diagrama de estado (o esquema de estado) que muestra el estado progresivo confor-me Esaw busca con afn el alimento y come.

Esaw

Canasta

Fuego

1: Reunir alimento3: Caminar hacia la cueva8: Comer el alimento

Canasta2: Vaciar a la4: Abrir5: Tomar el alimento

6: Cocinar el alimento

7: Retirar el alimento

Hambre Buscar

Comida

Reposo

/ Salir de la cueva

(Hambre)

(Seguro para comer) / Encontrar alimento

(No tiene hambre)

01 KIMMEL.indd 11 11/4/07 7:00:21 PM

www.FreeLibros.me

Manual de UML 12

Cubrir los diagramas de despliegue ms adelante en este libro, pero por ahora, apla-zar la cita de un ejemplo. En general, un diagrama de componentes es un poco semejan-te a uno de clases, con smbolos de componentes.

Otros diagramasHay otros tipos o variaciones de diagramas que podemos crear. Por ejemplo, un diagrama de topologa del despliegue le mostrar cmo se ver desplegado su sistema. Lo comn es que un diagrama de este tipo contenga smbolos que representen cosas, como servido-res web, servidores de bases de datos y varios dispositivos diversos, as como software que constituye la solucin de usted. Este tipo de diagrama es ms comn cuando usted est estructurando sistemas distribuidos en n hileras.

Ms adelante, en este libro, le mostrar ejemplos de algunos de estos diagramas. Recuer-de que, en el modelado, la clave consiste en modelar aspectos interesantes de su sistema que ayuden a aclarar elementos que puedan no ser obvios, en oposicin a modelarlo todo.

Hallar la lnea nalLa parte ms difcil del modelado es que es tan nuevo que los modelos uml estn sujetos a algo de las mismas guerras de los lenguajes que sufrieron los proyectos orientados a objetos durante la ltima dcada. Le aliento a evitar estas guerras de lenguajes, ya que principalmente son ejercicios acadmicos improductivos. Si se encuentra colgado acerca de si algo es bueno o no en uml, entonces se est dirigiendo hacia la parlisis del anlisis (y del diseo).

La meta es ser tan exacto como sea posible en una cantidad razonable de tiempo. El software mal diseado es sucientemente malo, pero ningn software es casi siempre peor. Con el n de determinar si ha concluido con un diagrama o modelo particular, haga la pregunta: el diagrama o modelo transmite lo que entiendo, lo que quiero dar a entender y mi intencin? Es decir, el diagrama o modelo es sucientemente bueno? La exactitud es importante porque los dems necesitan leer sus modelos, y los errores idio-mticos signican que esos modelos sern ms difciles de leer para los dems.

Cuntos diagramas debo crear?

No existe respuesta especca. Una pregunta mejor es: debo crear todo tipo de diagra-mas? La respuesta a esta pregunta es no. Un renamiento de esta respuesta es que resulta til crear diagramas que resuelvan los problemas delicados de anlisis y diseo, as como diagramas que la gente realmente leer.

01 KIMMEL.indd 12 11/4/07 7:00:21 PM

www.FreeLibros.me


Cun grande debe ser un diagrama?

Determinar cun grande necesita ser un modelo es otra buena cuestin para decidir. Si un modelo dado es demasiado grande, entonces puede aumentar la confusin. Intente crear modelos detallados, pero no demasiado. Como con la programacin, la creacin de modelos uml requiere prctica.

Solicite retroalimentacin de diferentes grupos cuya opinin sea importante. Si los usuarios nales piensan que un diagrama de anlisis capta de manera adecuada y correcta el problema, entonces siga adelante. Si los programadores pueden leer una secuencia y deducir cmo implementar esa secuencia, entonces siga adelante. Siempre puede agre-gar detalles, si debe hacerlo.

Cunto texto debe complementar mis modelos?

Una idea fundamental del uso de imgenes para modelar, en lugar de texto muy confuso, es que las imgenes transmiten ms signicado en menos espacio y son ms fciles de manipular. Si agrega demasiado texto restricciones, notas o documentos largos, en-tonces est anulando la nalidad de esta notacin pictrica ms concisa.

El mejor lugar para el texto es el caso de uso. Un buen texto descriptivo en cada caso de uso puede aclarar con precisin qu caracterstica apoya ese caso. En el captulo 2 demostrar algunas buenas descripciones de los casos de uso.

Se recibir bien que agregue cualquier texto aclaratorio que necesite, pero la regla general para el texto es anloga a la dada para los comentarios en cdigo: slo comente cosas que estn razonablemente sujetas a interpretacin.

Por ltimo, trate de documentar todo en su herramienta de modelado, en oposicin a un documento separado. Si encuentra que usted necesita o el cliente requiere un panora-ma arquitectnico general escrito, aplace esto hasta despus de que el software se haya producido.

Obtenga una segunda opinin

Si se encuentra atascado en un diagrama particular, obtenga una segunda opinin. Con frecuencia, dejar un diagrama a un lado durante un par de horas u obtener una segunda opinin le ayudar a resolver aspectos acerca de un modelo. Puede ser que halle que el usuario nal de ese modelo entender lo que usted quiere decir o proporcionar ms informacin que aclare la confusin, o bien un segundo par de ojos puede suministrar una respuesta lista. Un elemento crtico de todo software de desarrollo es construir cierta inercia y captar los macroconceptos, o grandes conceptos, sin quedarse atascado o man-tener esperando a los usuarios.

01 KIMMEL.indd 13 11/4/07 7:00:21 PM

www.FreeLibros.me

Manual de UML 14

Contraste de los lenguajes de modelado con el proceso

En realidad, el uml empez su vida como Unied Process (Proceso unicado). Los in-ventores se dieron cuenta con rapidez de que los lenguajes de programacin no deter-minan el proceso, ni debieran hacerlo los lenguajes de modelado. Por tanto, proceso y lenguaje se dividieron.

Existen muchos libros sobre procesos. No pienso que un proceso represente el mejor ajuste para todos los proyectos, pero quizs uno de los procesos ms exibles es el Ra-tional Unied Process (Proceso unicado racional). Mi enfoque en este libro es sobre el uml, no sobre cualquier proceso particular. Estar sugiriendo los tipos de modelos por crear y lo que le dicen a usted, pero le aliento a que examine los procesos de desarrollo por usted mismo. Considere examinar el Rational Unied Process (rup), el proceso Agile, eXtreme Programming (xp) e, incluso, Microsofts Services Oriented Architecture (soa, arquitectura orientada a servicios de Microsoft). [soa es ms que un procedimiento arqui-tectnico en el que se usan elementos como xml Web Services (Servicios web xml), pero ofrece algunas buenas tcnicas.]

No soy un experto en todos los procesos, pero enseguida doy un resumen que le dar un punto de partida. El rup es un aparador de actividades centradas en el uml, que dene macrofases iterativas en pequeas cascadas, incluyendo iniciacin, elaboracin, cons-truccin y transicin. xp es hackeo constructivo. En general, la idea se basa en estructurar sobre lo que usted comprenda, esperar que las cosas cambien y usar tcnicas como la programacin de redes composicin en factores y para apoyar los cambios a medida que usted aumenta su comprensin. El soa de Microsoft depende de tecnologas como com+, Remoting y los xml Web Services as como de una separacin de las responsabilidades por medio de los servicios. Agile es una nueva metodologa que no entiendo por comple-to, pero que en el libro del Dr. Boehm, Balancing Agility and Discipline, se le compara con xp, y sospecho que, desde el punto de vista conceptual, reside en alguna parte entre rup y xp.

Es importante tener presente que muchas personas o entidades que le ofrecen un pro-ceso pueden estar intentando venderle algo, y algunas muy buenas ideas tienen que venir de cada una de estas partes.

Examen1. Qu signica el acrnimo uml?

a. Uniform Model Language

b. Unied Modeling Language

01 KIMMEL.indd 14 11/4/07 7:00:22 PM

www.FreeLibros.me


c. Unitarian Mock-Up Language

d. Unied Molding Language

2. El UML slo se usa para modelar software.

a. Verdadero

b. Falso

3. Cul es el nombre del proceso ms ntimamente asociado con el UML?

a. El proceso de modelado

b. El Rational Unied Process

c. eXtreme Programming

d. Los mtodos Agile

4. Cul es el nombre del cuerpo de normas que dene el UML?

a. Unied Modeling Group

b. Object Modeling Group

c. Object Management Group

d. Los cuatro amigos

5. Los diagramas de caso de uso se usan para captar las macrodescripciones de un sistema.

a. Verdadero

b. Falso

6. Los diagramas de secuencia son diferentes de los de colaboracin (elija todo lo que sea aplicable).

a. Los diagramas de secuencia son diagramas de interaccin; los diagramas de colabo-racin no lo son.

b. Los diagramas de secuencia representan un ordenamiento en el tiempo, y los de colaboracin representan clases y mensajes, pero no se implica el ordenamiento en el tiempo.

c. El orden en el tiempo se indica numerando los diagramas de secuencia.

d. Ninguna de las anteriores.

7. Un diagrama de clases es una visin dinmica de las clases de un sistema.

a. Verdadero

b. Falso

8. Un buen modelo UML contendr por lo menos un diagrama de cada tipo.

a. Verdadero

b. Falso

01 KIMMEL.indd 15 11/4/07 7:00:22 PM

www.FreeLibros.me

Manual de UML 16

9. Cul es el apodo del grupo de cientcos ms notablemente asociados con el UML?

a. La pandilla de los cuatro

b. Los tres mosqueteros

c. Los tres amigos

d. El do dinmico

10. Los diagramas de secuencia son buenos para mostrar el estado de un objeto a travs de muchos casos de uso.

a. Verdadero

b. Falso

Respuestas 1. b

2. b

3. b

4. c

5. a

6. b

7. b

8. b

9. c

10. b

01 KIMMEL.indd 16 11/4/07 7:00:22 PM

www.FreeLibros.me

CAPTULO

17

El Unified Modeling Language (uml) soporta el anlisis y diseo orientados a obje-tos proporcionndole una manera de captar los resultados del anlisis y el diseo. En general, iniciamos con la comprensin de nuestro problema; es decir, el anlisis. Un tipo excelente de modelo para captar el anlisis es el diagrama de casos de uso.

La finalidad de un caso de uso es describir la manera en que se usar un sistema: describir sus finalidades esenciales. La finalidad de los diagramas de casos de uso es captar en forma visual las finalidades esenciales.

Un caso de uso bien escrito y bien representado en diagrama es una de las clasificaciones de modelos individuales ms importantes que usted puede crear. Esto es as porque expresar con claridad, conocer y organizar los objetivos es sin-gularmente importante para alcanzarlos con xito. Existe un viejo proverbio que dice: Un viaje de mil millas empieza con un paso, y existe un proverbio un poco menos antiguo que dice: Si no sabe hacia adnde va, entonces el viaje nunca terminar.

El principio con casos de uso

2

02 KIMMEL.indd 17 11/4/07 7:00:50 PM

www.FreeLibros.me

Manual de UML 18

En este captulo, hablar acerca de una primera parte significativa de ese viaje la creacin de casos de uso que cubrir

Los smbolos usados para crear los diagramas de casos de uso Cmo crear los diagramas de casos de uso Cuntos diagramas de casos de uso crear Cunto incluir en un diagrama de casos de uso El nivel de detalle a incluir en un diagrama de casos de uso Cmo expresar las relaciones entre los casos de uso individuales La cantidad y el estilo de texto que es til para hacer anotaciones en los diagramas

de casos de uso De manera signicativa, cmo establecer las prioridades de los casos de uso

Cmo hacer el caso para las casos de usoLos diagramas de casos de uso parecen muy fciles; constan de figuras de lnea, lneas y valos. La figura de palillos se llama actor y representa a alguien o algo que acta sobre el sistema. En el desarrollo de software, los actores son personas u otro software que ac-ta sobre el sistema. Las lneas son punteadas o continuas, con varias flechas o sin ellas, que indican la relacin entre el actor y los valos. Estos ltimos son los casos de uso y, en el diagrama de casos de uso, los valos tienen algn texto que proporciona una descrip-cin bsica. La figura 2-1 es un ejemplo sencillo de un diagrama de casos de uso.

Durante mucho tiempo los diagramas de casos de uso me fastidiaron porque parecan demasiado sencillos para tener algn valor. Un nio de tres o cuatro aos con un crayn y un pedazo de papel podra reproducir estas figuras de lnea; sin embargo, su sencillez es decepcionante.

Que un diagrama de casos de uso sea fcil de crear es un elogio implcito para el uml. Hallar los casos de uso correctos y registrar sus responsabilidades en forma correcta es la decepcin. Hallar los casos de uso correctos y describirlos de manera adecuada es el pro-ceso crtico que impide que los listos ingenieros de software pasen por alto necesidades

Figura 2-1 Un diagrama de casos de uso muy sencillo.

Patrn

Crear lista de trabajos

02 KIMMEL.indd 18 11/4/07 7:00:51 PM

www.FreeLibros.me


crticas y que inventen de manera innecesaria. En pocas palabras, los diagramas de casos de uso constituyen un macrorregistro de lo que usted quiere estructurar.

En el prrafo anterior, us el prefijo macro. Macro en este contexto sencillamente significa grande. Los grandes objetivos, o macroobjetivos, son los que se mencionan como los argumentos, o razones, poderosos de la empresa para hacer algo. En los diagra-mas de casos de uso se captan los objetivos grandes, poderosos. En el texto de esos casos se captan los detalles de apoyo.

Esto es lo que se me escapaba en las imgenes de las figuras de lnea de los diagramas de casos de uso; perda de vista que, sencillamente, al registrar lo que el sistema har y lo que no har, registramos y especificamos el alcance de lo que se est creando; tam-bin perda de vista que el texto que acompaa los diagramas de casos de uso rellena los espacios en blanco entre los macrosos y los microsos, en donde micro significa usos menores, de apoyo.

Adems de registrar los usos primarios y secundarios, los diagramas de casos de uso nos proporcionan en forma implcita varias oportunidades significativas para administrar el desarrollo, a lo cual entrar con ms detalle a medida que avance el captulo.

Establecimiento de prioridad de las capacidadesAlguna vez ha escrito una lista de cosas por hacer? Una lista de cosas por hacer es una lista de cosas que usted debe hacer o desea hacer. El acto de escribir la lista es un punto de partida. En esencia, los casos de uso son listas de cosas por hacer. Una vez que ha cap-tado los casos de uso, ha articulado lo que el sistema har, y puede usar la lista para dar prioridades a nuestras tareas. Tanto enunciar como organizar los objetivos son primeras tareas muy crticas.

El valor de establecer prioridades para las capacidades de un sistema es que el software es fluido. Permtame ilustrar, por medio de un ejemplo, lo que quiero decir. Es posible crear, guardar, abrir e imprimir un documento de texto tanto con Notepad (Bloc de notas) como con Word de Microsoft, pero la diferencia en el nmero de lneas de cdigo y el n-mero de caractersticas entre estos dos programas es tremenda. Al establecer prioridades de los usos, con frecuencia tenemos la oportunidad de hacer, con ventaja, malabarismos con las caractersticas, el presupuesto y el programa.

Suponga, por ejemplo, que mis objetivos primarios son ser capaz de crear, guardar, abrir e imprimir un documento de texto. Suponga adems que mis objetivos secundarios son guardar el documento como texto llano, HyperText Markup Language (html, lengua-je de marcado de hipertexto), y como texto enriquecido, es decir, formateo especial. Esta-blecer prioridades de las capacidades significa que podra elegir enfocarme hacia los usos primarios crear, guardar, abrir e imprimir, pero aplazar el soporte de html y texto enriquecido. (Las caractersticas en el software por lo comn se aplazan hacia versiones posteriores, debido a las restricciones reales mencionadas con anterioridad, incluyendo tiempo, presupuesto y un cambio en el entorno de la empresa.)

02 KIMMEL.indd 19 11/4/07 7:00:51 PM

www.FreeLibros.me

Manual de UML 20

No tener tiempo suficiente y quedarse sin dinero son problemas directos. Los desarro-lladores de software son rutinariamente optimistas, se distraen en salidas por la tangente y pasan ms tiempo en reuniones que en la planeacin, y estas cosas gravan un presu-puesto. Sin embargo, tomemos un momento para examinar un cambio en el entorno de la empresa. Si nuestras necesidades originales fueron html, texto llano y texto enrique-cido y hemos estado estructurando nuestro software en los ltimos cinco aos, resultara perfectamente plausible que un cliente dijera, a la mitad del curso del desarrollo, que guardar un documento como eXtensible Markup Language (xml, lenguaje ampliable de marcado) sera ms valioso que como texto enriquecido. De este modo, debido a un clima tecnolgico en evolucin, a media corriente un cliente podra restablecer las prioridades y demandar xml como ms importante que el texto enriquecido. Si no hubiramos docu-mentado nuestras necesidades primarias y secundarias, entonces podra ser un reto muy grande determinar los trueques deseables, como cambiar el texto enriquecido por el xml. Debido a que registramos con claridad los casos deseables de usos, podemos establecer prioridades y hacer trueques valiosos, si es necesario.

Comunicacin con los no tecnlos

Otra cosa que no perd de vista acerca de los casos de uso es que su mera sencillez los hace un medio fcil de transmisin para comunicarse con no tecnfilos. A estas personas las llamamos usuarios o clientes.

Los programadores que usan el hemisferio izquierdo de su cerebro en general detestan a los usuarios. La idea bsica es que si uno no puede leer el cdigo, entonces es tonto o, por lo menos, ms tonto que aquellos que s pueden. El uml y los casos de uso cubren la brecha entre los programadores que usan el hemisferio izquierdo del cerebro y los usuarios no tecnfilos.

Una figura de palillos, una lnea y un valo son suficientemente simplistas, cuando se combinan con algn texto, para que todos los participantes puedan entender el significado. El resultado es que los usuarios y clientes pueden observar los dibujos y leer el texto llano, y determinar si los tecnlogos han, o no, registrado con exactitud y comprendido las ca-ractersticas deseables. Esto tambin significa que los administradores quienes pueden no haber escrito cdigo en 10 aos y las direcciones tcnicas pueden examinar el pro-ducto final y, por inspeccin, garantizar que la inventiva desenfrenada no es la causa de los programas no cumplidos ni de las caractersticas ausentes. Demostrando esta disonancia al continuar con mi primer ejemplo, suponga que, de cualquier manera, se implementa el soporte de texto enriquecido porque el programador sabe cmo almacenar y recuperar ese tipo de texto. No obstante, debido a que el xml es ms reciente y el programador tiene me-nos experiencia en trabajar con l, la caracterstica de escritura en xml se aplaza sin ma-licia. Un administrador proactivo puede descubrir las necesidades de un cliente, segn se captan mediante los casos de uso, y apropiarse de salidas por la tangente improductivas.

02 KIMMEL.indd 20 11/4/07 7:00:51 PM

www.FreeLibros.me


Debido a que los casos de uso son visuales y sencillos, los usuarios y clientes pueden suministrar retroalimentacin, y las personas que constituyen el puente entre los clientes y los programadores, como los administradores, pueden determinar si las caractersticas que en realidad se estructuraron reflejan con exactitud los deseos de los usuarios.

Uso de los smbolos de los casos de usoLos diagramas bsicos de casos de uso constan de slo unos cuantos smbolos: el actor, un conector y el valo del caso de uso (figura 2-2). Tomemos unos cuantos minutos para hablar de cmo se usan estos smbolos y qu informacin transmiten.

Smbolos de actoresLa figura de palillos, mencionada como actor, representa participantes en los casos de uso. Los actores pueden ser personas o cosas. Si un actor es una persona, entonces, en realidad, nunca se puede representar por medio de un cdigo. Si un actor es otro subsis-tema, entonces se le puede observar como una clase o subprograma, pero todava repre-sentarse usando el smbolo de actor en los diagramas de casos de uso.

Los actores se descubren como resultado del anlisis. Conforme vaya identificando los macrousos del sistema, identificar quines son los participantes para esos casos de uso. En principio, registre cada actor a medida que se descubre, agregando un smbolo de actor a su modelo y describiendo cul es su papel. Nos preocuparemos acerca de la organizacin y el refinamiento ms adelante, en la seccin titulada Creacin de los diagramas de casos de uso.

Casos de usoEl smbolo del caso de uso se utiliza para representar capacidades. Al caso de uso se le da un nombre y una descripcin mediante un texto. Este ltimo debe describir cmo inicia y finaliza el caso de uso, e incluye una descripcin de la capacidad descrita por el nombre de la misma, as como escenarios de apoyo y requisitos no funcionales. En la seccin titulada Creacin de los diagramas de casos de uso, examinaremos ejemplos

Figura 2-2 Los smbolos bsicos de los diagramas incluyen al actor, al conector y al valo del caso de uso.

Actor Conector Caso de uso

02 KIMMEL.indd 21 11/4/07 7:00:51 PM

www.FreeLibros.me

Manual de UML 22

de nombres de casos de uso, y en la seccin titulada Documentacin de un caso de uso utilizando un borrador, proporcionar un borrador modelo que pueda usar para ayudarse a escribir las descripciones de los casos de uso.

Conectores

Dado que los diagramas de casos de uso tienen mltiples actores y en virtud de que los casos de uso pueden estar asociados con los actores y con otros casos de uso, se utilizan los conectores para indicar la manera en que ambos estn asociados. Adems, los estilos de conectores pueden cambiar para transmitir ms informacin acerca de la relacin entre los actores y los casos de uso. Por ltimo, los conectores pueden tener adornos y anotaciones que suministran incluso ms informacin.

Estilos de lneas para los conectoresExisten tres estilos bsicos de lneas para los conectores. Un conector de lnea simple se llama asociacin y se usa para mostrar cules actores estn relacionados con cules casos de uso. Por ejemplo, en la figura 2-1 se mostr que un patrn est asociado con el caso de uso Crear lista de trabajos.

Un segundo estilo de conector es una lnea punteada con una flecha direccional (figura 2-3). Este estilo de conector se conoce como dependencia. La flecha apunta hacia el caso de uso del que depende. Por ejemplo, suponga que a los patrones de www.motown-jobs.com se les debe dar acceso para crear una lista de trabajos. Entonces podemos decir que el caso de uso Crear lista de trabajo depende de un caso de uso Entrar. sta es la relacin que se ilustra en la figura 2-3.

Un tercer estilo de conector es una lnea dirigida con un tringulo hueco, al cual se le conoce como generalizacin. La palabra generalizacin en el uml significa herencia. Cuando mostramos una relacin de generalizacin entre dos actores o dos casos de uso, estamos indicando que el actor o el caso de uso hijos son un caso del actor o uso bsico y algo ms. En la figura 2-4, se muestra una relacin de generalizacin entre dos actores y dos casos de uso.

Figura 2-3 El caso de uso Crear lista de trabajos depende de que el patrn obtenga acceso.

Crear lista de trabajos Entrar

Patrn

02 KIMMEL.indd 22 11/4/07 7:00:52 PM

www.FreeLibros.me


En las relaciones de generalizacin, la flecha apunta hacia la cosa sobre la cual nos estamos expandiendo. Existen varias maneras en las que usted puede describir esta rela-cin en forma verbal acerca de la cual usted debe saber, pero desafortunadamente, todos estos sinnimos pueden conducir a confusin verbal. Los siguientes enunciados describen las relaciones de generalizacin que se muestran en la figura 2-4:

El usuario es el objetivo y el patrn es la fuente.

El patrn es un usuario.

El usuario es el subtipo y el patrn es el supertipo.

El patrn se hereda del usuario.

El usuario es el tipo padre y el patrn es el tipo hijo.

El patrn generaliza al usuario.

(En esta lista, puede sustituir la frase Crear lista de trabajos en todas partes en donde vea la palabra Usuario, y sustituir la frase Crear lista de trabajos por prioridades en todas las partes en donde vea la palabra Patrn, para transmitir la relacin entre los dos casos de uso.) El ltimo enunciado, en el cual se usa la palabra generaliza, es el ms exacto en el contexto del uml, pero vale la pena reconocer que todos los enunciados son equivalentes.

Figura 2-4 Diagrama de casos de uso en el que se muestran dos relaciones de generalizacin entre dos actores y entre dos casos de uso.

Usuario

Patrn

Crear lista de trabajos

Crear lista de trabajos por prio-

ridades

02 KIMMEL.indd 23 11/4/07 7:00:52 PM

www.FreeLibros.me

Manual de UML 24

Adornos de los conectoresLos diagramas uml fomentan el uso de menos texto porque las imgenes transmiten una gran cantidad de informacin a travs de una conveniente taquigrafa visual, pero los diagramas uml no se abstienen por completo del texto; por ejemplo, los conectores pue-den incluir texto que indique multiplicidad de los puntos extremos y texto que estereotipa el conector.

Manera de mostrar la multiplicidad

En general, los conectores pueden tener notaciones de multiplicidad en cualquiera de sus dos extremos. Las notaciones de multiplicidad indican el conteo posible de cada cosa. Por ejemplo, un asterisco significa muchos; un asterisco prximo a un actor significa que puede haber muchos ejemplos de ese actor. Aun cuando el uml permite hacer ano-taciones de esta manera en los conectores de caso de uso, eso no es muy comn. Es ms probable que usted vea estas marcas de notacin de conteo en diagramas del tipo de los de clase, de modo que dar detalles sobre la multiplicidad en el captulo 3.

Estereotipado de los conectores

Una notacin ms comn en los conectores es el estereotipo. Los estereotipos agregan detalles a la relacin entre los elementos en un diagrama de caso de uso. Por ejemplo, en la figura 2-3, introduje el conector de dependencia. Se puede usar un estereotipo para ampliar el significado de este conector.

En la seccin titulada Estilos de lneas para los conectores, dije que un patrn puede crear una lista de trabajos e ilustr esto con un actor patrn, un caso de uso Crear lista de trabajos y un conector de asociacin; sin embargo, tambin dije que el patrn debe obtener acceso. Cuando un caso de uso Crear lista de trabajos necesita los servi-cios de otro caso de uso Entrar entonces se dice que el caso de uso dependiente incluye el caso de uso del que depende. (En cdigo, una relacin incluir se implementa como reutilizacin de cdigo.)

Un estereotipo se muestra como texto entre los caracteres y (comillas angulares). Por ejemplo, si decimos que Crear lista de trabajos incluye a Entrar, entonces pode-mos representar un estereotipo incluir colocando una anotacin en el conector de depen-dencia como se muestra en la figura 2-5.

Figura 2-5 Ejemplo de un estereotipo incluir usado para representar reutilizar en la depen-dencia entre Crear lista de trabajos y Entrar.

EntrarCrear lista de trabajos

Patrn

incluir

02 KIMMEL.indd 24 11/4/07 7:00:52 PM

www.FreeLibros.me


Incluir y extender son conceptos importantes en los diagramas de caso de uso, de modo que enseguida ampliar lo relativo a estos temas.

NOTA Estereotipo es un concepto generalmente til en el UML. La razn de esto es que es permisible que usted introduzca y dena sus propios estereotipos. De esta manera, puede extender el UML.

Caso de uso de inclusin y de extensin

Una relacin de dependencia entre dos casos de uso significa que, de alguna manera, el caso dependiente necesita al caso del que depende. Dos estereotipos de uso comn y predefinidos que refinan las dependencias en los casos de uso son el incluir y el extender. Tomemos un minuto para ampliar nuestros comentarios de introduccin sobre incluir, de la seccin anterior, e introduzcamos extender.

SUGERENCIA Visio aplica un estereotipo extender en el conector de generalizacin para dar a entender herencia. Existen variaciones entre el UML y las herramientas del mismo, porque el UML es un estndar en evolucin y la implementacin de las herramientas puede ir adelante o atrs de la denicin ocial del UML.

Ms sobre los estereotipos incluirUna dependencia rotulada con el estereotipo incluir significa que, finalmente, el caso de uso dependiente es para volver a usar el caso del que depende. El equipaje que va con el estereotipo incluir es que el caso de uso dependiente necesitar los servicios del caso del que depende y saber algo acerca de la realizacin de sta, pero lo opuesto no es cierto. El caso de uso del que se depende es una entidad completa y distinta que no debe de-pender del caso dependiente. La concesin de acceso es un buen ejemplo. Resulta claro que requerimos que un patrn tenga acceso para crear una lista de trabajos, pero tambin pudimos obtener acceso por otras razones.

NOTA En una dependencia incluir entre casos de uso, el caso dependiente tambin se conoce como el caso de uso bsico, y aquella de la que se depende tambin se conoce como el caso de uso de inclusin. Aunque bsico y de inclusin pueden ser trminos ms precisos, no parece que se empleen de manera comn al hablar.

Poner tanto significado en una pequea palabra como incluir es la razn por la cual el uml puede transmitir una gran cantidad de significado en un diagrama sencillo, pero tambin es la razn por la cual los modelos uml pueden representar un reto para crearse y leerse. Una estrategia real a la que puede recurrir es agregar una nota en donde no est

02 KIMMEL.indd 25 11/4/07 7:00:53 PM

www.FreeLibros.me

Manual de UML 26

seguro acerca del uso de algn aspecto idiomtico del uml (vea, ms adelante, Anota-ciones en los diagramas de caso de uso). Por ejemplo, si quiere describir la relacin entre Crear lista de trabajos y Entrar, pero no est seguro acerca de cul conector o cul estereotipo usar, entonces podra usar una asociacin simple y una nota asociada al conector que describa en texto llano lo que usted quiere dar a entender. La nota puede actuar como un recordatorio para, ms adelante, regresar y buscar el uml preciso.

Uso de los estereotipos extenderEl estereotipo extender se usa para agregar ms detalle a una dependencia, lo cual signi-fica que estamos agregando ms capacidades (como ejemplo, vea la figura 2-6). Como se muestra en la figura, decimos que Registrar las listas vistas extiende (y depende de) Ver lista.

NOTA En una relacin extendida, la echa apunta hacia el caso de uso bsico y el otro extremo se conoce como el caso de uso de extensin.

En la seccin anterior, no permitiramos que un patrn creara una lista de trabajos sin registrarse, pero en el caso del registro del caso de uso entrar es indiferente para la reutilizacin del caso. En esta seccin, a el caso de uso ver lista no le importa que la es-tn registrando; en otras palabras, la caracterstica registrar necesitar saber acerca de la caracterstica ver lista, pero no en sentido contrario.

Una perspectiva valiosa aqu es quin podra estar interesado en el registro. Es eviden-te que al Solicitante de trabajo tal vez no le interese cuntas veces se ha visto la lista, pero un patrn previsor podra estar interesado en cunto trfico est generando su lista. Pasemos ahora por un momento a un dominio diferente. Suponga que el Solicitante de trabajo fuera el comprador de una casa y que la lista lo fuera de residencias. Ahora tanto el comprador como el vendedor podran estar interesados en el nmero de veces que se ha visto la propiedad. Una casa que ha estado en el mercado durante meses puede tener

Figura 2-6 Seguir el rastro del nmero de veces que se ve una lista de trabajos es una extensin de Ver lista, como se describe mediante la dependencia y el estereotipo extender.

Registrar las listas vistas

Ver lista

Solicitante de trabajo

extender

02 KIMMEL.indd 26 11/4/07 7:00:53 PM

www.FreeLibros.me


problemas. Sin embargo, en los dos escenarios, la lista es lo ms importante y el nmero de veces que se ha visto es secundario. Esto ilustra la nocin de caso de uso de extensin como parecidas a las caractersticas y, desde una perspectiva de mercadeo, las extensiones podran ser elementos que estn separados en un paquete opcional de caractersticas.

SUGERENCIA Considere la alternativa, ya que se relaciona con un caso de uso de ex-tensin. Los casos de uso de extensin son caractersticas secundarias naturales. Si su proyecto tiene un programa apretado, lleve hasta el nal los casos de uso de extensin, y, si su tiempo se agota, entonces posponga los casos de uso de extensin para una ver-sin posterior.

Incluir y extender parecen algo semejantes, pero la mejor manera de tenerlos en orden es recordar que la relacin incluir es para volver a aplicar el comportamiento modelado por otro caso de uso, en tanto que la relacin extender es para agregar partes a caso de uso existentes as como para modelar servicios opcionales del sistema (vergaard y Palmkvist, 2005, p. 79).

Anotaciones en los diagramas de casos de usoConsidere el trabajo de un estengrafo en un juicio. Los estengrafos usan esas graciosas mquinas estenogrficas de escribir que producen una suerte de majaderas taquigrficas. Podemos suponer con seguridad que si una mquina de escribir comn o un procesador de palabras pudiera aceptar una entrada suficientemente rpida como para mantenerse al ritmo del habla natural, entonces el estengrafo nunca se hubiera inventado.

Los estengrafos producen una taquigrafa que es ms condensada que el discurso al hablar. El uml es como la taquigrafa para el cdigo y el texto, y las herramientas de mo-delado del uml son semejantes a los estengrafos. La idea es que los modelos se puedan crear ms rpido que el cdigo o ms rpido que escribir descripciones en forma de texto. Dicho eso, a veces no hay un buen sustituto para el texto.

Si se encuentra en el predicamento de que slo el texto parece resolver o no est seguro del uml, entonces siga adelante y agregue texto. Puede agregar texto mediante la documentacin de sus modelos con caractersticas de la mayora de las herramientas de modelado, agregando referencias url a los documentos ms verbosos o agregando notas directamente en los propios diagramas. Sin embargo, si agrega demasiado texto, entonces de manera natural, tardar ms en completar el modelado y puede ser que se requiera un esfuerzo mayor para entender el significado de cada uno de los diagramas.

Insercin de notasEl uml es una taquigrafa para una gran cantidad de texto y de cdigo, pero si lo necesita, siempre puede agregar texto. Todos los diagramas, incluyendo los casos de uso, permi-

02 KIMMEL.indd 27 11/4/07 7:00:53 PM

www.FreeLibros.me

Manual de UML 28

ten que se les agreguen anotaciones en forma de texto. Las notas se representan como un trozo de papel con una punta doblada y una lnea que une el cuadro de texto al elemento que se le est haciendo la anotacin (figura 2-7). Use las notas con moderacin, porque pueden abarrotar un diagrama y hacerlo difcil de leer.

Modo de agregar documentacin de soporteTodas las herramientas de modelado que he usado Together, Rose, Rose xde, Visio, Poseidon para uml y la de Cayenne Software permiten la documentacin del modelo. Por lo comn, esta documentacin toma dos formas: texto que se almacena en el modelo y Uniform Resource Locators (url, localizadores uniformes de recursos), que hacen referencia a documentos externos (figura 2-8). El examen de las caractersticas de su herramienta particular le descubrir estas capacidades.

Ms importante es qu tipo de documentacin debe usted proporcionar. De manera subjetiva, la respuesta es tan pequea como aquella con la que pueda ponerse en marcha, pero en general, los diagramas de caso de uso parecen necesitar lo mximo.

Los diagramas de caso de uso son bastante bsicos con sus figuras de lnea, pero son bastante importantes porque registran las capacidades que tendr el sistema de usted. Una buena informacin a incluir con sus diagramas de caso de uso es

Un prrafo conciso en el que se describa cmo empieza el uso, incluyendo cuales-quiera condiciones previas

Un prrafo corto para cada una de las funciones primarias

Un prrafo corto para cada una de las funciones secundarias

Un prrafo corto para cada uno de los escenarios primarios y secundarios, los cua-les ayuden a ubicar en un contexto la necesidad de las funciones

Ver lista es parte de un caso de uso ms grande, Hallar trabajo, pero se encuentra aqu para ilustrar que estamos

registrando las listas vistas.

Ver lista

Registrar las listas vistas

Solicitante de trabajo

Figura 2-7 Nota que agrega texto llano para aclarar algn aspecto de un diagrama.

extender

02 KIMMEL.indd 28 11/4/07 7:00:53 PM

www.FreeLibros.me


Un prrafo para las necesidades no funcionales

Puntos de insercin en donde se usen cualesquiera otros casos de uso dependientes

Un punto de nalizacin con las condiciones posteriores

Todos estos elementos suenan como una gran cantidad de trabajo, y pueden serlo. Sin embargo, recuerde que los casos de uso son los fundamentos del anlisis, y es importante que las documente tan cuidadosa y completamente como pueda. De igual importancia es notar que us las palabras conciso y corto de manera intencional. Por corto, quiero dar a entender que es aceptable tener prrafos de una sola oracin.

Puede usar cualquier formato que le guste para documentar sus casos de uso. Si se siente cmodo con el formato de borrador, es muy fcil crear un borrador modelo con base en la lista con vietas que acabo de dar. Una buena prctica es elegir un estilo para su documentacin y adherirse a l.

Tomemos un momento para explicar en detalle los elementos segn se describen en la anterior lista con vietas de la documentacin del caso de uso. Tenga presente que esto no es una ciencia exacta y que su documentacin de los casos de uso no necesita ser perfecta.

Documentacin de un caso de uso utilizando un borradorPuede usar texto de forma libre para documentar un caso de uso, pero encuentro que un modelo de borrador sugiere la extensin de la informacin y acta como un recordatorio de los elementos necesarios para documentar cada caso en forma adecuada. A continua-

Figura 2-8 Mediante un doble clic sobre un elemento de modelo en Visio, puede aadir docu-mentacin que est agregada en el modelo.

02 KIMMEL.indd 29 11/4/07 7:00:54 PM

www.FreeLibros.me

Manual de UML 30

cin se presenta un modelo que incluye una breve descripcin y un ejemplo para cada seccin. Vale la pena hacer notar que este estilo de documentacin no es parte del uml, pero es un elemento til del modelado.

1. Ttulo

a. Descripcin: Use aqu el nombre del caso de uso, pues facilita mucho el acopla-miento de los diagramas de caso de uso con su documentacin respectiva.

b. Ejemplo: Mantener lista de trabajos.

2. Inicios del caso de uso

a. Descripcin: Describa con brevedad las circunstancias que llevan al caso de uso, incluyendo las condiciones previas. Deje fuera los detalles de la implemen-tacin, como El usuario hace clic en un hipervnculo, o las referencias a las formas, los controles o los detalles especcos de la implementacin.

b. Ejemplo: Este caso de uso se inicia cuando un patrn, un agente de un patrn o el sistema quiere crear, modicar o eliminar una lista de trabajos.

3. Funciones primarias

a. Descripcin: Los casos de uso no son necesariamente singulares. Por ejemplo, Administrar la lista de trabajos es un caso de uso razonable y puede incluir funciones primarias como leer un recipiente o escribir en l. La clave aqu es evitar demasiado pocas o demasiadas funciones primarias. Si necesita una bue-na medida, podran ser dos o tres funciones primarias por caso de uso.

b. Ejemplo: CLAB la lista de trabajos. Las funciones primarias de Mantener la lista de trabajos son crear, leer, actualizar y borrar la lista de trabajos.

4. Funciones secundarias

a. Descripcin: Las funciones secundarias son como un reparto de apoyo en una pieza teatral. Por ejemplo, dado un caso de uso Administrar la lista de traba-jos, actualizar, insertar, crear y borrar una lista de trabajos llamado CLAB por crear, leer, actualizar y borrar son excelentes funciones secundarias, parte de un caso de uso ms grande. Si necesita una medida, entonces el doble de funcio-nes secundarias que de primarias es bueno.

b. Ejemplos:

1) Hacer caducar la lista de trabajos. Treinta das despus de que la lista de trabajos se pone a disposicin para ser vista, se dice que caduca. Una lista que ha caducado no se borra, pero es posible que los usuarios, con excepcin del propietario de la lista, ya no puedan verla.

2) Renovar la lista de trabajos. Se puede extender una lista por 30 das adicio-nales mediante el pago de una tarifa adicional.

02 KIMMEL.indd 30 11/4/07 7:00:54 PM

www.FreeLibros.me


3) Hacer que una lista de trabajos sea prioritaria. En cualquier momento, du-rante la vida de una lista, su propietario puede elegir promoverla hacia lista prioritaria, mediante el pago de una tarifa prorrateada por la parte consumida del periodo de la misma.

4) Registrar las listas vistas. Cada vez que se ve una lista, se escribir una entrada de registro, haciendo constar la fecha y la hora en que se vio la lista y el protocolo de Internet (ip) del visitante.

5) Examinar registros de las veces que se ha visto la lista. En cualquier mo-mento, el propietario puede ver la informacin registrada en relacin con sus listas.

6) Notificacin automtica de los registros de la vista de la lista. El propie-tario de una lista de trabajos puede elegir que se le enven por correo elec-trnico los registros de las vistas de esa lista, con un intervalo especificado por l.

7) Pagar por la lista. Se pide al propietario que pague por cada lista, a menos que sta se ofrezca como un premio de promocin.

5. Escenarios primarios

a. Descripcin y ejemplo: Un escenario es un relato corto que describe las fun-ciones en un contexto. Por ejemplo, dada una funcin primaria Crear lista de trabajos, podramos escribir un escenario como ste: La secretaria del Sr. Gar-ca est por jubilarse, y l necesita contratar a alguien que la reemplace. Al Sr. Garca le gustara una secretaria que mecanografe 100 palabras por minuto, quiera trabajar slo cuatro horas al da y cobrar 10 dlares por hora. Necesita que la secretaria de reemplazo empiece a trabajar no despus del 15 de enero. Considere por lo menos tantos escenarios primarios como funciones primarias tenga. Tambin considere un par de variaciones del escenario para las funciones importantes. Esto ayudar a que piense acerca de su problema en formas creati-vas. Hacer una lista de los escenarios en aproximadamente el mismo orden que el de las funciones que describe el escenario es una prctica til.

6. Escenarios secundarios

a. Descripcin y ejemplo: Los escenarios secundarios son relatos cortos que ponen a las funciones secundarias en un contexto. Considere un escenario secundario al que nos referiremos como Hacer caducar lista de trabajos. Demostrado como un escenario, podramos escribir: El Sr. Garca pag para que la lista se publicara durante 30 das. Despus de 30 das, la lista de trabajos se retirar y se noticar al Sr. Garca por correo electrnico, dndole oportunidad de reno-varla. Podemos organizar los escenarios secundarios en un orden coherente con las funciones secundarias que apoyan.

02 KIMMEL.indd 31 11/4/07 7:00:54 PM

www.FreeLibros.me

Manual de UML 32

7. Necesidades no funcionales

a. Descripcin: Las necesidades no funcionales se encargan de com-portamientos implcitos, como con qu rapidez sucede algo o cuntos datos se pueden transmitir.

b. Ejemplo: Debe procesarse el pago de un patrn en un periodo no mayor a 60 segundos, en tanto que l o ella, espera.

8. Finalizaciones de los casos de uso

a. Descripcin: En esta parte se describe lo que signica haber na-lizado para el caso de uso.

b. Ejemplo: El caso de uso ha nalizado cuando los cambios hechos en la lista de trabajos se han mantenido y se ha hecho el pago.

Cunta informacin incluya en la parte escrita de sus casos de uso en realidad es decisin de usted. El uml guarda silencio acerca de este asunto, pero un proceso como el rup le pue-de ofrecer alguna gua sobre el contenido, cantidad y estilo de la documentacin en texto.

Como nota final, resulta til registrar ideas acerca de las funciones y escenarios, inclu-so si finalmente elige descartarlos. Por ejemplo, podramos agregar una funcin secun-daria que exprese que El sistema permitir una renovacin semiautomtica de una lista de trabajos que estn caducando, apoyada por el escenario La lista del Sr. Garca para contratar una nueva secretaria est prxima a caducar. Se notifica por correo electrnico al Sr. Garca que su lista est prxima a caducar. Al hacer clic sobre un vnculo en el co-rreo, la lista del Sr. Garca se renueva en forma automtica usando la misma facturacin e informacin de pago usadas con la lista original.

Al registrar y conservar las ideas consideradas, es posible hacer un registro de las ideas que se consideraron, pero puede ser que se lleven a cabo o que jams se haga. Conservar un registro de las posibilidades impide que usted repita una y otra vez las ideas conforme los miembros del equipo vienen y se van.

Por ltimo, resulta til insertar referencias a los casos de uso del que se depende. En lu-gar de, por ejemplo, repetir un caso de uso de inclusin, sencillamente haga una referencia a ese caso en el punto en que se necesite. Por ejemplo, suponga que pagar por una lista de trabajos requiere que un patrn tenga acceso; en lugar de repetir el caso de uso Entrar, sencillamente hacemos una referencia a ella en donde se necesite; en este caso, podemos hacer una referencia a Entrar cuando hablemos acerca de pagar por la lista de trabajos.

Creacin de los diagramas de casos de usoComo mencion al principio, los casos de uso son listas de diseos por hacer. Ya que un da feriado siempre est precisamente a la vuelta de la esquina, una buena analoga

02 KIMMEL.indd 32 11/4/07 7:00:54 PM

www.FreeLibros.me


comparativa es que definir casos de uso es como escribir una lista de tareas en orden para preparar su casa para una gran visita de parientes. Por ejemplo, podra escribir Desem-polvar la sala. Entonces decide que su hija de 10 aos hizo un buen trabajo la ltima vez, de modo que le pide a ella que desempolve. En este caso, el nivel de detalle es importante, porque sabe si alguna vez ha desempolvado que diferentes tipos de cosas necesitan diferentes tipos de desempolvado: las chucheras pequeas se pueden desempolvar con un plumero; las mesas para servir caf y las de los extremos podran necesitar Pledge y un pao limpio y seco, y los ventiladores del techo podran necesitar la varita y el cepillo de una aspiradora. La clave en este caso es la diferencia entre lo que describimos con un diagrama y lo que escribimos como parte de nuestro caso de uso.

NOTA Podra preguntarse qu tiene que ver desempolvar con los casos de uso y el software. La primera respuesta es que se pueden usar los modelos de caso de uso para cosas que no son software, y la segunda parte es que el software se encuentra en un nmero cada vez mayor de aparatos. Suponga que estbamos deniendo casos de uso para un robot que limpia casas; entonces nuestras reglas para desempolvar podran ser tiles. Y si se est preguntando cun probable podra ser el software para robots, entonces considere la aspiradora Roomba, un pequeo robot que vaga por un cuarto aspirando los desperdicios y, segn su material de mercadeo, incluso sabe cundo re-cargarse. Alguien tuvo que denir e implementar esas capacidades.

El caso de uso para desempolvar del prrafo anterior constara de un actor, Nia, un conector de asociacin y un caso de uso Desempolvar la sala (figura 2-9). No hace falta que el propio diagrama de casos de uso describa todas las microtareas necesarias de las que consta Desempolvar la sala. Por ejemplo, Encontrar Pledge y un pao limpio y seco es una subtarea necesaria, pero en realidad, no es un caso de uso en y por s misma. Los casos de uso buenos significan tener que hallar buenos actores y el nivel correcto de detalle, sin hacer confusos los diagramas.

Despus de que tenemos el diagrama de caso de uso, podemos agregar informacin de soporte de la documentacin del modelo para nuestro caso de uso. Las funciones primarias incluiran desempolvar las reas clave, y las funciones secundarias incluiran la preparacin, como hacerse de la aspiradora y hallar el Pledge. Los escenarios adecua-

Figura 2-9 Caso de uso para un actor nia y desempolvar una sala.

Desempolvar la sala

Nia

02 KIMMEL.indd 33 11/4/07 7:00:54 PM

www.FreeLibros.me

Manual de UML 34

dos incluiran el manejo de reas problemas especficas, como desempolvar los marcos de los cuadros y artculos de coleccin. Los requisitos no funcionales podran incluir Terminar de desempolvar antes de que lleguen los abuelos. No se preocupe acerca de lograr diagramas perfectos ni de la documentacin del caso de uso; use el borrador para ayudarse a considerar los detalles y los diagramas de caso de uso para obtener una buena imagen de sus objetivos.

Cuntos diagramas son sucientes?La suficiencia es un problema difcil. Si proporciona demasiados casos de uso, su mo-delado puede continuar durante meses o incluso aos. Tambin puede adentrarse en el mismo problema con la documentacin de los casos de uso.

NOTA Fui consultor en un proyecto para un departamento grande de la agencia de defensa. Literalmente, la agencia haba estado trabajando sobre casos de uso por casi dos aos sin tener el n a la vista. Aparte de que me pareci un proyecto interminable, los expertos del domini

Documents

Manual de UML - Paul Kimmel