Manual de UML - Paul Kimmel.pdf

5/21/2018 Manual de UML - Paul Kimmel.pdf

1/257

www.FreeLibros.me


2/257

MANUAL DE UM

www.FreeLibros.me


3/257

www.FreeLibros.me


4/257

MANUAL DE UM

PAUL KIMMEL

MXICO BOGOT BUENOS AIRES CARACAS GUATEMALALISBOA MADRID NUEVA YORK SAN JUAN SANTIAGO

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

Traduccin

Jos Hernn Prez CastellanosTraductor profesional

www.FreeLibros.me


5/257

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 Obregn

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

Supervisor de produccin: Jacqueline Brieo lvarezDiagramacin:By Color Soluciones Grficas

MANUAL DE UML

www.FreeLibros.me


6/257

A la memoria de mi hermana Jennifer Anne

a quien slo se le concedieron 35 aos.

www.FreeLibros.me


7/257

ACERCA DEL AUTOR

Paul Kimmel es arquitecto en jefe y uno de los fundadores de Software Concetions, Inc. Ha estado diseando e implementando software orientado a objet

desde 1990, tiene ms de 12 aos de experiencia con los lenguajes de modelady fue uno de los primeros en adoptar el Unified Modeling Language. Paul ha aydado a disear e implementar soluciones con el uso del umlpara algunas de lms grandes corporaciones del mundo, desde bancos internacionales, empresmultinacionales de telecomunicaciones, empresas de logstica y embarque, ocinas del Departamento de Defensa hasta grupos gubernamentales, nacionalesinternacionales.

www.FreeLibros.me


8/257

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 finalizacin 185

CAPTULO 10 Visualizacin de su topologa de despliegue 197

APNDICE A Examen final 209

Bibliografa seleccionada 225

ndice 227

www.FreeLibros.me


9/257

www.FreeLibros.me


10/257

ix

CONTENIDO

Reconocimientos xv

Introduccin xvii

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

Comprensin de los modelos 2

Comprensin del UML 3

La evolucin del diseo de software 3

Si nadie est modelando, por qu debehacerlo 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 final 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


11/257

Manual de Ux

Contraste de los lenguajes de modelado con el proceso

Examen

Respuestas

CAPTULO 2 El principio con casos de uso 1

Cmo hacer el caso para los casos de uso

Establecimiento de prioridad de las capacidades

Comunicacin con los no tecnfilos

Uso de los smbolos de los casos de uso

Smbolos de actores

Casos de uso

Conectores

Casos de uso de inclusin y de extensin

Anotaciones en los diagramas de casos de uso

Creacin de los diagramas de casos de uso

Cuntos diagramas son suficientes?

Ejemplos de diagramas de casos de uso

Diseo controlado con casos de uso 4Examen

Respuestas 4

CAPTULO 3 Diagramacin de caractersticas como procesos 4

Elaboracin de las caractersticas como procesos 4

Un viaje hacia el cdigo 4

Comprensin de los usos de los diagramasde actividades 4

Uso de lo smbolos de los diagramas de actividades

Nodo inicial

Flujo de control

Acciones

www.FreeLibros.me


12/257

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

Configuracin de los parmetros de entrada 70

Forma de mostrar las excepciones en losdiagramas 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


13/257

Manual de Uxii

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

Elementos de los diagramas bsicos de clase 10Comprensin de las clases y los objetos 10

Modelado de relaciones en los diagramas de clases 11

Estereotipado de las clases 11

Uso de paquetes 11

Uso de notas y comentarios 11

Restricciones 11

Modelado de primitivos 12

Modelado de enumeraciones 12

Indicacin de espacios de nombres 12

Cmo saber qu clases necesita 12

Uso de un enfoque ingenuo 12

Descubra otros beneficios del anlisis de dominios 12

Examen 12

Respuestas 13

CAPTULO 6 Cmo se relacionan las clases 13

Modelado de la herencia 13

Uso de la herencia simple 13

Uso de la herencia mltiple 13

Modelado de la herencia de interfaces 13

Boceto de diagrama 13

Uso de la realizacin 14

Descripcin de la agregacin y la composicin 14

Asociaciones y las clases asociaciones 14

Examen de las relaciones de dependencia 15

Adicin de detalles a las clases 15

www.FreeLibros.me


14/257

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

Especificacin de las interfaces proporcionadasy requeridas 179

Examen de los estilos de modelado de componentes 180

Trazado de los diagramas de componentespara consumidores 180

Trazado de los diagramas de componentespara productores 182

Examen 183

Respuestas 184

CAPTULO 9 Ajuste y finalizacin 185

Modelado de los hacer y los no hacer 186

No tenga esperando a los programadores 187

CONTENIDO

www.FreeLibros.me


15/257

Manual de Uxiv

Trabaje de una macrovista hacia una microvista 1

Documente en forma econmica 1

Encuentre un editor 1

Sea selectivo acerca de los diagramasque elige crear 1

No dependa de la generacin del cdigo 1

Modele y estructure disminuyendo el riesgo 1

Si es obvio, no lo modele 1

Haga hincapi en la especializacin 1

Uso de patrones de estado conocidos 1Refactorizacin de su modelo 1

Modo de agregar documentacin de soporte 1

Validacin de su modelo 1

Examen 1

Respuestas 1

CAPTULO 10 Visualizacin de su topologa de despliegue 19

Modelado de nodos 1

Manera de mostrar artefactos en nodos 2

Adicin de trayectorias de comunicacin 2

Examen 2

Respuestas 2

APNDICE A Examen final 20

Respuestas 2

Bibliografa seleccionada 22

ndice 22

www.FreeLibros.me


16/257

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 lectorencontrar como un libro informativo, entretenido y fcil de seguir sobre el UnifiedModeling 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. Ericrealiz un trabajo excelente al hallar mis equivocaciones y omisiones, as como almejorar las explicaciones.

Doy las gracias a mis anfitriones en el Ministry of Transportation Ontario, de St.Catharines, Ontario; colaborar con ustedes en el CIMS fue un proceso agradable yel examen de mis modelos y diseos con ustedes proporcion una excelente basepara 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 aprenderde 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 elbello campus de la Michigan State University. Gracias a la MSU por permitir el usode 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


17/257

Por ltimo, pero no porque sean los menos importantes, tengo una deuda gratitud con mi esposa Lori y mis cuatro hijos, Trevor, Douglas, Alex y Noah, q

representan el papel de mis ms importantes admiradores y partidarios. Una famies la ms grande de las bendiciones. (Tambin me gustara presentar al miembms reciente de nuestra familia, Leda, un eficiente laboratorio de chocolate, quiespera con paciencia a mis pies como un sutil recuerdo para empujarme de regrea la computadora e ir a hacer algo ms una que otra vez.)

