El Proceso Unificado de Desarrollo de Soft Jacobson

~L PROCESO UNIFICADO DE DESARROLLO
DE SOFTWARE

IVAR JACOBSON GRADY BOOCH JAMES RUMBAUGH

del Proceso

La guia completa

Unijicado escrita por sus creadores

The Addison-Wesley Object Technology Series

Grady Booch, Ivar Jacobson, and James Rumbaugh, Series Editors

Para tener mas informacion, consulte el sitio web de la serie [http://www.awl.comlcsengiotscriesi].as!como las paginas

de cada libro fhttp://www.awl.comicscngiI-S-B-Nij (I-S-B-N- cs el numero de ISBN dellibro en inglcs, incluycndo los guiones).

David Bellin and Susan Suchman SImone, The CRe Card Book ISBN 0-201-H9535-8

Grady Boocn, Object Solutions: Mwwging the Object-Oriented Project

ISBN 0-~053-0594-7

Grady Hooch, Object-Oriented Analvsis and Design with Applications, Second Edition

ISBN 0-8053-5340-2

Grady Booch. James Rumbaugh, and IVaT Jacobson, The Unified Modeling Language User Guide

ISBN 0-201-57168-4

Don Box, Essential COM ISBN 0-201-63446-5

Don Box, Keith Brown, Tim Ewald, and Chris Sclis, efjective COA1: 5() WCIYI 10 Improve Your CO/,,1 and MTS-based Applications ISBN 0-201-3796S-6

Alistair Cockburn, Surviving Obiecr-Oricnted Projects:

A Manager :\. Guide ISBN 0-201-49834-0

Dave Collins, Dcsiyning Object-Oriented Us«» lnteriaces ISBN 0-S053-5350-X

Bruce Powel Douglass, Doing Hard Tim e:Designing and Implementing r~mhedded Systems with (JML

ISBN 0-201-491\37-5

Bruce Powe! Douglass, Real-Time UML: Dn'C!oping Efiicient Objectsfor Embedded Svstems

ISBN 0-201-32579-9

Desmond F. D'Souza and Alan Cameron Will s, Objects, Components, and Frameworks with UML: The Catalysis Appmuch [SBN 0-201-31012-0

Martin Fowler, Analysis Patterns: Reusable Ohject Model:

ISBN 0-201-X9542-0

Martin Fowler with Kendall Scott, C?vIL Distilled:

Applying the Standard Ohject ModelinK Language ISBN 0-201-32563-2

Peter Hcinckiens, Building Scalabl« Database Applications:

Object-Oriented Design, Architectures, and Implementations ISBN 0-20[-31013-9

lvar Jacobson, Grady Booch, and James Rumbaugh, Tile Unified Software Development Process

ISBN 0-201-57[69-2

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Software Engineering. A Usc Case Driven Approach

ISBN 0-201-54435-0

lvar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage: Business Process Rcengineenng with Objecs Technology

ISBN 0-201-42289-1

lvar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse.' Architecture. Process and Olgani:;ation for Business Success

ISBN 0-201-92476-5

David jordan, C-- + Obje«! Databases: Programming with the ODMG Standard

ISBN 0-201-6348S-0

Philippe Kruchten, The Rational Unified Process: An Introduction ISBN 0-201-60459-0

Wilf Lal.onde, Discovering Smallralk ISBN 0-S053-2720-7

Lockheed Martin Advanced Concepts Center and Rational Software Corporation, Succeeding with the Booch and OMT Methnd«: A Practical Approach

ISBN 0-S053-2279-5

Thomas Mowbray and William Ruh, Imide CORBA:

Distributed Object Standards and Applications ISBN 0-201-1\9540-4

Ira Pohl, Object-Oriented Programming Usillg C+-, Second Edition [SBN 0-201-89550-1

Rob Pooley and Perdita Stevens, Using UML: Software Engineering Willi Objects and Components

ISBN 0-201-36067-5

Terry Quatrani, Visual lt10deling with Rational Rose and UML ISBN 0-201-31016-3

Brent E. Rector and Chris Sells, ATL Internals ISBN 0-201-69589-8

Doug Rosenberg with Kendall Scott, Use ClIS<' Driven Object Modeling with Lll1L: A Practical Appmach

ISBN 0-201-43289-7

Walker Royce, Sofiware Project Management: A Unified Framework ISBN 0--201-30958-0

William Ruh, Thomas Herron, and Paul Klinker, !lOT' Complete:

Middlewar« lntcroperability and Distributed Ohject Standards ISBN 0-201-37925-2

James Rumbaugh, lvar Jacobson, and Grady Booch, 111(' Unified Modeling Language Reference MWlIIal ISBN 0-201-30998-X

Geri Schneider and Jason P. Winters, Applving Use Cases:

A Practical Guide ISBN 0-201-30981-5

Yen-Ping Shan and Ralph H. Earle, Enterprise Computing with Object': From Client/Saver Environments to the internet ISBN 0--201-32566-7

David N. Smith, IBM Smalltnlk: The Language ISBN 0-8053-0908-X

Daniel Tkach, Walter Fang, and Andrew So, Visual Modeling Technique: Ohject Technology Using Visual Programming lSHN 0-8053-2574-3

Daniel Tkach and Richard Puttick, Object Technology in Application Development. Second Edition

ISBN 0-201-49g33-2

Jos Warmer and Anncke Kleppe, The Object Constraint Language: Precise Modeling with UML

[SHN 0-201-37940-6

EL PROCESO UNIFICADO DE DESARROLLO

DE SOFTWARE

Ivar JACOBSON Grady BOOCH James RUMBAUGH RATIONAL SOFTWARE CORPORATION

Traducclon:

Salvador Sanchez

Universidad Pontificia de Salamanca en Madrid Miguel Angel Sicilia Universidad Pontificia de Salamanca en Madrid

Carlos Canal

Universidad de Malaga

Francisco Javier Duran Universidad de Malaga

Coordinacion de la traduccion y revision tecnica:

Luis Joyanes

Director del Departamento de Lenguajes y Sistemas Informaticos Universidad Pontificia de Salamanca en Madrid Ernesto Pimentel

Director del Departamento de Lenguajes y Sistemas Informaticos Universidad de Malaga

ADDISON WESLEY

Madrid> Mexico> Santafe de Bogota> Buenos Aires> Caracas> Lima » Montevideo> San Juan San Jose> Santiago> Sao Paulo s White Plains

/ Datos de- catalogaci6n bibliogratica

Formato Il)S / 250

Pigmas: 0..1-6-+

I. Jacobson, G.lluuch . .I. Rumbaugh

EL PROCESO liN I f-ICi\ I)() DE DESARROLLO Ilf' SOFTWARE PFARSUN 1'lllICACI()N. S. 1\ .. Madrid. :'OO(J

ISBN: K.j-7Ko9-nJIl-~ Mntcria: Informatica ()Si.:'

I. Jacobson, G. Hooch • .I. Rumbaugh

EL PROCESO U\U'ICADO DE DESARROLLO DE SOFTWARE

)10 eSl:i permitida la rcproduccion total 0 parcial de esta obra ni su traturniento 0 uunsmision por cualquier medio 0 mctodo sin autorizaci(m eSCrilo. de la Editorial.

DERECHOS RESLRVADOS

© 2000 respecto a la primera edicion en cspaiiol por:

PEARSON EDUCAC[ON. S. A. )lunez de Balboa, 120

28006 Madrid

ISBN: 84-7829-036-2

Deposito legal: M_ 20.385-2000

ADDISON WESLEY es un sello editorial de PEARSON EDUCACION, S. A_

Traducido de:

THE UNIFIED SOFTWARE DEVELOPMENT PROCESS Copyright CO [999 Addison Wesley Longman Inc.

ISBN: 0-20[-57169-2

Edicion en espaiio]:

Editor: Andres Otero

Asistente edftorial: Ana Isabel Garcta Disefio de cubierta: DIGRAF, S_ A. Composicion: COPIBOOK. S. L. Impreso por: Imprenta FARESO, S. A.

IMPRESO EN ESPANA - PRINTED IN SPAIN

E..;te I ihm ha sido imprcso con pupcl y tin Las ecolugicos

Contenido

Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Parte I:

EI Proceso Unificado de Desarrollo de Software

Capitulo 1 : EI Proceso Unificado: dirigido por casos de uso,

centrado en la arquitectura, iterativo e incremental. . . . . 1

1.1. El Proceso Unificado en pocas palabras 4

1.2. El Proceso Unificado esta dirigido por casos de uso . . . . . . . . . . . . . . . . 5

1.3. EI Proceso Unificado esta centrado en la arquitectura . . . . . . . . . . . . . . . 5

1.4. EI Proceso Unificado es iterativo e incremental 6

I .5. La vida del Proceso U nificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . g

1.5.1. El producto 9

1.5.2. Fases dentro de un ciclo 10

1.6. Un Proceso integrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Capitulo 2: Las cuatro "P" en el desarrollo de software: Personas,

Proyecto, Producto y Proceso. . . . . . . . . . . . . . . . . . . . . . . . [3

2. [ . Las personas son decisivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1. Los procesos de desarrollo afectan a las personas 14

2.1.2. Los papclcs cambiaran 15

2.1.3. Convirtiendo "recursos" en "trabajadores' . . . . . . . . . . . . . . . . . 16

2.2. Los proyectos construyen el pruducto . . . . . . . . . . . . . . . . . . . . . . 17

2.3. El producto es mas que codigo 18

2.3.1. (.Que es un sistema software? . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.2. Artefactos.......................................... 18

VI CONTENIDO

2.3.3. Un sistema posee una coleccion de modelos 19

2.3.4. (,Que es un modelo? 20

2.3.5. Cada modelo es una vista autocontenida del sistema. . . . . . . . . 20

2.3.6. Dentro de un modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.7. Relaciones entre modelos . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4. El proceso dirige los proyectos 22

2.4.1. EI proceso: una plantilla . . . . . . . . . . . . . . . . . . . . 22

2.4.2. Las actividades relacionadas conforman flujos de trabajo . . . . . 22

2.4.3. Procesos especializados 24

2.4.4. Meritos del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5. La herramientas son esenciales en el proceso 25

2.5.1. Las herramientas intluyen en el praceso . . . . . . . . . . . . . . . . . . . 25

2.5.2. El proceso dirige las herramientas 26

2.5.3. El equilibrio entre el proceso y las herramientas 27

2.5.4. El modelado visual soporta UML . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.5. Las herramientas dan soporte al ciclo de vida completo 28

2.6. Referencias................................................ 29

Capitulo 3: Un proceso dirigido por casos de uso 31

3. I. Desarrollo dirigido por casas de uso en pocas palabras . . . . . . . . . . . . . . 33

3.2. l,Por que casas de usa? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1. Para capturar los requisites que aportan valor aiiadido . . . . . . . . 35

3.2.2. Para dirigir el proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.3. Para idear la arquitectura y rnas.. . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3. La captura de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.1. El modelo de casos de usa representa los requisitos funcionales. 38

3.3.2. Los actores son el entorno del sistema 39

3.3.3. Los casas de usa especifican el sistema. . . . . . . . . . . . . . . . . . . 39

3.4. Analisis, disefio e implementacion para realizar los casos de uso . . . . . . 40

3.4.1. Creacion del modele de analisis a partir de los casos de uso 41

3.4.2. Cada c1ase debe cumplir todos sus roles de colaboracion 45

3.4.3. Creacion del modelo de disefio a partir del modelo de analisis . . 46

3.4.4. Las subsistemas agrupan a las clases 49

3.4.5. Creacion del modele de implementacion a partir del modelo de

disefio 50

3.5. Prueba de los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6. Resumen.................................................. 53

3.7. Referencias................................................ 54

Capitulo 4: Un proceso centrado en la arquitectura 55

4.1. La Arquitectura en pacas palabras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2. Por que es necesaria la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2.1. Comprension del sistema 58

4.2.2. Organizacion del desarrollo 59

4.2.3. Fomento de la reutilizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.4. Evolucion del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3. Casos de uso y arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4. Los pasos hacia una arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Parte II:

CONTENIDO VII

4A.1. La linea base de la arquitectura es un sistema "pequefio y flaco" . . 65

4A.2. Utilizacion de patrones arquitectonicos 67

4A.3. Descripcion de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4AA. EI arquitecto crea la arquitectura 71

4.5. Por fin, una descripcion de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 72

4.5.1. La vista de la arquitectura del modelo de casus de uso 73

4.5.2. La vista de la arquitectura del rnodelo de disefio 74

4.5.3. La vista de la arquitectura del modele de despliegue .. . . . . . . . 76

4.5A. La vista de la arquitectura del modelo de implementacion . . . . . 77

4.6. Tres conceptos interesantes 78

4.6.1. L.Que es una arquitectura? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.6.2. L.Como se obtiene? 78

4.6.3. L.C6mo se describe? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.7. Referencias................................................ 78

Capitulo 5. Un proceso iterativo e incremental 81

5.1. Iterativo e incremental en breve. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.1.1. Desarrollo en pequefios pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.1.2. Lo que no es una iteracion 84

5.2. L.Por que un desarrollo iterativo e incremental? . . . . . . . . . . . . . . . . . . . . 85

5.2.1. Atenuaci6n de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.2.2. Obtenci6n de una arquitectura robusta .. . . . . . . . . . . . . . . . . . . 87

5.2.3. Gestion de requisitos cambiantes 87

5.2A. Perrnitir cambios tacticos 88

5.2.5. Conseguir una integraci6n continua. . . . . . . . . . . . . . . . . . . . . . 88

5.2.6. Conseguir un aprendizaje temprano 90

5.3. La aproximacion iterativa es dirigida por los riesgos 90

5.3.1. Las iteraciones alivian los riesgos tecnicos . . . . . . . . . . . . . . . . . 91

5.3.2. La direccion es responsable de los riesgos no tecnicos 93

5.3.3. Tratamiento de los riesgos 93

5A. La iteracion generic a 94

5.4.1. Lo que es una iteracion . . . . . . . . . . . . . . 94

5A.2. Planificacion de las iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5A.3. Secuenciaci6n de las iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.5. El resultado de una iteracion es un incremento. . . . . . . . . . . . . . . . . . . . 97

5.6. Las iteraciones sobre el ciclo de vida 98

5.7. Los modelos evolucionan con las iteraciones 100

5.8 Las iteraciones desafian a la organizaci6n 101

5.9 Referencias................................................ 102

Los flujos de trabajo fundamentales

Capitulo 6: Captura de requisitos: de la vision a los requisitos 105

6.1. Por que la captura de requisitos es cornplicada .. . . . . . . . . . . . . . . . . . . 106

6.2. El objeto del flujo de trabajo de los requisitos . . . . . . . . . . . . . . . . . . . . . 107

6.3. Vision general de la captura de requisitos 107

6A. EI papel de los requisitos en el ciclo de vida del software. . . . . . . . . . . . III

VIII CONTENIDO

6.5. La cornprension del contexto del sistema mediante un modelo del

dominio 112

6.5.1. ~Que es un modelo del dominio? 112

6.5.2. Desarrollo de un modelo del dominio . . . . . . . . . . . . . . . . . . . . . 114

6.5.3. Uso del modelo del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.6. La comprension del contexto del sistema mediante un modelo del negocio, 115

6.6.1. (,Que es un modelo del negocio? . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.6.2. Como desarrollar un modelo del negocio . . . . . . . . . . . . . . . . . . 118

6.6.3. Busqueda de casos de uso a partir de un modele del negocio .. 120

6.7. Requisites adicionalcs 121

6.8. Resumen.................................................. 123

6.9. Referencias................................................ 123

Capitulo 7: Captura de requisitos como casos de uso . . . . . . . . . . . 125

7.1. Introduccion............................................... 125

7.2. Artcfactos................................................. 127

7.2. I. Artefacto: modelo de casas de uso 127

7.2.2. Artefacto: actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

7.2.3. Caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

7.204. Artefacto: descripcion de la arquitectura (vista del modelo de

casas de usa) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

7.2.5. Artefacto: glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

7.2.6. Artefacto: prototipo de interfaz de usuario . . . . . . . . . . . . . . . . . 133

7.3. Trabajadores............................................... 133

7.3.1. Trabajador: analista del sistema 134

7.3.2. Trabajador: especificador de casos de uso 135

7.3.3. Disefiador de interfaces de usuario . . . . . . . . . . . . . . . . . . . . . . . 135

7.304. Trabajador: arquitecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

704. Flujo de trabajo 136

704.1. Actividad: encontrar acto res y casos de uso . . . . . . . . . . . . . . . . 138

704.2. Actividad: priorizar casos de usa 146

704.3. Actividad: detallar un caso de uso 147

70404. Actividad: prototipar la interfaz de usuario 152

704.5. Actividad: estructurar el modelo de casos de usa. . . . . . . . . . . . 158

7.5. Resumen del flujo de trabajo de los requisitos 162

7.6. Referencias................................................ 163

Capitulo 8: Analisis........................................ 165

8.1. Introducci6n............................................... 165

8.2. EI analisis en poe as palabras 168

8.2.1. Por que el analisis no es disefio ni irnplcrnentacion 168

8.2.2. EI objeto del analisis: resumen 169

8.2.3. Ejemplos concretos de cuando hacer analisis . . . . . . . . . . . . . . . 170

8.3. EI papel del analisis en el cielo de vida del software. . . . . . . . . . . . . . . . 171

804. Artefactos................................................. 172

804.1. Artefacto: modelo de analisis 172

804.2. Artefacto: c1ase del analisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

804.3. Artefacto: realizacion de caso de uso-analisis 177

CONTENTDO IX

8.4.4. Artefacto: paquete del analisis 181

8.4.5. Artefacto: descripcion de la arquitectura (vista del modelo de

analisis) .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

8.5. Trabajadores.............................................. 184

8.5.1. Trabajador: arquitecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

8.5.2. Trabajador: ingeniero de casas de uso 185

8.5.3. Trabajador: ingeniero de componentes . . . . . . . . . . . . . . . . . . . 186

8.6. Flujo de trabajo 187

8.6.1. Actividad: analisis de la arquitectura 187

8.6.2. Actividad: analizar un easo de uso 194

8.6.3. Aetividad: analizar una clase 197

8.6.4. Actividad: analizar un paquete 20 I

8.7. Resumen del analisis '. . . . . . . . . . . . . . . . . . 203

8.8. Referencias............................................... 204

Capitulo 9: Diseno......................................... 205

9.1. Introducei6n.............................................. 205

9.2. EI papcl del disefio en el cicio de vida del software 207

9.3. Artefactos................................................ 208

9.3.1. Artefacto: modelo de disefio . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

9.3.2. Artefacto: clase del disefio 209

9.3.3. Artefacto: realizacion de caso de uso-disefio 210

9.3.4. Artefacto: subsistcma del disefio . . . . . . . . . . . . . . . . . . . . . . . . 213

9.3.5. Artefaeto: interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

9.3.6. Artefaeto: dcscripcion de la arquitectura (vista del modelo de

disefio)............................................ 216

9.3.7. Artefaeto: modelo de despliegue . . . . . . . . . . . . . . . . . . . . . . . . 217


despliegue) 218

9.4. Trabajadorcs.............................................. 218

9.4.1. Trabajador: arquitecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

9.4.2. Trabajador: ingeniero de casos de uso 219

9.4.3. Trabajador: ingeniero de componentes . . . . . . . . . . . . . . . . . . . 220


9.5.1. Actividad: disefio de la arquitectura . . . . . . . . . . . . . . . . . . 221

9.5.2. Aetividad: disefiar un caso de uso . . . . . . . . . . . . . . . . . . . . . . . 237

9.5.3. Actividad: disefiar una clase ... . . . . . . . . . . . . . . . . . . . . . . . . 243

9.5.4. Aetividad: disefiar un subsisterna . . . . . . . . . . . . . . . . . . . . . . . 250

9.6. Resumen del disefio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

9.7. Referencias............................................... 253

Capitulo 10: Implementacion................................ 255

10.1. Introducci6n.............................................. 255

10.2. El papel de la implementaci6n en el ciclo de vida del software 256

10.3. Artefactos................................................ 257

10.3.1. Artefacto: modelo de implementaci6n 257

10.3.2. Artefacto: eomponente , ,.............. 257

X CONTENIDO

10.3.3. Artefacto: subsistema de la implernentacion . . . . . . . . . . . . . . 260

10.3.4. Artefacto: interfaz .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262


implementaci6n) 263

10.3.6. Artefacro: plan de integraci6n de construcciones .. . . . . . . . . 264

10.4. Trabajadores.............................................. 265

10.4.1. Trabajador: arquitecto . . . . . . . . . . . . . . . . . . . . . . . . 265

10.4.2. Trabajador: ingeniero de componentes . . . . . . . . . . . . . . . . . . 266

10.4.3. Trabajador: integrador de sistemas. . . . . . . . . . . . . . . . . . . . . 266


10.5.1. Acti vidad: implernentacion de la arquitectura 268

10.5.2. Actividad: integrar el sistema 270

10.5.3. Actividad: implementar un subsistema . . . . . . . . . . . . . . . . . . 272

10.5.4. Actividad: implementar una clase . . . . . . . . . . . . . . . . . . . . . . 274

10.5.5. Actividad: realizar prueba unidad . . . . . . . . . . . . . . . . . . . . . . 276

10.6. Resumen de la implementaci6n . . . . . . . . . . . . . . . . . . . . . . . . 279

10.7. Referencias............................................... 279

1 Capitulo 11: Prueba........................................ 281

II. 1. 11.2. 11.3.

11.4.

11.5.

11.6. 11.7.

Introducci6n .

EI papel de la prueba en el ciclo de vida del software .

Artefactos .

11.3.1. Artefacto: modelo de pruebas .

11.3.2. Artefacto: caso de prueba .

11.3.3. Artefacto: procedimiento de prueba .

11.3.4. Artefacto: componente de prueba .

11.3.5. Artefacto: plan de prueba .

11.3.6. Artefacto: defecto .

11.3.7. Artefacto: evaluacion de prueba .

Trabajadores .

11.4.1. Trabajador: disefiador de pruebas .

11.4.2. Trabajador: ingeniero de cornponentes .

11.4.3. Trabajador: ingeniero de pruebas de integracion .

11.4.4. Trabajador: ingeniero de pruebas del sistema. . .

Flujo de trabajo .

11.5.1. Actividad: planificar prueba .

11.5.2. Actividad: diseiiar prueba .

11.5.3. Actividad: implementar prueba .

11.5.4. Actividad: realizar pruebas de integracion .

11.5.5. Actividad: realizar prueba de sistema .

11.5.6. Actividad: evaluar prueba .

Resumen de la prueba .

Referencias .

Capitulo 12:

Parte III: EI Desarrollo iterativo e incremental

EI flujo de trabajo de iteraci6n generico

281 282 283 283 283 286 287 288 288 288 288 288 289 289 289 290 291 292 295 296 297 297 299 299

12.1. La necesidad de equilibrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

303

CONTENIDO XI

12.2. Las fases son la prirnera division del trabajo . . . . . . . . . . . . . . . . . . . . . 305

12.2.1. La fase de inicio establece la viabilidad 305

12.2.2. La fase de elaboracion se centra en la factibilidad 306

12.2.3. La fase de construccion construye el sistema . . . . . . . . . . . . . 307

12.2.4. La fase de transicion se mete dentro del entorno del usuario. 308

12.3. La iteracion generica ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

12.3.1. Los tlujos de trabajo fundamentales se repiten en cada

iteraci6n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

12.3.2. Los trabajadores participan en los flujos de trabajo 309

12.4. EI planificar precede al hacer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

12.4.1. Planear las cuatro fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

12.4.2. Plan de iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

12.4.3. Pensar a largo plazo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

12.4.4. Planear los criterios de evaluacion 313

12.5. Los riesgos influyen en la planificacion del proyecto . . . . . . . . . 314

12.5.1. Adrninistrar la lista de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . 314

12.5.2. Los riesgos intluyen en el plan de iteracion 315

12.5.3. Planificar la accion sobre los riesgos 316

12.6. Asignacion de prioridades a los casos de uso 316

12.6.1. Riesgos especificos de un producto particular 317

12.6.2. Riesgo de no conseguir la arquitectura correcta .. . . . . . . . . . 317

12.6.3. Riesgo de no conseguir los requisites correctos 319

12.7. Recursos necesitados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

12.7.1. Los proyectos difieren enormemente 320

12.7.2. Un proyecto tipico tiene este aspecto 321

12.7.3. Los proyectos mas grandes tienen mayores necesidades 321

12.7.4. Una nueva lfnea de productos requiere experiencia 322

12.7.5. EI pago del coste de los recursos utilizados 323

12.8. Evaluar las iteraciones y las fases 324

12.8.1. Criterios no alcanzados .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

12.8.2. Los criterios mismos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

12.8.3. La siguiente iteracion 325

12.8.4. Evolucion del conjunto de modelos 326

Capitulo 13: La fase de inicio pone en marcha el proyecto 327

13.1. La fase de inicio en pocas palabras 327

13.2. Al comienzo de la fase de inicio 328

13.2.1. Antes de comenzar la fase de inicio 328

13.2.2. Planificacion de la fase de inicio . . . . . . . . . . . . . . . . . . . . . . . 329

13.2.3. Ampliacion de la descripcion del sistema. . . . . . . . . . . . . . . . 330

13.2.4. Establecimiento de los criterios de evaluacion .... . . . . . . . . 330

13.3. Flujo de trabajo arquetfpico de una iteracion en la fase de inicio ..... 332

13.3.1. Introduccion a los cinco tlujos de trabajo fundamentales . . . . 332

13.3.2. Ajuste del proyecto al entorno de desarrollo. . . . . . . . . . . . . . 334

13.3.3. Identificacion de los riesgos entices . . . . . . . . . . . . . . . . . . . . 334

13.4. Ejecucion de los tlujos de trabajo fundamentales, de requisitos

a pruebas 334

13.4.1. Recopilacion de requisitos 335

r

XII CONTENIDO

13.5.

13.6. 13.7. 13.8.

13.4.2. 13.4.3. 13.4.4. 13.4.5.

Analisis .

Diseiio .

Implementaci6n .

Pruebas .

337 338 339 339 340 340 341 341 342 343

Capitulo 14: La fase de elaboraclon construye la linea base

de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

14.1. La fase de elaboraci6n en pocas palabras 345

14.2. AI comienzo de la fase de elaboracion 346

14.2.1. Planificacion de la fuse de elaboracion .. . . . . . . . . . . . . . . . . 346

14.2.2. Formacion del equipo 347

14.2.3. Modificacion del entorno de desarrollo 347

14.2.4. Estableeimiento de criterios de evaluacion . . . . . . . . . . . . . . . 347

14.3. Flujo de trabajo arquetipico de una iteracion en la fase de

elaboracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 14.3.1. Recopilacion y rcfinamiento de la mayor parte de los

14.4.

14.5.

14.6. 14.7. 14.8.

Realizacion del analisis inicial de negoeio .

13.5.1. Esbozar la apuesta econornica .

13.5.2. Estirnar la recupcracion de la inversion .

Evaluacirm de la itcracion 0 iteraciones de la fase de inicio .

Planificacion de la fase de elaboracion .

Productos de la fase de inieio .

requisitos .

14.3.2. Desarrollo de Ia Iinea base de la arquitectura .

14.3.3. Iterando mientras el equipo es pequefio .

Ejecucion de los flujos de trabajo fundamentales, de requisitos

a pruebas .

14.4.1. Recopilar los requisitos .

14.4.2. Analisis .

14.4.3. Discno .

14.4.4. Implementacion .

14.4.5. Pruebas .

Desarrollo del analisis delnegocio .

14.5.1. Preparar 18 apuesta economica .

14.5.2. Actualizar la recuperacion de la inversion .

Evaluacion de las iteraciones de la rase de elaboracion .

Planificacion de la fuse de construccion .

Productos clave .

349 349 350

350 351 353 357 360 361 363 363 363 364 364 365

Capitulo 15: La construcclon lIeva ala capacidad operaclon inicila . 367

15.1. 15.2.

15.3. 15.4.

La fase de construccion en poe as palabras .

Al eomienzo de la fuse de construccion .

15.2.1. Asignaci6n de personal para la fase .

15.2.2. Establecimiento de los eriterios de evaluacion .

Flujo de trabajo arquctipico de una iteracion en la fase de construeci6n . Ejecuei6n de los tlujos de trabajo fundamentales, de requisitos

a pruebas .

15.4.1. Requisitos .

367 368 368 369 370

371 372

15.5. 15.6. 15.7. 15.S.

CONTENIDO XIII

15.4.2. 15.4.3. 15.4.4. 15.4.5.

Analisis .

Diseiio .

Implementacion .

Pruebas .

373 374 375 377 378 37S 379 379

Capitulo 16: La translclon completa la version del producto . . . . . . . 3g I

16.1. 16.2.

16.3.

16.4.

16.5.

16.6.

16.7. 16.8.

Control del analisis de negocio .

Evaluacion de las iteraciones y de la fase de construccion .

Pluni licucion de la fasc de transicion .

Productos clave .

La rase de transicion en pocas palabras .

Al cornienzo de la rase de transicion .

16.2. I. Planificacion de la fase de transicion .

16.2.2. Asignacion de personal para la fase .

16.2.3. Establecimiento de los critcrios de evaluacion .

Los tlujos de trabajo fundamentales descmperian un papel pequefio

en esta fase .

Lo que se hace ell la fase de transicion .

16.4.1. Preparacion de la version beta .

16.4.2. Instalacion de la version beta .

16.4.3. Rcaccion a los resultados de las pruebas .

16.4.4. Adaptacion del producto a entornos de usuario variados .

16.4.5. Finalizacion de los artefactos .

16.4.6. j,Cuando acaba eI proyecto? .

Finalizacion del analisis del negocio .

16.5. I. Control del progreso .

16.5.2. Revision del plan del ncgocio " .

Evaluacion de la fase de transicion .

16.6.1. Evaluacion de las iteraciones y de la fase .

16.6.2. Autopsia del proyecto .

Planificacion de 1.1 proxima version 0 generaci6n .

Productos clave .

382 383 383 384 3g5

3SS 386 387 387 3gS 3g8 390 390 391 391 391 391 392 392 393 393

Capitulo 17: Como hacer que el Proceso Unificado funcione . . . . . . . . 395

17.1. EI Proceso Unificado ayuda a manejar la cornplejidad 395

17.1.1. Los objctivos del ciclo de vida 396

17.1.2. La arquitcctura del ciclo de vida. . . . . . . . . . . . . . . . . . . . . . . 396

17.1.3. Capacidad opcrativa inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

17.1.4. Lanzamiento del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

17.2. Los temas importantes ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

17.3. La direccion lidera la conversion al Proceso Unificado 398

17.3.1. La necesidad de actuar 399

17.3.2. La directriz de reingeniena . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

17.3.3. Irnplementacion de la transici6n . . . . . . . . . . . . . . . . . . . 400

17.4. Especializacion del Proceso Unificado 402

17.4.1. Adaptacion del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

17.4.2. Completando el marco de trabajo del proceso 403

17.S. Relacion con comunidades mas amplias 403

XIV CONTENJDO

17.6. Obtenga los beneficios del Proceso Unificado 404

17.7. Referencias............................................... 405

Apendice A: Vision general del UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

A.l. Introducci6n 407

A.I .1 . Vocabulario........................................ 408

A,1.2. Mecanismos de extensibilidad .. . . . . . . . . . . . . . . . . . . . . . . . 408

A.2. Notaci6n grafica 409

A.2.1. Casas estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

A.2.2. Elementos de comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . 410

A.2.3. Elementos de agrupacion 411

A.2.4. Elementos de anotacion 411

A,2.5. Relaciones de dependencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

A.2.6. Relaciones de asociacion 411

A,2. 7. Relaciones de generalizaci6n . . . . . . . . . . . . . . . . . . . . . . . 412

A.2.8. Mecanismos de extensibilidad 412

A.3. Glosario de terrninos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

A.4. Referencias............................................... 418

Apendlce B: Extensiones del UML especificas del Proceso

Unificado 419

B.l. Introducci6n 419

B.2. Estereotipos............................................... 419

B.3. Valores etiquetados 422

BA. Notacion grafica 424

B.5. Referencias 424

Apendlce C: Glosario general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

C.I . Introduccion 425

C.2. Terminos................................................. 425

Indice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Pre facio

Hay gente que cree que las empresas profesionales deberfan organizarse en torno a las habilidades de individuos altamente cualificados, que saben como hacer el trabajo y 10 haeen bien, y que raramente necesitan direccion sobre las politicas y procedimientos de la organizacion para la que trabajan.

Esta creencia es una equivocacion en la mayorfa de los casos, y una grave equivocacion en el caso del desarrollo de software. Por supuesto, los desarrolladores de software estan altamente cualificados, pero la profesion es min joven. En consecuencia, los desarrolladores necesitan direccion organizativa, a la cual, en este libro, llamamos "proceso de desarrollo de software". Ademas, debido a que el proceso que ponemos en marcha en este libro representa la union de metodologfas antes separadas, nos sentimos justificados al llamarlo "Proceso Unificado". No s610 reline el trabajo de tres autores, sino que incorpora numerosas aportaciones de otras personas y empresas que han contribuido a UML. asf como un mimero significativo de aportaciones fundamentales de personas en Rational Software Corporation. Surge de manera especial de la cxperiencia directa de cientos de organizaciones que han trabajado en sus oficinas con las primeras versiones del proceso.

Un director de una orquesta sinfonica durante un concierto hace poco mas que decir a los musicos cuando comenzar y ayudarles a tocar juntos. 13,1 0 ella no puede hacer mas porque ha dirigido ala orquesta durante los ensayos y la preparacion de las partituras, y porque cada rmisieo esta muy preparado en su propio instrumento yen realidad 10 toea de manera independiente del resto de los otros miembros de la orquesta. Lo que es mas importante para nuestros propositos, cada rmisico sigue un "proceso" disefiado hace mucho tiempo por el compositor. Es la partitura rnusical la que proporciona el grueso de "la politica y el procedimiento" que gufan el concierto. En contraste, los desarrolladores de software no trabajan de manera independiente; interaccionan unos con otros y con los usuarios. No tienen una partitura -mientras no tengan un proceso.

XVI PREFACIO

La necesidad de un proceso promete hacerse mas critica, especialrnente en empresas u organizaciones en las cuales los sistemas software son esenciales, tales como las financicras, las de control de trafico aereo, las de defensa y las de sistemas de telecornunicaciones, Con esto queremos decir que la direccion con exito del negocio 0 la ejecuci6n de la mision publica depende del software que la so porta. Estos sistemas software se hacen nuts complejos, su tiempo de salida al mercado necesita reducirse, y su desarrollo, por tanto, se hace mas diffcil. Por razones como estas, la industria del software necesita un proceso para guiar a los desarrolladores, al igual que una orquesta necesita la partitura de un compositor para dirigir cl concierto,

l.Que es un proceso de desarrollo de software?

Un proceso define quien esta haciendo que, cudndo, y U)I110 alcanzar un determinado objetivo, En 1a ingenierfa del software el objetivo es construir un producto software 0 mejorar uno cxistente. Un proccso efectivo proporciona norm as para cl desarrollo eficientc de software de calidad. Captura y presenta las mejores practicas que el estado actual de la tecnologfa permite. En consecuencia, reduce el riesgo y hace el proyecto mas predecible, El efecto global es el fomento de una vision y una cultura eomunes.

Es neccsario un proceso que sirva como gufa para todos los participantes --clientes, usuarios, desarrolladores y directores ejecutivos, No nos sirve ningiin proceso anti guo; necesitamos uno que sea el mejor proceso que la industria pueda reunir en este punto de su historia. Por ultimo, necesitamos un proeeso que estc ampliamente disponible de forma que todos los interesados puedan cornprender su papel en el desarrollo en el que se encuentran implieados.

Un proceso de desarrollo de software deberia tarnbien ser eapaz de evolucionar durante muchos afios. Durante esta evolucion deberia limitar su alcance, en un momenta del tiempo dado, a las realidades que permitan las tecnologfas, herramientas, personas y patrones de organizacion.

• Tecnologias, EI proceso debe construirse sabre las tecnologfas -Icnguajes de program acion, sistemas operativos, computadores, estructuras de red, cntornos de desarrollo, etc.disponibles en el momenta en que sc va a ernplear el proeeso. Por ejemplo, hace veinte afios el model ado visual no era real mente de uso general. Era demasiado caro. En aquellos tiempos, un creador de un proceso practicarnente tenia que asumir que se usarfan diagramas hechos a mano. Esa suposicion limitaba rnucho el grado en el cual el creador del proceso podia establecer el modelado dcntro del proceso,

• Herramientas. Los procesos y las herrarnientas deben desarrollarse en paralelo. Las herramientas son esenciales en el proceso. Dicho de otra forma, un proceso ampliamente utilizado puede soportar la inversion nccesaria para crear las herramientas que 10 soporten.

• Personas. Un creador del proceso debe lirnitar el conjunto de habilidades necesarias para trabajar en el proceso a las habilidades que los desarrolladores actuales poseen, 0 apuntar aquellas que los desarrolladores puedan obtener rapidarnente, Hoy es posible empotrar en herrarnientas software tecnicas que antes requerian arnplios conocimientos, como la comprobacion de la consistencia en los diagram as del rnodelo.

• Patrones de organizacion. Aunque los desarrolladores de software no pueden ser expertos tan independientes como los rmisicos de una orquesta, estan muy lejos de los trabajadores autornatas en los cuales Frederick W. Taylor baso su "direccion cientffica" hace cien alios. E1 creador del proceso debe adaptar el proceso a las realidades del momento

PREFACIO

XVII

-hechos como las emprcsas virtuales: el trabajo a distancia a traves de lineas de alta velocidad; la mezcla (en empresas pequefias recien montadas) de socios de la empresa, empleados asalariados, trabajadores por obra, y subcontratas de outsourcing; y la prolongada escascz de desarrolladores de software.

Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias. Ademas, el equilibrio debe estar presente no solo ahara, sino tambien en el futuro. EI creador del proceso debe disefiar el proceso de forma que pueda evolucionar, de igual forma que el desarrollador de software intenta desarrollar un sistema que no solo funciona este afio, sino que evoluciona con exito en los afios venideros. Un proceso debe madurar durante varios afios antes de alcanzar el nivel de estabilidad y madurez que Ie permitira resistir a los rigores del desarrollo de productos cornerciales, manteniendo a la vez un nivel razonable de riesgo en su utilizacion. EI desarrollo de un producto nuevo es bastante arriesgado en sf mismo como para afiadirle el riesgo de un proceso que este poco validado por la experiencia de su uso. En estas circunstancias, un proceso puede ser estable. Sin esle equilibrio de tecnologfas, herramientas, personas y organizacion, el uso del proceso serta bastante arriesgado.

Objetivos de este libro

Este libro presenta el proceso de desarrollo que estuvo constantemente en nuestras cabezas mientras desarrollabarnos el Lenguaje Unificado de Modelado. Aunque UML nos ofrece un modo estandar de visualizar, especificar, construir, documentar y comunicar los artefactos de un sistema muy basado en el software, por supuesto somos conscientes de que un lenguaje como estc debe utilizarse en el contexto de un proceso de software completo. UML es un medio, y no un fin. EI objetivo final es una aplicacion software robusta, flexible y esealable. Es necesario tanto un proceso como un lenguaje para poder obtenerla, y el objetivo de este libro es mostrar la parte del proceso. Aunque proporcionamos un breve apendice sobre UML, no pretende ser completo ni detaIl ado. Para un tutorial detallado sobre UML, remitimos a El Lenguaje Unificado de Modelado, traduccion de la Guia de Usuario del Lenguaje Unificado de Mode/ado [Ill. Para una referencia completa de UML remitimos al Lenguaje Unificado de Modelado Manual de Re[erencia l12].

Audiencia

Este libro esta destinado a cualquier persona irnplicada en el desarrollo de software. Se dirige principalmente a miernbros del equipo de desarrollo que se dedican a las siguientes actividades del ciclo de vida: requisites, analisis, disefio, implernentacion y pruebas -es decir, a trabajos que producen modelos UML. Asi, por ejemplo, este libro es util para analistas y usuarios finales (que especifican la estructura y comportamiento requeridos por el sistema), para desarrolladores de aplicaciones (que disefian los sistemas que satisfaccn esos requisitos), para programadores (que conviertcn esos disefios en codigo ejecutable), para ingenieros de prueba (que verifican y validan la estructura y comportamiento del sistema), para desarrol1adores de cornponentes (que crean y catalogan cornponentes), )l para directores de proyecto y de producto.

Este libro presupone un conocirniento basico de conceptos de orientaci6n a objetos. Tambien es iitil, pero no se requiere, experiencia en desarrollo de software y en algun lenguaje orientado a objetos.

XVIII

PREFACIO

Metodo del Ii bro

Hemos dedicado la mayorfa del espacio de este libro a aquellas actividades -requisitos, anal isis y disefio- sobre las cuales UML hace mayor hincapie, Es en esas areas de mayor enfasis en las que el proceso desarrolla la arquitectura de sistemas software complejos. Sin embargo, tratamos el proceso completo, aunque con menos detalle. No en vano, es el programa ejecutable el que se ejecuta finalmente. Para llegar hasta el, un proyecto depende de los esfuerzos de cada miembro del equipo, as! como del soporte de los usuarios. Como se vera, el proceso descansa en una tremenda variedad de actividades. Es necesario producir y hacer el seguimiento de muchos artefactos. Todas las actividades deben gestionarse.

EI tratamiento completo del ciclo del cicIo de vida queda fuera de la intenci6n de cualquier libro. Un libro que 10 hiciese tendrfa que cubrir normas de disefio, plantillas para los artefactos, indicadores de calidad, gestion del proyecto, gestion de la configuracion, rnetricas y mas, jmucho mas! Con el desarrollo del acceso interactivo, ese "mas" esta hoy disponible, y puede actualizarse segiin dicten los nuevos avances. Por esto, remitimos allector al Proceso Unificado de Rational, un producto software que puede utilizarse desde la Web, que orienta a los equipos de desarrollo hacia practicas de desarrollo de software mas efectivas. (Consultar para mas informacion http://www.rational.com.) Al cubrir el ciclo de vida cornpleto, el Proceso Unificado de Rational extiende el Proceso Unificado mas alla de las areas descritas en este libra y ofrece f1ujos de trabajo adicionales que este libro no cubre 0 que menciona s610 de pasada, como el modelado del negocio, la gestion del proyecto, y la gestion de la configuracion.

Historia del Proceso Unificado

El Proceso Unificado esta equilibrado por ser el producto final de tres decadas de desarrollo y uso practice. Su desarrollo como producto sigue un camino (vease la Figura P.l) desde el Proceso Objectory (primera publicacion en 1987) pasando por el Proceso Objectory de Rational (publicado en 1997) hasta el Proceso Unificado de Rational (publicado en 1998). Su desarrollo

EI metodo de Rational

Otras fuentes

UMl

EI rnatodo de Ericsson

Figura P.l. El desarrollo del Proceso Unificado (las versiones del producto se muestran en rectangulos coloreados en gris).

PREFACIO XIX

ha recibido influencias de muchas fuentes. No pretendemos tratar de identificarlas todas (realmente no sabemos cuales son todas), trabajo que dejamos ala investigaci6n de los arqueologos del software. Sin embargo, describiremos la inf1uencia sobre el producto de los metodos de Ericsson y de Rational, asf como el de varias otras fuentes.

EI metoda de Ericsson

El Proceso Unificado posee rakes profundas. En palabras de Peter F. Drucker, es una "innovacion basada en el conocimiento", EI nos informa de que "hay un lapso de tiempo prolongado entre la emergencia del nuevo conocimiento y su destilacion en tecnologfa utilizable". "Entonces, sucede otro largo periodo antes de que esta nueva tecnologfa aparece en el mercado en productos, procesos 0 servicios." [11

Un motivo para este largo tiempo de aparici6n es que la innovaci6n basada en el conocimiento se cimienta en la uni6n de muchos tipos de conocimiento, y esto Ileva su tiempo. Otra raz6n es que las personas que tienen que hacer efectiva la nueva idea necesitan tiempo para digerirla y comunicarla a los dernas.

Como primer paso hacia el alumbramiento del desarrollo del Proceso Unificado, nos remontaremos a 1967 para esbozar los logros de Ericsson [14], [15], [16]. Ericsson modelaba el sistema entero como un conjunto de bloques interconectados (en UML, se los conoce como "subsisternas" y se implementan mediante "componentes"). Despues, ensamblaba los bloques de mas bajo nivel en subsisternas de mas alto nivel, para hacer el sistema mas rnanejable. ldentificaban los bloques estudiando los casos de negocio -hoy conocidos como "cases de uso"-, previamente especificados. Para cada caso de uso, identificaban los bloques que deb fan cooperar para realizarlo. Con el conocimiento de las responsabilidades de cada bloque, preparaban su especificacion. Sus actividades de disefio producfan un conjunto de diagramas de bloques estaticos con sus interfaces, agrupados en subsistemas. Estos diagramas de bloques se corresponden directamente con una versi6n simplificada de los diagramas de clases 0 paquetes de UML -simplificados en que solo mostraban las asociaciones que se utilizaban para cornunicaciones.

EI primer producto del trabajo de las actividades de disefio era una descripcion de arquitectura software. Se basaba en la comprensi6n de los requisitos mas crfticos, y describia brevemente cada bloque y su agrupamiento en subsisternas. Un conjunto de diagramas de bloques describfan a los bloques y a sus interconexiones. Sobre las interconexiones se comunicaban sefiales, es decir, un tipo de mensaje. Todos los mensajes quedaban descritos, uno par uno, en una biblioteca de mensajes, La descripci6n de la arquitectura software y la biblioteca de mensajes eran los documentos fundarnentales que guiaban el trabajo de desarrollo, pero tarnbien se utilizaban para presentar el sistema a los clientes. En aquellos momentos (1968) los c1ientes no estaban acostumbrados a que les presentasen los productos software por medias similares a los datos de proyectos de ingenieria.

Para cada caso de uso, los ingenieros preparaban bien un diagrama de secuencia 0 bien un diagrama de colaboraci6n (hoy desarrollados adicionalmente en UML), Estos diagramas rnostraban como los bloques se comunicaban dinarnicamente para llevar a cabo el caso de uso. Preparaban una especificacion en forma de grato de estados (que inclufa solo estados y transiciones) y un grafo de transicion de estados (una version simplificada de los diagramas de actividad de UML). Este metodo, el disefiar a partir de bloques can interfaces bien definidos, fue la clave del exito, De ese modo, se podia crear una nueva configuracion del sistema -por ejemplo, para un cliente nuevo -intercambiando un bloque por otro que proporcionase las mismos interfaces.

XX PREFACIO

Par tanto, los bloques no eran solo subsisternas y componentes de codigo Fuente; sc compilaban en bloques ejecutables, se instalaban en la maquina destino uno por uno, y se eomprobaba que funcionaban con el resto de los bloques ejecutables, Es mas, debfa ser posible instalar eada bloque ejecutable, nuevo 0 rnodificado, sobre la marcha en LIn sistema en ejecucion, mientras este gestionaba llamadas de sistemas de telefonfa en operacion durante el 100 por ciento del tiempo. No se puede parar sistemas de esc tipo solo para haeer eambios. Seria como carnbiar las rued as a un coehe que circula a 100 kilometres par hora.

En esencia, eI metodo que utilizaban era el que hoy conocemos como desarrollo basado en componentes. Ivar Jacobson fue el creador de cste rnetodo de desarrollo. £1 dirigio su evolucion hacia un proccso de desarrollo de software durante muchos anos en el periodo anterior a Objectory.

EI Lenguaje de Descrlpclon y Especificacion

Un avance significativo durante este periodo fue la publicacion en 1976 por parte del CCIlT, el organismo internacional para la estandarizacion en el area de las telecomunicaciones, del Lenguaje de Especificacion y Descripci()11 iSpecification and Description Language, SDL) para el comportamiento funcional de los sistemas de telecornunicacion. Este estandar, influenciado significativarnente par el metoda de Ericsson, especificaba un sistema como un conjunto de bloques interconectados que se cornunicaban unos con otros unicamentc a traves de mensajes (llamados "sefiales" en el estandar). Cada bloque poseia un conjunto de "proccsos", que era el terrnino SDL para designar las clases activas. Un proceso poscfa instancias de manera muy parecida a como 10 hacen las clascs en terminos de orientacion a objetos. Las instancias de los procesos interactuaban mediante mensajes. SDL proponfa diagramas que cran especializaciones de 10 que hoy UML llama diagramas de clases, diagrarnas de actividad, diagramas de colaboracion y diagrarnas de secuencia.

POf tanto, SDL era un estandar de modelado de objetos especializado. Se actualiza periodicamente, y todavia 10 utilizan mas de 10.000 dcsarrolladores y cuenta con el soporte de varios fabricantes de herrarnientas, Fue desarrollado iniciulmente hace veinte anos, y estaba rnuy por delante de xu tiempo. Sin embargo, se desarrollo en un momenta en el cual el modelado de objetos no habia rnadurado. Probablemente, SDL sera sustituido por UML, que se estandurizo en 1997.

Objectory

En 1987 Ivar Jacobson dejo Ericsson y fundo Objectory AB en Estocolmo. Durante los siguientes ocho afios, cl y sus colaboradores desarrollaron un proceso denorninado Objectory C'Objectory" es una ahreviatura de "Object Factory", fabrica de objetos). Extendieron SlI uso en otras industrias adcmas de las de tclccomunicaciones, y en otros pafses aparte de Suiza,

Aunque el concepto de C(lSO de uso habia estado presente en el trabajo de Ericsson, ahora se lc habia dado un nombrc (que sc prcscnto en la conferencia OOPS LA de 1987), se habia desarrollado una tecnica de representacion, y la idea se habfa ampliado para abarcar una variedad de aplicaciones. Es decir, los cases de uso que dirigfan el desarrollo se hicieron mas claros, Dicho de otro modo, la arquitectura que conduce a los desarrolladores e informa a los usuarios cornenzo a destacar.

PREfACIO XXI

Los flujos de trabajo sucesivos se representaron en una serie de modelos: requisitos-casos de usn, analisis. diseiio, implementaci6n y prueba. Un modelo es una perspectiva del sistema. Las relaciones entre los modclos de esta serie eran importantes para los desarrolladores como forma de haccr cI scguirniento de una caractcnstica de un extreme a otro de la serie de rnodelos. De hecho, la trazabilidad se convirtio en un prerrequisito del desarrollo dirigido por cases de uso. Los desarrolladores podtan seguir la traza de un caso de uso a traves de la secuencia de modelos hasta el codigo fuente 0 bien, cuando surgfan problemas, volver hacia arras.

EI desarrollo del proceso Objectory continu6 en una serie de versiones, desde Objectory 1.0 en 1988 a la primera version intcractiva, Objcctory 3.8, en 1995 (pucde consultarse una vision general de Objectory en l2j).

Es importante hacer notar que el propio producto Objectory lIeg6 a ser visto como un sistema. Esta forma de describir un proceso ---como un producto en forma de sistema- proporcionaba una manera mejor de desarrollar una nueva versi6n de Objectory a partir de una anterior. Este modo de desarrollar Objectory hizo mas facil el ajustarlo para cubrir las necesidades expecfficas de diferentes organizaciones de desarrollo. El hecho de que el propio proceso de desarrollo de software Objcctory era un producto de ingenicna era una caracteristica (mica.

La experiencia en el desarrollo de Objectory tarnbien aporto ideas sobre como disefiar los pmcesos generales sobre los cuales opera un negocio. Eran aplicables los misrnos principios y estos se recogieron en un libro en 1995 [3].

EI rnetodo de Rational

Rational Software Corporation cornpro Objectory AB a finales de 1995 y la tarea de unificar los principios basicos subyacentes en los procesos de desarrollo existentes adquirio una urgencia especial. Rational habfa desarrollado algunas practicas de desarrollo de software, la mayoria de ellas complernentarias a las contenidas en Objectory.

Por cjcrnplo, como recordaron James E. Archer Junior y Michael T. Devlin en 1986 l4j. "En 1981. Rational se dispuso a crear un entorno interactive que mejoraria la productividad en el desarrollo de grandcs sistemas software". A eontinuaci6n dijeron que en este esfucrzo, eran importantes cl disciio orientado a objetos, la abstraccion, la ocultacion de la informacion, la rcutilizacion y el prototipado,

Muchos Iibros, artfculos y documentos internos detallan los desarrollos de Rational desde 198 L pero quiza las dos contribuciones mas irnportantes al proceso fueron los enfasis en la arquitectura y en el desarrollo iterativo. Por ejernplo, en 1990, Mike Devlin escribio un articulo introductorio sobre un proceso de desarrollo iterative dirigido por la arquitectura. Philippe Kruchten, a cargo de la division de Practicas de Arquitcctura en Rational, firma articulos sobrc lu iteracion y la arquitectura.

Mencionaremos uno de ellos, un artfculo sobre una representacion de la arquitectura con cuatro vistas: la vista 16gica. la vista de procesos, la vista flsica, y la vista de desarrollo, mas una vista adicional que ilustraba las primeras cuatro vistas mediante casos de uso 0 escenarios [6]. La idea de tcner un conjunto de vistas, en lugar de tratar de meter todo en un iinico tipo de diagrarna, nacio de la experiencia de Kruchten en varios proyectos grandes. Las vistas multiples permitieron encontrar, tanto a los usuaries como a los desarrolladores, 10 que necesitaban para sus diferentes objetivos con la vista adecuada.

XXII PREFACIO

Hay gente que percibe el desarrollo iterativo como algo caotico 0 anarquico. El metodo de cuatro fases (comienzo, elaboracion, construccion y transicion) se disefio para estructurar mejor y controlar el proceso durante las iteraciones. La planificacion detallada de las fases y la ordenacion de las iteraciones dentro de las fases fue un esfuerzo conjunto entre Walker Royce y Rich Reitman, junto con la participacion continua de Grady Booch y Philippe Kruchten.

Booch estaba presente desde los principios de Rational, y en 1996 en uno de sus libros menciono dos "principios fundarnentales" sobre la arquitectura y la iteracion:

• "Un estilo de desarrollo dirigido por la arquitectura es normalmente la mejor aproximacion para la creacion de la mayoria de los proyectos complejos muy basados en el software."

• "Para que un proyecto orientado a objetos tenga exito, debe aplicarse un proceso iterativo e incremental." [7]

EI Proceso Objectory de Rational: 1995-1997

En el momenta de la fusion, Objectory 3.8 habia demostrado que se puede crear y modelar un proceso de desarrollo software como si fuese un producto. Habfa disefiado la arquitectura original de un proceso de desarrollo software. Habla identificado un conjunto de modelos que documentaban el resultado del proyecto. Estaba correctamente desarrollado en areas como el modelado de casos de uso, analisis y disefio, aunque en otras areas -gestion de requisites aparte de los cases de uso, implernentacion y pruebas-no estaba tan bien desarrollado. Adernas, decfa poco sobre gestion del proyecto, gestion de la configuracion, distribucion, y sobre la preparacion del entorno de desarrollo (obtencion del proceso y las herramientas).

Por ella se le anadieron la experiencia y practicas de Rational para formar el Proceso Objectory de Rational 4.1. Se afiadieron, en concreto, las fases y la aproximacion iterativa controlada. Se hizo explicita la arquitectura en forma de una descripcion de la arquitectura -la "Biblia" de la organizacion de desarrollo de software.

Se desarrollo una definicion precisa de la arquitectura, considerada como la parte mas significativa de la organizacion del sistema. Representaba la arquitectura como vistas arquitectonicas de los modelos. Se amplio el desarrollo iterativo, pasando de ser un concepto relativamente general a ser un metoda dirigido por los riesgos que consideraba la arquitectura en primer lugar.

En estos momentos, UML estaba en fase de desarrollo y se incorporo como cl lenguaje de model ado del Proceso Objectory de Rational (Rational Objectory Process, ROP). Los autores de este libro colaboraron como creadores originales de UML. El equipo de desarrollo del proceso, liderado por Philippe Kruchten, corrigio aJgunas de las debilidades del ROP reforzando, por ejemplo, la gestion del proyecto, basada en aportaciones de Royce [8].

EI Lenguaje Unificado de Modelado

Era evidente desde hace algun tiempo la necesidad de un lenguaje de model ado visual y consistente, en el cual expresar los resultados de las bastante numerosas metodologfas de orientacion a objetos existentes a principios de los noventa.

Durante este periodo, Grady Booch, por ejemplo, era el autor del metoda Booch [91, y James Rumbaugh era el desarrollador principal de OMT (Object Modelling Technique) [IOJ creado en

PREFACIO

XXIII

el Centro de Investigacion y Desarrollo de General Electric. Cuando este ultimo se incorporo a Rational en Octubre de 1994, los dos comenzaron el trabajo de unificar sus rnetodos, en coordinacion con muchos de los clientes de Rational. Publicaron la version 0.8 del Metodo Unificado en Octubre de 1995, casi en el mismo momenta de la incorporacion de Ivar Jacobson a Rational.

Los tres, trabajando juntos, publicaron la version 0.9 del Lenguaje Unificado de Modelado.

El esfuerzo se ampli6 para incluir a otros metodologistas, aSI como a diversas empresas, que inclufan a IBM, HP y Microsoft, cada una de las cuales contribuy6 al estandar en evoluci6n. En noviembre de 1997, despues de pasar por el proceso de estandarizacion, el Object Management Group publico como estandar la version 1.1 del Lenguaje Unificado de Modelado. Rernitimos a la Guia de Usuario [IIJ y al Manual de Referenda [12J para obtener informacion detallada.

El Proceso Objectory de Rational utilize UML en todos sus modelos.

EI Proceso Unificado de Rational

Durante este periodo, Rational compro 0 se fusiono a otras empresas fabricantes de herramientas. Cada una de ellas aporto a la mezcla su experiencia en areas del proceso que ampliaron mas aiin el proceso Objectory de Rational:

• Requisite Tnc. aporto su experiencia en gestion de requisitos.

• SQA Inc. habfa desarrollado un proceso de prueba para acornpafiar a su producto de

pruebas, y 10 anadio a la dilatada experiencia de Rational en este campo.

• Pure-Atria anadio su experiencia en gesti6n de configuraci6n a la de Rational.

• Performance Awareness anadio las pruebas de rendimiento y las de carga.

• Vigortech afiadio su experiencia en ingenierfa de datos.

EI proceso tam bien se ampli6 can un nuevo flujo de trabajo para el model ado del negocio, basado en [3J, que se utiliza para obtener los requisitos a partir de los procesos de negocio que el software va a cubrir. Tambien se extendio con disefio de interfaces de usuario dirigido por los casos de uso (basado en el trabajo de Objectory AB).

A mediados de 1998 el Proceso Objectory de Rational se habia convertido en un proceso hecho y derecho, capaz de soportar el cicio de vida del desarrollo en su totalidad. Para ello, integraba una amplia variedad de aportaciones, no solo de los tres autores de este libro, sino de las muchas fuentes sobre las cuales sobre las cuales se basaron Rational y UML. En junio, Rational publico una nueva version del producto, el Proceso Unificado de Rational 5.0 [13]. En ese momento, por primera vez, se pusieron a disposici6n del publico en general muchos elementos de ese proceso propietario a traves de este libro.

El cambio de nombre retleja el hecho de que la unificacion ha tenido lugar en muchas dimensiones: unificacion de tecnicas de desarrollo, a traves del Lenguaje Unificado de Modelado, y unificaci6n del trabajo de muchos metodologistas ~no solo en Rational sino tambien en las oficinas de los cientos de c1ientes que llevaban utilizando el proceso muchos afios.

Agradecimientos

Un proyecto de esta magnitud es el fruto del trabajo de mucha gente, y nos gustarfa dar las gracias personal mente a tantos como sea posible.

XXIV

PREFACIO

Por aportaciones a este libro

Birgitte Lonvig prepare el ejemplo del sistema Interbank y 10 desarrollo en todos los modelos. Este es el ejemplo principal que utilizamos a 10 largo del libro.

Patrik Jonsson extrajo material de la documentacion del Proceso Objectory de Rational y 10 dispuso en el orden de los capitulos prupuestos. Tarnbien ayudo en la preparacion de los ejernplos, aportando much as ideas sobre la mejor manera de presentar el Proceso Unificado.

Ware Myers participo en el desarrollo de este libru desde el esquema inicial en adelante. Convirtio los primeros borradores preparados por el autor principal en prosa inglesa mas legible.

De los revisores agradecernos especialmente a Kurt Bittner, Cris Kobryn y Earl Ecklund, Jr.

Adernas, agradecemos principalmente las revisiones de Walker Royce, Philippe Kruchten, Dean Leffingwell, Martin Griss, Maria Ericsson y Bruce Katz. Tarnbicn fuerun revisores Pete McBreen, Glenn Jones, Johan Galle, N. Venu Gopal, David Rine, Mary Loomis, Marie Lenzi, Janet Gardner, y algunos revisores anonimos, a todos los cuales queremos dar las gracias.

Terry Quatrani de Rational mejoro el ingles de los Capftulos 1 al 5. Karen Tongish corrigio ellibro entero. Nuestros agradecimientos para ambos.

Queremos dar las gracias en particular a Stefan Bylund que reviso a conciencia los borradores y sugirio mejoras detalladas, muchas de las cuales se han incorporado. Sus aportaciones han aumentado considerablemente la calidad del libro.

Durante los aries

Tambien queremos dar las gracias a bastantes personas que nos han ayudado a "rnantcner al dia el proceso" y que han apoyado el trabajo de diversas maneras. En concreto, queremos dar las gracias a las siguientes personas: Stefan Ahlquist, Ali Ali, Gunilla Andersson, Kjell S. Andersson, Sten-Erik Bergner, Dave Bernstein, Kurt Bittner, Per Bjork, Hans Brandtberg, Mark Brorns, Stefan Bylund, Ann Carlbrand, Ingemar Carlsson, Margaret Chan, Magnus Christerson, Geoff Clernm, Catherine Connor, Hakan Dahl, Stephane Desjardins, Mike Devlin, Hakan Dyrhage, Susanne Dyrhage, Staffan Ehnebom, Christian Ehrenberg, Maria Ericsson, Gunnar M. Eriksson, lain Gavin, Carlo Goti, Sam Guckenheimer, Bjorn Gullbrand, Sunny Gupta, Marten Gustafsson, Bjorn Gustafsson, Lars Hallmarken, David Hanslip, Per Hedfors, Barbara Hedlund, Jorgen Hellberg. Joachim Herzog, Kelli Houston, Agneta Jacobson, Sten Jacobson, Paer Jansson, Hakan Jansson, Christer Johansson, Ingemar Johnsson, Patrik Jonsson, Dan Jonsson, Bruce Katz, Kurt Katzcff, Kevin Kelly, Anthony Kesterton, Per Kilgren, Rudi Koster, Per Kroll, Ron Krubeck, Mikael Larsson, Bud Lawson, Dean Leffingwell, Rolf Leidhammar, Hakan Lidstrom, Lars Lindroos, Fredrik Lindstrom, Chris Littlejohns, Andrew Lyons, Jas Madhur, Bruce Malasky, Chris McClenaghan, Christian Meek, Sue Mickel, Jorma Mobrin, Christer Nilsson, Rune Nilsson, Anders Nordin, Jan-Erik Nordin, Roger Oberg, Benny Odenteg, Erik Ornulf, Gunnar Overgaard, Karin Palmkvist, Fabio Peruzzi, Janne Pettersson, Gary Pollice, Tanya Prince, Leslee Probasco, Terry Quatrani, Anders Rockstrom, Walker Royce, Goran Schefte, Jeff Schuster, John Smith, Kjell Sorrne , Ian Spence, Birgina Spiridon, Fredrik Stromberg, Goran Sundelof, Per Sundquist, Per-Olaf Thysselius, Mike Tudball, Karin Villers, Ctirad Vrana, Stefan Wallin, Roland Wester, Lars Wetterborg, Brian White, Lars Wiktorin, Charlotte Wranne, y Jan Wunsche.

PREFACIO XXV

Adernas, las siguientes personas han ofrecido al autor principal su apoyo personal durante afios, por 10 cual me siento muy agradecido: Dines Bjorner, Tore Bingefors, Dave Bulman, Larry Constantine, Goran Hemdal, Bo Hedfors, Tom Love, Nils Lennrnarker, Lars-Olaf Noren, Dave Thomas, y Lars-Erik Thorelli.

Por ultimo, queremos dar las gracias en particular

A Mike Devlin, presidente de Rational Software Corporation, por su confianza en el proceso Objectory como un producto que ayudara a todos los desarrolladores de software del mundo, y pOI su apoyo constante en el uso de un proceso de software eficaz como guia para el desarrollo de hcrramientas.

Y por ultimo, querernos dar las gracias a Philippe Kruchten, director del Proceso Unificado de Rational. y a todos los miernbros del equipo del proceso Rational por haber integrado 10 mejor de Objectory con las mejores tecnicas de Rational y con UML, manteniendo ala vez sus valores individuales, Ademas, no podnamos haber conseguido este objetivo sin contar con el compromise personal de Philippe y con su perseverancia en la tare a de construir, sene ilia mente, cl mejor proceso de software nunca visto en el mundo.

EI proceso se abre camino

A 10 largo de cste libro, y del resto de los libros, versiones interactivas y herramientas relacionados, el proceso de desarrollo de software se hace mayor. EI Proceso Unificado tomo su inspiracion de muchas fuentes, y ya esta ampliamente difundido. Proporciona un sustrato comiin de comprension del proceso del cual pueden partir los desarrolladores, los directores y los usuarios.

Todavia queda mucho trabajo por hacer. Los desarrolladores deben aprender maneras unificadas de trabajar. Los clientes y los directivos deben apoyarlas. Para muchas empresas de desarrollo, el adelanto es s610 potencial. Usted puede hacerlo real.

Ivar Jacobson Palo Alto, California Diciembre de 1998 ivar@rational.com

Referencias

r I] Peter F. Drucker, "The Discipline of Innovation:' Harvard Business Review, May-June, 1985; reprinted Nov.-Dec. 1998, pp. 149-157.

[2J Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, ObjectOriented Software Engineering: A Use-Case Driven Approach, Reading, MA: AddisonWesley, 1992.

[31 Ivar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage: Business Process Reengineering with Object Technology, Reading, MA: Addison-Wesley, 1995.

[4) James E. Archer Jr. and Michael T. Devlin, "Rational's Experience Using Ada for Very Large Systems," Proceedings of the First international Conference on Ada Programming Language Applications [or the NASA Space Station, June, 1986.

XXVI

PRH'ACIO

l6J Philippe B. Kruchten, "The 4 + 1 View Model of Architecture", IEEE Software, November J 995, pp. 42-50.

L7J Grady Booch, Object Solutions: Managing the Object-Oriented Project, Reading, MA:

Addison-Wesley, 1996.

[81 Walker Royce, Software Project Management: A Unified Framework, Reading, MA:


[91 Grady Booch, Object-Oriented Analysis and Design with Applications, Redwood City, CA:

Benjamin/Cummings, 1994.

[10] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs, NJ: Prentice Hall, 1991.

[11] Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Reading, MA: Addison-Wesley. 1998.

[12] James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Reading, MA: Addison-Wesley, 1998.

[13J Philippe Kruchten, The Rational Unified Process: An Introduction, Reading, MA:


[14 J 1 var Jacobson, Concepts for Modeling Large Real Time Systems, Chapter 2, Dissertation, Department of Computer Systems, The Royal Institute of Technology, Stockholm, Sept. 1985.

lI5] Ivar Jacobson, "Object-Orientation as a Competitive Advantage", American Programmer, Oct. 1992.

[16J Ivar Jacobson, "A Large Commercial Success Story with Objects, Succeeding with Objects", Object Magazine, May 1996.

Parte I

I

, t"· r1

ad

a rro 1 ] ()

En esta Parte [ presentarnos las ideas fundamentales.

EI Capitulo 1 describe el Proceso Unificado de Desarrollo de Software brevemente, centrandose en su caracter dirigido por los casas de usa, centrado en la arquitectura, iterativo e incrementaL El proceso utiliza el Lenguaje Unificado de Modelado (UML), un lenguaje que produce dibujos comparables en sus objetivos a los esquemas que se utilizan desde hace mucho tiernpo en otras disciplinas tecnicas, EI proceso pone en practica el basar gran parte del proyecto de desarrollo en componentes reutilizables, es decir, en piezas de software can una interfaz bien definida.

EI Capitulo 2 introduce las cuatro "P": personas, proyecto, producto, y proceso, y describe sus relaciones, que son esenciales para la comprension del resto del libra. Los conceptos clave necesarios para comprender el proceso que cubre este libro son: artefacto, modelo, trabajador y.flujo de trabajo,

EI Capitulo 3 trata el concepto de desarrollo dirigido por casos de uso con mayor detalle. Los casos de uso son un media para determinar los requisitos correctos y utilizarlos para conducir el proceso de desarrol1o.

El Capitulo 4 describe el papel de la arquitectura en el Proceso Unificado. La arquitectura establece 10 que se tiene que hacer; esquematiza los niveles significativos de la organizacion del software y se centra en el armazon del sistema.

EI Capitulo 5 enfatiza la importancia de adoptar una aproximaci6n iterativa e incremental en el desarrollo de software. En la practica, esto se traduce en atacar primero las partes del sistema

2 EL PROCESO UNIFlCADO DE DESARROLLO DE SOFTWARE

cargadas de riesgo, obteniendo pronto una arquitectura estable, y completando despues las partes mas rutinarias en iteraciones succsivas, cada una de las cuales lleva a un incremento del progreso hasta la version final.

En la Parte II profundizaremos mas. Dedicarnos un capitulo a cada tlujo de trabujo fundamental: requisitos, analisis, diseiio, implernentacion y prueba. Estos flujos de trabajo se utilizaran despues en la Parte III como actividades importantes en los difercntes tipos de iteracion durante las cuatro fases en las que dividimos el proceso,

En la Parte III describimos en concreto como se lIeva a cabo el trabajo en cada fase: en la de inicio para obtener un anal isis del negocio, en la de elaboracion para crear la arquitecturu y hacer un plan, en la de construccion para aumentar la arquitectura hasta conseguir un sistema entregable, y en Ia de transicion para garantizar que cl sistema funciona correctarnente en el entorno del usuario. En esta parte, volvemos a utilizar los flujos de trabajo fundamentales y los combinamos de un modo ajustado a cada fase de manera que seamos capaces de alcanzar los resultados deseados.

La intcncion subyacente de una organizacion no es, sin embargo, tener un software bueno, sino adrninistrar sus procesos de negocio, 0 sistemas ernpotrados, de forma que Ie permita producir rapidarnentc bienes y servicios de alta calidad con costes razonables, en respuesta a las dernandas del rnercado. EI software es el anna estrategica con el cual las empresas 0 los gobiernos pueden conseguir en ormes reducciones en costes y tiempos de produccion tanto para bicnes como para servicios. Es imposible reaccionar con rapidez frente al dinamismo del mercado sin unos buenos procesos de organizacion establecidos. En el entorno de una econornia global que opera veinticuatro horas al dla, siete dias a la sernana, muchos de esos procesos no pueden funcionar sin el software. Un buen proceso de desarrollo de software es, por tanto, un elerncnto entice para el cxito de cualquier organizaci6n.

Capitulo 1

EI Proceso Unificado: dirigido por casos de uso, centrado

en la arquitectura, iterativo

e incremental

La tendencia actual en el software llcva a la construccion de sistemas mas gran des y mas cornplejos. Esto es debido en parte al hecho de que los eomputadores son mas potentes calla ario, y los usuaries, por tanto, esperan mas de ellos. Esta tendeneia tambien se ha visto afectada por el uso creciente de Internet para cl intercambio de todo tipo de informacion -de texto sin formato a texto con formate, fotos, diagrarnas y multimedia. Nuestro apetito de software min mas sofisticado crccc a medida que vemos como pueden mejorarse los productos de una version a otra, Qucremos un software que este mcjor adaptado a nuestras necesidades, pero csto, a su vcz, simplemente hace cl software mas complejo. En breve, querremos mas.

Tambien 10 queremos mas rapido. El tiempo de salida al mercado es otro conductor irnportante.

Conseguirlo, sin embargo, es diffcil. Nuestra demanda de software potente y complejo no se corresponde con como se desarrolla el software. Hoy, la mayoria de la gente desarrolla software mediante los mismos metodos que llcvan utilizandose desde haee 25 afios. Esto es un problema. A menos que renovemos nuestros metodos, no podremos cumplir con el objetivo de desarrollar el software complejo que se necesita actual mente.

El problema del software se reduce a la dificultad que afrontan los desarrolladores para coordinar las multiples cadenas de trabajo de un gran proyecto de software. La comunidad de desarrolladores necesita una forma coordinada de trabajar. Necesita un proceso que integre las multiples facctas del desarrollo. Necesita un rnetodo comiin, un proceso que:

4 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

• Proporcione una gufa para ordenar las actividades de un equipo.

• Dirija las tareas de cada desarrollador por separado y del equipo como un todo.

• Especifique los artefactos que deben desarrollarse.

• Ofrezca criterios para el control y Ia medici on de los productos y actividades del proyecto. La presencia de un proceso bien definido y bien gestionado es una diferencia esencial entre

proyectos hiperproductivos y otros que fracasan. (Vease Ia Seccion 2.4.4 para mas motivos por los cuales es necesario un proceso.) EI Proceso Unificado de Desarrollo -el resultado de mas de 30 afios de experiencia- es una solucion al problema del software. Este capitulo proporciona una vision general del Proceso Unificado completo. En posteriores capttulos, examinaremos cada elemento del proceso en detalle.

1.1.

EI Proceso Unificado en pocas palabras

En primer lugar, el Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software (vease la Figura 1.1). Sin embargo, el Proceso Unificado es mas que un simple proceso; es un marco de trabajo generico que puede especializarse para una gran variedad de sistemas software, para diferentes areas de aplicacion, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tarnafios de proyecto.

El Proceso Unificado esta basado en componentes, 10 cual quiere decir que el sistema software en construccion esta formado por componentes software (Apendice A) interconectados a traves de interfaces (Apendice A) bien definidas,

EI Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. De hecho, UML es una parte esencial del Proceso Unificado -sus desarrollos fueron paralelos.

No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres frases clave -dirigido por casos de uso, centrado en la arquitectura, e iterativo e incremental. Esto es 10 que hace unico al Proceso Unificado.

En las tres secciones siguientes describiremos esas tres frases clave. Despues, en el resto del capitulo, daremos una breve vision general del proccso: su cicio de vida, fases, versiones, iteraciones, flujos de trabajo, y artefactos. Toda la motivacion de este capitulo es la de presentar las ideas mas importantes y dar una "vista de pajaro" del proceso en su totalidad. Despues de este capitulo, el lector debe ria conocer, pero no necesariamente comprender en su totalidad, de que trata el Proceso Unificado, El resto dellibro cubrira los detalles. En el Capitulo 2 establecernos el contexto de las cuatro "P" del desarrollo de software: personas, proyecto, producto y proceso, Despues, dedicamos un capitulo a cada una de las tres ideas clave antes mencionadas. Todo esto constituira la primera parte del libro. Las Partes IT y III -el grueso del librodescribiran los distintos flujos de trabajo del proceso en detalle.

Proceso de desarrollo de Software

Requisitos del usuarlo

Sistema software

Figura 1.1. Un proceso de desarrollo de software.

1.2.

1.3.

EL PROCESO UNIFlCADO: DlRIGIDO POR CASOS DE usa, CENTRADO EN LA ARQUITECTURA... 5

EI Procesa Unificado esta dirigida par casos de usa

Un sistema software ve la luz para dar servicio a sus usuarios, Por tanto, para construir un sistema con exito debemos conocer 10 que sus futuros usuarios necesitan y desean.

EI termino usuario no s610 hace referencia a usuarios humanos sino a otros sistemas. En este sentido, el terrnino usuario representa alguien 0 alga (como otro sistema fuera del sistema en consideraci6n) que interacnia con el sistema que estamos desarrollando. Un ejemplo de interaccion serfa una persona que utiliza un cajero automatico. EI (0 ella) inserta la tarjeta de phistico, responde a las preguntas que le hace la maquina en su pantalla, y recibe una suma de dinero. En respuesta a la tarjeta del usuario y a sus contestaciones, el sistema lleva a cabo una secuencia de acciones (Apendice A) que proporcionan al usuario un resultado importante, en este caso, la retirada del efectivo.

Una interacci6n de este tipo es un caso de uso (Apendice A; vease tambien el Capitulo 3).

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casas de usa representan los requisitos funcionales, Todos los casos de usa juntos constituyen el modelo de casos de uso (Apendice B; vease tambien la Seccion 2.3), el cual describe la funcionalidad total del sistema. Puede decirse que una especificacion funcional contesta a la pregunta: i,Que debe hacer el sistema? La estrategia de los casos de uso puede describirse afiadiendo tres palabras al final de esta pregunta: i, ... para cada usuario? Estas tres palabras albergan una implicacion importante. Nos fuerzan a pensar en terminos de importancia para el usuario y no solo en terminos de funciones que seria buena tener. Sin embargo, los casas de uso no son s610 una herramienta para especificar los requisitos de un sistema. Tambien gufan su disefio, implernentacion, y prueba; esto es, guian el proceso de desarrollo. Basandose en el modelo de casos de usa, los desarrolladores crean una serie de model os de disefio e implernentacion que llevan a cabo los casas de uso. Los desarrolladores revisan cada uno de los sucesivos model os para que sean conformes al modelo de casos de uso. Los ingenieros de prueba prueban la implementacion para garantizar que los cornponentes del modelo de implementacion implementan correctamente los casas de uso. De este modo, los casas de uso no s610 inician el proceso de desarrollo sino que le proporcionan un hila conductor. Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hila -avanza a traves de una serie de flujos de trabajo que parten de los casos de usa. Los casas de uso se especifican, se disefian, y los casas de usa finales son la fuente a partir de la cuallos ingenieros de prueba construyen sus casas de prueba.

Aunque es cierto que los casos de uso gufan el proceso, no se desarrollan aisladamente. Se desarrolJan a la vez que la arquitectura del sistema. Es decir, los casas de uso gufan la arquitectura del sistema y la arquitectura del sistema influye en la seleccion de los casos de uso. Por tanto, tanto la arquitectura del sistema como los casas de uso maduran segiin avanza el ciclo de desarrollo.

EI Procesa Unificada esta centrado en la arquitectura

El papel de la arquitectura software es parecido al papel que juega la arquitectura en la construccion de edificios. El edificio se contempla desde varios puntas de vista: estructura, servicios, conduccion de la calefaccion, fontanerfa, electricidad, etc. Esto permite a un constructor ver una imagen completa antes de que comience la construccion. Analogamente, la arquitectura en un sistema software se describe mediante diferentes vistas del sistema en construccion,


EI concepto de arquitectura software incluye los aspectos estaticos y dinarnicos mas significativos del sistema. La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los inversores, y se retleja en los casas de usa. Sin embargo, tarnbien se ve intluida par muchos otros factores, como la plataforma en la que tiene que funcionar el software (arquitectura hardware, sistema operativo, sistema de gesti6n de base de datos, protocolos para comunicaciones en red), los bloques de construcci6n reutilizables de que se dispone (por ejempIa, un marco de trabajo (Apendice C) para interfaces graficas de usuario), consideraciones de implantacion, sistemas heredados, y requisites no funcionales (par ejemplo, rendimiento, fiabilidad). La arquitectura es una vista del disefio completo can las caracteristicas mas importantes resaltadas, dejando los detalles de Iado. Debido a que 10 que es significative depende en parte de una valoraci6n, que a su vez, se adquiere can la experiencia, el valor de una arquitectura depende de las personas que se hay an responsabilizado de su creaci6n. No obstante, el proceso ayuda al arquitecto a centrarse en los objetivos adecuados, como la cornprensibilidad, la capacidad de adaptaci6n al cambia, y la reutilizaci6n.

Leoma se relacionan los casos de usa y la arquitectura? Cada producto tiene tanto una funcion como una forma. Ninguna es suficiente por sf misma. Estas dos fuerzas deben equilibrarse para obtener un producto can exito, En esta situacion, la funci6n corresponde a los casos de uso y la forma a la arquitectura. Debe haber interaccion entre los casas de lIS0 y la arquitectura. Es un problema del tipo "el huevo y la gallina". Por un lado, los casas de uso deben encajar en la arquitectura cuando se lIevan a cabo. Por otro lado, la arquitectura debe permitir el desarrollo de todos los casas de usa requer idos, ahara y en el futuro. En realidad, tanto la arquitectura como los casas de usa deben evolucionar en paralelo.

Por tanto, los arquitectos moldean el sistema para darle unaforma. Es esta forma, la arquitectura, la que debe disefiarse para permitir que eI sistema evolucione, no s610 en su desarrollo inicial, sino tarnbien a Io largo de las futuras generaciones. Para encontrar esa forma, los arquitectos deben trabajar sobre Ia comprension general de las funciones clave, es decir, sabre los casos de uso claves del sistema. Estos casos de uso clave pueden suponer solamente entre el 5 y el 10 par ciento de todos los casas de uso, pero son los significativos, los que constituyen las funciones fundamentales del sistema. De manera resumida, podemos decir que el arquitecto:

• Crea un esquema en borrador de la arquitectura, comenzando par la parte de la arquitectura que no es especffica de los casas de usa (por ejernplo, la plataforma). Aunque esta parte de la arquitectura es independiente de los casos de uso, el arquitecto debe poseer una comprensi6n general de los casos de uso antes de comenzar la creacion del esquema arquitectonico,

• A continuacion, el arquitecto trabaja can un subconjunto de los casos de uso especificados, can aquellos que representen las funciones clave del sistema en desarrollo. Cada caso de uso seleccionado se especifica en detalle y se realiza en terminos de subsistemas (Apendice A; vease tambien Seccion 3.4.4), clases (Apendice A), y componentes (Apendice A).

• A medida que los casas de usa se especifican y maduran, se descubre mas de Ia arquitectura. Esto, a su vez, lIeva a la maduracion de mas casas de uso.

Este proceso continua hasta que se considere que la arquitectura es estable.

1.4.

EI Proceso Unificado es iteratlvo e incremental

El desarrollo de un proclucto software comercial supone un gran esfuerzo que puede durar entre varios meses hasta posiblemente un ana 0 mas. Es practice dividir el trabajo en partes mas

EL PROCESO UNIFICADO: DlRIGlDO POR CAS OS DE USO, CENTRADO EN LA ARQUITECTURA... 7

pequefias 0 miniproyectos. Cada miniproyecto es una iteracion que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Para una efectividad maxima, las iteraciones deber estar controladas; esto es, deben seleccionarse y ejecutarse de una forma planificada. Es par esto por 10 que son mini-prorectos.

Los desarrolladores basan la seleccion de 10 que se irnplementara en una iteracion en dos factores. En primer lugar, la iteracion trata un grupo de casos de uso que juntos amplfan la utilidad del producto desarrollado hasta ahora, En segundo lugar, la iteracion trata los riesgos mas importantes. Las iteraciones sucesivas se construycn sabre los artefactos de desarrollo tal como quedaron al final de la ultima iteracion. Al ser miniproyectos, comienzan con los casos de uso y continuan a traves del trabajo de desarrollo subsiguiente -amilisis, disefio, implernentacion y prueba-, que termina convirtiendo en codigo ejecutable los casos de uso que se desarrollaban en la iteraci6n. Por supuesto, un incremento no necesariamente es aditivo. Especialmente en las primeras fases del cielo de vida, los desarrolladores pueden tener que reemplazar un disefio superficial par uno mas detallado 0 sofisticado. En fases posteriores, los incrementos son tipicarnente aditivos.

En cada iteracion, los desarrolladores identifican y especifican los casos de uso relevantes, crean un disefio utilizando la arquitectura seleccionada como gufa, implementan el disefio mediante componentes, y verifican que los componentes satisfacen los cases de uso. SI una iteraci6n cumple con sus objetivos ---como suele suceder- el desarrollo continua con la siguiente iteraci6n. Cuando una iteracion no cumple sus objetivos, los desarrolladores deben revisar sus decisiones previas y probar con un nuevo enfoque.

Para alcanzar el mayor grado de economfa en el desarrollo, un equipo de proyecto intentara seleccionar s610 las iteraciones requeridas para lograr el objetivo del proyecto. Intentara secuenciar las iteraciones en un orden logico. Un proyecto con exito se ejecutara de una forma directa, solo con pequeiias desviaciones del curso que los desarrolladores planificaron inicialmente. Por supuesto, en la medida en que se afiadan iteraciones 0 se altere el orden de las mismas por problemas inesperudos, el proceso de desarrollo consumira mas esfuerzo y tiempo. Uno de los objetivos de la reduccion del riesgo es minimizar los problemas inesperados.

Son muchos los beneficios de un proceso iterative controlado:

• La ircracion controlada reduce el coste del riesgo a los costes de un solo incremento. Si los desarrolladores tienen que repetir la iteracion, la organizacion s610 pierde el esfuerzo mal empleado de la iteracion, no el valor del producto entero.

• La iteracion control ada reduce el riesgo de no saear al mercado el producto en el calendario previsto. Mediante la identificacion de riesgos en fases tempranas del desarrollo, el tiempo que se gasta en resolverlos se emplea al principio de la planificacion, cuando la gente csta menos presionada por cumpl ir los plazos. En el metodo "tradicional", en el cual los problemas complicados se revel an por primera vez en la prueba del sistema, el tiempo necesario para resolverlos normalmentc es mayor que el tiempo que queda en la plani ficacion, y casi siempre obliga a retrasar Ia entrega.

• La iteracion controlada acelera cl ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladorcs trabajan de manera mas efieiente para obtener resultados claros a corto plazo, en lugar de tener un calendario largo, que se prolong a eternamente.

• La iteraci6n controlada reconoce una realidad que a menudo se ignora -que las necesidades del usuario y sus correspondientes requisitos no pueden definirse completamente al


principio. Tfpicamente, se refinan en iteraciones sucesivas. Esta forma de operar hace mas facil la adaptaci6n a los requisitos cambiantes.

Estos conceptos -los de desarrollo dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental- son de igual importancia. La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mientras que los casos de usa definen los objetivos y dirigen el trabajo de cada iteracion, La eliminaci6n de una de las tres ideas reduciria drasticamente el valor del Proceso Unificado. Es como un taburete de tres patas. Sin una de elias, el taburete se cae.

Ahora que hemos presentado los tres conceptos clave, es el momento de echar un vistazo al proceso en su totalidad, su ciclo de vida, artefactos, flujos de trabajo, fases e iteraciones.

1.5.

La vida del Proceso Unificado

El Proceso Unificado se repite a 10 largo de una serie de ciclos que constituyen la vida de un sistema, como se muestra en la Figura 1.2. Cada cicio concluye con una version del producto (Apendice C; vease tambien el Capitulo 5) para los clientes.

Cada cicio consta de cuatro fases: inicio 1, elaboracion, construcci6n y transicion. Cada fase (Apendice C) se subdivide a su vez en iteraciones, como se ha dicho anteriormente. Viase la Figura 1.3.

Nacimiento

Muerte

I I

~\I

/

Tiempo

Los ciclos concluyen can una version

Figura 1.2. La vida de un proceso consta de ciclos dcsdc xu nacimiento hasta su muerte.

Tiempo

Itemcl6n #1

Iteracl6n

#n.,.

Inlelo

Elaboraelon

Construeci6n

Transicion

Versiones

Figura 1.3. Un ciclo con sus fascs c itcraciones,

I N. del T. Tarnbien se suele utilizur el termino "fase de comienzo".

EL PROCESO UNIFICADO: DlRIGlDO POR CASOS DE usa, CENTRA DO EN LA ARQUITECTURA... 9

1.5.1.

EI producto

Cada cicio produce una nueva version del sistema, y cada version es un producto preparado para su entrega. Consta de un cuerpo de codigo fuente incluido en componentes que puede cornpilarse y ejecutarse, ademas de manuales y otros productos asociados. Sin embargo, el producto terrninado no solo debe ajustarse a las necesidades de los usuaries. sino tambien a las de todos los interesados. es decir, toda la gente que trabajara con el producto. EI producto software deberia ser algo mas que el codigo maquina que se ejecuta.

El producto terminado incluye los requisitos, casos de usn, especificaciones no funcionales y casos de prueba. lncluye cl modelo de la arquitectura y el modelo visual -artcfactos modelados con el Lcnguaje Unificado de Modelado. De hecho, incluye todos los elementos que hemos mencionado en este capitulo, debido a que son esos elementos los que permiten a los interesados- clientes, usuarios, analistas. diseiiadores, programadores, ingenieros de prueba, y directores -especificar, disefiar, implementar, probar y utilizar un sistema. Es mas, son esos elementos los que permiten a los usuaries utilizar y modificar el sistema de generacion en gcneracion.

Aunque los componentes ejecutables sean los artefactos mas importantes desde la perspectiva del usuario, no son suficientes por sf solos. Esto se debe a que el entorno cambia. Se mejoran los sistemas operativos, los sistemas de bases de datos y las maquinas que los soportan. A medida que el objetivo del sistema se comprende mejor, los propios rcquisitos pueden cambiar. De hecho, el que los requisites cambien es una de las constantes del desarrollo de software. Al final, los desarrolladores deben afrontar un nuevo cicio, y los directores deben financiarlo, Para llevar a cabo el siguiente cicio de rnanera eficiente, los desarrolladores necesitan todas las representaciones del producto software (Figura 1.4):

~ £ ~~:~:~~~::::::::::::::::::-------

~ ~speclficad~"'~~r-"'",,, ...... ".......... ..." - -......... ... .............. _

Modelo de casos ~ A"" "'" "'" "'"

de uso / U" ' " " ",

to Q re~)izado par "'" ", "

" ~", t distribuida por

Q/ '<I "

EI ~ ,

E:(/ I /0,

"E1/EJ 0"01 /0 implementadopor ""

Modelo ~

Modelo

de despliegue / ~

~I ,,~/~

Modelo

de tmplernentaclon

Modelo

de anaflsls

, ,

de diseiio

V8fnicado po r

,

Modelo

de prueba

Figura 1.4, Modelo del Proceso Unificado, Existen dependencias entre muchos de los modelos. Como ejernplo, se indican las dependencias entre el rnodelo de cases de usn y los demas model os.

10 EL PROCESO UNIPlCADO DE DESARROLLO DE SOFTWARE

• Un modelo de casos de uso. con todos los casos de uso y su rclacion con los usuarios.

• Un modelo de analisis, COil dos propositos: rcfinar los casos de uso con mas detalle y establecer la asignacion inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan cl comportarniento.

• Un rnodelo de disefio que define: (a) la estructura cstatica del sistema en la forma de subsistemas, clases c interfaces y (b) los casos de uso reflejudos como colaboraciones (Apcndice A: vease tarnbien la Seccion 3. I) entre los subsisternas, clascs, c interfaces.

• Un modele de implementucion, que incluye componcntcs (que representan al codigo fuente) y la correspondencia de las clases con los componentes.

• Un modele de despliegue 2, que define los nodos ffsicos (ordenadores) y la corresponden-

cia de los componentes con esos nodos.

• Un modele de prueba, que describe los casos de prueba que verifican los cases de uso.

• Y, por supuesto, una representaci6n de la arquitectura,

EI sistema tambicn debe tener un modelo del dominio 0 modele dcl ncgocio que describa el contexto del negocio en el que se hall a cI sistema.

Todos estos modelos estan relacionados. Juntos, represent an al sistema como un todo. Los elementos de un modelo poseen dependencias de traza (Apendice A; veas« tambien la Seccion 2.3.7) hacia arras y hacia adelante, mediante enlaces hacia otros modelos, Por ejemplo, podernos hacer el seguirnicnto de un caso de uso (en el modclo de cases de uso) hasta una realizacion de caso de uso (en el modele de disefio) y hasta un caso de prueba (en el modclo de prucba). La trazabilidad facilita la cornprcnsion y el cambio.

1.5.2.

Fases dentro de un cicio

Cada cicio se desarrolla a 10 largo del tiernpo. Este tiernpo, a su vcz, se divide en cuatro fuses, como se muestra en la Figura 1.5. A traves de una secuencia de modelos, los implicados visualizan 10 que esta succdiendo en esas Iases. Dentro de cada fasc, los directores 0 los desarrolladores puedeu descornponcr adicionalrnente el trabajo -en iteracioncs con sus incrementos resultantes. Cada fase terrnina con un hito (Apendice C: vease tambien Capitulo 5). Cada hito se dctcrrnina por la disponibilidad de un conjunto de artefactos; es decir, ciertos modclos 0 documentes han sido desarrollados hasta alcanzar un cstado predefinido.

Los hitos ticncn muchos objetivos. El mas enrico es que los directores deben tornar ciertas decisiones cruciales antes de que el trabajo pueda continuar con la siguiente fase. Los hitos tarnbien permiten a la direccion, y a los rnisrnos desarrolladorcs, controlar el progreso del trabajo segun pasa por csos cuatro puntos clave. Al final, se obtienc un conjunto de datos a partir del seguimiento del ticmpo y esfuerzo consumido en cada fasc, Estos datos son iitiles en Ia estirnacion del tiempo y los recursos humunos para otros proycctos, en la asignacion de los recursos durante el tiernpo que dura el proyecto, y en el control del progreso contrastado con las planificaciones.

La Figura J .5. muestra en la columna izquierda los flujos de trahajo -requisitos. analisis, disefio, irnplementacion y prueba, Las curvas son una aproximacion (no dcbcn considcrarse muy litcralmente) de hasta d6nde sc Bevan a cabo los tlujos de trabajo ell cada fase, Recucrdcsc que cada fase sc divide normal mente en iteraciones 0 mini-proyectos. Una iteracion tipica pasa por los cinco t1ujos de trabajo, como se muestra en la Figura 1.5 para una iteracion en la fuse de elaboracion.

2 N. del 1: Tambien se suele utilizar el terrnino "modele de dixtribucion".

EL PROCESO UNIFICAOO; DIRIGIDO POR CASOS DE USQ, CENTRADO EN LA ARQUITECTURA... 11

Flujos de Trabaj fundamentales

Requisitos

Analisis

Disefio

lmplementacion

Prueba

Fases

Inicio I Elaboraclon I Construccion I

Translelon I

.-! ...... -tA-: I I

~ I Una iteraclon I

I en la fase de elaboraclcn

iter. #1

iter. #n

Iteraciones

Figura 1.5. Los cinco flujos de trabajo -rcLJuisilos. analisis. disefio, i mplcmcntucion y prueha- ticncn Jugal' sobrc las cuatro rases: inicio, claboraciun, construccion y rransicion,

Durante lajclse de inicio, se desarrolla una descripcion del producto final a partir de una buena idea y se presenta el analisis de negocio para el producto. Escncialmente, esta fuse responde a las siguicntcs preguntas:

• (,Cwiles son las principales funciones del sistema para sus usuaries mas importantcs?

• j,C6rno podrfa ser la arquitectura del sistema?

• (,Cwil es el plan de proyecto y cuanto costara dcsarrollar el producto?

La respuesra ala primera pregunta se encuentra en un modelo de casos de uso sirnplificado que contenga los cases de uso mas criticos. Cuando 10 tengamos, la arquitectura es provisional, y consiste tipicamente en un simple esbozo que muestra los subsistemas mas importantes, En esta fase, se idcntifican y priori zan los riesgos mas importantes, se planifica en detalle la fase de elaboracion, y se estirna el proyecto de manera uproxirnada.

Durante la/ase de elaboracion, se especifican en detalle la mayorfa de los casos de uso del producto y se diseiia la arquitectura del sistema. La relaci6n entre la arquitectura del sistema y el propio sistema es primordial. Una manera simple de expresarlo es decir que la arquitcctura es amiloga al esqueleto cubierto por la piel pero con muy poco nuisculo (cl software) entre los huesos y la piei -s610 10 necesario para permitir que el csqueleto haga movimientos basicos. El sistema es el cuerpo entcro con esqueleto, piel, y rmisculos.

Por tanto, la arquitectura se expresa en forma de vistas de todos los modclos del sistema, los cuales juntos representan al sistema entero. Esto implica que hay vistas arquitect6nicas del modelo de cases de usn, del rnodelo de analisis, del modelo de disefio, del modelo de imp lementacion y modelo de dcspliegue. La vista del modelo de implementaci6n incluye componentes para probar que la arquitectura es ejecutable. Durante esta fase del desarrollo. se realizan los casos de uso mas cruicos que se identificaron en la fase de cornienzo. EI resultado de esta fase es una linea base de la arquitcctura (Apendice C; vease tarnbien Seccion 4.4),


Al final de la fuse de elaboracion, el director de proyeeto esta en disposicion de planificar las actividades y estimar los rccursos necesarios para terrninar el proyecto. Aqui la cuestion fundamental es: (,son suficienternente estables los casos de usa, la arquitectura y el plan, y estan los riesgos suficientemente controlados como para que seamos capaces de comprometernos al desarrollo cntcro mediante un contrato?

Durante lajclse de construccion se crea el producto -se afiaden los rmisculos (software terminado) al esqueleto (la arquitectura), En esta fase, la linea base de la arquitectura crece hasta convertirse en el sistema completo. La descripcion evoluciona hasta convertirse en un producto prcparado para scr cntregado a la comunidad de usuarios. EI grueso de los rccursos requeridos se cmplea durante esta fase del desarrollo. Sin embargo, la arquitectura del sistema cs estable, aunque los desarrolladores pueden deseubrir formas mejores de estructurar el sistema, ya que los arquitectos recibinin sugerencias de cam bios arquitectonicos de menor irnportancia, AI final de esta fase, el produeto contiene todos los casos de uso que la direccion y el cliente han acordado para el desarrollo de esta version. Sin embargo, puede que no esta completamente libre de defectos. Muchos de estos defectos se descubriran y solucionaran durante la fase de transicion. La pregunta decisiva es: ~cubre el producto las necesidades de algunos usuaries de manera suficiente como para hacer una prirnera entrcga?

La [use de iransicion cubrc el periodo durante el cual cl producto sc convierte en version beta. En la version beta un mimero reducido de usuaries con experiencia prueba el producto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas e incorporan algunas de las rnejoras sugeridas en una version general dirigida a la totalidad de la comunidad de usuaries. La fasc de transicion conllcva actividades como la fabricacion, forrnacion del cliente, el proporcionar una linea de ayuda y asistencia, y la correcci6n de los defectos que se encuentren tras la entrega. EI equipo de mantenimicnto suele dividir esos defectos en dos categorias: los que tienen suficiente impacto en la operacion para justificar una version incrementada (versi6n delta) y los que pueden corregirse en la siguiente version normal.

1.6.

Un proceso integrado

El Proceso Unificado esta basado en cornponentes. Utiliza el nuevo estandar de modelado visual. cl Lcnguaje Unificado de Modelado (UML), y se sostiene sobre tres ideas basicas -casos de uso, arquitectura, y desarrollo iterativo e incremental. Para hacer que estas ideas funcionen, se necesita un proceso polifacetico, que tenga en cuenta ciclos, fases, flujos de trabajo, gestion del ricgo, control de calidad, gestion de proyecto y control de la configuracion. El Proccso Unificado ha establecido un marco de trabajo que integra todas esas diferentes facetas. Este marco de trabajo sirve tarnbien como paraguas bajo el cuallos fabricantes de herramientas y los desarrolladores pueden construir herrarnientas que soporten la automatizacion del proceso entero, de cada tlujo de trabajo individualmente, de la construccion de los diferentes rnodelos, y de la integracion del trabajo a 10 largo del cicIo de vida y a traves de todos los modelos.

El proposito de cste libro es describir el Proceso Unificado con un enfasis particular en las facetas de ingenierfa, en las tres ideas clave (casos de uso, arquitectura, y desarrollo iterativo e incrernental), y en el disefio basado en componentes y el uso de UML. Describiremos las cuatro fases y los diferentes tlujos de trabajo, pero no vamos a cubrir con gran detalle temas de gestion, como la planificacion del proyecto, planificacion de recursos, gestion de riesgos, control de configuracion, recogida de metricas y control de calidad, y s610 trataremos brevemente la autornatizacion del proceso.

Capitulo 2

Las cuatro "P" en el desarrollo de software: Personas, Proyecto, Producto y Proceso

E I resuItado final de un proyecto software (Apendice C) es un producto que toma forma durante su desarrollo gracias a la intervenci6n de muchos tipos distintos de personas. Un proceso de desarrollo de software gufa los esfuerzos de las personas implicadas en el proyecto, a modo de plantilla que explica los pasos necesarios para terminar el proyecto. Tipicamente, cl proceso esta automatizado por medio de una herramienta 0 de un conjunto de ellas. Vease la Figura 2.1.

A 10 largo de este libro utilizaremos los terminos personas, proyecto, producto, proceso (Apendice C) y herramientas, que definimos a continuacion:

• Personas. Los principales autores de un proyecto software son los arquitectos, desarroIladores, ingenieros de prueba, y el personal de gestion que les da soporte, ademas de los usuarios, clientes, y otros interesados. Las personas son real mente seres humanos, a difcrencia del tcrrnino abstracto trabajadores, que introduciremos mas adelante.

• Proyecto. Elemento organizativo a traves del cual se gestiona el desarrollo de software. El resultado de un proyecto es una version de un producto.

• Producto. Artefactos que se crean durante la vida del proyecto, como los modelos (Apendice A), codigo fuente, ejecutables, y documentaci6n.

• Proceso. Un proceso de ingenierfa de software es una definicion del conjunto complete de actividades necesarias para transforrnar los requisitos de usuario en un producto, Un proceso es una plantilla para crear proyectos,

• Herramientas. Software que se utiliza para automatizar las actividades definidas en el proceso.

14 EL PROCESO UNIFICADO DE DESARROLLO DE SOFfWARE

Proceso
Plantilla
Personas Proyecto I
Participantes
Resultado
Producto Automatlzaclon

Herramienlas

Figura 2.1. Las cuatro "P" en el desarrollo de software.

2.1.

Las personas son decisivas

Hay personas irnplicadas en el desarrollo de un producto software durante todo su cielo de vida. Financian el producto, 10 planifican, 10 desarrollan, 10 gestionan, 10 prueban, 10 utilizan y se bcnefician de d. Por tanto, el proceso que gufa este desarrollo debe orientarse a las personas, es decir, debe funcionar bien para las personas que 10 utilizan.

2.1.1.

Los procesos de desarrollo afectan a las personas

EI modo en que se organiza y gestiona un proyecto software afecta profundamente a las personas implicadas en 61. Conceptos como la viabilidad, la gestion del riesgo, la organizaci6n de los equipos, la planificaci6n del proyecto y la facilidad de comprensi6n del proyecto tienen un papel importante:

• Viahilidad del proyecto. La mayorfa de la gente no disfruta trabajando en proyectos que parecen imposibles ·-nadie quiere hundirse con la nave. Como vimos en el Capitulo 1, una aproxirnacion iterativa en cl desarrollo permite juzgar pronto la viabilidad del proyecto. Los proyectos que no son viables pueden detenerse en una fase temprana, aliviando asf los problemas de moral.

• Gestion del riesgo. De igual forma. cuando la gente siente que los riesgos no han sido analizados y reducidos, se sienten inc6modos. La exploracion de los riesgos significativos en las prirneras fases atemia este problema.

• Estructura de los equipos. La gente trabaja de manera mas eficaz en grupos pequefios de seis a ocho miembros. Un proceso que produce trabajo significativo para grupos pequefios, como el analisis de un determinado riesgo, el desarrollo de un subsistema (Apendice A), 0 eillevar a cabo una iteracion, proporciona esra oportunidad. Una buena arquitectura, con interfaces bien definidas (Apendice A; vease tambien el Capitulo 9) entre subsisternas y componentes (Apendice A; veClse tarnbien el Capitulo 10) hace posible una division del esfuerzo de este tipo.

LAS CUATRO "p,. EN EL DESARROLLO DE SOFTWARE: PERSONAS, PROYECTO. PRODUCTO... IS

• Planificacion. del proyecto. Cuando la gente cree que Ia planificacion de un proyecto no es realista, la moral se hunde ~la gente no quiere trabajar a sabiendas de que por mucho que 10 intenten, nunca podran obtener los resultados deseados, Las tecnicas que se utili zan en las fases de inicio y de elaboraei6n permiten a los desarrolladores tener una buena nocion de cual deberfa ser el resultado del proyecto-> es decir, de 10 que debena hacer la version del producto, Debido a que hay una sensacion adecuada de 10 que deberfa hacer el producto, puede crearse un plan de proyecto realista para el esfuerzo requerido, asf como una definicion del tiempo necesario para lograr los objetivos, atenuando el problema del "nunca acabaremos".

• Facilidad de comprension del proyecto. A la gente le gusta saber 10 que esta haciendo: quieren tener una comprensi6n globaL La descripci6n de la arquiteetura proporciona una vision general para cualquiera que se encuentre irnplicado en el proyectos

• Sensacion de cumplimiento. En un cicio de vida iterativo, la gente reeibe retroalimentacion freeuentemente, 10 cual a su vez, haee llegar a eonelusiones. La retroalimentaei6n frecuente y las conclusiones obtenidas aceleran el ritmo de trabajo. Un ritmo de trabajo rapido combinado con conclusiones frecuentes aumenta la sensacion de progreso de la gente.

2.1.2.

Los papeles cambiaran

Debido a que son las personas las que ejecutan las actividades clave del desarrollo de software, es necesario un proeeso de desarrollo uniforme que este soportado por herramientas y un Lenguaje Unifieado de Modelado (hoy disponible en UML) (Apendice C), para hacer que las personas sean mas eficaces. Ese proceso perrnitira a los desarrolladores construir un mejor software en terminos de tiempo de salida al mercado, calidad y costes, Les permite especificar los requisitos que mejor se ajusten a las necesidades de los usuarios. Les perrnite elegir una arquitectura que permita construir los sistemas de forma econornica y puntuaL Un buen proceso de software tiene otra ventaja: nos ayuda a construir sistemas mas complejos. Sefialamos en el primer capitulo que a medida que el mundo real se hace mas complejo, los clientes requeriran sistemas software mas cornplejos. Los proeesos de negoeio y su correspondiente software tendran una vida mas larga. Debido a que los cambios en el mundo real seguiran sucediendo durante estos ciclos de vida, los sistemas software tendran que disefiarse de un modo que les permira crecer durante largos periodos de tiempo,

Para eomprender y dar soporte a esos procesos de negoeio mas complejos y para implementarlos en software, los desarrolladores deberan trabajar con muchos otros desarrolladores. Para trabajar efieazmente en equipos cada vez mas grandes, se necesita un proceso que sirva como guia, Esta gufa tendra como resultado desarrolladores "que trabajan de manera mas inteIigente", es decir, que limitan sus esfuerzos individuales a aquello que proporcione un valor al cliente. Un paso en esta direccion es el modelado de casos de usn, que centra el esfuerzo en 10 que el usuario necesita hacer. Otro paso es una arquitectura que permitira a los sistemas el continuar su evoluei6n durante los afios venideros. Un tercer paso es la compra 0 reutilizaci6n de tanto software como sea posible. Esto, a su vez, puede lograrse solo si hay un modo consistente de integrar componentes reutilizables con elementos de nuevo desarrollo.

En los afios venideros, la mayoria de los informaticos van a empezar a trabajar mas estrechamente con sus objetivos, y seran capaces de desarrollar software mas complejo gracias a un proceso automatizado y a los componentes reutilizables. Las personas seran decisivas en el desarrollo de software en el futuro que esperamos. En ultimo termino, el contar con las personas

16 EL PROCESO UNIFlCADO DE DESARROLLO DE SOFfWARE

adecuadas es 10 que nos lleva al exito. El problema radica en hacerlas eficaces y permitir que se dediquen a 10 que s610 los seres humanos pueden haeer -ser creativos, encontrar nuevas oportunidades, utilizar la razon, comunicarse can los c1ientes y usuaries, y comprender rapidamente un mundo cambiante.

2.1.3.

Convirtiendo "recursos" en "trabajadores"

La gente llcga a ocupar muchos puestos diferentes en una organizaci6n de desarrollo de software. Su preparaci6n para esos puestos requiere una formaci6n y un entrenamiento preciso, seguidos de una cuidadosa asignacion guiada por el analisis y por una adecuada supervision. Una organizacion se enfrenta con una tarea esencial siempre que hace que una persona pase de recurso "laterite" a un puesto concreto de "trabajador".

Hemos elegido la palabra trabajador (Apendice C) para denominar a los puestos a los cuales se pueden asignar personas, y los cuales esas personas aceptan [4 j. Un tipo de trabajador es un papcl que un individuo puede desempefiar en cl desarrollo de software, como puede ser un especificador de casos de uso, un arquitecto, un ingeniero de componentes, 0 un ingeniero de pruebas de integracion. No utilizamos el terrnino rol (en lugar de trabajadori principalmente por dos rnotivos: tiene un significado preciso y diferente en UML, y el concepto de trabajador tiene que ser muy concreto; debemos pensar en terrninos de trabajadores individuales como los puestos que asumen las personas. Tambien debemos emplear el termino rol para hablar de los papcles que cumple un trabajador, Un trabajador puede asumir roles en relacion con otros trabajadores en diferentes flujos de trabajo. Par ejemplo, el trabajador ingeniero de componentes puede participar en varios flujos de trabajo y puede asumir un rul diferente en cada uno de eUos.

Cada trabajador (un trabajador concreto) es responsable de un conjunto completo de actividadcs, como las actividades necesarias para el disefio de un subsisterna. Para trabajar eficazmente. los trabajadores necesitan la informaci6n requerida para llevar a cabo sus actividades. Necesitan cornprender cuales son sus roles en relacion con los de otros trabajadores. Al mismo tiempo, si tienen que hacer su trabajo, las herrarnientas que emplean deben ser las adecuadas. Las herrarnientas no s610 deben ayudar a los trabajadores a lIevar a cabo sus propias acti vidades, sino que tarnbien deben aislarlcs de lu informacion que no les sea relevante. Para lograr estes objetivos, el Proceso Unificado describe formalmente los puestos -es decir, los trabajadoresque las personas pueden asumir en el proceso.

La Figura 2.2 ilustra como una persona puede ser varios trabajadores dentro de un proyecto. Un trabajador tambien puede representar a un conjunto de personas que trabajan juntas. Por ejemplo, un trabajador arquitecto puede ser un grupo de arquitectura.

Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un conjunto de actividades en el desarrollo de software.

AI asignar los trabajadores a un proyecto, el jefe del proyecto debe identificar las aptitudes de las personas y casarlas can las aptitudes requeridas de los trabajadores. Esta no es una tarea facil, en especial si es la primera vez que se utiliza el Proceso Unificado, Se deben casar las habilidades de los recursos (las personas reales) con las cornpetencias especificadas por los difercntes trabajadores que el proyecto necesita. Las aptitudes requeridas por algunos trabajadores pueden conseguirse mediante formaci6n, mientras que otras s610 pueden obtenerse por medio de la experiencia. Por ejemplo, las habilidades necesarias para ser un especificador de casos de uso

LAS CUATRO "P" EN EL DESARROLLO DE SOFTWARE: PERSONAS, PROYECTO, PRODUCTO... 17

Sacar Dinero; Especificador de Casos de Uso

cuenta: Sacar Dinero;

I~o Ingeniero de Pruebas

de Componentes de Integracion

Trabajadores

o o

o

o

o

o

Recursos

o

f3

o

m

Carlos

Maria

Figura 2.2. Trabajadores y recursos que los rcalizan,

pueden obtenerse mediante formacion, pero las de un arquitecto se adquieren normalmente de Ia experiencia.

Una persona puede ser rnuchos trabajadorcs durante la vida de un proyecto. Por ejernplo, Marfa pucdc eomenzar como especificador de casos de uso, y dcspues pasar a ser ingeniero de componentes.

AI asignar reeursos, el jefe de proyecto deberfa minimizar el trasiego de artefactos de un recurso a otro de manera que eI flujo del proceso sea tan continuo como se pueda. Por ejernplo, el ingeniero de cases de uso del caso de uso Sacar Dinero (Apendice A; vease tarnbien el Capitulo 7) obtendra gran cantidad de conocimiento sobre las responsabilidades de la clase Cuenta (Apendice A), aSI que 610 ella seria una eleccion logica para ser el ingeniero de componentes de la clase Cuenta. La alternativa serfa la de formar a una nueva persona para hacer el trabajo, 10 cual es posiblc, pero sena menos eficiente por la perdida de informacion, par el riesgo de una mala comprension, etc.

2.2.

Los proyectos construyen el producto

Un proyecto de desarrollo da como resultado una nueva version de un producto, EI primer proyecto dentro del cicio de vida (es deck el primer cicio de desarrollo, llamado a veces en ingles "green-field project", provecto inicial 0 innovador en castellano) desarrolla y obtiene el sistema o producto inicial. Vease [9] y [101 para una presentacion mas completa de la gestion de proyecto.

A traves de su ciclo de vida. un equipo de proyecto debe preocuparse del cambio, las iteraciones. y el patron organizativo dentro del cual se conduce el proyecto:

• Uno secuencia de cambia: Los proyectos de desarrollo de sistemas obtienen productos como resultados, pero el camino hasta obtenerlos es una serie de cambios. Este hecho de la vida del proyecto debe tenerse en mente mientras los trabajadores progresan a traves de las fases e iteraciones. Cada ciclo, cad a Iase y cada iteracion modifican el sistema de ser una cosa a otra distinta. El primer ciclo de desarrollo es un caso especial que convicrtc cl sistema de nada en algo. Cada cicio lIeva a una version, y mas alla de una secuencia de ciclos, el cambio continua por generaciones.

18 EL PROCESO UNIFIC;\DO DE DESARROLLO DE SOFTWARE

• Una serie de iteraciones: Dentro de cada Iase de un ciclo, los trabajadorcs llevan a cabo las actividades de la fuse a traves de una serie de iteracioncs. Cada iteracion implementa UB conjunto de caxos de uso relacionados 0 aremia algunos riesgos. En una iteracion los desarrolladores progresan a tra ves de una serie de flujos de trabajo: requisites. di scfio, implemcntacion y prueba. Debido a que cada iteracion pasa por cada uno de csos tlujos de trabujo, podcmos pcnsar en una iteracion como si fuese un miniprovecto,

• Un patron organizativo: Un proyecto irnplica a un equipo de personas asiguadas para 10- grar un resultado dcntro de las rcstriccioncs del negocio, es dccir, tiernpo. coste y calidad. La genre trabaja como difercntcs trabajadores. La idea de "proceso' es proporcionar un patron dentro del cual las personas en su papel de trabajadores ejecutan un proyecto. Este patron 0 plantilla indica los ti pos de trahajadores que el proyecto necesita y los artefuctos por los cualcs hay que trabajar, El proceso tambien ofrece un mouton de gufas, heuristicas y practicas de documcntacion que ayudan a haccr su trabujo a las personas asignadas.

2.3.

EI producto es mas que c6digo

En el contexte del Proccso U nificado, el proclucto que se obtieuc cs un sistema software. EI terrnino producto aqui hace referencia al sistema entero, y no s610 al codigo que se entrega.

2.3.1.

l,Que es un sistema software?

(,Un sistema software es el c6digo maquina, los ejecutables' Lo cs, por supucsto, pero (,que es el codigo maquina? iEs una dcscripcion: Una descripcion en forma biuaria que pucde "ser lcida' y "scr cornprcndida" por un computador,

i.Un sistema software es el codigo fucnte? Es decir, (,es una descripcion esc rita por progrumadores que puedc leer y cornprendcr lin compilador? Sf, puede que csta sea la respuesta,

Podemos seguir de esta forma haciendonos preguntas similares sobre el disefio de un sistema software en terrninos de subsisternas, clases, diagramas de interaccion (Apcndice A), diagramas de estados (Apendice A). y otros artefactos. (,Son ellos el sistema? SI, son parte de el. LQue hay de los requisites, prucbas. venta, produccion, instalacion y operacion? (,Son cl sistema'? Sf. tam bien son parte del sistema.

Un sistema es todos los artelactos que se nccesiian para representarlo en una forma comprensible por maquinas u hombres, para las maquinas, los trabajadores y los interesados. Las maquinas son las herramientas. compiladores, u ordenadores destinatarios. Entre los trabajadores tenemos directores, arquitectos, desarrolladorcs, ingenieros de prucba, personal de marketing, adrninistradorcs. y otros. Los intercsados SOil los inversorcs, usuaries, cornercialcs, jeres de proyccto, directores de linea de producto, personal de produccion, agencias de regulacion, etc.

En este libro, utilizarcmos el termino trabajador para estas ires categorfas a la vez, a menos que indiqucmos explfcitumentc otra cosa.

2.3.2.

Artefactos

Artefacto (Apendice C) es un termino general para cualquier tipo de informacion creada, producida, cambiada 0 utiiizada por los trabajadores en el desarrollo del sistema. Algunos ejcrnplos

LAS CUATRO .. p" EN EL DESARROLLO DE SOFTWARE: PERSONAS, PROYECTO, PRODUCTO... 19

de artcfactos son los diagramas UML y Sll texto asociado, los bocetos de la interfaz de usuario y los prototipos (Apcndice C; vease tam bien los Capnulos 7 y 13), los componentes, los planes de prueba tvease Capitulo II) Y los proccdimientos de prueba tvease Capitulo II).

Basicamentc, hay dos tipos de artefactos: artefactos de ingcnicna y artefactos de gestion. Este libro se centra en los artefactos de ingcnicria creados durante las distintas fascs del proceso (requisitos, analisis, disefio, implernentncion y prucba).

Sin embargo, cl desarrollo de software tambien requiere artefactos de gestion, Varios de eslOS artefactos tiencn un tiempo de vida corto ~solo duran 10 que dure la vida del proyecto. A cstc conjunto pertenecen artefactos como el analisis del negocio, el plan de desarrollo (incluycndo cl plan de versiones e iteraciones), un plan para la asignacion de personas concrctas a trabnjudores (es decir. a difcrcnrcs puestos 0 responsabilidades en c1 proyecto), y el disefio de las actividades de los trubajadores en el plan. Estes artefactos se describcn mediante texto () diugramas, utilizando cualquier tipo de visualizacion rcquerida para especificar el compromiso asumido por cl cquipo de desarrollo con los inversores. Los artcfactos de gestion tambien incluycn las especi ficaciones del entorno de dcsarrollo->- el software de autornatizacion del proceso asf como la plataforma hardware necesaria para los dcsarrolladores y necesaria como repositorio de los artefactos de ingenieria.

2.3.3.

Un sistema posee una colecci6n de modelos

EI tipo de artefucto mas intcrcsantc utilizado en el Proceso Unificado es el modele. Cadu irabajador necesita una perspective difercntc del sistema (I'hlse la Figura 2.3). Cuando disefiamos cl Proccso Unificado, identificamos todos los trabajadores y cada una de las perspectivas que posiblemente podrian neccsitar, Las perspectivas recogidas de todos los trabajadores se estructuran en unidades mas grandes, es decir. modclos, de modo que un trabajador pucde tomar una perspectiva concreta del conjunto de modelos.

La construccion de un sistema cs pOI' tanto un proceso de construccion de rnodelos, utilizando distiutos modelos para describir todas las perspectivas diferentes del sistema. La elec-

o o

If8
Usuarios
If8
Ingenieros
de prueba
Sistema
If8
Diseiiadores
If8
Analislas o

o

Arquitecto

EI Jefe de Proyecto

Figura 2.3. Trabajadores participando en el desarrollo de software. (Algunos son trabajadores individualcs: otros son multitipox y multiobjetos.j


Modelo de casos Modelo

de uso de anallsts

Modelo de disefio

L:J

Modelo de despliegue

L:J L:J

Modele Modelo

de implementacion de prueba

L:J L:J

Figura 2.4. EI conjunto fundamental de modelos del Proceso Uni ficado'.

cion de los model os para un sistema es una de las decisiones mas importantes del equipo de desarrollo.

En el Capitulo I presentamos los rnodclos principales del Proceso Unificado (vease la Figura 2.4).

EI Proceso Unificado proporciona un conjunto de modelos cuidadosamcnte seleccionado con el cual comenzar. Este conjunto de modelos hace claro el sistema para todos los trabajadores, incluyendo a los clientcs, usuarios y jefes de proyecto. Fue clegido para satisfaccr las necesidades de informacion de esos trabajadores.

2.3.4.

(.Que es un modelo?

Un modelo es una abstraccion del sistema. cspecificando el sistema modelado desde un cierto punto de vista y en un deterrninado ni vel de abstraccion r l ], Un punta de vista es, par ejemplo, una vista de especificacion 0 una vista de disefio del sistema.

Los model os son abstracciones del sistema que construyen los arquitectos y desarrolladores.

POI' ejemplo, los trabajadores que modelan los requisites funcionales piensan en el sistema con los usuarios fuera de 61 y con los casos de uso en su interior. No se preocupan de c6mo es el sistema por dentro, solo se preocupan de 10 que puede hacer para sus usurarios. Los trabajadores que construyen el disefio piensan en los elementos estructurales como subsisternas y clases; piensan en terminus de como esos elementos funcionan en un contexto dado y como coiaboran para proporcionar los casos de uso. Comprenden como funcionan esos elementos abstractos, y poseen en sus mentes una interpretacion particular.

2.3.5.

Cada modelo es una vista autocontenida del sistema

Un modelo es una abstraccion sernanticamenrc cerrada del sistema, Es una vista autocontenida en el sentido de que un usuario de un modelo no necesita para interpretarlo mas informacion (de otros rnodelos).

La idea de ser autocontenido significa que los desarrolladores trataron de que hubiera una sola interpretaci6n de 10 que ocurrira en el sistema cuando se dispare un evento descrito en el modelo. Ademas del sistema, un modele debe describir las intcracciones entre el sistema y los que le rodean. POI' tanto, aparte del sistema que se csta rnodelando, el modelo tam bien deberfa incluir elementos que dcscriban partes relevantes de su en torno, es decir, actores (Apcndice A; vease tam bien el Capitulo 7).

I En tcrntinos de l;ML. cstos "paquetes' reprcscntan entidades del negocio, "business entities" (0 unidades de trabajo, "work units") en el Proceso Unificado. y no elementos del modclo para modelar un sistema concreto. Vea.'e tambien la explicacion de la Seccion 7.1.

LAS CUATRO "P" EN EL DESARROLLO DE SOFfWARE: PERSONAS, PROYECTO, PRODUCTO... 21

La mayoria de los model os de ingenierfa se definen mediante un subconjunto de UML cuidadosamente seleccionado. Por ejemplo, el modelo de casos de uso comprende a los casos de uso y los actores. Esto es basicamente 10 que un lector necesita para comprenderlo. EI modelo de disefio describe los subsistemas y las clases del sistema y como interactuan para llevar a cabo los casos de uso. Tanto el modelo de casos de uso como el modelo de diseiio describen dos interpretaciones, diferentes pero mutuamente consistentes, de 10 que el sistema hara dado un conjunto de estimulos externos provinientes de los actores. Son diferentes debido a que estan pensados para ser utilizados por diferentes trabajadores con diferentes tareas y objetivos. EI modelo de casos de uso cs una vista externa del sistema, el modelo de disefio es una vista interna. EI modelo de casos de usa captura los usos del sistema, mientras que el modelo de disefio representa la construcci6n del sistema.

2.3.6.

Dentro de un modelo

Un modelo siernprc identifica el sistema que esta modelando. Este elemento del sistema es por tanto el contenedor de los demas elementos. EI subsisterna de mas alto nivel (Apendice B) representa al sistema en construccion. En el modelo de casos de uso, el sistema contiene casos de usa: en el modelo de diseno, contiene subsisternas, interfaces y clases. Tambien contiene colaboraciones (Apendice A) que identifican a todos los subsistemas 0 clases participantes, y puede contener mas cosas, como diagramas de estado 0 diagramas de interaccion. En el modelo de disefio cada subsistema puede ser contenedor de construcciones similares. Esto implica que hay una jerarquta de elementos en este modelo.

2.3.7.

Relaciones entre modelos

Un sistema contiene todas las relaciones (Apendice A) y restricciones entre elementos incluidos en diferentes modelos [1]. Por tanto un sistema no es 5610 la coleccion de sus modelos sino que contiene tambien las relaciones entre ellos.

Por ejernplo, cada caso de uso en el modelo de cases de uso tiene una relacion con una colaboraci6n en el modelo de analisis (y viceversa). Esa relaci6n se llama en UML dependencia de traza, 0 simplemente traza (Apendice A). Vease la Figura 2.5, en la que se indican las trazas en un solo senti do.

Tambien hay, por ejernplo, trazas entre las colaboraciones del modelo de disefio y las colaboraeiones en el modelo de analisis, y entre los componentes en el modelu de implementacion y los subsistemas en el modelo de diseiio. Por tanto, podemos conectar elementos en un modelo a elementos en otro mediante trazas.

El hecho de que los elementos en dos modelos esten conectados no cambia 10 que hacen en los modelos a los que pertenecen. Las relaciones de traza entre elementos en modelos distintos

E:J ¢:J E:J ¢:J E:J ¢:J E:J
Modelo Modelo Modelo Modelo
de Casos de Uso tiene relaciones de Analisis tiene relaciones de Diseno tiene relaeiones de lmplernentacion
detraza con de traza con detraza COil Figura 2.5. Los modelos estan estrechamente enlazados unos con otros mediante trazas.


no anaden informacion semantica para ayudar a comprender los propios model os relacionados; simplemente los conectan. La posibilidad de crear trazas es muy importante en el desarrollo de software por razones como la comprensibilidad y la propagacion de los cambios,

2.4.

EI proceso dirige los proyectos

La palabra proceso es un termino demasiado utilizado, Se utiliza en muchos contextos diferentes, como cuando decirnos proceso de negocio, proceso de desarrollo y proceso software, con muchos significados diferentes. En el contexto del Proceso Unificado, el termino se refiere a los procesos "de negocio" c1aves en una empresa de desarrollo de software, es decir, en una organizaci6n que desarrolla y da soporte al software (sobre el disefio de una cmpresa de desarrollo de software, vease [2]). En estos negocios tambien existen otros procesos, como el proceso de soporte, que interactiia con los usuarios de los productos, y un proceso de venta, que cornienza con un pedido y entrega un producto. Sin embargo, en este libro nos centrarnos en el proceso de desarrollo [3 J.

2.4.1.

EI proceso: una plantilla

En el Proceso Unificado, proceso hace referencia a un contexto que sirve como plantilla que puede reutilizarse para crear instancias de ella. Es comparable a una clase, que puede utilizarse para crear objetos en el paradigma de la orientacion a objetos. lnstancia del proceso es un sinonimo de proyecto,

En cste libro, un proceso de desarrollo de software es una definicion del conjunto completo de actividades necesarias para convertir los requisitos de usuario en un conjunto consistente de artefactos que conforman un producto software, y para convertir los cambios sobre esos requisitos en un nuevo conjunto consistente de artefactos.

La palabra requisito se utiliza con un senti do general, refiriendose a "necesidades". Al principio, estas necesidades no necesariamente se entienden en su totalidad. Para capturar cstos requisitos, 0 necesidades, de una forma mas cornpleta, tenemos que comprender con mayor amplitud el negocio de los clientes y el entorno en que trabajan sus usuarios.

El resultado de valor afiadido del proceso es un conjunto consistente de artefactos, una linea base que conforma una aplicaci6n 0 una familia de elias que forman un producto software.

Un proceso es una definicion de un conjunto de actividades, no su ejecucion.

Por ultimo, un proceso cubre no solamente el primer cicIo de desarrollo (la primera versi6n) sino tambien los ciclos posteriores mas comunes. En versiones posteriores, una instancia del proceso toma cambios incrementales en los requisitos y produce cambios incrementales en el conjunto de artefactos.

2.4.2.

Las actividades relacionadas conforman flujos de trabajo

El modo en que describimos un proceso es en terminos de flujos de trabajo, donde un flujo de trabajo es un conjunto de actividades. (,Cual es el origen de esos flujos de trabajo? No los obtenemos mediante division del proceso en un mimero de subprocesos mas pequefios que in-

LAS CUATRO ,yo EN EL DESARROLLO DE SOFfWARE: PERSONAS, PROYECTO, PRODUCTO... 23

teractuan. No utilizamos diagramas de t1ujo tradicionales para describir como descornponemos el proceso en partes mas pequefias. Estas no son formas eficaces de diseriar la estructura de flujos de trabajo.

En cambio, identificamos primero los distintos tipos de trabajadores que participan en el proceso. Despues identificamos los artefactos que necesitamos crear durante el proceso para cada tipo de trabajador. Esta identificacion, pOT supuesto, no es alga que sc pueda hacer en un abrir y cerrar de ojos. El Proceso Unificado se basa en una amplia experiencia para encontrar el coojunto Iactible de artefactos y trabajadores. Una vez que 10 hemos identiticado, podemos describir como fluye el proccso a traves de los diferentes trabajadores, y como ell os crean, producen y utilizan los artefactos de los dermis, En la Figura 2.6 mostramos un diagrama de actividad (Apendice A) que describe el flujo de trabajo en el modelado de casos de U50. Observense las "calles" (Apendice A) -hay una para cada trabajador-, como fluye el trabajo de un trabajador a otro, y como los trabajadorcs de este flujo lIevan a cabo las actividades (representadas por ruedas dentadas).

A partir de aquf podemos identificar facilmente las actividades que estos trabajadores deben realizar cuando se activan. Estas actividades por trabajador son trabajos significativos para una persona que acnie como trabajador. Adcmas, podemos ver inmediatamente a partir de esas descripciones si algun trabajador concreto necesita participar mas de una vez en el flujo de trabajo.

En otras palabras, describimos c1 proceso entero en partes lIamadas flujos de trabajo (Apendice C). En terrninos de UML, un flujo de trabajo es un estereotlpo (Apendice A) de colaboracion, en el cual los trabajadores y los artefactos son los participantes. Por tanto, los trabajadores y artefactos que participan en un flujo de trabajo pueden participar (y 10 sue1en hacer) tambien en otros f1ujos de trabajo. Usarernos para los flujos de trabajo la notacion de la Figura 2.7.

Un ejemplo de un t1ujo de trabajo es el f1ujo de trabajo de los requisitos. Inc1uye a los siguientes trabajadores: analista de sistemas, arquitecto, especificador de casos de uso y disefiador de interfaz de usuario. Y los siguientes artefactos: modelo de casos de uso, caso de uso, yotros. Otros ejemplos de trabajadores son: ingenieros de componentes e ingenieros de pruebas de integracion. Otros ejernplos de artefac to son las realizaciones de caso de uso (Apendice B; vease tarnbien los Capitulos 8 y 9), clases, subsistemas e interfaces.

o

o

o

o

Arquitecto

Idenlificar Aclores y Casos de Uso

.... -.~--~~~~~~

~

Priorizar Casos de Uso

Eslruclu rar el Modelo de Casos de Uso

Analisla de Sistemas

o

o

Especiticador de Casos de Uso

Delallar

un Caso de uso

o

o

Diseiiador de Inletfaz

Esbozar

de usuarlo

Inletfaz de Usuario

Figura 2.6. Un flujo de trabajo con trabajadores y actividades en "calles".


Requisitos

Una colaboraci6n

de trabajadores y a rtefaclos que se utiliza para describir

el flujo de Requisitos del proceso

Figura 2.7. La notacion "en forma de pez" es la abreviatura de un flujo de trabajo.

2.4.3.

Procesos especial izados

j Ningun proceso de desarrollo de software es de aplicabilidad universal! Los procesos varfan porque tienen lugar en diferentes contextos, desarrollan diferentes tipos de sistemas, y se ajustan a diferentes tipos de restricciones del negocio (plazas, costes, calidad y fiabilidad). Por consiguiente, un proceso de desarrollo de software del mundo real debe ser adaptable y configurable para cumplir con las necesidades reales de un proyecto y/o organizaci6n concreta. EI Proceso Unificado se disefio para poder ser adaptadu (sobre el disefio del proceso, vease [6]). Es un proceso generico, es decir, un marco de trabajo de proceso. Cada organizaci6n que utilice el Proceso Unificado en algun momenta 10 especializara para ajustario a su situaci6n (es decir, su tipo de aplicacion, su plataforma, etc.) (sobre la especializaci6n de un procesu, vease [8]).

El Proceso Unificado puede especializarse para cumplir diferentes necesidades de aplicaci6n o de organizacion, AI mismo tiempo, es deseable que el proceso sea, al menos, completamente consistente dentro de una organizacion, Esta consistencia perrnitira el intercambio de componentes, una transicion eficaz de personas y directivos entre proyectos, y ellogro de conseguir que las metricas sean comparables.

Los factores principales que influyen en como se diferenciara el proceso son:

• Factores organizativos: La estructura organizativa, la cultura de Ia empresa, Ia organizacion y la gestion del proyecto, las aptitudes y habilidades disponibles, experiencias previas y sistemas software existentes.

• Factores del dominio: EI dominio de la aplicacion, procesos de negocio que se deben soportar, la comunidad de usuarios y las ofertas disponibles de la competeneia.

• Factores del ciclo de vida: EI tiempo de salida al mercado, el tiempo de vida esperado del software, la tecnologfa y la experiencia de las personas en el desarrollo de software, y las versiones planificadas y futuras,

• Factores tecnicos: Lenguaje de programacion, herramientas de desarrollo, base de datos, marcos de trabajo y arquitecturas "estandar" subyacentes, comunicaciones y distribucion.

Estas son las causas. (,Que efeeto tendran? Bien, puede decidir eliminar trabajadores y artefactos del Proeeso Unificado para que se ajuste mejor a organizaciones de desarrollo menos maduras. Tambien puede ocurrir que extienda el proceso con trabajadores 0 artefactos nuevos -atin no especificados- ya que esas extensiones pueden hacer el proceso mas eficiente para su proyecto. Tambien puede cambiar la forma en que piensa que un determinado artefacto deberfa describirse; puede imponer una estructura diferente a su definicion. Nuestra experiencia es que la gente en los primeros proyectos utiliza mucho 10 que sugiere el Proceso Unificado. A medida que transcurre el tiempo y ganan mas experiencia, desarrollan sus propias extensiones secundarias.


(,Que tiene el diseno del Proceso Unificado que Ie permite ser especializado [6]7 La respuesta es simple pem no es facil de comprender al principio. EI propio Objectory esta disefiado con 10 que son, en efecto, objetos: casos de uso, colaboraciones y clases. Por supuesto, las clases aquf no son software sino objetos de negocio, es decir, trabajadores y artefactos. Pueden especializarse 0 intercambiarse con otros sin carnbiar el disefio del proceso. En capftulos posteriores cuando describamos los tlujos de trabajo, veremos como utilizarnos objetos para describirlos. Esos objctos son trabajadores y artefactos.

2.4.4.

Meritos del proceso

Un proceso cormin dentro y a 10 largo de los equipos de desarrollo proporciona muchos beneficios:

• Todo el mundo en cl cquipo de desarrollo puede comprender 10 que tiene que hacer para desarrollar el producto.

• Los desarrolladores pueden comprender mejor 10 que los otros estan haciendo -en momentos al principio 0 al final del proyccto, en proyectos sirnilares en la misma empresa, en diferentes ubicaciones geograficas, e incluso en proyectos de otras empresas.

• Los supervisores y directores, incluso los que no entienden el codigo, pueden comprender 10 que los desarrolladores estan haciendo gracias a los esquernas de la arquitectura.

, • Los desarrolladorcs, los supervisores y los directores pueden cambiar de proyecto 0 de division sin tener que aprendcr un nuevo proceso.

• La forrnacion puede estandarizarse dentro de la empresa, y puede obtenerse de compafieros 0 de curses breves.

• EI devenir del desarrollo del software es repetible, es decir, puede planificarse y estirnarse en coste can suficiente exactitud como para cumplir las expectativas.

A pesar de estas ventajas de un proceso corrnin, hay quien insiste en que un proceso cormin no resuelve los "problemas verdaderamente diffciles", A esto simplemente contestamos: "por supuesto que no". Es la gente la que real mente resuelvc los problemas. Pero un buen proceso ayuda a la gente a sobrcsalir como equipo. Cornparemoslo con una organizacion de operacioncs militares. La batalla siempre se reduce a personas que hacen cosas, peru el resultado tambien se decide por la eficacia de la organizacion,

2.5.

Las herramientas son esenciales en el proceso

Las herrarnientas soportan los procesos de desarrollo de software modernos. Hoy, es impensable desarrollar software sin utilizar un proceso soportado por herramientas, EI proceso y las herramientas vienen en el mismo paquete: las herramientas son esenciales en el proceso [5J, [7].

2.5.1.

Las herramientas influyen en el proceso

El proceso se ve influido fuertemente por las herramientas. Las herramientas son buenas para automatizar procesos repetitivos, mantener las cosas estructuradas, gestionar grandes cantidades de informacion y para guiarnos a 10 largo de un camino de desarrollo concreto.

26 EL PROCESO UN1F1CADO DE DESARROLLO DE SOrTWARE

Con poco soporte por herramicntas, un proceso debe sostenersc sobre gran cantidad de trabajo manual y sera por tanto menos formal. En Ia practica, la mayorfa del trabajo formal debe posponersc a las actividades de implernentacion. Sin un soporte por herrarnientas que autornatice la consistencia a 10 largo del cicio de vida, sent diffcil mantener actualizados los modelos y la implementacion. EI desarrollo iterative e incremental sera mas dificil, acabara siendo inconsistcntc, 0 requerini una gran cantidad de trabajo manual para aetualizar documcntos y mantener asf la consistencia. Esto ultimo podrfa disminuir la productividad del equipo de manera significativa. EI equipo tendrfa que haeer manual mente todas las comprobaciones de consistencia. Esto cs muy diftcil, si no imposiblc, por 10 que tendnamos muchas fisuras en los artefactos desarrol1ados. Y hacerlo de esc modo requerirfa mas tiernpo de desarrollo.

Las herramientas se desarrollan para auromatizar actividades, de manera cornpleta 0 parcial. para incrernentar la productividad y la calidad, y para reducir el tiempo de desarrollo. A medicia que introducimos soporte por herrarnientas, obtenemos un proeeso diferente, mas formal. Podernos incluir nuevas actividades que serfa poco practico realizar sin herramicntas. Podernos trabajar de una manera mas prccisa durante el ciclo de vida entero: podernos utilizar un lenguaje cle modelado formal como UML para asegurar que cada modelo es consistente internamente y en relacion con otros rnodelos. Podemos utilizar un modelo y a partir de 61 generar partes de otro modelo (por ejemplo, del disefio a la implementacion y vicevcrsa),

2.5.2.

EI proceso dirige las herramientas

EI proeeso, tanto si se define cxplicita como impltcitamente, especifica la funcionalidad de las herramienlas, es decir, los casos de uso de las herramicntas. EI heeho de que existe un proceso es, por supucsto, el iinico motivo para neccsitar hcrrarnientas. Las herramientas estan ahf para automatizar tanto como sea posiblc del proeeso.

La capacidad de autornatizar un proceso depende cle que tengamos una vision clara de que caxox de uso ncccsita cada usuario y que artcfuctos necesitu manejar. Un proceso automatizado proporciona un medio eficiente de permitir el trabajo concurrente del conjunto complete de los trabajadores, y proporciona una manera de cornprobar la consistencia de todos los artefaetos.

Las herramientas que implement an un proceso autornatizado deben sctfiiciles de usar. Hacerlas muy manejables significa que los desarrolladores de herramientas deben considerar seriamente la forma en que se lleva a cabo el desarrollo de software. Par ejernplo, i,como afrontara un trabajador una deterrninada tarca? (,C6mo se dara euenta cle como le puedc ayudar la herramienta? (,Que tareas hara con frecuencia y por tanto, rnereccn la pena ser automatizadas? (,Que tareas son poco frecucntes y quiza no merece la pena incluir en una herramienta? (,C6mo puede la hcrrarnicnta guiar a un trabajador para que ocupe xu tiernpo en las tare as importantcs que solo el puede haeer, ocupandose la herramienla del resto?

Para responder a prcguntas como esta», la herramienta debe ser sencilla de comprender y manejar para los trabajadores. Es mas. para que merezca la pena el tiernpo que se tarda en aprcnderla, debe proporcionar un incremento de productividad sustancial.

Hay razones cspeciales para el objetivo de la facilidad de uso. Los trabajadores deben ser capaces de probar diferentes alternativas y dcberian poder tan tear los diseiios candidates para cada alternativa con facilidad. Deberfan ser capaces de elegir una aproximacion y probarJa. Si resulta ser inviable, dcberian poder pasar Iacilmente de csa aproximacion a otra. Las herramientas de-

LAS CUATRO "P" EI\" EL DESARROLLO DE SOFTWARE: PERSONAS, PROYECTO, PRODUCTO... 27

benan perrnitir a los trabajadores reutilizar tanto como sea posiblc; no deberfan comenzar todo de nuevo para cada altcrnativa probada. En resumen, es esencial que las herrarnientas sean capaccs tanto de soportar la automatizacion de actividades repetitivas como de gestionar la informacion representada poria serie de model os y artcfactos, fomcntando y soportando las acti vidades crcativas que son el miclco fundamental del desarrollo.

2.5.3.

EI equilibrio entre el proceso y las herramientas

POI' tanto, dcsarrollar un proeeso sin pensar como se autornatizara es un mero ejercicio academico. Dcsarrollar hcrramientas sin saber que proceso (marco de trabajo) van a soportar puede ser una experimeniacion infructuosa. Debe haber un equilibria entre proceso y herramientas.

POI' un lado, el proceso dirige el desarrollo de las herrarnientas, Por otro lado, las herrarnientas dirigen el desarrollo del proceso. EI desarrollo del proceso y su soporte por herramicntas debe tener lugar de rnancra sirnultanca. En cada version del proceso debe haber tambien una version de las herrarnientas. En cada version debe darse este equilibrio. Alcanzar casi el ideal de este equilibrio nos llevara varias itcracioncs, y las sucesi vas iteraciones deben guiarse por la retroalimcntacion de los usuarios entre versiones.

Esta relacion proccso-hcrramienta es otro problema del "huevo y la gallina". (,eual existe primcro? En el caso de las herramientas, muchas de elias en las ultimas decadas han llegado antes de tiempo. EI proceso atin no estaba bien desarrollado. En consecuencia, las herramientas no funcionaban tan bien como sc cspcraba en los procesos, bastante mal planificados, en los cualcs los usuaries intentaron aplicarlas. Muchos de nosotros habfamos perdido Ia fe en las herramientus. En otras palabras, el proceso debe aprender de las herramientas, y las herramientas cleben soportar un proceso bien pensado.

Queremos explicar este tema con la mayor claridad: el desarrollo can cxito de una automatizacion de un proceso (herramientas) no puede hacerse sin el desarrollo paralelo de un marco de trabajo de proceso en el cual vayun a funcionar las herrurnientas. Este terna debe quedar claro para todo el mundo, Si aun alberga una sornbra de duda, preguntese si sena posible dcsarrollar un soporte inforrnatico para los proeesos de negocio en un banco sin conocer cualcs son.

2.5.4.

EI modelado visual soporta UML

Hasta aqui solo hemos dicho que las herramientas son i rnportantes para llevar a cabo el proposito del proceso.

Vamos a examinar un ejemplo significativo de una herramienta en el contexto del soporte del Proceso Unificado. Nuestro ejemplo es la herramienta de modelado para UML. UML es un lenguaje visual. Como tal, se le suponen caructeristicas cornunes en muchos productos cle dibujo, como edicion, dar formate, hacer zoom, imprirnir, dar color y disefio autornatico. Adernas de esas caractcristicas, UML define reglas sintacticas que cspccifican como combinar elementos del lenguaje. Por tanto, la herramienta debe ser capaz de garantizar que se cumplen esas reglas. Esta posibilidad esta fuera del alcance de los productos de dibujo habituales, donde no se eomprueban reglas.

Desafortunadamente, hacer cumplir reglax sintacticas de este tipo sin excepcion haria que la herrarnienta these imposible de utilizar, Por ejcmplo, durante la edici6n de un modele. el modelo

28 EL PROCESO UNlFICADO DE DESARROLLO DE SOFTWARE

sera con frecuencia sintacticamente incorrecto, y la herramienta debe poder permitir incorecciones sintacticas en este modo. Par ejemplo, debe permitirse incluir mensajes en un diagrama de secuencia (Apendice A; vease tambien el Capitulo 9) antes de que se haya definido ninguna operacion para 1a clase.

UML incluye un cierto ruimero de reg las sernanticas que tambien requieren soporte. Estas herramientas pueden incluirse en 1a herramienta de modc1ado, bien como de cumplimiento obligado inmediato 0 como rutinas bajo demanda que recorren e1 modelo y comprueban si hay errores comunes, 0 buscan fa1tas de complecion semanticas 0 sintacticas. En resumen, la herramienta de model ado debe incorporar mas que conocimicnto de UML; debe permitir que los desarrolladores trabajen creativamente con UML.

Mediante el uso de UML como lcnguaje estandar, el rnercado experimentara un soporte par nerramientas mucho mejor que el que nunca haya tenido ningun lenguaje de modelado. Esta oportunidad de un soporte rnejor es debida en parte a la definicion precisa de UML. Tambien puede atribuirse a1 hecho de que UML es hoy un estandar industrial ampliamente utilizado. En lugar de haber fabricantes de herramientas compitiendo para dar soporte a muchos lenguajes de model ado diferentes, el juego estri ahora en encontrar al que mejor soporte UML. Este nuevo juego ex mejor para los usuaries y clientes del software.

UML es solo el lenguaje de modclado. No define un proceso que diga como utilizar UML para desarrollar sistemas software. La herramienta de model ado no tiene que obligar a utilizar un proceso, pero si el usuario utiliza uno, la herramienta puede soportarlo.

2.5.5.

Las herramientas dan soporte al cicio de vida completo

Hay herramientas que soportan todos los aspectos del ciclo de vida del software (Apendicc C):

• Gestion de requisites: Se utiliza para almacenar, examinar, revisar. hacer el seguimiento y navegar por los diferentes requisitos de un proyecto software. Un requisito deherfa tener un estado asociado, y 1a herrarnicnta dcbcria permitir hacer el seguimiento de un requisite desde otros artefactos del cicIo de vida, como un caso de usn 0 un caso de prueba (w;ase el Capitulo 11).

• Modelado visual: Se utiliza para automatizar e1 uso de UML, es decir, para modelar y ensamblar una aplicacion visualmente. Con esta herramienta conseguirnos la intcgracion con entornos de programaci6n y aseguramos que el modelo y la implementacion siempre son consistentes.

• Herramientas de programacion: Proporeiona una gama de herrarnientas, incluyendo editores, cornpiladores, depuradores, detectores de errores y analizadores de rendimiento.

• Aseguramiento de la calidad: Se utiliza para probar aplicaciones y cornponentes, es decir, para registrar y ejecutar cases de prueba que dirigen la prueha de un IGU y de las interfaces de un componente. En un ciclo de vida iterativo, la prueba de regresion es min mas esencia1 que en e1 desarrollo convencional. La autornatizacion de los cases de prueba es esencial para conseguir una productividad alta. Adernas, muchas aplicaciones tambien necesitan ser expuestas a pruebas de estres y de carga. ~Como responded 1a arquitectura de 1a aplicacion cuando 1a estan utilizando 10.000 usuaries concurrentes? Queremos saber la respuesta a esta pregunta antes de entregarla al usuario mimero 10.000.

2.6.


Adernas de estas herramientas orientadas a la funcionalidad, hay otras herramientas que abarcan todo el cicio de vida. Estas herramientas inc1uyen las de control de versiones, gestion de la configuracion, seguimiento de defectos, documentacion, gestion de proyecto y automatizacion de procesos.

Referencias

[I J OMG Unified Modeling Language Specification. Object Management Group, Framingham, MA, 199R. Internet: www.omg.org.

[2] Ivar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Reading, MA: Addison-Wesley, 1997.

[3J Watts S. Humphrey, Managing the Software Process, Reading, MA: Addison-Wesley, 1989.

[4 J Ivar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage: Business Process Reengineering 'with Object Technology, Reading, MA: Addison-Wesley, 1995.

[51 Tvar Jacobson and Sten Jacobson, "Beyond methods and CASE: The software engineering process with its integral support environment", Object Magazine, January 1995.

[6] Ivar Jacobson and Sten Jacobson, "Designing a Software Engineering Process", Object Magazine, June 1995.

[7] Ivar Jacobson and Sten Jacobson, "Designing an integrated SEPSE", Object Magazine, September 1995.

[8] Ivar Jacobson and Sten Jacobson, "Building your own methodology by specializing a methodology framework", Object Magazine, November-December 1995.

[9] Grady Booch, Object Solutions: Managing the Object-Oriented Project, Reading, MA:


[I OJ Walker Royce, Software Project Management: A Unified Framework. Reading, MA: Addison-Wesley, 1998.

Capitulo 3

Un proceso dirigido por casos deuso

E 1 ?bj~tiv(: ,del :'r~1Ceso Uni~icado es guiar a .10s desarrollador~s en la implem~ntacion y distribucion eficiente de sistemas que se ajusten a las necesidades de los clientes. La eficiencia se mide en tcrminos de coste, calidad, y tiempo de desarrollo. EI paso desde la determinacion de las ncccsidades del cliente hasta la implementacion no es trivial. En primer lugar, las necesidades del cliente no son faciles de discernir. Esto nos obliga a que tengamos algun modo de capturar las necesidades del usuario de forma que puedan cornunicarsc facilmente a todas las personas implicadas en el proyecto. Despues, debemos ser capaces de disefiar una irnplementacion funcional que se ajuste a esas necesidades, Por ultimo, debemos verificar que las necesidades del c1iente se han cumplido mediante la prueba del sistema. Debido a esta cornplejidad, el proceso se describe como una serie de flujos de trabajo que construyen el sistema gradual mente.

Como dijimos en el Capftulo 1, el Proceso Unificado esta dirigido por los casos de usa, centrado en la arquitectura yes iterativo e incremental. En este capitulo examinarcmos el aspecto dirigido-por-casos-de-uso del Proceso Unificado, presentado por primera vez en [11 y expl icado en mas profundidad en 12J. Los aspectos de centrado en la arquitectura e iterativo e incremental son el lema de los Capitulos 4 y 5, respectivamente. Gracias a la division de la explicacion, esperamos comunicar la idea de desarrollo dirigido por casas de uso mas simple y claramente. Con el mismo objeti vo, restamos importancia a como preparar el modelo de despliegue, a como disefiar subsistemas con una alta cohesion, a como desarrollar buenos componentes de implementacion (vease la Seccion 10.3.2), y a como llevar a cabo otros tipos de pruebas. Estes temas


no contribuyen ala explicacion de los casas de uso y a como estos dirigen el trabajo de desarrollo, par 10 que posponemos su explicacion detail ada hasta la Parle II.

La Figura 3.1 muestra Ia serie de flujos de trabajo y modelos del Proceso Unificado. Los desarrolladores comienzan capturando los requisitos de cliente en la forma de cases de uso en el modelo de casos de usa. Despues analizan y disefian el sistema para cumplir los casos de uso, creando en primer lugar un modelo de analisis, despues uno de disefio y despues otro de implcrnentacion, el cual inc1uye todo el codigo, es decir, los componentes. Por ultimo, los desarrolladores preparan un modelo de prueba que les permite verificar que el sistema proporciona la funcionalidad descrita en los casos de uso. Todos los modelos se relacionan con los otros mediante dependencias de traza, EI modelo de implementacion es e1 mas formal, mientras que el modelo de casos de usa es el menos formal, en el senti do de poder ser interpretado por la rnaquina, es decir, las partes del modelo de implernentacion pueden cornpilarse y enlazarse produciendo ejecutables, mientras que el modelo de cases de uso se describe fundamental mente mediante lenguaje natural.

Los casos de uso han sido adoptados casi universal mente para la captura de requisites de sistemas software en general, y de sistemas basados en componentes en particular [6], pero los cases de uso son mucho mas que una herramienta para capturar requisites. Dirigen el proceso de desarrollo en su totalidad. Los casas de uso son la entrada fundamental cuando se identifican y especifican clases, subsistemas e interfaces (Apendice A), cuando se identifican y especifican casos de prueba, y cuando se planifican las iteraciones del desarrollo y la integracion del sistema tvease Capitulo 10). Para cada iteracion, nos guian a traves del conjunto completo de tlujos de trabajo, desde la captura de requisites, pasando por el analisis, disefio e implementacion, hasta la prueba, enlazando estos diferentes flujos de trabajo.

Requisitos ------- EJ Modelo

de casos de uso

Ami lisis - - - - - - - - - - - - - -

Modelo

de analisis

Diseno - - - - - - - - - - - - - - - - - - - - - -

EJEJ

Modelo Modelo

de disefio de despliegue

tmptementaclen - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --

Modelo

Prueba -------------------------------------------------------

de lmplementacion

EJ

Modelo de prueba

Figura 3.1. EI Proceso Unificado consiste en una serie de flujos de trabajo que van desdc los requisites hasta las pruebas (de izquierda a dcrecha y de arriba hacia abajo). Los flujos de trabajo desarrollan model os, desde el modelo de casos de uso hasta el modclo de prueba.

UN PROCESO D1RIGIDO POR CASOS DE usa 33

3.1.

Desarrollo dirigido por casos de uso en pocas palabras

La captura de requisitos tiene dos objetivos: encontrar los verdaderos requisitos tvease Capitulo 6), y representarlos de un modo adecuado para los usuarios, clientes y desarrolladores. Entendemos por "verdaderos requisites" aquellos que cuando se implementen afiadiran el valor espcrado para los usuaries. Con "representarlos de un modo adecuado para los usuarios, clientes y desarrolladores" queremos decir en concreto que la descripcion obtenida de los requisitos debe ser comprensible por usuarios y clientes, Este es uno de los retos principales del tlujo de trabajo de los requisites.

Normalmentc, un sistema tiene muchos tipos de usuarios. Cada tipo de usuario se representa por un actor. Los actores utilizan el sistema interactuando con los casos de uso. Un casu de uso es una secuencia de acciones que el sistema lIeva a cabo para ofrecer algtin resultado de valor para un actor. EI modelo de casos de uso esta compuesto por todos los actores y todos los casos de uso de un sistema l3]. [41.

Durante el aruilisis y el disefio, el modelo de cases de uso se transforrna en un modelo de disefio a traves de un modelo de analisis, En breve, tanto un modelo de analisis como un modelo de disefio son estructuras compuestas por clasificadores (Apendice A) y por un conjunto de realizaciones de casos de uso (vease Capitulos 8 y 9) que describen como esa estructura realiza los casos de uso. Los clasificadores son, en general, elementos "parecidos aclases". Por ejernplo, tienen atributos y operaciones (Apendice A), se les puede describir con diagramas de estados (Apendice A), algunos de eUos pueden instanciarse, pueden ser participantes en colaboraciones, etc. UML define muchos tipos de clasificadores. Subsisternas. clases e interfaces son ejemplos de clasificadores en esta estructura. Tambien son clasificadores los adores, casos de uso, componentes y nodos (Apendice A; vease tambien la Seccion 9.3.7).

El rnodelo de analisis es una especificacion detallada de los requisites y funciona como primera aproxirnacion del modelo de disefio. aunque es un modelo con entidad propia. Los desarrolladores 10 utilizan para comprender de manera mas precisa los casos de uso descritos en el tlujo de trabajo de los requisites, refinandolos en forma de colaboraciones entre clasificadores conceptuales (diferentes de los clasificadores de disefio que seran objeto de irnplementacion). EI modelo de anal isis tarnbien se utiliza para crear un sistema robusto y flexible (incluyendo una arquitectura) que ernplea la reutilizacion de componentes de manera considerable. EI modelo de analisis es diferente del de disefio en que es un modelo conceptual, en lugar de ser un esquema de la implementacion, El modelo de analisis puede ser transitorio y sobrevivir s610 al primer par de iteraciones. Sin embargo, en algunos casos, especial mente para sistemas grandes y complejos, el modelo de analisis debe mantenerse durante toda la vida del sistema. Es estos casos, existe una relacion directa (mediante dependencias de traza) entre una realizacion de caso de uso en el rnodelo de analisis y la correspondiente realizacion de caso de usn en el modelo de disefio. Cada elemento del modelo de analisis es trazable a partir de elementos del modelo de disefio que 10 realizan. (El modelo de analisis, su proposito y su relacion con el modelo de disefio se explican en profundidad en las Secciones 8.1 a 8.3).

El modelo de disefio posee las siguientes caracterfsticas:

• El modelo de disefio es jerarquico, peru tambien contiene relaciones que atraviesan la jerarqufa. Las relaciones son las habituales en UML: asociaciones, generalizaciones, y dependencias (Apendice A).


• Las rcalizaciones de los casos de uso son estereotipos de colaboraciones. Una colaboracion represcnta como los clasificadores participan y desernpefian papeles en hacer algo util. como la realizacion de un caso de lISO.

• EI modelo de disefio es tambicn un esquema de la implementacion. Existe una correspondencia directa entre subsisternas del modele de disefio y componentes del modelo de irnplemcntacion.

Los dcsarrolladorcs crean un modele de analisis que uriliza el modele de casos de uso como entrada [5]. Cada caso de uso en cl modelo de casos de usn se traducira en una rcalizacion de caso de uso en cl modele de analisis. La dualidad caso de uso/realizacion de caso de usn es la base de una trazabilidad directa entre los requisites y el aruilisis. Tornando los casos de uso uno a uno, los desarrolladores pueden identificar las clases que participan en la realizaci6n de los casos de uso. Por ejemplo, el caso de uso Sacar Dinero puede realizarse por parte de las clases de analisis Retirada de Efectivo, Cuenta, Cajero. y otras que no necesitamos idcntificar para csta explicacion. Los desarrolladores asignan responsabilidades (Apendice A) definidas en cl caso de uso a responsabilidades de las clases. En nuestro ejernplo, la clase Cuenta podria tener responsabilidades como "restar cantidad de la cucnta". De esta forma. podemos garantizar que ohtenemus un conjunto de clases que juntas realizan los casos de uso y son verdaderarnentc necesarias para los usuarios.

Despues, los desarrolladores discfian las clases y las realizaciones de casos de uso para obtencr mejor partido de los productos y tecnologias (object request brokers'; kits de construccion de IGU. Y sistemas de gesti6n de base de datos) que se utilizaran para implementar el sistema. Las clascs de disefio sc agrupan en subsisternas, y pucden definirse interfaces entre ellos. Los dcsarrolladores tambien preparan elmodelo de dcspliegue, dondc definen la organizacion ffsica del sistema en terrninos de nodos de c6mputo. y verifican que los casus de uso pueden implementarse como componentes que sc ejecutan en esos nodos.

A continuacion, los desarrolladores implementan las clases discfiadas mediante un conjunto de ficheros (codigo Iuente) en el modele de implementacion, a partir de los cuales se pueden producir (cornpilar y enlazar) ejecutables, como DLL's, JavaBeans, y cornponentes ActiveX. Los casos de uso ayudan a Ius desarrolladores a determinar el orden de implementacion e intcgracion de los componentes.

Por ultimo. durante el llujo de trabajo de prueba los ingenieros de prueba verifican que el sistema irnplerncnta de verdad la funcionalidad descrita en los casos de uso y que satisface los requisitos del sistema. EI modelo de prueba se compone de casos de prueba (y otros elementos que cxplicarernos mas adelante en cl Capitulo 11). Un caso de prueba define una colcccion de entradas, condiciones de ejecucion, y resultados. Muchos de loscasos de prueba se pueden obtener dircctarnente de los casos de uso y por tanto tenemos una dependencia de traza entre cl caso de prueba y el casu de uso correspondiente. Esto significa que los ingenieros de prucba verificaran que el sistema puede hacer 10 que los usuarios quieren que haga. es dccir, que ejecuta los casos de uso. Cualquiera que haya probado software en el pas ado en realidad ha probado casos de uso ~ incluso si su trabajo no los describfa en esos terrninos en su momento l8J. Lo novedoso y difcrente del Proceso Unificado es que la prueba puede planificarse al principio del ciclo de desarrollo. Tan pronto como se hayan cupturado los casos de uso, cs posible cspecificar los casos de prueba (pruebas de "caja negra") y dcterrninar el ordcn en el cual

I N. del T. Por su amplia difusion en la industria del software, mantenernos el rerrnino original en ingles.

UN PROCESO DIRIGlDO POR CASOS DE usa 35

realizarlos, integrarlos y probarlos. Mas adelanto, segun se vayan realizando los casos de usn en el disefio, pueden detallarse las pruebas de los casos de uso (pruebas de "caja blanca"). Cada forma de ejecutar un caso de uso --es decir, cada camino a traves de una realizaci6n de un caso de llSO- es un caso de prueba candidato.

Hasta aqui, hemos presentado el Proceso Unificado como una secuencia de pasos, muy parecida al antigun metodo en cascada. Pero 10 hemos hecho as! s610 para rnantener la simplicidad hasta cste momento. En el Capitulo 5 veremos como estos pasos pueden desarrollarse de una forma mucho mas interesante mediante una aproxirnacion iterativa e incremental. Reulmcnte, 10 que hcmos descrito hasta aquf cs una sola iteracion. Un proyecto de desarrollo complete sera una serie de iteraciones, en la cual cada una de ellas (con la posible excepci6n de la primera) consiste en una pasada a traves de los tlujos de trabajo de requisites, analisis, discfio, implernentacion y prucba.

Vamos a cxarninar con mas detalle los beneficios de los casos de usn antes de estudiar los flujos de trabajo mas en profundidad.

3.2.

(,Por que casas de usa?

Existen varies rnotivos por los cualcs los casos de uso son buenos. se han hecho populares y se han adoptado universalmcnte [6]. Las dos razones fundamentales son:

• Proporcionan un rnedio sistematico e intuitive de capturar requisitos funcionales (Apendice C; vease tambien los Capftulos 6 y 7) centrandose en el valor afiadido para el usuano.

• Dirigen todo el proceso de desarrollo debido a que la mayoria de las actividades como el analisis, discfio y prueba se lIevan a cabo partiendo de los casus de uso. EI disefio y la prueba pueden tambien planificarse y coordinarse en rerrninos de casos de uso. Esta caracterfstica es aiin mas evidente cuando la arquitectura se ha estabilizado en el proyecto. despues del primer conjunto de iteraciones.

3.2.1.

Para capturar los requisitos que aportan valor afladido

Segtin Karl Wieger, "la perspectiva que proporcionan los casos de uso refuerza el objetivo ultimo de la ingenierfa del software: la creacion de productos que perrnitan a los clientes realizar un trabajo iitil." [9]. Existen varias razones por las cuales esto es cierto.

En primer lugar, la idea de caso de uso permite la identificaci6n del software que cumple con los objetivos del usuario. Los casos de usa son las funcioncs que proporciona un sistema para afiadir valor a sus usuarios, Tomando la perspectiva de cada tipo de usuario, podernos capturar los cases de uso que necesitan para hacer su trabajo. Por otro lado, si comenzamos pensando en un conjunto de buenas funciones del sistema sin pensar en los casos de uso que emplean los usuarios concrctos, sera diffcil decir si esas funciones son importantes 0 incluso si son bucnas. LA quicn ayudan? {,Que necesidades del negocio satisfacen? i,Cuanto valor afiaden al negocio?

36 EL PROCESO UNIFlCADO DE DESARROLLO DE SOFfWARE

Los mejores casos de uso son aquellos que afiaden el mayor valor al negocio que implanta el sistema. Un casu de uso que aporta un valor negativo 0 que permite hacer al usuario cosas que no deberfa poder hacer no es un casu de uso. Podriamos llamarlo un "caso de abuso", ya que especifica form as de utilizar el sistema que deben prohibirse. Un ejemplo de un caso de uso de este tipo serfa permitir a un cliente de un banco transferir dinero de la cuenta de otro a la suya. Los casos de uso que aportan poco 0 ningiin valor se utilizaran con menos frecuencia; son "cases sin-usc" superfluos.

Como dijirnos en el Capftulo 1, mucha gente ha llegado a la conclusion de que preguntarse a sf mismos sobre que quieren que haga el sistema no les ayuda a obtener las rcspuestas correctas. En su lugar, obtienen una lista de funciones del sistema, que a primera vista puede parecer valiosa, pero cuando se exarnina mas en profundidad se ve que no necesariamente esta relacionada con las necesidades del usuario. Puede parecer que la estrategia de los casos de uso que reformula la pregunta afiadiendo tres palabras al final -(,que se quiere que haga el sistema para coda usuario?- es solo un poco diferentc, pero obtiene un resultado muy distinto. Nos mantiene centrados en la comprension de como el sistema debe dar soporte a cada uno de sus usuarios. Nos guia en la identificacion de las funciones que cada usuario necesita. Tambien nos ayuda a abstcnernos de sugerir funciones superfluas que ninguno de los usuarios necesita,

Ademas, los cases de usa son intuitivos. Los usuaries y los clientes no tienen que aprender una notacion compleja. En su lugar, se puede usar simple castellano (es decir, lenguaje natural) la mayor parte del tiempo, 10 que hace mas facil la lectura de los cases de usa y la propuesta de cambios.

La captura de los casos de uso implica a los usuaries, a los clientes y a los desarrolladores.

Los usuarios y los clientes son los expertos en los requisitos. El papel de los desarrolladores es el de facilitar las discusiones y ayudar a los usuarios y a los clientes a comunicar sus necesidades.

EI modelo de casos de uso se utiliza para conseguir un acuerdo con los usuarios y clientes sobre que deberia hacer el sistema para los usuarios. Podemos pensar en el modelo de casos de usa como en una especificacion completa de todas las formas posibles de utilizar el sistema (los casas de usa). Esta especificacion puede utilizarse como parte del contrato con cI cliente. EI modelo de casos de uso nos ayuda a delimitar el sistema definiendo todo 10 que debe hacer para sus usuarios. Una tecnica interesante para estructurar los casas de usa se encuentra en [12], Y [Ill proporciona una buena introduccion general a los cases de usa.

3.2.2.

Para dirigir el proceso

Como hemos dicho, el que un proyecto de desarrollo este dirigido por los casos de uso significa que progresa a traves de una serie de flujos de trabajo que se inician a partir de los casas de uso. Los casas de uso ayudan a los desarrolladores a encontrar las clases. Las clases se recogen de las descripciones de los casas de usa a medida que las leen los desarrolladores, buscando clases que sean adecuadas para la realizacion de los casos de uso-. Los casos de usa tambien nos

, Esto es una simplificacion. En rcalidad, cada caso de uso puede rocar varias clases (suhsistcmas, etc.) que ya se han desarrollado, de modo que modificaremos los casos de usn para que se ajusten a csos bloques de construcci6n reurilizables. Esto se explicara en la Secci6n 4.3.

UN PROCESO DIRIGIDO POR CASOS DE usa 37

Requisitos

Prueba

Figura 3.2. Los cases de usn enlazan los flujos de trabajo fundamentales, La elipse sombreada en el fondo sirnboliza como los cases de usn cnlazan esos flujos de trabajo.

ayudan a desarrollar interfaces de usuario que hacen mas facil a los usuarios el desempefio de sus tareas. Mas adelante, las realizaciones de los casos de uso se prueban para verificar que las instancias (Apendice A) de las clases pueden llevar a cabo los casos de usa r8].

Los casos de uso no solo inician un proceso de desarrollo sino que 10 enlazan, como se muestra en la Figura 3.2.

Tambien tenemos que estar seguros de que capturamos los casos de uso correctos de forma que los usuarios obtengan los que realmente quieren. La mejor forma de conseguir esto es, por supuesto, hacer un buen trabajo durante el flujo de los requisitos, Pero can frecuencia no es suficicnte. Un sistema en ejecucion nos permite una validaci6n adicional de los casos de uso con las neccsidades reales del usuario.

Los casus de usa ayudan a los jefes de proyeeto a planificar, asignar y eontrolar muchas de las tareas que los desarrolladores rcalizan. Por cada easo de uso, un jefe de proyecto puede identificar unas cuantas tareas. Cada caso de usa a especificar es una tarea, eada caso de usa a disefiar es una tarea, y cada caso de uso a probar es una tarea. EI jefe de proyecto puede incluso estimar el esfuerzo y el tiempo neeesario para llevar a cabo esas tareas. Las tareas identificadas a partir de los casos de uso ayudan a los jefes a estimar el tamafio del proyecto y los recursos nccesarios. Entonees esas tareas pueden asignarse a desarrolladores concretos que se hacen responsables de ellas. Un jefe de proyecto podria hacer responsable de la especificaci6n de cinco cases de uso a una persona durante el flujo de requisitos, a otra responsable de disefiar tres casox de uso y a un tercero responsable de especificar los casos de prueba para dos casos de uso.

Los casas de usu son un importante mecanismo para dar soparte a la trazabilidad a traves de todos los modelos. Un caso de usa en el modelo de requisitos es trazable a su realizaci6n en el analisis y en el disefio, a todas las clases participantes en su realizacion, a componentes (indirectamente), y finalmente, a los casos de prueba que 10 verifican. Esta trazabilidad es un aspecto importante de la gestion de un proyecto. Cuando se cambia un caso de usa, las realizaciones, clases, componentes y casos de prueba correspondientes tienen que comprobarse para ser actualizadas. De igual forma, cuando un componente de fichero(c6digo fuente) se modifica, las clases, casos de uso y casos de prueba correspondientes que se Yen afectados tarnbien deben comprobarse (vease rIO]). La trazabilidad entre los casos de uso y el resto de los elementos del modelo haee mas facil mantener la integridad del sistema y eonservar actualizado al sistema en su conjunto cuando tenemos requisites cambiantes.

3.2.3.

Para idear la arquitectura y mas ...

Los casos de usa nos ayudan a llevar a cabo el desarrollo iterativo. Cada iteracion, excepto quiza la primera de todas en un proyecto, se dirige por los casas de usa a traves de todos los flujos de trabajo, de los requisites al disefio y ala prueba, obteniendo un incremento (Apendice C). Cada incremento del desarrollo es por tanto una realizacion funcional de un conjunto de casos de uso. En otras palabras, en cada iteracion se identifican e implementan unos cuantos casos de uso.


Los casas de uso tambien nos ayudan a idear la arquitectura. Mediante la seleccion del conjunto correcto de casas de usa -los casas de uso significativos arquitectonicamente-e- para llevarlo a cabo durante las primeras iteraciones, podemos implementar un sistema can una arquitectura estable, que pueda utilizarse en muchos ciclos de desarrollo subsiguientes. Volveremos a este tema en el Capitulo 4.

Los casas de uso tarnbien se utilizan como punta de partida para escribir el manual de usuario. Ya que cada caso de usa describe una forma de utilizar el sistema, son el punta de partida ideal para explicar como puede el usuario interactuar can el sistema.

Mediante la estirnacion de la frecuencia de uso de los diferentes caminos en los casas de usa, podemos estimar que caminos necesitan el mejor rendimiento. Esas estimaciones pueden utilizarse para dimensionar la capacidad de proceso del hardware subyacente a para optimizar el disefio de la base de datos para ciertos usos. Pueden utilizarse estimaciones parecidas para conseguir una buena facilidad de usa, seleccionando los caminos mas importantes para centrarnos en ell as durante el disefio de la interfaz de usuario.

3.3.

La captura de casas de usa

Pasamos ahara a dar una vision general de como se desarrolla el trabajo a traves de todos los flujos de trabajo. Nos centraremos, como se dijo anteriormente, en el hecho de que esta dirigidopor-casos-de-uso. En la siguiente seccion nos centramos en la captura de requisitos funcionales en la forma de casas de usa, aunque tambien es necesario capturar otros tipos de requisitos.

Durante el tlujo de trabajo de los requisites identificamos las necesidades de usuarios y clientes como requisitos. Los requisites funcionales se expresan coma casas de uso en un modelo de casas de usa, y los dernas requisitos a bien se "adjuntan' a los casos de usa a los que afectan, a bien se guardan en una lista aparte 0 se describen de alguna otra forma.

3.3.1.

EI modelo de casos de uso representa los requisitos funcionales

EI modelo de casos de usa ayuda al cliente, a los usuarios y a los desarrolladores a llegar a un acuerdo sobre como utilizar el sistema. La mayorfa de los sistemas tienen muchos tipos de usuarios. Cada tipo de usuario se representa mediante un actor. Los actores utilizan el sistema al interactuar can los casos de usa. Todos los actores y casos de uso del sistema forman un mode- 10 de casos de uso [Z], [3]. Un diagrama de casos de uso (Apendice A; vease tarnbien la Seccion 7.4.1) describe parte del model a de casos de usa y muestra un conjunto de cases de usa y actores can una asociacion entre cada par actor/caso de usn que interacnian (vease la Figura 3.3).

Ejemplo

Un modelo de casos de uso para un sistema de cajero automatlco (CA)

EI actor Cliente de Banco utiliza un sistema CA para retirar e ingresar dinero desde y en cuentas, y para transferir dinero entre cuentas. Esto se representa par los tres casas de usa que se muestran en la Figura 3.3, que poseen asociaciones can el actor para indicar su interaccion.

UN PROCESO DJRIGIDO POR CASOS DE usa 39

o

/ Saear Dinero

~ 0

Cliente ~ Ingresar Dinero

del Banco ~

o

Transferencia entre Cuentas

Figura 3.3. Un ejemplo de diagrama de cu ... os de uso con Ull actor y Ires casos de usn.

3.3.2.

Los acto res son el entorno del sistema

No todos los actores reprcscntan a personas. Pueden ser actores otros sistemas 0 hardware externo que interactuara con el sistema. Cada actor asume un conjunto coherente de papeles cuando interacnia con el sistema. Un usuario ffsico puede actuar como uno 0 varios actores, dcscmpeiiando los papeles de csos actores en su interaccion con el sistema. Varies usuariox concretos pueden actuar como diferentes ocurrencias del rnismo actor. Por cjernplo, puede haber miles de personas que acuian como el actor Cliente de Banco.

Los actores se comunican con cI sistema mediante el envio y rccepcion de mensajes (Apcndice A) hacia y desde el sistema segun este lleva a cabo los casos de uso, A medida que definimos 10 que hacen los actores y 10 que hacen los casos de uso, trazaremos una clara separacion entre las responsabilidades lie los adores y las del sistema. Esta separacion nos ayuda a delimitar el alcance del sistema.

Podernos encontrar y especificar todos los actores examinando a los usuarios que utilizanin el sistema y a otros sistemas que deben intcractuar con el. Cada categoria de usuaries o sistemas que interactuan se representan por tanto como actores.

3.3.3.

Los casos de uso especifican el sistema

Los casos de uso estan diseiiados para cumplir los deseos del usuario cuando utiliza el sistema. El modele de casus de uso captura todos los requisites funcionales del sistema. Definirernos un caso de uso de rnanera precisa como sigue:

Un C(lSO de uso especifica una secuencia de acciones. incluyendo variantes, que el sistema puede llevar a cabo. y que producen un resultado observable de valor para WI actor concreto.

Idcntificarnos los casos de uso cxaminando como los usuarios necesitan utilizur el sistema

para realizar su trabajo (para un modo de estructurar los casos de uso basado en objctivos, vease [10]). Cada uno de esos modos de utilizar el sistema que aiiaden valor al usuario es un caso de usn candidato. Estes candidatos sc ampliaran, se cambiaran, se dividiran en casos de uso mas pequefios, 0 se integraran en casos de uso mas completes. EI modelo de casos de usn csta casi terrninado cuando recoge todos los requisites funcionalcs correctamente de un modo


que puedan comprender los clientes, usuarios y desarrolladores. La secuencia de acciones realizada por un caso de uso durante su operaci6n (es decir, una instancia del casu de usa) es un camino especifico a traves del caso de uso. Puedc haber muchos caminos, muchos de ellos muy parccidos -son variantes de la ejecucion de la secuencia de acciones especificada en el caso de uso. Para hacer que un modelo de cases de uso sea mas comprensible, podernos agrupar descripciones de caminos variantes parccidas en un solo caso de uso. Cuando dccirnos que identificamos y describirnos un casu de uso, real mente cstamos diciendo que identificarnos y describimos los difercntes caminos que es practice definir como un solo caso de usa.

La secuencia de acciones para un camino a traves de este caso de uso es (de forma muy simplificada):

EI Cliente del Banco se identifica.

EI Cliente del Banco elige de que cuenta sacar dinero y especifica que cantidad. EI sistema deduce la cantidad de la cuenta y entrega el dinero.

Los casos de usa tambien se utilizan como "contenedores" de los requisitos no funcionales (Apendice C; veas(:' tarnbien el Capitulo 6), tales como los requisites de rendimiento, disponibilidad, exactitud y seguridad que son especificos de lin caso de uso. Por ejemplo, puedc asociarse al caso de lISO Sacar Dinero el siguiente requisito: el tiempo de respuesta para un Cliente de Banco medido desde la seleccion de la cantidad a sacar hasta la entrega de los recibos debe ser menor de 30 segundos en cl 95 por ciento de los casos,

Resumicndo, todos los requisitos funcionales quedan atados mediante cases de uso, y muchos de los requisites no funciona1es pueden asociarsc a los cases de uso. De hecho, el modelo de casos de usn es un vehfculo para organizar los requisites de un modo facil de gestionar. Clientes y usuaries pueden cornprenderlo y utilizarlo para comunicar sus necesidades de un modo consistente y no redundante. Los desarrolladores pueden dividir el trabajo de captura de requisitos entre cllos, y despues utilizar los resultados (fundamentalmente los casas de uso) como entrada para el aruilisis, disefio, implernentacion y prueba del sistema.

3.4.

Anallsls, diseiio e lmplementacion para realizar los casos de uso

Durante el analisis y el disefio, transformamos el modelo de casos de uso mediante un modelo de analisis en un modelo de diseiio, es decir, en una cstructura de clasificadores y realizaciones de casos de uso. EI objetivo es realizar los casos de uso de una forma economica qe manera que el sistema ofrezca un rendimiento adecuado y pueda evolucionar en cl futuro.

En esta seccion, veremos como pasar par un modelo de analisis para desarrollar un disefio que realice los casos de uso. En los Capitulos 4 y 5, examinarernos como la arquitectura y el desarrollo iterativo e incremental nos ayudan a desarrollar un sistema econ6mico que pueda ineorporar nuevos requisites.


3.4.1.

Creaci6n del modelo de anallsis a partir de los casos de uso

El modele de analisis crece incrcmentalmente a mcdida que se analizan mas y mas casos de uso. En cada itcracion, elegimos un conjunto de casas de uso y los reflejamos en el modele de analisis. Construimos el sistema como una estructura de clasificadores (clases de analisis) y relaciones entre elias. Tambien describimos las colaboraciones que Ilcvan a cabo los casos de usn, es decir, las realizaciones de los casos de uso. Despues, en la siguiente iteracion, tomamos otro conjunto de caxos de uso para desarrollar, y los afiadimos a la iteracion anterior. En las Secciones 5.3 y 12.6. discutirernos como identificar y seleccionar los conjuntos mas "importantes' de casus de usa para las primeras iteraciones can el objetivo de construir pronto una arquitectura estahle dentro del ciclo de vida del sistema.

Una forma practica de trabajar es identificar y describir en primer lugar los casos de uso para una itcracion, despucs leer la descripcion de cada caso de uso (ejernplificada en la Seccion 3.3.3), y proponer los clasificadores y asociaciones necesarios para llevar a cabo el caso de uso. La hacemos para todos los casos de uso de una iteracion a modo de esfuerzo coordinado. Dependiendo de dondc nos encontremos en el ciclo de vida y del tipo de iteraci6n que estemos tratando, puede que haya ya una arquitectura establecida para guiarnos en la identificacion de nuevos clasificadores y en la reutilizaci6n de los existentes ivease Ia Seccion 4.3). Cada clasificador descmpeiia uno 0 varies roles en una realizacion de caso de uxo. Cada papel de un clasificador cspecifica las rcsponsabilidades, atributos y dernas que el clasificador debe tener para participar en la realizacion del caso de usa. Podemos pensar en esos roles como en "ernbriones" de clasificadorcs. De heche, un 1'01 en UML es un clasificador en sf mismo. Por ejemplo, podemos pensar que un rol de una clase es una vista de la clase. Por tanto, incluye 10 que incluya la clase. es decir, sus responsabilidades, atributos y dernas -pero solo aquellos que sean de interes para el rol en una realizacion de caso de uso. Otra forma de describir un rol de una cluse es verlo como 10 que queda de la clase cuando se le pone un filtro, un filtro que bloquea el resto de los roles de la clase que no tienen responsabilidades comunes. Este conccpto de rol se describe brevemente en este capitulo, aunque por sirnplicidad no se desarrolla completamente hasta lu Parte II de este libro donde se explican todos los clasificadores en detalle,

Ejemplo

La realizaci6n de un caso de uso en el modelo de anallsls

En la Figura 3.4 describimos como se Ileva a cabo el caso de uso Sacar Dinero mediante una colaboracion (es decir, una realizacion de caso de usa) con una dependencia de "traza" (una traza es un

Modelo de casos

de usa

Modelo de anatlsts

~ .... trace»

~,, J

Sacar Dinero

Sacar Dinero

participante

f() f() 0 0

Salida lntertaz Retirada Cuenta

del Cajero de Efectivo

Figura 3.4. Las clascs de analisis que participan en la realizaci6n de Saear Dinero. Salida e Interfaz del Cajero son clascs de interfaz, Retirada de Efectivo es una clase de control, y Cucnta es una clase de cntidad.


estereotipo de dependencia que se indica mediante las comillas « y ») entre ellos, Y c6mo cuatro clases participan y desempeFian roles en la realizaci6n del caso de uso. Como puede verse en la figura, la notaci6n para una realizaci6n de caso de uso 0 colaboraci6n es una elipse con una linea de trazo discontinuo.

Comenzurnos normal mente examinando unos pocos casos de uso, crcando sus rcalizaciones, c idcntificando los roles de los clasificadores. Despues hacemos 10 mismo para mas casos de uso y proponemos nuevos roles de clasificador. Algunos de estos ultirnos pueden especificarse como roles nuevos 0 rnodificados de c1asificadores ya idcntificados, mientras que otros roles necesitaran nuevos clasificadores. Despues observamos de nuevo los primcros casos de usn, altcrnando de esta forma entre los cases de uso y construyendo gradualmente un modelo de analisis estable. AI final, cada clasificador puede participar y dcsernpefiar papeles en varias realizaciones de caso de uso.

Estereotipos de amilisis

En el modele de analisis, se utilizan tres estereotipos diferentes sobre las clases: "boundary class", "control class",y "entity class'? (traducidos al castellano, clase de interfaz, clase de control y clase de entidad, respectivamente). Salida e Interfaz del Cajero son clases de interfaz que se utilizan general mente para modelar la interacci6n entre el sistema y sus actores (es decir, los usuarios y los sistemas externos). Retirada de Efectivo es una clase de control que se utiliza general mente para representar coordinacion, secuenciamiento, transacciones y control de otros objetos -y se utiliza con frecuencia para encapsular el control relativo a un caso de uso (en el ejemplo, el caso de uso Sacar Dinero). Cuenta es una clase de entidad, que en general se utilizan para modelar informaci6n que tiene una vida larga Y que a veces es persistente. Por tanto, cada uno de estos estereotipos de clase encapsula un tipo diferente de comportamiento (0 funcionalidad, si se quiere). En consecuencia, los estereotipos nos ayudan a construir un sistema robusto, algo a 10 cual volveremos, para explicarlo en mas detalle, en el Capitulo 8. Tambien nos ayudan a encontrar activos reutilizables, ya que las clases de entidad son normalmente genericas para muchos casos de usc, y por tanto para muchas aplicaciones diferentes. La distincion de las clases de analisis en esos tres estereotipos se describe can mas detalle en [2]. Se lIeva utilizando desde hace muchos anos y hoy esta muy difundida e esta incluida en UML [12].

Ejemplo

Una clase que participa en varias realizaciones de caso de uso en el modele de analisis

En la parte izquierda de la Figura 3.5 tenemos un conjunto de casos de uso para un sistema de Cajero Automatico (el mismo de la Figura 3.3), y a la derecha tenemos la correspondiente estructura del sistema, en este caso, las clases de anal isis que realizan los casos de uso. La estructyra del sistema se modela en un diagrama de clases (Apendice A). Los diagramas de clases se utilizan generalmente para mostrar clases y sus relaciones, pero tarnbien pueden utilizarse para mostrar subsistemas e interfaces (como veremos cuando expliquemos el diseno en la Secci6n 3.4.3). Por sencillez, hemos

1 N. del T Hemos optado pm 110 traducir los cstcrcotipos en los diagrarnas UML.

r

Modelo de casos de uso

Ingresar Dinero

lJN PROCESa DIRIGIDO POR CASaS DE usa 43

Modelo de analisis

o 0

/ Salida Retirada

/e Efectivo~

~ ~ 0 ki

Cliente ~ c Interfaz Transferencias Cuenta

".'",0 ~.' C'i'''~ .:

~ ®

Receptor de Dinero

Ingreso

Figura 3.5. EI diagrarna rnucstra C(]1ll0 cuda caso de usa (izquierda) se realiza como una cstructura de clascs del an.ilisi» (dcrccha). POI' cjemplu. las clascs Intcrfaz del Cajero, Retirada de Efectivo. Cuenta y Salida participan en la rcalizacion delcaso de usn Sueur Dinero. Las closes Intcrlaz del Cajcro y Cucnta parricipan y desernpenan roles en las Ires realizaciones de casu de llSO. Las otras clases participan en una

sola realizacion de C<lSO de usn, es decir, desempefian un solo rol.

utilizado diferentes sombreados para indicar en que realizaciones de caso de uso participa y desernpefia alqun rol cada clase.

EI diagrama de clases para el sistema CA (Figura 3.5) se obtuvo a partir del estudio de las descripciones de los tres casos de uso y de la posterior busqueda de formas de llevar a cabo cada uno de ellos. Podriamos haber hecho alga como 10 siguiente:

• La realizaci6n de los tres casos de usa, Sacar Dinero, Transferencia entre Cuentas, e Ingresar Dinero implica a la clase Interfaz del Cajero y a la clase de entidad Cuenta. La ejecuci6n de cad a caso de uso comienza con un objeto (Apendice A) de la clase Interfaz del Cajero. Oespues, el trabajo continua en un objeto de control que coord ina la mayor parte del caso de uso en cuesti6n. La clase de este objeto es especffica de cad a caso de usa. La clase Retirada de Efectivo participa por tanto en el caso de uso Sacar Dinero, etc. EI objeto Retirada de Efectivo pide a la clase Salida que entregue el dinero, y este pide al objeto Cuenta que disminuya el saldo.

• EI objeto Transferencia pi de a los dos objetos Cuenta implicados en la realizaci6n del caso de usa Transferencia entre Cuentas que actualicen sus saldos.

• EI objeto Ingreso ace pta dinero a travss del Receptor de Dinero y pide al objeto Cuenta que incremente el saldo.

Hasta aqui hcrnos trabajado para obtener una estructura del sistema estable para la iteraci6n en curso. Hemos identificado las responsabilidades de los clasificadores participantes. y hemos cncontrado relaciones entre los clasificadores. Sin embargo. no hemos identificado en detalle la interaccion que debe tener lugar en el desarrollo de los casos de uso. Hemos encontrado la estructura, pero ahora es necesario sobreponer sobre esa estructura los diferentes patrones de interaccion necesurios para la realizaci6n de cada caso de uso.

44 EL PROCESO UNIHCADO DE DESARROLLO DE SOFTWARE

Como dijimos anteriormente, cadu casu de uso sc dcsarrol1a como una realizacion de casu de usn, y cada realizacion de caso de uso tiene un conjunto de clasificadorcs participantes, que desernpefian diferentes roles. Comprender los patrones de interaccion significa que describirnos como se lleva a cabo 0 se ejccuta (0 sc instancia) una real izacion de caso de LlSO. Par ejemplo, que ocurre cuando un Cliente de Banco concreto saca dinero, cs dccir, cuando el 0 ella ejecuta un casu de usn Sueur Dinero. Sabemos que las clases Interfaz del Cajero, Rctirada de Efectivo, Salida y Cuenta participaran en la realizacion del caso de usa. Tambien sabernos las responsabilidadcs que dcberian cumplir. Sin embargo, aun no sabemos como ellus -0 mas corrcctamente, como objetos de esas clases- interactuaran para llevar a cabo la realizucion del caso de uso. Esio es 10 siguiente que debcmos averiguar. Utilizamos fundamental mente diagramas de cola bora cion (Apcndice A) para modelar las interaccioncs entre objetos en el analisis, (UML tambien proporciona diagramas de secuencia para modelar interacciones, volvcremos a hablar de ellos cuando traternos el disefio cn la Seccion 3.4.3.) Un diagrama de coluhoraciun recuerda a un diagrama de clascs. pero contienc instancias y enlaces (Apendice A) en lugar de clases y asociaciones. Muestra como intcracnian Ins ohjelos secuencialmente 0 en paralelo, numerando los mensajes que se envian unos a otros.

Ejemplo

Uso de diagramas de colaboraci6n para describir una realizaci6n de caso de uso en el modelo de analisis

En la Figura 3.6 utilizamos un diagrama de colaboracion para describir como una sociedad de objetos de analisis Ileva a cabo la realizaclon del caso de uso Sacar Dinero.

EI diagrama muestra como el control pasa de un objeto a otro a medida que se Ileva a cabo el caso de usc, y los mensajes que se envfan entre los objetos. Un mensaje de un objeto dispara al objeto receptor para que tome el control y Ileve a cabo una de las responsabilidades de su clase.

EI nombre de un mensaje indica el motivo del objeto que realiza la lIamada en su interacci6n con el objeto invocado. Mas adelante, en el diserio, estos mensajes se retinaran en una 0 mas operaciones proporcionadas par las clases de disefio correspondientes (como veremos en la Seccion 3.4.3).

1 : identifieaeion .»

2: solieitar retirada

:Interfaz .......

d~o

3: validar y retirar

-+

:Cliente de Banco

:Retirada de Efectivo

:Cuenta

'-

5: entrega de dinero

¥

4: autorizar entrega

:Salida

Figura 3.6. Un diagrama de colaboracion para la realizacion del caso de uso Sacar Dinero en cl modele de analisis.

eN PROCESO D[R[GIDO POR CASOS DE usa 45

Como complemento a un diagrarna de colaboracion, los desarro!ladores pueden usar tarnbien texto para explicar como interacnian los objetos para !levar a cabo eI flujo de eventos del caso de uso. Existen muchas otras formas de describir una realizacion, como el texto estructurado 0 cl pscudocodigo.

Ejemplo

Descrlpclon del flujo de sucesos de una realizaclon de caso de uso

Oescribimos ahora la realizaci6n del caso de uso Sacar Dinero en terrninos de objetos y actores que interactuan, como se muestra en la Figura 3.6.

Un Cliente de Banco decide sacar dinero y act iva el objeto Interfaz del Cajero. EI Cliente de Banco se identifica y especifica la cantidad a retirar y la cuenta de [a cual hacerlo (1). Interfaz del Cajero verifica la identidad del Cliente de Banco y solicita al objeto Retirada de Efectivo que lIeve a cabo la transaccion (2).

Si la identidad del Cliente de Banco es valida, se Ie solicita al objeto Retirada de Efectivo que confirme si el cliente del banco tiene derecho a sacar la cantidad especificada de la Cuentao EI objeto Retirada de Efectivo 10 confirma solicitando al objeto Cuenta que valide la peticion y, si la peticion es valida, que reste la cantidad (3).

Despues el objeto Retirada de Efectivo autoriza a Salida a que entregue al Cliente de Banco la cantidad solicitada (4). Entonces es cuando el Cliente de Banco recibe la cantidad de dinero solicitada (5).

Observese que este sencillo ejemplo solo muestra un camino a traves de la realizacion del caso de usc, cuando todo sucede sin complicaciones. Podrian ocurrir complicaciones, por ejemplo, si el saldo de la Cuenta es demasiado bajo para permitir la retirada de efectivo.

En este momcnto, hcmos analizado cada caso de usa y por tanto hemos identificado todos los roles de clase que participan en cada realizaci6n de caso de uso. Ahora pasamos a c6mo analizar cada cJase.

3.4.2.

Cada clase debe cumplir todos sus roles de colaboraci6n

Las responsabilidades de una clase son sencillamente la recopilacion de todos los roles que cumple en todas las realizaciones de casu de uso. Juntandolas y eliminando repeticiones entre los roles, obtenemos una cspecificacion de todas las rcsponsabilidades y atributos de la clasc.

Los desarro!ladores responsables de analizar y realizar los casos de uso son los responsables de espccificar los roles de las clases. Un desarrollador responsable de una c1ase agrupa todos los roles de la clase en un conjunto completo de responsabilidades para la clase, y despues los integra en un conjunto consistente de responsabilidades,

Los dcsarrolladorcs responsables de analizar los casas de usn deben asegurarse de que las clases realizan los caxos de usn con la calidad adecuada. Si se cambia una clase, su desarrollador debe verificar que la clase sigue cumpliendo sus roles en las realizaciones de casos de usa. Si se cambia un rol en una realizacion de caso de uso, el desarrollador del caso de uso


debe cornunicar el cambia al dcsarrollador de la clase. Par tanto, los roles ayudan a mantener la integridad del analisis tanto a los desarrolladores de las clases, como a los de los casos de uso.

3.4.3.

Creaci6n del modelo de dlserio a partir del modelo de anal isis

EI modelo de disefio se crea tomando el modelo de analisis como entrada principal. pero se adapta al entorno de implementacion elegido, por ejemplo, a un object request broker, un kit de construccion de IGU. 0 a un sistema de gestion de bases de datos. Tarnbien debe adaptarse para reutilizar sistemas heredados (Apendice C) 1I otros marcos de trabajo desarrollados para el proyeeto. Par tanto, micntras que el modele de analisi« sirve como una primera aproximacion del modele de diseiio, el modelo de disefio funciona como esquema para la implcmcntacion.

De igual forma que cl modelo de analisis, el model a de discfio tarnbien define clasificadores (clasex, subsisternas e interfaces), rclaciones entre esos clasificadores, y colaboraciones que llevan a cabo los casos de usn (las realizaciones de casos de uso), Sin embargo, los elementos definidos en el modelo de disefio son las "contrapartidas de discno' de los elementos, mas conceptuales, dcfinidos en el modele de analixix, en el sentido de que los primeros (disefio) se adaptan al entorno de la irnplcrnentacion mientras que los tiltimos (analisis) no. Dicho de otra forma, el modelo de diseiio cs mas "fisico" por naturaleza, mientras que cl rnodelo de analisis cs mas "conceptual".

Puede hacerse la traza de una realizacion de caso de uso en el rnodelo de analisis a partir de una realizacion de caso de uso en eI modelo de disefio.

Ejemplo

Realizaciones de casos de uso en los model os de anallsls y dlsefio

En la Figura 3.7 describimos como el caso de uso Sacar Dinero se Ileva a cabo mediante una realizacion de caso de uso tanto en el modelo de analisis como en el modelo de dlserio.

Las realizaciones de caso de usa en los diferentes modelos sirven para casas distintas. Hecuerdese de la Seccion 3.4.1 (Figura 3.4) que las clases de analisis Intetiaz del Cajero, Retirada de Efectivo, Cuenta, y Salida participan en la realizacion del caso de usa Sacar Dinero en el modelo de analisis. Sin embargo, cuando se diserian esas clases del analisis, todas elias especifican y hacen surgir clases de diserio mas refinadas que se adaptan al entomo de lmplernentacion, como se ejemplifica en la Figura 3.8.

Modela de casas de usc

Modelo de anal isis

Modelo de dlsefio

C>:._._--

~:t:.:::~c.:,:~"~ __ ("' .. - - "':~ .. _<:t~::~c:c:~: __ ~ .. '" - - ....

... ..._ -»

Sacar Di nero

Sacar Dinero

Sacar Dinero

Figura 3.7. Rcalizacioncs de caso de uso en diferentes modelos.


Modelo

de anal isis

o

,

de diseiio :

,

Modelo

Interfaz del Cajero

11 A" 0- \<:,

/ : ; -, ,

I «trace» ,

, , ,

Salida

11 t:-f';.. ~

, I I ~

, , ' , .

, ,

Reti rad a de Electivo

t:-t::

cuenra

AAA

, , ,

, , ,

, ,

, ,

, , ,

" «trace» ~~

. «traca» \

,

«trace: \

"

>,

, ,

Dispositivo '

de visualizaci6n i

L- ___J:

~\,

,8'

,

Figura 3.8. Clases de dixeno del rnodclo de disefio con xu ... trazas hacia clases del modele de analisi».

Por ejemplo, la clase del analisis Ilamada Interfaz del Cajero se disefia mediante cuatro clases del diserio: Dispositivo de visualizacion, Teclado, Lector de Tarjetas, y Gestor de Cliente (esta ultima es una clase activa y por tanto se dibuja con borde grueso; vsase el Apenoice A).

Observese en la Figura 3.8 que la mayoria de las clases de diserio normal mente tienen una sola traza a una clase de anal isis. Esto es habitual para las clases de disefio que son especfficas de la aplicaciori, disefiadas para dar soporte a una aplicacion 0 a un conjunto de elias. Por tanto, la estructura del sistema definida por el modelo de anal isis se conserva de forma natural durante el disefio, aunque pueden ser necesarios algunos cambios (como por ejemplo, el Gestor de Cllente que participa en el diserio de las dos clases Interfaz del Cajero y Salida). Ademas, las classs activas (Gestor de Cliente, Gestor de Transacciones y Gestor de Cuentas) representan procesos que organizan el trabajo de las otras clases (no activas) cuando el sistema es distribuido (volveremos a este tema en la Seccion 4.5.3).

Como consecuencia, la raalizacion del caso de uso Sacar Dinero en el modelo de disefio debe describir como se realiza el caso de uso en terminos de las clases de diserio correspondientes. La Figura 3.9 muestra un diagrama de clases que es parte de la realizacion del caso de usa.

Es evidente que este diagrama de clases incluye mas detalles que el diagrama de clases del modelo de anal isis (Figura 3.5). Este detalle es necesario debido a la adaptacion del modelo de diserio al entorno de la lmplernentacion.

De manera parecida a como 10 haciamos en el anal isis (Figura 3.6), debemos identificar la interaccion detallada entre los objetos de diseno que tiene lugar cuando se Ileva a cabo el caso de usc en el modelo de diseno. Utilizamos principal mente diagramas de secuencia para modelar las interacciones entre objetos del oiseno, como se muestra en la Figura 3.10.

EI diagrama de secuencia muestra como el control -que comienza en la esquina superior izquierda- pasa de un objeto a otro a medida que se ejecuta el caso de uso y a medida que se envian mensajes entre objetos. Un mensaje enviado por un objeto dispara la toma del control en el objeto receptor y la reallzacion de las operaciones de su clase.

Es un ejercicio interesante cornparar este diagrama de secuencia con su "contrapartida de analisis" -es decir, el diagrama de colaboracion-> de la Figura 3.6. Como puede comprobarse, los dos

48 EL PROCESO UNIFlCADO DE DESARROLLO DE SOFTWARE

Figura 3.9. Un diagrama de clases que es parte de la realizacion del caso de uso Sacar Dinero en el modele de diserio. Cada clase de discfio participa y asurnc roles en la rcalizucion del caso de uso.

primeros mensajes del diagrama de colaboraei6n ("1: identifieaei6n" y "2: solieitar retirada") se disenan mediante todos los mensajes en el diagrama de secuencia de la Figura 3.10. Esto nos proporeiona una idea de la eomplejidad y de la cantidad de detalle que se incluye en el modelo de disefio en comparacion con la del modelo de anal isis.

:eliente I : Lec!or II :DisPOSitivo·,1 ~ I :Gestor II :Contador I ~ :Gestor de I
de Cliente de Efectivo Transacciones
de Banco de Tarjetas de vtsuattaecten ---
Introducir I I
taneta Tarjeta introduclda (10)
So.icnar C~diQO PIN
Mostrar petici6n
EspecificarlC6dlQO PIN
Ccdiqo PIN (PIN)
Solicitar validaci6n de PIN (PIN)
Soucitar cantidad a retirar
Mostra r peticion
.. I
Especificar cantidad
eantidad (e)
Solicitar disponibilidad de saldo (e)
I
Solicitar retirada de cantidad (e)
I ...

Figura 3.10. Un diagrarna de secuencia que es parte de la realizaci6n del easo de usn Sacar Dinero en el modele de diserio.

De igual forma que en los diagramas de colaboracion, los desarrolladores pueden tambien utillzar texto como complemento a los diagramas de secuencia -explicando c6mo interactuan los objetos de disefio para lIevar a cabo el flujo de eventos del caso de uso.

UN PROCESO DIRIGIDO POR CAS OS DE usn 49

Como puede observarse en estc ejernplo. el rnodelo de disefio contendra probablcmente muchas clases. Por tanto, cs necesaria una forma de organizarlas. Esto se hace mediante subsistemas. que tratamos en la siguiente scccion.

3.4.4.

Los subsistemas agrupan a las clases

Es imposible utilizar solo clases para realizar los easos de uso en un sistema grande con cientos 0 miles de clases: el sistema es dernasiado grande para poder comprcnderlo sin una organizacion de mas alto nivel. Las clases sc agrupan en subsistcrnas. Un subsisterna cs un agrupamiento scmanticamcnte util dc clases () de otros subsisternas, Un subsisterna posee un conjunto de interfaces que ofrcce a sus usuarios, Estas interfaces definen el eontcxto del subsisterna (actores y otros suhsistemas y clases).

Los suhsistemas de bajo nivel se denominan subsistemas de servicio (Apendice B: duse tambien el Capitulo 9) dcbido a que sus clascs llevan a cabo un servicio (para una descri pcion mas detallada del concepto de servicio, vease la Seccion 8.4.5.1). Los subsistcmas de scrvicio constituyen una unidad rnanejable de funcionalidad opcional (0 potcncialmentc opcional). S610 cs posible instalar un subsistema en un sistema del cliente si se hace en su totalidad. Los subsistcrnas de scrvicio tambien se utilizan para modclar grupos de clascs que tienden a carnbiar juntas.

Los subsisternas pueden discfiarse dcscendente 0 ascendentementc. Cuando se haec de manera ascendcnte, los desarrolladores proponen subsisternas basados cn las clases que ya han identificado; proponcn subsistcrnas que crnpaquetan las clascs en unidades con unas funciones clararnente definidas. Si en cambio los desarrolladores eligen un enfoquc descendente. el arquitecto identifica los subsisternas de mas alto nivel y las interfaces antes de que se hayan identi ficado las clases. Por tanto. se asigna a los desarrolladores cl trabajo con determinados subsistcmas para identificar y disefiar las clases dentro de sus subsistcmas. Prescntamos los subsistcmas en el Capitulo 1, y los explicaremos con mas profundidad en los Capftulos 4 y 9.

Los desarrolladores agrupan las clases en los tres subsistemas que se muestran en la Figura 3.11. Estos subsistemas se eligieron de forma que todas las clases que proporcionan la interfaz qrafica S8 ubican en un subsistema, todas las que lienen que ver can las cuentas en otro, y las clases especificas de los casas de usa en un tercero. La ventaja de colocar todas las clases de interfaz grafica en un subsistema de Interfaz GA es que podemos reemplazar este subsistema par otro que ofrezca la misma funcionalidad al subsistema de Gesti6n de Transacciones. Un subsistema de Interfaz GA alternativo podrfa ofrecer una implernentacion de la interfaz de usuario muy diferente, quiza disefiada para aceptar y entregar monedas en lugar de billetes.

Gada una de las clases especificas de los casos de uso en el subsistema de Gesti6n de Transacciones, como la clase Retirada de Etectivo, se colocan en un subsistema de servicio aparte. Gada uno de estos subsistemas de servicio podria contener mas de una class en realidad, pero no 10 hemos reflejado en nuestro sencillo ejemplo.

La Figura 3.11 tarnbien muestra las interfaces entre los subsistemas. Un drculo representa una interfaz. La linea continua de una clase a una interfaz significa que la clase proporciona la interfaz.


«subsystem" Gestion de Cuentas

Gestlon

de Transacciones

"service subsystem»

Gestion de Retirada

Figura 3.11. Tres subsistcmas y un subsistcma de servicio (en gris dentro del subsistcma de Gcxrion de Transacciones) para nuestro ejemplo sencillo del CA.

Una linea de trazo discontinuo de una class a una interfaz significa que la clase usa la interfaz. Por sencillez, no mostramos las interfaces que proporcionan 0 utilizan los actores; en su lugar, empleamos asociaciones normales.

La interfaz Transferencias define operaciones para transferir dinero entre cuentas, retirar dinero, e ingresar dinero en cuentas. La interfaz Retirada de Efectivo define operaciones para solicitar retiradas de efectivo de una cuenta. La interfaz Entrega define operaciones que otros subsistemas, como el de Gesti6n de Transacciones, pueden utilizar para entregar dinero al cliente del banco.

3.4.5.

Creaci6n del modelo de implementaclon a partir del modelo de dlsefio

Durante el tlujo de trabajo de implernentacion desarrollamos todo 10 necesario para obtcner un sistema ejecutahle: compnnentes ejecutables, componentes de fichero (c6digo fuentc, guiones shell, etc). componentes de tabla (elementos de la base de datos), etc. Un componente es una parte ffsica y reemplazable del sistema que cumple y proporciona la realizacion de un conjunto de interfaces. EI modelo de implemcntaci6n est.i forrnado por componentes, que incluyen todos los ejecutables (Apendice A: vease tarnbien cl Capitulo 10) tales como cornponentes ActiveX y JavaBeans, aSI como otros tipos de componentes.

Ejemplo

Componentes en el modelo de lmpternentaclon

En la Figura 3.12 se muestran los componentes que implementan las clases de disefio (como se defini6 en la Secci6n 3.4.3).

Por ejemplo, el componente fichero salida.c contiene el c6digo fuente de tres clases (y por tanto las implementa): Alimentador de la Salida, Gestor de Cliente, y Contador de Efectivo. Este compo-

r

UN PROCESO DIRIGTDO POR CASOS DE usa 51

Modelo de oiserio

Modelo de implementaci6n

Figura 3.12. Cornponentes que invplcmerwan clascs de di . sefio.

nente fichero se compilara y emazara junto con el componente fichero cliente.c para obtener cliente.exe, que es un ejecutable.

Un cornponente presupone un contexte de la arquitcctura definido por sus interfaces. Tarnbien es reernplazable, es decir, los desarrolladores pueden intercarnbiar un componente con otro, quints rnejor, siempre que el nuevo proporcione y requiera las mismas interfaces. Normalmente existe una forma directa de implementar un subsistema de servicio del rnodelo de discfio mediante componentes que pueden asignarse a nodos del modelo de despliegue. Cada subsistema de servicio se implerncntara mediante un componente si siempre se asigna a un mismo tipo de nodo en cl modele de c1espliegue. Si se asigna a mas de un nodo, podemos dividir el subsislema de servicio -Ilormalmente separando algunas clases->- en tantas partes como tipos de nodo. En cste caso, cada parte del subsistema de servicio se implementara como un componcnte.

Ejemplo

Un subsistema de servicio implementado mediante componentes

Supongamos que hemos elegido una soluci6n cliente/servidor (vease la Secci6n 9.5.1.1) para nuestro ejemplo del Cajero Automatico, Podriamos distribuir tanto en el cliente como en e\ servidor parte del subsistema de servicio Gestion de Retirada de Efectivo (Figura 3.11) que contiene a la clase Retirada. EI subsistema de servicio Gestion de Retirada de Efectivo podrfa implementarse mediante dos componentes: "Retirada en el Cliente" y "Retirada en el Servidor".

Si los componentcs se implementan en un lenguaje de programacion orientado a objetos, la irnplcmentacion de las clases es tam bien directa. Cada clase de diserio se corresponde con una clase en la implernentacion, por ejemplo, c1ases c++ 0 Java. Cada componente fichero puede implementar varias de esas clases, dependiendo de las convenciones del lenguaje de prograrnacion.

Pero la irnplernentacion es mas que el desarrollo del codigo para crear un sistema ejecutable.

Los desarrolladores responsables de implerncntar un componente son tam bien responsablex de hacer su prueba de unidad antes de enviarlo a las prucbas de integracion y del sistema.


3.5.

Prueba de los casas de usa

Durante la prueba, verificarnos que el sistema irnplerncnta correctamente su especificacion. Dcsarrollamos un modele de prucbu cornpucsto por casos de prueba y procedimientos de prueba (Apendice C; veasc tambien el Capftulo II) y despucs ejecutarnos los casos de prueba para estar seguros de que el sistema funcionu como esperantos. Un caso de prueba es un conjunto de cntradas de prueba, condiciones de ejccucion, y resultados csperados, desarrollados para un objetivo concreto, tal como probar un camino concreto a traves de un caso de uso, 0 vcrificar que se cumple un requisite cspecifico. Un procedimiento de prueba es una especificacion de como llevar a cabo la preparucion, ejccucion, y cvaluaci6n de los resultados de un caso de prueba particular. Los proccdimicntos de prueba tambicn pucden derivarse de los cases de uso. Los defectos hall ados se anal izan para localizar el problema. Despues estes problemas se priorizan y sc corrigen par orden de importancia.

En la Seccion 3.3, comenzamos con la captura de los casos de usn, y despues ell la Seccion 3.4 analizamos, disefiamos, c implementamos un sistema que lIevaba a cabo los casos de uso. Ahora, describiremos como probar que los casos de uso se han irnplementado correctamente. De alguna forma, esto no es nada nuevo. Los desarrolladores sicmpre han probado los casos de usn, incluso antes de que se acunara cl termino casu de [ISO. La forma practica de probar las Iuncioncs de Ull sistema es Ia prueba de que el sistema puede utilizarse de maneras que tengan scntido para los usuaries. Sin embargo, pOI' otro iado, csta es una tecnica nueva. Es nueva ya que identificamos los casos de prueba (como cases de uso durante el tlujo de trabajo de los requisitos) antes de que tan siquiera comencernos a diseiiar el sistema, y despues nos asegurarnos de que nuestro diseno real mente irnplemcntu los cases de uso.

Ejemplo

Identificaci6n de un caso de prueba a partir de un caso de uso

En la Figura 3.13 mostramos un caso de prueba, Sacar Dinero-Flujo Basico, que especifica como probar el flujo basico del caso de uso Sacar Dinero.

Observese el nuevo estereotipo que presentamos aqui para los casos de prueba, un sfmbolo de caso de uso con una cruz dentro. Hacemos esto para poder dibujar los casos de prueba en los diagramas (vsase el Capitulo 11).

Modelo de casas de usa

c=:x- - - - - - -- _:'~r31~~:'_ --0

Modelo de prueba

Sacar Dinero

Sacar DineroFlujo Basico

Figura 3.13. Un caso de prueba del modclo de prueba que cspecifica cumo probar un caso de uso (Sacar Dinero) del modele de casos de uso.

r

UN PROCESO DIRIGIDO POR CASOS DE usn 53

EI caso de prueba especifica la entrada, los resultados esperados, y otras condiciones relevantes para verificar el flujo basico del caso de uso Sacar Dinero:

Entradas:

• La cuenta 12-121-1211 del Cliente de Banco tiene un saldo de 350 d6lares.

• EI Cliente de Banco se identifica correctamente.

• EI Cliente de Banco solicita la retirada de 200 d61ares de la cuenta 12-121-1211.

• Hay suficiente dinero (por 10 menos 200 d6lares) en el Cajero Autornatico.

Resultados:

• EI saldo de la cuenta 12-121-1211 del Cliente de Banco disminuye a 150 d6lares.

• EI Cliente de Banco recibe 200 d61ares del Cajero Autornatico.

Condiciones:

No se permite a ninqun otro caso de uso (instancias de) acceder ala cuenta 12-121-1211 durante la ejecucion del caso de prueba.

Observese que cste caso de prucba se basa en la descripcion del caso de uso Sacar Dinero que se dio en la Seccion 3.3.3. Mediante la identificaci6n tcmprana de los casos de uso, podemas comenzar pronto la planificacion de las actividades de prueba, y podemos proponer casas de prueba desde el comienzo. Estos casas de prueba podran detallarse mas durante el disefio, cuando sepamos mas sobre como el sistema llevara a cabo los cases de usa. Algunas herramientas generan los casos de prueba a partir del modelo de disefio -todo 10 que hay que hacer es introducir munualmente los datos necesarios para ejecutar las pruebas.

Las pruebas de los casos de uso pueden llevarse a cabo bien desde la pcrspecti va de un actor que considera el sistema como una caja negra, 0 bien desde una perspectiva de disefio, en la cual el caso de prueba sc construyc para verificar que las instancias de las clases participantes en la realizacion del caso de uso hacen 10 que deberfan hacer. Las prucbas de caja negra pucden identificarse, espccificarse y planificarse tan pronto como los requisitos sean algo establcs.

Tambien hay otro tipo de prucbas, como las del sistema, las de aceptacion, y las de la documentaci6n de usuario. Hablaremos mas sobre las pruebas en el Capitulo 11.

3.6.

Resumen

Los casos de uso dirigen el proceso. Durante el flujo de trabajo de los requisites, los desarrolladores pucden representar los requisitos en la forma de casas de usa. Los jefes de proyecto pueden dcspues planificar el proyecto en terminos de los casos de uso can los cuales trabajan los desarrolladores. Durante el analisis y el disefio, los desarrolladores crean realizaciones de casos de uso en terminos de clases y subsistemas. Los componentes se incorporan en los incrernentos, y cada uno de ellos realiza un conjunto de casos de uso. Por ultimo, los ingenieros de prueba verifican que el sistema implernenta los casos de uso correctos para los usuarios. En otras palabras, los casos de uso enlazan todas las actividades del desarrollo y dirigen el proceso de desarrollo --este es quiza el beneficia mas importante de 1a aproximacion dirigida por los casas de uso.

Los casas de uso proporcionan muchos beneficios al proyecto. Sin embargo, no son todo.

En el siguiente capitulo hablaremos sobre otro aspecto muy irnportante del Proceso Unificado -el estar centrado en la arquitectura.

15] Ivar Jacobson, "Use cases and objects", ROAD 1(4), November-December 1994.

54 EL PROCESO UNIFICADO DE DESARROLl.o DE SOFfWARE

3.7. Referencias

[I] Ivar Jacobson. "Object-oriented development in an industrial environment", Proceedings (~l OOPSLA '87, Special issue of SIGPLAN Notices 22( 12): 183- 19 I, December 1987.

[2] Ivar Jacobson. Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, ObjectOriented Software Engineering: A Use-Case Driven Approach, Reading, MA: AddisonWesley. 1992 (Revised fourth printing. 19(3).

r3] Tvar Jacobson, "Basic use case modeling," ROAD I (2), July-August 1994.

14J Ivar Jacobson, "Basic Use Case Modeling (continued),', ROAD I (3), September-October 1994.

[61 Ivar Jacobson and Magnus Christerson, "A growing consensus on LIse cases", Journal of Object-Oriented Programming, March-April 1995.

[71 Ivar Jacobson and Sten Jacobson, "Usc-case engineering: Unlocking the power", Object Magazine, October 1996.

[SJ Karl Wieger, "Use cases: Listening to the customer's voice", Software Development, March 1997.

[9 J E. Ecklund, L. Delcambre, and M. FreiIing, "Change cases: Use cases that identify future requirements", Proceedings, Conference OIl Object-Oriented Programming Systems, Languages, & Applications (OOPSLA '96), ACM, 1996, pp. 342-358.

[JOI Alistair Cockburn, "Structuring use cases with goals", Report on Analysis & Design (ROAD), 1997.

[Ill Geri Schneider and Jason Winters, Applying Usc Cases: A Practical Approach, Reading, MA: Addison-Wesley, 1998.

r 12] OMG Unified Modeling Language Specification. Object Management Group, Framingham, MA, 1998. Internet: www.omg.org,

Capitulo 4

Un proceso centrado en la arquitectura

En el Capnulo 3, comenzamos can una simplificacion, dicien.do que s610 los casas de uso mostrarian el camino a traves de los requisitos, analisis. disefio, implernentacion y prucbas para producir un sistema. No obstante, para desarrollar software hay que hacer algo mas que conducirse a ciegas a traves de los tlujos de trabajo guiado exclusivamente por los casos de uso.

Los cases de usn solarncntc no son suficientes. Se neccsitan mas cosas para conseguir un sistema de trabajo. Esas "cosas' son la arquitectura. Podemos pensar que la arquitectura de un sistema es la vision comun en la que todos los ernpleados (desarrolladores y otros usuarios) deben cstar de acuerdo, o como poco. deben aceptar. La arquitectura nos da una clara perspeetiva del sistema complete, necesaria para controlar el desarrollo.

Necesitarnos una arquitectura que describa los elementos del modelo que son mas importantes para nosotros. (.C6mo podemos determinar que elementos son importantes? Su importancia reside en el hecho de que nos guian en nuestro trabajo con el sistema, tanto en este cicio como a traves del ciclo de vida completo. Estos elementos signifieativos, arquitectonicarnente hablando, incluyen algunos de los subsistemas, dependencias, interfaces, colaboraciones, nodos y clasex activas (Apendice A; vease tarnbien la Seccion 9.3.2). Describen los cimientos del sistema, que son necesarios como base para comprenderlo, desarrollarlo y producirlo economicarnente.

Vamos a comparar un proyecto software con la construccion de un garaje de uso individual.

En primer lugar, el constructor deberia considerar como quieren utilizar el garaje los usuarios.

56 EL PROCESO UNTFICADO DE DESARROLLO DE SOFTWARE

Un casu de usa podrfa scr ciertamentc Guardar el Coche, es dccir, conducir cl coche dentro del garaje, y dejarlo alli para sacarlo mas tarde.

l,Tendra el usuario algun otro uso en mente? Supongamos que quiere utilizarlo tarnbicn como taller. Esto Ileva al constructor a pensar en las necesidades de luz -algunas ventanas y luz electrica=-. Muchas herrarnientas funcionan con electricidad, asf que el constructor debe plancar poner media docena de enchufes y el suficiente voltaje para soportarlos. De alguna forma, el constructor esta desarrollando una arquitcctura simple. Puede haccrlo mental mente porque ya ha visto un garaje antes. Ha visto un banco de trabajo antes. EI sabe que una persona necesita un banco de trabajo para trabajar. EI enfoque del constructor no es ciego porque ya esta familiarizado con la arquitectura tipica de un pequeiio garaje. Simplcmente ha juntado las partes para adecuar el garaje para su uso, i. Y si el constructor nunca ha visto un garaje y se centra ciegamente en la forma en que se utilizana? Construirfa un garaje muy extrafio. ASI que necesita considerar no solamente la funcionalidad del garaje, sino su forma.

Construir una casa can 10 habitaciones, una catedral, un centro comercial 0 un rascacielos, son tareas diferentes. Hay muchas formas de construir grandes edificios como estes. Para disefiarlos sc requiere un equipo de arquitectos. Los miembros del equipo tendran que mantenerse informados del progreso de la arquitectura. Esto significa que tendran que registrar su trabajo de forma que sea comprensible para los otros miembros del equipo. Tambien tendran que presentarselo de forma cornprensible a una persona no experta -ya sea el propietario, el usuario u OtIOS imeresados-. Por ultimo, tambien deben informar de la arquitectura al constructor y a los proveedores de materiales mediante los pIanos del edificio,

De forma similar. el desarrollo de muchos sistemas software -0 de sistemas software con el hardware correspondiente sobre el que se ejecuta- requiere el pensar y registrar las ideas de forma eomprcsible, no solo para los siguientes desarrolladores, sino para otro tipo de usuaries. Es mas, estas ideas, esta arquitectura, no brotan hechas y dercchas del monte de Zeus: los arquitectos las desarrollan iterando repetidas veces durante la fase de inicio y elaboraci6n. De hecho, el primer objetivo de la fase de elaboracion es establecer una arquitectura salida de forma que sea una arquitectura base ejecutable (Apendice C). Como resultado, se entra en la fase de construccion con unos fundamentos solidos para construir el resto del sistema.

4.1.

La arquitectura en pocas palabras

Necesitarnos una arquitectura, bien. Pero, i.que quiere decir exactamente "arquitectura de sistemas software"? A rnedida que uno busca en la literatura sobre arquiteetura software, nos viene ala cabeza la parabola del ciego y cl elefante. Un elefante es todo 10 que el hombre ciego va encontrando -una gran serpiente (la trompa), un trozo de cuerda (la cola), un arbol pequefio (la pata)-. De forma similar. Ia idea de arquitectura, al menos reducida a una sencilla frase definitoria, es 10 que se encuentra en la mente del autor en esc pun to.

Vamos a comparar de nuevo la arquitectura software con la construccion de casas. Un edificio es habitualmente una sola unidad desde la perspectiva del cliente. El arquitecto del edificio, por tanto, puede encontrar iitil el hacer una maqueta a escala del edificio, junto con los dibujos del edificio visto desde distintas perspectivas. Estos pIanos no son muy detallados par 10 general. pero son comprensibles para el cliente.

No obstante. la construccion de edificios implica a otro tipo de trabajadores durante la fase de construccion, como carpinteros, albafiiles, peones. soladores, fontaneros y electricistas.

r

I

I

UN PROCESO CENTRADO EN LA ARQUITECTURA 57

Todos ellos necesitan mas detalles y pianos especializados del edificio, y todos estes pianos deben ser consistentes unos con otros. Las tuberfas de ventilacion y las tuberias de agua, por ejemplo, no deben estar situadas en el mismo espacio fisico. EI papel del arquitecto es crear los aspectos mas significativos del discfio del edificio en su conjunto. As] que el arquitccto hace un conjunto de pIanos del edificio que describcn muchos de los bloques del cdificio, tales como los pilarcs en la excavacion, Un ingcniero de cstructuras determina el tarnafio de las vigas que soportan la estructura, Los pilares soportan las parcdes, los sueJos y el techo. Esta estructura contiene sistemas para ascensores, agua, elcctricidad, aire acondicionado, sanitarios, etc. Sin embargo. cstos pIanos de la arquitectura no son 10 suficientemente dctallados para que los constructores trabajcn a partir de cllos. Los delineantes preparan pIanos y espccificaciones que proporcionan detalles sabre la eleccion de materiales, subsisternas de ventilacion, y cosas asf, EI arquitecto tiene la responsabilidad global sobre el proyecto, pero estes otros tipos de diseriadores completan los dctalles. En general, el arquitecto es un experto en integrar todos los aspectos del cdificio, pero no es un expcrto en cada aspccto. Cuando todos los planes estan hechos, los pianos de la arquitectura cuhren iinicamente las partes principales del edificio, Los pianos son vistas de todos los otros pianos, siendo consisterues con todos ellos.

Durante la construccion, distintos trabajadorcs utilizaran los planes de la arquitectura -las vistas de los pIanos detallados- para tener una buena vision global del edificio, pero se fianin de los planos de la construccion mas detallados para realizar su trabajo.

Como un cdificio, un sistema software es una iinica entidad, pero al arquitecto del softwure y a los desarrolladores les resulta util presentar el sistema desde diferentes perspectivas para cornprender mejor el diserio. ESlaS perspectivas son vistas (Apendices A y C) del modelo del sistema. Todas las vistas juntas rcpresentan la arquitectura,

La arquitcctura software abarca decisiones importantes sobre:

• La organizacion del sistema software.

• Los elementos cstructurules que cornpondran el sistema y sus interfaces. junto con sus comportamientos, tal y como se especifican en las colaboraciones entre estes elementos.

• La composicion de los elementos estructurales y del comportamiento en subsisternas progresivamente mas grandes.

• EI estilo de la arquitectura (Apendice C) que gufa esta organizacion: los elementos y sus interfaces. sus colaboraciones y su cornposicion.

Sin embargo, la arquitcctura software esta afectada no s610 por la estructura y el comportaruicnto, sino tambien pur el uso, la funcionalidad, el rendimiento, la flexibilidad, la rcutilizacion, la Iacilidad de cornprcnsion, las restricciones y compromises econ6mieos y tecnologicos, y la estctica.

En la Scccion 4.4. discutiremos cl concepto de arquiteetura software en terrninos mas concretos y se describira como representarla utilizando el Proceso Unificado, No obstante, aqui insinuaremos una descripcion de la arquitectura (Apendice C). Ya hemos dichu que la arquitectum se representa mediante vistas del modelo: una vista del modelo de cases de uso, una vista del modelo de analisis, una vista del modclo de diseiio, etc. Este conjunto de vistas concuerda con las 4+ 1 vistas discutidas en r31. Ya que una vista de un modelo es un extracto, ° una parte de ese rnodelo, una vista del modelo de casus de uso, por ejemplo, se parecc al propio modelo de casos de uso. Tiene actores y casos de uso, peru solamente aquellos que son arquitectonicarnente

4.2.1.

Comprension del sistema

58 EL PROCESO UNlFICADO DE DESARROLLO DE SOFTWARE

significativos, De forma similar, la vista de la arquitectura del modelo de disefio se parece al modelo de disefio, pero contiene exclusivarnente aquellos elementos del disefio que cornprenden los casos de uso importantes desde el punto de vista de la arquitectura tvease la Seccion 12.6.2).

No hay nada rnagico en la descripcion de la arquitectura. Es como lin descripcion cornpleta del sistema con todos sus model os (hay algunas diferencias que comentaremos mas tarde), pero mas pequefio.jComo de pequefio? No hay un tarnano absoluto para la descripcion de la arquitectura, pero scgun nuestro experiencia una gran clase de sistemas suele estar entre 50 y 100 paginas. Ese rango es aplicable en sistemas de una sola aplicacion (Apendice C); las descripciones de arquitectura para sistemas de conjuntos de aplicaciones sera mayor (Apendice C).

4.2.

Por que es necesaria la arquitectura

Un sistema software grande y complejo rcquiere una arquitectura para que los desarrolladores puedan progrcsar hasta tener una vision cormin. Un sistema software es dificil de abarcar visualmente porque no existe en un mundo de tres dimensiones. Es a menudo iinico y sin precedente en detenninados aspectos. Suele utilizar teenologfa poco probada 0 una mezcla de tecnologias nuevas. Tampoeo es raro que el sistema lleve a sus iiltimos lfrnites la teenologfa existcnte, Adernas, debe ser construido para acomodar gran cantidad de clases que sufriran cambios futuros. A medida que los sistemas se hacen mas cornplejos, "los problemas de diseno van mas alla de los algoritrnos y las estructuras de datos para su cornputacion: para disefiar y especificar una estructura del sistema global surgen nuevos tipos de problemas" [I J.

Adernas, existe con frecuencia un sistema que ya rcaliza algunas de las funciones del sistema propuesto, El saber identificar que haee estc sistema, casi sicmpre con poca 0 ninguna documentacion, y que c6digo pueden reutilizar los desarrolludores, afiade complejidad at desarrollo.

Se necesita una arquitectura para:

• Comprender el sistema.

• Organizar e1 desarrollo.

• Fomentar la rcutilizacion.

• Hacer evolucionar el sistema.

Para que una organizacion desarrolle un sistema, dicho sistema debe ser comprendido por todos los que vayan a intervenir en d. El haeer que los sistemas modcrnos sean comprensibles es un reto importante por much as razones:

• Abarcan un comportamiento complejo.

• Operan en entornos complejos.

• Son tecnologicamente complejos.

• A menudo eombinan cornputacion distribuida. produetos y plataforrnas eomerciales (como sistemas operativos y sistemas gestores de bases de datos) y reutilizan cornponentes y marcos de trabajo.

• Deben satisfacer demandas individuates y de la organizaci6n.

UN PROCESO CENTRADO EN LA ARQUTTECTURA 59

• En algunos cases son tan grandes que la direccion tiene que dividir el trabajo de desarrollo en varios proyectos, que estan a menudo separados geograficarnente, afiadiendo dificultades ala hora de coordinarlos.

Por otra parte, estos factores cambian constantemente. Todo esto afiade dificultad potencial para comprendcr la situaci6n.

Para realizar un desarrollo centrado en la arquitectura (Apendice C) hay que prevenir estos fallos en la compresion del sistema. Por consiguiente, el primer requisito que tiene lugar en una descripcion de la arquitectura cs que se debe capacitar a los desarrolladores. directives, clientes y otros usuarios para cornprender que se esta haciendo con suficiente detalle como para facilitar su propia participaci6n. Los model os y diagramas que rncncionamos en el Capitulo J ayudan a esto, y deben utilizarse para describir la arquitectura. A medida que la gente se vaya familiarizando con UML, encontraran mas facil de comprender la arquitectura modclada en ese lenguaje.

4.2.2.

Organizaci6n del desarrollo

Cuanto mayor sea la organizacion del proyecto software, mayor sera la sobrecarga de comunicacion entre los desarrolladores para intentar coordinar sus csfuerzos. Esta sobrecarga se incrementa cuando el proyecto esta geograficamentc disperse. Dividiendo el sistema en subsisternas, con las interfaces clara mente definidas y con un responsable 0 un grupo de responsables establecido para cada subsistcma, el arquitecto puede reducir la carga de comunicacion entre los grupos de trabajo de los difcrentes subsistemas, tanto si estan en el misrno edificio como si estan en diferentes continentes. Una "buena" arquitectura es la que define explfcitamente estas interfaces, haciendo que sea posible la reduccion en la comunicacion, Una interfaz bien definida "cornunica" eficientemcnte a los desarrolladores de ambas partes que necesitan saber sobre 10 que los otros equipos estan haciendo.

Las interfaces estahlcs permiten que el software de amhas partes progrese independientemente. Una arquitectura y unos patrones de disefio (Apendice C) adecuados nos ayudan a encontrar las interfaces correctas entre los subsistemas. Un ejemplo es el patron Boundary-Control-Entity (v/ase la Seccion 4.3.1), que nos ayuda a distinguir el comportamiento especffico de los casos de uso, las clases de interfaz y las clases genericas,

4.2.3.

Fomento de la reutilizaci6n

Permftanos usar una analogfa para explicar como la arquitectura es importante para la reutilizacion. La industria de la fontanerfa esta estandarizada desde hace ticmpo, Los contratistas de fontaneria se benefician de componentes estandar, En lugar de esforzarse en encajar la dimension de cornponentes "crcativos", obtenidos de aqui y de alia, el fontanero los selecciona de un conjunto de componentes estandarizados que siempre se ajustaran,

Como el fontanero, los desarrolladores capaces de reutilizar conocen cl dominio del problema (Apendice C) y que componentes cspecifica como adecuados la arquitectura. Los desarrolladores piensan en como conectar esos componentes para cumplir con los requisites del sistema y realizar el modelo de casos de uso. Cuando tienen disponibles componentes reutilizables, los usan. Como los elementos estandar de fontaneria, los cornponentes software reutilizables estan disefiados y probados para encajar, y asf el tiempo de construccion y el coste son menores. EI resultado cs predecible. Como en la industria de la fontaneria, donde la estandarizaci6n llevo

EI Sistema AXE de Ericsson - Sobre la importancia de la arquitectura


siglos, en la estandarizacion del software se va avanzando con la experiencia -pero esperamos que se incrernente la "componentizacion' de aqui a un par de anos-. De heche, ya ha comenzado.

La industria del software todavia ticne que alcanzar el nivcl de estandarizacion que muchos dominies hardware han conseguido, pero las bucnas arquitecturas y las interfaces bien definidas son pasos en esa direcci6n. Una buena arquitectura ofrece a los desarrolladores un andamio establc sobre el que trabajar, EI papel de los arquitectos ex definir ese andamiaje y los subsistemas reutilizables que el desarrollador pueda utilizar, Se obtienen subsistemas reutilzables disefiandolos con cuidado para que puedan ser utilizados conjuntamente [21, Un buen arquitecto ayuda a los desarrolladores para que sepan d6nde buscar elementos reutilizables de manera poco costosa, y para que puedan encontrar los componentes adecuados para scr rcutilizados. EI UML acelerara el proceso de "construccion de componentes", porque un lenguaje de modelado estandar es un prerrequisito para construir componentes especfficos del dominio que puedan estar disponibles para su reutilizacion.

4.2.4.

Evoluci6n del sistema

Si hay algo de 10 que podemos estar seguros, es de que cualquier sistema de un tamafio considerable evolucionara. Evolucionara incluso aunque arin estc en desarrollo. Mas tarde, cuando cste en usn, el entorno cambiante provocara futuras evoluciones. Hasta que esto ocurra, el sistema debe ser facil de modificar; esto quiere dccir que los desarrolladores debcrfan ser capaces de modificar partes del diseno e irnplernentacion sin tener que preocuparse POf los efectos inesperados que puedan tener repercusion en el sistema. En la mayona de los cases, deberian ser capaces de implementar nuevas funcionalidades (es decir, casos de uso) en el sistema sin tener que pensar en un irnpacto dramatico en el disefio c implementacion existentes. En otras palabras, el sistema debe ser en sf mismo flexible a los cambios 0 tolerante a los carnbios. Otra forma de enunciar este objetivo es afirmar que el sistema debe ser capaz de evolucionar sin problemas. Las arquitccturas clel sistema pobres, por el contrario, suelen degradarse con el paso del tiempo y necesitan ser "parchcadas" hasta que al final no es posiblc actualizarlas con un coste razonable.

Ejemplo

EI sistema de conrnutacion de telecomunicaciones de Ericsson se desarrollo inicialmente a principio de los setenta usando una primera version de nuestros principios de las arquitecturas. La descrlpcion de la arquitectura software es un artefacto importante que ha guiado el desarrollo completo del trabajo a 10 largo de la vida del sistema. La arquitectura estaba guiada par un par de principios que ahora S8 han incorporado al Proceso Unificado.

Uno de estos principios era el de la rnodularizacion de funciones. Las clases 0 los elementos de disefio equivalentes se agruparon en bloques funcionales, 0 subsistemas de servicio, que los ellentes podian considerar como opcionales (incluso si se entregaban a todos los clientes). Un subsistema de servicio tenia una fuerte cohesion interna. Los cambios en el sistema solian localizarse en un subsisterna de servicio y raramente estos cam bios afectaban a mas de un servicio,

Otro de los principios era el de separar el disefio de interfaces del disefio de subsistemas de servicio. EI objetivo era conseguir diserios "conectables" 1, donde muchos subsistemas de servicio po-

I Se ha optado por csta traduccion para cl tcrrnino ingle's "plug-able", [lllnqlle podria habcrsc mantenido el original debido a Sll amplia ditusion.

r

UN PROCESO CENTRADO EN LA ARQUITECTURA

61

dian soportar la misma interfaz. Cambiar un subsistema de servicio por otro podia hacerse sin cambiar los clientes del subsisterna de servicio (los cuales dependian solamente de las interfaces, no del c6digo del subsistema de servicio).

Un tercer principle era hacer corresponder los subsistemas de servicio en el oiseno a uno 0 mas componentes de la implementaci6n. Los componentes de los subsistemas de servicio podian ser distribuidos en diferentes nodos de computacion, Habla exactamente un componente por cada nodo de proceso en el cual el subsistema de servicio podia ser ejecutado. Asi, si el subsistema de servicio se ejecutaba en el ordenador central (servidor), entonces habrfa exactamente un componente para el subsistema. Si el subsistema estaba siendo implementado en ambos, clientes y servidor, habrfa dos componentes. Este principio sirnplitico la qestion de los cam bios en el software en las diferentes instalaciones.

Todavfa hay otro principio, que era el bajo acoplamiento entre los subsistemas de servicio. La unica cornunicacion entre los subsistemas de servicio eran las seriales, Aunque las sefiales eran asfncronas (semantics de envfo sin respuesta), estas no solo soportaban encapsulacion, sino tambien distribucion.

Dado que su comienzo y su consiguiente desarrollo fue guiado por una arquitectura bien diseriada, el sistema AXE continua hoy en uso, con mas de un centenar de clientes y varios miles de instalaciones. Se espera que continue funcionando durante decadas, con los cam bios necesarios.

4.3.

Casas de usa y arquitectura

Ya hemos sefialado que existe cierta interaccion entre los casus de uso y la arquitectura. En el Capitulo 3 mostramos por primera vez como desarrollar un sistema que proporciona los casas de uso correctos a sus usuarios. Si el sistema proporciona los casos de usa currectos --casos de uso de alto rendirnicnto, calidad y facilidad de utilizaci6n- los usuarios pueden emplearlo para llevar a cabo sus objetivos. Pero, (,como podemos conseguirlo? La respuesta, como ya hemos sugcrido, es construir una arquitectura que nos permita implementar los casas de uso de una forma econornica, ahora y en el futuro.

Vamos a clarificar como succde esta interacci6n, obscrvando primero que influye en la arquitectura (viase Ia Figura 4.1) y despues que influye en los casos de uso.

Restricciones Y posibilidades

(SOSde uso

( Mqu"ectur.

Experiencia:

• Arquitecturas anteriores

• Patrones de la arquitectura

Software del sistema

Capa intermedia (incluyendo marcos de trabajo)

Sistemas heredados

Estandares y polfticas

Requisitos no funcionales

Necesidades de distribuci6n

Figura 4.1. Existcn diferentes tipos de requisitos y productos que influycn en la arquitectura, aparte de los casas de usn. Tambien son de ayuda en el disefio de una arquitectura la experiencia de trabajos anteriores y las estructuras que podamos identificar como patrones de la arquitectura.

Como ya hemos dicho, la arquitectura esta condicionada par los casas de uso que queremos que soporte el sistema: los casos de usa son directores de la arquitectura. Despues de todo, quercmos una arquitectura viable a la hora de implementar nuestros casas de uso. En las primeras iteraciones, elegimos unos pocos casos de uso, que pensamos que son los que nos ayudaran mejor en el diserio de la arquitectura. Estos casos de uso arquitectonicamente significativos incluyen los que son mas neccsarios para los clientes en la proxima version y quiza para versiones futuras.

Sin embargo, la arquitectura no s610 sc ve condicionada par los cases de usa arquitectonicamente significativos, sino tarnbien por los siguientes factores:

• Sobre que productos software del sistema queremos desarrollar, como sistemas operatives o sistemas de gestion de bases de datos concretos.

• Que productos de middleware (capa de intermedin: Apendice C) queremos utilizar.

Por ejemplo, tcncrnos que seleccionar un object request broker (ORB), que es un mecanismo para la conversion y envio de mensajes a objetos en entornos heterogeneos [6], 0 un marco de trabajo indcpendiente de la plataforma, es decir, un subsistcrna "prefabricado", para construir interfaces graficas.

• Que sistemas hercdados queremos utilizar en nuestro sistema. La utilizacion en nuestra arquitectura de un sistema heredado, como por ejemplo un sistema bancario existente, nos permite reutilizar gran parte de la funcionalidad existcntc, pero tambien tenemos que ajustar nuestra arquitectura para que encaje con el producto "antiguo".

• A que estandares y politicas corporati vas debernos adaptarnos. Por ejernplo, podemos elegir cl Lenguaje de Definicion de Interfaces tInterface Definition Language, IDL) [7] para especificar todas las interfaces de las clases, 0 el estandar TMN de tclecomunicaciones [8] para especificar objetos en nuestro sistema.

• Requisitos no funcionales generales (no especfficos de los cases de uso), como los requisites de disponibilidad, tiernpo de recuperacion, 0 usa de memoria.

• Las necesidades de distribucion especifican como distribuir el sistema. quiza a traves de una arquitectura cliente/scrvidor,

Podemos pensar en los elementos de la parte derecha de la Figura 4.1 como en restricciones y posibilidadcs que nos llevan a torjar la arquitectura de una forma determinada.

La arquitectura se desarrolla en iteraciones de la fase de elaboracion. La siguiente podria ser una aproximacion simplificada, de algun modo ingcnua. Cornenzamos deterrninando un discfio de alto nivcl para la arquitectura, a modo de una arquitectura en capas (Apendice C). Despues formamos la arquitectura en un par de construcciones (Apendice C; vease tarnbien el Capitulo 10) dentro de la primera iteracion,

En la primera construccion, trabajarnos con las partes generales de la aplicacion (Apendice C), que son generales en cuanto al dominio, y que no son especfficas del sistema que pens amos desarrollar (es decir, seleccionamos el software del sistema (capa de software del sistema; Apendice C; vease tambien la Seccion 9.5.1.2.2), el middleware, los sistemas heredados, los estandares y las polfticas de uso). Decidirnos que nodos contendra nuestro rnodelo de desarrollo y como deben interactuar entre ellos. Tarnbien decidimos como rnanejar los requisitos generales no Iuncionales, aSI como la disponibilidad de estos requisitos. Can la primera pasada es suficiente para tener una vision general del funcionamiento de la aplicacion,


r


entrada del cliente JI----3>-

. ) casos de usc

entrada del usuario

arq uitectu ra

Figura 4.2. Los caxos de usn pueden ser dcsarrollados de acuerdo a las entradas de los clicntes y de los uxuariox. No obstante. iambien se ven influcnciados pm la arquitcctura seleccionada.

En la segunda construcci6n. trabajamos con los aspectos de la arquitectura espccificos de la aplicacion (eapa espccifica de la aplicacion; Apcndice C). Escogemos un conjunto de casos de uso relevantes en cuanto a la arquitcctura, capturamos los requisitos. los analizamos, los disefiamos. los implementamos y los probamos. El resultado seran nuevos subsistemas implementados como componentes del desarrollo que soportan los casas de uso seleccionados. Pueden existir tam bien algunos cambios en los componentes significativos de la arquitcctura que implementamos en la primera entrega (cuando no pensamos en terminos de casus de uso). Los componentes nuevos 0 cambiados sc desarrollan para realizar los casos de uso, y de esta forma la arquitectura se adapta para ajustarse mejor a los casus de lISO. Entonces elaboraremos otra construccion, y asf sucesivamcnte hasta terminar con las iteraciones. Si este final de las iteraciones tiene lugar en cl final de lu fase de claboracion, hahremos conseguido una arquitcctura estahle.

Cuando tenemos una arquitectura cstable, podemos implementar la funcionalidad completamente realizando el resto de casus de uso durante Ia rase de construccion, Los cases de usa implcmcntados durante la fase de conxtruccion se dcsarrollan utilizando como entradas los requisitos de los clientes y de los usuaries (\,(5ase la Figura 4.2), pero los casos de uso estrin tarnbien inlluenciados por la arquitectura elegida en la rase de elaboraci6n.

Scgun vayamos capturando nuevos casus de uso, vamos utilizando el conocimiento que ya tenernos de la arquitectura existente para hacer mejor nuestro trabajo. Cuando calcularnos el valor y el coste de los casos de uso que se sugieren, 10 hacernos a la luz de la arquitcctura que tcnernos, Algunos casos de uso seran mas faciles de implernentar, mientras que otros seran mas diffcilcs.

Ejemplo

Adaptacion de los casas de uso a la arquitectura ya existente

EI cliente ha requerido una funcion que supervise el proeeso de earga. Esto se especifico eomo un easo de usa que midiera la earga, eon un nivel de prioridad alto en el computador. La implernentacion de ese easo de uso podrfa haber requerido algunos cambios en sistema operative en tiempo real que se estaba utilizando. Entonees, el equipo de desarrollo suqirio que la funeionalidad requerida fuera implementada en un dispositivo externo separado que hieiera Ilamadas al sistema y midiera el tiempo de respuesta. EI cliente obtuvo mayor fiabilidad en las medidas y el equipo de desarrollo evito tener que cambiar partes crftieas de la arquitectura subyacente.

Negociamos con el clicnte y decidimos si los casos de uso podrfan carnbiarse para hacer la implementacion mas sencilla, ajustando los cases de uso y el disefio resultante con la arqui-

,0" ( casos de uso ) 0""'''' arquitectura


Figura 4.3. Los caxos de uso conducen cl desarrollo de la arquitectura, y la arquitectura indica que caxos de uso pueden rcalizarse.

tectura que ya tenemos. Estc ajustc significa que dcbernos considerar que ya tenernos los subsistemas, interfaces, casos de uso, realizaciones de cases de uso, c1ases y demas. Ajustando los casus de usu con la arquitectura, podemos crear nuevos casos de uso, subsistemas y clases con poco esfucrzo, partiendo de las que ya existen.

Asi, por una parte, la arquitectura esta influenciada pOl' aqucllos cases de uso que quercmos que el sistema soporte. Los casus de uso conduccn la arquitectura, POI' otra parte, utilizamos nuestro conocimiento de la arquitectura para hacer mejor el trabajo de captura de requisites, para obtener casos de uso, La arquitectura gufu los casos de uso tvease la Figura 4.3).

L,Que cs primero, la arquitectura 0 los casos de uso? Tencrnos otra vez el tipico problema del "huevo y la gallina". La mejor forma de resolver estos problemas es mediante una iteracion. Prirnero, construimos una arquitectura tentativa basica a partir de una buena comprensi6n del area del dominio (Apendice C), pero sin considerar los casos de uso detallados. Entonces, escogemos un par de casos de uso y arnpliamos la arquitcctura adaptandola para que soporte csos cases de uso. Despues, escogemos algunos cases de usa mas y construirnos una arquitectura todavia mejor, y aSI sucesivamente, Con cada iteracion, escogernos e implernentamos un conjunto de casos de uso para validar, y si es nccesario, mejorar la arquitectura, Con cada iteracion tambien irnplernentamos adcmas las partes de la arquitectura especificas de la aplicacion basadas en los casas de uso que hemos seleccionado. Los casos de uso entonces nos ayudan a mejorar gradual mente la arquitcctura segun vamos iterando para completar el sistema. Este es uno de los beneficios de los desarrollos conducidos por casos de uso. Volveremos sobre este enfoque en el Capitulo 5.

Resumicndo. una buena arquitectura cs alga que nos perrnite ohtener los cases de uso corrcctos, de manera econornica. hoy y en el futuro.

4.4.

Los pasos hacia una arquitectura

La arquitectura se desarrolla mediante iteraciones, principalmente durante la fase de elaboracion. Cada iteracion se dcsarrolla como se esbozo en el Capitulo 3, cornenzando con los requisitos y siguiendo con el analisis, disefio, implementacion y pruebas, peru ccntrandonos en los casos de uso relevantes desde el punto de vista de la arquitectura y en otros requisites. EI resultado aI final de la fase de elaboracion es una linea base de la arquitectura -un esqueleto del sistema con pocos "musculos" de software.

j,Que casos de uso son relevantes arquitectonicamente hablando? Plantearemos esta cuestion en la Seccion 12.6. Por ahora, es suficiente con decir que los casas de usa arquitectonicarnente relevantes son aquellos que nos ayudan a mitigar los riesgos mas importantes, aquellos que


son los mas importantcs para los usuarios del sistema. y aqucllos que nos ayudan a cubrir todas las funcionalidades significativas, de forma quc nada quede en penumbra. La implementacion, integracion y prucba de la lfnea base de la arquitectura proporeiona scguridad al arquitccto y a otros trabajadores de su cquipo, por ]0 que comprender estos puntos es algo francamente opcrativo. Esto es algo que no puedc obtenerse mediante un analisis y diseno "sobre cl papel". La linea base de la arquitectura de operacion proporciona una demostraci6n que Iunciona para que los trabajadores puedan proporcionar sus rctroalimentaciones.

4.4.1.

La linea base de la arquitectura es un sistema "pequerio y flaco"

Al final de la rase de claboraci6n hemos desarrollado modelos del sistema que representan los casos de uso mas importantcs y sus realizacioues, desde la perspectiva de la arquitectura. Tarnbien hcmos decidido, como ya sc discuti6 en la Scccion 4.3, "Casos de uso y arquitcctura", con que estandares contarnos, que software del sistema y que middleware utilizar, que sistemas heredados reutilizar y que nccesidades de distribucion tenemos. Asi, tendrernos una primera version de los modelos de casos de uso, de anal isis, de disefio y demas, Esta agregacion de modelos (vhlse la Figura 4.4) es la lfnea base de la arquitectura; es un sistema pequefio y naco 2. Tiene las versiones de todos los model os que un sistema terminado contiene al final de la rase de construccion. Incluye el misrno esqueleto de subsisternas, componentes y nodos que un sistema definitive, pero no existe toda la rnusculatura. No obstante, conticne comportamiento y codigo ejecutable. El sistema tlaco sc desarrollara para convertirse en un sistema heche y derecho, quizas con algunos carnbios sin importancia en su estructura y comportamiento. Los cambios son menores porquc al final de la fase de claboracion hemos definido una arquitectura estable: si no, la fase de elaboracion debe continual' hasta que alcance su objetivo.

En la Figura 4.4, la parte sornbreada de cada modele representa la version del mismo que esta desarrollada al final de la fase de claboracion. es decir, la version del modelo que es parte de la linea base de la arquitcctura, EI rectangulo completo (Ia parte sombreada y sin sornbrear) representa la version del modele como desarrollo a] final de la fase de transicion, por tanto, la linea base representa la version del cliente (el lector no deberia sacar ninguna conclusion del tarnafio de las areas sombreadas que se muestran en la Figura 4.4, que s610 tienen finalidad ilustrativa), Desde la lfnea base de la arquitectura hasta la version de la linea base del cliente, habra algunas otras que representen las versiones internas de los modelos (Apcndice C). Podrtamos habcr mostraclo esas nuevas versiones del modelo como incrementos partiendo de Ia linea base de la arquitectura. Cada nueva version de un modcIo puede desarrollarse a partir de la anterior version. Los diferentes model os de la Figura 4.4, como es natural, no se desarrollan independientemente los unos de los otros. Cada caso de uso del modele de casos de uso corresponde, por cjernplo, a una realizacion de caso de uso en los modelos de analisis y disefio, y a una prueba en el modclo de pruebas. Los procesos y la estructura de los nodos deben ajustarse a la ejecucion requerida por los casos de uso (en caso contrario, el modelo de casos de

, Esto no ex del todo correcto, Al final de la fase de elaboracion, tenemos una version del modele de casos de uso que contiene los casos de usn arquitcctonicameme significativos y los cusos de uso (rnris del gO pm ciento) que necesitamos tener especificados para hacer un anali,is del negocio. Axf, la linea base de la arquitectura tiene mas dcl modelo de casos de usn y del modclo de an.ilisi« que 10 que la Figura 4A indica. 1\:0 obstante. para nuestro proposito en este rnomento. podcmos hacer esta si mpl i ficacion.


E:J E:J E:J

Modelo de Casos

Modelo

Modelo

Modelo Modelo Modelo

de Distribuci6n de Implementaci6n de Prueba

de Uso

de Amilisis

de Diseiio

Figura 4.4. La lfnea base de la arquitectura es una version interna del sistema, que est a centrad a en la descripcion de la arquitectura.

uso 0 el modelo de despliegue deben modificarse, quizas cambiando la forma en que las clases activas se asignan a los nodos para una mcjor ejecucion. Tales cambios en el desarrollo o en el modelo de disefio pueden conducir a alteraciones en el modelo de casos de uso, si es que los cambios 10 requieren). Los elementos del modelo, en los diferentes modelos, estan, como se dijo en la Seccion 2.3.7, relacionados entre sf a traves de las dependencias de traza.

No obstante, la linea base de la arquitectura, esto es, la version interna del sistema al final de la fase de elaboracion, se representa por algo mas que los artefactos del modelo. Tambien se incluye la dcscripcion de la arquitectura. Esta descripcion se desarrolla habitualmente de forma concurrente, a menudo incluso antes que las actividades que obtienen las versiones del mode- 10 que son parte de la linea base de la arquitectura. El papel de la descripcion de la arquitectura es guiar al equipo de desarrollo a traves del ciclo de vida del ~istema -no solo por las iteraciones del ciclo actual, sino por todos los ciclos que vengan-. Este es el estandar a seguir por todos los desarrolladores, ahora y en el futuro. Como la arquitectura deberfa ser estable, el estandar deberia ser estahle tambien.

La descripcion de la arquitectura pucde adoptar diferentes formas. Puede ser un extracto (de las versioncs) de los modelos que son parte de la lfnea hase de la arquitectura, 0 puede ser una reescritura de los extractos de forma que sea mas facil leerlos. Volveremos a esto en la Seccion 4.4.3, "Descripcion de la arquitectura", En cualquicr caso, incluye extractos 0 vistas de los modelos que son parte de la lfnea base de la arquitectura. A medida que se dcsarrolla el sistema y los modelos se van haciendo mas voluminosos en las iiltimas fases, la arquitectura seguira incluyendo vistas de las nuevas versiones de los model os. Asumiendo que la Iinea base de la arquitectura ha desarrollado una arquitectura estable -esto es, los elementos del modclo relevantcs arquitectonicamente no cambian en las sucesivas iteraciones-, la descripcion de la arquitectura tambien sera estable, e incluira en todo momenta vistas de los modclos del sistema.

Es fascinante observar que resulta posible desarrollar una arquitectura estable durante la fase de elaboracion del primer ciclo de vida, cuando solamente se ha invertido aproximadamente un 30 por ciento de la primcra version. Esta arquitectura constituira los pilares del sistema el resto de su vida. Aunque los cambios en los pilares resultaran costosos, y en algunos casos muy diffciles, es importante obtener una arquitectura estable pronto en el desarrollo del trabajo. El desarrollo de una arquitectura para un sistema en particular es, por una parte, la creacion de algo nuevo. Por otro lado, la gente lleva desarrollando arquitecturas muchos afios, Se tiene experiencia y conocimiento en el desarrollo de buenas arquitecturas. Hay muchas "soluciones'' gencricas -estructuras, colaboraciones y arquitecturas ffsicas- que han evolucionado a 10

UN PROCESO CENTRADO EN LA ARQUrTECTURA 67

largo de rnuchos anos y con las que todo arquitecto con experiencia deberfa estar familiarizado. Estas soluciones se llarnan habitualmente patrones, como los patrones de arquiteetura descritos en r41 y los patrones de diseno descritos en [51. Los patrones genericos son recursos con los que los arquitectos pueden contar.

4.4.2.

Utilizaci6n de patrones de la arquitectura

Las ideas del arquitecto Christopher Alexander sobre como los "lenguajes de patroncs" se utilizan para sistematizar principios y practicas irnportantcs en el disefio de edifieios y comunidades, han inspirado a muchos miembros de la comunidad de la orientacion a objetos a definir, coleccionar y probar una gran variedad de patrones software [101. La "comunidad de patrones" define un patron como "una solucion a un problema de disefio que aparece con frecuencia". Muchos de los patrones de discfio estan documentados en Iibros, que presentan los patrones utilizando plantillas estandar. Estas plantillas asignan un nombre a un patron y presentan un resumen de los problemas y las fuerzas que 10 hacen surgir, una soluci6n en terminos de colaboracion de clases participantes e interaccion entre objetos de esas clases. Las plantillas tambien proporcionan ejernplos de como se utiliza el patron en algunos Icnguajes de progrumacion, junto can variantes del patron, un resumen con las ventajas y las consecuencias de la uti lizacion de patrones, y referencias a estos, Segun Alexander, seria bueno que los ingcnieros de software aprendiesen los nombres y el objetivo de muchos patrones estandur, y que los aplicasen para hacer disciios mejores y mas cornpresibles. Existen patrones de disefio como Facade, Decorator, Proxy Observer, Strategy y Visitor ampliamente citados y utilizados.

La comunidad de patrones tarnbicn ha aplicado esta idea, con una plantilla de documento ligeramente modificada, para recoger soluciones estandar a problemas de la arquitectura que ocurrcn frecuenternente. Algunos de estos patrones incluyen Layers, Pipes and Filters, Broker Blackboard, Horizontal-Vertical Metadata y MVC. Otros han desarrollado patrones para que se utilicen durante el analisis (",patrones de analisis"), durante la implementacion ("idiomas" que hacen corrcsponder estructuras cornunes de oricntacion a objetos con aspectos peculiares de los lenguajes, como C ++ a Smalltalk), e incluso para estructuras de organizacion efectivas ("patrones de orgunizacion"). Tfpicamente los patrones de discfio se implernentan de una forma I11UY directa en lenguajes orientados a objctos. Algunos ejemplos pueden ser C++, Java y Smalltalk, mientrus que los patrones de arquitcctura se manejan mejor con sistemas 0 subsisternas c interfaces, y los ejemplos no incluyen habitual mente codigo. Para ver un buen esquema de clasificacion vease [9 [.

Desde nuestra perspectiva dirigida par modelos, definirernos patron como una plantil la de colaboracion, que es una colaboracion general que puede especializarse segun 10 definido en la plantilla (Apendicc A). Por tanto, consideramos los patrones de disefio como colaboraciones entre clases e instancias, con su comportamicnto explicado en los diagramas de colaboracion, Utilizarcmos plantillas de colaboracion ya que entendemos que las soluciones son bastante generales. Utilizaremos herencia. extension y otros mecanismos para cspecializar el patron (especificando los nombrcs de clases, mimero de clases, etc., que aparecen en la plantilla). En rnuchos casos, cuando especializamos las plantillas de colaboracion, surgen colaboraciones concretas que pueden trazarse dircctamente con los casus de uso. Vease [5] para un tratamiento extenso de los patrones de disefio.

Los patrones de las arquitecturas se utilizan de una forma parecida pero se centran en estructuras e interacciones de grano mas grueso, entre subsistemas e incluso entre sistemas.


Existen much os patrones de arquitectura, pero aquf solo trataremos brevemente algunos de los mas interesantes.

EI patron Broker r41 es un meeanismo generico para la gestion de objetos distribuidos.

Perrnite que los objetos hagan Ilamadas a otros objetos remotos a traves de un gestor que redirigc la llamada al nodo y al proccso que guardan al objeto deseado. Esta redireccion se haec de manera transparente, 10 cual quiere dccir que el llarnante no necesita saber si el objeto lIamado es remoto. EI patron Broker suele utilizar el patron de disefio Proxy, que proporciona un objeto sustituto local can la misma interfaz que el objeto remota para hacer transparentes el estilo y los detalles de la comunicacion distribuida.

Hay otros patrones que nos ayudan a comprender el hardware de los sistemas que construimos y que nos ayudan a disefiar nuestro sistema sobre el. como por ejemplo Client/Server, Three-Tier, y Peer-to-Peer. Estos patrones definen una estructura para el modelo de despliegue y sugieren como se deben asignar los componentes a los nodos. En la Seccion 4.5, ilustrarcrnos como xe pudo aplicar el patron Client/Server al sistema CA dcscrito en el Capitulo 3. En nuestro ejernplo, la distribucion cliente/servidor tiene un nodo clicnte que ejecuta el codigo de interfaces de usuario y parte de la logica de negocio (clases de control) en cada CA "ffsico", EI nodo servidor mantiene las cuentas y las reglas de negocio que perrniten vcrificar las transacciones.

EI patron Layers es aplicable a muchos tipos de sistemas. Este patron define como organizar el modelo de disefio en capas, 10 cual quierc decir que los cornponcntes de una capa s610 pueden haeer refcrencia a cornponentes en capas inmediatamente inferiores. Este patron es importante porque sirnplifica la cornprension y la organizaci6n del desarrollo de sistemas complejo», reduciendo las dependcncias de forma que las capas mas bajas no son conscientes de ningun detalle 0 interfaz de las superiores. Adernas, nos ayuda a identificar que puede reutil izarsc, y proporciona una estructura que nos ayuda a tomar decisiones sobre que partes comprar y que partes construir.

Un sistema con una arquitectura en capas pone a los subsisternas de aplicacion individuales en 10 mas alto. Estos se construyen a partir de subsistemas en las capas mas bajas, como son los marcos de trabajo y las bibliotccas de clases. Observernos la Figura 4.5. La capa general de aplicacion contiene los subsistcrnas que no son especificos de una sola aplicacion, sino que pueden

LJ, } Capa especilica de la aplicaci6n

~"~~ PLl

L___J- L__j LJ Capa general de la aptlcaclon

~ "..; ~

t]'tJ/'

~ .. "' .. .' : /

rj7"'Cj

Capa de middleware

Capa de software del sistema

Figura 4.5. La arquitectura en capas organiza los sistemas en capas de subsistemas.

UN PROCESO CENTRADO EN LA ARQUlTECTURA 69

ser reutilizados pur muchas aplicaciones diferentes dentro del mismo dominio 0 negocio, La arquitectura de las dos capas inferiores puede establecerse sin considerar los casos de uso debido a que no son dependientes del ncgocio. La arquitectura de las dos capas superiores se crea a partir de los casos sc usa significativos para la arquitectura (estas capas son dependientes del negocio).

Una capa (Apendicc C) es un conjunto de subsistemas que comparten el mismo grado de generalidad y de volaiilidad en las interfaces: las capas inferiores son de aplicacion general a varias aplicaciones y debeu poseer interfaces mas estables, mientras que las capas mas altas son mas dependientes de la aplicacion y pueden tener interfaces menos estables. Debido a que las capas inferiores cambian can menor frecuencia, los desarrolJadores que trabajan en las capas supcriores pueden construir sobre capas inferiores estables. Subsisternas en diferentes capas puedcn reutilizar casos de uso, otros subsistemas de mas bajo nivel, clases, interfaces, coIaboraciones, y componentes de las capas inferiores. Podemos aplicar sobre un mismo sistema muchos patrones de arquitectura, Los patrones que estructuran el modelo de despliegue (es decir, Client/Server, Three-Tier, 0 Peer-to-Peer) pueden combinarse con el patron Layers, 10 cual nos ayuda a estructurar el modelo de disefio, Los patrones que tratan estructuras en diferentes modelos son a menudo independientes unos de otros. Inc1uso los patrones que tratan el mismo modele suelen poder combinarse bien mutuamente. POI ejernplo, el patron Broker se combina correctamente con el patron Layers, y ambos se utilizan en el modelo de disefio. EI patron Broker se encarga de como tratar con la distribucion transparente de objetos, mientras que cl patron Layers nos indica como organizar el disefio entero. De hecho, el Patron Broker puede interpretarse como un subsistcma en la capa intermedia'.

Observcsc que a veces un patron es prcdorninante. Por ejernplo, en un sistema en capas, el patron Layers define la arquitectura general y la descornposicion del trabajo (cada capa asignada a un grupo diferentc), rnientras que se pueden utilizar Pipes y Filters dentro de una 0 mas capas. En contraste, en un sistema basado en Pipes y Filters, mostrariamos la arquitectura general como un flujo entre filtros. mientras que la division en capas podrfa utilizarse de forma explicita para algunos filtros.

4.4.3.

Descrlpclon de la arquitectura

La lfnea base de la arquitectura desarrollada en la fase de elaboracion sobrevive, como dijimos en la Seccion 4.4.1, en forma de una descripcion de la arquitectura. Esta descripcion se obtiene de versiones de los diferentes modelos que son resultado de la rase de elaboracion, como se mucstra en la Figura 4.6. La descripcion de la arquitectura es un extracto 0, en nuestros terrninos, un conjunto de vistas ---quiza con una recscritura cuidada para hacerlas mas legibles- de los model os que estan en la linea base de la arquitectura. Estas vistas incluyen los elementos arquitectonicamente significativos, Por supuesto, muchos de los elementos del modclo que son parte de la linea base de la arquiteetura aparcceran tambien en la descripcion de la arquitcctura. Sin embargo, no 10 haran todos ellos, debido a que para obtener una linea base operativa puede ser necesario el desarrollo de algunos elementos del modelo que no son arquitectonicarnente interesantes, pero que se necesitan para generar cadi go ejecutable. Debido a que la lfnea base de la arquitectura no solo sc usa para desarrollar una arquitectura, sino tambien para especificar los requisites del sistema en un nivel que perrnita el desarrollo de un plan detail ado, el modelo de casos de uso de esta linea base puede contener tarnbien mas casos de uso aparte de los interesantes desdc el punto de vista de la arquitectura.

1 N. del 1: Tambicn sc suele utilizar el tennino "capa middlcware",


La descripcion de la arquitectura debe mantencrse actualizada a 10 largo de la vida del sistema para reflejar los cambios y las adiciones que son relevantes para la arquitectura. Estas cambios son normal mente secundarios y pueden incluir:

• La identificacion de nuevas clases abstractas e interlaces.

• La adicion de nueva funcionalidad a los subsisternas existentes.

• La actualizacion a nuevas versiones de los componentes reutilizables.

• La reordenacion de la estructura de procesos.

Puede que tengarnos que modificar Ia propia descripcion de Ia arquitcctura, pero su tarnafio no debe creccr, S610 se actualiza para ser relevante (pease la Figura 4.6).

Como dijimos anteriorrnente, Ia descripcion de la arquitectura prcsenta vistas de los modelos. Esto incluyc cases de uso, subsistemas, interfaces, algunas clases y componcntes, nodos y colaboraeiones. La descripci6n de la arquitcctura tambicn incluye requisites significativos para la arquitcctura que no estan descritos pOl' media de los casos de uso, Estos otros requisites son no funcionalcs y sc especifican como requisites adicionales, como aquellos relativos a la seguridad, e importantes rcstricciones acerca de Ia distribucion y Ia concurrcncia (Apendice C: vease tambien la Scccion 9.3.2). La dcscripcion de la arquitectura debcria incluir tambien una breve descripcion de la plataforma, los sistemas heredados, y el software comercial que se utilizara, como pOI' cjemplo la invocacion de rnetodos remotos de Java tRemote Method Invocation, RMI) para la distribucion de objetos. Es mas, cs importante describir los marcos de trabajo que implerncntan mccanismos (Apendice C vease tarnbien 9.5.1.4) genericos, como el almacenarnicnto y recupcracion de un objeto en una base de datos relacional. Estos rnecanis-

Linea base de la arquitectura

Modelo luIodelo Modela Modelo Model-o Modell)

de cases de anattsls de dlsenc de desde lrnple- de prueba

de usc pllegue mentacicn

!

Dascripcion de la arquitectura version en la lase de elaboraclon

Modelo luIodelQ Modelo Modelo Modelo

ce casas de anallsls de diserio de desde tmple-

de usa pliegue mentacldn

Ud · .. ,t] .. 1

" " .. ,'" .,',"_ .-_" . ' ..... ',.

Linea base al tina I de fa construccton

Modelo Modelo Modelo Mode-Io Modelo Modelo

de cases de anauale de dlsenc de desde imple- de prueba

de usa pliegue merrtaclon

!

Descripclon de fa arquitectura version en la lase de construcclon

Modelo Modelo Modelo Modela Modelo

de casoe de anatlsts de eleenc de desde imp le-

de usc plleque mentactcn

Figura 4.6. Durante [a construccion, los divcrsos modelos van crcciendo hasta cornpletarse

(scgun sc rnuestra con las Iormas rcllenas en la esquina superior derecha). La descripcion de lu arquitectura, sin embargo, no crcce significativamcnre (abajo a la derecha l debido a que la mayor parte de [a arquitectura se dcfinio durante la fase de elaboracion. Se incorporan pocos carnbios sccundarios a la arquitcctura (indicados por un rellcno puntcado).


mos pueden reutilizarse en varias realizaciones de caso de uso ya que se han disefiado para llevar a cabo colaboraciones reutilizablcs, La descripcion de la arquitectura tarnbien deberia documentar todos los patrones de arquitectura que se han utilizado.

La dcscripcion de la arquitectura subraya los rcmas de diseno mas importantes y los expone para ser considerados y para obtcner Ia opinion de otros, Despues se deben tratar, analizar y resolver estos remas, Extos aruilisis pueden, por ejernplo, incluir una estimacion de la earga del rendimiento,o requisitos de memoria. e imaginar requisites futuros que podrfan romper la arquitectura,

Aunque este detallada en 10 necesario, la descripci6n de la arquitectura es aun una vista de alto nivel. Por un lado, no se pretende que cubra todo: no deberia inundar a los participantes con una cantidad desbordante de detalle. Es un mapa de carrctcras, no una especificacion dctallada del sistema entero. Por otro lado, debe representar 10 que cada participante necesita, por 10 que incluso pucdc que 100 paginas no sean excesivas. La gente utilizara un documcnto grande si contiene 10 que necesitan en una forma que sea rapidamcntc cornprensible. Despues de todo, eso es 10 que se espera de una descripci6n de 1a arquiteetura: deberfa contener 10 que los desarrolladores neccsitan para haeer sus trabajos.

Cuando Ieernos una descripci6n de la arquitcctura, nos puede parecer que trata algunos de los subsistemas de manera superficial, mientras que especifica en detalle las interfaces y colaboraciones de un punado de otros subsistemas, La razon para este tratarniento distinto es que los subsistemas muy especificados son significativos para la arquitectura, y deberfan marnenerse bajo el control del arquitecto tvease las Secciones 12.4.2 y 14.4.3.1).

Puede ser util el tratar que no cs una arquiteetura. La mayorfa de las clases, con operacioncs, interfaces, y atributos que son privadas en los subsistemas 0 en los subsistemas de servicio (ocultas a1 rcsto del sistema), no son significativas para la arquitectura. Los subsistemas que son variantes de otros subsistemas no son importantes desde una perspectiva de la arquitectura, La experiencia indica que menos dell () por ciento de las clases son rclevantes para la arquitectufa. EI 90 por ciento restante no es significative porque no es visible al resto del sistema. Un cambio en una de ellas no afceta a nada esencial fuera del subsistema de servicio. Tampoco son arquitectonicamcntc relevantes 1a mayoria de las realizaciones de cases de uso debido a que no irnponcn ninguna restricci6n adicional a1 sistema. Este es el motivo por el cual los arquitectos pucdcn p1anificar una arquitectura particndo s610 de una fraccion de los cases de uso y de otros requisites. La mayoria de las realizaciones de caso de uso representan simple eomportamiento afiadido Iacil de irnplcmcntar incluso a pesar de que constituyen la mayoria de las funciones que el sistema ofrece. Y esta es la clave: la mayoria de la funcionalidad del sistema es en realidad facil de irnplernentar una vez que hemos estab1eeido 1a arquitectura,

La descripcion de la arquiteetura no ineluye informaci6n que sea s610 necesaria para validar o verificar la arquitectura, Por tanto no tiene casos 0 procedimientos de prueba, y no incluye una vista de 1a arquitectura del mode1o de prueba. Estas cuestiones no son de arquitectura. Sin embargo. como puede verse en 1a Figura 4.6, la linea base de la arquiteetura eontiene una version de todos los rnodclos, incluida una version del modelo de prueba. Por tanto, la lfnea base subyacente a la descripcion de la arquitectura contiene pruebas realizadas -todas las lfncas base las incluyen.

4.4.4.

EI arquitecto crea la arquitectura

E1 arquitecto crea la arquitectura junto con otros desarrolladores. Trabajan para conseguir un sistema que tendra un alto rendimiento y una alta calidad, y sera cornpletamente funcional,


verificable, amigable para el usuario, fiable, de alta disponibilidad, preciso, extensible, tolerante a cambios, robusto, mantenible, portable, confiable, seguro, y econ6mico. Enos saben que han de convivir con esas restricciones y que tendran que tomar soluciones de compromiso entre ell as -este es el motivo por el que hay un arquitecto-. EI arquitecto posee la responsabilidad tecnica mas importante en cstos aspectos y selecciona entre patrones de arquitectura y entre productos para establecer las dependencias entre subsistemas para cada uno de esos distintos intereses. Aquila separaci6n de intereses significa 1a creaci6n de un disefio donde un cambio en un subsistema no retumba en otros varios subsistemas.

EI verdadero objetivo es cumplir con las necesidades de la aplicaci6n de la rnejor forma posible con el estado actual de la tecnologfa y can un coste que la aplicaci6n pueda soportar, en otras palabras, ser capaz de implementar Ia funcionalidad de la aplicaci6n (es decir, los casos de uso) de manera econ6mica, ahora yen el futuro. En este punto el arquitecto tiene el soporte de UML y del Proceso Unificado. UML posee construcciones potentes para la formulaci6n de la arquitectura, y el Proceso Unificado nos ofrece directrices detalladas sobre 10 que constituye una buena arquitectura. Inc1uso aSI, al final, la arquitectura seleccionada es el resultado de un juicio basado en aptitudes y experiencia. EI arquitecto es el responsab1e de emitir este juicio. Cuando el arquitecto presenta la descripci6n de la arquitectura, al termino de la fase de elaboracion, al jefe de proyecto, esta qucriendo decir: "Ahora se que podcmos construir el sistema sin encontrar ninguna sorpresa tecnica importante."

Un arquitecto cualificado se consigue mediante dos tipos de aptitudes. Una es el conocimicnto del dominio en el que trabaja, por 10 que debe trabajar adquiriendo experiencia con todos los usuarios -no s610 con los desarrolladores-. El otro es el conocimiento del desarrollo de software, incluso debe ser capaz de escribir codigo, ya que debe comunicar la arquitectura a los de s arroll adores, coordinar sus esfuerzos, y obtener su retroalirnentacion. Tambien es valioso que el arquitecto tenga experieneia can sistemas simi lares al que se esta desarrollando.

EI arquitecto ocupa un puesto diffcil en la organizaci6n de desarrollo. No deberfa ser jefe de prayecto, ya que ese puesto ticne much as dificultades adernas de la arquitectura. Debe contar can el eompromiso incondicional de la dirceci6n. tanto para crear la arquitectura por primera vez, como para forzar a que se cumpla. Adernas debe ser 10 bastante flexible como para encajar las opiniones utiles de los desarrolladores y otros implicados. Este es un breve resumen de 10 que el arquitecto pone sobre la mesa. Puede que un solo arquitecto no sea suficiente para sistemas grandes. En su lugar, puedc ser una sabia decisi6n el tener un grupo de arquitectura para desarrollarla y mantenerla.

EI desarrollo de la arquitectura consume un tiempo de calendario considerable. Este tiempo esta al principio del calendario de desarrollo y puede incomodar a los directores que estan acostumbrados aver dedicado el tiempo de desarrollo a la implernentacion y pruebas en SI1 mayor parte. Sin embargo, la expcriencia indica que la duraci6n total del desarrollo desciende mareadamente cuando es una buena arquitectura la que guia las ultimas fases. Esto es alga que comentaremos en el Capftulo 5.

4.5.

iPOr fin una descripci6n de la arquitectura!

Hemos estado hablando bastante tiempo sobre 10 que es la arquitectura sin ofrecer un ejemplo significativo, Presentamos ahora un ejernplo concreto de la apariencia de una descripcion de arquitectura. Sin embargo, antes tenemos que explicar par que no es facil hacerlo.


Recuerdese que la descripci6n de la arquitectura es sencillamente un extracto adecuado de Ius rnodelos del sistema (es decir, no afiadc nada nuevo). La prirnera version de la descripcion de la arquitectura es un extracto de la version de los modelos que tenemos al termino de la fase de claboracion en el primer ciclo de vida. Dado que no intentamos hacer una reescritura mas legible de esos extractos, la descripci6n de la arquitectura se parece mucho a los modelos normales del sistema. Esta apariencia significa que la vista de la arquitectura del modelo de casos de uso es muy parecida a un modele de casus de uso normaL La iinica diferencia reside en que la vista de la arquitectura s610 contiene los casos de uso significativos para la arquitectura tvease la Secci6n 12.6.2), mientras que el rnodelo de casos de uso final contiene todos Ius casus de uso. Lo mismo ocurre con la vista de la arquitectura del modelo de disefio. Es igual que un modelo de disefio, pero s610 representa los casos de uso que son interesantes para la arquitectura.

Otra raz6n por la cual es diffcil ofrecer un ejemplo es que s610 es interesante hablar de la arquitectura en sistemas reales, y cuando queremos hablar aquf subre un sistema en detalle, debe ser por necesidad un sistema pequerio. Sin embargo, vamos a emplear el ejemplo del CA del Capitulo 3 para ilustrar 10 que podrian llevar las vistas de la arquitectura. Lo haremos comparando 10 que deberfa estar en las vistas y 10 que deberfa estar en los model os completos del sistema.

La descripcion de la arquitectura tiene cinco secciones, una para cada modelo. Tiene una vista del modelo de casos de usn, una vista del modelo de analisis (que no siempre se mantiene), una vista del modelo de disefio, una vista del modelo de despliegue, y una vista del modelo de implernentacion. No incluye una vista del modelo de prueba porque no desernpefia ningiin papel en la descripcion de la arquitectura, y solo se utiliza para verificar la lfnea base de la arquitectura.

4.5.1.

La vista de la arq u itectu ra del madela de casas de usa

La vista de la arquitectura del modclo de casos de uso presenta los actores y casos de uso mas importantes (0 escenarios de esos casos de uso). Vease la Secci6n 3.3, "La captura de casos de uso", en 10 relativo al modelo de cases de uso del sistema de CA.

Ejemplo

,

La vista de la arquitectura del modelo de cas os de uso del sistema de CA

En el ejemplo del CA, el caso de usa mas importante es Sacar Dinero. Sin 131, no existirfa un verdadero sistema de CA. Los casas de usa Ingresar Dinero y Transferencia entre Cuentas se consideran menos importantes para un cliente de banco normal.

Para definir la arquitectura, el arquitecto sugiere por tanto que el caso de uso Sacar Dinero se implemente en su totalidad durante la fase de elaboracion, pero ningun otro caso de usa (0 parte de caso de uso) se considera interesante para la arquitectura. (En la practica, esta decision podrfa ser un poco precipitada, pero la utilizamos para los propositos de esta explicacion.)

La vista de la arquitectura del modelo de casos de usa deberfa par tanto, mostrar la descripci6n completa del caso de usa Sacar Dinero.


4.5.2.

La vista de la arquitectura del modelo de dlsefio

La vista de la arquitectura del modelo de disefio presenta los clasificadores mas importantes para la arquitectura pertenecicntes al modelo de disefio: los subsistemas e interfaces mas importantes, asf como algunas pocas clases muy importantes, fundamental mente las clases activas. Tambien presenta como se realizan los casos de uso en terrninos de esos clasificadores, par medio de realizaciones de casos de uso. Las clases activas tarnbien las trataremos en la Seccion 4.5.3 cuando hablemos del modelo de despliegue (en el cual las clases activas se asignan a nodos).

Ejemplo

La vista de la arquitectura del modelo de dlserio del sistema deCA

En la Secci6n 3.4.3, identificamos tres clases activas: Gestor de Clientes, Gestor de Transacciones, y Gestor de Cuentas (Figura 4.7). Estas clases activas se incluyen en la vista de la arquitectura del modelo de disefio.

Adernas, en la Secci6n 3.4.4, se describieron los tres subsistemas: Interfaz del CA, Gesti6n de Transacciones, y Gesti6n de Cuentas; vease la Figura 4.8. Estos subsistemas son necesarios para la realizaci6n del caso de uso Sacar Dinero, por 10 cual son subsistemas significativos para la arquitectura. EI modele de disefio incluye muchos otros subsistemas, pero no los consideramos.

EI subsisterna Interfaz del CA se encarga de todas las entradas y salidas del cliente del banco, tales como la impresi6n de los recibos y la recepci6n de los comandos del cliente. EI subsistema de Gesti6n de Cuentas mantiene toda la informaci6n persistente sobre las cuentas, y se utiliza en todas las transacciones relativas a elias. EI subsistema de Gesti6n de Transacciones contiene las clases para el comportamiento espedfico de los casos de uso, como el comportamiento especifico del caso de uso Sacar Dinero. En el ejemplo de la Secci6n 3.4.4, dijimos que las clases especificas de los casos de uso acaban a menudo en distintos subsistemas de servicio, como los subsistemas de servicio para cada una de las clases Retirada de Efectivo, Transferencia e Ingreso

Gestor

de tra nsacclones

Figura 4.7. La cstructura estatica de la vista de la arquitectura del modelo de disefio para el sistema de CA.

Este diagrarna de clases muestra las clases activas,

"subsystem" Q -----I Interfaz A del CA

Entrega

Cliente de banco

Transferir Depositos

Historia

Figura 4.8. La estructura estatica de la vista de la arquitectura del modelo de disefio para el sistema de CA.

Este diagrarna de clases muestra los subsistemas y las interfaces entre cllos.


1: Identificar(cantidad) __..

2: Retirada::realizar_

3: Transferencias::validar _

r ( tid d t )

~ (cantidad, cuenta) ~yrelrar can I a ,cuen a -----,
«subsystem" «subsystem" «subsystem"
Interfaz Gestion de Gestion

delCA tra nsacciones de cuentas
te Clien de banco - 5: dineroO

_ 4: Entrega::autorizarEntrega (cantidad)

Figura 4.9. Los suhsistcma» que colaboran en la ejecucion del casu de US(l Sacar Dinero.

dentro del subsistema de Gesti6n de Transacciones (no se muestran en la Figura 4.8). En realidad, cada uno de esos subsistemas de servicio contiene normal mente varias clases, pero nuestro ejemplo es muy sencillo.

Los subsistemas de la Figura 4.8 proporcionan comportamiento unos a otros mediante interfaces, como la interfaz Transferencias que proporciona la Gesti6n de Transacciones. Las interfaces Transferencias, Retirada, y Entrega se describen en la Secci6n 3.4.4. Tarnbien tenemos interfaces Transferir, Dep6sitos, e Historia, pero no se ven implicadas en el caso de uso que tratamos en este ejemplo, por 10 que no las hemos explicado.

No basta con la estructura estatica, Tarnbien tenemos que mostrar c6mo se Ilevan a cabo, por parte de los subsistemas del modelo de disefio, los casos de uso significativos para la arquitectura. Por tanto, describiremos una vez mas el caso de uso Sacar Dinero, esta vez en terrninos de subsistemas y actores que interactuan utilizando un diagrama de colaboracion (Apendice A), como se muestra en la Figura 4.9. Los objetos de las clases que poseen los subsistemas interactuan unos con otros para ejecutar una instancia de un caso de uso. Los objetos se envian mensajes; el diagrama muestra estos intercambios. Los mensajes Ilevan nombres que especifican operaciones contenidas en las interfaces de los subsistemas. Esto se indica mediante la notacion :: (por ejemplo, Retirada::realizar(cantidad, cuenta), donde Retirada es una interfaz proporcionada por una clase dentro del subsistema de Gesti6n de Transacciones).

La siguiente lista explica brevemente el flujo de la ejecuci6n del caso de uso. EI texto es casi el mismo que el de la Secci6n 3.4.1 (Ia descripci6n de la ejecuci6n del caso de uso), pero aquf 10 presentamos en terrnlnos de subsistemas en lugar de clases.

Precondici6n: EI cliente del banco tiene una cuenta bancaria valida para el CA.

1. EI actor Cliente de Banco selecciona sacar dinero y se identifica en la Interfaz del CA, quizas a traves de una tarjeta de banda maqnetica, mediante un numero y una contraseria. EI Cliente de Banco tarnbien indica la cantidad a retirar y de que cuenta hacerlo. Suponemos que el subsistema Interfaz de CA es capaz de verificar la identidad.

2. La Interfaz de CA solicita al subsisterna de Gesti6n de Transacciones que retire el dinero.

Este subsistema es responsable de Ilevar a cabo la secuencia entera de retirada a modo de transacci6n at6mica, de manera que el dinero se deduce de la cuenta y tam bien se entrega al Cliente de Banco.

3. Gesti6n de Transacciones solicita al subsistema Gesti6n de Cuentas que retire el dinero. EI subsistema Gesti6n de Cuentas decide si puede retirarse el dinero y, si es aSI, deduce la suma de la cuenta y devuelve una respuesta que indica que es posible ejecutar la retirada.

4. Gesti6n de Transacciones autoriza al Interfaz de CA a entregar el dinero.

5. Interfaz de CA entrega el dinero al Cliente de Banco.

El Proceso Unificado de Desarrollo de Soft Jacobson

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

El Proceso Unificado de Desarrollo de Soft Jacobson

Uploaded by

Copyright:

Available Formats

~L PROCESO UNIFICADO DE DESARROLLO

You might also like

El Proceso Unificado de Desarrollo de Soft Jacobson

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

El Proceso Unificado de Desarrollo de Soft Jacobson

Uploaded by

Copyright:

Available Formats

﻿~L PROCESO UNIFICADO DE DESARROLLO

You might also like

~L PROCESO UNIFICADO DE DESARROLLO