Programaci´n Modular. ETSIT. 1o C. o Apuntes del profesor Juan Falgueras.

Curso 2005 21 de febrero de 2005

1 Ingenier´ del software ıa
Contenido
1. Ingenier´ del software ıa 1.1. Desarrollo actual de proyectos de software . . . . 1.2. Ciclo de vida del software . . . . . . . . . . . . . 1.2.1. Modelos orientados hacia la especificaci´n o 1.2.2. Modelos de desarrollo evolutivos . . . . . 1.2.3. Modelos iterativos . . . . . . . . . . . . . 1.2.4. Transformaciones formales . . . . . . . . . 1.2.5. Desarrollo as´ptico . . . . . . . . . . . . . e 1.2.6. Aplicabilidad de cada modelo . . . . . . . 1.3. Fundamentos del dise˜o del software . . . . . . . n 1.3.1. Dise˜o por encapsulado y ocultamiento . n 1.3.2. Modularidad . . . . . . . . . . . . . . . . 1.3.3. TADs . . . . . . . . . . . . . . . . . . . . 1.3.4. POO . . . . . . . . . . . . . . . . . . . . . 1.3.5. Abstracci´n . . . . . . . . . . . . . . . . . o 1.3.6. Ocultaci´n de informaci´n . . . . . . . . . o o 1.3.7. Independencia funcional . . . . . . . . . . 1.3.8. Cohesi´n . . . . . . . . . . . . . . . . . . o 1.3.9. Acoplamiento . . . . . . . . . . . . . . . . 1.4. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 4 4 5 6 9 9 10 10 11 11 12 12 13 13 13 13 13 14

1.

Ingenier´ del software ıa
Objetivos del tema: Presentar al estudiante la problem´tica del desarrollo de las aplicaciones de software. a Conocer el lenguaje general usado y las principales t´cnicas que hist´ricamente se han e o ido cimentando especialmente respecto al desarrollo de grandes aplicaciones; ver muchos de los mitos ya desaparecidos. Convencer al estudiante de la importancia de la reusabilidad del c´digo en el desarrollo o de software. Dar al estudiante criterios de validaci´n de los m´dulos constitutivos de los programas, o o de sus caracter´ ısticas y oportunidad. Introducir a las t´cnicas modernas de modularizaci´n, y programaci´n orientada a obe o o jetos. Se trata ´ste de un tema m´s bien te´rico en el que trataremos de comprender los grandes e a o problemas que envuelven el complejo mundo del desarrollo de las enormes aplicaciones que se est´n imponiendo. a Con la presentaci´n del Ciclo de Vida y las variantes hist´ricas que se han desarrollado, o o trataremos de entender la necesaria organizaci´n que debe existir tras los grupos m´s o menos o a grandes de desarrollo. As´ se presentan los papeles m´s importantes a cubrir en la organizaci´n ı a o

