ingenieria del software

5/13/2018 Ingenieria Del Software - slidepdf.com

http://slidepdf.com/reader/full/ingenieria-del-software-55a7560e3f3d3 1/323

INTRODUCCIONA LA INGENIERÍADEL SOFTW AREJosé A . Cerrada Somol inos

( C o o r d i n a d o r )

TO Editorial universitaria

^ ^ Ramón Areces U f l E D



I N T R O D U C C I Ó NA L A I N G E N I E R Í A

D E L S O F T W A R E



J O S É A . C E R R A D A S O M O L I N O SCatedrát ico de Lenguajes y Sistemas InformáticosEscuela de Informática (UNED)

M A N U E L E . C O L L A D O M A C H U C ACatedrático de Lenguajes y Sistemas Informáticos

Facultad de Informática (UPM)S E B A S T I Á N R U B É N G Ó M E Z P A L O M O

Profesor Ayundante de Lenguajes y Sistemas InformáticosEscuela de Informática (UNED)

J O S É F E L I X E S T I V A R I Z L Ó P E ZProfesor Ayudante de Lenguajes y Sistemas Informáticos

Escuela de Informática (UNED)ook k\ - -

INTRODUCCIONA LA INGENIERÍA

DEL SOFTWAREMVf.RS!;MD NACIONAL DL-;

| EDUCACIÓN A DISTANCIA| CiiNTRO ASOCIA n ni PONTEVEDRA

W , B L , 0 1 E C A

'"G'STRO N°

E D I T O R I A L C E N T R O D E E S T U D I O S R A M Ó N A R E C E S , S .A .



Primera edic ión: junio 2000Primera reimpresión: enero 2003Segunda re impres ión: junio 2005Tercera re impres ión: ju l io 2006

Reservados todos los derechos.Ni la totalidad ni parte de este l ibro puede reproducirse o transmitirsepor ningún procedimiento electrónico o mecánico, incluyendo fotoco-pia, grabación magnética, o cualquier almacenamiento de informacióny sistema de recuperación, sin permiso escrito de Editorial Centro deEstudios Ramón Areces, S. A.

© EDI TORI AL CEN TRO DE ESTU DI OS RAM Ó N ARECE S, S. A .Tomás Bretón, 21 - 28045 MadridTeléfono: 915.398.659Fax: 914.681.952Correo: [email protected] Web: www.cerasa.es

ISBN-10: 84-8004-417-9ISBN-13: 978-84-8004-417-2Depósito legal: SE-3148-2006 Unión Europea

Impreso por Publidisa

mailto:[email protected]

http://www.cerasa.es/







CONTENIDO

UNIDA D DIDÁCTICA I

Tema 1Introducción 3

1.1 Co ncep to de Ingen iería de Sistemas 31.1.1 Co nce pto de sistema 3

1.1.2 Sistemas basad os en co m pu tado r 41.1.3 Com ponentes hardw are, softwa re y hum ano s 51.2 Carac terísticas del so ftw are 51.3 Conce pto de Ingeniería de Softw are 6

1.3.1 Per spe ctiva históric a 71.3.2 La crisis del so ftw ar e 81.3.3 M itos del so ftw are 9

1.4 Form alización del proc eso de desa rrollo 101.4.1 El ciclo de vid a del sof tw are . M ode los clásicos 10

El m ode lo en cascada 11El m ode lo en V 14

1.5 Uso de pro totip os 161.5.1 Pro totipo s ráp ido s 171.5.2 Pro totipo s evo lutivos 191.5.3 He rram ientas para realización de prototipo s 20

1.6 El m od elo en espiral 211.7 Com binación de mo delo s 231.8 M antenim iento del softw are 23

1.8.1 Ev olució n de las aplic acio nes 241.8.2 Ge stión de cam bios 251.8.3 Re inge niería 26



vni Intro du cció n a la Inge niería de So ftw are

1.9 Garan tía de calidad de sof tw are 261.9.1 Factores de calid ad 271.9.2 Plan de ga ran tía de calida d 281.9.3 Re visio nes 291.9.4 Pr ue ba s 301.9.5 Gestión de config uración 301.9.6 N orm as y está nd ares 32

Te ma 2

Especificación deSof tware 35

2.1 M od elad o de Sistemas 352.1.1 Con cepto de m ode lo 362.1.2 Técnicas de m od elad o 37

Descomposición. Mo delo jerarqu izado 37Aproxim aciones sucesivas 38Emp leo de diversas notaciones 39Considerar dist intos pu nto s de vista 39Realizar un análisis del dom inio 40

2.2 Análisis de requisitos de softw are 42

2.2.1 Ob jetivo s del análisis 432.2.2 Ta reas del análisis 462.3 No tacione s par a la especificación 49

2.3.1 Leng uaje na tura l 502.3.2 D iag ram as de flujo de da tos 522.3.3 Dia gram as de transición de estad os 572.3.4 Descripciones funcio nales. Pse udo cód igo 602.3.5 Descripción de da tos 632.3.6 Dia gram as de m ode lo de dato s 65

2.4 Do cum ento de especificación de requis itos 682.5 Ejem plos de especificaciones 75

2.5.1 Video juego de las min as 752.5.2 Sistema de ges tión de biblioteca 83

UN IDAD DIDÁCTICA II

Te ma 3

Fu nd am entos del Diseño de Softwar e 103

3.1 Intro du cció n 103



Contenido vn

3.2 Con cepto s de base 1073.2.1 A bstrac ción 1083.2.2 M od ula rida d 1103.2.3 Re finam iento 1113.2.4 Estr uctu ras de da tos 1123.2.5 Oc ultac ión 1133.2.6 G ene ricid ad 1143.2.7 H ere ncia 1163.2.8 Po lim orf ism o 1183.2.9 Co nc urre nc ia 119

3.3 No tacion es pa ra el dise ño 121

3.3.1 No tacione s estru ctur ales 122Diag ram as de estructura 124Diag ram as HIPO 126Diag ram as de Jackson 128

3.3.2 N otac ion es está ticas 130Diccionario de da tos 130Diag ram as Entidad-Relación 130

3.3.3 No tacion es diná mic as 131Diag ram as de flujo de datos 131Diagra ma s de transición de estados 131

Len guaje de Desc ripción de Pro gra m as (PDL) 1313.3.4 No tacione s híb rida s 132Diagra ma s de abstracciones 132D iagra m as de objetos 136

3.4 Do cum entos de diseño 1403.4.1 Do cum ento AD D 1403.4.2 Do cum ento DD D 144

Tema 4Técnicas Generales de

Diseñ o d e Softwar e 147

4.1 Desc omp osición M od ula r 1484.1.1 Indep ende ncia func ional 150

Acoplamiento 150Cohesión 154

4.1.2 Co m pre nsib ilidad 1574.1.3 A da pta bilid ad 158

4.2 Técnicas de diseño funcion al desce nden te 1604.2.1 Desarrollo por refinam iento progre sivo 160



rvn i Introducción a la Ingenier ía de Software

4.2.2 Prog ram ación estru ctu rad a de Jackson 1624.2.3 Diseñ o estr uc tura do 1654.2.4 Ejem plo: Sistem a de gestió n de biblioteca 169

4.3 Técnicas de diseñ o bas ado en abstracciones 1704.3.1 Desco mp osición m od ula r basa da en abstracciones 1704.3.2 M éto do de Ab bott 1724.3.3 Ejemp lo: Vid eojueg o de las m inas 175

4.4 Técnicas de diseñ o orie ntad as a objetos 1774.4.1 Diseño orie ntad o a objetos 1784.4.2 Ejem plo: Estación m eteoro lógic a 180

4.5 Técnicas de diseñ o de dato s 188

4.6 Diseño de bases de dato s relaciónales 1894.6.1 Form as no rma les 1894.6.2 Dis eño de las en tid ad es 1914.6.3 Tr ata m ien to de las relacion es de asociación 1924.6.4 Trata mie nto de las relaciones de com posición 1934.6.5 Tr ata m ien to de la here ncia 1944.6.6 Dise ño de índ ices 1944.6.7 Ejemp lo: Diseño de dato s para la gestión de biblioteca 194

4.7 Diseño de bases de da tos de objetos 1974.8 Ejem plos de diseñ os 198

4.8.1 Vi deo jueg o de las m ina s 1984.8.2 Ejem plo: Sistem a de gestió n de biblioteca 217

UN IDAD DIDÁCTICA III

Te ma 5Codificación yPr ue ba s 233

5.1 Codificación del diseñ o 2335.2 Lenguajes de prog rama ción 2355.3 De sarrollo histórico 235

5.3.1 Prim era gen erac ión 2365.3.2 Seg und a generac ión 2375.3.3 Tercera gen erac ión 238



Contenido íx

5.3.4 Cu arta gene ración 2415.4 Prestac iones de los leng uaje s 2435.4.1 Es tructu ras de contro l 243

Programación estructurad a 243M anejo de excepc iones 244Concurrencia 248

5.4.2 Estr uctu ras de dat os 252Da tos simp les 252Datos com puesto s 253Constantes 254Com probación de tipos 255

5.4.3 Ab straccion es y objetos 256Abstracciones funcion ales 257Tipos abstractos de datos 257Objetos 258

5.4.4 M od ula rid ad 2595.5 Criterios de selección del leng uaje 2615.6 Asp ectos me todo lógico s 263

5.6.1 N or m as y estilo de codificación 2645.6.2 M anejo de erro res 2655.6.3 A spe cto s de eficienc ia 268

5.6.4 Tran sportab ilidad de softw are 2705.7 Técnicas de prue ba de unid ad es 2725.7.1 Objetivos de las pru eb as de sof tw are 2725.7.2 Pru eb as de caja neg ra 2745.7.3 Pru eba s de caja tra nsp are nte 2795.7.4 Estimación de erro res no dete ctad os 284

5.8 Estrateg ias de integrac ión 2855.8.1 Integración Big Bang 2865.8.2 Integrac ión de sce nd en te 2865.8.3 Integrac ión asc end ente 287

5.9 Pru eba s de sistema 2895.9.1 Ob jetivos de las pru eb as 2895.9.2 Pru eb as alfa y beta 290

Tema 6Autom atización del Pr ocesod e Desar r ollo 293

6.1 Entorno s de desarrollo softw are 2936.2 Pan orám ica de las técnicas CASE 294



vni Introducción a la Ingeniería de Software

6.2.1 Sop orte de las fases de de sarro llo 2946.2.2 Form as de organ ización 2956.2.3 Objetivo de un ento rno de desarro llo 296

6.3 Un a clasificación prag má tica 2976.3.1 En torno s asociado s a un leng uaje 2976.3.2 En torno s orien tado s a estru ctura 3006.3.3 En torno s bas ado s en herra m ienta s 3016.3.4 Ento rnos asociad os a me todo logía 3036.3.5 Entornos de 4 a generación 305

6.4 Un a clasificación po r nive les 3056.5 Herram ientas de sof tw are 307

6.5.1 H err am ien tas clásicas 3076.5.2 He rram ient as evolu cion adas 3086.5.3 Herramientas de 4 a generación 311

6.6 Ento rnos integ rado s 3126.6.1 Integ ración de da tos 3126.6.2 Integ ración del con trol 3136.6.3 Integración de la presen tación 3146.6.4 Integ ración del pro ceso 3146.6.5 El rep osi torio CASE 315

6.7 Bancos o equ ipo s de trabaj o 316

6.8 En torno s orien tado s al proceso 319

Bibliografía 323

Glosar io d e Acrónimos 329

í ndice 331



Tema 1Introducción

Este Tema se dedica a introducir una serie de conceptos básicos en elcampo de la ingeniería de software, con objeto de disponer de unabase inicial para las explicaciones que se irán dando en los restantes

capítulos del libro. Aunque se presuponen en el lector algunosconocimientos de programación, se realiza un esfuerzo para facilitarla lectura por quienes no tengan conocimientos específicos en esecampo.

1.1 Concepto de Ingenier ía de Sis temas

La ingeniería de sistemas es un marco general dentro del cual se puedensituar, con sus características propias, las disciplinas de ingeniería

particulares. La ingeniería de sistemas los estudia desde un punto de vistageneral y global, prescindiendo en parte de su naturaleza concreta; por ellosus técnicas propias son distintas de las técnicas de cada ingenieríaparticular.

Las siguientes secciones analizan el concepto de sistema y las actividadesde la ingeniería de sistemas. Por supuesto, el abordar la ingeniería desistemas como parte de este libro tiene como finalidad establecer el marcogeneral dentro del cual se habrán de estudiar como técnicas particulares deingeniería las correspondientes a la concepción, desarrollo y explotación desistemas informáticos. Por ello se estudian las características propias de

estos sistemas, y la naturaleza de los elementos que los componen.

1.1.1 Concepto de sistema

Consultando el diccionario encontramos:

Sistema, (del latín systema, y éste del griego ovozfjja) ... Conjuntode cosas que ordenadamente relacionadas entre sí contribuyen adeterminado objeto ...



4 Introducción a la Ingeniería de Software

El concepto de sistema es fundamental en los campos científico y técnico.En ingeniería se atiende fundamentalmente a los sistemas artificiales,creados por el hombre. Estos sistemas, cada vez más complejos, hanpermitido ir dominando progresivamente nuestro entorno natural, que cadavez v a siendo más adaptad o a la comod idad hu mana, en detrimento de suscaracterísticas naturales espontáneas.

La creación de sistemas complejos exige un trabajo colectivo, y por tantouna labor de organización, si se quiere realizar en forma eficaz. Laingeniería de sistemas atiende a los aspectos de organización de estossistemas, tanto en lo referente al sistema en sí como al proceso de su

desarrollo. Por ejemplo, para contruir un puente los ingenieros de obraspúblicas deben elegir sus elementos componentes: pilares, plataforma,tirantes, etc., y también decidir en qué forma se irán construyendo yensamblando dichas partes: primero la cimentación, luego los pilares, etc.

El concepto de sistema puede ser considerado en forma recursiva. Laspartes de un sistema pueden, en ciertos casos, ser consideradas comosistemas más sencillos o subsistemas, compuestos a su vez, de partes mássencillas.

1.1.2 S istem as basados en computador

Los sistemas que ha de concebir y construir el ingeniero en informática sonsistemas basados en computadores. Estos sistemas contienen uno o máscomputadores dedicados a tareas de control del conjunto. Entre ellospodemos citar los satélites artificiales y naves espaciales, los modernosaviones, las fábricas de montaje automatizadas con robots, y cada vez conmayor frecuencia sistemas más cercanos a nuestra vida cotidiana tales comoautomóviles o aparatos electrodomésticos. Algunos de estos sistemas sólopueden ser desarrollados por equipos multidisciplinares, a base dedescomponer el sistema completo en subsistemas separados, desarrollados

por especialistas en campos diferentes.

En lo que sigue atenderemos fundamentalmente a sistemas informáticoscompuestos exclusivamente por computadores y sus elementos periféricosconvencionales. En sistemas más complejos siempre podremos delimitar,como subsistemas, conjuntos de sus elementos puramente informáticos.Dentro de un sistema informático podremos distinguir los elementosmateriales, que constituyen el hardware del sistema, de los programas quegobiernan el funcionamiento del computador, y que constituyen el softwaredel mismo.



Introducción 5

1.1.3 Componentes hardw are, so f tw are y humanos

Los sistemas informáticos realizan tareas de tratamiento de la información.Estas tareas consisten fundamentalmente en almacenamiento, elaboracióny presentación de datos.

Cuando se concibe un sistema informático para automatizar determinadasacciones se presentan varias posibilidades para la realización de cadaoperación concreta de tratamiento de información:

1 - La operación puede ser realizada directamente por algún elemento

físico (hardware) del sistema.

2 - La operación puede ser prog ram ada , desarrolland o el progra ma(software) apropiado.

3 - La operación se realiza man ualmente por el usuario del sistema.

Estas tres opciones se derivan del reconocimiento de las diferentes clases deelementos que intervienen en un sistema inform ático utilizado por p ersonas:los componentes hardware, los componentes software, y los usuarioshumanos del sistema.

La última opción puede resultar algo chocante, ya que las personas no sonrealmente parte del sistema artificial que es objeto de la labor de ingeniería.Sin embargo, la visión de sistema requiere incluir la actividad humana delos usuarios, ya que en la concepción del sistema informático no sólo sedecide el trabajo a realizar por el computador, sino también cómo ha de serusado por las personas que operan dicho sistema.

La concepción de un sistema informático en forma global, que es laactividad de la ingenería de sistemas basados en computadores, consiste,por tanto, en decidir qué elementos hardware se utilizarán, qué elementossoftware han de ser adquiridos o desarrollados, y qué personas se necesitanpara operar el sistema y, al mismo tiempo, repartir y asignar las actividadesde tratamiento de información entre estos diferentes "elementos"componentes.

1.2 Caracter ís t icas del sof tware

Tradicionalmente se vienen clasificando los elementos componentes de unsistema informático en dos grandes grupos: el hardware y el software. Loscomponentes hardware, o equipos físicos, se identifican con relativa




facilidad. El software, sin embargo, es algo más difícil de caracterizar, y aveces se define por exclusión: es software todo lo que no es hardware. Elsoftware incluye, por supuesto, los programas que gobiernan elfuncion am iento del com putad or, pero también incluye otros elementos talescomo documentos, bases de datos, o incluso algo tan inmaterial como sonlos procedimientos de operación o de mantenimiento periódico.

El software presenta diferencias importantes respecto al hardware, queafectan profundamente a las actividades de ingeniería de uno y de otro.Comenzaremos por analizar las actividades típicas de la ingeniería deproductos hardware, que forman parte de la cultura general del hombre de

la calle. Pensemos, por ejemplo, en la ingeniería de automóviles, que sonproductos bien conocidos.

Los componentes hardware se obtienen mediante un proceso de fabricaciónen que se obtienen sucesivas copias de un producto patrón diseñadopreviamente. Esta operación de fabricación es costosa, y conlleva unconsumo significativo de energía, materiales y mano de obra. La operaciónde diseño previo del producto también es costosa, pero su costo repercutesólo parcialmente en cada unidad de producto fabricado.

Por otra parte, la utilización de un elemento hardware implica un procesode desgaste o envejecimiento que exige reparaciones ocasionales operiódicas para garantizar un servicio aceptable.

La ingeniería de software, sin embargo, presenta características especiales.El proceso de fabricación, consistente en obtener copias sucesivas delproducto, es trivial y se puede realizar a un costo muy bajo. La laborimportante es la del desarrollo inicial, de manera que el costo total defabricar miles de unidades de un producto software es similar al de fabricaruna sola.

Ade m ás, el software no se desgasta. Un program a funcionará al cabo de losaños con la misma corrección con que lo hizo el primer día sin necesidadde modificación ninguna. Las tareas de mantenimiento de software son enrealidad tareas adicionales de desarrollo, realizadas ocasionalmente durantela vida útil del producto con objeto de mejorarlo.

1.3 Concepto de In genier ía de S of tw are

El término Ingeniería de Software aparece utilizado inicialmente de maneraformal con ocasión de un congreso de la OTAN [Buxton76] a finales de los



Introducción 7

años 60, aunque hay evidencia de que se venía empleando informalmente

en los años anteriores. Con esta denominación se designa el empleo en eldesarrollo de productos software de técnicas y procedimientos típicos de laingeniería en general.

La ingeniería de software amplía la visión del desarrollo de software comouna actividad esencialmente de programación, contemplando además otrasactividades de análisis y diseño previos, y de integración y verificacionesposteriores. La distribución de todas estas actividades a lo largo del tiempoconstituye lo que se ha dado en llamar "ciclo de vida" del desarrollo desoftware.

1.3.1 Perspectiva histórica

En las décadas iniciales de existencia de la informática, la labor dedesarrollo de software se planteaba como una actividad artesanal, basadaen la labor de personas habilidosas y más o menos creativas, que actuabanen forma individual y relativamente poco disciplinada.

Al aumentar la capacidad de los computadores gracias a los avances delhardware, aumenta también la complejidad de las aplicaciones a programar,y se aprecia la necesidad de una mejor organización de la producción de

software, basada en el trabajo en equipo, con la consiguiente división yorganización del trabajo, y el empleo de herramientas apropiadas queautomaticen las labores triviales y repetitivas.

La organización del proceso de desarrollo de software da lugar a laaparición de metodologías de desarrollo específicas, recomendadas pordive rsos especialistas en áreas de aplicación m as o menos especializadas. Enparticular aparecen muchas metodologías particulares para el desarrollo delos l lamado s sistemas de información, que constituyen la inmensa mayoríade los desarrollos informáticos.

Estas metodologías se desarrollan a lo largo de los años 70, pero sóloempiezan a aplicarse ampliamente en los años 80, gracias a la aparición deherramientas de soporte apropiadas, deno minadas en general herramientasCASE (Computer Aided Software Engineering).

Las herramientas CASE tradicionales apoyaban las actividadesinmediatamente anteriores a la programación o codificación, para la que seseguían empleando herramientas tradicionales (compilador, etc.) quefuncionaban en forma totalmente separada de la herramienta CASE. En losaños 90 se amplía el campo de aplicación de las herramientas de ingeniería



8 Introducción a la Ingeniería de Softwa re

de software, reconociendo la necesidad de automatizar aún más la labor de

desarrollo medíante la formalización del proceso completo de producciónde software y el empleo de herramientas que soporten todo el ciclo de vidade desarrollo. Estas herramientas se de signan con las siglas IPSE (IntegratedProject Support Environment) o, más recientemente, ICASE (IntegratedCASE) .

1.3.2 t a cris is del softw are

Una situación de crisis representa un punto importante de evolución. Unacrisis se resuelve, para bien o para mal, mediante fuertes cambios.

La crisis del software corresponde a la situación, indicada en la secciónanterior, en que los avances en la capacidad de los equipos hardware diólugar a la necesidad de desarrollar aplicaciones software demasiadocomp lejas para ser llevad as a cabo con las técnicas artesanales del m omento.Esta situación aparece con claridad a mediados de la década de los 60.

La evolución forzada por esta crisis se traduce, como ya se ha indicado, enla aparición de metodologías concretas de desarrollo y, en general, en laconcepción de la ingeniería de software como disciplina.

Sin emba rgo la crisis del softw are se ha diferenciado de lo que n ormalme ntese entiende por crisis en que esta evolución no ha dado lugar a unaposterior situación estable, ni siquiera a corto plazo. En lugar de ello nosencontramos con que la evolución del hardware continúa a un fuerte ritmo,abaratando el costo de los equipos informáticos al tiempo que aumenta sucapacidad, y forzando un incremento continuo en la complejidad de lasaplicaciones software. Con ello se mantiene la situación de crisis que sehabía producido, y que continúa hasta nuestros días.

Lo qu e nos encontramos, m ás que una crisis tradicional, es una situación defuerte evolución permanente, con avances continuos en las técnicas de

ingeniería de software que resultan sin embargo insuficientes en cadamomento. De hecho se discute si el término ingeniería de software esrealmente válido, ya que una disciplina de ingeniería se caracteriza, engeneral, por haber alcanzado una cierta madurez en las técnicas a aplicar,basadas en un fundamento científico subyacente y no sólo en unpragmatismo artesanal.



Introducción 9

13 .3 M itos del sof tware

El continuo proceso de evolución en las disciplinas de desarrollo desoftw are, junto con algun as de sus características particulares, tales comouna relativa inmaterialidad, hacen difícil obtener una visión serena y justade la ingeniería de software, provocando que por parte de los usuarios eincluso de algunos profesionales se mantengan opiniones infundadas sobrela importancia o influencia de determinados factores en el éxito o calidadde un producto software.

Algunas de estas opiniones, relativamente generalizadas, constituyenverdaderos mitos, difíciles de erradicar. Podemos mencionar, por ejemplo,

las siguientes:

El hardware es mucho más importante que el software:Manifiestamente falso, ya que al usar un computador nuestrainteracción es fundamentalmente con el software, y sólo de unamanera muy limitada el usuario accede directamente a elementoshardware del equipo. Este menosprecio por el software se evidenciaen quienes consideran que la realización de copias "pirata" o ilegalesde los programas no es una acción censurable.

El software es fácil de desarrollar. Esto es falso para cualquieraplicación software de cierta importancia. El desarrollo de grandessistemas es muy complejo y costoso, incluso aunque esos sistemas noempleen ningún material o hardware específico. De hecho eldesarrollo de software exige una mayor proporción de mano de obra,frente al empleo de maquinaria, y por ello el progresivo aumento delcosto de la mano de obra en los países desarrollados ha llevado a uncrecimiento importante en el coste de los productos software.

El software consiste exclusivamente en programas ejecutables: Elsoftware 110 se define de esta manera. Al concebir un sistema

informático de manera global hay que pensar en todos los elementosque intervienen: hardware, software y personas. Los procedimientosque han de seguir esas personas para usar correctamente el sistemason también elementos software. Igualmente es software toda ladocumentación del desarrollo, necesaria para poder mantener elproducto después de haber sido puesto en explotación.

• El desarrollo de software es sólo una labor de programación: Falso,pues no se puede limitar el trabajo de desarrollo sólo a la fase decodificación. Las tareas de análisis y diseño no son meras actividades




complementarias que puedan ser vistas como un costo añadido,necesario para organizar el trabajo en equipo. Las tareas de análisisy diseño son el fundamento para todo el resto del desarrollo, igualque el proyecto de un arquitecto o de un ingeniero es necesario paraacometer la construcción de un edificio u otra obra pública, que noconsiste simplemente en colocar materiales uno sobre otro.

Es natural que el software contenga errores: No exactamente.Aunque es cierto que el desarrollo de software, como toda actividadhumana, es susceptible de errores, no es admisible que los productossoftware siempre contengan errores. Si un producto hardware

contiene defectos, se rechaza. Con el software debería ocurrir lomismo. Por desgracia el software erróneo no puede simplementesustituirse por otro sin defecto, ya que todas las copias del productosoftware son exactamente iguales. Los errores del software sonerrores durante su desarrollo inicial, y deben reducirse a un nivel tanbajo como en el diseño de los productos hardware durante la fase dedesarrollo de ingeniería.

1.4 Formal¡zacion del pro ces o de desarroll o

Una característica ele la ingeniería es la existencia de procedimientos bienestablecidos para la realización de las actividades de desarrollo,construcción, fabricación, etc. A continuación se expone cómo se planteanesos procedimientos en el caso de la ingeniería del software.

1.4.1 £1 ciclo de vida del sof tw are . Modelos clásicos

Uno de los primeros logros de la ingeniería del software ha sido identificarde manera precisa la forma que adopta el proceso de desarrollo del

softw are. Este proceso de desarrollo, incluyendo el mantenimiento necesariodurante su explotación, se ha dado en llamar ciclo de vida del software.

Los modelos clásicos de ciclo de vida plantean el desarrollo y explotaciónde una aplicación software como una secuencia de actividades sucesivas ydiferentes que se van realizando una tras otra. Dos formas bien establecidasde plantear el proceso de desarrollo son:

• El modelo en cascada• El modelo en V



Introducción 11

Ambos modelos identifican actividades similares, y prácticamente sólo sediferencian en la forma de presentación de las mismas.

1.4.1.1 El modelo en cas cad a

Este es el modelo más primitivo de ciclo de vida, pero que ha resultadofundamental para progresos posteriores, porque en él se identifican yaprácticamente todas las clases de actividades distintas que intervienen enel desarrollo y explotación de software.

En la Figura 1.1 aparece una representación gráfica de este modelo. Seidentifican distintas actividades o fases que han de realizarse precisamenteen el orden indicado, de manera que el resultado de una de estas fases esel elemento de entrada para la fase siguiente.

Análisis Documento de requisitosJk .

Diseno Documento de diseño

Codificación Código fuente

Integración Sistema en explotación

Mantenimiento

F igura 1.1. Ciclo de vida en cascada

Existen diferentes variantes de este modelo, que se diferencian en elreconocimiento o no como fases separadas de ciertas actividades, de maneraque lo que en una variante se plantea globalmente como una sola fase, enotra puede desglosarse en una secuencia de dos o tres fases consecutivas.En la Figura 1.1 se han representado las fases siguientes:



12 Introducc ión a la Ingenier ía de Softwa re

1) A N Á L I S I S ; Consiste en analizar las necesidades de los usuariospotenciales del software para determinar qué debe hacer el sistemaa desarrollar, y de acuerdo con ello escribir una especificación precisade dicho sistema.

2) D ISEÑO : Consiste en descomponer y organizar el sistema enelementos componentes que puedan ser desarrollados por separado,para aprovechar las ventajas de la división del trabajo y poder hacerel desarrollo en equipo. El resultado del diseño es la colección deespecificaciones de cada elernenio componente.

3 ) C O D I F I C A C I Ó N : En esta fase se programa cada elemento componentepor separado, es decir, se escribe el código fuente de cada uno.Normalmente se harán también algunas pruebas o ensayos paragarantizar en lo posible que dicho código funciona correctamente.

4) INTEGRACIÓN: A con tin ua ción hay qu e ir co m bin an do tod os lose l e m e n t o s c o m po n e n t e s d e l s i s t e m a , y pr o b a r e l s i s t e m a c o m pl e t o .H a b r a q u e h a c e r pr u e b a s e x h a u s t i v a s pa r a g a r a n t i z a r e lfunc ionamiento correc to de l con junto , antes de ser puesto ene x pl o t a c i ó n .

5) M A N T E N I M I E N T O : Durante la explotación del sistema software esnecesario realizar cambios ocasionales, bien para corregir errores nodetectados con anterioridad, o bien para introducir mejoras. Para ellohay que rehacer parte de los trabajos anteriores.

El modelo de ciclo de vida en cascada trata de aislar cada fase de lasiguiente, de manera que las fases sucesivas puedan ser realizadas porgru po s de person as diferentes, facilitando la especialización. De esta m anerapodemos encontrar perfiles profesionales diferentes, tales como analista,diseñador, programador, etc.

Para conseguir esta relativa independencia es fundamental que en cada fasese genere una información de salida precisa y suficiente para que otraspersonas puedan acometer la fase siguiente. Se insiste así en la necesidadde establecer unos modelos de documentación apropiados. En general sesuelen exigir los documentos siguientes:

A) D O C U M E N T O D E R E Q U I S I T O S D E L S O F T W A R E (en inglés S R D : SoftwareRequirements Document): como producto de la fase de análisis.Consiste en una especificación precisa y completa de lo que debe

hacer el sistema, prescindiendo de los detalles internos.



Introducción 13

B ) D O C U M E N T O D E D I S EÑ O D E L S O F T W A R E (en inglés S D D : SoftwareDesign Document): como producto de la fase de diseño. Consiste enuna descripción de la estructura global del sistema, y laespecificación de qué debe hacer cada una de sus partes y cómo secombinan unas con otras.

C) CÓDIGO FUENTE: co m o pr od uct o de la fase de cod if icació n. C on tien el o s pr o g r a m a s f u e n t e , e n e l l e n g u a j e d e pr o g r a m a c i ó n e l e g i d o , yd e b i d a m e n t e c o m e n t a d o s pa r a c o n s e g u i r q u e s e e n t i e n d a n c o nc l a r i d a d .

D) E L S I S T E M A S O F T W A R E , ejecutable: como producto de la fase deintegración. Deben documentarse también las pruebas realizadassobre el sistema completo.

E ) D O C U M E N T O S D E C A M B IO S : tras cada modificación realizada duranteel mantenimiento. Los documentos de cambios suelen recopilarinformación de cada problema detectado, descripción de la soluciónadoptada, y las modificaciones realizadas sobre el sistema paraaplicar dicha solucion.

El modelo en cascada hace énfasis también en la necesidad de terminar

correctamente cada fase antes de comenzar la siguiente. Esto se debe a quelos errores producidos en una fase son muy costosos de corregir si ya se harealizado el trabajo de las fases siguientes.

Para detectar los errores lo antes posible, y evitar que se propaguen a fasesposteriores, se establece un proceso de revisión al completar ca da fase, antesde pasar a la siguiente. Esta revisión se realiza fundamentalmente sobre ladocumentación producida en esa fase, y se hace de una manera formal,siguiendo una lista de comprobaciones establecida de antemano. Si, a pesarde todo, durante la realización de una fase se detectan errores en el

resultado de fases anteriores, será necesario rehacer parte del trabajovolviendo a un punto anterior del ciclo de vida, como se indica con líneadiscontinua en la Figura 1.1.

Como se ha indicado, existen variantes en cuanto a la colección particularde actividades que componen el proceso en cascada. En la Figura 1.2 serepresenta una variante ampliada de este modelo de ciclo de vida. Estemodelo se utilizá en el desarrollo de grandes sistemas que necesitantambién una ingeniería de sistemas previa, un diseño arquitectónico, unaspruebas para cada unidad y las pruebas del sistema completo.




ingenieríade sistemas Especificación del sistema

yrAnálisis

Especificación de! software

Diseño

arquitectónico Documento de arquitectura del sistema

Diseñodetallado Especificaciones de módulos y funciones

Codificación

Código fuenteJk.

Pruebas deunidades Módu los util izables

ják.

Integración

Sistema util izable

Pruebas de

sistema Sistema aceptado

Explotación ymantenimiento

F igura 1.2. Mo delo en cascada, ampliado

1.4.1.2 El modelo en V

Este modelo se basa en una secuencia de fases análoga a la del modelo en

cascada, pero se da especial importancia a la visión jerarquizada que se vateniendo de las distintas partes del sistema a medida que se avanza en eldesarrollo. En la Figura 1,3 se recoge esta idea en un diagramabidimensional. en que el eje horizontal representa avance en el desarrolloy el eje vertical corresponde al nivel de detalle con que se trabaja en cadafase.

En este diagrama vernos como en las fases iniciales, en la rama izquierdadescendente, el sistema software se va descomponiendo en elementos cadavez más sencillos, hasta llegar a las sentencias del lenguaje de



Introducción 15

Mundo real AAnálisis

4Explotación

Jk . SistemaValidación ^ ^

NIVEL

Módulo

Sentencia

Diseño Integración

Verjt^ y

Codificación

DESARROLLO ^

F igura 1.3. Mo delo en V del ciclo de vida

programación, A partir de ahí el sistema se va construyendo poco a pccoa base de integrar los elementos que lo componen, siguiendo la ra:naderecha ascendente, hasta disponer del sistema completo listo para >erusado.

Al igual que en el modelo en cascada, existen diversas variantes del mod l̂oen V, que se caracterizan por reconocer o no determinados niveles dedetalle intermedios. El diagrama de la Figura 1.3 corresponde a un modelosimplificado, similar al modelo en cascada, también simplificado, de laFigura 1 . 1 .

En las actividades situadas en un nivel determinado se trabaja sobre unaunida d del nivel de detalle superior, que se organiza en varias unida des leínivel de detalle inferior. Por ejemplo, durante la codificación se trabaja c mun módulo, que se organiza y construye con sentencias del lenguaje.

Durante las fases de diseño y de integración se trabaja con un sistemasoftware, que se organiza (durante el diseño) o se construye (durante laintegración) con varios módulos.

En el diagrama en V se puede poner de manifiesto de manera elegante cueel resultado de una fase no sólo sirve com o entrada para la f seinmediatam ente siguiente, sino que tam bién debe utilizarse en fa esposteriores para comprobar que el desarrollo es correcto. En particular lacomp robación de que una parte del sistema cu mp le con sus especiflcacior.esparticulares se denomina verificación, y en el diag ram a sim plificado de la



16 Introduc ción a la Ingeniería de Softwa re

f igura 1 .3 aparece a nivel de módulo. La comprobación de que un elemento

satisface las necesidades del usuaiio identificadas durante el análisis sedenomina validación, y en el diagra ma aparece a nivel del sistemacompleto.

Al igual que en el modelo en cascada, se pueden establecer modelos deciclo en V más elaborados, con un mayor número de fases. En la Eigura 1.4se representa una variante ampliada de este modelo.

Mundo reai

Análisis de Explotaciónnecesidades Validación del sistema * mantenim.

Ámbito de aphc.

Análisis del Pruebas de

s o f t w a r e Verificación del sistema aceptación

Sistema <4K •

Diseño de la Integraciónarquitectura Verificación de subsistemas del sistema

Subsistema

Diseño Integracióndetallado Verif. módulos subsistemas

Moduio\ •

Codificación Prue bas deunidades

Sentencia <

Figura 1.4. Mo delo en V, ampliado

1.5 Uso de prototipo s

Los modelos clásicos tienen el inconveniente de estar muy orientados haciauna forma de desarrollo lineal, en que cada fase del desarrollo tiene unaduración limitada en el tiempo, de forma que una vez terminada una fasepueden dedicarse a otra cosa los recursos humanos o materiales que se hanempleado en ella. Esto quiere decir que no se contemplan de maneraorganizada las vueltas airas necesarias ocasionalmente al detectar algoinadecuado en una tase anterior durante una fase posterior del desarrollo.



Introducción 17

Estas vueltas atrás resultan así bastante costosas, por lo que los modelosclásicos insisten mucho en las actividades de ievisión del resultado de cadafase, para evitar los retrocesos, en lo posible,

Desgraciadamente hay situaciones en que no es posible garantizaradecuadamente al concluir una fase que su resultado es correcto. Estoocurre, por ejemplo, en sistemas innovadores, en que rio se dispone de unaexperiencia previa para contrastar sí las decisiones adoptadas durante elanálisis y diseño son apropiadas.

El empleo de prototipos puede solucionar, ai menos en parte, este

problema. Un prototipo es un sistema auxiliar que permite probarexperimentalmen te ciertas soluciones parciales a las necesidades del usuarioo a los requisitos del sistema. Si el prototipo se desarrolla con un costosensiblemente inferior al del sistema final, los errores cometidos en elmismo no resultarán dem asiado costosos, ya que su incidencia está limitadapor el costo total del desarrollo de dicho propotipo, y normalmente seráinferior, ya que siempre h abrá algo del prototipo que sea aprovech able parael resto del desarrollo.

Para reducir el costo del desarrollo del prototipo, con respecto al delsistema final, se puede:

• Limitar las funciones, y desarrollar sólo unas pocas• Limitar su capacidad , permitiendo que sólo se procesen unos pocos

datos• Limitar su eficiencia, perm itiendo que opere en form a lenta• Evitar limitaciones de diseño usand o un soporte hard wa re más

potente• Reducir la parte a desarrollar, usan do un ap oyo soft wa re más

potente

Normalmente se distinguen dos clases de prototipos, según se pretendaaprovechar el código del mismo, o sólo la experiencia obtenida con él, talcomo se indica a continuación.

1.5.1 Prototipos rápidos

Estos prototipos son aquellos cuy a fina lidad es sólo adqu irir experiencia, sinpretender aprovecharlos como producto. Se denominan también prototiposde usar y tirar (en inglés throw-away), y maquetas (en inglés mockup)cuando su funcionalidad o capacidad es muy l imitada.




F igura 1.5. Aná lisis con pro to tipo rápido

Estos prototipos se aprovechan dentro de las fases de análisis y/o diseñode un sistema, para experimentar algunas alternativas y garantizar en loposible que las decisiones tomad as son correctas. Una ve z completad as estasfases el sistema final se codifica totalmente partiendo de cero, es decir, sin

aprovechar el código del prototipo. La Figura 1.5 representa una variantedel ciclo de vida en cascada usando un prototipo de usar y tirar durante lafase de análisis.

Lo imp ortante en estos prototipos es desarrollarlos en poco tiempo, y de ahíel nombre de prototipos rápidos, para evitar alargar excesivamente laduración de las fases de análisis y diseño. Hay que tener en cuenta que eldesarrollo com pleto y experim entación con el prototipo o prototipos es sólouna parte de alguna fase del ciclo de vida del sistema final.



Introducción 19

15 .2 Prototipos evolutivos

Otra manera de utilizar un prototipo es tratando de aprovechar al máximosu código. En este caso el prototipo se desarrollará sobre el mismo soportehardware/software que el sistema final , pero sólo realizará algunas de lasfunciones, o en general, será sólo una realización parcial del sistemadeseado.

El prototipo inicial se construirá tras unas fases parciales de análisis ydiseño. La experimentación con el prototipo permitirá avanzar en esas fasesparciales, y a continuación ampliar el prototipo inicial para irlo convirtiendo

en el sistema final mediante adiciones sucesivas.

F igura 1.6. Mo delo de ciclo de vida evo lutivo

De esta manera se van construyendo sucesivas versiones del prototipo, cada

vez más completas, hasta obtener el sistema deseado. Al mismo tiempo losdocum entos de especificación, diseño, etc. van sien do también desarrollado sprogresivamente.

Esta forma de desarrollo pued e formalizarse en un modelo de ciclo de vidaevolutivo, tal como el que se representa en la Figu ra 1.6. Este modelo p uedeconsiderarse como un proceso iterativo en bucle sobre el modelo encascada, de manera que en cada iteración se hace sólo una parte deldesarrollo, avanzando un poco en cada fase. Cada iteración utiliza todo loque se ha generado en la iteración anterior, y produce un nuevo prototipo,

que es una nueva versión parcial del sistema, hasta llegar finalmente al




sistema completo, con lo que se sale del bucle de iteraciones y termina el

proceso.

1.5.3 Herram ientas para realización de prototipos

Puesto que un prototipo es una versión particular del sistema software adesarrollar, se podrán usar para su construcción herramientas similares alas que se usen en cualquier desarrollo de software. Evidentemente, si setrata de un prototipo evolu tivo habrá que usar, en general, las herram ientasque se seguirán empleando hasta el sistema definitivo.

En el caso de los prototipos de usar y tirar se podrán emplear herramientasdiferentes que para el sistema definitivo. En especial se buscaránherram ientas qu e perm itan construir el prototipo en poco tiempo, si se tratade un prototipo rápido, y en todo caso herramientas que permitan hacerlocon el mínimo esfuerzo, para reducir el costo total del desarrollo.

Entre las herramientas que suelen recomendarse para la construcción deprototipos están las denominadas de 4a generación. Estas herramientas sonespecialmende adecuadas para la construcción de sistemas de información,que se apoyan en una base de datos de uso general, y utilizan lenguajes

especializados para programar la interfaz de usuario, basada en menús,formularios de entrada de datos, y formatos de informes.

Estas herramientas se utilizan muchas veces en la construcción del sistemafinal, ya que facilitan mucho el trabajo de desarrollo. Si no fuesenseleccionadas para ello por razones de eficiencia o compatibilidad, siemprepodrán ser empleadas en la construcción de un prototipo previo, si seconsidera apropiado.

Los lenguajes de 4a generación son simplemente un caso particular delenguajes de muy alto nivel, que normalmente siguen un estilo declarativo

en lugar de operacional. Los lenguajes declarativos permiten describir elresultado que se desea obtener, en lugar de describir las operaciones paraconseguirlo. Los lenguajes de muy alto nivel y sus herramientas asociadasresultarán también apropiadas para el desarrollo de prototipos rápidos. Eneste sentido se ha recomendado a veces el empleo de lenguajes tales comoProlog o SmallTalk.

Análogos a los lenguajes de muy alto nivel son los lenguajes deespecificación. Estos lenguajes tienen como objetivo formalizar laespecificación de los requisitos de un sistema software, y entre ellos hay



Introducción 21

algunos de uso bastante extendido, como VDM y Z. Si especificamos unaaplicación con uno de estos lenguajes, y disponemos de un compilador ogenerador de programas para dicho lenguaje, podremos obtenerdirectamente un prototipo ejecutable.

Otra técnica adecu ada para la construcción de prototipo s es el uso extensivode la reutilización de software. Combinando varios módulos o subsistemasescritos de antemano pod rem os construir en poco tiempo un sistema n uevo.Si la colección de software disponible es extensa o especializada en nuestrocampo de aplicación, no será difícil encontrar un repertorio de componen tesque nos permitan construir con poco esfuerzo un sistema similar al desead o.

1.6 El modelo en espiral

El modelo espiral desarrollado por B. Boehm [Boehm88] puede considerarsecomo un refinamiento del modelo evolutivo general. Como elementodistintivo respecto a otros modelos de ciclo de vida, introduce la actividadde análisis de riesgo como elemento fundamental para guiar la evolucióndel proceso de desarrollo.

El ciclo de iteración del modelo evolutivo se convierte en una espiral alañadir como dimensión radial una indicación del esfuerzo total realizadohasta cada momento, que será un valor siempre creciente, tal como seindica en la Figura 1.7. Las distintas actividades se representan sobre unosejes cartesianos, conteniendo cada cuadrante una clase particular deactividades: P L A N I F I C A C I Ó N , A N Á L I S I S D E R I E S G O , I N G E N I E R Í A y E V A L U A C I Ó N ,

que se suceden a lo largo de cada ciclo de la espiral. La dimensión angularrepresenta el avance relativo en el desarrollo de las actividades de cadacuadrante. En cada ciclo de la espiral se realiza una parte del desarrollototal, siguiendo la secuencia de las cuatro clases de actividades indicadas.

Las actividades de planificación sirven para establecer el contexto deldesarrollo, y decidir qué parte del mismo se abordará en ese ciclo de laespiral.

Las actividades de análisis de riesgo consisten en evaluar diferentesalternativas para la realización de la parte del desarrollo elegida,seleccionando la más ventajosa y tomando precauciones para evitar losinconvenientes previstos.




VersionessucesivasdeI sistema

F igura 1,7. M odelo en es piral del ciclo de vida

Las actividades de ingeniería corresponden a las indicadas en los modelosclásicos: análisis, diseño, codificación, etc. Su resultado será ir obteniendoen cada ciclo una versión más completa del sistema.

Las actividades de evaluación analizan los resultados de la fase deingeniería, habitualmente con la colaboración del "cliente" para quien serealiza el desarrollo. El resultado de esta evaluación se utiliza comoinformación de entrada para la planificación del ciclo siguiente.

Según qué parte del desarrollo se decida hacer en cada ciclo, tendremosdistintas variantes del modelo espiral, que podrá así adaptarse a cadaproyecto concreto. Por ejemplo, si en cada vuelta se realizase exactamenteuna de las fases del modelo en cascada, el modelo espiral coincidiría condicho modelo en cascada en los aspectos de ingeniería. Si en cada vuelta serealiza lo suficiente de cada fase como para obtener una versión parcialampliada del sistema, el modelo espiral coincidirá con el evolutivo. De



Introducción 23

todas formas el modelo espiral siempre se distingue por las actividades deanálisis de riesgo, que no aparecen en los otros modelos.

1.7 Comb inación de mode los

Cada uno de los diferentes modelos de ciclo de vida presenta ventajas einconvenientes a la hora de aplicarlo, dependiendo de la clase de sistemaa desarrollar y el contexto en que se realiza el desarrollo. A veces puederesultar ventajoso tratar de aprovechar las ventajas de varios modelosdiferentes, combinándolos en un modelo mixto de ciclo de vida.

Un ejemplo concreto podría ser el siguiente:

1 - Se realiza la fase de análisis emplean do la técnica de prototiporápido.

2 - Se evalúa n modelos alternativos para el resto del desarrollo3 - Se realiza el resto del desarrollo según el mo delo elegido, que pod ría

ser:3.1 Mod elo en cascada3.2 Mod elo evolutivo

etc. ...

Es fácil darse cuenta de que el modelo espiral es de alguna manera unacombinación de modelos, ya que las actividades de ingeniería puedenrealizarse según cualquier otro modelo particular de ciclo de vida.

1.8 M antenimiento del so ft w are

Las actividades fundamentales del desarrollo de software, correspondientesa las fases de análisis, diseño, codificación y pruebas se describen con

detalle en los siguientes Tem as. La fa se de mantenimiento es algo particular,y se describe en este primer Tema. Esta etapa final denominadamantenimiento, o explotación y mantenimiento, no suele representar unaactividad específica, sino que consiste normalmente en repetir o rehacerparte de las actividades de las fases anteriores para introducir cambios enuna aplicación de software ya entregada al cliente y puesta en explotación.

A continuación se analiza con más detalle en qué consiste el proceso demantenimiento de una aplicación so ftwa re, y po rqué es necesario realizarlo,en lugar de seguir explotando la aplicación original tal como se desarrolló

la primera vez.




1.8.1 Evolución de los apli cacion es

Una de las características del software, que lo diferencian de los productoshardware, es la ausencia de deterioro o envejecimiento durante suutilización. U n sistema so ftw are func ionará con la m isma corrección al cabode los años que el primer día de su empleo. ¿Porqué es necesariomodificarlo?

Hay varios motivos para ello, que dan lugar a distintos tipos demantenimiento con diferentes objetivos, entre ellos:

• Mantenimiento correctivo• Mantenimiento adap tativo• Mantenim iento perfectivo

El mantenimiento correctivo tiene corno finalidad corregir errores en elproducto software que no han sido detectados y eliminados durante eldesarrollo inicial del mismo. Este tipo de mantenimiento no debería existirsi el desarrollo inicial se hubiera realizado con las debidas garantías decalidad. Sin embargo es prácticamente imposible evitarlo, ya que el

desarrollo de software, como cualquier otra actividad humana, está sujetoa errores.

El mantenimiento adaptativo se produce en aplicaciones cuya explotacióndura bastantes años, de manera que los elementos básicos hardware ysoftware (máquina + sistema operativo) que constituyen la plataforma oentorno en que se ejecutan evoluciona a lo largo de ese tiempo,modificándose parcialmente la interfaz ofrecida a las aplicaciones quecorren sobre ellos. Esto exige modificar una aplicación para adaptarla a lasnuevas características del entorno si se quiere seguir utilizándola.

Finalmente el mantenimiento perfectivo aparece sobre todo en aplicacionessujetas a la competencia de mercado. Este tipo de mantenimiento esnecesario para ir obteniendo versiones mejoradas del producto quepermitan mantener el éxito del mismo. También se realiza sobreaplicaciones en que las necesidades del usuario evolucionan, y por tantohay que modificar los requisitos iniciales del producto para seguirsatisfaciéndolas.



Introducción 25

1.8.2 be stión de cambios

Con independencia del objetivo concreto del mantenimiento, las activida desa realizar durante el mismo son básicamente la realización de cambiossucesivos sobre una determinada aplicación o producto software yadesarrollado. La aplicación de técnicas de ingeniería a la actividad demantenimiento exige organizar y gestionar apropiadamente el desarrollo deestos cambios.

Podríamos distinguir dos enfoques diferentes en la gestión de cambios,

dependiendo del mayor o menor grado de modificación del producto.

Si el cambio a realizar afecta a la ma yoría de los componentes del producto,dicho cambio se puede plantear como un nuevo desarrollo, y aplicar unnuevo ciclo de vida desde el principio, aunque aprovechando lo yadesarrollado igual que se aprovecha un prototipo.

Si el cambio afecta a una parte localizada del producto, entonces se puedeorganizar como simple modificación de algunos elementos. Es importantedarse cuenta de que un cambio en el código del producto software debe darlugar además a una revisión de los elementos de documentación afectados,es decir, cambiar el código de algunos módulos puede requerir ademásmo dificar los documentos de diseño o incluso, en el caso de mantenimientoperfectivo, modificar el documento de especificación de requisitos.

Desde el punto de vista de gestión la realización de cambios se puedecontrolar mediante dos clases de documentos, que a veces se refunden enuno solo:

• Informe de problema: describe una dificultad en la utilización delproducto que requiere alguna modificación para subsanarla.

• Informe de cambio: describe la solución dada a un problema y elcambio realizado en el producto software.

El informe de problema puede ser originado por los usuarios. Este informese pasa a un grupo de ingeniería para la comprobación y caracterización delproblema, y luego a un grupo de gestión para decidir la solución a adoptar.Este grupo de gestión inicia el informe de cambio, que se pasa de nuevo algrupo de ingeniería para su desarrollo y ejecución.




1.8.3 Reingeniería

Con mucha frecuencia, por desgracia, es necesario mantener productossoftware que no fueron desarrollados siguiendo las técnicas de ingenieríade software, sino de forma artesanal. En estos casos el desarrollo no sueleestar documentado, y se dispone solamente del código fuente, quizácomentado.

Para ayudar al mantenimiento de este tipo de aplicaciones se handesarrollados algunas técnicas particulares que tratan de subsanar estasdeficiencias de documentación. Estas técnicas se han denominadoinicialmente ingeniería inversa, y más modernamente reingeniería.

La ingeniería inversa consiste en tomar el código fuente y a partir de éltratar de construir, si es posible de manera automática, algunadocumentación, en particular documentación de diseño, con la estructuramodular de la aplicación y las dependencias entre módulos y funciones.Esto facilita la caracterización del ámbito de un posible cambio, es decir,determinar qué módulos y funciones habría que modificar.

Una documentación mecánica de la estructura del sistema software es

insuficiente para mantener aplicaciones complejas. La actividad dereingeniería se plantea como algo más general, que trata de generar unsistema bien organizado y documentado a partir del sistema inicialdeficiente. Este trabajo puede incluir el reconstruir manualmente ladocumen tación inexistente, y m odificar el código fuente para reestructurarlode manera más apropiada.

1.9 G arantía de cal idad de s of tw are

La calidad de un producto software, como cualquier otro producto deingeniería, viene determinada fundamentalmente por el proceso seguido ensu desarrollo. En el modelo de ciclo de vida encontramos actividadestípicamente productivas, tales como las de análisis, diseño y codificación,y otras cuyo objetivo es controlar la calidad del producto, tales como lasrevisiones y pruebas,

A continuación se analiza cómo se valora la calidad de un productosoftware, y cómo debe organizarse el proceso de desarrollo para garantizarun nivel de calidad adecuado.



Introducción 27

1.9.1 Factores de calidad

La calidad de un producto puede valorarse desde puntos de vista diversos.El software no es una excepción, y existen por tanto diferentes enfoquespara la valoración de su calidad.

Lo ideal sería poder medir la calidad del software como se miden ciertosaspectos de calidad de otros productos de ingeniería: pureza de unproducto, resistencia de un material, etc. Desgraciadamente ésto no resultafácil, y las técnicas de aplicación de métricas precisas a los productossoftware están todavía en evolución.

Existe un esquema general de mediciones de la calidad de softwarepropuesto por McCall y otros [McCall78J, basado en valoraciones a tresniveles diferentes, denominados factores, criterios y métricas. Los factoresde calidad constituyen el nivel superior, y son la valoración propiamentedicha, significativa, de la calidad. Esta valoración no se hace directamente,sino en función de ciertos criterios o aspectos de nivel intermedio queinfluyen en los factores de calidad. Las métricas están en el nivel inferior,son mediciones puntuales de determinados atributos o características delproducto, y son la base para evaluar los criterios intermedios.

Entre los factores de calidad propuestos encontramos los siguientes:

CORRECCIÓN: ES el grado en que un producto software cumple con susespec i f i cac iones . Podría es t imarse como e l porcenta je de requis i tosq u e s e c u m p l e n a d e c u a d a m e n t e .

FiABlLlDAD: ES el grado de ausencia de fal los durante la operación delpr o d u c t o s o f t wa r e . P u e d e e s t i m a r s e c o m o e l n ú m e r o d e f a l l o spr o d u c i d o s o e l t i e m po d u r a n t e e l q u e pe r m a n e c e i n u t i l i z a b l ed u r a n t e u n i n t e r v a l o d e o pe r a c i ó n d a d o .

EFICIENCIA: ES la relación entre la cantidad de resultados suministrados y

los recursos requer idos durante la operac ión. Se medir ía como lai n v e r s a d e l o s r e c u r s o s c o n s u m i d o s p a r a r e a l iz a r u n a o pe r a c i ó n d a d a .

SEGURIDAD: ES la dif icultad para el acceso a los datos o a las operacionespor parte de personal no autor izado .

FACILIDAD DE USO: ES la inversa del esfuerzo requerido para aprender ausar un producto software y utilizarlo adecuadamente.

M A N T E N I B IL I D A D : Es la facilidad para corregir el producto en caso necesario.Se aplica propiamente al mantenimiento correctivo.

F L E X I B I L I D A D : E S la facilidad para modificar el producto software. Se aplicapropiamente al mantenimiento adaptativo y al perfectivo.




F A C I L I D A D D E P R U E B A : E S la inversa del esfuerzo requerido para ensayar un

producto software y comprobar su corrección o habilidad.T R A N S P O R T A B I L I D A D : E S la facilidad para adaptar el producto software a una

plataforma (hardware + sistema operativo) diferente de aquella parala que se desarrolló inicialmente.

R E US AB I L ID AD : Es la facilidad para emplear partes del producto en otrosdesarrollos posteriores. Se facilita mediante una adecuadaorganización de los módulos y funciones durante el diseño.

I N T E R O P E R A T I V I D A D : E S la facilidad o capacidad del producto software paratrabajar en combinación con otros productos.

Estos factores de calidad se centran en características del producto so ftwa re.En muchos casos se contemplan también otros aspectos relativos al procesode desarrollo, ya que la organización de éste influye muy directamente enla calidad del producto obtenido.

1.9Z Plan de garantí a de calidad

Una adecuada calidad del producto es inalcanzable sin una buenaorganización del desarrollo. Ya se ha indicado anteriormente que lastécnicas de ingeniería de software tratan de formalizar el proceso de

desarrollo evitando los inconvenientes de una producción artesanalinformal.

Esta organización del proceso de desarrollo de software debe materializarseen un documento formal, denominado Plan de Garantía de Calidad deSoftware (en inglés SQAP: Software Quality Assurance Plan). El plan debecontemplar aspectos tales como:

Organización de los equipos de personas y la dirección yseguimiento del desarrollo.

Modelo de ciclo de vida a seguir, con detalle de sus fases yactividades.

Documentación requerida, especificando el contenido de cadadocumento y un guión del mismo.

• Revision es y auditorías que se llevarán a cabo durante el desarrollo,para garantizar que las actividades y documentos son correctos yaceptables.



Introducción 29

• Organización de las prueb as que se realizarán sobre el productosoftware a distintos niveles. A veces esta parte se redacta como unplan separado.

• Organización de la etapa de mantenimiento, especifican do cómo hade gestionarse la realización de cambios sobre el producto ya enexplotación.

1.9.3 Revisiones

Una revisión consiste en inspeccionar el resultado de una actividad paradeterminar si es aceptable o, por el contrario, contiene defectos que han deser subsanados. Las revisiones se aplican, fundamentalmente, a ladocumentación generada en cada etapa o fase del desarrollo.

De acuerdo con el espíritu de las reglas de ingeniería de software, lasrevisiones deben ser formalizadas. Esto quiere decir que deben estarcontempladas en el modelo de ciclo de vida y que debe existir unanormativa para su realización.

Parece interesante enunciar algunas recomendaciones concretas sobre cómoformalizar las revisiones, entre ellas las siguientes:

• Las revisiones deben ser realizadas por un gru po de personas, y nopor un solo individu o. Esto facilita descubrir posibles fa llos, al existirdiversos puntos de vista.

• El grup o que realiza la revisión debe ser reducido, para evitarexcesivas discusiones y facilitar la comunicación entre sus m iembros.Se recomienda de tres a cinco personas.

La revisión no debe ser realizada por los autores del producto, sinopor otras personas diferentes para garantizar la imparcialidad decriterio.

• Se debe revisar el producto, pero no el productor ni el proceso deproducción. El producto permanece, mientras que el cómo se obtuvoinfluye poco en el uso futuro de ese producto.

• Si la revisió n ha de decid ir la aceptación o no de un prod ucto, sedebe establecer de antemano una lista formal de comprobaciones arealizar, y atenerse a ella.




• Debe levantarse acta de la reunión de revisión, conteniendo los

puntos importantes de discusión y las decisiones tomadas. Estedocumento puede considerarse como el producto de la revisión.

1.9.4 Pruebas

Las pruebas o ensayos consisten en hacer funcionar un producto softwareo una parte de él en condiciones determinadas, y comprobar si losresultados son los correctos. El objetivo de las pruebas es descubrir loserrores que pueda contener el software ensayado.

Las pruebas no permiten garantizar la calidad de un producto. Puededecirse que una prueba tiene éxito si se descubre algún error, con lo que sesabe que el producto no cumple con algún criterio de calidad; por elcontrario, si la prueba no descubre ningún error, no se garantiza con ellola calidad del producto, ya que pueden existir otros errores que habrían dedescubrirse mediante pruebas diferentes. Esto es así porque nunca puedeensayarse un producto en forma exhaustiva, sino que las pruebas sólo hacenque el producto realice una parte ínfima de la enorme variedad deoperaciones concretas que podría realizar.

A pesar de esta limitación, las pruebas son una técnica fundamental degarantía de calidad. En el Tema 5 se describen técnicas concretas paraorganizar y realizar pruebas de software.

1.9.5 Gestión de configuración

Para p recisar el concepto de configuración consultaremos, como otras veces,el diccionario:

Configuración. (Del latín configurado) Disposición de las partes quecomponen una cosa y le dan su peculiar figura. . . .

La configuración de software hace referencia a la manera en que diversoselementos se combinan para constituir un producto software bienorganizado, tanto desde el punto de vista de su explotación por el usuariocomo de su desarrollo o mantenimiento.

Describiremos aquí brevemente los elementos básicos de la gestión deconfiguración. Estas ideas se encuentran más desarrolladas en otros textosgenerales de ingeniería de software, tal como [Pressman98].



Introducción 31

Para cubrir la doble visión del software, desde el punto de vista del usuario

v del desarrollados habremos de considerar como elementos componentesde la configuración todos los que intervienen en el desarrollo, y no sólo losque forman parte del producto entregado al cliente. Estos elementos serán,por ejemplo:

• Docum entos del desarrollo: Especificaciones, diseño, etc.• Cód igo fuente de los modulos.• Prog ram as, datos y resultados de las pruebas.• M anua les de usuario.• Docum entos de mantenimiento: inform es de problem as y cambios.

• Prototipos intermedios• No rm as particulares del proyecto.... etc. ...

El problema de la gestión de configuración es que estos elementosevolucionan a lo largo del desarrollo y la explotación del producto soft wa re,dando lugar a diferentes configuraciones particulares, compuestas dediferentes elementos. Los elementos individuales evolucionan a base deconstruir sucesivas versiones de los mismos.

Para mantener bajo control la configuración o configuraciones de software

hay que apoyarse en técnicas particulares de:

• Control de version es• Control de cambios

El control de versiones consiste en almacenar de forma organizada lassucesivas versiones de cada elemento de la configuración, de manera queal trabajar sobre una configuración concreta del producto software se puedaacceder cómodamente a las versiones apropiadas de sus elementos.

Elcontrol de cambios

consiste en garantizar que las diferentesconfiguraciones del software se componen de elementos (y versiones deestos elementos) compatibles entre sí, y que constituyen un conjuntocoherente.

El control de cambios se realiza normalmente usando el concepto de líneabase. Una línea base es una configuración particular del sistema. Cada líneabase se construye a partir de otra mediante la inclusión de ciertos cambios,que pueden ser la adición o supresión de elementos, o la sustitución dealgunos por versiones nuevas de los mismos. La aceptación de los cambiosy la consiguiente creación de la nueva línea base ha de controlarse mediante




pruebas o revisiones apropiadas, para garantizar la corrección de la nueva

configuración.

Las líneas base constituyen configuraciones estables, que no pueden sermodificadas (se dice que están "congeladas"). La forma de modificar unalínea base es crear otra nueva introduciendo los cambios apropiados. Laantigua línea base seguirá existiendo, aunque en algún momento se podráhacer desaparecer si se está seguro de no necesitarla más.

1.9 .6 Normas y están dares

Las recomendaciones de la ingeniería de software se han traducido enocasiones en normas precisas sobre determinados aspectos del desarrollo desoftware, desde el enfoque global del proceso de desarrollo hasta normasdetalladas de codificación, procedimientos concretos para la realización deensayos o modelos más o menos precisos de la documentación a redactar.

Algunas de estas normas han sido recogidas por organizacionesinternacionales y establecidas como estándares a seguir en el desarrollo dedeterminadas aplicaciones. Entre estas normativas encontramos lassiguientes:

IEEE: es la asociación profesional Institute of Electrical and ElectronicsEngineer establecida en USA. Lía establecido una colección denormas, muchas de el las admitidas también como normas ANSI(American National Standards Institute) y recogidas globalmente en[IEEE93].

DoD: son las siglas del Departamento de Defensa (Department of Defense)norteamericano. La norma fundamental es la DoD-STD-2167A[D0D88], que se complementa con otras normas adicionalesconteniendo, por ejemplo, modelos de los documentos a redactar. Enla actualidad está en revisión y será sustituida por la MIL-STD-SDD,que engloba en una sola tanto la norma principal como lascomplementarias de documentación.

ESA: es la Agencia Europea del Espacio (European Space Agency). Poseeuna norma general para el desarrollo de software [ESA91], Estanorma se apoya en algunos aspectos en las normas del IEEE citadasanteriormente.



Introducción 33

ISO: son las siglas del organismo internacional de normalización(International Standards Organization). Está integrado por losorganismos nacionales de normalización de un gran número depaíses (el de España es AENOR). Publica un sinfín de normas paratoda la actividad técnico-industrial. Entre sus normas de Ingenieríade Software de mayor nivel se encuentran la ISO-9001, que establecelos criterios que han de cumplir las empresas que desarrollensoftware para obtener certificaciones de determinados niveles degarantía de calidad de su producción.

En muchos países se han desarrollado también normas oficiales similares

a éstas, para uso interno. Entre las normas españolas encontramos:

METRICA-2: Desarrollada por el Consejo Superior de Informática delMinisterio para las Administraciones Públicas (MAP). Es una normapara el desarrollo de sistemas d e información de las adm inistracionespúblicas, basada en la metodología de análisis y diseño estructuradode Yourdon/DeMarco.



Te m a 2Es p ec i f ¡cación deS o f t w a r e

Este Terna está dedicado a describir la labor de análisis y definición de losrequisi tos que ha de cumplir un proyecto de software. Esta labor debe dar

lugar a la especificación de softw are, en la que se concretan las nec esidadesque se desean cubrir y se fyan las restricciones con las que debe trabajar elsoftware a desarrollar. El análisis se realiza dentro de la primera fase (fasede definición) del ciclo de vida y t iene una importancia decisiva paraconseguir que el sistema que se construya finalmente sea realmente el quese deseaba.

Primeramente, en este Tema, se hace un breve repaso al modelado desistemas centrado específicamente en los sistemas desarrollados mediantesoftware. A continuación, se estudia de manera detallada el proceso deanálisis de requisitos, estableciendo los objetivos y las tareas de dicho

análisis. Seguidamente se describen dist intas notaciones que habitualmentese emplean para elaborar la especificación de software. Finalmente, sesugiere un posible formato para el documento que recoge la especificacióny que consti tuye el resultado fundamental del análisis. Con este formato serealizan como ejemplo dos documentos completos de especificación querecogen el análisis de dos aplicaciones que se utilizan a lo largo del libro.

2 .1 M ode lado de S i s t em as

Para la mayoría de los trabajos de ingeniería es bastante habitual uti l izarprotot ipos o maqu etas. Por ejemplo en arqui tectura es mu y com ún realizarun modelo o maqueta a escala del nuevo edificio. Esto mismo sucedecuando se t rata de anal izar e l comportamiento de un nuevo disposi t ivomecánico, eléctrico, hidráulico, etc. Todos estos modelos facilitan alingeniero la labor de comprensión de los problemas que se plantean en elnuevo sistema a desarrollar.

El modelado de los sistemas real izados mediante sof tware también t ienecomo objetivo entender mejor el funcionamiento requerido y facil i tar lacomprensión de los problemas planteados. Sin embargo, para este t ipo de



36 Introdu cción a la Ingeniería de So ftwa resistemas no se busca, en principio, un modelo f ísico de su comportamiento.En este caso, el sistema software deberá efec tuar de una forma más o me n o scompleja un determinado tra tamiento de la información, y se t ra ta deestablecer mo delos conceptuales qu e reflejen por u n lado la organización dela información y por otro las diversas t ransformacion es que se deben l levara cabo con dicha información.

Hay que tener presente que cuando hablamos de modelo en este Tema nosestamos ref ir iendo a un modelo completo y preciso del comportamiento uorganización del s is tema sof tware . No hay que confundir es te modelo conel cor respondien te a u n a ma q u e ta o protot ipo parc ia l empleado como ayuda

para realizar la actividad de análisis, tal como se indicaba en el Temaanter ior .Existen diversas metodologías para realizar el análisis de los requisitos quedebe cumplir un proyecto sof tware . Un aspecto común a todas e l las es quetratan de facilitar la obtención de uno o varios modelos que detallen elcomportamiento deseado del s is tema. El empleo de una u otra metodologíadependerá del tipo de aplicación (gestión, control, cálculo, etc.) o de laspreferencias del anal is ta que e labore el modelo. El es tudio de metod ologíasconcretas queda fuera del alcance de este libro y serán objeto de estudio encursos posteriores.

2.1.1 Concepto de modelo

Con carácter genera l , un modelo conceptual es todo aquel lo que nosperm ite conseguir una abstracción lógico-matemática del m un do rea l y q uefacilita la comprensión del problema a resolver.

De manera específica, el modelo de un sistema software debe establecer laspropiedades y res tr icc iones del s is tema. Con e l modelo, s iempre se t ra tará

de ofrecer una visión de alto nivel, sin descender a explicar detallesconcretos del mismo. Por otro lado, el modelo debe explicar QUÉ debehacer e l s is tema y no CÓMO lo debe hacer . Después en la e tapa de diseñoposterior es cuando se debe concretar cómo se deben hacer las cosas.

Así, los objetivos que se deben cubrir con los modelos se pueden concretaren los siguientes:

1.- Facilitar la com pren sión del pro blem a a resolver.



Especificación de So ftwa re 372.- Establecer un marc o par a la discusión, qu e sim plif iqu e y sistematice

la labor tanto del análisis inicial como de las futuras revisiones delm i s m o3.- Fijar las bas es pa ra realiza r el dise ño

4.- Facilitar la verif icación del cum plim iento de los objetivos del sistema

2.12 Técnicas de modeladoLa obtención de un modelo que cubra todos los obje t ivos anter iores no es

una tarea fácil . Las dif icultades son de todo tipo. En primer lugar, loss is temas a modelar pueden ser muy complejos . Por otro lado, esre la t ivamente normal que no se disponga de ninguna referencia oexperiencia anterior , dado que el sistema que se trata de modelar eimp lem entar no ha s ido plantead o anter iormente . A continuación se indicanalguna s técnicas que p ued en resul tar út i les para rea l izar e l m odela do d e unsis tema sof tware .

2.1.2.1 Descomposición. Modelo jerarquizado

Cuando un problema es complejo, la pr imera técnica que se debe empleares descomponerlo en otros más sencillos de acuerdo con el viejo axioma"divide y vencerás". De esta manera, se establece un modelo jerarquizadoen e l que e l problema global queda subdividido en un c ier to número desubproblemas. Por e jemplo, s i se t ra ta de modelar un s is tema para lagest ión integra l de una empresa , es te s is tema se puede descomponer en lossubsis temas s iguientes:

• Sis tema de nóm inas• Sistema de conta bilidad• Sistema de facturació n

• ... etc . ...Este t ipo de descomposic ión se denomina hor izonta l y t ra ta dedescom pone r fun cionalm ente el problem a. A continuación, en e l anál isis decada uno de es tos subsis temas se pueden emplear las mismas técnicas quecon el sistema global. Por tanto, es posible volver a descomponer cada unode estos subsistemas a su vez en otros más simples. Por ejemplo, el sistemade nóminas se puede dividir en los s iguientes:

• Real ización de nóm inas• Pago s a la Seg uridad Social



38 Introdu cción a la Ingeniería de Softw are• Pag os del IRPF• ... etc . ...

Evidentemente , para completar e l modelo se tendrán que establecer lasinter fases entre las par tes o subsis temas en que queda dividido, paraposibi l i ta r e l funcionamiento del s is tema global .

Cuando se descompone un modelo t ra tando de deta l lar su es tructura , es tetipo de descomposición se denomina vertical. Por ejemplo, la realización denóminas se descompone según la secuencia :

• Entrad a de datos del t rabajado r• Cálculo de los ingreso s bru tos• Cálculo de las retenciones• Cálculo del pag o a la Seg uridad Social• Impresión de la nóm ina

Esta técnica supone aplicar el método de refinamientos sucesivos almodelado del s is tema.

2.122. Aproximaciones sucesivas

A pesar de que e l s is tema a desarrol lar nunca será igual a a lguno ya enfunc ionamiento , s iempre se pod rá tomar como mode lo de pa r t ida el mode lode otro sistema similar . Por ejemplo, es corriente que el sistema softwareque se quiere modelar sust i tuya a un proceso de t rabajo ya exis tente , quese rea l iza de forma tota lmente manual o con un grado de automatizaciónmenor del que se pretende lograr con el nuevo sistema. En este caso, sepuede crear un modelo de par t ida basado en la forma de t rabajo anter ior .Sin embargo, es te modelo sólo será pre l iminar y tendrá que ser depuradomediante aproximaciones sucesivas hasta a lcanzar un modelo f ina l .

Como es fác i l suponer , la depuración es una labor ardua y dif íc i l querequiere una gran experiencia del analista y en cualquier caso un estudioexhaust ivo del problema que se t ra ta de resolver con e l s is tema sof tware .Para lograr un buen resul tado mediante aproximaciones sucesivas , ademásdel analista, es fundamental contar con la colaboración de alguien queconozca m uy bien el s is tema an ter ior y que sea capaz de incorp orar m ejorasdentro del nuevo s is tema y discut ir las venta jas e inconvenientes de cadauno de los modelos intermedios e laborados.



Especificación de Softw are 392.1.2.3 Empleo de diversas notaciones

A veces puede suceder que e l modelo resul te muy complejo o inc lusoimposible de realizar utilizando una única notación para su elaboración. Enun apar tado poster ior se descr iben dis t intas notaciones ut i l izadashabitualmente . En estos casos es impor tante t ra tar de ut i l izar notacionesal ternat ivas o complementar ias que s implif iquen e l modelo.

Una posible notación para descr ibir e l modelo de un s is tema es medianteel lenguaje natura l . Evidentemente , todo se puede descr ibir mediante unaexplicación más o menos prol i ja empleando e l lenguaje natura l . Sin

embargo, es te método puede dar lugar a un modelo dif íc i l de apreciar ensu conjunto por lo farragoso de las explicaciones. Además es normal que sepro duz can im precis iones , repet ic iones e incluso incorrecciones en el mode loasí realizado. Como suele ser habitual, un esquema, una f igura, o cualquiermétodo gráf ico suele ser más fác i l de entender . Hay que recordar que unaimagen puede valer más que mil pa labras .

Teniendo en cuenta los objetivos, ya citados anteriormente, que debe cubrirun modelo, lo ideal es emplear para su elaboración la notación con la quemejor se cubran dichos objetivos. Incluso es aconsejable emplear variasnotaciones juntas cuando sea necesario. Así, existen diversas herramientasde modelado para la ayuda a l anál is is y diseño de los s is temas, tambiénllamadas herramientas CASE (Computer Aided Sof tware Engineer ing) , quecombinan texto, tablas, diagramas, gráficos, etc. Estas herramientas estándisponibles en e l mercado y es tán basadas en dis t intas metodologías deanál is is y diseño de s is temas sof tware . Dependiendo del aspecto concre todel s is tema que se quiere modelar es más adecuado emplear una u otranotación

2.1.2.4 Considerar distintos puntos de vista

Para poder concretar la creación de un modelo es necesario adoptar undeterminado punto de vis ta . Después, e l modelo que resul te es taránecesar iamente inf luido por e l punto de vis ta adoptado. Por e jemplo,cuando un pintor realiza un paisaje, elige el punto de vista que refleje deforma más exacta lo que quiere transmitir con el cuadro: calma, soledad,tristeza, alegría, sosiego, etc. El pintor, con el punto de vista elegido, tratade destacar los rasgos del mundo real que coinciden con el objetivo que seplantea en el cuadro y a la vez trata de ocultar aquellos detalles que noayudan a perf i lar e l modelo del mundo rea l que t ra ta de obtener en e lcuadro .



40 Introdu cción a la Ingeniería de So ftwareEvidentemente , no se puede comparar la labor de un pintor con la de uningeniero qu e t ra ta de obtener el modelo so f tware de una fu tura apl icación.Sin emb argo, tamb ién este úl t imo debe e legir e l pu nto de vis ta que perm itaobtener e l modelo más adecuado para representar e l comportamientodeseado del s is tema. Con este fin, en ocasiones será más adecuado adoptare l punto de vis ta del futuro usuar io del s is tema, en otras será másimpor tante considerar e l punto de vis ta del mantenedor del s is tema, enalgunos modelos será suf ic iente con perf i lar lo desde e l punto de vis tafuncional, etc. Por tanto, en el desarrollo de un modelo se debe elegirconvenientemente e l punto de vis ta más adecuado. Para la e lección seráconveniente esbozar distintas alternativas y elegir aquella que resulte la más

idónea .En ocasiones e l modelo no quedará completamente def inido con un solopunto de vista. En este caso lo adecuado sería realizar el modelo desdedis t intos puntos de vis ta , que muestren todos los aspectos que se quierendestacar del sistema.

2.1.2.5 Realizar un an álisis del dominio

Por dominio entenderemos e l campo de apl icación en e l que se encuadrael s is tema a desarrol lar . Por e jemplo, supongamos que se t ra ta dedesarrollar un sistema para el seguimiento de la evolución de los pacientesde un hospita l . Este s is tema quedará encuadrado dentro de las apl icacionespara la gestión de hospitales. En este campo, como en cualquier otro, existedesde siempre una cierta manera de realizar las cosas y una terminologíaya acuñada que debe ser respetada y tenida en cuenta . Esto es lo quedenominaremos rea l izar un anál is is de l dominio de la apl icación.

Si bien las peculiar idades de cada aplicación hacen que necesar iamente debaser es tudiada como un caso único, es impor tante anal izar e l dominio de la

apl icación para s i tuar la dentro de un entorno mucho más global . Pararealizar este análisis es aconsejable estudiar los siguientes aspectos:• No rmativ a que afecte a l s is tema• Otros s is temas semejantes• Estud ios recientes en el cam po de la aplicación• Bibliog rafía clásica y actu aliza da: Libro s y artícu los sob re el

t e ma• ... etc. ...



Especificación de So ftwa re 41Este estudio facilitará la creación de un modelo más universal. Comoventajas de este enfoque se puede citar las siguientes:1.- Facilitar la comunicación entre analista y usuario del sistema:

La creación de un nuevo modelo requiere una colaboración muyestrecha entre el experto que conoce los detalles de la aplicación quese es tá creando, que deno m inarem os usuar io, y el ingeniero desoftware que realiza el análisis, que denominaremos analista. Estacolaboración sólo es posible si la comunicación entre ellos resultafluida y emplean el mismo lenguaje. Por ejemplo, en el sistema de

seguimiento de la evolución de los pacientes, para guardar lainformación de cada paciente desde s iem pre se em plea e l té rmin o d e"historia clínica" y resultaría confuso cambiar es ta denominación porla de "ficha del paciente" que podría sugerir el analista.

2.- Creación de elementos realmente significativos del sistema:

Cuando se ignora el dominio de una aplicación, la solución que seadopta queda particularizada en exceso. Por ejemplo, si se trata dereal izar una apl icación de contabi l idad para una empresadeterminada, es bastante normal que se adapte f ielmente a lasexigencias del contable de dicha empresa, lo que puede dar lugar asoluciones no válidas para otras empresas. Sin embargo, si se tieneen cuenta el Plan Contable Nacional, la aplicación será válida encualquier empresa . En este sent ido se adoptarán los términosnorm alizados de balance, cuenta , apunte , t ransferencia , e tc . según uncriterio único y universal.

3.- Reutilización posterior del software desarrollado:

Otro de los beneficios importantes del análisis del dominio es la

posible reutilización posterior de aquellos elementos que han sidocreados dentro de un contexto más globalizado. Este criterio es elque ha s ido ut i l izado desde s iempre para dotar a todos loscomputadores de un paque te de subru t inas ma temát icas . Dent ro deun dominio de cá lculo matemático s iempre es necesar io disponer deoperaciones tr igonométricas, logaritmos, matrices, etc. con distintasprecisiones y tanto en coma fya como en coma flotante.

Otro e jemplo en este sent ido ser ía e l s iguiente : supongamos que setrata de realizar un sistema para la gestión de una base de datos ent iemp o rea l que necesita un t iem po de acceso que no se pued e lograr



42 Introdu cción a la Ingeniería de So ftwarecon ninguna de las disponibles en e l mercado. Para que e l esfuerzo

que hay que realizar no sirva sólo para la aplicación concreta, lo quese debe hacer es especificar un conjunto de subrutinas de consulta ymodif icación que se adapten a l es tándar SQL (Standard QueryLanguage) . Con estas subrut inas cualquier programa que ut i l ice unabase de datos med iante SQL pod rá ut i l izar nue stra base de datos conun mejor t iempo de respuesta .

2 .2 Aná l i s is de r equ i s i to s de so f tw a re

Como ya se ha comentado anter iormente , la e tapa de anál is is se encuadradentro de la primera fase (fase de definición) del ciclo de vida y tiene unaim portan cia decisiva en el desarro llo de toda s las etap as posterio res (diseño,codif icación, prueba y mantenimiento) . Como también ha s ido apuntado enel apartado anterior , el ingeniero de software encargado de esta labor lol lamaremos anal is ta .

Con el análisis de requisitos se trata de caracterizar el problema a resolver.Esto se puede concre tar en la obtención del modelo global que def ine porcompleto e l comportamiento requer ido del s is tema. Esta tarea es bastantecompleja. El primer problema que se le presenta al analista es conseguir un

interlocutor válido para poderla llevar a cabo. Este interlocutor, quedenominaremos de forma genér ica cliente, puede en a lgún caso estarconst i tuido por una o var ias personas exper tas en todo o sólo en una par tedel trabajo que se pretende automatizar con el sistema que se trata deespecificar , por ejemplo, cuando se trata de automatizar la gestión de unaempresa y exis te un responsable de la contabi l idad, pedidos, fac turación,etc. y otro del pago de las nóminas, será necesaria la colaboración deambos. En otros casos, no existirá nadie capaz de asumir el papel de cliente,bien debido a que nadie conoce exactamente lo que se requiere del sistemao bien simplemente por lo novedoso de la aplicación. En estos casos, elanalista debe buscar su cliente median te una documentac ión exhaus t ivasobre el tema.Como ya se ha podido deducir fác i lmente , a lo largo de es te tema no seasociará al cliente con la persona o entidad que f inancia el proyecto. Aquí,el cliente será e l encargado o encargados de e laborar junto con e l anal is talas especif icaciones del proyecto de sof tware y que poster iormente seencargarán de ver if icar e l cumplimiento de las mismas como si de uncontrato se tratara. Por tanto, en algunas ocasiones el cliente será el usuariofinal de la aplicación, en otros coincidirá con el cliente que propiamentef inancia e l proyecto e inc luso en otros pued e ser s implem ente p ar te de una



Especificación de Softw are 43especif icación de otro proyecto de mayor envergadura en e l que estáencuadrado e l nues t ro .

2.2.1 Objetivos del análisis

El objetivo global del análisis es obtener las especificaciones que debecumplir el sistema a desarrollar . El medio que se emplea para lograr dichoobjetivo es obtener un modelo válido, necesario y suficiente para recogertodas las necesidades y exigencias que el cliente precisa del sistem a yadem ás tam bién tod as aquel las restr icc iones que e l anal is ta considere d ebe

verif icar el sistema. Las especificaciones se obtendrán basándose en elmode lo ob ten ido .Evidentemente , en e l proceso de anál is is quedarán descar tadas aquel lasexigencias del cliente que resul ten imposibles de lograr o que s implementeresulten inalcanzables con los recursos puestos a disposición del proyecto.De igual manera, como resultado del diálogo entre el analista y el clientequedarán convenientemente matizadas cada una de las exigencias ynecesidades del s is tema para adaptar las a los medios disponibles para e lproyecto.

Para lograr una especificación correcta, el modelo global del sistema deberátener las s iguientes propiedades:

1.- Completo y sin omisiones:

Aunque pueda parecer s imple , es ta propiedad no es senci l la decumplir dado que a priori no es fácil conocer todos los detalles delsistema que se pretende especificar . Por otro lado, cualquier omisiónpuede tener una gran incidencia en el diseño posterior e inclusodesvir tuar e l modelo del s is tema. Por e jemplo, supongamos que se

omite, por considerarlo sobreentendido, los sistemas operativos (DOSy UNIX) o la configuración m ínim a qu e se precisará p ara la ejecucióndel sistema a desarrollar . Las consecuencias de esta omisión puedendar lugar a que se anule o reduzca la utilidad del sistemadesarrollado finalmente.

2.- Conciso y sin tr ivialidades:

En general, uno de los graves errores que se suelen cometer ale laborar una documentación es suponer que será más exhaust ivacuanto más voluminosa resul te . Sin embargo, s i e l tamaño crece



44 Introd ucción a la Ingeniería de Softw aredesmesuradamente suele ser una prueba inequívoca de que no estás iendo revisada convenientemente y que muy probablemente t ienetrivialidades, repeticiones innecesarias o incluso alguna inexactitud.Por e jemplo, es to puede ocurr ir a l e laborar un nuevo modelopar t iendo de otro anter ior semejante. En pr incipio se suele m antenertodo aquel lo que no entra en contradicc ión con e l nuevo modelo.Esto da lugar a que se mantengan párrafos del anter ior que noapor tan nada a l nuevo mode lo y que pueden da r luga r ainexactitudes.

Por otro lado, cuando un modelo resul ta muy far ragoso es muy

probable que no se estudie en detalle y que resulte dif ícil distinguirlos aspectos fundamenta les de aquel los que no lo son.3. - Sin ambigüedades

Existe cierta tendencia a pensar que el análisis de requisitos es unmero trámite , que debe ser pasado rápidamente para entrar de l lenoen el diseño e implementación del sistema. Esta f ilosofía, queafor tunadamente es cada día menos habitual , da lugar a que en e lanálisis se dejen ciertos aspectos completamente ambiguos. Lasconsecuencias de esta actitud son todas negativas:

• Dificu ltades en el diseñ o• Retrasos y er rores en la implem entación• Imp osibilid ad de verif icar si el sistema cum ple las

especificaciones

Si se considera que el modelo resultado del análisis es un contratocon el cliente, es evidente que nada debe quedar ambiguo o de locontrar io se producirán inevitablemente f r icc iones y problemas deconsecuencias dif íciles de prever.

4.- Sin detalles de diseño o implementaciónComo ya se ha indicado anteriormente, el objetivo del análisis esdefinir el QUÉ debe hacer el sistema y no el CÓMO lo debe dehacer. Por tanto, es claro que no se debe entrar en ningún detalle deldiseño o implementación del sistema en la etapa de análisis. Hay quetener en cuenta que e l anal is ta puede tener una formación previamuy próxima a l diseño y codificación. Esto hace que de una manerainvoluntaria tenga cierta tentación a buscar la solución en lugar de



Especificación de So ftwa re 45

exclusivamente plantear e l problema. Esta tentac ión debe sersuperada si se quiere realizar un buen análisis.5.- Fácilmente entendible por el cliente

La única form a de conocer si el cliente está de acuerdo con e l mo delofruto del análisis es que lo entienda y sea capaz de discutir todos susaspectos. Es importante, por tanto, que el lenguaje que se utilice seaasequible y que facilite la colaboración entre analista y cliente. Eneste sent ido es m uy interesante e l emp leo de notaciones gráficas talescomo las que se es tudiarán en e l próximo apar tado.

6.- Separando requis i tos funcionales y no funcion ales

Los requisitos funcionales son los destinados a establecer el modelode funcionamiento del s is tema y serán e l f ruto fundamenta l de lasdiscusiones entre analista y cliente. Las person as no muy exper tas ensis temas software, tales com o el usua rio, t ienen ten den cia a creer quelos requisitos funcionales son los únicos a tener en cuenta y que sóloen base a ellos se realizarán las pruebas de verif icación del sistemadespués de su implementación. Sin embargo, exis ten además lasrestr icciones o requisitos no funcionales que están destinados aencuadrar e l s is tema dentro de un entorno de t rabajo y quedel imitan:

• Capac idades mín im a y máxima• Interfases con otros sistema s• Recursos qu e se necesitan• Aspectos de segu r idad• Asp ectos de f iabilidad• Aspectos de m antenim iento• Asp ectos de calidad

• ... etc . ...Estos requisitos no funcionales tienen un origen más técnico y notienen tanto interés para el cliente como lo tienen los funcionales.Por tanto, parece evidente que deban permanecer c laramenteseparados en e l modelo del s is tema.

7.- Dividiendo y jerarquizando e l modelo

La forma más senci l la de s implif icar un modelo necesar iamentecomplejo del s is tema es dividiéndolo y jerarquizá ndolo . Esta divis ión



46 Introd ucció n a la Ingen iería de So ftwaredará lugar a otros submodelos , como ya se indicó anter iormente . Enla definición del modelo global del sistema, se deberá ir de lo generala lo particular . Esto facilitará su comprensión y permitirá abordar elanál is is de cada par te por separado de una forma rac ional ysis temática . Ejemplos de es te enfoque ya se han mostrado en e lapar tado anter ior de es te mismo tema.

8.- Fijando los criterios de validación del sistema:

Es muy impor tante que en e l modelo del s is tema quedenexpresamente indicados cúales serán los criterios de validación del

sistema. No hay que olvidar el aspecto contractual que debe tener elmodelo aprobado en la especificación del sistema. En este sentido unbuen método para fyar los criterios de validación es realizar concarácter pre l iminar e l Manual de Usuar io del s is tema. Aunque en e lManual no se recogen todos los aspectos a validar, siempre suele serun buen punto de pa r t ida .

2.22 Tareas del anál isis

Para la realización correcta de un análisis de requisitos conviene efectuaruna serie de pasos o tareas. Dependiendo de las características ycomplejidad del sistema que se trata de analizar , alguna de las tareas puederesultar tr ivial o inexistente. A continu ación se indican las tareas en el orde nen que habitualmente serán desarrol ladas:

1 . - ESTUDIO DEL SISTEMA EN SU CONTEXTO

Los s is temas rea lizados med iante sof tw are o s is temas sof tw are norm alm enteson subsis temas de otros s is temas más complejos en los que se agrupansubsis temas hardw are , su bsis temas mecánicos, subsis temas sensor ia les, e tc .

Por tanto, la primera tarea del análisis del sistema software será conocer elmedio en e l que se va a desenvolver .Por ejemplo, en un sistema para la supervisión y control del nivel de gasescontaminantes en un gara je , se dispondrán sensores de CO, C0 2 y de otrosgases s i tuados en diferentes puntos del garaje. Asimismo, para evacuar losgases se dispondrá de var ios extrac tores s i tuados normalmente próximos aalguno de los sensores. Por otro lado, el sistema debe disponer de unaconsola situada en la cabina de control en la que se muestra periódicamentela situación y en la que se indican mediante alarmas acústicas situacionesque requieran la intervención del operador (avería en un sensor, avería en



Especificación de So ftware 47un ven ti lador , nivel de contam inantes a l to e incontrolable, etc.). Si se quiereespecificar un sistema que pueda ser utilizado en cualquier tipo de garajey con cualquier tipo de sensor, es importante establecer un contexto globalde funcionamiento del s is tema. Aparece de inmedia to la necesidad deespecif icar una fun ción de conf iguración del s is tema p ara e l garaje concretoen el que se instala. Esto es, indicar el número y tipo de sensores, susituación, condicion es de alarma, etc. Tod os estos detalles sólo se pu ed enconocer si se analiza el sistema software en su contexto.

Otro aspecto muy impor tante en este sent ido es e l anál is is de l dominio dela aplicación. Este análisis, como ya se indicó en el apartado del modelado

de sistemas, incide directamente no sólo en la terminología a emplear en laespecificación del sistema, sino también en la creación de sistemas con unavisión más globalizadora y que facilita la reutilización posterior de algunade sus par tes .

2 . - IDE NT IF IC AC IÓN DE NE C E S IDADE S

Inicialmente, la actitud del cliente es solicitar del sistema todas aquellasfunciones de las que en a lgún momento s int ió la necesidad, s in pararse apensar e l grado de ut i l idad que tendrán en e l futuro. La labor del anal is taes concretar las necesidades que se pueden cubrir con los mediosdisponibles (potencia de cálculo, capacidad de memoria, capacidad de disco,etc.) y dentro del presupuesto y plazos de entrega asignados a la realizacióndel sistema.

Para rea l izar es ta tarea de anál is is es fun dam ent a l que e l anal is ta m anteng aun diálogo constante y f luido con el cliente, esto es, con todos aquellos quepu ed an apor tar a lgo a l s is tema en cualquiera de sus facetas. De todos ellos,el analista deberá recoger y estudiar sus sugerencias para elaborar unapropuesta que sa t isfaga a todos. Com o resul tado de esta labor deben qued ar

descar tadas aquel las funciones muy costosas de desarrol lar y que noapor tan gran cosa a l s is tema. Adem ás, para aquel las necesidades que tenganun cierto interés y que requieran más recursos de los disponibles, el analistatendrá que apor tar a lguna solución aunque sea incompleta , que encajedentro de los presupuestos del s is tema. Por e jemplo, suele ser f recuente lanecesidad de acotar la cant idad d e información que se necesita guard ar pararealizar posteriormente estadísticas. Una actitud permisiva en este sentidopuede dar lugar a megabytes de información que no s irven para nada.

Desde luego, las necesidades que f inalmente se identif iquen deberán estarconse nsuad as por tod os aquel los que junto a l anal is ta haya n par t ic ipad o en



48 Introducción a la Ingeniería de Softw areel análisis. Es labor del analista convencer a todos de que la soluciónadoptada es la mejor con los medios disponibles y nunca tratar de imponersu criterio a toda costa.

3 . - ANÁL IS IS DE AL T E R NAT IVAS . E S T UDIO DE VIAB IL IDAD

En esta tarea aparece de forma evidente el enfoqu e de ingeniero de sof twaredel que debe estar im preg nad a la actividad del analista. En principio existeninfinitas soluciones a un mismo problema. La labor del analista se debecentrar en buscar aquella al ternativa que cubra las necesidades realesdetectadas en la tarea anterior y que tenga en cuenta su viabil idad tanto

técnica como económica.Cuando no es posible con un enfoque determinado encontrar un modeloque cubra todas las necesidades de una forma satisfactoria, se deben buscarsoluciones al ternativas. Con cada una de las al ternativas planteadas esnecesario realizar su correspondiente estudio de viabil idad. Estos estudiosconsti tuirán una base fundamental para la toma de decisión sobre laalternativa finalmente elegida.

La realización de esta tarea no siempre resulta necesaria. Solamente enaquellos sistemas cuya complejidad, al to presupuesto o dificultad intrínsecaasí lo aconsejen, se deberá realizar un análisis completo de diversasalternativas.

4 . - E S T AB L E C IM IE NT O DE L M ODE L O DE L S IS T E M A

Según se van obteniendo conclusiones de las tareas anteriores, estas sedeben ir plasmando en el modelo del sistema. Así , el modelo se iráperfi lando a medida que se avanza en el estudio de las necesidades y lassoluciones adoptadas. Probablemente, el resultado final será un modelo delsistema global jerarquizado en el que aparecerán subsistemas que a su vez

tendrán que ser desarrollados hasta concretar suficientemente todos losdetalles del sistema que se quieren especificar.Para la elaboración del modelo se deberán uti l izar todos los mediosdisponibles, desde procesadores de texto hasta las más sofist icadasherramientas CASE, pasando por las más diversas herramientas gráf icas.Todo ello debe contribuir a simplificar la elaboración del modelo y afacilitar la comunicación entre analista, cliente y diseñador. En el próximoapartado se detallan la mayoría de las notaciones que se uti l izanhabi tualmente para desarrol lar e l modelo del s is tema.



Especificación de So ftw are 495 . - E L AB OR AC IÓN DE L DOC UM E NT O DE E S P E C IF IC AC IÓN DE R E QUIS IT OS

El resultado final del análisis será el documento de especificación derequisi tos. Este documento debe recoger absolutamente todas lasconclusiones del análisis. Evidentemente, una parte fundamental de estedocumento será el mod elo del s is tema y precisamente es en este docum entodonde se debe ir perfi lando su elaboración a lo largo de todo el análisis.Existen dist intas propuestas de organización de este documento que seránestudiadas en un próximo apartado de este mismo tema.

Es muy importante tener en cuenta que este documento será el que uti l izará

el diseñador como punto de part ida de su trabajo. Asimismo, estedocumento también es el encargado de fi jar las condiciones de validacióndel sistema una vez concluido su desarrollo e implementación. Todo elloindica la transcendencia que t iene su elaboración y el cuidado que se debeponer para que sea úti l tanto al cliente como al diseñador.

6 . - R E VIS IÓN C ONT INUADA DE L ANÁL IS IS

Desgraciadamente la labor de análisis no acaba al dar por finalizada laredacción del documento de especificación de requisi tos. A lo largo deldesarrollo del sistema y según aparecen problemas en las etapas de diseño

e implementación se tendrán que modificar alguno de los requisi tos delsistema. Tampoco resulta muy raro que se modifiquen los requisi tos debidoa cambios de cri terio del cliente debidos a los más diversos motivos. Todoello implica que se debe proceder a una revisión continuada del análisis yde su documento de especificación de requisi tos según se producen loscambios.

Si se prescinde de esta últ ima tarea, cosa desgraciadamente bastantehabitual , se corre el peligro de realizar un sistema del que no se tenganinguna especificación concreta y en consecuencia tampoco ningún mediode validar si es o no correcto el sistema finalmente desarrollado.

2.3 No taciones para la espec i f icac ión

La especificación será fundamentalmente una descripción del modelo delsistema que se pretende desarrollar. Para un mismo modelo conceptual ,dependiendo de la notación o notaciones (texto, gráficos, tablas, etc.) que seempleen para su descripción, se obtendrán dist intas especificaciones. Aprior i , todas las especi f icaciones deberían ser equivalentesindependientemente de la notación empleada. Sin embargo, e l empleo de



50 Introducción a la Ingeniería de Softw arela notación más adecuada en cada caso redundará en una mejorespecificación del sistema. En general , siempre será preferible uti l izar unatabla o una notación gráfica que el texto que las pueda describir.

Las diversas metodologías de análisis, desarrolladas a lo largo de años, hanido estableciendo dist intas notaciones para describir el modelo global delsistema o ciertos aspectos del mismo. Debido al desarrollo paralelo de lasdist in tas metodologías es f recuente que una misma notación tengasignificados dist intos en cada metodología (por ejemplo: un círculo puedesignificar en unos casos una transformación de datos y en otros representarun estado del sistema), o que para un mismo concepto se empleen dist intas

notaciones (por ejemplo, un estado del sistema puede indicarse medianteun círculo o mediante un rectángulo). Para evitar malas interpretaciones enla especificación, es fundamental conocer el significado concreto de lanotación que se uti l iza.

En cualquier caso, la notación o notaciones empleadas deberán ser fácilesde entender por el cliente, el usuario, y en general por todos aquellos quepuedan part icipar en el análisis y desarrollo del sistema. No obstante, elempleo de una notación u ot ra dependerá de la complej idad y t ipo desistema a desarrollar (gestión, control, comunicaciones, etc.), de lametodología empleada, de las herramientas disponibles (procesador detextos, software para gráficos, entornos CASE, etc.) e incluso de laspreferencias del analista o del cliente.

A continuación se hace un repaso a las notaciones que se uti l izan másfrecuentemente para especificar los sistemas software.

2.3.1 Lenguaje natural

La notación más inmediata que se puede emplear para real izar unaespecificación es el lenguaje natural que habitualmente empleamos para

comunicarnos. Mediante explicaciones más o menos precisas y m ás o men o sexhaustivas es posible describir prácticamente cualquier cosa.Para sistemas de una complejidad pequeña, es suficiente el lenguaje naturalcomo notación para realizar su especificación y es la manera en que casisiempre se suele realizar. Cuando la complejidad del sistema es rriediana ogran de, resulta prácticam ente impo sible uti l izar sólo el lenguaje natural . Losprincipales inconvenientes, como ya ha sido mencionado, son lasimprecisiones, repeticiones e incorrecciones que se pueden producir.Además, existen ot ras notaciones que son mucho más adecuadas parasintet izar aspectos concretos del sistema y que son capaces de ofrecer una



Especificación de Softw are 51visión más globalizadora, lo que simplifica mucho la especificación del

sistema.El lenguaje natural será la notación que se empleará siempre que seanecesario aclarar cualquier aspecto concreto del sistema, que no seancapaces de reflejar el resto de notaciones. En cualquier caso, siem pre qu e seuti l ice el lenguaje natural es muy importante organizar y estructurar losrequisi tos recogidos en la especificación. La mejor manera de lograrlo, esconcebir cada uno de los requisi tos como una cláusula de un contrato entreel analista y el cliente. Así, se pueden agrupar los requisi tos según sucarácter:

1.- Funcionales2.- Calidad3.- Seguridad4.- Fiabilidad5.- ...

y dentro de cada grupo, establecer y numerar correlat ivamente las cláusulasde dist intos niveles y subniveles que estructuren los requisi tos:

1.- Funcionales

R. l . l : M odos de func ionamien toR.1.2: Formatos de entradaR.1.3: Formatos de salidaR.1.4

Para l imitar las imprecisiones y ambigüedades propias del lenguaje natural ,es conveniente establecer ciertas reglas de uso del lenguaje, que impidan,en la me dida de lo posible, un us o retórico o impreciso. Eviden temen te, unaespecificación nunca debe ser una novela y es preferible que se uti l icenfrases siempre con la misma construcción que tengan siempre la mismainterpretación.El lenguaje natural estructurado es un a notación m ás form al que el lenguajenatural . Fundamentalmente se trata de establecer ciertas reglas para laconstrucción de las frases en las que se especifica una acción de t iposecuencia, condición o i teración. No se trata de obligar a que todas lasespecificaciones escritas en español utilicen las mismas frases, lo que seríaimposible. Se trata de lograr que dentro de una misma especificación todaslas frases se construyan de igual manera. Por ejemplo, en lugar de escribiren dist intos apartados de la especificación:



52 Introducción a la Ingeniería de Softw areCuando se teclee la clave 3 veces mal, se debe invalidar la tarjeta ...

Cuando el saldo sea menor de cero pesetas se aplicará un interés . . . .

Para los clientes mayores de 65 años se establecerá un descuento de ....

es mejor que todas las frases se construyan de igual manera:SI se teclea la clave 3 veces mal ENTONCES invalidar tarjeta . . .

SI el saldo es menor de cero pesetas ENTONCES el interés será .. .

SI el cliente es mayor de 65 años ENTONCES el descuento será .. .

Construcciones similares se pueden uti l izar para la i teración y lasecuencia. No se trata de uti l izar siempre una misma palabra clave(SI, REPETIR, etc.), sino emplear la misma construcción en todas lasfrases, al menos, de una misma especificación.

2.3.2 Diagram as de flujo de d at os

Esta notación está asociada a la metodología de análisis estructurado, quefue desarrollada a lo largo de la década de los 70 [DeMarco79]. El enfoquedel análisis estructurado es considerar que un sistema software se puedemodelar mediante el flujo de datos que entra al sistema, lastransform acione s que se realizan con los datos de en trada y el flujo de d atosque se produce a la sal ida como resultado de la transformación. Estafi losofía se puede aplicar con total generalidad para modelar los sistemasde información, en los que efectivamente siempre se producen sucesivastransformaciones de los datos de entrada (salario, ingresos, precios, etc.)para obtener los datos de salida (nómina, liquidaciones, facturas, etc.).

Con los diagramas de flujo de datos (DFD) se pueden modelar de formamuy sencil la las transformaciones y los flujos de datos uti l izando unanotación gráfica. Como se muestra en la figura 2.1, una flecha indica unflujo de datos en el sentido en el que apunta su cabeza. Con cada flecha deun DFD se t ienen que detal lar sus Datos mediante un nombre o unadescripción. Un proceso o transformación de datos se indica con un círculoo burbuja. Dentro del círculo se nombra o describe el proceso que realiza.Una l ínea doble indica un almacén de datos. Estos datos almacenadospueden ser guardados por uno o var ios procesos y asimismo pueden serconsultados o consumidos por uno o más procesos. Entre las dos l íneas se



Especificación de Softw are 53detalla el nombre o descripción de los datos que guarda el almacén.Finalmente, un rectángulo representa una entidad externa al sistemasoftware (el usuario, otro programa, un disposit ivo hardware, etc.) , queproduce o consume sus datos.

Datos

Entidad

Externa

Flujo de los Datos en el sentido de la flecha

Proceso o transformación de datos

Entidad externa que produce o consume datos

Almacén de Datos Almacén de datos con cualquier organización

Fig u ra 2 .1 . No tac ió n DFD b ás i ca

Como ejemplo de diagrama de DFD, supongamos el s iguiente enunciadode problema: Se trata de especificar un sistema para el control de acceso aun recinto mediante una tarjeta y u na clave de acceso. La tarjeta ma gnéticalleva grabada los datos personales del propietario y la clave de acceso. Elsistema dispondrá de un teclado numérico para introducir la clave y un

display o pantalla para escribir los mensajes. El sistema registrará todos losintentos de accesos aunque sean fal l idos por no teclear correctamente laclave o por tratar de uti l izar un t ipo de tarjeta incorrecta.

En la figura 2.2 se muestra el DFD del sistema global o DFD de contexto.En este ejemplo, las entidades externas son el lector de las tarjetasmagnéticas, el teclado para introducir la clave, la pantalla o display y eldisposit ivo para la apertura de la puerta. El lector de tarjetas suministra anuestro sistema los datos grabados en las mismas (Nombre y apell idos,clave de acceso, etc.) y mediante el teclado se lee la clave para lacorrespondiente comprobación. La pantalla recibe de nuestro sistema los



54 Introd ucció n a la Ingeniería de Softw aremensajes para poder establecer el diálogo con la persona que trata deacceder al recinto y el dispositivo de apertura de la puerta, las órdenes paraabrir la.

F i g u r a 2 . 2 . D F D d e c o n t e x t o p a r a e l s i s t e m a d e c o n t r o l d e a c c e s o

El DFD de contexto nunca es suficiente para describir el modelo del sistemaque se trata de especificar . Para refinar el modelo, los DFD se usan deform a jerarqu izada por niveles . El DFD de contexto se denom ina nivel 0. Acontinuación, cada proceso o burbuja se puede "explotar" y mostrar cómose organiza inter iormen te , m ediante otros DFD. En el caso de un diagram ade contexto, sólo se puede explotar un único proceso que es el proceso

global del sistema y su explosión dará lugar al único DFD de nivel 1.En el ejemplo del sistema para el control de acceso, la f igura 2.3 muestra elDFD de nivel 1. Como se puede observar, los f lujos de entrada y salida alDFD de nivel 1 corresponden exactamente con los que t iene e l procesoControl de Acceso del diagrama de contexto, esto es: Datos Tarjeta, Clave,Mensajes y Ordenes.

La elaboración del nuevo DFD es el resultado de la labor de análisis delsistema que se está especificando. Teniendo en cuenta las necesidades delcliente expresadas en el enunciado, se ve que hace falta utilizar un almacén



Especificación de Softw are 55para guardar los datos de la tarjeta que intenta acceder, y si f inalmente seconsigue o no. En la f igura 2.3, este almacén se ha denominado Informaciónde Accesos.

Fig u ra 2 .3 . DFD d e n iv e l 1 p ara e l s i s t ema d e co n t ro l d e acceso

También, de acuerdo con e l cliente, el proceso Comprobar Tar je ta será e lenc arga do de verif icar si la tarjeta introd ucid a p or el lector es correcta. Estaverif icación se reduce a comprobar si los datos que tiene grabados la tarjetalo es tán en e l orden y formato adecuado y con los controles de segur idadestablecidos. En cualquier caso se grabarán todos los datos de la tarjetaleída para el control de acceso.

El proceso Co m proba r Clave es e l encargad o de ver ificar si la clave tecleadaes la misma que está grabada en la tarjeta. Si la clave es correcta se autorizael acceso. En cualquier caso se graba el resultado del intento de acceso. Elproceso Visualizar Mensajes es el encargado de sacar por pantalla losmensajes que le envían los dos anteriores para establecer el diálogo con lapersona que trata de acceder al recinto. Finalmente, el proceso Control dePuer ta es e l encargado de e jecutar y tempor izar la orden de aper tura de lapuer ta .

El ref inamiento del DFD de nivel 1 puede continuar con cada uno de losprocesos que en él aparecen. Una forma de facilitar la identif icación de los

Datos



56 Introdu cción a la Ingeniería de So ftwa resucesivos DFD es nu m erar de form a corre la tiva los dis t intos procesos antes

de su refinamiento. El DFD resultante de la explosión de un proceso xt endrá e l núm ero x del proceso explotado. Los procesos hijos que aparecenen él se numerarán de 1 en adelante, en la forma x.l , x.2, . . . El únicoproceso del diagram a de contexto no l leva num eración, y el único diagram aresul tante de nivel 1 se designa como DFD 0. De esta manera los sucesivosd iagramas se numera rán de la fo rma:

Nivel 0 Diagram a de contextoNivel 1 DFD 0Nivel 2 DFD 1 hasta DFD n

de los procesos 1 hasta n del nivel 1Nivel 3 DFD 1.1 hasta DFD í.ide los procesos 1.1 hasta l.i del nivel 2

DFD 2.1 hasta DFD 2.jde los procesos 2.1 hasta 2.jdel nivel 2

D FD n. 1 hasta DFD n.kde los procesos n. 1 hasta n.k del nivel 2

Niv el 4 DF D 1.1.1 ha sta DFD 1.1.xDFD l. i . l hasta DFD l. i .z

... etc. ...

En todo s ellos los f lujos de d atos de en trad a y salida a ntes de la "explosión"del proceso debe coincidir con los f lujos de entrada y salida del DFDresultado de la explosión o refinamiento. La ventaja de esta notación es su

simplic idad lo que permite que sea fác i lmente entendida por todos:cliente,

usuario, analista, etc. En los ejemplos que se desarrollan al f inal de estecapítulo se puede comprobar todo esto.

Aunque se podr ía continuar ref inando de manera indef inida , a par t i r de undeterminado nivel y dependiendo de la complej idad del s is tema que seespecifica, no tiene sentido subdividir más los procesos. En este punto esconveniente describir cada uno de ellos utilizando otra notación distinta,por ejemplo, el lenguaje natural estructurado que ya ha s ido presentado opseudocódigo que se presentará más adelante en este mismo apar tado.



Especificación de Softw are 57Por otro lado, también es necesario describir las estructuras de cada uno delo s flujos de datos y las es tructuras de los datos guardados en cada uno delos almacenes de datos. Esta descripción también se puede realizarmedian te lenguaje natural estructurado o bien ut i l izando a lguna de lasnotaciones para la descr ipción de datos que se es tudiarán en un próximoapartado. En líneas generales, se tratará de describir mediante una tabla,todos los e lementos básicos de información que const i tuyen los diversosdatos que se manejan en los dis t intos DFD del modelo del s is tema. Porejemp lo, en la f igura 2.3, los datos Clave, Tarjeta Correcta o Info rma ción deAccesos.

Para f inalizar esta introducción a los diagramas de f lujo de datos, convieneprecisar algunos aspectos. Principalmente, los DFD sirven para establecerun modelo conceptual del sistema que facilita la estructuración de suespecif icación. El modelo as í desarrol lado es fundamenta lmente es tá t icod a d o q u e refleja los proceso s necesarios para su d esarrollo y la interrelaciónque existe entre ellos. M edian te un DFD nun ca se pu ed e establecer ladinámica o secuencia en la que se ejecutarán los procesos. Por ejemplo, enla f igura 2.3 no se establece ningún orden concreto entre los flujos de salidadel proceso Comprobar Tar je ta y por tanto, se podrá producir pr imeroGrabar Tarjeta, desp ués M ensaje de Com probación de Tar je ta y f ina lmenteTarjeta Correcta o en cualquier otro orden.

La única premisa de carácter dinámico que se puede establecer en un DFDes que en ellos se utiliza un modelo abstracto de computo del tipo f lujo dedatos [CerradaOO], Así, los procesos funcionan de forma semejante a una"Red de operadores" y en cada ejecución se utiliza y consume un elementode cada uno de los f lujos de datos de entrada y se generan los elementosde datos previstos para cada uno de los f lujos de salida. En el caso de losa lmacenes de datos , los e lementos se ut i l izan pero no se consumen ypueden ser ut i l izados poster iormente .

2.3.3 Diagramas de tr ansición de est ad osEl número de es tados posibles que se pueden dar en un s is tema sof twarecrece de una forma exponencia l con su complej idad. Incluso para s is temasbastante s imples e l número de es tados es muy grande. Hay que tener encuenta que cada vez que se modifica una variable, se evalúa una condicióno e l té rmino de una expresión se produce un cambio de es tado en e lsistema. Todos estos estados y las sucesivas transiciones entre ellosconf iguran la dinámica del s is tema que se produce mientras se es táe jecutando.



58 Introd ucció n a la Ingeniería de So ftwa rePara realizar la especificación de un sistema, de todos sus estados posibles,sólo es imp or tante resa l tar aquel los que t ienen c ierta t ranscendencia desdeun punto de vis ta funcional . El diagrama de t ransic ión de es tados es lanotación específica para descr ibir e l com portam iento dinám ico del s is temaa par t i r de los es tados e legidos como más impor tantes . Por tanto, es unanotación que se complementa perfec tamente con los diagramas de flujo d edatos y que ofrece otro punto de vista del sistema que en la mayoría de loscasos resulta imprescindible.

Estado inicial/final del sistema( Q ) Arranque/parada del s is tema

x - —

Estado ( Estado ) Estad o Inter medio del Sistema

\ — y

Evento

7 Evento que provoca el cambio de EstadoEvento

F i g u r a 2 . 4 . N o t a c i ó n b á s i c a d e D i a g r a m a s d e E s t a d o

La notación básica para e laborar los diagramas de es tados que se empleahabitualmente se muestra en la f igura 2.4. Como se puede observar en la

f igura , se sugieren dos formas dis t intas para representar un estado:mediante un rec tángulo o mediante un c írculo. En ambas notaciones seindica mediante el nombre que encierran en su interior el estado concretoque representan. La razón por la que existen estas dos posibilidades es suprocedencia . Los diagramas de es tado mediante c írculos son los másuti l izados para representar autómatas de es tados f ini tos (autómatasmecánicos, circuitos eléctr icos o electrónicos y au tom atism os en g eneral) . Sinembargo, para evitar la confusión con la notación empleada en laelaboración de los DFD, para la especificación de un sistema softw are sesuele emplear e l rec tángulo.



Especificación de So ftwa re 59Los eventos que provocan e l cambio de es tado se indican mediante unaflecha dir igida desde el estado viejo al nuevo estado. Por razones estéticasse em plean f lechas en form a de arco cuan do se ut i lizan c írculos y fo rm ada spor t ramos rec tos cuando se ut i l iza un rec tángulo.

Cuando se considere interesante destacar los estados inicial y f inal delsistema, se puede hacer mediante dos círculos concéntricos.

En la f igura 2.5 se muestra el diagrama de estados del sistema de acceso.En este caso el sistema es muy sencillo y los estados posibles son solamentetres: Esperar Tarjeta, Esperar Clave y Permitir Acceso. Respecto a los

eventos que provocan los cambios de es tado, se deberán ut i l izar otrasnotaciones para detallar de manera más precisa el significado concreto decada uno de e l los . A pesar de todo, es te diagrama modela de manerasencilla y precisa la dinámica del sistema y se complementa perfectamentecon los DFD del apartado anterior para lograr una especificación lo máscompleta y exacta posible.

Arranquedel Sistema

Fin del Acceso

F i g u r a 2 . 5 . D i a g r a m a d e E s t a d o s d e l S i s t e m a d e A c c e s o

En los e jemplos del f ina l de es te tema se muestra otro diagrama de estadouti l izando la notación a l ternat iva .



60 Introdu cción a la Ingeniería de So ftwareCuando la complej idad del s is tema así lo requiera , serán necesar ios var iosdiagramas de es tados. Además del diagrama de estados global de l s is tema,pueden ser necesarios otros diagramas adicionales para especificar ladinámica de determinados procesos s ignif ica t ivos del s is tema. En estoscasos, es impor tante e legir cuidadosamente los es tados y las t ransic ionesque fac i l i ten la comprensión del s is tema s in profundizar en deta l les dediseño que deberán ser concre tados poster iormente .

2.3.4 Descripciones funcionales. Pseudocódigo

Los requis i tos funcionales son una par te muy impor tante de laespecificación de un sistema. Por tanto, es esencial que las descripcionesfuncionales se rea l icen empleando una notación precisa y que no se prestea ambigüedades. Como mínimo se deberá ut i l izar un lenguaje naturalestructurado y siempre que sea posible es aconsejable utilizar una notacióna lgo más prec isa que denominaremos pseudocódigo .

Entenderemos por pseudocódigo una notación basada en un lenguaje deprogramación estructurado (Pascal, Modula-2, Ada, etc) del que se excluyentodos los aspectos de declaración de constantes, t ipos, variables ysubprogramas. El pseudocódigo maneja datos en genera l , no t iene unasintaxis estr icta, como sucede con los lenguajes de programación y sepueden incluir descr ipciones en lenguaje natura l s iempre que se considerenecesar io , como par te del pseudocódigo.

Hay que tener cuidado a l emplear pseudocódigo para rea l izar unaespecificación software. Si se detalla o "refina" demasiado una descripciónfuncional mediante pseudocódigo se puede estar rea l izando e l diseño delsistema e incluso su codificación. De hecho, existen notaciones similares alpseudocódigo que están pensadas para rea l izar e l diseño. En este caso, sehabla de lenguaje de descr ipción de prog ram as (PDL - Program Descr ipt ion

Language). Estos lenguajes para el diseño, se estudiarán en el tema de lasegunda unidad didáct ica dedicado a las técnicas genera les de diseño.Es im por tan te destacar que aunqu e se ut i licen notaciones parecidas(pseudocódigo o PDL), los objetivos que se persiguen son muy diferentes.Cuando se especifica se trata de indicar cual es la naturaleza del problemaa resolver sin detallar cómo se debe resolver. En este sentido, en unaespecificación no se debería establecer ninguna forma concreta deorganización de la información ni tampoco ninguna propuesta concre ta delos procedimientos de resolución de los problemas.



Especificación de So ftware 61La notación de las estructuras básicas que se pueden emplear en elpseudocódigo tendrán los s iguientes formatos:

A.- Selección:

SI <Pseudocódigo de la Condic ión> ENTONCES<Pseudocódigo>

SI-NO<Pseudocódigo>

FIN-SI

donde <Pseudocódigo de la Condic ión> es la condic ión que se debever ificar para efec tuar el <Pseu docódigo > indicado des pué s de EN TONCE So en caso contrario efectuar el <Pseudocódigo> indicado después de SI-NO.Por ejemplo, para el sistema de control de acceso tendríamos:

SI Datos Tar je ta son Correctos ENTON CESGuardar Datos Tar je ta ;Comprobar Clave

SI-NODevolver Tarjeta

FIN-SIEvidentemente , cuando se necesi ten se pueden anidar var ias se leccionesunas dentro de otras .

B.- Selección por casos:

CASO Especif icación del e lemento se lec tor>SI-ES <Descripción del caso 1> HACER <Pseudocódigo> ;

SI-ES <Descripción del caso 2> HACER <Pseudocódigo> ;SI-ES <Descripción del caso N> HACER <Pseudocódigo>;OTROS <Pseudocódigo>

FIN-CASO

donde <Especificación del elemento selector> determina el elemento con elque se efec túa la se lección. Este e lemento sólo podrá tomar un númeroacotado de valores dis t intos y según tome uno u otro se efec tuará e l<Pseudocódigo> correspondiente . El <Pseudocódigo> indicado después deOTROS se realizará cuando el valor del elemento no coincida con ninguno



62 Introd ucció n a la Ingeniería de So ftwarede los previstos. Por ejemplo, para seleccionar en un cajero automático elt ipo de operaciones que se pueden rea l izar dependiendo del t ipo de tar je taintroducida , se tendr ía :

CASO Tipo de Tar je taSI-ES Visa HAC ER Op eracion esSI-ES CuatroB HAC ER OperacionesSI-ES Express HAC ER Op eracion esOTROS Devolver Tar je ta

FIN-CASO

C.- I teración con pre-condiciónMIENTRAS <Pseudocódigo de la condic ión> HACER

<Pseudocódigo>FIN-MIENTRAS

que efectúa e l <Pseudocódigo> mientras que se ver if ique la condic iónindicada por <Pseudocódigo de la condic ión>.

D.- I teración con post-condiciónREPETIR

<Pseudocódigo>HASTA <Pseudocódigo de la condic ión>

que efectúa el <Pseudocó digo> hasta qu e se ver if ique la condic ión indicadapor <Pseu docód igo de la condic ión>. Por e jemplo, en el s is tema de controlde acceso, para comprobar la clave se pueden permitir hasta tres intentos:

REPETIRLeer ClaveHAS TA Clave correcta o Tres intento s incorrectos

E.- Número de i te rac iones conocido

PARA-CADA <Especif icación del e lemento índice> HACER<Pseudocódigo>

FIN-PARA

a crédito;en cuenta;con confirmación;



Especificación de So ftw are 63donde <Especificación del elemento índice> indica el número de veces quese efectúa el <Pseudocódigo>. Por ejemplo, si se quieren listar todos losaccesos realizados en el sistema de control de acceso, se podría indicar:

PARA -CADA Acceso regis trado HAC EREscribir datos del acceso;Escribir resultado del acceso

FIN-PARA

235 Descripción de datos

La descr ipción de los datos const i tuye otro aspecto fundamenta l de unaespecificación software. Se trata de detallar la estructura interna d e los datosque maneja el sistema. Lo mismo que sucede con la descripción funcional,cuan do se rea liza una descr ipción de da tos no se debe descender a deta l lesde diseño o codificación. Sólo se deben describir aquellos datos que resultenre levantes para entender que debe hacer e l s is tema.

En pr incipio, también los datos se pueden descr ibir ut i l izando e l lenguajenatural, sin embargo es mejor emplear notaciones más específicas. Unaposible solución es utilizar la notación usada para definir t ipos de datos enalguno de los lenguajes estructurados habituales (Pascal, Modula-2 o Ada).Sin embargo, es ta solución t iene como inconveniente fundamenta l la grandependencia de una sintaxis concreta y la necesidad de detallar aspectospropios de la fase de diseño o codificación tales como el tamaño o el t ipoconcreto de cada elemento.

La notación adoptada en la metodología de anál is is es tructurado es lo que

se conoce com o diccionario de datos [Yourdon90]. Esta notac ión es bastantemás informal que cualquier def inic ión de t ipos de un lenguaje deprogramación pero con ella se logra una descripción de los datossuficientemente precisa para la especificación de requisitos.

Aunque exis ten diversos formatos posibles de diccionario de datos segúnlos dis t intos autores o herramientas CASE que lo incorporen, en esenciatodos los formatos aconsejan que a l menos se pueda descr ibir la s iguienteinformación para cada dato:



64 Introducción a la Ingeniería de Softw areA.- Nombre o nombres:

Será la denominación con la que se utilizará este dato en el resto de laespecificación. Puede ocurrir que para mayor claridad de la especificaciónse uti l icen dist intos nombres para datos que t ienen una misma descripción.

B.- Utilidad:

Se indicarán todos los procesos, descripciones funcionales, almacenes dedatos, etc. en los que se utilice el dato.

C.- Estructura:Se indicarán los elementos de los que está consti tuido el dato, ut i l izando lasiguiente notación:

A + B Secuencia o concatenación de los eleme ntos A y B

[ A | B ] Selección entre los distintos elementos A o bien B

{ A } N Repetición N veces del elemento A (se omite N si esindeterminado)

( A ) Opcionalmente se podrá incluir el elemento A

/ descripción / Descripción en lenguaje natura l com o com entarios

= Separador ent re el nom bre de un elemento y sudescripción

Para i lustrar una descripción de datos, a continuación se detallan algunos

de los datos del sistema de control de acceso:Nom bres: Datos Tarjeta ,

Grabar Tarjeta

Util idad: Proceso: Co m prob ar Tarjeta com o entra daProceso: Comprobar Tarjeta como salidaAlmacén de datos: Información de Accesos como entradaEntidad externa: Lector de Tarjetas como salida



Especificación de So ftwa re 65Estructura : No m bre +

Pr imer Apell ido +Segundo Apell ido +Nivel de Acceso +Clave +( Có d ig o e mp r e s a )

N o m b r ePr imer Apell ido =Segundo Ape l l ido =Nivel de Acceso =

Código empresa =Nombre: Clave

/Ris t r a con 10 ca rac te res máximo//Ris tra con 20 ca rac te res máximo//Ris t r a con 20 ca rac te res máximo/[ 0 | 1 | 2 ]

[ 101 I 102 I ... I 199 ]

Uti l idad: Proceso: Co m prob ar Clave como entrad a

Estructura : { Dígito } 4

Dígito = / Carácter nu m érico del 0 al 9 /

2.3.6 Diagram as d e modelo de d a tos

Si un sistema maneja una cierta cantidad de datos relacionados entre sí,como sucede habitualmente en los s is temas de información, es necesar ioestablecer una organización que facilite las operaciones que se quierenrealizar con ellos. Por ejemplo, si tenemos datos de países, regiones,ciuda des, etc. y en tre ellos existen ciertas relaciones tales como: un a ciud ades capi ta l de un determinado país o un país t iene embajada en unadeterminada c iudad o una c iudad esta en una determinada región, e tc . ,inm edia tam ente su rge la necesidad d e es tablecer una organización entre losdatos que simplif ique y agilize su utilización. Precisamente dicha

organización es la que configura la estructura de la base de datos queutilizará el sistema.Es fundamental que en la especificación se establezca el modelo de datosque se considera más adecuado para conseguir todos los requis i tos del (

s is tema. Este mod elo se conoce como mo delo ent idad-re lac ión (modelo E-R)y permite def inir todos los datos que manejará e l s is tema junto con lasrelaciones que se desea que existan entre ellos. Aunque el modelo estarásujeto a revisiones durante las fases de diseño y codificación, como sucedecon el resto de la especificación, sin embargo, es un punto de partidaimprescindible para comenzar cualquier diseño.



66 Introdu cción a la Ingeniería de So ftware

Entidad

Min : Max

Relación entre entidades/datos

Entidad/Datos relacionados

Cardinalidad entre Mínimo y Máximo

Sentido de la relación

F i g u r a 2 . 6 . N o t a c i ó n b á s i c a d e d i a g r a m a s d e d a t o s

Existen diversas propuestas de notación para rea l izar los diagramas E-R,aunque entre todas ellas las diferencias son mínimas. En la f igura 2.6 serecogen los e lementos d e la notación m ás habituales . Las ent idad es o datosque se manejan en e l diagrama se encier ran dentro de un rec tángulo, porejemplo: ciudad, país, región, etc. Las relaciones se indican mediante unrom bo qu e encierra el t ipo de relación, por ejemplo: es capital de, t ieneembajada en, está en, etc.

Las entida des y la relación que se establece entre ellas se indican unié ndo lastodas mediante l íneas . Opcionalmente , se puede indicar e l sent ido de la

relación con una f lecha. Es conveniente utilizar la f lecha sobre todo cuandoúnicamente con e l nombre de la re lac ión encerrado en e l rombo no quedaclaro cual es su sentido.

Otro elemento fundamental es la cardinalidad de la relación, esto es, entreque valores mínimo y máximo se mueve la re lac ión entre ent idades. Pore jemplo, un país puede no tener embajada en ninguna c iudad o tener las enmuchas. En los diagramas E-R, la cardinal idad se indica según se muestraen la f igura 2.7, donde cero es un círculo, uno es una raya perpendicular ala línea de relación y muchos o N son tres rayas en bifurcación. La



Especificación de So ftwa re 67cardinal idad se dibuja s iempre unida a la segunda ent idad de la re lac ióncon un s ímbolo para e l va lor mínimo y otro para e l máximo.

Cardinalidad

O f 0 : 1 o < 0 : N

- + f 1 = 1 K 1 : N

Fig u ra 2 .7 . No tac ió n p ara l a ca rd in a l id ad

Para explicar mejor todo esto, veamos la figura 2.8. Inicialmente la relación"Capital" es ambigua dado que no queda claro si se trata de "es Capital de"o de "tiene como capital". La flecha nos aclara, en este caso, que la relaciónprincipal del diagrama es "es Capital". Teniendo en cuenta la cardinalidadunida a la segunda ent idad, tenemos la re lac ión: Una c iudad puede ser lacapita l de ningún país o ser lo como máximo de uno.

Figura 2 .8 . Diagrama E-R senci l lo

También en el mismo diagrama se indica la relación inversa: Un país tienecomo capital una y sólo una ciudad. Esta es la razón de utilizar nombresambiguos para las re lac iones, que se puedan emplear en ambos sent idos yasí se prescindirá de la flecha. En la figura 2.9 se tiene el diagrama E-R delsistema completo, cuya interpretación resulta tr ivial.



68 Introdu cción a la Ingen iería de So ftware

2.4 Documento de espec i f icac ión de requis i tos

El documento de especif icación de requis i tos , denominadoS O F T W A R E

R E Q U I R E M E N T S D O C U M E N T ( S R D ) O S O F T W A R E R E Q U I R E M E N T S S P E C I F I C A T I O N(SRS) en la literatura anglosajona, es el encargado de recoger todo el frutodel t rabajo rea l izado durante la e tapa de anál is is de l s is tema de una formaintegra l en un único documento.

Pueden existir otros documentos previos al SRD, tales como los estudios deviabilidad o los estudios de las diversas alternativas posibles, centradosfundamenta lmente en los aspectos de la gest ión del proyecto. También esposible , cuando e l proyecto es muy amplio y se prolonga mucho en e lt iempo, que se e labore un documento con la his tor ia del proyecto y todas

las vic is i tudes habidas , de las que se podrán sacar enseñanzas en futurosproyectos . Todo s estos doc um ento s t ienen una ut i l idad concre ta pero no sonimprescindibles , s in embargo, e l SRD es un documento fundamenta l y ese l punto de par t ida del desarrol lo de cualquier s is tema sof tware .

Con carácter general, el SRD debe cubrir todos los objetivos indicados enel apar tado 2.2. Además, dado que será un documento que deberá serrevisado con cierta frecuencia a lo largo del desarrollo de la aplicación, esmuy conveniente que se redacte de una forma fác i l de modif icar . Por otrolado, también debe facilitar la labor de verif icación del cumplimiento de lasespecificaciones. Todo esto hace que la mejor manera de redactar este



Especificación de So ftwa re 69documento sea en forma de un contra to con sus dis t intas c láusulasorganizadas y agrupadas según e l carácter de los requis i tos .Son muy numerosas las propuestas de organización del documento SRD.Se puede decir que práct icamente cada autor propone uno dis t into. Sinembargo, en líneas generales todas las propuestas son similares. Diversosorganismos internacionales tales como IEEE [IEEE84], el Departamento deDefensa nor teamer icano [ D 0 D 8 8 ] o la Agencia Espacial Europea [ESA91]han establec ido su propia organización de documentos y los imponen a lasempresas que contra tan para evi tar e l caos que supondr ía la coordinaciónde miles de proyectos cada uno con una organización dis t inta de la

documentac ión .A continuación se sugiere un modelo de documento SRD basado en lapropuesta de la Agencia Espacial Europea [ESA91]. Este documento tieneun carácter genera l y en a lgunos casos no será necesar io cumplimentartodos sus apar tados. El índice del documento propuesto se recoge en e lcuadro 2.1. El contenido de cada apartado debería ser el siguiente:

1. INTRODU CCIÓN

Esta sección debe dar una vis ión genera l de todo e l documento SRD.

1.1 Objetivo

Debe exponer brevemente el objetivo del proyecto, a quién va dir igido, losparticipantes y el calendario previsto.

1.2 Ámbito

En esta subsección se identif icará y dará nombre al producto o losproductos resul tantes del proyecto. Asimismo, se explicará qué hace cada

uno y si se considera necesario que no será capaz de hacer. También sedetallarán de manera precisa las posibles aplicaciones y beneficios delproyecto.

1.3 Definiciones, siglas y abreviaturas

Aquí se incluirá un glosario que contendrá una lista de definiciones detérminos, s iglas y abrevia turas par t iculares ut i l izados en e l documento, yque conven ga reseñar p ara fac i li ta r su lec tura o evi tar am bigüe dades . T odaesta información organizada y c las if icada convenientemente , se podrárecoger también en uno o var ios apéndices a l f ina l de l documento.



70 Introdu cción a la Ingeniería de So ftwa re

1. INTRODUCCIÓN1.1 O bjetivo1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias1.5 Panorámica del documento

2. DESCRIPCIÓN GENERAL2.1 Relación con otros proyectos

2.2 Relación con proyectos anteriores y posteriores2.3 Objetivo y funciones2.4 Consideraciones de entorno2.5 Relaciones con otros sistemas2.6 Restricciones generales2.7 Descripción del modelo

3. REQUISITOS ESPECÍFICOS3.1 Requisitos funcionales3.2 Requisitos de capacidad3.3 Requisitos de interfase

3.4 Requisitos de operación3.5 Requisitos de recursos3.6 Requisitos de verificación3.7 Requisitos de pruebas de aceptación3.8 Requisitos de documentación3.9 Requisitos de seguridad3.10 Requisitos de transportabilidad3.11 Requisitos de calidad3.12 Requisitos de fiabilidad3.13 Requisitos de mantenibilidad3.14 Requisitos de salvaguarda

4. APÉNDICESCu ad ro 2 .1 . In d ice d e l d o cu men to SRD

1.4 Referencias

Si el documento contiene referencias concretas a otros, se dará una lista conla descr ipción bibl iográf ica de los docum entos referenciados y la man era deobtener acceso a dichos documentos. Si fuera necesario, también en este

caso se remitirá a un apéndice posterior .



1.5 Panorámica del documentoEspecificación de So ftwa re 71

Esta subsección describirá la organización y el contenido del resto deldocumento .

2. DESCRIPCIÓN GENERAL

En esta sección se dará una visión general del sistema, ampliando elcontenido de la sección de introducción. Constará de los siguientesapa r tados :

2.1 Relación con otros proyectosSe describirán las analogías y diferencias de este proyecto con otrossimilares o complementarios, o con otros sistemas ya existentes o endesarrollo. Si no hay proyectos o sistemas relacionados, se indicará "Noaplicable".

2.2 Relación con proyectos anteriores y posteriores

Se indicará si este proyecto es continuación de otro o si se continuará eldesarrollo en proyectos posteriores. Si no hay proyectos de esta clase, seindicará "No existen".

2.3 Objetivo y funciones

Se debe describir el sistema en su co njun to con los objetivos y las funcione sprincipales.

2 .4 Consideraciones de entorno

En este apartado se describirán las características especiales que debe tenerel entorno en que se utilice el sistema a desarrollar . Si no se necesitancaracterísticas especiales, se indicará "No existen".

2.5 Relaciones con otros sistemas

Se describirán las conexiones del sistema con otros, si debe funcionarintegrado con ellos o utilizando entradas o salidas indirectas deinformación. Si el sistema no necesita intercambiar información con ningúnotro, se indicará "No existen".



72 Introducción a la Ingeniería de Softw are2.6 Restricciones generales

Se describirán las restricciones generales a tener en cuenta a la hora dediseñar y desarrollar el sistema, tales como el empleo de determinadasmetodologías de desarrol lo , lenguajes de programación, normaspart iculares, restricciones de hardware, de sistema operativo, etc.

2.7 Descripción del modelo

Este será probablemente el apartado más extenso de esta sección. Debedescribir el modelo conceptual que se propone para desarrollar el sistema

en su conjunto y para cada una de sus partes más relevantes. Este modelose pue de realizar uti l izando toda s las notaciones y herra m ientas disponibles.

3. REQUISITOS ESPECÍFICOS

Esta sección es la fundamental del documento. Debe contener una l istadetallada y completa de los requisi tos que debe cumplir el sistema adesarrollar.

Los requisi tos deben exponerse en la forma más precisa posible, pero sin

que la descripción de un requisi to individual resulte demasiado extensa. Sifuera necesario, puede darse una descripción resumida y hacer referenciaa un Apéndice con la descripción detallada.

Es importante no incluir en los requisi tos aspectos de diseño o desarrollo.Los requisi tos son lo mínimo que se impone al sistema, y no hay quedescribir soluciones particulares que no sea obligatorio utilizar (exceptocomo aclaración o sugerencia).

Es ventajoso enunciar los requisi tos en forma de una l ista numerada, para

facil i tar su seguimiento y la validación del sistema. Cada requisi to debe iracompañado de una indicación del grado de cumplimiento necesario, esdecir, si es obligatorio, recomendable o simplemente opcional .

Los requisi tos se agruparán en los apartados que se indican a continuación.Si no hay requisitos en alguno de ellos, se indicará "No existen".

3.1 Requisi tos funcionales

Son los que d escriben las func iones o el QUÉ d ebe hacer el sistema y estánmuy l igados al modelo conceptual propuesto. Aquí se concretarán las



Especificación de So ftwa re 73operaciones de tratamiento de información que realiza el sistema, talescomo a lmacenamiento de información, generación de informes, cá lculos ,estadísticas, operaciones, etc.

3.2 Requisitos de capacidad

Son los referentes a los volúmenes de información a procesar , t iempo derespuesta, tamaños de f icheros o discos, etc. Estos requisitos debenexpresarse mediante valores numéricos e inc luso, cuando sea necesar io , sedarán valores para el peor, el mejor y el caso más habitual.

3.3 Requisitos de interfaseSon los referentes a cualquier conexión a otros sistemas (hardware osoftware) con los que se debe interactuar o comunicar. Se incluyen, portanto, bases de datos, protocolos, formatos de f icheros, sistemas operativos,datos, etc. a intercambiar con otros sistemas o aplicaciones.

3.4 Requisitos de operación

Son los referentes al uso del sistema en general e incluyen los requisitos dela interfase de usuario (menús de pantalla, manejo de ratón, teclado, etc.) ,

e l a r ranque y parada , copias de segur idad, requis i tos de insta lac ión yconf iguración.

3.5 Requisitos de recursos

Son los referentes a elementos hardware, software, instalaciones, etc. ,necesar ios para e l funcionamiento del s is tema. Es muy impor tante es t imarlos recursos con cierto coeficiente de seguridad en previsión de necesidadesde última hora no previstas inicialmente.

3.6 Requisitos de verif icación

Son los que debe cumplir el sistema para que sea posible verif icar ycertif icar que funciona correctamente (funciones de autotest, emulación,simulación, etc.).

3.7 Requisitos de pruebas de aceptación

Son los que deben cumplir las pruebas de aceptación a que se someterá e ls is tema.



74 Introducción a la Ingeniería de Softw are3.8 Requisi tos de documentación

Son los referentes a la docum entación q ue debe fo rmar par te del pro ductoa entregar.

3.9 Requisi tos de seguridad

Son los referentes a la protección del sistema co ntra cualquier ma nipulacióno utilización indebida (confidencialidad, integridad, virus, etc.).

3.10 Requisi tos de transportabil idad

Son los referentes a la posible uti l ización del sistema en diversos entornoso sistemas operativos de una forma sencil la y barata.

3.11 Requisitos de calidad

Son los referentes a aspectos de calidad, que no se incluyan en otrosapar t ados .

3.12 Requisitos de fiabilidad

Son los referentes al límite aceptable de fallos o caídas durante la operacióndel sistema.

3.13 Requisi tos de mantenibil idad

Son los que debe cumplir el sistema para que se pueda realizaradecuadamente su mantenimiento durante la fase de explotación.

3.14 Requisi tos de salvaguarda

Son los que debe cumplir el sistema para evitar que los errores en elfuncionamiento o la operación del sistema tengan consecuencias graves enlos equipos o las personas.

APÉNDICES

Se incluirán como apéndices todos aquellos elementos que completen elcontenido del documento, y que no estén recogidos en ot ros documentosaccesibles a los que pueda hacerse referencia.



Especificación de So ftwa re 75

2 .5 E jem p lo s de espec i f icac iones

En este apartado se recogen las especificaciones completas de dos sistemas,que se irán desarrollando a lo largo del libro.

25.1 Videojuego de las minas

El documento SRD para e l videojuego de las minas es e l s iguiente :

DOCUMENTO DE REQUISITOS DEL SOFTWARE (SRD)

Pr oyecto: JUE GO DE LAS MIN AS (Versión Simple)Autor es: J .A. Cerrad a y R. Góm ez Fecha: En ero 1999Documento: MINAS-SRD-99

CONTENIDO1. INTRODUCCIÓN

1.1 Objetivo1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias1.5 Panorámica del documento

2. DESCRIPCIÓN GENERAL2.1 Relación con otros proyectos2.2 Relación con proyectos anteriores y posteriores2.3 Objetivo y funciones2.4 Consideraciones de entorno2.5 Relaciones con otros sistemas2.6 Restricciones generales2.7 Descripción del modelo

3. REQUISITOS ESPECÍFICOS3.1 Requisitos funcionales3.2 Requisitos de capacidad3.3 Requisitos de interfase3.4 Requisitos de operación3.5 Requisitos de recursos3.6 Requisitos de verificación3.7 Requisitos de pruebas de aceptación3.8 Requisitos de documentación3.9 Requisitos de seguridad3.10 Requisitos de transportabilidad3.11 Requisitos de calidad3.12 Requisitos de fiabilidad3.13 Requisitos de mantenibilidad3.14 Requisitos de salvaguarda



76 Introducción a la Ingeniería de Softw are1. INTRODUCCIÓN1.1 Objetivo

Se trata de realizar un videojuego denominado "Juego de las Minas" cuyas reglas y característicasgenerales se detallan en los siguientes apartados de este documento.

La utilización de este videojuego deberá ser fácil de aprender sin necesidad de la lectura previa deningún manual. En todo caso, el juego dispondrá de las correspondientes ayudas para facilitar suaprendizaje.

1.2 Ámbito

En este proyecto se realizará una versión simple del videojuego que solamente utilizará pantallaalfanumérica y teclado.


Tablero: Elemento gráfico que se muestra en la pantalla del computador con forma de cuadrículay en el que se desarrolla el juego.

Casilla: Cada uno de los elementos de los que está formada la cuadrícula del tablero.

Mina: Elemento oculto en una casilla del tablero y que si se destapa provoca la finalización deljuego de manera infructuosa para el jugador.

1.4 Referencias

No aplicable

1.5 Panorámica del documento

En el resto de este documento se recogen el modelo conceptual, las reglas del juego y los requisitosque debe cumplir el sistema a desarrollar.


2.1 Relación con otros pr oyectos

Ninguna.

2.2 Relación con pr oyectos anteriores y posteriores

En este desarrollo se abordará una versión simple que utilizará una interfase de usuario parapantalla alfanumérica y teclado. En una fase posterior, se desarrollará una versión más elaboradaque utilizará pantalla gráfica y ratón. El desarrollo de esta versión simple y la posterior deberádiferir solamente en los módulos específicos dedicados a la interfase hombre-máquina.



Especificación de Sof tw are 772.3 Objetivo y funciones

El objetivo es realizar una versión simplificada del juego de las minas. En este juego se trata dedescubrir dentro del tablero la situación de las minas sin que ninguna de ellas explote y en el menortiempo posible.

Las funciones básicas serán:

• Selección del nivel de dificultad del ju ego (bajo, med io, alto)• Desarr ollo de la partida según las reglas de juego• Elabor ación y man tenimiento de la tabla de mejor es r esultados

• Ayudas al jugador

2.4 Consideraciones de entorno

No existen

2.5 Relación con otros sistemas

No existen

2.6 Restricciones generales

Para la realización de este proyecto se deberán utilizar las siguientes herramientas y entornos:

Lenguaje de progra mación: Modu la-2Metodología: Desarr ollo modular basado en abstra ccionesSistema opera tivo: DO S ver sión 3.0 o posteriorMá ximo personal: 1 persona

2.7 Descripción del modelo

En el juego se emplea un tablero cuadrado de N casillas de lado semejante al que se muestra en lafigura M.l. En este tablero están ocultas un número determinado de minas que pueden estarsituadas en cualquier casilla. Inicialmente se muestra el tablero con todas las casillas tapadas. Enel ejemplo de la figura M. 1, las casillas tapadas están en blanco. El jugador tiene que ir destapandolas casillas para descubrir la situación de las minas. Cuando se destapa una casilla que tiene unamina, esta mina explota y se acaba el juego infructuosamente. El objetivo del juego es encontrarla situación de todas las minas sin que explote ninguna de ellas.Para facilitar la búsqueda de todas las minas, el jugador podrá marcar una casilla cuando tenga lacerteza de que en ella existe una mina. En la figura M.l la marca se indica con el símbolo "!!".Esta marca impide que pueda ser destapada la casilla por error. El jugador también podrá quitarla marca de una casilla. En todo momento se mostrará en pantalla el número de minas ocultas ytodavía no marcadas.

El jugador podrá seleccionar el grado de dificultad del juego entre tres niveles: ba jo, medio y alto.En cada nivel se empleará un tamaño distinto de tablero y el número de minas a descubrir tambiénserá distinto. La situación de las minas en el tablero se realizará de forma aleatoria.



78 In troducc ión a la Ingenier ía de Softw are

F i gu ra M . l . T ab l e ro de l j uego de la s m inas

Cada vez que el jugador destapa una casilla, se deberá indicar si tenía una mina, en cuyo casofinaliza el juego, o el número de minas que rodean la casilla que ha sido destapada. En la figuraM.l las casillas con el símbolo ".." indican que el número de minas que las rodean son cero. Elnúmero de minas que pueden rodear una casilla pueden ir desde 0 hasta 8.

El ju ego dispondrá de un cronómetr o que actualiza en pa ntalla cada segundo el tiempo transcurridodesde el comienzo de la última partida. Si el jugador consigue descubrir todas las minas, elprograma registrará el tiempo invertido junto con el texto que desee poner el jugador y actualizará

la lista de los mejores tiempos registrados en el nivel correspondiente: bajo, medio o alto.2.7.1 Descripción de datos

Los principales datos que se utilizan son los siguientes:

Nombre: Tablero

Estructur a: tama ño del tab lero + n° de minas + { inform ación de casilla }inform ación de casilla = si/no mina +

si/no destapada +si/no marcada



Especificación de So ftwa re 79Nombre: Mejor es resultados

Estructur a: { inform ación resultado }inform ación resultado = Texto del ganador +

nivel dificultad +tiempo invertido

2.7.2 Diagra ma de transición de estados

El diagrama de estados del sistema se muestra en la figura M.2

3. REQUISITOS ESPECÍFICOS3.1 Requisitos funcionales

R. 1.1: Las reglas del juego son las siguientes:

R. 1.1.1: El juego se iniciará al destapar la primera casilla.

R. 1.1.2: Al iniciarse el juego se pondrá el cronómetro en marcha y se situarán de formaaleatoria las minas en el tablero

R. 1.1.3: El cronómetro se actualizará cada segundo



80 In troducción a la Ingenier ía de Softw areR. 1.1.4: En cada paso del juego, el jugador puede destapar una casilla, marcar en una

casilla la presencia de una mina o quitar la marca puesta en cualquier pasoanterior.

R. 1.1.5: Al destapar una casilla que tiene una mina se acaba el juego de forma infructuosapara el jugador y se muestra la situación de todas las minas.

R. 1.1.6: Al destapar una casilla que no tiene mina se informa al jugador del número deminas que rodean la casilla destapada.

R. 1.1.7: Cua ndo se destapa una casilla que no tiene ninguna m ina a su alrededor ,automáticamente también se destapan todas las casillas que la rodean. Esterequisito se cumplirá de forma recursiva con las nuevas casillas destapadas.

R. 1.1.8: Cuando se marca la presencia de una mina en una casilla se impide que dichacasilla pueda ser destapad a mientr as no se quite la ma rca.

R.l.1.9: A una casilla marcada se le puede quitar la marca

R. 1.1.10: El jugador consigue su objetivo cuando todas las casillas que no tienen mina hansido destapadas. En este momento se para el cronómetro indicando el tiempoinvertido.

R.1.2: En todo momento el jugador estará informa do de los segundos tr anscurr idos y de las minasque todavía quedan por marcar del total de minas ocultas inicialmente.

R.1.3: El jugador en cualquier momento podrá cambiar el nivel de dificultad del juego entre lostres siguientes: bajo, medio y alto. Por defecto estará seleccionado el nivel medio. Estosniveles representarán distintos tamaños del tablero y un número diferente de minas ocultas.

R. 1.4: El jugador puede registrar el texto que quiera, junto al tiempo invertido, en la tabla de losmejores resultados y dentro del nivel de dificultad en el que se realizó el juego.

R.1.5: El jugador en cualquier momento podrá finalizar el juego.

R. 1.6: La tabla con los mejores resultados no se borrará nunca al apagar el computador.

R. 1.7: Para reinicializar la tabla de resultados existirá una opción especial no accesible a cualquier

jugador.R. 1.8: La situación inicial de las minas en el tablero será aleatoria y deberá dar lugar a un reparto

aproximadamente uniforme en todo el tablero.

R. 1.9: (Requisito deseable) Se dispondrá de una ayuda con las reglas del juego que podrá serconsultada solamente antes de comenzar o al finalizar un juego.

R. 1.10: El juego dispondrá de una ayuda simplificada que podrá ser consultada en cualquiermom ento y que explicará las teclas que se pued en utilizar dur ante el ju ego y la funciónde cada una.



Especificación de So ftw are 813.2 Requ isitos de capacidad

R.2.1: Precisión del cronómetro < 0.1 segundo

R.2.2: Respuesta al pulsar una tecla < 0.1 segundo

R.2.3: T iemp o para situar inicialmente las minas < 1 segundo

3.3 Requisitos de interfase

R.3.1: Para la presentación del tablero en pantalla será necesario al menos disponer de una pantallade tipo alfanumérico.


Además de los indicados en el apartado de descripción del modelo respecto a la estructura deltablero, casillas, etc., se deberán cumplir los siguientes:

R.4.1: En todo momento y dentro del tablero deberá señalarse claramente la casilla en la que estásituado el jugad or.

R.4.2: Para m over se de una casilla a otra de las que la r odean sólo será necesar io pulsar una teclauna sola vez.

R.4.3: Para destapar, marcar o desmarcar una casilla sólo será necesario pulsar una tecla una solavez.

R.4.4: El cambio de nivel de dificultad se realizará de form a rotativa (bajo - > medio - > alto - >bajo) con sólo pulsar una tecla una sola vez. El cambio de nivel reiniciará el nuevo tablerode juego.

R.4.5: Para finalizar el juego o mostrar las ayudas del juego sólo será necesario pulsar una teclauna vez.

3.5 Requ isitos de r ecursos

R.5.1: Este sistema no requiere recursos especiales para su utilización y podrá ser ejecutado encualquier instalación básica basada en un PC compatible con la configuración mínimasiguiente:

• CPU: 486 o posterior• Memoria: 640 Kbytes o más• Pantalla: cualquiera con modo texto de 80 X 25 caracteres• Disquete: VA pulgadas o 514 pulgadas• No necesita disco duro



82 In troducción a la Ingenier ía de Softw are3.6 Requ isitos de ver ificación

R .6.1: (Requisito deseable) Se dispondrá de un modo a uxiliar para depur ación en el que el tableroserá "transparente" y en el que el jugador conoce la situación de todas las minas a priori.

3.7 Requ isitos de pr uebas de aceptación

Ninguno.

3.8 Requ isitos de docum enta ción

R.8.1: El videojuego estará autodocumentado con las funciones de ayuda previstas

3.9 Requisitos de seguridad

R.9.1: (Requisito deseable) Se dispondrá de algún mecanismo de protección contra la copiaindiscriminada del programa.

3.10 Requisitos de transportabilidad

Ninguno.

3.11 Requ isitos de calidad

No aplicable.

3.12 Requisitos de fiabilidad

No aplicable.

3.13 Requ isitos de mantenibilidad

No aplicable.

3.14 Requisitos de salvaguarda

No aplicable.



Especificación de Softw are 83

2.5.2 Sistema de gestión de biblioteca

Se trata de informatizar la gestión del préstamo de libros en una bibliotecarelativamente pequeña, atendida por una sola persona. En esta biblioteca sepueden consultar libros en la sala de lectura, sin ningún control especial, ytambién se pueden sacar l ibros en préstamo, en forma controlada .

Para sacar libros en préstamo el usuario debe estar dado de alta en unregistro d e lectores, en el que hab rá una f icha por cada usuar io, co nteniendosus datos personales .

Los libros estarán catalogados. Habrá un registro de libros con una f ichapor cada uno, conteniendo los datos fundamenta les: t í tulo, autor , mater iasde que trata, etc.

Cuando un libro se saque en préstamo, se anotará en la f icha del libro aquién está prestado. Un mismo lector puede tener a la vez varios libros enpréstamo, hasta un límite f ijo. También hay un límite f ijo para el númerode días que se puede tener prestado un l ibro. Pasado ese plazo s in que sehaya devuelto el l ibro, el bibliotecario avisará por teléfono al lector morosopara que realice la devolución.

El s is tema informático se usará también como ayuda para localizar los librossol ic i tados por los usuar ios , permit iendo rea l izar búsquedas en e l ca tá logode libros, bien por autor, t í tulo o materia.

A continuación se presenta un ejemplo de lo que podría ser el SRD de estesistema, recogiendo el análisis realizado con la metodología de ANÁLISISE S T R U C T U R A D O .



84 Introdu cción a la Ingen iería de So ftwareDOCUMENTO DE REQUISITOS DEL SOFTWARE (SRD)

Proyecto: SISTEMA DE GESTIÓN DE BIBLIOTEC AAutores: M. Collado y J .F. Estivar izFecha: Ma yo 1999Documento: BEBLIO-SRD-99

CONTENIDO1. INTRODUCCIÓN

1.1 Objetivo1.2 Ámbito

1.3 Definiciones, siglas y abreviaturas1.4 Referencias1.5 Panorámica del documento

2. DESCRIPCIÓN GENERAL2.1 Relación con otros proyectos2.2 Relación con pr oyectos anteriores y posteriores2.3 Objetivo y funciones2.4 Consideraciones de entorno2.5 Relaciones con otros sistema s2.6 Restricciones generales2.7 Descripción del modelo

3. REQUISITOS ESPECÍFICOS3.1 Requisitos funcionales3.2 Requisitos de capacidad3.3 Requ isitos de interfase3.4 Requisitos de operación3.5 Requ isitos de r ecursos3.6 Requisitos de verificación3.7 Requ isitos de pr uebas de aceptación3.8 Requisitos de documentación3.9 Requisitos de seguridad3.10 Requisitos de transportabilidad3.11 Requisitos de calidad3.12 Requisitos de Habilidad3.13 Requisitos de mantenibilidad3.14 Requisitos de salvaguarda

1. INTRODUCCIÓN1.1 Objetivo

El objetivo del sistema es facilitar la gestión de una biblioteca mediana o pequeña, en lo referentea la atención directa a los usuarios. Esto incluye, fundamentalmente, el préstamo de libros, asícomo la consulta bibliográfica.



Especificación de So ftware 851.2 Ámbito

El sistema a desarr ollar se denominará BIBLIO -1, y consistirá en un único programa que r ealizarátodas las funciones necesarias. En particular, deberá facilitar las siguientes:

• Gestión del pr éstamo y devolución de libros• Consulta bibliográ fica por título, autor o mater ia

El sistema no ha de soportar, sin embargo, la gestión económica de la biblioteca, ni el control deadquisición de libros, ni otras funciones no relacionadas directamente con la atención a los usuarios.

El sistema facilitará la atención al público por parte de un único bibliotecario, que podrá atendera todas las funciones.

1.3 Definicion es, siglas y abr eviatur as

Ninguna.

1.4 Referencias

Ninguna.

1.5 Panorámica del documentoEl resto de este documento contiene una descripción del modelo del sistema, en la Sección 2, y lalista de requisitos específicos en la Sección 3.

Para confeccionar el modelo se ha aplicado la metodología de ANÁLISIS ESTR UC TUR ADO. L osdiagramas de flujo de datos se han incluido en la Sección 2, así como el diccionario de datos y eldiagrama Entidad-Relación correspondiente al modelo de datos. Las especificaciones de procesos(funciones) se han incluido en el apartado 3.1 Requisitos funcionales.


2.1 Relación con otros pr oyectos

Ninguna.

2.2 Relación con pr oyectos anteriores y posteriores

Ninguna.



86 In troducción a la Ingenier ía de Softw are2.3 Objetivo y funciones

La biblioteca dispone de una colección de libros a disposición del público. Cualquier persona puedeconsultar los libros en la sala de lectura, sin necesidad de realizar ningún registro de esta actividad.

Los libros pueden ser también sacados en préstamo por un plazo limitado, fijado por laorganización de la biblioteca, y siempre el mismo. En este caso es necesario mantener anotados loslibros prestados y qué lector los tiene en su poder. Para que un lector pueda sacar un libro enpréstamo debe disponer previamente de una ficha de lector con sus datos, y en particular conindicación de su teléfono, para facilitar la reclamación del libro en caso de demora en sudevolución.

Un lector puede tener a la vez varios libros en préstamo, hasta un máximo fijado por la

organización de la biblioteca, igual para todos los usuarios.Los usuarios deben disponer de algunas facilidades para localizar el libro que desean, tanto si espara consultarlos en la sala como si es para sacarlos en préstamo. Se considera razonable poderlocalizar un libro por su autor, su título (o parte de él) o por la materia de que trata. Para labúsqueda por materias, existirá una lista de materias establecida por el bibliotecario. Cada libropodrá tratar de una o varias materias.

El objetivo del sistema es facilitar las funciones más directamente relacionadas con la atencióndirecta a los usuarios de la biblioteca. Las funciones principales serán:

• Anotar los pr éstamos y devolucion es• Indicar los pr éstamos que hayan sobrepa sado el plazo establecido• Búsquedas por autor, título o mater ia

Como complemento serán necesarias otras funciones, en concreto:

• Man tener un r egistro de los libr os

• Ma ntener un r egistro de los usuar ios (lectores)

2.4 Consideraciones de entorno

Ninguna.

2.5 Rela ciones con otros sistema sNinguna.

2.6 Restricciones generales• El sistema se desarr ollar á y documenta rá emp leando la metod ología de an álisis y diseño

estructurado.• La implementación se hará sobre una base de datos relacional.• El programa deberá poder ejecutar se en máquinas de poca capacidad y con sistemas

operativos sencillos, sin soporte de multitarea, tal como MS-DOS en PCs.



Especificación de So ftw are 87

2.7 Descripción del modeloEl sistema de gestión de biblioteca será operado por una sola persona, que dispondrá de un terminalcon pantalla y teclado. También existirá una impresora por la que podrán obtenerse listados y fichasde los libros y de los lectores. Esta organización se refleja en el Diagrama de Contexto que semuestra en la figura B . l .

Orden

F i g u r a B . l . D C . D i a g r a m a d e c o n t e x t o

Ficha de libro

F i g u r a B . 2 . D F D . O G e s t i ó n d e l a b i b l i o t e c a



88 In troducción a la Ingenier ía de Softw areLa operación del sistema se hará mediante un sistema de menús para seleccionar la operacióndeseada, y con formularios en pantalla para la entrada y presentación de datos. Las funciones arealizar se pueden organizar en varios grup os principales, tal como se indica en el diagrama de flujode datos de la figura B.2. Estos grupos de funciones se describen a continuación. La descripciónprecisa de cada función se incluye en la Sección 3: Requisitos Específicos.

2.7. 1 Gestión de libros

Estas funciones permiten mantener actualizado el registro (fichero) de libros existentes en labiblioteca. El desglose de las mismas se refleja en el diagrama de flujo de datos de la figura B.3.

Ficha de libro

F i gu ra B . 3 . DF D . l Ge s t i ón de L i b ros

Las funciones de gestión de libros son las siguientes:

Fu nción 1.1 Alta de libro: r egistra un nuevo libr oFunción 1.2 Baja de libro: mar ca un libro como dado de bajaFun ción 1.3 Anular baja de libro: supr ime la mar ca de bajaFu nción 1.4 Actualizar libro: mod ifica los datos del libr oFu nción 1.5 Listar libr os: lista todos los libr os registr adosFu nción 1.6 Compa ctar r egistro de libr os: elimina los libr os dad os de bajaFu nción 1.7 Actualizar lista de materias: actualiza la lista de materias consider ada s

2.7.2 Gestión de lectores

Estas funciones permiten mantener actualizado el registro (fichero) de usuarios (lectores). Eldesglose de las mismas se refleja en el diagrama de flujo de datos de la figura B.4.



Especificación de Sof twa re 89

Ficha de lector

F i gu ra B . 4 . DFD .2 Ge s t i ón de l e c t o r es

Las funciones de gestión de lectores son las siguientes:

Fu nción 2.1 Alta de lector: r egistra un nuevo usuario (lector)Fun ción 2.2 Baja de lector: mar ca un lector como dado de bajaFun ción 2.3 Anular baja de lector: supr ime la marca de bajaFu nción 2.4 Actualizar lector: m odifica los datos del lectorFu nción 2.5 Listar lector es: lista todos los lectores registra dosFu nción 2.6 Compa ctar r egistro de lectores: elimina los lector es dad os de bajaFun ción 2.7 Buscar lector: localiza un lector por nombr e o apellido

2.7.3 Gestión de pr éstamosEstas funciones permiten tener anotados los libros en pr éstamo, y conocer en un momento d ado losque han sido retenidos más tiempo del permitido. El desglose de las mismas se refleja en eldiagrama de flujo de datos de la figura B.5.

Las funciones de gestión de préstamos son las siguientes:

Fun ción 3.1 Anotar préstamo: anota los datos del préstamoFu nción 3.2 Anotar devolución: elimina los datos del pr éstamoFu nción 3.3 Lista de mor osos: lista todos los pr éstamos no devueltos en el plazo fijad oFu nción 3.4 Pr éstamos de lector: lista los libros que tiene en préstamo un lector dado



90 In troducción a la Ingenier ía de Softw are

OrdenrdenAnotar

PréstamoListado demorosos

LIBROS

Ordenrden Préstamos jde lector

AnotarDevolución

Morosos

•

Préstamos de lector

•

F i g u r a B . 5 . D F D . 3 G e s t i ó n d e p r é s t a m o s

/ \Orden / D \

k, Buscar porLibros

" Materias V\\

/ '

1 Orden _ \k Buscar por i

Librosw

Autor i r

1x

- x/ \\ /

Orden Buscar por Libros

! / f Titulo/

r

MATERIAS LIBROS

F i g u r a B . 6 . D F D . 4 B ú s q u e d a s



Especificación de Softw are 912.7.4 Búsquedas

Estas funciones permiten localizar libros por autor, título o materia. El desglose de las mismas serefleja en el diagrama de flujo de ciatos de la figura B.6.

Las funciones de búsqueda son las siguientes:

Fun ción 4.1 Buscar p or autor: localiza los libros de un autor dadoFu nción 4.2 Buscar por título: localiza los libros cuyo título contiene un texto dadoFun ción 4.3 Buscar p or materia: localiza los libr os que tratan de una materia dada

2.7.5 Modelo de datos

El diagrama Entidad-Relación correspondiente a los datos principales del sistema se recoge en lafigura B.7. El significado de cada elemento es el siguiente:

F i gu ra B . 7. Mo de l o de da t o s de l s i s t em a

Entidad Libro: Contiene los datos de identificación del libroEntidad Lector: Contiene los datos personales del lectorEntidad Materia: Contiene el término clave que identifica la materiaRelación Pr estado-a: E nlaza un libr o con el lector que lo ha sacado en préstamo. Contiene

la fecha del préstamoRelación Trata-de: Enlaza un libro con cada materia de la que trata

Las estructuras de datos principales se recogen en el diccionario de datos del cuadro B.l



92 Introdu cción a la Ingeniería de Softw are

D A T O D E S C R I P C I Ó N

L E C T O R E S { F I C H A - D E - L E C T O R }L I B R O S { F I C H A - D E - L I B R O }M A T E R I A S { M A T E R I A }F I C H A - D E - L E C T O R C Ó D I G O - D E - L E C T O R + D A T O S - D E - L E C T O RF I C H A - D E - L I B R O C Ó D I G O - D E - L I B R O + D A T O S - D E - L I B R O

+ D A T O S - D E - P R É S T A M OM A T ER I A /Nom b r e d e l a m a t e ri a /C Ó D I G O - D E - L E C T O R / N ú m e r o d e l le ct or /C Ó D I G O - D E - L I B R O /Número de l l i b ro/

D A T O S - D E - P R É S T A M O F E C H A + C Ó D I G O - D E - L E C T O RD A T O S - D E - L E C T O R /Nombre, ape l l i dos , DNI , domic i l i o , t e l é fono, . . . /D A T O S - D E - L I B R O /Autor, t í tu lo, mater ias, . . . /O R D E N /Da t os de c ada o rden /R E S P U E S T A /Respues t a en pan t a l l a /L I S T A D O - D E - L I B R O S L I B R O SL I S T A D O - D E - L E C T O R E S L E C T O R E SM O R O S O S { F E C H A + /Dato s de l l ib ro/ + /Da tos de l l ec tor /}P R É S T A M O S - D E - L E C T O R { F E C H A + /Da t os de l l ib r o / }

Cuad ro B . l . D i c c i ona r i o de da t o s de l s i s t em a

3. REQUISITOS ESPECÍFICOSTodos los requisitos se consideran obligatorios, salvo que se indique lo contrario.

3.1 Requisitos funcionales

3.1.1 Almacenamiento de datos

R .l .l El sistema mantendrá almacenados en forma permanente al menos los datos indicados enLIBROS, LECTORES y MATERIAS, en el Diccionario de Datos descrito en laSección 2.7.5.

3.1.2 Funciones principales

R. 1.2 El sistema r ealizar á al men os las funciones que se describ en a continua ción, bajo peticióndel operador.



Especificación de Softw are 933.1.2.1 Gestión de libr os

Fu nción 1.1 Alta de libr o: registr a un nu evo libr oEntrada: DATOS-DE-LEBROSalida: FICHA-DE LIBROUsa:Actualiza: LIBROSEfecto: Compone una nueva ficha de libro asignando código automáticamente y leyendo

los datos del libro por pantalla (las materias se seleccionarán de entre la lista dematerias registradas). Registra la ficha en el fichero de libros, y además laimprime.

Excepciones:

Fun ción 1.2 Baja de libro: ma rca un libr o como dado de bajaEntrada: CÓDIGO-DE LIBROSalida:Usa:Actualiza: LIBROSEfecto: Lee el código del libro por pantalla, y marca la ficha de ese libro en el fichero de

libros como dada de baja.Excepciones: Si no existe el libro con ese código, o ya estaba dado de baja, da un aviso.

Función 1.3 Anular baja de libro: suprime la mar ca de bajaEntrada: CÓDIGO-DE-LIBROSalida:

Usa:Actualiza: LIBROSEfecto: Lee el código del libro por pantalla, y anula la marca de dado de baja en la ficha

de ese libro en el fichero de libros.Excepciones: Si no existe el libro con ese código, o no estaba dado de baja, da un aviso.

Fun ción 1.4 Actualizar libro: mod ifica los datos del libr oEntrada: CÓDIGO-DE-LIBRO, DATOS-DE-LIBROSalida: FICHA-DE LIBROUsa:Actualiza: LIBROSEfecto: Lee el código del libro por pantalla, localiza la ficha de ese libro, y actualiza los

datos de ese libro, también por pantalla (las materias se seleccionarán de entre lalista de materias registradas). Registra la ficha actualizada en el fichero de libros,y la imprime.

Excepciones: Si no existe el libro con el código indicado, da un aviso.

Fu nción 1.5 Listar libr os: lista todos los libros registrad osEntrada:Sal ida: LISTADO-DE-LIBROSUsa: LIBROSActualiza:Efecto: Imprime un listado con todos los datos de todos los libros, incluso los que estén

dados de baja.Excepciones:



94 In troducción a la Ingenier ía de Softw areFu nción 1.6 Comp actar r egistr o de libr os: elimina los libros dados de baja

Entrada:Salida:Usa:Actualiza: LIBROSEfecto: Suprime del fichero de libros las fichas de libros que estén dados de baja,

liberando el espacio que ocupaban.Excepciones:

Fu nción 1.7 Actualizar lista de materias: actu aliza la lista de mater ias considera dasEntrada:Salida:Usa:

Actualiza: MATERIASEfecto: Se edita por pantalla la lista de materias a considerar, pudiendo añadir, suprimirmaterias, o modificar sus nombres.

Excepciones: Si se intenta suprimir una materia habiendo libros registrados que tratan deella, se pedirá confirmación especial. Si se fuerza la eliminación, se suprimirátambién la referencia a esa materia de los libros que traten de ella.

3.1.2.2 Gestión de lectores

Fun ción 2.1 Alta de lector: registra un nuevo usuar io (lector)Entrada: DATOS-DE-LECTORSalida: FICHA-DE-LECTORUsa:Actualiza: LECTORESEfecto: Compone una nueva ficha de lector asignando código automáticamente y leyendo

los datos del lector por pantalla. Registra la ficha en el fichero de lectores, yademás la imprime.

Excepciones:

Fun ción 2.2 Baja de lector: mar ca un lector com o dado de bajaEntrada: CÓDIGO-DE-LECTORSalida:Usa:Actual iza: LECTORES

Efecto: Lee el código del lector por pantalla, y marca la ficha de ese lector en el ficherode lectores como dada de baja.Excepciones: Si no existe el lector con el código indicado, o ya estaba dado de baja, da

un aviso.

Fun ción 2.3 Anular baja de lector: suprime la mar ca de bajaEntrada: CÓDIGO-DE-LECTORSalida:Usa:Actual iza: LECTORESEfecto: Lee el código del lector por pantalla, y suprime la marca de dado de baja de la

ficha de ese lector en el fichero de lectores.



Especificación de So ftw are 95Excepciones: Si no existe el lector con el código indicado, o no estaba dado de baja, da

un aviso.Fu nción 2.4 Actualizar lector: m odifica los datos del lector

Entrada: CÓDIGO-DE-LECTOR, DATOS-DE-LECTORSalida: FICHA-DE-LECTORUsa:Actualiza: LECTORESEfecto: Lee el código del lector por pantalla, localiza la ficha de ese lector y actualiza los

datos de ese lector, también por pantalla. Registra la ficha actualizada en elfichero de lectores, y la imprime.

Excepciones: Si no existe el lector con el código indicado, da un aviso.

Fun ción 2.5 Listar lectores: lista todos los lectores r egistra dosEntrada:Sal ida: LISTADO-DE-LECTORESUsa: LECTORESActualiza:Efecto: Imprime un listado con todos los datos de todos los lectores, incluso los que estén

dados de baja.Excepciones:

Función 2.6 Compactar registro de lectores: elimina los lectores dados de bajaEntrada:Salida:

Usa:Actualiza: LECTORESEfecto: Suprime del fichero de lectores las fichas de lectores que estén dados de baja,

liberando el espacio que ocupaban.Excepciones:

Función 2.1 Buscar lector: localiza un lector por nombre o apellidoEntrada: NOMBRE-O-APELLIDOSalida: FICHA-DE-LECTORUsa: LECTORESActualiza:Efecto: Presenta en pantalla un listado con los datos de cada lector que contenga el

nombre o apellido indicado.Excepciones:

3.1.2. 3 Gestión de pr éstamos

Fun ción 3.1 Anotar pr éstamo: anota los datos del pr éstamoEntrada: CÓDIGO-DE-LIBRO, CÓDIGO-DE-LECTORSalida:Usa: LECTORESActualiza: LIBROSEfecto: Lee por pantalla los códigos del libro y del lector. Anota en la ficha del libro los

datos del préstamo: código del lector y la fecha del día, tomada del reloj delsistema. Actualiza la ficha en el fichero de libros.



96 In troducción a la Ingenier ía de Softw areExcepciones: Si no existe el libro o el lector, o el libro ya estaba prestado, o el lector

tiene ya el máximo de libros en préstamo, da un aviso.Fu nción 3.2 Anotar devolución: elimina los datos del pr éstamo

Entrada: CÓDIGO-DE-LIBROSalida:Usa: LECTORESActualiza: LIBROSEfecto: Lee por pantalla el código del libro, y elimina los datos de préstamo de su ficha.

Actualiza esa ficha en el fichero de libros.Excepciones: Si el libro no existe, o no está prestado, da un aviso.

Fu nción 3.3 Lista de mor osos: lista todos los préstamos no devueltos en el plazo fijado

Entrada:Salida: MOROSOSUsa: LIBROS, LECTORESActualiza:Efecto:

Imprime un listado con los datos de libros y lectores de todos los préstamos paralos que el plazo desde que se realizaron hasta hoy sea superior el plazo límiteestablecido.

Excepciones:

Fu nción 3.4 Pr éstamos de lector: lista los libr os que tiene en pr éstamo un lector da doEntrada: CÓDIGO-DE-LECTOR

Salida: PRÉSTAMOS-DE-LECTORUsa: LIBROS, LECTORESActualiza:Efecto: Presenta en pantalla un listado con los datos abreviados de cada libro que tenga

en préstamo ese lector, y la fecha de cada préstamo.Excepciones: Si el lector no existe, da un aviso.

3.1.2.4 Búsquedas

Fu nción 4.1 Buscar por autor: localiza los libr os de un autor dadoEntrada: NOMBRE-O-APELLIDOSalida: FICHA-DE-LIBROUsa: LIBROSActualiza:Efecto: Presenta en pantalla un listado con los datos de cada libro cuyo autor contenga el

nombre o apellido indicado.Excepciones:

Fu nción 4.2 Buscar por título: localiza los libr os cuyo título contiene un texto dadoEntrada: TEXTOSalida: FICHA-DE-LIBROUsa: LIBROSActualiza:



Especificación de So ftw are 97Efecto: Presenta en pantalla un listado con los datos de cada libro cuyo título contenga el

texto indicado.

Excepciones:Fun ción 4.3 Buscar por ma teria: localiza los libros que tratan de una materia dada

Entrada: MATERIASalida: FICHA-DE-LIBROUsa: LIBROSActualiza:Efecto: Presenta en pantalla la lista de materias y permite seleccionar la materia objeto de

la búsqueda. Presenta en pantalla un listado con los datos de cada libro que tratede la materia indicada.

Excepciones:

3.2 Requisitos de capacidad

R .2.1 El softwar e debe soportar al men os 9.000 libr os, 9.000 lectores y 250 mat erias.

R .2.2 No obstante lo anter ior, la capa cidad de alma cenam iento puede estar limitada por lacapacidad del hardware de cada instalación.

R .2.3 La ejecución de cualquiera d e las funciones principa les (excepto listad os) deberá dur ar 5segund os, como má ximo, en un PC con pr ocesador 80486. Esto incluye las búsquedas conregistros de 9000 libros o lectores. El tiempo puede ser proporcionalmente mayor conregistros de mayor capacidad.

R .2.4 En el caso de los listados, el límite anterior se incrementar á en el tiemp o físico deimpresión, dependiente de la impresora.

3.3 Requ isitos de inter fase

No aplicable.


R .4.1 La selección de una función se hará median te un sistema de menús

R.4.1.1 (Deseab le) La selección de una función principal no debería exigir m ás de dosniveles de menú

R .4.2 Los códigos de libro y lector deberá n ser fáciles de teclear , exigiend o pocas pulsaciones.

R .4.3 (Deseab le) Sobre un libro o lector seleccionad o mediante una función se podrá invocar otrasin necesidad de volver a seleccionar manualmente dicho libro o lector.

R .4.4 (Deseab le) La función de actualizar la lista de mat erias debería ser accesible desde las dealta de libro y actualizar libro.



98 In troducción a la Ingenier ía de Softw areR .4.5 El sistema podrá configura rse para que el programa entre en funcionamiento

automáticamente al arrancar el equipo.R .4. 6 Existirá la posibilidad de sacar y restablecer copias de seguridad (backu ps). Par a ello bastará

que se puedan salvar y restaurar los ficheros con los registros permanentes del sistema.

R.4 .7 En las funciones que actualizan los registros perma nentes, se pedirá confirma ción antes dehacerlo, presentando los datos que se van a actualizar.

R .4.8 Al arrancar la ap licación (o durante la opera ción), se podrán modificar los límites depréstamo, tanto el plazo como el número de libros para un mismo lector.

3.5 Requisitos de recursosR.5.1 El programa deberá poder ejecutar se en equipos tipo PC (o similar es) de gama baja, con la

configuración mínima equivalente a la siguiente:

• CPU: 486 o posterior• Memoria: 640 Kb• Pantalla: alfanumérica 80 x 25 caracteres• Disquete: 3V2" 720Kb o 5 l/4 n 1,2Mb, para backup• Disco fijo: con capacidad para los programas y los registros permanentes

3.6 Requ isitos de ver ificaciónR .6.1 (Deseab le) Deberá disponer se de un sistema de acceso a los registros de libr os, lectores y

materias, independiente de la aplicación, y que permita examinar su contenido,preferiblemente obteniendo un listado del mismo, para comprobar que la informaciónalmacenada es la correcta.

3.7 Requ isitos de pr uebas de aceptación

R.7 .1 Se deben probar al menos una vez todas y cada una de las funciones, tanto con entradasnormales como con datos que provoquen errores, en su caso.

3.8 Requisitos de documentación

R .8.1 Existirá un manual de oper ación, sencillo, que describa el uso del sistema .

R .8.2 (Deseab le) Un resumen del manual de oper ación estará disponible como ayuda en línea,durante la operación del sistema.



Especificación de So ftw are 99í . 9 Requisitos de seguridad

R .9.1 (Deseab le) La comp acta ción de los r egistr os sólo deber ía realizarse si pr eviamente se hasacado una copia de "backup" de los mismos.

R .9.2 Aunqu e se llene el disco fijo y no se pueda n registra r n uevos libr os, lectores, m aterias opréstamos, no deberá perderse información anterior de los registros permanentes.

3 .1 0 Requisitos de transportabilidad

R -10.1 (Deseab le) El pr ogram a se codificar á en un lenguaje de progr am ación de alto nivel, parael que exista una definición normalizada.

3.11 Requisitos de calidadNinguno en especial.

3 .1 2 Requ isitos de fiabilidad

Ninguno en especial.

3.13 Requisitos de mantenibilidad


3.14 Requisitos de salvaguarda




Te m a 3Fundam entos de l

D iseñ o de S o f tw a r e

Con este Tema se inicia el estudio de las etapas de desarrollo. Después dehaber especificado QUÉ se quiere resolver durante la especificación, lasetapas de desarrol lo se dedican a determinar CÓMO se debe resolver el

proyecto. La primera de estas etapas es la de diseño, se continúa con la decodif icación y se f inal iza con las etapas de pruebas del sof tware real izado.Toda esta segunda unidad didáct ica está dedicada a la etapa de diseño.

Concretamente, en este Tema se abordan los fundamentos de la etapa dediseño. Pr imeramente se concreta qué se ent iende por diseño y se anal izanlas actividades que se deben realizar para llevarlo a cabo. A continuaciónse in t roducen a lgunos concep tos fundamenta les que deben tener se encuenta para real izar cualquier diseño. Seguidamente se descr iben dis t intasnotaciones que se pueden emplear para la descr ipción de un diseño

sof tware. Algunas de estas notaciones son versiones ampliadas de las yaestudiadas para la especif icación y otras son totalmente específ icas para eldiseño. Finalmente, se proponen unos formatos concretos para laelaboración de los documentos del diseño arqui tectónico y del diseñodetal lado en los que se recogen todos los resul tados del diseño.

3.1 Introducción

Comenzaremos esta unidad didáct ica, dedicada íntegramente al diseño,tratando de establecer qué se ent iende por diseño de sof tware. Siconsul tamos el diccionar io , encontramos la s iguiente def inición:

Diseño, (del italiano disegno) ... \ \ 2. Descripción o bosquejo dealguna cosa, hecho por palabras .

Lo que t rasladado al contexto del diseño de s is temas sof tware ser ía ladescripción o bosquejo del sistema a desarrollar . En nuestro caso, ladescr ipción se puede y se debe hacer mediante otras notaciones másformales y no sólo empleando palabras . Se t rata, por tanto, de def inir yformalizar la es tructura del s is tema con el suf iciente detal le como parapermitir su realización f ísica.




El punto de par t ida pr incipal para abordar e l diseño es e l documento deespecificación de requisitos (SRD). La realización del diseño de un sistemaes un proceso creativo que no es nada trivial y que casi siempre se lleva acabo de una forma iterativa mediante prueba y error. En este proceso esmuy importante la exper iencia previa y siempre que sea posible se tra taráde reuti l izar e l mayor número de módulos o e lementos ya desarrollados.Cuando esto úl t imo no sea posible , por tra tarse del diseño de un sistemacom pletam ente or iginal y sin ning ún anteced ente previo, es seguro que paracom enzar e l diseño, al menos se po drá apro vechar e l enfoq ue dado a a lgú notro proyecto anterior, lo que se conoce como aprovechar el know-how(saber hacer). Después, en sucesivas iteraciones se perfilará el enfoque más

adecuado para e l nuevo diseño. Esta forma de trabajo es la misma que seutiliza para diseñar nuevos coches, aviones, edificios, puentes o cualquierotra obra de ingeniería. Está claro que los expertos en la construcción deaviones son más adecuados para diseñar uno nuevo que los encargados dediseñar puentes.

En el próximo Tema se estudiarán ciertas técnicas de carácter general paraabordar el diseño de cualquier sistema. Desgraciadamente, estas técnicasson empír icas y no están suf ic ientemente formalizadas como para que sepu ed an real izar de una m anera automática . Para c ierto t ipo de aplicaciones

sencillas o m uy específicas (nóminas, cálculos científicos, control de stocks,etc.) existen herramientas tales como lenguajes de cuarta generación, hojasde cálculo, paquetes de cálculo científico, etc. , que simplifican mucho lalabor de diseño y codificación, pero esto no es la situación general. En losrestantes casos, la aplicación de las técnicas no es tan sistemática y es muyimportante la habil idad del diseñador .

El método más eficaz para adquirir experiencia en el diseño es participar enalgun o de e l los y apre nde r d e los otros diseña dores sus técnicas de trabajo.Tam bién es aconsejable estudiar diseños y a real izados y ' analizarporm eno rizada me nte las razones por las que se adop ta una u otra solución.

Estas razones normalmente no se suelen explicar en los libros ya quedependen de cada caso concreto y de las preferencias de cada diseñador, loque hace muy difícil establecer ninguna regla general. Por tanto, es muycomplicado aprender a diseñar exclusivamente leyendo l ibros.

En los desarrollos de sistemas software de los años 60, el objetivo del dise ñoera conseguir la mayor eficiencia posible, dado que la memoria de loscomputadores era escasa y su potencia de cálculo no muy grande.Actualmente y debido a l t remendo aumento de los costos de desarrollo, e lobjet ivo fundamental es conseguir que e l sof tware sea fáci l de mantener y

si es posible que se pueda reutilizar en futuras aplicaciones. Para conseguir



Fun dam ento s del Diseño de Software 105

ambos objetivos, la etapa de diseño es la más importante de la fase dedesarrollo de sof tware .

Durante la e tapa de diseño se t iene que pasar de una forma gradual delQUÉ debe hacer el sistema, según se detalla en el documento de requisitos,al CÓMO lo debe hacer, estableciendo la organización y estructura física delsof tware . En esta transformación gradual no siempre está c laramentedeterminado dónde acaba e l análisis y dónde empieza e l diseñoprop iam ente dicho. En algun os casos se l lega a considerar qu e los requisi tosforman par te del diseño externo o funcional del s is tema. De cualquiermanera , durante e l diseño se t iene que pasar de las ideas informales

recogidas en el SRD a definiciones detalladas y precisas para la realizacióndel sof tware mediante ref inamientos sucesivos.

A lo largo del proceso de d iseño se realiza un co njun to de actividad es. Estasactividades tienen como objetivo sistematizar cada uno de los aspectos oelementos de la estructura del sistema. Aunque no existe consenso ni en elnúmero ni en la denominación de las actividades, con ellas se persigue unref inamiento progresivo del diseño. Dependiendo de la complejidad delsistema a diseñar a lgunas de las act ividades quedarán englobadas dentrode otras o simplemente desaparecerán. A continuación se enumeran ydescriben actividades habituales en el diseño de un sistema:

1.- DIS EÑO AR QUITECTÓNIC O: Ésta es la prim era a ctivida d a realizar y en ellase deben abordar los aspectos estructurales y de organización delsistema y su posible división en subsistemas o mó dulos. Ad emás, setienen que establecer las relaciones entre los subsistemas creados ydefinir las interfases entre ellos. Esta actividad proporcionará unavisión global del sistema y por tanto resulta esencial para poderavanzar en las actividades siguientes. Por ejemplo, para el sistema decontrol de acceso del tema anterior, no tiene ningún sentido abordarel diseño de la visualización de mensajes sin tener absolutamente

establecidos todos los módulos del sistema, los tipos de mensajesposibles que cada uno necesitará, la interfase con la que seinterrelacionarán los distintos módulos, etc.

2 . - DIS EÑO DETALLADO: Con esta actividad se aborda la organización de losmódulos. Se tra ta de determinar cuál es la estructura más adecuadapara cada uno de los módulos en los que quedó subdividido e lsistema global. Simplificando, podemos decir que si se utilizara ellenguaje Modula-2 como notación de diseño esta actividad sería laencargada de la elaboración de los módulos de definición para cada



106 Introd ucció n a la Ingen iería de Softw are

uno de los módulos del programa global . Así , estos módulos de

def inic ión ser ían e l resultado fundamental de esta act ividad.

También como resultado del diseño deta l lado, aparecen nuevosmó dulo s que se deb en incorporar a l diseño global, com ponen tes quees razonable agrupar en un único módulo, o módulos quedesaparecen por estar vacíos de contenido. Esto refleja lainterrelación entre el diseño arquitectónico y el detallado a pesar deque pudieran parecer act ividades puramente secuenciales. Cuandose trata de diseñar sistemas no muy complejos, el diseño detalladono existe como ta l act ividad y es simplemente un ref inamiento deldiseño arquitectónico.

3.- DISEÑO PROCEDIMENTAL: Esta actividad es la encargada de abordar laorganización d e las operaciones o servicios que ofrecerá cada uno delos módulos. Siguiendo con la simplificación anterior del empleo deModula-2, en esta actividad se diseñan los algoritmos que seem plean en e l desarrollo de los módulos de implementación para losprocedimientos más importantes de cada uno de los módulos delsistema. No rmalm ente , en esta act ividad se detal lan en pseudocódigoo PDL solamente los aspectos más relevantes de cada algoritmo (Verapartado 2.3.4 del Tema 2). Posteriormente en la etapa de

codificación se dará forma definitiva a los algoritmos.

4.- DISEÑO DE DATOS: En esta actividad se aborda la organización de la basede datos del sistema y se puede realizar en paralelo con el diseñodetal lado y procedimental . El punto de par t ida para esta act ividades el diccionario de datos y los diagramas E-R de la especificacióndel sistema. Con esta actividad se trata de concretar el formatoexacto para cada dato y la organización que debe existir entre ellos.El diseño de datos es de una gran importancia para conseguir e lobjetivo de que el sistema sea reutilizable y fácilmente mantenible.Sin embargo, una par te muy importante de esta act ividad se suele

realizar en el momento que se elabora la especificación de requisitosdel sistema.

5.- DISEÑO DE LA INTERFAZ DE USUARIO: En cualquier aplicación sof tware ,cada día resulta más importante e l esfuerzo de diseño dest inado aconseguir un diá logo más ergonómico entre e l usuar io y e lcomputador . Por e jemplo, la faci l idad de aprendizaje y manejo deuna aplicación aumenta considerablemente cuando en la interfaz deusuar io se emp lean ventan as desplegables y ra tón en lugar de me núsy teclado. Precisamente esta actividad es la encargada de la




organización de la interfaz de usuar io. La importancia de estaactividad ha propiciado e l desarrollo de técnicas y herramientasespecíficas que facilitan mucho el diseño. Sin embargo, paraconseguir una buena interfaz de usuar io hay que tener en cuentaincluso factores psicológicos.

El resultado de todas estas act ividades de diseño debe dar lugar a unaespecificación lo más formal posible de la estructura global del sistema y decada uno de los e lementos del mismo. Esto consti tuye e l "producto deldiseño" y se recogerá en el Documento de Diseño de Softwar e (en inglésSDD: Software Design Document, o también Software Design Descriptiorí).

Si la complejidad del sistema así lo aconseja se podrán utilizar variosdocu men tos para descr ibir de forma jerarq uizad a la estructura global delsistema, la estructura de los elementos en un primer nivel de detalle y enlos sucesivos niveles de detalle hasta alcanzar el nivel de codificación conlos listados de los programas. Las normas ESA establecen un Documentode Diseño Arquitectónico (ADD: Architectural Design Document) y unDocumento de Diseño Detallado (DDD: Detailed Design Document) al quese pueden añadir como apéndices los l is tados de los programas una vezcom pletado e l desarrollo. El form ato de estos docum entos será e l obje to delúlt imo apar tado de este mismo Tema.

3 2 Conceptos de ba se

La experiencia acumulada a lo largo de los años por los diseñadores desistemas sof tware ha permitido identif icar una ser ie de conceptos ocaracterísticas de los sistemas y sus estructuras que tienen especialinfluencia en la calidad de un diseño de software.

Muchos de estos conceptos aparecen en un campo bastante amplio de laactividad de desarrollo de software, y su utilidad no se limitaexclusivamente a la tarea de diseño. Algunos de ellos se pueden aplicar de

manera natural en el análisis e incluso en otro tipo de actividades dentro yfuera del ámbito del desarrollo de sistemas software. Todas las técnicas quese estudiarán en e l próximo Tema están basadas en uno o var ios de losconceptos que aquí se recogen.

La aplicación par t icular de determinadas técnicas da lugar a metodologíasespecíficas, que podrán cambiar o mejorar en el futuro. Sin embargo, losconceptos de base permanecen y se seguirán uti l izando probablemente singrandes var iaciones. Lamentablemente , los conceptos por sí mismos noconstituyen una técnica o metodología de diseño. La importancia relativade cada concepto en las diferentes técnicas de diseño varía según la opinión



108 Introdu cción a la Ingen iería de Softw are

o preferencias personales de los distintos expertos. A continuación se recogeuna lista bastante amplia de los conceptos más interesantes a tener encuenta en cualquier diseño.

32.1 Abs t r acc ión

El concepto de abstracción se utiliza en un gran número de actividadeshumanas. Por e jemplo, en e l lenguaje con e l que nos comunicamos seuti l izan esencialmente un conjunto amplio de abstracciones a las que nosrefer imos a través de las palabras. Cada nu eva palabra sirve para refer irnosa un nuevo concepto abstracto aceptado por todos sin necesidad de aclarar

cada vez su significado.

Cuando se diseña un nuevo sistema sof tware es importante identif icar loselementos realmente significativos de los que consta y además abstraer lautilidad específica de cada uno, incluso más allá del sistema software parael qu e se está diseñ and o. Este esfuerzo dará com o resultado que e l e lementodiseñado podrá ser sust i tuido en el futuro por o tro con mejores prestacionesy también podrá ser reutilizado en otros proyectos similares. Estos son dosde los principales objetivos del diseño: conseguir elementos fácilmentemantenibles y reutilizables.

Durante el proceso de diseño se debe aplicar el concepto de abstracción entodos los niveles de diseño. Tomando como ejemplo e l s is tema para e lcontrol de acceso enunciado en el tema anterior, en un primer nivelaparecen abstracciones tales como: Tarjeta, Mensajes, Ordenes, etc.Inicialmente, todos ellos son elementos abstractos y su diseño sepuede realizar sin tener en cuenta al sistema de control de accesoconcreto en el que se utilizarán. Esto facilitará los cambios futurosy la posibilidad de reutilizarlos en diversos sistemas. En un segundonivel aparecen nuevas abstracciones como: Clave, Control de Puerta,Comproba r C l ave , etc. a los que se aplicarán los mismos criterios. Este

proceso de abstracción se puede y se debe continuar con cadaelemento sof tware que tengamos que diseñar . El mismo procedimientoes el que se utiliza para diseñar un coche, un avión, una casa, etc.Inicialmente tenemos como elementos abstractos el motor, el chasis,las ruedas, etc. y para diseñar estos elementos a su vez necesitamosfiltros, bujías, correas, etc. que si se diseñan convenientemente sepodrán uti l izar en cualquier modelo de coche.

En el diseño de los e lementos sof tware se pueden uti l izarfundamentalmente tres formas de abstracción:



Fun dam entos del Diseño de Software 109

• Abstracciones funcionales• Tipos abstractos• M áquinas abstractas

Como se explica en e l l ibro de Fundamentos de Programación[CerradaOO], una abstracción funcional sirve para crear expresionesparametr izadas o acciones parametr izadas mediante e l empleo defunciones o procedimientos. Para diseñar una abstracción funcionales necesario fijar los parámetros o argumentos que se le deben pasar,el resultado que devolverá en el caso de una expresiónparam e tr izada, lo qu e se p retend e que resuelva y como lo deb e

resolver (el algoritmo que se debe emplear). Por ejemplo, se puedediseñar una abstracción funcional para Comproba r C l ave cuyoparámetro es la c lave a comprobar y que devuelva como resultadosi/no la clave es correcta.

En cuanto a los tipos abstractos, estos sirven para crear los nuevostipos de datos que se necesitan para abordar el diseño del sistema.Por ejemplo, un tipo Tarjeta para guardar toda la informaciónrelacionada con la tarjeta utilizada: clase de tarjeta, identificador,clave de acceso, dat os personales, etc. Ad em ás, jun to al nu evo tipo

de dato se deben diseñar todos los métodos u operaciones que sepueden realizar con él. Por ejemplo, Leer Tarjeta, Grabar Tarjeta,Comprobar Tar jeta, e t c .

Una máquina abstracta permite establecer un nivel de abstracciónsuper ior a los dos anter iores y en é l se def ine de una manera formale l compor tamiento de una máquina. Un ejemplo de este t ipo deabstracción sería un intérprete de órdenes SQL (Standard QueryLanguage) para la gestión de una base de datos. El lenguaje SQLestablece formalmente e l comportamiento perfectamente def inidopara la máquina abstracta encargada de manejar la base de datos:

construcción, búsqueda e inserción de elementos en la base de datos.Otro ejemplo clásico de máquina abstracta es la definición de unprotocolo de comunicaciones en el que se establecen los posiblesestados (espera, envío, recepción, inactivo, ....), las transiciones entreellos, los tipos de mensajes, etc. que configuran la máquinaabstracta como un autómata. También, el sistema para control deacceso uti l izado como ejemplo se puede ver como una máquinaabstracta si se consigue formalizar todo su comportamiento. Paratodos estos casos la tarea de diseño consiste en definir formalmentela máquina abstracta que se necesita.



110 In troducción a la Ingenier ía de Software

3.2 .2 Modularidad

Casi s iem pre los proyectos req uieren el t rabajo s imu ltáneo y coordina do devarias persona s . Una fo rm a clás ica de conseguir la coordinación es me dianteel empleo de un d iseño modular . Uno de los pr imeros pasos quein tu i t ivamente parece claro que se debe dar a l abordar un d iseño es d iv id irel s is tema en sus correspondientes módulos o partes c laramentediferenciadas . Esta d iv is ión permite encargar a personas d iferentes e ldesarro l lo de cada módulo y que todas e l las puedan t rabajars imultáneamente . Sin embargo, para conseguir la adecuada coordinación,la división en módulos no resulta trivial y además es necesario que lasin terfases entre todos el los queden completamente defin idas y

correctamente d iseñadas . En el próximo Tema se es tudiará la técnica dedescomposición modular que permite lograr es te objet ivo .

Además de posibili tar la división del trabajo, las ventajas de uti l izar undiseño modular son de todo t ipo:

CLARIDAD: Siempre es más fácil de entender y manejar cada una de laspartes o mó dulo s de un s is tema que t ra tar de entenderlo como untodo compac to .

REDUCCIÓN DE COSTOS: Resul ta más barato desarro l lar , depurar ,docum en ta r , p robar y man tener un s i s t ema modu la r que o t ro que nolo es . Hay que tener en cuenta que s i e l número de módulos creceinnecesariamente es ta af i rmación puede no ser correcta . Cuando haydemasiados módulos se aumentan también las re laciones entre e l losy las interfases necesarias.

REUTILIZACIÓN: Si los m ódu los se d iseñan tenie ndo en cuenta o tra s posib lesapl icaciones resul tará inmediata su reut i l ización .

El concepto de modularidad se debe apl icar en el d iseño de cualquier

sistema, incluso en aquellos para los que existan l imitaciones de t iempo omemor ia que impidan que en su cod i f i cac ión se puedan emplear módu loscompilados por separado. Por e jemplo , s i c ier tas operaciones son cr í t icas yse debe n real izar en un t iem po mu y corto , no se pu ed en e mple ar subru t inascon las que se gastaría un tiempo precioso en cada l lamada. En este caso sepueden emplear macros para sus t i tu i r a las subrut inas s in que es to afectepara nada al d iseño.

La modularidad es un concepto de d iseño que no debe es tar l igado a laetapa de codif icación y mucho menos al empleo de un determinado




lenguaje de programación. Sin embargo, histór icamente se ha asociado e l

concepto de módulo a determinadas estructuras de los lenguajes deprogramación. En lenguajes como FORTRAN, Pascal , e tc . un módulo sólose puede asociar a una subrutina , procedimiento o función. Estasestructuras resultan insuf ic ientes cuando se quiere conseguir que cadamiembro del equipo de trabajo pueda desarrollar su act ividad por separadoy de forma coordinada y tampoco permi ten agru par en una m isma ent idadsólo datos o datos y las operaciones que los manejan. Otros lenguajesposteriores sí que están dotados de estructuras específicas para estos fines.Los package de ADA o los M O D U L E de Modula-2 son los e jemplos másclaros. La ventaja que supone la utilización de estos últimoslenguajes es que resulta inmediato trasladar e l diseño a estructuras

del lenguaje.

3 2.3 Ref inamiento

El concepto de ref inamiento resulta imprescindible para poder real izarcualquier tipo de diseño. En un diseño, sea del tipo que sea, siempre separ te inic ia lmente de una idea no muy concreta que se va ref inando ensucesivas aproximaciones hasta p erf i lar e l má s mínim o deta l le . Fue N iklausWirth [Wirth71] el primero que recomendó la aplicación de refinamientossucesivos para e l diseño de programas.

Las especif icaciones recogidas en e l documento SRD siempre terminansiendo expresadas en un lenguaje de programación de a l to nivel . Sinembargo, el alto nivel de los lenguajes de programación es sólo relativo, yesos lenguajes están más próximos a l lenguaje del computador que a lnuestro propio. La forma natural de acercar ambos lenguajes (e l natural yel de programación) es utilizando el refinamiento: el objetivo global de unnuevo sistema software expresado en su especificación se debe refinar ensucesivos pasos hasta que todo quede expresado en e l lenguaje deprogramación del computador . Además, todos los lenguajes t ienen laposibil idad de declarar subprogramas (funciones y procedimientos) capaces

de expresar los pasos del ref inamiento como acciones o expresionesparametr izadas. Por tanto, e l proceso de ref inamiento se puede dar porconcluido cuando todas las acciones y expresiones quedan ref inadas enfunción de otras acciones o expresiones o bien en función de lasinstrucciones básicas del lenguaje empleado.

El uso directo e irrestringido de refinamientos sucesivos conduciría aprogramas monolíticos. El refinamiento directo debe dejar de aplicarse si eltamaño del programa resultante para una sola acción global excede de unlímite razonable, establecido típicamente en unas dos páginas de texto. Si




se excede este límite, convendrá aplicar las ideas de abstracción ymodular idad para f ragmentar una operación global en var ias separadas.

En el próximo Tema se estudiará la técnica de diseño descendente en la quese emplean los ref inamiento s sucesivos como mecan ismo básico de diseño.

32 A E s t r u c t u r a s d e d a t o s

La organización de la información es una parte esencial del diseño de unsistema software. Las decisiones respecto a que datos se manejan y laestructura de cada uno de ellos afectan de una forma decisiva al resto del

diseño: abstracciones, módulos, algoritmos, etc. Por ejemplo, una decisiónerrónea respecto a si un determinado resultado intermedio se guarda o secalcula nuevamente cada vez que se necesite, puede hacer tan lento elsistema que resulte inservible. Esto mismo puede suceder si la estructurade datos e legida complica de manera excesiva la búsqueda de unde te rminado da to .

De la importancia d e las estructuras d e datos en e l diseño son bu ena pruebalas metodo logías de diseño or ientad as a los datos, ta les como las prop uestasJackson [Jackson75], [Jackson83] y Warnier [Warnier81], En estasmetodo logías es precisamente la estructura de dato s e l pu nto d e par t ida del

que se arranca para realizar el diseño.

El estudio de la gran diversidad de estructuras de datos posibles quedafuera del alcance e interés de este libro. Además, existen muchos y buenoslibros dedicados a l estudio de las estructuras de datos más adecuadas pararesolver los problemas clásicos que se presentan en la mayoría de los casos[Aho83], [Wirth80], [Collado87]. Para el diseño basta tener en cuenta, engeneral , las estructuras fundamentales, ta les como:

• Registros

• Conjuntos• Formaciones• Listas, Pilas, Co las• Árboles• Grafos• Tablas• Ficheros

Es labor del diseñador la búsqueda, a partir de estas estructuras básicas, dela combinación más adecuada para lograr aquella estructura o estructurasque den respuesta a las necesidades del s is tema planteadas en su



Fun dam entos del Diseño de Softw are 113

especificación. Como siempre, resulta trascendental la experienciaacumulada de diseños anter iores.

3.2.5 Ocultación

Para poder ut i l izar correctamente un programa no es necesario conocer cuáles su estructura interna. Por ejemplo, el usuario de un procesador de textospuede ser cualquier persona que no posea absolutamente ningúnconocimiento de informática y mucho menos de la estructura interna delprograma. De forma semejante se puede pensar respecto a cada uno de losmódulos en los que se divide e l programa en su diseño. Al programador

"usuar io" de un módulo desarrollado por otro programador del equipopue de quedar le comple tamente oculta la organización de los datos internosque maneja y el detalle de los algoritmos que emplea.

El concepto d e ocultación aplicado al desarrollo de so f tware fue pro pue stopor Pamas [Parnas72] . Cuando se diseña la estructura de cada uno de losmódulos de un sistema, se debe hacer de ta l manera que dentro de é lqueden ocultos todos los deta l les que resultan ir re levantes para suutilización. Tomando como ejemplo el sistema de control de acceso, en elmódulo para e l control de puer ta deben permanecer ocultos todos losdetalles específicos del manejo de la puerta concreta utilizada (eléctrica,hidráulica, neumática, etc.) y por tanto del modo de actuar para conseguirsu apertura o cierre (tipo de señal y temporizaciones necesarias). Al"usuario" de este módulo sólo le interesa conocer cómo se le pasa la ordende que la puerta se abra o se cierre.

Con carácter general, se trata de ocultar al "usuario" todo lo que pueda sersusceptible de cambio en e l futuro y además es ir re levante para e l uso(hardware, sistema operativo, compilador, idioma, etc.) . Sin embargo, semuestra en la interfaz sólo aquello que resultará invariable con cualquiercambio. Las ventajas de aplicar este concepto son las siguientes:

DEP URACI ÓN: Resulta más sencillo detectar qué módulo concreto nofunciona correctamente. También es más fácil establecer estrategiasy programas de prueba que ver i f iquen y depuren cada módulo porseparado en base a lo que hacen sin tener en cuenta cómo lo hacen.

MANTENI MI ENTO: Cualquier modif icación u operación de mantenimientoque se necesite en un módulo concreto no afectará al resto de losmódulos del sistema. Si se cambian el hardware, el sistemaoperativo, etc. sólo se tiene que modificar el módulo encargado de




ocultar estos detalles. El resto de módulos que usen el módulomodif icado permanecerán sin cambios.

Aunque el concepto de ocultación se puede y se debe aplicar con cualquiermetodo logía o lenguaje de program ación, estructu ras como los packages deADA o los M O D U L E de Modula-2 y, por supuesto, los lenguajes deprogramación orientados a objetos, tienen la ventaja de facilitar demanera considerable la labor de diseño cuando se aplica el conceptode ocultación.

32 .6 Gene r i c idad

Un posible enfoque de diseño es agrupar aquellos e lementos del s is temaque uti l izan estructuras semejantes o que necesi tan de un tra tamientosimilar. Si se prescinde de los aspectos específicos de cada elementoconcreto es bastante razonable diseñar un e lemento genér ico con lascaracter íst icas comunes a todos los e lementos agrupados. Poster iormente ,cada uno de los e lementos agrupados se pueden diseñar como un casoparticular del elemento genérico. Esta es la idea básica que aporta elconcepto de gener ic idad.

Para i lustrar este concepto con un e jemplo, supongamos que se tra ta de

diseñar un sistema operat ivo mult i tarea que necesi ta a tender las órdenesque le llegan de los distintos terminales. Una de las órdenes habituales seráimprimir por una cualquiera de las impresoras disponibles. Por otro lado,es norm al que d esde var ios terminales simu ltáneam ente se necesite accedera f icheros o bases de datos compart idas. Cada una de estas act ividadesnecesi ta de un módulo gestor para decidir en qué orden se a t ienden laspeticiones. La forma más sencilla de gestión es poner en cola las órdenes,peticiones de impresión o peticiones de acceso a ficheros o bases de datoscom part idas. Inmed iatam ente surge la necesidad de una estructura genér icaen forma de cola para la que se necesitan también unas operaciones

genéricas tales como poner en cola, sacar el primero, iniciar la cola, vercuántos hay en cola, etc. Evidentemente en cada caso el tipo de informaciónque se guarda en la cola es diferente: tipo de orden a ejecutar, texto aimprimir, dato a consultar, etc. A partir de la cola genérica y con un diseñoposterior más detallado se tendrá que decidir la estructura concreta de lasdistintas colas necesarias y si para alguna de ellas es conveniente utilizarprioridades, lo que daría lugar a operaciones específicas.

Indu dable me nte e l concepto de gener ic idad es de gran uti l idad en e l diseñoy da lugar a soluciones simples y fáciles de mantener. Sin embargo, laimplementación de los e lementos genér icos obtenidos como resultado del




diseño puede resultar bastante compleja e incluso desvir tuar e l propioconcepto de gener ic idad. Por e jemplo, un lenguaje de programación, ta lcomo Pascal o Modula-2, impone unas restr icciones muy fuer tes en e lmanejo de datos de distinto tipo y las posibles operaciones entre ellos. Conestos lenguajes es necesario definir un tipo distinto de cola para cada tipode e lemento a a lmacenar , y aunque las operaciones sean esencialmenteidénticas para los distintos datos almacenados, también es necesarioimp lemen tar com o operaciones dist intas las dest in adas a manejar cada t ipode cola. Esto es, si tenemos los tipos:

esta solución, que es la única posible en estos lenguajes, desvirtúa deforma evidente la gener ic idad propuesta en e l diseño.

El lenguaje de programación ADA tiene la posibil idad de declarare lementos genér icos (generic) ta les como t ipos, constantes,subprogramas y objetos, que se pueden uti l izar para parametr izar unprocedure o u n package. En este caso, tendríamos los siguienteselementos genér icos:

Ahora, es posible obtener los procedimientos para cada t ipo de datoalmacenado en la cola de la siguiente forma:

procedure Poner_Entero i s n e w Poner_en_Co l a ( INTEGER ) ;procedure Poner_Rea l i s n e w Poner_en_Co l a ( REAL ) ;procedure Poner_Carac ter i s n e w Pone r _ en_ C o l a ( C HA RA C TER ) ;

Co!a_de_enteros

Co l a_de_ rea l e sCo l a_de_ca rac te res

es necesario implementar las operaciones:

Poner_enteroPone r_ rea lPoner_carac ter

Sacar_enteroSaca r_ rea l

(en la cola de enteros)(en la cola de reales)(en la cola de caracteres)

generictype COLA is prívate;

procedure Poner_en_Co la( X: i n COLA ) ;




procedure Poner_OtroTipo i s n e w Poner_en_Cola( OtroTipo ) ;

sin necesidad de desarrollar implementaciones dist intas para cadauno de ellos.

3.2 .7 Herenc ia

Otro enfoque posible del diseño cuando hay e lementos con caracter íst icascomunes es establecer una clasificación o jerarquía entre esos elementos delsistema par t iendo de un e lemento "padre" que posee una estructura y

operaciones básicas. Los e lementos "hijos" here dan del "padre" su estructuray operaciones para ampliar los, mejorar los o simplemente adaptar los a susnecesidades. A su vez los elementos "hijos" pueden tener otros "hijos" quehereden de e l los de una forma semejante . De manera consecutiva se puedecontinuar con los siguientes descendientes hasta donde sea necesario. Estaes la idea fundamental en la que se basa el concepto de herencia.

El mecanism o de herencia permite reuti l izar una gran can tidad de sof twareya desarrollado. Habitualmente , en un nuevo proyecto siempre se par te deotros proyectos ya real izados de los que se toman todos aquellos e lementosque nos pueden resultar út i les bien directamente , o con pequeñas

modificaciones, o de forma combinada entre varios, etc. Facilitar esta labores uno de los objet ivos fundamentales del concepto de herencia .

Si t ra tamos de real izar un software para dibujo asist ido por com putad or , lasf iguras que se manejan se podrían c lasif icar del s iguiente modo:

FIGURAS:

ABIERTAS:

TR AZO R EC TO:

LÍNEA RECTATR AZO C UR VO:

SEGMENTO DE CIRCUNFERENCIA

C ER R ADAS :

ELIPSES:

C ÍR C ULOS

P O L Í G O N O S :

TR IÁNGULOS :

EQUILÁTEROS

R EC TÁNGULOS :

C U A D R A D O S



Fu nda me ntos del Diseño de Softw are 117

Aquí, el elemento "padre" será FIGURAS. Las operaciones básicas concualquier t ipo de figura podrían ser:

• Desplazar• Rotar• Pintar

Aunque es tas operaciones las heredan todos los t ipos de f igura ,normalmente deberán ser adaptadas en cada caso . Así , Rotar los CÍRCULOSsignifica dejarlos tal cual están.

Por otro lado, al concretar los elementos "hijos" aparecen nuevasoperaciones que no tenían sentido en el elemento "padre". Así, la operaciónde calcular el Perímetro solo t iene sent ido pa ra f igu ras CERRADAS. De fo rmasemejante só lo los PO L Í G O N O S tendrán una operación específ ica paradeterminar la posición de sus Vértices, sólo en los RE CT Á N G U L O S se puedehablar de las longi tudes de sus lados LadoUno y LadoDos y de suDiagonal, etc.

El concepto de herencia está muy ligado a las metodologías de análisis ydiseño de software orientadas a objetos . Aunque en es te apartado sólo seha me nc ion ad o la herencia sim ple entre un "hijo" y un único "padre", es

posib le real izar d iseños en los que se tengan en cuenta herencias múlt ip lesde varios "padres". En esencia se t ra ta de aprovechar e lementos yadesar ro l l ados para p roduc i r o t ro nuevo que combine s imul táneamen te l ases t ructuras y propiedades de más de un elemento anter ior .

La aplicación del concepto de herencia en la fase de diseño es posible sinmayor problema. Sin embargo, para t ras ladar de una manera d irecta ysencilla los resultados del diseño a la codificación es aconsejable uti l izar unlenguaje de programación orientado a objetos . Algunos de es tos lenguajesson los siguientes:

• Smalltalk• Object Pasca l• Objetive-C• Eiffel• C++

Todos ellos disponen del mecanismo de herencia. En [Budd94] se detallanlas part icular idades del mecanismo de herencia propuesto por cadalenguaje .



118 In troducción a la Ingenier ía de Software

3.2 .8 Pol imorfismo

La defin ición de pol imorfismo que encontramos en el d iccionario es las iguiente:

Pol imorfismo. Propiedad de los cuerpos que pueden cambiar deforma s in variar su naturaleza.

En nuestro caso , e l concepto de pol imorfismo engloba d is t in tasposib i l idades u t i l izadas habi tualmente para conseguir que un mismoelemen to so f tware adqu ie ra var ias fo rmas s imul táneamen te :

1.- El concepto de generic idad in t rodu cido an ter iorm ente es una m anera delograr que un elemento genérico pueda adquir i r d is t in tas formascuando se part icular iza su u t i l ización .

2 . - El concepto de pol imorfismo es tá muy unido al concepto de herencia .Como se indicó anter iormente , las es t ructuras y operacionesheredadas se pueden adaptar a las neces idades concretas delelemento "hijo": no es lo mismo Rotar ELIPSES que CÍRCULOS. Portanto, la operación de rotar t iene distintas formas según el t ipo defigura a la que se destina y es en el momento de la ejecución delprograma cuando se u t i l iza una u o tra forma de ro tación . Este t ipode pol imorfismo se conoce como de Anulación, dado que la ro taciónespecífica para los círculos anula la más general para las elipses.

En algunos casos, no hay anulación real dado que no tiene sentidodiseñar e implementar una operación general que abarque todas lasposib les s i tuaciones que se puedan p lantear con todos los posib lesdescendientes . Para es tos casos se p lantea un pol imorfismo Difer idoen el cual se plantea la necesidad de la operación para el elemento"padre", pero su concreción se deja diferida para que cada uno de los

elementos "hijos" concrete su forma específica. Este es el caso de laoperación Rotar FIGURAS que resul tar ía muy compleja y ademásprobablemente inút i l .

3.- Por últ imo, existe otra posibilidad de polimorfismo que se conoce comoSobrecarga. En este caso quienes adq uiere n m últ ip les form as son losoperadores , funciones o procedimientos . El e jemplo clás ico depol imorfismo por sobrecarga lo const i tuyen los operadoresmatem áticos: + , - , * y / . E s tos ope rad ores son s imilares paraoperaciones entre enteros, reales, conjuntos o matrices. Sin embargo,en cada caso el t ipo de operación que se invoca es distinto: la suma




entre enteros es mucho más sencil la y rápida que la suma entrereales y por otro lado con el mismo operador + se indica laoperación suma entre valores numéricos o la operación de uniónentre dos conjuntos o la suma de matrices. En el diseño de estaSobrecarga de operadores, a pesar de que nos resulta tan familiar, seha uti l izado e l concepto de polimorf ismo. Este mismo concepto sedebe aplicar cuando se diseñan las operaciones a realizar entreelementos del sistema que se trata de desarrollar. Por ejemplo, sepuede utilizar el operador + para unir r istras de caracteres o realizarresúmenes de ventas.

El polimorf ismo por Sobrecarga también se puede uti l izar confunciones o procedimientos. Así , podemos tener la función Pintarpara FIGURAS y diseñar también una función Pintar pararepresentar en una gráfica los valores de una tabla o rellenar condistintos trazos una región de un dibujo, etc.

Todas estas posibil idades de polimorf ismo redundan en una mayorfacilidad para realizar software reutilizable y mantenible. Si se quierediseñar un módulo que uti l ice mucha gente , los e lementos que sepropo ngan d eberán resul ta r familiares al may or núm ero posible de usuar iospotenciales.

Al igual que la herencia, el concepto de polimorfismo está ligado a lasmetodologías or ientadas a objetos y para simplif icar la implementación esconveniente utilizar algún lenguaje orientado a objetos de los indicados enel apar tado anter ior .

3.2.9 Concurrencia

Los computadores disponen de una gran capacidad de proceso que no se

debe desap rovechar . M ientras el operado r decide la s iguiente tecla que debepulsar o durante e l t iempo en que se está imprimiendo, e l computadorpuede real izar de manera concurrente otras tareas. Sobre todo en lossistemas de tiempo real existe la necesidad de aprovechar toda la capacidadde proceso del computador para a tender a todos los eventos que seproducen y en e l mismo instante en que se producen. En estos casosnormalmente se establecen t iempos máximos de respuesta antedeterminados eventos (alarmas, fallos, errores, etc.) .

Cuando se tra ta de diseñar un sistema con restr icciones de t iempo se debetener en cuenta lo siguiente:




1.- TAREAS CONCURRENTES:Determinar qué tareas se deben ejecutar enparalelo para cumplir con las restricciones impuestas. Se deberá

prestar especial atención a aquellas tareas con tiempos de respuestamás críticos y aquellas otras que se ejecutarán con mayor frecuencia.Al diseño y codif icación de ambos grupos de tareas se debe prestarespecia l cuidado, pues de e l lo depende que se cumplan f inalmentelas restricciones.

2.- SINCRONIZACIÓN DE TAREAS: Determinar los puntos de sincronizaciónentre las dist intas tareas. Normalmente las tareas nunca funcionancada una por separado sin tener en cuenta a las demás. Cuando una

tarea TI se encarga de obtener un resultado que debe utilizar otraT2, ambas se deben sincronizar. La tarea T2 esperará hasta que TItenga disponible un n uevo resultado y en e l caso de qu e T2 no hayautilizado el anterior resultado es TI la que debe esperar. Para lasincronización entre tareas se pueden utilizar semáforos omecanismos de t ipo rendezvous disponibles en los sistemasoperativos o en lenguajes de programació n con currentes (Ada, PascalConcurrente, etc.) .

3.- COMUNICACIÓN ENTRE TAREAS: Determinar si la cooperación se basa enel empleo de datos compart idos o mediante e l paso de mensajesentre las tareas. En cualquier caso, el diseñador debe concretar laestructura de los datos compart idos o de los mensajes que seintercambian. También se debe concretar qué tareas serán lasproductoras de los datos y qué otras serán las consumidoras. En e lcaso de uti lizar datos com part idos se tend rá qu e evitar que los datospuedan ser modif icados en e l momento de la consulta , lo que dar íalugar a errores muy difíciles de detectar. En este caso, es necesarioutilizar mecanism os com o semáforo s, mon itores, regione s críticas, etc.para garantizar la exclusión mutua entre las distintas tareas quemodif ican y consultan los datos compart idos. Estos mecanismos

están disponibles en los sistemas operativos o en lenguajes deprogramación concurrente .

4.- INTERBLOQUEOS (deadlock): Estudiar los posibles interbloqueos entretareas. Un interbloqueo se produce cuando una o var ias tareaspermanecen esperando por t iempo indef inido una si tuación que nose puede producir nunca. Por ejemplo, el caso más sencillo deinterbloqueo entre dos tareas se produce cuando ambassimultáneamente se quedan esperando algún resultado que se debenproporcionar mutuamente la una a la otra y ninguna puede avanzar .




El concepto de concurrencia introduc e un a comp lejidad adicional a l s is temay por tanto sólo se debe utilizar cuando no exista una solución de tiposecuencial sencilla que cumpla con los requisitos especificados en eldocumento SRD. En general, se requieren conocimientos específicos para eldiseño de sistemas concurrentes o de tiempo real [BenAri89] y en grannúm ero de casos la solución f inalmen te ado ptad a resulta ser comp letamentea la medida.

3.3 Nota cion es par a el diseño

Para concretar y precisar las descripciones resultantes de todo el proceso dediseño se pueden utilizar múltiples notaciones. Como sucedía con laespecif icación, cada notación de diseño ha sido propuesta dentro de unametodología concreta, y un mismo símbolo (rectángulo, círculo, etc.) puedetener significados distintos según los casos. Además, debido a la evoluciónde las metodologías y según las propuestas de dist intos exper tos ofabricantes de herramientas de diseño, se utilizan distintos símbolos pararepresentar una misma idea. De las decenas de notaciones que existen, eneste apar tado se ha tra tado de recoger aquellas que disfrutan de mayoraceptación, empleando para e l lo los símbolos ut i l izados más comunmente .A pesar de todo, s i se ut i l iza una nueva herramienta o metodología dediseño, es muy aconsejable cerciorarse antes del significado de cadasímbolo. Con este repaso panorámico se trata de facilitar el aprendizaje decualquier notación nueva si tuándola dentro del contexto adecuado.

El objetivo fundamental de cualquier notación es resultar precisa, clara ysencilla de interpretar en el aspecto concreto que describe. Se trata sobretodo de evi ta r ambigüed ades e interpretaciones erróneas del diseño. En estesentido lo más adecuado ser ía emplear notaciones formales de t ipo cuasimatemático. Sin embargo, sólo una par te muy pequeña del resultado de undiseño se suele descr ibir ut i l izando únicamente notaciones formales.

Resulta muy difícil establecer dónde queda la frontera entre laespecificación y el diseño de las características externas o estructurales deun sistema. Así, resulta normal que para ciertos aspectos de diseño seempleen notaciones semejantes e incluso las mismas del análisis. Para estasnotaciones nos remitiremos a lo dicho en e l apar tado del Tema anter iordedicado a las notaciones para la especificación.

Según el aspecto del sistema qu e se trata de des cribir es aconsejable emplearuna u otra clase de notación. D e acue rdo con este criterio, clasificaremos lasnotaciones en los siguientes grupos:



122 Introd ucció n a la Ingeniería de Softw are

Notaciones estructurales• No taciones estáticas o de organ ización• Notaciones dinám icas o de com portam iento• Notaciones híbr idas

El lenguaje natural co mo notación qu eda fuer a de esta c lasificación puestoq u e se puede utilizar para cubrir cualquier aspecto del sistema. Siempre quese utilice, se deberán tener en cuenta las recomendaciones dadas en el Temaanter ior y en todo caso, se procurará ut i l izar solamente com o com plemen toa otras notaciones.

3 .3 .1 Notac iones e s t ruc tu r a le s

Estas notaciones sirven para cubrir un primer nivel del diseño

arquitectónico y con ellas se trata de desglosar y estructurar el sistema ensus par tes fundamentales. En pr incipio, cualquier notación informalutilizada en otras actividades de ingeniería y que permita describir laestructura global de un sistema, puede ser válida . Una notación habitualpara desglosar un sistema en sus par tes es e l empleo de diagramas debloques.

En la figura 3.1 se muestra el diagrama de bloques de un sistema que estádividido en cuatro bloques y en e l que además se indican las conexionesque existen entre ellos. En algunos casos estas conexiones también puedenreflejar una cierta clasificación o jerarquía de los bloques. Cuando la

A

C

D

Figura 3.1 Diagrama de B loques



Fu nda me ntos del Diseño de Softw are 123

notación es informal, es necesario concretar esplícitamente si con eldiagrama se indica algo más que la simple conexión existente entre losbloques.

Capa 1

Capa 2

Capa 3

Capa 4

Capa 5

Capa 6

Capa 7

( a ) ( b )Figura 3.2 Diagramas de cajas adosadas

Otra notación informal para estructurar un sistema se muestra en la f igura3.2. En este caso se em plea n "cajas ados adas " pa ra d elimita r los bloques. Laconexión entre los bloques se pone de manif iesto cuando entre dos cajasexiste una f rontera común.

En el diagrama (a) de la figura 3.2 se muestra un sistema organizado por

capas. Esta estructura se emplea, por ejemplo, en el estándar OSI decomunicaciones. En él se establecen 7 capas o niveles: Físico, Enlace, Red,Transporte, Sesión, Presentación y Aplicación. A grandes rasgos, cada capaes un subsistema hardware o sof tware encargado de incorporar a losmensajes que se envían c ier ta información red un dan te adic ional . La mism acapa al recibir un mensaje se encarga de eliminar las redundanciasintroducidas en el envío y comprobar si la información recibida es correcta.Entre capas adyacentes está def in ida una interfaz com pletam ente estándar .Todo esto posibil i ta que las modif icaciones en la implementación de unacapa nunca afecten a l resto y que e l sof tware de comunicaciones dedistintos fabricantes sea compatible.

I

EP 1

SP 2 S

T

S



124 Intro duc ción a la Ingen iería de Sof twa re

Otro ejemplo es la propuesta de Hat ley [Hat ley87], que sugiere comoplant i l la de arqui tectura para es t ructurar los s is temas la que se muestra enla figura 3.2 (b). Los subsistemas generales propuestos en la plantil la son:E (Entrada), S (Salida), T (Test para la autocomprobación y elmantenimiento), I (Interfase de usuario) y Pl, P2, . . . . (Procesado y controldel s is tema). A cont inuación se presentan algunas notaciones más formalespara describ ir la es t ructura de un s is tema.

F i gu ra 3 .3 D i ag rama de es t ruc tu ra

3 .3 .1 .1 D iag ram as d e e s t r u c t u r a

Estos d iagramas fueron propuestos por Yourdon [Yourdon79] y Myers[Myers78] para describ ir la es t ructura de los s is temas software como una

jerarquía de subprogramas o módulos en general . En la f igura 3 .3 semu es t ra un d iag rama de es t ruc tu ra . El s ignif icado de los s ímbolos u t i l izadoses el siguiente:

RECTÁNGULO: representa un módulo o subprograma cuyo nombre se indicaen su interior

L Í N E A : une a dos rectángulos e indica que el módulo superior l lama outil iza al módulo inferior. A veces la l ínea acaba en una flecha juntoal módulo infer ior a l que apunta .




RO M BO : se sitúa sobre una Línea e indica que esa llamada o utilización es

opcional. Se puede prescindir de este símbolo si en la posteriordescr ipción del módulo super ior , mediante pseudocódigo u otranotación, se indica que el módulo inferior se utiliza sóloopcionalmente .

A R C O : se sitúa sobre una Línea e indica que esa llamada o utilización seefectúa de manera repetitiva. Se puede prescindir de este símbolo sien la poster ior descr ipción del módulo super ior , mediantepseudocódigo u otra notación, se indica que e l módulo infer ior seutiliza de forma repetitiva.

CÍRCULO CON FLECHA: se sitúa en paralelo a una Línea y representa el envíode los datos, cuyo nombre acompaña a l s ímbolo, desde un móduloa otro. El sentido del envío lo marca la flecha que acompaña alcírculo. Para indicar que los datos son una información de control seutiliza un círculo relleno. Una información de control sirve paraindicar SI/NO, o bien un estado: Correcto / Repetir / Error / Espera/ Desconectado / ....

En el Tema siguiente se verán técnicas de diseño que permiten obtener eldiagrama de estructura a partir de la especificación. Cuando el diseño

realizado es razonablem ente correcto, e l resultado es un d iagram a en formade árbol mostrando la jerarquización de los módulos. Como sucede en laf igura 3.3, es normal que var ios módulos super iores ut i l icen un mismomódulo inferior, lo que significa que ese módulo se reutiliza en variospuntos del s is tema.

El diagrama de estructura no establece ninguna secuencia concreta deutilización de los módulos y tan sólo refleja una organización estática de losmismos. Por ejemplo, en la figura 3.3 el módulo A utiliza a los módulos B,C y D en cualquier orden sin tener en cuenta su situación a la izquierda, ala derecha o en el centro.

Observando el diagrama de la f igura 3.3 se puede decir lo siguiente:

• El mó dul o E propo rciona e l dato U al m ódu lo B. Este dato es unaentrada al sistema (teclado, ratón, generación por cálculo, etc.) .

• El mó dul o B transfo rma el dato U y obtiene e l dato X queproporc iona a l mó dulo A. El m ódu lo A uti l iza a l m ód ulo B de formarepetitiva.




• El m ód ulo A propo rciona a l mó dulo C el dato Y y este úl t imo le

devuelve a l módulo A la información de control Z.

• El m ó d u l o C proporc iona a l mó dulo F el dato V. También, e l móduloD proporciona a l módulo F e l mismo dato V.

• El mó dulo F no devue lve nada a n ingun o de sus módulossuperiores. Eso ocurre, por ejemplo, si se encarga d e realizar la salidade los datos que se le envían (impresora, pantalla, etc.) .

• El m ód ulo D se utiliza opc ionalm ente por A y recibe de este últimoel dato X que a su vez A recibió de B.

• El dia gra m a es estrictam ente jera rqu izad o y no existen Líneas entremódulos de un mismo nive l .

F igura 3 .4 D iagrama HIPO de conten idos

3 .3 .12 Diagramas HIPO

Los diagramas HIPO (Hierarchy-Input-Process-Output) son una notaciónpropuesta por IBM para facilitar y simplificar el diseño y desarrollo desistemas sof tware , dest inados fundamentalmente a gest ión ( facturación,




contabilidad, nóminas, inventario, etc.) . La mayoría de estos sistemas se

pueden diseñar como una estructura jerarquizada (Hierarchy) desubprogramas o módulos. Además, e l formato de todos los módulos sepuede adaptar a un mismo patrón caracter izado por los datos de entrada(Input), el tipo de proceso (Process) que se realiza con los datos y losresultados de sal ida que proporciona (Output) .

DE: N (i.j)

O

Datos_A I

Datos_B f

Diagrama: a.b

Pseudocódigo

del Proceso

con referencias

a otros diagramas

de detalle: L (k,m)

TTPARA: M (k,l)q (m,n)

Datos N

Datos_M

Titulo del Diagrama: A

F igura 3 .5 D iagrama HIPO de de ta l l e

La f igura 3.4 muestra un diagrama HIPO de contenidos que se ut i l iza paraestablecer la jerarquía entre los módulos del s is tema. Como se puedeobservar, es asimilable a un diagrama de estructura simplificado en el queno se indican los datos que se intercambian los módulos. Cada módulo

tiene un nombre (A, B, C, . . .) y una referencia al correspondiente diagramaHIPO de detalle (0.0, 1.0, ....).

En la f igura 3.5 tenemos e l diagrama HIPO de deta l le del módulo cuyonombre es A y referencia (a.b). Los diagramas de detalle constan de treszonas: Entrada (I), Proceso (P), Salida (O). En las zonas de entrada y salidase indican respectivamente los datos que entran (Datos_A y Datos_B) ysalen (Datos_N y Datos_M) del módulo. En la zona central se detalla elpseudocódigo del proceso con referencia a otros diagramas de deta l le denivel inferior en la jerarquía. La lista de los diagramas referenciados se



128 Introd ucció n a la Ingeniería de Softw are

listan a continuación de la partícula PARA: Por la parte superior y acontinuación de la partícula DE: se indica el diagrama de detalle de nivelsuperior: N(i,j).

3.3.1 .3 Diagrama s d e J ackson

Esta notación forma par te de la metodología desarrollada por JacksonLJackson75], [Jackson83] para diseñar sistemas software a partir de lasestructuras de sus datos de entrada y sa l ida . El proceso de diseño esbastante sistemático y se lleva a cabo en tres pasos:

A B C

x y*

z0 0

u V

Secuencia Iteración Selección

F i gu ra 3 .6 No tac i ón de Jac kson

1.- Especificación de las estructuras de los datos de entrada y salida

2.- Obtención de una estructura del programa capaz de transformar lasestructuras de datos de entrada en las de salida. Este paso implicauna conversión de las estructuras de datos en las correspondientes

estructuras de programa que las manejan, teniendo en cuenta lasequivalencias clásicas entre ambas:

TUPLA - SECUENCIA: Colección de elementos de tipos diferentes,combinados en un orden f i jo.

UNIÓN - SELECCIÓN: Selección de un elemento entre varios posibles,de t ipos diferentes.

FORMACIÓN - ITERACIÓN: Colección de elementos del mismo tipo.




3.- Expansión d e la estructura del p rogram a p ara lograr e l diseño deta l ladodel sistema. Para realizar este paso normalmente se utilizapseudocódigo.

La metodología Jackson está englobada dentro de las de Diseño Dirigidopor los Datos, que ha sido uti l izado fundamentalmente para diseñarsistemas re la t ivamente pequeños de procesamiento de datos.

La notación pro pu est a po r Jackson se m ues tra , en la figura 3.6 y sirveindistintamente para especificar tanto la estructural de los datos como la

estructura del programa. En estos diagramas la éstrúctura del e lementosuper io r se deta l la según que da indicado po r los e lementos inm edia tamenteinferiores. En este caso es fundamental la situación de cada elemento en eldiagrama. En la figura 3.6, el elemento A es igual a la secuencia x-y leídade izq uierd a a d erecha y n unc a a la inversa. El eleme'nto B es igual a larepetición de cero o m ás veces del elem ento z (indicado po r el símbo lo "*").El e lemento C es igual a una selección entre los e lementos u y v ( indicadopor el símbolo "O").

F igura 3 .7 D iagrama de Jackson

En la figura 3.7 se muestra un diagrama de Jackson y la estructura deprograma equivalente . Si los e lementos del diagrama representan datos, la




estructura equivalente , expresada en notación de diccionario de datos, es lasiguiente:

A = B + C + DC = [ E | F ]E = { G }F = H + I

3 .3 .2 Nota c iones e s t á t i c a s

Estas notaciones sirven para describir características estáticas del sistema,tales como la organización de la información, sin tener en cuenta suevolución durante e l funcionamiento del s is tema. La organización de lainformación es uno de los aspectos en los que se hace un especial hincapiéal especificar el sistema. Sin embargo, en el documento SRD deespecif icación sólo se real iza una propuesta de organización a grandesrasgos y de acuerdo exclusivamente con las necesidades externas delsistema. En la fase de diseño se completa la organización de la informaciónteniendo en cuenta todos los aspectos internos: datos auxil iares, mayoreficiencia en el manejo de los datos, datos redundantes, etc. Por tanto, comoresultado del diseño se tendrá una organización de la información con un

nivel de detalle mucho mayor. En cualquier caso, las notaciones que sepueden emplear para descr ibir e l resultado de este trabajo son las mismasque se emplean para realizar la especificación.

3.3.2.1 Diccionar io d e d a to s

Con esta notación se detalla la estructura interna de los datos que manejael sistema. Las características de esta notación ya han sido descritas en elapar tado de descr ipción de datos del Tema de especif icación de sof tware .Para el diseño se partirá del diccionario de datos incluido en el documento

SRD y med iante los ref inamien tos necesar ios se amp liará y co mpletaráhasta alcanzar el nivel de detalle necesario para iniciar la codificación. Enel próximo Tema se estudiarán las técnicas para realizar esta labor.

3.3.2.2 Diagra m as En tidad -Relación

Esta notación permite definir el modelo de datos, las relaciones entre losdatos y en general la organización de la información. Esta notación estádescr i ta en e l apar tado de diagramas de modelo de datos del Tema deespecificación d e software. Para la fase de diseño se tom ará com o pun to depar t ida e l diagrama propuesto en e l documento SRD, que se completará y



Fu nda me ntos del Diseño de Software 131

ampliará con las nuevas entidades y relaciones entre las mismas, queaparezcan en la fase de diseño del sistema.

3.3.3 Not acion es dinám icas

Estas notaciones permiten descr ibir el com portam iento del s is tema d ura ntesu funcionamiento. La especif icación de un sistema es precisamente unadescr ipción del com portam iento requ er ido desd e un pun to de vista externo.Al diseñar la dinámica del s is tema se deta l lará su com portam iento externoy se añadirá la descr ipción de un comportamiento interno capaz de

garantizar que se cumplen todos los requisi tos especif icados en e ldocumento SRD. Así, las notaciones que se emplean para el diseño son lasmismas utilizadas en la especificación.

3.3 .3 .1 Diagrama s d e f lu j o d e da tos

Las características de esta notación están detalladas en el Tema deespecificación de software. Desde el punto de vista del diseño, losdiagramas de f lujo de datos serán mucho más exhaustivos que los de laespecificación. Esto es debido a la necesidad de describir cómo se hacen

internamente las cosas y no sólo qué cosas debe hacer el sistema.3.3 .3 .2 Diagramas de t r an s ic ión d e es ta d os

Esta notación está descrita en el Tema de especificación de software. En eldiseño del s is tema pueden aparecer nuevos diagramas de estado quereflejen las transicione s entre estad os internos. Sin embargo , es preferible nomodif icar o ampliar los diagramas recogidos en e l documento SRDencargados de ref le jar e l funcionamiento externo del s is tema.

3.3.3.3 Lenguaj e d e Descr ipción d e Pr ogra ma s (PDL)

La notación PDL ha sido presentada en e l apar tado dedicado alpseudocódigo del Tema de especif icación de sof tware . Como all í secomentaba, esta notación se utiliza tanto para realizar la especificaciónfuncional del sistema como para elaborar el diseño del mismo. La diferenciaentre ambas situaciones la marca el nivel de detalle al que se desciende enla descripción funcional.

Tanto al especificar como al diseñar se utilizan las mismas estructurasbásicas de la notación PDL. Sin embargo, cuando se quiere descender alnivel de detalle que se requiere en la fase de diseño, la notación PDL se




amplía con ciertas estructuras de algún lenguaje de alto nivel. Uno de loslenguajes más apropiados para estos fines es Ad a. La notación den om inadaAda-PDL permite declarar estructuras de datos e incluso existencompi ladores pa ra ve r i f ica r e l cor respondiente pseudocódigo.Evidentemente, a nivel de diseño, los detalles de implementación se dejaránindicados mediante comentar ios en lenguaje natural . Ada-PDL ha sidoincluido como estándar en las normas IEEE. Aunque no es tota lmenteformal conduce a descr ipciones precisas, poco ambiguas, y re la t ivamentefáciles de comprender si se conoce suficientemente el lenguaje Ada.

3.3 .4 Nota c iones h íbr idas

Estas notaciones tra tan de cubrir s imultáneamente aspectos estructurales,estáticos y dinámicos. En realidad algunas de las notaciones descritasanter iormente , aunque han sido c lasif icadas dentro de un grupo concreto,poseen también ciertas características del resto de los grupos.

Según hemos visto, la metodología de Jackson utiliza una notaciónestructural que describe, según los casos, la organización de la información(estática) o el comportamiento (dinámico) del sistema y está basadaprecisamente en aprovechar la analogía que existe entre la organización de

los datos y los procedim ientos o pro gram as necesar ios para su manejo. Portanto, se podría considerar como una notación híbr ida . También lametodología de diseño or ientada a los datos de Warnier-Orr posee unanotación que se puede considerar híbr ida por las mismas razones: se par tede la organización de los datos para diseñar los procedimientos. Para unestudio en detalle de esta metodología se pueden consultar [Warnier81] y[Orr81].

Prescindiendo de las notaciones de Jackson y Warnier, el objetivofundamental de este apar tado es presentar las notaciones más modernasque se han propuesto dentro de las metodologías de diseño basado en

abstracciones y de diseño orientado a objetos. Todas estas notaciones sonhíbr idas y permiten un enfoque globalizado del diseño en e l que seaglutinan los aspectos estáticos (datos), dinámicos (operaciones) y deestructura del sistema.

3.3 .4 .1 Diagramas de abs t r acc iones

Como ya hemos visto en este mismo Tema, e l concepto de abstracción esfun dam ent al para la estructuración d e sistemas complejos. La notación q ueaquí se describe fue propuesta originalmente por Liskov [Liskov80] para

descr ibir la estructura de un sistema sof tware compuesto por e lementos




abstractos. En la propuesta or iginal se contemplaban dos t ipos deabstracciones: las funciones y los tipos abstractos de datos. A ellos se hanañadido con símbolo propio [CerradaOO] los datos encapsulados.

Dada la afinidad existente entre los tipos abstractos de datos y las clases deobjetos, al tiempo que se presenta la notación para describir abstracciones,se aprovecha para establecer una cierta analogía entre la programaciónbasada en abstracciones y la programación or ientada a objetos.

Nombre Nombre

Contenido Atributos

Operaciones Métodos

( a ) ( b )

F igura 3 .8 Es t ru c t ur a de una Ab st r ac c ió n (a) y de un O bj et o (b)

Según se muestra en la figura 3.8 (a), en una abstracción se distinguen trespar tes o e lementos c laramente diferenciados:

NOMB R E: ES el identificador de la abstracción

C O N T E N I D O : E S el elemento estático de la abstracción y en él se define laorganización de los datos que constituyen la abstracción. Si seutilizase el lenguaje Modula-2, este elemento lo formarían lasdef inic iones de constantes, t ipos de datos y var iables declarados enel módulo de def inic ión.

OP ER AC IONES : ES el elemento dinámico de la abstracción y en él se agrupantodas las operaciones def inidas para manejar e l C O N T E N I D O de laabstracción. Si se utilizase el lenguaje Modula-2, este elemento estaría




formado por la s de f in ic iones de func iones y /o procedimientosdeclaradas en e l módulo de def inic ión.

Inicialmente la única forma de abstracción disponible en los lenguajes, y portanto con la que únicamente se podía abordar un diseño, era la def inic iónde subpro gram as: funciones (expresiones parametr izadas) o procedimientos(acciones parametr izadas) . Un subprograma consti tuye una operaciónabs t rac ta que denominaremos abstracción funcional. Esta forma deabstracción no tiene la parte de C O N T E N I D O y sólo está constituida por unaúnica O P E R A C I Ó N .

Al analizar y diseñar un sistema se identifican datos de diferentes tipos conlos que hay que operar . En un diseño bien organizado se puede agrupar enuna misma entidad la estructura del t ipo de datos con las correspondientesoperaciones necesarias para su manejo. Esta forma de abstracción sede nom ina tipo abstracto de datos y t iene una par te de CO N T E N I D O ytambién sus correspondientes O PE RA CI O N E S.

Los tipos abstractos de datos permiten crear nuevos t ipos de datos, ademásde los predef inidos en e l lenguaje de implementación. Todos los datosconcretos que se manejen en un programa deben aparecer como constanteso var iables de a lgún t ipo, sea predef inido o def inido como t ipo abstracto.Para ope rar con un d ato en par t icular se invocará a lguna de las operacionesdef inidas sobre su t ipo, indicando a qué dato en par t icular queremosaplicarla. Por ejemplo, si tenemos el tipo abstracto Tarjeta y se declara:

V A R tar jeta4B, tar jetaVISA : Tar jeta;

podremos indicar con cuál de e l las queremos real izar una operaciónhaciéndola aparecer como argumento de la misma, por e jemplo:

LeerTarjeta( tarjeta4B );

ComprobarTar jeta( tar jetaVISA );

Cuando sólo se necesi ta una var iable de un determinado t ipoabstracto, su declaración se puede encapsular dentro de la mismaabstracción. Así, todas las operaciones de la abstracción se referiránsiempre a esa variable sin necesidad de indicarlo de manera explícita.Esta forma de abstracción se denomina Dato encapsulado, tieneC O N T E N I D O y OPERACIONES, al igual que un tipo abstracto, pero nopermite declarar otras var iables de su mismo t ipo.




Abstracción funcional

Tipo Abstracto de datos

Dato encapsulado

F igura 3 .9 Abst racc iones: notac ión bás i ca

En el ejemplo anterior, si sólo se maneja una Tarjeta, se podríadeclarar:

MODULE Ta r j e ta ;E X P O R T LeerTarje ta , ComprobarTar je ta ;V A R «dato s de la tarjeta» ...

END Tarjeta;

e invocar las operaciones simplemente como:

LeerTar jeta;

ComprobarTar je ta ;

En la figura 3.9 se muestra la notación gráfica para indicar laforma de abstracción que se está empleando.

En la figura 3.10 tenemos el diagrama de estructura de un sistema.En este caso los módulos son abstracciones en sus dist intas formasposibles y la relación entre abstracciones es jerárqu ica e implica q uela abstracción superior utiliza a la inferior. Así, la abstracciónfuncional A utiliza el dato encapsulado D y el tipo abstracto B. Aldato encap sulado D también lo ut i l izan B y la abstracción funcional

C. A su vez, la abstracción fun cion al C tam bién es utilizada p or B.




A

ñF i gu ra 3 . 1 0 Diag rama de es t ruc tu ra basada en abs t rac c i ones

3.3 .4 .2 D ¡agramas d e ob je t os

La metodología de diseño basado en abstracciones y la metodologíaor ientada a los objetos se han desarrollado de forma parale la pero enámbitos muy dist intos. Las abstracciones se pueden considerar unapropuesta de los exper tos en programación, mientras que los objetos sonuna propuesta de los expertos en inteligencia artif icial. Aunque lassimil i tudes entre ambos conceptos son muy grandes, su desarrollo endistintos ámbitos ha propiciado la utilización de una terminología distintapara indicar lo mismo. Esto da lugar a cierta confusión.

Como se indica en la figura 3.8 (b), la estructura de un objeto es

exactamente igual que la estructura de una abstracción. En cuanto a latermino logía em ple ada se pu ed e establecer la equivalen cia que se recogeen el cuadro 3.1.

Las diferencias fundamentales entre ambos conceptos son las siguientes:

1.- N o existe na da equiv alente a los dat os encap sula dos ni a lasabstracciones funcionales cuando se utilizan objetos en forma estricta(algunos lenguajes, com o SmallTalk, sup len esta carencia pe rm itien doasociar atributos y métodos a las clases).




2.- Sólo entre objetos se con tem pla una relación de herencia.

Teniendo en cuenta la escasa diferencia entre ambos planteamientos, en elresto de este Tema utilizaremos la terminología de objetos, debido a lamayor aceptación que ha a lcanzado.

ABSTRACCIONES OBJETOS

Tipo Abstracto de DatosAbstracción FuncionalDato encapsulado

Clase de ObjetoNO HAY EQUIVALENCIANO HAY EQUIVALENCIA

Dato Abstracto(Variable o Constante)

Objeto (Ejemplar de la Clase)

ContenidoOperac iones

Atr ibutosM é todos

Llamad a a una operación Mensaje a l Objeto

Cuadro 3.1 Equiva lenc ias de terminologías

Si consideramos un objeto formado exclusivamente por sus a tr ibutos,tendremos una estructura de datos. Esta estructura , como cualquier otra ,puede formar par te de un diagrama de modelo de datos E-R (Entidad-Relación) como una entidad más. Inversamente, es admisible considerar qu e

todas las entidades en un mo delo de d atos son objetos (o más exactamente ,clases de objetos). Como entidades, e n t r e objetos se p u e d e d e s t a c a rcualquier tipo de relación que el diseñador considere necesaria. Además,debido a las propiedades par t iculares de los objetos, se pueden establecerentre ellos dos tipos de relaciones especiales:

A.- CLASIFICACIÓN, ESPECIALIZACIÓN O HERENCIA: ( N O contemplada entreabstracciones)

Esta relación entre objetos permite diseñar un sistema aplicando el

concepto de herencia. Como ya se indicó al hablar de herencia, los



«, iu uigciucud ue ooiuware

objetos "h i jos" pueden adaptar las operaciones heredadas a susnecesidades concretas . Así , la herencia también se puede denominarespecialización o clasificación. Para ratificar esta afirmación escompletamente vál ido el e jemplo de las FIGURAS que hemosclasificado en ABIERTAS, CERRADAS, Las operaciones para ro tar ,desplaz ar , e tc . se hered an y especial izan según la es t ructura concretade la figura "hija".

Hijo_Uno Hijo_Tres

F igura 3 .11 C las i f i cac ión, esp ec ia l i zac ión o heren c ia ent r e ob je to s

En la figura 3.11 se muestra un ejemplo de herencia entre objetos. Lanotación empleada es la sugerida por la metodología OMT (ObjectModelling Technique) descrita en [Rumbaugh91], Con el triángulo se indica

que los objetos inferiores (Hijo_Uno, Hijo_Dos e Hijo_Tres) heredan losatributos y las operaciones del objeto superior (Padre). De esta mismametodología también forma parte la notación empleada en la f igura 3.8 paradescribir una abstracción u objeto. Hay que tener en cuenta que existe ungran número de notaciones para representar objetos y sus re lacionespart iculares , por lo que para t rabajar con unos d iagramas concretos esconveniente consul tar e l correspondiente manual de la herramienta desoporte o un texto específ ico sobre la metodología empleada.



Fun dam ento s del Diseño de Softw are 139

Con la relación de herencia no es necesario indicar la cardinalidad entre lasclases de objetos, que está implícita en el diagrama, ya que en él apareceexpresamente cada relación de herencia entre clases.

Estructura

s z -

Elemento_l Elemento_2 Elemento_3

Figu ra 3.12 Compos ic ión de obje tos

B. - CO MPO SI CI Ó N (También válida entre abstracciones)

La relación de composición permite describir un objeto mediante loselementos que lo forman. En la f igura 3.12 se muestra la relación decomposición con la notación OMT. El rombo indica que el objetoEstructura está compuesto de E l e m e n t o _ 1 , E lemento_2 yE lemento_3.

En la relación de composición sólo hay que indicar la cardinalidaden un sentido. Cada objeto hi jo sólo puede formar par te de un objetopadre . Sólo fa l ta indicar qué número mínimo y máximo de objetos decada clase hija se pueden utilizar para componer un objeto de laclase padre . Como se muestra en la f igura 3.12, la cardinalidad seindica junto a cada uno de los objetos componentes. Así , para formarEstructura son necesarios cero o varios Elemento_1, uno y sólo unE lemento_2 y al menos un E lemento_3.




3.4 Docum entos d e d iseño

El resultado principal de la labor realizada en la etapa de diseño se recogeen un documento que se ut i l izará como elemento de par t ida para lassucesivas e tapas del proyecto, y que denominaremos documento de diseñode software o Software Design Docum ent (SDD). Cuan do la complejidad delsistema haga que e l documento SDD resulte muy voluminoso y dif íc i l demanejar es habitual ut i l izar dos o más documentos para descr ibir de formajerarquizada la estructura global del s is tema.

Existen numerosas propuestas para la organización de los documentos y dehecho probablemente cada empresa ut i l ice uno dist into. Organismosinternacionales como IEEE [IEE87], el Departamento de Defensanorteamericano [ D 0 D 8 8 ] o la Agencia Espacial Europea [ESA91] hanpropuesto sus propias normas de documentación, bien como simplesrecomendaciones o como normas de obligado cumplimiento cuando serealiza un trabajo para dichos organismos.

Las normas de la ESA establecen el empleo de un Documento de DiseñoArquitectónico o "Architectural Design Document" (ADD) para describir elsistema en su conjunto y otro Documento de Diseño Detallado o "DetailedDesign Document" (DDD) para describir por separado cada uno de loscom pone ntes del s is tema. Los índices de estos doc um entos están recogidosen los cuadros 3.2 y 3.3 respectivamente. Los contenidos de cada apartadoson los siguientes:

3.4.1 Documento ADD

1. INTRODUCCIÓN

Esta sección debe dar una visión general de todo e l documento ADD. Los

contenidos de sus apartados (Objetivo, Ámbito, Definiciones, siglas yabreviaturas, y Referencias) serán similares a los descritos en el Temaanterior para el documento SRD pero referidos al sistema tal como se hadiseñado. Siempre que se considere interesante se puede y se debe hacerreferencia a los correspondientes apar tados del documento SRD.

2. PANORÁMICA DEL SISTEMA

Esta sección debe dar una visión general de los requisitos funcionales (y deotro tipo) del sistema que ha de ser diseñado, haciendo referencia al

documento SRD.




1. INTRODUCCIÓN1.1 Objetivo1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias


3. CONTEXTO DEL SISTEMA

3.n Definición de interfaz externa

4. DISEÑO DEL SISTEMA4.1 Metodología de diseño de alto nivel4.2 Descomposición del sistema

5. DISEÑO DE LOS COMPONENTES

5.n Identificador del componente5.n.l Tipo

5.n.2 Objetivo5.n.3 Función5.n.4 Subordinados5.n.5 Dependencias5.n.6 Interfases5.n.7 Recursos5.n.8 Referencias5.n.9 Proceso5.n.l0 Datos

6. VIABILIDAD Y RECURSOS ESTIMADOS

7. MATRIZ REQUISITOS/COMPONENTES

Cuadro 3 .2 . Ind i ce de l documento ADD


En esta sección se indicará si este sistema posee conexiones con otros y sidebe funcionar de una forma integrada con e l los. En cada uno de sus




apar tados se def inirá la correspondiente interfase que se debe uti l izar concada uno de los otros sistemas. Si el sistema no necesita intercambiarinformación con ningún otro, se indicará "No existe interfaz" o "Noaplicable".

4. DISEÑO DEL SISTEMA

Esta sección describe el nivel superior del diseño, en que se considera elsistema en su conjunto y se hace una pr imera estructuración encomponentes .

4.1 Metodología de diseño de alto nivel

Se describe brevemente o se hace referencia a la metodología a seguir en elproceso de diseño de la arquitectura del sistema.

4.2 Descomposición del sistema

Se describe el primer nivel de descomposición del sistema en suscomponentes pr incipales. Se enumeran los componentes y las re lacionesestructurales entre ellos.

5. DISEÑO DE LOS COMPONENTES

Las siguientes subsecciones se repiten para cada uno de los componentesmencionados en e l apar tado 4.2

5.n Identif icador del componente

Nombre de l componente . Dos componentes no podrán tener nunca e l

mismo nombre. Al elegir el nombre se tratará de que refleje su naturaleza.Esto simplifica la búsqueda e identificación de los componentes.

5.n.l Tipo

Se describe la clase de componente. En algunos casos es suficiente conindicar e l t ipo de componente: subprograma, módulo, procedimiento,proceso, datos, etc. También es posible definir aquí nuevos tipos basados enotros más e lementales. En cualquier caso, dentro del mismo documento sedebe establecer una lista coherente de los tipos usados.




5.n.2 Objetivo

Se debe describir la necesidad de que exista el componente. Para ello sepuede hacer referencia a un requisito concreto que se trata de cubrir . Si elrequisi to no form a par te del docum ento SRD se tend rá q ue deta l lar en estem om e nto .

5.n.3 Función

Se describe qué hace el componente. Esto se puede detallar mediante la

transformación entrada/sal ida que real iza o si e l componente es un dato sedescr ibirá qué información guarda.

5.n.4 Subordinados

Se enumeran todos los componentes usados por éste .

5.n.5 Dependencias

Se enumeran los componentes que usan a éste . Junto a cada dependenciase po drá indicar su naturaleza: invocación de operación, datos comp art idos,inicialización, creación, etc.

5.n.6 Interfases

Se describe cómo otros componentes interactúan con éste. Se tienen queestablecer las distintas formas de interacción y las reglas para cada una deellas: paso de parámetros, zona común de memoria, mensajes, etc. También

se indicarán las restricciones tales como rangos, errores, etc.

5.n.7 Recursos

Se descr iben los e lementos usados por este componente que son externosa este diseño: impresoras, particiones de disco, organización de la memoria,librerías matemáticas, servicios del sistema operativo, tamaño de "buffers",posibilidades de interbloqueos, etc.



144 Introducción a la Ingenier ía de Sof tware

5.n.8 Referencias

Se presentan todas las referencias ut i l izadas.

5.n.9 Proceso

Se descr iben los algor i tmos o reglas que ut i liza el com pone nte para real izarsu función como un ref inamiento de la subsección 5.n .3 .

5 .n . l0 Datos

Se descr iben los datos internos del componente incluyendo el método derepresentación, valores iniciales, formato, valores válidos, etc. Estadescr ipción se puede real izar mediante un diccionar io de datos . Además,se indicará el s ignif icado de cada elemento.


Se analiza la viabilidad de la realización del sistema y se concretan losrecursos que se necesitan para llevarlo a cabo.

7. MATRIZ REQUISITOS/COM PONEN TES

Finalmente, en esta sección se muestra una matr iz poniendo en las f i lastodos los requis i tos y en las columnas todos los componentes . Para cadarequis i to se marcará el componente o componentes encargados de que secu mp la .

3.4.2 Docum ento DDD

Este doc um ento i rá creciendo con el desarrol lo del proyecto. En proyectosgrandes puede ser conveniente organizar lo en var ios volúmenes.

Como se puede ver en el cuadro 3.3 , el formato de este documento esbastante similar al ADD. La diferencia entre ambos es el nivel de detalle alque se desciende. En este documento exis ten un mayor número decomponentes y para cada uno de el los se baja incluso hasta al nivel decodificación. Los l is tados fuente se recogen d entro d el docu m ento como unapéndice .




Parte 1. DESCRIPCIÓN GENERAL

1. INTRODUCCIÓN1.1 Objetivo1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias1.5 Panorámica

2. NORMAS, CONVENIOS Y PROCEDIMIENTOS

2.1 Normas de diseño de bajo nivel2.2 Normas y convenios de documentación2.3 Convenios de nombres

(ficheros, programas, módulos, etc.)2.4 Normas de programación2.5 Herramientas de desarrollo de sof tware

Parte 2. ESPECIFICACIONES DE DISEÑO DETALLADO

n. Identif icador del componenten. l Identif icadorn.2 Tipon.3 Objetivon.4 Funciónn.5 Subordinadosn.6 Dependenciasn.7 Interfasesn.8 Recursosn.9 Referenciasn.10 Proceson. l l Da tos

APÉNDICE A. LISTADOS FUENTE

APÉNDICE B. MATRIZ REQUISITOS/COMPONENT ES

Cuadro 3 .3 . Ind i ce de l documento DDD

Dentro de la Parte 1 es interesante destacar la sección 2 dedicada a recogertodas las normas, convenios y procedimientos de trabajo que se deben




aplicar durante el desarrollo del sistema. La importancia de esta sección esmuy grande y de e l la depende que e l t rabajo real izado por un equipoamplio de personas tenga una estructura coherente y homogénea. Larealización de esta sección debe ser la primera actividad del diseñodetal lado antes de inic iar e l diseño propiamente dicho.

Si se utilizan las mismas normas en diversos proyectos, se puede sustituiresta sección por referencias a los documentos que contienen la informacióncorrespondiente .



Tem a 4Técnicas Generales de

Diseno de So f tw are

El diseño d e softw are es un a act ividad que re quiere tener c ier ta experienciaprevia, que es difícil de adquirir sólo a través del estudio de las técnicas dediseño. Sin embargo, un conocimiento detal lado de dichas técnicas esesencial para poder abordar la tarea de diseño con perspect ivas de éxi to.

En es te Tema se hace un repaso a las técnicas más importantes de diseñoque se emplean habi tualmente . Todas e l las t ra tan de faci l i tar la real izacióndel diseño. Basadas en una o varias de es tas técnicas se han desarrol ladometodologías completas de diseño y en a lgunos casos también lascor respond ientes her ramientas CASE para d i seño asi s tido por co mp utado r .El es tudio de cualquiera de es tas metodologías queda fuera del a lcance dees te l ibro. Además, ceñirse a una metodología concreta l imi ta bas tante lacapacidad del diseñador a la hora de intentar enfoques a l ternat ivos dediseño. Por ot ro lado, exis ten l ibros enteros dedicados exclus ivamente a la

presentación y es tudio de cada una de las metodologías y suscor respondientes her ramientas .

Con carácter general , todas las técnicas t ra tan de conseguir como objet ivosinmediatos del diseño los s iguientes :

a .- La descom posición m od ula r del s is tema. Se t ra ta de apl icar e lconcepto de modular idad y obtener una divis ión del s is tema enpar tes o módulos .

b.- La decis ión sobre los aspectos de imp leme ntación o representación

de datos que son importantes a nivel global . Se t ra ta de que eldiseñador decida sobre los a lgori tmos y/o las es t ructuras de datosfundamentales que se deben ut i l izar para la real ización del s is tema.

Este Tema comienza es tableciendo cier tos requis i tos y caracter ís t icas quedebe poseer la descomposición modular de un s is tema. A cont inuación sees tudian las técnicas de diseño propiamente dichas , agrupadas en

• Diseño func iona l descendente• Diseño orientado a objetos



148 In t rodu cc ión a l a Ingen ie r ía de Sof tw are

• Diseño de da tos

Dent ro de l s egundo grupo se ded ica un apa r tado espec í f i co a l d i señobas ado e n abs t racc iones com o paso p rev io a l d i seño o r ien tad o a ob je tos . Losobje tos incorporan re spec to a l a s abs t racc iones e l mecan ismo de he renc ia yla pos ibi l idad de es tablecer re lac iones de especia l ización entre obje tos .

F ina lmente se inc luyen los documentos de d i seño de dos e jemplost o t a l m e n t e d e s a r ro l l a d o s .

4.1 Descomposición Modular

Todas l a s t écn icas de d i seño es tán de acue rdo en l a neces idad de rea l i za ru n a d e s c o m p o s i c i ó n m o d u l a r d e l s i s t e m a c o m o a c t i v i d a d fu n d a m e n t a l d e ld i seño y pa ra logra r lo e s necesa r io concre ta r los s igu ien tes a spec tos :

• Iden t i f i ca r los módulos• Desc r ib i r cada módulo• Desc r ib i r l a s re lac iones en t re módulos

La d i fe renc ia fundamenta l en t re l a s d i s t in ta s t écn icas de d i seño esprec i samente lo qué se en t iende por módulo en cada una de e l l a s y , comoconsecuencia , los cr i ter ios que se deben emplear para su ident i f icación, lamanera en que se desc r iben los módulos y l a s pos ib les re lac iones que sepueden es tab lece r en t re e l los .

Con un ca rác te r lo más genera l pos ib le , s e puede dec i r que un módulo e sun f ragmento de un s i s t ema sof tware que se puede e labora r con re la t ivaindependenc ia de los demás . La idea bás ica e s p rec i samente que l ae laborac ión de los d i fe ren tes módulos se pueda enca rga r a pe rsonasd i s t in ta s y que todas e l l a s t raba jen en pa ra le lo .

Con la de f in ic ión an te r io r son innumerab les los t ipos pos ib les de módulos .Algunos de e l los pueden se r los s igu ien tes :

CÓDIGO FUENTE: Contiene texto fuente escrito en el lenguaje deprogramac ión e leg ido . Es e l t ipo de módulo cons ide rado como ta lcon mayor f recuenc ia y en e l que se hace mayor h incap ié en l a sd i fe ren tes t écn icas de d i seño . Su fo rmato y o rgan izac ión dependenmucho de l a t écn ica y l engua je empleados .



Técnicas Ge nerales de Diseñ o de Sof twa re 149

• T A B L A D E D A T O S : Se util iza para tabular ciertos datos de inicialización,

exper im entales o s implem ente de dif íci l obtención. Por ejemplo, unaapl icación de control de procesos en que haya un depósi to de formair regular puede tener tabulados los volúmenes de l íquido en eldepósi to en función del n ivel . Esta tabla puede ser un móduloespecíf ico para cada forma de depósi to y cuando se cambia eldepósi to sólo es necesar io cambiar es te módulo.

• C O N F I G U R A C I Ó N : Un sis tema se puede concebir para t rabajar en entornosdiversos según las necesidades de cada cliente. En estos casos,in teresa agru par en un m ismo mó dulo toda aquel la in fo rmación quepermite conf igurar el entorno concreto de t rabajo . Esto es lo quesucede con los s is temas operat ivos que conf iguran el número y t ipode per ifér icos que el cliente adquiere . O tro ejemplo son los m ódu losencargados de guardar todos los mensajes de una apl icación en losdis t in tos id iomas. Un cambio de idioma sólo requiere el cambio dees te módulo .

B D T R O S : En general , un módulo puede servir para agrupar cier tos elementosdel s is tema relacionados entre s í y que se puedan t ratar de formaseparada del resto. Por ejemplo, para util izar el "make" de UNIX esnecesar io indicar en un módulo o f ichero el número y orden en que

se deben combinar los otros módulos para generar el programa dels is tema. También se elaboran por separado los f icheros de ayuda enlínea, los manuales de usuario, etc.

Hü formato concreto de cada t ipo de módulo depende de la técnica,metodología o herramienta ut i l izados. Por ejemplo, dependiendo dellenguaje de programación, un módu lo de CÓDIGO FUENTE puede ser una

única subrut ina en un f ichero fuente FORTRAN o un t ipo abstracto dedatos den t ro de un MODULE de Modula-2 .

Un mismo s i s tema se puede descomponer en módulos de muchas fo rmasd i feren tes y p robab lemente cada d i señador a rg um entará r azones ev iden tespara considerar que su propuesta es la mejor . Casi s iempre el objet ivofundamental de cualquier diseño es conseguir un s is tema mantenible y sóloen casos excepcionales se sacrif icará este objetivo para lograr una mayorvelocidad de proceso o un m eno r tama ño de código. Evidentem ente, resul tamuy dif íci l es tablecer un patrón de medida capaz de indicar de una maneraprecisa y cuant i tat iva lo buena o mala que es una determinadadescom posición pa ra faci l i tar su m antenim iento. Sin emb argo, la exper ienciaacumulada permi te es tab lecer que una descompos ic ión modular debeposeer cier tas cual idades mínimas para que se pueda considerar



150 Introd ucc ión a la Ingen iería de So ftwa re

suf icientemente vál ida. Estas cual idades se pueden concretar en las que se

estudian en los s iguientes apar tados.

4.1.1 Independencia funcional

En la matr iz REQUISITOS/COMPONENTES del f inal de los documentosADD y DDD es necesar io indicar qué componente (módulo) se encargaráde real izar cada un o de los requis i tos ( funciones) indicados en el doc um entoSRD. Com o pr im er paso de la descom posición se pu ede establecer que cadafun ción se po drá real izar en un m ódu lo dis t in to . Desde luego, s i el anális ises tá bien hecho y las funciones son independientes , es tos módulos tendrán

indep ende ncia funcion al entre ellos. Poster iorm ente y en sucesivos pasos deref inamien to de l d iseño se agru pará n funciones a f ines en un m ismo mó duloo se subdiv idirán cier tos mó dulo s en otros var ios má s senci llos . Para l levara cabo esta tarea es necesar io tener muy en cuenta los conceptos deabstracción, ocultación, genericidad, etc. explicados en el Tema anterior .

Para que un módulo posea independencia funcional debe r ea l izar unafunción concreta o un conjunto de funciones af ines , s in apenas ningunarelación con el res to de los módulos del s is tema. Aunque resul ta absurdo,el mayor grado de independencia se consigue cuando no exis te ninguna

relación entre los dis t in tos módulos . Evidentemente al descomponer unsis tema en sus par tes o módulos es necesar io que exis tan cier tas relacionesentre ellos. En todo caso se trata de reducir las relaciones entre módulos almín imo. Una mayor independencia r edunda en una mayor f ac i l idad demantenimiento o sust i tución de un módulo por otro y aumenta laposibi l idad de reut i l ización del módulo.

Para medir de una forma relat iva la independencia funcional que hay entrevar ios módulos se ut i l izan fundamentalmente dos cr i ter ios: acoplamientoy cohesión. Estos cr i ter ios fueron suger idos por Stevens, Constant ine yMyers [Stevens74] dentro de la metodología de diseño estructurado, pero

son igualmente val idos para real izar la descomposición funcional de unsis tema ut i l izando cualquier otro t ipo de técnica o metodología.

4.1.1.1 Acoplamiento

El grado de acoplamiento entre módulos es una medida de la in ter relaciónque existe entre ellos: t ipo de conexión y complejidad de la interfase. Comoescala para medir de una forma cual i tat iva el grado de acoplamiento entremódulos se util iza la siguiente escala:



Técnicas Generales de Diseño de Sof tw are 151

F U E R T E :

M O D E R A D O :

D É B I L :

Acoplamien to por Conten ido

Aco p lamien to Co mú nAcoplamien to ExternoAcoplamien to de Cont ro lAcoplamiento por Et iquetaAcoplamien to de DatosSin Acoplamiento Directo

Para manejar es ta escala hay que saber el s ignif icado de cada t ipo deacoplamiento y cuándo se produce. Con el la se t rata de conocer lo que sedebe hacer para conseguir un acoplamiento débi l y lo que se debe evi tarpara que no exis ta un acoplamiento fuer te entre módulos . No se t rata de

si tuar con precis ión el resul tado de la descomposición f inal de un s is temaden tro de es ta escala, dad o que es to no resul ta de especial in terés y ade má sresulta dif ícil delimitar las fronteras entre los tipos consecutivos. Por elcontrario, el objetivo es que durante el diseño se tenga en cuenta la escalapara buscar descomposiciones con acoplamiento débi l o , a lo sumo,mo d er ad o .

En la f igura 4.1 se muestran gráficamente situaciones que dan lugar a laexis tencia de un acoplamiento fuer te entre módulos .

Figura 4.1 Acoplam iento fu er te : (a) por contenido ; (b) común o exte rn o

El acop lamien to por Contenido se p roduce cuando desde un módulo sepu ede n cam biar los datos locales e incluso el código de otro mód ulo. Com ose muestra en la f igura 4.1 (a) , en realidad no existe una separación real



152 Introducción a la Ingenier ía de Sof tw are

entre módulos y hay solapes entre el los . Este t ipo de acoplamiento sólo se

puede lograr ut i l izando un lenguaje emsamblador o de muy bajo nivel ypuede y debe ser evi tado s iempre. Resul ta práct icamente imposible no sólomantener s ino también entender y depurar un s is tema con acoplamientopor contenido.

Para el acoplamiento Común se emplea una zona común de datos a la quetienen acceso varios o todos los mó du los del sistem a (Ver f igu ra 4.1 (b)). Enla práct ica, es to s ignif ica que cada módulo puede estructurar y manejar lazona común con total l iber tad s in tener en cuenta para nada al res to demó dulo s . El em pleo de es te acoplam iento exige que todo s los m ódu los es ténde acuerdo en la es tructura de la zona común y cualquier cambio adoptado

por uno de el los afecta al res to que deber ían ser modif icados según lanueva estructura. Este t ipo de acoplamiento se produce cuando se ut i l izae l COMMON de FORTRAN y r esponde a una fo rma de t r aba jo en la quela memoria disponible era escasa. La depuración y el mantenimiento de unsis tema con esta descomp osición resul ta m uy dif íci l y s iemp re que se p ued ase debe evitar .

\\

A

7/

/

Figura 4.2 Acoplamiento moderado

En el acoplamiento Externo la zona común de la f igura 4.1 (b) estáconstituida por algún dispositivo externo (disco, sensor, canal decomunicaciones, etc.) al que están ligados todos los módulos. En este casola es tructura de la zona común la impone el formato de los datos quemaneja el dispositivo y cualquier modificación exige el cambio de todos losmódulos . Aunque el acoplamiento externo es inevi table, s iempre se deben



Técnicas Generales de Diseño de Sof tware 153

buscar descom posiciones en qu e los disposi t ivos externos afecten al mínim o

número pos ib le de módulos .La f igura 4 .2 muestra la s i tuación t íp ica de un acoplamiento moderado oacop lamien to de Control.

En este caso, una señal (s) o dato de control que se pasa desde un módulo(A) a otro (B) es lo que determina la l ínea de ejecución que se debe seguirdentro de es te úl t imo (B) . Con este t ipo de acoplamiento dentro de unmismo módulo se pueden t ratar d is t in tos casos o s i tuaciones. Por ejemplo,es razonable que un módulo pueda generar o no una señal acúst ica alalcanzar un nivel de alarma y en general que el acoplamiento s i rva para

sol ici tar o anular servicios adicionales a un determinado módulo. Sinembargo, cuando se t rata de ut i l izar es te t ipo de acoplamiento paraaprovechar cier tas par tes del módulo con f ines completamente dispares sesuelen crear módulos dif íci les de entender , depurar , modif icar y mantener .Como veremos en el próximo apar tado, es to da lugar a un módulo con muypoca cohesión en que sus elementos tienen muy poca relación entre ellos.

En la f igura 4 .3 tenemos una descomposición modular con acoplamientodébil.




Aquí , el acoplamiento se produce sólo a t ravés del in tercambio de aquel los

datos que un módulo necesita de otro. Si el intercambio se realizaestr ictamente con los únicos datos que se necesi tan tenemos unacop lamien to de Datos. Este es el mejor t ipo posible de acoplamiento.

Cu an do en el in tercambio se sum inis tra u na referencia que faci li ta el accesono sólo a los datos es tr ictamente necesar ios s ino también a la es tructuracompleta de la que forman parte (p.ej. , vector, pila, árbol, grafo, etc.) :t enemos un acop lamien to por Etiqueta.

Ambos t ipos de acoplamiento débi l son los más deseables en unadescomposición modular . Con el los , cualquier modif icación en un móduloafecta muy poco o nada al res to . Sin embargo, cuando se ut i l iza unacoplamiento fuer te es necesar io ser muy meticuloso y consul tar s iempre atodo el equipo de diseño e implementación antes de in troducir n ingúncambio en las zona s comune s. El equip o en su conjunto debe anal izar todaslas consecuencias del cambio propuesto . Además, cada cambio deberáquedar regis t rado junto con las razones que lo hacían necesar io .

Evidentemente el acoplamiento más débil es el que no existe. Este caso esel que se produce entre los módulos E y B de la f igura 4.3 entre los que noexis te ningún t ipo de acoplamiento directo .

4.1.12 Cohesión

El cr i ter io de cohesión es complementar io al de acoplamiento. Además debuscar un acoplamiento débi l entre módulos es necesar io lograr que elcon ten ido de cada módulo tenga coherencia . Cuando se descompone unsis tema se debe buscar un objet ivo específ ico para cada módulo. Acont inuación, se t ratará de agrupar en el mismo módulo todos aquel loselementos afines o que estén relacionados con el objetivo f ijado para dichomódulo. Por otro lado, se debe tener en cuenta que el número de módulos

no debe crecer desmesuradamente para no aumentar l a comple j idad de lsistema. Esto último hace que ciertos elementos "sueltos" se incorporen a undeterminado modulo aunque no tengan mucha af in idad con é l y que comoresul tado se disminuya la cohesión del módulo.

Como escala para medir de forma cual i tat iva la cohesión de un módulo seutiliza la siguiente:




T Cohesión abstraccional

B A J A :

A L T A :

M E D I A :

Cohes ión funcionalCohesión secuencialCohesión de comunicaciónCohes ión tempora lCohesión lógicaCohesión coincidental

La cohesión coincidental es la peor posible y se produce cuando cualquierrelación entre los elementos del módulo es una "pura coincidencia", esto es,no guardan absolutamente ninguna relación entre el los . El módulo se

convierte en un "cajón de sastre" del que es muy dif ícil establecer cual es suobjetivo concreto. La existencia de este t ipo de módulos indica que no hasido real izada ninguna labor de diseño y que s implemente se ha efectuadoun t roceado del s is tema agrupando l íneas de código de cien en cien.

La cohesión lógica se p roduce cuando se agrupan en un mismo móduloelementos que real izan funciones s imilares desde un punto de vis ta deusuar io . Este es el caso de un m ód ulo o bibl ioteca de funcio nes m atemá ticasen el que coseno, raíz cuadrada, logar i tmo, etc . se agrupan debido a sucarácter de herramientas matemáticas que el usuar io pref iere mantenerunidas . Esta misma cohesión es la que exis te en los módulos de

en t rada/sa l ida o cuando se d i seña un módulo para e l manejo de todos losmensajes de er ror que se producen en el s is tema.

Una cohesión temporal es e l r esu l tado de agrupar en un mismo móduloaquel los elementos que se ejecutarán en un mismo momento. Esta es lasituación que se produce en la fase de inicialización o f inalización dels is tema en que necesar iamente se deben "ar rancar" o "parar" disposi t ivoscompletamente heterogéneos: teclado, pantal la , ratón, impresora, etc .

La cohesión BAJA debe evi tarse práct icamente s iempre. De hecho, tan sólo

se podr ía just if icar una cohesión lógica o tempo ral y solam ente en los casosdados como ejemplo u otros semejantes .

Por cohesión de comunicación se ent iende aquel la que se produce cuandotodos los elementos del módulo operan con el mismo conjunto de datos deentrada o producen el mismo conjunto de datos de sal ida. Esto se da, porejemplo cuando un módulo real iza operaciones diversas , pero s iempre conla misma tabla de datos , y también cuando un módulo de expor tación dein formación empaqueta d i s t in tas c lases de da tos pero generando s iempreel mismo f ichero de sal ida.



156 Introd ucció n a la Ingen iería de Sof tw are

La cohesión secuencial es la que se pro duc e cua ndo todo s los eleme ntos del

módulo t rabajan de forma secuencial . Esto es , la sal ida de un elemento delmódulo es la entrada del s iguiente de una manera sucesiva. Por ejemplo,un módulo para calcular el valor medio y también a cont inuación ladesviación típica de un conjunto de valores tiene una cohesión secuencial.

Co n un a cohesión MEDIA se pu ed e red ucir el nú m er o d e mó dul os. Sinembargo, es to no se debe real izar a costa de aumentar el grado deacoplamiento entre módulos . Por ejemplo, no se deben unir dos móduloscon aco plam iento DÉBIL pa ra ob tener u no ún ico con a copla mie ntoMODERADO, en el que se requiere pasar una señal para indicar con cual delos dos ant iguos submódulos se quiere t rabajar .

En un módulo con cohesión funcional cada elemento es tá encargado de larealización de una función concreta y específ ica. Con las técnicas de diseñofuncional descendente es te nivel de cohesión es el máximo que se puedelograr dentro de un módulo. Por tanto, con estas técnicas el objetivo seráque todos los módulos tengan una cohesión funcional .

Con la técnica de diseño basado en abstracciones, un módulo con cohesiónfuncion al ser ía una abstracción funcional . La cohesión abstraccional se logracuando se diseña un módulo como t ipo abstracto de datos con la técnica!

basada en abstracciones o como una clase de objetos con la técnicaorientada a objetos. En ambos casos, se asocian un cierto contenido(atributos) u organización de datos con las correspondientes operaciones(métodos) encargados de su manejo.

Independientemente de la técnica empleada, una cohesión ALTA debe ser elobjet ivo que se debe perseguir en cualquier descomposición modular . Conello, se facili tará en gran medida el mantenimiento y la posible reutil izaciónde los módulos as í d iseñados.

Para conocer, y si es necesario, mejorar la cohesión de un módulo se sugiere

realizar una descripción de su comportamiento [Stevens74], A partir de ladescr ipción, se puede establecer el grado de cohesión de acuerdo con lossiguientes criterios:

A.- Si la descr ipción es un a f rase com puesta q ue cont iene comas o m ásjde un verbo es muy probable que se es té incluyendo más de una ifunción y la cohesión será MEDIA de tipo secuencial o decomunicación




B.- Si la descripc ión contiene palabr as relaciona das con el t iem po, tales

como: "primero", "después", "entonces", "cuando", "a continuación","al comenzar", etc. la cohesión será de tipo temporal o secuencial.

C.- Si la fra se de la descrip ción no se refiere a algo específ ico acont inuación del verbo, es m uy prob able que tengam os una cohesiónlógica. Por ejemplo, "escribir todos los mensajes de error" o "calculartodas las funciones t r igonométr icas".

D.- C ua nd o se util izan pala bra s tales com o: "inicializar", "preparar","configurar", etc. , la cohesión será probablemente de tipo temporal.

Estos criterios serán siempre orientativos debido tanto a las deficienciasintr ínsecas propias de cualquier descr ipción que se real iza en lenguajenatural como también a la dif icul tad de del imitar las f ronteras entre losdistintos niveles de cohesión. Así, con una descripción detallada: "medirtempera tu ra , humedad y p res ión" se puede pensar en una cohes iónsecuencial y con una más concisa: "medir sensores" en una cohesiónfuncional. Está claro que la palabra "sensores" resulta más imprecisa que lastres a las que sust i tuye. Por otro lado, el d iseñador es el encargado dematizar la necesidad de un t ratamiento específ ico para cada t ipo de sensoro s i todos los sensores se deben t ratar como un único t ipo abstracto de

datos . Esto úl t imo dar ía lugar a una cohesión abstraccional .

En r esumen , l a descompos ic ión modular con una mayor independenciafunc iona l se logra con u n aco plam iento DÉBIL entr e sus m ód ulo s y u nacohes ión ALTA de ntr o d e cad a un o d e ellos.

4.1.2 Comprensibilidad

La dinámica del proceso de diseño e implementación de un s is tema haceque los cambios sean más f recuentes de lo que ser ía deseable.

Poster iormente, los cambios cont inúan durante la fase de mantenimientohasta que se sust i tuye el s is tema por otro nuevo. A menudo los cambiosdeben ser real izados por personas que no par t iciparon ni en el d iseño ni enla implementación. Para facili tar e incluso posibili tar estos cambios esnecesar io que cada módulo sea comprensible de forma ais lada. No t ienesen t ido que a veces e l es fuerzo de comprens ión de un módulo sea mayorque el necesario para su realización.

El pr imer factor que faci l i ta la comprensión de un módulo es suindep ende ncia funcional . Ya hemo s vis to que con u na cohesión ALTA y un



158 In t rodu cc ión a l a Ingen ie r ía de Sof tw are

a c o p l a m i e n t o DÉBIL e l módulo t i ene menor dependenc ia de l re s to de l

s i s t ema y por t an to se rá más fác i l en te nde r su func ion am ien to de m aneraa i s lada . S in embargo , e s to no es suf ic ien te y e s necesa r io además cu ida respec ia lmente los s igu ien tes fac to res :

1 . - I D E N T I F I C A C I Ó N : Una e lecc ión adecuada de l nombre de l módulo y de losnombres de cada uno de sus e lementos fac i l i t a mucho sucomprens ión . Los nombres deben re f le ja r de manera senc i l l a e lob je t ivo de l a en t idad que represen tan . Un buen e jemplo de l ad i f i cu l t ad de compres ión que represen ta l a u t i l i zac ión de unaiden t i f i cac ión inadecuada son los l ib ros o manua les t écn icos" t raduz tados" con un to ta l desconoc imien to de l l éx ico u t i l i zadoh a b i t u a l m e n t e .

2.- DOCUMENTACIÓN: La labor de documentación de cada módulo y dels i s t ema en genera l deb e se rv i r pa r a fac i li t a r l a com pres ión , ac la rand otodos aque l los a spec tos de d i seño o implementac ión que por sun a t u r a l e z a n o p u e d a n q u e d a r r e f le j a d o s d e o t ra m a n e ra . H a y q u etene r en cuen ta que s i l a documentac ión es muy pro l i j a y re i t e ra t ivase corre e l r iesgo de que no se lea . En cada diseño se debenes tab lece r normas y convenios de documentac ión que ev i ten e s tosp ro b l e m a s . E s t a s n o rm a s fo rm a rá n p a r t e d e l D o c u m e n t o d e D i s e ñ o

Deta l l ado (DDD)

3 . - S I M P L I C I D A D : Las soluciones senci l las son s iempre las mejores . Una lgor i tmo compl icado es muy d i f í c i l de en tender , depura r ymodi f ica r en e l caso de que sea necesa r io . Un es fue rzo fundamenta lde l d i señador debe es ta r ded icado a s impl i f i ca r a l máximo la sso luc iones p ropues tas . Só lo en casos muy excepc iona les ( t i empo ome mo r ia e scasos ) , s e pu ed e sac r if i ca r l a s impl ic ida d d e un a lgor i tmopor o t ro más sof i s t i cado y d i f í c i l de comprender .

4.1.3 Adaptabil idad

Al d i seña r un s i s t ema se p re tende re so lve r un p rob lema concre to y se t ra tade obtener práct icamente un " t ra je a la medida" . Por tanto, ladescompos ic ión modula r e s ta rá muy media t i zada por e l ob je t ivo concre tode l d i seño . Es to d i f i cu l t a bas tan te l a adap tab i l idad de l d i seño a o t ra sneces idades y l a pos ib le reu t i l i zac ión de a lgunos de sus módulos . S inembargo , e s inev i tab le que un s i s t ema en mayor o menor medida se adap tea los nuevos requis i tos que va imponiendo e l "c l iente" .



Técnicas Gene ra le s de Diseño de Sof tw are 159

Inde pen den c ia func io na l y com prens ib i l idad son dos cua l id ades e senc ia le s

que debe t ene r cua lqu ie r d i seño pa ra pos ib i l i t a r su adap tab i l idad . No sepuede aborda r l a t a rea de adap tac ión de un d i seño con un acop lamien toFUERTE e n t r e s u s m ó d u l o s , c o n m ó d u l o s d e BAJA cohes ión , ma ldocumentados y d i f í c i l e s de comprender . Con es ta s p remisas , re su l ta másaconse jab le y ven ta joso rea l i za r un d i seño comple tamente nuevo quee l imine todas l a s de f ic ienc ias de l que se p re tende adap ta r .

Desgrac iadamente l a s adap tac iones sue len se r múl t ip le s y va r iadas a lolargo de la vida del s is tema. Así , es necesario cuidar otros fac toresad ic iona les pa ra fac i l i t a r l a adap tab i l idad y de e l los des taca remos loss igu ien tes :

1 . - P REVI SI ÓN : R e s u l t a m u y c o m p l i c a d o p r e v e r q u e e v o l u c i ó n fu t u r a t e n d ráun d e te r mi nad o s i s t ema . Só lo l a exper ienc ia p rev ia nos pue de ind ica rque pa r te s de s i s t emas semejan tes han s ido más suscep t ib le s acambios o adap tac iones . Por e jemplo : l i s t ados , p resen tac iones enpanta l la , e tc . En e l diseño, es tas partes se deberán agrupar enmódulos con un acop lamien to lo más déb i l pos ib le con e l re s to delos m ód ulo s de l s is t ema . Así , l a s adap tac ion es se po dr án rea l i za r concorrecciones que sólo afectarán a los módulos previs tos . S i laadap tac ión ex ige una modi f icac ión de l a descompos ic ión modula r

resu l ta rá t remendamente más compl icada y cos tosa de rea l i za r .

2 . - A C C E S I B I L I D A D : Antes de aborda r l a nueva adap tac ión de un s i s t ema esnecesa r io conocer lo con la su f ic ien te p rofundidad . P rev iamente acua lqu ie r adap tac ión es impresc ind ib le e s tud ia r l a e s t ruc tura g loba lde l s i s t ema y todos aque l los de ta l l e s a los que a fec te de manerafundamenta l l a adap tac ión . Es te t raba jo só lo e s pos ib le s i re su l t asenci l la la acces ibi l idad a todos los documentos de especif icación,d i seño e implementac ión . Es to requ ie re una o rgan izac ión minuc iosaque en la mayoría de los casos sólo es pos ible s i se emplea unaher ramien ta CASE. En es te s en t ido hay que seña la r l a s pos ib i l idades

que of recen los en tornos de d i seño y l engua jes de p rogramac iónbasados en e l empleo de ob je tos . Todos e s tos en tornos mant ienenuna bibl ioteca de obje tos de fác i l acces ibi l idad y gracias a lmecan ismo de he renc ia re su l ta re la t ivamente senc i l l a suadap tab i l idad . Es ta d i sponib i l idad pe rmi te rea l i za r p ro to t ipos denuevos s i s t emas como adap tac ión de o t ros ya ex i s ten tes en un p lazom u y b re v e d e t i e m p o .

3.- CONSISTENCIA: Cuando se realizan adaptaciones sucesivas es vitalmantene r l a cons i s tenc ia en t re todos los documentos de



160 Introd ucció n a la Ingen iería de Sof tw are

especif icación, d iseño e implem entación p ara cada nue va adaptac ión.

La tentación de modif icar exclusivamente los programas fuentes s inactual izar ningún otro documento da lugar a un caos en el que esimposible saber a que adaptación per tenece cada nueva vers ión demódulo y en consecuencia nunca se podrán abordar poster ioresadaptaciones. Exis ten herramientas para el "control de vers iones yconf igurac ión" que permi ten mantener au tomát icamente laconsis tencia de cada adaptación. En los entornos o lenguajesor ientados a objetos no exis ten es te t ipo de herramientas y esobl igator io imponer una discipl ina fér rea dentro de la bibl ioteca deobjetos para mantener la consis tencia de las dis t in tas adaptaciones .Periódicamente se debe revisar la biblioteca, eliminar objetosduplicados, reestructurar la organización de objetos , etc .

4. 2 Técnicas de diseño funcional descendente

En este grupo de técnicas se incluyen todas aquel las en que ladescomposición del s is tema se hace desde un punto de vis ta funcional , esdecir , se at iende fundamentalmente a la función o funciones que ha dereal izar el s is tema, que se van expresando poco a poco mediante funcionesmás senci l las , las cuales se encomiendan a módulos separados.

De es ta manera los módulos cor responden prec i samente a funcionesconcretas que se han de realizar en el sistema. Desde el punto de vista dela codif icación, cada módulo corresponde esencialmente a un subprograma.Por es ta razón estas técnicas de diseño conducen a es tructuras modularesque pueden implementarse bien casi con cualquier lenguaje deprogramación, incluso aquel los como FORTRAN o COBOL que carecen defaci l idades para la implementación de t ipos abstractos de datos .

4.2.1 Desarrollo por refinamiento progresivo

Esta técnica corresponde a la aplicación en la fase de diseño de lametodo log ía de p rogramación conocida como programación estructurada[Dijkstra68], [Dahl72], y que condujo a la construcción de programasmed ian t e refinamientos sucesivos [Wirth71J.

La programación estructurada recomienda emplear en la construcción depro gra m as sólo es tructuras d e control claras y senci llas, con un único pun toinicial y un único punto f inal de ejecución. En particular son la secuencia,la selección entre alternativas, y la iteración.



Técnicas Ge nerales de Diseño de So ftwa re 161

La construcción de programas basada en el concepto de ref inamiento, ya

expue sto en el Tem a anter ior , consis te en plantea r in icialmente el pro gram acomo una operación global , única, e i r la descomponiendo poco a poco enfunción de otras operaciones más senci l las . Cada paso de descomposiciónconsis t i rá en ref inar o detal lar la operación considerada en ese momentosegún una es tructura de las mencionadas anter iormente, cuyos elementosserán a su vez operaciones. Por ejemplo, consideremos un programa paraobtener las raíces de una ecuación de segundo grado. Los pr imerosref inamien tos podr ían ser :

Obtener raíces -->

Leer coeficientesResolver ecuación -->

Calcular discriminante

Calcular raíces -->

SI el discriminante es negativo E N T O N C E SCalcular raíces complejas

SI-NOCalcular raíces reales

FIN-SIImprimir raíces

Figura 4 .4 Diseño por refin am iento

La aplicación de esta técnica a la fase de diseño consiste en realizarsólo los pr imeros niveles de ref inamiento, as ignando a módulosseparados las operaciones parciales que se van ident i f icando. En ele jemplo an ter io r , l a descompos ic ión modular de l p rogramaresul tante del pr imer ref inamiento podr ía ser la que se indica en la




figura 4.4. A nivel de codificación, estos módulos separados se

invocar ían, tal como se ha dicho, como subprogramas. El paso de laestructura de ref inamientos a es tructura modular es inmediata, yaque los ref inamientos se basan precisamente en la apl icación deestructuras de control en el programa.

4.2 .2 Programación estruc turad a de Jackson

La técnica de Progra ma ción Estruc turada de Jackson (en inglés JSP: JacksonStructured Programming) apar ece d escrita e n [Jackson75]. Esta técnica sigueestr ictamente las ideas de la programación estructurada en cuanto a lasestructuras recomendadas (secuencia, selección, i teración) y el método deref inamientos sucesivos para construir la es tructura del programa en formadescendente. Se ut i l izan los diagramas específ icos descr i tos en el Temaanter ior para representar tanto la es tructura del programa como la de losdatos con los que opera.

No hay que confundir es ta metodología de diseño de programas con ladenominada JSD: Jackson System Development, del mismo autor , descr i taen [Jackson83], y que presenta algunas analogías con las técnicas dedesarrol lo or ientadas a objetos .

La apor tación pr incipal de la programación estructurada de Jackson f rentea la metodología general de programación estructurada es tá en lasrecomendaciones para i r construyendo la es tructura del programa, que debehacerse similar , en lo posible, a las estructuras de los datos de entrada ysal ida. Esta idea es muy apropiada para las apl icaciones denominadasant iguamente de "proceso de datos", que sol ían real izarse en modo "batch"y que en la actual idad han s ido englobadas dentro de los denominados"sis temas de información", que operan con f recuencia en forma interact iva.

La técnica original de JSP se basa en los siguientes pasos:

1) An al izar el entorn o del proble ma y descr ibir las es tructu ras de datosa procesar .

2) Con struir la es tructura del pro gra m a basad a en las es tructu ras dedatos .

3) De finir las tarea s a realizar en térm inos de las opera cioneselementales disponibles , y s i tuar las en los módulos apropiados de laes t ruc tu ra de l p rograma.



Técnicas Gene rales de Diseño de Sof tw are 163

Como técnica de diseño los pasos s ignif icat ivos son los dos pr imeros,mientras que el tercero corresponde más bien a la fase de codif icación.

I lustraremos esta técnica mediante un ejemplo, consis tente en un programapara "justif icar" un texto, es decir , reagrupar las palabras en líneas eintercalar los espacios apro piad os p ara que las l íneas del texto se ajusten alos márge nes es tablecidos. En este ejemplo se prete nde, a dem ás, respe tar laforma de separar los párrafos en el texto or iginal . Si consideramos el textoinicial:

T e x t o d e e n t r a d aE s t e p á r r a f o y l o s d o s s i g u i e n t e s s o n u n

e j e m p l o d e l t e x t o q u e s ep r e t e n d e a j u s t a r . E s t e e s e l p r i m e rp á r r a f o .

Y e s t e e s e l s e g u n d o p á r r a f o , q u e e s t ás e p a r a d o d e l a n t e r i o rs ó l o p o r e l s a n g r a d o .

E s t e t e r c e r p á r r a f o n o t i e n e s a n g r a d o , y l as e p a r a c i ó n v i e n e d a d ap o r u n a l í n e a e n b l a n c o .

se t ratar ía de obtener como resul tado algo s imilar a:

T e x t o d e s a l i d a

E s t e p á r r a f o y l o s d o s s i g u i e n t e s s o n u n e j e m p l od e l t e x t o q u e s e p r e t e n d e a j u s t a r . E s t e e s e lp r i m e r p á r r a f o .

Y e s t e e s e l s e g u n d o p á r r a f o , q u e e s t ás e p a r a d o d e l a n t e r i o r s ó l o p o r e l s a n g r a d o .

E s t e t e r c e r p á r r a f o n o t i e n e s a n g r a d o , y l as e p a r a c i ó n v i e n e d a d a p o r u n a l í n e a e n b l a n c o .

En el P A S O 1 del diseño ident i f icamos las es tructuras de los datos deentrada y salida. En el texto de entrada los espacios en blanco y lossaltos de línea sólo son signif icativos en la separación entrepárrafos . Podr íamos descr ibir la es tructura como una i teración de

elementos , b ien palabras o separadores .

texto de entrad a = { [ sep arad or de párrafo | palabra ] }

El diagrama equivalente aparece a la izquierda de la f igura 4.5.

En el caso del texto de salida, la escritura ha de hacerse alcompletar las l íneas y justif icarlas, en caso de que no sean la últimadel pár rafo. Además se usan l íneas en blanco como separación. Laestructura de sal ida podr ía ser una i teración de l íneas , cada una delt ipo aprop iado .



164 Introd ucció n a la Ingen iería de Sof twa re

EN TRA D A SALIDA

Figura 4.5 Ejemplo de estr uc tur as de entrad a y salida

texto de sal ida = { [ l ínea ajustada | l ínea f inal | l ínea en blanco ] }

El diagrama de estructura aparece a la derecha de la f igura 4.5.

E N T R A D A P R O C E S O S A L I D A

Figura 4.6 Ejemplo de diseño usando JSP

El problema ahora es encontrar , en el PASO 2, una estructura delprograma que se ajuste al mismo t iempo a las dos es tructuras dedatos: la de entrada y la de salida.

En este caso lo que se puede hacer es buscar una unidad super ior deinformación que englobe a las unidades de datos de la entrada y de



Técnicas Ge nerales de Diseño de So ftw are 165

la sal ida, y usar la como unidad de t ratamiento en el programa. Estaunidad super ior ser ía el pár rafo, que podr ía adaptarse a ambas en lafo rma:

texto = { párrafo }párrafo de entrad a = sep arad or de párrafo + { palabra }párra fo de sa l ida = { l í ne a en b lanco }

+ { l ínea ajustada } + l ínea f inal

Con esta perspect iva podemos redef inir las es tructuras de los datosde entrada y de salida, tal como se indica en la f igura 4.6. Ahora ya

se puede der ivar con relat iva faci l idad la es tructura del programa,mediante un sencillo análisis de las operaciones a realizar con cadaelemento de datos . La es tructura resul tante podr ía ser larepresentada en el centro de la f igura 4 .6 , donde se han señaladocon las letras (A), (B), (C), (D) y (E) los elementos correspondientes delas dis t in tas es tructuras . La operación de inicio de párrafo procesael separador de párrafo en la entrada y genera las l íneas en blancoa la salida. La operación de formar líneas lee las palabras del textode entrada y las agrupa en l íneas , jus t i f icando e impr imiendo lasl íneas que se l lenen. La operación de terminar párrafo impr ime lalínea f inal, sin ajustar .

4.2.3 Diseño estructur ado

Esta técnica de diseño [Yourdon79] [Page-Jones80] es el complemento dell lama do anál is is es tructu rado . A mb as técnicas coinciden en el em pleo de losdiagramas de f lujo de datos (DFD), descrita en el Tema anterior , comomedio fundamenta l de r epresen tac ión de l modelo funcional de l s i s tema.Para el d iseño se emplea la notación de diagramas de es tructura, tambiéndescrita en el Tema anterior . La tarea de diseño consiste en pasar de losDFD a los diagramas de es tructura.

La dif icul tad a super ar al hacer el d iseño res ide en que no basta con asignarmódulos a procesos o grupos de procesos relacionados entre s í , s ino quehay que es tablecer una jerarq uía o es tructura de control entre los diferentesmó dulos , qu e no está implíci ta en el mo delo func ional descr i to m edian te losdiagramas de f lu jo de datos .

Por ejemplo, considerando un caso muy senci l lo con sólo dos operacioneso procesos (Figura 4.7-A), cada uno de los cuales materializamos como unmódulo separado , t enemos t r es pos ib i l idades de o rgan izac ión modularsegún cómo establezcam os la jerarqu ía d e control entre el los .




X / \ V \ z

Y UNO Y DOS ; Y

(A)

UNO. leer x...

DOS. escribir z.

(B) (C) (D)

Figura 4.7 Ejemplo de estru ctu ras a lternativas

• AA

V y "

>! BB

cc V

pp

> > RR

V• aa

YY

* \XX • =

Flujo de entrada Flujo de transformación Flujo de salida

Control deentrada

AA BB CC

Controlprincipal

Control detransformación

PP CX3 RR

Control desalida

/

XX YY ZZ

Figura 4.8 Diseño basado en el f lujo de transform ación




En la f igura 4.7-B el módulo de la primera operación lee los datos e invocaa la segunda con los valores intermedios. En el caso de la f igura 4.7-C es elm ódu lo de la seg und a ope ración quie n t iene el control sobre la pr imera. Enel último caso, de la f igura 4.7-D, se ha introducido un módulo adicional,l l amado módulo de coordinación, para llevar el control de los otros dos.Para es tablecer una jerarquía de control razonable entre las diferentesoperaciones descr i tas en los diagramas de f lu jo de datos , la técnica dediseño estructurado recomienda hacer cier tos anál is is del f lu jo de datosglobal. En concreto se recom ienda real izar los anál is is den om inad os d e flujode transformación y de flujo de transacción. Estos anál isis pued en real izarsecon mayor faci l idad s i se modif ica parcialmente la es tructura jerárquica de

los diagramas de f lu jo de datos , construyendo un único diagrama con todoslos procesos contenidos en los pr imeros niveles de descomposición, yprescindiendo de los almacenes de información.

r x

K A1 • A2 >J/ <

—. / " Transaccionesf .

• P1 • P2 / • CT • B1 í >

W K 0 3 >transacción

Controlprincipal

Control depreparación

Control detransacción

P1 P2 Transacción A... A1 A2 ...

i . . .

Transacción B... B1 ... Transacción C... C1 C2 C3 ...

Figura 4. 9 Diseño basado en el flu jo de tra nsac ción

El análisis de f lujo de transformación consiste en identif icar un f lujo globalde información desde los elementos de entrada al s is tema hasta los desalida, tal como se indica en la parte superior de la f igura 4.8. Los procesosse desl indan en t res regiones, denominadas de f lu jo de entrada, detransformación, y de sal ida. Para obtener la es tructura modular delprograma se as ignan módulos para las operaciones del d iagrama (o grupos




de el las) y se añaden módulos de coordinación que real izan el control deacuerdo con la distr ibución del f lujo de transformación, tal como se indicaen la parte inferior de la misma figura. Si se considera conveniente, a cadauna de las partes se le pueden aplicar a su vez las técnicas de análisis def lujo , para ref inar aún más la es tructura del s is tema.

El análisis del f lujo de transacción es aplicable cuando el f lujo de datos sepuede descomponer en var ias l íneas separadas , cada una de las cualescorre spon de a una fu nción global o t ransacción dis tin ta, de man era q ue sóloun a de es tas l íneas , en general , se activa para cada entr ada de dato s de t ipodiferente. En la par te sup er ior d e la f igura 4.9 se repres enta un d iagram a de

flujo con estas características. El análisis consiste en identif icar el l lamadocentro de transacción, a partir del cual se ramifican las l íneas de f lujo, y lasregiones correspondientes a cada una de esas l íneas o t ransacciones. Laestructura modular del s is tema puede der ivarse de la dis t r ibución del f lu joidentif icada en este análisis, tal como se indica en la parte inferior de lamism a f igu ra. Si se considera apro piado, a cada u na d e las t ransacciones sele puede apl icar por separado el anál is is de f lu jo de t ransformación y/o detransacción, para ref inar aún más la es tructura del s is tema.

Ficha de libro>

Figura 4.10 Ge stión de biblioteca . Diseño inicial



Técnicas Generales de Diseño de Software 169

4.2 .4 Ejemplo: Sist em a de gest ión de b ibl ioteca

Se describe aquí como ejemplo un posible diseño del caso práct icoespecif icado en el Tema 2 con el nombre de "Sis tema de Gest ión deBibl ioteca", empleando la técnica de diseño es t ructurado, por ser la másajus tada a la forma de especif icación mediante diagramas de f lujo de datosusada en el SRD de este ejemplo.

El pr imer paso será anal izar los t ipos de f lujo de datos que c i rculan por e ls is tema. Podemos reformular e l diagrama de pr imer nivel DFD.Oprescindiendo, para s impl i f icar , de los a lmacenes de información, en la

forma que se indica en la figura 4.10. En este diagrama se apreciaclaramente una es t ructura de t ransacciones , en la que e l centro detransacción no se corresponde con un proceso concreto, s ino s implementecon la ramificación del f lujo de órdenes de entrada. De aquí podemosderivar un primer nivel de es t ructura del s is tema ta l como el que apareceen dicha figura.

Gestión debiblioteca

Gestión delibros

"1Alta

Baja

Anularbaja

Listar

Compactar

Actualizarmaterias

Actualizar i

Gestión delectores

Gestión depréstamos

1Búsquedas

Alta

Baja

Anular

i i Ustar

! i I

i Compactar

Buscarlector

Actualizar

Préstamo

i—^ Devolución

Ustar

Préstamosde lector

Buscar pormateria

Buscar porautor

Buscar portítulo

Figura 4.11 Diseño final del sistem a de gestión d e b iblioteca

proceso puede repet i rse con cada uno de los subsis temas (ges t ión deros, de lectores, etc. . . ) , para refinar aún más la estructura del sistema. El

l is is de cada subsis tema nos vuelve a mostrar un esquema de f lujo de



170 Introducc ión a la Ingenier ía de Sof tw are

transacción, ya q ue cada u no d e el los es un a ag rupac ión d e funcion es más jsencil las , que se han asociado en un mism o proceso o diagra m a p or la :af inidad de los datos sobre los que operan. Es inmediato , por tanto , l legara la estructura f inal de la f igura 4.11, en que aparece un segundo nivel dedescomposición del s is tema.

4.3 Técnicas de diseño basado en abstracciones

Estas técnicas de diseño surgen cuando se identif ican con precisión losconceptos de abstracción de datos y de ocul tación descr i tos en el Tema

anter ior . La idea general es que los módulos se correspondan o bien confunciones o bien con t ipos abstractos de datos . Las es tructuras modulares!resul tantes pueden implementarse bien con lenguajes de programación quetengan faci l idades para implementar abstracciones de datos , tales comoModula-2 o Ada, y en menor medida con lenguajes como Pascal o C. Porsupues to , pueden también implementar se con lenguajes de p rogramaciónor ientad os a objetos , que poseen aú n m ás faci l idades . En todo caso resul tanmenos apropiados los lenguajes como FORTRAN o COBOL que sólocuen tan con módulos de t ipo subprograma.

4.3.1 Descomposición modular basada en abstr accio nes

Esta técnica aparece descrita en [Parnas72] y [Liskov80]. Considerada comotécnica de programación, consis te en ampliar el lenguaje exis tente connue vas operac iones y t ipos de datos , def inidos por el usuar io , de form a quese s implif ique la escr i tura de los niveles super iores del programaJConsiderada como técnica de diseño, consis te en dedicar módulosseparados a la real ización de cada t ipo abstracto de datos y cada función :

impor tan te .

Para la representación de la es tructura modular basada en abstracciones, ]

usaremos la notación introducida en el Tema anter ior , basada en lapropuesta inicial de [Liskov80].

Esta técnica de diseño puede apl icarse tanto en forma descendente comoascendente. En form a desce nden te pue de considerarse como una am pliaciónde la técnica de ref ina mie nto progresivo, en que al real izar un ref inam ientose plantea como al ternat iva, además de su descomposición, el que laoperación a ref inar se def ina separadamente como abstracción funcional , obien como operación sobre un t ipo abstracto de datos . En forma ascendentese t rata de i r ampliando las pr imit ivas exis tentes en el lenguaje deprogramación y las l ibrer ías asociadas con nuevas operaciones y t ipos de




mayor nivel , más adecuados para el campo de la apl icación que se es tád iseñando . En muchos casos puede ap l icar se s imul táneamente de ambasmaneras .

Volviendo al ejemplo de la ecuación de 2 o grado, usado en la sección 4.2.1,podemos ident i f icar los t ipos abstractos correspondientes a un númerocomplejo, y a una ecuación de 2o grado. Sabiendo que la fórmula que da lasraíces es:

podemos def inir sobre dichos t ipos abstractos las s iguientes operacionesnecesarias para la aplicación:

Para obtener las raíces se usarán las operaciones def inidas sobre los

números comple jos . La es t ruc tu ra modular de l p rograma podr ía serla representada en la f igura 4.12.

AX2+Bx+C=0 x=B±YJ B2-&AC

2 A

Ecuación de 2 o grado:Leer ecuación

Escribir ecuación

Obtener raíces

Número comple jo :Escribir

Sumar, Restar, etc...

Raíz cuadrada

Programaprincipal

Ecuación de2Q grado

Figura 4.12 Ejemplo de diseño basado en ab strac cion es



172 Introdu cción a la Ingenier ía de Softw are

4.3 .2 Método de Abb ott

En la descripción de la descomposición modular basada en abs t raccionesdel apartado anter ior no se ofrece ninguna guía , sa lvo el sent ido común,para i r reconociendo aquel los e lementos del modelo del s is tema que sonbuenos candidatos para ser considerados como abs t racciones , seanfunciones o t ipos abs t ractos de datos . En [Abbot t83] se sugiere una formame tódica de con seguir lo a part i r d e las descripciones o especif icaciones dels is tema hechas en lenguaje natural . De hecho es ta técnica puede apl icarsetambién, y con mayor precis ión, a las descripciones más formales , queemplean notaciones precisas y no sólo lenguaje natural .

La idea es identificar en el texto de la descripción aquellas palabras oté rminos que puedan cor responder a e lementos s igni f i ca t ivos de l d i seño:t ipos de datos , a t r ibutos y operaciones , fundamentalmente . Los t ipos dedatos aparecerán como sus tant ivos genéricos , los a t r ibutos comosustant ivos , en general , y las operaciones como verbos o bien comonom bres de acc iones. Alguno s adje t ivos pu ede n t am bién suger i r va lores delos a t r ibutos .

Se pu ede co menzar su bray and o en e l t ex to todos los t é rminos de a lguno delos t ipos indicados, que sean significativos para la aplicación, y establecerdo s li s tas : un a de no m bres y ot ra de verbo s u operaciones . El s iguiente pasoes reorganizar dichas l i s tas extrayendo los pos ibles t ipos de datos , yasociándoles sus a t r ibutos y operaciones . Al reorganizar las l i s tas hay quedepurarlas e l iminando los términos i r re levantes o s inónimos, y completar lacon los e lem entos impl íc i tos en la descripción, pero qu e no se m encio naba nexpresamente .

Podemos i lus t rar es ta técnica apl icándola a l e jemplo del programa de a jus tede un texto, ya ut i l izado en es te Tema. Comenzaremos con unaespecif icación informal del mismo, en la que subrayamos los e lementos

significativos:A J U S T E D E L M A R G E N D E R E C H O D E U N T E X T O - E s p e c i f i c a c i ó n i n f o r m a l

Se trata de desarrollar un programa que permita obtener textos impresos con elmargen derecho bien ajustado, al mismo tiempo que se recomponen las líneaspara que contengan tantas palabras como quepan en ellas.

El programa operará a partir de un texto de entrada sin ajustar y sin limitacionesde margen, el cual deberá ser impreso a la salida en forma ajustada.

El ajuste se hará de manera que se respete la separación en párrafos del texto de

entrada. Dicha separación vendrá marcada por líneas en blanco y/o sangrado.



Técnicas Ge nerales de Diseño de Sof tw are 173

Esto quiere decir que la primera línea de un párrafo debe seguir a una línea enblanco o bien empezar por algún espacio en blanco. Las líneas segunda ysiguientes del párrafo empezarán en la primera columna, y no irán precedidas deninguna línea en blanco.

La form a de separar párraf os en el texto inicial debe respetarse en la salida. Estoquiere decir que las líneas en blanco entre párrafos deben reproducirse en lasalida, así como el sangrado si lo hay.

Todas las líneas de salida, excepto las que sean final de párrafo, deberán serajustadas al margen derecho intercalando espacios en blanco entre las palabras.La posición del margen derecho será un parámetro global del programa.

En este marcado ya se ha omit ido destacar cier tos elementos deinformación, tales como ". . . primera línea de un párrafo . . . segunda y siguientes . . .

primera columna . . .", que se refieren a las l íneas del texto de entrada,cuya organización, como ya se di jo en un apar tado anter ior , no essignif icativa para el resultado a generar , salvo en lo referente a laseparación entre párrafos .

A par t i r de es te marcado elaboramos una doble l is ta , con loselementos correspondientes a datos y a operaciones. En estas listasse han marcado con el s igno "=" los términos considerados s inónimos.

También se han dis t inguido, comentándolos , los términos homónimospero con diferente s ignif icado.

separación en párrafos= fo rma de separar pár rafoslíneas en blancos an g r ad o= espacio en blanco

(comienzo de línea)p á r r a f olíneas de salidafinal de párrafoespacios en blanco

(entre palabras de salida)

DAT OS OPERACIONEStextos impresos= sal idamargen derecho= mar g enpalabrastexto de entrada= texto inicial

a jus tado= ajustar= ajuste= intercalando (espacios)r eco mp o n enq u e p a nser impreso




Figura 4.13 Programa de ajuste: diseño mediante ab stracc ione s

A partir de estas l istas iniciales hay que elaborar la descripción deabstracciones, indicando para cada t ipo abstracto de datos cuálesson sus atr ibutos y sus operaciones. En esa l is ta se pueden añadir loselementos necesarios no incluidos en las l istas iniciales. En este case podr ía tener :

D A T O : PalabraAtr ibutos:

caracteresOperaciones:

impr imir

DATO: Párrafo (de salida)Atr ibutos:separador de pár rafolíneas de salida

Operaciones:iniciar pár rafoponer palabra (= recomponer)te rminar pár rafo

D A T O : Separador de pár rafoAtr ibutos:

líneas en blancos an g r ad o

Operaciones:

D A T O : Línea (de salida)Atr ibutos:s an g r ad opalabras

Operaciones:iniciar línea¿cabe palabra?poner pa labraimpr imir s in ajustarimpr imir a jus tada




Para obtener el d iseño podemos asignar un módulo a cadaabstracción de datos o grupo de abstracciones relacionadas entres í . El módulo puede corresponder a un dato encapsulado s i sólo semaneja un dato de ese t ipo en todo el programa. Además hay quetratar de expresar cada operación en función de las otras , para verlas relaciones de uso entre módulos y detectar posibles omisiones .También hay que añadir abstracciones funcionales para el móduloprincipal y otras operaciones omitidas, en su caso. En este ejemplo sedetecta la omisión de una función para leer las palabras del textode entrada y reconocer la separación entre párrafos . El d iseñoresultante podría ser el indicado en la f igura 4.13. El t ipo "separador

de párrafo" no se ha mater ial izado en un módulo separado, ya queno hay operaciones def inidas sobre él y su contenido de informaciónse reduce a un par de números enteros ( l íneas de separación ysangrado) .

4.3 .3 Ejemplo: Videoju ego de las minas

Este ejemplo ha sido descrito en el Tema 2, donde se encuentra incluso eldoc um ento de especificación de requis itos , completo . Para real izar el d iseñobasado en abstracciones debem os emp ezar po r recopi lar toda la informa ción

disponible. Puede considerarse que la información es bastante precisa, eincluye ya la ident i f icación de var ias funcion es y t ipos de da tos impo r tantes .

Un pr imer repaso del documento de especif icación de requis i tos , al quepodemos apl icar la técnica de Abbot para ident i f icar elementossignificativos, nos conduciría a una primera lista de tipos de datos yoperaciones asociadas , por ejemplo:

D A T O : TableroAtr ibutos:

t amañ odatos de casillasn° de minasn° de casi l las destapadas

Operaciones:iniciar tableromover cur sord es t ap a rp o n e r /q u i t a r mar ca

D A T O : CasillaAtr ibutos:

hay minan° de minas vecinases tá des tapadaes tá marcadaOperaciones:d es t ap a r

p o n e r /q u i t a r mar ca

O P E R A C I Ó N : Minas ( ju e

g o )




D A T O : Tabla de resul tadosAtributos: (por nivel y entrada) O P E R A C I Ó N : A y u d a

textot iempo

Operaciones:ano tar r esu l tadopresentar en pantal la

En esta lista se han incluido algunos tipos abstractos de datos, así como unpar d e abstracciones funcionales , corresp ondiente s al pro gra m a pr incipal (eljuego de las minas) y a la invocación de la ayuda en pantalla. El siguiente

nivel de ref inamiento exige idear de manera más precisa la forma dereal izar cier tas operaciones. Por ejemplo, se t iene el problema de cómoactual izar el cronó me tro en pantal la m ientras se es tá des arrol lan do el juego,y en par t icular mien tras se es tá espe rand o qu e el jug ad or pu lse alguna tecla.Otros problemas son cómo conservar los mejores resul tados de una sesiónpara otra, y cómo actualizar un elemento en pantalla sin álterar lapresentación de otros .

Los úl t imos problemas son relat ivamente fáci les de resolver . Se puedealmacenar la tabla de resultados en un f ichero en disco, entre sesión ysesión. La pantal la puede actual izarse por zonas, d isponiendo de una

función para situar el cursor de texto antes de escribir . Estas soluciones nosl levan a diseñar nuevas abstracciones de nivel más bajo que las anter iores ,y que permitan real izar las operaciones indicadas , pero evi tando tener queinvocar directam ente fun cione s del sis tema operat ivo. El prob lem a de actuarpor t iempo y no sólo por la acción del jugador es algo más complejo . Se;podr ía pensar en usar el mecanismo de inter rupciones, pero resul ta mássenci l lo real izar en el programa pr incipal un esquema de monitor cícl ico, ;disponiendo de una operación de lectura del teclado que no impliqueespera: si no se pulsa tecla se devuelve tecla nula al leer . El esquema sería:

REPETIRLeer teclaSI tecla no nula ENT ON CES

responder a la teclaFIN-SILeer t iempoSI ha pas ado el p lazo ENT ON CES

actuar por t i empoFIN-SI

HASTA f in de l juego



Técnicas Ge nerales de Diseño de Sof tw are 177

Esto nos l leva a diseñar un módulo de cronómetro del juego, de al to nivel ,que se apoya en otro de bajo nivel para leer el reloj del computador, asícomo otro módulo de bajo nivel para leer del teclado sin espera. Elcronómetro ser ía un dato encapsulado, def inido de la s iguiente manera:

D A T O : Cr o n ó met r oAtr ibutos:

t i empo t r anscur r ido , en segundosOperaciones:

iniciaractual izar , s i ha pasado un segundo

p a r a r

El resul tado f inal del d iseño se recoge en el documento que aparece comoejemplo de documento completo de diseño arqui tectónico, más adelante eneste mismo Tema.

4.4 Técnicas de diseño orientadas a ob jetosA

El diseño or ientado a objetos es esencialmente igual al d iseño basado enabstracciones, que de hecho se describe en muchos casos como "basado enobjetos". Los objetos sólo añaden algunas características adicionales, talescomo la herencia y el pol imorf ismo.

Se han descr i to una gran var iedad de metodologías par t iculares en es tecampo [Coad90], [Booch94], [Rumbaugh91], etc. Todas ellas t ienen muchoselementos en común, y se dis t inguen sobre todo en la apar iencia de losdiagramas empleados para descr ibir el d iseño. Esta s i tuación es análoga ala que ocurr ió en su momento con las metodologías de anál is is y diseñoestructurado, basadas en los diagramas de f lu jo de datos .

La idea global de las técnicas de diseño orientadas a objetos es que en ladescomposición modular del s is tema cada módulo contenga la descr ipciónde un a clase de objetos o de var ias clases relacionadas entre s í . A dem ás deldiagrama modular que descr ibe la es tructura del s is tema, es tasmetodologías se apoyan en diagramas ampliados del modelo de datos , enque se ponen de manif ies to dis t in tas relaciones entre los datos ,independientes de las relaciones de uso, que son las que aparecen en eld iagrama de es t ruc tu ra .




4.4.1 Diseño orientado a objetos

Pue sto que la ma yoría de las meto dolog ías or ienta das a objetos son bas tantes imilares , nos l imi tarem os aquí a describi r un a técnica general par a derivarel diseño a partir de las especificaciones del sistema. Realmente el diseñoorientado a objetos se solapa en parte con el análisis del sistema si en él seemplean ya objetos para describi r e l modelo del s is tema a desarrol lar .

La técnica general de diseño se basa en los siguientes pasos:

1) Es tud iar y com pre nd er el pro blem a a resolver . Refo rmu lar las

especificaciones, s i se considera conveniente, para hacerlassufic ientemente precisas .

2) De sarrolla r en l íneas gen erale s un a posib le solución . Describirlasuf ic ien temente , a l menos de una manera informal .

3) Fo rm alizar dicha estrateg ia en térm ino s de clases y objetos y susrelaciones . Es to puede hacerse mediante las s iguientes e tapas :

a.- Iden tificar los objetos (o clases), su s atri bu tos y com pon entes. jb.- Iden tificar las ope racio nes sobre los objeto s y asociarlas a la

clase u objeto adecuado.c .- Apl icar herencia do nd e sea conven iente .d. - Describir cada operación en fun ción de las ot ras , y su bsan an

posibles omis iones .e .- Es tablecer la es t ruc tura mo du lar del s is tema, as ign and o clases

y objetos a módulos .

Si t ras es tos pasos e l diseño del s is tema no es tá sufic ientemente ref inado,se vuelven a repetir, aplicándolos a las clases y objetos poco detallados^has ta conseguir un diseño aceptable , l i s to para ser codif icado,

cont inuación se detal la a lgo más cada uno de los e lementos de es ta técnigeneral .

1. ESTUDIAR Y COMPRENDER EL PROBLEMA . Debe haberse real izado ya enfase de anál is is de requis i tos . Sin embargo puede ser necerepet i r lo en parte , bien porque la especif icación nosufic ientemente precisa , o s implemente porque el diseño va areal izado por personas di ferentes de las que confeccionaronespecificación.




2. DESARROLLAR UNA POSIBLE SOLUCIÓN. ES posible que es to se haya hecho

también durante la fase de anál is is , aunque es más probable que setenga que hacer o completar en la fase de diseño. Convendráconsiderar var ias al ternat ivas y elegir la que se considere másapro piad a. La solución elegida debe expresa rse con suf iciente detal lecomo para que en su descr ipción aparezcan mencionados casi lose lementos que fo rmarán par te de l d i seño . De todas maneras puedeser suf iciente una descr ipción informal .

3.a IDENTIFICAR LAS CLASES Y OBJETOS . Pue de hacerse s iguiend o la técnica deAbbott mencionada anter iormente. En este pr imer paso se at iende

sobre todo a identif icar las clases de objetos y sus atr ibutos. Si unobjeto contiene otros objetos, no se suelen tratar como atr ibutos, sinoque se establece una relación de composición entre el objetocompuesto y los objetos componentes . Tras es te pr imer paso puedeya confeccionarse un diagrama inicial del modelo de objetos, con lasrelaciones de composición, así como otras relaciones generales quese vayan ident i f icando.

3.b IDENTIFICAR LAS OPERACIONES SOBRE LOS OBJETOS. También puedehacerse s iguiendo la técnica de Abbott . Además de ident i f icar lasoperaciones hay que decidir a qué objeto o clase se asocia. Esto

puede ser un problema de diseño no t r iv ial . Por ejemplo, laoperación de escr ibir en pantal la la representación como caracteresde una fecha puede asociarse al objeto fecha, o bien al objetopantal la . Cada decis ión t iene sus ventajas e inconvenientes . Enalgunos casos puede f raccionarse la operación en var ias mássencil las . Por ejemplo, se pue de def inir una o peración de conversiónde fecha a texto, sobre el objeto fecha, y otra operación de escrituradel texto sobre el objeto pantalla. Las operaeiones pueden reflejarsesobre el d iagrama de modelo de objetos .

3 . C A P L I C A R H E R E N C I A .

Una v ez iden t i f icados los objetos y su s operacionesasociadas, hay que detectar analogías entre ellos, si las hay, yestablecer las relaciones de herencia apropiadas , reformulando lasdescripciones de los objetos si es necesario. Estas relaciones deherencia se incluirán en el d iagrama de modelo de objetos que se vadesar ro l lando .

3.d DESCRIBIR LAS OPERACIONES. Esta es una manera de ver if icar que eldiseño es consis tente. Cada operación se descr ibe de m ane ra inform alo en pseudocódigo, haciendo referencia únicamente a operaciones oclases de datos def inidos en es te mismo diseño, o bien predef inidos




en el lenguaje de program ación a usar y otros elem entos de sof twar eya disponible. En caso necesar io habrá que añadir nuevasoperaciones a las ya identif icadas, o incluso nuevas clases de objetos,y se actualizará el modelo de objetos.

3.e E S T A B L E C E R L A E S T R U C T U R A M O D U L A R . Para ello hay que asignar clases,objetos y operaciones a m ódu los separ ados. En pr incipio se in tentaráque cada módulo corresponda a una clase de objetos (o a un objetoen par t icular ) . Si el módulo es demasiado complicado, cier tasoperaciones pueden establecerse como módulos separados. Tambiénes posible agrupar en un solo módulo var ios objetos o clases muy

relacionados e ntre s í, para m ejorar las caracterís t icas de acoplam ientoy cohesión. Como resu l tado de es ta etapa se obte ndrá el d iagr am a deestructura del s is tema.

Como ya se ha indicado, hay que anal izar s i el d iseño modular resul tantees apropiado para pasar a la fase de codif icación. Si algún módulo estodav ía d em asiad o com plejo , o no es tá de f inido con suf iciente precis ión, serepet i rán los pasos anter iores de diseño para ese módulo, con objeto derefin ar lo.

4.4 .2 Ejemplo: Estación me teorológica

Para la realización de este ejercicio de diseño se parte de una especif icacióno descr ipción informal del s is tema a desarrol lar :

EJEMPLO: ESTACIÓN METEOROLÓGICA

Un s is tema de recogida de datos meteorológicos es tá formado por una serie dees taciones meteorológicas automáticas que recogen datos ambientales , real izanalgún t ratamiento local de dichos datos , y envían periódicamente la informaciónrecogida y elaborada a un computador de zona para su t ratamiento.

Se trata de diseñar el software que ha de controlar el funcionamiento de una deestas estaciones automáticas.

Los datos medidos son:

• Temperatura• Velocidad y dirección del viento• Pres ión atmosférica• Precip itación (lluvia)

Para ello se dispone de dispositivos de medida que aceptan las siguientes órdenesbásicas :

T e r móme t r o :

• lectura de la temp eratura en ese instante



Técnicas Generales de Diseño de Sof tware 35

Anemómetro:

• lectura de la velocid ad de viento en ese instante

Veleta:

• lectura de la direcció n de viento en ese instante

Barómetro:• lectura de la presión atmosférica en ese instante

Pluviómetro:• iniciar medición (vaciar el depósito)• lectura de la lluvia caída desde el inicio anterio r

Los datos de los medidores deberán leerse cada minuto, excepto la precipitaciónque se leerá cada hora.

Con las lecturas de los instrumentos deberán realizarse los siguientes cálculospara cada periodo de una hora:

• Con los datos de temperatu ra, presión, y velocidad de viento, seobtendrán los valores máximo, mínimo y medio.

• Para la dirección de viento, se obtendrá la media y se marca rán paraenviar todas las lecturas que se desvíen en más de 15°.

La estación meteorológica dispone de otros dos dispositivos para la medida deltiempo y comunicación con el computador de zona. Las operaciones básicas son:

Reloj:• lectura de la hora en ese instante• poner el reloj en hora

Modem:• recibir un men saje• transmitir un mens aje

La comunicación con el computador de zona se realiza por línea compartida. Elcomputador de zona explorará cíclicamente (mediante polling) las estacionesmeteorológicas para ver si tienen algo que comu nicar. L as estaciones res ponde ráncon uno o varios mensajes, el último de los cuales indicará fin de transmisión.

Las estaciones comunicarán datos cuando hayan completado el tratamiento de losvalores de una hora. El mensaje de exploración desde el computador centralincluirá la hora del reloj maestro. La estación pondrá su reloj en hora si ladesviación del reloj local excede de 20 segundos.

El arranque de la estación meteorológica se hará automáticamente al conectarsea la corriente, o mediante un pulsador manual. En el arranque, se esperará a unaexploración del computador de zona, se pondrá el reloj en hora, se notificará quese produce dicho arranque, y se inicializará la recogida de datos.

También habrá un pulsador manual de parada que detendrá la operación de laestación.

El diseño or ientado a objetos puede real izarse s iguiendo losindicados anter iormente:



182 Introducción a la Ingenier ía de Sof tware

1. Estudiar y comprender el problema. Requiere leer con atención lasespecif icaciones y consul tar todos los puntos dudosos que seencuentren. En par t icular habrá que conocer el formato de losmensajes a enviar y recibir .

2. Desarrollar una posible solución. En este caso se puede optar pormantener en memoria los datos necesar ios para i r componiendo lainformación que habrá que enviar cada hora. Esta información será:

• Para la tem pera tura, presión, velocidad y dirección de viento ,

la suma de las medidas y el número de el las , para obtener lamedia al f inal.

• Para la tem pera tura, presión y velocidad de viento , el máxim oy el mínimo hasta cada momento, que serán f inalmente los detoda la hora.

• Para la dirección de viento , cada una de las mue stras , parapoder seleccionar al f inal de la hora las que se desvíen másdel límite.

Los valores f inales se calcularán al cabo de la hora, y se pondrána cero los regis t ros . Los valores f inales se mantendrán almacenadosen espera de t ransmit i r los a la es tación central , a l mismo t iempo quese va real izando la recogida de datos de la hora s iguiente. Alcompletar una nueva hora, los nuevos datos to tales se almacenanreemplazando a los de la hora anter ior , aunque éstos no hayanpodido ser t rasmit idos a la es tación central .

3.a Identificar las clases y objetos. Según la técnica de Abbott,marcando los términos clave como se ha hecho en la descr ipcióninformal inicial, se pueden confeccionar las siguientes listas deelementos signif icativos:

DAT OSdatos meteorológicos= datos ambientales= t emp er a tu r a= velocidad del v iento= dirección del viento= presión atmosfér ica

OPERACIONES flectura= leeriniciar mediciónobtener máximoobtener mín imoobtener media




= precipi tación= lecturas que se desvíendisposi t ivo de medidamensajef in de t ransmisiónh o r aestaciónp u l s ad o r man u a l

poner el reloj en horarecibir= explorart ransmit i r= r esponder= comunicar= notif icara r r an q u edetener

A par t i r de la l is ta de nombres de datos hay que ident i f icar los

candidatos a clases y objetos. Este paso no es tr ivial, y requierecierta experiencia o habilidad para realizarlo. En este ejemplo sepuede llegar a la siguiente lista de clases y atr ibutos:

Disposi t ivo de medidalecturamáx imomín imomed ialecturas que se desvían

Mensajehoradatos meteorológicosf in de t ransmisión

Relojhora

Estación

3.b Identificar las operaciones sobre los objetos. A partir de la l istade operaciones se van asignando los diferentes elementos a las clases

reconocidas. En este caso, podemos llegar a la siguiente distr ibución:

Disposi t ivo de medidaleeriniciar mediciónobtener máximoobtener mín imoobtener media

Mensajeenviarrecibir



184 Int roducción a la Ingenier ía de Software

Relojleerponer en hora

Estaciónar rancarde t e ne r

3.c Aplicar herencia. En es te caso se puede observar que no todas laoperaciones sobre disposi t ivos de medida son apl icables a cada uno delos disposi t ivos . Podemos ident i f icar medidores especial izados , con

operac iones par t i cu la res . As í l l egamos a l s iguiente esquemasup erc lase / subc lases:

M e d i d o rMedidor con máximo, mínimo y mediaMedidor con media y lecturas que se desvíanMedidor con pues ta a cero inic ia l

La pr imera subc lase cor responde a l as medic iones de t empera tura ,pres ión y velocidad de viento, mientras que la segunda correspondea la dirección del viento, y la tercera a la precipitación. Ahora hay

que redefini r los a t r ibutos y operaciones sobre es tas c lases . Lasnuevas operac iones podr ían se r :

M e d i d o rleer (lectura simple)

Medidor con máximo, mínimo y medialee r (acumulando y ac tua l i zando máximo y mínimo)obtener mediaponer a cero (e l acumulador)

Medidor con media y lecturas que se desvíanleer (acumulando y regis t rando lecturas)obtener mediaobtener medidas desviadasponer a cero (e l acumulador)

Medidor con pues ta a cero inic ia linic iar medición




Todos los medidores especial izados heredan la operación de lecturasimple, y la mayoría de ellos la redefinen.

3.d Describir las operaciones. Ahora hay que comprobar que cadaoperación es real izable, b ien directamente o en función de las otras .Por ejemplo, la clase "Medidor" y la subclase "Medidor con máximo,mínimo y media" se podr ían def inir , en pseudocódigo, en la formasiguiente:

CLASE Medidor

ATRIBUTOSlectura: TipoMedidaOPERACION Leer

tomar una nueva ' lectura 'FIN-CLASE

CLASE MedidorConMáximo ES-UN MedidorATRIBUTOS

máximo, min ino : T ipoMedidaacumulado : T ipoMedidanumMues t ras : ENTERO

OPE RACI ON Po n e r ACer oponer a cero 'acumulado ' y 'numMuestras '

OPE RACI ON Ob ten e rM ed ia ( m ed i a )devue lve 'media ' = 'acum ulado ' / 'num M uestras '

OPERACION LeerSUPER.Leeracumular la nueva ' lectura ' en 'acumulado 'incrementar 'numMues t r as 'si la nueva ' lectura' es mayor que el 'máximo', anotarla

como nuevo 'máximo '

si la nueva ' lectura' es menor que el 'mínimo', anotarlacomo nuevo 'mín imo 'FIN-CLASE

Las operaciones que dan problemas son las de "Arrancar" y "Detener"la es tación. Con un poco de ref lexión se puede comprender que enrealidad la estación sólo tiene una operación que realizar , que es elt rabajo normal , y que podemos redef inir como "Operar". El f lu jo decontrol de es ta operación puede adoptar la forma clás ica demonitor cíclico, lo que conduce al siguiente pseudocódigo:




CLASE EstaciónOPE RACI ON Op er a rinicializar la estaciónREPETIR

SI hay mensa je ENTONC ESrecibir mensajeponer en hora el reloj, si hace faltacomponer mensaje con datos de la hora anter iorenviar el mensaje

FIN-SIleer el reloj

SI ha pasad o un minu to ENTONC ESleer medidas de tempera tu ra , v ien to y p res ión

FIN-SISI ha pasad o una hora ENTON CES

leer pluviómetroiniciar lectura del p luviómetrocalcular los datos de la hora

FIN-SIHASTA tec la de para da pu lsada

FIN-CLASE

Esta descr ipción nos l leva a descubr ir que necesi tamos dosoperaciones adicionales sobre la clase "Mensaje", correspondientes adetectar s i ha l legado un nuevo mensaje, y a componer el mensajepara enviar lo .

Con el resul tado de todos es tos pasos del d iseño se puede yaconfeccionar un diagrama de objetos del sof tware de la es taciónmeteorológica, tal como el que se representa en la f igura 4.14. Unobjeto "Estación" se compone de un gestor de "Mensajes" (modem), un"Reloj", y una colección de medidores de las clases indicadas. Los

medidores son especializaciones de la clase genérica "Medidor".

3.e Establecer la estructura modular. Ahora se agrupan loselementos del d iseño en módulos , y se construye el d iagrama deestructura de la aplicación, con las relaciones de uso entremódulos . La forma más senci l la de hacer lo es as ignar un módulo acada clase de objetos. Con ello se llega a la arquitecturarepresentada en la f igura 4.15. Las relaciones de herencia de lafigura 4.14 se traducen ahora a relaciones de uso. Una subclaseutiliza el código de su superclase.




Figura 4.14 Modelo de ob jet os de la estació n me teorológica

Figura 4.15 Arqu itectura del so ftw ar e de la estació n m eteorológica




4 .5 Técnicas de diseño de datos

La mayor ía de las apl icaciones informáticas requieren almacenarinform ación en form a perm ane nte. La ma nera t íp ica de hacer lo es apo yan doesa aplicación en una base de datos subyacente. El diseño de la estructurade las bases de datos es hoy día una disciplina independiente [Date90],[DeMiguel93], al igual que otras que sirven de apoyo a la ingeniería delsof tware .

En esta sección y las s iguientes se presentan algunas ideas fundamentalessobre cómo organizar la base de datos en que se almacena la informaciónpermanente de una apl icación informática. Muchas de es tas ideas puedenapl icarse también a la organización de las es tructu ras de datos en mem oria,durante la operación de la apl icación.

La organización de la base de datos puede real izarse desde var ios puntosde vista. Una forma clásica de enfocarla es en tres niveles: externo,concep tual e in terno. En cada nivel se es tablecen esquem as de organizaciónde los datos desde un punto de vis ta concreto . El paso de un nivel a otroes el siguiente:

nivel externo: Esquemas de usuar io

N. ANÁLISISnivel conceptual: Esque ma s lógicos

N D I S E Ñ O

nivel interno: Esquemas f ís icos

El nivel externo corresponde a la vis ión dé usuar io . La organización de losdatos se real iza s iguiendo esquemas s ignif icat ivos en el campo de laapl icación, por ejemplo, en forma de f icha de cl iente o de empleado.

El nivel conceptual establece una organización lógica de los datos, conindep ende ncia del sent ido f ís ico que tengan en el cam po de apl icación. Esaorganización se resume en un diagrama de modelo de datos , b ien del t ipoEntidad-Relación (descr i to en el Tema 2) o como diagrama de Modelo deObjetos (descrito en el Tema 3)

El nivel físico organiza los datos según los esquemas admisibles en els is tema de gest ión de bases de datos y/o lenguaje de programación elegidopara el desarrollo. Si se util iza una base de datos relacional los esquemasf ís icos serán esquemas de tablas .




El paso del n ivel externo al n ivel conceptual se puede real izar durante laetapa de análisis de requisitos. El paso del nivel conceptual al nivel internose real izará habi tualmente durante la fase de diseño.

4.6 Diseño de bases de datos relaciónales

Par t iendo del modelo Entidad-Relación o bien del Modelo de Objetos , esposible dar reglas prácticas, relativamente sencillas, para obtener losesqu em as de las tablas de una base de da tos relacional que ref lejen la vis ión

lógica de los datos, y que sean aceptablemente eficientes. En [Rumbaugh91]se s is tematizan bien esas recom endaciones, que nos guían sobre la form a detraducir a esquem as de tablas los atr ibutos d e las ent idade s, y las relacionesentre ellas, incluyendo las de composición y herencia entre objetos.

En el modelo relacional, los aspectos de eficiencia se contemplan desde dospuntos de vis ta . Por una par te se es tablecen las l lamadas formas normales,que t ienden a evi tar redundancias en los datos almacenados. Por otra par tese es tudia el empleo de índices para mejorar la velocidad de acceso a losdatos .

4.6.1 Formas normales

Las form as norm ales de Cod d def in en cri terios par a es tablecer esquema s detablas que sean claros y no redundantes . Estos cr i ter ios se numerancorrelat ivamente, de menor a mayor nivel de res tr icción, dando lugar a lasfo rmas normales Ia, 2a, 3a, e tc . Una tabla que cumpla con una cier ta formanormal cumple también con las anter iores .

Para i lus trar las def iniciones de es tas formas normales , consideraremos

com o ejemplo una tabla en que se recoge inform ación sobre la organizaciónde las clases presenciales en un determinado centro educat ivo. En cadacurso hay var ios grupos de clase, y en cada grupo se impar ten var iasasignaturas . Cada asignatura es impar t ida por uno o var ios profesores , cadauno de los cuales se encarga de esa as ignatura en uno o var ios grupos.Cada asignatura t iene, además, un profesor coordinador , que puede ser , ono, uno de los profesores que la impar ten. Cada profesor t iene as ignado undespacho. En la f igura 4.16 se recoge toda esta información en una solatabla.



190 Introd ucc ión a la Ingen iería de Sof twa re

Grupo Asignatura Profesor Despacho Coordinador11, 12 Cálcu lo F. Díaz D-23 R. Pérez13 Cálculo A. García D-27 R. Pérez11 Algebra C. Morales D-34 F. Arranz12 Algebra M. Campos D-21 F. Arranz13 Algebra F. Arranz D-32 F. Arranz

Figura 4.16 Tabla sin ninguna normalización

Se dice que una tabla se encuentra en Ia forma normal si la información

asociada a cada una de las columnas es un valor único, y no una colecciónde valo res en núm er o variab le. La tabla de la f igura 4.16 no está en Ia f o r manormal , porque hay alguna casi l la en que se ha anotado más de un valor(var ios grupo s con el mism o profesor) . Podem os forza r que la tabla es tá enIa forma normal desdoblando la f i la de esa casi l la en tantas f i las comovalores hay en la misma casilla, tal como se indica en la f igura 4.17.

Grupo Asignatura Profesor Despacho Coordinador

11 Cálculo F. Díaz D-23 R. Pérez

12 Cálculo F. Díaz D-23 R. Pérez13 Cálculo A. García D-27 R. Pérez11 Algebra C. Morales D-34 F. Arranz12 Algebra M. Campos D-21 F. Arranz13 Algebra F. Arranz D-32 F. Arranz

Figura 4.1 7 Tabla en Ia forma normal, pero no en 2 a

Se dice que una tabla está en 2a forma normal si está en I a fo rma normal yademás hay una clave pr imar ia (una columna o combinación de var ias) quedistingue cada f ila, y cada casilla que no sea de la clave primaria dependede toda la clave primaria. En la tabla de la f igura 4.17 la clave primaria esla combinación de las dos pr imeras columnas. La tabla no está en 2a f o r manorm al porqu e e l da to de l coord inador de la as ignatu ra no depen de de todala clave primaria, sino sólo de parte de ella (depende de la asignatura, perono de l g rupo) . Se puede consegu i r l a segunda fo rma normal supr imiendoeste dato de la tabla principal, y usando una tabla auxiliar para relacionarla asignatura con el coordinador, tal como se hace en las tablas de la f igura4.18.




Grupo Asignatura Profesor Despacho

11 Cálculo F. Díaz D-2312 Cálculo F. Díaz D-2313 Cálculo A. García D-2711 Algebra C. Morales D-3412 Algebra M. Campos D-2113 Algebra F. Arranz D-32

Asignatura Coordin.

CálculoÁlgebra

R. PérezF. Arranz

Figura 4.1 8 Tabla en 2Q forma normal, pero no en 3 a

Se dice que una tabla está en 3a forma normal si satisface el criterio de la2a forma normal y además el valor de cada columna que no es clavepr imar ia depende directamente de la clave pr imar ia, es decir , no haydependencias entre columnas que no son clave pr imar ia. La tabla de lafigura 4.18 no está en 3 a fo rma normal porque e l despacho de l p rofesordepende del profesor . Puede conseguirse la tercera forma normalel im inand o de la tabla cada colum na de pen dien te de otra no clave pr imar ia,y usando una tabla auxi l iar para regis t rar d icha dependencia. Esto se hahecho en las tablas de la f igura 4.19.

Grupo Asignat. Profesor

11 Cálculo F. Díaz12 Cálculo F. Díaz13 Cálculo A. García11 Algebra C. Morales12 Algebra M. Campos13 Algebra F. Arranz

Asignat. Coordin.

CálculoÁlgebra

R. PérezF .Arranz

Profesor Desp

F. Díaz D-23A. García D-27C. Morales D-34M. Campos D-21F. Arranz D-32

Figura 4.19 Tabla en 3a forma normal

Existen cr i ter ios aún más res tr ict ivos que def inen las formas normales 4a y

siguientes, que se aplican poco en la práctica.

4.6 .2 Diseño de las ent idad es

En el modelo relacional cada ent idad del modelo E-R se t raduce en unatabla por cada clase de entidad, con una f ila por cada elemento de esa clasey una columna por cada atr ibuto de esa ent idad.




Si una entidad está relacionada con otras, y se quiere tener una referencia

rápida entre las ent idades relacionadas, se puede incluir además unacolumna conteniendo un código o número de referencia que ident i f iquecada elemento de datos, es decir , cada f ila de la tabla. En el modelo deobjetos, esto corresponde a almacenar explícitamente en la tabla elidentif icador del objeto.

El nú m ero o código de referencia, si se usa, s i rve perfecta me nte como clavepr imar ia .

4.6 .3 Tratam iento de las relaciones de asociación

En el modelo de objetos se distinguen dos tipos especiales de relación, queson las de composición (o agregación) y las de herencia (o especialización).Las dem ás relaciones se deno m inan genér icam ente relaciones de asociación.En el modelo E-R todas las relaciones se consideran relaciones deasociación. En las explicaciones siguientes se atiende sólo a relacionesbinar ias , entre parejas de ent idades.

La manera de almacenar en tablas la información de las relaciones deasociación depende de la cardinalidad de la relación. La técnica general es

traducir la relación a una tabla conteniendo referencias a las tablas de lasentidades relacionadas, así como los atr ibutos de la relación, si los hay. Estoes vál ido para relaciones con cualquier cardinal idad, incluyendo N-N. Lareferencia a las ent idades relacionadas se hará mediante la clave pr imar iade cada una. La f igura 4.20 (a) recoge esta idea.

Si la cardinalidad es 1-N, es decir , la cardinalidad de un lado de la relaciónestá limitada a 1, es posible incluir los datos de la relación en la mismatabla de una de las entidades relacionadas, tal como se indica en la f igura4.20 (b).

Si la relación es 1-1, es decir , la cardi nalid ad está limita da a 1 en ca da lado,se pueden fundir las tablas de las dos ent idades en una sola, tal como sehace en la figura 4.20 (c).

El reducir el número de tablas s implif ica en cier to modo los esquemasf ís icos de la base de datos . Por ejemplo, algunas de las columnas concódigos de referencia pueden ya no ser necesarias, tal como se indica conlíneas de puntos en la f igura. Esta simplif icación se hace a costa de reducir ,en algunos casos , el grado de normalización.




R B

a) relación N-NTabla A Tabla R Tabla B

Ref.A Atrib.A

_Ref.A Ref.B Atrib.R Ref.B Atrib.B

¡ |

b) relación 1-NTabla A + R Tabla B

AtribA Ref.B Atrib.R

c) relación 1-1Tabla A + B + R

Atrib.B Atrib.R

Ref.B Atrib.B

•A .i

Figura 4 . 20 Tab las para relacion es de asociación

4 . 6 4 Tratamiento de las relaciones de composición

Las relaciones de composición o agregación se t ratan de la misma maneraque las relaciones de asociación. En las relaciones de composición lacardinal idad del lado del objeto compuesto es casi s iempre 1 , por lo queserán de aplicación las simplif icaciones indicadas en la sección anterior .




4. 6.5 Tratamiento de la herencia

Cuando una clase de objetos (ent idad genérica) t iene varias subclases(ent idades específ icas) se pueden adoptar t res formas de a lmacenar entablas la información de las entidades, tal como se recoge en la figura 4.21.En el caso (a) se usa una tabla para la superclase, con los atributoscomunes , heredados por las subclases , más una tabla por cada subclase , consus atributos específicos. En el caso (b) se han repetido los atributoscomunes en las tablas de cada subclase , por lo que desaparece la tabla dela superclase. En el caso (c) se prescinde de las tablas separadas para cadasubclase , y se amplía la tabla de la superclase con todos los a t r ibutos de

cada una de las subclases , en forma de campos o columnas con valoresopcionales , segú n cuál sea la subclase del objeto a lm acen ado en cada f i la dela tabla.

4.6 .6 Diseño de índices

Los índices permiten acceder rápidamente a un dato concreto, reduciendoasí el t iempo de acceso. Pero esto es a costa de aumentar el espacionecesario de a lmacenamiento y, lo que es más importante , aumentar e lt i em po necesario para a lmacenar cada nu evo d a to y más aún p ara mo di f ica r

el valor de un at r ibuto indexado ( la modif icación equivale a suprimir e le lemento del índice y luego re inser tar lo con el nuevo valor) .

En general , s i hay que acceder a datos a t ravés de sus re laciones con otros ,será conveniente m ante ner índices sobre las c laves pr im arias y column as dereferencia de las ent idades re lacionadas . Aparte de es to, no es fáci l darcr i ter ios generales senci l los para decidir cuándo conviene o no es tableceríndices adicionales sobre campos no clave.

4 .6 .7 Ejemplo: Diseño de dat os para la ges tión de bibliotec a

La visión externa de los datos está consti tuida por los elementos "Ficha delibro" y "Ficha de lector", con los siguientes contenidos:

Ficha de libro:A uto r (es)Tí tuloEditorial, etc.M ate ria (s)Lector (si está prestado)Fecha del préstamo (si está prestado)




X a) tablas de superclasey de subclases

Ref.X Atrib.X

Relación deherencia

Ref.X Atrib.Y Ref.X Atrib.Z

b) sólo tablas de subclases

Ref.Y Atrib.X Atrib.Y Ref.Z Atrib.X Atrib.Z

c) sólo tabla de superclaseRef.X Atrib.X Atrib.Y Atrib.Z

xxxx y y y y

xxxx

_7 7 7 7

Figura 4.2 1 Tablas para relac iones de he renc ia

Ficha de lector:N o m b r eApel l idosDomicilioTeléfono

En el documento de especif icación de requis i tos correspondiente a es teejemplo, que aparece en el Tema 2, se ha planteado como modeloconceptual correspondiente a es tos datos los del d iagrama E-R que al l íaparece, con las entidades LIBRO, LECTOR y MATERIA, y las relaciones



196 Introd ucc ión a la Ingen iería de Sof twa re

PRESTADO-A y TRATA-DE. La razón para desglosar la l is ta de mater ias

de las f ichas de libro es para permitir que dicha lista de materias("thesaurus", en la terminología de los bibliotecarios) sea permanente, ytodas las mater ias es tén reseñadas aunque no haya ningún l ibro que t ratede a lguna de e l las en un momento dado .

La traducción directa de estas entidades y relaciones a tablas relaciónalestiene el inconveniente de la falta de normalización en lo referente a losautores de los libros. En la visión inicial se habla del "autor" de un libro,cuando en real idad pueden ser var ios . En este caso no se cumplir ía la I a

forma normal , ya que en el mismo campo tenemos una colección de datos

en número var iable. Para conseguir la I

a

fo rma normal se puedepromocionar el autor como ent idad independiente, y es tablecer la relaciónAUTOR-DE entre autores y libros. Esto nos lleva a rehacer el modeloconceptual según el diagrama E-R de la f igura 4.22.

Figura 4. 22 Modelo de dato s revisado

Ahora se puede hacer de forma adecuada el d iseño de los esquemas f ís icosde la base de datos relacional. Las entidades LIBRO, LECTOR, AUTOR yMATERIA se t raducen a una tabla cada una, incluyendo una columna deN° de referencia para acceso mediante las relaciones .




LIBRO LECTOR AUTO R MATERIAN°Ref N°Ref N°Ref N°RefT í tu lo No m b r e No m b r e No m b r eEditorial ... A pellid os

DomicilioTeléfono

Las relaciones TRATA-DE y AUTOR-DE son de cardinal idad N-N, y setraducen en una tabla adicional para cada una.

TRATA-DE AUTOR-DE

N°Ref. Libro N°R ef.LibroN°Ref .Mater ia N°Ref .Autor

La relación PRESTADO-A es de cardinal idad 1-N. Se puede apl icar lasimplif icación indicada en la sección 4.6.3, incluyendo esta información enla tabla de libros.

LIBRON°RefTítuloEditorial ...N°Ref.LectorFechaPrés tamo

Con esto se tiene de nuevo un esquema similar al de la visión externa dela f icha de libro, en la que aparecen anotados el lector y la fecha delpréstamo, en su caso. Estos campos de la tabla serán opcionales, y estaránvacíos si el l ibro no está prestado.

4 .7 Diserto de bases de datos de ob jeto s

A diferencia de las bases de datos que siguen el modelo relacional, en lasbases de datos or ientadas a objetos no hay todavía un conjunto es table deestructuras de información fundamentales , que se consideren pr imit ivas deeste modelo de bases de datos. En las bases de datos relaciónales sólo setrabaja con la estructura tabla. En las bases de datos de objetos hay unamayor var iedad de es tructuras disponibles , pero dis t in tas en cada caso.




En general pueden adoptarse dos enfoques en el d iseño f ís ico con estas

bases de datos . El pr imer enfoque resul ta apropiado cuando la base dedatos de objetos permite usar una gran var iedad de es tructuras . En estecaso el d iseño se puede hacer como para las es tructuras de datos enmemoria. El s is tema de gest ión de base de datos apor ta como complementola persistencia de los datos.

El segundo enfoque se apl icar ía cuando no exis te esa gran var iedad deestructuras de datos , y la base de datos de objetos resul ta análoga a unabase de datos relacional, en que se establece implícitamente una tabla porcada clase de objetos. En este caso se seguirían las recomendaciones ya

dadas para el d iseño sobre el modelo relacional . El s is tema de gest ión debase de datos aporta la existencia implícita de identif icadores de objetos,que hacen innecesar ias las columnas expl íci tas de códigos o números dereferencia.

4 .8 Ejemplos de diseños

En este apar tado se recogen los documentos completos de diseño de los dossis temas que se han ido desarrol lando a lo largo del l ibro .

4.8.1 Videojuego de las minas

El documento ADD para el v ideojuego de las minas es el s iguiente:

DOCUMENTO D E DISEÑO DEL SOFTWARE (ADD)

Proyecto: JUEG O DE LAS MINAS (Versión Simple)

Autor(es) : J .A. Cerrada y R. GómezFecha: Febrero 1999Documento: MINAS-ADD-99

CONTENIDO

1. INTRODUCCIÓN1.1 Objetivo1.2 Ámbito





1.4 Referencias

2 . PANORÁMICA DEL SISTEMA


4. DISEÑO DEL SISTEMA4.1 Metodología de diseño de alto nivel

4.2 Descomposición del sistema

5. DESCRIPCIÓN DE COMPONENTES



1. INTRODUCCIÓN

1.1 Objetivo

Se trata de realizar un videojuego denominado "Juego de las Minas" cuyas reglas y característicasgenerales se detallan en el documento de requisitos del software: MINAS-SRD-99. En líneasgenerales, en este juego se trata de descubrir dentro del tablero la situación de las minas ocultasy situadas aleatoriamente sin que ninguna de ellas explote y en el menor tiempo posible.

1.2 Ámbito

En este desarrollo se abordará una versión simple que utilizará una interfase hombre-máquina parapantalla alfanumérica y teclado. En una fase posterior, se desarrollará una versión más elaboradaque utilizará pantalla gráfica y ratón. El desarrollo de esta versión simple y la posterior deberádiferir solamente en los módulos específicos dedicados a la interfase hombre-máquina".

1.3 Definicion es, siglas y abreviaturas

Tablero: Elemento gráfico que se muestra en la pantalla del computador con forma de cuadrículay en el que se desarrolla el juego .

Casilla: Cada uno de los elementos de los que está formada la cuadrícula del tablero.

Mina: Elemento oculto en una casilla del tablero y que si se destapa provoca la finalización deljuego.

1.4 Referencias

M I N A S - S R D - 9 9 : D O C U M E N T O D E R E Q U I S I T O S D E L S O F T W A R E d e l V I D E O J U E G O D E L A S M I N A S .


Se recoge aquí un resumen de la descripción del sistema ya incluida en el documento deespecificación de requisitos MINAS-SRD-99.




2.1 Obje t ivo y funciones

El objetivo es realizar una versión simplificada del juego de las minas. En este juego se trata dedescubrir dentro del tablero la situación de las minas sin que ninguna de ellas explote y en el menort iempo posible .

Las funciones básicas serán:

• Selección del nivel de dificultad del juego (bajo, medio, alto)• Desarrollo de la partida según las reglas del juego• Elaboración y mantenimiento de la tabla de mejores resul tados• Ayudas a l jugador

2.2 Descr ipción funcional '

En el juego se emplea un tablero cuadrado de N casil las de lado, semejante al que se muestra enl a f i gura M. l .

2 2 1 2 2

5 1 i 1 1 2

i | 2 1 1 i i

4 1 1 1 33 1 1 1

1i i 2

1

1

¡ | 4 1 1 1

Figura M . l Table ro de l juego de las minas

En este tablero están ocultas un número determinado de minas que pueden estar situadas encualquier casil la. Inicialmente se muestra el tablero con todas las casil las tapadas. En el ejemplode la figura M . l, las casillas tapadas están en blanc o. El jug ado r t iene que ir destapando las casil laspara descubrir la situación de las minas. Cuando se destapa una casil la que tiene una mina, esta




mina explota y se acaba el juego infructuosamente. El objetivo del juego es encontrar la situación

de todas las minas sin que explote ninguna de ellas.

Para facilitar la búsqueda de todas las minas, el jugador podrá marcar una casilla cuando tenga lacerteza de que en ella existe una mina. En la figura M.l la marca se indica con el símbolo "!!".Esta marca impide que pueda ser destapada la casilla por error. El jugador también podrá quitarla marca de una casilla. En todo momento se mostrará en pantalla el número de minas ocultas ytodavía no marcadas.

El jugador podrá seleccionar el grado de dificultad del juego entre tres niveles: bajo, medio y alto.En cada nivel se empleará un tamaño distinto de tablero y el número de minas a descubrir tambiénserá distinto. La situación de las minas en el tablero se realizará de forma aleatoria.

Cada vez que el jugador destapa una casilla, se deberá indicar si tenía una mina, en cuyo casofinaliza el juego, o el número de minas que rodean la casilla que ha sido destapada. En la figuraM.l las casillas con el símbolo ". ." indican que el número de minas que las rodean son cero. Elnúmero de minas que pueden rodear una casilla pueden ir desde 0 hasta 8.

El juego dispondrá de un cronómetro que actualizará en pantalla cada segundo el tiempotranscurrido desde el comienzo de la última partida enjuego. Si el jugador consigue descubrir todaslas minas, el programa registrará el tiempo invertido junto con el texto que desee poner el jugadory actualizará la lista de los mejores tiempos registrados en el nivel correspondiente.


No hay conexión con otros sistemas.


4.1 Metodología de diseño de alto nivel

Se utiliza la metodología de diseño modular basado en abstracciones.

4.2 Descomp osición del sistema

La figura M.2 contiene el diagrama de estructura del sistema. En él aparecen los componentesprincipales y las relaciones de uso entre ellos, así como una serie de módulos de bajo nivel, que

constituyen una librería de soporte.Las componentes principales son las siguientes:

Abstracciones funcionales:- Minas- Ayuda

Tipos Abstractos de Datos:- Casilla

Datos Encapsulados- Tablero- Crono- Resultados




Casilla

Tablero Crono Ayuda Resultados

Pantau:.p m a > * ••• l¡llirTécíadol! Reloj Ficheros

F i g ura M .2 D i ag rama d e e s t ruc t u ra

El diagrama de estructura del sistema util iza un módulo para cada una de estas abstracciones, segúnse muest ra en la f igura M.2. El módulo pr incipal encargado del control del juego es Minas, queutil iza y coordina al resto de módulos. El dato encapsulado Tablero util iza el t ipo abstracto de datoCasi l la . Adem ás, en la f igura se muest ran var ios módulos encargados de adaptar los módulos delibrería de los distintos compiladores a las necesidades de este sistema. Estos módulos son:

Tipos Abst rac tos de Datos:- Ficheros

Datos Encapsulados:- Pantalla- Teclado- Reloj

- Azar


A continuación se describen cada uno de los módulos indicados en el diagrama de estructura delsistema.

5 .1 M ódulo : MIN AS

5.1 .1 Tipo: Programa Principal



Técnicas Generales de Diseño de Softw are 203

5.1.2 ObjetivoEfectuar el control principal del juego.

5 .1 .3 Función

Iniciar el juego y controlar la ejecución de las diferentes funciones:

• Selección del nivel de dificultad del juego (bajo, medio, alto)• Desarrollo de la partida según las reglas del juego• Elaboración y mantenimiento de la tabla de mejores resultados• Ayudas al jugad or

El flujo de control de este módulo equivale al del sistema completo, y se muestra en la figura M.3.

5 .1 .4 Subordinados : Tablero, Crono, Ayuda, Resultados, Pantalla, Teclado

5.1.5 Dependencias : Ninguna

5.1 .6 Interfases: Ninguna

5.1.7 Recursos : Ninguno

5.1 .8 Referencias: Ninguna




5.1 .9 Proceso : De acuerdo con el diagrama de la figura M.3 será:

Inicializar juego por defectoREPETIR

Leer opción sin esperaSI Inicio Juego ENTONCES

CASO opciónSI-ES Ayuda HACER Mostrar ayudaSI-ES Cambio dificultad HACER Cambiar dificultadSI-ES Borra resultados HACER Borrar MejoresSI-ES Muestra resultados HACER Mostrar MejoresSI-ES I a jugada HACER

Pasar al estado: En JuegoRealizar jugada

FIN-CASOS I N O

Actualizar cronómetroCASO opción

SI-ES Ayuda HACER Mostrar ayudaSI-ES Cambio dif icultad HACER

Cambiar dificultadPasar al estado: Inicio Juego

SI-ES Jugada HACERRealizar jugadaSI Fin de Juego & Mejor resultado ENTONCES Grabar mejor FIN-SISI Fin de Juego ENTONCES Pasar al estado: Inicio Juego FIN-SI

FIN-CASOFIN-SI

HASTA Fin de juego

5.1 .10 Datos

• Ultima opción• Nivel de dificu ltad• Estado del juego

5.2 Módulo: TABLERO

5.2 .1 Tipo: Dato encapsulado

5.2 .2 Objetivo

Este módulo realiza todas las operaciones básicas para manejar el tablero del juego.

5 .2 .3 Función

La función de este módulo es encapsular todas las operaciones posibles que se pueden realizarel tablero en las distintas fases del juego. Las operaciones previstas son las siguientes:

• Iniciar el tablero• Poner las minas aleatoriamente

• Mover el cursor a otra casilla



Técnicas Generales de Diseño de Softwa re 205

• Marcar o desm arcar la casilla apuntada por el cursor• Destapar casillas a partir de la apuntada por el cursor• Pintar el tablero

5 .2 .4 Subordinados : Casilla, Azar, Pantalla

5 .2 .5 Dependencias: Minas

5.2 .6 Internases-, Para cada operación:

Operación: Iniciar tableroEntrada: Nivel de dificultadSalida:

Operación: Poner minasEntrada:Salida:

Operación: Mover cursorEntrada: Incremento de posición X, Incremento de posición YSalida:

Operación: Marcar o desmarcar casillaEntrada:Salida:

Operación: Destapar casillasEntrada:

Salida: SI/NO fin del juego, SI/NO objetivo alcanzadoOperación: Pintar tablero

Entrada:Salida: Presentación en pantalla del tablero

5.2.7 Recursos: Ninguno


5.2 .9 Proceso : Para cada operación:

Operación: Iniciar tableroProceso:

Inicializar tamaño tablero y total casillas según nivelInicializar número de minas y marcas según nivelIniciar cursorIniciar casillas

Operación: Poner minasProceso:

REPETIRElegir casilla aleatoriamentePoner mina en la casillaIncrementar el n° de minas que rodean a las casillas vecinas

HAST A Total de minas




Operación: Mover cursor

Proceso:Comprobar límites del tableroSituar el cursor en la nueva posiciónPintar casilla con nueva posición del cursor

Operación: Marcar o desmarcar casillaProceso:

Cambiar marca de casillaPintar casilla con/sin marcaActualizar n° de casillas marcadas

Operación: Destapar casillasProceso:

Destapar y pintar casillaSI no hay mina & vecinas = 0 ENTONCES

Destapar y pintar recursivamente las casillas próximas con vecinas = 0FIN-SIActualizar n° de casillas tapadasDevolver resultado

Operación: Pintar tableroProceso:

Pintar dibujo base del tableroREPETIR

Pintar casillaHAST A Total casillas

5 .2 .10 Dalos

Los atributos del tablero son los siguientes:

• Núm ero de minas• Lado del tablero• Núm ero de casillas marcadas• Núm ero de casillas tapadas• Posición del cursor

Datos de las CASILLAS

5.3 Módulo: CASILL A

5.3.1 Tipo\ Tipo abstracto de datos

5.3.2 Objetivo

Este módulo define el tipo abstracto de datos para una casilla del tablero.

5 .3 .3 Función

Este módulo encapsula todas las operaciones posibles que se pueden realizar con cualquier casilladel tablero y define la estructura de datos asociada a una casilla. Las operaciones previstas seránlas siguientes:




• Iniciar

• Camb iar marca• Poner mina• Incrementar vecinas• Destapar• Pintar

5 .3 .4 Subordinados: Pantalla

5 .3 .5 Dependencias : Tablero

5 .3 .6 Internases: Para cada operación:

Operación: IniciarEntrada:Salida:

Operación: Cambiar marcaEntrada:Salida: Variación de marca: Puesta, Quitada, Imposible por destapada

Operación: Poner minaEntrada:Salida:

Operación: Incrementar vecinasEntrada:Salida:

Operación: DestaparEntrada:Salida: SI/NO destapada, SI/NO mina, Número de vecinas

Operación: PintarEntrada:Salida: Presenta ción en pantalla de la casilla

5 .3 .7 Recursos: Ninguno


5.3 .9 Proceso: Para cada operación:Operación: IniciarProceso:

Poner casilla sin minaPoner casilla sin marcaPoner casilla no destapadaPoner número de vecinas a cero

Operación: Cambiar marcaProceso:

SI no destapada ENT ON CES cambiar marca FIN-SIDevolver variación de marca



208 Introducción a la Ingeniería de Softw are

Operación: Poner mina

Proceso:Poner casilla con mina

Operación: Incrementar vecinasProceso:

Incrementar en uno el número de vecinas

Operación: DestaparProceso:

SI no marcada & no destapada EN TO NC ES destapar FIN-SIDevolver resultados

Operación: PintarProceso:

Pintar casilla

5 .3 .10 Datos

Los atributos de una casilla son los siguientes:

• SI/NO con mina• SI/NO destapada• SI/NO marcada• Núm ero de vecinas

5.4 Módulo: CRONO


5.4 .2 Objetivo

Este módulo es el encargado de proporcionar todas las operaciones necesarias para manejar elcronómetro del juego.

5 .4 .3 Función

Este módulo encapsula todas las operaciones que se pueden realizar con el cronómetro en lasdistintas fases del juego. Las operaciones previstas son las siguientes:

• Iniciar• Parar• Actualizar

5 .4 .4 Subordinados: Pantalla, Reloj


5.4 .6 Inte/fases: Para cada operación:

Operación: IniciarEntrada:Salida:




Operación: PararEntrada:Salida: Valor final del cronómetro

Operación: ActualizarEntrada:Salida:



5.4 .9 Proceso: Para cada operación:

Operación: IniciarProceso:

Poner segundos a cero

Operación: PararProceso:

Devolver segundosPoner segundos a cero

Operación: ActualizarProceso:

Leer reloj del computadorSI Tiempo transcurr ido = 1 segundo ENT ON CES

Incrementar segundosActualizar segundos en pantalla

FIN-SI

5 .4 .10 Datos

Los atributos del cronómetro son los siguientes:

• Segundos

5.5 Módulo: AYUDA

5.5.1 Tipo: Abstracción funcional (procedimiento)

5 .5 .2 Objetivo

Este módulo es el encargado de proporcionar la información de ayuda al jugador.

5 .5 .3 Función

La función de este módulo es presentar en pantalla la información de ayuda al jugador.

5 .5 .4 Subordinados: Pantalla





5.5 .6 InterfasesOperación: Presentar ayuda

Entrada:Salida: Presenta en pantalla texto de ayuda

5.5 .7 Recursos: Ninguno


5.5 .9 Proceso

Operación: Presentar ayudaProceso:

Presentar en pantalla el texto de ayuda

5.5 .10 Datos

Texto a presentar, codificado en la propia función.

5 .6 Módulo: RESULTADOS


5.6 .2 Objetivo

Este módulo es el encargado de gestionar la tabla de los mejores resultados obtenidos por losdistintos jugadores.

5 .6 .3 Función

Las operaciones sobre la tabla de resultados son las siguientes:

• Borrar resultados de un nivel de dificultad• Com probar si hay mejo r resultado en un nivel de dificultad• Grabar resultado en un nivel de dificultad• Presentar mejores resultados de un nivel de dificultad

5.6.4 Subordinados: Pantalla, Fichero

5.6 .5 Dependencias: Minas

5.6 .6 Interfases: Por cada operación:

Operación: BorrarEntrada: Nivel de dificultadSalida:

Operación: ComprobarEntrada: Nivel de dificultad, SegundosSalida: SI/NO mejor resultado, posición ocupada




Operación: GrabarEntrada: Texto a grabar, posicion ocupadaSalida:

Operación: PresentarEntrada: Nivel de dificultadSalida: Presentación en pantalla de mejores resultados del nivel

5 .6 .7 Recursos:

Un fichero en disco para almacenar la tabla de resultados.

5 .6 .8 Referencias: Ninguna

5.6 .9 Proceso: Por cada operación:

Operación: BorrarProceso:

Inicializar tabla de resultadosGrabar en el fichero en disco

Operación: ComprobarProceso:

Buscar el orden que ocupa el resultado

Devolver SI/NO es mejor y la posición que debe ocupar el resultadoOperación: GrabarProceso:

Desplazar los resultados peoresCopiar el texto a grabar en la posiciónGrabar en el fichero en disco

Operación: PresentarProceso:

Presentar en pantalla la tabla de mejores resultados del nivel de dificultad

5.6 .10 Daos

Tabla con los registros ordenados por nivel de dificultad y segundos invertidos en orden creciente.Cada registro deberá tener:

• Nivel de dificultad• Resultado en segundos invertidos• Texto grabado por el jugad or (Nom bre, etc.)

5 .7 Módulo: PANTALLA

5.7.1 Tipo: Dato encapsulado




5.7 .2 Objetivo

Este módulo es el encargado de proporcionar todas las operaciones necesarias para el manejo dela pantalla e independizar al resto del sistema de un compilador o sistema operativo concretos.

5 .7 .3 Función

Este módulo en capsula todas las operaciones que se pueden necesitar de la pantalla. Las op eracionesprevistas son las siguientes:

• Limpiar• Situar cursor• Cambio video inverso/normal• Salto de línea• Escribir ristra de texto

• Escribir núm ero entero• Escribir carácter

5 .7 .4 Subordinados: Módulos predefinidos del compilador

5 .7 .5 Dependencias : Minas, Tablero, Casilla, Crono, Ayuda, Resultados

5 .7 .6 Internases: Por cada operación:

Operación: LimpiarEntrada:Salida: Limpiar la pantalla por completo

Operación: Situar cursorEntrada: Posición del cursorSalida: Presentar el cursor en la posición indicada de la pantalla

Operación: Cambiar vídeoEntrada: Normal/InversoSalida: Cambiar el vídeo de la posición en la que está el cursor

Operación: Salto de líneaEntrada:Salida: Salta el cursor a la primera posición de la siguiente línea

Operación: Escribir ristraEntrada: Ristra de texto a escribir

Salida: Presenta en pantalla el texto a partir de la posición del cursor

Operación: Escribir enteroEntrada: Entero a escribir, número de espacios de formatoSalida: Presenta en pantalla el entero en los espacios indicados a partir del cursor

Operación: Escribir carácterEntrada: Carácter a escribir

Salida: Presenta en pantalla el carácter en la posición del cursor

5 .8 Módulo: TECL ADO





5.8 .2 ObjetivoEste módulo es el encargado de proporcionar todas las operaciones necesarias para el manejo delteclado e independizar al resto del sistema de un compilador o sistema operativo concretos.

5 .8 .3 Función

Este módulo encapsula todas las operaciones que se pueden necesitar del teclado. Las operacionesprevistas son las siguientes:

• Leer tecla con espera• Leer tecla sin espera• Leer ristra con espera

5 .8 .4Subordinados:

Módulos predefinidos del compilador


5.8 .6 Interfases: Por cada operación:

Operación: Leer tecla con esperaEntrada:Salida: Carácter ASCII de la tecla pulsada

Operación: Leer tecla sin esperaEntrada: Carácter ASCII testigoSalida: Carácter A SCII testigo o de la tecla pulsada

Operación: Leer ristra con esperaEntrada:Salida: Ristra leida

5.9 Módulo: RELOJ


5.9 .2 Objetivo

Este módulo es el encargado de proporcionar todas las operaciones necesarias para el manejo delreloj e independizar al resto del sistema de un compilador o sistema operativo concretos.

5 .9 .3 FunciónEste módulo encapsula la operación de lectura de reloj siguiente:

• Leer segundos

5.9 .4 Subordinados: Módulos predefinidos del compilador

5 .9 .5 Dependencias: Crono

5.9 .6 Inte/fases: Por cada operación:

Operación: Leer segundosEntrada:

Salida: Segundos leidos en el reloj del computador




5.10 Módulo: AZAR

5.10.1 Tipo: Dato encapsulado

5.10 .2 Objetivo

Este módulo es el encargado de proporcionar todas las operaciones necesarias para generarnúmeros aleatorios e independizar al resto del sistema de un compilador o sistema operativoconcretos.

5 .10 .3 Función

Este módulo encapsula las operaciones para generar números aleatorios siguientes:

• Iniciar semilla

• Obtener un nuevo núme ro

5.10 .4 Subordinados: Módulos predefinidos del compilador

5 .10 .5 Dependencias: Tablero

5 .10 .6 Interfases: Por cada operación:

Operación: Iniciar semillaEntrada:Salida:

Operación: Obtener un nuevo número

Entrada: Rango de validez del númeroSalida: Nuevo número

5.10 .7 Datos

El atributo es el siguiente:

• Núm ero anterior

5.11 Módulo: FICHERO

5.11.1 Tipo: Tipo abstracto de datos

5 .11 .2 ObjetivoEste módulo es el encargado de proporcionar todas las operaciones necesarias para el manejo deficheros e independizar al resto del sistema de un compilador o sistema operativo concretos.

5 .11 .3 Función

Este módulo encapsula todas las operaciones que se pueden necesitar para el manejo de ficheros.Las operaciones previstas son las siguientes:

• Abrir• Cerrar• Leer tabla de resultados




• Escribir tabla de resultados

5.11.4 Subordinados: Módulos predefinidos del compilador

5.11.5 Dependencias: Resultados

5 .11 .6 Interfases: Por cada operación:

Operación: AbrirEntrada: Nombre del ficheroSalida: Identificador interno del fichero

Operación: CerrarEntrada: Identificador interno del fichero

Salida:

Operación: Leer tabla de resultadosEntrada: Identificador interno del ficheroSalida: Tabla de resultados

Operación: Escribir tabla de resultadosEntrada: Identificador interno del fichero, tabla de resultadosSalida:


El programa puede ejecutarse en una máquina tipo PC de gama baja. La configuración mínima

estimada es:

• Procesad or: 80486• Memo ria RAM : 512 Kb• Pantalla: Mod o texto de 25 x 80 caracteres, mono cromo o color• Disquete o disco duro: 360 Kb


Se recoge en la figura M.4. En ella se pueden observar requisitos no ligados a ningún componente.Son de dos clases. Los marcados con asterisco (*) son requisitos que no se cumplen. Los demásson requisitos no funcionales que se satisfacen con otros elementos del sistema distintos de losmódulos establecidos en el diseño.




MÓDULOSM I N A S

1 T A B L E R O

1 1 C R O N O

1 1 | A Y U D A

1 1 1 1 R E S U L T A D O S

1 1 1 1 | CASI L L A

REQUISITOS 1 1 1 1 1 1

R . l . l X X X X X X

R . 1 . 1 . 1 X - - -

R . l . l . 2 X X X -

R . l . l . 3 - - X -

R . l . l . 4 X - - X

R . l . l . 5 - X - -

R . l . l . 6 - - - X

R . l . l . 7 - X - -

R . l . l . 8 - - - X

R . l . l . 9 - - - X

R . l . l . 1 0 X - X -

R . 1 . 2 - - X X

R . 1 . 3 X - -

R. 1.4 X - - X

R . 1 . 5 X - - -

R. 1.6 - - - X

R . 1 . 7 X - - -

R . 1 . 8 - X - -

* R.1 .9 - - -

R. 1.10 X - X -

R.2 .1 - - X -

R . 2 . 2 X - -

R . 2 . 3 - X - -

R . 3 . 1 - - - -

R . 4 . 1 - X - -

R . 4 . 2 X - - -

R . 4 . 3 X - - -

R . 4 . 4 X - - -

R . 4 . 5 X - - -

R . 5 . 1 - - - -

* R.6 .1 - - - -

R . 8 . 1 - - X -

* R.9 .1 - - -

NOTA: Los requisi tos marcados con (*) no se cumplen

F i g u r a M . 4 . M a t r i z REQUISITOS-COMPONENTES



Técnicas Gene rales de Diseño de Software 217

4.8 .2 Ejemplo: Siste m a de gest ión de bibl ioteca

En es ta sección se presenta e l documento de diseño de arqui tectura (ADD)del s is tema de ges t ión de bibl ioteca usado anter iormente como ejemplo, ycuyo documento de especif icación de requis i tos (SRD) se presentó en e lTema 2.

DOCUMENTO DE DISEÑO DEL SOFTWARE (ADD)

Proyecto: SISTEMA DE GESTIÓN DE BIBLIOTECAAutor(es): M. Collado y J.F . EstivarizFecha: Noviem bre 1999Documento: BIBLIO-ADD-99

CONTENIDO

1. INTRODUCCIÓN1.1 Objetivo

1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias

2 . PANORÁMICA DEL SISTEMA


4. DISEÑO DEL SISTEMA4.1 Metodología de diseño de alto nivel4.2 Descomposición del sistema







1. INTRODUCCIÓN1.1 Objet ivo

El objetivo del sistema es facilitar la gestión de una biblioteca mediana o pequeña, en lo referentea la atención directa a los usuarios. Esto incluye, fundamentalmente, el préstamo de libros, asícomo la consul ta bibl iográfica.

1.2 Ámbito

El sistema a desarrollar consistirá en un único programa que realizará todas las funcionesnecesarias. En particular, deberá facilitar las siguientes:

• Gestión del présta mo y devolu ción de libros

• Consu lta bibliog ráfica por título, autor o materiaEl sistema no ha de soportar, sin embargo, la gestión económica de la biblioteca, ni el control deadquisición de libros, ni otras funciones no relacionadas directamente con la atención a los usuarios.

El sistema facilitará la atención al público por parte de un único bibliotecario, que podrá atendera todas las funciones .

1.3 Def inicion es, siglas y abrev iaturas

Ninguna .

1.4 Referencias

BIBLIO - SRD- 99 : DOCUMENTO DE REQUISITOS DEL SOFTWARE del SISTEMA DE GESTIÓN DE

B I B L I O T E C A .


Se recoge aquí un resumen de la descripción del sistema ya incluida en el documento deespecif icación de requis i tos BIBLIO-SRD-992.1 Objet ivo y funciones

La biblioteca dispone de una colección de libros a disposición del público. Cualquier persona puedeconsultar los libros en la sala de lectura, sin necesidad de realizar ningún registro de esta actividad.

Los libros pueden ser también sacados en préstamo por un plazo limitado, fijado por la

organización de la biblioteca, y siempre el mismo. En este caso es necesario mantener anotados loslibros prestados y qué lector los tiene en su poder. Para que un lector pueda sacar un libro enpréstamo debe disponer previamente de una ficha de lector con sus datos, y en particular conindicación de su teléfono, para facilitar la reclamación del libro en caso de demora en sudevolución.

Un lector puede tener a la vez varios libros en préstamo, hasta un máximo fijado por laorganización de la biblioteca, igual para todos los usuarios.

Los usuarios deben disponer de algunas facilidades para localizar el libro que desean, tanto si espara consultarlos en la sala como si es para sacarlos en préstamo. Se considera razonable poderlocalizar un libro por su autor, su título (o parte de él) o por la materia de que trata. Para labúsqueda por materias, existirá una lista de materias establecida por el bibliotecario. Cada libropodrá tratar de una o varias materias.



Técnicas Generales de Diseño de Softwa re 219

El objetivo del sistema es facilitar las funciones más directamente relacionadas con la atencióndirecta a los usuarios de la biblioteca. Las funciones principales serán:

• Anotar los préstamos y devoluciones• Indicar los préstamos que hayan sobrepasado el plazo establecido• Búsquedas por autor, título o materia

Como complemento serán necesarias otras funciones, en concreto:

• Mantener un registro de los libros• Mantener un registro de los usuarios (lectores)

2.2 Descripción funcional

El sistema de gestión de biblioteca será operado po r una sola perso na, que dispondrá de un terminal

con pantalla y teclado. También existirá una impresora por la que podrán obtenerse listados y fichasde los libros y de los lectores.

La operación del sistema se hará mediante un sistema de menús para seleccionar la operacióndeseada, y con formularios en pantalla para la entrada y presentación de datos. Las funciones arealizar se pueden organizar en varios grupos principales, que se describen a continuación.

2.2 .1 Gestión de libros

Estas funciones permiten mantener actualizado el registro (fichero) de libros existentes en labiblioteca. Las funciones de gestión de libros son las siguientes:

Función 1.1 Alta de libro: registra un nuevo libroFunción 1.2 Baja de libro: marca un libro como dado de baja

Función 1.3 Anular baja de libro: suprime la marca de bajaFunción 1.4 Actualizar libro: modifica los datos del libroFunc ión 1.5 Listar libros: lista todos los libros registra dosFunción 1.6 Com pactar registro de libros: elimina los libros dados de bajaFunción 1.7 Actualizar lista de materias: actualiza la lista de materias consideradas

2.2 .2 Gestión de lectores

Estas funciones permiten mantener actualizado el registro (fichero) de usuarios (lectores). Lasfunciones de gestión de lectores son las siguientes:

Función 2.1 Alta de lector: registra un nuevo usuario (lector)Función 2.2 Baja de lector: marca un lector como dado de bajaFunción 2.3 Anular baja de lector: suprime la marca de baja

Función 2.4 Actualizar lector: modifica los datos del lectorFunción 2.5 Listar lectores: lista todos los lectores registradosFunción 2.6 Com pactar registro de lectores: elimina los lectores dados de bajaFunción 2.7 Buscar lector: localiza un lector por nomb re o apellido

2.2 .3 Gestión de préstamos

Estas funciones permiten tener anotados los libros en préstamo, y conocer en un momento dado losque han sido retenidos más tiempo del permitido. Las funciones de gestión de préstamos son lassiguientes:

Función 3.1 Anotar préstamo: anota los datos del préstamoFunción 3.2 Anotar devolución: elimina los datos del préstamo




Fun ción 3.3 Lista de moros os: l ista todos los préstam os no devueltos en el plazo fi jadoFun ción 3.4 Préstam os de lector: l ista los l ibros que tiene en préstamo un lector dado

2 .2 .4 Búsquedas

Estas funciones permiten local izar l ibros por autor , t í tulo o mater ia . Las fu nciones de búsqueda sonlas siguientes:

Fun ción 4.1 Buscar por autor: localiza los l ibros de un autor dad oFun ción 4.2 Buscar por t í tulo: localiza los l ibros cuyo tí tulo contiene un texto dadoFun ción 4.3 Buscar por mater ia: localiza los l ibros que tratan de una materia dad a

2.3 Mo delo de datos

El modelo conceptual se describe en el diagrama Entidad-Relación, revisado, que aparece en laF i g u r a B . l .

F i g u r a B . l . M ode l o de da tos ENTIDAD-RELACIÓN

Este modelo ampl ía e l descr i to en e l documento de requisi tos BIBLIO-SRD-99. Las ent idades dedatos principales y las relaciones entre ellas son las siguientes:

Entidad Libro: Contiene los datos de identificación del l ibroEnt idad Autor: Cont iene e l nombre y apel l idos del autorEntidad Lector: Contiene los datos personales del lectorEnt idad Mater ia : Cont iene e l té rmino c lave que ident i f ica la mater iaRelación Autor-de: Enlaza un l ibro con su(s) autor(es)Relación Prestado-a: Enlaza un l ibro con e l lec tor que lo ha sacado en préstamo . Cont iene

la fecha del préstamoRelación Trata-de: Enlaza un libro con la(s) materia(s) de la(s) que trata




Los esquemas f ísicos correspondientes a este modelo conceptual se descr iben en e l apar tado 5.1

Módulo: BASEDATOS.

La Ficha de Libro es una visión externa de los datos de un libro, para ser presentada en pantalla,o impresa como ficha o como líneas de detalle en un listado, y que incluye:

• Núm ero de referencia• -Título• Autor(es)• Colección• Editorial• Mater ia(s)

La Ficha de Lector es una visión externa que incluye los datos de un lector almacenados en la tabla

LECTORES, para ser presentada en panta l la o impresa como f icha o como l íneas de deta l le en unl istado.


No existe conexión con ot ros sistemas.


4.1 Metodología de diseño de a l to nivel

Se util iza la metodología de DISEÑO ESTRUCTURADO, basada en la descomposición funcional del

sistema.

4.2 Descomposic ión del sistema

La est ructura modular del sistema aparece representada en la Figura B.2. Los módulosindentificados son los siguientes:

BaseDatos

Figura B .2 . Ar qui t ec tur a de l s i s tema




• BIBLIO: ES el progra ma principal. Realiza el diálogo con el opera dor, en lo referen te a laselección de función.

• G E S T IO N L L B RO S , G E S T I O N L E C T O R E S , G E S T I O N P R E S T A M O S , B U S Q U E D A S : M ó d u l o s q u e

realizan las funciones principales del sistema.

• BASEDATOS: Mó dulo que con tiene la base de datos del sistem a.

El módulo BaseDatos está realizado físicamente por el SGBD comercial que se utiliza.


5.1 Módulo: BASEDATOS

5 .1 .1 Tipo: Base de datos relacional

5 .1 .2 Objetivo: Este módulo contiene la base de datos relacional que almacena la informaciónpersistente del sistema.

5 .1 .3 Función

Almacenar los datos que se indican.

5 .1 .4 Subordinados: Ninguno

5 . 1 . 5 Dependencias: G E S T I O N L I B R O S , G E S T I O N L E C T O R E S , G E S T I O N P R E S T A M O S , B U S Q U E D A S

5 .1 .6 Internases

El modelo físico de datos es el siguiente:

• Tabla: LIBROSCampo Tipo Long. Indice DescripciónNumRef Num . 4 Sí Número de referencia del libroTitulo Texto 60 No Título del libroColeccion Texto 20 No Colección a la que pertenece, opcional

Editorial Texto 30 No Nom bre de la editorialLector N u m . 4 Sí Número de referencia del lector quelo ha sacado en préstamo

FechaPres Fecha Sí Fecha en que se prestó

• Tab la : LECTO RESCam po Tipo Long. Indice DescripciónNumRef Num. 4 Sí Núm ero de referen cia del lectorApellidos Texto 40 No Apellidos del lectorNombre Texto 20 No Nombre del lectorDomicil io Texto 40 No Domicilio del lectorTelefono N u m . 7 N o Número de teléfono del lector




Tabla : MATERIASCampoNumRefNombre

Tabla : AUTORESCampoNumRefNombre

• Tabla: AUT OR-DECampo

LibroAutor

Tabla : TRATA-DECampoLibroMateria



5.1 .9 Proceso: Ninguno

5.1 .10 Datos (ver Interfases)

5.2 Módulo: BlBLlO

5.2 .1 Tipo: Abstracción funcional (programa principal)

5 .2 .2 Objetivo: Este es el programa principal de la aplicación

5.2 .3 FunciónEste módulo se encarga de realizar el diálogo con el usuario en lo referente a la selección de lafunción deseada en cada momento. También debe realizar las operaciones oportunas al comienzoy al final de una sesión de trabajo.

5 . 2 . 4 Subordinados: G E S T I O N L I B R O S , G E S T I O N L E C T O R E S , G E S T I O N P R E S T A M O S , B U S Q U E D A S

5.2 .5 Dependencias: Ninguna

5.2 .6 Interfases: No aplicable


TipoNum.Texto

Long.320

IndiceSíNo

DescripciónNúmero de referencia de la materiaNombre de la materia (término opalabra clave que la identifica)

TipoNum.Texto

Long.430

IndiceSíN o

DescripciónNúmero de referencia del autorNombre y apellidos del autor

Tipo

N um .N um .

Long.

44

Indice

SíNo

Descripción

Número de referencia del libroNúmero de referencia del autor

TipoN um .N um .

43

IndiceSíN o

DescripciónNúmero de referencia del libroNúmero de referencia de la materia





5.2 .9 Proceso

- Iniciar la sesión- REPETIR

- Presentar menú principal- Elegir opción- CASO opción DE

Gestión de libros:- Presentar menú de gestión de libros- Elegir opción- CAS O opción DE

Alta de libro: Realiza r altaBaja de libro: Realizar baja

FIN-CASOGestión de lectores:

Gestión de préstamos:

Búsquedas:

FIN-CASOHASTA fin de sesión

- Terminar la sesión

5 . 2 . 1 0 Datos ( v e r B A S E D A T O S )

5.3 Módulo: GESTIONLIBROS

5.3 .1 Tipo: Abstracción funcional (colección de funciones)

5 .3 .2 Objetivo: Realizar las funciones de mantenimiento del registro de libros disponibles en labiblioteca.

5 .3 .3 Función: Las funciones realizadas por este módulo son las siguientes:

Función ALTALIBRO: registra un nuevo libroEntrada:Salida:

Usa : MATERIAS

Actua l iza : LIBROS, AUTORES, AUTOR-DE, TRATA-DE

Efecto: Compone una nueva ficha de libro asignando código automáticamente y leyendolos datos del libro por pantalla (las materias se seleccionarán de entre la lista dematerias registradas). Registra la ficha en el fichero de libros, y además laimprime.

Excepciones:




Proceso: - Asignar número de referencia al nuevo libro- Editar la ficha del libro mediante un formulario en pantalla

- El autor o autores se seleccionan de la lista de autores, añadiendonuevos nombres o editando los existentes, si es necesario- La materia o materias se seleccionan de la lista de materias, pero nose pueden añadir o modificar las materias existentes

- Pedir confirmación- SI se confirma ENT ON CES

- Registrar la ficha del libro en las tablas de LIBROS, AUTOR-DE yTR A TA - D E- Imprimir la ficha del libro

SI-NO- Anular la asignación de nuevo número de referencia y lasmodificaciones en las tablas

FIN-SI

Función BAJALIBRQ: marca un libro como dado de bajaEntrada:Salida:

Usa : AUTORES, MATERIAS, AUTOR-DE, TRATA-DE

Actualiza: LIBROS

Efecto: Lee el código del libro por pantalla, y marca la ficha de ese libro en el fichero delibros como dada de baja.

Excepciones: Si no existe el libro con el código indicado, o ya estaba dado de baja , da unaviso.

Proceso:- Lee el número del libro por pantalla- Busca el libro en la tabla LIBROS- SI el libro no existe EN TO NC ES

- Da mensaje de que no existeS I N O

- Presenta la ficha del libro en pantalla- Pide confirmación de la baja- SI se confirma ENT ONC ES

- Marca el libro como borrado en la tabla LIBROSFIN-SI

FIN-SI

Función ANULARBAJALIBRQ: suprime la marca de bajaEntrada:Salida:

Usa : AUTORES, MATERIAS, AUTOR-DE, TRATA-DE




Actualiza: LIBROSEfecto: Lee el código del libro por pantalla, y anula la marca de dado de baja en la ficha

de ese libro en el fichero de libros.Excepciones: Si no existe el libro con el código indicado, o no estaba dado de baja, da un

aviso.Proceso:

- Lee el número del libro por pantalla- Busca el libro en la tabla LIBROS- SI el libro no existe o no está marcado como borrado EN TO NC ES

- Da el mensaje de aviso apropiadoSI-NO

- Presenta la ficha del libro en pantalla- Pide confirmación de la anulación de la baja

- SI se confirma ENT ON CES- Anula la marca de borrado del libro en la tabla LIBROS

FIN-SIFIN-SI

Función EDITARLIBRO: modifica los datos del libroEntrada:Salida:Usa : MATERIASActualiza: LIBROS, AUT ORE S, AU TOR -DE, TRA TA-D EEfecto: Lee el código del libro por pantalla, localiza la ficha de ese libro, y actualiza los

datos de ese libro, también por pantalla. Registra la ficha actualizada en el fichero

de libros, y la imprime.Excepciones: Si no existe el libro con el código indicado, da un aviso.

Proceso:- Lee el número de referencia del libro por pantalla- Busca el libro en la tabla LIBROS- SI el libro no existe o está marcado como borrado EN TO NC ES

- Da el mensaje de aviso apropiadoS I N O

- Editar la ficha del libro mediante un formulario en pantalla- El autor o autores se seleccionan de la lista de autores,añadiendo nuevos nombres o editando los existentes, si esnecesario- La materia o materias se seleccionan de la lista de materias,pero no se pueden añadir o modificar las materias existentes

- Pedir confirmación- SI se confirma ENT ON CES

- Registrar la ficha modificada del libro en las tablas deLIBROS, AUTOR-DE y TRATA-DE- Imprimir la ficha modificada del libro

SI-NO- Anular las modificaciones en las tablas

FIN-SIFIN-SI




Función LLSTARLLBROS: lista todos los libros registradosEntrada:Salida:Usa : LIBROS, AUTO RES, MATE RIAS, AUTO R-DE, TRATA -DEActualiza:Efecto: Imprime un listado con todos los datos de todos los libros, incluso los que estén

dados de baja, indicando si están prestados.Excepciones:Proceso:

- PARA -CADA libro registrado HAC ER- Imprimir una o varias líneas del listado, con los datos de la ficha dellibro y la indicación de si está prestado o dado de baja(el listado se hará paginando en la forma habitual)

FIN-PARA

Fu nc ión COMPACTARLIBROS : elimin a lo s lib ros d ado s de b ajaEntrada:Salida:Usa :

Actualiza: LIBROS, AUT ORE S, AU TOR -DE, TRA TA-D E

Efecto: Suprime del fichero de libros las fichas de libros que estén dados de baja,liberando el espacio que ocupaban.

Excepciones:

Proceso:- PARA -CADA libro registrado HACE R

- SI está marcado como borrado ENT ON CES- Borrar las líneas que correspondan de las tablas deA U TO R - D E y TR A TA - D E

FIN-SIFIN-PARA

- Compactar las tablas de LIBROS, AUTOR-DE y TRATA-DE- P A R A - C A D A a u to r H A C ER

- SI no queda ningún libro de ese autor EN TO NC ES- Borrar ese autor

FIN-SIFIN-PARA- Compactar la tabla de AUTORES

Función EDITARMATERIAS: actualiza la lista de materiasEntrada:Salida:

Usa : TRATA-DE

Actualiza: MATERIAS




Efecto: Se edita por pantalla la lista de materias a considerar, pudiendo añadir, suprimirmaterias, o modificar sus nombres.

Excepciones: Si se intenta suprimir una materia habiendo libros registrados que tratan deella, se pedirá confirmación especial. Si se fuerza la eliminación, se suprimirátambién la referencia a esa materia de los libros que traten de ella.

Proceso:- Editar la lista de materias en pantalla, permitiendo

- Añadir materias- Modificar el nombre de una materia- Suprimir materia:

- Si hay libros que tratan de esa materia, pedir confirmación- SI se confirma la supresión EN TO NC ES

- Borrar las entradas en TRATA-DE correspondientesa esa materia

FIN-SI

5 . 3 . 4 Subordinados: BASEDATOS

5 . 3 . 5 Dependencias: BIBLIO

5.3 .6 Iníetfases (ver Función)

5.3 .7 Recursos: Ninguno


5.3 .9 Proceso (ver Función)

5 . 3 . 1 0 Datos (ver módulo BASEDATOS)

5.4 Módulo: GESTIONLECTORES

5.5 Módulo: GESTIONPRESTAMOS




5 .6 Módu l o : BU SQ U ED A S


Esta aplicación puede ejecutarse en una máquina tipo PC de gama baja. Los recursos mínimosestimados son los siguientes:

• Procesado r: 80486• Sistema Operativo: DO S• Memoria RAM : 2 Mb• Pantalla: Mo do texto de 25 x 80 caracteres, mon ocromo o color

• Disco duro:4 Mb para el SGBD1 Mb para los programas de la aplicación4 Mb para los datos de la aplicación (10.000 libros y 10.000 lectores)


Se recoge en la Figura B.3. En ella pueden observarse requisitos no ligados a ninguna componente.Son de dos clases. Los marcados con asterisco (*) son requisitos que no se cumplen. Los demásson requisitos no funcionales que se satisfacen con otros elementos del sistema distintos de losmódulos establecidos en el diseño.




MODULOSB A S E D A T O S

| BIBLIO

1 1 G E S T I O N L I B R O S

1 1 1 G E S T I O N L E C T O R E S

1 1 1 | G E S T I O N P R E S T A M O S

1 1 1 1 B U S Q U E D A S

REQUISITOS 1 1 1 1 1 1R . L . L X -

R . 1 . 2 X - -

F . L . L - X -

F . 1 . 2 - X -

F . 1 . 3 - X -

F . 1 . 4 - X -

F . 1 . 5 - X -

F . 1 . 6 - X _F . 1 . 7 - X -

F . 2 . 1 - - X

R . 2 . 1 X _ _R . 2 . 2 - -

R . 2 . 3 - - -

R . 2 . 4 - - -

R . 4 . 1 X - -

R . 4 . 1 . 1 X -

R . 4 . 2 X -

* R . 4 . 3 - - _* R . 4 . 4 - -

R . 4 . 5 - - -

R . 4 . 6 - - -

R . 4 . 7 X X X XR . 4 . 8 X - -

R . 5 . 1 - - -

R . 6 . 1 X - -

R . 7 . 1 - - -

R . 8 . 1 - - -

* R . 8 . 2 - -

* R . 9 . 1 - - -

R . 9 . 2 X - -

R . 1 0 . 1 - -

NOTA: Los requisi tos marcados con (*) no se cumplen

Figura B . 3 . M a t r i z REQUISITOS-COMPONENTES



Tema 5Codif icación yPruebas

En este Tem a se hace un ráp ido repaso a las últ imas fases del ciclo de vida:codificación, pruebas de unidades, fase de integración y pruebas delsistema; con ellas se materializa el diseño y se obtiene el producto final decualquier desarrollo. Entre todas estas fases existe una gran interrelación.Las técnicas de prueba de unidades son imprescindibles para depurar lacodificación de cada módulo o unidad por separado. Las pruebas delsistema nos aseguran que la integración de todas las unidades se realizacorrectamente. Cuando una prueba de unidad o de s is tema no se superacorrectamente es necesario modificar la codificación y ésta posteriormentetendrá que ser probada de nuevo.

5.1 Codificación del diseño

La fase de codificación constituye el núcleo central de cualquiera de losmo delos d e desarrollo de softw are: ciclo de vida, uso de prototipos, mod eloen espiral, etc. Hasta la década de los 70, en el desarrollo de softwareprácticamente todo el trabajo se centraba en la fase de codificación.Actualmente, también sucede lo mismo al desarrollar pequeños sistemasque son realizados enteramente por una única persona en un plazo detiempo muy breve. Simplificando, se puede decir que las etapas previas de

análisis y diseño tienen com o misión fund am en tal la de organizar y traduc irlos requisitos del cliente en unidades o módulos de programa que puedanser codificados de form a indep end iente y sencilla. La impo rtancia de la fasede codificación dentro del desarrollo de software es evidente si se t iene encuenta que en ella se elabora el pro duc to fun da m en tal de todo el desarrollo:los programas fuente.

Un elemento esencial dentro de la codificación es el lenguaje deprogramación que se emplea. En los próximos apartados de este mismoTema se repasan el desarrollo histórico de los lenguajes, sus prestacionesbásicas y algunos criterios de selección. Existen cientos de lenguajes y cada




uno de ellos t iene sus propias peculiaridades lo que hace que sea másaconsejable su utilización en unos casos que en otros. Por ejemplo, COBOLestá pensado para codificar sistemas de información mientras que C, Pascalo Ada son más adecuados para sistemas de control o de cálculo. El uso deun determ inado lenguaje l imita e impone al prog ram ado r un a determ inadaforma de trabajo, pero el resultado de la codificación no debería quedarexcesivamente mediatizado por el lenguaje util izado.

El estudio de una determinada metodología de programación queda fuerade los objetivos de este libro. Sin embargo, dada la importancia que losaspectos metodológicos t ienen para lograr una codificación de buena

calidad se dedicará un ap arta do d e este Tem a al repaso de aqu ellos aspectosque inciden de una manera decisiva en la calidad. Antes de iniciar la fasede codificación es fundamental establecer por escrito cuál será lametodología de programación que se empleará por todos miembros delequipo de trabajo. Normalmente, todas las empresas de desarrollo desoftware t ienen su propia metodología de programación que ut i l izan entodos sus desarrollos. La metodología empleada tiene tanta importanciacomo el lenguaje de programación elegido.

En la fase de codificación pueden intervenir un gran número deprogramadores y durante un t iempo muy largo. Como parte de la

metodología de program ación y para garant izar la adecu ada hom ogeneidaden la codificación se deben establecer las normas y estilo de codificación.Solamente una disciplina rigurosa en el empleo de las normas establecidases capaz de asegurar una codificación de calidad. Además un esti lohom ogéneo hace posible un t rabajo coordinado e ntre los programad ores y aque el entendimiento entre todos ellos resulta mucho más fácil . Comoventaja adicional, el empleo de estas normas facili ta de forma considerableel mantenimiento posterior y la reusabilidad del software codificado.

Cuando los resultados de las pruebas no sean satisfactorios habrá que

realizar cam bios en la codificación. Amb os aspectos, codificación y prueba s,están muy relacionados. Por ejemplo, es normal que para depurar unfragmento de código se incluyan en el mismo código ciertos puntos de testque nos informen del paso del programa por dichos puntos. Estos puntosde test forman parte del mismo código a depurar y también pueden sercausa de errores. La codificación se debe estructurar para facili tar sudepuración y las modificaciones derivadas de las pruebas. Así, resultarámás sencillo y barato localizar las causas de una disfunción y la posteriormodificación del fragmento de programa afectado.



Codificac ión y Pru eba s 235

5.2 Lenguajes de programación

Los lenguajes de program ación son el medio fun dam ental que tenemos pararealizar la codificación. Aunque los lenguajes han evolucionado muchode sde los años 50, todav ía suelen estar m ás próxim os a la form a de trabajarde los com putadore s que a la forma de pensar del ser human o. A pesar detodo, resulta muy interesante conocer la evolución que se ha producido enlos lenguajes y observar cómo han mejorado sus prestaciones a lo largo delos últimos treinta años. Con los lenguajes actuales resulta más sencilloobtener un so ftwa re de calidad, fácil de m anten er y con posibilidades realesde reutil ización.

El conocimiento de las prestaciones de los lenguajes permite aprovecharmejor sus posibilidades y también salvar sus posibles deficiencias.Evidentemente no existe un único lenguaje ideal para todo y a veces esnecesario trabajar con varios lenguajes para las distintas partes de un mismodesarrollo. Por ejemplo, un lenguaje ensamblador para los controladores dedispositivos hardware (teclado, motores, válvulas, etc.), un lenguajeestructurado (Pascal, C, Ada, etc.) para los algoritmos y un lenguaje decuarta generación para la interfase hombre-máquina.

El desarrollo de los lenguajes ha sido posible gracias a la experienciaacumulada en la codificación de los más diversos proyectos de software.Cuando se logra un consenso global respecto a la necesidad de una nuevaprestación esto provoca su incorporación al lenguaje. Este es el caso dellenguaje C++ que es el resultado de incorporar la posibilidad de definir yutil izar objetos en C. Así, en los lenguajes de programación quedanreflejados los avances metodológicos que se producen para mejorar ysimplificar el desarrollo de software.

5.3 Desarrollo histórico

Aunque la historia de los computadores es relativamente reciente, soncientos y cientos los lenguajes que han sido diseñ ado s con los más diversosobjetivos. La util idad de la mayoría de ellos ha sido meramenteexperimental o de investigación. Sólo un número relativamente pequeño seutil iza o ha sido util izado en el desarrollo de software a escala industrial .El estudio detallado de tan sólo los dos o tres más representativos quedacompletamente fuera de los objetivos de este l ibro. Incluso resulta difícilrealizar una clasificación coherente en la que cada lenguaje se puedacatalogar indiscut iblemente dentro de un grupo concreto y determinado.




El estudio de la evolución histórica de los lenguajes es una buena manerade adquirir una visión panorámica de los mismos. En todo caso, dentro deesta evolución se suelen distinguir cuatro generaciones de lenguajes que sesolapan en el t iempo. Los lenguajes de las nuevas generaciones coexistencon los de las generaciones anteriores hasta que se imponen por completolos de mejores prestaciones.

5.3.1 Primera generación

Los primeros computadores eran máquinas de válvulas t remendamente

costosas y los programas que podían ejecutar eran muy pequeños. Laprogramación se hacía introduciendo directamente en su memoria el escasonúmero de instrucciones del programa en forma de códigos binarios. Pararealizar esta labor era esencial conocer la estructura interna del com putad or,tarea ésta que estaba reservada a un número reducido de personas.

Durante la década de los 50 el número de computadores disponiblesaumentó y la tarea de su programación empezó a tener entidad propia. Parasimplificar esta labor tan tediosa y disminuir las posibilidades de error secrearon los lenguajes ensambladores. Un lenguaje ensamblador consistefundamentalmente en asociar a cada instrucción del computador un

nemotécnico que recuerde cuál es su función. Estos nemotécnicosconstituyen un lenguaje algo más próximo al ser humano que el purocódigo máquina a base de unos y ceros. Los ensambladores se consideranla primera generación de lenguajes, con un nivel de abstracción muy bajo.

Actualm ente, con cada nuev o com puta dor q ue se diseña, el fabricante debeproporcionar de forma inmediata su correspondiente ensamblador. Portanto, existen tantos ensambladores como computadores distintos. Laprogramación en ensamblador resulta compleja, da lugar a errores difícilesde detectar, exige que el pro gra m ad or conozca b astante bien la arqu itectura

del computador y sobre todo se necesita adaptar la solución a lasparticularidades de cada computador concreto. Sólo está justificada lautil ización del ensamblador en aquellos casos en los que no se puedepro gra ma r con nin gún lengua je de alto nivel. Esta situación es cada día másrara y se da fundamentalmente cuando se requiere una opt imización delcódigo para aplicaciones con especificaciones muy críticas de tiempo real.En cualquier caso, sólo se programarán en ensamblador pequeñosfragmentos de programa que se podrán insertar , en forma de macros osubrutinas, dentro del programa escrito en un lenguaje de alto nivel.



Codificación y Prue bas 237

5.3.2 Segunda generación

El aumento de la capacidad de memoria y disco de los computadores hizoposible abordar programas más grandes y complejos . Cuando estosprogramas se real izaban enteramente en ensamblador resul taban muydifíciles de depurar, entender y mantener, lo que aumentaba los costes y elt iempo de desarrollo. A finales de la década de los 50 se comenzaron adesarrollar los primeros lenguajes de alto nivel. Su característica másnotable era que no depen dían de la est ructura de un co mp utador concretoy por primera vez se programaba en "alto nivel", de manera simbólica.

Esta segunda generación de lenguajes supone un paso trascendental en lacreación de herramientas para el desarrollo de software. Con ellos, seincorporan los primeros elementos realmente abstractos. Por ejemplo,aparecen tipos de datos (numéricos o de caracteres) no soportadosdirectam ente p or las instrucciones de la máqu ina. También se pu ed e igno raren parte la organización interna de la memoria del computador para pasara trabajar con variables simbólicas de distintos tamaños y estructuras(vectores o matrices) según las necesidades de cada programa. Además sedispone de las primeras estructuras de control para la definición de bucles

genéricos o la selección entre varios caminos alternativos de ejecución, etc.Todo esto hizo que estos lenguajes alcanzaran inmediatamente una ampliadifus ión y que se util izaran de fo rma ma siva. Toda vía hoy se utilizan estosmism os lenguajes o algun o de sus descendientes directos de la tercerageneración. Algunos de los lenguajes más representativos de estageneración son FORTRAN, COBOL, ALGOL y BASIC.

FORTRAN (FORmula TRANslator): Es un lenguaje que fue pensado paraprogramar fundamentalmente aplicaciones científicas o técnicas enlas que tiene una gran importancia el cálculo numérico. Con el pasode los años se han sucedido sucesivas versiones: FORTRAN-IV,

FORTRAN-66, FORTRAN-77, FORTRAN-90 que han ido corrigiendodeficiencias anteriores y se han adaptado a las nuevas propuestasmetodológicas incorporadas por otros lenguajes. Desde el punto devista metodológico, una deficiencia imp ortan te que todavía conservaFORTRAN es el manejo casi directo de la memoria mediante lasentencia COMMON.

A pesar de su origen científico, FORTRAN se ha util izado y secontinúa util izando en el desarrollo de una amplia gama deaplicaciones de todo tipo que incluyen la realización de sistemas de

gestión de bases de datos, sistemas en tiempo real, etc.




COBOL: Es el leng uaje con el que está n escritos casi tod os los sistemas pa rael procesa miento de inform ación (contabilidad, nóminas, facturación,control de almacén, etc.). Hay que tener en cuenta que este t ipo desistemas supone más del 70% de todo el software que se desarrolla.Aunque actualmente se continúa util izando COBOL para estosdesarrollos, los lenguajes de la cuarta gene ración están consiguiendodesplazarlo paulat inamente.

ALGOL: Se considera el precurso r de m ucho s de los lengua jes de la tercerageneración y especialmente de Pascal y todo s sus descendientes, talescomo Modu la-2 y Ada . Se pu ed e decir que es el prim er lenguaje que

da una gran importancia a la t ipificación de datos. También en estecaso existen diversas versiones: ALGOL -6O, ALGOL-68, aunque sudifusión a nivel industrial o comercial no ha sido tan importantecomo en el caso de FORTRAN.

BASIC: Fue pensa do p ara la enseñanza de la progra ma ción y es de destacarsu sencillez y facilidad de aprendizaje. Gracias a los escasos recursosque necesitaba un intérprete de BASIC, con la llegada de losprimeros com putadore s de sobremesa se prod ujo una rápida difusiónde este lenguaje y con él se desarrollaron las aplicaciones másdiversas. Son innum erable s las versiones qu e existen d e este lenguaje

y en algunas de ellas se incorporan herramientas de todo tipo. Porejemplo, existen versiones para trabajar con distintos t ipos de basesde datos, con entornos de ventanas (windows) o incluso paraaplicaciones de t iempo real. Estas versiones han sido desarrolladasfundamentalmente para t rabajar con los actuales computadorespersonales.

5.3.3 Terc era generación

A esta generación pertenecen gran parte de los lenguajes que se util izanactualm ente p ara el desarrollo d e softw are. A finales de los 60 y principiosde los 70 se consolidan las bases teóricas y prácticas de la programaciónestructurada. Con esta nueva metodología, la programación pierdedefinitivamente su consideración de "arte" destinado a demostrar lashabi l idades del program ador para convert irse en una tarea product iva q uese debe realizar de forma metódica y sin concesiones a la genialidad. Hayque tener en cuenta que ya entonces el número de personas queparticipaban en el desarrollo de un nuevo compilador, sistema operativo uotro t ipo de aplicación podía ser de varias decenas. Aparece así , lanecesidad d e una nueva generación d e lenguajes fuertem ente tipados, que



Codificación y Prueb as 239

facili ten la estructuración de código y datos, con redundancias entre ladeclaración y el uso de cada tipo de dato. Con ello se facilita la verificaciónen compilación de las posibles inconsistencias de un pr ogra m a. Algu nos delos lenguajes más importantes de esta generación son los siguientes:

PASCAL: Aparece en 1 9 7 1 y se puede considerar el primer lenguaje de estageneración. Aunque fue diseñado fundamentalmente para laenseñanza de la programación estructurada, su sencillez y buenasprestaciones hizo que pronto se util izara también para el desarrollode todo tipo de aplicaciones científico-técnicas o de sistemas. Pascalpermite la estructuración del código mediante procedimientos o

funcio nes que se pu ed en definir de man era recursiva. La tipificaciónde datos es bastante rígida y no se contempla en forma apropiada lacompilación separada.

MODULA-2 : ES el descendiente más directo de Pascal y con su diseño setrataban de paliar las carencias más importantes de su predecesor.Ambos lenguajes han s ido diseñados por Niklaus Wirth. Lasdeficiencias fundamentales de Pascal se deben a que no fue pensadocomo un lenguaje para el desarrollo de software a gran escala. EnModula-2 se incorpora la estructura de módulo y queda separada laespecificación del mód ulo de su realización conc reta. Esto facilita una

compilación segura y permite la ocultación de los detalles deimplem entación. C on Mo dula-2 se facili ta enorm em ente la aplicacióninmediata de los conceptos fundamentales de diseño: modularidad,abstracción y ocultación. Además, Modula-21 incorpora ciertosmecanismos básicos de concurrencia. Al contrario de lo que sucediócon Pascal, la utilización de Modula-2 para el desarrollo deaplicaciones es todavía más bien escasa.

C: Aparece en 1975 y su desarrollo es prácticamente paralelo a Pascal.Originalmente fue diseñado para la codificación del sistema

operativo UNIX. Posteriormente ha sido util izado ampliamente paradesarrollar software de sistemas y aplicaciones científico-técnicas detodo tipo. A pesar de su consideración de lenguaje de alto nivelposee ciertas características que le hacen muy flexible y capaz deoptimizar el código tanto como si se util izara un lenguajeensamblador. Por otro lado, esto mismo hace que deba ser uti l izadocon bastante cuidado. Por ejemplo, la importancia de los punterosdentro del lenguaje y su íntima relación con vectores, matrices y engeneral con el manejo casi directo de la memoria puede tenerresultados desastrosos si no se toman las debidas precauciones.También posee un conjunto de operadores muy amplio que permite




hacer cualquier cosa con cualquier t ipo de dato sin apenas ningunarestricción. Esto puede dificultar bastante la depuración de unprograma cuando se ut i l izan indiscriminadamente.

ADA: Es el lenguaje patrocinado por el Departamento de Defensa de losEEUU, principal consumidor de software del mu ndo , para imponerlocomo estándar en todos sus desarrol los de s is temas con c om putadorenglobado ("embedded computer systems") y de t iempo real. Es undescendiente de Pascal mucho más potente y complejo. Aunquedesde principios de los 80 se viene hablando de las ventajas de Adacomo lenguaje universal, todavía no está suficientemente extendido.

Esto se ha debido fundamentalmente a la dif icul tad de aprendizajede un lenguaje tan complejo y a que la puesta a punto de loscompiladores ha requerido más tiempo del previsto. Los package deAd a facilitan la codificación de u n diseño mo dula r y la aplicación delos conceptos de abstracción y ocultación. Ada perm ite la definiciónde elementos genéricos y dispone de mecanismos para laprogramación concurrente de tareas y la sincronización ycooperación entre ellas.

Dentro de esta misma generación y de forma paralela, se han idodesarrol lando lenguajes asociados a otros paradigmas de programación o

modelos abstractos de cómputo (orientación a objetos, funcional o lógico)como enfoqu es al ternat ivos a la programación imperat iva representada porPascal, C, Modula-2 y Ada. Los lenguajes que soportan estos paradigmastienen una aplicación bastante orientada hacia el campo para el cual hansido diseñados. Algunos de los más representativos son los siguientes:

SMALLTALK: Este lenguaje es el precursor de los lenguajes orientados aobjetos. Aunque las primeras versiones son de principios de los 70,los entorno s de traba jo disponibles e ran deficientes y su difu sión fuemuy limitada. Durante la década de los 80, las estaciones de trabajo

con pantallas gráficas y procesadores más potentes permitendisponer de entornos más amigables y las nuevas versiones dellenguaje alcanzan may or difusión.

C++: Es un lenguaje que inco rpora al lenguaje C los mecanism os básicos dela programación orientada a objetos: Ocultación, clases, herencia ypolimorfismo. Con este lenguaje se trata de aprovechar la ampliadifusión que tiene C y facili tar su util ización cuando se empleantécnicas de análisis y diseño orientadas a objetos.




EiFFEL: Este lenguaje de finales de los 80 supone probablemente el intento

más serio de diseño de un lenguaje completamente nu evo orientadoa objetos, tomando como estructura básica de part ida un lenguajeimperativo estructurado. Eiffel permite la definición de clasesgenéricas, herencia múltiple y polimorfismo. Aunque su difusióntodavía no es muy grande es previsible que la adquiera en un futuropróximo.

LISP: Es el precursor de los lenguajes funcionales. Las primeras versionesaparecieron junto a los lenguajes de 2a generación. Aunqueactualmente compiten con él un gran número de lenguajes

funcionales, continúa siendo uno de los más util izados enaplicaciones de inteligencia artificial y sistemas expertos. En LISPtodos los datos se organizan en forma de listas y para su manejo seemplean exclusivamente funciones, que normalmente son recursivas.LISP está pensado especialmente para la manipulación de símbolos,demostración de teoremas y resolución de problemas teóricos.

PROLOG: Este lenguaje es el repres entan te m ás imp ortan te d e los lenguajeslógicos y se util iza fundamentalmente para la construcción desistemas expertos. En el desarrollo de la propuesta de "quintageneración", el lenguaje PROLOG se tomó como un punto de

arranque. Los elementos fundamentales que util iza son: hechos yreglas; ambos constituyen la base de la representación delconocimiento. A partir de ellos se pueden inferir nuevos hechos oreglas que se incorporan a la base del conocimiento. Cuando elnúmero de hechos y reglas crece, el proceso de inferencia puederesultar tremendamente costoso y lento.

5. 3. 4 Cuarta generación

Los lenguajes de la cuarta generación (L4G) tratan de ofrecer alprogramador un mayor nivel de abstracción, prescindiendo por completodel comp utador. N orma lmente estos lenguajes no son de propósi to generaly en realidad se pueden considerar herramientas específicas para laresolución de determ inad os pro blem as en los cam pos m ás diversos. Se tratade lograr que cualquiera, sin grandes conocimientos sobre programación decomputadores, pueda util izar estos lenguajes para realizar aplicacionessencillas. Por otro lado, no es aconsejable utilizar estas herramientas paradesarrollar aplicaciones complejas debido a lo ineficiente que resulta elcódigo que g eneran. En todo caso, se pued en util izar p ara la realización de



242 Introducción a la Ingeniería de Softw arei

prototipos que posteriormente serán mejorados con lenguajes de la tercerageneración.

Desde hace diez o quince años han venido surgiendo lenguajes oherramientas 4G. Sin embargo, y sobre todo en los últimos años, la ampliadifusión de los computadores personales de altas prestaciones: potencia decálculo, pantalla gráfica, ratón, etc; han sido determinantes para sudesarrollo más amplio. Sería tremendamente prolijo hacer una relación deherramientas (la mayoría de ellas t ienen marcas comerciales) e inclusoresulta difícil establecer una clasificación. Una posible agrupación según suaplicación concreta sería la siguiente:

BASES DE DATOS: Estos lenguajes permiten acceder y manipular lainformación de la base de datos mediante un conjunto de ordenes depetición (QUERY) relativamente sencillas. Con estas órdenes sepueden establecer condiciones para el simple acceso a determinadosdatos, se pueden agrupar datos que veri f ican una determinadarelación entre ellos, se pueden efectuar cálculos entre los datos uotras operaciones muc ho m ás sofisticadas. La ventaja fund am en tal deestos lenguajes es que dotan de una gran versatil idad a la base dedatos y permiten que pueda ser el propio usuario quien diseñe suspropios listados, informes, resúmenes, cálculos, etc., cuando los

necesite.

GENERADORES DE PROGRAMAS: Con ellos se pueden construir elementosabstractos fundamentales en un cierto campo de aplicación sindescender a los detalles concretos que se necesitan en los lenguajesde la tercera generación. La generación de los correspondientesprogramas, en algún lenguaje de la tercera generación, se realiza deacuerdo a un conjunto de reglas que se establecen a priori y quedependen del lenguaje destino. Evidentemente, el programagenerado se puede modificar o adaptar cuando la generación

autom ática no resulta c om pletam ente satisfactoria. Con la uti lizaciónde estos lenguajes siempre se produce un ahorro considerable detiempo de desarrollo. La mayoría de los generadores de programassirven para realizar aplicaciones de gestión y el lenguaje destino esCOBOL. Sin embargo, recientemente se han desarrolladoherramientas CASE para diseño orientado a objeto que se puedenutil izar para aplicaciones de sistemas y que generan programas enC, C++ o Ada.

CÁLCULO: Existe una amplia gama de herramientas de cálculo destinadasa simplificar las más diversas tareas científicas o técnicas.



Codificación y Pru eba s 243

Inicialmente estas herra mien tas fue ron simplem ente aplicaciones máso menos sofisticadas que ofrecían distintos métodos o algoritmospara resolver un problema concreto en el campo de la estadística, lainvestigación operativa, el control, etc. Sin embargo, algunas de estasherramientas ha n evolucionado de tal man era que se han convert idoen verdaderos L4G. Con ellos se puede programar prácticamentecualquier problema dentro de un determinado campo. Comoejemplos concretos se pueden citar los siguientes: hojas de cálculo;herramientas de cálculo matemático, herramientas de simulación ydiseño para control, etc.

OTROS: En este grupo se pueden englobar todo tipo de herramientas queperm itan una prog ram ación de cierta com plejidad y para ello util icenun lenguaje. Como ejemplos concretos se pueden citar lasherramientas para la especificación y verificación formal deprogramas, lenguajes de simulación, lenguajes de prototipos, etc.

5.4 Prestaciones de los lenguajes

Es m uy imp ortan te conocer las prestaciones qu e ofrecen los lenguajes en suconjunto y cada uno de ellos en particular. Esto facilita mucho la tarea deselección del más adec uad o par a un a dete rm inad a aplicación. Existen librosenteros dedicados a realizar estudios comparativos entre distintos lenguajes[Pratt84], [Sebesta89], pero esto queda fuera del alcance de este libro. Eneste apa rtad o se ag rup an las prestaciones de los lenguajes en cuatro gran desapar tados y se hace un pequeño repaso de las est ructuras más importantesdentro de cada grupo.

5.4.1 Estructuras de control

En este grupo nos referiremos al conjunto de sentencias o instrucciones delos lengua jes que se enc uad ran den tro de la parte ejecutiva de un prog ram a.Se incluyen aquí algunas estructuras específicas para el manejo deexcepciones y para la programación concurrente, además de las clásicaspara la programación est ructurada.

5.4.1.1 Programación estructurada

Actualmente cualquier lenguaje imperativo dispone de sentencias quefacili tan la programación estructurada y esto se puede considerar un




requisito mínimo para realizar cualquier desarrollo software. Para ello,siempre existen sentencias para programar:

SECUENCIA: Normalmente escribiendo una tras otra las sentenciasSELECCIÓN: Normalmente mediante una construcción if - then - elseITERACIÓN: Al menos mediante la construcción while - do

El conjunto de sentencias de los lenguajes suele ser algo más rico y sedispone de otras sentencias para la selección:

SELECCIÓN GENERAL: mediante un if - then - elsif - then ... else

SELECCIÓN POR CASOS: mediante una sentencia case - of

y para la iteración:

REPETICIÓN: mediante una sentencia repeat - untilBUCLE CON CONTADOR: mediante una sentencia for - to - doBUCLE INDEFINIDO: mediante las sentencias loop y exit

Por otro lado, par a facilitar el desarrollo p or refin am ientos sucesivos, tod oslos lenguajes permiten definir subprogramas mediante el empleo deprocedimientos o funciones. Normalmente, es tos subprogramas se pueden

definir en forma recursiva. Las ventajas respecto a la sencillez y claridadque representa el empleo de la recursividad en la resolución dedeterminados problemas es indiscutible.

5.4.1.2 Manejo de excepcion es

Durante la ejecución de un programa se pueden producir errores o sucesosinusuales que denominaremos genéricamente excepciones. Los errorespueden tener distintos orígenes: errores humanos, fallos hardware, errores

software. También pueden tratarse como excepciones situaciones noerróneas pero poco frecuentes: datos de entrada vacíos, valores fuera delrango habitual, etc.

Errores humanos: El operador puede introducir datos erróneos, aunque elprograma veri f ique la val idez de cada dato por separado cuando seintroduce. Resulta muy complejo comprobar todo un conjunto de datos deentrada si están relacionados entre sí . Por ejemplo, entre varios datos deentrada se puede obtener un resultado intermedio que es cero y seproducirá una excepción si se util iza como cociente en una división porcero.




Fallos hardware: Cualquier mal funcionamiento de un periférico (teclado,ratón, disco, coprocesador matemático, sensor, actuador, etc.) puede darcomo resultado un dato erróneo que se introduce al programa. También sepueden producir errores debidos a la capacidad limitada de los recursos:memoria, disco, coprocesador matemático, etc.

Errores software: El programa puede tener algún defecto no detectado enla fase de pruebas.

Datos de entrada vacíos: Por ejemplo, un programa para ordenar unacolección de datos, u obtener estadísticas, pue de q ue reciba oca sionalmente

una colección de datos vacía, sin ningún elemento.

Valores fuera de rango: A veces se puede invocar una operación o funciónsobre un operando o argumento no admisible, tal como una división porcero o la raíz cuadrada de un número negativo.

Si las situaciones anteriores no han sido previstas, el programa puedeabortar. Los sistemas operativos son los encargados de detectar los falloshard wa re y de evi tar que los errores huma nos o de software pued an l legara afectar al resto de los usuarios del computador o al mismo sistemaoperativo. Por ejemplo: la violación de la partición de memoria asignada a

otro programa o de las zonas de disco o memoria reservadas al propiosistema operativo. La medida correctora del sistema operativo es siempreabortar el programa para evitar males mayores. Este hecho no es admisibleen un programa que debe funcionar siempre y en cualquier circunstancia.Por ejemplo, el control de una central nuclear, los frenos ABS de un coche,una centralita telefónica, un cajero automático, etc.

Para facili tar la claridad del programa es preferible, siempre que seaposible, escribir la parte principal del código atendiendo sólo a lassituaciones normales. Esto exige algún mecanismo apropiado para desviar

automáticam ente la ejecución hacia un fragm ento de código apropiad o encaso de que ocurra alguna situación anormal. Esta transferencia de controlse contempla en lenguajes que incorporan el manejo de excepciones.

Para concretar un poco más como se realiza el manejo de las excepciones,a continuación se describe muy someramente la propuesta de Ada, que sínos permite manejar las excepciones dentro del programa. En Ada existenvarias excepciones predefinidas que son las siguientes:




CONSTRAINT_ERROR =>NUMERIC_ERROR =>PROGRAM_ERROR =>STORAGE_ERROR =>TASKING_ERROR =>

Fuera de RangoOperaciones aritméticasEjecución anó m ala de un a sentenciaFalta de memoriaFallo en tareas concurrentes

Cada una de estas excepciones agrupa varias causas distintas y se disparaautomáticamente cuando se detecta cualquier fallo o error del t ipocorresp ondien te. Por ejemplo, la excepción CONSTRAINT_ERROR se pued edisparar tanto por un valor entero que excede el máximo como por uníndice de una matriz fuera del tamaño definido.

Ada también dispone de un controlador predefinido para las excepcionespredefinidas, que se ejecuta cuando en nuestro programa no se realizaningún tratamiento específico para alguna de ellas. El tratamientopredefinido suele ser dar un mensaje de error y abortar el programa. Laprogramación de un control específico de las excepciones se hace al final decada unidad de programa o módulo con la siguiente sintaxis:

beginB L O Q U E J J N I D A D

exceptionwh en E X C E P C I O N J J N Owh en EXC EPC ION_DOS

end;

El B L 0 Q U E _ U N I D A D es la secuencia de sentencias de la unida d de progra ma .E X C E P C I O N _ X X X pueden ser cualquiera de las predefinidas u otras quepueda definir el programador. Los TRATAMIENTO_XXX se programan comosecuencias de sentencias en la forma habitual. Cuando se dispara unaexcepción al ejecutar el B L O Q U E _ U N I D A D , la ejecución continúa con el

correspondiente TRATAMIENTO. En general, este tratamiento tendrá comoobjetivo analizar, si es posible, cuál fue la causa de la excepción, registrarla situación encontrada y en todo caso recuperar el estado del sistema paraque pueda continuar su ejecución normal.

En Ada, después de la ejecución del TRATAMIENTO se abandona porcompleto la ejecución de la unidad. Por el contrario, en otros lenguajes (p.e.PL/1) se reanu da la ejecución inm ediatamen te d espués del pu nto en el quese disparó la excepción.

= > T R A T A M I E N T O J J N O ;

=> TR ATAMIENTO_DOS;




Cuando se produce la excepción en una unidad que no t iene programado

su tratamiento, la excepción se propaga a la unidad que la l lamó. Estapropagación continúa hasta alcanzar la unidad más externa y ejecutar eltratamiento predefinido si no existe ningún otro.

Ada permite la definición de nuevas causas de excepción. Este mecanismosirve para cortar una línea de ejecución brusca me nte cu and o se detecta, porejemplo, una situación de alarma que requiere un tratamiento inmediato alma rgen del habitual. Otra aplicación es ma tizar las excepciones prede finida sy adaptarlas a las necesidades de nuestro program a d ado q ue en la m ayoríade los casos las excepciones predefinidas no dan demasiada información de

la causa concreta de la excepción. A cada nueva excepción se le debe darun nombre y efectuar su declaración, que se debe hacer al comienzo de launidad con la siguiente sintaxis:

Sobre_Presion, Tabla_Llena: exception

Para indicar desde el programa que se ha producido la excepción se util izala construcción:

raise Sobre_Presión o raise Tabla_Llena

Evidentemente, el disparo de la excepción estará condicionado a lacomprobación de una determinada situación. Por ejemplo:

if Presión > Maxima_Presion then raise Sobre_Presion end if;

Como se indicó anteriormente, el tratamiento de estas excepciones seprograma igual que las predefinidas:

exceptionwh en Sobre_Presion => ....

wh en NUMERIC_ERROR => ...end

Un análisis más detallado del manejo de excepciones en Ada se puedeencontrar en cualquier manual o l ibro específico del lenguaje. En cualquiercaso, siempre que se necesite manejar excepciones se deben estudiar lasalternativas que ofrecen los distintos lenguajes para evitar trabajar a bajonivel, interceptando las acciones del sistema operativo.




5.4.1.3 Concurrencia

En el Tema 3 se hizo una peq ueñ a introdu cción al concepto de concurrenciay a algunos de los aspectos fundamentales que se deben tener en cuentapara su diseño y programación:

• Tareas que se deben ejecutar concurrentemente• Sincronización de tareas• Comunicación entre tareas• Interbloqueos (en inglés "deadlock")

Para los tres primeros aspectos se han sistematizado estructuras de controlespecíficas. Algunas de ellas ya han sido incorporadas a ciertos lenguajespar a facili tar la progr am ación concurrente. El cuarto aspecto es un problem aque no se puede sistematizar globalmente y que se debe estudiar en cadacaso particular.

Tod os los lenguajes concurrentes p erm iten d eclarar distintas tareas y definirla forma en que se ejecutarán concurrentemente. Sin embargo, existendistintas formas de abordar este aspecto:

CORRUTINAS: No existen tareas sino corrutinas. Las corrutinas t ienen una

estructura semejante a subprogramas, pero entre ellas se puedentransferir el control de ejecución en cualquier m om ento y no sólo d euna form a jerarquizada según el es tr icto orden d e l lama da/re torno .En realidad la concurrencia se limita a un avance de la ejecución detodas las corrutinas pero secuenciando ese avance por un acuerdoentre ellas. Esta propuesta es la que utiliza Modula-2.

FORK-JOIN: Una tarea puede arrancar la ejecución concurrente de otrasmediante una orden fork. La concurrencia se finaliza con un joininvocado por la misma tarea que ejecutó el fork y con el que ambas

tareas se fund en de nu evo e n una única. Es posible realizar todo s losfork-join que se deseen, implicando a cualquier número de tareas ycon cualquier nivel de anidamiento. Esta propuesta es la que seemplea en el sistema operativo UNIX y en el lenguaje PL/1.

C O B E G I N - C O E N D : Todas las tareas que se deben ejecutar concurrentementese declaran dentro de una construcción cobegin TI | T2 | .... | Tncoend. Al alcanzar el cobegin se inicia la ejecución de to da s las tareas(TI, T2,.., Tn). La finalización de la concurrencia exige que todas lastareas hayan acabado. Es posible anidar varios cobegin-coend. Estapropuesta se util iza en el lenguaje ALGOL68.




PROCESOS: Cada tarea se declara como un proceso. Todos los procesos

declarados se ejecutan concurrentemente desde el comienzo delprograma y no es posible iniciar ninguno nuevo. Esta propuesta esla uti l izada por Pascal Concurrente. En Ada se util iza esta mismapropuesta, pero además es posible lanzar dinámicamente un procesoen cualquier momento.

Para lograr la sincronización y la cooperación entre tareas, los lenguajesconcurrentes disponen de est ructuras con las que se puede n resolver ambosaspectos. Además, prácticamente cada lenguaje propone estructurasdiferentes y aunque cada una tiene sus ventajas e inconvenientes, la

ma yoría d e ellas son intercambiables, en cuanto a que pe rmiten resolver losmismos problemas con una mayor o menor dificultad. Las estructuras conuna mayor aceptación, clasificadas en dos grandes grupos, son lassiguientes:

f SemáforosVARIABLES COMPARTIDAS: i Regiones críticas condicionales

{ Monitores

í "Co mm unicating Sequential Processes" (CSP)PASO DE MENSAJES: i Llamada a procedimientos remotos

l "Rendezvous" de Ad a

El primer grupo necesita que todas las tareas se ejecuten en un mismocomputador (mult iprogramación) o en dis t intos computadores peroutil izando un a mem oria com partida (multiproceso) para que todas las tareasteng an acceso a las VARIABLES COMPARTIDAS que emplean para comunicarse.

Además, el segundo grupo se puede util izar para la sincronización ycooperación entre tareas que se ejecutan en computadores que no tienennin gu na me mo ria com ún (procesos distribuidos) y que están conectados poruna red de comunicaciones que les permite comunicarse mediante el PASO

DE MENSAJES.

Para i lustrar los problemas de sincronización y cooperación entre tareasutil izaremos los semáforos que son la primera estructura que se propuso yaen 1968 por Dijkstra. Un semáforo es un nuevo tipo abstracto de datos delque se pueden declarar variables de una forma similar a:

VAR

Sincro : semaphore := 0;

Arbitro : semaphore := 1;




El tipo semaphore sólo puede tomar valores positivos entre cero y un

valor máximo, que depende de la implementación. En la declaración sele puede dar un valor inicial. Por ejemplo, la variable Sincro se inicializa a ceroy la variable Arbitro se inicializa a uno.

El tipo abstracto semaphore tiene definidas dos únicas operaciones, P y V, querealizan, en forma indivisible, lo siguiente:

P( Sincro ): IF Sincro = 0 TH ENla tarea que ejecuta P( Sincro) se suspende y se

pone en cola

ELS E (* Sincro > 0 *)Sincro := Sincro - 1;

END

V( Sincro ): IF hay alguna tarea esperando en la cola THEN

continúa la ejecución la primera tarea de la cola

ELSE

Sincro := Sincro + 1;

END

Un semáforo se puede util izar para la sincronización entre dos

tareas. Por ejemplo, con la declaración del semáforo Sincroinicializado a 0, analizaremos el comportamiento de las siguientestareas:

PROC ESS Productor; PROC ESS Consum idor;

Inicialmente, la tarea Consumidor esperará suspendida en P(Sincro)hasta que la tarea Productor haya elaborado el primer dato y ejecuteV(Sincro) dejando Sincro con un valor igual a 1. Esto mismo sucederácon los siguientes datos si la velocidad del Productor es inferior a ladel Consumidor. Por el contrario, si la tarea Productor puede elaborarvarios datos por anticipado, con los correspondientes V(Sincro) seindicará a la tarea Consumidor que cuando ejecute P(Sincro) puedecontinuar su ejecución puesto que Sincro es mayor que cero y hay

BEGIN

LOOP

elaborar un dato;

V(Sincro)

END

END Productor;

BEGIN

LOOP

P(Sincro);

utilizar el dato

END

END Consumidor;




datos ya elaborados para consumir. De esta manera se logra la

sincronización entre ambas tareas.

El semáforo también se puede util izar para programar la cooperaciónentre tareas. Por ejemplo, con la declaración del sem áforo Arbitroinicializado a 1 se pue de com partir el acceso a un rec urso comú n:disco, impresora, etc. En este caso tendríamos los siguientes procesoso tareas:

PROCE SS Uno; PROC ESS Dos ;

BEGIN BEGINLOOP LOOP

P( Arb itro ) P( Arb itro );

usar recurso usar recurso

V( Arbitro ) V( Arbitro )

END END

END Uno; END Dos;

La primera tarea que ejecute P(Arbitro) dejará Arbitro igual a 0. Esto

hace esperar a la otra tarea al ejecutar su P(Arbitro). La espera seprolongará hasta que la primera finalice la utilización del disco ola impresora y ejecute el V(Arbitro). Dependiendo del resto de t rabajode cada tarea la alternancia en la utilización del disco o de laimpresora puede ser cualquiera, pero s iempre se garant iza que hayexclusión mutua entre ellas y que la cooperación es satisfactoria.

Podemos decir que los semáforos son estructuras de bajo nivel paraprogramar la concurrencia entre tareas. Por ejemplo, si no se siguela disciplina convenida:

• Se pu ed e usa r el recurso sin realizar el P(Arbitro)Se puede bloquear el recurso si no se realiza el V(Arbitro)

• Es fácil equiv ocarse y hacer un P(Sincro) en vez deP(Arbitro)

• No se distingue un sem áforo para sincronizar de otropara cooperar

Todos estos errores son difíciles de detectar y depurar. Laspropuestas posteriores: regiones críticas, monitores, CSP, etc., evitanen gran medida todos estos problemas. Como siempre lo adecuado es




estudiar las estructuras disponibles en el lenguaje que se pretende

util izar.

5.4 .2 Estructuras de dato s

En este grupo nos referiremos a las distintas formas que emplean loslenguajes para estructurar los datos que manejan.

5.4.2.1 Datos simples

Todos los lenguajes pueden manejar datos de t ipo entero, pero hay quetener en cuenta su rango. Algunos lenguajes t ienen dos o más rangos deenteros: normal, corto, largo, etc.

Tam bién es norm al m anejar datos reales en todo s los lenguajes. En este casohay que tener en cuenta su precisión, aunque a veces se dispone de realescon precisión simple y con doble precisión. En algunos lenguajes másdedicados al cálculo científico se pueden manejar directamente datoscomplejos.

Actualmente, práct icamente todos los lenguajes y computadores manejan

los datos de t ipo carácter empleando habitualmente el código ASCII.Aunque es bastante raro emplear alguna otra tabla de código, esconven iente comprob arlo. Para ma nejar los caracteres ag rup ad os la may oríade los lenguajes disponen de dato s de t ipo ristra de caracteres ("string"). Sinembargo, no existe una forma única de organización y operación con estosdatos y es aconsejable estudiar la forma específica del lenguaje empleado.

En lenguajes como Pascal y sus descendientes, es posible definir datossimples por enumeración, de la siguiente forma:

TY PE Color = (Rojo, Am aril lo, Azul, Verde , Gris);

Cuando un lenguaje no tiene esta posibilidad, se pueden empleardirectamente los enteros y es responsabilidad del programador haceruna asociación y manipulación correctas. Con este t ipo de datos seaumenta mucho la claridad de los programas y se evitan errores. Untipo de dato enumerado del que sí disponen la mayoría de loslenguajes es el tipo lógico (verdadero, falso) o booleano.

Los datos de t ipo subrango permiten acotar el rango de un tipo dedato ordinal para crear un nuevo tipo de dato. Por ejemplo:




TYP E ColoresB asicos = [ Rojo .. Azul ];

En los lenguajes que tienen esta posibilidad resulta más sencilla ladepuración y el mantenimiento de los programas, si se dispone dedetección automática en ejecución de los valores que se salen delrango.

5.4.2.2 Datos compuestos

Las posibilidades de definir datos compuestos o estructurados en loslenguajes de programación varían de unos a otros, e incluso dependen de

la versión concreta de c om pilador o de la versión del está nda r del lenguaje.Los datos compuestos siempre se definen como combinaciones de otrostipos de datos simples y compuestos ya definidos.

Prácticamente todos los lengua jes t ienen la posibilidad d e definir y m anejarformaciones (vectores o matrices, en inglés "arrays") y solamente esnecesario familiarizarse con la sintaxis y semántica de cada uno.

La definición de datos compuestos de elementos heterogéneos (esquematupia) se realiza en la mayoría de los lenguajes mediante la estructuraregistro ("record"). Por ejemplo:

TYPE Circulo = RECOR D

CentroX, CentroY: REAL;

Radio: INTEGER;

Pintado: Color

END;

En Pascal y sus descendientes la estructura registro se usa tambiénpara definir el esquema unión como registro con campos variantes.En lenguaje C existe una construcción separada para ello.

En lenguajes como FORTRAN, en los que no existen los registros, hayque recurrir a un ARRAY o formación para agrupar varios datos enuna sola estructura.

Pascal y sus descendientes t ienen la posibilidad de definir datos detipo conjunto tomando como referencial un t ipo enumerado osubrango. Por ejemplo:

TYP E Mezcla = SET OF Color;




En lenguajes como C, que no disponen de esta posibilidad, se puederecurrir a las operaciones para manejo de bits, de bajo nivel, parausar un grupo de bytes como estructura conjunto.

El empleo de datos dinámicos está resuelto de formas muy diversas enlos distintos lenguajes. Por ejemplo, en LISP las listas manejadasdinámicamente son los datos fundamentales. En Pascal, Modula-2,C y Ada se realiza mediante punteros. En FORTRAN no existe estaposibilidad.

5.4.2.3 Constantes

En los primeros lenguajes sólo se contemplaba el empleo de constantesliterales, expre sadas directam ente por su valor n um érico o de caracteres. Enlos lenguajes modernos se pueden declarar constantes simbólicas, connombre .

En Pascal las constantes han de declararse antes que los tipos. Así, sólo esposible que las constantes puedan ser de alguno de los t ipos predefinidos:entero, real, carácter o booleano.

En Modula-2 no existe un orden obligatorio para las declaraciones. Esto

perm ite declarar también constantes de un t ipo enu me rado o conjunto. Porejemplo:

CONST

Pintura = Amaril lo;

MiColor = Mezcla {Rojo, Verde }

Sin embargo, en Modula-2 no se pueden declarar constantes de t ipoestructurado: formación o registro. Esto sí es posible en Adaut i l izando un agregado: agrupación de expresiones separadas por

comas y encerradas entre paréntesis. Por ejemplo:Tabla: constant array (0..1, 0..2) of REAL :=

( (1.0, 2.0, 3.0), (M*N, 0.0, 0.0) );

Cualquiera de las expresiones puede incluir valores simbólicos que seevaluarán una única vez en ejecución. Esto permite unainicialización dinámica de las constantes y "congelar" un valorconstante para el resto de la ejecución del programa después decalculado.



Cod ificación y Pru eba s 255

5.4 .2. 4 Comprobación de tipos

Las operaciones que se pueden realizar con los datos de un programadep end en del nivel de comprobación d e t ipos que corresponda al lenguajeutil izado. Según se propone en [Fairley85] al menos se pueden distinguirlos cinco niveles siguientes:

Nivel 0: Sin tiposNivel 1: Tipado automáticoNivel 2: Tipado débilNivel 3: Tipado semirrígido

Nivel 4: Tipado fuerteNIVEL 0 (Sin Tipos): A este nivel pertenecen los lenguajes en los que no se

pueden declarar nuevos tipos de datos y todos los datos que seutil izan deben pertenecer a sus t ipos predefinidos. Estos lenguajeshan sido pensados para realizar aplicaciones en un campo específicoy resulta muy complejo util izarlos fuera de ese campo. Según elcampo de aplicación del lenguaje, los datos predefinidos sonnuméricos: BASIC; caracteres y numéricos: COBOL; listas: LISP;formaciones multidimensionales: APL; ristras de caracteres: Snobol;etc. En todos ellos, no es necesario que el compilador realice ninguna

comprobación de t ipos. Es responsabilidad exclusiva delprogramador dis t inguir qué representa cada dato.

NIVEL 1 (Tipado automático): En este caso es el com pilador el enca rgado dedecidir cuál es el t ipo más adecuado para cada dato que util iza elprogram ador. A simismo, es también el compilador el encargado deconvertir al t ipo adecuado los operandos de una expresión cuandoestos son incompatibles entre sí o cuando lo son con el operadorutilizado en la expresión. Por ejemplo, si se utiliza un dato lógico enuna expresión aritmética se convertirá previamente a numérico conla equivalencia: 0 = verdadero y 1 = falso, o si se utiliza un datonumérico en una expresión de caracteres se convertirá a surepresentación como ristra de dígitos. Todo esto se realizaautomáticamente y aparentemente l ibera al programador decualquier com probación. Sin em bargo, si se desconocen las reglas deselección y conversión de tipos que utiliza el compilador, losresultados pueden ser una sorpresa. Un lenguaje que util iza estaforma de comprobación de t ipos es PL/1.

NIVEL 2 (Tipado débil): También en este nivel se realiza una conversiónautomática de t ipos pero solamente entre datos que poseen ciertas




similitudes. Así, no es posible la conversión automática de un valor

lógico a numérico o viceversa pero sí son factibles las conversionesentre enteros y reales. En expresiones con operandos de distintostipos (enteros, reales, etc.), las conversiones siempre se hacen haciael tipo de mayor rango o precisión (real). FORTRAN es el lenguajetípico de los que utilizan esta com probación de t ipos. El pu nto en elque la comprobación de t ipos resulta muy débil en FORTRAN es enlos subp rogra ma s. Entre declaración y util ización de un subp rogr am ano se realiza ninguna comprobación ni en el número ni en los t iposde los argumentos.

NIVEL 3 (Tipado semirrígido): El lenguaje m ás rep resentativo de este niveles Pascal. Todos los datos que se quieran usar deben ser declaradospreviamente con sus correspondientes t ipos. Son tipos incompatibleslos que se declaran por separado con nombres distintos aunquetengan la misma estructura. Nunca es posible realizar operacionesentre datos de t ipos incompatibles. Respecto a los procedimientos yfunciones, se comprueban el número de los argumentos y el t ipo decada uno de ellos para que coincida la declaración con su utilización.Sin embargo, en un tipa do sem irrígido existen alguna s vías de escapeque permiten evitar todo lo anterior. Por ejemplo, en Pascal no secomprueban los t ipos de los argumentos de aquellas funciones o

procedimientos que son pasados a su vez como argum entos d e otrosprocedimientos o funciones. Pero la vía de escape más usada en estetipo de lenguajes es la compilación separada ya que no existeningun a form a de comprobación de t ipos en tiempo de mon taje o deejecución. Por tanto, puede ser distinto lo que se declara y compilaen un módulo de lo que se compila y usa en otro módulo.

NIVEL 4 (Tipado fuerte): En este nivel no existe ninguna escapatoria posibley el pro gra ma dor está obligado a hacer explícita cualquier co nversiónde tipo qu e necesite realizar. Las comp robaciones de t ipo se realizanen compilación, carga y ejecución. Para llevar a cabo esta

comprobación tan exhaustiva de t ipos es necesario disponer, ademásdel compilador para el lenguaje, de un entorno único de desarrollode programas que englobe toda la información necesaria. Loslenguajes que tienen este nivel son Ada y Modula-2.

5.4.3 Abstracciones y obje tos

La imp ortancia del concepto de abstracción ya ha sido d iscutida en el Tema3. Desde el punto de vista del diseño se indicaban tres formasfundamentales de abstracción:



Codificación y Pru eb as 257

• Abstracciones funcion ales

• Tipos abstractos• M áquin as abstractas

Para la codificación de un diseño basado en las dos primeras formas, loslenguajes de propósito general disponen de ciertas estructuras quesimplifican bastante esta labor. Sin embargo, para la programación de unamáquina abstracta se requieren herramientas mucho más específicas (p.ej . :lenguaje 4G, simulador, etc.), lo que se escapa bastante del objetivo de esteapar tado .

5.4.3.1 Abstracciones funcionales

Las abstracciones funcionales han sido durante mucho tiempo un mediofun da m en tal para el diseño, estructuración y codificación de los program as;por ello, todos los lenguajes disponen de alguna construcción para sudefinición. Según el lenguaje, la deno minac ión p ue de variar: su bprog ram as,subrutinas, procedimientos, funciones, etc. En todos ellos se t ienen quedefinir el nombre y la interfaz de la abstracción, se tiene que codificar laoperación que realiza y finalmente se dispone de un mecanismo para lautilización de la abstracción.

Normalmente, en todos los lenguajes permanece oculta la codificación dela operación para quien hace uso de la misma. Sin embargo, dependiendode las reglas de visibilidad de cada lenguaje, en la codificación se podrá ono acceder a da tos externos. Pascal, Modula-2 y A da tienen un a visibilidadpor bloques, lo que permite consultar y modificar cualquier dato de losbloques más externos. En FORTRAN las subrutinas se deben realizar enficheros aparte y por tanto hay total opacidad desde dentro hacia fuera yal contrario. Conviene recordar que en FORTRAN para acceder a datosglobales se dispone de la sentencia COMMON.

5.4.3.2 Tipos abstrac tos de datos

Para la codificación de un tipo abstracto de datos se deben agrupar en unaentidad única el contenido o atributos de los datos de la abstracción y lasoperaciones definidas para el manejo del contenido. Además, debe existirun mecanismo de ocultación que impida el acceso al contenido por una víadistinta a las que ofrecen las operaciones definidas.

Pascal no dispone de ninguna estructura específica para agrupar datos confunciones/procedimientos y sus reglas de vis ibi l idad por bloques nopermiten lograr el nivel de ocultación adecuado. Empleando un fichero




aparte, las subrutinas de FORTRAN sí tendrían el nivel de ocultación

adecuado pero no sería fácil definir los atributos como tipo, y sólo seríaposible tener una subrutina por fichero.

Modula-2 dispone de la est ructura MODULE con la que se pueden definirde una forma agrupada el contenido y operaciones de un t ipoabstracto:

DEFINITION MO DULE Ejemplo;

TYPE Contenido;

PROCEDURE OperacionUno( . . . ) ;

PROCEDURE OperacionDos( . . . ) ;

END Ejemplo.

Además, en esta definición aparecen los únicos elementos visibles deltipo abstracto que se necesitan para poder hacer uso de él .Permanecerán ocultos todos los detalles de la codificación oimplementación del t ipo abstracto. En el caso de Modula-2, estoúltimo se hace por separado de la siguiente forma:

IMPLEMEN TATION MODULE Ejemplo;

PROCEDURE OperacionUno( . . . ) ;

END OperacionUno;

PROCEDURE OperacionDos( . . . ) ;

END OperacionDos;

BEGIN

END Ejemplo.

El lenguaje Ada dispone de la estructura package que es muysemejante al MODULE de Modula-2

5.4 .3 .3 Objetos

Como se indicó en el Tema 3, desde el punto de vista del diseño existe ungran paralelismo entre abstracciones y objetos. Sin embargo, desd e el pu nto




de vista de la programación las diferencias son algo más importantes. Los

conceptos de polimorfismo y herencia aparecen muy ligados a los objetosy para su codificación resulta necesario que los lenguajes de programacióndispongan de unas construcciones específicas.

Modula-2 no dispone de mecanismos de herencia ni polimorfismo. Así,aunque es un lenguaje perfectamente válido para codificar un diseñobasado en abstracciones, resulta muy complicado tratar de codificar undiseño orientado a objetos si entre ellos existe alguna relación declasificación, especialización o herencia.

El lenguaje Ada dispone de estructuras para la programación de ciertostipos de polimorfismo . Por un lado, se pu ede n dec larar elementos gen éricos(generic) y por otro, también es posible aplicar sobrecarga a los operadoresy las funciones. Sin embargo, no es posible realizar polimorfismo deanulación o diferido que son los más ligados al mecanismo de herencia.

Solamente con los denominados genéricamente lenguajes orientados aobjetos resulta factible la codificación de diseños orientados a objetos conherencia simple o múltiple y polimorfismo. Algunos de ellos son lossiguientes:

• Smalltalk • Ob jetive - C• Object Pascal • C++• Eiffel

Para un estudio más detallado de la programación orientada a objetos y laspecu liaridade s de cada un o de estos lengua jes se pu ed e consultar [Budd94],

5.4.4 Modularidad

Según se indicaba en el Tema 3, el concepto de modularidad está l igado a

la división del trabajo y al desarrollo en equ ipo d e un proyec to softw are. Enlos primeros lenguajes de programación las herramientas para la divisiónen partes o módulos no estaban vinculadas nunca al lenguaje ynormalmente eran las herramientas generales del s is tema operat ivo(gestores de ficheros, montadores de enlaces, cargadores, etc.), lasencargadas de facili tar este trabajo. A medida que el tamaño de losproyectos aumenta se ve más clara la importancia de disponer dentro de losmismos lenguajes de mecanismos adecuados para facili tar el trabajo enequipo. La primera cualidad que se exige es la compilación separada, quepermite preparar y compilar separadamente el código de cada módulo.




Además, en los lenguajes modernos se introducen redundancias entre la

definición y uso de cada módulo que podrán ser verificadasautomáticamente por el compilador del lenguaje. Cuando es posiblecomprobar en tiempo de compilación que el uso de un elemento esconsistente con su definición, diremos que la compilación separada essegura.

En FORTRAN se requiere un fichero diferente para cada una de lassubrutinas o módulos en los que se divide un proyecto. Cada fichero secompila por separado del resto y se obtiene otro fichero reubicable en elque sólo se conserva con seguridad el nombre de la subrutina. Cuando seunen todos los ficheros reubicables la única comprobación posible es si

están disponibles o no todas las subrutinas util izadas. Evidentemente, estacompilación no es segura puesto que no es posible verificar si coinciden elnúmero de argumentos de la subrutina en su definición y en su util ización,ni por supuesto el t ipo de cada uno de ellos.

Pascal fue diseñado para la realización de programas monolít icos y no estácontemplada totalmente en la definición estándar del lenguaje unacompilación separada por partes. Hay que tener en cuenta que Pascal teníacomo objetivo la enseñanza de la programación y no el desarrollo demedianos o grandes proyectos. No obstante, la amplia difusión alcanzada

por Pascal ha l levado a que en sus compiladores actuales se pueda realizaruna compilación separada empleando para ello las "unidades" o "módulos".Sin embargo, esta compilación tampoco es segura por las mismas razonesque no lo es en FORTRAN. Precisamente esta es una vía de escape queexiste en Pascal para evitar un tipado fuerte.

Para conseguir que una compilación separada sea segura se debe comprobarque la definición de unos elem entos en un mó dulo es consistente con el usoque se hace de ellos desde otro módulo. Una forma de conseguir esto esseparar de manera lógica la definición de los elementos, o interfaz delmó dulo, de la codificación de dichos elementos. La interfaz del mód ulo será

lo único visible para el resto de los módulos y en la compilación de estosúltimos se podrá comprobar que el uso coincide con la definición dada,permaneciendo oculto cómo ha sido o será finalmente codificado. Por otrolado, en la compilación de la codificación del módulo se comprobarátambién que concuerda con su definición.

Modula-2 debe su nombre a la importancia que tuvo el concepto demodularidad en su diseño. Como se mostró en una sección anterior, parala codificación de cada módulo es necesario definir su interfaz con unaestructura DEFINITION MODULE y su codificación mediante una




estructura IMPLEMENTATION MODULE. La compilación es segura

puesto que la definición de la interfaz se util iza tanto paracomprobar el uso por otros módulos como para comprobar lacodificación del módulo de implementación. En Ada se adopta lamisma solución y para ello se util izan las construcciones package ypackage body para l a de f i n i c ión y l a imp lemen tac ión ,respect ivamente.

En C ANSI la parte de definición (prototipos) se puede escribir en unfichero aparte. Mediante una directiva #include, ese fichero se puedecompilar formando parte de otro fichero, bien sea el deimplementación o bien otro módulo que usa esa definición. En amboscasos, el compilador comprobará la coherencia de todo el códigocomo si fuera un único fichero.

5.5 Criterios de selección del lenguaje

Después del repaso a las diferentes prestaciones que ofrecen los lenguajesno parece sencilla la selección de uno determinado para el desarrollo de unproyecto. El lenguaje de programación es probablemente uno de loselementos más importantes de cualquier desarrollo puesto que es la

herramienta de t rabajo que ut i l izarán mayor número de personas y queademás tiene una influencia decisiva en la depuración y mantenimiento dela aplicación. A priori, en la decisión deberían prevalecer los criteriostécnicos, pero existen otros factores de t ipo ope rativo qu e debe n ser tenido smuy en cuenta. Algunos de los criterios de selección que deberían seranalizados son los siguientes:

IMPOSICIÓN DEL CLIENTE: En alguno s casos es directame nte el cliente el quefija el lenguaje que se debe utilizar. Las razones para esta imposiciónpueden ser de diversa índole. Por ejemplo, el lenguaje Ada fue diseñadopara imponerlo como estándar en todos los desarrollos de sistemas concomputador empotrado o englobado (embedded computer systems) para elDepartamento de Defensa norteamericano; se trataba con ello de disminuirlos costes de desarrollo y mantenimiento que se producen cuando seutilizan cientos de lenguajes diferentes. En otras ocasiones el cliente no estan drástico y simp leme nte establece una relación reducid a de lengu ajes quese pueden usar en sus desarrollos.

TIPO DE APLICACIÓN: Aunque con las prestaciones de cualquier lenguaje deúltima generación se pueden realizar aplicaciones para los más diversoscampos, no parece muy realista pensar en un lenguaje universal que sirva




para todo. Por el contrario cada día aparecen nuevos lenguajes orientados

a un campo de aplicación concreta.

Sólo en aplicaciones de tiempo real muy crítico (robótica, aeroespaciales,etc.) o para hardware muy especial, sin compiladores de lenguajes de altonivel, estaría justificado el empleo de lenguajes ensambladores. En todocaso, la parte realizada en ensamblador debería quedar reducidaexclusivamente a lo imprescindible.

Para aplicaciones de gestión lo habitual es uti lizar COBOL, aunq ue cada díase util izan más los lenguajes de cuarta generación. En las aplicaciones delárea técnica/científica, tradicionalm ente ha sido FORTRAN el lenguaje má s

empleado, aunque tanto Pascal como C también se util izan con bastantefrecuencia. Para aplicaciones de sistemas y t iempo real se util izan bastanteC, Modula-2 y Ada. Los lenguajes Lisp y PROLOG todavía están entre losmás usados para las aplicaciones de inteligencia artificial. Finalmente, paraaplicaciones con un diseño o rientad o a objetos se pue de n utilizar C++, Eiffelo cualquier otro diseñado para este fin.

DISPONIBILIDAD Y ENTORNO: Desde luego no existen compiladores de todoslos lenguajes para tod os los com putad ores. Por tanto, como paso previo, esnecesario comprobar qué compiladores existen para el computador elegido.

Normalmente, el número de ellos será bastante reducido. Puede resultarinteresante realizar un estud io compa rativo de los com piladores disponiblesen cuanto a la memoria y t iempo de ejecución del código que generan paraun programa sencillo de prueba. En este sentido se debe tener en cuenta siel código generado se ejecuta directamente o se interpreta posteriormente.

Un factor muy importante a tener en cuenta en la selección, es el entornoque acompaña a cada compilador. El desarrollo será más sencillo cuantomás potentes sean las herramientas disponibles: editor, montador deenlaces, depurador, control de versiones, manejo de l ibrerías de programasrealizado s en ensam blado r o en otros lenguajes, etc. Por otro lado, también

se deben considerar las facilidades de manejo de estas herramientas y lo"amigable" que resulta su utilización, por ejemplo, no es lo mismo unentorno de ventanas y ratón que otro basado en menús.

EXPERIENCIA PREVIA: Au nqu e se supone qu e el equipo de t rabajo posee unabuena metodología de t rabajo y se adaptaría rápidamente a un nuevolenguaje y entorno, siempre que sea posible es más rentable aprovechar laexperiencia previa. Cuando las condiciones de trabajo no se modifican elrendimiento aumenta y se disminuyen las posibilidades de error. En lama yoría d e las em presa s de softw are están establecidos tanto el lengu aje de




program ación que ut i lizan preferentemen te como su entorno de desarrol loy en todo caso, a lo largo del t iempo, se van actualizando con nuevasversiones. Hay que tener en cuenta que la formación de todo el personal esuna inversión muy importante.

REUSABILIDAD: Este aspecto es importa nte tanto p or la posibilidad de u tilizarsoftware ya realizado como por el hecho de dejar disponibles para otrosproyectos partes del software desarrollado. Así, por un lado, es muyinteresante conocer exhaustivamente las l ibrerías disponibles y por otro,resul ta muy conveniente disponer de herramientas dentro del entorno del

lenguaje para la organización de dichas librerías en las que se facilite labúsqueda y el almacenamiento de los módulos reutil izables. Este t ipo deherramientas todavía no están muy extendidas pero es previsible que seut i l icen mucho en un futuro muy próximo.

TRANSPORTABILIDAD: L O S desarrol los se real izan para un computadorconcreto, pero a lo largo del tiempo este se queda obsoleto. Por esta y otrasrazones, es bastante habitual que se traten de trasladar las aplicaciones deunos computadores a otros. Para facili tar esta labor es muy interesante queel lenguaje util izado sea transportable. La transportabilidad está l igada aque exista un estándar del lenguaje que se pueda adoptar en todos los

compiladores. Pese a todo siempre existirán pequeños detalles que noresul tarán comp letamente compat ibles y que deberán ser modificados paraadaptarlos al nuevo computador.

U so DE VARIOS LENGUAJES: Aunque no es aconsejable mezclar varioslenguajes en un mismo proyecto, hay ocasiones en las que las distintaspartes del mismo resultan mucho más sencillas de codificar si se util izandiferentes lenguajes. En todo caso, para tomar esta decisión se debe hacerun estudio de la compatibilidad entre los compiladores y en definitiva delos pros y los contras de util izar uno o varios lenguajes.

5.6 Aspectos metodológicos

En este apartado se repasan ciertos aspectos metodológicos que puedenmejorar la codificación bajo dete rm inad os p un tos de vista: claridad, m anejode errores, eficiencia y transportab ilidad. U n estudio más pr of un do de todoslos aspectos de una buena metodología de programación queda fuera delalcance de este libro.




5.6.1 Normas y estilo de codificación

Cu an do se inicia la fase de codificación de un proyec to es fund am en tal fi jarlas normas que deberán respetar todos los programadores para que elresultado del trabajo de todo el equipo sea completamente homogéneo. Eshabitual que las empresas dedicadas al desarrollo de software tengan yaestablecidas un conjunto de no rm as que con carácter general aplican a todossus proyectos.

Casi todos los lenguajes permiten un formato libre en la escritura de sussentencias e ignoran los espacios en blanco redundantes y los comentarios.

Así, al mism o texto de un p rog ram a se le pu ed en dar distintos forma tos quepueden resultar muy significativos desde el punto de vista del lectorhumano, al t iempo que son irrelevantes desde el punto de vista delcompilador. Para la puesta a punto y sobre todo para el mantenimiento deun programa es esencial que éste resulte fácil de entender por todos, susactuales y futuros lectores, incluyendo a su propio autor. Por tanto, sedeben fijar normas concretando un esti lo de codificación. No se trata deproponer e l mejor estilo posible puesto que este sería muy difícil deestablecer y provocaría muchas discusiones estériles. Lo más importante esfijar un esti lo concreto y que todo el equipo lo adopte y lo respete.

Para fi jar un esti lo de codificación se deberán concretar al menos lossiguientes puntos:

• Formato y contenido de las cabeceras de cada módulo:- Identificación del módulo- Descripción del módulo- Autor y fecha- Revisiones y fechas

• Formato y contenido para cada tipo de comentario:- Sección- Orden- Al margen

• Util ización de encolumnado- Tabulador = N° espacios- Máximo indentado- Formato selección- Formato iteración




• Elección de nombres- Convenio para el uso de mayúsculas y minúsculas- Nombres de f icheros- Identificadores de elementos del programa

En el libro de Fu nd am en tos d e Progra ma ción [CerradaOO] se conc retan e stospuntos para configurar el esti lo de todos los programas escritos a lo largodel texto.

Además del esti lo, en las normas se deben incluir todas aquellasrestricciones o recom endacion es qu e pue da n co ntribuir a me jorar la claridaddel código y a simplificar su mantenimiento posterior. Por ejemplo, sepueden fijar las siguientes restricciones de carácter general:

El tamaño máximo de las subrut inas no debe superar P páginas.

• Las subrut inas tendrán un máximo de N argumentos .

Se deben incluir en un fichero todas las ristras de caracteres queutilice el programa. Esto facilitará la personalización y los cambios.

• Evitar el an ida m ien to excesivo de sentenc ias IF.• ... etc . ...

Con los mismos fines, también se puede limitar el empleo de algunassentencias del lenguaje. Por ejemplo, si se utiliza el lenguaje C para lacodificación, se pueden dar normas como las siguientes:

• Evitar el em pleo de goto

• No usar los ope rado res de autoasignac ión (+=, -=, *=, /= , %=,

« = , » = , & = ,

A

=, | =), ya que p ue de n res ultar con fuso s• ... etc . ...

5.6.2 Manejo de erro res

Durante la ejecución de un programa se pueden producir fallos que tienencomo origen las más diversas causas:

Introducción de datos incorrectos o inesperados




• An oma lías en el ha rdw are (p.ej.: ruid o en las comun icaciones )• Defectos en el softw are (p.ej.: erratas no de pu ra da s del program a)

Algunas de estas causas no pueden ser eliminadas completamente, por loque si se quiere evitar su efecto indeseable habrá que introducir elementoscorrectores en el código del programa. En lo que sigue consideraremos loserrores en el funcionamiento de un programa desde el punto de vis ta delsoftware, funda me ntalmen te, pero antes de anal izar la manera de organizarel código para atenuar o evitar errores, comenzaremos por definir demanera precisa los conceptos básicos a tener en cuenta:

Defecto: Errata o "gazapo" de software. Puede permanecer oculto duranteun tiempo indeterminado, si los elementos defectuosos nointervienen en la ejecución del programa. Esto depende de los datosparticulares con los que se opere en cada momento. En sistemas entiempo real, tamb ién de pe nd e del mom ento preciso en que se recibanestímulos externos.

Fallo: Es el hecho de que un elemento del programa no funcionecorrectamente, produciendo un resultado (parcial) erróneo. Si unelemento software defectuoso interviene en una ejecución particulardel programa, dará lugar normalmente a un fal lo.

Error. Se define como un e stado inadmisible de un pro gra m a al que se l legacomo consecuencia de un fallo. Típicamente consiste en la salida oalmacenamiento de resultados incorrectos.

Esta terminología no se emplea siempre con la precisión requerida. Porejemplo, en la bibliografía sobre pruebas o ensayos de programas se sueleusar el término "error" como sinónimo de "defecto".

Al codificar un programa se pueden adoptar distintas actitudes respecto al

tratam iento de los errores (o más precisamen te, de los fallos). Ana lizaremosbrevemente cada una de ellas:

NO CONSIDERAR LOS ERRORES:

Con esta actitud, la má s cómo da desd e el pu nto de vista de la codificación,se declina toda responsabilidad si se produce algún error. Para ello, seexigirá como requisito que todos los datos que se introduzcan deberán sercorrectos y que el programa no deberá tener ningún defecto. Cuando no secumpla alguno de estos requisitos, no será posible garantizar el resultadocorrecto del programa. Evidentemente, esta postura no es realista y sólo




puede ser válida para sistemas con muy baja probabilidad de fallo o muypoca trascendencia de los mismos.

PREVENCIÓN DE ERRORES:

Consiste en detectar los fallos antes de que provoquen un error. La técnicageneral de prevención se conoce como program ación a la defensiva (eninglés "defensive programming") y consiste en que cada programa osubp rogra ma esté codificado de mane ra qu e desconfíe s is temáticamente delos datos o argumentos que se le introducen, y devuelva siempre:

a.- El resultado correcto, si los datos son válidos, o bien

b.- Una indicación precisa del fallo, si los datos no son válidos

En el caso (b), además, el código del programa debe evitar operar con losdatos incorrectos de forma que el estado después de la operación seaerróneo. Si han sido considerados todos los posibles fallos, no se puedeproducir ningún error en el programa.

Conviene recordar que un error es un estado incorrecto (o resultadoincorrecto) del programa. La prevención de errores evita estos resultadosincorrectos, a base de no producir resultados en caso de fallo. De todas

maneras una ventaja principal de la programación a la defensiva es evitarla propagación de errores, facili tando así el diagnóstico de los defectos.

RECUPERACIÓN DE ERRORES:

Cu an do no se pued en detectar todo s los posibles fallos, es inevitable que enel programa se produzcan errores. En este caso se puede hacer untratamiento del error con el objetivo de restaurar el programa en un estadocorrecto y evitar que el error se propague. Este tratamiento exige dosactividades diferentes y complementarias:

1. - DETECCIÓN del error2.- R EC UP ER AC IÓN del error

Para la detección de un error hay que concretar qué situaciones seconsiderarán erróneas y realizar las comprobaciones adecuadas en ciertospu nto s estratégicos del prog ram a. Por su parte, en la recuperación se t ienenque adoptar decisiones sobre cómo corregir el estado del programa parallevarlo a una situación consistente. Estas decisiones p ue de n afectar a otraspartes del programa diferentes y alejadas de aquella en la que se producela detección del error.




Para la recuperación de errores, existen dos esquemas generales:

• Recuperación hacia adelan te• Recuperación hacia atrás

La recuperación hacia adelante trata de identificar la naturaleza o el t ipo d eerror (p.ej . : fuera de rango, sobrepresión, etc.), para posteriormente tomarlas acciones adecuadas que corrijan el estado del programa y le permitancontinuar correctamente su ejecución. Este esquema se puede programarmediante el mecanismo de excepciones que ya ha sido descrito en unapartado anterior .

La recuperación hacia atrás trata de corregir el estado del programarestaurándolo a un estado correcto anterior a la aparición del error, todoello con independencia de la naturaleza del error. Con este esquema senecesita guardar periódicamente el últ imo estado correcto del programa. Enla nueva operación se parte de ese último estado correcto para obtener otronuevo estado. Si ese nuevo estado es también correcto, la operación se dapor terminada satisfactoriamente. En caso de error, se restaura el estadoanterior y se trata de realizar la misma operación por un camino oalgoritmo diferente.

Este esquema se util iza habitualmente en los sistemas basados entransacciones. Una transacción es una operación que puede terminar conéxito, modificando el estado del sistema ("commit"), o con fallo, en cuyocaso la transacción se aborta ("abort") y se restaura el estadoinmediatamente anterior , de manera que la operación no produce ningúnefecto. Los esqu em as de transacciones se usan p ara m ante ner la consistenciaen las bases de datos (p.ej.: en las transacciones bancarias). En estos casos,lo fun da m en tal es asegu rar que el estado del prog ram a sea siem pre correctoaunque se queden pendientes de realizar ciertas operaciones.

En general, todos los programas que realizan una previsión o recuperaciónde errores se denominan genéricamente tolerantes a fallos.

5.6.3 Aspectos de eficiencia

Actualmente, la eficiencia en la codificación no es tan importante como lofue en los primeros computadores. La potencia de cálculo y la cantidad dememoria disponible en los computadores actuales permite asegurar queprácticamente nunca será necesario sacrificar la claridad en la codificación




por una mayor eficiencia. La eficiencia se puede analizar desde varios

puntos de vista:

• Eficiencia en m em oria• Eficiencia en tiem po

El bajo costo de la mem oria hace que cu and o se precisa cierto aho rro resultesuficiente con el que se puede obtener de forma automática empleando uncomp ilador que disponga de posibil idades de compresión de memoria. Porotro lado, cuando el volumen de información a manejar sea excesivamentegra nd e para la me mo ria disponible, será dura nte la fase de diseño d etalladocuando se deban estudiar las distintas alternativas y optar por el algoritmo

que optimice más la uti l ización de la memoria.

La eficiencia en tiempo adquiere su mayor importancia en la codificaciónde sistemas para t iempo real con plazos muy crít icos. En ocasiones unama yor eficiencia en tiempo se logra dism inuy end o la eficiencia en mem oria.Por ejemplo, cua ndo un cálculo es m uy co mplejo y no ha y suficiente tiemp opara l levarlo a cabo se puede adoptar como solución tabular dicho cálculoy simplemente consultarlo cada vez que se necesite.

La primera vía para conseguir un ahorro de t iempo importante es realizar

en la fase de diseño detallado un estudio exhaustivo de las posiblesal ternat ivas del problema y adoptar el algori tmo más rápido. Aunqueexisten compiladores capaces de optimizar el código que generan paraaumentar su eficiencia en tiempo, las mejoras que se pueden obtener sondifíciles de prever. Existen form as bastante simples de obtene r un a horro detiempo significativo utilizando técnicas de codificación tales como lassiguientes:

• Tabular los cálculos comp lejos segú n se men cionó anteriormen te.• Expansión en línea: Si se emp lean macros en lugar de sub rutina s se

ahorra el t iempo necesario para la transferencia de control y el paso

de argumentos.• Desp legado de bucles: En la evaluación de la condición de un bucle

se emplea un tiempo que se puede ahorrar repitiendo el código deforma sucesiva. Por ejemplo, si se repite 10 veces seguidas el códigointerno del bucle, las evaluaciones se reducen a la décima parte.

• Simplificar las exp resione s aritmé ticas y lógicas.• Sacar fue ra de los bucles todo lo que no sea necesario repetir.• Utilizar estr uc tura s de dat os de acceso rá pid o (p.ej.: vecto res en lugar

de listas con encadenamiento)




• Evitar las operacion es en coma flotante y realizarlas preferiblem enteen coma fija.

• Evitar las conversiones innecesarias de t ipos de datos.• ... etc . ...

5.6.4 Transportabilidad de software

Realizar una aplicación transportable implica un esfuerzo adicional, que enmuchos casos se rentabiliza rápidamente. La transportabilidad permite usarel mismo software en distintos computadores actuales y futuros. Por tanto,la transportabilidad no sólo es rentable a corto plazo para aprovechar el

mismo software en dis t intos computadores s ino también a medio y largoplazo para facili tar el mantenimiento/adaptación de la aplicación a lasnuevas arqui tecturas y prestaciones de los computadores .

Como factores esenciales de la transportabilidad se pueden destacar lossiguientes:

• Util ización de estándares• Aislar las peculiaridades

Un producto software desarrol lado exclusivamente sobre elementos

estándar (lenguaje, base de datos, librerías gráficas, etc.) es teóricamentetransportable sin ningún cambio, al menos entre plataformas que cuentencon el soporte apropiado de dichos estándares. La falta de estándares esuno de los problemas que dificulta la transportabilidad. En este caso, sedeben util izar lenguajes, compiladores, bases de datos y herramientas engeneral , que tengan una amplia difusión y que se puedan considerarestándares "de facto". De todos ellos, se procurarán evitar aquelloselementos no consolidados por completo y que puedan estar sujetos afuturos cambios o revisiones.

La mejor manera de aislar las peculiaridades es dest inar un móduloespecífico para cada una de ellas. El transporte se resolverá recodificandoy ada ptan do solamente estos mód ulos específ icos al nuevo com putador. Laspecul iaridades funda me ntales de los com putadores suelen estar vinculadasa los elementos siguientes:

ARQUITECTURA DEL COMPUTADOR:

La arquitectura del computador determina la longitud de palabra (8, 16, 32ó 64 bits) y de esto se derivan la representación interna de los valoresenteros y reales. Cuando no se desbordan los rangos o precisiones delcom putado r no resul ta muy com pleja la t ransportabi l idad debido a que será




el compilador el encargado de tener en cuenta todos los detalles. Aunqueafortunadamente este problema es cada día menos frecuente, la cosa secomplica cuando se l lega a desbordar la capacidad de la longitud depalabra del computador. Para resolver esto es necesario definir un nuevotipo abstracto de dato con el rango o precisión ampliados y crear para éltodas las operaciones necesarias mediante funciones. En Ada el nombre deestas func iones pu ed en ser directam ente ope rado res (+, *, / , ...).Inevitablemente, la implementación de estos nuevos tipos abstractos serábastante ineficiente respecto a los t ipos propios del computador realizadospor hardware .

La tabla de códigos de caracteres util izados es otra causa de problemas.Actualm ente, prácticam ente todo s los com puta do res util izan la tabla ASCII.Sin embargo, para facili tar la transportabilidad lo mejor es no aprovecharnunca en la codificación el orden de los caracteres en una tabla concreta.

SISTEMA OPERATIVO:

Los lenguajes incorporan de un modo u otro el acceso a servicios delsistema operativo para realizar tareas como las siguientes:

• En tra da /sa lida (teclado, pantalla, ratón, etc.)

• M ane jo de ficheros (abrir, leer, escribir, etc.)Manejo de librerías (numéricas, utilidades, etc.)

En muchas aplicaciones es inevitable hacer uso de algunas o todas estasfacilidades que son específicas de ca da sistema operativo. Los lenguajes dealto nivel disponen de procedimientos o funciones predefinidos para larealización de las operaciones más elementales dentro de estas tareas ysiempre que sea posible deben ser las únicas que se util icen. En algunoscom piladores concretos, el nivel de sofisticación de estas operaciones pue deser mayor y esto simplificará bastante la codificación. Sin embargo, sutransportabilidad será bastante incierta dado que son operaciones que no

se encontrarán en todos los compiladores con carácter general.

Lo habitual es que se necesiten operaciones más complejas yparticularizadas que las predefinidas en los lenguajes. En este caso, sedeben concretar y especificar claramente cada una de ellas. Estas nuevasoperaciones se agruparán en módulos de entrada/sal ida, para manejo deficheros, librerías matemáticas, etc. propios de cada aplicación. Para cadam ódu lo y operación se definirá una interfaz única y precisa en toda laaplicación. El resto de la aplicación util izará estos módulos de formaindependiente del sistema operativo. En la implementación de estos

módulos se podrán util izar las operaciones disponibles en el lenguaje y el




sistema operativo. Para transportar la aplicación a otro sistema operativosólo será necesario realizar una nueva implementación de estos módulos apartir del nuevo sistema operativo y sus operaciones más o menossofisticadas.

5.7 Técnicas de prueba de unidades

A lo largo de la fase de codificación se introducen de manera inadvertidamúltiples errores de todo tipo e incorrecciones respecto a lasespecificaciones del proyecto. Todo ello debe ser detectado y corregido

antes de entregar al cliente el programa acabado. Como sucede concualquier otro producto (mecánico, electrónico, etc.), para garantizar sucalidad es necesario someter al programa a diversas pruebas destinadas adetectar los errores o verificar su funcionamiento correcto. Según lautil ización final del programa, las pruebas pueden ser más o menosexhaustivas. Para un software crít ico (aeronáutica, nuclear, automoción,etc.), el costo de las pruebas puede ser la partida más importante del costode todo el desarrollo.

Para evitar el caos de una prueba global única, se deben hacer pruebas acada un ida d o m ódu lo según se avan za en la codificación del proyecto. Estofacili tará eno rme me nte las posteriores prue bas de integración entre m ódu losy las pruebas del sistema total que deben realizarse en cualquier caso. Eneste apartado se describen ciertas técnicas para realizar las pruebas de lasunidades .

5.7.1 Objetivos de las pruebas de software

A un qu e pu ed a resultar paradójico, el principal objetivo de las prue bas debeser conseguir que el programa funcione incorrectamente y que se descubransus defectos. Esto exige elaborar minuciosamente un juego de casos de

prueba dest inados a someter al programa a un máximo número posible desituaciones diferentes. Para elaborar los casos de prueba se debe tener encuenta lo siguiente:

• Un bue na prueba es la que encuentra errores y no los encubre• Para detectar un error es necesario conocer cuál es el resultad o

correcto• Es bue no que no participen en la pru eba el codificador o diseñad or

Siempre hay errores, y si no aparecen se deben diseñar pruebasmejores

• Al corregir un error se pu ed en introducir otros nue vos




• Es imposible dem ostrar la ausencia de defectos me diante prueb as

Probar completamente cada módulo es inabordable y además no resul tarentable ni práctico. Como se muestra en la figura 5.1, con las pruebas sólose explora una parte de todas las posibilidades del programa. Se trata dealcanzar un com promiso p ara qu e con el men or esfuerzo posible se pue dandetectar el máximo número de defectos y sobre todo aquellos que puedanprovocar las más graves consecuencias.

Figura 5.1. Dominio de las pruebas

Para garantizar unos resultados fiables, además del juego de casos deprueba, es esencial que todo el proceso de prueba se realice de la maneramás automática posible. Esto exige crear un entorno de prueba que asegureunas condiciones predefinidas y estables para las sucesivas pasadas, quenecesariam ente se debe n efectuar despu és de corregir los errores detectad osen cada pasada anterior .

Las pruebas de unidades se realizan en un entorno de ejecución controlado,que puede ser diferente del entorno de ejecución del programa final enexplotación. El entorno deberá proporcionar, al menos, un informe con losresultados de las pruebas y un registro de todos los errores detectados consu discrepancia respecto al valor esperado. A veces para establecer elentorno de pruebas serán suficientes las uti l idades del sistema operativopreparando en un fichero los casos de prueba y recogiendo en otro ficherolos resultados obtenidos que se compararán posteriormente con losesperados. Si se necesita un entorno más sofisticado que registre t iempos u



274 Introducc ión a la Ingeniería de Softw are

otros parám etros d e la prueb a será necesario desarrollar el correspondienteprograma.

Las técnicas de prueba de unidades responden a dos estrategiasfundamentales :

A co ntinuación se describen las técnicas principales aplicables en cada caso.

5.7 .2 Pruebas de caja negra

Según muestra la figura 5.2, la estrategia de caja negra ("black box") ignorapor completo la estructura interna del programa y se basa exclusivamenteen la com probación de la especificación entrada-sa lida del softw are. Se tratade verificar que todos los requisitos impuestos al programa, como acualquier otro producto, se cumplen. Esta es la única estrategia que puedeadoptar el cliente o cualquier persona ajena al desarrollo del programa.

La elaboración de unos buenos casos de prueba que permitan conocer elcorrecto funcionamiento de la caja negra no resulta trivial, y para ello sedeben emplear todos los métodos que estén a nuestro alcance. Esta tarearequiere cierta dosis de ingenio y hay personas mejor capacitadas que otraspar a llevarla a cabo. Com o si se tratara de u n juego, el objetivo es descub rirlos errores o incorrecciones del módulo "sospechoso" y para ello hay quediseñar un "interrogatorio" amplio y coherente.

Pruebas de "caja negra"Pruebas de "caja transparente

Casosde Prueba Resultados

Figura 5.2. Pruebas de Caja Negra

Existen ciertos métodos basados fundamentalmente en la experiencia queayudan bastante en la elaboración de casos de prueba. Todos ellos se




pue den y se deben ut il izar de form a conjunta y complem entaria. A lgunosde los usados más ampliamente son los siguientes:

PARTICIÓN EN CLASES DE EQUIVALENCIA:

Según se muestra en la figura 5.3 se trata de dividir el espacio de ejecucióndel programa en varios subespacios. Cada subespacio o clase equivalenteagrupa a todos aquel los datos de entrada al módulo que resul tanequivalentes desde el punto de vista de la prueba de caja negra. Laequivalencia podría corresponder intuitivamente a que el algoritmo decálculo, tal como se describe externamente, siga los mismos pasos en suejecución. Por ejemplo, si estam os pro ban do una func ión que realiza la raíz

cuadrada será suficiente con probar cualquier número positivo, el cero ycualquier número negat ivo o tal vez sea más adecuado probar con uncuadrado perfecto positivo, un valor positivo sin raíz exacta, el cero, uncuadrado perfecto negativo y un valor negativo arbitrario. De una formatenemos tres clases equivalentes y de otra cinco.

Figura 5.3. Clases de equivalencia

Los pasos que se deben seguir con este método son los siguientes:

1. Determ inar las clases equivalen tes aprop iada s




2. Establecer pruebas para cada clase de equivalencia: Se debenproponer casos o datos de pruebas válidos e inválidos para cada unade las clases definidas en el paso anterior.

Con este método, si las clases se eligen adecuadamente, se reduce bastanteel nú m ero de casos que se necesitan para desc ubrir un defecto. Según cómose caractericen las clases de equivalencia se pueden emplear las siguientesdirectrices:

A. Rango de valores:Ejemplo: 0 <= edad <120 años

Casos válidos: 1 den tro del rang o 33 añosCasos inválidos: 1 ma yor y 1 me nor -5 y 132 años

B. Valor específico:Ejemplo: Clave = OCULTA

Casos válidos : 1 igual OCU LTACasos inválidos: 1 distinto Otra578

C. Conjunto de valores:Ejemplo: Ope raciones = com pra, venta, cambio

Casos válidos: 1 por elemen to comp ra, venta, cambio

Casos inválidos: 1 fue ra del conjun to regalo

Hay que tener en cuenta que un caso de prueba válido para una clasepue de ser también un caso de prue ba invál ido para otra y asimismo pued eocurrir que un caso de prueba bien elegido sea válido para varias clases.Así, par a la elaboración del jueg o de casos de prue bas se pu ed en refinar lospasos indicados anteriormente:

1. De finir las clases equ ivalen tes

2. Definir un a prue ba qu e cubra tantos casos válidos como sea posible

de cualquier clase3. M arcar las clases cub iertas y repetir el paso anter ior has ta cubrir

todos los casos válidos de todas las clases

4. Definir una pru eba específica para cada caso inválido

ANÁLISIS DE VALORES LÍMITE:

Muchos programas se construyen codificando primero un t ratamientogeneral, y retocando luego el código para cubrir casos especiales. Por estay otras razones es bastante normal que los errores tengan cierta tendencia




a aparec er precisam ente al oper ar en las fronte ras o valores l ímite de losdatos normales .

El método de análisis de valores límite (en inglés "boundary analysis"),como se muestra en la figura 5.4, hace un especial hincapié en las zonas delespacio de ejecución que están próximas al borde. Este método escomplementario del anterior y también en éste se deben proponer casosválidos y casos inválidos. Por ejemplo, para el rang o de ed ade s indicado enel apartado anterior, los casos de prueba serían:

Límite inferior: -1 0 1

Lím ite su pe rio r: 119 120 121

Los errores en los l ímites pueden tener consecuencias más graves de lonormal debido a que pueden provocar la necesidad de unos recursos extraque no estaban previstos. Por ejemplo, si un sistema de control de unacentral nuclear debe poder atender 20 alarmas simultáneamente, en laspruebas se podrán provocar 21, 22 e incluso 30 alarmas y comprobar que




se detecta esta situación y se avisa al operador sin abortar el programa y

producir la parada del sistema por violación de memoria.

En este caso, las directrices a seguir en la elaboración de casos de pruebaserían las siguientes:

1. Entrada s: Probar con los mismos valores l ímite y justo fu era delímites. Por ejemplo, si la precisión en los cálculos = 5 cifras, probar5 y 6

2. Salidas: Pro bar con los m ism os valores límite y jus to fue ra de límites.Por ejemplo: Para l istados con N° línea s/pá gin a = 70, prob ar 70 y 71

3. Me moria: Probar con tam año s nulos, l ímite y superior al límite detodas las estructuras de información. Por ejemplo, para pilas, colas,tablas, etc., probar los casos vacío, lleno y sobrelleno (un elementomás de lleno)

4. Recursos: Probar con ningún recurso, l ímite de recursos y supe rioral límite. Por ejemplo, si máximo N° de terminales = 30, probar 0, 30y 31

5. Otros: Pen sar en otra s situacione s límite y establecer las prue ba s

Este mé todo tam bién se pued e util izar con la estrategia de caja transpa renteen la medida que se conozcan las estructuras internas del programa.

COMPARACIÓN DE VERSIONES:

Cuando una unidad o módulo es especialmente crít ico se puede hacer undesarrollo multi-versión (en inglés "N-version") encargando la codificaciónde difere ntes versiones a distintos program ado res. To dos ellos util izarán lasmismas especificaciones de partida y deberían obtener móduloscompletamente intercambiables. Sin embargo, esto no suele ocurrir debidoa variaciones en los algoritmos empleados, diferencias de matiz en la

interpretación de la especificación, diferentes precisiones, etc.

Por otro lado, se elaborará un juego de casos de prueba mediante losmétodos habituales. Hay que tener en cuenta que no siempre se conocen deforma completamente exacta los resul tados esperados y que en algunoscasos, como sucede en los sistemas de tiempo real, resulta casi imposibleconocer a priori cuáles serán esos resultados.

A continuación, se someterán todas las versiones al mismo juego de casosde prueba de una forma completamente automática. Los resul tados de lasdistintas versiones se comparan entre ellos y con los esperados. Cualquier



Codificación y Pru ebas 279

discrepancia entre las distintas versiones se debe analizar hasta discernir siuna versión es errónea y sus causas. Cua ndo todas las versiones pro duzc anlos mism os resultados y éstos coincidan con los deseados se pued e supone rque todas son equivalentes y correctas, y se puede utilizar cualquiera deellas.

La redundancia que se introduce con la codificación de varias versionesaumenta las garantías de que el módulo funciona correctamente y quecumple las especificaciones. Sin embargo, no es un criterio infalible puestoque un error en la especificación se trasladará a todas las versiones.

EMPLEO DE LA INTUICIÓN:

Como ya ha sido comentado, la elaboración de pruebas requiere ingenio. Eneste sentido, es muy importante dedicar cierto tiempo a preparar pruebasque planteen situaciones especiales y que puedan provocar algún error.Para ello, las personas ajenas al desarrollo del módulo suelen aportar unpunto de vista mucho más distante y fresco que las que participan en él. Enesta forma de trabajo es funda m enta l la intuición aunq ue ésta suele ir mu yligada a la experiencia previa en otras situaciones similares.

Casosde Prueba IF Correcto THEN Resultados

OperarELSE

Corregir_DatosEND

ResultadosInternos

Figura 5.5. Pruebas de caja tran sp are nte

5.7 .3 Pruebas de caja transp arente

Según se muestra en la figura 5.5, en la estrategia de prueba de cajatransparente

("white box", "clear box", "glass box") se conoce y se tiene en




cuenta la estructura interna del módulo. En la elaboración de los casos de

pru eba se trata de conseguir qu e el pro gram a transite por tod os los posiblescaminos de ejecución y ponga enjuego todos los elementos del código. Portanto, los casos de prueba deben conseguir que:

• Tod as las decisiones se ejecuten en un o y otro sentido• Tod os los bucles se ejecuten en los sup uesto s m ás diversos posibles• Tod as las estructu ras de dato s se mo difiqu en y consulten alguna vez

En principio puede parecer que las únicas pruebas realmente necesarias sonlas que sirven para demostrar el funcionamiento según las especificaciones

y esto se puede lograr con una estrategia de caja negra. Sin embargo, unprograma es una ent idad de una complej idad muy superior a la del mássofisticado artilugio mecánico, hidráulico, electrónico, etc., para los que sísuele ser suficiente con someterlos a pruebas de caja negra. Como ejemplose puede decir que un sencillo bucle que se pueda ejecutar entre 0 y 10veces y que teng a en su interior sólo 5 caminos diferente s se pu ede ejecutarde casi 10 millones de formas distintas.

Es cierto que en la mayoría de los programas sólo se l legan a ejecutar unnúmero bastante reducido de todos los caminos posibles. Pero también escierto que no resulta fácil prever a priori qué caminos son los que se

ejecutarán y cuáles no. Cuando se elaboran las pruebas de caja negrapueden quedar perfectamente inexplorados caminos que en unfuncionamiento habi tual no serán muy frecuentados pero que s í sondecisivos en situaciones concretas y que si no han sido probadosconvenientemente pueden producir un error en el peor momento.

Las pru eba s de caja negra y de caja trans pare nte d eben ser com pleme ntariasy nu nca excluyentes. De hecho es conveniente aplicar el m étod o de análisisde valores l ímite para elaborar pruebas de caja transparente teniendo encuenta la estructura del programa. Está claro que las pruebas de cajat ransparente deben ser propuestas por alguien que haya part icipado oconozca la codificación en detalle. En este caso, los métodos másampliamente util izados son los siguientes:

CUBRIMIENTO LÓGICO:

No parece muy razonable proponer casos de prueb a para conseguir que unprograma se ejecute de todos los billones o tri l lones de formas posibles,pero al menos debemos conseguir cierto cubrimiento lógico de todas lassecciones de código y no dejar ninguna sin ejecutar alguna vez.




Dado un fragmento de código como el que muestra el diagrama de flujo dela figura 5.6, denominaremos camino básico a cualquier recorrido quesiguiendo las flechas de las l íneas de flujo nos permita ir desde el puntoinicial (0) al punto final (9) del diagrama. Se utiliza aquí un diagrama deflujo por su carácter gráfico, pero los razon am ientos se pu ed en trasladar deforma inmediata a un fragmento de código escrito en cualquier lenguaje deprogramación. Cada rombo del diagrama debe representar un predicadológico simple, esto es, no puede ser una expresión lógica con algúnoperador OR, AND, etc. Hay que tener en cuenta que cualquier expresiónlógica siempre se puede representar uti l izando un rombo por cadapredicado lógico simple.

Figura 5.6. Diagrama de f lu jo con 3 predicados lógicos simples

Primeramente, se trata de determinar un conjunto de caminos básicos querecorran todas las l íneas de flujo del diagrama alguna vez. Como máximo,el número de caminos básicos necesarios vendrá determinado por elnúm ero de predicados lógicos s imples o rombos q ue tenga el diagram a deflujo de acuerdo con la siguiente fórmula:

N° máximo de cam inos = N° predicados + 1




En el caso de la figura 5.6 tenemos:

N° máximo de caminos = 3 + 1 = 4

y pa ra este ejemplo serían suficientes los siguientes cu atro cam inos básicos:

C am in o 1: 0 - 1 - 9C am ino 2: 0 - 1 - 2 - 3 - 4 - 5 - 1 - 9C am ino 3: 0 - 1 - 2 - 3 - 6 - 8 - 1 - 9C am ino 4: 0 - 1 - 2 - 3 - 6 - 7 - 1 - 9

Existen otros caminos, tales como:

C am ino 5: 0 - 1 - 2 - 3 - 4 - 5 - 1 - 2 - 3 - 6 - 7 - 1 - 9

pero ninguno de ellos util iza alguna línea de flujo nueva no util izadapreviamente por los cuatro primeros. Lo que sí es posible es susti tuir uncamino por otro siempre que con el conjunto se recorran todas las l íneas.

El mé todo del cub rimiento lógico consiste en elaborar casos de pru eba paraque el programa recorra un determinado conjunto de caminos s iguiendociertas pautas. Para ello, se pueden establecer distintos niveles decubrimiento:

NIVEL I : Se trata de elaborar casos de pruebas para que se ejecuten almenos una vez todos los caminos básicos, cada uno de ellos porseparado .

NIVEL II: Se trata de elaborar casos de pru eba para q ue se ejecuten toda slas combinaciones de caminos básicos por parejas. En el ejemplo dela figura 5.7 serían necesarios 7 caminos para probar lascombinaciones por parejas. Estos caminos podrían ser:

Camino 1: 0 - 1 - 1 1Camino 2: 0 - 1 - 2 - 3 - 5 - 6 - 7 - 1 - 11Camino 3: 0 - 1 - 2 - 3 - 5 - 6 - 8 - 1 - 11Ca min o 4: 0 - 1 - 2 - 3 - 5 - 9 - 10 - 1 - 11Camino 5: 0 - 1 - 2 - 4 - 5 - 6 - 7 - 1 - 11Camino 6: 0 - 1 - 2 - 4 - 5 - 6 - 8 - 1 - 11Camino 7: 0 - 1 - 2 - 4 - 5 - 9 - 10 - 1 - 11

NIVEL III: Se trata de elaborar casos de prueb a pa ra qu e se ejecuten unnúmero significativo de las combinaciones posibles de caminos.




Como se ha comentado, cubrir todas las combinaciones posiblesresulta inabordable.

Como mínimo las pruebas de cada módulo deben garantizar el nivel I.Según los distintos autores, con el cubrim iento lógico se pue de n q ue dar sindetectar el 50 % de los errores y es necesario util izar otros métodos. Enconcreto, nunca se podrá detectar la falta de un fragmento de código.

PRUEBAS DE BUCLES:

Los bucles constituyen un elemento esencial en cualquier programa y se

debe prestar especial atención a la elaboración de pruebas para ellos. Coneste fin, distinguiremos entre las siguientes situaciones:

Bucle con número no acotado de repeticiones. Se elaborarán pruebas para:

• Ejecutar el bucle 0 veces• Ejecutar el bucle 1 vez• Ejecutar el bucle 2 veces• Ejecutar el bucle un núm ero m od era do de veces• Ejecutar el bucle un nú m ero elevado de veces




Bucle con núm ero m áximo (M) de repeticiones. Se elaborará n p rue bas para:

• Ejecutar el bucle 0 veces• Ejecutar el bucle 1 vez• Ejecutar el bucle 2 veces• Ejecutar el bucle un núm ero interm edio de veces• Ejecutar el bucle M -l veces• Ejecutar el bucle M veces• Ejecutar el bucle M +l veces

Bucles anidados. El número de pruebas crece de forma geométrica con el

nivel de anidamiento; para reducir este número se util izará la siguientetécnica:

1. Ejecutar todo s los bucles externos en su núm ero m ínimo de vecespara probar el bucle más interno con el algoritmo de bucle quecorresponda.

2. Para el siguie nte nivel de anida m iento , ejecutar los bucles extern osen su número mínimo de veces y los bucles internos un númerotípico de veces, pa ra pr ob ar el bucle del nivel con el algor itmo debucle que corresponda.

3. Repetir el paso 2 has ta com pletar to do s los niveles.

Bucles concatenados. Si son independientes se probarán cada uno porseparado con alguno de los criterios anteriores. Si están relacionados (p.ej.:el índice final de uno es el inicial del siguiente), se empleará un enfoquesimilar al indicado para los bucles anidados.

EMPLEO DE LA INTUICIÓN:

También con la estrategia de caja transparente merece la pena dedicar uncierto t iempo a elaborar pruebas que sólo por intuición podemos estimar

que plantearán situaciones especiales. Es obvio que para ello es necesarioconocer mu y en detalle la estructura del m ód ulo y tener alguna experienciaprevia.

5.7 .4 Estimación de err ore s no de tec tad os

Aunque sea constatable que no aparecen nuevos errores y haya s idoconsiderable el esfuerzo empleado con las pruebas más diversas ysofisticadas, resulta imposible demostrar que un módulo no tiene defectos.Este hecho resulta poco tranquilizador, por lo que conviene obtener alguna



Codificac ión y Pru eba s 285

estimación estadística de las erratas que pueden permanecer todavía sin serdetectadas.

Desde luego, el juego de pruebas sólo ejercita el módulo en una parte desus posibilidades y siempre pueden quedar situaciones sin explorar. Paratener una estimación del número de defectos que quedan sin detectar sepuede util izar la siguiente estrategia:

1. An otar el núm ero d e errores que se pro du cen inicialmente con eljuego de casos de prueba: E] (p.ej.: E, = 56).

2. Corregir el m ódu lo hasta que no tenga ning ún error con el mismojuego de casos de prueba.

3. Introducir aleatoriamen te en el m ód ulo un núm ero razonable deerrores: EA (p.ej.: EA = 100) en los puntos más diversos. Esta labordebe rá ser realizada po r alguien q ue no conozca el juego de casos deprueba.

4. Someter el mó dulo con los nue vos errore s al jueg o de casos deprueba y hacer de nuevo el recuento del número de errores que sedetectan: ED (p.ej.: ED = 95).

5. Para el jueg o de casos de prue ba considerado , sup on iend o que seman tiene la misma p ropo rción estadística, el porcentaje de errores sindetectar será el mismo para los errores iniciales que para los erroresdeliberados. Por tanto, el número estimado de errores sin detectarserá:

E E = (E A - E D ) * (E, / E D ) = (100 - 95 ) * (5 6 / 95 ) - 3 errores

Dependiendo de lo crít ico que resulte el software y del resultado obtenidocon esta estrategia, se debe estudiar la conveniencia de elaborar nuevoscasos de prueba.

5.8 Estrategias de integración

Las unidades o módulos de un producto software se han de integrar paraconformar el sistema completo. Desgraciadamente, en esta fase deintegración también aparecen nuevos errores debidos a las más diversascausas:

• De sacuerdo s en la interfaz• Interacción indeb ida entre m ódu los




• Imprecisiones acum uladas• ... etc . ...

iDurante la fase de integración se debe proceder en forma sistemática,siguiendo una estrategia bien definida, para facili tar la depuración de loserrores que vayan surgiendo. Entre las estrategias básicas de integracióntenemos:

• Integrac ión "Big Bang"• Integración desce nden te (en inglés "Top-Down")• Integra ción asce nde nte (en inglés "Bottom-Up")

Estas est rategias pueden emplearse independientemente o en formacombinada.

5.8.1 Integración Big Bang

Esta estrategia consiste en realizar la integración de todas las unidades enun único paso. Como es fácil suponer la cantidad de errores que aparecende go lpe pu ed e h acer casi imposible la identificación de los defectos que loscausan, provocando un auténtico caos. Sólo para sistemas muy pequeñosse puede justificar la uti l ización de esta estrategia. La ventaja fundamental

es que se evita la realización del software de "andamiaje" que se requierecon las otras dos estrategias progresivas.

5.8.2 Integración descend ente

Como se muestra en la figura 5.8, en esta estrategia de integración se parteinicialmente del módulo principal (Módulo P) que se prueba con módulosde "andamiaje" o sustitutos (en inglés "stubs") de los otros módulos usadosdirectam ente (Sust. A,. . .). Los mó dulo s susti tutos se van re em plaza ndo , u nopor uno, por los verdaderos y se realizan las pruebas de integración

correspondientes. La forma en que se produce la susti tución e integraciónde los módulos verdaderos puede ser estrictamente por niveles, por ramaso una mezcla, según vayan estando disponibles.

La codificación de los susti tutos es un trabajo adicional que convienesimplificar al máximo y para el que se pueden adoptar distintas soluciones:

• No hacer nad a y que sólo sirva para compro bar la interfaz• Imp rimir un men saje de seguim iento con informac ión de la l lamada• Sum inistrar un resultad o fijo• Sum inistrar un resultad o aleatorio




• Sum inistrar un resultad o tabu lado u obtenid o con un algoritmosimplificado

Paso 1Módulo P

Paso 2Módulo P

I<^SustIT) Módulo C

Paso 3Módulo P

iMódulo B Módulo C

Paso 4

Módulo A

Módulo P

Módulo B Módulo C

Módulo C1 r S u s t . C

Figura 5.8. Inte gra c ión descendente

La ventaja funda me ntal de la integración descendente es que se ven desdeel principio las posibilidades de la aplicación. Esto permite mostrar muypronto al cliente un prototipo sencillo y discutir sobre él posibles mejoraso modificaciones.

Los inconvenientes más importantes son:

1. La integración estrictamente de scend ente l imita en cierta forma el

trabajo en paralelo.2. Al conducir la integración de los nuevos módulos desde otros

módulos ya integrados y definitivos se t ienen bastantes l imitacionespara hacer pruebas especiales o dirigidas a un objetivo específico.Para lograr esto es necesario desarrollar nue vos m ódu los o hacer unaintegración híbrida ascendente-descendente.

5.8.3 Integración ascendente

En la estrategia de integración ascendente se empieza por codificar por

sep ara do y en paralelo todos los mó dulo s de nivel más bajo. Para probarlos




se escriben módulos gestores o conductores (en inglés "drivers") que loshacen funcionar independientemente o en combinaciones sencillas. Porejemplo, según se muestra en la figura 5.9, el Gestor A es el encargado derealizar las pruebas de integración entre los módulos Al y A2 antes de quese tenga disponible el módulo definitivo A. Los Gestores se vansust i tuyendo uno a uno por los módulos de mayor nivel según se vancodificando, al t iempo que se van desarrollando nuevos gestores si hacefalta. En este caso, el orden de sustitución puede ser cualquiera salvo paralos últimos pa sos en qu e se necesita que tod os los mód ulos inferiores esténdisponibles.

Figura 5.9. Integrac ión Ascendente

Aunque en algunos casos se puede prescindir de los Gestores, su interésradica fundamentalmente en su capacidad para probar de forma expl íci tasituaciones especiales o infrecuentes.

Las ventajas de la integración ascendente coinciden con los inconvenientesde la integración descendente:

• Facilita el traba jo en para lelo• Facilita el ensa yo de situacion es especiales




Por el contrario, el inconveniente más importante es que resulta difícil

ensa yar el func ionam iento global del produ cto so ftwa re hasta el final de suintegración.

La mejor solución es util izar una integración ascendente con los módulosde nivel más bajo y una integración descendente con los de nivel más alto.Esto se denomina integración sandwich.

5.9 Pruebas de sistema

Finalizada la integración, es el mo m ento de prob ar el sistema com pleto p araver si verdaderamente cumple las especificaciones en un entorno real detrabajo. En todas estas pru eba s se suele aplicar u na estrategia de caja negraal sistema en su conjunto.

5.9.1 Objetivos de las pruebas

Según el objetivo perseguido, tendremos diferentes clases de pruebas.

PRUEBAS DE RECUPERACIÓN:

Sirven para comprobar la capacidad del sistema para recuperarse antefallos. Con estas pruebas, además de provocar el fallo, se debe comprobarsi el sistema lo detecta, si lo corrige cuando así está especificado y si elt iempo de recuperación es menor del también especificado.

PRUEBAS DE SEGURIDAD:

Sirven para comprobar los mecanismos de protección contra un acceso omanipulación no autorizada. Las pruebas deberán intentar violar los

mecanismos previstos como si de un intruso se tratara.PRUEBAS DE RESISTENCIA:

Sirven para comprobar el comportamiento del sistema ante situacionesexcepcionales. Las pruebas deberán forzar el sistema por encima de sucapac idad y prestaciones norm ales para verificar cuál es su com portam ientoy cómo se va degradando en estos casos.




PRUEBAS DE SENSIBILIDAD:

Sirven para comprobar el tratamiento que da el sistema a ciertassingularidades relacionadas casi siempre con los algoritmos matemáticosutil izados. Las pruebas deben buscar combinaciones de datos que puedanprovocar alguna operación incorrecta o poco precisa en un entorno delproblema especialmente sensible.

PRUEBAS DE RENDIMIENTO:

Sirven para comprobar las prestaciones del sistema que son crít icas entiempo. Estas pruebas son fundamentales para los sistemas de t iempo real

y / o s istemas con comp utador en globado. Para medir los t iempos se suelennecesitar equipos de instrumentación externos (emuladores, analizadoreslógicos, osciloscopios, etc.). Por ejemplo, se puede forzar al sistemaprovoc ando m últ iples interrupciones s imultáneamen te para m edir el t iempomáximo que emplea en t ratarlas .

5.9.2 Pruebas alfa y beta

Para comprobar que un producto software es realmente út i l para sususuarios es conveniente que estos últimos intervengan también en laspruebas finales del sistema. De esta manera se pueden poner de manifiestonuevas deficiencias no caracterizadas hasta entonces. Por ejemplo:

• Me nsajes ininteligibles para el usua rio• Presentación inadecuad a de resul tados• Deficiencias en el m anu al de usua rio• Procedim ientos de operación inusuales• ... etc . ...

Para la realización de estas pruebas se pueden necesitar semanas o meses

porque el usuario necesita ir aprendiendo el manejo del nuevo sistema. Esprobab le que los prob lem as má s graves aparez can ya al com ienzo y por elloes aconsejable que alguien del equipo de desarrollo acompañe al usuariodurante la primera toma de contacto. Se denominan pruebas alfa a unasprimeras pruebas que se real izan en un entorno controlado donde elusuario t iene el apoyo de alguna persona del equipo de desarrollo y a suvez esta misma persona puede seguir muy de cerca la evolución de laspruebas.

Posteriormente, en las pruebas beta, uno o varios usuarios trabajan con elsistema en su entorno normal, sin apoyo de nadie, y anotando cualquier




problema que se presente. En algunos s is temas pued en qued ar regis tradas

automáticamente las últ imas operaciones que han dado lugar al problema.Sin embargo, es muy importante que sea el usuario el encargado detransmitir al equipo de desarrollo cuál ha sido el procedimiento deoperación que le l levó al error. Esta información resulta vital para abordarla corrección.



Te m a 6Au tom a t iz a c ión de l P ro ce so

de Desa r ro l l o

Este Tema se dedica a analizar los elementos de soporte informático delproceso de desarrollo, conocidos genéricamente como técnicas CASE. Dadala varie dad de elem entos existentes, se realiza un e sfuerz o por clasificar dealguna manera las herramientas disponibles, para presentarlas de unamanera coherente.

6.1 Entornos de desarrollo software

La palabra entorno (en inglés "environment") se viene utilizando eninformática desd e hace algun os años p ara d esignar el contexto en el cual se

realiza una determinada actividad, y en particular para designar lacombinación de instrumentos disponibles para ello. Además, para aplicarcon propiedad el nombre de "entorno" a una determinada colección deinstrumentos se requiere que dicha colección constituya un conjuntocoherente, de forma que todos los elementos se combinen unos con otrosde manera apropiada y que, en lo posible, aparezcan más como una únicaherram ienta global que como una colección de herram ientas indep endien tes.

U n entorno de desarrollo de software (en inglés SEE: Software EngineeringEnvironment) consiste, por tanto, en el conjunto de los elementosdisponibles pa ra realizar dicho desarrollo, y especialmente los instrum entosinformá ticos que facili tan esta labor. Las técnicas de sopo rte inform ático deldesarrollo de software se designan habitualmente con las siglas inglesasCASE (Computer Aided Software Engineering).

La reciente evolución de las técnicas de ingeniería de software ha hechoaparecer una mu lt i tud d e herramientas de soporte de diferentes act ividadesdel desarrollo, que al t iempo que facili tan la producción de softwareintroducen a veces cierta confusión debida a la proliferación de enfoquesdiferen tes que se dan al concebir las distintas herram ientas d isponibles ho ydía.




Las siguientes secciones tratan de d ar u na visión coord inada de las actuales

técnicas CASE, desde las más elementales y clásicas hasta las másevolucionadas, que apenas empiezan a util izarse.

6.2 Panorámica de las téc nic as CASE

Tomando el término CASE en su aspecto más general, se aborda aquí unapresentación de conjunto de los diferentes elementos informá ticos de ap oyoa la labor de desarrollo de software.

6.2.1 Soporte de las fases de desarrollo

Históricamente el soporte informático del desarrollo de software ha idoprogresando desde las fases centrales del ciclo de vida hacia los extremos.Las primeras herramientas disponibles se han centrado exclusivamente enla fase de codificación (o programación). La evolución del soporteinformático de programación ha ido ligado a la evolución de los lenguajes.De hecho, la palabra "entorno" se ha aplicado inicialmente en informáticaa la actividad de programación antes que a la de desarrollo global desof tware .

El entorno de programación clásico (que aún no recibía este nombre) seorgan izaba en torno a un com pilador, al que se añadían un editor de textos,para la preparación del código fuente, y un montador de enlaces, parapermit i r la preparación de módulos por separado y su posteriorcombinación en un programa ejecutable único.

Un enfoque alternativo del entorno de programación clásico lo constituyenlos intérpretes de lenguajes interactivos, que combinan en una solaherramienta las funciones de edición y ejecución del programa.

La aparición de metodologías concretas de análisis y diseño dió lugar a laprogresiva aparición de herramientas para soporte de las mismas. Estasherramientas han recibido en muchos casos la denominación deherramientas CASE, dando lugar así a una cierta confusión al l imitar laaplicación del término CASE a sólo estas fases del ciclo de vida. Lametodología más extendida, al menos en cuanto a la variedad de productoscomerciales que la soportan, es la de análisis y diseño estructurado, en susdistintas variantes.

Para la fase de pruebas e integración se puede disponer de herramientas deensayo, que permiten ejecutar automáticamente programas de prueba, y



Au tomatizac ión del Proceso de Desarrollo 295

comparar los resultados obtenidos con los esperados, decidiendo así si la

prueba se ha realizado con éxito.

Para la fase de mantenimiento se dispone de soporte de gestión deconfiguración, que hab itualme nte se aplica tamb ién a las fases anteriores decodificación, pruebas e integración. Este soporte incluye la gestión deversiones y el control de cambios.

El futuro de las técnicas CASE está en el soporte completo de todo el ciclode vida. Por el momento esto no se consigue con un producto único,aunque sí se han establecido esquemas generales para integrar diversos

elementos en un entorno común. Estos entornos integrados se handesignado inicialmente con las siglas inglesas IPSE (Integrated ProjectSup port E nvironm ent). Actualm ente se prefiere hablar de ICASE (IntegratedCASE) o de ISEE (Integrated Software Engineering Environments).

6.2 .2 Formas de organización

Un entorno de desarrol lo de software, con independencia de que cubra uncam po m ás o me nos am plio del ciclo de vida, suele ser una com binación deelementos que automatizan una variedad mayor o menor de funciones. Elentorno en su conjunto puede estar organizado de diferentes maneras .

Una manera de construir un entorno de desarrollo es combinar variasherramientas distintas, cada una de las cuales realiza una funcióndiferenciada. La combinación de herramientas exige, en general, que elproducto resul tante de unas puede usarse como elemento de entrada deotras. De esta manera la actividad de desarrollo puede organizarse comocadenas de t rabajos.

Un ejemplo típico es el entorno de programación clásico, con la cadenaedi tor-compilador-montador que permite pasar del texto fuente al program aejecutable. Este núcleo básico puede ampliarse con otras herramientas talescomo las que se describen más adelante en este Tema.

Otra forma de organizar el entorno es disponer de un almacén común deinformación, denominado repositorio. En este almacén se guarda lainformación en un form ato común a todas las herramientas , de manera quecualquiera de ellas puede aplicarse a los datos disponibles en cadamomento. Las herramientas CASE de análisis y diseño están organizadashabitualmente de esta manera. Por ejemplo, con la metodología de análisisestructurado, el repositorio contiene la l ista completa de todos los datosusados en la aplicación en desarrollo, y esta lista se usa tanto para rotular




las flechas dura nte la edición de los diag ram as d e flujo de datos, com o p ara

comprobar que las especificaciones de proceso contienen referencias a losdato s de entrad a y salida, o para im primir el diccionario de datos com pleto.

Finalmente podemos hablar de entornos que están organizados como unaúnica herramienta global, capaz de realizar todas las funciones necesarias.Este enfoque resulta muy ventajoso de cara a la comodidad de util ización,pero también encierra el peligro de resultar demasiado cerrado, y nofacili tar su combinación con otros elementos de soporte del desarrollo.

6 2 . 3 Objetivo de un entorno de desarrollo

La diversidad de herramientas y entornos disponibles hoy día, y laconsiguiente dificultad para clasificar todo este conjunto de elementos, sedebe en buena parte a la diversidad de objetivos parciales que tratan desatisfacerse al diseñar cada h erram ienta. Según cuál sea el objetivo buscado,las herramientas o entornos de t rabajo adoptarán una u otra forma,resultando a veces elementos muy diferentes entre sí .

Uno de los objetivos parciales, y de hecho uno de los más antiguos, es darsoporte a la programación en un lenguaje concreto. En este caso tenemosentor nos l igados a un lengua je en particular. Los intérpretes interactivos son

un ejemplo clásico. En algunos casos el entor no com o tal es tan impo rtantecomo el lenguaje. Esto ha ocurrido con el lenguaje SmallTalk, para el quese desarrolló el prim er e ntorno de trabajo basado en una interfaz gráfica conventanas y menús. También en el caso del lenguaje Ada se ha tratado decrear un entorno estándar, y no sólo un lenguaje de programación.

Otro de los objetivos pu ed e ser dar so porte a un a metodo logía de desarrolloconcreta, independiente en la mayoría de los casos del lenguaje deprogra ma ción util izado. Así se han con struido, como ya se ha indicado, lasllamadas herramientas CASE que soportan las metodologías particulares deanálisis y diseño de software.

También encontramos entornos de trabajo centrados en la planificación ycontrol del proceso de desarrollo de un proyecto. Estos entornos incluyenherramientas para la organización y control de tareas, ayudas para laplanificación de reuniones, medida de la productividad, etc.

Otro objetivo, algo especial, es ayudar al desarrollo de entornos dedesarrollo. Tenem os en este caso los l lamados meta-entornos, que permitenconstruir entornos o herramientas p ara sop ortar una metodología o lenguajedeterminado, a partir de su descripción formal, de igual manera que hay




herramientas para construir casi automáticamente un compilador a part i rde la descripción formal del lenguaje.

Los ejemplos anteriores no agotan la lista de objetivos posibles, pero son yaun exponente de la variedad de enfoques que pueden darse a la hora decrear una nueva herramienta o entorno de desarrollo.

6.3 Una clasificación pragmática

Un primer intento de clasificar la variedad de entornos de desarrollo loencontramos en [Dart87], Esta clasificación puede considerarse como

realizada desde un punto de vista pragmático, poco formal, definiendogrupos de entornos similares por analogías de diferentes clases, unas vecesde organización y otras de objetivos. Esa clasificación cubre la mayoría delos productos existentes en el momento, pero no otros de gran difusiónactual, como son las herra mie ntas d e 4a generación. Supliendo esta omisión,tenemos las siguientes agrupaciones:

• Entorn os asociados a un lenguajeEntornos orientados a est ructura

• Entornos basados en herramientas• Entorno s asociados a una me todología

• Entorno s de 4a generación

A continuación se describen cada uno de estos grupos.

6.3. 1 Entornos asociados a un lenguaje

Un primer paso hacia la idea de un entorno de programación integrado loconstituyen los intérpretes de los lenguajes de programación interactivos,tales como los intérpretes de LISP o BASIC. Por ejemplo, un intérprete deBASIC perm ite editar el pro gra m a (habitualmen te en mem oria), almacenarlo

en un f ichero externo, recuperar p rogram as prep arado s de antem ano y, porsupu esto, ejecutar el pro gram a en edición en cualquier mom ento, de m anerainmediata. Los intérpretes tradicionales de BASIC operaban a base deintroducir órdenes en forma de líneas de texto. Si una línea de textocomienza por un número, se entiende que es una orden de edición, y lalínea se almace na com o línea del progra ma , o reemplaz a a otra ya existentecon ese número. Si la orden no comienza con un número se entiende quees una orden de ejecución inmediata. En particular hay una orden paraejecutar el programa. El intérprete suele incluir algunas facilidades dedepuración, tales como ejecutar el programa paso a paso, o examinar y




modificar los valores de las variables en mitad de la ejecución del

programa.

Más potentes resultan los entornos evolucionados para el lenguaje LISP,como por ejemplo Interlisp. Este entorno posee amplias facilidades paradesarrollo incremental, incluyendo potentes órdenes de edición, correcciónautom ática de errores de mec anogra fiado, mane jo de la historia de ó rdenes,con posibilidades de a nular o repetir anteriores órden es de edición, etc. Losentornos modernos se apoyan en sistemas de ventanas para la interaccióncon el usuario. Así se puede disponer de una ventana para la edición enmodo pantalla del programa fuente, otra ventana para realizar en ella laejecución, y otra ventana para examinar el contenido de los valoressimbólicos. La ejecución paso a paso va marcando en la ventana de edicióncada una de las expresiones que se van ejecutando.

F igura 6.1 Apa r i enc ia de un ed i tor d e cl ases en Sm al lTa l k

Un caso especial digno de mención aparte son los entornos asociados allengu aje SmallTalk. Este lenguaje, adem ás d e ser el pionero de los lenguajesde programación orientados a objetos, l leva asociado los primeros entornosgráficos interactivos basados en ventanas, menús, iconos y dispositivoapuntador (ratón o similar). Un entorno SmallTalk se diferencia de losentornos asociados a otros lenguajes en que el programa que se está




preparando no constituye un elemento separable del entorno de desarrollo,

sino que se materializa como una versión modificada del propio entorno.

En otras palabras, podemos decir que para desarrollar un programa enSmallTalk lo que se hace es añadir nuevos elementos a los ya existentes enel entorno de desarrollo, de manera que se disponga finalmente de unafunción equivalente al programa deseado. El entorno de desarrollo en síestá escrito en su mayor parte en el propio lenguaje SmallTalk, de maneraque los programas en desarrollo pueden apoyarse en la amplia colección dedefiniciones de clases y objetos que con stituyen el entorn o de program ación.Estas clases soportan de manera inmediata el manejo de diferentesestructuras de datos, de las ventanas gráficas, y la edición de textos.

Un elemento central del entorno de programación SmallTalk es el editor declases. En la figura 6.1 se muestra el aspecto de un entorno particular deSmallTalk (SmallTalk/V, de DigiTalk) cuando se ha activado este elemento.El editor de clases opera mediante una ventana con varios paneles. En lospane les superio res aparece la jerarqu ía d e clases definidas en el entorno. Alseleccionar una de ellas se presentan los nombres de los métodos definidosen la clase seleccionada. Seleccionando a su vez uno de esos métodos sepresenta en el panel inferior el texto fuente de su definición, que puede sereditada y recompilada. Usando el panel de edición y la función de

compilación asociada a él se pueden definir también nuevos métodosasociados a una clase, así como definir nuevas clases.

Otro caso particular es el de los entornos asociados al lenguaje Ada. Estelenguaje ha surgido de un proceso de normalización promovido por elDepartamento de Defensa de Estados Unidos. En este proceso se hadefinido no sólo el lenguaje en sí , sino la arquitectura y funcionesfundamentales de los entornos de programación para este lenguaje, talcomo se refleja en la figura 6.2. El nombre en código asignado a ladefinición estándar del entorno Ada es Stoneman [Buxton84].

El entorno se apoya en un núcleo base (KAPSE: Kernel Ada ProgramSupport Environment) que debe estar disponible en cualquier sistema quepermita desarrollos en Ada. En la actualidad está constituido por unalibrería de funciones denominada CAIS ( Common APSE Interface Set).Sobre esta base se debe disponer de al menos una serie de herramientasbásicas: editor, compilador, montador, etc. , que constituyen el entornomínimo (MAPSE: Minimal Ada Program Support Environment). Endiferentes instalaciones puede haber herramientas adicionales. El entornocompleto, incluyendo todas las herramientas disponibles en cada caso, sedenomina, en general, APSE (Ad a Programming Support Environment).




F igura 6 .2 Esquema de un entorno Ad a

6.3. 2 Entornos orientados a estru ctur a

En estos entornos se almacena la información correspondiente al programaen forma estructurada, y no simplemente como texto. Para el caso delpro gra m a fuente , esto quiere decir que no se almacena el texto fuente, sinosu equivalente como árbol de sintaxis abstracta (AST: Abstract Syntax Treé).La edición del programa se consigue mediante un editor de estructura, quepermite construir o modificar un programa operando sobre los elementosde su estructura: sentencias, declaraciones, expresiones, etc. En lugar deinsertar, borrar o ree mp lazar caracteres o l íneas del texto, el editor perm iteinsertar, borrar o reemplazar expresiones, sentencias, declaraciones devariables, bloques de programa, etc.

El ejem plo clásico de ento rno o rien tado a estru ctur a lo cons tituye el "CornellProgram Synthesizer" [Teitelbaum91], Este entorno permite desarrollarprogramas en lenguaje PL/I operando sobre la est ructura codificada delprograma. Las operaciones sobre esa estructura incluyen tanto la edicióncomo la ejecución del programa, y permiten operar con programas a medioconstruir, mientras no se intente trabajar con un elemento aún no definido.El entorno se basa en plantillas (templa tes) que describen las estructuras



Autom atización del Proceso de Desarrollo 301

básicas y la manera de presentarlas en pantalla en forma de texto. Por

ejemplo, la plantil la correspondiente a una sentencia IF es

Los elementos en cursiva son huecos ( placeholders ) en la plantilla,que habrán de ser rellenados con elementos concretos. Loselementos literales, entre doble apóstrofo (") incluyen códigos decontrol del formato de presentación. Puesto que la plantil la

incluye la forma en que se presenta el elemento en pantalla, elest i lo de encolumnado del programa es totalmente automático.

Pos ter iomente es te proyecto se ampl ió , desarro l lando unaherramienta para generar au tomát icamente un en torno deprogramación, similar al de PL/I, para cualquier otro lenguaje deprogramación, partiendo de una descripción formal de la sintaxis ysemántica del lenguaje en forma de gramática de atributos. Estaherramienta se ha denominado "Synthesizer Generator" [Reps84],

Otro proyecto en que se han desarollado herramientas para laconstrucción de entornos de programación orientados a estructuraes el proyecto Gandalf [Habermann86], cuyo elemento central es ungenerador de edi tores denominado ALOEGEN.

6.3 .3 Entornos basados en herram ientas

Los entornos de esta clase consisten en una colección de herramientas (eninglés "toolkit" o "toolbox") relativamente independientes. Para que elconjunto se pueda considerar con propiedad un entorno de desarrol lo es

necesario que las distintas herramientas sean compatibles entre sí . Ademásdebe existir algún medio de hacerlas funcionar en forma combinada, parafacilitar su manejo.

Un ejem plo clásico es el den om inad o "entorno de progra ma ción UNIX", queincluye una variada colección de programas de util idad para el desarrollode programas en lenguaje C, tales como las siguientes:

ii"IF (" condición

") \{ \nTHEN " sentencia-1

"ELSE" sentencia-2

"\}\r"

II

I I

ccvi

compi l ado r /mon tadoreditor de textos




cdbprofcxrefcb

lint

ar

make

verifica la consistencia de programas

gestor de l ibreríasdepurador s imbólicopresenta el perfil de ejecucióngenerador de referencias cruzadas"pretyprinter"automatiza la compilación y montaje

A esta colección se pu ed en a ñad ir otras herram ientas p ara tratar ficheros detexto, en general, y preparar documentación. Entre ellas:

La colección de herramientas disponible en UNIX es amplísima, superandoel centena r de util idades. La com patibilidad viene d ad a p or los form atos deficheros tratados: texto, fund am enta lme nte, así como código objeto y cód igoejecutable. Para combinar unas herramientas con otras se dispone de las

facilidades propias de este sistema operativo. Muchas herramientas puedenoperar como fil tros y ejecutarse en cadena conectando la salida de unprograma como entrada del s iguiente.

En realidad la forma más flexible de combinar herramientas es usar lasposiblidades de los "shell" o intérpretes de órdenes. Los lenguajes deórdenes de UNIX disponen de construcciones similares a las del lenguajeC y pueden usar variables . Usando un lenguaje de órdenes se puedeprogramar la realización automática de operaciones complejas que formenparte del proceso de desarrollo de software, facili tando la aplicación denormas o reglas particulares de programación o desarrollo.

Otros sistemas operativos incluyen colecciones de herramientas similares aalgunas de las mencionadas. Por ejemplo, sobre VMS de DEC existe elconjunto VaxSet (o el más moderno DECSet) que comprende editororientado a lenguaje, gestor de versiones, analizador de código fuente, etc.

Los entornos basados en herramientas suelen presentar como ventaja el serbastante abiertos, permitiendo la incorporación de nuevas herramientas dediferentes fabricantes o desarrolladas por los propios usuarios. Comoinconveniente se les puede achacar la falta de una interfaz de usuario

troff, nroff proce sadore s de texto

SCCS sistema de control de versionesawk program a de manipulación de textogrep busca patron es en ficheros de textowh at busca texto de identificación... etc. ...



Au toma tización del Proceso de Desarrollo 303

interactiva y uniforme, y ciertas l imitaciones en la representación de

información compleja si se fuerza el uso de ficheros de texto como mediofundamental de intercambio de información.

F igura 6 .3 E jemplo de DFD rea l i zado con una her r am ienta C A S E

6. 3. 4 Entornos asociados a metodología

El establecimiento de metodologías de análisis y diseño en los primerosaños d e existencia d e la ingeniería de so ftwa re como disciplina consolidada,dio lugar a continuación a la aparición de numerosas herramientas de

soporte de dichas metodologías. Como ya se ha indicado, muchas de estasherramientas se han denominado comercialmente "herramientas CASE",aunque realmente sólo soporten algunas fases del ciclo de vida dedesarrollo. La principal ventaja de estas herramientas es que suelenconstituir entornos de trab ajo bien integrado s y con una interfaz de usu ariouni forme.

La integración de los distintos elementos del entorno se suele conseguirmediante el empleo de un almacén único o repositorio CASE paraalmacenar todos los elementos de información contemplados en la




metodología soportada. Como ejemplo podemos considerar las

metodologías de análisis y diseño estructurado, basadas en el empleo dediagramas de flujo de datos. El repositorio contiene la informacióncorrespondiente a toda la familia de diagramas de flujo de datos, así comolas descripciones de cada dato y de cada proceso. El entorno de análisis ydiseño permite edi tar separadamente cada diagrama de f lujo y cadadescripción de proceso (miniespecificación), así como el diccionario dedatos. Algunos elementos de información, almacenados sólo una vez en elrepositorio, aparecen en varios diagramas o descripciones. La herramientaCASE facili ta también el mantenimiento o al menos detección de laconsistencia entre las diferentes descripciones o diagramas del productosoftware en desarrollo.

Project- C:\YSELECT\SYSTEM\BIBLI094\Title. Gesti ó n de bibliotecaDate: 9-Jan-95 Time. 16:57

This report generates a data dictionary listing. in alphabetical order.The report lists the ñ ame, type and BNF attribute for each item.Note type abreviations are- D = Di serete Flow

CD = Continious FlowC = Control Flow3S = Data StoreCS = Control Store

The format of the report is.

Ñ AME TYPE BNF

Ficha de lector D No BNFFicha de libro 0 No BNFFichas D [ Ficha de libro | Ficha de lector ]LECTORES DS í Ficha de lector }LIBROS DS { Ficha de libro }Libros D No BNFListado de lectores D No BNFListado de libros 0 No BNFListados 0 [ Listado de libros | Listado de lectores 1 Morosos ]Materia D No BNFMATERIAS DS { Materia }Morosos D No BNFOrden D No BNFPrestamos de lector D No BNF

Respuesta D [ Libros | Prestamos de lector ]

F igura 6 .4 E jemplo de d i c c ionar io de dato s de l a f i g ur a an ter i o r

En la figura 6.3 aparece como ejemplo un diagrama de flujo de datosconstruido con una de estas herramientas (SELECT/Yourdon). En la figura6.4 se muestra la versión inicial del diccionario de datos, correspondiente




al mismo ejemplo, generado por la herramienta CASE tras editar

manualmente la estructura (en notación BNF) de algunos datos.

Algunas herramientas CASE permiten también generar automáticamentepartes del código de la aplicación en desarrollo. Por ejemplo, a partir de lasdescripciones del diccionario de datos se puede generar directamente laDATA DIVISION de un programa en COBOL.

6.3 .5 Entornos de 4 a generación

Los entornos de desarrollo basados en herramientas de 4 a generación sonrelativamente recientes, aunque hoy día su uso está bastante extendido. Lamayoría de estos entornos se apoyan en un sistema de gestión de base dedatos dotado de un lenguaje de consulta, al que se añaden algunasherramientas conplementarias .

Estos entornos suelen estar orientados al usuario final. El desarrollo de unsistema de info rma ción consiste en definir los esqu em as de la base de datossubyacente y programar las operaciones o transacciones principales. Lasoperaciones de manipulación pueden programarse directamente con ellenguaje de consulta de la base de datos, o ayudarse con herramientas

específicas para el diseño d e form ularios de visualización y edición de datosen pantalla, generación de l istados o informes, generación de sistemas demenús para el diálogo con el usuario, etc.

M uchas de estas herram ientas de ayuda p ued en considerarse como entornosde programación visuales, en que se edita en pantalla el esquema de unaconsulta, de un formulario, de un listado, etc. A partir de este esquema segenera automáticamen te un prog ram a equivalente en el lenguaje básico deacceso a la base de datos.

6.4 Una clasifica ción por niveles

La clasificación de la sección anterior sigue unos criterios pragmáticos,t ratando de agrupar los productos CASE según afinidades. Podemosencontrar clasificaciones más modernas en [Fernstróm92] y [Fuggetta93].Estas clasificaciones se basan principalm ente en la funcion es realizadas porlos distintos productos CASE, y su situación en el entorno global dedesarrollo.




Un criterio base de estas clasificaciones es el nivel de funcionalidad del

producto CASE, correspondiente a la actividad de desarrollo queautomatiza o soporta. Los niveles que se distinguen son:

El nivel de servicio corresponde a un producto que real iza una función uoperac ión elemental, atómica, que un a vez invocad a no ha de inte rrum pirse.Desde el punto de vista del proceso de desarrollo, es una operación que hasido automatizada completamente; por ejemplo, la compilación de unprograma fuente .

El nivel de herramienta corresponde a un producto software que permiteinvocar diferentes servicios u operaciones correspondientes a una mismaactividad individualizada dentro del proceso de desarrollo. Un ejemplotípico es el de un editor (de texto, diagrama o documento).

El nivel de banco de trabajo o equipo de herramientas (en inglés:

"Workbench", "Toolkit" o "Toolbox") corresponde a un producto CASE queautomatiza o soporta un perfil concreto de actividad profesional dentro delproceso de desarrollo. Por ejemplo, la actividad del analista, o deldiseñador, o del "bibliotecario", etc. Un banco de trabajo suele englobarvarias herramientas, a men udo fuertem ente integradas, con una interfaz deusuario uniform e. De esta manera po dem os disponer d e un banco o equipode análisis, de diseño, etc. En el caso particular de la actividad decodificación, el banco de trab ajo correspo nde a lo que se deno min a entornode programación.

El nivel de entorno de desarrollo corresponde a un producto CASE que

soporte el proceso completo de desarrollo de software. Como ya se haindicado, se suele designar con las siglas IPSE o ICASE.

Los dos primer os niveles mencio nado s se describen a veces como un o solo,en cuyo caso se deno min a he rram ienta, por ejemplo, tanto a un ed itor comoa un compilador.

Producto CASE Actividad soportadaServicioHerramientaBanco de trabajoEntorno de desarrollo

OperaciónTareaPapel o perfil profesionalProceso de desarrollo de software




6.5 Herramientas de soft w ar e

Aquí se describen pro ductos co rrespondientes a los dos prim eros niveles dela clasificación anterior. En primer lugar se describen las herramientastradicionales, y luego las más modernas. Algunas de ellas han sidomencionadas ya al hablar de entornos basados en herramientas .

6.5.1 Herramientas clásicas

El repertorio de herramientas que podemos considerar tradicionales incluye

las siguientes:EDITOR DE TEXTO: Permite editar ficheros de texto. En su forma tradicional

considera el texto formado por l íneas y caracteres. A veces incluyefunciones orientadas a palabras, pero en general no atiende parana da a la naturale za del texto en edición, es decir, no tiene en cue ntasi el texto es un programa fuente, o en general, si sigue una reglasde construcción determinadas.

C O M P I L A D O R : Traduce un fichero de texto fuente a otro de código objeto,normalmente reubicable. El código objeto no suele ser ejecutable

directamente.

M O N T A D O R D E E N LA C ES (en inglés "linker"): Permite construir un programaejecutable combinando varios ficheros objeto. Habitualmente manejalibrerías de funciones en código objeto, realizando la inclusiónautom ática de aquellas que son efectivamente usada s en el prog ram a.

GESTOR DE LIBRERÍA: Permite co mb inar varios ficheros objeto en un a libreríaúnica. La librería suele incluir un índice que permite localizarrápidamente dentro de ella el fragmento de código objeto quecontenga un nombre simbólico o referencia externa determinada.

HER R AM IENTA "M AKE" : Sirve para automatizar la actualización de unconjunto de ficheros a partir de otros. Típicamente sirve paraautomatizar la compilación y montaje de programas a partir de losficheros fuente. Opera a partir de un fichero de dependencias en elque se indica de qué ficheros depende uno dado, y qué órdenes hayque ejecutar para regenerarlo en caso necesario. Estas órdenes soninvocada s selectivamente d ep end iend o d e si la fecha de actualizacióndel fichero final es anterior o posterior a las de los ficheros depart ida.




INTÉRPRETE INTERACTIVO: Constituye en sí mismo casi un entorno de

programación completo (si lo es, habrá que clasificarlo con el nivelde banco de trabajo y no de herramienta). Un intérprete interactivoengloba fu ncion es equiva lentes a las de edición, compilación, m ontajey ejecución de un programa.

C OM P ILADOR / INTÉR P R ETE: ES un procesador d e un lenguaje interpretado enform a no interactiva. Incluye un com pilador que tradu ce el prog ram afuente a código intermedio, y un intérprete de ejecución de dichocódigo intermedio que contiene la l ibrería de todas la funcionesbásicas de soporte del lenguaje. No incluye funciones de edición delprograma.

DEP UR ADOR AB S OLUTO: Permite ejecutar un p rogram a en form a controlada,instrucción por instrucción, o hasta un punto concreto. Tambiénpermite examinar y modificar el contenido de la memoria y losregistros del procesad or. Co mo sólo hace referencia a direcciones d ememoria o instrucciones de máquina, puede ser uti l izado conprogramas escritos en cualquier lenguaje y preparados con cualquiercompilador. Su inconveniente es que resulta muy incómodo de usar.

DEPURADOR SIMBÓLICO: Realiza una función análoga al anterior pero

traba jand o con referencia al código fuen te, lo cual resulta muc ho máscómodo. La ejecución por pasos opera sobre las sentencias dellenguaje, y el acceso a la memoria se hace con referencia a lasvariables del prog ram a. El de pu rad or simbólico necesita una tabla deinformación generad a por el compilador, que ha de estar prepa radopara ello.

6.5.2 Herramientas evolucionadas

En este apartado se describen otras herramientas que han alcanzado ya unaamplia difusión. Algunas de ellas pueden casi considerarse clásicas,mie ntras que otras se em plean h abitualm ente sólo en entornos de desarrolloavanzados.

EDITORES ORIENTADOS A LENGUAJE: No rmalm ente son editores de est ructura.El programa fuente no se almacena internamente como texto, sinoque se codifica su estructura sintáctica/semántica. Ya se ha habladode esta clase de herramientas al mencionar los entornos orientadosa estructura. Aunque presentan claras ventajas respecto a un editorde textos convencional, toda vía no se emplean con pro fusión , ya q ue




por debajo de un cierto nivel de estructura (t ípicamente el de

expresión aritmética) resulta más cómoda la edición del códigofuente como texto.

HER R AM IENTA "M AKE" AUTOM ÁTIC A: Las herramientas clásicas de t ipo"make" necesitan una lista explícita de dependencias entre ficherosy acciones de actualización. Hay casos en que las tareas decompilación y montaje pue den automatizarse totalmente detectandolas dependencias entre módulos mediante el análisis del códigofuente. De esta manera se puede combinar una herramienta dedetección de dependencias, que genera el fichero de dependencias,

con una herram ienta "make" clásica. Tam bién se pu ed e incorpo rar lafunción "make" en el propio compilador, de manera que lacompilación de un módulo provoca automáticamente larecompilación, en caso necesario, de aquellos de los que depende.

MANEJADOR DE VERSIONES: Este t ipo de herramienta permite almacenar demanera organizada y eficiente una serie de versiones de un mismoelemento de software. Todas las herramientas de esta clase puedenmanejar ficheros de texto, y algunas permiten también almacenarversiones de ficheros binarios. Ya se ha mencionado como ejemplolas util idades de SCCS para UNIX. Las versiones suelen designarse

mediante una numeración correlativa, a varios niveles; por ejemplo1.1, 1.2, 2.1, etc. Algunas herramientas de esta clase usan un ficheroseparado para las versiones de cada elemento de software. Otrasoperan con librerías que agrupan las distintas versiones de todos loselementos de software correspondientes a un mismo sis tema osubsistema en desarrollo. Es frecuente que estas herramientas seutil icen automáticamente desde las uti l idades de t ipo "make" alrecompilar una aplicación en desarrollo.

P R OC ES ADOR ES / ANALIZADOR ES DE C ÓDIGO F UENTE: En este grupo se p uede n

incluir diferentes herramientas que procesan el texto fuente paraobtener mediciones (tamaño, complejidad, etc.), generar tablas dere fe renc i as , enco lumnar s egún un es t i l o no rmal i zado("prettyprinters"), comprobar la consistencia de módulos entre sí, etc.Muchas de estas uti l idades pueden ser consideradas comocomplemento de los compiladores tradicionales, y las funciones querealizan podrían estar incorporadas directamente a dichoscompiladores .

PROCESADORES DE DOCUMENTOS: Estas herramientas no son específicas delas labores de desarrollo de software, pero son un soporte




fund am ental para el las . Los procesadores de do cumentos, l lamados

también procesadores de texto ("word processors"), facilitan laedición de documentación. Existen dos enfoques fundamentales. Enuno de ellos se usa un editor convencional para preparar un ficherocon el texto del documento, sobre el que se realiza un marcado paraseñalar las partes del documento y/o el esti lo de presentación. Laherramienta de proceso de documento genera el texto impreso enforma apropiada a partir de este fichero con el texto marcado. Lasutilida des "troff" y " nro ff en UNIX son un ejem plo clásico de esteenfoque, que también lo siguen TgX y sus variantes.

El otro enfoque corresponde a los edi tores de documentos quepresentan en pantalla una representación más o menos exacta delresultado impreso previsto, y permiten editar el documentodirectam ente sobre dicha presentación. La mism a herram ienta realizalas funciones de edición y de composición e impresión deldocumento .

HERRAMIENTAS DE CONTROL DE PRUEBAS: Ayudan a la realización depruebas unitarias o de integración. Las hay de varias clases. Hayherramientas para comprobar el grado de cubrimiento o ejecución decódigo durante las pruebas. Otras herramientas invocan la ejecución

de program as de prueba en forma automática, comproba ndo q ue losresultados coinciden con los esperados. También hay herramientaspara facili tar las pruebas automáticas de programas interactivos,simulando la entrada de órdenes o datos por teclado o ratón, enforma prederminada.

HERRAMIENTAS DE CONTROL DE CAMBIOS: Ayudan a la realización deldesarrollo en form a incremental, y al ma ntenim iento de aplicaciones.Una herram ienta d e este t ipo mantiene un a configuración consistentedel sistema en desarrollo, denominada línea base, y sólo permiteincorporar cambios en forma controlada, garant izando que las

modificaciones mantienen el sistema en estado operativo. Estasherramientas pueden apoyarse en herramientas t ipo "make" pararealizar las actualizaciones, en herramientas de control de pruebaspara garantizar el correcto funcionamiento del sistema, y enherramientas de manejo de versiones para almacenar la evolución dela línea base.

PROCESADORES DE FICHEROS DE TEXTO: En este grupo de herramientas sepue den incluir un gran núm ero de program as de ut i lidad disponiblesen sistemas UNIX, muchos de los cuales han sido transportados o




adaptados a otros s is temas operat ivos, const i tuyendo un verdadero

"cajón de sastre" del que se puede echar mano ocasionalmente parareal izar pequeñas (o grandes) tareas en forma cómoda. Algunas deestas herramientas se han mencionado ya al hablar de entornosbasados en herramientas. Destacaremos aquí solamente la uti l idad"awk" de UNIX, que es un c om pilado r/ intérpre te de un lenguaje demanipulación de ficheros de texto que facili ta las operaciones detratamiento de ficheros de datos. La forma básica de operación esrealizar el tratamiento línea por línea, con acciones particulares paracada clase de línea de texto, identificada por un p atrón determ inado.

Esta panorámica no agota la variedad de herramientas de apoyo al

desarrollo de softw are existentes hoy día, pero es suficiente pa ra i lustrar lasposibilidades de soporte informático de las actividades de desarrollo.

6.5 .3 Herramientas de 4 a generación

Las herramientas mencionada s en los apartad os anteriores suelen ser usad aspor los ingenieros de software y programadores para desarrol lar nuevosproductos software. Las técnicas de 4 a generación buscan la aproximaciónal usuario final, permitiendo que éste realice sus propios desarrollos.Algunas de estas técnicas se han mencionado ya en este Tema. Citaremosahora las herramientas más conocidas en este campo.

HOJ A DE C ÁLC ULO: ES una herramienta para facili tar la realizaciónautomática de cálculos basados en una plantil la o formulario,habitualmente de t ipo matricial o tabular. Se puede especificar quedeterminadas casil las de la tabla se rellenen automáticamente condatos calculados a partir de las otras. Los datos o las fórmulas seeditan en forma interactiva. Algunas herramientas modernas de estetipo permiten también la presentación gráfica de los valoresalmacenados en la hoja de cálculo.

P R OC ES ADOR ES DE DOC UM ENTOS : Estas herramientas se han mencionado yaen el apartado anterior. Las herramientas de 4a generación adoptansiempre el segundo de los enfoques mencionados all í , presentandoen pantal la el documento a medida que se va edi tando.

GESTORES DE BASES DE DATOS: Perm iten definir los esqu em as de las bases dedatos, y realizar operaciones generales de consulta y manipulación,tales como la inserción de nuevos datos, modificación de los




existentes, búsquedas, etc. Suelen estar basados en el modelo

relacional.

LENGUAJES DE 4aGENER AC IÓN: Permiten programar operaciones de

tratamiento de datos. Normalmente están asociados a un gestor debase de datos, en cuyo caso engloban un lenguaje de consulta yactualización (query language), tal como SQL.

GENERADORES DE PROGRAMAS: También suelen estar asociados a un sistemade gestión de base de datos. Son herramientas para la preparacióninteractiva de esqu em as de informes, form ularios en pantalla, m enús,etc. A partir de los esquemas editados en forma interactiva, generanprogramas en el lenguaje de 4 a generación asociado.

Realmente hay otras muchas herramientas o programas de ut i l idad quepu ed en incluirse en la categoría de softw are de 4a generación, pero aquí noslimitamos a considerar el software de desarrollo.

6.6 Entornos integrados

Los siguientes niveles (banco o equipo de trabajo, entorn o d e desarrollo) se

pueden analizar atendiendo no sólo a las funciones que realizan, o lasherramientas que incluyen, sino también a la manera en que estasherramientas se integran en un conjunto coherente. La integración[Thomas92] puede presentar diferentes aspectos:

• Integración de datos• Integra ción del control• Integración de presentación• Integración del proceso

A continuación se estudia cada uno de estos aspectos.

6.6.1 Integración de datos

La integración de datos significa que la información almacenada en elentorno es gest ionada de manera uniforme, con independencia de lastransform acione s concretas que se hag an con cada elemento de información.Esta forma de integración debe conseguir:

• Interoperabi lidad entre herramientas




• No redu nda ncia de datos, evitand o duplicacionesConsistencia de datos, evitando incoherencias

• Paso de datos de un a herram ienta a otra

La integración de datos puede conseguirse de distintas maneras [Chen92]:

TRANSFERENCIA DIRECTA de datos de una herramienta a otra. Es una maneramuy eficiente de compartir datos, pero poco flexible. Resultacomplicada cuando hay que integrar much as herramientas diferentes .

TRANSFERENCIA MEDIANTE FICHEROS. Ésta es la manera más sencilla deconseguir el paso de información de una herramienta a otra. En la

actualidad existe incluso un formato normalizado para intercambiode datos (CDIF: CASE Data Interchange Format) propuesto por laEIA (Electronic Industries Association) norteamericana.

TRANSFERENCIA BASADA EN COMUNICACIÓN. ES una alternativa a latransferencia mediante ficheros, y puede ser usada en sistemasdistribuidos y en sistemas abiertos.

R EP OS ITOR IO C OM ÚN. Esta forma de integración es la que se utiliza conpreferencia en entornos modernos, que buscan un grado deintegración elevado. Se estudia con detalle más adelante.

6.6 .2 Integración del control

La integración del control consiste en permitir la combinación flexible defunciones para cumplir con las particularidades del proceso y actividadesque hay que informatizar. El mayor grado de integración se consiguecuando desde una herramienta se pueden invocar funciones suminis t radaspor otra herramienta. Para que una herramienta suministre algún servicioa otra será necesario compartir información entre ellas; por tanto, la

integración del control exige como paso previo la integración de los datos.

La integración del control se puede conseguir mediante un sistema degestión de procesos y mensajes. Mediante un sistema de mensajes sepueden invocar funciones entre herramientas a diferentes niveles:herramienta-herramienta, herramienta-servicio, o servicio-servicio.

Un sistema de gestión de procesos permite invocar como acción única unacombinación de acciones realizadas por distintas herramientas. Ya se hamencionado como ejemplo el empleo del lenguaje de órdenes asociado a un



314 Introducc ión a la Ingeniería de Software

"shell" de un sistema operativo para programar secuencias de acciones que

automaticen determinadas actividades del proceso de desarrollo.

6.6. 3 Integración de la presentación

La integración de la presentación trata de realizar la interacción con elusuario de manera uniforme, con independencia de la función oherramienta en uso en un momento dado. De esta manera se reduce elesfu erzo de me mo ria y atención necesario para u tilizar el entorno. Para ellose deben conseguir los objetivos propios d e un sistema amigab le (en inglésuse r-fríe ndly):

• Limitar el nú m ero de form as de interacción diferen tes usa das por elconjunto de las herramientas y servicios.

• Usar form as de interacción y presentación adecu ada s al mo delomental que el usuario t iene del entorno.

• Satisfacer los t iemp os de respue sta espe rado s y dar indicación delavanceLdeJa operación en caso de tratamientos de larga duración.

• M antene r informa ción útil a disposición del usuario.

La integración de la presentación se puede basar en el empleo de sistemasde interfaz de usuario normalizados, tales como Motif u Open Look. Sinembargo el uso de uno de estos sistemas no garantiza en sí mismo un nivelde integración suficiente, ya que dicha interfaz sólo implica una forma depresentación uniforme, pero no su adecuación al modelo mental delusuario, que debe conseguirse mediante un diseño adecuado del diálogo,implícito en el flujo de control de cada herramienta o servicio.

6.6 .4 Integración del proceso

La integración del proceso consiste en que las herram ientas se combinan detal manera que apoyan o fuerzan de manera efect iva el uso de unametodología de desarrollo definida. Este modo de integración exige, engeneral, la existencia de una buena integración de control y datos.

El proceso d e desarrollo pu ed e d efinirse en base a los siguientes elementos:




• Un paso del desarrollo es una unidad de trabajo concreta que

produce un resultado; por ejemplo, la revisión del documento dediseño.

• Un suceso o evento de desarrollo es una condición que ocurredurante la ejecución de un paso y que puede desencadenar laejecución de una acción asociada; por ejemplo, la compilación sinerrores de un módulo puede desencadenar la ejecución de losprogramas de prueba de esa unidad.

• Una restricción del desarrollo es una limitación que debe cumplirse;

por ejemplo, que no debe haber dos personas editando el mismofichero al mismo tiempo, o que el autor de un módulo no debeencargarse de las pruebas del mismo.

Un buen grado de integración del proceso exige que los pasos, eventos yrestricciones que definen de manera natural la metodología de desarrolloa util izar, sean representables y tratables dentro del entorno.

6.6 .5 El repositorio CASE

El repositorio CASE es un almacén común en el que se guarda toda lainformación necesaria para la operación de un grupo de herramientas o deun entorno de desarrollo. En su forma más sencilla, el repositorio facilita lasfunciones de almacenamiento y recuperación de datos , normalmente enforma concurrente multiusuario, y el mantenimiento de relaciones entre losdatos. El repositorio puede suministrar, además, funciones de gestión deversiones, de seguridad, mediante control de acceso, y de gestión detransacciones.

Para proporcionar las funciones de almacenamiento y recuperación de datosse requiere, según [Chen92]:

• Un servicio de metamodelo, que permita definir las estructuras dedatos que han de almacenarse en el repositorio.

• Un servicio de consulta y actualización (query), que permita accedery manipular la información contenida en el repositorio.

• Un servicio de vistas, que permita definir subconjuntos de datos yoperaciones que constituyan el subentorno de trabajo de ciertas




actividades, y entre los que haya que mantener relaciones concretas

de consistencia.

• Un servicio de intercambio de datos, que facilite la importación yexportación de información mediante ficheros externos o canales decomunicación.

La información que interesa almacenar en un repositorio CASE cubre unespectro muy amplio. Su contenido puede incluir:

• Código fuen te

• Código objeto• Cód igo ejecutable• Órd enes de compilación y mo ntaje• Dependencias entre mó dulos• Estructura mo dular• Program as de prueb a• Datos de prueb a• Resul tados de prueb as• Especificaciones de mó dulo s• Informa ción de cambios• Métricas de calidad

• Docum entos de diseño• Doc um entos de requisitos• Inform es de revisiones• Definición de la metod ología de desarrollo• Informa ción de planificación del proyecto• Informa ción de gestión del proyecto• Informa ción de la em presa• ... etc . ...

Integrar toda esta información en forma homogénea en un repositorio únicono resulta fácil , por supuesto. Ésta es una de las dificultades a las que hayque enfrentarse a la hora de construir entornos de desarrollo capaces desoportar todo el ciclo de vida del software.

6.7 Bancos o equipos de trab ajo

Com o ya se ha indicado, un banco d e trabajo debe integrar las h erram ientasnecesarias para dar soporte a un determinado perfil profesional o actividadgeneral de desarrollo. Para que el banco de trabajo merezca este nombre,debe conseguir:




• Integración de la presentación, con una interfaz de usua rio

homogénea y consis tente• Integración del control, con la posibilidad de invocar cómod am ente

una herramienta o cadena de herramientas

• Integración de datos, preferiblem ente m edia nte un repositorio com ún

Según la clase de actividad sopo rtada, ten drem os distintos bancos o equipo sde trabajo, entre ellos los siguientes:

EQUIPO DE ANÁLISIS Y DISEÑO, denominado a veces herramienta CASE, oCASE superior ("upper" CASE). Debe ser capaz de soportarcompletamente un a determ inada m etodología. Corresponde a lo queen el apartado 6.3.4 se ha denominado "entorno asociado ametodología". M uchos de estos entornos cubren las dos fases (análisisy diseño), mientras que otros sólo cubren un a d e ellas. El repositorioalmacena en forma estructurada todos los elementos de informacióndefinidos en la metodología soportada, con referencias entre ellos,evitando redundancias y garantizando la consistencia.

Por ejemplo, para soportar la metodología de análisis y diseñoestructurado se incluyen editores de diagramas de flujo de datos,

diccionario de datos, especificaciones de proceso, diagra ma s entidad-relación, diagramas de estructura modular, diagramas de transiciónde estados, etc. La modificación de un elemento desde un editorpuede implicar su modificación a nivel global, con lo que el cambiose apreciará en todos los diagramas o descripciones en que aparezcadicho elemento.

ENTOR NO DE P R OGR AM AC IÓN, es el banco de trabajo para la actividad decodificación, y puede extenderse también al diseño detallado y a laspruebas de unidades. Con mucha frecuencia aparece como entornoasociado a un lenguaje determinado, tal como se describió en lassecciones 6.3.1 y 6.3.2. También puede construirse como colección deherramientas independientes, como se indicaba en la sección 6.3.3,pero en este caso no suele alcanzar un nivel de integración elevado.

Un entorno de programación integrado debe incluir las funciones deedición orientada al lenguaje, compilación y montaje automáticos,depuración, evaluación de métricas, etc.

EQUIPO DE VERIFICACIÓN Y VALIDACIÓN, capaz de facili tar las tareas deinspección y pruebas de módulos y sistemas. En muchos casos suele




estar l igado al entorno de programación, ya que con frecuencia se

necesita operar sobre el código fuente. Puede incluir funciones de:

• Aná lisis estático, con evalu ación de mé tricas de calidad ygeneración de matrices o grafos de l lamadas entre funcionesy módulos.

• Generación de tablas de referencias cruzad as.

• Análisis dinámico, con evaluación del cubrim iento de códigoy perfil de ejecución.

• Gestión de prueb as, auto ma tizan do la realización de ensayos

y comprobando los resultados. Se necesita para realizarcómodamente pruebas de regresión.

EQUIPO DE CONSTRUCCIÓN DE INTERFAZ DE USUARIO. Permite definircómodamente el esquema de diálogo con el usuario, así como loselementos, habitualmente gráficos, de interacción. La definición dela interfaz de usuario suele hacerse en forma interactiva,manipulando directamente la imagen de pantal la correspondiente acada elemento de interacción (menú, icono, botón, etc.).

En la mayoría de los casos el desarrollo de la interfaz de usuarioequivale al desarrollo del programa principal de la aplicación. Confrecuencia se incluye un generador de código que produce el textofuente de dicho program a principal en un lenguaje de programaciónde uso general que debe ser compatible, a nivel de l lamadas afunciones, con el lenguaje de programación usado para desarrollarel resto de la aplicación.

EQUIP O DE GES TIÓN DE C ONF IGUR AC IÓN, que permita almacenar diferentesversiones de los elementos del proyecto, definir distintasconfiguraciones y controlar los cambios sucesivos. Es fundamental

que se combine bien con el entorno de programación si se quiererealizar desarrollo incremental, modificando progresivamente laconfiguración de módulos del sistema en construcción. También esindispensable para gestionar cómodamente las tareas demantenimiento.

Un enfoque tradicional de estos bancos de trabajo consiste en usarun repositorio central para las versiones estables, y materializar lasconfiguraciones como copias temporales, en un directorio separado,de versiones estables combinadas con versiones en desarrollo. Unenfo que m ás evoluciona do consiste en interceptar el acceso al sistema




de ficheros básico, definiendo las configuraciones como sistemas

virtuales de ficheros, en los que un mismo nombre de fichero hacereferencia a una u otra versión dependiendo de la configuración enque se trabaje.

EQUIPO DE INGENIERÍA INVERSA. Debe facilitar la extracción de informaciónde diseño y los elementos abstractos a partir de un código o sistemasoftware ya desarrol lado. Puede incluir herramientas para generartablas de referencias cruzadas, diagramas de flujo de ejecución,recolectar las cabeceras de funciones y procedimientos, reagrupar yreordenar el código fuente, etc. Dada la variedad de situaciones yestilos que p ued en aparece r en el código de a ntiguas aplicaciones, noes posible sistematizar esta actividad, y sólo puede contarse conayudas parciales.

EQUIPO DE GESTIÓN DE PROYECTOS, que facilita la confección de planes detrabajo, con asignación de t iem pos y recursos a las diferen tes tareas,y el seguimiento de su realización. Algunas veces se incluyentambién herram ientas para autom atizar la agenda de t rabajo personalde los miembros del equipo, los calendarios de reuniones,intercambio de mensajes, etc.

6.8 Entornos orien tados al proceso

Un entorno de desarrollo orientado al proceso debe ser capaz de soportartodas las actividades del ciclo de vida de desarrollo, y además hacerlo deacuerdo con una metodología concreta, es decir, siguiendo un modelo dedesarrollo definido. Al hablar aquí de metodología nos referimos ametodología global de desarrollo de software, representada a nivel generalpor un modelo de ciclo de vida. Por supuesto, esta metodología dedesarrollo puede detallarse tanto como se desee, especificando ademásmetodologías concretas de análisis, diseño, programación, etc. Como ya seha indicado, u n en torno global de estas características se suele designar conlas denominaciones IPSE, ICASE, o simplemente ISEE (integrated SoftwareEngineering Environment).

La característica principal que distingue un entorno de esta clase de unbanco de trabajo amplio es el soporte explícito de un modelo global dedesarrollo. El entorno debe poseer, por tanto, las características deintegración del proceso, tal como se describían en la sección 6.6.4, ademásde las de integración de datos, control y presentación.




Para con seguir este nivel de integración es necesario contar con un mo delo

form al del proceso de desarrollo. A diferencia de las me todologías parcialesde análisis y diseño, este modelo de desarrollo suele construirse más omenos a medida de cada empresa productora de software. Por esta razónno existen, en general, productos comerciales disponibles en formainmediata. Un ISEE de uso general deberá permitir, entonces:

• construir la definición form al del mo delo del proceso de desarrollo,y

• aseg urar la aplicación práctica del mo delo definido.

Como ya se ha indicado, no hay, en general, entornos ISEE disponiblesdirectamente como productos comerciales. Lo que sí existen son esquemasgenerales de arquitectura de entornos orientados al proceso, que en algunoscasos han dado lugar al desarrollo de colecciones de herramientas quefacili tan, al menos en parte, las funciones deseadas. Mencionaremos acontinuación algunas de estas propuestas.

Herramienta

de interacción

Herramienta

de interacción

Herramienta

de interacción

Software Bus

Serv idor Serv idor

F i gu ra 6 .5 A rq u i t e c tu ra de l en to rno E SF

P C T E ( P O R T A B L E C O M M O N T O O L E N V I R O N M E N T ) es una arquitectura deentorno integrado basada en un repositorio común. El elementoprincipal de esta propuesta es la definición de la interfaz de accesoa dicho repositorio. El repositorio puede almacenar objetos dediferentes clases, tales como documentos, diagramas oespecificaciones de distintos elementos definidos en el modelo dedesarrollo. Sobre este repositorio pueden operar herramientas que




automaticen las actividades previstas en el modelo del proceso.

Existen implementaciones de repositorios que cumplen con laespecificación PCTE, y también algunas colecciones de herramientas,como las correspondientes al proyecto PACT.

ESF (EUREKA SOFTWARE FACTORY) define otro modelo de arquitectura[Fernstróm92], cuyo elemento central de integración es elden om inad o "software bus", que constituye una interfaz norm alizadapara interconexión de herramientas, tal como se indica en la figura6.5. En ESF se distinguen dos clases de herramientas: servidores yherramientas de interacción. Los servidores pueden realizar lasfunciones de repositorio, tanto centralizado como distribuido, ysum inistrar servicios o funcion es autom atizada s. Las herram ientas deinteracción permiten la comunicación con los usuarios, que puedenacceder a los repositorios y a los servicios a través de ellas.

F i g u ra 6 .6 M o d e l o d e r e f e r e n c i a N I S T / E C M A

El MODELO NIST/ECMA, propuesto por estos organismos (Nat ionalInst i tute of Standards and Technology, y European ComputerManufacturers Association). En este modelo [Chen92], representadoen la figura 6.6, se contempla una infraestructura fija, compuesta por




elementos que proporcionan integración de datos, basada en un

repositorio común, integración de presentación, mediante un soporteglobal de interfaz de usuario, e integración del control, basada en lagestión de procesos y mensajes. El entorno puede particularizarsepara un modelo de desarrol lo determinado instalando sobre estoselemen tos fi jos un a colección particular de herram ientas.

En ausencia de productos CASE listos para usar y capaces de integrarse enuna arqui tectura uniforme, se puede adoptar un enfoque pragmático, ycom binar de la mejor ma ner a posible produ ctos heterog éneos pa ra construirun entorn o global. Un ejem plo concreto es el entorn o ESSDE, recom end adopara proyectos de la ESA (European Space Agency). Este entorno estáconstruido alrededor de dos productos comerciales concretos: Concerto (deSEMA Group) y Rational Ada. El primero es una herramienta CASE dediseño que soporta la metodología HOOD. El segundo es un entorno deprogramación en lenguaje ADA. A estos elementos se han añadidoherramientas adicionales para gestión de configuración, preparación dedocumentación, etc.

ingenieria del software

Documents