mantenimiento del software 1

Análisis, Diseño y Mantenimiento del Software

Manuel Arias Calleja y Ángeles Manjarrés RiescoDpto. de Inteligencia Arti�cial - ETSI Informática - UNED

Actualizada en Octubre de 2006Parte correspondiente al primer parcial

Índice general

Guía de estudio de la asignatura VPresentación y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VContexto y conocimientos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VEsquema y resumen de contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIMaterial y medios de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

1. Contexto de la asignatura en la Ingeniería de Software 11.1. Necesidad de una metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1. Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2. La crisis del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3. De�nición de metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.4. Finalidad de una metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.5. Taxonomía de las metodologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Ciclo de vida del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.1. Ciclos de vida en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2. Modelo de ciclo de vida en espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.3. Ciclos de vida orientados a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3. Notaciones de especi�cación y diseño (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.2. Modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.3. Modelo estructural estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.4. Modelo de comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.3.5. Modelo estructural de implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2. Fase de especi�cación 272.1. Obtención de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.2. Técnicas de obtención de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3. Representación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.4. Análisis orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.5. Validación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.6. Bases de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3. Fase de diseño 433.1. Conceptos y elementos del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1.1. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2. Diseño estructurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3. Diseño orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4. Validación y con�rmación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4.1. Revisión del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.2. Veri�cación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.3. Validación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.5. Documentación: especi�cación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4. Fase de implementación 534.1. Guías de estilo de codi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.1. Traducción del diseño a la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.1.2. Estilo de programación orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.3. Normas para programadores en C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1.4. Normas para programadores en C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61III

IV Índice general

4.1.5. Normas para programadores en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2. Técnicas de depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3. Documentación del código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.3.1. Tipos de comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3.2. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Bibliografía 75

Índice alfabético 76

Guía de estudio de la asignatura

Autores: Manuel Arias Calleja. Basado en una versión del año 2003 por Manuel Arias Calleja y José Ramón Álvarez Sánchez.

Revisado: Octubre de 2006 por Manuel Arias Calleja y Ángeles Manjarrés Riesco

Revisión de los elementos del UML: Ángeles Manjarrés y Manuel Arias Calleja

Revisión de los principios de orientación a objetos: Manuel Arias

Asignatura: Análisis, Diseño y Mantenimiento de Software

Código: 55-402-4 (4o curso de la titulación: �Ingeniero Informático�)

Breve descripción:Análisis y de�nición de requisitos. Diseño, propiedades y mantenimiento del software.

Presentación y objetivosEl objetivo principal de la Ingeniería del software (IS) es el desarrollo y mantenimiento de software de forma sistemática y

productiva, asegurando su calidad, �abilidad y facilidad de uso. Los enfoques más comunes de la docencia de la IS, se centranen el análisis de los procesos de desarrollo y mantenimiento, así como de las técnicas integrales y de apoyo al servicio de laobtención de productos de alta calidad que satisfagan al usuario.

Esta Guía didáctica está diseñada para conducir el estudio de la asignatura en sus aspectos puramente técnicos, que seránlos evaluados en las pruebas presenciales. En la Guía de Curso se detallan objetivos docentes adicionales que serán cubiertosmediante actividades NO obligatorias que los alumnos podrán seguir en los cursos virtuales a la vez que estudian el temarioconvencional.

Contexto y conocimientos previosContexto académico previo

Ingeniería del software es una materia troncal del segundo ciclo que en la titulación de Ingeniero en Informática, impartidapor la ETSII de la Universidad Nacional de Educación a Distancia (Resolución de 21 de marzo de 2001, BOE 10 de abril), se hadividido en dos asignaturas obligatorias y anuales del cuarto curso, cada una de las cuales tiene asignados 9 créditos (5 teóricos y4 prácticos). Las denominaciones que se han dado a estas dos asignaturas complementarias son Análisis, Diseño y Mantenimientodel software (descrita como �Análisis y de�nición de requisitos. Diseño, propiedades y mantenimiento del software�) y Análisis yGestión del Desarrollo del Software (descrita como �Análisis de aplicaciones. Gestión de con�guraciones. Plani�cación y gestiónde proyectos informáticos�).

Ambas asignaturas se hayan fuertemente vinculadas, en tanto que se complementan para proporcionar una visión general delproceso completo de la producción de software, tanto desde un punto de vista técnico como humano, vertientes que caracterizantodo proceso de ingeniería.

El programa de la asignatura Análisis y Gestión del Desarrollo del Software está estructurado en dos cuatrimestres. El primercuatrimestre se dedica al Proceso Software Personal (PSP), cuyo objetivo es la adquisición de una correcta disciplina personalpara el desarrollo de un software de calidad en los plazos y costes comprometidos. El segundo cuatrimestre está dedicado ala gestión global del proceso de desarrollo software en el que intervienen decenas o centenares de ingenieros. Su objetivo estambién obtener un software de calidad en los plazos y costes plani�cados, si bien en este caso se destacan la problemática y lastécnicas asociadas al trabajo en equipo. Las asignaturas de Ingeniería del software deberían, idealmente, ser cursadas en paralelopor los alumnos, dado su carácter mutuamente complementario. En de�nitiva, el objeto de la asignatura Análisis y Gestión delDesarrollo del Software es mostrar cómo se evalúan las técnicas de ingeniería estudiados en la asignatura Análisis, Diseño yMantenimiento del software, y cómo se aplican en un contexto profesional.

Otras asignaturas relacionadasSon muchas y diversas las asignaturas de la titulación relacionadas con la asignatura Análisis, Diseño y Mantenimiento del

Software. El haber cursado algunas de estas asignaturas (o bien las asignaturas equivalentes de carreras impartidas en otrasuniversidades) es requisito imprescindible para su adecuado seguimiento.V

VI Índice general

En concreto, es razonable esperar que el alumno matriculado en Ingeniería del software haya seguido previamente las asig-naturas obligatorias del primer ciclo Ingeniería del software e Ingeniería del Software de Gestión, como iniciación a la materiaobjeto de esta memoria (dada la extensión de los contenidos, es conveniente que el alumno parta de una visión introductoria ygeneral de la ingeniería de software, conozca los modelos de ciclo de vida básicos y alguna metodología estructurada).

Por otro lado, el alumno sólo podrá dar pleno sentido al contenido de esta materia si ha cursado las asignaturas que seencuadran en el componente que en la sección anterior se ha etiquetado por Fundamentos de la computación. Entre tales asig-naturas se cuentan las relacionadas con la teoría de la programación (Programación I, Programación II, Programación III, Es-tructura de Datos y Algoritmos y Lenguajes de Programación, todas ellas asignaturas obligatorias del primer ciclo), y las queestudian la teoría de la computabilidad (Teoría de autómatas I, Teoría de autómatas II). (Obviamente, la comprensión de lasmencionadas asignaturas a su vez ha exigido del alumno los conocimientos matemáticos que se proporcionan en las asignaturasLógica matemática, Análisis Matemático, Algebra, Ampliación de Matemáticas y Matemática discreta.

Resulta asimismo altamente recomendable que el alumno haya cursado también algunas asignaturas relacionadas con lostemas anteriores pero de una orientación más práctica y especí�ca. Es el caso de las optativas del tercer curso ProgramaciónConcurrente, Programación Declarativa y Programación Orientada a la Inteligencia Arti�cial (orientadas a la programación), yDiseño y Evaluación de Con�guraciones, y Con�guración, Diseño y Gestión de Sistemas Informáticos.

Es también de interés, si bien no imprescindible para la asimilación de los contenidos, que el alumno disponga de conocimien-tos del campo de la Inteligencia Arti�cial. En particular, la asignatura Sistemas basados en conocimiento I, asignatura optativadel tercer curso, aborda el estudio de las diferentes fases del ciclo de desarrollo de un sistema experto, coincidentes en lo esencialcon las fases de desarrollo de los productos software convencionales. Sin duda el alumno que haya estudiado esta asignaturadispondrá de una visión más abierta, y la re�exión sobre los paralelismos y discrepancias entre ambas disciplinas le ayudará aprofundizar en la materia. De hecho, a medida que aumenta la complejidad de las aplicaciones software en dominios no tradi-cionalmente abordados por la Inteligencia arti�cial, la ingeniería del conocimiento y la IS convencional han ido eliminandoprogresivamente sus difusas fronteras, y comenzado a bene�ciarse mutuamente de sus respectivos avances. En concreto, el usode las técnicas OO se ha generalizado en todos los ámbitos, y las técnicas de formalización de requisitos se ven enriquecidaspor los interesantes resultados obtenidos en el campo del procesamiento del lenguaje natural, tradicionalmente estudiado en laInteligencia Arti�cial. El conocimiento de los principios básicos de la Inteligencia Arti�cial, que se estudian en la asignaturaobligatoria del segundo curso Introducción a la Inteligencia Arti�cial, es también sin duda de utilidad en este contexto.

En el programa del 4o curso existe un grupo de asignaturas que guarda una evidente relación con la Ingeniería del software, yque resulta interesante que el alumno estudie en paralelo con las asignaturas de Ingeniería del software, tratando de establecer lasoportunas conexiones. Es particularmente el caso de la asignatura obligatoria Lógica computacional, donde se estudian los fun-damentos de las técnicas formales de desarrollo software y de la asignatura Inteligencia Arti�cial e Ingeniería del Conocimiento,que redunda en el estudio de las técnicas de la ingeniería del conocimiento. Finalmente, es preciso destacar que los conocimien-tos adquiridos en estas asignaturas son esenciales para el seguimiento de una buena parte de las asignaturas del quinto curso, enparticular, de las obligatorias Sistemas Informáticos I, Sistemas Informáticos II y Sistemas Informáticos III, más las optativasAprendizaje y Personalización del Software, Diseño de Sistemas de Trabajo Cooperativo (CSCW) y Calidad de Software; y sir-ven de introducción a las asignaturas optativas Sistemas en tiempo real, Seguridad en las comunicaciones y en la información ySistemas de comunicación de datos. Asimismo son obviamente indispensables para la realización del Proyecto de Fin de Carrera,ejercicio de desarrollo de un proyecto informático que debe llevarse a cabo con el rigor de un proyecto real, y que es obligatoriopara la obtención del título. Por supuesto será fundamental para la formación posterior del alumno titulado y para el ejercicio desu práctica profesional.

Esquema y resumen de contenidosA continuación exponemos un resumen de los temas que componen el contenido de la asignatura que se expandirá más

adelante. Estos temas se podrían agrupar en tres partes que se corresponden con los objetivos presentados anteriormente:

Parte I: Introducción. Tema 1.Parte II: Fases de Construcción. Temas 2 al 6.Parte III: Metodologías y Herramientas. Temas 7 y 8.

La primera parte es preparatoria e incluye la introducción y ubicación de los elementos que van a conformar la asignatura. Enla segunda parte se van describiendo las distintas fases del desarrollo y mantenimiento del software. La parte �nal incluye unconjunto de metodologías donde se recopilan y organizan de diferentes formas las fases, junto con algunas herramientas dedesarrollo.

Esta asignatura es anual y por lo tanto se divide en dos parciales. A los efectos de exámenes parciales se considera que lostemas del 1 al 4 pertenecen al primer parcial y los temas del 5 al 8 pertenecen al segundo parcial.

Esquema:Tema 1: Contexto de la Asignatura en la IS

• Necesidad de una metodología• Ciclo de vida del software• Notaciones de especi�cación y diseño

Índice general VII

Tema 2: Fase de Requisitos

• Obtención de requisitos• Análisis de requisitos• Representación de requisitos• Validación de requisitos• Bases de documentación

Tema 3: Fase de Diseño

• Conceptos y elementos del diseño• Métodos de diseño• Validación y con�rmación del diseño• Documentación: especi�cación del diseño

Tema 4: Fase de Implementación

• Guías de estilo de codi�cación• Iteración de pruebas y depuración• Manuales técnico y de usuario

Tema 5: Fases de Pruebas

• Veri�cación y validación a lo largo del ciclo de vida• Técnicas y métodos de prueba• Documentación de pruebas

Tema 6: Fase de Entrega y Mantenimiento

• Finalización del proyecto• Plani�cación de revisiones y organización del mantenimiento• Recopilación y organización de documentación

Tema 7: Metodologías de Desarrollo

• Proceso Uni�cado de Rational• Método Extreme Programming• Métodos de software libre: �catedral� vs. �bazar�

Tema 8: Herramientas de Desarrollo y Validación

• Herramientas CASE• CVS (Concurrent Versioning System)• Entornos de desarrollo de interfaces

Material y medios de estudioEstructura de esta Guía Didáctica y libro base

En los siguientes capítulos de esta guía de estudio se detallan los contenidos con la información que el alumno de educacióna distancia necesita para poder estudiar la asignatura. Al principio de cada capítulo se incluye un �Tutorial previo� con loselementos que describen el contexto, conocimiento previo, objetivos y guía de estudio para ese capítulo. En esta asignatura seutilizará como material básico de estudio el libro [Pre05] (opcionalmente se podrá seguir la asignatura con la edición anterior[Pre01], pero la referencia para las preguntas de los exámenes es la sexta edición):

Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-Hill, 2005Este libro base cubre la mayor parte del temario. En esta guía los contenidos de cada capítulo se sustituirán por la referencia(entre corchetes como [Pre05, sec. ... y cap ...]) a los apartados del libro base, o bien se incluirán desarrollados directamente enesta guía si no existe una correspondencia directa con el libro base. Al �nal de cada capítulo se incluye en esta guía un �Tutorialposterior� que contiene ejercicios o actividades propuestas adicionales a las que aparecen en el libro base, para que el alumnopueda comprobar si ha logrado los objetivos del capítulo, y también información adicional para la extensión de conocimientospara los alumnos interesados en profundizar en el tema, junto con referencias alternativas sobre los mismos contenidos. Al �nalde esta guía didáctica se incluye en un apéndice el glosario de términos habituales en la Ingeniería de Software que puedenaparecer en el contenido1, también se incluye una recopilación de referencias bibliogra�cas (recomendadas o referidas en elmaterial), más un indice alfabético de referencia para conceptos y términos que aparecen en el material.

1Además al �nal del libro base [Pre05] o [Pre01] hay un apéndice que recopila todas las siglas en ingles y castellano usadas profusamente en Ingeniería delSoftware.

VIII Índice general

Medios AdicionalesAdicionalmente a esta guía, el alumno dispondrá de los medios de comunicación habituales con su Profesor Tutor en el Centro

Asociado o a través de las Tutorías Telemáticas (o Cursos Virtuales) de la UNED http://virtual.uned.es/, y también con elEquipo Docente en la Sede Central (en las direcciones, teléfonos y horarios indicados en la Guía de Curso). Esto se complementacon los canales de comunicación y recopilación de información tanto en soporte físico (CDROM) como en línea a través de lapágina de Internet de la asignatura en la UNED http://www.ii.uned.es/superior/cuarto/ADMSoft.html. En todos estosmedios se incluirá la información particular de referencias y contenidos que se detallan en los capítulos de esta guía, con laventaja adicional de que en los medios en línea los enlaces de direcciones en Internet y otros materiales se irán ampliando yactualizando más frecuentemente. Se recomienda encarecidamente el seguimiento de los cursos virtuales. Además del libro base(que contiene al �nal de cada capítulo �otras lecturas y fuentes de información�) y del material incluido en esta guía, tambiénse recomiendan como bibliografía complementaria general los libros [Som98] (o la edición en inglés más reciente [Som01]) y[RBP+96]:

Ian Sommerville. Ingeniería de Software. Addison-Wesley Iberoamericana, 1998James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Modelado y diseño orien-tado a objetos. Metodología OMT y OMT II. Prentice Hall, 1996

EvaluaciónLa evaluación o�cial de la asignatura se hará por medio de las pruebas presenciales habituales de la UNED. Se harán dos

pruebas parciales, una para cada cuatrimestre. Las pruebas subjetivas consistirán en una parte de preguntas teóricas breves sobreaspectos relevantes del temario correspondiente, más posiblemente otra parte práctica compuesta de ejercicios con supuestosprácticos que describirán parcialmente un problema de diseño de software sobre el cual se pedirá al alumno completar o extenderalgunos aspectos relacionados con el temario correspondiente. La puntuación correspondiente a cada pregunta se especi�cará enel enunciado. En la nota �nal se tendrá en cuenta la compensación entre preguntas dentro de un mismo examen parcial así comola compensación de ambos parciales. Los parciales compensan a partir de 4 y se guardan hasta septiembre.

En algunos capítulos puede haber propuestas para realizar prácticas por el propio alumno, estas serán totalmente voluntarias(y que por tanto no podrán ser tenidas en cuenta para la puntuación de la nota �nal), pero se recomienda al alumno su realizaciónpara ayudarle a una mejor comprensión de los temas.

Capítulo 1

Contexto de la asignatura en la Ingeniería deSoftware

Tutorial previoIntroducción

Al inicio de la asignatura es conveniente repasar algunos conceptos generales sobre Ingeniería de Software e introducir lostemas que se van a estudiar.

En el desarrollo de sistemas software es necesario plani�car el uso de recursos y temporizar adecuadamente las diferentesactividades para no sobrepasar los límites económicos y de tiempo dedicados a un proyecto. Es principalmente con este objetivoque se han ido desarrollando el conjunto de técnicas que reciben el nombre de Ingeniería del Software. Gracias a estas técnicasel desarrollo del software se sistematiza en la medida de lo posible, de modo que el resultado sea previsiblemente aceptable, esdecir, cumpla las expectativas planteadas en términos de tiempo de desarrollo, precio �nal, mantenibilidad y e�ciencia.

Una metodología de desarrollo reúne un conjunto de prácticas que se ejercen en las diferentes fases del ciclo de vida deun producto software. Esas fases son: especi�cación, diseño, codi�cación, pruebas y mantenimiento. Para dar soporte a lasdiferentes etapas, y particularmente a las etapas de análisis y diseño, se han de�nido notaciones de modelado tales como eldifundido estándar UML.

En este primer capítulo se muestra la utilidad de seguir una metodología en el desarrollo de software. A continuación sepresentan los aspectos más generales del ciclo de vida del software y se introducen las distintas fases del desarrollo en que seprofundizará en los capítulos del bloque II (temas 2 al 6). Finalmente, se describe el lenguaje UML, de uso extendido y soportadoactualmente por varias herramientas CASE capaces de generar código a partir de los diagramas de esta notación.

Relación con otros temasCon este tema se pretende asegurar que el alumno dispone de base su�ciente para abordar el estudio del resto de la asignatura.

Es recomendable el repaso de las asignaturas previas de la titulación en que se estudiaron las bases de la Ingeniería del Softwarey el desarrollo de programas.

Al mismo tiempo este tema es importante por proporcionar una visión general de las diferentes fases de un ciclo de desarrollode software y de su coordinación en metodologías.

Para hacerse una composición de lugar sobre lo que se habla en este capítulo y en la asignatura en general es recomendablehaber desarrollado algún proyecto en un lenguaje de programación.

Objetivos del temaEste tema es introductorio. El alumno debe comprobar que dispone de los conocimientos básicos necesarios para afrontar

el resto de la asignatura, entendiendo la estructura general del desarrollo del software, así como las implicaciones y relacionescon la plani�cación y gestión de proyectos informáticos. Para ello debe: comprender la necesidad de utilizar una metodología enel desarrollo de aplicaciones, comprender las ventajas e inconvenientes de los diferentes ciclos de vida para discernir cuando esadecuado usar uno u otro, y saber utilizar (en un nivel medio) la notación UML para la especi�cación y diseño de sistemas.

Guía de estudio y esquemaEs conveniente realizar una lectura inicial del tema para identi�car sus contenidos y repasar los conceptos que considere

necesarios, bien acudiendo a textos de asignaturas ya cursadas, bien estudiando las referencias proporcionadas en el apartado de�extensión de conocimientos�. El capítulo tiene tres partes:

La explicación acerca de la necesidad de una metodología se incluye directamente en esta guía y, adicionalmente, se puedeestudiar en el libro base [Pre05, cap. 1, y secs. 2.1 y 2.2] o en la edición anterior [Pre01, cap. 1, y secs. 2.1 y 2.2].Los ciclos de vida. Se da una descripción de cada uno y una lista de ventajas e inconvenientes. También este apartado estáen esta guía y se puede extender su estudio en el libro base [Pre05, secs. 3.1 a 3.5.2] o en la edición anterior [Pre01, secs.2.3 a 2.12]. 1

2 Contexto de la asignatura en la Ingeniería de Software

La notación de especi�cación y diseño UML. La mejor forma de asimilar esta parte consiste en estudiar la teoría e irhaciendo pequeños ejemplos. En esta guía se incluye este apartado junto referencias a los apartados del libro base [Pre05,secs. 8.4 a 8.8 y 7.5] o en la quinta edición [Pre01, sec. 22.5] y [Pre01, cap. 20]. Advertimos que este material de estudiodel UML se re�ere a la primera versión del lenguaje. Hemos creído conveniente formar al alumno en esta primera versióndebido a que aún la segunda es relativamente reciente y es de preveer que ambas versiones convivan en el mundo empre-sarial durante un tiempo signi�cativo. (Las novedades introducidas en la segunda versión se estudiarán en una adenda aesta guía que se publicará el primero de noviembre en la Web de la asignatura).

1.1. Necesidad de una metodologíaEl proceso de construcción del software requiere, como en cualquier otra ingeniería, identi�car las tareas que se han de

realizar sobre el software y aplicar esas tareas de una forma ordenada y efectiva. Adicionalmente y aunque no es el objetoprincipal de esta asignatura, el desarrollo del software es realizado por un conjunto coordinado de personas simultáneamente y,por lo tanto, sus esfuerzos deben estar dirigidos por una misma metodología que estructure las diferentes fases del desarrollo. Entemas posteriores, en primer lugar se explicarán en detalle las mencionadas fases y a continuación las metodologías usuales quelas gestionan.

En esta asignatura se hará especial énfasis en los temas relacionados con el análisis, diseño y mantenimiento del software,mencionando apenas los temas especí�cos de la organización y gestión de proyectos que conciernen a la distribución de mediosy tareas entre las personas a cargo del desarrollo, ya que estos últimos temas son objeto de otras asignaturas de la titulación.

1.1.1. SistemasLa Ingeniería de Sistemas es el contexto genérico en que se situan las herramientas y metodologías usadas para crear

sistemas. Un sistema puede estar formado por subsistemas de diferentes tipos. La ingeniería de sistemas constituye el primerpaso de toda ingeniería: proporciona una visión global de un sistema en su conjunto para que, posteriormente, cada uno de sussubsistemas se analice con la rama de la ingeniería adecuada. Una de esas ramas es la ingeniería del software.

La Ingeniería del Software trata, según Bauer [Bau72], del establecimiento de los principios y métodos de la ingeniería,orientados a obtener software económico, que sea �able y funcione de manera e�ciente sobre máquinas reales.

El sistema es un conjunto de elementos que cooperan entre sí para proporcionar una funcionalidad. En el caso de un sistemainformático, consta de dos tipos de elementos: Hardware y Software.

1.1.2. La crisis del softwareDesde el momento en que se introdujeron computadores con capacidad para soportar aplicaciones de tamaño considerable

(años 60), las técnicas de desarrollo para los hasta entonces pequeños sistemas dejaron progresivamente de ser válidas. Estastécnicas consistían básicamente en codi�car y corregir (code-and-�x) que se resume en lo siguiente:

No existe necesariamente una especi�cación del producto �nal, en su lugar se tienen algunas anotaciones sobrelas características generales del programa. Inmediatamente se empieza la codi�cación y simultáneamente se vadepurando. Cuando el programa cumple con las especi�caciones y parece que no tiene errores se entrega.

La ventaja de este enfoque es que no se gasta tiempo en plani�cación, gestión de los recursos, documentación, etc. Si el proyectoes de un tamaño muy pequeño y lo realiza un equipo pequeño (una sola persona o dos) no es un mal sistema para producir unresultado pronto. Hoy en día es un método de desarrollo que se usa cuando hay plazos muy breves para entregar el producto �naly no existe una exigencia explícita por parte de la dirección de usar alguna metodología de ingeniería del software. Puede darresultado, pero la calidad del producto es imprevisible. Las consecuencias de este tipo de desarrollos eran:

1. El costo era mucho mayor de lo originalmente previsto.2. El tiempo de desarrollo también excedía lo proyectado.3. La calidad del código producido era imprevisible y en promedio baja.

Aunque se han desarrollado técnicas para paliar estos problemas, hoy en día aún se considera normal que una aplicación rebasesus proyecciones iniciales de tiempo y dinero y que se descubran bugs (errores informáticos) en su ejecución. Esto se debe a quetodavía no se aplica de un modo sistemático la ingeniería del software durante el desarrollo.

1.1.3. De�nición de metodologíaEn la literatura sobre este tema existen muchas de�niciones sobre lo que es una metodología. Más o menos todas ellas

coinciden en que debería tener al menos las siguientes características:

1. De�ne cómo se divide un proyecto en fases y las tareas que se deben realizar en cada una de ellas.2. Especi�ca para cada una de las fases cuáles son las entradas que recibe y las salidas que produce.3. Establece alguna forma de gestionar el proyecto.

Teniendo esto en cuenta establecemos la siguiente de�nición: Metodología es un modo sistemático de producir software.

1.1 Necesidad de una metodología 3

1.1.4. Finalidad de una metodologíaLos atributos deseables en el producto �nal son:

1. Adecuación: El sistema satisface las expectativas del usuario.2. Mantenibilidad: Facilidad para realizar cambios una vez que el sistema está funcionando en la empresa del cliente.3. Usabilidad: Facilidad de aprender a manejar el sistema por parte de un usuario que no tiene por qué ser informático. La

resistencia de los usuarios a aceptar el nuevo sistema estará relacionada con este atributo.4. Fiabilidad: Capacidad de un sistema de funcionar correctamente durante un tiempo dado. La diferencia con la corrección

es que aquí interesa el tiempo, es decir, no se trata del número absoluto de defectos en el sistema sino de los que semani�estan en un intervalo de tiempo. Interesan sobre todo:

a) MTBF: Mean Time Between Failures (Tiempo medio entre fallos)b) Disponibilidad: Probabilidad de que el sistema esté funcionando en un instante dado.

5. Corrección: Densidad de defectos mínima.6. E�ciencia: El sistema es capaz de realizar su tarea con el mínimo consumo de recursos necesario.

1.1.5. Taxonomía de las metodologíasExisten dos grupos de metodologías en función de la mentalidad con la que abordan un problema: metodología estructurada

o metodología orientada a objetos.

Metodología estructurada

Constituyó la primera aproximación al problema del desarrollo de software. Está orientada a procesos, es decir, se centra enespeci�car y descomponer la funcionalidad del sistema. Se utilizan varias herramientas:

Diagramas de �ujo de datos (DFD): Representan la forma en que los datos se mueven y se transforman. Incluyen:

• Procesos• Flujos de datos• Almacenes de datos

GestionarAltas/Bajas

GestionarPedidos

GestionarDevoluciones

PelículasDisponibles

Alta/BajaPelícula

PedidoPelícula

DevoluciónPelícula

Figura 1.1: Ejemplo de DFD

Los procesos individuales se pueden a su vez �explosionar� en otros DFD de mayor nivel de detalle.Especi�caciones de procesos: Descripciones de los procesos de�nidos en un DFD que no se puede descomponer más.Pueden hacerse en pseudocódigo, con tablas de decisión o en un lenguaje de programación.Diccionario de datos: Nombres de todos los tipos de datos y almacenes de datos junto con sus de�niciones. La informaciónque se incluye en él se puede ver en [Pre01, sec. 12.7].Diagramas de transición de estados: Modelan procesos que dependen del tiempoDiagramas entidad-relación: Los elementos del modelo E/R se corresponden con almacenes de datos en el DFD. En estediagrama se muestran las relaciones entre dichos elementos

Los lenguajes de programación también re�ejan esta dicotomía que existe entre las metodologías; así, existen lenguajes para laprogramación estructurada. Los más famosos son: Cobol, Fortran, C, Pascal y Modula 2.

Metodología orientada a objetos

Constituye una aproximación posterior.Cuenta con mayor número de adeptos y es previsible que termine sustituyendo a laanterior. Además, es ampliamente admitido que proporciona una serie de ventajas:

1. Está basada en componentes, lo que signi�ca que facilita la reutilización de código escrito por terceras personas.


2. Facilita el mantenimiento, debido a que favorece que los cambios están más localizados.

La mentalidad que subyace al diseño estructurado es: ¿Cómo se puede dividir el sistema en partes más pequeñas que puedan serresueltas por algoritmos sencillos y qué información se intercambian?. En el diseño orientado a objetos la idea es sin embargo:¿Cuáles son los tipos de datos que hay que utilizar, qué características tienen y cómo se relacionan?.

La orientación a objetos supone un paradigma distinto del tradicional (no necesariamente mejor o peor) que implica focalizarla atención en las estructuras de datos. El concepto de objetos tuvo sus orígenes en la inteligencia arti�cial como un modo derepresentación del conocimiento. El primer lenguaje orientado a objetos fue Simula67, desarrollado por Kristen Nggaard y Ole-Johan Dahl en el Centro de Cálculo noruego, pero el que se considera el primer lenguaje orientado a objetos puro fue Smaltalk,donde todos los elementos del lenguaje son objetos. El lenguaje C++ fue una ampliación de C para que soportara objetos; resultómuy e�ciente pero también muy complejo. Java es otro lenguaje orientado a objetos derivado del C++ pero más sencillo yconcebido con la idea de minimizar los errores.

Objetos y clases Un objeto consta de una estructura de datos y de una colección de métodos (antes llamados procedimientoso funciones) que manipulan esos datos. Los datos de�nidos dentro de un objeto son sus atributos. Un objeto sólo puede sermanipulado a través de su interfaz, esto es, de una colección de funciones que implementa y que son visibles desde el exterior.

Los conceptos importantes en el contexto de clases y objetos se pueden consultar en [Pre01, sec. 20.1] y [Pre01, sec. 20.2].En resumen son:

1. Encapsulamiento: Característica intrínseca de los sistemas orientados a objetos. Consiste en que se ocultan los detalles deimplementación de las clases, lo cual simpli�ca su manipulación.

2. Clases: Describen abstracciones de datos y operaciones necesarias para su manipulación. Dentro de una clase se de�nen:

Atributos: Tipo de datos contenidos en una clase.Métodos: Algoritmos internos de la clase.

3. Polimor�smo: Capacidad de un objeto de presentar varios comportamientos diferentes en función de cómo se utilice; porejemplo, se pueden de�nir varios métodos con el mismo nombre pero diferentes argumentos.

4. Herencia: Relación de generalización; cuando varias clases comparten características comunes, éstas se ponen en unaclase antecesora.

5. Asociación: Relación entre clases que cooperan con alguna �nalidad.

Durante la etapa de análisis se identi�can los objetos del dominio del problema. En el diseño se de�nen las características delos objetos.

1.2. Ciclo de vida del softwareAl igual que otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su

desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que sedetecta la necesidad de construir un sistema de software hasta que éste es retirado, se identi�can varias etapas que en conjuntose denominan ciclo de vida del software. En cada caso, en función de cuáles sean las características del proyecto, se con�guraráel ciclo de vida de forma diferente. Usualmente se consideran las etapas: especi�cación y análisis de requisitos, diseño delsistema, implementación del software, aplicación y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareasdel desarrollo del software es la documentación de todos los elementos y especi�caciones en cada fase. Dado que esta tareasiempre estará in�uida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases comoun apartado especial para recalcar su importancia en el conjunto del desarrollo del software.

Tal como ya hemos mencionado, las etapas principales en cualquier ciclo de vida son:

1. Análisis: Se construye un modelo de los requisitos2. Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema,