www.FreeLibros.me


18/257

xvii

A menudo, los nuevos inventos nacen sin necesidad y se documentan sobre serville-tas mucho antes, si acaso, de que se proporcione una definicin autorizada y formal.

El Unified Modeling Language (uml) es precisamente uno de esos ejemplos. Losaspectos individuales de lo que al final se convirti en el umllos definieron IvarJacobson, James Rumbaugh y Grady Booch, sin necesidad, mucho antes de que suscolaboraciones individuales se consolidaran en una sola definicin.

Existe un problema mixto con las especificaciones formales y estndar. En gene-ral, para que un cuerpo augusto de cientficos ratifique algo debe estar definido sinambigedad y con rigor. Si busca la definicin del uml, encontrar metamodelosque describen hasta el ms mnimo detalle lo que es y lo que no es. El efecto esmuy semejante a leer informes del congreso: extensos, ridos, tediosos y con unpoquito de jugo ocasional. Piense en las definiciones formales, en comparacincon las aplicaciones prcticas, como esto: existen reglas rigurosas especficas que

definen algo tan sencillo como el lgebra, pero usted no necesita conocerlas, auncuando realizamos lgebra sencilla o nos apoyamos en ella en tareas cotidianas,como bombear gasolina. Por ejemplo, precio por litro multiplicado por el nmerode litros = precio total. Con una simple sustitucin de texto por carcter, podemoscrear ecuaciones aritmticas, p * g = t, que empiezan por parecerse a esas confusasecuaciones de la escuela, pero que las hacen convenientes, desde el punto de vistarotacional, para determinar cualquier cantidad de ella. Lo que quiero decir es queincluso las personas que se identificaran como desafiadas por las matemticas lasaplican todos los das para fines prcticos, sin siquiera pensar que lo que estn ha-ciendo es resolver problemas matemticos.

se es el objetivo de este libro. Hay definiciones formales y rigurosas del umly

existen por buenas razones, pero usted no necesita conocerlas para usar este lengua-je de una manera prctica. Los lingistas del umldeben conocerlo en lo ms ntimo,para definir con rigor, precisamente como los profesores de un idioma conocen la

INTRODUCCIN

www.FreeLibros.me


19/257

Manual de Uxviii

gramtica hasta lo ms profundo para poder ensearlo, pero usted no necesita sun profesor de su idioma para comunicarse con eficacia. Esto es verdad tambi

para eluml

; no necesita conocer todos los detalles acerca de l para usarlo ceficacia.umlDesMitificadoest escrito de manera sencilla y est diseado para hacer q

este lenguaje sea prctico, as como una herramienta eficaz para comunicar anliy diseo de software.

Hay muchos libros sobre proceso, y el umlno define un proceso. Sin embargeste libro est organizado de tal manera que si usted crea los tipos de modelos sgn se necesita, en el orden en el que aparecen en l, entonces puede contar con inicio prctico de un proceso susceptible de usarse.

umlDesMitificadoes un libro de tamao modesto, pero es una recopilacin ms de una docena de aos de experiencia prctica trabajando con algunas de l

mayores y mejor conocidas empresas del mundo, as como con muchas bien concidas y no tan grandes empresas. El umldescrito en este libro es pragmtico, prtico y aplicable, ya sea que usted se encuentre estructurando aplicaciones pequemedianas o muy grandes. En pocas palabras, umlDesMitificadodeja la pelusa yrigor de torre de marfil a otros textos y le dice a usted lo que necesita saber para uscon xito el umlal describir software.

www.FreeLibros.me


20/257

1

CAPTULO

Las imgenes de pequeas personas formadas por palillos representan la fde comunicacin ms antigua registrada en la historia humana. Algo de esterupestre se remonta a pocas tan antiguas como hace 75,000 aos. Lo que rebastante extrao es que nos encontramos al principio del moderno siglo xxidava estamos usando pequeas figuras de lnea para transmitir informacines correcto; un pequeo hombre formado por palillos que llamamos Esaw carcter central en uno de los lenguajes ms recientes desarrollado por los hum(figura 1-1).

1

Una imagevale ms que milneas de cdig

1

www.FreeLibros.me


21/257

Manual de U2

El lenguaje acerca del cual estoy hablando se llama Unified Modeling Language(Leguaje unificado de modelado), o uml. El umles un lenguaje tanto como Pascal, C# sharp), el alemn, el ingls y el latn; y el umlposiblemente es uno de los lenguajes mrecientes inventados por la humanidad, alrededor de 1997.

Como sucede con otros lenguajes, el umlfue inventado por necesidad. Es ms, comcon muchos lenguajes, en el umlse usan smbolos para transmitir significado. Sin embgo, a diferencia de los lenguajes orgnicos, como el ingls y el alemn, que evolucioncon el transcurso del tiempo a partir del uso comn y la adaptacin, el umlfue inventapor cientficos, lo cual, por desgracia, es un problema. Los cientficos son muy integentes pero con frecuencia no son muy buenos para explicar las cosas a aquellos mencientficos. Aqu es en donde intervengo.

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

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

Los modelos son valiosos por muchas razones especficas; en gran parte, constan imgenes e, incluso, las imgenes simples pueden transmitir ms informacin que u

gran cantidad de texto; por ejemplo, cdigo. Esto resulta coherente con el viejo adagio tanto modificado de que una imagen expresa un millar de lneas de cdigo. Los modelson valiosos porque es ms fcil dibujar algunas imgenes sencillas que escribir cdio incluso texto que describan lo mismo. Los modelos son valiosos porque es ms bararpido y fcil cambiar modelos que cambiar cdigo. La verdad simple es que barato, rpido, fcil y flexible es lo que usted quiere cuando est resolviendo problemas.

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

Esaw

www.FreeLibros.me


22/257

CAPTULO 1 Una imagen vale ms que mil lneas de cdigo3

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 UEl umles una definicin oficial de un lenguaje pictrico con smbolos y relaciones co-munes que tienen un significado comn. Si todos los participantes hablan uml, entonceslas imgenes tienen el mismo significado para todos aquellos que las observen. Por lotanto, aprender umles esencial para ser capaz de usar imgenes para experimentar bara-ta, flexible 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 beneficios del modela-do es aprender el lenguaje del mismo.

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

Aunque, por qu el uml? Usted podra usar cualesquiera smbolos y reglas con el finde crear su propio lenguaje de modelado, pero el truco estara en hacer que otros tambinlo usaran. Si sus aspiraciones son inventar un mejor lenguaje de modelado, entonces nome corresponde detenerlo. Debe saber que el umlse considera un estndar y que lo que

este lenguaje es o no es lo define un consorcio de empresas que constituyen el ObjectManagement Group (omg, Grupo de Administracin de Objetos). La especificacin delumlest definida y ha sido publicada por el omgenwww.omg.org.

