Ei PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE IVAR JACOBSON GRADY BOOCH JAMES RUMBAUGH ; La guia completa del Proceso Unificado escrita por sus creadores Addison Wesley‘The Addison-Wesley Object Technology Series Grady Booch, Ivar Jacobson, and James Rumbaugh, Series Editors Para tener mas informacion consult a sitio web de la serie (hip:/www.awl.comiesengtseries', asi como las paginas de cada libro [hugpwww.awl comieseng1-S-B-NI] (+S -B-N- es el nimero de ISBN del ibro en inglés, ineluyendo los guiones), David Bellin and Susan Suchman Simone, The CRC Cant Book ISBN 0.201-89835-8 Grady Booch, Object Solutions: Manuying the Object-Oriented Project ISUN 0.8053.0594.7 Grady Boosh, Object-Orienred Analysis and Design with Applications, Second Editon ISBN D-KASH-5340.2 Grady Booch, James Rumbaugh, and Ivar facobson, The Unified Modeling Language User Guide ISBN 0.201-57108-4 Don Box, Essential COM ISBN 0-201-63486.5 Daas Bus, Keith Brown, Tim Ewald, and Chri Seis, Aiecrive COM: 50 Wa to nprove Your COM and MTS-hased Applications ISBN 6-201-37968-0 Alistair Cockburn, Surviving Object-Oriemed Panjets A Managers Guide ISBN 0201-49834. Dave Collins, Designing OhjectOriented User Interfaces ISBN 0-8053.5350-X Bruce Powel Douglass, Doing Hand Tine: Designing and Inplemennng Embedded Sostems with UML ISBN 0-201=19837-5 Bruce Powel Douglass, Real-Time Objects for Emheudded Systems ISBN 0:201-325799 ‘Desmond F, D'Souza and Alan Cameron Wills, Objects Components, and Prumeworks vith UML: The Catalvis Approuch ISBN 0-201-31012.0 Matin Fowler, Anaysis Porters: Reusable Object Models ISBN 0-201-89542.0 Manin Fowler with Kendall Scott, UME Dissilled: Applhing the Standard Object Mostetng Langa ISBN 0:201-32563-2 ML: Developing Fsfcient Peter Heinckiens, Building Scaluble Database Applications: Object-Oriented Design, Architectures, and Implementations ISBN 0201-31013. ar Jacobson, Graly Booch, and James Rumbaugh, The Unified Software Development Process ISBN 0201-57169 war Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Software Engineering A.Use Case Driven Approach ISBN 0-201-54435-0 var Jacobson, Marin Ericsson. and Agneta Jacobson, The Object Advantage: Business Process Reeneineering ‘ith Object Technelogy ISBN 0-201-42280-1 Ivar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Proves vind Organ for Business Success TSBN 0-201-92476-5 David Jordan, C-+ Object Databases: Programming with the ODMG Standart ISBN 0-201-83488-0 Philippe Kruchten, The Ravional Unified Process: An Introduction ISBN'0-201-60459.0 WilfLaLonde, Discovering Smart ISBN 0-8053-2720-7 Lockheed Manin Advanced Concepts Center and Rational ‘Aware Corporation, Succeeding with the Booch and OMT Methods: Practical approach ISBN 0-8053.2979.5 ‘Thomas Mowbray and William Rub. faside CORBA: Distaduted Object Standards and Applications ISBN 0:201-89540-4 Ia Pohl, Object-Oriented Programming Using C=, Second Eiition ISBN 0-201-89550-1 Rob Pooley and Perita Stevens, Using UML: Software Engineering with Objects and Components ISBN0-201-36067-5 “Temry Quatrani, Visual Modeling with Rational Rose and UML ISBN 0-201-31016-3 BrontE. Rector and Chris Sell, ATL Jaternals ISBN 0°201-60589-8 Doug Rosenberg with Kendall Scat, Ue Case Driven Object Madeling with UML: A Practical approach ISBN 0:201-43289-7 Walker Rayee, Safieure Project Management: 4 Unified Framesork ISBN 0.201-30958-0 Willian Rub, Thomas Herron, and Paul Klinker, JOP Complete Muldleware interoperability and Distributed Object Standards ISBN 0:201-3792: James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Langguaye Reference Manual ISBN 0-201-30998-% Geri Schneider and Jason P. Winters, Appling Use A Practical Gide ISBN 0-201-3098|-5 ‘Yen-Ping Shan and Ralph H. Earle, Emerprise Computing with Objects: From Client Server Environments to rhe Internet ISBN 0-201-32566-7 David N. Smith, [BM Sola: The Language ISBN 0-8053.0908-X Danie! Tkach, Walter Fang. and Andrew So, Fisuat Modeling Technique: Object Technologs Using Vsual Programming ISBN H-80S3-2574-3 Daniel Trach ard Richard Puttick, Object Techinalogy in Application Development. Second Edition ISBN 0-201-49833-2 os Warmer ang Anacke Kleppe, The Object Consaraint “Language: Precive Modeling with UML ISHN 0-201-3794046EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE Ivar JACOBSON Grady BOOCH James RUMBAUGH RATIONAL SOFTWARE CORPORATION Traduccién: Salvador Sanchez Universidad Pontificia de Salamanca en Madrid Miguel Angel Sicilia Universidad Pontificia de Salamanca en Madrid Carlos Canal Universidad de Mélaga Francisco Javier Duran Universidad de Malaga Coordinacién de la traducci6n y revisién técnica: Luis Joyanes Director del Departamento de Lenguajes y Sistemas Informéticos Universidad Pontificia de Salamanca en Madrid Ernesto Pimentel Director del Departamento de Lenguajes y Sistemas Informiticos Universidad de Mélaga ADDISON WESLEY Madrid + México + Santafé de Bogoti + Buenos Aires * Caracas * Lima * Montevideo + San Juan San José + Santiago + Sto Paulo * White PlainsNE Reeyerlro - td Datos ds aah actin blondie 1. Jacobson. Bane, J Rumbaugh EL PROCLSO UNIFICADO DE DESARROLLO DE SOFTWARE, PEARSON FDLCACION, S\, Male, 2081 ISBN; EL TADO.NB6 Mar floss 3 Forma 198 % 280 Prgms 408 1. Jacobson, G. Booch, J. Rumbaugh PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE No esté permiida ls eeproduecisn tonal © parcial de esta obra fi su tatamiient 0 transimisin por cualquier medio © método sin auorizacidn eserta de la Editorial DERECHOS RESERVADOS (© 2000 respecto a a primera edicién en espaol por PEARSON EDUCACION, 8. A Nuner de Balboa, 120 28006 Madi ISBN: 84-7829-036-2 Depésito legal: M. 20.385-2000 ADDISON WESLEY ¢s un sello editorial de PEARSON EDUCACION, S. A. Traducido de: ‘THE UNIFIED SOFTWARE DEVELOPMENT PROCESS. Copyright © 1999 Addison Wesley Longman Ine ISBN: 0-201-57169-2 Eddicién en export: Editor: Andrés Otero Asistemte editorial: Ana Isabel Garcla Diseito de cubierta: DIGRAR, S. A. ‘Composicién: COPIBOOK. 8. L, Impreso por: Imprenta FARESO. S. A. IMPRESO EN ESPANA - PRINTED IN SPAIN Fite id rps con papel tineContenido Prefacio . Parte I: El Proceso Uni ado de Desarrollo de Software Capitulo 1: El Proceso Unificado: dirigido por casos de uso, 16. Capitulo 2: Las cuatro “P” en el desarrollo de softwar BRE centrado en la arquitectura, iterativo e incremental. El Proceso Unificado en pocas palabras : EI Proceso Unificado esté dirigido por casos de uso El Proceso Unificado esté centrado en la arquitectura El Proceso Unificado es iterativo e incremental La vida del Proceso Unificado .. 15.1. El producto ........... 1.5.2. Fases dentro de un ciclo Un Proceso integrado Proyecto, Producto y Proceso. Las personas son decisivas . 2.1.1, Los procesos de desarrollo afectan a las personas 2.1.2. Los papeles cambiarin ... 3. Convirtiendo “recursos” en “trabajadores Los proyectos construyen el producto El producto es mas que cédigo ....... 2.3.1 {Qué es un sistema software? ..... 2.3.2. Artefactos xv 15vi CONTENIDO 26. Capitulo 3: Un proceso di bf Eee Capitulo 4: Un proceso centrado en la arquitectura . . 41. 4.2. Un sistema posee una coleccién de modelos {Qué es un modelo? a Cada modelo es una vista autocontenida del sistema .- Dentro de un modelo... Relaciones entre modelos . El proceso dirige los proyectos... 0.0. 0ceeeeeeee eee 2.4.1, El proceso: una plantilla .. an 2.4.2. Las actividades relacionadas Conforman flujos de trabajo 2.4.3. Procesos especializados ........ 2.4.4. Méritos del proceso ...... La herramientas son esenciales en el proceso. vee 2.5.1. Las herramientas influyen en el proceso . .. 2.5.2. El proceso dirige las herramientas . .. : 3. El equilibrio entre el proceso y las herramientas 2.5.4. El modelado visual soporta UML : 2.5.5. Las herramientas dan soporte al ciclo de vida completo Referencias... ...scees Ren jo por casos de uso Desarrollo dirigido por casos de uso en pocas palabras . Por qué casos de uso? ....... 3.2.1. Para capturar los requisites que aportan valor atadido 3.2.2. Para dirigir el proceso ......... 3.3.3. Para idear la arquitectura y més, La captura de casos de uso . 3.3.1. El modelo de casos de uso representa los requi 3.3.2. Los actores son el entorno del sistema .. 3.3.3. Los casos de uso especifican el sistema : Analisis, disefio e implementacién para realizar los casos de uso 3.4.1. Creacién del modelo de andlisis a partir de los casos de uso . . 3.4.2. Cada clase debe cumplir todos sus roles de colaboracién Los subsistemas agrupan a las clases disefio sees Prueba de los casos de uso Resumen Referenci: La Arquitectura en pocas palabras : Por qué es necesaria la arquitectura .. <2... : 4.2.1. Comprension del sistema... 0.2... cece eee 4.2.2. Organizacién del desarrollo. 4.2.3. Fomento de la reutilizacién 4.2.4. Evolucién del sistema ........0500+6 ron Casos de uso y arquitectura 0.0 Los pasos hacia una arquitectura Creacién del modelo de disefio a partir del modelo de andlisis .. Creacién del modelo de implementacién a partir del modelo de 19 20 20 21 21 22 22 22 24 25 25 25 26 27 27 28 29 aL 33 35 35 36 37 38 38 39 39 40 41 45 46 49 50 52 53 54 35 56 58 38 59 5045. 4.6, 47. Capitulo 5. Un proceso iterativo e incremental 5. 5.3, 55, 5.6, 5.7. 58 59 CONTENIDO 4.4.1, La linea base de la arquitectura es un sistema “peque’to y flaco” Utilizacién de patrones arquitecténicos ..........5 Descripeién de la arquitectura . 4.4.4, El arquitecto crea la arquitectura Por fin, una descripeién de la arquitectura oeeeeen 4.5.1, La vista de la arquitectura del modelo de casos de uso. 4.5.2. La vista de la arquitectura del modelo de disefio 4.5.3. La vista de la arquitectura del modelo de despliegue 4.54, La vista de la arquitectura del modelo de implementacién . Tres conceptos interesantes ........ 4.6.1, {Qué es una arquitectura? rrerren 4.6.2. {Comose obtiene? .....0 00sec 4.6.3. (Cémo se describe? ..... Referencias ....... Iterative e incremental en breve 5.1.1. Desarrollo en pequeiios pasos... 5.1.2, Loque noes unaiteracién ...... Por qué un desarrollo iterativo ¢ incremental? « ‘Atenuacién de riesgos .... : Obtencién de una arquitectura robusta. Gestién de requisitos cambiantes Permitir cambios técticos Conseguir una integracién continua 5.2.6. Conseguir un aprendizaje temprano : La aproximacién iterativa es dirigida por los riesgos .. . 5.3.1, Las iteraciones alivian los riesgos técnicos . . 5.3.2. Ladireccién es responsable de los riesgos no téenicos 5.3.3, Tratamiento de los tiesgos ....... La iteracién genérica .......... 5.4.1. Lo que es una iteracién nore 5.4.2. Planificacién de las iteraciones 2.22.2... 5.4.3, Secuenciacién de las iteraciones El resultado de una iteraciGn es un ineremento . Las iteraciones sobre el ciclo de vida. . Los modelos evolucionan con las iteraciones. Las iteraciones desafian a la organizacién Referencias Parte Il: Los flujos de trabajo ftundamentales Capitulo 6: Captura de requisitos: de la vision a los requisitos . . 6.1 6.2. 63. 64. Por qué la captura de requisitos es complicada El objeto del flujo de trabajo de los requisitos VisiGn general de la captura de requisitos .. El papel de los requisitos en el ciclo de vida del software - vu 65 67 69 7 nD 73 4 76 71 78 8 8 18 18 81 82 83 84 85 85 87 87 88 88 90 90 91 93 93 94 94 96 96 07 98 100 101 102 105 106 107 107 lLVII CONTENIDO 6.5. La comprensién del contexto det sistema mediante un modelo del dominio . Soret errr ee 112 6.5.1, ,Quées un modelo del dominio? . 2 6.5.2. Desarrollo de un modelo del dominio ua 6.5.3. Uso del modelo del dominio ........ us 6.6. La comprensidn del contexto del sistema mediante un modelo del negocio, 115 6.6.1. Qué es un modelo del negocio? ...-..--eeeeeeeeeeeer eee US 6.6.2. Cémo desarrollar un modelo del negocio 118 6.6.3. Busqueda de casos de uso a partir de un modelo del negocio .. 120 6.7. Requisitos adicionales ... 121 68. Resumen ......c cece 123 6.9. Referencias . . . 123 Capitulo 7: Captura de requisitos como casos de uso ... 125 7.1. Introdueci6n 125 7.2. Ariefactos ve veces 127 7.2.1. Artefacto: modelo de casos de USO sss eve 127 7.2.2. Artefacto: actor... 2... a 128 7.2.3. Caso de uso ....... 129 7.24, Artefacto: descripcién de la arquitectura (vista del modelo de casos de uso) i Artefacto: glosario Artefacto: prototipo de interfaz de usuario 73. Trabajadores : 7.3.1. Trabajador: analista del sistema... 73.2. Trabajador: especificador de casos de us 7.3.3, Disefiador de interfaces de usuario ........ 7.34, Trabajador: arquitecto ... 7.4, Flujo de trabajo els 7A.1. Actividad: encontrar actores y casos de USO... esses Actividad: priorizar casos de uso. Actividad: detallar un caso de uso : Actividad: prototipar la interfaz de usuario Actividad: estructurar el modelo de casos de uso... 7.5. Resumen del Ajo de trabajo de los requisitos 7.6. Referencias . beens Capitulo 8: Analisis ... 165 8.1. Introduecién . . 165 8.2. El andlisis en pocas palabras : 168 8.2.1. Por qué el analisis no es disenio ni implementacion 168 8.2.2. El objeto del andlisis: resumen . 169 8.2.3. Ejemplos coneretos de cudndo hacer anilisis .......... 170 8.3, El papel del andlisis en el ciclo de vida del software... i71 8.4, Artefactos . 172 84.1. Artefucto: modelo de andlisis 172 8.4.2. Artefacto: clase del andli 173. 8.4.3. Artefacto: realizacién de caso de uso-anilisis 177CONTENIDO IX 8.4.4. Artefucto: paquete del andlisis ...... 18] 84.5, Artefacto: descripeidn de la arquitectura (vista del modelo de andlisis) 0.0... rer nrnaes 183 8.5. Trabajadores fee 184 8.5.1. Trabajador: arquitecto : 184 85.2. Trabajador: ingeniero de casos de uso a cee 185 8.5.3. Trabajador: ingeniero de componentes ...........60.0002. 186 8.6. Flujo de trabajo a et eee 187 8.6.1. Actividad: andlisis de la arquitectura - 187 8.6.2. Actividad: analizar un caso de uso ......-- : . 194 8.6.3. Actividad: analizar una clase 197 8.6.4. Actividad: analizar un paquete . : - 201 8.7. Resumen del andlisis. : bebeteeeeeeeeeeeeees 203 R8. Referencias 204 Capitulo9: Disefio............ an 9.1, Introduccién . eeSeTeTTE : = fio en el ciclo de vida del software seveeeeeeee 207 9.2. El papel del dis 93. Artefactos 2... vetetetetetttteteseereses 208 9.3.1. Artefacto: modelo de disefio . . nee coo 208 9.3.2. Artefacto: clase del diseio osc eeeeeeeeeeeeee 209 9.3.3, Artefacto: realizacién de caso de uso-diseito . 210 9.3.4. Artefacto: subsistema del disefio . . . . . . . 213 9.3.5. Artefacto: interfaz : 215 9.3.6. Artefacto: descripcisn de la arquitectura (vista del modelo de diseno) ——— . 216 9.3.7. Artefacto: modelo de despliegue - nee 217 9.38. Artefacto: deseripeidn de la arquitectura (vista del modelo de despliegue) 9.4, Trabajadores 9.4.1. Trabajador: arquitecto 9.4.2, Trabajador: ingeniero de casos de uso. 2A.3. | Trbjador:ingeniero de component 9.5. Flujo de trabajo a 9.5.1, Actividad: disefio de la arquitectura .. 9.5.2. Actividad: disefiar un caso de uso . 9.5.3, Actividad: disefiar una clase... 9.5.4. Actividad: disenar un subsistema . 9.6. Resumen del diseio 9.7. Referencias Capitulo 10: Implementacién .. 255 10.1. Introduceién .... seve 255 10.2. El papel de la implementacién en el ciclo de vida del sofware 256 10.3. Artefactos ....... Deere 257 10.3.1. Artefacto: modelo de implementacién . 237 10.3.2. Artefacto: componente 257X — CONTENIDO 10.3.3. Artefacto: subsistema de Ia implementacin .............. 260 10.3.4. Antefacto: interfaz ......, 262 10.3.5, Artefacto: descripcién de la angst (vista del modelo de implementacién) veces 263 10.3.6. Artefacto: plan de integracién de construcciones .......... 264 10.4. Trabajadores en ee 265 10.4.1. Trabajador: arquitecto . i sevens 265 10.4.2. Trabajador: ingeniero de componentes 266 10.4.3. Trabajador: integrador de sistemas... 266 10.5. Flujo de trabajo. eeeeed 267 10.5.1. Actividad: implementacién de la arquitectura 268 10.5.2. Actividad: integrar el sistema ......... coves 270 10.5.3. Actividad: implementar un subsistema ......... : 272 10.5.4, Actividad: implementar una clase 274 10.5.5. Actividad: realizar prueba unidad . .. pease 276 10.6. Resumen de la implementacién ........... eee 279 10.7, Referencias... fee eee eeteteeeeeetrenees 219 .Capitulo 11: Prueba ......... . L281 I.L. Introduecién . cevteeeeeees 281 11-2. El papel de la prueba en el ciclo de vida del software . 282 1L3. Artefuctos ....... 283 11.3.1. Artefacto: modelo de pruebus ee 283 11.3.2, Artefacto: caso de prueba . . : betteteeeeeeees 283 11.3.3. Artefacto: provedimiento de pruebas... sss 286 I Artefacto: componente de prueba .......... veveee 287 11.3.5, Artefacto: plan de prueba, ceceeeeeees 288 HW Attefacto: defecto ....... . a - 288 11.3.7. Artefacto: evaluacién de prueba ceveeeeeees 288 11.4. Trabajadores . ce veceeeeeeees 288 L141. Trabajador: disefiador de pruebas. . ceceeeeeeeeee 288 11.4.2. Trabajador: ingeniero de componentes . : cee 289 11.4.3, Trabajador: ingeniero de pruebas de integracién - 289 11.4.4, Trabajador: ingenieto de pruebas del sistema. ceceees 289 ILS. Flujo de trabajo weet eeee ee eeteeeeettreeerer eres 290 115.1. Actividad: planificar prueba . 201 11.5.2, Actividad: disefiar prueba ......... eee 292 11.5.3. Actividad: implementar prueba 0... 60.00.00 cee 295 11.5.4, Actividad: realizar pruebas de integracién 296 11.5.5. Actividad: realizar prueba de sistema... .. sevens 297 11.5.6. Actividad: evaluar prueba Perot hee eee 297 11.6, Resumen de la prueba 0.0 ...0..eeeceeee rere eeeeee - 299 11.7, Referencias ......... : cetteteeeeeereeeereree E! Desarrollo iterativo e incremental Capitulo 12: EI flujo de trabajo de iteracién genérico veces 303 12.1. La necesidad de equilibrio - 304