y la interfaz de usuario.3. Codi�cación: Se construye el sistema. La salida de esta fase es código ejecutable.4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.5. Mantenimiento: En esta fase, que tiene lugar después de la entrega, se asegura que el sistema siga funcionando y adap-

tándose a nuevos requisitos.

Las etapas constan de tareas. La documentación es una tarea importante que se realiza en todas las etapas. Cada etapa tiene comoentrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida según se muestra enla �gura 1.2.

Algunos autores dividen la fase del diseño en dos partes: Diseño global o arquitectónico y diseño detallado. En el primero setransforman los requisitos en una arquitectura de alto nivel, se de�nen las pruebas que debe satisfacer el sistema en su conjunto,se esboza la documentación y se plani�ca la integración. En el detallado, para cada módulo se re�na el diseño y se de�nen losrequisitos del módulo y su documentación.

Las formas de organizar y estructurar la secuencia de ejecución de las tareas en las diferentes fases de cada uno de los métodospueden dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuación realizanestas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.

1.2 Ciclo de vida del software 5

Figura 1.2: Etapa genérica

1.2.1. Ciclos de vida en cascadaEl ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras

ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones (se estima que el90 % de los sistemas han sido desarrollados así). La estructura se muestra en la �gura 1.3.

Figura 1.3: Ciclo de vida en cascada

Descripción

Este modelo admite la posibilidad de hacer iteraciones. Así por ejemplo, si durante el mantenimiento se ve la necesidad decambiar algo en el diseño se harán los cambios necesarios en la codi�cación y se tendrán que realizar de nuevo las pruebas, esdecir, si se tiene que volver a una de las etapas anteriores al mantenimiento se recorrerán de nuevo el resto de las etapas.

Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento especí�co. Idealmente,

cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:

Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (SoftwareRequirements Document).Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)Codi�cación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.Pruebas: A partir de los módulos probados se realizan la integración y pruebas de todo el sistema. El resultado de laspruebas es el producto �nal listo para entregar.

Ventajas

La plani�cación es sencilla.


La calidad del producto resultante es alta.Permite trabajar con personal poco cuali�cado.

Inconvenientes

Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamentede�nidas las especi�caciones del sistema, o puede ser que surjan necesidades imprevistas.Si se han cometido errores en una fase es difícil volver atrás.No se tiene el producto hasta el �nal, esto quiere decir que:

• Si se comete un error en la fase de análisis no se descubre hasta la entrega, con el consiguiente gasto inútil de recursos.• El cliente no verá resultados hasta el �nal, con lo que puede impacientarse .

No se tienen indicadores �ables del progreso del trabajo (síndrome del 90 %).1

Es comparativamente más lento que los demás y el coste es mayor también.

Tipos de proyectos para los que es adecuado

Aquellos para los que se dispone de todas las especi�caciones desde el principio, por ejemplo, los de reingeniería.Se está desarrollando un tipo de producto que no es novedoso.Proyectos complejos que se entienden bien desde el principio.

Como el modelo en cascada ha sido el más seguido ha generado algunas variantes. Ahora veremos algunas.

Ciclo de vida en V

Propuesto por Alan Davis, tiene las mismas fases que el anterior pero tiene en consideración el nivel de abstracción decada una. Una fase además de utilizarse como entrada para la siguiente, sirve para validar o veri�car otras fases posteriores. Suestructura está representada en la �gura 1.4.

Figura 1.4: Ciclo de vida en V

Ciclo de vida tipo sashimi

Según el modelo en cascada puro una fase sólo puede empezar cuando ha terminado la anterior. En este caso, sin embargo, sepermite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseño se comienza a implementar. El nombre�sashimi� deriva del estilo de presentación en rodajas de pescado crudo en Japón. Una ventaja de este modelo es que no necesitagenerar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Losproblemas planteados son:

Es aún más difícil controlar el progreso del proyecto debido a que los �nales de fase ya no son un punto de referencia claro.Al hacer cosas en paralelo, si hay problemas de comunicación pueden surgir inconsistencias.

La fase de �concepto� consiste en de�nir los objetivos del proyecto, bene�cios, tipo de tecnología y tipo de ciclo de vida. Eldiseño arquitectónico es el de alto nivel, el detallado el de bajo nivel. En la �gura 1.5 se ha representado la estructura del ciclode vida sashimi.

1Consiste en creer que ya se ha completado el 90 % del trabajo, pero en realidad queda mucho más porque el 10 % del código da la mayor parte de losproblemas


Figura 1.5: Ciclo de vida sashimi

Ciclo de vida en cascada con subproyectos

Si, una vez que se ha llegado al diseño arquitectónico, se comprueba que el sistema se divide en varios subsistemas indepen-dientes entre sí, sería razonable suponer que a partir de ese punto cada uno se puede desarrollar por separado y en consecuenciaen paralelo con los demás. Cada uno tendrá seguramente fechas de terminación distintas. Una vez que han terminado todos seintegran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a más gente trabajando en paralelo de formae�ciente. El riesgo es que existan interdependencias entre los subproyectos.

Ciclo de vida en cascada incremental

En este caso se va creando el sistema añadiendo pequeñas funcionalidades. Cada uno de los pequeños incrementos es com-parable a las modi�caciones que ocurren dentro de la fase de mantenimiento. La ventaja de este método es que no es necesariotener todos los requisitos en un principio. El inconveniente es que los errores en la detección de requisitos se encuentran tarde.

Hay dos partes en el ciclo de vida, que lo hacen similar al ciclo de vida tipo sashimi. Por un lado están el análisis y eldiseño global. Por otro lado están los pequeños incrementos que se llevan a cabo en las fases de diseño detallado, codi�cación ymantenimiento.

Figura 1.6: Cascada incremental

Ciclo de vida en cascada con reducción de riesgos

Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en cascada es que si se entienden mal losrequisitos esto sólo se descubrirá cuando se entregue el producto. Para evitar este problema se puede hacer un desarrollo iterativodurante las fases de análisis y diseño global. Esto consistiría en:

1. Preguntar al usuario.2. Hacer el diseño global que se desprende del punto 1.3. Hacer un prototipo de interfaz de usuario, hacer entrevistas con los usuarios enseñándoles el prototipo y volver con ello al

punto 1 para identi�car más requisitos o corregir malentendidos.

El resto es igual al ciclo de vida en cascada.


1.2.2. Modelo de ciclo de vida en espiralPropuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases

y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, ladiferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos,mal diseño, errores en la implementación, etc. Un representación típica de esta estructura se muestra en la �gura 1.7.

Figura 1.7: Ciclo de vida en espiral

En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:

Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista

• Características del producto.• Formas de gestionar el proyecto.

Restricciones:

• Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.• Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

Riesgos: Lista de riesgos identi�cados.Resolución de riesgos: La técnica más usada es la construcción de prototipos.Resultados: Es el producto que queda después de la resolución de riesgos.Planes: Lo que se va a hacer en la siguiente fase.Compromiso: Decisiones de gestión sobre cómo continuar.

Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos; tambiénse veri�ca que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuándotermina el proyecto y cuándo empieza la fase de mantenimiento. Cuando hay que hacer un cambio, éste puede consistir en unnuevo ciclo.

Ventajas

No necesita una de�nición completa de los requisitos para empezar a funcionar.Al entregar productos desde el �nal de la primera iteración es más fácil validar los requisitos.El riesgo en general es menor porque, si todo se hace mal, sólo se ha perdido el tiempo y recursos invertidos en unaiteración (las anteriores iteraciones están bien).El riesgo de sufrir retrasos es menor, ya que al identi�car los problemas en etapas tempranas hay tiempo de subsanarlos.


Inconvenientes

Es difícil evaluar los riesgos.Necesita de la participación continua por parte del cliente.Cuando se subcontrata hay que producir previamente una especi�cación completa de lo que se necesita, y esto lleva tiempo.

Dónde es adecuado

Sistemas de gran tamaño.Proyectos donde sea importante el factor riesgo.Cuando no sea posible de�nir al principio todos los requisitos.

1.2.3. Ciclos de vida orientados a objetosLos tipos de ciclos de vida que se han visto hasta ahora son relativos al análisis y diseño estructurados, pero el desarrollo

de sistemas orientados a objetos tiene la particularidad de estar basados en un diseñado de componentes que se relacionan entreellos a través de interfaces, o lo que es lo mismo, son más modulares y por lo tanto el trabajo se puede dividir en un conjunto deminiproyectos. Además, hoy en día existe una tendencia a reducir los riesgos y, en este sentido, el ciclo de vida en cascada noproporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos esel ciclo de vida en espiral.

En este texto sólo veremos un tipo de ciclo de vida orientado a objetos, que es además el más representativo: el modelofuente.

Modelo fuente

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a objetos yposiblemente el más seguido. Un proyecto se divide en las fases:

1. Plani�cación del negocio2. Construcción: Es la más importante y se divide a su vez en otras cinco actividades: Plani�cación, Investigación, Especi�-

cación, Implementación y Revisión.3. Entrega o �liberación�.

Figura 1.8: Ciclo de vida fuente


La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos. Además de las tres fases,existen dos periodos:

1. Crecimiento: Es el tiempo durante el cual se construye el sistema2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se plani�ca igual que el periodo anterior, es decir,

con las fases de Plani�cación del negocio, Construcción y Entrega.

Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momentocualquiera. La ventaja es que permite un desarrollo solapado e iterativo. En la �gura 1.8 se muestra un esquema de este tipo deciclo de vida.

1.3. Notaciones de especi�cación y diseño (UML)Una parte esencial de todas las tareas del desarrollo del software, en particular de la especi�cación de requisitos y del

diseño, es la utilización de una notación para la descripción de modelos que permita la mecanización parcial del proceso deproducción. Dado que en la actualidad la fase de implementación se suele realizar con tecnologías orientadas a objetos, y queadicionalmente este tipo de enfoque también es aplicable en otras fases del desarrollo, es importante que el alumno conozca almenos los principios básicos de las notaciones orientadas a objetos, y en especial de la más extendida últimamente, la notaciónUML (Uni�ed Modelling Language, Lenguaje Uni�cado de Modelado).

1.3.1. IntroducciónModelos

La construcción de todo sistema de ingeniería requiere un estudio previo que consiste en la identi�cación de sus componentesy de las relaciones entre éstas, la comprensión de sus propiedades, y la concepción de su comportamiento dinámico. El resultadode este estudio es un modelo o representación del sistema. Un modelo es una representación de la realidad donde se abstrae lono esencial. La abstracción permite gestionar la complejidad y experimentar con diferentes soluciones. Para un mismo sistema sepuede de�nir más de un modelo diferente en función del aspecto que interese destacar o el nivel de detalle deseado. El modeladopermite pues ver un sistema desde diferentes perspectivas, haciendo así más sencillo su entendimiento y desarrollo. Finalmente,los modelos juegan un papel esencial en la comunicación con el cliente y entre los profesionales que forman parte del equipo dedesarrollo.

�UML�, siglas de Uni�ed Modeling Language es un lenguaje concebido, como su nombre indica, para expresar modelos. Noes nada más que eso, no indica cómo se deben hacer el desarrollo y ni siquiera el análisis orientados a objetos y, en consecuencia,no es una metodología de desarrollo. Es importante tener bien claro que tan sólo se trata de una notación; ahora bien, es lanotación que se ha convertido en el estándar de facto de la mayor parte de las metodologías de desarrollo orientado a objetos queexisten hoy en día.

El UML se utiliza para la especi�cación, visualización, construcción y documentación de sistemas software. De esta frase,la palabra visualización es la más importante; UML es un lenguaje grá�co, esto es, basado en diagramas, y está pensado para�entrar por los ojos�, tanto de los desarrolladores como de los clientes. Se buscó en él un lenguaje fácil de aprender pero rico ensigni�cado, estándar, estable, con�gurable e independiente de lenguajes de programación o procesos de desarrollo particulares.Al mismo tiempo se pretendió que soportara conceptos de desarrollo de alto nivel tales como colaboraciones, armazones (frame-works), patrones y componentes, y permitiera abordar aspectos clave del desarrollo de software actual tales como escalabilidad,concurrencia, distribución, ejecutabilidad, etc.

El UML soporta todo el ciclo de vida del desarrollo de software y en distintas áreas de aplicación (sistemas distribuidos, tiem-po real, aplicaciones monoproceso, sistemas de información corporativos, banca/�nanzas, telecomunicaciones, defensa/espacio,electromedicina, ciencia, ...). Diferentes herramientas CASE orientadas a objeto que dan soporte al desarrollo basado en UML(Rational Rose, Together, Objecteering, Paradigm Plus, ...) proliferan en el mercado del software.

Este capítulo no pretende ser exhaustivo, debe entenderse más bien como una introducción inicial abreviada a este lenguajede modelado.

Para ver una mínima introducción a conceptos de orientación a objetos puede ser interesante leer primero la sección 3.3 deesta guía.

Historia

Grady Booch, Jim Rumbaugh e Ivar Jacobson (los apodados "tres amigos") desarrollaron los tres métodos de desarrolloorientado a objetos más seguidas de la industria. De la uni�cación del OMT (Object Modeling Technique) de Rumbaugh y elmétodo de Booch nació la primera versión del UML en el año 1994. Posteriormente, se incorporaron el método OOSE (Object-Oriented Software Engineering) de Jacobson y algunos conceptos de otros lenguajes de modelado. En la actualidad el UML esun estándar abierto del grupo OMG (Object Management Group) y se halla en su versión 2.0.

Elementos del lenguaje UML

A continuación se presenta una clasi�cación general de los elementos del lenguaje UML. En las secciones siguientes seexplica cómo estos elementos se combinan para construir diferentes tipos de modelos, y se de�nen algunos elementos adicionalesque intervienen especí�camente en estos modelos.

En el lenguaje UML se distinguen básicamente tres tipos de elementos:

1.3 Notaciones de especi�cación y diseño (UML) 11

1. Bloques de construcción: Pueden ser Entidades, Relaciones o Diagramas.2. Mecanismos comunes: Entre ellos se distinguen Especi�caciones, Adornos y Mecanismos de extensión.3. Reglas de combinación

Los bloques de construcción se de�nen como abstracciones y tienen manifestaciones concretas denominadas Instancias. Lasinstancias más comunes son las instancias de clase (Objetos) y las instancias de asociación (Enlaces). Las instancias puedenidenti�carse mediante un nombre o bien ser anónimas.

En cuanto a las Entidades, pueden ser:

Estructurales: Entre ellas se distinguen Casos de uso, Clases, Componentes y Nodos. Un tipo particular de clases sonlas Interfaces.De agrupamiento: Son los Paquetes. Tipos particulares de paquetes son los Modelos y los Subsistemas. Entre los mod-elos se distinguen Modelos de casos de uso, Modelos estructurales estáticos, Modelos de comportamiento y Modelosestructurales de implementación.De comportamiento: Son, principalmente, las Acciones, los Estados, las Transiciones y los Mensajes.

Las Relaciones, se clasi�can principalmente en:

DependenciasAsociacionesGeneralizaciones

Se distingue entre Diagramas de:

Casos de usoClasesObjetosSecuenciaColaboraciónEstadosActividadesComponentesDespliegue

Como veremos en las seciones siguientes, los modelos de casos de uso se describen mediante diagramas de casos de uso ydiagramas de secuencia; Los modelos estructurales estáticos mediante diagramas de clases y de objetos, los modelos de compor-tamiento mediante diagramas de secuencia, diagramas de colaboración,diagramas de estados y diagramas de actividades; y losmodelos estructurales de implementación mediante diagramas de componentes y diagramas de despliegue.

En cuanto a los Mecanismos comunes se clasi�can en:

Especi�caciones: Descripciones textuales detalladas de la sintaxis y semántica de un bloque de construcción.Adornos: Elementos grá�cos y textuales que pueden añadirse a la notación grá�ca básica para proporcionar detallesadicionales de la especi�cación (símbolos de visibilidad, compartimentos adicionales, notas, roles, representación de clasesy características especiales - abstracta, raíz, hoja - etc).Mecanismos de extensión: Posibilidades de extensión controlada del lenguaje para adecuarse a aplicaciones, procesos odominios de aplicación concretos. Se distingue entre Estereotipos, Valores etiquetados y Restricciones.

En las secciones siguientes explicamos los diferentes tipos de modelos que pueden de�nirse en UML, describiendo al mismotiempo los elementos que intervienen en los correspondientes diagramas. Hemos optado por describir estos elementos a medidaque se hace referencia a ellos por entender que en un contexto de modelado concreto se pueden entender mejor su utilidad ysigni�cado. Por lo general no distinguiremos entre los diferentes tipos de adornos o mecanismos de extensión que estos elementosconstituyen, por no considerarlo relevante en el nivel de estudio del lenguaje exigido para esta asignatura. Los símbolos grá�cosque los denotan aparecen ilustrados en las �guras de esta sección. Las antes mencionadas reglas de combinación están implícitasen la descripción de los diferentes diagramas.

1.3.2. Modelo de casos de usoRepresenta la visión que tendría del sistema un usuario externo, y es desarrollado por los analistas con la colaboración de

los expertos del dominio de aplicación. Un caso de uso expresa lo que comúnmente se denomina una transacción, esto es, unainteracción entre el sistema y el usuario u otro sistema que es visto como un �actor� externo: p.e., un usuario que pulsa el botónde llamada de un ascensor, o un periférico que solicita datos de un ordenador central.

Los casos de uso sirven para especi�car los requisitos funcionales del sistema e identi�car los escenarios de prueba. Nor-malmente se utilizan en las primeras etapas de desarrollo. En particular, algunas metodologías están dirigidas por casos de uso,de forma que es a partir de ellos que se derivan los modelos estructurales y de comportamiento. En cualquier caso, siempre espreciso asegurarse de que el modelo de casos de uso es coherente con estos modelos.

En UML los casos de uso se de�nen mediante diagramas de casos de uso y de secuencia, y descripciones textuales (especi�-caciones) que resultan de cumplimentar unas plantillas estándar.


Entidades

En los casos de uso intervienen dos entidades estructurales:

Casos de uso: Consisten en una secuencia de Acciones (unidades básicas de comportamiento; habitualmente implemen-tadas por una sentencia de ejecución), y posibles variantes de estas acciones, que puede realizar el sistema al interaccionarcon los actores.Actores: De�nen un conjunto de roles que desempeñan los usuarios cuando interaccionan con los casos de uso.

Interviene también en los casos de uso una entidad de agrupamiento, el Límite del sistema, que representa el límite entre elsistema físico y los actores que con él interaccionan.

Relaciones

En los modelos de casos de uso pueden estar implicadas relaciones de los tres tipos principales:

Asociación: Indica la participación de un actor en un caso de uso (véase la �gura 1.9), esto es, la comunicación de una�instancia� de un actor con �instancias� del caso de uso o de otro actor que interviene en el caso de uso.Generalización: Muestra una taxonomía entre casos de uso o actores generales, y casos de uso o actores más especí�cos.Dependencia: Puede indicar que el comportamiento de un cierto caso de uso extiende el de un caso de uso base, cuali-�cándose con un estereotipo «extend», o bien que el comportamiento de un caso de uso incluye el de un caso de uso base,cuali�cándose con un estereotipo «include» (véase la �gura 1.10). Cuando un caso de uso extiende a otro, añade algunospasos a la secuencia de interacciones por él especi�cada. Cuando un caso de uso incluye a otro, signi�ca que contiene lasecuencia de interacciones por él especi�cada. Este último concepto se identi�ca con el de llamada a subrutinas: Cuandodos o más casos de uso tienen una parte signi�cativa en común, es útil de�nir casos de uso elementales que representan lassecuencias repetidas.

Figura 1.9: Asociación entre un caso de uso y un actor

Figura 1.10: Relaciones entre casos de uso

Diagramas

En la �gura 1.9 se ilustra un diagrama de casos de uso elemental. En cuanto a los diagramas de secuencia, que completan losmodelos de casos de uso, se verán en detalle en la sección posterior �Modelado de comportamiento�.

Mecanismos comunes

Como especi�caciones de los casos de uso se utilizan las denominadas Descripciones de casos de uso, obtenidas al cumpli-mentar una plantilla donde se detallan los actores implicados, las precondiciones y postcondiciones, la secuencia normal deacciones emprendidas por los actores y respuestas asociadas del sistema, y los posibles escenarios alternativos y excepcionales.La información contenida en estas especi�caciones tiene una traducción diagramática en los diagramas de casos de uso y diagra-mas de secuencia.

Modelado de casos de uso

Al modelar casos de uso es importante asegurarse de que cada caso de�nido describe una parte signi�cativa del funcionamien-to del sistema. Para evitar la de�nición de un número excesivo de casos de uso, hay que tener presente que un caso de uso no esun paso, operación o actividad individual de un proceso, sino un proceso completo que incluye varios pasos.


Otro aspecto importante a tener en cuenta es la utilidad de los casos de uso en la comunicación entre analistas, desarrolladoresdel software y expertos del dominio de aplicación: deben se entendibles por todos y constituir una descripción de alto nivel delsistema que no incorpore conceptos de diseño.

Para identi�car casos de uso es recomendado comenzar por modelar el contexto con que habrá de relacionarse, fase queimplica los siguientes pasos:

1. Identi�cación de los actores que interactúan con el sistema.2. Organización de estos actores.3. Especi�cación de la correspondientes vías de comunicación.

A continuación, para cada uno de estos actores, habrán de identi�carse los procesos que inician o en los que participan. Loscasos de uso resultantes deben constituir un modelo de requisitos del sistema.

Los siguientes pasos a seguir en la de�nición de casos de uso serán pues:

1. Identi�cación de las necesidades de los actores.2. Designación de estas necesidades como casos de uso.3. Identi�cación de los casos de uso que pueden ser especializaciones de otros y búsqueda de secuencias parciales comunes

en los casos de uso ya encontrados.

Un enfoque alternativo consiste en prestar inicialmente atención a los Eventos relevantes que condicionan respuestas delsistema, y buscar después qué actores y casos de uso están relacionados con estos eventos.

1.3.3. Modelo estructural estáticoMuestra una visión de la estructura interna del sistema en términos de las entidades que lo integran y las relaciones que

existen entre ellas, capturando el vocabulario del dominio de aplicación. Este modelo es desarrollado por analistas, diseñadoresy programadores y se de�ne mediante diagramas de clases y de objetos.

Entidades estructurales

Las entidades estructurales implicadas en un modelo estructural estático son de tipo:

Clase : Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.Interfaz: Nombre asignado a un conjunto de operaciones que caracterizan el comportamiento de un elemento.Puede versecomo un tipo particular de clase.

Clases Las clases son abstracciones del dominio de aplicación o bien de la tecnología utilizada en su desarrollo. Constituyenel elemento básico de modelado en el paradigma de orientación a objetos. Una clase se instancia en objetos excepto cuando sede�ne como Clase abstracta (un adorno de clase).

Las clases abstractas se utilizan en niveles altos de las jerarquías de clases para de�nir abstracciones muy generales de lasque derivar otras clases. En una jerarquía de clases existe una clase Raíz o base sin Superclases, que da origen a la jerarquía,y clases Hojas sin Subclases. El signi�cado de estas jerarquías está ligado al concepto de Herencia, que se presentará en unasección posterior.

En la �gura 1.11 se ilustran las partes de una clase, que se disponen de arriba a abajo en el orden siguiente:

Figura 1.11: Plantilla para una clase en UML

1. Nombre: Distingue a la clase del resto de clases en el ámbito del modelo. Consiste en una cadena de cualquier longitudque puede contener letras, números y signos de puntuación (exceptuando � � y �::�). Aparece en cursiva en el caso delas clases abstractas (clases que carecen de instancias). El nombre de clase puede aparecer opcionalmente precedido delnombre del paquete en que la clase se utiliza; su sintaxis se de�ne pues, en notación BNF: [paquete::]nombre-simple.


2. Atributos: Representan propiedades características compartidas por todos los objetos de la clase. Una clase puede tenercualquier número de atributos. Un nombre de atributo consiste en una cadena de cualquier longitud que puede contenerletras y números. Sobre ellos pueden proporcionarse diferentes informaciones:

a) Tipo: Atributo:Tipob) Valor inicial: Atributo:Tipo=Valor ó Atributo=Valorc) Restricciones: Condiciones semánticas que pueden expresarse utilizando cualquier lenguaje, incluido el lenguaje nat-

ural, si bien UML tiene un lenguaje semi-formal asociado para expresar restricciones: el lenguaje OCL. Se encierransiempre entre corchetes.

d) Visibilidad o Alcance: Determina en qué medida otras clases pueden hacer uso del atributo. Un atributo público (+)es visible para cualquier clase externa; un atributo protegido (#) es visible para cualquier descendiente en la jerarquíade herencia; y un atributo privado (-) es sólo visible para la propia clase. El valor por defecto de la visibilidad essiempre público.

e) Ámbito: Puede ser de dos tipos:

de instancia: cuando cada objeto tiene su propio valor,de clase: cuando todas las instancias de una clase comparten un valor. (p.e., las variables static en Java). Estetipo de ámbito se indica subrayando el nombre del atributo.

Toda esta información es opcional, de hecho, es común que en las especi�caciones de las clases no se detallen más que losnombres de sus atributos. Su sintaxis se resumen en: [visibilidad]nombre [:tipo][=valorInicial][restricciones].Atributos derivados son aquellos cuyo valor puede computarse a partir de valores de otros atributos; aunque no añadeninformación semántica al modelo, se hacen explícitos por claridad o propósitos de diseño.

3. Operaciones: Son servicios básicos ofrecidos por los objetos de una clase, que con frecuencia provocan cambios en susestados (se adornan con query aquellas operaciones que no tienen ningún efecto secundario, esto es, que no modi�can elestado del sistema). Al igual que en el caso de los atributos, pueden especi�carse su visibilidad, ámbito y propiedades. Sepueden indicar también el tipo de los argumentos que reciben y el tipo del valor que retornan. Tanto si se especi�can susargumentos como si no, han de añadirse un paréntesis abierto y otro cerrado al �nal de su nombre, de acuerdo a la sintaxis:[visibilidad]nombre([parámetros])[:tipoRetorno][propiedades]. La sintaxis completa de los parámetros es:[dirección]nombre:tipo[= valorPorDefecto]. La implementación concreta que una clase hace de una operación sedenomina Método. La descripción de un método puede realizarse mediante una especi�cación textual descrita en cualquierlenguaje elegido (p.e., el OCL). Al igual que existen clases abstractas existen Operaciones abstractas, esto es, operacionesque se de�nen exclusivamente como una signatura. Las clases que contienen este tipo de operaciones requieren subclasesque proporcionen métodos para su implementación. Las operaciones de las clases hoja de una jerarquía de clases obligada-mente habrán de tener un método asociado.

4. Responsabilidades: Son descripciones de lo que hace la clase en su conjunto. Esta información casi nunca se incluye enlos diagramas.

5. Otras: Una clase puede incluir partes adicionales prede�nidas (p.e., excepciones) o de�nidas por el usuario.

La información que se ha incluído en la �gura 1.11 es mucha más de la que se suele mostrar: una clase puede representarsecon un simple rectángulo que contiene su nombre; véase la �gura 1.12. También es común omitir parte de la información de unapartado. Los puntos suspensivos que aparecen el la �gura 1.11 al �nal de las secciones de atributos y operaciones indican quela representación de la clase es abreviada, o lo que es lo mismo, que faltan atributos y operaciones que no se ha consideradonecesario detallar para el propósito del diagrama en cuestión.

Ascensor

Figura 1.12: La representación de clase más sencilla posible

Las instancias de clase se denominan objetos. Los objetos se caracterizan por un estado de�nido por los valores especí�cosde sus atributos en cada instante de tiempo.

La notación grá�ca de una clase en un diagrama de clases coincide con la de un objeto en un diagrama de objetos. La sintaxisde su nombre, que aparece subrayado, es: [nombreInstancia][:nombreClase] (vésase la �gura 1.13).

ascensor2:Ascensor

Figura 1.13: Símbolo en UML de un objeto

Interfaces Las interfaces son conjuntos de operaciones que especi�can parte de la funcionalidad (un servicio) proporcionadapor una clase o componente, con independencia de su implementación. Pueden verse como contratos entre los clientes de lainterfaz y sus implementaciones; el programador responsable de la interfaz puede optar por implementar una nueva o bienadquirir o reutilizar otra implementación, con tal de que el estipulado contrato se cumpla.


Una interfaz y la clase que la implementa están relacionadas mediante una realización (un tipo particular de relación dedependencia), donde una clase puede realizar varias interfaces y una interfaz puede realizarse por más de una clase. Por otrolado, una clase �cliente� puede usar varias interfaces con las que estará relacionada mediante una relación de uso (otro tipo derelación de dependencia).

Las interfaces establecen conexiones entre los componentes de una aplicación, y representan los principios de modularidad yocultación necesarios en diseños orientados a objetos de calidad.

En cuanto a su representación diagramática, las interfaces se muestran como clases sin atributos mediante dos representa-ciones alternativas que se muestran en la �gura 1.14: como clases con estereotipo «interfaz» y, en forma abreviada, sin mostrarlas operaciones. Al tratarse de un tipo particular de clases, entre las interfaces pueden darse relaciones de herencia. Todas lasoperaciones de una interfaz son públicas.

ObjetoGrafico

<<interface>>

Dibujable

+Dibujar()

ObjetoGrafico

Dibujable

<<interface>>

Iterable

<<interface>>

Collection

<<interface>>

List<<interface>>

Queue<<interface>>

Set

<<interface>>

SortedSet

Figura 1.14: Interfaces

Relaciones

Asociación Es una relación conceptual, que no es inherente a la naturaleza de las clases sino al papel que juegan en el modelo.Especi�ca que las instancias de una clase están conectadas con las de otra. No se trata de una relación fuerte, es decir, el tiempode vida de dos objetos relacionados es independiente (a menos que exista una restricción asociada a la relación que indique locontrario).

La representación grá�ca de una asociación (véase la �gura 1.15) es básicamente una línea que conecta las clases, pero puedeincluir opcionalmente un nombre que da idea de su interpretación en el dominio de la aplicación, así como otros adornos en susextremos tales como:

Un triángulo relleno que indica su dirección (cuando la asociación no es simétrica).Un nombre de rol que cuali�ca el papel que juega cada una de las partes en la asociación (una clase puede desempeñardistintos roles en distintas asociaciones).Una indicación de Navegabilidad, propiedad del rol que consiste en la posibilidad de �ir� desde el objeto origen al objetodestino, es decir, implica la visibilidad de los atributos del objeto destino por parte del objeto origen. Por defecto lanavegabilidad es bidireccional, En la �gura 1.17 se ilustra una asociación no bidireccional: dada una password, no sepuede acceder directamente al usuario a que pertenece (al menos en principio).Un valor de multiplicidad que especi�ca por cada clase de la asociación el número de objetos que se relacionan con unsolo objeto de la clase asociada.Una Cali�cación, atributo de la asociación que permite localizar una cierta instancia cuando la multiplicidad de la asi-ciación es mayor que la unidad en el extremo considerado. (véase la �gura 1.18).Un símbolo de Agregación, que indica una asociación de tipo todo/parte y se representa con un símbolo de diamante(véase la �gura 1.19). Sirve para modelar elementos que se relacionan utilizando expresiones como: �es parte de�, �tieneun�, �consta de�, etc. Una asociación de agregación fuerte, donde las partes (componentes) no pueden existir independi-entemente del todo que las integra (entidad compuesta), se denomina (Composición), y se denota mediante un diamantenegro.

Figura 1.15: Ejemplo de una asociación

En una composición, cada componente pertenece a un todo y sólo a uno (en la �gura 1.19 no se cumple esto, por ejemplo, laantigua Unión Soviética tenía una parte europea y una parte asiática). En la �gura 1.20 vemos un ejemplo de este tipo de relación.