La evolucin del diseo de softwaSi siente que ha llegado tarde a la fiesta del uml, no se inquiete; en realidad, ha llegadotemprano. La verdad es que el umlha llegado tarde a la fiesta 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 umly el modelado apenas estn empezando aponerse de moda. Esto queda ejemplificado de la mejor manera en las propias palabras deBill Gates despus de su famosa semana de reflexin en 2004, en donde se informa quehabl acerca de la importancia creciente del anlisis y diseo formales (lase uml) en elfuturo. Este sentimiento lo apoya tambin la muy reciente compra de Visio, que incluyelas capacidades de modelado de uml, por parte de Microsoft.

www.FreeLibros.me
http://www.omg.org./http://www.omg.org./http://www.omg.org./http://www.omg.org./


23/257

Manual de U4

El umlrepresenta una formalizacin del anlisis y el diseo, y la formalizacin siempre parece llegar tarde. Considere los fabricantes de automviles del siglo pasado.

principio del siglo pasado, todos los fabricantes de coches en Flint, Michigan, estabconvirtiendo los carruajes ligeros tirados por un solo caballo en automviles. Esto ocrri mucho antes de que las grandes universidades, como la Michigan State Universi(msu), graduaran ingenieros mecnicos capacitados para construir automviles y herrmientas de software, como programas para diseo con ayuda de computadora (cad) qson especialmente buenos en el dibujo de artculos complejos, como las partes de los atomviles. La evolucin de la ingeniera formalizada de los automviles es consecuencon la evolucin de la ingeniera formalizada del software.

Hace alrededor de 5000 aos, los chinos crearon una de las primeras computadorael baco. Hace cerca de 150 aos, Charles Babbage invent una mquina mecnica clculo. En 1940, Alan Turing defini la mquina Turing de clculo, y Presper Ecke

y John Mauchly inventaron la Eniac. Despus de las mquinas de clculo, vinieron ltarjetas perforadas y el anlisis y diseo estructurados de Grace Hopper para apoyar desarrollo de Cobol. En la dcada de 1960, se invent Smalltalk, un lenguaje orientadoobjetos, y en 1986, Bjarne Stroustrop invent lo que ahora se conoce como C++. No fsino hasta alrededor de este mismo periodo la dcada de 1980 cuando hombres muinteligentes, como Ivar Jacobson, James Rumbaugh y Grady Booch, empezaron a defilos elementos del anlisis y diseo modernos de software, lo que ahora llamamos el um

A finales de la dcada de 1980 y principios de la de 1990, las guerras sobre la notcin del modelado estaban plenamente entabladas, con diferentes facciones apoyana Jacobson, Rumbaugh o Booch. Recuerde, no fue sino hasta 1980 cuando la persopromedio pudo comprar y poseer una computadora personal (pc), y hacer algo til c

ella. Jacobson, Rumbaugh y Booch, cada uno por su lado, usaron smbolos y reglas dferentes para crear sus modelos. Finalmente, Rumbaugh y Booch empezaron a colaboen relacin con los elementos de sus respectivos lenguajes de modelado, y Jacobson les uni en Rational Software.

A mediados de la dcada de 1990, se fusionaron los elementos de modelado de Rumbaugh [Object Modeling Technique (omt, tcnica de modelado de objetos)], Boo(mtodo de Booch) y Jacobson (Objectory and Use Cases, cajas objetos y de usos) Rumbaugh, Jacobson y Booch se les mencionaba como los tres amigos para formelproceso unificado de modelado. Poco tiempo despus, se eliminprocesode la espcificacin del modelado y naci el uml. Esto ocurri hace muy poco tiempo, apenas 1997. La especificacin uml2.0 se estabiliz en octubre de 2004. Es correcto, ahora s

estamos en la versin 2.Esto lleva a la pregunta: precisamente cuntas empresas estn usando el umly,

realidad, diseando software con modelos? La respuesta es todava muy pocas. Trabjo en toda Norteamrica y personalmente conozco ejecutivos en algunas empresas software con mucho xito, y cuando les pregunto si estructuran el software con uml,respuesta es, casi siempre, no.

www.FreeLibros.me


24/257


Si nadie est modelando, por qu debe hacerlo usted?

Una persona racional podra preguntar: por qu entonces, si Bill Gates est ganando milesde millones escribiendo software sin hacer un hincapi significativo 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 proporcionanlas 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 nacionesen 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 undesarrollador euroasitico de software esto permitir a las empresas intentar tener xitocon una frecuencia cinco veces mayor. Qu estn hallando estas empresas que estnllevando 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 enlugares alejados slo introduce problemas adicionales y tampoco es garanta de xito. Larespuesta real que se necesita consumir ms tiempo en el anlisis y el diseo del software,y esto significa modelos.

Modelado y el futuro del desarrollo de software

Un nfasis creciente en el anlisis y diseo formales no significa el fin del crecimiento dela industria del software; significa que los das del salvaje, salvaje oeste de las dcadasde 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 significa precisamenteahora es que los profesionales capacitados en uml tienen una oportunidad nica paracapitalizar este inters creciente en este lenguaje; tambin significa que, de manera gra-dual, menos proyectos fallarn, la calidad del software mejorar y se esperar que msingenieros en software aprendan el uml.

Herramientas para modela

Hasta hace muy poco, el modelado ha sido un cautivo en una torre de marfil rodeadapor una guarnicin impenetrable de cientficos armados con metamodelos y herramien-tas para modelar ridculamente caras. El costo de una licencia para una herramientapopular para modelar estaba en los miles de dlares, lo que signific que el profesionalpromedio deba gastar por una aplicacin para modelar tanto como lo que gast por todauna computadora. Esto es ridculo.

www.FreeLibros.me


25/257

Manual de U6

Las herramientas para modelar pueden ser muy tiles, pero es posible modelar sobtrozos de papel. Por fortuna, usted no necesita ir tan lejos. La ame o la odie, Microso

es muy buena para bajar el costo del software. Si tiene una copia de msdn, entonces tieuna herramienta casi gratuita para modelar: Visio. sta es una buena herramienta, capde producir de manera competente modelos umlde alta calidad, y no le destrozar presupuesto.1

Para mantenernos en el tema de este libro desmitificar uml, en lugar de hacsaltar la banca en Together o Rose, usaremos el Visio de precio adecuado. Si el lectquiere usar Rose xde, Together o algn otro producto, sea bienvenido para hacerlo, pedespus de leer este libro ver que puede usar Visio y crear modelos profesionalesahorrarse cientos o incluso miles de dlares.

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