1 Con . o [YC79]). son hoy d´ imprescindibles para cualquier proyecto de ingenier´ Para o ıa ıa. por otro lado. completo respecto a la modularidad en concreto. Las caracter´ ısticas que formalmente debe ofrecer este interfaz lo han de convertir en un conjunto coherente. modularidad. Las correctas costumbres en programaci´n.1 Desarrollo actual de proyectos de software 2 análisis especificación diseño implementación mantenimiento Figura 1: Ciclo de vida en cascada. la programao a ci´n orientada a objetos.. de grupos de trabajo para resolver la compleja e inmensa maquinaria de relojer´ que es una ıa gran aplicaci´n de software.1. dise˜o orientado n a objetos). 2). los tiempos empleados en cada etapa y la misi´n de las herramientas CASE o se pueden ver en el cl´sico [Fis88]. las t´cnicas de implementaci´n concretas (portabilidad. a e Dentro de un ciclo de vida se enumeran y definen las caracter´ ısticas que hacen a un software de calidad (Fig. La modularidad inicialmente y sobre ella. e o 1. ¿qu´ es el dise˜o?. tenemos que entender c´mo la programaci´n es un proceso de ingenier´ en el que o o ıa cada uno de nosotros es parte dentro de un grupo de trabajo1 . Una de las mejores referencias hist´ricas al ciclo de vida del software es la de Yourdon (en o [You88]. dentro del u o e entorno de trabajo a seguir. en el Ciclo de Vida primitivo (ver Fig. estilo. podemos ver la serie temporal inicial de que sit´a esquemas generales de trabajo en cuanto a documentaci´n. por medio e e de modelos. La poca duraci´n de o o o las aplicaciones de software por su insuficiente flexibilidad para adaptarse a las continuamente nuevas necesidades de los usuarios y el alto costo de su desarrollo nos deben hacer ver la gran importancia de seguir buenas t´cnicas de gesti´n de software. Desarrollo actual de proyectos de software ¿qu´ son las especificaciones y de qu´ forma se pueden dar?. finalmente. es recomendable la lectura complementaria del art´ ıculo de Barbara Liskov [Lis81] en la que se desarrolla un ejemplo completo de un programa formateador de textos en lenguaje CLU. o En t´rminos generales se puede llegar a decir que la p´rdidad de reusae e bilidad en inform´tica es su p´rdida de valor. 1). con interfaces de uso perfectamente documentadas. algebraicas. entender esto.1. a un nivel de abstracci´n m´s alto. En adelante se har´ hincapi´ en la realizaci´n de programas mediante m´dulos especificados a e o o formalmente en su totalidad. etc. control de excepciones. verificaci´n (emp´ o ırica y formal) Para plantear la tem´tica de la Ingenier´ del Software es preciso entender: a ıa y. formales. una de las propiedades m´s importantes que garantizan una efi´ a ciente construcci´n de software es la reusabilidad. caracter´ e n ısticas (top-down. a Aunque no la unica. etc´tera. reutilizabie o lidad).

Ada. tipos de par´metros gen´ricos. C++. o En este sentido los lenguajes de programaci´n han ido evolucionando y adoptando estos o criterios en mayor o menor grado dependiendo de su finalidad: C. A lo largo del curso se va a trabajar frecuentemente con o diferentes implementaciones de TADs. al contrario que los diagramas de estructuras. como la de SmallTalk. se presentan los conceptos b´sicos de programaci´n orientada a objetos. tipos.1 Desarrollo actual de proyectos de software 3 Cualidades del Software Corrección Fiabilidad Conveniencia al usuario Adecuado Aprendible Robusto Mantenibilidad Legibilidad Expandibilidad Comprobabilidad Eficiencia Portabilidad Figura 2: Caracter´ ısticas deseables del software y no redundante de procedimientos. fueron precursores de la programaci´n orientada a objetos.. C++. etc. concurrencia. a o .. Se clasificar´n los componentes de software desde el punto de vista de su finalidad y de a las propiedades de su implementaci´n. Tambi´n puede ser asociado en el desarrollo “top-down”. est´n bastante unificados en su presentaci´n a o y simbolog´ En un diagrama de flujo de datos en distintos niveles. instanciaci´n. e vistas en primera aproximaci´n. al nivel de detalle de las operaciones. o con la sintaxis de paquetes de Ada. ıas. etc. Modula2. etc´tera. refiere a las entidades que intervienen. recolecci´n de memoria no o o usado. a niveles inferiores de detalle. Pascal. etc. donde. de miniespecificaciones. Eiffel o etc. hoy presente en todos los lenguajes de desarrollo3 . como sentencias generales que en sucesivas aproximaciones se van a ir refiriendo a o instrucciones a “bajo nivel” 3 Una lectura complementaria que introduce al concepto de programaci´n orientada a objetos es [Boo86]. Esto puede ser o relacionado con el ciclo de vida del software. librer´ y o o a e ıas sublibrer´ lo que repercute en la composici´n de grupos de trabajo. desde un nivel de especificaciones a niveles de detalle en las miniespecificaciones. o Como ejemplo sencillo de esta jerarquizaci´n de niveles que aparecen tanto en relaci´n con o o las estructuras de datos como con las de control podemos ver la diagramaci´n de flujos de datos o que. 2 Es muy importante definir desde un principio lo que se entiende por “nivel de abstracci´n”.1. desde el nivel “cero” que se ıa. que cubran la finalidad del m´dulo en el nivel e o de abstracci´n planteado2 . Estas implementaciones necesitar´n ser caracterizadas por a sus propiedades respecto a diversos conceptos: acotaci´n. Para poder reutilizar los m´dulos y objetos se usan distintos mecanismos y recursos que o permiten la su abstracci´n: genericidad.

Dependiendo del nivel de detalle.1. incluyendo sus entradas y salidas.1. Este modelo consta de varias ıa etapas (Fig. Se prueban los o 3. Dependiendo de la envergadura de la organizaci´n se podr´ llegar a mayor detao a lles o a descripciones abstractas. dise˜o y desarrollo con ı o n tiempos intermedios de separaci´n entre ellas. ıan de las necesidades a programar. Se dan varios pasos. el ciclo de vida del software. en o u 1970.2.2 Ciclo de vida del software 4 1. As´ se definieron actividades delimitadas de especificaci´n. Un modelo de desarrollo de software es una representaci´n abstracta o de las actividades y documentos a realizar en el desarrollo de software. es una actividad estructurada. 1. es a lo que se denomina proceso de software. o Dise˜o del software y del sistema.2. Hoy d´ se denomina a este modelo de desarrollo de cascada. Conforme se iban ampliando las necesidades de software esta carencia de modelos y estructura fue haci´ndose m´s y m´s costosa. Se definen los servicios a prestar y las restricciones a cumplir. Cada organizaci´n sigue su propio proceso de software. 3): Documentos de requisitos Especificación del diseño del sistema Diseño del software y del sistema Implementación y prueba de unidades Integración y prueba del sistema Mantenimiento Programas del sistema Sistema realizado Definición de requisitos Figura 3: Modelo en cascada de desarrollo de software 1. y a veces indistinguiblemente. el modelo puede tambi´n mostrar los papeles responsables de estas actividades. La primera discusi´n p´blica acerca de este “ciclo de vida” del software se debe a Royce. 2. que demanda una gran actividad intelectual y puede exigir gran creatividad a los participantes del mismo. Se identifican los subsistemas y la estructura global del n sistema. Definici´n de requisitos. y en su conjunto. Modelos orientados hacia la especificaci´n o Entre los a˜os 50 y 60 el desarrollo del software fue un proceso muy informal alejado de otras n metodolog´ seguidas en procesos de ingenier´ Usualmente se segu´ descripciones informales ıas ıa. en los cuales se supon´ acabadas las actividades o ıan de las etapas anteriores. Ciclo de vida del software El desarrollo de cualquier sistema de software. Bas´ndose en otros procesos e a a a de ingenier´ las organizaciones fueron adoptando procesos de desarrollo para el software m´s ıa a estructurados. desde que el sistema es dise˜ado y programado hasta que es n validado. desarrollo de software. El desarrollo del software es una actividad muy compleja. pero estos o m´todos particulares suelen seguir a procesos de software m´s abstractos y generales: los modelos e a de desarrollo de software. n Implementaci´n y prueba de unidades. Se desarrollan individualmente los m´dulos que cono o forman el sistema en (uno o varios) lenguajes de programaci´n elegidos. . las e herramientas que se usan para desarrollarlas. A esta secuencia de actividades. incluso el de sistemas triviales. Se pueden seguir m´todos de dise˜o estructurado para el e n desarrollo del dise˜o del software. los tipos de comunicaci´n entre las actividades y los o papeles y situaciones excepcionales a considerar como parte de los procesos.

o o u ı a El modelo evolutivo. 5). . Una vez que el sistema prototipo permite esta comprensi´n. Durante su tiempo de vida. o o es el modelo iterativo en cascada. Se integran y prueban todos los m´dulos como un sistema o o completo. Formulaci´n de un esquema de los requisitos del sistema. Definición de requisitos Documentos de requisitos Especificación del diseño del sistema Diseño del software y del sistema cambios en los requisitos cambios en el diseño cambios en el programa Mantenimiento Implementación y prueba de unidades Integración y prueba del sistema Programas del sistema Sistema realizado Figura 4: Modelo en iterativo en cascada de desarrollo de software 1. tan r´pido como sea posible. Su objetivo es ‘solamente’ el comprender los requisitos reales del usuario. basado en prototipos. 5. Aunque no necesariamente ni o completa ni consistente sino tan s´lo como gu´ para los programadores. o 4. a que resuelve en parte el problema de la simplicidad del modelo de cascada que s´lo muestra una o salida por proceso y el hecho de que esta salida no puede ser reinsertada como parte de la entrada de etapas anteriores.2. Una modificaci´n que permite la iteraci´n en el modelo de cascada se muestra en la Figura 4. el software ser´ modificado siguiendo los requisitos del usuario y reparando los fallos que se a van descubriendo. Mantenimiento. dado la creciente importancia de este aspecto. se deshace o del prototipo. basado en las especificaciones antea riores. o ıa Desarrollo de un sistema. es especialmente importante hoy d´ en el desarrollo ıa de sistemas interactivos. Al no requerir preespecificaciones detalladas ´ e tampoco exige una costosa producci´n de documentaci´n por etapas. 2. Dentro de los modelos evolutivos en general hay dos muy utilizados: Prototipado de pruebas (Fig. Evaluaci´n y modificaci´n del sistema seg´n vayan as´ especific´ndolo los propios usuarios.2 Ciclo de vida del software 5 m´dulos por separado. Integraci´n y prueba del sistema. 3. Las etapas son: o o 1. Cada uno de estos puntos puede naturalmente ser detallado m´s y dar lugar a una descripci´n a o m´s fina en forma tambi´n de cascadas.2. Modelos de desarrollo evolutivos Los documentos producidos al final de cada etapa pueden convertirse en obst´culos en tanto a en cuanto las sucesivas etapas no podr´n empezar hasta que ´stos no se acaben.1. a e Entre las muchas variantes surgidas de este ya bien asentado modelo est´n el modelo en V. Se instala y pone en funcionamiento el sistema. En los modelos a e evolutivos se produce un sistema rudimentario inicial que evoluciona seg´n las necesidades del u cliente hasta cumplir con los requisitos ultimos de ´ste.

divide el proceso en conjuntos de procesos menores.1. Evalución de prototipo Figura 6: Desarrollo mediante prototipados que evolucionan. Una vez o o que uno de los incrementos se ha completado y puesto en funcionamiento. . El el modelo incremental el cliente identifica y esquematiza los servicios esperados por el sistema prioriz´ndolos. a El modelo incremental sugerido por Mills. Los prototipos sucesivos son modificados hasta constituir el propio software que finalmente usar´ el cliente. no muestran claramente los momentos. el incremental y el modelo en espiral son los m´s importantes de los modelos iterativos. Esta priorizaci´n es tenida en cuenta a la hora del desarrollo. Entrega de sistema Especificación abstracta Construcción de prototipo Entrega de prototipo Propuesta nuevos requ.2. De la esa o quematizaci´n y divisi´n surgen partes a ser resueltas por distintas partes del sistema. el cliente puede usarlo teni´ndose as´ en cuenta sus sugerencias tanto para mejorar esa parte como para reestructurar e ı y mejorar las dem´s. en 1980. Modelos iterativos Los modelos evolutivos aunque permiten la interacci´n entre las etapas del desarrollo.3. 6). que se identifican y resuelven por separado. No es imprescindible utilizar el mismo proceso con cada incremento en el a desarrollo. Dos modelos de desarrollo.2 Ciclo de vida del software 6 Prototipado evolutivo (Fig. no o lo hacen de una manera. a Esquema de requisitos Desarrollo de prototipo Evaluación de prototipo Especificación de sistema Desarrollo de software Validación de sistema Figura 5: Prototipado de pruebas desechables. 1.

Esto dificulta a´n m´s la independencia de las partes del u u a sistema. a Cada fase se representa mediante una vuelta de espiral y cada vuelta pasa por cuatro etapas (Fig. normalmente no son independientes y la consecuci´n de uno implica el desarrollo de varios. Identificaci´n de los incrementos que deben ser relativamente peque˜os (de no m´s de unas o n a 20. o 2. Antes de entrar en la siguiente a o fase se debe tener una completa evaluaci´n de los riesgos involucrados. desde una concepci´n inicial. Ve el desarrollo del proyecto como una espiral. pero no pospone las especificaciones de ninguna otra de manera que se puedan prever los contratos y fechas de trabajo.2 Ciclo de vida del software 7 Aunque las ventajas son evidentes. ıcil que usualmente debe fijarse con horarios y fechas desde el principio. Los requisitos. Fue propuesto inicialmente por Boehm en 1988. requisitos del cliente con funcionalidades del sistema. o Este modelo se caracteriza por permitir revisiones regulares del progreso logrado frente a objetivos bien definidos de manera que no sufre de problemas usuales en los modelos de prototipos. en el centro. Infraestructura necesaria Muchos sistemas exigen de la implantaci´n de una infraestructura o com´n a varias partes del sistema. Los riesgos se consideran o una falta de informaci´n de manera que para resolverlos es necesaria la recogida de informaci´n y o o su an´lisis. siendo dif´ en muchos casos asociar o ıcil. como: e 1.1. 3. 8) . hasta el desarrollo final del sistema.000 l´ ıneas de c´digo) y cubrir alguna funcionalidad. Este modelo est´ basado en una constate evaluaci´n de riesgos. es o a dif´ llevar un sistema de contrataciones y organizar el trabajo del personal involucrado. Definición del esquema de requisitos Priorización de requisitos Asignación de requisitos a incrementos Diseño de la arquitectura del sistema Desarrollo de servicios básicos Especificación de un incremento del sistema Desarrollo de un incremento del sistema Validación del incremento NO Integración del incremento Validación del sistema ¿Está completo el sistema? SÍ Entrega final Figura 7: Modelo de desarrollo incremental Este ultimo aspecto se elimina en la variante de entrega incremental que sigue las primeras ´ etapas. En el modelo en espiral cada parte se resuelve independientemente teniendo muy en cuenta los costos y riesgos. Gesti´n de los contratos Ya que partes del sistema no se saben cu´ndo van a empezar. los inconvenientes tambi´n aparecen.

2.2 Ciclo de vida del software 8 1. con la posible actividad de resoluci´n de a o riesgos mediante construcci´n de prototipos. co mpa Requ. 3 Protot. 2. o Fase de desarrollo. o de e ón as ci f ca te ifi ien an u pl sig la Figura 8: Modelo en espiral de Boehm original. 4. 3. Establecimiento de objetivos y restricciones de esa vuelta. operativo Concepto de operaciones odelo s. r alte sg es rn de riesgos os olu at ció iva n s. m Protot. etc. Aqu´ un fallo en la interfaz ser´ un desastre a ı ıa para el sistema completo. que puede acompa˜ar a la del dise˜o. . por ejemplo. 1988.1. mientras que en sistemas de m´s compleja definia ci´n de requisitos. Fase de an´lisis de riesgos frente a los objetivos. 1 Sim ula cion es. al tipo de uso que se o quiere del sistema. por otro lado esenciales a la hora de prever fechas de contrataci´n. n Las dos grandes dificultades de este modelo son 1. como en los sistemas altamente interactivos. por ejemplo en un sistema que pretende ser de tipo “walk up and use”. o ı Fase de planificaci´n. ya que este modelo trata de evitar decisiones prematuras. Los problemas de contrataci´n. Donde no hay un gran riesgo en la recogida de requisitos se convierte en un sencillo modelo en cascada. programaci´n y actividades de n n o validaci´n. La dificultad del an´lisis de riesgos. Aqu´ podemos usar un modelo en cascada. de Análisis de riesgos ob D je et tiv er os m y ina re ció st n ric d ci e on es Análisis de riesgos Análisis de riesg REVISIÓN plan de requisitos y de ciclo de vida Prot. Esto se resuelve en la etapa que corresponda mediante la construcci´n de o bocetos y prototipos parciales que habr´n de testearse ampliamente antes de abordar su desarrollo. en la que se planea la siguiente iteraci´n. que requiere personal con experiencia y altamente espea cializado. el sistema puede ser considerado o como un sistema evolutivo con las actividades de prototipado dominando y un tercer cuadrante relativamente peque˜o (ver Figura 8). de SW plan de desarrollo integración y plan de pruebas Validación requis.v e aceptación lo d ol ivel servicio rr sa e n Deient u sig rativ as Un t´ ıpico riesgo es la inadecuaci´n de la interfaz de usuario. en el que se requerir´ una gran facilidad de manejo para todos. Diseño Diseño producto detallado código test diseño unidades n n v&v ió ió test ac ucc integración ific rod test er p . o que son. o o E ide val nt uac ific ió ac n d ió e Análisis rie n. 2 Prot. a Este modelo abarca a otros.

ıa 1. Esencial por el hecho de permitir la integraci´n de partes formalmente o correctas. Adem´s a´n no est´ muy claro c´mo aplicarlo al desarrollo de interfaces de usuario.5. a como se ha dicho de t´cnicas formales suficientes para software medianamente complejo. a u a o ya que a´n est´n muy verdes las formalizaciones del proceso de interacci´n persona-ordenador. como por ejemplo. o e . Para estos sistemas ni siquiera el enfrentamiento del resultado a una bater´ de datos de prueba es suficiente. dado que estas pruebas demuestran tan s´lo la ıa o posibilidad de que existan errores. sistemas de seguridad. como el de control ferroviario. Es el aspecto m´s delicado de este modelo por carecerse. Sin embargo exige a que los desarrolladores dominen t´cnicas de especificaci´n y manipulaci´n matem´ticas.2. Toma su nombre del usado para las salas para la fabricaci´n de semiconductores donde se trata de tener un ambiente absolutamente o exento de impurezas que pudieran introducirse en las obleas de silicio. no su total ausencia. 1. Combina aspectos o del desarrollo incremental y el de transformaciones formales.2. s´ que se llega a emplear en algunos sistemas de a ı seguridad cr´ ıticos. seg´n un modelo de Littlewood de 1990.1. lo que es e o o a muy costoso. Desarrollo formal del software. Transformaciones formales En aquellos sistemas en los que el resultado debe seguir fielmente las especificaciones. u Este modelo parece confirmar en la pr´ctica una alta fiabilidad de los resultados. 3.2 Ciclo de vida del software 9 Este modelo requiere de un alto grado de cercan´ o confianza entre el cliente y los desarrolladores. Las caracter´ ısticas que lo definen son (Fig. en determinadas fases del desarrollo. u e o n Prueba estad´ ıstica. 2.4. Desarrollo as´ptico e El desarrollo en sala as´ptica (Cleanroom process) se desarroll´ en IBM a partir de trabajos e o sobre programaci´n estructurada de 1970 a partir de 1987 por Mills y Linger. etc. e Desarrollo incremental. 9): 1. La unica opci´n posible en estos casos ´ o es la elaboraci´n de una metodolog´ que matem´ticamente demuestre la correcci´n del c´digo o ıa a o o construido. u a o Requisitos del sistema Especificación formal del sistema Definición de incrementos de software Desarrollo del sistema Verificación FORMAL del código Integración de incrementos Pruebas estadísticas al diseño Pruebas al sistema integrado Figura 9: Proceso de habitaci´n as´ptica (Cleanroom process).. el sistema de ciclo de vida en cascada no es apropiado. seg´n las t´cnicas formales que lo permiten demostrar s´lo cuando son peque˜as. La fiabilidad del software se eval´a seg´n el n´mero de fallos detectados u u u en el proceso de datos de muestra. Aunque este sistema no se haya muy extendido debido fundamentalmente a la a´n u incapaz an´lisis y formalizaciones existentes.

Se encuentran pues. Interfaces de usuario dif´ ıciles de especificar.3. 1992). diagramas de flujo de datos (DFDs). Object Pascal (Tesler. b-u y t-d. no incluyendo interacci´n personao ordenador. etc. Podemos resumir en una tabla los modelos vistos aqu´ ı: Modelo Cascada Prototipo Aplicabilidad Sistemas de especificaciones n´ ıtidas. resultan incompletos a la hora de determinar la correcci´n o respecto a especificaciones y son inadecuados en el dise˜o de sistemas interactivos ya que alejan n . Adecuados para el desarrollo interno en empresas. e El dise˜o basado en refinamientos sucesivos nos lleva a acercarnos a niveles de detalle en los n procesos en un enfoque top-down (t-d). se han fijado en las caracter´ n ısticas funcionales de las aplicaciones. o Partes de sistemas pero con desarrolladores intercomunicados. principalmente en programaci´n. ObjectStore. Ada y Modula-2. Estos dos enfoques. Sistemas de bien conocidos requisitos de infraestructura (sobre bases de datos. etc. por ejemplo). en 1972) y basado en el uso de Tipos Abstractos de Datos (TADs. Lenguajes o como Ada 95. En la d´cada de los 70 se ampli´ a t´cnicas o e o e de diagramaci´n de flujo de datos (DFD) y diagramas de entidad-relaci´n (ERD). Sistemas muy peque˜os pero de seguridad cr´ n ıtica. Desarrollo subcontratado. Orion. El enfoque bottom-up (b-u) aunque est´ tambi´n orientado al aspecto funcional del software a e se concentra en la informaci´n y su uso. utilizan este paradigma. Java. Software que requiere prototipos para pruebas de mercado. Por entonces fue o o cuando se empezaron a plantear las cuestiones de necesidad de desarrollo de software modular (en trabajos de Parnas. C++ (de Stroustrup. a Los enfoques de dise˜o top-down. O2. as´ sin problemas ı. DFDs. de contrataci´n. 1985). se puede concluir que no existe un modelo ideal y la aplicabilidad de cada cual depende del tipo de proyecto. Aplicabilidad de cada modelo En resumen. en 1986). Tradicionalmente se han desarrollado t´cnicas en el dise˜o del software: top-down (t-d). bottom-up. las tareas que los pueden gestionar.2. Evolutivo Incremental Espiral Formales As´ptico e 1. a partir de los datos. Grandes sistemas particionables y de altas exigencias de fiabilidad.3 Fundamentos del dise˜o del software n 10 1. etc. Gemstone.6. A partir de los datos reales que se deben manejar en la o aplicaci´n. Eiffel (Meyer. El concepto de m´dulo fue experimentado a finales de los 70 o por Niklaus Wirth (en 1977) y hasta principios de los 80 d´nde se uso como base de lenguajes o fundamentales como Smalltalk-80. Modula-3. Partes de sistemas grandes. Sistemas comerciales peque˜os o medianos dependientes de una base n de datos. e n bottom-up (b-u). Desde mediados de los 80 y durante los 90 ha habido una emergente necesidad hacia la programaci´n orientada a objetos (POO). Hist´ricamente est´n muy ligados a los lenguajes de programaci´n o a o imperativos o procedurales como Fortran. diagramas de entidad relaci´n o (DER) y m´quinas de estado finitos (MEF). Pascal o C ya que son estos lenguajes los que se definieron con aqu´llos enfoques. en especial con los trabajos de Liskov en 1975). Fundamentos del dise˜ o del software n Durante los a˜os 60 el unico m´todo que se empleaba para el dise˜o de los programas era el de n ´ e n los diagramas de flujo.1. y tambi´n lenguajes de gesti´n de bases datos como e o Ontos. Sistemas interactivos de vida corta. se identifican los aspectos comunes entre ellos y se sintetiza en un proceso ascendente o para conseguir un conjunto de funciones que cubran el acceso y proceso de aquellos datos. Smalltalk (Goldberg. 1989). Grandes sistemas claramente particionables.

Modularidad El concepto de m´dulo fue propuesto inicialmente por Parnas a principio de los 70 y fue impleo mentado en lenguajes como Modula-2 y Ada. Es considerado el complemento de la cohesi´n. Son adem´s principios muy importantes en n a muchos otros enfoques de dise˜o. sencillo y bien definido. e Los DER sirven para detallar las estructuras de datos y su interrelaci´n complementando o as´ la descripci´n m´s grosera de los DFDs. Los m´dulos formalizaron este proceso reconocieno do la particionabilidad de los programas en unidades discretas con una interacci´n expl´ o ıcitamente representada y. ıan e o 1. incluy´ndose hoy en ellos relaciones de herencia. 1. n Los DFDs permiten el dise˜o atendiendo a los datos.3. Permite la continua y necesaria mejora de los m´duo o los/TADs. u o Entre los defectos de los DFDs est´n su incapacidad para la representaci´n de iteraciones a o entre tareas. o a a uno-a-muchos o muchos-a-muchos) y atributos. perfectamente definida. Son sin embargo enfoques a adecuados a problemas peque˜os y bien definidos. Los DER utilizan la interrelaci´n para modelar las ı o a o ´ asociaciones de informaci´n est´ticas entre entidades. e Las MEF capturan los aspectos de control del sistema.3 Fundamentos del dise˜o del software n 11 el desarrollo de las funciones del sistemas de la interfaz que los usar´. o Los DFDs son muy populares y a´n hoy se usan dado su sencillez de interpretaci´n. Para ello establecen estados que representan puntos funcionales del dise˜o. Facilitan su o modificaci´n. Dise˜ o por encapsulado y ocultamiento n El dise˜o de software usando m´dulos y TADs est´ basado en conceptos como: n o a Separaci´n de objetivos y modularidad. a las entradas y salidas. Se pueden ejecutar cambios en el interior de la estructura interna de cada componente sin afectar al resto de los m´dulos o TADs. Individualmente cada unidad de programa encapsulaba la funcionalidad deseada para una tarea y ofrec´ una interfaz para su cliente (otro ıa m´dulo) mientras ocultaba su implementaci´n. Al ocultarse los detalles se tiene una m´s o o a amplia perspectiva durante el desarrollo. o Particularmente se ve´ que una estructura de datos dada mostraba siempre una compa˜´ de funıa nıa ciones que permit´ su acceso y posibilidades. por tanto. Antiguamente se dec´ que un procedimiento deber´ ıa ıa tener como m´ximo una p´gina de largo (unas sesenta l´ a a ıneas). . hasta llegar a las miniespecificaciones.2. Un sistema de bajo acoplamiento entre compoo nentes. Su origen estuvo en el examen de programas reales que mostraban soluciones de enfoque comunes independientemente del dominio de la aplicaci´n.3. Si as´ fuera. El acoplamiento significa interdependencia entre componentes. En lenguajes como C esto se recog´ organizando en ıan ıa ficheros separados la estructura del programa.1. el sistema ser´ ı ıa juzgado como coherente. o a o Mediante la jerarquizaci´n de los diagramas. tiene asimismo poca interacci´n entre ellos. Permiten la divisi´n del trabajo de desarrollo. Cohesi´n/acoplamiento. Esta representaci´n del sistema permite adem´s la exploraci´n de las funciones en detalle. Estas tendr´n cardinalidades (uno-a-uno. Permiten abordar grandes problemas. Son una notaci´n semiformal e incompleta y deben ser complementados con otras o t´cnicas. lo que a su vez los hace m´s f´ciles de o a a controlar. o o Abstracci´n e independencia de la representaci´n. Un m´dulo es coherente si cada parte en ´l est´ orientada hacia un o o e a objetivo claro. representando con arcos etiquetados los diferentes valores n (en forma de frases) que causar´ a aqu´l estado un cambio o transici´n a otro estado.1. o Incremental/anticipaci´n de cambios. o o Los m´dulos ofrec´ pues la posibilidad de encapsular la funcionalidad y permitir futuros o ıan cambios. caracterizaci´n n o de los datos que deben llegar y salir y de los procesos que descritos sobre todo en funci´n de la o manera de transformar esos datos.

TADs que pueden ser semejantes pero s´lo difieran en alguna peque˜a caracter´ o o n ısticas tendr´n igualmente que ser implementados por separado con la repetici´n del c´digo. Incrementa la productividad. con un fuerte paralelismo con el concepto de TAD. su concreci´n en un lenguaje OO o es contradictorio. -. e o Dado que los enfoques DFD y DER son en parte contrarios. o Favorece la reusabilidad del software. siendo una t´cnica o e orientada a los dise˜adores de software m´s que a los usuarios finales de los programas. Los m´dulos encajaban bien con las descripciones de los DFDs y DER. comportamiento de TADs.1. Adem´s la carencia de patrones y la falta de la herencia de caracter´ a ısticas hacen que la construcci´n de TADs en un proyecto pueda dar lugar un alto grado de redundancia o de c´digo. n a 1. e o Encapsular y ocultar los aspectos no definidos.3. La diferencia fundamental con el TAD est´ en el concepto de herencia. div y mod) nos abstraen del mecanismo interno de su implementaci´n. o La implementaci´n privada de los TADs queda oculta al cliente del mismo. que estas t´cnicas son particulares para cada parte del proceso. o Definir las t´cnicas de manipulaci´n para cada unidad. que es el propio o dise˜ador en otra parte del dise˜o. o sin embargo. modificaci´n y recorrido. que reflejan todo su comportamiento externo. o Aunque no hay un total acuerdo en cuanto a la terminolog´ respeto al dise˜o OO. o n No existen t´cnicas globales que permitan la transici´n de DER directamente hacia una POO.3. o Describir el prop´sito de cada unidad. Para ello debemos: o a Identificar las unidades de informaci´n principales. Por ejemplo. podemos ıa n describir los siguientes conceptos comunes: . Facilita la evoluci´n del software. *. n n En realidad los TADs no son una idea nueva como concepto ya que los tipos definidos por los lenguajes de programaci´n tienen m´s que ning´n otro. 1.3. Claramente las ventajas del uso de los TADs son las mismas que la del uso de los m´dulos. La herencia permite la compartici´n controlada a o de propiedades entre objetos/clases permitiendo as´ el recoger tanto datos componentes como ı operaciones admisibles desde el supertipo o superclase al subtipo o subclase. Controla la consistencia de la informaci´n. La POO es adecuada porque: Refuerza la modularidad.4. los errores se pueden e arrastrar a todos ellos. o a u el tipo entero y las operaciones que lo permiten manejar (+. o Los TADs dan lugar a una programaci´n m´s orientada a los datos y su uso. TADs Los TADs fueron propuestos inicialmente por Liskov para el lenguaje de programaci´n CLU o a finales de los 70. Un TAD est´ caracterizado por una informaci´n almacenable y una serie de a o procedimientos de acceso.3 Fundamentos del dise˜o del software n 12 Desde muchos puntos de vista la modularidad reflejaba el enfoque top-down del refinamiento por pasos sucesivos. POO La transici´n hacia el dise˜o OO a partir de las especificaciones no es una actividad trivial. Es por esto que la mayor´ de los lenguajes OO encierran su propio enfoque de ıa lo que es el proceso de dise˜o utilizando una unidad de encapsulamiento/abstracci´n llamada tipo n o de objeto o clase. Estas a o o carencias hacen de los TADs menos reutilizables.

7. que repiten todos o parte de la composici´n del ancestro. Si existen varios la multiplicidad implicar´ mayor dependencia o a de m´dulos externos as´ como una m´s complicada idea de su funcionamiento. es imposible de evitar totalmente siendo una cao racter´ ıstica natural un acoplamiento controlado entre los m´dulos. sin embargo. Cohesi´n o La cohesi´n es la cualidad m´s importante para hacer que los m´dulos sean independientes o a o ya que representa el hilo conductor que une internamente las piezas de un m´dulo. Representa su estado interno caracterizando la o instancia. Pero e n siempre tomando como punto de partida el conjunto de propiedades de la superclase.6. La independencia funcional facilita la ocultaci´n de la informaci´n al no revelar ning´n detalle o o u de su mecanismo a ning´n otro m´dulo. llamada a m´todo.9. simplificadamente. o La abstracci´n en el desarrollo del software se consigue mediente la independizaci´n de los o o detalles en bloques no visibles. ı 1. e o Informaci´n: tipos privados de un TO/clase. Acoplamiento El acoplamiento entre m´dulos surge de la falta de coherencia interna de los mismos o su o complicada definici´n.5. Ocultaci´n de informaci´n o o La ocultaci´n de la informaci´n permite la abstracci´n de detalles as´ como la privacidad del o o o ı desarrollo y tambi´n la seguridad de acceso. Herencia: compartici´n controlada de la informaci´n/m´todos entre TO/clases entendi´no o e e dose esta compartici´n como una herencia de m´s TO/clases m´s generales a otros m´s o a a a particulares. subclases. o ı a 1. Abstracci´n o La abstracci´n es una t´cnica de desarrollo muy potente que permite ignorar los detalles y o e utilizar tan s´lo los elementos. e La ocultaci´n de la informaci´n exige la creaci´n de m´dulos aislados y el aislamiento de los o o o o m´dulos exige su independencia funcional. de un nivel m´s abstracto en o a el que s´lo nos interesan caracter´ o ısticas dadas del m´dulo o componente de software. que puede ser lanzada por la propia instancia sobre o e s´ misma o otras instancias de otros. Si este hilo es o unico y sencillo todas piezas del m´dulo encontrar´n los elementos necesarios para su funciona´ o a miento dentro del propio m´dulo. probablemente algunos de sus m´todos/datos. y a˜adiendo o eliminando otros. substituo yendo.3. 1. o 1.3. Independencia funcional Es una necesidad para varias de las caracter´ ısticas antes mencionadas: la reutilizaci´n de eleo mentos implica manejar elementos realmente independientes. Instancia: Concreci´n en un TO/clase de una informaci´n y m´todos. En general.1. Esta dependencia controlada se o .3. M´todo: procedimiento requerido para una acci´n particular contra los datos privados del e o TO/clase.3.3 Fundamentos del dise˜o del software n 13 Tipo objeto/clase: sirve para modelar las caracter´ ısticas (en forma de informaci´n recogible) o y el comportamiento (m´todos utilizables) para una aplicaci´n. menos farragosos. ya que en otro caso.3.8. la complicaci´n o a˜adida por los m´dulos dependientes los hace menos utiles ni interesantes en distintos proyectos n o ´ o partes distintas del mismo. u o 1. o o e Mensaje: Acci´n.

Technical report. 1988. 1979. Pressman.. Structured Design. MIT.4. [You88] Edward Yourdon. del mismo.4 Referencias 14 consigue estableciendo t´cnicas de comunicaci´n e intercambio de datos/control entre los m´dulos. second edition. este art´ ıculo basa un ejemplo desarrollado en CLU en la abstracci´n y stepwise refinement de Dijstra y Wirth. Software Engineering. Un m´dulo o sin datos de entrada tendr´ siempre el mismo comportamiento y por lo tanto no tendr´ ning´n ıa ıa u inter´s ni uso. 1996. e 1. M´s breve y a ıa a con menos bibliograf´ ıa. McGraw-Hill. [Som96] Ian Sommerville. El a ıan o fan in o abanico de par´metros de entrada de una funci´n o m´dulo deber´ ser peque˜o (no m´s a o o ıa n a de tres par´metros) as´ como el fan out o abanico de datos de salida. IEEE Transactions on Software Engineering.2. Case. Referencias Textos fundamentales. esperados. ıa a Ya va por la cuarta edici´n. February 1986. Juan Falgueras Dpto. Fisher. Referencia obligada para todos los programadores. Cambridge. Mass. Sci. Barbara Liskov. 1988. Ofrece o una visi´n global y muy completa de todos los problemas y modelos de la programaci´n o o de sistemas. Eng. 12(2):211–221. traducidos y asequibles son los de [Pre93] y [Som96] Referencias [Boo86] Grady Booch.32 . [Pre93] Roger S. Prentice-Hall. Addison-Wesley. Modular program construction using abstractions. Using Software Development Tools. [Fis88] [Lis81] Alan S. Un enfoque pr´ctico. of Elect. Extensa bibliograf´ ıa. Yourdon Press. Sin a ı embargo es este acoplamiento controlado el que permite hacer con los m´dulos distintas operao ciones y desvelar el comportamiento de los mismos con distintos datos o situaciones. 02139/USA. e o o Los par´metros que se env´ en una llamada a otra funci´n son parte de este acoplamiento. 1993. and Comp. Object-oriented development. Cl´sico a introductorio sobre la problem´tica general de la Ingenier´ del Software. Puede resultar un poco superficial en algunos terrenos debido naturalmente al espacio limitado del texto. March 1981. Fundamentals of a Discipline of Computer Program and Systems Design. Managing the System Life Cycle. 5th edition. Constantine. Lenguajes y Ciencias de la Computaci´n o Universidad de M´laga a Despacho 3. Ingenier´ del Software. Interesante y sencillo de leer. [YC79] Edward Yourdon and Larry L. Dept.1. El ejemplo es un detenido desarrollo o de un formateador de texto. John Wiley & Sons.

Sign up to vote on this title
UsefulNot useful