Es posible que dos clases estén relacionadas entre sí por más de una asociación o que una clase esté relacionada con muchasclases por diferentes asociaciones. Por lo general, las asociaciones son relaciones simétricas. Se dice que una relación es re�exivacuando asocia entre sí a objetos de una misma clase. La notación con que se expresa la multiplicidad de una asociación es diversa:

1. Números concretos. Un número exacto: A. Por ejemplo: 5 (signi�ca exactamente 5).2. Intervalos. Entre A y B, ambos incluidos: A..B. Por ejemplo: 2..6 (es entre 2 y 6).3. Asterisco. El símbolo * signi�ca muchos. Si está en un intervalo se pone en el extremo superior. A..* se lee: A o más. Por

ejemplo: 3..* (es 3 o más). Si el * está solo signi�ca que puede ser un número cualquiera, cero incluido.4. Combinación de los elementos anteriores: Por ejemplo: 1..4,6,9..* (que signi�ca entre 1 y 4, ó 6, ó 9 ó más de 9, es

decir, los valores 0, 5, 7 u 8 no estarían permitidos); 2,4,6 (los valores 2, 4 ó 6 y ninguno más).

Así, en el ejemplo representado en la �gura 1.16, se hacen las siguientes suposiciones:

Figura 1.16: Relaciones entre alumnos, asignaturas y profesores

Un alumno puede estar matriculado como mínimo en una asignatura (si no está en ninguna no es alumno) y como máximoen 11.En una asignatura se puede matricular un número ilimitado de alumnos pero tiene que haber al menos un matriculado, ode lo contrario la asignatura no existe.Un alumno puede estar haciendo o no el proyecto �n de carrera. En caso a�rmativo tendrá un profesor asignado comocoordinador.Existen asignaturas que tienen prácticas y algunas de ellas se realizan entre varios alumnos. Un alumno puede estar asoci-ado con un número variable de compañeros para realizarlas.

Figura 1.17: Navegabilidad

EstudianteAsignatura

Cursa1..11

1..*

EstudianteAsignatura

Cursa1..11

1Num.Matrícula

Figura 1.18: Cali�cación

Asociaciones derivadas son aquellas cuyos enlaces pueden deducirse de la existencia de otros enlaces.

Generalización Es una relación entre una abstracción general y una abstracción más concreta. Las relaciones de generalizaciónentre clases (una superclase o clase principal y una subclase o clase secundaria) se denominan relaciones de herencia. Indica quela subclase �hereda� las operaciones y atributos de�nidos en la superclase. Este tipo de conexión se lee como �es un tipo de�. Enla �gura 1.21 se muestra un ejemplo de representación.

Una clase puede tener ninguna, una (Herencia simple) o varias (Herencia múltiple) superclases. La relación de general-ización o herencia permite de�nir taxonomías de clases. En una jerarquía de herencia, las clases sin superclases se denominan


Continente Pais

Figura 1.19: Agregación

Ascensor

Motor

Cable

Cabina

Electrónica

Figura 1.20: Composición con una agregación (la electrónica puede ser compartida por un grupo de ascensores)

clases Raíz, y las clases sin subclases se denominan clases Hoja. En las jerarquías de herencia se da el Polimor�smo, que con-siste en que un objeto de una subclase puede comportarse como un objeto de cualquiera de sus superclases en cualquier contexto(el recíproco no es cierto). Así, si una operación de la subclase tiene la misma signatura que una operación de la superclase,cuando se invoque la operación de un objeto de la subclase se ejecutará el método de�nido en la subclase y, cuando se invoquela operación de un objeto de la superclase, se ejecutará el método de la operación de la superclase.

Prof.Universidad

Prof.AsociadoProf.Ayudante Prof.ColaboradorProf.Titular

Prof.EscuelaUniversitaria Prof.TitularUniversidadProf.AyudanteDoctor

CatedráticoCatedráticoEscuela

Figura 1.21: Herencia; los nombres de las clases abstractas se escriben en cursiva

Dependencia Es una relación entre dos entidades estructurales tal que un cambio en una de ellas (la independiente) puedeafectar a la otra (la dependiente). Suele ser unidireccional y se interpreta muchas veces como una relación �de uso�, entendiéndoseque una clase �usa� a otra cuando ésta de�ne el tipo de alguno de los argumentos que aparece en las signaturas de sus operaciones(véase la �gura 1.22).

En UML se contemplan otros tipos de relaciones de dependencia, tales como derivación, instanciación, re�namiento yrealización. Esta última es una relación semántica que se da entre clases, una de las cuales especi�ca un contrato que la otra secompromete a cumplir. Sirve habitualmente para separar la de�nición de un sevicio o contrato y su implementación, y relaciona,típicamente, una interfaz con la clase o componente que la implementa.


DoyServicioUsoServicio

Figura 1.22: Dependencias

Diagramas

Diagrama de clases Es el diagrama central de una especi�cación UML. Describe un modelo estático del sistema en términosde las entidades y relaciones descritas en las secciones anteriores (clases; interfaces; y relaciones de asociación, herencia ydependencia).

Veamos cómo sería el modelo de clases que corresponde con este texto: En un conocido juego de estrategia hay tres tiposde razas: Terrans, Zergs y Protos. Cada tipo de raza de�ne a su vez dos tipos de personajes: Trabajadores (consiguen recursosy construyen edi�cios) y Soldados (pegan a personajes de otro bando). Un personaje tiene como características: Si es aéreoo terrestre, salud (número entero), velocidad, escudo, etc. Un soldado además de�ne si puede pegar a personajes aéreos oterrestres, daño que hace, etc. Un trabajador recoge recursos y los lleva a un edi�cio de recogida. Los recursos son de dos tipos:Gemas y Gas y se van agotando a medida que son explotados. Hay diferentes tipos de edi�cios propios de cada raza y cada unoproporciona capacidades diferentes a los miembros de su bando, por ejemplo, el máximo número de personajes de un bando estádeterminado por el número de edi�cios granja multiplicado por 8; el edi�cio armería mejora en +1 el daño de los soldados. Unbando está de�nido por un conjunto de personajes y edi�cios de una o más razas. El juego tiene lugar sobre un tablero de�nidoen una retícula romboidal. En cada punto de la retícula se de�ne el tipo de terreno y se pueden posicionar personajes, edi�ciosy recursos. Un bando puede ser dirigido por un jugador o por la inteligencia arti�cial del programa.

Figura 1.23: Diagrama de clases

Diagrama de objetos Este diagrama permite modelar una instantánea del sistema en un momento dado de su funcionamiento.Nótese que, no obstante, describe un modelo estructural estático, ya que no incluye información alguna sobre evolución temporal.Contiene principalmente objetos y enlaces que ligan estos objetos (esto es, instancias de clases y relaciones de�nidas en losdiagramas de clases). Los objetos pueden aparecer agrupados en paquetes. En los diagramas de clases también es posible mostrarobjetos que son instancias de las clases de�nidas, siempre que se considere relevante para el propósito de la representación; poresta razón, los diagramas de objetos pueden verse como diagramas de clases que no contienen clases. En el ejemplo de la �gura1.24, se ilustra la notación de un diagrama de objetos. Hacemos notar que:

1. Dar nombre a objetos y enlaces es opcional pero, en el caso de los objetos, es obligado indicar la clase de que son instancia.2. También pueden mostrarse opcionalmente los atributos, con sus correspondientes valores, en caso de considerarse rele-

vantes.3. Al igual que las clases, los objetos pueden estereotiparse.


miCoche:Coche

Matrícula = www-1234Modelo = Citroen ZX 1.9 DColor = Verde oscuro metalizadoasientoIzdo:AsientoDelantero

asientoDcho:AsientoDelantero

asientoTrasero:AsientoTrasero

salpicadero:Salpicadero

motor:Motor

carroceria:Carroceria

Figura 1.24: Diagrama de objetos

Mecanismos comunes

En los modelos estructurales estáticos suele utilizarse todo tipo de mecanismos comunes del UML. Algunos de ellos hansido mencionados en las secciones anteriores, donde se ha explicado cómo se añaden a las notaciones básicas de los bloques deconstrucción para enriquecer la representación (símbolos de visibilidad, estereotipos, etc) De�nimos brevemente a continuaciónel sentido preciso de los dos más comúnmente utilizados:

Estereotipos. Suponen una extensión del metamodelo del UML, esto es, del conjunto de conceptos (metaconceptos) pre-de�nidos (tales como clase, atributo, caso de uso, etc.) en términos de los cuales se de�nen los modelos. De�nir un nuevoestereotipo supone añadir un nuevo concepto por herencia, de modo que constituya un caso particular de algún conceptoya de�nido. Está aceptado asimismo de�nir nuevas notaciones grá�cas para representar los nuevos conceptos (es el casodel símbolo de actor, que representa una clase estereotipada como «actor».Notas Anotaciones escritas habitualmente de modo informal, a modo de texto explicativo ligado a algún elemento. Serepresentan en la forma indicada en la �gura 1.25.

Ascensor No se tiene en cuenta

el coeficiente de

seguridad del cable

Figura 1.25: Nota relativa a una clase

Entidades de agrupamiento

En los modelos estructurales, los Paquetes agrupan clases vinculadas por alguna relación (su representación se ilustra en la�gura 1.26). En cuanto a los Subsistemas, agrupan paquetes que participan en un comportamiento, desde una visión de alto niveldel sistema.

AWT

Button Canvas

Label CheckBox

Figura 1.26: Paquete inluido en las librerías estándar de Java para la implementación de interfaces grá�cos

Modelado estructural

Los modelos estructurales son útiles tanto cuando análisis y diseño se abordan con una perspectiva ascendente (�bottom-up�)como cuando se abordan con una perspectiva descendente (�top-down�). En el primer caso, el objetivo del modelado estructuralserá especi�car la estructura de alto nivel del sistema, para lo que se utilizarán clases con signi�cado arquitectural y entidades deagrupamiento para gestionar la complejidad (paquetes y subsistemas). En el segundo caso, se tratará de especi�car la estructurade bajo nivel, que se irá re�nando a medida que progrese el desarrollo (añadiendo detalles, reclasi�cando, de�niendo nuevasrelaciones, etc.).


Para comenzar un desarrollo especi�cando el modelo estructural estático es preciso conocer bien el dominio de aplicación.De otro modo, será más adecuado utilizar, p.e., un método dirigido por casos de uso, y el modelo estructural habrá de de�nirseen coherencia con los casos de uso o colaboraciones ya especi�cados.

Un buen modelo estructural debe constituir un esqueleto extensible y re�nable a medida que se profundiza en el conocimien-to del dominio de aplicación. En las primeras fases de de�nición siempre es preferible limitarse a utilizar las notaciones másbásicas, dejando las más avanzadas para añadir detalles en fases posteriores. En particular, es importante evitar limitar los mod-elos iniciales añadiendo aspectos propios de fases de implementación. También debe evitarse mezclar en un mismo diagramaentidades descritas en niveles de abstracción diferentes. Finalmente, constutiye también una buena práctica organizar las clasesen paquetes cuando empiezan a resultar numerosas.

1.3.4. Modelo de comportamientoUn modelo de comportamiento describe la evolución del estado del sistema y las interacciones que tienen lugar entre sus

elementos. Se expresa mediante diagramas de interacción (de dos tipos: diagramas de colaboración y diagramas de secuencias),diagramas de estado y diagramas de actividad. Entre las entidades de comportamiento, las principales entidades implicadas enlos diagramas de interacción son los mensajes, mientras que en los diagramas de estado y actividad las entidades protagonistasson los estados, las transiciones y las acciones. Los cuatro tipos de diagramas de comportamiento pueden implicar asimismodiferentes entidades estructurales, y los diagramas de colaboración exhiben, adicionalmente, asociaciones.

Diagramas de interacción

Un Mensaje es la especi�cación de un conjunto de Estímulos comunicados entre instancias de clase, de componente o decaso de uso, junto con la especi�cación de las correspondientes clases, componentes o casos de uso emisores y receptores, delmensaje previo que los induce y de los subsecuentes procesos desencadenados (nuevos mensajes y acciones).

Los estímulos pueden ser Señales, entendidas como informaciones de datos o de control comunicadas entre instancias, oinvocaciones de operaciones. Una Interacción es un conjunto de estímulos, intercambiados entre un grupo de instanscias (declases, componentes o casos de uso), en un contexto dado, y con un determinado propósito. Se entiende que dos instancias sólopodrán intercambiar estímulos cuando estén ligadas por algún enlace.

Un Evento es una ocurrencia signi�cativa para una instancia; en el contexto de los diagramas de interacción son, principal-mente, Recepciones de estímulos y Satisfacción de condiciones.

En un diagrama de interacción �guran:

Instancias (de clases, de componentes o de casos de uso). Entidades con identidad única a las que se puede aplicar unconjunto de operaciones, que tienen un estado y almacenan los efectos de estas operaciones.Acciones. Existen acciones prede�nidas (p.e.: CreateAction, CallAction, DestroyAction, UninterpretedAction...), y ac-ciones de�nidas por el desarrollador.Estímulos. Las invocaciones de operaciones pueden ser de dos tipos

• Síncronas: las instancias en comunicación tienen que estar sincronizadas, esto es, la instancia que invoca se quedabloqueada hasta recibir una respuesta.

• Asíncronas: las instancias en comunicación no tienen que estar sincronizadas

Las señales siempre son asíncronas. Existen algunos tipos característicos de señales:

• Retorno de invocación síncrona.• Retorno de invocación asíncrona.• Creación de instancia.• Destrucción de instancia.

Operaciones. Servicios que pueden solicitarse de las instancias

Como ya hemos mencionado, existen dos tipos de diagramas de interacción: los diagramas de secuencias y los disgramas decolaboración. Además de los elementos antes listados, en los diagramas de colaboración pueden �gurar explícitamente enlacesque conectan las diferentes instancias, y atributos de estos enlaces.

Diagrama de secuencias Muestra instancias y mensajes intercambiados entre ellas teniendo en cuenta la temporalidad con laque ocurren (lo que comúnmente se denomina escenario en el contexto del software de comunicaciones). Las instancias puedenser de clases y también de componentes y de casos de uso. Los tres tipos de instancias se ven como objetos únicos, a efectos deestos modelos. Sirven para documentar el diseño, y especi�car y validar los casos de uso. Gracias a estos diagramas se puedenidenti�car los cuellos de botella del sistema, re�exionando sobre los tiempos que consumen los métodos invocados.

En un diagrama de secuencias �guran, además de los elementos básicos de un diagrama de interacción antes presentados:

1. Línea de vida de un objeto: Es una representación de la actividad del objeto durante el tiempo en que se desarrolla elescenario. Se entiende que la dimensión temporal crece de arriba a abajo de la línea. Se representa con una cabecera enforma de rectángulo, que incluye el nombre del objeto y una línea vertical de puntos por debajo. Durante el tiempo en quela instancia está ejecutando un método, la línea de puntos se convierte en un rectángulo.


2. Activación: Punto en que un objeto pasa a tener un método en ejecución, bien por autoinvocación de la correspondienteoperación, bien por invocación procedente de otro objeto.

3. Tiempo de transición: Es el tiempo que transcurre entre dos mensajes.4. Condicional: Representa alternativas de ejecución o hilos de ejecución (procesos ligeros) paralelos. Indica que un mensaje

sólo se envía si una condición se satisface. La condición se escribe entre corchetes y puede referenciar a otro objeto (ver�gura 1.27).

obj1:ClaseA obj2:ClaseB obj3:ClaseB

[Condición X]Mensaje

[No Condición X]Mensaje

Figura 1.27: Diagrama de secuencias; condicionales

5. Iteración: Indica una acción que se repite mientras se satisfaga una cierta condición. Se denota con el símbolo * previo ala condición (ver �gura 1.28).

buscador:Buscador lista:Lista

*[hayMasElementos]getNextElement()

Figura 1.28: Diagrama de secuencias; iteración

6. Invocación recursiva: Se representa superponiendo un rectángulo al que representa al método desde el que se activó (ver�gura 1.29).

controlador:Controlador

complicado:Algoritmo<<create>>

hazAlgo()

mensajeRecursivo()

Fin de la llamada:

"hazAlgo()"<<destroy>>

Figura 1.29: Creación de objeto, invocación recursiva y destrucción de objeto

Nótese que, en los diagramas de secuencias, los estímulos se denotan mediante �echas horizontales trazadas desde la línea devida del objeto que los envía hasta la del objeto que los recibe. En cuanto a las señales de creación y destrucción de objetos, lacreación se representa mediante un mensaje de creación que termina en la cabecera de una línea de vida (la de la nueva instanciacreada), mientras que la destrucción se representa mediante un aspa que �gura al �nal de la línea de vida del objeto destruido(véase la �gura 1.29).

Diagrama de colaboración Muestran las interacciones que tiene lugar entre los objetos, organizadas en términos de los objetosy de los enlaces que los conectan (véase el ejemplo de la �gura 1.30). Proporcionan una visión de la secuencia de interaccionesalternativa de la proporcionada por los diagramas de secuencia. Para cada diagrama de colaboración existe un diagrama desecuencias equivalente (se puede generar de un modo automático un tipo de diagrama a partir del otro). Es un diagrama máscompacto que el de secuencias pero muestra peor la evolución temporal.

Diagrama de estados

La evolución de un sistema a lo largo del tiempo puede modelarse como la transición entre una serie de estados de unautómata o máquina de estados. Los diagramas de estados del UML representan el comportamiento de las instancias de clases,componentes o casos de uso, como máquinas de estados extendidas que constan siempre de un estado inicial y un estado �nal. Acada estado se asignan:

Nombre.


jugador:Jugador primerDado:Dado

segundoDado:Dado

1:r1:=lanzar()

2:r2:=lanzar()

jugar()

Figura 1.30: Diagrama de colaboración

Variables de estado.Acciones que se realizan al entrar en el estado.Acciones que se realizan hasta el abandono del estado.Eventos que disparan transiciones hacia otros estados.Transiciones, asociadas a los respectivos conjuntos de eventos que las estimulan y, opcionalmente, a un conjunto deacciones, parámetros y condiciones que habilitan o no la transición.

Un estado puede, alternativamente, expandirse en una máquina de estados representable a su vez mediante un diagrama deestados. Las máquinas de estado representadas por los diagramas de estados soportan concurrencia: esta se representa medianteun estado compuesto que se expande en un diagrama con más de un estado de inicio y un único estado �nal.

El estado de un sistema en un instante dado resume la historia de eventos pasados. Por ejemplo, imaginemos un ascensor queen cuanto llega al sótano (área restringida a la que sólo se puede acceder con llave) sube a los pocos segundos por sí mismo paraevitar que posibles intrusos puedan acceder a las viviendas. Por otra parte el ascensor puede estar subiendo, bajando o parado.Estar en el sótano se considera otro estado diferente. El comportamiento del ascensor aparece representado mediante un diagramade estados UML en la �gura 1.31.

Subiendo Parado Bajando

Sótano

llegar

llegar

llegar

subir

bajar

time-out

Figura 1.31: Diagrama de estados para un ascensor

Diagrama de actividades Representan asimismo un caso particular de máquinas de estado donde las transiciones entre estadosno son motivadas por eventos externos, sino que tienen lugar espontáneamente cuando concluyen las actividades a ellos asociadas.Modelan el comportamiento del sistema haciendo énfasis en la participación de los objetos en ese comportamiento. Se centran enmostrar el �ujo de control y datos entre objetos y su comportamiento interno (las acciones que conllevan sus operaciones y cómose ven afectados por ellas), en lugar de mostrar su respuesta a eventos. Las máquinas de estado representadas por los diagramasde actividades soportan también concurrencia.

Para diseñarlos se sugiere seguir la siguiente estrategia:

1. Identi�car una clase que participa en el comportamiento que se desea modelar, cuyas actividades de proceso deban serespeci�cadas.

2. Identi�car las distintas actividades cuyo modelado es de interés.3. Identi�car estados, �ujos y objetos.

Este tipo de diagrama es útil para modelar el �ujo de trabajo de un negocio a alto nivel (véase el ejemplo de la �gura 1.32).Los diagramas de actividades constan de los siguientes elementos:

1. Punto inicial. Representa el estado inicial. Se denota mediante un círculo negro.2. Punto �nal. Representa el estado diana. Se denota mediante un círculo negro rodeado exteriormente por otro círculo.3. Actividades. Estados de actividad donde se ejecutan conjuntos de acciones que pueden describir parcial o totalmente una

operación de clase o acciones de usuario. Un estado de actividad puede expandirse en un nuevo diagrama de actividadesque suponen una descomposición funcional de la actividad principal. Se simbolizan mediante rectángulos con bordesredondeados.

4. Transiciones. Suponen el paso de una actividad a otra. Se representan mediante �echas.


Ducha

Desayuno Ver tele

Andar

[EstadoAnimo = Deportista] [EstadoAnimo = Sedentario]

Abrir garaje Abrir garaje

Abrir puerta

Esperar 30 segundos

Cerrar puerta

Conducir

Figura 1.32: Diagrama de actividades; concurrencia, bifurcación e indicación

5. Actividades concurrentes. Se representan mediante sus correspondientes actividades y una barra negra de la que partenlas transiciones que las inician.

6. Bifurcaciones: Se representan mediante un rombo o sencillamente mediante dos �echas que parten de una actividad haciaotras dos. En cualquier caso, la condición se expresa en cada uno de los ramales entre corchetes.

7. Indicaciones: Representan eventos que pueden enviarse o recibirse. El envío se denota mediante un rectángulo acabado en�echa, y la recepción mediante la �gura complementaria.

En los diagramas de actividades el �ujo de control y el �ujo de objetos no aparecen separados: ambos se modelan como tran-siciones de estados. Es aconsejable de�nir diagramas bien anidados y asegurar que habrá una máquina de estados correspondientea cada actividad ejecutable, así como evitar el �go to� en la medida de lo posible.

Modelado del comportamiento

Los diagramas de interacción habrán de utilizarse principalmente cuando haya interés en conocer cómo se comportan lasinstancias implicadas en un caso de uso, en de�nitiva, cómo interaccionan unas con otras y cómo se reparten las responsabilidades(cómo atienden los requisitos). Sirven para identi�car las interfaces de las clases. Un buen diagrama de interacción habrá deincluir indicaciones sobre el contexto de la interacción (mediante especi�caciones textuales).

Los diagramas de secuencia permitirán ilustrar escenarios típicos, mostrando el orden explícito de los estímulos, por lo queresultarán muy adecuados para el modelado del tiempo real. El �ujo deberá presentarse de izquierda a derecha y de arriba a abajo.

Los diagramas de colaboración muestran cómo se coordinan las entidades en la estructura del sistema y cómo el controlpasa de unas instancias a otras. Al hacer explícitas las relaciones entre instancias, ayudan a realizar su agrupación en módulos.Permiten asimismo concentrarse en los efectos de la ejecución sobre las diferentes instancias.

Los diagramas de estado serán útiles para mostrar el comportamiento de una única instancia dentro de un caso de uso. Per-miten capturar el comportamiento dinámico de sistemas de cierta complejidad, resultando particularmente adecuados para elmodelado de sistemas reactivos orientados a eventos (p.e., interfaces de usuario, dispositivos hardware o protocolos de comuni-cación).

Los diagramas de actividad permitirán observar el comportamiento a través de varios casos de uso o muchos hilos de eje-cución. Serán particularmente útiles en aplicaciones que requieran modelos de �ujo de control o de �ujo de datos/objetos (p.e.,modelos de procesos de negocios), en lugar de modelos dirigidos por eventos. En estos casos, el comportamiento no dependemucho de eventos externos, los pasos se ejecutarán de principio a �n sin ser interrumpidos, y entre pasos se producirán �ujos deobjetos/datos. Estos diagramas se construirán normalmente durante el análisis para estudiar qué actividades ocurren, en lugar dequé objetos son responsables de ellas (posteriormente se podrán usar Particiones para asignar esas responsabilidades).


1.3.5. Modelo estructural de implementaciónEl modelo estructural de implementación muestra los aspectos de implementación de un sistema: la estructura del código

fuente y objeto, y la estructura de la implementación en ejecución. En UML se utilizan dos tipos de diagramas para expresar estosmodelos: los diagramas de componentes y los diagramas de despliegue. Las principales entidades implicadas en los primeros soncomponentes y, en los segundos, componentes y nodos.

Un Componente se de�ne como una parte modular, reemplazable y signi�cativa del sistema que empaqueta una imple-mentación y expone una interfaz. Un Nodo designa un objeto físico de ejecución que representa un recurso computacional.

Diagrama de componentes

Modelan una visión estática del sistema en el nivel de implementación. Ilustran la organización y las dependencias entrecomponentes software. Los componentes pueden ser código fuente (clases de implementación,una implementación de una inter-faz, �cheros de scripts...) binarios, ejecutables, tablas, o cualquier otro tipo de elemento que forme parte de la implementaciónde sistema o de su documentación. En un diagrama de componentes no necesariamente estarán presentes todos los componentes.En la �gura 1.33) se muestra cómo un componente implementa una interfaz.

GUI Dibujar

Componente

Interfaz

Figura 1.33: Diagrama de componentes

El estándar de UML de�ne cinco estereotipos para caracterizar tipos de componentes: executable, library, table, �le y docu-ment.

Ejecutables Estos componentes se modelan siguiendo los siguientes pasos (véase el ejemplo de la �gura 1.34):

<<executable>>Servidor.exe

<<library>>TCP/IP.dll

<<library>>BaseDatos.dll

Figura 1.34: Ejecutable que usa una librería de comunicaciones y una base de datos

1. Se identi�can los componentes y posibles particiones del sistema en susbsistemas, determinándose cuáles son susceptiblesde ser reutilizados, se agrupan por nodos y se realiza un diagrama por cada nodo que se desee modelar.

2. Se identi�ca cada componente con su correspondiente estereotipo.3. Se relacionan los componentes entre sí.

Código fuente Modelar estos componentes es útil para expresar las dependencias que existen entre los módulos, con vistas acomponer librerías o programas ejecutables (véase el ejemplo en la �gura 1.35).

Diagrama de despliegue

Este diagrama re�eja la organización del hardware. Su entidad central es el nodo. Los nodos pueden o no tener capacidadpara ejecutar componentes. Un nodo lleva asociado un nombre y un conjunto de componentes (que pueden representarse sólomediante sus nombres o bien mediante un diagrama de componentes). Cada nodo puede estar físicamente conectado a otrosnodos. La utilidad principal de este tipo de diagramas es la modelización de redes (véase el ejemplo de la �gura 1.36).


<<file>>Agenda.c

<<file>>Agenda.h

<<file>>stderr.h

<<file>>stdio.h

Figura 1.35: Dependencias entre el código

Servidor

BDOracle

ClienteSevilla

AplicaciónVentas

AplicaciónServidor

ClienteMadrid

AplicaciónVentas

ClienteBarcelona

AplicaciónVentas

Figura 1.36: Diagrama de distribución

Tutorial posteriorResumen de contenidos

En este capítulo introductorio se abordan la división en fases de un proyecto (ciclos de vida), las características de lasmetodologías que ordenan estas fases, y la notación de modelado actualmente más difundida (UML).

1. Metodologías: Se plantea el porqué de la ingeniería del software. Se de�ne lo que se entiende por sistema y por metodología(una forma podría decirse �burocrática� de producir un sistema con costes y tiempos controlados). Se establece tambiénuna clasi�cación de las metodologías que, al igual que se verá con los ciclos de vida, pertenecen a dos tipos principales:estructuradas y orientadas a objetos.

2. Ciclos de vida: Se explica lo que es un ciclo de vida, las fases de las que se compone y la forma en que se ordenanestas fases. Se presenta una clasi�cación de los distintos ciclos de vida que se pueden dar en un proyecto. Básicamente,se consideran dos tipos principales que son: el ciclo de vida en cascada (el más antiguo y preferido en las metodologíasestructuradas) y el ciclo de vida en espiral (el más nuevo, preferido en las metodologías orientadas a objetos). Estos sedividen a su vez en varios subtipos que cumplen diferente propósitos. Los ciclos de vida son:

a) Ciclo de vida en cascada. Subtipos: ciclo de vida en V, Sashimi, cascada con subproyectos, cascada incremental ycascada con reducción de riesgos.


b) Ciclo de vida en espiral. Subtipos: Fuente y además los subtipos cascada incremental y cascada con reducción deriesgos, que también se pueden considerar como ciclos de vida en espiral.

c) Notaciones de especi�cación y diseño (UML): Se proporciona una introducción a la notación UML. E xisten librosmuy completos al respecto, aquí solo se presentan nociones básicas para componer un diagrama pequeño partiendode un texto o para entender diagramas ya construidos. El motivo de explicarlo en este tema es su utilización a lo largode todas las fases del ciclo de vida.

Ejercicios y actividades propuestos1. ¿Qué ciclos de vida elegiría para cada una de estas aplicaciones?

Una biblioteca de cálculo numérico para hacer operaciones con matrices de gran tamaño.Una agenda electrónica para guardar teléfonos, direcciones, etc. Es más que posible que se quiera ampliar.

2. ¿Cómo representaría la siguiente descripción en UML?:Una casa está en una ciudad, las casas pueden estar en un edi�cio y varios edi�cios forman una manzana. Hay casas queson chalés y los chalés pueden estar solos o adosados. Los chalés y los edi�cios están en una calle, dentro de la cual tienenun número asignado; por otra parte, las casas que forman parte de edi�cios tienen un número que indica el piso y unaletra. Una casa pertenece a una calle. Una zona es un conjunto de calles y cada una es conocida por un código postal. Unconjunto de zonas es una ciudad, que tiene un nombre y pertenece a una provincia, la cual a su vez pertenece a un país, elcual está en un continente o como mucho en dos (p. ej Rusia). En una casa viven personas y el número de personas quevive en una casa puede ser cualquiera. Una persona puede vivir en más de una casa (por ejemplo, durante el verano en unay en el invierno en otra). Una casa es poseída por una o varias personas.

3. Represente la siguiente situación en UML:Una persona pertenece a tres posibles grupos: Estudiante, Trabajador o Jubilado. Un trabajador puede tener empleo o no ypuede cambiar entre cualquiera de estas situaciones siendo despedido si está trabajando o siendo contratado si está parado.Cuando llega a los 65 años pasa a estar jubilado; a su vez, un estudiante pasa a ser un trabajador cuando acaba sus estudios.Un jubilado no cambia de estado (y si cambia, mal asunto).

4. En el ejercicio anterior con los tres grupos de personas, ¿Cómo representaría en un diagrama de clases a un estudiante quetrabaja al mismo tiempo?

5. Represente la siguiente descripción en UML:Un paracaidista se tira desde un avión, momento a partir del cual está cayendo deprisa. Pueden pasar dos cosas: el paracaí-das se abre o no se abre. Si no se abre existe un segundo paracaídas de emergencia que se despliega tirando de una anilla.Nuevamente pueden pasar dos cosas. Si todo sale bien, tanto con el primero como con el segundo se pasa al estado decayendo despacio. Se puede estar cayendo deprisa un máximo de 30 segundos y cayendo despacio un tiempo que oscilaentre 0 y 5 minutos en función del momento en el que se abra uno de los paracaídas. Al �nal el paracaidista llega al suelo.

6. Represente esta situación en UML:Un objeto A (cliente) hace una llamada a un objeto B (interfaz) que se encarga de crear un objeto C (servidor) si no existeninguna instancia de C. En caso contrario no hace nada, es decir, sólo puede existir una instancia de C. En cualquier casodevuelve a A una referencia al objeto C, entonces A invoca una función de C, tras lo cual A imprime un mensaje y seautodestruye.

Extensión de conocimientosEste tema también se puede estudiar en [Som98, cap. 1], [Haw98, caps. 1 al 3] ó [Sch92, caps. 1 y 2]. Se pueden refrescar