Puede usar texto llano para describir un sistema, pero se puede transmitir ms informcin con imgenes. Podra seguir con ahnco la mxima de la eXtreme Programming (xprogramacin extrema) y codificar, volviendo a descomponer en factores conforme ava

ce, pero los detalles de las lneas de cdigo son mucho ms complejos que las imgeny los programadores se adhieren al cdigo pero no a las imgenes. (Yo no comprendpor completo la psicologa de esta adhesin al cdigo, pero en realidad existe. Slo trade criticar en forma constructiva el cdigo de alguien ms y observe cmo se deteriola conversacin con rapidez hasta llegar al insulto.) Esto significa que una vez que escribe el cdigo, es muy difcil obtener la aceptacin de su codificador o de un admnistrador para hacerle modificaciones, en especial si el cdigo se percibe para trabajInversamente, la gente trabajar con mucho gusto de manera informal con los modeloaceptar sugerencias.

Por ltimo, debido a que en los modelos se usan smbolos sencillos, ms personinteresadas pueden participar en el diseo del sistema. Muestre a un usuario final un ce

tenar de lneas de cdigo y escuchar el chillar de los grillos; muestre a ese usuario finun diagrama de actividades, y esa misma persona le dir si ha captado usted la esencia cmo se realiza correctamente esa tarea.

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

www.FreeLibros.me


26/257


Creacin de diagramLa 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 nadieleer. 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 ola diversidad de diagramas que necesitamos crear y no indica cunto detalle necesitamosagregar a esos diagramas.

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

Revisin de los tipos de diagramasExisten varios tipos de diagramas que usted puede crear. Revisar con rapidez los tiposde diagramas que puede crear y los tipos de informacin que se pretende transmitir concada uno de estos diagramas.

Diagramas de casos de usoLos diagramas de casos de usoson 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 casode uso (figura 1-2).

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

Diagramas de actividadesUn diagrama de actividadeses la versin umlde un diagrama de flujo. Los diagramasde actividades se usan para analizar los procesos y, si es necesario, volver a realizar laingeniera de los procesos (figura 1-3).

Figura 1-2 El caso de uso Hallar alimento.

Hallar alimento

www.FreeLibros.me


27/257

Manual de U8

Un diagrama de actividades es una herramienta excelente para analizar problemas qual final, el sistema deber resolver. Como una herramienta de anlisis, no queremos empezar resolviendo el problema en un nivel tcnico mediante la asignacin de clases, pepodemos usar los diagramas de actividades para entender el problema e incluso refinlos procesos que comprenden el problema.

Diagramas de clasesLos diagramas de clasesse usan para mostrar las clases de un sistema y las relacionentre ellas (figura 1-4). Una sola clase puede mostrarse en ms de un diagrama de clasy no es necesario mostrar todas las clases en un solo diagrama monoltico de clases. mayor valor es mostrar las clases y sus relaciones desde varias perspectivas, de una mnera 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 campara hallar alimento.

Salir dela cueva

Vagar

Buscaralimento

Evitar losdepredadores

(Necesitar msalimento)

Regresara la cueva

www.FreeLibros.me


28/257


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

Diagramas de interaccinExisten dos tipos de diagramas de interaccin: la secuenciay la colaboracin. Ambostransmiten la misma informacin, empleando una perspectiva un poco diferente. Losdiagramas de secuencia muestran las clases a lo largo de la parte superior y los mensajesenviados entre esas clases, modelando un solo flujo 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 figura 1-5 muestra un ejemplo sencillo de diagramade secuencia, y la 1-6 transmite la misma informacin con el uso de un diagrama decolaboracin.

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 eldiagrama 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 interaccinentre secuencia y colaboracin, pero no es necesario crear los dos tipos de diagramas. Engeneral, 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 delsistema que se est diseando.

Sustento Esaw

Agua Alimento

www.FreeLibros.me


29/257

Manual de U10

Diagramas de estadoMientras que los diagramas de interaccin muestran los objetos y los mensajes que pasan entre ellos, un diagrama de estadomuestra el estado cambiante de un solo objeconforme ste pasa por un sistema. Si continuamos con nuestro ejemplo, entonces nenfocaremos sobre Esaw y cmo est cambiando su estado a medida que busca con afel alimento, lo encuentra y lo consume (figura 1-7).

RECUERDE Desmitificado:el UMLes 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, finalmente, con tanta exactitud como sea posible, sin quedarse

atascado decidiendo acerca de los elementos del lenguaje. Desafortunadamente, las h

rramientas del UMLno 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

alimento.

Esaw Canasta Fuego

Adquirirel alimento

Caminarhacia la cueva

Abrir

Tomar el alimento

Cocinar (alimento)

Trasladar (alimento)

Comer

Vaciar a la (alimento)

Alimento cocinado

www.FreeLibros.me


30/257


Diagramas de componentesEl umldefine varios tipos de modelos, incluyendo modelos para anlisis, para diseo ypara 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 modelode implementacin es de componentes. En un diagrama de componentes, stos se mues-tran piense en subsistemas en el producto final.

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

