Ingeniería del software - Benet Campderrich.pdf

321

Transcript of Ingeniería del software - Benet Campderrich.pdf

  • Ingenieradel software

  • Ingenieradel software

    Benet Campderrich Falgueras

  • Primera edicin: abril 2003

    Fundaci per a la Universitat Oberta de Catalunya Benet Campderrich Falgueres, del texto Editorial UOC, de esta edicinAragn, 182, 08011 BarcelonaMaterial realizado por Eureca Media, SLImpresin:Diseo: Manel Andreu

    ISBN: 84-8429-793-4, del productoISBN: 84-8318-997-6, del libroDepsito legal:

    Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio,sea ste elctrico, qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escrita de los titulares del copyright.

  • Autor

    Benet Campderrich FalguerasDoctor en Ingeniera Industrial. Especializado en ingeniera del software y bases de datos. Profesor titular de la Universidad Rovira i Virgili.

  • Editorial UOC 7 ndice

    ndice

    Presentacin ................................................................................................... 13

    Captulo I. Introduccin a la ingeniera del software OO ................ 15

    1. Qu es la ingeniera del software ............................................................. 151.1. El software como producto industrial.................................................. 161.2. La ingeniera del software .................................................................... 171.3. Los grandes problemas de la ingeniera del software:

    la calidad y la productividad............................................................... 172. El ciclo de vida del software ..................................................................... 19

    2.1. El ciclo de vida clsico......................................................................... 202.2. Los ciclos de vida iterativos e incrementales ...................................... 23

    3. Desarrollo estructurado y desarrollo orientado a objetos ..................... 283.1. Los mtodos estructurados.................................................................. 283.2. Los mtodos orientados a objetos....................................................... 283.3. Los mtodos formales.......................................................................... 30

    4. Las herramientas CASE ............................................................................. 305. El OMG y el UML ....................................................................................... 32

    5.1. El Object Management Group (OMG) .................................................... 325.2. Unified Modeling Language (UML) ........................................................ 32

    Conclusiones ................................................................................................... 35

    Captulo II. UML (I): el modelo esttico ................................................ 37

    1. Concepto de modelo esttico y diagrama de clases ............................... 372. Clasificadores ............................................................................................. 393. Paquetes...................................................................................................... 404. Clase y conceptos afines ........................................................................... 43

    4.1. Representacin ampliada de las clases ................................................ 43

  • Editorial UOC 8 Ingeniera del software

    4.2. La herencia en el anlisis y el diseo .................................................. 484.3. Variantes en el concepto de clase ....................................................... 514.4. Interfaces ............................................................................................. 54

    5. Representacin de los objetos .................................................................. 566. Relaciones entre clases .............................................................................. 57

    6.1. Asociaciones ........................................................................................ 576.2. Agregaciones y composiciones............................................................ 636.3. Relaciones de dependencia ................................................................. 66

    7. Comentarios y restricciones ..................................................................... 677.1. Comentarios ........................................................................................ 677.2. Restricciones........................................................................................ 67

    Conclusiones ................................................................................................... 69

    Captulo III. UML(II): el modelo dinmico y de implementacin ............................................................................. 71

    1. El diagrama de estados.............................................................................. 711.1. Conceptos bsicos ............................................................................... 721.2. Notaciones bsicas............................................................................... 741.3. Transiciones complejas ....................................................................... 781.4. Estados compuestos............................................................................. 791.5. Notacin ampliada del estado............................................................. 82

    2. El diagrama de casos de uso ..................................................................... 832.1. Actores ................................................................................................. 832.2. Concepto de caso de uso..................................................................... 852.3. Relaciones entre casos de uso.............................................................. 862.4. Notacin.............................................................................................. 87

    3. Los diagramas de interaccin................................................................... 883.1. Interacciones y colaboraciones ........................................................... 883.2. El diagrama de colaboracin ............................................................... 933.3. El diagrama de secuencias ................................................................... 95

    4. El diagrama de actividades....................................................................... 994.1. Elementos especficos .......................................................................... 99

    5. Los diagramas de implementacin ........................................................ 1025.1. El diagrama de componentes ............................................................ 1025.2. El diagrama de despliegue ................................................................. 105

    Conclusiones ................................................................................................. 107

  • Editorial UOC 9 ndice

    Captulo IV. Recogida y documentacin de requisitos ................... 109

    1. Los requisitos ........................................................................................... 1101.1. Clases de requisitos ........................................................................... 110

    2. Fuentes de informacin .......................................................................... 1113. Pasos de la recogida y documentacin de requisitos ........................... 112

    3.1. El contexto del software ..................................................................... 1123.2. Los guiones ........................................................................................ 1143.3. Identificacin de los actores.............................................................. 1143.4. Identificacin de los casos de uso ..................................................... 1153.5. Identificacin de las relaciones entre casos de uso........................... 1163.6. Identificacin de las relaciones de especializacin entre actores ..... 1183.7. La documentacin de los casos de uso ............................................. 118

    4. La recogida y documentacin de requisitos de la interfaz de usuario ... 1204.1. Concepto de interfaz de usuario ....................................................... 1204.2. Identificacin de las restricciones tcnicas ....................................... 1214.3. Elaboracin de los perfiles de usuario............................................... 1214.4. Documentacin de las tareas actuales y futuras ............................... 1224.5. Comparacin entre tareas y casos de uso ......................................... 1234.6. Especificaciones de usabilidad .......................................................... 124

    5. Ejemplo..................................................................................................... 1245.1. Informacin inicial ........................................................................... 1255.2. Modelo del dominio.......................................................................... 1255.3. Modelo del negocio........................................................................... 1265.4. El glosario del modelo del negocio ................................................... 1285.5. Los guiones ........................................................................................ 1295.6. Casos de uso ...................................................................................... 1305.7. Requisitos de la interfaz de usuario................................................... 135

    Conclusiones ................................................................................................. 139

    Captulo V. Anlisis orientado a objetos ............................................. 141

    1. El papel del anlisis................................................................................. 1421.1. La relacin entre la recogida de requisitos y el anlisis .................... 1421.2. La relacin entre el anlisis y el diseo............................................. 1421.3. La utilidad del anlisis....................................................................... 143

    2. Paquetes de anlisis y paquetes de servicios ......................................... 1442.1. Los paquetes de anlisis .................................................................... 145

  • Editorial UOC 10 Ingeniera del software

    2.2. Los paquetes de servicios................................................................... 1453. Revisin de los casos de uso ................................................................... 1464. Especificacin de las clases de anlisis .................................................. 147

    4.1. Identificacin de las clases de entidades........................................... 1484.2. Especificacin de los atributos de las clases de entidades................. 1504.3. Identificacin de las relaciones entre clases...................................... 1514.4. Identificacin de las clases de frontera, las clases de control

    y de las operaciones. Diagrama esttico de anlisis .......................... 1585. Especificacin formal de los casos de uso ............................................. 1586. Anlisis de la interfaz de usuario ........................................................... 1597. Ejemplo..................................................................................................... 160

    7.1. Revisin de los casos de uso.............................................................. 1607.2. Paquetes de anlisis y de servicios .................................................... 1607.3. Identificacin de las clases de entidades........................................... 1617.4. Especificacin de los atributos de las clases de entidades................. 1627.5. Relaciones .......................................................................................... 1637.6. Identificacin de las clases de frontera, las clases de control

    y de las operaciones........................................................................... 1667.7. Especificacin formal de los casos de uso ......................................... 1697.8. Anlisis de la interfaz de usuario....................................................... 171

    Conclusiones ................................................................................................. 175

    Captulo VI. Diseo orientado a objetos.............................................. 177

    1. El papel del diseo .................................................................................. 1781.1. La relacin entre el diseo y la realizacin....................................... 1781.2. La utilidad del diseo ........................................................................ 179

    2. La reutilizacin ........................................................................................ 1792.1. La reutilizacin de clases ................................................................... 1792.2. La reutilizacin de componentes ...................................................... 1802.3. Los patrones ...................................................................................... 1802.4. Marcos de aplicaciones...................................................................... 192

    3. El diseo arquitectnico ......................................................................... 1933.1. Establecimiento de la configuracin de la red .................................. 1943.2. Establecimiento de los subsistemas................................................... 194

    4. El diseo de los casos de uso .................................................................. 195

  • Editorial UOC 11 ndice

    5. Revisin del diagrama esttico de diseo ............................................. 1965.1. Normalizacin de los nombres ......................................................... 1975.2. Reutilizacin de clases ....................................................................... 1985.3. Adaptacin de la herencia en el nivel soportado por el lenguaje

    de programacin ............................................................................... 1985.4. Sustitucin de las interfaces .............................................................. 2015.5. Cambios para la mejora del rendimiento ......................................... 2015.6. Especificacin de las operaciones implcitas..................................... 2025.7. Referencias a las clases de frontera.................................................... 2025.8. La clase inicial ................................................................................... 2035.9. Cohesin y acoplamiento ................................................................. 203

    6. Diseo de la persistencia ........................................................................ 2056.1. Persistencia con bases de datos orientadas a objetos ........................ 2066.2. El modelo para bases de datos relacionales y ficheros clsicos:

    alternativas ........................................................................................ 2066.3. Persistencia con bases de datos object-relational ................................ 215

    7. Diseo de la interfaz grfica de usuario ................................................ 2167.1. Elementos y funcionamiento de la interfaz grfica de usuario ........ 2177.2. El diseo de las interfaces grficas .................................................... 236

    8. Diseo de los subsistemas ....................................................................... 2439. Ejemplo..................................................................................................... 244

    9.1. El diseo arquitectnico ................................................................... 2449.2. El diseo de los casos de uso ............................................................. 2449.3. El diagrama esttico de diseo .......................................................... 2499.4. El diseo de la persistencia ............................................................... 2519.5. El diseo de la interfaz de usuario .................................................... 2549.6. El diseo de los subsistemas.............................................................. 258

    Conclusiones ................................................................................................. 260

    Captulo VII. Introduccin al software distribuido ........................ 261

    1. Entornos distribuidos y entornos abiertos ............................................ 2611.1. Objetivos de los entornos distribuidos ............................................. 2621.2. Importancia de las normas en los entornos distribuidos ................. 2631.3. Concepto de sistema abierto ............................................................. 263

    2. Entornos cliente/servidores clsicos...................................................... 2642.1. Ventajas e inconvenientes de la arquitectura cliente/servidor......... 2652.2. Arquitecturas cliente/servidor de dos capas...................................... 2662.3. Arquitecturas de ms de dos capas.................................................... 267

  • Editorial UOC 12 Ingeniera del software

    3. Entornos con middleware: CORBA ........................................................ 2683.1. Concepto de middleware.................................................................... 2683.2. CORBA............................................................................................... 269

    4. RMI............................................................................................................ 2984.1. Mecanismos de una invocacin remota ........................................... 298

    5. Documentos compuestos distribuidos: DCOM..................................... 2995.1. Concepto de documento compuesto ................................................ 2995.2. Aspectos de la gestin de los documentos compuestos.................... 3005.3. OLE, COM y DCOM.......................................................................... 301

    6. Desarrollo del software distribuido........................................................ 3086.1. El anlisis de requisitos en el caso de software distribuido ............... 3086.2. La distribucin de los objetos ........................................................... 308

    Bibliografa.................................................................................................... 312

    Glosario ......................................................................................................... 314

  • Editorial UOC 13 Presentacin

    Presentacin

    La ingeniera del software comprende los mtodos y las tcnicas que se utili-

    zan en el desarrollo profesional del software. Se trata de un campo muy amplio,

    del cual esta materia slo trata una parte.

    La ingeniera del software consta principalmente de dos familias de tcnicas:

    Las estructuradas, cronolgicamente las ms antiguas.

    Las orientadas a objetos (OO), que constituyen la parte principal de esta obra,

    con las exclusiones mencionadas.

    El resto de la obra es una introduccin a la ingeniera del software.

    La tecnologa de elaboracin de software orientado a objetos ha tenido la ma-

    yor parte de su desarrollo desde 1985 hasta la actualidad. Como suele pasar con

    toda nueva tecnologa, al principio aparecen muchas tcnicas alternativas y el

    paso del tiempo comporta que muchas se abandonen y slo quede una o algunas

    que llegan a ser un estndar, oficial o de hecho. Parece que la tecnologa orien-

    tada a objetos ha alcanzado hace unos pocos aos esta situacin, al menos en lo

    que respecta al modelo bsico, del cual existe el estndar denominado UML, ya

    ampliamente aceptado y utilizado. ste es el modelo que utilizamos.

    Adems del modelo utilizado, otro aspecto fundamental del desarrollo de

    software es el mtodo, ya que, si utilizamos el mismo modelo, podemos imagi-

    nar muchos mtodos diferentes que utilizan las notaciones del modelo en otro

    orden o para otros propsitos distintos. A diferencia del caso del modelo bsico,

    es poco probable que se imponga un mtodo como estndar; como mucho se

    puede establecer como estndar legal la presentacin de una determinada docu-

    mentacin elaborada segn un modelo fijado, pero la manera como se trabaje

    para elaborarla siempre tendr un margen de libertad amplio.

  • Editorial UOC 14 Ingeniera del software

    En esta obra se ha optado por seguir un mtodo inspirado en el denominado

    Rational Unified Process, porque ste es bastante elaborado y coherente y, ade-

    ms, ha sido desarrollado esencialmente por el mismo equipo que desarroll el

    UML, lo cual ofrece una cierta garanta de coherencia entre el mtodo y el mo-

    delo.

    Se puede considerar que esta obra tiene una parte bsica, un ncleo y una

    conclusin:

    La parte bsica comprende unos conocimientos fundamentales, que son el ca-

    ptulo Introduccin a la ingeniera del software OO, dedicado a los conceptos

    generales de la ingeniera del software; el captulo UML (I): el modelo esttico

    y el captulo UML (II): el modelo dinmico y de implementacin.

    El ncleo de la obra est constituido por los captulos Recogida y documen-

    tacin de requisitos, Anlisis orientado a objetos y Diseo orientado a

    objetos.

    La conclusin es el captulo Introduccin al software distribuido, que ofrece

    una visin general de la tecnologa del software distribuido orientado a obje-

    tos. Este tema conduce a introducir no solamente la problemtica y las tcni-

    cas directamente relacionadas con la distribucin del software, sino tambin

    conceptos que tienen un campo de aplicacin ms amplio.

  • Editorial UOC 15 Captulo I. Introduccin a la...

    Captulo I

    Introduccin a la ingeniera del software OO

    En este captulo se empieza a introducir el concepto de ingeniera de software y

    a presentar su problemtica. Se describe con detalle el ciclo de vida clsico o en cas-

    cada, y se presentan los modelos de ciclo de vida alternativos, en especial los cono-

    cidos como modelos iterativos e incrementales, entre los cuales se describe el ciclo

    de vida del Rational Unified Process.

    Se definen tambin las dos grandes lneas tecnolgicas actuales en el desarro-

    llo de software: el desarrollo estructurado y el desarrollo orientado a objetos, y

    se introduce el concepto de herramienta CASE. El captulo termina con la pre-

    sentacin del origen y estatus del modelo estndar UML, el modelo orientado a

    objetos que se utiliza en esta obra, y del OMG, la organizacin responsable del

    mismo.

    1. Qu es la ingeniera del software

    Un sistema de software, denominado tambin aplicacin o simplemente

    software, es un conjunto integrado de programas que en su forma definitiva se

    pueden ejecutar, pero comprende tambin las definiciones de estructuras de da-

    tos (por ejemplo, definiciones de bases de datos) que utilizan estos programas y

    tambin la documentacin referente a todo ello (tanto la documentacin de

    ayuda en el uso del software para sus usuarios como la documentacin generada

    durante su construccin, parte de la cual tambin servir para su mantenimien-

    to posterior).

  • Editorial UOC 16 Ingeniera del software

    1.1. El software como producto industrial

    Un software no es una obra de arte, sino un producto de consumo utilitario

    y masivo; para una empresa o trabajador autnomo, el software es un medio auxi-

    liar que interviene de manera ms o menos indirecta, pero a menudo imprescin-

    dible, en su gestin y cada vez ms en su proceso productivo; tambin existe,

    como todos sabemos, un consumo privado de software. Por tanto, se puede con-

    siderar plenamente como un producto industrial.

    Por ejemplo...

    los bancos, las industrias de fabricacin en serie, las empresas de comercio electr-nico, etc. actualmente no podran funcionar sin software.

    Sin embargo, es un producto industrial con algunas caractersticas especiales.

    En primer lugar, es mucho ms un producto singular que un producto que se fa-

    brique en serie (aunque algunos software tienen muchos miles de usuarios e, inclu-

    so, millones), ya que, si bien existe y no siempre produccin en serie de copias

    del software, sta es una actividad muy poco importante dentro del conjunto de su

    proceso productivo y relativamente sencilla.

    La produccin de software se parece a la construccin!

    Desde cierto punto de vista, la produccin de software se parece a la construccin de vi-viendas o edificios industriales, por ejemplo, en el hecho de que cada producto es dife-rente y su elaboracin se basa en un proyecto especfico (en el caso de produccin enserie, lo que se proyecta es un prototipo del producto, y no cada unidad que se produce).

  • Editorial UOC 17 Captulo I. Introduccin a la...

    Otras caractersticas del software son, como seala Pressman, que no se estro-

    pea por el uso ni por el paso del tiempo. Si finalmente se tiene que sustituir es

    porque se ha quedado tecnolgicamente anticuado o inadaptado a nuevas ne-

    cesidades o porque ha llegado a resultar demasiado caro mantenerlo.

    1.2. La ingeniera del software

    En general, a cada tipo de producto industrial corresponde un tipo de in-

    geniera, entendida como el conjunto de mtodos, tcnicas y herramientas

    que se utilizan tanto para desarrollar el producto (es decir, elaborar el proyec-

    to o prototipo) como para fabricarlo (afinando ms se puede decir que exis-

    ten, pues, dos ingenieras para cada tipo de productos: la del producto y la del

    proceso).

    Una tcnica es la manera preestablecida en la que se lleva a trmino un paso

    en la elaboracin del producto, un mtodo es una manera determinada de apli-

    car varias tcnicas sucesivamente y una herramienta es un instrumento de cual-

    quier tipo que se utiliza en la aplicacin de una tcnica.

    El software no es ninguna excepcin a esta regla, y, por tanto, hay una inge-

    niera del software que comprende las tcnicas, mtodos y herramientas que se

    utilizan para producirlo.

    En el caso de la ingeniera del software no se suele hablar de ingeniera de pro-

    ceso; quiz se podra pensar que es la que hace referencia a la programacin en

    sentido estricto, pero cada vez es menos ntida la distincin entre la programa-

    cin y las fases anteriores en el desarrollo de software.

    1.3. Los grandes problemas de la ingeniera del software:

    la calidad y la productividad

    A pesar de los grandes adelantos que ha habido en las tcnicas de desarrollo

    de software durante los ltimos treinta aos, tanto la calidad del software como

    la productividad de su proceso de elaboracin todava no han alcanzado niveles

  • Editorial UOC 18 Ingeniera del software

    plenamente comparables con los de otras tecnologas ms antiguas. Todo esto,

    combinado con un aumento realmente espectacular de la demanda de software,

    ha provocado lo que se ha denominado la crisis del software.

    En cuanto a la calidad, la causa principal de dificultades es la gran complejidad

    del software comparado con otros tipos de productos, que provoca, por ejemplo,

    que no sea posible, ni mucho menos, probar el funcionamento de un software en

    todas las combinaciones de condiciones que se pueden dar. Y eso ocurre en una

    poca en la que se da cada vez ms importancia a la calidad en todos los mbitos,

    al considerarla un factor de competitividad dentro de unos mercados cada vez

    ms saturados y, por tanto, ms exigentes. No es extrao, pues, que el tema de la

    calidad (y dentro de ste, cuestiones como la garanta de calidad y las certificacio-

    nes oficiales de calidad) adquiera una importancia creciente dentro de la ingenie-

    ra del software.

    Por lo que respecta a la productividad, cabe decir para empezar que cual-

    quier fabricacin en serie tiene necesariamente una productividad mucho ms

    elevada que la fabricacin de un producto singular; pero, incluso, si la compa-

    ramos con otras ingenieras de producto singular, la productividad es clara-

    mente inferior. La complejidad del producto tambin puede ser una causa de

    este hecho, pero ciertamente no es la nica. Un factor que tiene un peso real-

    mente importante en la baja productividad es el hecho de que, a diferencia de

    las otras tecnologas, en un proyecto de software el desarrollo empieza tradicio-

    nalmente de cero (slo recientemente se utilizan fragmentos de software pre-

    fabricados).

    El aprovechamiento de elementos en la fabricacin en serie

    Cuando se disea un nuevo modelo de coche, se incluyen desde el principio much-simos elementos que ya existan y que, por tanto, no es necesario disear; no sloelementos normalizados como tornillos y tuercas, sino tambin elementos ms com-plejos como bateras e, incluso, motores o cajas de cambio completos. Tambin enla construccin de edificios una actividad que tiene ms semejanzas con la produc-cin de software, como se ha indicado se utilizan muchos elementos estndares oprefabricados: tejas, vigas, ventanas, persianas, grifos, etc.

    Por tanto, no es extrao que uno de los grandes retos, por el momento, de

    la ingeniera del software sea conseguir desarrollar fragmentos de software (de-

  • Editorial UOC 19 Captulo I. Introduccin a la...

    nominados componentes) que sean reutilizables, por un lado, y, por el otro, de-

    sarrollar software y reutilizar sus fragmentos (que seguramente estarn mejor

    probados que si se hicieran de nuevo, lo cual adems mejorara la calidad del

    software producido).

    Una de las vas mediante las cuales se pretende conseguir una cierta reuti-

    lizacin en el desarrollo orientado a objetos es especialmente con compo-

    nentes; otras son los patrones de diseo (reutilizacin, si no de fragmentos

    de software, por lo menos de ideas o recetas para hacerlos) y los marcos o

    frameworks, que son estructuras formadas por sistemas de software a los cuales se

    pueden acoplar otros sistemas de software, sustituibles, para hacer funciones

    concretas.

    2. El ciclo de vida del software

    La produccin de software es algo ms que la programacin; hay etapas que

    la preceden y otras que la siguen.

    El ciclo de vida del software est constituido por el conjunto de todas estas

    etapas. Los mtodos y tcnicas de la ingeniera del software se inscriben dentro

    del marco delimitado por el ciclo de vida del software, y, ms concretamente, por

    las diferentes etapas que se distinguen.

    La misma existencia de distintos modelos del ciclo de vida del software hace

    comprender que no hay ninguno que sea ideal o que no tenga grandes limita-

    ciones.

    Sin embargo, es indispensable que todo proyecto se desarrolle dentro del mar-

    co de un ciclo de vida claramente definido, si se quiere tener una mnima garan-

    ta de cumplimiento de los plazos, y respetar los lmites de los recursos asignados.

    Adems, la garanta de calidad y las certificaciones* de calidad tambin presupo-

    nen que el proceso de produccin de software se desarrolle segn un ciclo de vida

    con etapas bien definidas.

    *. Un ejemplo de certificacin de calidad sera la ISO.

  • Editorial UOC 20 Ingeniera del software

    2.1. El ciclo de vida clsico

    La figura siguiente nos muestra las etapas previstas en una cierta versin del

    ciclo de vida clsico.

    A veces, el ciclo de vida clsico tambin se denomina ciclo de vida en cascada,

    lo cual quiere decir que en cada etapa se obtienen unos documentos (en ingls,

    deliverables) que son las bases de partida de la etapa siguiente que, por tanto, no

    puede comenzar antes de que haya terminado la anterior y nunca se regresa a

    etapas pasadas.

    2.1.1. Etapas

    La primera etapa se denomina anlisis previo y tambin anlisis de sistemas

    o ingeniera de sistemas. En esta etapa se definen los grandes rasgos del sistema

    de software que tendr que dar soporte informtico a unas actividades determi-

    nadas de unos ciertos usuarios dentro del marco ms general de la actividad de

    la empresa u organizacin.

  • Editorial UOC 21 Captulo I. Introduccin a la...

    Adems, este sistema tendr que funcionar en un entorno de hardware y red

    determinado, que ser necesario indicar, y quiz tambin tendr que intercam-

    biar informacin con otro software o compartir una base de datos. Estos hechos

    constituyen otros aspectos del entorno del futuro software de los cuales se tendr

    que dejar constancia.

    Hay que tener en cuenta los recursos necesarios para el desarrollo del software

    y los condicionamientos temporales, especialmente los plazos impuestos desde

    fuera del proyecto, que a menudo estn determinados por los hechos que han

    causado las necesidades de informacin que tiene que satisfacer dicho software, y

    tambin restricciones eventuales y condiciones adicionales que sea necesario res-

    petar; y, en funcin de todo esto, se evala la viabilidad tcnica, econmica y le-

    gal del proyecto de desarrollo de dicho software.

    El documento que resulta de esta etapa se denomina Especificacin del siste-

    ma, y sirve de base para tomar la decisin definitiva sobre la continuacin del

    proyecto.

    La segunda etapa es el anlisis de requisitos o simplemente anlisis. Su objeti-

    vo es definir con detalle las necesidades de informacin que tendr que resolver

    el software, sin tener en cuenta, por el momento, los medios tcnicos con los que

    se tendr que llevar a trmino el desarrollo del software.

    Como el lenguaje de programacin, el gestor de bases de datos, los compo-

    nentes que se pueden reutilizar, etc.

    En esta etapa detallamos los requisitos de la etapa anterior; ahora slo pen-

    samos en el software que es necesario desarrollar y sus interfaces con el entorno.

    La figura responsable del anlisis el analista, que puede ser un informtico o

    un usuario debe tener o adquirir conocimientos generales sobre el dominio de

    la aplicacin y obtener informacin de los usuarios y de otras fuentes que le per-

    mita hacerse una idea precisa de las funciones, y de los requisitos en general, del

    futuro software. Con esta informacin se redacta el documento que llamaremos

    Especificacin de requisitos, que tiene una doble funcin: especificar qu debe

    hacer el software, con la suficiente precisin para que se pueda desarrollar, y servir

    de base para un contrato, explcito o no, entre el equipo de desarrollo del software

    y sus futuros usuarios.

    El diseo es la etapa siguiente. Si el anlisis especifica el problema o qu tiene

    que hacer el software, el diseo especifica una solucin a este problema o cmo

    el software tiene que hacer su funcin.

  • Editorial UOC 22 Ingeniera del software

    Del software, hay que disear varios aspectos diferenciados: su arquitectura

    general, las estructuras de datos (base de datos, etc.), la especificacin de cada

    programa y las interfaces con el usuario, y se tiene que llevar a cabo de manera

    que, a partir de todo esto, se pueda codificar el software, de una manera parecida

    a la construccin de un edificio o de una mquina a partir de unos planos.

    El documento resultante es la Especificacin del diseo. La etapa de diseo es

    el mejor momento para elaborar la Especificacin de la prueba, que describe con

    qu datos se tiene que probar cada programa o grupo de programas y cules son

    los resultados esperados en cada caso.

    La programacin o codificacin, que es la cuarta etapa, consiste en traducir

    el diseo a cdigo procesable por el ordenador.

    Es en esta etapa donde se le da forma real al software, es en realidad cuando se

    elabora.

    El entregable que se genera en esta etapa es el programa propiamente, con to-

    das sus funcionalidades y componentes.

    La prueba es la ltima etapa del desarrollo del software y la penltima del mo-

    delo de ciclo de vida del software que hemos considerado.

    La etapa de prueba consiste en probar el software desde distintos puntos de

    vista de una manera planificada y, naturalmente, localizar y corregir dentro del

    software y su documentacin los errores que se detecten.

    La prueba se lleva a trmino en las dos fases siguientes:

    1) En la primera se hacen pruebas, primero para cada uno de los programas

    por separado y, despus, por grupos de programas directamente relacionados, y

    se aplica la especificacin de la prueba que hemos mencionado con anterioridad.

    2) En la segunda fase se comprueba que el conjunto de programas d los re-

    sultados que se esperan y que lo haga con el rendimiento deseado.

    El primer equipo de desarrollo hace la ltima fase de la prueba y, si los resulta-

    dos son satisfactorios, se entrega el software al cliente, el cual puede hacer una prue-

    ba parecida por su cuenta y con sus datos, con la finalidad de decidir si acepta el

    software. Con la aceptacin por parte del cliente se da por terminado el desarrollo.

    La ltima etapa del ciclo de vida es el mantenimiento o, si se prefiere, explo-

    tacin, del software, ya que siempre que se utilice el software habr que mantener-

    lo, es decir, hacer cambios pequeos o grandes para corregir errores, mejorar

  • Editorial UOC 23 Captulo I. Introduccin a la...

    las funciones o la eficiencia, o adaptarlo a un nuevo hardware o a cambios en las

    necesidades de informacin.

    Puesto que un software puede estar en explotacin diez aos o ms, a menu-

    do el coste total del mantenimiento durante la vida del software es de dos a cinco

    veces mayor que el coste de desarrollo.

    2.1.2. El caso de lenguajes de cuarta generacin

    Los lenguajes o ms bien entornos de programacin de cuarta generacin

    son de muy alto nivel (en el sentido de que a menudo una sola de sus instruccio-

    nes equivale a muchas instrucciones del lenguaje ensamblador) y en gran parte

    son no procedimentales y estn integrados en un gestor de bases de datos rela-

    cionales. Incluyen herramientas de dibujo de pantallas, generacin de listados y

    en ocasiones salidas grficas y hoja de clculo. Algunos pueden generar cdigo en

    un lenguaje de tercera generacin.

    Para aplicaciones sencillas, se puede pasar directamente de los requisitos a la

    codificacin, pero en proyectos complejos es necesario llevar a cabo una etapa de

    diseo, aunque simplificada.

    2.2. Los ciclos de vida iterativos e incrementales

    El ciclo de vida en cascada ha sido muy criticado y se han propuesto algunos

    modelos alternativos.

    2.2.1. Inconvenientes del modelo de ciclo de vida en cascada

    El inconveniente del modelo de ciclo de vida en cascada es que no es realista.

    Como se ha visto, el modelo de ciclo de vida en cascada comporta que las

    sucesivas etapas del desarrollo se hacen de manera lineal, de forma que una fase

    no comienza mientras no se haya acabado la anterior, y no se vuelve nunca atrs.

    Tambin queda implcito en el modelo que, cuando se acaba una fase, se sabe

    al menos aproximadamente qu porcentaje del proyecto queda por hacer, ya que

  • Editorial UOC 24 Ingeniera del software

    si el anlisis se ha completado y su resultado es cien por cien fijo, se puede saber

    con cierta precisin la duracin del diseo e, incluso, de la programacin.

    Ahora bien, en la realidad es posible que la especificacin del sistema sea fia-

    ble en lo que respecta a las funciones, ya que no se espera que se describan pun-

    to por punto. Sin embargo, precisamente por esto ltimo, el coste y la duracin

    del proyecto se han calculado sobre una base muy poco slida y tienen un gran

    margen de error.

    No obstante, el problema ms grave se presenta en el anlisis de requisitos,

    por el hecho de que stos casi siempre son incompletos al principio o cambian

    antes de que se haya acabado de construir el software, y a menudo suceden ambas

    cosas a la vez. Y si la especificacin de requisitos es incompleta e insegura, es

    obvio que el diseo y la programacin tendrn problemas y, sobre todo, retra-

    sos y aumentos de coste importantes para el trabajo no previsto que se deber

    hacer y tambin para el que ser necesario rehacer.

    Existen dos razones por las cuales es prcticamente imposible elaborar unos

    requisitos completos y estables en el primer intento:

    a) En primer lugar, es difcil encontrar un conjunto de futuros usuarios que

    conozcan lo suficiente el entorno en el que se debe utilizar el software, que hayan

    reflexionado lo suficiente sobre lo que quieren conseguir y que, adems, se pon-

    gan de acuerdo.

    b) En segundo lugar, porque el trabajo de consolidacin de las peticiones de

    estos usuarios nunca ser perfecto.

    En cualquier caso, tenemos que contar con el hecho de que, una vez termina-

    da oficialmente la etapa de anlisis y comenzada la de diseo, todava surgirn re-

    quisitos nuevos y cambios en los ya existentes.

    Qu se puede hacer, entonces? Parece que la opcin ms razonable sea es-

    tudiar a fondo una pequea parte de los requisitos que tenga una cierta autono-

    ma, y disearla, programarla y probarla, y una vez que el cliente la haya dado

    por buena, hacer lo mismo con otra parte, y otra. Si partimos de un software ya

    construido en parte, se puede esperar que la idea que nos hacemos de los requi-

    sitos restantes pueda ser cada vez ms precisa y que tambin obtengamos una

    estimacin cada vez ms segura del coste y de la duracin del proyecto comple-

    to; esto es lo que denominamos ciclo de vida iterativo e incremental (iterativo por-

  • Editorial UOC 25 Captulo I. Introduccin a la...

    que se repite dentro de un mismo proyecto e incremental porque procede por

    partes). Y se tendr que considerar normal que, a veces, cuando se construya

    una parte, se vea que es necesario modificar una hecha con anterioridad.

    La necesidad de estimar el coste y los plazos

    Los inconvenientes del modelo del ciclo de vida clsico mencionados en este subapar-tado no quieren decir que no pueda haber plazo o lmite de coste para un proyecto dedesarrollo de software; simplemente, se debe reconocer que no es realista creer que sepueda fijar de forma exacta la funcionalidad, el coste y la duracin del proyecto, todoa la vez. Si el software tiene que funcionar en una fecha determinada y no se puede au-mentar el gasto en personal, ser necesario estar dispuesto a aceptar que el software norealice todas las funciones deseadas; si la funcionalidad y la fecha de entrega del pro-grama son innegociables, se tendr que aumentar el nmero de programadores o ana-listas. Y esto no supone ninguna renuncia en relacin con los resultados que sealcanzaban hasta ahora, porque en la prctica muy pocos eran los proyectos en los queno se producan desviaciones en cuanto a la funcionalidad, presupuesto o plazo, sinoen varias de estas cosas al mismo tiempo.

    Por tanto, el modelo de ciclo de vida en cascada puede ser vlido si se aplica de

    manera que cada etapa, del anlisis de requisitos a la prueba, no prevea todo el

    conjunto del software, sino slo una parte cada vez; entonces tendramos un ciclo

    de vida iterativo e incremental basado en el ciclo de vida en cascada.

    2.2.2. El ciclo de vida con prototipos

    Para ayudar a concretar los requisitos, se puede recurrir a construir un proto-

    tipo del software.

    Un prototipo es un software provisional, construido con herramientas y tc-

    nicas que dan prioridad a la rapidez y a la facilidad de modificacin antes que a

    la eficiencia en el funcionamiento, que slo tiene que servir para que los usua-

    rios puedan ver cmo sera el contenido o la apariencia de los resultados de al-

    gunas de las funciones del futuro software.

    Un prototipo sirve para que los usuarios puedan confirmar que lo que se les

    muestra, efectivamente, es lo que necesitan o bien lo puedan pedir por compa-

    racin, y entonces se prepara una nueva versin del prototipo teniendo en cuen-

  • Editorial UOC 26 Ingeniera del software

    ta las indicaciones de los usuarios y se les ensea otra vez. En el momento en que

    el prototipo ha permitido concretar y confirmar los requisitos, se puede comen-

    zar un desarrollo segn el ciclo de vida en cascada, en este caso, no obstante, par-

    tiendo de una base mucho ms slida.

    Caractersticas del ciclo de vida con prototipos

    El ciclo de vida con prototipos no se puede considerar plenamente un ciclo de vidaiterativo e incremental, ya que slo el prototipo se elabora de manera iterativa, y nonecesariamente incremental. Sin embargo, es un modelo de ciclo de vida que puedeser adecuado en algunos casos, en especial cuando basta con prototipar un nmeroreducido de funciones para que las otras sean bastante parecidas a stas de forma quelas conclusiones a las que se llegue con el prototipo tambin les sean aplicables.

    2.2.3. La programacin exploratoria

    La programacin exploratoria consiste en elaborar una primera versin del

    software, o de una parte de ste, ensearla a los usuarios para que la critiquen y,

    a continuacin, hacerle los cambios que stos sugieran, proceso que se repetir

    tantas veces como sea necesario.

    La diferencia principal con respecto a los prototipos es que aqu el software

    es real desde el principio.

    Caractersticas de la programacin exploratoria

    La programacin exploratoria se puede considerar un ciclo de vida iterativo, pero no in-cremental, ya que el software est completo desde la primera versin. Como consecuenciade las numerosas modificaciones que sufre, la calidad del software desarrollado de estamanera y de su documentacin tiende a ser deficiente, como la de un software que hayaexperimentado un mantenimiento largo e intenso.

    2.2.4. El ciclo de vida del Rational Unified Process

    La empresa Rational Software ha propuesto este ciclo de vida como marco

    para el desarrollo de software que utiliza sus herramientas. Es claramente un ci-

    clo de vida iterativo e incremental.

  • Editorial UOC 27 Captulo I. Introduccin a la...

    Se distinguen estas cuatro etapas (denominadas fases):

    1) Inicio

    Se establece la justificacin econmica del software y se delimita el alcance del

    proyecto.

    2) Elaboracin

    Se estudia el dominio del problema, o simplemente dominio (parte de la ac-

    tividad de la empresa dentro de la cual se utilizar el software) y se tienen en

    cuenta muchas de las necesidades de informacin y eventuales requisitos no

    funcionales y restricciones, se establece la arquitectura general del software y se

    realiza una planificacin del proyecto.

    3) Construccin

    Se desarrolla todo el producto de forma iterativa e incremental, se tienen en

    cuenta todas las necesidades de informacin que debe satisfacer y se desarrolla

    la arquitectura obtenida en la fase anterior.

    4) Transicin

    Comprende la entrega del producto al cliente y el comienzo de su utiliza-

    cin; aunque es posible que sea necesario hacer retoques en el software y aadir

    nuevas funciones como consecuencia de errores detectados o de requisitos que

    se haban pasado por alto hasta el momento.

    En cada una de estas fases se llevan a cabo (en diferentes proporciones) los

    siguientes componentes de proceso:

    recogida de requisitos (requirement capture),

    anlisis y diseo,

    realizacin (implementation),

    prueba (test ).

    Cada unidad en la que se ejecutan pocos o muchos de los componentes de

    proceso es una iteracin, y se aplica a un nuevo fragmento de software. Todas las

    fases tienen iteraciones.

  • Editorial UOC 28 Ingeniera del software

    3. Desarrollo estructurado y desarrollo orientado a objetos

    Los mtodos de desarrollo de software ms utilizados hasta ahora pertenecen a

    dos grandes grupos: los mtodos estructurados y los mtodos orientados a objetos.

    3.1. Los mtodos estructurados

    Los mtodos estructurados provienen de la programacin estructurada y se

    utilizan tcnicas no muy integradas entre s.

    Los mtodos estructurados tienen, asimismo, estas caractersticas:

    La especificacin de los procesos y la de las estructuras de datos generalmen-

    te quedan bastante diferenciadas, y hay mtodos que ponen ms nfasis en

    aqullos o en stos.

    Muchas de sus tcnicas o bien pasan de lo general a lo particular (tcnicas top-

    down) o bien a la inversa (tcnicas bottom-up).

    Tcnicas ms utilizadas para los mtodos estructurados

    Las tcnicas ms usadas en los mtodos estructurados son seguramente los diagramas

    de entidad-relacin y de flujo de datos, con sus variantes. Los primeros se refieren a

    los datos y los segundos, a los procesos.

    3.2. Los mtodos orientados a objetos

    Si bien los mtodos estructurados continan siendo muy utilizados, los de-

    nominados mtodos orientados a objetos ganan terreno rpidamente.

    Si los mtodos estructurados de desarrollo de software tienen su origen en la pro-

    gramacin estructurada, los mtodos orientados a objetos tienen sus races en la

    programacin orientada a objetos.

    Es lgico que haya sucedido as en los dos casos: una nueva tcnica de pro-

    gramar exige una nueva manera de disear los programas adaptada a las carac-

  • Editorial UOC 29 Captulo I. Introduccin a la...

    tersticas de la programacin, y un nuevo mtodo de diseo hace deseable un

    nuevo mtodo de anlisis de requisitos que tenga la misma orientacin que el

    diseo, con la finalidad de evitar que el paso del anlisis de requisitos al diseo

    implique un cambio de modelo que inevitablemente comportara un trabajo

    adicional y un mayor riesgo de errores.

    De la misma manera que la programacin orientada a objetos gira en torno

    al concepto de clase, tambin lo hacen el anlisis de requisitos y el diseo. Por

    esta razn, el diagrama bsico de estos mtodos, el diagrama de clases y objetos,

    se utiliza tanto en el anlisis como en el diseo; adems, muchas de las clases

    descritas en el anlisis de requisitos se implementan en los programas pasando

    por el diseo, lo cual hace que el paso del anlisis de requisitos al diseo sea ms

    suave que en los mtodos estructurados y tambin ms sencillo y rpido.

    Puesto que dentro de una clase hay a la vez atributos y operaciones, es decir,

    datos y procesos, en el desarrollo orientado a objetos a medida que se definen e

    implementan clases se avanza al mismo tiempo en estas dos dimensiones. El de-

    sarrollo no procede ni de manera top-down ni bottom-up, sino que, ms bien, se

    construyen grupos de clases interrelacionadas, a menudo por niveles: clases que

    gestionan la presentacin de la informacin, o bien las entradas por pantalla, o

    bien las lecturas y grabaciones de la base de datos, o bien los algoritmos princi-

    pales del software; o bien proceden segn un ciclo de vida incremental, tal como

    hemos visto.

    Cabe aadir que el desarrollo orientado a objetos, adems de introducir tc-

    nicas nuevas, tambin aprovecha algunas tcnicas y conceptos del desarrollo es-

    tructurado, como el diagrama de estados y transiciones, segn veremos.

    Hay dos caractersticas del desarrollo orientado a objetos que probablemente

    han favorecido de manera decisiva su expansin hasta ahora y tambin con toda

    probabilidad la continuarn favoreciendo:

    Parece que permite por primera vez en la historia de la tecnologa del soft-

    ware la reutilizacin de software en un grado significativo, en forma de cla-

    ses implementadas, lo cual podra significar una va para solucionar, aunque

    slo sea en parte, los problemas de productividad y calidad descritos en apar-

    tados anteriores.

    Su relativa simplicidad facilita el desarrollo de herramientas informticas de

    ayuda al desarrollo; este factor podra ser potenciado por el hecho de que en

  • Editorial UOC 30 Ingeniera del software

    estos ltimos aos ha aparecido una notacin orientada a objetos muy am-

    pliamente aceptada, el UML.

    3.3. Los mtodos formales

    Los denominados mtodos formales parten de una especificacin de las nece-

    sidades de informacin en trminos de un modelo matemtico riguroso, del cual

    se podra deducir el programa que les satisfaga. Tambin permitan demostrar ma-

    temticamente que un programa es correcto en el sentido de que se ajusta a aque-

    llas necesidades.

    Aunque tendran que permitir eliminar las ambigedades y carencias de los

    mtodos no tan rigurosos, su utilizacin directa en el desarrollo de software para

    usos reales es poco frecuente en la actualidad, sin duda debido a la gran com-

    plejidad que tendra un modelado tan detallado y formalizado en casos reales.

    Algunos de los lenguajes de especificacin formal ms conocidos son Z,

    VDM, CSP y LARCH.

    4. Las herramientas CASE

    CASE significa Computer-Aided Software Engineering. Las herramientas CASE son

    software de apoyo al desarrollo, mantenimiento y documentacin informatizados

    de software.

    De esta definicin generalmente se excluyen las herramientas que tienen

    una de las funciones siguientes:

    1) o bien no tienen slo esta finalidad (herramientas de tratamiento de tex-

    to, de hoja de clculo, de dibujo en general, de planificacin de proyectos de

    cualquier ingeniera), ya que propiamente pertenecen a otros mbitos;

    2) o bien se utilizan para codificar el software (compiladores, entornos de

    cuarta generacin, editores ordinarios de programas, etc.), ya que siempre estn

    presentes, incluso cuando el desarrollo de software se hace de la manera ms ma-

    nual posible.

  • Editorial UOC 31 Captulo I. Introduccin a la...

    Quedan, pues, principalmente las herramientas que ayudan a aplicar tcnicas

    concretas de desarrollo y mantenimiento de software y por eso gestionan informa-

    cin sobre los elementos y conceptos que se utilizan en los mtodos de desarrollo,

    como las siguientes:

    Las herramientas diagramticas, las cuales, a diferencia de las de dibujo, re-

    conocen que un determinado smbolo es una clase y no simplemente un rec-

    tngulo. Estas herramientas tambin acostumbran a aceptar documentacin

    textual sobre aquellos elementos.

    Las herramientas de gestin de la prueba y de gestin de la calidad en general.

    Las herramientas de gestin de cambios, etc.

    Herramientas UpperCASE y LowerCASE

    A veces se distingue entre herramientas UpperCASE, que son las de anlisis y diseo, yLowerCASE, que se usan durante la programacin y la prueba.

    La importancia de la integracin de las herramientas

    Es conveniente que las herramientas que dan apoyo a diferentes tcnicas utilizadasdentro del mismo mtodo estn integradas, en el sentido de que si hay un tipo de ele-mento que es comn a dos tcnicas, sea compartido por las dos herramientas respec-tivas, de manera que slo sea necesario describirlo una vez y que todos los cambiosque se realicen despus en esta descripcin lleguen a las dos.

    La expansin del uso de herramientas CASE en el mtodo estructurado se fre-

    n a causa de la diversidad y de la falta de estandarizacin de las tcnicas que se

    utilizan; en los mtodos orientados a objetos, en cambio, actualmente la situa-

    cin es la contraria: por un lado, algunos diagramas sirven tanto para el anlisis

    como para el diseo, y por el otro, se ha producido una estandarizacin de las

    tcnicas y notaciones en el modelo conocido como UML que ha hecho que en

    el poco tiempo transcurrido desde su publicacin haya aparecido un nmero

    importante de conjuntos integrados de herramientas CASE basadas en l. Este

    soporte informatizado, amplio y creciente, en el desarrollo de software orientado

    a objetos sin duda reforzar la mejora de la calidad y la productividad en el de-

  • Editorial UOC 32 Ingeniera del software

    sarrollo de software que, tal como hemos visto, la tecnologa orientada a objetos

    tiene que fomentar.

    5. El OMG y el UML

    Para el desarrollo orientado a objetos utilizaremos el modelo denominado

    UML, del cual actualmente es responsable la organizacin llamada OMG.

    5.1. El Object Management Group (OMG)

    El Object Management Group (OMG), creado en 1989, es una organizacin no

    lucrativa en la cual participan ms de ochocientas grandes empresas de software,

    de hardware, usuarias y consultoras, y tiene la finalidad de fomentar el uso de la

    tecnologa de objetos e impulsar la introduccin de software orientado a objetos

    que ofrezca reusabilidad, portabilidad e interoperabilidad en entornos distribui-

    dos heterogneos.

    El medio con que el OMG intenta conseguir sus objetivos es la elaboracin de

    estndares, para los cuales acepta propuestas. En cambio, no produce software ni

    elabora especificaciones de implementacin o funcionalidad.

    El otro estndar del OMG

    Adems del UML, otro estndar que ha elaborado el OMG es CORBA, sobre objetos dis-

    tribuidos, cuyas implementaciones tienen una expansin rpida.

    5.2. Unified Modeling Language (UML)

    El Unified Modeling Language (UML) es un modelo para la construccin de

    software orientado a objetos que ha sido propuesto como estndar de ISO por el

  • Editorial UOC 33 Captulo I. Introduccin a la...

    OMG. Consta de un conjunto de tipos de diagramas interrelacionados, dentro

    de los cuales se utilizan elementos del modelo, que sirven parar describir distin-

    tos aspectos de la estructura y la dinmica del software.

    UML es el resultado de una cierta unificacin de los modelos utilizados en

    tres mtodos preexistentes de desarrollo de software orientado a objetos hechos

    por sus autores en colaboracin. Estos mtodos son los siguientes:

    el mtodo de Grady Booch;

    el OMT, de Jim Rumbaugh y otros;

    el OOSE, de Ivar Jacobson.

    Adems, se encuentran conceptos aportados por muchos otros autores, en-

    tre ellos Peter Coad, Edward Yourdon, James Odell y Bertrand Meyer.

    Evolucin del modelo UML

    Los primeros pasos hacia el modelo unificado se dieron en el ao 1994, cuando Boochy Rumbaugh, trabajando en Rational Software Corporation, comenzaron la unificacinde los modelos respectivos, y en octubre de 1995 se public la versin provisional 0.8del entonces denominado Unified Method.

    El mismo ao, Jacobson se incorpor con su empresa al equipo mencionado y a Ra-tional y, como resultado del trabajo de los tres autores, en 1996 salieron las versiones0.9 y 0.91 del UML. El OMG emiti en aquella poca una Request For Proposal, paraun modelo de este tipo, y entonces Rational, para responderle, constituy un consor-cio con otras organizaciones, con el resultado de que en enero de 1997 se present enla OMG la versin 1.0 del UML.

    Otras empresas que haban presentado tambin respuestas de manera independientese aadieron al consorcio y se public la versin 1.1, que fue aceptada por el OMG ennoviembre de 1997 (hubo otra propuesta, la del modelo OML, que tena y todava tie-ne un nmero importante de partidarios). El OMG encarg una revisin, cuyo resul-tado fue una versin 1.2, no publicada, y la versin 1.3, ya publicada como estndar.La versin 1.4 se public oficialmente en septiembre de 2001.

    Con el UML se ha llegado a un modelo orientado a objetos nico como mo-

    delo oficial, pero eso no quiere decir que se haya alcanzado un mtodo nico

    de desarrollo orientado a objetos; la verdad es que por el momento parece que

    falta bastante para llegar al mismo, si es que alguna vez se consigue. Es decir,que

  • Editorial UOC 34 Ingeniera del software

    lo que se ha conseguido es que haya unos diagramas que todos los desarrollado-

    res de software orientado a objetos entendern y harn de la misma manera, lo

    cual supone un adelanto realmente importante con respecto a la situacin an-

    terior en la que cada mtodo tena su notacin grfica; pero, incluso as, conti-

    na siendo posible que existan mtodos diferentes que utilicen el UML y que,

    por ejemplo, se valgan de los mismos diagramas en orden diferente o dentro de

    modelos de ciclo de vida distintos.

  • Editorial UOC 35 Captulo I. Introduccin a la...

    Conclusiones

    Se ha concretado qu se entiende por software en esta obra, se ha indicado por

    qu se puede considerar un producto industrial y, como consecuencia, por qu

    tiene sentido hablar de una ingeniera del software, y tambin hemos entrado en

    contacto con los dos grandes problemas que han afectado tradicionalmente al

    desarrollo de software: las carencias referidas a la productividad y calidad.

    Si entramos dentro del proceso de elaboracin del software, hemos visto el

    concepto de ciclo de vida y sus dos grandes modelos el ciclo de vida en cascada

    o clsico y los ciclos de vida iterativos e incrementales, ms dos modalidades in-

    termedias el desarrollo con prototipos y la programacin exploratoria. Como

    ciclos concretos, hemos indicado de una manera ms o menos detallada el ciclo

    de vida del Rational Unified Process, como representante de las tendencias ac-

    tuales en lo que se refiere a ciclos iterativos e incrementales, y el ciclo de vida cl-

    sico, cuyo inters radica, adems de en su importancia histrica, en el hecho de

    que algunos de sus conceptos continan siendo vlidos todava.

    A continuacin, se han presentado las tres grandes familias de mtodos de

    desarrollo de software: las dos ms utilizadas en entornos reales, que son los m-

    todos estructurados ms tradicionales y los mtodos orientados a objetos en

    plena expansin, sin menospreciar los mtodos formales, interesantes por su

    gran rigor terico.

    Despus de hablar de tcnicas, es lgico referirse a las herramientas que stas

    emplean; por eso hemos visto el concepto de herramientas CASE y nos hemos

    informado de su situacin actual y de la evolucin previsible de su papel.

    Puesto que para estudiar el anlisis y diseo orientados a objetos tema esen-

    cial de esta obra utilizaremos los conceptos y la notacin del UML, se ha expues-

    to el origen de este modelo y el cometido de la organizacin que se responsabiliza

    del mismo, la OMG.

  • Editorial UOC 37 Captulo II. UML (I): el modelo esttico

    Captulo II

    UML (I): el modelo esttico

    Como sabemos, para el anlisis y el diseo orientados a objetos utilizaremos

    los conceptos y las notaciones esencialmente grficas del UML.

    El UML comprende un cierto nmero de diagramas interrelacionados me-

    diante conceptos comunes. Slo para describirlos, los consideraremos agrupa-

    dos en tres modelos:

    En este captulo veremos el modelo esttico, que consta, por una parte, de clases

    y objetos, y por la otra, de relaciones de diferentes tipos entre clases y entre objetos.

    En captulos posteriores trataremos el resto de los modelos y la utilizacin

    del UML en el anlisis y en el diseo.

    1. Concepto de modelo esttico y diagrama de clases

    El modelo esttico del UML es aqul en el que se describen las clases y los

    objetos. Se denomina esttico porque muestra todas las relaciones posibles a lo

    largo del tiempo, no las que son vlidas en un cierto momento.

    Esttico describe la estructura de clases y objetos.

    Dinmico (o modelo de comportamiento), describe las interacciones entre los objetos dentro del software.

    Implementacin describe la estructura del software en cuanto a los componentes de que consta y su ubicacin.

  • Editorial UOC 38 Ingeniera del software

    Ejemplo de modelo esttico

    Un diagrama esttico nos puede mostrar que cada profesor tiene, al menos, una asigna-

    tura, y que cada asignatura tiene, al menos, un profesor, pero no nos dice qu asig-

    naturas tiene un profesor concreto.

    Este modelo consta de los dos diagramas siguientes:

    Diagrama de clases, que puede contener clases y objetos y relaciones entre s-

    tos, y que se hace siempre.

    Diagrama de objetos, que slo contiene objetos y relaciones entre stos, y que

    es opcional, ya que se utiliza principalmente para realizar ejemplos del diagra-

    ma de clases con objetos concretos de las mismas.

    Un diagrama de clases muestra la estructura esttica de las clases en un do-

    minio (porcin del mundo real considerada por una aplicacin); se muestran las

    clases y las relaciones entre stas, que pueden ser de herencia, asociacin, agre-

    gacin o uso.

    Uso del modelo esttico

    El modelo esttico se utiliza en todas las etapas del ciclo de vida; en las diferentes etapasse documentan diferentes tipos de objetos. En el anlisis se consideran objetos del mun-do del usuario (por ejemplo, artculos, facturas, clientes, etc.) y en el diseo, en cambio,se consideran objetos de la tecnologa informtica: pantallas, gestores de disco, etc.

    El modelo esttico pretende ser independiente del lenguaje de programa-

    cin, pero, sin embargo, si se sabe cul ser, es conveniente no utilizarlo en

    el anlisis de conceptos que sabemos que dicho lenguaje no soporta, si que-

    remos ahorrarnos muchos cambios cuando lleguemos al diseo. Tambin se

    deber tener en cuenta que, cuando el UML permite describir elementos in-

    compatibles con un lenguaje determinado, raramente la herramienta CASE

    nos lo impedir; por lo tanto, ser responsabilidad del diseador del software

    evitar caer en la utilizacin de conceptos no soportados por el lenguaje de

    programacin.

  • Editorial UOC 39 Captulo II. UML (I): el modelo esttico

    Relaciones en los lenguajes de programacin

    Los lenguajes de programacin soportan las relaciones de herencia, pero no distin-guen entre los otros tres tipos de relaciones que existen; por tanto, al pasar del diseoa la programacin, estos tipos se tendrn que transformar.

    Tambin puede suceder lo contrario; es decir, que se quieran modelar ele-

    mentos que la herramienta CASE no soporta, porque UML no los prev, o por

    otros motivos; entonces se tendrn que documentar estos aspectos mediante

    comentarios libres, que permiten todas las herramientas. Algunas herramientas

    permiten que el usuario defina extensiones, pero si una empresa utiliza esta po-

    sibilidad, los diagramas generados no sern transportables a otras empresas.

    2. Clasificadores

    El clasificador es la entidad bsica del modelo esttico. Un clasificador es

    ms general que una clase; es un conjunto cuyos elementos se denominan ins-

    tancias.

    El clasificador en s mismo no tiene smbolo grfico, sino que lo tienen sus

    estereotipos:

    Clase: El concepto de clase es el que ya conocemos de la programacin orien-

    tada a objetos, y sus instancias son los objetos, que tienen identidad, en el

    sentido de que incluso dos objetos que coinciden en el valor de todos sus atri-

    butos son objetos diferentes si se han creado como tales.

    Tipo de dato: Por tipo de dato entendemos un tipo base ofrecido por algn

    lenguaje de programacin o construido por el programador; tiene operacio-

    nes asociadas igual que las clases, pero sus instancias, a diferencia de los ob-

    jetos, no tienen identidad.

    Interfaz: Una interfaz slo describe las operaciones de una clase que son visi-

    bles desde otras clases; se dice que dicha clase implementa la interfaz corres-

    pondiente.

  • Editorial UOC 40 Ingeniera del software

    Estereotipo

    Un estereotipo de un elemento del UML es una variante ms restrictiva de dicho ele-mento; hay estereotipos que forman parte del UML, y tambin se pueden encontrarestereotipos definidos referidos al diagrama, que son un instrumento para extenderel UML, pero as se pierde portabilidad.

    La utilidad del concepto de clasificador radica en el hecho de que los estereo-

    tipos mencionados tienen mucho en comn, por lo que es suficiente con reali-

    zar la indicacin una vez en el clasificador. La notacin grfica simplificada es

    la misma para los tres: un rectngulo.

    Todos los clasificadores deben tener un nombre. En un clasificador se puede

    indicar la palabra clave del estereotipo (entre comillas latinas, ). Cuando no

    se indique ningn estereotipo, se tratar de una clase.

    3. Paquetes

    Un paquete o package es slo una caja que contiene elementos, como cla-

    sificadores, objetos u otros paquetes, as como otras entidades que veremos ms

    adelante, como los casos de uso.

    Paquetes en JAVA

    Por la definicin que ofrecemos de paquete, podemos ver que el concepto de paqueteen el UML es diferente y ms amplio que en Java.

  • Editorial UOC 41 Captulo II. UML (I): el modelo esttico

    Grficamente, un paquete se representa as:

    Todas las aplicaciones deben tener, por lo menos, un paquete que normal-

    mente se denomina raz. Cada elemento de un paquete tiene visibilidad, es decir,

    puede ser reconocido o bien desde todos los otros paquetes, o bien slo desde al-

    gunos.

    Ejemplo de paquetes

    stas son dos maneras de representar el mismo paquete:

    En la primera, se pueden incluir dentro del smbolo del paquete los smbolos de loselementos que contiene; la segunda, simplificada, es ms adecuada para representarreferencias al paquete (desde otros paquetes, por ejemplo).

    Se pueden establecer los siguientes tipos de relaciones entre paquetes:

    De especializacin. Si un paquete A hereda de otro B todos los elementos de B,

    son casos ms restrictivos de elementos de A.

    De inclusin. Si el paquete A incluye el B, todos los elementos de B estn

    tambin en A.

  • Editorial UOC 42 Ingeniera del software

    De importacin. Desde el paquete que importa se reconocen los nombres de

    los elementos del otro paquete visibles desde el exterior.

    Ejemplo

    Por ejemplo, pblicos en el sentido de Java.

    De acceso. No slo se reconocen los nombres de los elementos, sino que, ade-

    ms, se pueden utilizar.

    Ejemplo de relaciones entre paquetes

    En la representacin grfica, el paquete Diagramas que vemos a continuacin importadel paquete Figuras, y el paquete Diagramas de UML hereda del paquete Diagramas;una relacin de acceso se representara con la palabra clave access.

  • Editorial UOC 43 Captulo II. UML (I): el modelo esttico

    4. Clase y conceptos afines

    Sobre la programacin orientada a objetos sabemos que una clase describe

    un conjunto de objetos en el cual todos tienen los mismos atributos y las mis-

    mas operaciones. Los atributos y operaciones pueden ser de instancia, es decir,

    vinculados a objetos individuales, y de clase, que no estn relacionados con

    ningn objeto en particular de la clase. Este mismo es el concepto de clase en

    el UML.

    En principio, cada clase es visible (es decir, reconocida) dentro del paquete

    donde se ha declarado, y su nombre no puede estar repetido en ste, pero desde

    un paquete se reconocen los nombres de clases y elementos en general de

    otro paquete del que se importa, en el sentido indicado con anterioridad; el

    nombre de la clase tiene que estar calificado por el del paquete, as Paquete :

    Clase.

    4.1. Representacin ampliada de las clases

    Puesto que una clase es un clasificador, se puede utilizar como smbolo de la

    clase un simple rectngulo con el nombre. Sin embargo, dado que una clase con-

    siste en un encapsulado de unos atributos y unas operaciones, tambin se da una

    representacin grfica ms detallada por medio de un rectngulo dividido en los

    tres compartimentos siguientes:

    El primer compartimento contiene el nombre de la clase.

    El segundo compartimento contiene la lista de los atributos.

    El tercer compartimento corresponde a los servicios de la clase.

    Se ha de tener en cuenta que como sinnimos de operacin se utilizan a menudo m-todo y servicio; pero en UML, el trmino servicio no se usa, y por mtodo se entiendela implementacin de una operacin.

    El usuario puede crear otros compartimentos, adems de los tres obligatorios,

    para dar informacin adicional como excepciones, requisitos, etc.

  • Editorial UOC 44 Ingeniera del software

    4.1.1. El compartimento del nombre

    En la parte superior del compartimento de la clase se puede indicar un este-

    reotipo.

    Algunos estereotipos forman parte del UML como metaclass, del que se ha-

    blar ms adelante, y se pueden definir mediante un proyecto concreto, por

    ejemplo.

    Justo debajo se encuentra el nombre de la clase. Se recomienda que sea un

    sustantivo en singular que a veces puede tener una segunda palabra que la cali-

    fique.

    Tambin es recomendable que comience por mayscula.

    Debajo del nombre se pueden encontrar comentarios optativos entre llaves

    ({}) denominados cadenas de caracteres de propiedades (property strings) o valores

    etiquetados (tagged values)*; los puntos suspensivos que se pueden hallar al final

    de uno de los apartados indican que hay ms elementos, pero que no se ven. La

    property string abstract denota una clase abstracta.

    El nombre de clases

    Los nombres de las clases tienen que estar bien pensados. La posibilidad de reuti-lizacin depende en gran medida de ello, porque cuando queramos reutilizar unaclase de una librera que tenga centenares de nombres, la nica pista que tendre-mos es el nombre, y si no se le dio un nombre adecuado, ser muy difcil de en-contrar.

    Un atributo de clase es lo mismo que un atributo static de Java y una variable de clase deSmalltalk y C++.

    Ejemplo de clase slo con el compartimento del nombre

    En la figura siguiente, el estereotipo anlisis podra indicar que la clase Rectangulo seha identificado en la etapa de anlisis.

    *. Formato de los comentariosProperty strings y tagged values tienen la forma nombre = valor; en el caso de propiedades booleanas,el nombre solo ya indica la presencia de la propiedad.

  • Editorial UOC 45 Captulo II. UML (I): el modelo esttico

    4.1.2. Especificacin de los atributos

    Cada atributo tiene un nombre o identificador y un tipo. Este ltimo puede

    ser un tipo simple del lenguaje de programacin (por lo menos, durante el di-

    seo y la programacin, porque durante el anlisis puede ser que las clases se

    describan sin pensar en ningn lenguaje de programacin en concreto) como

    entero o carcter, o bien un tipo complejo, como una lista de enteros, o tam-

    bin una clase ya definida.

    Un atributo, sea de instancia o de clase, se define de la siguiente forma:

    visibilidad nombre : expresin-de-tipo ?= valor-inicial { property string }

    Se indica que un atributo es atributo de clase* subrayando su definicin.

    La visibilidad de un atributo** indica hasta qu punto las operaciones de

    otras clases pueden acceder al atributo, y se indica mediante los siguientes sm-

    bolos.

    Pblico: +

    Protegido: #

    Privado: -

    Dentro del paquete:

    Tambin tienen visibilidad otros elementos del modelo esttico, como las

    operaciones y los extremos de asociacin.

    *. Atributo de clase. Un atributo de clase es lo mismo que un atributo static de Java y una variablede clase de Smalltalk y C++.**. La visibilidad. En el UML no hay definiciones del significado de estas opciones de visibilidad,sino que se dejan para los lenguajes de programacin; si algn lenguaje incluye ms tipos de visibi-lidad, tambin se podrn indicar aqu.

  • Editorial UOC 46 Ingeniera del software

    En el lugar de los atributos, se pueden utilizar property strings, que son, respec-

    tivamente, public, protected o private. Las property strings son opcionales; adems

    de las mencionadas, podemos encontrar frozen, que indica que no se puede cam-

    biar el valor del atributo.

    En lo referente al nombre de los atributos, se deben tener en cuenta las siguien-

    tes pautas:

    Se recomienda que comience por minscula.

    Cuando se trate de un atributo derivado (es decir, que es redundante con

    otros a partir de los cuales se puede obtener el valor), el nombre tiene que ir

    precedido de /.

    Es conveniente que el nombre cumpla las reglas lxicas del lenguaje de pro-

    gramacin, si no queremos que se tenga que cambiar al llegar al diseo. La

    expresin de tipo y el valor inicial tambin las debern respetar.

    Se pueden utilizar indicadores de multiplicidad como en el caso de los vectores

    o matrices de acuerdo con el lenguaje.

    Uso de los indicadores de multiplicidad

    Consideremos:

    hijos [0..3]: persona o bien, hijos [3]: persona; en el primer caso podra haber entre 0 y3 hijos, pero en el segundo tiene que haber exactamente tres.

    Ejemplo de clase con compartimento de nombre y compartimento de atributos

    Como se puede ver en la figura siguiente:

  • Editorial UOC 47 Captulo II. UML (I): el modelo esttico

    extremos seran las coordenadas de dos vrtices opuestos del rectngulo, que lo determi-nan; Punto sera una clase descrita en el mismo paquete; gruesoLnea tiene el valor 1 poromisin, y rea es un atributo derivado, ya que su valor se puede calcular a partir de lascoordenadas de los puntos de extremos.

    4.1.3. Especificacin de las operaciones

    Una operacin se define de la siguiente forma:

    visibilidad nombre ( lista-de-parmetros ): tipo-de-retorno {property string}

    Se indica que una operacin es operacin de clase subrayando su definicin.

    La visibilidad se seala igual que en el caso de los atributos.

    Conviene que el nombre de la operacin y de los parmetros y el tipo de los

    parmetros y del retorno cumplan las reglas del lenguaje de programacin.

    En la programacin conviene que los nombres de las operaciones estn bien pensa-dos, porque son la base del polimorfismo, en el que se aplica que a igual concepto,igual nombre.

    Se recomienda que los nombres de las operaciones comiencen por minscula.

    La lista de parmetros se compone de parmetros separados por comas; la sin-

    taxis de cada uno es la siguiente:

    tipo nombre : expresin-de-tipo = valor-por-omisin

    Donde tipo es in, out o inout (por omisin, in), y nombre es el nombre del pa-

    rmetro formal; expresin-de-tipo depende del lenguaje; valor-por-omisin depen-

    de del lenguaje y es opcional.

    El tipo-de-retorno slo se tiene que utilizar cuando la operacin devuelva un

    valor como resultado, y tambin se puede usar un parmetro out en su lugar.

    Opcionalmente, puede aparecer property strings: query, que denota que la ope-

    racin no modifica el estado del sistema, y para especificar la semntica de concu-

    rrencia se pueden utilizar una de stas: sequential, guarded o concurrent, y abstract,

    que indica que la operacin es abstracta.

    Se pueden utilizar estereotipos ponindolos encima de la operacin afectada.

  • Editorial UOC 48 Ingeniera del software

    Ejemplo de clase con los tres compartimentos

    Tal y como se puede apreciar en el grfico siguiente, la operacin nuevoRectangulo es delestereotipo (no incluido dentro del UML) constructor y tiene dos parmetros in (poromisin); la operacin calculoArea no tiene parmetros pero retorna un valor, cuyo tipose indica.

    4.2. La herencia en el anlisis y el diseo

    Sabemos que la herencia presupone que existan dos clases, de las cuales una

    desempea el papel de superclase y la otra, el de subclase.

    Se dice que la relacin entre una subclase y su superclase es una relacin

    is_a_kind_of.

    La subclase comprende un subconjunto de los objetos de la superclase, los

    cuales, por tanto, tienen todos los atributos y operaciones de instancia de la su-

    perclase (se dice que la subclase los hereda) y, adems, pueden tener algunos adi-

    cionales, especficos de la subclase.

    Segn se defina primero la superclase o sus subclases, tenemos respectiva-

    mente dos tipos de herencia: herencia por especializacin y herencia por gene-

    ralizacin.

  • Editorial UOC 49 Captulo II. UML (I): el modelo esttico

    4.2.1. Herencia por especializacin

    Se llama de esta manera porque lo que se hace es crear una clase ms especia-

    lizada, ms restrictiva, a partir de una clase definida con anterioridad.

    Ejemplo de especializacin

    Consideramos que en la gestin de un hotel identificamos la clase Habitacin y des-pus nos damos cuenta de que hay una categora especial de habitaciones que tieneatributos y/o operaciones diferentes, que son las suites; esto se representa de la si-guiente forma:

    La flecha con punta triangular vaca y cuerpo continuo expresa una relacin

    entre subclase y superclase, y su sentido indica cul es cada una. Tambin se ha-

    bla de que hemos creado una jerarqua de herencia, muy sencilla en algunos ca-

    sos (como por ejemplo el caso de especificacin) pero que llega a ser un rbol de

    diferentes niveles si hay superclases que presenten distintas subclases y subcla-

    ses que sean a la vez superclases de otras.

    Incluso la jerarqua se convierte en una red si algunas clases tienen ms de

    una superclase (herencia mltiple).

    El proceso mediante el cual reconocemos una subclase dentro de otra clase que,

    consecuentemente, pasa a ser superclase de la primera se denomina especializa-

    cin o derivacin.

  • Editorial UOC 50 Ingeniera del software

    4.2.2. Herencia por generalizacin. Clases abstractas

    Supongamos que, al informatizar los impuestos de un municipio, encontra-

    mos, por un lado, los impuestos sobre las motos y por otro, los impuestos sobre

    los ciclomotores. Aunque inicialmente se haba considerado que Motos y Ciclo-

    motores son dos clases diferentes, despus se ha observado que tienen algunos

    atributos y operaciones en comn y, en consecuencia, se define una superclase

    comn Veh2Ruedas

    En este caso hemos procedido al revs: a partir de las subclases, hemos en-

    contrado la superclase. Este proceso se denomina generalizacin.

    De la misma forma que en el ejemplo del hotel poda haber habitaciones que no

    fueran suites y, por tanto, haba objetos que, de las dos clases, slo pertenecan a Ha-

    bitacin, en este ltimo, cualquier vehculo de dos ruedas es o bien una moto o

    bien un ciclomotor. Es decir, todos los elementos de Veh2Ruedas pertenecen a

    una u otra subclase y, por lo tanto, Veh2Ruedas es una clase artificial, un simple

    recurso para no describir dos veces lo que tienen en comn Motos y Ciclomotores; se

    dice que Veh2Ruedas es una clase abstracta.

    Una clase abstracta es una superclase de la cual no se pueden crear (instanciar)

    directamente objetos, sino que se tienen que crear necesariamente en alguna de

    sus subclases.

  • Editorial UOC 51 Captulo II. UML (I): el modelo esttico

    Otro procedimiento

    En el proceso de generalizacin tambin se podra haber trazado una flecha indepen-diente desde cada subclase a la superclase. La propiedad disjoint denota que todo ob-jeto de la superclase pueda pertenecer slo a una de las subclases como mximo.

    Por esta razn se dice que las clases abstractas son no instanciables.

    Se indica que una clase es abstracta o bien poniendo su nombre en cursiva,

    o bien con la propiedad {abstract} en el compartimento del nombre.

    Una clase abstracta puede tener operaciones abstractas, que son las que slo es-

    tn implementadas en las subclases, en principio, de forma diferente en cada una.

    Una operacin abstracta debe tener o bien su definicin en cursiva, o bien la

    propiedad {abstract} al final de la misma.

    4.3. Variantes en el concepto de clase

    En este subapartado consideraremos diferentes tipos especiales de clases,

    pero no todos se pueden representar directamente en UML.

    4.3.1. Clases diferidas

    Las clases diferidas son clases abstractas que tienen alguna operacin abstracta.

    Tambin se denominan clases virtuales porque en algunos lenguajes como

    C++ o Delphi, los servicios de las caractersticas que acabamos de indicar se de-

    claran virtual; en Java se declaran abstract, y en Eiffel, deferred. En UML se definen

    simplemente como clases abstractas.

    4.3.2. Clases terminales

    Muchas veces, y especialmente en frameworks, nos interesa bloquear los cam-

    bios que se podran realizar con la herencia, porque al crear una subclase es fcil

  • Editorial UOC 52 Ingeniera del software

    que no se conozcan todas las dependencias y restricciones que se heredan, de

    modo que se pueden cometer errores.

    Java permite calificar diferentes elementos como terminales:

    Clases terminales, que son las que no pueden tener subclases. Mtodos terminales, que son aquellos que no pueden ser modificados en una subclase. Atributos terminales, cuya visibilidad no se puede cambiar en una subclase.

    El UML no dispone de estos conceptos.

    4.3.3. Metaclases

    Las metaclases son clases cuyas instancias son clases.

    El concepto de metaclase raramente se encuentra implementado en los len-

    guajes orientados a objetos; un lenguaje que lo implementa es el CLOS (CLOS

    es la sigla de Common Lisp Object System), que fue creado por investigadores de

    inteligencia artificial y es un derivado del LISP.

    En UML, la metaclase es un estereotipo de la clase.

    4.3.4. Clases parametrizadas o plantillas

    Una clase parametrizada o plantilla (en ingls, template) es un descriptor de

    clase formalmente igual a una clase, excepto que algn trmino de su definicin

    es un parmetro.

    Qu es un parmetro de una plantilla?

    Un parmetro puede ser, por ejemplo, el nombre de una operacin o atributo, el tipo deun atributo o de un parmetro o del resultado de una operacin, el nmero de elemen-tos de un atributo que sea una matriz o el nmero de bytes de un atributo de tipo string.

    Cuando se dan valores a todos los parmetros de una plantilla se obtiene una

    clase totalmente especificada que, por tanto, no puede ser modificada directa-

  • Editorial UOC 53 Captulo II. UML (I): el modelo esttico

    mente, pero se pueden definir sus subclases. Aunque una plantilla no es propia-

    mente una clase, se puede definir como subclase de una clase A, y entonces las

    clases que se han obtenido al dar valores a sus parmetros sern subclases de A.

    Ejemplo de clase parametrizada

    En el diagrama que vemos a continuacin hemos definido una plantilla, hemos ge-nerado una clase y hemos dado un valor a cada parmetro. La relacin entre la clasey la plantilla se puede representar de las dos formas indicadas:

    Las clases parametrizadas se denominan clases genricas* en algunos lenguajes

    de programacin.

    4.3.5. Clases de utilidad

    A veces nos encontramos con rutinas que no corresponden a ninguna clase de

    operacin, o bien con datos que no corresponden a ningn objeto determinado,

    por ejemplo, parmetros del sistema que slo pueden tener un valor cada uno.

    Para incluir estas rutinas y datos dentro de un diagrama esttico de UML, po-

    demos definir una clase con el estereotipo utility, e incluir las rutinas como ope-

    raciones y los datos como atributos.

    *. Las clases genricas en otros lenguajes. C++ y Eiffel soportan plenamente las clases genricaspero con algunas diferencias, mientras que en Java