conocimientos previos en [CCEG00] y otros libros especí�cos de asignaturas previas o simultáneas sobre Ingeniería del Software,por ejemplo en [Hum95] ó [Hum01].

La revista en línea �Software Development� http://www.sdmagazine.com/, puede ser una buena fuente para encontrarartículos (en inglés) sobre temas de IS en general. Dentro de �The Collection of Computer Science Bibliographies�. Tambiénpuede ser interesante la guía al SWEBOK (Software Engineering Body of Knowledge) en http://www.swebok.org/ que es unainiciativa conjunta del IEEE y la ACM para expresar el conjunto de conocimientos básicos en Ingeniería del Software.

Sobre el lenguaje UML se pueden extender conocimientos en varios libros especí�cos del tema como [JBR00a, JBR00b,Fow97] ó [Sch01b], o bien a través de las páginas de Internet: http://www.omg.org/technology/uml/ del Object Managen-emt Group (OMG).

Hay una herramienta de libre distribución para la representación mediante diversos métodos (incluido UML) en http://wwwhome.cs.utwente.nl/~tcm/ llamada TCM (Toolkit for Conceptual Modeling). En http://argouml.tigris.org/ sepuede encontrar ARGOUML que es una herramienta libre (implementada en Java y licencia BSD) especí�ca para la repre-sentación en UML. También se puede encontrar información en http://uml.sourceforge.net/index.php sobre el progra-ma �UML Object Modeller� (para KDE en GNU/Linux) para dibujar diagramas de UML. La herramienta Eclipse, en http://www.eclipse.org tiene plugins para UML y algunos son gratuitos. Se pueden encontrar en http://eclipse-plugins.2y.net/eclipse/index.jsp.

Capítulo 2

Fase de especi�cación

Tutorial previoIntroducción

Una vez que el proyecto ha superado tanto la decisión de desarrollarlo como su estudio de viabilidad (estudiado en otrasasignaturas) empieza la fase de especi�cación, donde se emplean un conjunto de técnicas para captar requisitos y representarlosde un modo útil para la fase posterior de diseño.

Se dice que la especi�cación es la fase importante mientras que el diseño es la difícil. La importancia se debe al alto costeeconómico y de tiempo que supone un requisito mal entendido. La realización de una buena especi�cación no es tan sencillocomo se puede pensar en un principio, pues muchas veces el propio cliente no tiene una imagen clara del sistema �nal o surgennuevas necesidades a mitad del desarrollo. Este problema puede afrontarse de varias formas: usando técnicas de comunicaciónefectivas, estudiando el dominio del problema, creando modelos del problema real y, por último, revisando la especi�cacióncreada.

Se deben documentar y registrar debidamente todas las actividades anteriores para que en caso de que surja algún problemase pueda seguir su traza hasta los requisitos.

Relación con otros temasLa extracción, modelado, análisis y representación de requisitos o especi�caciones es un problema muy relacionado con

la Ingeniería del Conocimiento, por tanto sería conveniente que el alumno repasara los temas correspondientes en las asignat-uras previas relacionadas. Es necesario ejercitar la capacidad de abstracción para poder expresar lo que pide el cliente en unarepresentación formal que responda a sus expectativas.

Objetivos del temaEs necesario en esta fase separar y entender los conceptos propios de cómo especi�car un problema y cómo hacer útil esas

especi�caciones para posteriores fases del desarrollo. El alumno debe ser capaz de extraer y representar un conjunto de requisitosexpresados en lenguaje natural a una representación que sirva de entrada a la fase siguiente de diseño.

Guía de estudio y esquemaEn el tema se exponen los contenidos teóricos genéricos. El alumno debe identi�car cuáles son los elementos correspondientes

a la obtención y el análisis de los requisitos en esos ejemplos para generalizarlo a otros problemas.

1. Obtención de requisitos: se estudia directamente en el material en esta guía.2. Análisis de requisitos: este apartado se puede estudiar en [Pre05, secs. 7.1 a 7.7, 7.6, 7.7] y [Pre05, secs. 8.1 a 8.4] o en la

quinta edición [Pre01, secs. 11.1 a 11.3].3. Representación de requisitos: el contenido se estudiará en [Pre05, secs. 8.1 a 8.4] (aunque se denomina �modelado del

análisis�) o en la quinta edición [Pre01, sec. 11.5 y cap. 12].4. Análisis orientado a objetos: en [Pre05, cap.8] o en la quinta edición [Pre01, cap. 21].5. Validación de requisitos: en [Pre05, sec.7.8] o en la quinta edición [Pre01, sec. 11.6] junto con el apartado correspondiente

en esta guía.6. Bases de documentación: en el contenido del apartado correspondiente de esta guía.

2.1. Obtención de requisitosLos métodos tradicionales en cualquier ingeniería requieren como primer paso la obtención de los requisitos en forma de

especi�caciones por parte del cliente. Este problema habitualmente tiene complicaciones debidas al paso entre el lenguaje natural27

28 Fase de especi�cación

y los lenguajes más formales en ingeniería. Por lo tanto la obtención de los requisitos es un paso complejo y que no tiene unasolución sencilla. Se suelen utilizar los métodos de pregunta-respuesta o los de cuestionarios plantilla para per�lar la versióninicial, pero se requieren sucesivas iteraciones (incluso con otras fases de desarrollo) antes de obtener unas especi�cacionesadecuadas.

2.1.1. IntroducciónUn requisito se de�ne como una capacidad que el sistema debe tener porque el cliente lo ha pedido explícita o implícitamente.

Lógicamente, la determinación del conjunto de requisitos es el primer paso que se debe dar en la construcción de una aplicación.Existen dos subtareas en la obtención de los requisitos:

Análisis: Consiste en comprender el problema del cliente para conseguir una lista de las características que debe tener elproducto.Especi�cación: Consiste en traducir los requisitos a un documento con un formato concreto que pueda servir de entrada ala fase de diseño.

La obtención de requisitos es difícil por varias razones:

La naturaleza de los requisitos es cambiante.Surgen nuevos requisitos en cualquier momento.El cliente puede no tenerlos claros.Pueden existir malos entendidos debidos a:

• Falta de conocimientos por parte del equipo desarrollador sobre el problema.• Falta de conocimientos técnicos (informáticos) por parte del cliente para expresarse con claridad.

Análisis

Como se ha dicho es la captación de un listado de requisitos que se van a conseguir comunicándonos con el cliente. Parafacilitar esta comunicación se han desarrollado varias técnicas: entrevistas, prototipos, desarrollo conjunto de aplicaciones (JointApplication Development, JAD), plani�cación conjunta de requisitos (Joint Requirements Planning, JRP) y casos de uso delUML.

Especi�cación

Después del análisis se redacta un documento técnico con todos los requisitos anteriores, este documento tiene que tener estaspropiedades:

Completitud: Están todos los requisitos.Concisión: Es importante no hacer una novela, hay que contar lo que hay pero pensando que quien se lea el documentocobra por horas.Legibilidad: Es similar al punto anterior, pero el sentido de este es la claridad.Consistencia: No existen contradicciones entre diferentes puntos del documento.Facilidades de prueba: De algún modo se debe poder comprobar cada uno de los requisitos.Facilidades de cambio: Es bastante probable que el documento cambie a lo largo del ciclo de vida (requisitos añadidos,eliminados o cambiados).Facilidades de seguimiento: Debe ser posible comprobar si se van cumpliendo los objetivos.Factibilidad: Los objetivos de�nidos deben ser alcanzables con el tiempo y presupuesto disponibles.

Tipos de requisitos

Requisitos funcionales: Dicen qué debe hacer el sistema, en el sentido de servicios proporcionados al usuario.

Requisitos no funcionales: Hablan de características del sistema, como pueda ser la �abilidad, mantenibilidad, sistema oper-ativo, plataforma hardware, lenguaje de programación, etc.

En el siguiente texto: Se desea desarrollar un editor de texto para programadores que emplee menos de cinco megas de memo-ria y tarde menos de un segundo en cargarse. Debe reconocer y colorear adecuadamente el código fuente de programas escritosen C, C++, Java y Modula 2. Debe ser capaz de colorear asimismo texto escrito en LATEX. El editor deberá ser multiplataforma, olo que es lo mismo, funcionará en Linux, las diferentes versiones de Windows y Mac. El lenguaje de programación es indiferentepero el editor no debe presentar problemas de �fuga de memoria�. Debe ser capaz de invocar comandos para compilar y recogeren una ventana los errores y advertencias de dicha compilación. El código fuente se documentará con Doxygen.

Siguiendo la de�nición los requisitos funcionales son:

Debe reconocer y colorear adecuadamente el código fuente de programas escritos en C, C++, Java y Modula 2.

2.1 Obtención de requisitos 29

Debe ser capaz de colorear texto escrito en LATEX1.Debe ser capaz de invocar comandos para compilar y recoger en una ventana los errores y advertencias de dicha compi-lación.

Y los no funcionales. Se pone en paréntesis el tipo de característica:

Emplea menos de cinco megas de memoria. (e�ciencia)Tarda menos de un segundo en cargarse. (e�ciencia)Debe ser multiplataforma. (sistemas operativos)El editor no debe presentar problemas de �fuga de memoria� (corrección)Se documentará con Doxygen (método de desarrollo)

2.1.2. Técnicas de obtención de requisitosEn esta sección veremos las técnicas de comunicación con el cliente.

Entrevistas genéricas

Las entrevistas en términos generales generan estrés porque se ponen de mani�esto las carencias de formación, de conocimien-to o realización del propio trabajo, problemas personales o interpersonales, pero sobre todo porque suele haber algo en juego.

Aparte del tema del estrés en toda reunión suele haber una relación de poder entre los integrantes. Las relaciones de poderson el mejor contaminante de la buena comunicación, ejemplos: �si digo que nuestra parte del proyecto tiene tal problemadelante del jefe de mi jefe directo, mi jefe directo me despide�, el individuo X impone una alternativa peor que otras porque nolas comprende o por interés personal: �el servidor web de contenidos se programa en C desde cero (porque es el lenguaje que Xconoce)� o �las compras de hardware se hacen siempre en la empresa Z (que es de mi hermana)�, etc.

Figura 2.1: Relaciones de poder en la empresa. El dibujo es del autor argentino Quino (Joaquín Salvador Lavado)

Debido a lo anterior, sobre éste tema de las entrevistas y reuniones se han vertido rios de tinta. El resultado ha sido una�burocratización� del proceso que es necesaria por como funciona la psicología humana. Veremos un resumen de lo esencialadaptado a las necesidades de construir una especi�cación software.

Aunque también existan otras técnicas, ésta es inevitable. La tendremos al menos al inicio del proyecto. Una entrevista genéri-ca sigue este patrón: Preparación, Desarrollo y Análisis.

Fases de la entrevista genérica

Preparación: Es el trabajo previo. Tiene cuatro apartados: documentarse sobre el tema que se va a tratar, seleccionar a lagente que se va a entrevistar, determinar el objetivo de la entrevista y logística de la misma

• Documentación: El entrevistador se informa acerca del tema a tratar. Puede hacerlo de varias formas:1Sistema de proceso de textos de varias décadas de antigüedad muy usado por investigadores


◦ Estudiar la bibliografía sobre el tema.◦ Estudiar documentos sobre proyectos similares.◦ Inmersión dentro de la organización para la que se desarrolla el proyecto

• Personal: Se seleccionan las personas a las que se va a entrevistar. Existen dos tipos de personas:

◦ Directivos: Dan una imagen de alto nivel de la empresa. Puede ser útil para determinar la estructura arquitectóni-ca de la aplicación. Ejemplos (inspirados en la �gura): política que se sigue para comprar escobas, departamentoresponsable de su compra, almacenaje y distribución, etc.

◦ Plantilla de base: Dan una imagen de un grano más �no. Son los que pueden concretar las funciones a imple-mentar. Ejemplos (inspirados en la �gura): un requisito sería el desarrollo de una escoba especializada en barrerrincones, otra con mango más largo para llegar al techo, etc.

• Determinar el/los objetivos de la entrevista. Previamente a la entrevista se pueden distribuir a los entrevistadoscuestionarios sobre el tema a tratar y una introducción.

• Logística. La tercera entrada del DRAE2 de�ne la logística como Conjunto de medios y métodos necesarios parallevar a cabo la organización de una empresa, o de un servicio, especialmente de distribución. En este contextotrata de los temas prácticos acerca de como discurre la entrevista: lugar, hora, minimizar interrupciones, encontrar unhueco común en la agenda de todos, etc.

DesarrolloHay tres etapas [PV96]:

1. Apertura: El entrevistador se presenta e informa al entrevistado de cuales van a ser los puntos tratados en la entre-vista.

2. Desarrollo: El entrevistado debería hablar el 80 % del tiempo. No debe durar más de dos horas para no cansar alentrevistado, que empezará a cometer errores y a dar señales de �estoy perdiendo el tiempo y tengo otras cosas quehacer�. Consiste en realizar una serie de preguntas. Dichas preguntas se pueden clasi�car en dos tipos:

• Preguntas abiertas, también conocidas como de contexto libre. No se pueden contestar con �Si� o �No�. Porejemplo: ¿Cuál es la lista de pasos para dar de baja un producto?. Más tarde se pasa a preguntas más concretas.

• Preguntas cerradas, tienen una respuesta simple y concreta, como a�rmaciónes o negaciones o de tipo numérico.

Hay tres modelos

• Forma de expresarse: Se deben evitar los tecnicismos que el entrevistado pueda no conocer.• Psicología: El problema fundamental de las entrevistas es que se trata con personas en vez de con máquinas, por

eso la información conseguida puede tener omisiones o imprecisiones. Hay que tener en cuenta las siguientesreglas entre muchas otras de la comunicación no verbal.◦ No insinuar que el entrevistado debería saber algo que no sabe para que no se ponga a la defensiva. También

hay que dejar claro que los intereses del entrevistador son únicamente la adquisición de requisitos, no hacerun examen de conocimientos, y por tanto las lagunas que pueda tener no trascenderán a sus superiores.

◦ Lenguaje del cuerpo: Dicen los psicólogos que el 90 % de la comunicación es no verbal. Se debe estar atentoa los signos que puedan denotar inseguridad en algunos temas para preguntar a otras personas.

◦ Usar técnicas para mantener la atención del entrevistado, como por ejemplo evitar las circunstancias quesometan a la persona a interferencias o intentando estimular su creatividad.

3. Terminación: Se hace un resumen de la información recogida (para validar que es correcta) y, de ser necesario, secita para la siguiente entrevista. Uno de los problemas recurrentes en la especi�cación de requisitos es que sueleser difícil tener este tipo de sesiones. Se debe intentar que el entrevistado se sienta cómodo y con la sensación dehaber aprovechado el tiempo para que podamos recurrir a él en otra ocasión. Por último se le agradece que nos hayadedicado su tiempo.

Análisis: Se trata de ver como utilizar los conocimientos adquiridos. Para ello las actividades son:

1. De tipo administrativo, como por ejemplo, pasar a limpio la entrevista.2. Asimilación de la información: Se contrasta con otras entrevistas, bibliografía, etc. Se llega a conclusiones.3. Evaluación de la entrevista: ¿Qué objetivos se pretendía conseguir y qué es lo que realmente se ha conseguido?

Para validar una vez más la entrevista se puede mandar la documentación generada al entrevistado.

Desarrollo conjunto de aplicaciones (JAD)

En el apartado anterior se vio una somera introducción a una entrevista clásica donde existe un entrevistador y un entrevistado.Ahora se contempla un tipo de entrevista desarrollada por IBM para varias personas. Consiste en un conjunto de reuniones en unperiodo de entre dos y cuatro días. Se basa en cuatro principios:

2Diccionario de la Real Academia de la Lengua


1. Dinámica de grupo: Son técnicas de discusión para generar ideas y confrontar puntos de vista.2. Uso de ayudas audiovisuales: Diagramas, transparencias, pizarras, etc.3. Modo de trabajo sistemático: Se sigue el guión que se expone en las fases. Todo el mundo tiene un rol asignado.4. Filosofía de documentación WYSIWYG (What You See Is What You Get).

Existen dos tipos de sesiones JAD: JAD/Plan, para obtención de requisitos y JAD/Design, para el diseño. Veremos sólo elprimero.

Ventajas del JAD:

1. La información obtenida se puede contrastar in situ porque están todos los interesados. En las entrevistas individuales estees un proceso lento. Además en esta contrastación participan tanto los usuarios como los desarrolladores, esto quiere decirque los requisitos que se obtienen son los correctos.

2. Los clientes se sienten involucrados en el proceso de desarrollo porque ellos mismos participan en la exploración de losproblemas que se plantean, con lo cual la resistencia al cambio será menor.

Inconvenientes:

1. Al ser varias personas es difícil encontrar un hueco en la agenda de todos para estas reuniones.2. Es una técnica complicada.

Participantes: Participan de ocho a doce usuarios a parte de los analistas. Hay seis tipos:

1. Jefe del JAD: Debe tener las características clásicas de una persona que dirige una reunión: Dotes de comunicación yliderazgo. Son deseables también conocimientos de psicología para por ejemplo conseguir que todo el mundo participe oevitar con�ictos, pero sobre todo, para dirigir la sesión a sus objetivos.

2. Analista: La función realizada es la de secretario de la sesión. Es la persona encargada de poner por escrito la información.No es una tarea tan trivial como parece, tiene que ser alguien que haya comprendido el tema y lo pueda expresar bien conlas herramientas que se empleen.

3. Patrocinador: Es el cliente: ya sea el jefe de la empresa contratante o quien tiene la capacidad para decidir si se sigue conel desarrollo. Debe informar de cuales son las necesidades que cubrirá el producto.

4. Representantes de los usuarios: En el JAD/Plan son directivos porque proporcionan una visión global del sistema. En elJAD/Design son usuarios.

5. Desarrolladores: Son las personas que pueden informar de las di�cultades de implementación de ciertas características.6. Especialistas: Son la �autoridad� a consultar sobre aspectos puntuales tanto por parte de los usuarios como por parte de

los desarrolladores.

Fases del JAD

1. Adaptación: El jefe del JAD es quien debe adaptar la sesión a las características propias del proyecto en curso. Para ellodebe:

Documentarse sobre la organización y el proyecto.Decidir cuestiones organizativas sobre las sesiones JAD: Número y duración, lugar (mejor si es fuera de la empresapara evitar interrupciones), fechas, etc.Seleccionar a los participantes adecuados para cada reunión.

2. Sesión JAD: Está dividida en una serie de pasos:

Presentación: Al igual que en la entrevista individual, el jefe del JAD y el patrocinador ejecutivo se presentan. Elpatrocinador explica los motivos del proyecto. El jefe del JAD explica la mecánica de la reunión.De�nición de requisitos de alto nivel: Esto ya es parte del trabajo productivo. El jefe del JAD hace preguntas del tipo:¿Qué bene�cios se esperan del sistema? ¿Cuáles son los recursos disponibles? Estos requisitos se van escribiendoen algún medio que permita que todo el mundo lo pueda ver, por ejemplo transparencias.Delimitar el ámbito del sistema: Cuando se ha reunido un conjunto de requisitos lo su�cientemente grande se lespuede organizar y decidir el ámbito del sistema-Documentar temas abiertos: Si un tema queda sin resolver se debe documentar para otra sesión y asignar una personaresponsable de su solución.Concluir la sesión: El jefe del JAD hace un repaso de la información obtenida con los participantes. Es el momentode hacer correcciones o añadidos.

3. Organización de la documentación: Se trata de producir un documento con la información recabada en la fase anterior.Hay tres partes que se siguen secuencialmente.

Compilar la documentación: La documentación recogida se redacta en un documento normalizado.


Revisar la documentación: Se envía la documentación a los participantes para que efectúen correcciones.Validar la documentación: El patrocinador ejecutivo da su aprobación.

Plani�cación conjunta de requisitos (JRP)

Es un subconjunto de las sesiones JAD. Se caracterizan por estar dirigidas a la alta dirección y en consecuencia los productosresultantes son los requisitos de alto nivel o estratégicos. La plani�cación de una sesión consiste en varios pasos:

1. Iniciación: Se delimita el alcance del plan de sistemas de información, unidades organizativas afectadas y per�les nece-sarios para la reunión.

2. Búsqueda: Se identi�can objetivos, situación actual e información al respecto.3. Lugar: Es importante que al igual que en la sesión JAD sea fuera de la organización para evitar interrupciones. La sala

de reuniones debe ser además confortable y equipada con el mobiliario adecuado. Las ayudas audiovisuales pueden serpizarras, proyectores, etc. Se debe contar además con ordenadores equipados con herramientas CASE, procesadores detexto, hojas de cálculo y herramientas de prototipado.

4. Seleccionar a los participantes. Los per�les son los siguientes:

Jefe JRP: Debe tener las mismas aptitudes que en el caso del JAD.Patrocinador: El que respalda económicamente el proyecto.Director del proyectoConsultores: Traduce los requisitos de usuario a información estructurada inteligible por los usuarios.Especialista en modelización: Elabora los modelos en la reunión.Usuarios de alto nivel: De�nen los procesos organizativos y los sistemas de información afectados por el plan desistemas de información y las prioridades de implantación.

5. Redactar la agenda de asuntos a tratar. Esta agenda debe ser plani�cada asignando tiempos para cada cuestión.6. Realización: Discurre igual que la sesión JAD.

Brainstorming

Este es otro tipo de entrevista de grupo. A diferencia del JAD que está fuertemente estructurada, el brainstorming (tormenta deideas) se caracteriza precisamente por lo contrario, porque aunque existe un jefe del grupo, su función es meramente anecdótica.El objetivo es la generación de ideas novedosas para la resolución de un problema. Su utilización es adecuada al principiodel proyecto, pues puede explorar un problema desde muchos puntos de vista. Una característica importante es que sirve paraencontrar soluciones novedosas.

Ventajas del brainstorming

1. Es fácil (la única norma es que vale todo y no se puede criticar a nadie). Esta técnica es muy usada por este motivo.2. No está tan formalizado como el JAD.

Inconvenientes

1. No proporciona resultados con mucho nivel de detalle.2. Es difícil reunir a todo el mundo.

Fases del Brainstorming

1. Preparación

Se selecciona a las personas involucradas, es decir: Jefe de la reunión, usuarios y desarrolladores.Se les convoca a una hora y en un lugar determinados.

2. Desarrollo: El jefe expone el problema a resolver, entonces cada persona expone sus ideas para la solución. El jefe da lapalabra a una persona u otra. Cuando se han generado su�cientes ideas se termina la reunión. Normas a seguir:

No se permite la crítica a ningún participante, diga lo que diga.Se promueven las ideas más creativas aunque no sean factibles para estimular la creatividad del resto del grupo.Cuantas más ideas salgan mejor.Los participantes pueden añadir ideas propias a las ideas de otros.

3. Consolidación: Es similar a la fase de análisis en la entrevista individual o la fase de organización de la documentación deJAD. Se divide en tres partes

Clasi�car ideas para agruparlas o fusionarlas.


Descartar ideas peregrinas o poco factibles.Priorizar ideas en función de su importancia.

4. Documentación: Se pone por escrito la información que sale de la fase de consolidación.

Prototipos

Un prototipo es una versión reducida de la aplicación �nal. Se puede construir con dos �losofías[Som98]:

1. Prototipos de desarrollo rápido. Sirven para obtener y validar requisitos. Cuando han cumplido esta �nalidad se �desechan�.2. Prototipo inicial: Se desarrolla el sistema de un modo incremental partiendo de una versión inicial.

El segundo caso se ha discutido ya en el capítulo dedicado a ciclos de vida. El primer caso sigue el proceso indicado en la �gura2.2.

Requisitosiniciales

Desarrolloprototipo

Evaluación

Especificación

Desarrollosistema

Validación

Figura 2.2: Obtención y validación de requisitos a partir de prototipos [Som98]

Un prototipo no es utilizable como sistema �nal porque se ha desarrollado con la máxima rapidez y en consecuencia:

1. Los requisitos no funcionales tales como rendimiento, seguridad, etc no se implementan.2. No hay documentación.3. El sistema será caro de mantener porque el prototipo habrá sufrido muchos cambios a lo largo del desarrollo y su estructura

estará en mal estado.4. La calidad del código es mala.

Existen tres técnicas de desarrollo rápido de prototipos[Som98] que se pueden usar conjuntamente: Lenguajes de alto nivel,Programación de bases de datos y Componentes reutilizables.

Lenguajes de alto nivel: Son lenguajes de gran nivel de abstracción que necesitan menos líneas de código para hacer lomismo que en un lenguaje de bajo nivel como C. Ejemplos de lenguajes de alto nivel son: Lisp, Smaltalk y Prolog. Loslenguajes de alto nivel tienen la desventaja de cargar mucho al sistema, razón por la cual no están más extendidas, aunqueeste motivo es cada vez menos importante dada la potencia de las máquinas actuales.Cuando se desarrolla un prototipo hay que responder algunas cuestiones para escoger el lenguaje, tales como cual es elmejor lenguaje para el dominio del problema que se está abordando. Por ejemplo, Lisp y Prolog pueden ser adecuados


para inteligencia arti�cial, Java si se necesita un software multiplataforma, etc. Se deben tener en cuenta asimismo factorestales como las facilidades suministradas por la herramienta para la construcción automatizada de interfaces de usuario, laexperiencia que tiene con dichas herramientas el personal con el que contamos, si se puede conectar o forma parte de unaherramienta CASE, etc.Programación de bases de datos: Una base de datos tiene un lenguaje de programación que permite manipularla y utili-dades. Un lenguaje de cuarta generación es el lenguaje de programación de la base de datos y su entorno. Son interesanteslas herramientas que permiten acceder a la base de datos a través de un navegador ya que así se puede acceder desdecualquier punto.Componentes reutilizables: El principio en el que descansan los componentes es que es más rápido usar software hechoque hacerlo, por ejemplo, los beans de Java. Si además existe algún mecanismo que permita que esos componentes secomuniquen y se integren fácilmente, mejor. Problemas que se pueden presentar:

1. No existen todos los componentes necesarios para el prototipo que se quiere desarrollar, con lo que hay que desarrol-larlos.

2. Los componentes existen, pero no son exactamente lo que se necesita y hay que adaptarlos.

El desarrollo de prototipos con reutilización se puede hacer a dos niveles:1. Nivel de aplicación: Los sistemas que componen la aplicación pueden ser compartidos por otras aplicaciones. Por ejemplo:

se puede insertar un grá�co desarrollado con una aplicación en otra. Las aplicaciones actúan como si estuvieran conectadasentre si al estilo de las tuberías de Unix.

2. Nivel de componente: Los componentes están integrados en un armazón estándar, como puede ser un lenguaje de desarrollode componentes, por ejemplo: PYTHON o PERL o algo más general como CORBA, DCOM o JAVABEANS.

JAVABEANS es un ejemplo de componentes reutilizables. Son un tipo de componentes escritos en Java, que generalmente tienenalgún tipo de interfaz grá�ca (Enterprise-JavaBeans sin embargo no es así, pues se ocupa más de la lógica de la aplicación). Suscaracterísticas son:

1. Tienen un constructor predeterminado sin parámetros (es decir, un bean es una clase que cumple una serie de restricciones)2. Son persistentes. La persistencia es la capacidad de un objeto de convertirse en un �ujo de bytes para por ejemplo poder

ser escrito en disco o recuperado del mismo. Un objeto persistente puede sobrevivir al apagado del sistema y seguirfuncionando del mismo modo.

3. No son nunca clases abstractas, es decir, siempre se pueden crear instancias de ellos.4. Para escuchar un evento se usan estas dos funciones:

public void addEventListenerType(EventListenerType evento)public void removeEventListenerType(EventListenerType evento)

5. La forma de dar valor o conocer el valor de una propiedad es con métodos de la forma: getX() y setX(Propiedadpropiedad). Si la propiedad es booleana en vez de getX() se usa isX(). Si la propiedad es indexada se utiliza: getX(intindex) ó getX() que devuelve un array y los métodos para asignar valor serían: setX(int index, propiedad) ósetX(Propiedad[] propiedad).

Casos de uso

Son una forma de especi�car los requisitos de un sistema. Un caso de uso consiste en una interacción de algo externo alsistema y el sistema. Fueron introducidos por Jacobson en 1992. Aunque es una técnica de�nida dentro del ambiente del análisisorientado a objetos no tieneque ver con objetos, se podría utilizar perfectamente dentro del análisis estructurado. Más adelanteveremos la técnica de los casos de uso. Un caso de uso:

Describe la interacción entre un actor externo al sistema y el sistema con texto en lenguaje natural.Representa los requisitos funcionales desde el punto de vista del usuario y por lo tanto produce un resultado observablepor él.Es iniciado por un único actor.Realiza una funcionalidad concreta.

Los objetivos de los casos de uso son:Comprender la funcionalidad del sistema.Discutir con el usuario nuestra visión de esa funcionalidad.Identi�car conceptos del sistema, clases, atributos y operaciones.Validar el análisis y el modelo del diseño.Proporcionar información para las pruebas del sistema y de aceptación.

Existen dos tipos de elementos:1. Actores: El actor puede ser tanto una persona como otro sistema que juega un rol en la interacción con el mismo. Un

mismo rol puede ser desempeñado por varias personas y una persona puede desempeñar más de un rol. Un usuario no esun actor, sino que asume un rol cuando interactúa con el sistema y por lo tanto funciona como un tipo de actor.

2. Caso de uso: Es la interacción que se quiere modelar. Pueden agruparse en paquetes y tener relaciones entre ellos.


Identi�car actores Un caso de uso se compone de actores y de interacciones de esos actores sobre el sistema. por lo tanto, loprimero es buscar actores. Teniendo en cuenta lo que es un actor, hay que encontrar la siguiente información:

1. Identi�car los usuarios del sistema. Para ello tener en cuenta para quien se está diseñando o con que personas va ainteractuar de un modo directo (actores principales) y quienes va a tener un papel de supervisión o mantenimiento delsistema (actores secundarios).

2. Identi�car los roles que juegan esos usuarios desde el punto de vista del sistema. Hay varios tipos, gestores de alto nivel,gente que introduce datos, etc.

3. Identi�car otros sistemas con los cuales exista comunicación. Estos sistemas también se consideran como actores dadoque son algo externo a nuestro sistema.

Identi�car operaciones Una vez que se tienen los actores se trata de encontrar los casos de uso, como lo que tenemos en estemomento son los actores, partimos de esta base para encontrar la información que falta. Los actores interactuaran con el sistemarealizando un conjunto de tareas que tendremos que enumerar y manejarán información, tanto la que suministren al sistemacomo la que el sistema les suministre a ellos. Una vez que se dispone de los actores y de los casos de uso hay que encontrar lasrelaciones que hay entre ellos. Las relaciones que hay entre casos de uso son de dos tipos:

Aquellas en las que uno extiende a otro: Son muy parecidos (comparten muchos pasos) pero tienen ligeras diferenciasadaptadas a la forma particular en la que se realiza una tarea.Aquellas en las que uno usa a otro: En esta situación un caso de uso es similar a una función o subrutina que es llamadapor otro.

Otra forma de hallar casos de uso es hacer una lista de eventos. Un evento es una ocurrencia a la que el sistema tiene queresponder. No supone un diálogo como un caso de uso porque ocurre de un modo atómico. Los pasos a seguir en este caso sonpor un lado identi�car todos los eventos a los que el sistema tiene que responder y luego relacionarlos con los actores adecuados.

Una vez identi�cados estos casos de uso podemos sacar otros nuevos de varias formas:

1. Por variaciones respecto a casos de uso existentes si:

Existen diferentes actores que puedan utilizar un mismo caso de uso pero con variaciones signi�cativas.Existen diferentes versiones del mismo caso de uso con variaciones signi�cativas.