Figura 1-7 Diagrama de estado (oesquema 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

Canasta

2:Vaciarala4:Abrir5:Tomarelalimento

6:Cocinarelalimento

7:Retirarelalimento

Hambre Buscar

Comida

Reposo

/ Salir de la cueva

(Hambre)

(Seguro para comer) / Encontrar alimento

(No tiene hambre)

www.FreeLibros.me


31/257

Manual de U12

Cubrir los diagramas de despliegue ms adelante en este libro, pero por ahora, apzar la cita de un ejemplo. En general, un diagrama de componentes es un poco semeja

te a uno de clases, con smbolos de componentes.

Otros diagramasHay otros tipos o variaciones de diagramas que podemos crear. Por ejemplo, un diagramde topologa del desplieguele mostrar cmo se ver desplegado su sistema. Lo comes que un diagrama de este tipo contenga smbolos que representen cosas, como servidres web, servidores de bases de datos y varios dispositivos diversos, as como softwaque constituye la solucin de usted. Este tipo de diagrama es ms comn cuando ustest estructurando sistemas distribuidos en nhileras.

Ms adelante, en este libro, le mostrar ejemplos de algunos de estos diagramas. Recu

de que, en el modelado, la clave consiste en modelar aspectos interesantes de su sistemque ayuden a aclarar elementos que puedan no ser obvios, en oposicin a modelarlo tod

Hallar la lnea finalLa parte ms difcil del modelado es que es tan nuevo que los modelosumlestn sujeta algo de las mismas guerras de los lenguajes que sufrieron los proyectos orientadosobjetos durante la ltima dcada. Le aliento a evitar estas guerras de lenguajes, ya qprincipalmente son ejercicios acadmicos improductivos. Si se encuentra colgado acer

de si algo es bueno o no en uml, entonces se est dirigiendo hacia la parlisis del anli(y del diseo).

La meta es ser tan exacto como sea posible en una cantidad razonable de tiempo. software mal diseado es suficientemente malo, pero ningn software es casi siemppeor. Con el fin de determinar si ha concluido con un diagrama o modelo particulhaga la pregunta: el diagrama o modelo transmite lo que entiendo, lo que quiero darentender y mi intencin?Es decir, el diagrama o modelo es suficientemente bueno? exactitud es importante porque los dems necesitan leer sus modelos, y los errores idimticos significan que esos modelos sern ms difciles de leer para los dems.

Cuntos diagramas debo crear?No existe respuesta especfica. Una pregunta mejor es: debo crear todo tipo de diagrmas?La respuesta a esta pregunta es no. Un refinamiento de esta respuesta es que resutil crear diagramas que resuelvan los problemas delicados de anlisis y diseo, as comdiagramas que la gente realmente leer.

www.FreeLibros.me


32/257


Cun grande debe ser un diagrama?

Determinar cun grande necesita ser un modelo es otra buena cuestin para decidir. Siun modelo dado es demasiado grande, entonces puede aumentar la confusin. Intentecrear modelos detallados, pero no demasiado. Como con la programacin, la creacin demodelos umlrequiere prctica.

Solicite retroalimentacin de diferentes grupos cuya opinin sea importante. Si losusuarios finales piensan que un diagrama de anlisis capta de manera adecuada y correctael problema, entonces siga adelante. Si los programadores pueden leer una secuencia ydeducir 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 significado en menos espacio y son ms fciles demanipular. Si agrega demasiado texto restricciones, notas o documentos largos, en-tonces est anulando la finalidad de esta notacin pictrica ms concisa.

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

Se recibir bien que agregue cualquier texto aclaratorio que necesite, pero la reglageneral 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 hayaproducido.

Obtenga una segunda opinin

Si se encuentra atascado en un diagrama particular, obtenga una segunda opinin. Confrecuencia, 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 elusuario final de ese modelo entender lo que usted quiere decir o proporcionar msinformacin que aclare la confusin, o bien un segundo par de ojos puede suministraruna respuesta lista. Un elemento crtico de todo software de desarrollo es construir ciertainercia y captar los macroconceptos, o grandes conceptos, sin quedarse atascado o man-tener esperando a los usuarios.

www.FreeLibros.me


33/257

Manual de U14

Contraste de los lenguajes de modelado

con el procesoEn realidad, el umlempez su vida como Unified Process (Proceso unificado). Los iventores se dieron cuenta con rapidez de que los lenguajes de programacin no deteminan el proceso, ni debieran hacerlo los lenguajes de modelado. Por tanto, procesolenguaje se dividieron.

Existen muchos libros sobre procesos. No pienso que un proceso represente el mejajuste para todos los proyectos, pero quizs uno de los procesos ms flexibles es elRtional Unified Process(Proceso unificado racional). Mi enfoque en este libro es sobreuml, no sobre cualquier proceso particular. Estar sugiriendo los tipos de modelos pcrear y lo que le dicen a usted, pero le aliento a que examine los procesos de desarrol

por usted mismo. Considere examinar el Rational Unified Process (rup), el proceso AgieXtreme Programming (xp) e, incluso, Microsofts Services Oriented Architecture (soarquitectura orientada a servicios de Microsoft). [soaes ms que un procedimiento arqutectnico en el que se usan elementos como xmlWeb Services (Servicios web xml), peofrece algunas buenas tcnicas.]

No soy un experto en todos los procesos, pero enseguida doy un resumen que le daun punto de partida. El rupes un aparador de actividades centradas en el uml, que defimacrofases iterativas en pequeas cascadas, incluyendo iniciacin, elaboracin, contruccin y transicin. xpes hackeo constructivo. En general, la idea se basa en estructursobre lo que usted comprenda, esperar que las cosas cambien y usar tcnicas como programacin de redes composicin en factores y para apoyar los cambios a medida q

usted aumenta su comprensin. El soade Microsoft depende de tecnologas como comRemoting y los xmlWeb Services as como de una separacin de las responsabilidadpor medio de los servicios. Agile es una nueva metodologa que no entiendo por compto, pero que en el libro del Dr. Boehm,Balancing Agility and Discipline, se le compacon xp,y sospecho que, desde el punto de vista conceptual, reside en alguna parte entrupy xp.

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

Examen1. Qu significa el acrnimo uml?

a. Uniform Model Language

b. Unified Modeling Language

www.FreeLibros.me


34/257


c. Unitarian Mock-Up Language

d. Unified Molding Language

2. El UMLslo 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 Unified Process

c. eXtreme Programming

d. Los mtodos Agile

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

a. Unified 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 UMLcontendr por lo menos un diagrama de cada tipo.

a. Verdadero

b. Falso

www.FreeLibros.me


35/257

Manual de U16

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

a. La pandilla de los cuatrob. 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

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

www.FreeLibros.me


36/257

CAPTULO

17

El Unified Modeling Language (uml

) soporta el anlisis y diseo orientados a tos proporcionndole una manera de captar los resultados del anlisis y el disegeneral, iniciamos con la comprensin de nuestro problema; es decir, el anlisitipo excelente de modelo para captar el anlisis es el diagrama de casos de uso

La finalidad de un caso de usoes describir la manera en que se usar un sistdescribir sus finalidades esenciales. La finalidad de los diagramasde casos des captar en forma visual las finalidades esenciales.

Un caso de uso bien escrito y bien representado en diagrama es una dclasificaciones de modelos individuales ms importantes que usted puede cEsto es as porque expresar con claridad, conocer y organizar los objetivos esgularmente importante para alcanzarlos con xito. Existe un viejo proverbio

dice: Un viaje de mil millas empieza con un paso, y existe un proverbio un menos antiguo que dice: Si no sabe hacia adnde va, entonces el viaje nterminar.

El principicon casos de us

2

www.FreeLibros.me


37/257

Manual de U18

En este captulo, hablar acerca de una primera parte significativa de ese viaje 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 diagram

de casos de uso

De manera significativa, 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, lneasvalos. La figura de palillos se llama actory representa a alguien o algo que acta sobel sistema. En el desarrollo de software, los actores son personas u otro software que ata sobre el sistema. Las lneas son punteadas o continuas, con varias flechas o sin ellque indican la relacin entre el actor y los valos. Estos ltimos son los casos de uso y, el diagrama de casos de uso, los valos tienen algn texto que proporciona una descricin 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 parecdemasiado sencillos para tener algn valor. Un nio de tres o cuatro aos con un crayy un pedazo de papel podra reproducir estas figuras de lnea; sin embargo, su sencilles decepcionante.

Que un diagrama de casos de uso sea fcil de crear es un elogio implcito para el umHallar los casos de uso correctos y registrar sus responsabilidades en forma correcta esdecepcin. Hallar los casos de uso correctos y describirlos de manera adecuada es el prceso crtico que impide que los listos ingenieros de software pasen por alto necesidad

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

Patrn

Crear lista de trabajos

www.FreeLibros.me


38/257

CAPTULO 2 El principio con casos de uso19

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

En el prrafo anterior, us el prefijo macro. Macro en este contexto sencillamentesignifica grande. Los grandes objetivos, o macroobjetivos, son los que se mencionancomo 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 casosse captan los detalles de apoyo.

Esto es lo que se me escapaba en las imgenes de las figuras de lnea de los diagramasde casos de uso; perda de vista que, sencillamente, al registrar lo que el sistema har ylo 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 losespacios en blanco entre los macrosos y los microsos, en donde microsignifica usosmenores, de apoyo.

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

Establecimiento de prioridad de las capacidades

Alguna vez ha escrito una lista de cosas por hacer? Una lista de cosaspor hacer es unalista de cosas que usted debe hacer o desea hacer. El acto de escribir la lista es un puntode 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 darprioridades 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 posiblecrear, 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 prioridadesde los usos, con frecuencia tenemos la oportunidad de hacer, con ventaja, malabarismoscon 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 secundariosson 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 usosprimarios crear, guardar, abrir e imprimir, pero aplazar el soporte de htmly textoenriquecido. (Las caractersticas en el software por lo comn se aplazan hacia versionesposteriores, debido a las restricciones reales mencionadas con anterioridad, incluyendotiempo, presupuesto y un cambio en el entorno de la empresa.)

www.FreeLibros.me


39/257

Manual de U20

No tener tiempo suficiente y quedarse sin dinero son problemas directos. Los desarrlladores de software son rutinariamente optimistas, se distraen en salidas por la tangen

y pasan ms tiempo en reuniones que en la planeacin, y estas cosas gravan un prespuesto. Sin embargo, tomemos un momento para examinar un cambio en el entorno la empresa. Si nuestras necesidades originales fueron html, texto llano y texto enriqucido y hemos estado estructurando nuestro software en los ltimos cinco aos, resultaperfectamente plausible que un cliente dijera, a la mitad del curso del desarrollo, qguardar un documento como eXtensible Markup Language (xml, lenguaje ampliable marcado) sera ms valioso que como texto enriquecido. De este modo, debido a un climtecnolgico en evolucin, a media corriente un cliente podra restablecer las prioridady demandar xmlcomo ms importante que el texto enriquecido. Si no hubiramos docmentado nuestras necesidades primarias y secundarias, entonces podra ser un reto mgrande determinar los trueques deseables, como cambiar el texto enriquecido por el xm

Debido a que registramos con claridad los casos deseables de usos, podemos establecprioridades y hacer trueques valiosos, si es necesario.

Comunicacin con los no tecnfilos

Otra cosa que no perd de vista acerca de los casos de uso es que su mera sencillez lhace un medio fcil de transmisin para comunicarse con no tecnfilos. A estas personlas llamamos usuarioso clientes.

Los programadores que usan el hemisferio izquierdo de su cerebro en general detesta los usuarios. La idea bsica es que si uno no puede leer el cdigo, entonces es tonto

por lo menos, ms tonto que aquellos que s pueden. El umly los casos de uso cubrla brecha entre los programadores que usan el hemisferio izquierdo del cerebro y lusuarios no tecnfilos.

Una figura de palillos, una lnea y un valo son suficientemente simplistas, cuando combinan con algn texto, para que todos los participantes puedan entender el significadEl resultado es que los usuarios y clientes pueden observar los dibujos y leer el texto llany determinar si los tecnlogos han, o no, registrado con exactitud y comprendido las cractersticas deseables. Esto tambin significa que los administradores quienes puedno haber escrito cdigo en 10 aos y las direcciones tcnicas pueden examinar el prducto final y, por inspeccin, garantizar que la inventiva desenfrenada no es la causa de lprogramas no cumplidos ni de las caractersticas ausentes. Demostrando esta disonanc

al continuar con mi primer ejemplo, suponga que, de cualquier manera, se implementasoporte de texto enriquecido porque el programador sabe cmo almacenar y recuperar etipo de texto. No obstante, debido a que el xmles ms reciente y el programador tiene mnos experiencia en trabajar con l, la caracterstica de escritura en xmlse aplaza sin mlicia. Un administrador proactivo puede descubrir las necesidades de un cliente, segn captan mediante los casos de uso, y apropiarse de salidas por la tangente improductivas

www.FreeLibros.me


40/257


Debido a que los casos de uso son visuales y sencillos, los usuarios y clientes puedensuministrar retroalimentacin, y las personas que constituyen el puente entre los clientes

y los programadores, como los administradores, pueden determinar si las caractersticasque en realidad se estructuraron reflejan con exactitud los deseos de los usuarios.

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

Smbolos de actoresLa figura de palillos, mencionada como actor, representa participantes en los casos deuso. Los actores pueden ser personas o cosas. Si un actor es una persona, entonces, enrealidad, 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 identificandolos macrousos del sistema, identificar quines son los participantes para esos casos deuso. En principio, registre cada actor a medida que se descubre, agregando un smbolode actor a su modelo y describiendo cul es su papel. Nos preocuparemos acerca de laorganizacin 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 sele da un nombre y una descripcin mediante un texto. Este ltimo debe describir cmoinicia y finaliza el caso de uso, e incluye una descripcin de la capacidad descrita porel nombre de la misma, as como escenarios de apoyo y requisitos no funcionales. En laseccin 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 delcaso de uso.

Actor Conector Caso de uso

www.FreeLibros.me


41/257

Manual de U22

de nombres de casos de uso, y en la seccin titulada Documentacin de un caso de uutilizando un borrador, proporcionar un borrador modelo que pueda usar para ayudar

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 lcasos de uso pueden estar asociados con los actores y con otros casos de uso, se utilizlos conectores para indicar la manera en que ambos estn asociados. Adems, los estilde conectores pueden cambiar para transmitir ms informacin acerca de la relacientre los actores y los casos de uso. Por ltimo, los conectores pueden tener adornosanotaciones que suministran incluso ms informacin.

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

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

Un tercer estilo de conector es una lnea dirigida con un tringulo hueco, al cual seconoce como generalizacin. La palabra generalizacinen el umlsignifica herenciCuando mostramos una relacin de generalizacin entre dos actores o dos casos de usestamos indicando que el actor o el caso de uso hijos son un caso del actor o uso bsiy algo ms. En la figura 2-4, se muestra una relacin de generalizacin entre dos actoresdos casos de uso.

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

Crear lista de trabajos Entrar

Patrn

www.FreeLibros.me
http://www.motown-jobs.com/http://www.motown-jobs.com/http://www.motown-jobs.com/http://www.motown-jobs.com/http://www.motown-jobs.com/


42/257


En las relaciones de generalizacin, la flecha apunta hacia la cosa sobre la cual nosestamos 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 enunciadosdescriben 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 trabajosen todas partes en dondevea la palabra Usuario, y sustituir la frase Crear lista de trabajos por prioridadesentodas las partes en donde vea la palabra Patrn, para transmitir la relacin entre los doscasos de uso.) El ltimo enunciado, en el cual se usa la palabra generaliza, es el msexacto en el contexto del uml, pero vale la pena reconocer que todos los enunciados sonequivalentes.

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

