Analisis_Diseno_y_Mantenimiento_del_Software

Vista previa del material en texto

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/267196110
Análisis, Diseño y Mantenimiento del Software
Article
CITATION
1
READS
3,092
2 authors:
Manuel Arias
National Distance Education University
19 PUBLICATIONS   114 CITATIONS   
SEE PROFILE
Angeles Manjarrés Riesco
National Distance Education University
52 PUBLICATIONS   260 CITATIONS   
SEE PROFILE
All content following this page was uploaded by Angeles Manjarrés Riesco on 20 January 2015.
The user has requested enhancement of the downloaded file.
https://www.researchgate.net/publication/267196110_Analisis_Diseno_y_Mantenimiento_del_Software?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_2&_esc=publicationCoverPdf
https://www.researchgate.net/publication/267196110_Analisis_Diseno_y_Mantenimiento_del_Software?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_3&_esc=publicationCoverPdf
https://www.researchgate.net/?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_1&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Manuel-Arias?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Manuel-Arias?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/National-Distance-Education-University?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Manuel-Arias?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Angeles-Riesco?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Angeles-Riesco?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/National-Distance-Education-University?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Angeles-Riesco?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Angeles-Riesco?enrichId=rgreq-b8bfb07b89eca4df65cd21806045909d-XXX&enrichSource=Y292ZXJQYWdlOzI2NzE5NjExMDtBUzoxODc2MjI1MTMxOTI5NjBAMTQyMTc0NDEwMTM0Mg%3D%3D&el=1_x_10&_esc=publicationCoverPdf
Análisis, Diseño y Mantenimiento del Software
Manuel Arias Calleja y Ángeles Manjarrés Riesco
Dpto. de Inteligencia Arti�cial - ETSI Informática - UNED
Actualizada en Octubre de 2006
Parte correspondiente al primer parcial
II
Índice general
Guía de estudio de la asignatura V
Presentación y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
Contexto y conocimientos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
Esquema y resumen de contenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI
Material y medios de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII
1. Contexto de la asignatura en la Ingeniería de Software 1
1.1. Necesidad de una metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2. La crisis del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3. De�nición de metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.4. Finalidad de una metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.5. Taxonomía de las metodologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Ciclo de vida del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Ciclos de vida en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Modelo de ciclo de vida en espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3. Ciclos de vida orientados a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Notaciones de especi�cación y diseño (UML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2. Modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3. Modelo estructural estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.4. Modelo de comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.5. Modelo estructural de implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2. Fase de especi�cación 27
2.1. Obtención de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.2. Técnicas de obtención de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3. Representación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4. Análisis orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5. Validación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6. Bases de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3. Fase de diseño 43
3.1. Conceptos y elementos del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.1. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2. Diseño estructurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3. Diseño orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
3.4. Validación y con�rmación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.1. Revisión del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.2. Veri�cación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.3. Validación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5. Documentación: especi�cación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4. Fase de implementación 53
4.1. Guías de estilo de codi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.1. Traducción del diseño a la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.2. Estilo de programación orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.3. Normas para programadores en C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.4. Normas para programadores en C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61III
IV Índice general
4.1.5. Normas para programadores en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2. Técnicas de depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3. Documentación del código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.1. Tipos de comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.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 objetivos
El 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 centran
en el análisis de los procesos de desarrollo y mantenimiento, así como de las técnicas integrales y de apoyo al servicio de la
obtenció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án
los evaluados en las pruebas presenciales. En la Guía de Curso se detallan objetivos docentes adicionales que serán cubiertos
mediante actividades NO obligatorias que los alumnos podrán seguir en los cursos virtuales a la vez que estudian el temario
convencional.
Contexto y conocimientos previos
Contexto académico previo
Ingeniería del software es una materia troncal del segundo ciclo que en la titulación de Ingeniero en Informática, impartida
por la ETSII de la Universidad Nacional de Educación a Distancia (Resolución de 21 de marzo de 2001, BOE 10 de abril), se ha
dividido en dos asignaturas obligatorias y anuales del cuarto curso, cada una de las cuales tiene asignados 9 créditos (5 teóricos y
4 prácticos). Las denominaciones que se han dado a estas dos asignaturas complementarias son Análisis, Diseño y Mantenimiento
del software (descrita como �Análisis y de�nición de requisitos. Diseño, propiedades y mantenimiento del software�) y Análisis y
Gestión del Desarrollo del Software (descrita como �Análisis de aplicaciones. Gestión de con�guraciones. Plani�cación y gestión
de proyectos informáticos�).
Ambas asignaturas se hayan fuertemente vinculadas, en tanto que se complementan para proporcionar una visión general del
proceso completo de la producción de software, tanto desde un punto de vista técnico como humano, vertientes que caracterizan
todo proceso de ingeniería.
El programa de la asignatura Análisis y Gestión del Desarrollo del Software está estructurado en dos cuatrimestres. El primer
cuatrimestre se dedica al Proceso Software Personal (PSP), cuyo objetivo es la adquisición de una correcta disciplina personal
para el desarrollo de un software de calidad en los plazos y costes comprometidos. El segundo cuatrimestre está dedicado a
la gestión global del proceso de desarrollo software en el que intervienen decenas o centenares de ingenieros. Su objetivo es
también obtener un software de calidad en los plazos y costes plani�cados, si bien en este caso se destacan la problemática y las
técnicas asociadas al trabajo en equipo. Las asignaturas de Ingeniería del software deberían, idealmente, ser cursadas en paralelo
por los alumnos, dado su carácter mutuamente complementario. En de�nitiva, el objeto de la asignatura Análisis y Gestión del
Desarrollo del Software es mostrar cómo se evalúan las técnicas de ingeniería estudiados en la asignatura Análisis, Diseño y
Mantenimiento del software, y cómo se aplican en un contexto profesional.
Otras asignaturas relacionadas
Son 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 otras
universidades) 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 materia
objeto de esta memoria (dada la extensión de los contenidos, es conveniente que el alumno parta de una visión introductoria y
general 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 se
encuadran 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 que
estudian la teoría de la computabilidad (Teoría de autómatas I, Teoría de autómatas II). (Obviamente, la comprensión de las
mencionadas asignaturas a su vez ha exigido del alumno los conocimientos matemáticos que se proporcionan en las asignaturas
Ló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 los
temas anteriores pero de una orientación más práctica y especí�ca. Es el caso de las optativas del tercer curso Programación
Concurrente, Programación Declarativa y Programación Orientada a la Inteligencia Arti�cial (orientadas a la programación), y
Diseñ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 optativa
del tercer curso, aborda el estudio de las diferentes fases del ciclo de desarrollo de un sistema experto, coincidentes en lo esencial
con las fases de desarrollo de los productos software convencionales. Sin duda el alumno que haya estudiado esta asignatura
dispondrá de una visión más abierta, y la re�exión sobre los paralelismos y discrepancias entre ambas disciplinas le ayudará a
profundizar 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 eliminando
progresivamente sus difusas fronteras, y comenzado a bene�ciarse mutuamente de sus respectivos avances. En concreto, el uso
de las técnicas OO se ha generalizado en todos los ámbitos, y las técnicas de formalización de requisitos se ven enriquecidas
por los interesantes resultados obtenidos en el campo del procesamiento del lenguaje natural, tradicionalmente estudiado en la
Inteligencia Arti�cial. El conocimiento de los principios básicos de la Inteligencia Arti�cial, que se estudian en la asignatura
obligatoria 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, y
que resulta interesante que el alumno estudie en paralelo con las asignaturas de Ingeniería del software, tratando de establecer las
oportunas 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, en
particular, de las obligatorias Sistemas Informáticos I, Sistemas Informáticos II y Sistemas Informáticos III, más las optativas
Aprendizaje 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 y
Sistemas 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 obligatorio
para la obtención del título. Por supuesto será fundamental para la formación posterior del alumno titulado y para el ejercicio de
su práctica profesional.
Esquema y resumen de contenidos
A 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. En
la segunda parte se van describiendo las distintas fases del desarrollo y mantenimiento del software. La parte �nal incluye un
conjunto de metodologías donde se recopilan y organizan de diferentes formas las fases, junto con algunas herramientas de
desarrollo.
Esta asignatura es anual y por lo tanto se divide en dos parciales. A los efectos de exámenes parciales se considera que los
temas 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 estudio
Estructura 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ón
a distancia necesita para poder estudiar la asignatura. Al principio de cada capítulo se incluye un �Tutorial previo� con los
elementos que describen el contexto, conocimiento previo, objetivos y guía de estudio para ese capítulo. En esta asignatura se
utilizará 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, 2005
Este 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 en
esta 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 �Tutorial
posterior� que contiene ejercicios o actividades propuestas adicionales a las que aparecen en el libro base, para que el alumno
pueda comprobar si ha logrado los objetivos del capítulo, y también información adicional para la extensión de conocimientos
para los alumnos interesados en profundizar en el tema, junto con referencias alternativas sobre los mismos contenidos. Al �nal
de esta guía didáctica se incluye en un apéndice el glosario de términos habituales en la Ingeniería de Software que pueden
aparecer en el contenido1, también se incluye una recopilación de referencias bibliogra�cas (recomendadas o referidas en el
material), 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 del
Software.
VIII Índice general
Medios Adicionales
Adicionalmente 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 el
Equipo Docente en la Sede Central (en las direcciones, teléfonos y horarios indicados en la Guía de Curso). Esto se complementa
con 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 la
pá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 la
ventaja adicional de que en los medios en línea los enlaces de direcciones en Internet y otros materiales se irán ampliando y
actualizando 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én
se 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, 1998
James 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ón
La 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 sobre
aspectos relevantes del temario correspondiente, más posiblemente otra parte práctica compuesta de ejercicios con supuestos
prácticos que describirán parcialmente un problema de diseño de software sobre el cual se pedirá al alumno completar o extender
algunos aspectos relacionados con el temario correspondiente. La puntuación correspondiente a cada pregunta se especi�cará en
el enunciado. En la nota �nal se tendrá en cuenta la compensación entre preguntas dentro de un mismo examen parcial así como
la 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ón
para ayudarle a una mejor comprensión de los temas.
Capítulo 1
Contexto de la asignatura en la Ingeniería de
Software
Tutorial previo
Introducción
Al inicio de la asignatura es conveniente repasar algunos conceptos generales sobre Ingeniería de Software e introducir los
temas que se van a estudiar.
En el desarrollo de sistemas software es necesario plani�car el uso de recursos y temporizar adecuadamente las diferentes
actividades para no sobrepasar los límites económicos y de tiempo dedicados a un proyecto. Es principalmente con este objetivo
que se han ido desarrollando el conjunto de técnicas que reciben el nombre de Ingeniería del Software. Gracias a estas técnicas
el desarrollo del software se sistematiza en la medida de lo posible, de modo que el resultado sea previsiblemente aceptable, es
decir, 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 de
un producto software. Esas fases son: especi�cación, diseño, codi�cación, pruebas y mantenimiento. Para dar soporte a las
diferentes etapas, y particularmente a las etapas de análisis y diseño, se han de�nido notaciones de modelado tales como el
difundido 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 se
presentan los aspectos más generales del ciclo de vida del software y se introducen las distintas fases del desarrollo en que se
profundizará en los capítulos del bloque II (temas 2 al 6). Finalmente, se describe el lenguaje UML, de uso extendido y soportado
actualmente por varias herramientas CASE capaces de generar código a partir de los diagramas de esta notación.
Relación con otros temas
Con 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 Software
y 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 desarrollo
de 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 recomendable
haber desarrollado algún proyecto en un lenguaje de programación.
Objetivos del tema
Este 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 relaciones
con la plani�cación y gestión de proyectos informáticos. Para ello debe: comprender la necesidad de utilizar una metodología en
el desarrollo de aplicaciones, comprender las ventajas e inconvenientes de los diferentes ciclos de vida para discernir cuando es
adecuado 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 esquema
Es 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 puede
estudiar 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 ir
haciendo 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 estudio
del UML se re�ere a la primera versión del lenguaje. Hemos creído conveniente formar al alumno en esta primera versión
debido 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 a
esta guía que se publicará el primero de noviembre en la Web de la asignatura).
1.1. Necesidad de una metodología
El 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 objeto
principal 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. En
temas posteriores, en primer lugar se explicarán en detalle las mencionadas fases y a continuación las metodologías usuales que
las 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 medios
y 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. Sistemas
La Ingeniería de Sistemas es el contexto genérico en que se situan las herramientas y metodologíasusadas para crear
sistemas. Un sistema puede estar formado por subsistemas de diferentes tipos. La ingeniería de sistemas constituye el primer
paso de toda ingeniería: proporciona una visión global de un sistema en su conjunto para que, posteriormente, cada uno de sus
subsistemas 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 sistema
informático, consta de dos tipos de elementos: Hardware y Software.
1.1.2. La crisis del software
Desde 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. Estas
té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 sobre
las características generales del programa. Inmediatamente se empieza la codi�cación y simultáneamente se va
depurando. 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 proyecto
es 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 un
resultado pronto. Hoy en día es un método de desarrollo que se usa cuando hay plazos muy breves para entregar el producto �nal
y no existe una exigencia explícita por parte de la dirección de usar alguna metodología de ingeniería del software. Puede dar
resultado, 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 rebase
sus proyecciones iniciales de tiempo y dinero y que se descubran bugs (errores informáticos) en su ejecución. Esto se debe a que
todaví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ía
En 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ía
Los 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 se
mani�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ías
Existen 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 en
especi�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
Gestionar
Altas/Bajas
Gestionar
Pedidos
Gestionar
Devoluciones
Películas
Disponibles
Alta/Baja
Película
Pedido
Película
Devolución
Pelí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ón
que se incluye en él se puede ver en [Pre01, sec. 12.7].
Diagramas de transición de estados: Modelan procesos que dependen del tiempo
Diagramas entidad-relación: Los elementos del modelo E/R se corresponden con almacenes de datos en el DFD. En este
diagrama 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 la
programació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 la
anterior. 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.
4 Contexto de la asignatura en la Ingeniería de Software
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 ser
resueltas 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 focalizar
la atención en las estructuras de datos. El concepto de objetos tuvo sus orígenes en la inteligencia arti�cial como un modo de
representació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 y
concebido 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 procedimientos
o funciones) que manipulan esos datos. Los datos de�nidos dentro de un objeto son sus atributos. Un objeto sólo puede ser
manipulado 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 de
implementació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; por
ejemplo, 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 una
clase 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 de
los objetos.
1.2. Ciclo de vida del software
Al 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 se
detecta la necesidad de construir un sistema de software hasta que éste es retirado, se identi�can varias etapas que en conjunto
se 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 del
sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas
del desarrollo del software es la documentación de todos los elementos y especi�caciones en cada fase. Dado que esta tarea
siempre estará in�uida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases como
un 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 requisitos
2. 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 como
entrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida según se muestra en
la �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 se
transforman 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 los
requisitos 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étodos
pueden dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuación realizan
estas 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 cascada
El 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 el
90 % 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 de
cambiar 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, es
decir, 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. (Software
Requirements 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 las
pruebas es el producto �nal listo para entregar.
Ventajas
La plani�cación es sencilla.
6 Contexto de la asignatura en la Ingeniería de Software
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 perfectamente
de�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 de
cada una. Una fase además de utilizarse como entrada para la siguiente, sirve para validar o veri�car otras fases posteriores. Su
estructura 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, se
permite 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 necesita
generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los
problemas 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ónpueden 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. El
diseñ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 ciclo
de 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 los
problemas
1.2 Ciclo de vida del software 7
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 consecuencia
en paralelo con los demás. Cada uno tendrá seguramente fechas de terminación distintas. Una vez que han terminado todos se
integran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a más gente trabajando en paralelo de forma
e�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 necesario
tener 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 el
diseñ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 y
mantenimiento.
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 los
requisitos esto sólo se descubrirá cuando se entregue el producto. Para evitar este problema se puede hacer un desarrollo iterativo
durante 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.
8 Contexto de la asignatura en la Ingeniería de Software
1.2.2. Modelo de ciclo de vida en espiral
Propuesto 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, la
diferencia 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én
se veri�ca que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuándo
termina el proyecto y cuándo empieza la fase de mantenimiento. Cuando hay que hacer un cambio, éste puede consistir en un
nuevo 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 una
iteració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.
1.2 Ciclo de vida del software 9
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 objetos
Los 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 entre
ellos 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 de
miniproyectos. Además, hoy en día existe una tendencia a reducir los riesgos y, en este sentido, el ciclo de vida en cascada no
proporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos es
el 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 modelo
fuente.
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 y
posiblemente el más seguido. Un proyecto se divide en las fases:
1. Plani�cación del negocio
2. 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
10 Contexto de la asignatura en la Ingeniería de Software
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 sistema
2. 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 momento
cualquiera. La ventaja es que permite un desarrollo solapado e iterativo. En la �gura 1.8 se muestra un esquema de este tipo de
ciclo 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 de
producción. Dado que en la actualidad la fase de implementación se suele realizar con tecnologías orientadas a objetos, y que
adicionalmente este tipo de enfoque también es aplicable en otras fases del desarrollo, es importante que el alumno conozca al
menos los principios básicos de las notaciones orientadas a objetos, y en especial de la más extendida últimamente, la notación
UML(Uni�ed Modelling Language, Lenguaje Uni�cado de Modelado).
1.3.1. Introducción
Modelos
La construcción de todo sistema de ingeniería requiere un estudio previo que consiste en la identi�cación de sus componentes
y de las relaciones entre éstas, la comprensión de sus propiedades, y la concepción de su comportamiento dinámico. El resultado
de este estudio es un modelo o representación del sistema. Un modelo es una representación de la realidad donde se abstrae lo
no esencial. La abstracción permite gestionar la complejidad y experimentar con diferentes soluciones. Para un mismo sistema se
puede de�nir más de un modelo diferente en función del aspecto que interese destacar o el nivel de detalle deseado. El modelado
permite 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 de
desarrollo.
�UML�, siglas de Uni�ed Modeling Language es un lenguaje concebido, como su nombre indica, para expresar modelos. No
es 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 la
notación que se ha convertido en el estándar de facto de la mayor parte de las metodologías de desarrollo orientado a objetos que
existen 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 en
signi�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 lenguaje
de 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 de
esta guía.
Historia
Grady Booch, Jim Rumbaugh e Ivar Jacobson (los apodados "tres amigos") desarrollaron los tres métodos de desarrollo
orientado a objetos más seguidas de la industria. De la uni�cación del OMT (Object Modeling Technique) de Rumbaugh y el
mé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 es
un 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 se
explica cómo estos elementos se combinan para construir diferentes tipos de modelos, y se de�nen algunos elementos adicionales
que 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. Las
instancias más comunes son las instancias de clase (Objetos) y las instancias de asociación (Enlaces). Las instancias pueden
identi�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 son
las 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 Modelos
estructurales de implementación.
De comportamiento: Son, principalmente, las Acciones, los Estados, las Transiciones y los Mensajes.
Las Relaciones, se clasi�can principalmente en:
Dependencias
Asociaciones
Generalizaciones
Se distingue entre Diagramas de:
Casos de uso
Clases
Objetos
Secuencia
Colaboración
Estados
Actividades
Componentes
Despliegue
Como veremos en las seciones siguientes, los modelos de casos de uso se describen mediante diagramas de casos de uso y
diagramas 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 los
modelos 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 detalles
adicionales de la especi�cación (símbolos de visibilidad, compartimentos adicionales, notas, roles, representación de clases
y características especiales - abstracta, raíz, hoja - etc).
Mecanismos de extensión: Posibilidades de extensión controlada del lenguaje para adecuarse a aplicaciones, procesos o
dominios 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 mismo
tiempo los elementos que intervienen en los correspondientes diagramas. Hemos optado por describir estos elementos a medida
que se hace referencia a ellos por entender que en un contexto de modelado concreto se pueden entender mejor su utilidad y
signi�cado. Por lo general no distinguiremos entre los diferentes tipos de adornos o mecanismos de extensión que estos elementos
constituyen, por no considerarlo relevante en el nivel de estudio del lenguaje exigido para esta asignatura. Los símbolos grá�cos
que los denotan aparecen ilustrados en las �guras de esta sección. Las antes mencionadas reglas de combinación están implícitas
en la descripción de los diferentes diagramas.
1.3.2. Modelo de casos de uso
Representa 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, una
interacció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ón
de 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 dirigidaspor casos de uso,
de forma que es a partir de ellos que se derivan los modelos estructurales y de comportamiento. En cualquier caso, siempre es
preciso 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.
12 Contexto de la asignatura en la Ingeniería de Software
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 interaccionar
con 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 el
sistema 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 algunos
pasos a la secuencia de interacciones por él especi�cada. Cuando un caso de uso incluye a otro, signi�ca que contiene la
secuencia de interacciones por él especi�cada. Este último concepto se identi�ca con el de llamada a subrutinas: Cuando
dos o más casos de uso tienen una parte signi�cativa en común, es útil de�nir casos de uso elementales que representan las
secuencias 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 los
modelos 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 de
acciones 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 es
un paso, operación o actividad individual de un proceso, sino un proceso completo que incluye varios pasos.
1.3 Notaciones de especi�cación y diseño (UML) 13
Otro aspecto importante a tener en cuenta es la utilidad de los casos de uso en la comunicación entre analistas, desarrolladores
del software y expertos del dominio de aplicación: deben se entendibles por todos y constituir una descripción de alto nivel del
sistema 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 que
implica 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. Los
casos 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 del
sistema, y buscar después qué actores y casos de uso están relacionados con estos eventos.
1.3.3. Modelo estructural estático
Muestra 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ñadores
y 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 verse
como 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. Constituyen
el elemento básico de modelado en el paradigma de orientación a objetos. Una clase se instancia en objetos excepto cuando se
de�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 las
que 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 una
secció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 longitud
que puede contener letras, números y signos de puntuación (exceptuando � � y �::�). Aparece en cursiva en el caso de
las clases abstractas (clases que carecen de instancias). El nombre de clase puede aparecer opcionalmente precedido del
nombre del paquete en que la clase se utiliza; su sintaxis se de�ne pues, en notación BNF: [paquete::]nombre-simple.
14 Contexto de la asignatura en la Ingeniería de Software
2. Atributos: Representan propiedades características compartidas por todos los objetos de la clase. Una clase puede tener
cualquier número de atributos. Un nombre de atributo consiste en una cadena de cualquier longitud que puede contener
letras y números. Sobre ellos pueden proporcionarse diferentes informaciones:
a) Tipo: Atributo:Tipo
b) Valor inicial: Atributo:Tipo=Valor ó Atributo=Valor
c) 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 encierran
siempre 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ía
de herencia; y un atributoprivado (-) es sólo visible para la propia clase. El valor por defecto de la visibilidad es
siempre 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). Este
tipo 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 los
nombres 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ñaden
informació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 sus
estados (se adornan con query aquellas operaciones que no tienen ningún efecto secundario, esto es, que no modi�can el
estado del sistema). Al igual que en el caso de los atributos, pueden especi�carse su visibilidad, ámbito y propiedades. Se
pueden indicar también el tipo de los argumentos que reciben y el tipo del valor que retornan. Tanto si se especi�can sus
argumentos 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 se
denomina Método. La descripción de un método puede realizarse mediante una especi�cación textual descrita en cualquier
lenguaje elegido (p.e., el OCL). Al igual que existen clases abstractas existen Operaciones abstractas, esto es, operaciones
que se de�nen exclusivamente como una signatura. Las clases que contienen este tipo de operaciones requieren subclases
que 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 en
los 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 representarse
con 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 un
apartado. Los puntos suspensivos que aparecen el la �gura 1.11 al �nal de las secciones de atributos y operaciones indican que
la representación de la clase es abreviada, o lo que es lo mismo, que faltan atributos y operaciones que no se ha considerado
necesario 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í�cos
de 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 sintaxis
de 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) proporcionada
por una clase o componente, con independencia de su implementación. Pueden verse como contratos entre los clientes de la
interfaz y sus implementaciones; el programador responsable de la interfaz puede optar por implementar una nueva o bien
adquirir o reutilizar otra implementación, con tal de que el estipulado contrato se cumpla.
1.3 Notaciones de especi�cación y diseño (UML) 15
Una interfaz y la clase que la implementa están relacionadas mediante una realización (un tipo particular de relación de
dependencia), donde una clase puede realizar varias interfaces y una interfaz puede realizarse por más de una clase. Por otro
lado, una clase �cliente� puede usar varias interfaces con las que estará relacionada mediante una relación de uso (otro tipo de
relación de dependencia).
Las interfaces establecen conexiones entre los componentes de una aplicación, y representan los principios de modularidad y
ocultació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 mostrar
las operaciones. Al tratarse de un tipo particular de clases, entre las interfaces pueden darse relaciones de herencia. Todas las
operaciones 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 tiempo
de vida de dos objetos relacionados es independiente (a menos que exista una restricción asociada a la relación que indique lo
contrario).
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 puede
incluir opcionalmente un nombre que da idea de su interpretación en el dominio de la aplicación, así como otros adornos en sus
extremos 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ñar
distintos roles en distintas asociaciones).
Una indicación de Navegabilidad, propiedad del rol que consiste en la posibilidad de �ir� desde el objeto origen al objeto
destino, es decir, implica la visibilidad de los atributos del objeto destino por parte del objeto origen. Por defecto la
navegabilidad es bidireccional, En la �gura 1.17 se ilustra una asociación no bidireccional: dada una password, no se
puede 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 un
solo 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�, �tiene
un�, �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 diamante
negro.
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, la
antigua 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.
16 Contexto de la asignatura en la Ingeniería de Software
Es posible que dos clases estén relacionadas entre sí por más de una asociación o que una clase esté relacionada con muchas
clases por diferentes asociaciones. Por lo general, las asociaciones son relaciones