2. Buscando el caso de uso opuesto a uno dado, por ejemplo, si tengo dando de alta cliente podría existir el caso de uso dandode baja cliente

3. Preguntarnos que tiene que ocurrir para que se cumplan las precondiciones de un caso de uso, por ejemplo, para hacer unpedido es necesario que el cliente entre con su password, con lo que tiene que existir un caso de uso para dar de alta.

Ejemplo En una universidad el proceso de matriculación es el siguiente: Si el alumno es nuevo se le pide cierta documentación(fotocopia del DNI o pasaporte, fotografías, certi�cados, etc.) si es antiguo se pide sólo la fotocopia del DNI o pasaporte. Elalumno escoge las asignaturas en las que desea matricularse. En este proceso puede ocurrir algún error, como que escojaalguna en la que no pueda matricularse, que no escoja ninguna, etc. El sistema deberá dar los oportunos mensajes de error paraayudar al usuario. Otro tipo de alumno es el que pide traslado de expediente de otra universidad. En este caso debe aportar lamisma documentación que el alumno nuevo y la documentación que acredite que ha aprobado las asignaturas que sean. Debehacer asimismo una solicitud de convalidación de asignaturas. Cuando esto acaba se matricula como un alumno antiguo. Porotra parte, los profesores usan el sistema para poner las cali�caciones. Una vez que el profesor se identi�ca adecuadamentey selecciona la asignatura y la convocatoria el sistema presenta un listado y el profesor rellena las notas. Existe un procesoanálogo para modi�car la nota de un alumno. El jefe de estudios es el profesor que se encarga de gestionar el proceso decomposición de horarios: introduce el número de horas, los equipos docentes y otros datos y restricciones de cada asignatura, elsistema genera unos horarios usando un algoritmo de investigación operativa y los presenta al jefe de estudios. Si está satisfechotermina el proceso, en caso contrario introduce una nueva restricción y se generan nuevamente los horarios. Si las restriccionesson demasiado fuertes puede ocurrir que no exista solución, en este caso el sistema imprime una advertencia y el jefe de estudiosdebe eliminar alguna restricción.

Para resolver el problema vamos a adoptar la estrategia recomendada.

1. Identi�car actores

Identi�camos usuarios. Hay dos: Estudiantes y profesores.Identi�camos roles que juegan. Los estudiantes por un lado consultan datos (asignaturas disponibles en las quepueden matricularse) e introducen datos (asignaturas en las que quedan matriculados). Los profesores tienen losmismos papeles. El jefe de estudios juega un papel de gestor de alto nivel.Identi�camos otros sistemas: No hay.

2. Identi�car operaciones:

Matricular a un alumno.Introducir notas.


Modi�car notas.Generar horarios.

Posibles variaciones de los casos de uso existentes: La operación de matriculación es diferente en función del tipo dealumno: Nuevo, Antiguo y el que viene de otra universidad. Podemos derivar de eso tres posibles casos de uso:

Matricular alumno nuevo.Matricular alumno antiguo de esta universidad.Matricular alumno nuevo que viene de otra universidad.

Estos tres casos de uso se parecen entre si. Podemos pensar que entre ellos puede haber algún tipo de relación de herencia.Como la herencia trata de hallar la parte común deberíamos buscar el más sencillo. El más sencillo es el de matricularalumno antiguo, los otros dos son modi�caciones más o menos complicadas.El hecho que un caso de uso haya generado otros dos relacionados entre si por herencia nos puede hacer pensar que alactor relacionado (alumno) le pasa lo mismo. Lo que está claro es que un mismo alumno sólo va a emplear uno de los trescasos de uso, aunque no creemos que esto por si solo sea motivo para crear tres tipos de alumno3. Si que está claro sinembargo que se deben hacer tres casos de uso diferentes y relacionados del modo en el que lo están porque son funcionesque di�eren ligeramente entre ellas.Se puede pensar en crear un caso de uso para seleccionar las asignaturas en las que se matricula un alumno. El criteriopara generar el caso de uso o dejarlo como una mera línea en la descripción de los casos de uso va a ser la complejidaddel proceso. Vamos a suponer que es lo su�cientemente complejo4, con lo que tendremos el caso de uso Seleccionarasignaturas, usado por los casos de uso de matriculación.Hemos visto también que hay un tipo de profesor especial llamado Jefe de estudios. Como tiene una función especí�cadentro de la organización podemos suponer que es un tipo de actor con algunas características que le distinguen del profesornormal.

Figura 2.3: Conjunto de casos de uso

Dar detalle a los casos de uso descritos Esto que se ha descrito hasta ahora es la forma de construir un armazón de casos deuso, veamos como se pueden concretar un poco más. Para cada caso de uso hay que:

Describir la información de entrada y de salida.Identi�car las precondiciones, o lo que es lo mismo, todo lo que se tiene que cumplir antes de realizar el caso de uso.Identi�car las postcondiciones; lo que se tiene que cumplir después de realizar el caso de uso.La descripción detallada del caso de uso contiene:

• Una descripción textual de su objetivo.• Variantes posibles para realizar este caso de uso. Diagramas de interacción de detalle (de secuencia o colaboración).• Errores y excepciones posibles.

Relacionar el caso de uso con la interfaz de usuario que lo representa.Especi�car el diálogo que da solución al caso de uso.

La descripción de un caso de uso consta de los siguientes elementos:3Esto es subjetivo, la otra solución sería perfectamente válida. La ventaja de esta es no complicar el modelo más de lo necesario.4Sólo para poner el ejemplo

2.2 Análisis de requisitos 37

1. Descripción del escenario.2. Suposiciones acerca del escenario.3. Condiciones previas para el caso de uso.4. Se expresa en una tabla con la secuencia de interacciones. La tabla puede tener una columna con el curso normal de

acontecimientos y otra con posibles alternativas. Cada alternativa representa un error o excepción y no tienen su�cienteentidad como para ser un caso de uso al que se llegue con una relación extiende.

5. El actor responsable.6. Resultado una vez terminado el caso de uso.

Actores y casos de uso abstractos

Un caso de uso que sólo exista para ser utilizado por otros casos de uso se dice que es abstracto. Como ese caso de uso notiene un actor que lo utilice, nos inventamos un actor �cticio (abstracto). La manera en la que se relaciona este nuevo actor �cticiocon los de verdad es por medio de la herencia. Por lo tanto, todos los actores que utilicen un caso de uso que a su vez utilizaun caso de uso abstracto heredarán de él. Un actor puede heredar de cualquier otro, tanto si es abstracto como si no, con lo quehereda también todas las funcionalidades a las que puede acceder.

Otras clasi�caciones de los casos de uso

Casos de uso esenciales y de implementación Cuando se está en la fase inicial de recopilar todos los casos de uso, no seponen en detalle, se indica su nombre y poco más (casos de uso esenciales, o de trazo grueso). Cuando se va a implementar elcaso de uso hay que de�nirlo con más detalle (caso de uso de implementación o trazo �no).

Casos de uso temporales Son aquellos iniciados no por un actor, sino por un evento de reloj. Se debe indicar el momento enel que esto ocurre, p. ej.: cada 500 milisegundos. La notación consiste en poner el caso de uso en un óvalo con línea de puntos ocon símbolo de reloj.

Casos de uso primarios y secundarios Los casos de uso secundarios son aquellos que existen por que son necesarios paraque el sistema funcione pero que no son inherentes a su funcionalidad.

2.2. Análisis de requisitosUna vez que hemos extraído los requisitos del problema es necesario convertir esos requisitos en un modelo del problema

que distinga los elementos que forman parte de los requisitos y las relaciones entre ellos, así como las funcionalidades esperadasdel conjunto. En este apartado se estudiarán las diferentes estrategias o patrones de modelado del problema.

El contenido de este apartado se estudia en [Pre05, secs. 7.1 a 7.7, 7.6, 7.7] y [Pre05, secs. 8.1 a 8.4] o en la quinta edición[Pre01, secs. 11.1 a 11.3].

2.3. Representación de requisitosComo resultado del análisis de los requisitos especi�cados inicialmente, se obtiene un modelo del problema que es necesario

representar de una manera formal que permita la aplicación de técnicas sistemáticas para su resolución. Existen diversos lengua-jes y métodos de especi�caciones que tienen características diferentes según el método posterior del desarrollo. Por ejemplodiagramas entidad-relación para modelado, diagramas contextuales, plantillas o marcos conceptuales, diagramas funcionales,etc. El método más extendido de representación es mediante técnicas orientadas a objetos y los lenguajes asociados a ellas.

El contenido de este apartado se estudia en [Pre05, secs. 8.1 a 8.4] o en la quinta edición [Pre01, sec. 11.5 y cap. 12].

2.4. Análisis orientado a objetosEl análisis orientado a objetos representa el problema en términos de clases, sus propiedades y sus relaciones. El modelo que

resulta de este análisis utiliza técnicas muy diversas, algunas como la de los casos de uso son perfectamente aplicables también alanálisis estructurado. La ventaja del análisis orientado a objetos es que la representación que se logra del mundo es más próximaa la realidad. La transformación de los requisitos en términos de usuario a la especi�cación en términos de sistema informáticoes más suave.

El contenido de este apartado se estudia en [Pre05, cap .8] o en la quinta edición [Pre01, cap. 21].

2.5. Validación de requisitosEs importante que antes de continuar el desarrollo del software a partir de los requisitos modelados y representados se haga

la comprobación de su validez, comparando la correspondencia con las descripciones iniciales y si el modelo responde a lorealmente deseado. Esta parte de la fase de requisitos se suele realizar comprobando que el modelo obtenido responde de lamisma forma deseada que la que el cliente pide por un lado, y por otro a la inversa si otras respuestas del modelo convencen al


cliente. En algunos casos será necesario construir prototipos con una funcionalidad similar muy reducida para que el cliente sehaga una idea aproximada del resultado.

De�niciónLa validación de los requisitos comprueba que estos son correctos. Esta fase debe realizarse o de lo contrario se corre el

riesgo de implementar una mala especi�cación, con el costo que eso conlleva.Los parámetros a comprobar por la especi�cación son [Som01]:

1. Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener puntos de vista distintos ynecesitar otros requisitos.

2. Consistencia: No debe haber contradicciones entre unos requisitos y otros.3. Completitud: Deben estar todos los requisitos. Esto es imposible en un desarrollo iterativo, pero, al menos, deben estar

disponibles todos los requisitos de la iteración en curso.4. Realismo: Se pueden implementar con la tecnología actual.5. Veri�cabilidad: Tiene que existir alguna forma de comprobar que cada requisito se cumple.

El contenido de este apartado se completa con [Pre05, sec. 7.8] o en la quinta edición [Pre01, sec. 11.6].

2.6. Bases de documentaciónYa desde los primeros pasos del desarrollo del software es necesario comenzar a organizar toda la documentación. En primer

lugar se han de gestionar los formatos en los que se va a escribir la documentación. Preferiblemente se deben utilizar herramientasde ayuda que semi-automatizan la recopilación de la documentación durante el desarrollo. Evidentemente, tanto las especi�ca-ciones iniciales del problema (en lenguaje natural probablemente) como las especi�caciones �nales de los requisitos (en unlenguaje formal), pasando por los estados intermedios de análisis y modelado y las diferentes pruebas de validación se debenguardar como parte inicial de la documentación.

El documento de especi�cación de requisitos SRS (Software Requirements Speci�cation) es como el contrato o�cial que seestablece entre los desarrolladores y los clientes. Incluye tanto los requisitos funcionales como los no funcionales. Una recolec-ción correcta y completa es crucial para el desarrollo de un sistema de información exitoso. Para alcanzar el mayor grado decalidad es esencial que el SRS sea desarrollado de un modo sistemático e inteligible, en cuyo caso re�ejará las necesidades delusuario y será útil para todos. Lo que sigue es una plantilla del SRS según el estándar IEEE 830.

En la portada se indican: Nombre de la empresa, Nombre del proyecto, Número de versión y Fecha.El índice debe constar de las siguientes secciones: Introducción, Descripción general, Requisitos especí�cos, Gestión del

cambio del proceso, Aprobación del documento e Información de soporte. El desarrollo del índice anterior debe contener lasiguiente información:

1. Introducción. Las siguientes subsecciones dan una visión general del documento.

a) Propósito: Identi�ca el propósito del documento y el per�l de usuario al que está dirigido.b) Alcance. En esta subsección:

Se identi�ca el nombre de los productos software que se van a desarrollar.Se explica lo que hacen los productos y lo que no hacen.Se describen las aplicaciones del software especi�cado, incluyendo bene�cios y objetivos.Se debe ser consistente con especi�caciones similares de más alto nivel si existen, es decir, en el caso de queestas sean las especi�caciones de un subsistema.

c) De�niciones, acrónimos y abreviaturas: Es un listado de las de�niciones de todos los términos, acrónimos y abre-viaturas necesarios para interpretar correctamente el SRS. La información puede ser proporcionada con referencias aapéndices.

d) Referencias:

Se da la lista completa de todos los documentos referenciados en cualquier lugar de la SRS.Se identi�ca cada documento por título, versión, fecha y responsable de su redacción.Se especi�can las fuentes desde las que se pueden obtener las referencias.

e) Visión de conjunto: Describe la organización general de la SRS.

2. Descripción general: Describe los factores generales que afectan al producto y sus requisitos. No se de�nen requisitosespecí�cos (sección 3), sólo su contexto.

a) Perspectiva del producto: Relación del producto con otros similares. Si el producto es independiente y autocontenidose debe decir aquí. Si es un componente de un sistema mayor aquí deben estar los requisitos para que el sistema mayorlo pueda utilizar e identi�ca las interfaces entre el sistema y el software. Se puede poner un diagrama de bloques paramostrar las interconexiones del sistema con otros e interfaces externas.

2.6 Bases de documentación 39

b) Interfaces del sistema: Identi�ca la funcionalidad del software y la descripción de la interfaz. Especi�ca:

Características lógicas de cada interfaz entre el producto y sus usuarios.Todos los aspectos relativos a la optimización de la interfaz con los usuarios.

1) Interfaces hardware: Se especi�can las características de cada interfaz entre el producto y los componenteshardware. Incluye la con�guración, dispositivos soportados, cómo son soportados y protocolos.

2) Interfaces software: Es una lista de otros productos software e interfaces con otras aplicaciones.a′ Para cada producto se debe incluir: Nombre, Mnemónico, Número de versión y Fabricante.b′ Para cada interfaz se debe desarrollar en: Motivos para interactuar con el producto y De�nición de la interfaz

acerca de contenido de los mensajes y formatos.3) Interfaces de comunicaciones. Por ejemplo protocolos de comunicaciones.

c) Restricciones de memoria.d) Operaciones normales y especí�cas tales como:

1) Modos de operación en la empresa del usuario.2) Operaciones interactivas y no interactivas.3) Funciones de proceso de datos.4) Operaciones de backup.

e) Requisitos de instalación. Se de�nen:

1) Requisitos para datos y secuencias de inicialización especí�cos para un emplazamiento, misión o modo deoperación.

2) Características necesarias para adaptar el software a un entorno concreto.f ) Funciones del producto: Es un resumen de las funciones que proporciona el software. A veces esta lista puede

copiarse de las especi�caciones de alto nivel. Este resumen:

Debe ser inteligible por el cliente con una sola lectura.Se pueden utilizar elementos textuales o grá�cos para mostrar las diferentes funciones y sus relaciones. No esun grá�co del diseño, sólo muestra relaciones lógicas entre funciones y variables.

g) Características del usuario: Es una lista de aptitudes y motivos para ellas.h) Restricciones: Descripción general de limitaciones que afectarán a los desarrolladores tales como: Políticas, Limita-

ciones de hardware, Interfaces con otras aplicaciones, Operaciones en paralelo, etc.i) Suposiciones y dependencias: Lista de cada uno de los factores que afectan a los requisitos. No son restricciones de

diseño pero un cambio en ellos afectaría a los requisitos.j) Requisitos no implementados: Lista de requisitos que se dejan para futuras versiones.

3. Requisitos especí�cos: Es una lista de los requisitos a un nivel de detalle lo su�cientemente �no que permita a los de-sarrolladores diseñar un sistema que los satisfaga. Deben incluir las entradas, las salidas y las funciones suministradas enrespuesta a entradas o para suministrar una salida.

a) Interfaces externos: Es una lista detallada de todas las entradas y salidas. Complementa las descripciones de interfazen el apartado 2b pero sin repetir información.

b) Requisitos funcionales: De�nen las acciones que el software tiene que tomar para producir las salidas a partir de lasentradas. Ejemplos:

Comprobar la corrección de la entrada.Secuencia correcta de las operaciones.Respuestas a situaciones anormales.Relaciones entre entradas y salidas.

c) Requisitos de rendimiento: Especi�ca requisitos estáticos y dinámicos. Un requisito estático de rendimiento puede serel número de usuarios conectados simultáneamente. Un requisito dinámico sería por ejemplo el número de transac-ciones por minuto. Estos requisitos deben especi�carse en unidades medibles.

d) Requisitos relativos a bases de datos: Requisitos lógicos que tiene que tener la información que se deje en la base dedatos. Por ejemplo: Tipos de información, frecuencia de uso, etc.

e) Restricciones de diseño: Restricciones de diseño que pueden ser impuestas por otros estándares, limitaciones dehardware, etc.

1) Conformidad con los estándares: Requisitos derivados de la existencia de estándares. Por ejemplo: Formato delos informes, nombre de los datos, procedimientos de contabilidad o auditorías.

f ) Atributos del sistema software: Son propiedades del sistema. El hecho de tenerlas constituye un requisito. Los másimportantes son: Fiabilidad, Disponibilidad, Seguridad, Mantenibilidad y Portabilidad.


g) Organización de los requisitos. Los requisitos deben ser presentados de un modo jerárquico para que la cantidad deinformación no sea abrumadora para el lector y se puedan comprender con facilidad. No existe un modo óptimo parapresentarlos. Esto es una lista de posibles criterios.

Modo del sistema: Es el modo de operación. Algunos sistemas se comportan de un modo muy distinto en funcióndel modo en el que estén.Clases de usuario: En función de a quién esté dirigido interesará resaltar unas funciones u otras.Objetos: Se pueden agrupar las funciones en términos de las suministradas por jerarquías de objetos.Características: Son servicios observables externamente que puede requerir una secuencia de entradas y salidasen un orden concreto.Estímulo: Algunos sistemas se describen mejor en términos de estímulo - respuesta.Respuesta: Clasi�cación en función del tipo de respuesta que da el sistema.Jerarquía funcional: Se trata de organizar el sistema en términos de funciones con entradas y salidas similares.

h) Comentarios adicionales.

4. Gestión del cambio del proceso: Seleccionar la gestión del proceso de cambio que deba ser usada para identi�car, registrar,evaluar y actualizar el SRS para que re�eje el alcance de los cambios en el proyecto y sus requisitos.

5. Aprobación del documento: Identi�car a las personas que deben dar su visto bueno. Deben constar su nombre, �rma yfecha.

6. Información de soporte. Hace que este documento sea más fácil de usar. Incluye índice y apéndices.


En este capítulo se ven las formas de captura de requisitos y su representación. La �nalidad de esta fase es producir undocumento que represente los requisitos y que sirva de entrada para la fase de diseño. El análisis es la forma de conseguir losrequisitos y la especi�cación la forma de representarlos.

Técnicas de obtención de requisitos

1. Entrevistas: Consiste en hablar con el cliente. Hay que tener sobre todo conocimientos de psicología para facilitar lacomunicación.

2. JAD: Consiste en un tipo de entrevista muy estructurada aplicable a grupos de personas. Cada persona juega un papelconcreto y todo lo que se hace está reglamentado.

3. JRP: Es un subconjunto de JAD.4. Brainstorming: Es un tipo de entrevista que no tiene ningún tipo de estructura o reglamentación. Genera ideas novedosas.5. Prototipos: Se trata de construir una mini-aplicación inicial para clari�car algunos puntos y luego tirarla o bien para usarla

como base para añadir más cosas.6. Casos de uso: Representan grá�camente los requisitos funcionales y relaciones de uso y generalización entre ellos. Es la

técnica de�nida en UML. No está necesariamente asociada a la programación orientada a objetos, puede usarse tambiéncon metodologías más clásicas.

Análisis de requisitos

Características del análisis antes de la existencia de técnica alguna del tema: Monolítico, ambiguo, difícil de mantener yredundante. Posteriormente (años 70 y 80) surge el análisis estructurado moderno que es grá�co y soluciona algunos de los prob-lemas anteriores. Su objetivo es modelar por separado los datos, procesos y el control usando como nexo común el diccionariode datos.

Técnicas de representación de requisitos

1. Diagramas de �ujo de datos: Se describen los elementos de los que consta, lo que es el diagrama de contexto y heurísticaspara desarrollarlo.

2. Diagramas de �ujo de control: Es similar a los DFD.3. Diagramas de estados: Son un tipo de modelización matemática usada también en diseño de circuitos, compiladores, etc.4. Modelo Entidad / Relación: Usado para representar los datos y la forma en la que se relacionan entre ellos.5. Diccionario de datos: Se puede de�nir como el pegamento que mantiene unido a todo lo anterior. Es una descripción

detallada de los datos.

2.6 Bases de documentación 41

Análisis orientado a objetos

Es la otra forma de ver el problema. Se representa el mundo en función sobre todo de los datos, características e interrela-ciones entre ellos en vez de en función de los algoritmos o funciones.

Propiedades de un sistema orientado a objetos: Abstracción, Encapsulamiento, Modularidad, Jerarquía, Polimor�smo, Per-sistencia.

Conceptos importantes: Clase, Objeto y Atributos.

Sesión CRC: Es una simulación hecha por personas del funcionamiento dinámico de un sistema orientado a objetos. Se basaen que cada persona representa una clase y su interacción con las demás. Cada clase tiene escritas sus propiedades en unatarjeta.

Identi�cación de clases, atributos y relaciones entre clases.

Re�namiento del modelo: Consiste en otro conjunto de heurísticas para eliminar elementos sobrantes o identi�car otros nuevosen el modelo anterior.

Validación de requisitos

Es la comprobación de que todo el trabajo anterior se ha realizado bien.

Bases de documentación

Es el documento que resulta de todo lo anterior pero orientado al cliente, es decir, a las obligaciones contraídas con él, la ideano consiste en usar este documento como entrada para otra fase. Se ha tomado la plantilla de documento de�nida por el estándarIEEE 830.

Ejercicios y actividades propuestas1. Compare los diagramas del análisis estructurado y los del UML. ¿Existen similitudes?

1. ¿Qué diferencia existe entre los requisitos que se obtienen en una sesión JAD y una sesión JRP?2. Si se tiene que construir un sistema novedoso en el que los requisitos están claros pero se tienen dudas técnicas acerca de

la mejor solución discuta que tipos de sesiones serían las más adecuadas.3. Un videoclub tiene diferentes tipos de precios para sus películas en función de su categoría. Cada película tiene un código

y aunque haya varias películas con el mismo título el código es distinto para cada una. Los datos que interesa guardar decada película son: Título, Director, Actores principales, Localización, Categoría y Código. Los clientes tienen asignado unCódigo de cliente y se conoce también su Nombre, Dirección, Teléfono. El videoclub hace préstamos a sus clientes pordos días y se podrá sancionar a quien se retrase según el número de días.

Desarrolle los DFD que sea posible.Desarrolle la especi�cación de los procesos.

Extensión de conocimientosSobre la obtención, análisis y representación de requisitos también se puede estudiar en [Som98, cap. 2 y 3], [Haw98, caps.

5 al 10] ó [Sch92, caps. 3 y 4]. Sobre el análisis orientado a objetos también se puede ver [RBP+96].El libro [GW89] completo es especí�co sobre requisitos.OUTREACH PROJECT TOOL es una plataforma de libre distribución para gestión de proyectos a través de Web muy orientada

al manejo de los requisitos y la comunicación entre desarrolladores y clientes. Ver en http://outreach.sourceforge.net/(hay enlace a una �demo� interactiva).

Capítulo 3

Fase de diseño

Tutorial PrevioIntroducción

Una vez que se han identi�cado los requisitos para el problema, es necesario idear y componer la forma de la solución parael problema. El diseño es la fase en la que se estudia el problema, se identi�can las características que tendría una solución yse analiza a su vez cada una de esas características. En la fase de diseño es más efectivo utilizar patrones y modelos conocidospara ir resolviendo partes del problema, es decir modularizar el problema y proyectarlo en módulos en la solución. Aunque, elproceso de diseño es en gran medida ad hoc, es decir, no está tan formalizado como las otras fases y por tanto se apoya bastanteen la experiencia e intuición de los diseñadores.

En este tema se van a proponer las formas de diseño convencionales, una comparación de los más utilizados y la validacióno comprobación de su adecuación, junto con la parte correspondiente de documentación de todo el proceso. Principalmente haydos tipos de diseño:

Diseño funcional: Parte de una vista de alto nivel que se va re�nando progresivamente. En este caso la atención se focalizaen la forma de procesar los datos.Diseño orientado a objetos: Se entiende el sistema como un conjunto de objetos. Para distinguirlos se identi�can los tiposde datos, sus operaciones y atributos asociados. Los objetos se comunican entre ellos enviándose mensajes.

La validación del diseño comprueba si se siguen las especi�caciones del diseño y se cumplen requisitos de calidad. La mejorforma de redactar la documentación consiste en seguir una plantilla de un documento estándar rellenando varias secciones.

Relación con otros temasPara la comprensión de este tema es conveniente tener en mente los diferentes modelos de programación que han ido es-

tudiando en la carrera y que se utilizarán después en la fase del tema siguiente. También es necesario haber preparado el temade requisitos para entender cuáles son los elementos de entrada en el diseño. Es necesario saber: descomponer un problema enotros más pequeños, identi�car las estructuras de datos necesarias e identi�car �ujos de datos entre subsistemas y cuáles son lasentradas y salidas necesarias para cada subsistema.

Objetivos del temaSe deben obtener los conocimientos sobre las técnicas de diseño más efectivas y utilizadas, junto con la comprensión de las

diferencias entre esas técnicas que permitan conocer cuál es el método más apropiado en cada situación. Se pretende en estetema introducir los dos tipos de métodos que existen de diseñar un sistema y proporcionar un método genérico para redactar ladocumentación.

Guía de estudio y esquemaA la vez que se estudia el contenido teórico del tema es conveniente ir siguiendo los ejemplos propuestos y realizar algunos

ejercicios simples con otros problemas, utilizando los problemas supuestos por el alumno como ejercicios en el tema 2.Como se ha dicho antes, la tarea de diseño es en gran medida ad hoc y depende de la experiencia de los diseñadores. El

mejor método para aprender a diseñar es realizar todos los ejercicios propuestos (tanto explícitos, en el tutorial posterior, comoimplícitos o genéricos mencionados anteriormente).

Se incluye en esta guía una pequeña introducción a los patrones. El resto del contenido de este apartado se estudia en[Pre05, cap. 9] o en la quinta edición [Pre01, cap. 13].Diseño estructurado. Este apartado se estudiará en [Pre05, caps. 10 y 11] o en la quinta edición [Pre01, caps. 14 y 16].Diseño orientado a objetos. Este apartado se estudiará principalmente en esta guía y en [Pre05, caps. 10 y 11] o en la quintaedición [Pre01, cap. 22]. Se incluye una pequeña introducción a los patrones de diseño.Validación y con�rmación del diseño. Este apartado se incluye en esta misma guía.43

44 Fase de diseño

Documentación: especi�cación del diseño. Este apartado está contenido en [Pre05, caps. 9 y 11] o en la quinta edición[Pre01, sec. 13.8].

3.1. Conceptos y elementos del diseñoSe incluye en esta guía una pequeña introducción a los patrones. El resto del contenido de este apartado se estudia en [Pre05,

cap. 9] o en la quinta edición [Pre01, cap. 13].Partiendo de los requisitos para el problema, es necesario decidir cómo se va a realizar la solución para el problema. Existen

unos cuantos principios de diseño básicos y elementos que se deben considerar antes de ponerse a decidir un diseño en particular.En primer lugar el principio de modularidad está presente en casi todos los aspectos del diseño al igual que en muchas otrasáreas de ingeniería. Junto con las especi�caciones funcionales y de datos hay que considerar también el diseño de la interfaz y elacoplamiento de las diferentes partes.

3.1.1. PatronesEn otras ramas de la ingeniería establecidas desde hace más tiempo, existen prototipos de soluciones estándar para problemas

conocidos, por ejemplo, los tornillos siguen una normativa en cuanto a diámetro de la rosca, longitud, material, forma de lacabeza, etc. Los patrones se pueden ver como un intento de hacer eso mismo pero a diferentes niveles de abstracción.

Es frecuente encontrarse con el mismo tipo de problema más de una vez. Si se ha diseñado una solución para ese problemasería deseable ahorrar trabajo de algún modo. Un patrón da una solución ya ensayada para un tipo de problema. La idea partió enun principio del arquitecto Christopher Alexander en los años 70.

Un patrón de diseño identi�ca las clases y sus instancias, sus papeles y colaboraciones y la distribución de responsabilidades.Un anti-patrón es un error y las consecuencias que se deducen de él. Hay dos tipos:

Una mala solución a un problema y la situación causada.Una descricción como salir de una situación mala.

Un framework (suele traducirse por �armazón� pero usaremos el término inglés) es un conjunto integrado de componentes quecolaboran para proporcionar una arquitectura reutilizable para una familia de aplicaciones.

Las diferencias entre los patrones y los frameworks son:

Grado de abstracción, que en el caso del patrón es mayor.Los patrones son elementos arquitectónicos más pequeños (un framework puede contener varios patrones).Los patrones están menos especializados.

Tipos de patrones

Hay muchas clasi�caciones posibles, una sencilla podría ser esta:

Patrones arquitectónicos: Es la organización estructural de un sistema. Consiste en un conjunto de subsistemas prede�nidosy sus responsabilidades. Incluye reglas para organizar las relaciones entre ellos.Patrones de diseño: Son esquemas para re�nar los subsistemas o componentes de un sistema o las relaciones entre ellos.Describen estructuras de comunicaciones entre componentes en un contexto.Patrones de codi�cación: Es un patrón de bajo nivel que describe como implementar aspectos particulares de los compo-nentes o relaciones entre ellos con un lenguaje de programación.Patrones de análisis: Son un conjunto de prácticas que guían la obtención de un modelo.Patrones de organización: Describen la estructuración del personal en las organizaciones.

La diferencia entre unos tipos y otros está tanto en el nivel de abstracción como en el contexto en el que son aplicables.Fuera de esta clasi�cación general se pueden encontrar otros tipos de patrones para situaciones más especí�cas como progra-

mación concurrente, interfaces grá�cas, organización y optimización del código, etc.

Características de los patrones

Para que un patrón se pueda considerar como tal debe pasar unas pruebas llamadas test de patrones, mientras tanto recibe elnombre provisional de proto-patrón. Según Jim Coplien un patrón debe cumplir con estos requisitos:

Soluciona un problema.Ha sido probado.La solución no es obvia.Describe participantes y relaciones entre ellos.Tiene un componente humano.

3.1 Conceptos y elementos del diseño 45

Descripción de un patrón

Tiene varias partes:1. Nombre: Es una palabra signi�cativa o una frase corta2. Problema: Describe los objetivos dentro de un contexto3. Contexto: Son las precondiciones que se han de dar para que el patrón sea aplicable.4. Fuerzas: Son las restricciones que han de cumplirse.5. Solución. Relaciones estáticas y reglas dinámicas que describen como realizar la función. Es una descripción que puede

tener diagramas y texto que muestra la estructura del patrón, sus participantes y sus colaboraciones. Esta solución nomuestra sólo la estructura estática, sino también el comportamiento dinámico. En la descripción se incluyen además lasposibles trampas que puedan existir y las variantes de la solución.