Usuario

Patrn

Crear lista de trabajos

Crear lista detrabajos por prio-

ridades

www.FreeLibros.me


43/257

Manual de U24

Adornos de los conectoresLos diagramas umlfomentan el uso de menos texto porque las imgenes transmiten ugran cantidad de informacin a travs de una conveniente taquigrafa visual, pero ldiagramas umlno se abstienen por completo del texto; por ejemplo, los conectores puden incluir texto que indique multiplicidad de los puntos extremos y texto que estereotiel conector.

Manera de mostrar la multiplicidad

En general, los conectores pueden tener notaciones de multiplicidad en cualquiera de sdos extremos. Las notaciones de multiplicidad indican el conteo posible de cada cosPor ejemplo, un asterisco significa muchos; un asterisco prximo a un actor signifique puede haber muchos ejemplos de ese actor. Aun cuando el umlpermite hacer an

taciones de esta manera en los conectores de caso de uso, eso no es muy comn. Es mprobable que usted vea estas marcas de notacin de conteo en diagramas del tipo de lde 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 agregdetalles a la relacin entre los elementos en un diagrama de caso de uso. Por ejempen la figura 2-3, introduje el conector de dependencia. Se puede usar un estereotipo paampliar el significado de este conector.

En la seccin titulada Estilos de lneas para los conectores, dije que un patrn puecrear una lista de trabajos e ilustr esto con un actor patrn, un caso de uso Crear li