6. Resultado: Es el contexto que queda como consecuencia de la aplicación del patrón.7. Justi�cación: Es una explicación de porque se sigue cada uno de los pasos y del patrón como un todo.8. Patrones relacionados.9. Utilización: Aplicación del patrón en sistemas existentes

Patrones arquitectónicos

La arquitectura divide la aplicación en las partes que la componen. Este paso es el primero y supondrá la futura división deltrabajo en los diferentes grupos.

1. Sistemas genéricos

Layers: Estructura las aplicaciones que pueden ser divididas en grupos de subtareas en las que cada una de ellas tengaun nivel de abstracción. El ejemplo más representativo de este patrón es la arquitectura de siete niveles OSI (físico,enlace, red, transporte, sesión, presentación y aplicación.) donde se de�niría una clase para cada nivel.Tuberías y �ltros: Pensado para aplicaciones que manejan corrientes de datos. Cada paso del proceso se encapsulaen un �ltro. Los datos se pasan a través de tuberias entre �ltros adyacentes. Se de�niría una clase tubería, unaclase genérica �ltro y una clase por cada �ltro concreto por donde deban pasar los datos. Ejemplo: La estructura deun compilador (análisis léxico, sintáctico, semántico, generador de código intermedio, optimizador y generador decódigo �nal).Pizarra: Apropiado para sistemas expertos o no deterministas. Existe una estructura de datos llamada pizarra en laque varios procesos pueden escribir una solución parcial al problema. En este caso el sistema se descompone en lapizarra y en los diferentes subsistemas.

2. Sistemas distribuidos

Broker: Se tienen varios sistemas diferentes que interactuan entre ellos. El broker es el elemento que coordina lacomunicación y gestiona los errores.

3. Sistemas interactivos

Modelo-Vista-Controlador: Son aplicaciones que se dividen en tres componentes: El modelo que contiene el nucleode la funcionalidad y de los datos, la vista, que proporciona información al usuario y los controladores, que gestionanlas entradas del usuario. La interfaz está formada por la vista y los controladores. Cada vez que se modi�que lainterfaz o el modelo hay que revisar la otra parte.Presentación-Abstracción-Control: Es otro tipo de software interactivo pero pensado esta vez en el marco de losagentes. Cada agente es responsable de una parte de la funcionalidad y se divide en tres partes: presentación, abstrac-ción y control. Esta separación está diseñada para separar la interacción con el usuario del nucleo de funcionalidaddel agente y de las comunicaciones con otros agentes.

4. Sistemas adaptables

Microkernel: Adecuado para sistemas que van a ser sometidos a cambios en sus requisitos. Se tiene por una parte unnucleo de funcionalidad y por otro una funcionalidad extendida y partes especí�cas de cada cliente. El microkernelfunciona además como un punto de conexión al que se podrán añadir extensiones a las que gestionará. Se ha utilizadoen la construcción de sistemas operativos.Re�exión: Es el caso en el que el comportamiento del sistema tiene que cambiar de un modo dinámico. Se puedenmodi�car las estructuras de datos y los mecanismos de llamada a las funciones. La aplicación se divide en dos partes:Un metanivel que da información acerca de las propidades del sistema y que por lo tanto posee autoconocimiento yun nivel base donde reside la lógica de la aplicación. La implementación y los cambios se hacen en el metanivel.

Patrones de diseño

El problema del diseño es que es la etapa di�cil del ciclo de vida por estar menos sistematizada y su calidad depende sobretodo de la experiencia del personal. Un patrón de diseño puede aliviar esa di�cultad al tener guardada en si la experiencia de losdiseñadores que lo crearon, que pueden no formar parte del equipo actual.

46 Fase de diseño

Los patrones de diseño han sido clasi�cados. Una de las clasi�caciones el la del libro Patterns in java (volume 1), según lacual hay seis categorías (se exponen también los patrones de cada una). Durante el diseño se trata de identi�car situaciones enlas que son aplicables.

No es necesario estudiar en detalle la siguiente lista, sólo es una panorámica general.

1. Fundamentales: Son los más importantes y los más utilizados en la de�nición de otros patrones.

Delegation: Extiende las funcionalidades suministradas por una clase escribiendo otra que utiliza instancias de laoriginal.Interface: Una clase utiliza los servicios suministrados por instancias de otras clases a través de un interfaz.Immutable: Pensado para objetos referenciados por muchos otros o accedidos por varios procesos concurrentes demodo que no cambie su estado después de ser creados.Marker interface: Son para clases que utilizan interfaces que acceden a objetos sin hacer suposiciones acerca de lasemántica de tales objetos.Proxy: Utilizado para que un objeto A (cliente) haga llamadas a otro B (servidor) a través de un tercer objeto C queactua como representante de B.

2. De creación: Describen cómo crear objetos cuando hay que tomar alguna decisión.

Factory method: De�ne una interfaz para crear un objeto, pero la elección de la clase que se va a instanciar se decideen tiempo de ejecución. Los objetos de las subclases tienen una interfaz común.Abstract factory: Si tenemos un conjunto de clases abstractas de las cuales heredan clases concretas, este patrónpermite, al igual que el anterior crear ese tipo de objetosBuilder: Un objeto cliente crea otro objeto especi�cando tipo y contenido pero sin detalles acerca del objeto creado.Prototype: Un objeto crea objetos sin conocer su clase o detalles de los mismos dando objetos prototipo a un objetode creación que se encarga de ello haciendo copias de esos objetos prototipo.Singleton: Es el caso en el que se quiere garantizar que sólo se crea una instancia de una clase.Object pool: Gestiona un objeto para que pueda ser reutilizado cuando es cumputacionalmente costoso crear instan-cias de ese objeto.

3. De partición: Dan una guía sobre como dividir los casos de uso y actores en clases.

Layered initialization: Trata el problema que se plantea cuando se necesitan varias implementaciones de una clasecomún en la que además la lógica común se utiliza para decidir que clases especializadas hay que crear.Filter: Permite que un conjunto de objetos con la misma interfaz y que realizan distintas operaciones sobre datospuedan de un modo dinámico conectarse en el orden en el que se realizan las operaciones.Composite: Usado para construir objetos que se componen de otros objetos.

4. Estructurales: Son las formas de interacción entre objetos.

Adapter: Es como un puente entre dos clases con interfaces incompatibles que permite que puedan relacionarse.Iterator: Es una forma de de�nir interfaces para hacer un recorrido de un conjunto de datos.Bridge: Permite que una jerarquía de abstracciones y sus correspondientes implementaciones puedan cambiar porseparado.Facade: Es una forma de crear una interfaz uni�cada para manipular un conjunto de objetos.Flyweight: Trata el caso cómo crear una sola instancia en vez de muchas cuando contienen la misma información.Pensado para mejorar la e�ciencia.Dynamic linkage: Permite que un programa solicite cargar clases que implementan un interface conocido.Virtual proxy: Si un objeto es caro de instanciar, se pospone la instanciación hasta que realmente se necesite el objeto.El patrón oculta esta inexistencia dando a los clientes un objeto proxy que implementa el mismo interface. Esto seconoce como instanciación perezosa.Decorator: Extiende la funcionalidad de un objeto de un modo transparente a sus clientes utilizando una instancia dela clase original.Cache management: Se tiene una copia de los objetos que son costosos de construir para acelerar el acceso a losmismos.

5. De comportamiento: Organizan y gestionan los comportamientos.

Chain of responsability: Permite que un objeto pase un comando a un objeto que es parte de alguna estructura sinsaber que objeto lo va a ejecutar. Un objeto de la estructura puede ejecutar el comando o pasárselo a otro.Command: Permite que un objeto pueda realizar una operación parametrizada de modo que se puede controlar quéoperaciones se ejecutan, la secuencia, encolarlas, etc.Little languaje: Si la solución a varios problemas se puede expresar como las combinaciones de una serie de opera-ciones del tipo creación o búsquedas en estructuras de datos y asignación de valores este patrón de�ne un lenguajecon estas operaciones para resolver un conjunto de problemas.

3.2 Diseño estructurado 47

Mediator: Modela una clase cuya responsabilidad es controlar y coordinar las interacciones de un grupo de objetos.Encapsula el comportamiento colectivo en una clase mediadora.Snapshot: Es una vista de un objeto sin información temporar acerca de él. El objeto puede ser capturado o restaurado.Observer: Sirve para detectar dinámicamente los cambios en un objeto y comunicar esos cambios a los objetos quedependan de él para que se actualizen.State: Es útil cuando un objeto tiene que cambiar su comportamiento cuando cambia su estado. Cada estado quedaencapsulado como un objeto separado.Null object: Cuando no existe un objeto se denota con un puntero a null, el problema de esto es que supone añadirestructuras de control que comprueben si el objeto es null antes de hacer algo. La alternativa es de�nir un null object,que es un objeto que no hace nada.Strategy: Es una forma de seleccionar el algoritmo que se quiere emplear en una situación. La forma es tener unaclase antecesora y en cada subclase se de�ne un algoritmo distinto. La selección del algoritmo se realiza en funcióndel objeto y puede cambiar dinámicamente en el tiempo.Template method: Si se tiene un algoritmo que tiene una secuencia �ja de pasos y uno o más de los pasos son variableseste patrón lo que hace es poner cada paso variable en una función abstracta, después extiende la clase con una clasederivada que implementa la variación que se necesita.Visitor: Una forma de realizar una operación es implementar la lógica de esa operación en los objetos involucrados.El patrón visitor es una alternativa a esta opción que implementa esa lógica en una clase separada visitor. Las ventajasson que no se complican las clases de los objetos involucrados y que se pueden usar varias clases visitor distintas.

6. De concurrencia. En la concurrencia existen dos tipos de problemas:

Acceso a recursos compartidos. El problema que se debe resolver aquí son los interbloqueos.Secuenciación de operaciones. El problema es garantizar que se ejecutan una serie de pasos en orden.

Los patrones de�nidos para este apartado son:

Single threaded execution: Evita que se hagan llamadas concurrentes que accedan a recursos compartidos al mismo tiempo.Guarded suspension: Impide que se llame a un método hasta que se cumpla una precondición.Balking: Hace que se retorne de un método sin hacer nada en el caso de que el objeto no esté preparado para procesar lallamada.Scheduler: De�ne una política sobre cuando se permite que un thread use un recurso compartido.Read/Write lock: Soluciona el problema de lectores y escritores sobre un área protegida. Se puede leer concurrentementepero se necesita acceso exclusivo para escribir.Producer-Consumer: Gestiona la forma en la que se comunican de forma asíncrona un productor y un consumidor.Two-phase termination: Es un modo de terminar la ejecución de un hilo. Lo hace comprobando una variable en una seriede puntos.

3.2. Diseño estructuradoPara realizar el diseño de una solución a un problema concreto se pueden utilizar diferentes enfoques, según se basen en los

datos en la funcionalidad o en la interacción. En este tema se describen los dos métodos más utilizados: estructurado y orientadoa objetos. El diseño estructurado con estilo procedimental (o funcional) descendente, en el cual se van re�nando y dividiendo losmódulos funcionales de la solución, se basa en la utilización de los elementos: secuencia, condición y repetición.

El contenido de este apartado se estudia en [Pre05, caps. 10 y 11] o en la quinta edición [Pre01, caps. 14 y 16].

3.3. Diseño orientado a objetosEl otro tipo de métodos de diseño es el diseño orientado a objetos, que se basa en dividir jerárquicamente los elementos del

diseño (objetos) y encapsular conjuntamente los datos con sus funciones de acceso, de forma que la interacción se realiza porpaso de mensajes entre los objetos.

Es el paradigma1 que se empezó a seguir a partir de la década de los 80. A continuación veremos los conceptos más impor-tantes.

El concepto central en orientación a objetos es la clase. Una clase2 es una forma de llamar por el mismo nombre un conjunto decosas que comparten características comunes. Por ejemplo podríamos pensar en una clase llamada NumeroComplejo. Un númerocomplejo está formado por dos números reales (uno es la parte real y otro la imaginaria) y esos dos números son los atributosque describen el objeto. Un objeto es un individuo concreto que pertenece a la clase NumeroComplejo, por ejemplo (3, 4i).

1El concepto de objeto surgió a mediados de los 60 gracias a dos noruegos: Dahl y Nygaard, que desarrollaron el primer lenguaje orientado a objetos: Simula67

2La palabra �clase� viene de clasi�cador

48 Fase de diseño

Figura 3.1: Representación en UML de una clase. Tiene Nombre de la clase, Atributos y Métodos

Otra cuestión es que posiblemente queramos tener rutinas manipular esos números: suma, escribir por pantalla, etc. Cada unade esas rutinas las llamamos métodos.

De�nición de clase

Primera de�nición (de andar por casa): Una clase es un conjunto de atributos (≡ datos) y de métodos (∼= funciones ∼=procedimientos ∼= rutinas) con los que se manipulan dichos datos ≡ Estructura de datos.

Las clases suelen representar cosas que existen en el mundo real. Por ejemplo: La clase Estudiante la podemos de�nir conlos atributos: Nombre, Apellido1, Apellido2, NIF, etc. Podría tener los métodos: irAula( ) (Mueve al estudiante del punto A alpunto B dada una ruta), hallarRuta( ) (este método averigua la ruta mencionada antes y es usado por el método anterior), etc.

Los métodos públicos son aquellos que pueden ser invocados por otros objetos. El conjunto de métodos públicos es loque se conoce como la Interfaz del objeto. En este ejemplo, irAula() sería un método público, el método hallarRuta() sería unmétodo privado que solo los objetos de la clase Estudiante serían capaces de invocar cuando necesitasen ir de un punto a otro ypor tanto no formaría parte de su interfaz.

Segunda de�nición (un poco mejor): Una clase es algo que tiene responsabilidades. Pueden ser de dos tipos: De compor-tamiento, que se implementan con métodos y de estado, que se implementan con datos.

Responsabilidades{

Comportamiento (Métodos)Estado (Datos)

Una responsabilidad es como un contrato entre dos partes, es algo que la clase se compromete a hacer a cambio de algo.En el ejemplo anterior la clase Estudiante tiene la responsabilidad de saber llegar al aula x. En general, cuando una clase A invocaun método de una clase B, A es responsable de que los parámetros que se pasen a B sean consistentes3 (precondición) y B esresponsable de que se devuelvan resultados correctos (postcondición).

Ejemplo: La clase A invoca un método de B. La clase B tiene el método escribirTipoTriangulo(lado1, lado2, lado3),que puede ser Equilátero (3 lados iguales), Isósoceles (2 lados iguales) o Escaleno (todos los lados distintos). La clase A esresponsable de que los lados sean números positivos y que la suma de las longitudes de dos cualesquiera de los lados sea mayorque la longitud del otro lado (en otro caso no sería un triángulo válido). La clase B es responsable de clasi�car correctamente eltriángulo y no se preocupa de que los datos de entrada sean válidos.

Encapsulamiento: Una clase debe ocultar los detalles de cómo está implementada y en general toda aquella información queno sea imprescincible para manipularla. En el ejemplo del estudiante el método hallarRuta() no es conocido por las otras clases.El encapsulamiento reduce la complejidad.

Ejemplo: Un Abonado es una persona que usa un Teléfono. Existen dos tipos de teléfonos: Móvil y Fijo. Un teléfono sea deltipo que sea se compone de un Teclado, un Altavoz y un Micrófono.

Figura 3.2: Ejemplo de clases y relaciones entre ellas

3La de�nición de consistencia dependerá del dominio de aplicación

3.4 Validación y con�rmación del diseño 49

Asociación: Es una relación que existe entre dos clases. En el ejemplo anterior la clase Abonado está relacionada con la claseTeléfono. Una asociación se suele implementar en el código con un puntero dentro de un objeto de una clase a la otra. Unacomposición es un tipo de asociación entre clases del tipo es parte de. Un teclado, un altavoz y un micrófono son parte de un (ysolo un) teléfono.

Herencia: Es una relación entre clases cuando una es un tipo de la otra. En el ejemplo, las clases Movil y Fijo son tipos deteléfonos. Se dice que la clase Teléfono es padre de Movil y Fijo. La herencia permite encapsular en una clase antecesora losaspectos comunes de las clases hijas.

Se dice que una clase es abstracta cuando no se pueden crear instancias de objetos partiendo de ella. En el ejemplo todos losteléfonos son o �jos o móviles, así que no sería posible crear un objeto de la clase Teléfono porque hay que concretar de qué tiposería. La �nalidad de Teléfono es especi�car la parte compartida de la interfaz.

Una colaboración es una solicitud hecha por un objeto a otro. Para identi�carlas, se debe examinar cada par clase-responsabilidadcon el �n de determinar si es necesario que la clase interactúe con otra/s para llevar a cabo esa responsabilidad. En el ejemploanterior un abonado debe usar una instancia de la clase teléfono para poder hablar con otro abonado.

Polimor�smo: Es la capacidad de un objeto de responder de formas distintas al mismo mensaje. Ejemplo: Un teléfono móvilpara establecer una llamada tiene que hallar y reservar una banda de frecuencias libre para comunicarse con la torre de telefoníamás cercana mientras que un teléfono �jo se limita a mandar un mensaje a la centralita. La operación ( marcar() ) es la misma,pero cada hijo de la clase Teléfono implementa esa misma interfaz del modo adecuado a sus características.

3.4. Validación y con�rmación del diseñoPara cerrar un paso en la fase de diseño es necesario hacer la validación de los resultados obtenidos y comprobar si cumplen

con las especi�caciones de requisitos que eran la entrada a esta fase. Se trata de un conjunto de actividades para garantizar que seesta construyendo el producto correcto de la manera adecuada. Cada una de las actividades del diseño deben estar re�ejadas enlos planes del mismo, estos planes se actualizaran cuando sea necesario para adaptarse a los cambios que vayan surgiendo perocada cambio deberá ser revisado y aprobado.

Debe existir un procedimiento de control de diseño que especi�que cómo se plani�ca y desarrolla. Por otra parte, la informa-ción de entrada al diseño, que es la resultante de la fase anterior debe incluir además de los requisitos del usuario cosas tales comorequisitos legales y regulaciones que se apliquen al proyecto. Las entradas al diseño deben tener en cuenta cualquier modi�cacióndel contrato. Los resultados del diseño deben ser documentados de forma que se pueda hacer una veri�cación y validación de losmismos.

3.4.1. Revisión del diseñoDurante el proceso de diseño se deben plani�car algunas revisiones formales del trabajo que se va realizando. Los partici-

pantes son todas aquellas personas involucradas en el diseño que se esté revisando, así como representantes del cliente. Cuando�nalice la revisión se debe redactar un documento con el resultado de la revisión y las partes afectadas. La forma de revisar eldiseño estará documentada en el procedimiento de control del diseño.

3.4.2. Veri�cación del diseñoLas actividades que se realizan son:

Realización de cálculos alternativos.Comparación con diseños preliminares si es aplicable.Pruebas y demostracionesRevisión del diseño.

3.4.3. Validación del diseñoGarantiza que el producto cumple con los requisitos de�nidos por el cliente. Se realiza después de la veri�cación si esta fue

satisfactoria. Una validación se realiza en un entorno operativo normal. También esto se realizará conforme al procedimiento decontrol del diseño.

3.5. Documentación: especi�cación del diseñoEvidentemente uno de los puntos más importantes en la documentación es la especi�cación del diseño. Dado que el diseño

tiene una gran componente de invención, es necesario dejar muy claramente documentadas las decisiones y elementos utilizadosen el diseño. Además el diseño será el elemento clave para la fase siguiente de implementación que debe seguir �elmente losdictados del diseño.

50 Fase de diseño

Para dejar constancia de los diseños se deben utilizar lenguajes lo más formales posible, como tablas, diagramas y pseu-docódigo, que en algunos casos pueden permitir incluso la utilización de herramientas para automatizar parcialmente el procesode construcción del código en la siguiente fase de implementación.

El contenido de este apartado está incluido en [Pre05, caps. 9 y 11] o en la quinta edición [Pre01, sec. 13.8].


El diseño es la fase que sigue a la especi�cación y el análisis. Consiste en añadir a la representación anterior los detallenecesarios para pasar a la implementación. Al igual que en el capítulo anterior, existen 2 tipos de diseño: orientado a objetos yestructurado. También existen diferentes formas de realizarlo en función de características del sistema (tiempo real, distribuido,etc.)

Diseño arquitectónico: Independientemente del tipo de diseño (estructurado u orientado a objetos) existe una primera fase queconsiste en la división del sistema en subsistemas. Los apartados a tener en cuenta son:

1. Descomposición estructural: Descomposición en subsistemas2. Intercambio de información entre subsistemas: Hay dos opciones: con una base de datos central o por medio de

mensajes.3. Forma de realizar el control: Centralizado o basado en eventos.

Sistemas distribuidos: Son un tipo especial de sistema que merece un tratamiento aparte debido a que parece ser la tendenciaactual. Hay varios tipos de arquitecturas:

1. Arquitectura cliente-servidor: Puede ser de dos o de tres capas.2. CORBA: Es un sistema de objetos distribuidos. Utiliza IDL como lenguaje de de�nición de interfaces. {ATEN-

CIÓN: CORBA No se trata en este curso, ver en [Pre01, cap. 28]}

Diseño estructurado

Es el análisis clásico. Esta basado en el �ujo de los datos a través del sistema. En una primera fase se hace un diseñopreliminar y posteriormente un diseño detallado. Objetivos: Comprensión, mantenibilidad, facilidad de pruebas e integracióncon otras aplicaciones. Principios: Abstracción, modularización, independencia, arquitectura, ocultamiento de la información yre�namiento paso a paso. Sus elementos importantes son:

1. Módulo: El árbol de módulos de�ne las relaciones entre los mismos.2. Tabla de interfaz: Especi�ca como son las comunicaciones inter-módulos.3. Cohesión: Un módulo es cohesivo si sus tareas se realizan con independencia del sistema pero relacionadas entre sí.4. Acoplamiento: Media de la complejidad de las interfaces de un módulo.5. Diagrama de estructuras: Es un método de descomposición funcional donde el bloque básico es el módulo. Es un árbol

o diagrama jerárquico. Se de�nen en él: bucles, alternativas y subrutinas.6. Heurísticas de diseño: Consejos a aplicar.7. Tipos de �ujos de información: Flujos de transformación y de transacción.

Diseño detallado: Es una especi�cación con mayor nivel de detalle de las estructuras de datos y algoritmos.

Otras notaciones que forman parte de metodologías pensadas en torno al diseño estructurado son:

1. Diagramas HIPO: Muestran entradas, salidas y funciones. Muestran lo que hace el sistema pero no el cómo. {ATEN-CIÓN: los diagramas HIPO No se tratan en este curso}

2. Diagramas de Warnier-Orr: Son una representación jerárquica de los programas, sistemas y estructuras de datos. Puederepresentar iteraciones, secuencias y alternativas.

3. Diagramas de Jackson: Produce un programa a partir de su especi�cación. Las entradas y salidas son secuenciales aligual que el proceso.

Diseño orientado a objetos

Como se ha dicho antes, es la otra forma de hacer el diseño. Se incluye también en este resumen el diseño arquitectónico porser parte integrante de la metodología, aunque lo dicho en el apartado anterior dedicado al tema es igualmente válido. Hay dospartes:

1. Diseño del sistema = (Diseño arquitectónico)2. Diseño de objetos = (Diseño detallado)

3.5 Documentación: especi�cación del diseño 51

Patrones: Consisten en la identi�cación de problemas usuales en el análisis, diseño, codi�cación, etc e incluir una plantilla desolución.

Frameworks: Son otro mecanismo de reutilización pero un framework se puede componer de varios patrones. Generan aplica-ciones para un dominio.

Validación y con�rmación del diseño

Son un conjunto de actividades que garantizan que el producto se está construyendo de la forma adecuada. Se compone de larevisión, la veri�cación y la validación del diseño.

Documentación

Se incluye una plantilla para redactar el documento correspondiente al igual que en la fase anterior.

Ejercicios y actividades propuestas1. ¿Cuáles son las principales diferencias entre el diseño estructurado y el orientado a objetos?2. ¿Por qué el diseño arquitectónico es el primer paso?3. ¿Cuáles son los tipos de modelos cliente-servidor de tres capas?4. {Este ejercicio no se tratará en este curso} ¿Qué es necesario para que un objeto pueda invocar los servicios de otro en

CORBA?5. {Este ejercicio no se tratará en este curso} ¿Cuál es la secuencia de pasos que ocurre cuando un cliente utiliza los servicios

de un servidor en CORBA? ¿Podría el servidor ser cliente de su cliente?6. ¿Qué nivel de acoplamiento hay entre dos módulos A y B donde A utiliza una función de B pero ambos manipulan el

mismo conjunto de variables globales?

Extensión de conocimientosLos contenidos de este tema también pueden estudiarse en [Som98, cap. 4], [Haw98, caps. 11 al 14] ó [Sch92, caps. 5 al 8].Se puede profundizar en el diseño orientado a objetos, por ejemplo, en los libros [RBP+96, Mey98, Boo94, Jac92, WBWW90].En http://www.nist.gov/dads/ se puede encontrar una recopilación en forma de diccionario (en inglés) de descripciones

y enlaces sobre algoritmos, estructuras de datos y problemas.Se puede encontrar información sobre CORBA (Arquitectura común de distribución de objetos) en [Pre01, sec. 28.9.5] y

también un tutorial en la página web http://java.sun.com/developer/onlineTraining/corba/corba.html, aparte, porsupuesto, de la página propia de CORBA http://www.corba.org/.

52 Fase de diseño

Capítulo 4

Fase de implementación

Tutorial PrevioIntroducción

Una vez que se dispone de un diseño para la solución del problema, incluso en una fase temprana o provisional del diseño,ya se puede comenzar a plasmar ese diseño en el código que permita realizarlo o implementarlo. En esta fase el programadorrecibe las especi�caciones del diseño y transforma esas especi�caciones, que pueden estar en formatos mezclados formales,semiformales o manuales, en un programa o módulo que las efectúe. Esta tarea de modi�cación puede estar semi-automatizadaen algunos casos o realizarse de forma completamente manual. En cualquier caso se requiere que esa transformación se hagade manera sistemática y coherente. Las particularidades propias de lenguajes de programación concretos se estudian en otrasasignaturas y por tanto no se incluirán en este tema. Lo que sí se estudiarán son las técnicas o estilos de codi�cación formal.

Durante la implementación se escribe el código de la aplicación. Existen una serie de "vicios" en el estilo de codi�caciónque pueden tener como consecuencia que el código sea confuso para terceras personas o para uno mismo pasado un tiempo y enconsecuencia difícil de mantener; además, algunas prácticas pueden inducir errores. Es especialmente recomendable para estaparte seguir las recomendaciones del PSP (Personal Software Process). Para realizar el trabajo este debe ser dividido en pequeñosmódulos que se reparte entre individuos o pequeños grupos atendiendo a un grá�co de dependencias entre tareas y con la ideaen mente de paralelizar tanto trabajo como sea posible. A medida que se van haciendo los módulos hay que comprobar quecumplen con una cierta calidad, para ello existen varios tipos de pruebas. En este capitulo se estudia la necesidad de comprobarla ejecución correcta del módulo, por tanto interesan las pruebas que se hacen a nivel de módulo, también llamadas pruebasunitarias. Además de todo ello hay dos tipos de manuales importantes que hay que producir en esta etapa: el manual de usuarioy el manual técnico.

Relación con otros temasEn este capítulo el alumno debe recordar los conocimientos sobre programación que ha ido adquiriendo a lo largo del estudio

de otras asignaturas en la carrera para entender y generalizar la idea de los estilos de codi�cación y la depuración. Para compren-der la problemática asociada a la programación es necesario conocer muy bien al menos un lenguaje de programación y teneralguna experiencia con él. Se puede considerar que con las prácticas de programación de cursos pasados es su�ciente.

Objetivos del temaLos objetivos de este tema son resaltar la importancia de que la codi�cación de los programas se haga de una forma ordenada,

sistemática y documentada, así como de la necesidad de realizar pruebas y depuración de errores propios de la implementación.Se busca aprender algunas recomendaciones para producir código de calidad, poder entregar el código en tiempo mínimo, poderdividir el trabajo resultante del diseño entre un grupo de personas y tener una plantilla para redactar documentación para losmanuales de usuario y técnico.

Guía de estudio y esquemaDespués del estudio del contenido teórico del tema, se deben realizar pruebas de codi�cación con distintos estilos basándose

en los mismos ejemplos mostrados, utilizando el lenguaje de programación que mejor conozca o pre�era el alumno. En paralelocon el estudio del tema podría ser de interés que se desarrollara un pequeño proyecto de programación donde se pusieran enpráctica los conceptos desarrollados en el capítulo.

Para conseguir los objetivos es necesario no sólo memorizar el contenido del capítulo, sino desarrollar hábitos que permitanutilizarlo en la práctica de la programación, lo cual es una tarea que requiere constancia. La redacción de una documentaciónde calidad no es trivial, son necesarias aptitudes pedagógicas, de estilo de escritura, etc. De todas formas, aunque puede resultardifícil las primeras veces, se puede considerar una tarea �burocrática�, es decir, al �nal lo que hay que hacer es seguir un manualde redacción de manuales.

Guías de estilo de codi�cación. Este apartado se estudia directamente en esta guía.53

54 Fase de implementación

Técnicas de depuración. El contenido de este apartado se encuentra en [Pre05, sec. 13.7] o en la quinta edición [Pre01, sec.18.7].Documentación del código. El contenido se encuentra en esta guía.

4.1. Guías de estilo de codi�caciónDentro de los proyectos en los que trabajan varias personas debe haber una coherencia entre los programas escritos por

diferentes programadores para facilitar la interacción y la modi�cación de los mismos. Por tanto desde el principio del proyectodebe estar claro el conjunto de normas y estilos que se utilizarán en la programación: indentado (sangrado), nombres de variables,elección de estructuras, contenido de comentarios, distribución de los fuentes, etc. Existen herramientas propias de la codi�caciónque incorporan automáticamente la reescritura del código según determinadas normas estándar.

La mayor parte del tiempo un programador lo pasa manteniendo código. Si ese código lo ha escrito él mismo puede tenerserios problemas para ello, si lo han escrito terceras personas casi seguro que será más práctico rehacer todo ese código porquetardará menos. El problema es que todos los que hemos escrito alguna vez un programa hemos adquirido una serie de �maloshábitos�. En este capítulo se verán una serie de normas de escritura de código fuente que dan un formato más homogéneo y portanto más fácilmente mantenible.

Hay muchas propuestas sobre normas de estilo para diversos lenguajes, sobre todo para C y C++. Las empresas tienen suspropias normas, que suelen ser variantes de estándares publicados, por ejemplo, en este capítulo se verá un resumen de lasnormas de Ellemtel Telecommunications Systems Laboratories para C++. También veremos una recomendaciones de estilo deprogramación en C y las normas de�nidas por SUN acerca de Java.

Estas normas tampoco son las ordenanzas a seguir por todo aquel que quiera hacer un programa en alguno de estos lenguajes,pueden infringirse si se considera necesario pero explicando la razón. Por eso de�nimos esta primera regla: �Cada vez que serompa una norma se deberá documentar el motivo�.

4.1.1. Traducción del diseño a la implementaciónUna vez terminado el diseño, la traducción de éste a un lenguaje orientado a objetos no debe suponer mayores problemas

porque las estructuras de estos lenguajes soportan los conceptos del diseño. La traducción del diseño a la implementación se llamaingeniería directa y puede ser parcialmente automatizada. La ingeniería inversa es el paso contrario, pasar de la implementaciónal diseño y también puede ser automatizada. Lo expuesto en este apartado está bastante aceptado en general y se puede encontrartambién en otros sitios (p. ej. [RBP+96, JBR00a]).

Casos de uso

Los casos de uso son una descripción del funcionamiento de un sistema. No se les puede aplicar la ingeniería directa oinversa para generar código o para obtener casos de uso a partir del código como al resto de diagramas en UML, pero veremosun conjunto de instrucciones para averiguar cuáles son los casos de uso de un sistema a partir de su comportamiento (ingenieríainversa).

Se identi�can los actores que interactúan con el sistema.Se investiga la forma en la que el actor interactúa con el sistema. Puede cambiar su estado o el de su entorno o responde aun evento.Se traza el �ujo de eventos de un sistema relativos a cada actor. Primero se consideran los �ujos principales y luego losalternativos.Identi�car casos de uso que se puedan fusionar y los que tengan relaciones de uso o de extensión entre ellos.Se representan los actores y casos de uso identi�cados en un diagrama.

De�niciones de clases

Es el primer paso para implementar el diseño. En general, para convertir un diagrama de clases en su equivalente en unlenguaje, lo primero es identi�car las reglas de correspondencia al lenguaje de programación. Puede ocurrir que no exista unaforma de hacer la correspondencia, por ejemplo, en Java no existe la herencia múltiple, con lo que, o bien se prohibe a losdiseñadores usarla, o bien se busca algún subterfugio para poder implementar esa característica, lo que añadirá complejidad. Losatributos y operaciones que se han de�nido en el diseño se tienen que de�nir dentro de la clase correspondiente como públicos,privados o protegidos, aunque este aspecto es probable que se haya de�nido en el diseño. Hay que de�nir también su tipo.

De�nición de clases en C++ Una ejemplo de clase en C++:

class Punto{

private:// Aquí se definen las variables y métodos privados.// Ninguna otra clase puede acceder a ellos.

4.1 Guías de estilo de codi�cación 55

int x; // Variables privadasint y;protected:

// Variables y métodos protegidos. Solo la propia clase// y las que hereden de ella pueden acceder a ellos.

public:// Variables y métodos públicos. Accesibles por todos.

Punto() { ... } // constructorPunto(int x,int y) // otro constructor~Punto() { ... } // destructor

}

No puede haber atributos o métodos con el mismo nombre. Los atributos y métodos de un tipo (privado, protegido o público)se declaran juntos en su bloque correspondiente. Existe un método público sin valor de retorno llamado constructor que tiene elmismo nombre de la clase y debe ser de�nido obligatoriamente.

De�nición de clases en Java Una clase en Java:

class Punto{

private int x; // Variables privadasprivate int y;public Punto(int x,int y);// Constructorpublic Punto(); // Otro constructor

}

Creación y destrucción de objetos

Un objeto es una instancia de una clase y cuando se crea una se reserva espacio de memoria. Cuando el objeto deja de existir,o bien se programa explícitamente la secuencia de acciones que hay que realizar, lo cual es una actividad propensa a errores, obien existe un mecanismo automático que va eliminando los objetos que no están referenciados por ningún otro.

Creación y destrucción de objetos en C++ Los constructores son los métodos que inicializan un objeto una vez que se hareservado memoria para él. Puede haber varios que reciben diferente número y tipo de parámetros. La asignación de memoria sepuede hacer de tres formas: Preasignados en memoria global �ja (static), en la pila (automatic) y en el cúmulo o heap (dynamic).Ejemplo:

Punto *p=new Punto(100,30); // Memoria dinámicaPunto p(100,30); // Memoria de pilastatic int j; // Memoria global fija

Puede existir un método antagónico al constructor llamado destructor, también con el mismo nombre que el constructor peroprecedido de �~� y que es invocado de forma automática antes de liberar la memoria que ocupa el objeto.

Creación y destrucción de objetos en java Hay pocas diferencias respecto a C++; los constructores siguen las mismas reglasy para destruir un objeto se invoca un recolector de basura cuando no queda memoria para liberar la de los objetos que ya noestán referenciados por ningún otro objeto. También se puede implementar un destructor utilizando la palabra finalize, quese invoca justo antes de ser destruido por el recolector de basura (garbage collector). Ejemplos:

Un objeto se crea del siguiente modo:

Punto p = new Punto(100,30);

Un destructor en Java:

protected void finalize() {System.out.println(�Este objeto será procesado por el garbage collector�);

};

Invocación de métodos

Para llamar a un método se indica al menos el nombre del objeto y el del método, que puede tener parámetros o no.


Invocación de métodos en C++ Ejemplo: Tenemos el método DesplazarHorizontalmente de la clase Punto.

Punto *p1, p2;...// Invocación de los métodosp1->DesplazarHorizontalmente(10);p2.DesplazarHorizontalmente(25);

Existe un puntero this que hace referencia al propio objeto. Si se recibe un parámetro con el mismo nombre que una variablede�nida en el objeto, se puede acceder a la variable del objeto utilizando ese puntero this:

void Punto::DesplazarHorizontalmente(int x) {this->x = this->x + x;

}

Invocación de métodos en Java La notación en java es igual pero sin la versión con punteros.

p.DesplazarHorizontalmente(10);

Uso de la herencia

La herencia es estática si se determina en el momento de la compilación, como ocurre en la mayoría de los lenguajes, esimplícita si el comportamiento de un objeto depende de su clase y no se puede cambiar y es por grupos si las características deherencia se especi�can para una clase, no para objetos concretos.

Herencia en C++ Una clase puede heredar de varias clases que se especi�can en la declaración. La subclase se llama derivada.La forma de heredar puede ser privada, protegida o pública. El resultado de esto es que los métodos y variables de la claseantecesora se heredan con el tipo de acceso de menor grado, por ejemplo, una variable pública que pertenece a una clase que sehereda de modo protected se convierte en protected. Ejemplo de la sintaxis:

class Punto: public ObjetoGrafico { ... }

Herencia en Java Está mucho más limitada. Sólo existe herencia simple, aunque una clase puede implementar múltiplesinterfaces y las interfaces pueden heredar de múltiples interfaces. Ejemplo:

class Punto extends ObjetoGrafico { ... }

Implementación de asociaciones

Existen dos formas: punteros y objetos de asociación. Lo normal es que el lenguaje no tenga de�nida esta última opción.Ejemplo: Supongamos que tenemos de�nido un objeto Recta, que se forma a partir de dos objetos Punto que de�ne el usuariopinchando en la pantalla, y queremos asociar los dos puntos a la recta. El objeto recibe los dos puntos en su constructor (ver�gura 4.1).

PuntoRecta1 2

Consta de

Figura 4.1: Asociación entre recta y punto

Implementación en C++ En la implementación del constructor se copian a los dos punteros de la clase las direcciones de losobjetos Punto recibidos:

class Recta {private:

Punto *p1,*p2;public:

Recta(Punto *p1,Punto *p2) {this->p1=p1; this->p2=p2; };...}


Implementación en java El puntero está en el lado de la asociación que necesita acceder a la otra clase, es decir, si esnavegable en ambos sentidos estará en ambas clases:

class Recta {Punto p1,p2;Recta(Punto p1,Punto p2) this->p1=p1; this->p2=p2; }

...}

El problema ahora es: ¿Qué se hace si se tiene una relación con una cardinalidad indeterminada, o lo que es lo mismo, puedehaber muchos objetos en el otro lado relacionados con una clase dada?.

La respuesta es que si la cardinalidad es alta pero está acotada se puede implementar con un array de punteros. Si no estáacotada se puede tener un conjunto de punteros en una clase contenedora que puede crecer de forma arbitraria.

4.1.2. Estilo de programación orientado a objetosVeremos las directrices generales a seguir para que el código sea reutilizable, extensible, robusto y utilizable en grandes

sistemas [RBP+96, cap. 14].

Reusabilidad

La ventaja de la reutilización es que la cantidad de código se reduce por lo que la comprensión del mismo también es mássencilla. Es más sencillo reutilizar código en lenguajes orientados a objetos debido a que los módulos son más cohesivos y menosacoplados. El inconveniente es que escribir código reutilizable es más difícil y siempre va a requerir un esfuerzo adicional.Existen dos tipos de reutilización:

Dentro de un mismo proyecto pueden existir partes redundantes, se trata de descubrirlas y compartirlas por los módulosque las usen.Reutilizar código de un proyecto antiguo en proyectos nuevos. Es más complicado que el punto anterior, requiere que elcódigo haya sido escrito siguiendo una pautas que ahora veremos.

Reglas generales de estilo para escribir código reutilizable:

Construir métodos cohesivos. Un método es cohesivo si realiza una única función o varias íntimamente relacionadas. Encaso contrario hay que dividirlo.Métodos pequeños. Un método es grande si sobrepasa una o dos páginas, en cuyo caso habrá que dividirlo, con lo queademás de hacerlo más sencillo puede que uno de los trozos sea reutilizable.Mantener la congruencia de los métodos. Un método se dice que es congruente si tiene un nombre similar a métodossimilares, condiciones, orden de argumentos, valor proporcionado y condiciones de error.Separar la política de la implementación. Los métodos de política son los de alto nivel y toman decisiones de control.Son dependientes de la aplicación, se entienden y se escriben fácilmente. Son los módulos que deben comprobar el estadoy los errores. Los métodos de implementación son los que hacen el �trabajo sucio�, es decir, son los que tienen de�nidoslos algoritmos, pero no son los que toman la decisión de ejecutar o no esos algoritmos. Si encuentran un error durante laejecución deben dar un informe a los módulos superiores, pero no deben tomar acciones por su cuenta, como son métodosautocontenidos son fácilmente reutilizables.Proporcionar una cobertura uniforme. Consiste en redactar métodos que sean capaces de tratar todas las combinacionesde las posibles entradas que se puedan dar, y no sólo las actuales.Generalizar los métodos. Es similar al punto anterior pero en referencia al modo de funcionamiento y al contexto. Cuandolos valores estén vacíos o sean extremos o estén un poco más allá del límite.Evitar el acoplamiento. Por ejemplo, el que se da cuando se accede a objetos globales y hay que tener conocimiento delos mismos para poder utilizarlos.Evitar los modos. Una operación con modos tiene una forma de funcionamiento según el modo en el que esté. Lo acon-sejable es tener un método distinto para cada modo.

Herencia

Otra forma de reutilizar es escribir código de forma que se pueda heredar. Las reglas de estilo en este sentido son:

Métodos comunes: Se pone el código común en un método al que invocan los diferentes métodos. Si ese código comúnestá en varias clases se pone en un método de una clase antecesora.Factorización. Cuando tenemos dos métodos muy parecidos de clases diferentes se puede utilizar otra aproximación: Elcódigo común se pone en un método distinto de una clase antecesora, y es ese método el que, en función de la clase en laque estemos llama a un método u otro. Es corriente utilizar la factorización con clases abstractas. En el siguiente ejemplode C++, los métodos A y C son comunes, pero el B es propio de cada clase:


class Comun {public:A() { ... }C() { ... }virtual B() { ... }MetodoComun() {

A();B();C();

}}class X:public Comun {

B() { ... }}class Y:public Comun {

B() { ... }}

Delegación. Si se tiene que ejecutar un método en una clase A que ya está implementado en la clase B, heredar de B sólopara poder utilizar su método es un error, en vez de eso se delega enviando la operación a B desde A.Código externo encapsulado. Si se utiliza código de otra aplicación con una interfaz diferente, en vez de hacer llamadasdirectas a ese código es mejor hacer un método o una clase que se encargue de ello. De esta forma, si hay que hacermodi�caciones, estas estarán más localizadas.

Extensibilidad

Consiste en añadir nuevas funcionalidades al código. Veamos un conjunto de normas a seguir para facilitarla.

Encapsular las clases. Esto signi�ca que sólo una clase puede acceder a sus propios datos e implementación.Ocultar las estructuras de datos. El motivo es que las estructuras de datos son propias de los algoritmos. Si se hacenpúblicas será más difícil cambiar el algoritmo más adelante.Ley de Demeter : Evitar recorrer múltiples enlaces o métodos. Si a través de las asociaciones un método llega a una clasevecina, no deben utilizar los enlaces de ésta para acceder a una tercera clase, más bien debería utilizar un método de suclase vecina para esta operación, de esta forma no es necesario que el método tenga conocimiento de todas las asociacionesdel modelo, sólo de las clases relacionadas con la propia.Evitar sentencias �case� basadas en el tipo de objeto. En su lugar se pueden utilizar métodos. Solo se deben usar esassentencias si van a tener en cuenta los atributos de cada objeto.Distinguir los métodos públicos de los privados. Se debe minimizar el número de métodos públicos para disminuir lacomplejidad de la interfaz y porque si se modi�can esto afectará a las clases que los utilicen, por eso deben ser diseña-dos con más cuidado. Los métodos privados añaden modularidad, dependen de la implementación de la clase y puedenmodi�carse sin que cause efectos secundarios fuera de la clase.

Robustez

Un método es robusto si no falla incluso ante parámetros incorrectos. Directrices para construir programas robustos:

Protección contra errores. Debe tenerse en cuenta que el usuario puede producir entradas incorrectas. El sistema deberíadar un mensaje de error y no �colgarse�. El sistema operativo, el hardware u otra librería pueden contener errores también,para lo cual se deben instalar comprobaciones internas. Las comprobaciones de errores aumentan el tamaño y la lentituddel código. Las relativas al usuario deberían estar siempre, las demás pueden eliminarse en la versión �nal que se entregue.Optimizar después de que funcione el programa.Evitar los límites prede�nidos. Es decir, utilizar memoria dinámica en vez de estructuras de datos de tamaño �jo. Esto damás �exibilidad (y algún que otro error).Disponer el programa para la depuración y la monitorización del rendimiento. En función de las facilidades sumin-istradas por la herramienta de programación, tendremos que añadir sentencias de depuración, que se ejecutan en funciónde una variable que indique el nivel de depuración. También es posible añadir código que recoja estadísticas sobre porejemplo el número de invocaciones a una función.

Grandes sistemas

No es lo mismo trabajar solo que en un grupo, hay que pensar en que son otras personas las que van a utilizar, depurar,modi�car o mantener el código. Las directrices que se indican son aplicables también para un proyecto unipersonal.

No empezar a programar de forma prematura. Es decir, antes de empezar el proceso de implementación hay otras cosascomo la especi�cación o el diseño.Crear métodos comprensibles. Un método es comprensible si terceras personas pueden entender lo que hace.


Hacer que los métodos sean legibles. Esto signi�ca:

• Que los nombres de las variables sean signi�cativos (mejor no utilizar abreviaturas).• Evitar un nivel de anidamiento excesivo.• No utilizar una misma variable temporal para diferentes propósitos en lugares diferentes.• Comprobar la ortografía de los nombres.

Utilizar los mismos nombres que en el modelo de objetosSeleccionar cuidadosamente los nombres. Deben ser descriptivos y no ambiguos para no llevar a confusión. No se debeasignar nombres iguales a métodos semánticamente distintos. Para los métodos se puede tomar como procedimiento deasignación de nombres el formato nombre_objeto, por ejemplo, borrar_pantalla. Dos clases que tengan métodos con elmismo nombre deberían tener un mismo ancestro y los métodos la misma signatura, es decir, el mismo número y tipo deparámetros.Utilizar normas comunes de programación. En referencia a cosas tales como la indentación de párrafos, forma de hacerlos comentarios, poner todos los nombres en minúsculas, etc.Documentar las clases y métodos. Deben existir comentarios en la cabecera de cada clase o método para explicar sucometido, precondiciones y postcondiciones. Así mismo debe haber aclaraciones dentro de cada método acerca de lospasos seguidos en los algoritmos.

En los apartados siguientes se presentan una serie de normas de estilo para lenguajes concretos.

4.1.3. Normas para programadores en COrganización de �cheros

En general un �chero no debe tener más de 1000 líneas y las líneas no deben ser demasiado largas (80 caracteres o más).

Nombres de �cheros

Tienen un nombre base y una extensión, �.c� para el C, �.o� para código objeto, etc. Hay �cheros con nombres reservadoscomo �README� ó �Make�le� (en sistemas UNIX).

Organización de los �cheros de código fuente (�.c�)

Este es el orden sugerido de secciones para un módulo:

1. Un prólogo que indique:

Descripción del propósito de los objetos en los �cheros.Información de gestión, p. ej. información del control de la revisión o fecha de la última modi�cación. (Esta infor-mación es opcional)Autor. (Opcional)

2. Ficheros �.h�. Si la razón de que se incluya un �chero no es obvia debe explicarse. En ocasiones �cheros como �stdio.h�deben incluirse antes que los del usuario.

3. De�nes (macros de constantes, macros de funciones), typedef y enum, por este orden.4. Declaraciones de datos (externas) en este orden: extern, globales no estáticos, globales estáticos. Si un conjunto de �#de-

�ne� se aplica sobre unas líneas de código, esos �#de�ne� deben estar justo antes de esas líneas de código o embebidas enla declaración de estructuras y correctamente indentados (sangrados).

5. Las funciones van la �nal en algún orden lógico. Por ejemplo: se ponen juntas las funciones con un grado similar deabstracción.

Organización de los �cheros de cabecera (�.h�)

Son �cheros que se incluyen dentro de otros antes de la compilación por el preprocesador. Contienen declaraciones de datosy de�nes necesarios para más de un �chero.

1. Organización: Tienen que estar organizados de un modo funcional, es decir, las declaraciones para subsistemas diferentesdeben estar en �cheros de cabecera distintos. Si un conjunto de declaraciones va a ser cambiado cuando se porte el sistemaa otra plataforma, debería también en este caso estar en un �.h� aparte.

2. Los nombres deben ser distintos de los de las librerías del sistema, como �math.h�. No se deben usar nombres de rutacompletas, es mejor utilizar las opciones del compilador para indicar el directorio especí�co o la opción �-I� (para indicarel directorio de las cabeceras en algunos compiladores).

3. Las cabeceras que de�nen funciones o variables externas deben ser incluidas en los �cheros que las de�nen para de estaforma hacer comprobación de tipos y que las variables externas siempre sean consistentes con la de�nición.

4. No se deben de�nir variables en un �chero de cabecera.


5. No debería haber �cheros de cabecera anidados. Si es así, se debe poner en el prólogo que �cheros de cabecera sonnecesarios.

6. Para evitar incluir la misma cabecera más de una vez se debe usar la siguiente estructura:

#ifndef EJEMPLO_H#define EJEMPLO_H/* Cuerpo de EJEMPLO.H */#endif

Otros �cheros

El �chero �README� debe tener una descripción del proyecto completo. Puede también explicar detalles técnicos acercadel �Make�le�, una lista de �cheros dependientes del hardware especí�co de la máquina, etc.

Comentarios

«Cuando el código y los datos se contradicen probablemente ambos estén mal» - Norm Schryer

1. Los comentarios deben describir qué está pasando, cómo se está haciendo, qué signi�can los parámetros, qué variablesglobales se están usando y cualquier restricción o error. Los comentarios cortos (una línea) son para expresar el qué. Elcómo se escribe en unas cuantas líneas que preceden al algoritmo.

2. Los comentarios deben justi�car el código que parezca erróneo o poco razonable.3. Las descripciones de estructuras de datos o algoritmos deben hacerse en bloques de comentario de esta forma:

/** Comentario*/

4. Los comentarios dentro de una función deben estar correctamente indentados con el código que comentan. Pueden usarsetanto comentarios de una línea como de varias. Si el comentario es muy corto se puede poner seguido a una línea de código,y si aparecen varios comentarios de este tipo deben estar a la misma altura.

Declaración de variables

1. Las declaraciones globales se ponen en la primera columna. Las declaraciones externas de datos deben ir precedidas porla palabra extern. Los límites de los arrays hay que repetirlos en la declaración extern.

2. El �*� de la declaración de punteros debe estar junto a la variable y no en el tipo.Mal: char* s,t,v;

Bien: char *s, *t, *v;3. Las declaraciones de cosas que no tengan que ver entre sí deben hacerse por separado.4. Las llaves para abrir �{� deben ir en la misma línea que en los struct ó typedef y la llave para cerrar �}� en la línea

siguiente. Ejemplo:

struct complejo {real a, b;

};

5. Las variables que deban tener un valor inicial se deben inicializar todas de forma explícita.6. Cuando un �chero es parte de un todo en vez de ser un programa autocontenido se debe utilizar la palabra static para hacer

las funciones y las variables locales a los �cheros. Una variable debe poder ser accedida desde otro �chero sólo cuandosea realmente muy necesario y se deberá comentar.

7. Los tipos más importantes deben ser remarcados usando typedef.8. El tipo de retorno se debe declarar siempre.

Declaración de funciones

Cada función debe llevar un prólogo que indique lo que hace la función y cómo usarla. También es conveniente aclarardecisiones de diseño no triviales.Se debe poner un tipo de retorno para cada función. No usar el tipo int por defecto. Si hay que explicar ese tipo, se hace enel prólogo.

Los diez �mandamientos� para los programadores en C

Estas son una serie de normas para no cometer (demasiados) errores.


1. Se debe utilizar alguna herramienta como lint1 de vez en cuando.2. Comprobar siempre si un puntero es NULL.3. Siempre se debe hacer un casting de los argumentos de las funciones a los tipos esperados, incluso cuando creas que no es