de trabajos y un conector de asociacin; sin embargo, tambin dije que el patrn deobtener acceso. Cuando un caso de uso Crear lista de trabajos necesita los servcios de otro caso de uso Entrar entonces se dice que el caso de uso dependienincluyeel caso de uso del que depende. (En cdigo, una relacin incluir se implemencomo reutilizacin de cdigo.)

Un estereotipo se muestra como texto entre los caracteres y (comillas angularePor ejemplo, si decimos que Crear lista de trabajos incluye a Entrar, entonces podmos representar un estereotipo incluircolocando una anotacin en el conector de depedencia como se muestra en la figura 2-5.

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

EntrarCrear listade trabajos

Patrn

incluir

www.FreeLibros.me


44/257


Incluir y extender son conceptos importantes en los diagramas de caso de uso, demodo 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 defina 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 ypredefinidos 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, dela 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 UMLy las herramientas del mismo,

porque el UMLes un estndar en evolucin y la implementacin de las herramientas

puede ir adelante o atrs de la definicin oficial 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 elestereotipo incluir es que el caso de uso dependiente necesitar los servicios del caso delque 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 claroque requerimos que un patrn tenga acceso para crear una lista de trabajos, pero tambinpudimos obtener acceso por otras razones.

NOTAEn 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 conocecomo el caso de uso de inclusin. Aunque bsicoy de inclusinpueden ser trminos ms

precisos, no parece que se empleen de manera comn al hablar.

Poner tanto significado en una pequea palabra como incluires la razn por la cualel umlpuede transmitir una gran cantidad de significado en un diagrama sencillo, perotambin es la razn por la cual los modelos umlpueden representar un reto para crearsey leerse. Una estrategia real a la que puede recurrir es agregar una nota en donde no est

www.FreeLibros.me


45/257

Manual de U26

seguro acerca del uso de algn aspecto idiomtico del uml(vea, ms adelante, Anociones en los diagramas de caso de uso). Por ejemplo, si quiere describir la relaci

entre Crear lista de trabajos y Entrar, pero no est seguro acerca de cul conectorcul estereotipo usar, entonces podra usar una asociacin simple y una nota asociadaconector que describa en texto llano lo que usted quiere dar a entender. La nota pueactuar como un recordatorio para, ms adelante, regresar y buscar el umlpreciso.

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

NOTA En una relacin extendida, la flecha apunta hacia el caso de uso bsico y el o

extremo se conoce como el caso de uso de extensin.

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

Una perspectiva valiosa aqu es quin podra estar interesado en el registro. Es evidete que al Solicitante de trabajo tal vez no le interese cuntas veces se ha visto la lis

pero un patrn previsor podra estar interesado en cunto trfico est generando su lisPasemos ahora por un momento a un dominio diferente. Suponga que el Solicitante trabajo fuera el comprador de una casa y que la lista lo fuera de residencias. Ahora tanel comprador como el vendedor podran estar interesados en el nmero de veces que ha visto la propiedad. Una casa que ha estado en el mercado durante meses puede ten

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

Registrar las listas vistas

Ver lista

Solicitante de trabajo

extender

www.FreeLibros.me


46/257


problemas. Sin embargo, en los dos escenarios, la lista es lo ms importante y el nmerode 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 extensionespodran 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 final 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 ordenes 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 deuso existentes as como para modelar servicios opcionales del sistema (vergaard yPalmkvist, 2005, p. 79).

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

Los estengrafos producen una taquigrafa que es ms condensada que el discurso alhablar. El umles como la taquigrafa para el cdigo y el texto, y las herramientas de mo-delado del umlson semejantes a los estengrafos. La idea es que los modelos se puedancrear 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 estseguro del uml, entonces siga adelante y agregue texto. Puede agregar texto mediantela documentacin de sus modelos con caractersticas de la mayora de las herramientas demodelado, agregando referencias urla los documentos ms verbosos o agregando notasdirectamente en los propios diagramas. Sin embargo, si agrega demasiado texto, entoncesde 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 umles 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-

www.FreeLibros.me


47/257

Manual de U28

ten que se les agreguen anotaciones en forma de texto. Las notas se representan como trozo de papel con una punta doblada y una lnea que une el cuadro de texto al elemenque se le est haciendo la anotacin (figura 2-7). Use las notas con moderacin, porqpueden 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, VisPoseidon para umly la de Cayenne Software permiten la documentacin del modePor lo comn, esta documentacin toma dos formas: texto que se almacena en el modey Uniform Resource Locators (url, localizadores uniformes de recursos), que hacreferencia a documentos externos (figura 2-8). El examen de las caractersticas de herramienta particular le descubrir estas capacidades.

Ms importante es qu tipo de documentacin debe usted proporcionar. De manesubjetiva, la respuesta es tan pequea como aquella con la que pueda ponerse en marchpero 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 sobastante importantes porque registran las capacidades que tendr el sistema de usted. Ubuena informacin a incluir con sus diagramas de caso de uso es

Un prrafo conciso en el que se describa cmo empieza el uso, incluyendo cuale

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 cu

les ayuden a ubicar en un contexto la necesidad de las funciones

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

registrando las listas vistas.

Ver lista

Registrar las listasvistas

Solicitante de trabajo

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

extender

www.FreeLibros.me


48/257


Un prrafo para las necesidades no funcionales

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

Un punto de finalizacin con las condiciones posteriores

Todos estos elementos suenan como una gran cantidad de trabajo, y pueden serlo. Sinembargo, 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 esnotar que us las palabras concisoy cortode manera intencional. Por corto, quiero dar aentender que es aceptable tener prrafos de una sola oracin.

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

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

Documentacin de un caso de uso utilizando un borradorPuede usar texto de forma libre para documentar un caso de uso, pero encuentro que unmodelo de borrador sugiere la extensin de la informacin y acta como un recordatoriode 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.

www.FreeLibros.me


49/257

Manual de U30

cin se presenta un modelo que incluye una breve descripcin y un ejemplo para caseccin. Vale la pena hacer notar que este estilo de documentacin no es parte del um

pero es un elemento til del modelado.1. Ttulo

a. Descripcin: Use aqu el nombre del caso de uso, pues facilita mucho el acop

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

uso, incluyendo las condiciones previas. Deje fuera los detalles de la impleme

tacin, como El usuario hace clic en un hipervnculo, o las referencias a l

formas, los controles o los detalles especficos de la implementacin.b. Ejemplo: Este caso de uso se inicia cuando un patrn, un agente de un patrn

el sistema quiere crear, modificar o eliminar una lista de trabajos.

3. Funciones primarias

a. Descripcin: Los casos de uso no son necesariamente singulares. Por ejemp

Administrar la lista de trabajos es un caso de uso razonable y puede inclu

funciones primarias como leer un recipiente o escribir en l. La clave aqu

evitar demasiado pocas o demasiadas funciones primarias. Si necesita una bu

na medida, podran ser dos o tres funciones primarias por caso de uso.

b. Ejemplo: CLABla lista de trabajos. Las funciones primarias de Mantener

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 u

pieza teatral. Por ejemplo, dado un caso de uso Administrar la lista de trab

jos, actualizar, insertar, crear y borrar una lista de trabajos llamado CLABp

crear, leer, actualizar y borrar son excelentes funciones secundarias, parte

un caso de uso ms grande. Si necesita una medida, entonces el doble de funci

nes secundarias que de primarias es bueno.

b. Ejemplos:

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

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

www.FreeLibros.me


50/257


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 consumidadel 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 listay 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 suslistas.

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 menosque 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. Demostradocomo 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 notificar 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.

www.FreeLibros.me


51/257

Manual de U32

7. Necesidades no funcionales

a. Descripcin: Las necesidades no funcionales se encargan de com-

portamientos implcitos, como con qu rapidez sucede algo ocuntos 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 significa haber fina-

lizado para el caso de uso.

b. Ejemplo: El caso de uso ha finalizado 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 deciside usted. El umlguarda silencio acerca de este asunto, pero un proceso como el ruple pude 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, inclso si finalmente elige descartarlos. Por ejemplo, podramos agregar una funcin secudaria que exprese que El sistema permitir una renovacin semiautomtica de una lide trabajos que estn caducando, apoyada por el escenario La lista del Sr. Garca pacontratar una nueva secretaria est prxima a caducar. Se notifica por correo electrnial Sr. Garca que su lista est prxima a caducar. Al hacer clic sobre un vnculo en el crreo, la lista del Sr. Garca se renueva en forma automtica usando la misma facturacie informacin de pago usadas con la lista original.

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

Por ltimo, resulta til insertar referencias a los casos de uso del que se depende. En gar de, por ejemplo, repetir un caso de uso de inclusin, sencillamente haga una referenca ese caso en el punto en que se necesite. Por ejemplo, suponga que pagar por una lista dtrabajos requiere que un patrn tenga acceso; en lugar de repetir el caso de uso Entrarsencillamente hacemos una referencia a ella en donde se necesite; en este caso, podemhacer 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 qun da feriado siempre est precisamente a la vuelta de la esquina, una buena analog

www.FreeLibros.me


52/257


comparativa es que definir casos de uso es como escribir una lista de tareas en orden parapreparar 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 ltimavez, de modo que le pide a ella que desempolve. En este caso, el nivel de detalle esimportante, porque sabe si alguna vez ha desempolvado que diferentes tipos decosas necesitan diferentes tipos de desempolvado: las chucheras pequeas se puedendesempolvar con un plumero; las mesas para servir caf y las de los extremos podrannecesitar Pledgey un pao limpio y seco, y los ventiladores del techo podran necesitarla varita y el cepillo de una aspiradora. La clave en este caso es la diferencia entre lo quedescribimos 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 unnmero cada vez mayor de aparatos. Suponga que estbamos definiendo 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 definir e implementar esas capacidades.

El caso de uso para desempolvar del prrafo anterior constara de un actor, Nia, unconector de asociacin y un caso de uso Desempolvar la sala (figura 2-9). No hace faltaque 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 yseco 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 dedetalle, sin hacer confusos los diagramas.

Despus de que tenemos el diagrama de caso de uso, podemos agregar informacinde soporte de la documentacin del modelo para nuestro caso de uso. Las funcionesprimarias incluiran desempolvar las reas clave, y las funciones secundarias incluiranla 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

www.FreeLibros.me


53/257

Manual de U34

dos incluiran el manejo de reas problemas especficas, como desempolvar los marcde los cuadros y artculos de coleccin. Los requisitos no funcionales podran inclu

Terminar de desempolvar antes de que lleguen los abuelos. No se preocupe acerca lograr diagramas perfectos ni de la documentacin del caso de uso; use el borrador paayudarse a considerar los detalles y los diagramas de caso de uso para obtener una bueimagen de sus objetivos.

Cuntos diagramas son suficientes?

La suficiencia es un problema difcil. Si proporciona demasiados casos de uso, su mdelado puede continuar durante meses o incluso aos. Tambin puede adentrarse enmismo problema con la documentacin de los casos de uso.

NOTA Fui consultor en un proyecto para un departamento grande de la agencia dedefensa. Literalmente, la agencia haba esta

Manual de UML - Paul Kimmel.pdf

Documents

Transcript of Manual de UML - Paul Kimmel.pdf