necesario.4. Se debe declarar con mucho cuidado los tipos de retorno de las funciones en los �cheros �.h�.5. Comprobar que el tamaño de las cadenas es lo su�cientemente grande como para que quepa cualquier cosa (si se prueba

una cadena con �hola� ten la seguridad que llegará el día en el que alguien escribirá �supercalifragilisticoespialidoso�.6. Si una función puede devolver un código de error, lo comprobarás cada vez que llames a esa función, aunque tripliques el

tamaño del código.7. Estudiarás las librerías para asegurarte de no inventar nada que ya exista, así tu código será corto y legible.8. Indentarás (sangrarás) correctamente tus programas para que su estructura sea clara.9. Los identi�cadores externos deberán ser únicos desde sus primeros seis caracteres.

10. Escribirás código independiente del hardware de la máquina especí�ca en la que programes, porque los días de esa máquinallegarán a su �n antes que los de tu programa.

4.1.4. Normas para programadores en C++A continuación veremos un conjunto de reglas y recomendaciones para escribir código en C++. Estas normas son las de�nidas

por Ellmentel Telecomunications Systems Laboratories. La �nalidad de este apartado es ver un ejemplo más, no es necesariomemorizar, tan solo quedarse con una visión general.

Para que el código sea correcto y fácil de mantener, el programa debería:

Tener un estilo consistente.Ser fácil de leer y comprender.Ser portable a otras arquitecturas.No tener algunos tipos de errores comunes.Ser mantenible por gente diferente.

Las normas tienen dos partes: Las reglas, que no deberían ser infringidas mas que por motivos muy serios y las recomendaciones,que pueden tomarse como consejos.

Ficheros de código fuente

Estructura del código Reglas:

Las extensiones de los mismos tipos de �cheros serán siempre las mismas. Ejemplo: Include: �.h� ó �.hh�, fuente: �.cc�,�cheros inline: �.icc�. Excepción: Cuando se utilicen módulos de C, que no tienen las mismas extensiones.Los �cheros de implementación tienen la extensión �.cc�. Excepción: Hay compiladores que sólo aceptan la extensión�.c�.Los �cheros de de�nición inline tienen la extensión �.icc�.

La �nalidad es dar una visión uniforme de los nombres de �chero y distinguir entre los diferentes tipos, entre los de C y los deC++ y entre los de de�nición y los de implementación. Recomendaciones:

Un �chero include no debe contener más de una de�nición de clase.Dividir la de�nición de las funciones miembro entre tantos �cheros como sea posible.Colocar el código dependiente de la máquina en un módulo aparte.

Nombre de los �cheros Se trata de evitar las colisiones de nombres. Recomendaciones:

Dar siempre nombre de �cheros que sean únicos en un contexto tan grande como sea posible.El nombre de un �chero include de una clase debería ser: NombreClase + extensión. Respetar las mayúsculas y minúsculasdel nombre de la clase en el nombre del �chero.

Comentarios Reglas:

Cada �chero con código fuente debe tener una introducción con información sobre el contenido de ese módulo.Todos los �cheros deben tener copyright.Todos los comentarios se deben escribir en Español.

1Utilidad para programadores en C en UNIX que permite detectar declaraciones no usadas, inconsistencias entre tipos, uso de variables antes de su de�nición,código no alcanzable, caminos de ejecución sin retorno, etc


Recomendaciones:Escribir un breve comentario antes de cada función.Es mejor usar �//� para los comentarios.

Hay que tener en cuenta que los comentarios de los �cheros include van dirigidos a los usuarios de las funciones o clases, y losde los �cheros de implementación a los que mantienen el código.

Ficheros include Reglas:Todos los �cheros include tienen que contar con algún medio que impida múltiples inclusiones de ese archivo.Los siguientes tipos de de�niciones deben estar en �cheros include separados:

• Clases que se usan como clases base.• Clases que se usan como variables miembro.• Clases que aparecen como tipos de retorno o como tipos de argumento en prototipos de funciones o funciones

miembro.• Prototipos de funciones para funciones o funciones miembro usados en funciones inline miembro que están de�nidas

en el �chero.Las de�niciones de clases a las que sólo se accede vía puntero (*) o referencia (&) no serán incluidas como include.Nunca especi�car las rutas completas en las directivas �#include�.Cada �chero de implementación deberá incluir:

• Declaraciones de tipos y funciones usados en las funciones que se implementen en el �chero.• Declaraciones de variables y funciones miembro usados en las funciones que se implementen en el �chero.

Recomendaciones:Usar la directiva #include �nombre_de_fichero.hh� para los include de�nidos por el usuario.Usar la directiva #include <nombre_de_fichero.hh> para los include de las librerías.Cada �chero de implementación debería declarar una constante con una variable de cadena que describa el �chero, así, enun sistema UNIX el comando what podrá ser usado para obtener información del �chero.Nunca incluir otros �cheros en un �chero inline.

Asignación de nombres

Un identi�cador consta de: Pre�jo, Nombre y Su�jo. El pre�jo y el su�jo son opcionales. El su�jo suele ser utilizado porherramientas que generan código. Reglas:

El identi�cador de cada clase, tipo enumerado, función, constante o variable globales en una librería de clases debe empezarcon un pre�jo que sea único para cada librería.Los nombres de las variables, constantes y funciones deben empezar en minúsculas.Los nombres de los tipos abstractos de datos, estructuras, typedef y tipos enumerados deben empezar en mayúsculasLos nombres que consistan en más de una palabra, las palabras deben ir juntas y la inicial de cada palabra debe ir enmayúsculas.No usar identi�cadores que comienzan con �_�.Si un nombre comienza por mayúscula aparece después de un pre�jo.Si un nombre no empieza por mayúscula estará separado de su pre�jo por �_�.

Recomendaciones:No usar nombres que sólo di�eran en que una letra sea mayúscula o minúscula.Los nombres no deben incluir abreviaturas que no sean aceptadas por todo el mundo.Una variable visible en un trozo grande de código debe tener un nombre largo.Los nombres de las variables deberían recordar para qué sirven.Se debe escribir el código de forma que sea fácil cambiar los pre�jos de los identi�cadores globales.Encapsular en una clase: las variables y constantes globales, tipos enumerados y typedef.

Estilo

Clases Reglas:Las partes de una clase de declaran en este orden: Público, protegido y privado. Este es además el orden que interesa ala gente. La parte privada la va a leer cualquiera que use la clase, la parte protegida quien quiera heredar y la privada engeneral nadie.No se de�nen funciones miembro dentro de la de�nición de la clase.


Funciones Recomendaciones:

Dar siempre explícitamente el tipo de retorno de cada función.El primer parámetro de la función va en la misma línea que el nombre y si todos los demás caben en esa línea se ponen, encaso contrario se escribe uno por línea.Escribir el tipo de retorno de cada función en una línea aparte.Escribir el paréntesis izquierdo después del nombre de la función, es decir, que no haya un carácter en blanco. Ejemplo:

intbuscarLista(int intElementos,

cadena *cadenaPunteroLista,cadena cadenaBuscada);

Bloques Recomendación: Los corchetes que delimitan el comienzo (�{�) o el �nal (�}�) de un bloque deben ir en líneas aparte.

Sentencias de control de �ujo Recomendación: Todas las sentencias de control de �ujo (if, else, while, for) deben irseguidas de un bloque incluso aunque sea vacío. Ejemplo:

for (char *c=charCadena; *c!='A' && *c; c++){}

Punteros y referencias Recomendación: Los operadores �*� y �&� deben estar conectados directamente con el tipo de lavariable y no con la variable misma. Nótese que la recomendación para el lenguaje C es justamente la contraria.

Miscelánea Recomendación: No usar espacios alrededor de �.� ó �->� ni entre operadores u operandos unarios.

Clases

Derechos de acceso Regla: No especi�car nunca un dato como público o protegido. Los motivos son que:

Sólo la propia clase podrá manipular esa variable (encapsulación).Cualquier función del programa podría cambiar ese valor provocando errores.Evitando que se modi�que externamente una variable, se evita también que quien modi�que esa variable deba tener encuenta la implementación de la clase.

Funciones inline Una función inline es aquella cuyo código compilado se sitúa donde se utiliza, de esta forma no se hace lallamada y se consigue más e�ciencia. Recomendaciones:

Las funciones de acceso deben ser inline. (Una función de acceso sólo devuelve un valor de un dato miembro).Las funciones que sólo llaman a otra función deben ser inline.Los constructores y destructores no deben ser inline.

Funciones friend Recomendación: Las funciones amigas están para proporcionar funciones adicionales que están mejor fuerade la clase.

Funciones miembro const Reglas:

Una función miembro que no cambie las variables de instancia de un objeto se debe declarar const.Si el comportamiento de un objeto depende de datos externos al objeto, estos datos no deben ser modi�cados por funcionesmiembro const.

Constructores y destructores Reglas:

Una clase que use new para crear instancias gestionadas por la clase debe de�nir un constructor de copia. Excepciones: Siuna clase tiene un área de datos compartida no es necesario tener un constructor de copia, tan sólo hay asegurarse de queno se destruya el área mientras haya punteros que la referencien.Todas las clases que sean usadas como clase base y que tengan funciones virtuales deben de�nir un destructor virtual.No usar objetos globales en constructores y destructores.


Operadores de asignación Reglas:

Una clase que usa new para crear instancias gestionadas por la clase debe de�nir un operador de asignación. Excepción:Si los objetos de una clase tienen un área de datos compartida no es necesario de�nir un operador de asignación. Hay queasegurarse de que el área de datos no se destruye mientras haya punteros que la referencien.Un operador de asignación que hace una operación destructiva debe protegerse de realizar esta acción en el objeto en elque está operando.

Recomendación: Un operador de asignación debe devolver una referencia const al objeto que está siendo asignado.

Sobrecarga de operadores Recomendaciones:

Usar la sobrecarga de operadores de un modo uniforme a lo largo de todo el programa.Cuando se de�ne un operador y también se usa la función opuesta es conveniente de�nir ambos (por ejemplo, �==� y �!=�).

Tipos de retorno de las funciones miembro Reglas:

Una función pública miembro no debe devolver nunca una referencia no constante o un puntero a datos miembro.Una función pública miembro nunca debe devolver una referencia no constante o punteros a datos fuera del objeto a menosque el objeto comparta datos con otros objetos.

Herencia Recomendaciones:

Si un objeto se compone de otros, no utilizar la herencia para re�ejar este tipo de relaciones.Dar acceso a las clases derivadas a los tipos de datos miembro con funciones protected de acceso.

Clases plantillas

Recomendaciones:

Hay clases plantilla que no pueden ser creadas usando un tipo determinado por incompatibilidades con la implementaciónde los métodos. Como el compilador no detecta este tipo de cosas, hay que tener cuidado.Hay que tener cuidado con las de�niciones múltiples de funciones sobrecargadas junto con la instanciación de clasesplantilla. Por ejemplo, si de�nimos una función con un tipo determinado y esa misma función la sobrecargamos con el tipode�nido en la plantilla podríamos tener dos funciones idénticas.

Funciones

Estas reglas son aplicables a las funciones miembro.

Argumentos de las funciones Regla: No usar argumentos sin especi�car (elipsis).Recomendaciones:

Evitar funciones con muchos argumentos.Si una función almacena un puntero a un objeto que es accedido a través de un argumento, dejar que el argumento sea deltipo del puntero.Usar referencias constantes (const &) en vez de llamadas por valor a menos que se estén usando tipos de datos prede�nidoso punteros

Sobrecarga de funciones Recomendación: Cuando se sobrecargan funciones, todas las variaciones deben tener la mismasemántica (son usadas para el mismo propósito).

Argumentos formales Regla: Los nombres de los argumentos de las funciones tienen que ser los mismos en la de�nición yen la declaración.

Tipos de retorno y valores Reglas:

Especi�car siempre el tipo de retorno de una función explícitamente.Una función pública nunca debe devolver una referencia o un puntero a una variable local.

Funciones Inline Regla: No usar la directiva del preprocesador �#define� para obtener código más e�ciente. En lugar deeso usar funciones inline.Recomendación: Usar funciones inline sólo cuando sean realmente necesarias.


Objetos temporales Recomendación: Minimizar el número de objetos temporales que son creados como valores de retorno defunciones o como argumentos a funciones.

General Recomendación: Evitar funciones largas y complejas.

Constantes

Reglas:

Las constantes deben ser de�nidas con const o enum. Nunca usando #de�neEn lugar de utilizar valores numéricos en el código usar valores simbólicos. La excepción serían los valores numéricoscomúnmente utilizados y con signi�cado claro tales como 0, 1, true ó false.

Variables

Reglas:

Las variables deben ser declaradas con el mínimo alcance posible.Cada variable debe ser declarada en una sentencia distinta.Se debe dar un valor a cada variable que sea declarada antes de usarla.Si es posible usar siempre la inicialización en vez de la asignación.Excepción: Cuando se asigna a una variable el valor de una expresión complicada puede no ser necesario dar un valorinicial.

Punteros y referencias

Reglas:

No comparar un puntero con NULL o asignar NULL a un puntero. Usar 0 en su lugar.Deben evitarse en la medida de lo posible los punteros a punteros.Usar typedef para simpli�car la sintaxis cuando se declaren punteros a funciones.

Conversiones de tipos

Reglas:

Nunca usar conversiones explícitas de tipo (cast). Excepciones:

• Una conversión explícita es preferible a una conversión implícita.• Para convertir un puntero a una clase base a un puntero a una clase derivada en un contenedor implementado en una

clase contenedora heterogénea.• Se debe usar para convertir una corriente de bits a un objeto. Ocurre cuando se desempaqueta un mensaje en un buffer.

Como regla general la generación explícita de tipos es necesaria para leer la representación externa de un objeto.

No escribir código que dependa de funciones que usen conversiones implícitas de tipos.Nunca convertir punteros a objetos de una clase derivada a punteros a objetos de una clase base virtual. Excepción: Siuna clase base virtual contiene una función virtual pura que convierte un puntero a clase base virtual a un puntero a clasederivada, esto puede funcionar de�niendo la función en la clase derivada. Esto signi�ca que todas las clases derivadasdeben ser conocidas en la clase base virtual.Nunca convertir un const a un no const.

Estructuras de control de �ujo

Reglas:

El código que va después de un case siempre debe terminar con un break.Las sentencias switch siempre deben tener una rama default para tratar casos inesperados.Nunca usar goto.

Recomendaciones:

La elección del tipo de bucle (for, while, do-while) debe depender de las siguientes consideraciones:

• for: Se usa cuando hay una variable que se incrementa en una cantidad constante cada iteración y la terminacióndepende de una expresión constante.

• while: Cuando la condición de terminación se evalúa al principio de la iteración.


• do-while: Si la condición de terminación es mejor evaluarla al �nal.

Usar siempre unsigned para las variables que no pueden tener valores negativos.Usar límites inferiores incluyentes (�>=�) y límites superiores excluyentes (�<�).Evitar el uso de continue.Usar break para salir de un bucle si esto evita usar �ags.No usar expresiones lógicas del tipo �if(test)� ó �if(!test)� cuando test es un puntero.

Expresiones

Recomendación: Usar paréntesis para clari�car el orden de evaluación de los operadores en las expresiones.

Reserva de memoria

Reglas:

No usar malloc, realloc o free.Usar siempre corchetes (�[ ]�) cuando se liberan arrays con delete.

Recomendaciones:

Evitar usar datos globales.No liberar memoria, esperar que algún otro lo libere más tarde.Asignar siempre un nuevo valor a un puntero que apunte a memoria liberada.

Manejo de errores

Recomendaciones:

Asegurarse de que el manejo de fallos se ha hecho de tal modo que sea fácil convertirlo al manejo de excepciones.Comprobar los códigos de fallo que se pueden recibir de funciones de librería incluso si esas funciones parecen seguras.

Código portable (multiplataforma)

Abstracciones de datos Recomendación: No usar directamente los tipos de datos prede�nidos en las declaraciones.

Tamaño de los tipos Recomendaciones:

No suponer que un int y un long tienen el mismo tamaño.No suponer que un int tiene 32 bits (quizás tiene sólo 16).No suponer que un char es signed o unsigned.Poner siempre unsigned char si se usa ASCII de 8 bits.

Conversiones de tipo Recomendaciones:

Sea cuidadoso cuando haga conversiones de tipo desde uno �corto� a uno �más largo�.No suponer que los punteros y los enteros tienen el mismo tamaño.Usar conversiones explícitas de tipo para operaciones aritméticas usando valores con signo y sin signo.

Representación de datos Recomendaciones:

No suponer que se conoce como se representa en memoria la instancia de un objeto.No suponer que los tipos long, �oat, double o long double van a comenzar en direcciones de memoria arbitrarias o ajus-tadas.

Under�ow / Over�ow Recomendación: No depender del funcionamiento del under�ow u over�ow de ningún modo.

Orden de ejecución Recomendaciones:

No suponer que los operandos de una expresión van a ser evaluados en un orden de�nido.No suponer que se conoce como han sido implementados los mecanismos de invocación de una función.No asumir que un objeto es inicializado en un orden concreto en los constructores.No asumir que los objetos estáticos son inicializados en ningún orden concreto.


Objetos temporales Recomendación: No escribir código que dependa del tiempo de vida de un objeto temporal.

Aritmética de punteros Recomendaciones:

Evitar usar las operaciones de desplazamiento en lugar de la aritmética de punteros.Evitar la aritmética de punteros.

4.1.5. Normas para programadores en JavaJava, al igual que C++, es un lenguaje orientado a objetos. La mayor parte de las normas que son aplicables a C++ son

igualmente válidas para Java, no obstante, SUN ha de�nido una serie de normas en la página http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html que exponemos resumidas a continuación.

Ficheros

La extensión para los archivos de código fuente es �.java� y para los archivos compilados �.class�.

Organización de �cheros

Cada �chero debería contener una sola clase. Si hay clases privadas e interfaces asociados con esa clase se pueden poner enel mismo �chero después de la clase pública. Las secciones en las que se divide el �chero son:

Comentarios de tipo directorio de todo el módulo.Sentencias del tipo package e import.Clases y declaraciones de interfaz. Consta de las siguientes partes:

• Comentarios generales acerca de la clase o interfaz (comentarios de documentación).• Sentencia class o interface.• Comentarios acerca de la implementación de las clases (comentarios de implementación).• Variables estáticas.• Variables de instancia. Tanto las variables estáticas como las de instancia se agrupan por su alcance, es decir, por este

orden: públicas, protegidas y privadas.• Constructores.• Métodos. Se agrupan por su funcionalidad, no por su alcance.

Formato del texto

SUN de�ne una serie de principios generales:

El sangrado determinado para un bloque es de cuatro espacios.La longitud de las líneas de código no debe ser superior a 80 caracteres.La longitud de las líneas de comentarios no debe ser superior a 70 caracteres.Normas para partir líneas demasiado grandes:

• Partir después de una coma.• Partir después de un operador.• Es preferible romper a alto nivel que a bajo nivel. Ejemplo:

Bien:

x = MetodoLargo (Par1, Par2,MetodoBajoNivel(Par31,Par32,Par33)

Mal:

x = MetodoLargo (Par1, Par2, MetodoBajoNivel(Par31,Par32,Par33)

• Alinear la nueva línea al comienzo de la anterior. Si esto pudiera causar confusión indentar (sangrar) con 8 espacios.

Comentarios

En Java hay dos tipos de comentarios: De documentación y de implementación. Los comentarios de documentación tienen laforma: �/* ... */�. Existe una herramienta llamada Javadoc que genera páginas HTML partiendo de este tipo de comentarios.El tema de los comentarios se trata en profundidad en el tercer apartado de este capítulo.


Declaraciones

La recomendación en este sentido es que no se declare más de una variable por línea, poniendo el nombre de la variableindentada y con un comentario. Deben estar localizadas al principio del bloque. Ejemplo:

int numPuntos = 3; // Puntos que definen la figura

Es conveniente inicializar las variables en el lugar en el que se declaran, a menos que esta inicialización dependa de un cálculoposterior.Las clases e interfaces deben usar la siguiente convención:

No se ponen espacios entre el nombre de los métodos y el paréntesis �(�.La llave de apertura �{� aparece en la misma línea que el nombre del método o clase.La llave de cierre de bloque �}� aparece en una línea a parte del bloque, excepto cuando el bloque está vacío.Los métodos se separan por una línea en blanco.

Ejemplo:

class Punto extends ObjetoGrafico {int x;int y;Punto(a,b) {

x=a;y=b;

}

Sentencias

Debe haber una y sólo una sentencia por línea. Si hay un bloque de sentencias, éste debe ser sangrado con respecto a lasentencia que lo genera y debe estar entre llaves aunque sólo tenga una sentencia para de este modo evitar errores cuandose añaden otras sentencias al bloque. Ejemplo:

if (x>1) {y++;z=CalcularZ(x,y);

}else {

y=y-2;}

Sentencias if-else, if else-if else. A los bloques de�nidos por estas sentencias se les aplican las normas de�nidas en puntosanteriores. Todos los bloques tienen el mismo nivel de sangrado.Bucles. De�nen un bloque, que sigue las normas anteriores. Si el bucle es vacío (no tiene sentencias) no se abren ni secierran llaves.Las sentencias return no deben usar paréntesis.

Separaciones

Incrementan la legibilidad del código. La regla general es que cuanto más �importante� sean las partes a separar tanto mayordebe ser la separación. En este sentido el criterio es:

Dos líneas: Entre clases e interfaces.Una línea: Entre métodos, declaraciones de variables y la primera instrucción, secciones lógicas diferentes de un métodoy antes de un comentario de línea o de bloque.Un carácter en blanco: Entre una palabra y un paréntesis, después de una coma, los operadores binarios menos el �.�, lasexpresiones del for, y entre un cast y la variable.

Ejemplo:

class X {...}class Y extends X{/* Declaraciones */

int x;int y;

/** Desplaza la figura pixel a pixel horizontalmente */

4.2 Técnicas de depuración 69

int desplazarHorizontal(int h) {int inc;if (h<0) {

h = -h;inc = -1;

}else {

inc = 1;}for (int i=0; i<h; i++) {

x = x + inc;if (!Dibujar()) {

return -1;}

}return 0;

}/** Desplaza la figura pixel a pixel verticalmente */

int desplazarVertical(int h) {...

Nombres

Las normas de asignación de nombres son:

Paquetes: Nombres en minúsculas separados por puntos. Ejemplo: java.io.Clases e interfaces: Dos o tres nombres con la primera letra en mayúsculas, sin usar abreviaturas. Ejemplo: ObjetoGrafico.Métodos: La primera palabra debería ser un verbo y en minúsculas. Ejemplo: desplazarHorizontal.Variables: Deben ser cortas (pueden ser de una letra) y signi�cativas. Si son varias palabras la primera en minúscula.Ejemplos: i, j, k, unTriangulo.Constantes: Se escriben en mayúsculas y si son varias palabras van unidas por un carácter de subrayado. Ejemplo:

MAX_LONG = 1000

4.2. Técnicas de depuraciónDurante el desarrollo de la fase de implementación se deben realizar dos tipos de labores relacionadas con la comprobación

del código obtenido. La primera consiste en elaborar los conjuntos de prueba para los diferentes módulos que se programan. Lasegunda consiste en comprobar si los módulos cumplen las especi�caciones de diseño con esos conjuntos de prueba. Tambiénse puede incluir dentro de este proceso la comprobación de corrección en la ejecución de los módulos y evitar posteriormente laaparición de errores frecuentes como pérdidas de memoria, comportamientos extraños ante entradas de datos imprevistas, etc.

El contenido de este apartado se encuentra en [Pre05, sec. 13.7] o en la quinta edición [Pre01, cap. 18.7].

4.3. Documentación del códigoAdemás de la documentación incluida dentro del código fuente correspondiente, es necesario generar los manuales técnicos y

de referencia adecuados, así como la parte inicial correspondiente del manual de usuario (que se �nalizará en la fase de entrega).Estos manuales se deben ir escribiendo simultáneamente al código y se deben actualizar en concordancia con los cambios en elmismo.

Esta documentación es esencial para las fases de pruebas y de mantenimiento, así como para la entrega �nal del producto.Por tanto se deben mantener actualizadas y funcionales desde el primer momento.

Además de las recomendaciones que se han dado para lenguajes especí�cos vamos a ver de que modo se puede hacer ladocumentación interna de un programa (comentarios). Esta documentación es importante de cara al mantenimiento futuro delprograma, tanto si lo hacen terceras personas como si lo hace el encargado de programar el código fuente del módulo. Ademásde estos comentarios en el código se extraen los esbozos para los manuales técnicos y de referencia.

4.3.1. Tipos de comentariosDistinguiremos tres tipos de comentarios desde el punto de vista de la parte que comentan y dónde se localizan.

Directorio: Son los situados al principio de cada módulo. La información que contiene es: Lista de funciones o clasesimplementadas en el módulo, Versión, Fecha, Programador, Copyright e Interfaces con otros módulos.Prólogo: Cumple la misma función que el directorio pero para cada función o método. Indica la siguiente información:Finalidad, Comentarios acerca de las variables signi�cativas, Descripción general del funcionamiento e Información parala reutilización (efectos colaterales, variables globales que utiliza, etc.)


Explicativo: Aclaraciones acerca de partes del código. Hay dos tipos: de línea y de bloque.Las ventajas de los comentarios de bloque es que están localizados en un punto concreto y no dispersos por varias líneasentre el código, con lo que además son fáciles de modi�car. Los comentarios de una línea deben ponerse en la misma líneadel código que se esta comentando y se usan para explicar sentencias complicadas.

Los tipos de comentarios según cómo están redactados son estos cinco (de peor a mejor):

Repetir el código: Consiste en expresar el código de otra forma pero sin añadir información signi�cativa. Este tipo decomentarios son innecesarios.Explicación del código: Ayudan a comprender el código. Es mejor reescribir el código de modo que sea más inteligibleque utilizar este tipo de comentarios.Marcadores: Son notas temporales para la gente que trabaja en el proyecto. Se eliminan cuando el proyecto �naliza.Resumen del código: Explica en pocas palabras la función de un trozo de código.Descripción de la �nalidad: Explica el por qué. Es el más fácil de entender.

4.3.2. Consideraciones generalesLos comentarios deben ser entre el 25 % y el 33 % de las líneas de un módulo.No se deben comentar cosas evidentes. Ejemplo:

if (x<5) i+=2; // Suma 2 a �i� cuando �x� es menor que 5

Se debe comentar más el cómo y no el qué.Los datos se deben comentar cuando el nombre no sea su�ciente como para que se entienda. Si un dato se compone deotros más pequeños aplicar esta misma regla recursivamente caso de ser necesario.


En teoría es posible realizar la implementación de un modo totalmente automatizado partiendo del diseño. Como esto a veceses difícil de llevar a la práctica, se dan una serie de consejos para pasar el diseño a código fuente y como redactar este códigofuente en un conjunto de lenguajes.

Traducción del diseño a la implementación

Ingeniería inversa: Consiste en averiguar las especi�caciones de un sistema a partir de su funcionamiento. Se dan algunasheurísticas para averiguar los casos de uso de un sistema: de�niciones de clases, creación y destrucción de objetos, invo-cación de métodos, herencia e implementación de asociaciones.

Estilo de programación orientado a objetos: Son un conjunto de consejos para conseguir: reusabilidad, reconocer la herencia,construir métodos extensibles, código robusto y trabajo en grupo e�caz.

Normas para programadores en C: Son un conjunto de normas que cubren todos los apartados de la codi�cación, tanto deltamaño de los �cheros, como de la elección de nombres (quizás lo más importante), indentación, etc.

Normas para programadores en C++: Es una recopilación similar para el lenguaje C++. Es más extenso debido a la comple-jidad del lenguaje. Estas normas fueron compiladas por Ellmentel Telecomunications System Laboratories.

Normas para programadores en Java: Es un resumen de las normas publicadas por SUN para el lenguaje Java.

Técnicas de depuración

Consiste en un conjunto de técnicas para descubrir errores de codi�cación. Incluye también un pequeño apartado para proce-sos concurrentes.

Documentación del código

Al igual que el diseño el análisis producen documentos según una plantilla estándar, el código tiene que tener una docu-mentación interna. Se distinguen los tipos de comentarios (Directorio, prólogo y explicativo), donde se colocan, que informaciónse incluye en cada uno de ellos y la forma de redacción de la información.

4.3 Documentación del código 71

Ejercicios y actividades propuestas1. Suponga que tiene este código:

char *posicion(char *cad,char *cad2) {for (char *c1=cad,char *c2=cad2; *c1; c1++) {for (char *c3=c1,char *c4=c2; *c3 && *c4 &&(*c3==*c4); c3++, c4++)if (!*c4) return c1;}}

a) ¿Qué propósito tiene?b) ¿Es correcto?. Si no es así, ¿a qué se debe?c) Redacte de nuevo el código de modo que se pueda entender su propósito y funcionamiento de un vistazo.

Asigne nombres signi�cativos a las variables y a la función.Escriba comentarios.Ponga la indentación correcta.Si es necesario cambie la estructura de la función.

2. Suponga que tiene un programa en C++ que calcula un fractal y lo dibuja como una imagen en la pantalla. Para estas fun-ciones utiliza un módulo con una estructura de datos que de�ne los números complejos y las operaciones relativas a ellos:Producto, Suma, Resta, Potencia. A cada punto de la pantalla se le aplica un algoritmo, lo cual estaría en otro módulo. Setendría otro módulo con las funciones relativas a los grá�cos: Dibujar matriz de puntos, Zoom, etc.Redacte la documentación de cada módulo del programa: prólogo y comentarios antes de cada función (haga las suposi-ciones que considere oportunas sobre que funciones existirían).

Extensión de conocimientosTambién se puede estudiar parte de los contenidos de este tema en [Som98, caps. 5 y 6], [RBP+96], [BMP87, caps. 10 al 15]

ó [Sch92, caps. 9 y 10].La herramienta de análisis y modelado de software ALMA http://www.desnoix.com/guillaume/alma/, permite el análi-

sis de código fuente orientado a objetos para su representación y modelado o su transformación a otros lenguajes. Esta herramien-ta, ALMA, es muy interesante y al estar implementada en Java es fácilmente instalable en cualquier entorno.

Es interesante hacer notar que existen ciertos lenguajes de programación que facilitan y promueven con su sintaxis unacodi�cación más clara, ordenada, sistemática y autodocumentada. Tal es el caso, por ejemplo, del lenguaje PYTHON que,normalmente, es interpretado pero que auto-precompila cada �chero fuente ejecutado y reutiliza esa versión precompilada(preanalizada) si no cambia el fuente. Este lenguaje es muy útil para hacer prototipos rápidos, pero también para aplica-ciones más grandes (por ejemplo véase ZOPE http://www.zope.org/). Prácticamente todas las implementaciones de PYTHONson de libre distribución. Se puede ver más información en las siguientes páginas Web: http://www.python.org/, http://www.freenetpages.co.uk/hp/alan.gauld/spanish/ es una traducción al español del libro [Gau01] (un tutorial básico),el libro de libre distribución (licencia FDL) [DEM02] en http://www.ibiblio.org/obp/thinkCSpy/ o un libro en líneahttp://diveintopython.org/es/ (traducción al castellano de �Dive into Python�) con varias referencias a otra informaciónen español, aparte de la página http://users.servicios.retecal.es/tjavier/python/Un_poco_de_Python-2.html so-bre PYTHON de Tomás Javier Robles Prado.

Existe una técnica de escribir la documentación incluida dentro del código fuente, conocida por el nombre en inglés de�Literate Programming�. Se puede encontrar extensa información sobre este tema en la FAQ especí�ca: http://shelob.ce.ttu.edu/daves/lpfaq/faq.html. Además hay algunas otras herramientas de ayuda en la generación de referencias cruzadasy documentación a partir del código fuente, como por ejemplo CXREF http://www.gedanken.demon.co.uk/cxref/, ó la másreciente y completa DOXYGEN http://www.doxygen.org/ (que se puede utilizar para otros lenguajes además de C). Tambiénes interesante ver el ejemplo de cómo un proyecto enorme, como es el �kernel� del sistema operativo Linux, tiene un sistema dereferencias cruzadas: http://lxr.linux.no/.

Modi�caciones en la guía

Los cambios más importantes de la guía son todo lo referente al UML, contenido en el capítulo 1.

Se ha añadido un grá�co de ejemplo de DFD en el capítulo 1, página 3.

Se ha ampliado el resumen de los conceptos importantes en orientación a objetos en el capítulo 1, página 4.

Se ha eliminado el resumen de UML del tutorial posterior correspondiente al capítulo 1.

Se han eliminado las siguientes referencias a páginas web que ya no están disponibles:

Capítulo 1

• liinwww.ira.uka.de/bibliography/SE• usuarios.lycos..es/oopere/uml.htm

Capítulo 2: La referencia: www.cibertienda.org parece estar temporalmente no disponible en la red. No se ha eliminadoporque hay numerosas páginas que hacen referencia a esta aplicación. Se puede encontrar información relativa en www.onirica.com/es/productos/cibertiendaCapítulo 4

• www.oprenresources.com/es/magazine/tutoriales/corba

Capítulo 5

• www.bagley.org/doug/shootout/• internet.ls-la.net/mirrors/99bottles/

Se han añadido las siguientes referencias a páginas web:

Capítulo 1

• www.eclipse.org• eclipse-plugins.2y.net/eclipse/index.jsp

Capítulo 4

• java.sun.com/developer/onlineTraining/corba/corba.html

73

Bibliografía

[Bau72] F. L. Bauer. Software Engineering. Information Processing, (71), 1972.

[BMP87] Doug Bell, Ian Morrey, and John Pugh. Software Engineering: A Programming Approach. Prentice Hall, 1987.

[Boo94] Grady Booch. Object-Oriented Analysis and Design. Benjamin Cummings, 1994.

[CCEG00] J. A. Cerrada, M. Collado, J. F. Estívaliz, and S. R. Gómez. Introducción a la Ingeniería de Software. Ceura, 2000.

[DEM02] Allen Downey, Jeff Elkner, and Chris Meyers. How to Think Like a Computer Scientist: Learning with Python.Green Tea Press, 2002. http://thinkpython.com.

[Fow97] Martin Fowler. UML Distilled. Addison Wesley, 1997.

[FW94] Neville J. Ford and Mark Woodroffe. Introducing Software Engineering. Prentice-Hall, 1994.

[Gau01] Alan Gauld. Learn to Program Using Python. Addison-Wesley, 2001.

[GW89] Donald A. Gause and Gerald M. Weinberg. Exploring Requirements: Quality Before Design. Sei Series in SoftwareEngineering. Dorset House, 1989.

[Haw98] I. T. Hawryszkiewycz. Introducción al análisis y diseño de sistemas. Anaya, 1998.

[Hum95] Watts S. Humphrey. A Discipline for Software Engineering. Addison-Wesley, 1995.

[Hum01] Watts S. Humphrey. Introducción al Proceso Software PersonalSM . Addison-Wesley, 2001.

[Jac92] Ivar Jacobson. Object Oriented Software Engineering. Addison Wesley, 1992.

[JBR00a] Ivar Jacobson, Grady Booch, and James Rumbaugh. El lenguaje uni�cado de modelado. Addison Wesley, 2000.

[JBR00b] Ivar Jacobson, Grady Booch, and James Rumbaugh. El lenguaje uni�cado de modelado. Manual de referencia.Addison Wesley, 2000.

[Mey98] Bertrand Meyer. Construcción de Software O-O. Prentice Hall Iberia, 1998.

[Pre01] Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-Hill, 2001.

[Pre05] Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-Hill, 2005.

[PV96] Mario G. Piattini Velthuis. Análisis y diseño detallado de aplicaciones informáticas de gestión. RAMA, 1996.

[RBP+96] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Modelado y diseñoorientado a objetos. Metodología OMT y OMT II. Prentice Hall, 1996.

[Sch92] Stephen R. Schach. Practical Software Engineering. Aksen Associates, 1992.

[Sch01a] Stephen R. Schach. Object oriented and classical software engineering. Mc GrawHill, 2001.

[Sch01b] Joseph Schmuller. Aprendiendo UML en 24 horas. Prentice Hall, 2001.

[Som98] Ian Sommerville. Ingeniería de Software. Addison-Wesley Iberoamericana, 1998.

[Som01] Ian Sommerville. Software Engineering. Addison-Wesley, 2001.

[WBWW90] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. Designing Object-Oriented Software. Prentice Hall,1990.

75

Índice alfabético

Abstract factory, 46Adapter, 46Adecuación, 3Análisis, 28Antipatrón, 44Argumentos, 64Asignación, 64Asociaciones, 56

C++, 56Java, 57

Balking, 47Bloques, 63Brainstorming, 32Bridge, 46Broker, 45Builder, 46

C++, 4Código externo, 58Cache management, 46Casos de uso, 34, 35, 54

Actor, 34, 35Rol, 34

Actores abstractos, 37Casos de uso abstractos, 37Casos de uso de implementación, 37Casos de uso esenciales, 37Casos de uso primarios, 37Casos de uso secundarios, 37Casos de uso temporales, 37Extends, 12Include, 12

Cast, 65Chain of responsability, 46Ciclo de vida, 4

Cascada con reducción de riesgos, 7Cascada con subproyectos, 7Cascada incremental, 7Ciclo de vida en cascada, 5Ciclo de vida en V, 6Espiral, 8Fuente, 9Sashimi, 6

Clase, 13Abreviada, 14Abstracta, 13Asociación, 15

Agregación, 15Cali�cación, 15Composición, 15Dependencia, 17Herencia y generalización, 16Interfaces, 14Multiplicidad, 15Navegabilidad, 15

Re�exiva, 16Rol, 15

Atributos, 14Estereotipo, 19Método, 14Nombre, 13Notas, 19Operaciones, 14Paquete, 19Responsabilidades, 14Subsistema, 19

Clase abstracta, 13Clases, 62

Java, 69code-and-�x, 2Comentarios, 60, 61

Java, 67Command, 46Composite, 46Const, 63Constantes

Java, 69Constructores, 63Control de �ujo, 63, 65Corrección, 3Creación de objetos, 55

C++, 55Java, 55

Declaración, 60Funciones, 60Variables, 60

DeclaracionesJava, 68

Decorator, 46De�nición de clases, 54

C++, 54Java, 55

Delegación, 58Delegation, 46Demeter, 58Destrucción de objetos, 55

C++, 55Java, 55

Destructores, 63DFD, 3Diagrama de actividades, 22

Actividades, 22Actividades concurrentes, 23Bifurcaciones, 23Indicaciones, 23Punto �nal, 22Punto inicial, 22Transiciones, 22

Diagrama de clases, 18Diagrama de colaboración, 2176

Índice alfabético 77

Diagrama de componentes, 24Diagrama de despliegue, 24

Nodo, 24Diagrama de estados, 21Diagrama de objetos, 18Diagrama de secuencias, 20

Activación, 21Condicional, 21Creación, 21Destrucción, 21Invocación recursiva, 21Iteración, 21Línea de vida, 20Tiempos de transición, 21

Diccionario de datos, 3Directorio, 69Diseño

Revisión, 49Validación, 49Veri�cación, 49

Disponibilidad, 3Documentación, 69Dynamic linkage, 46

E�ciencia, 3Entrevistas

Fases, 29Entrevistas genéricas, 29Errores, 66Especi�cación, 28Especi�cación de procesos, 3Etapas ciclo de vida, 4

Análisis, 4Codi�cación, 4Diseño, 4Mantenimiento, 4Pruebas, 4

Excepciones, 66Explicativo, 70Expresiones, 66Extensibilidad, 58

Facade, 46Factory method, 46Fiabilidad, 3Filter, 46Flyweight, 46Framework, 44Friend, 63Funciones, 63

Guarded suspension, 47

Herencia, 56, 64C++, 56Estática, 56Implícita, 56Java, 56Por grupos, 56

Include, 62Ingeniería de sistemas, 2Ingeniería del software, 2Ingeniería directa, 54Ingeniería inversa, 54Inline, 63, 64

Inmutable, 46Interface, 46Interfaces

Java, 69Invocación de métodos, 55

C++, 56Java, 56

Iterator, 46

JAD, 30Java, 4JRP, 32

La crisis del software, 2Layered initialization, 46Layers, 45Little languaje, 46

MétodosJava, 69

Mantenibilidad, 3Marker interface, 46Mediator, 47Memoria, 66Metodología, 2

Estructurada, 3Orientada a objetos, 3

Microkernel, 45Modelo, 10Modelo-Vista-Controlador, 45MTBF, 3Multiplataforma, 66

Nombre, 61Nombres, 62

Java, 69Normas, 59

C, 59C++, 61Java, 67

Null object, 47

Object pool, 46Observer, 47OMG, 10OMT, 10OOSE, 10Operaciones abstractas, 14Over�ow, 66

PaquetesJava, 69

Patrón, 44Patrones, 44

Patrones arquitectónicos, 44, 45Patrones de análisis, 44Patrones de codi�cación, 44Patrones de diseño, 44Patrones de organización, 44Sistemas adaptables, 45Sistemas distribuidos, 45Sistemas genéricos, 45Sistemas interactivos, 45

Patrones de diseño, 45De comportamiento, 46De concurrencia, 47De creación, 46

78 Índice alfabético

De partición, 46Estructurales, 46Fundamentales, 46

Pizarra, 45Prólogo, 69Presentación-Abstracción-Control, 45Producer-Consumer, 47Prototipos, 33

Componentes reutilizables, 34Nivel de aplicación, 34Nivel de componente, 34

Desarrollo rápido de prototipos, 33Lenguajes de alto nivel, 33Programación de bases de datos, 34

Prototype, 46Proxy, 46Punteros, 63, 65

Read/Write lock, 47Re�exión, 45Requisito, 28Requisitos funcionales, 28Requisitos no funcionales, 28Reusabilidad, 57Robustez, 58

Scheduler, 47Sentencias

Java, 68Separaciones

Java, 68Simula67, 4Single threaded execution, 47Singleton, 46Sistema, 2Smaltalk, 4Snapshot, 47Sobrecarga, 64

Funciones, 64Operadores, 64

SRS, 38State, 47Strategy, 47

Template method, 47Templates, 64Tuberías y �ltros, 45Two-phase termination, 47

UML, 10, 54Under�ow, 66Usabilidad, 3

Variables, 65Java, 69

Virtual proxy, 46Visitor, 47

mantenimiento del software 1

Documents