Temario Completo de Ingenieria de Software

ndice general
1. Contexto de la asignatura en la Ingeniera de Software

1.1. Necesidad de una metodologa . . . . . . . . . . . .
1.1.1. Sistemas . . . . . . . . . . . . . . . . . . .
1.1.2. La crisis del software . . . . . . . . . . . . .
1.1.3. Definici de metodologa . . . . . . . . . .
1.1.4. Finalidad de una metodologa . . . . . . . .
1.1.5. Taxonoma de las metodologas . . . . . . .
1.2. Ciclo de vida del software . . . . . . . . . . . . . .
1.2.1. Ciclos de vida en cascada . . . . . . . . . .
1.2.2. Modelo de ciclo de vida en espiral . . . . . .
1.2.3. Ciclos de vida orientados a objetos . . . . . .
1.3. Notaciones de especificaci y diseo (UML) . . . .
1.3.1. Introduccin . . . . . . . . . . . . . . . . .
1.3.2. Modelo de casos de uso . . . . . . . . . . .
1.3.3. Modelo estructural esttico . . . . . . . . . .
1.3.4. Modelo de comportamiento . . . . . . . . .
1.3.5. Modelo estructural de implementacin . . . .
Ejercicios y actividades . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
2
3
3
4
5
8
9
10
10
11
13
20
24
25
2. Descripcin de ejemplos gua

2.1. Ejemplo A: Aplicacin de comercio en Web . . . . . . . . . . . . . . .
2.2. Plantilla de solucin propuesta para el ejemplo A . . . . . . . . . . . .
2.3. Ejemplo B: Gestin de proceso en una fbrica de productos electrnicos
2.4. Plantilla de solucin propuesta para el ejemplo B . . . . . . . . . . . .
2.5. Ejemplo C: Agenda electrnica personal . . . . . . . . . . . . . . . . .
2.6. Plantilla de solucin propuesta para el ejemplo C . . . . . . . . . . . .
2.6.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
28
30
30
31
32
32
34
3. Fase de requisitos
3.1. Obtencin de requisitos . . . . . . . . . . .
3.1.1. Introduccin . . . . . . . . . . . .
3.1.2. Tcnicas de obtencin de requisitos
3.2. Anlisis de requisitos . . . . . . . . . . . .
3.3. Representacin de requisitos . . . . . . . .
3.4. Anlisis orientado a objetos . . . . . . . . .
3.5. Validacin de requisitos . . . . . . . . . . .
3.6. Bases de documentacin . . . . . . . . . .
Ejercicios y actividades . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
36
36
44
44
44
44
44
48
4. Fase de diseo
4.1. Conceptos y elementos del diseo .
4.2. Diseo estructurado . . . . . . . . .
4.3. Diseo orientado a objetos . . . . .
4.4. Validacin y confirmaci del diseo
4.4.1. Revisin del diseo . . . . .
4.4.2. Verificaci del diseo . . .
4.4.3. Validacin del diseo . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
50
50
50
50
50
50
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ndice general
IV
4.5. Documentacin: especificaci del diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5. Fase de implementacin
5.1. Guas de estilo de codificaci . . . . . . . . . . .
5.1.1. Traduccin del diseo a la implementacin
5.1.2. Estilo de programacin orientado a objetos
5.1.3. Normas para programadores en C . . . . .
5.1.4. Normas para programadores en C++ . . . .
5.1.5. Normas para programadores en Java . . .
5.2. Tcnicas de depuracin . . . . . . . . . . . . . . .
5.3. Documentacin del cdigo . . . . . . . . . . . . .
5.3.1. Tipos de comentarios . . . . . . . . . . . .
5.3.2. Consideraciones generales . . . . . . . . .
Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
54
54
57
59
61
67
69
69
69
70
71
6. Fases de pruebas
6.1. Verificaci y validacin a lo largo del ciclo de vida
6.2. Tcnicas y mtodos de prueba . . . . . . . . . . .
6.3. Documentacin de pruebas . . . . . . . . . . . . .
Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
7. Fase de entrega y mantenimiento

7.1. Finalizacin del proyecto . . . . . . . . . . . . . . . . . . . .
7.1.1. Aceptacin . . . . . . . . . . . . . . . . . . . . . . .
7.1.2. Informe de cierre del proyecto . . . . . . . . . . . . .
7.1.3. Indicadores del proyecto . . . . . . . . . . . . . . . .
7.2. Planificaci de revisiones y organizacin del mantenimiento .
7.3. Recopilacin y organizacin de documentacin . . . . . . . .
7.3.1. Motivos de la documentacin . . . . . . . . . . . . .
7.3.2. Directrices a seguir para la redaccin de un documento
7.3.3. Tipos de documentos . . . . . . . . . . . . . . . . . .
7.3.4. Manual de usuario . . . . . . . . . . . . . . . . . . .
7.3.5. Manual del sistema . . . . . . . . . . . . . . . . . . .
7.3.6. Manual de mantenimiento . . . . . . . . . . . . . . .
Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
. 5
. 6
. 6
. 6
. 7
. 7
. 7
. 8
. 8
. 9
. 10
. 12
. 13
Captulo 1
Contexto de la asignatura en la Ingeniera de

Software
Tutorial previo
Introduccin
Al inicio de la asignatura es conveniente repasar algunos conceptos generales sobre Ingeniera de Software y plantear la
estructura de los temas que se van a estudiar. En este captulo se muestra la utilidad de seguir una metodologa en ese desarrollo
preparando los temas siguientes. A continuacin se detallan los aspectos ms generales del ciclo de vida del software planteando
las distintas fases del desarrollo que se extendern en los siguientes captulos de la parte II (temas 3 al 7). Finalmente, se presentan
los aspectos de notacin y representacin a utilizar a lo largo de las distintas fases.
En el desarrollo de un sistema informtico del tipo que sea es necesario hacer una planificacin de cara a rentabilizar el esfuerzo. Para ello algunas empresas y universidades han desarrollado a lo largo del tiempo varias metodologas. Todas ellas tienen
en comn la intencin de automatizar el proceso de desarrollo para que el producto resultante cumpla una serie de requisitos
(tiempo de desarrollo, calidad, eficiencia, precio, mantenibilidad). Las metodologas dividen la realizacin de un proyecto en
una serie de etapas que son: especificacin, diseo, codificacin, pruebas y mantenimiento. Las distintas formas de ordenar el
esfuerzo a lo largo del tiempo son los ciclos de vida.
Por otra parte, para realizar las etapas de anlisis y diseo se han desarrollado notaciones como el UML, muy usada actualmente y soportada por varias herramientas CASE capaces de generar cdigo a partir de los diagramas de esta notacin.
Relacin con otros temas

Este tema intenta garantizar que el alumno recuerda los elementos necesarios, que debe haber adquirido en asignaturas
previas, relativos a la organizacin del desarrollo del software, para poder plantear una base comn sobre la que comenzar el
desarrollo de la asignatura. Por lo tanto se debe acudir a las asignaturas previas de la titulacin en las cuales se comienzan a
estudiar las bases de la Ingeniera del Software y el desarrollo de programas.
Al mismo tiempo este tema ser muy importante en el resto de la asignatura por su visin general de las diferentes fases y de
su coordinacin en metodologas.
Para hacerse una composicin de lugar sobre lo que se habla en este captulo y en la asignatura en general es recomendable
haber desarrollado algn proyecto en un lenguaje de programacin.
Objetivos del tema

Este tema es preparatorio para el resto de la asignatura. El alumno debe comprobar que tiene los conocimientos previos
necesarios para afrontar con garantas el resto de la asignatura, entendiendo la estructura general del desarrollo del software, as
como las implicaciones y relaciones con la planificacin y gestin de los proyectos informticos. Para ello debe: comprender la
necesidad de utilizar una metodologa 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 poder utilizar la notacin UML en la especificacin y diseo
de un sistema.
Gua de estudio y esquema

Es conveniente realizar una lectura inicial del tema para comprobar cules son los aspectos que se deben conocer en el mismo.
Posteriormente se debe acudir a repasar los conceptos previos necesarios en las referencias dadas en el apartado de extensin de
conocimientos o en las de las asignaturas previas en las cuales se hayan estudiado. El captulo tiene tres partes:
La explicacin acerca de la necesidad de una metodologa se puede considerar terica. Este apartado se incluye directamente en esta gua y, adicionalmente, se puede estudiar en el libro base [Pre01, cap. 1, y secs. 2.1 y 2.2].
Para los ciclos de vida se dan una descripcin de en qu consiste cada uno y una lista de ventajas e inconvenientes. Tambin
este apartado est en esta gua y, se puede extender el estudio en el libro base [Pre01, secs. 2.3 a 2.12].
1
Contexto de la asignatura en la Ingeniera de Software
Notaciones de especificacin y diseo (UML): La mejor forma de asimilar esta parte consiste en ir haciendo ejemplos.
En esta gua se incluye este apartado a estudiar junto con el apartado del libro base [Pre01, sec. 22.5]. Tambin puede ser
conveniente una lectura somera del captulo 20 en el mismo [Pre01, cap. 20].
1.1. Necesidad de una metodologa

El proceso de construccin del software requiere, como cualquier otra ingeniera, identificar 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 se debe realizar por un conjunto coordinado de personas simultneamente, y por lo
tanto sus esfuerzos deben estar dirigidos por una misma metodologa que permita estructurar las diferentes fases del desarrollo.
Por lo tanto, en temas posteriores, primero se explicarn en detalle esas fases y ms adelante las metodologas usuales que las
organizan y aglutinan.
En esta asignatura se har especial nfasis en los temas ms relacionados con el anlisis, diseo y mantenimiento del software,
dejando de forma ms superficial los temas especficos de la organizacin, gestin del proyecto en cuanto a la distribucin
de medios y tareas entre el grupo de personas a cargo del sistema completo, ya que estos ltimos temas son objeto de otras
asignaturas en la misma titulacin.
1.1.1. Sistemas
La Ingeniera de Sistemas es el contexto genrico en el que se pueden situar las herramientas y metodologas usadas para
crear sistemas. Un sistema puede estar formado por subsistemas de diferentes tipos. La ingeniera de sistemas es el primer paso
que se da y proporciona una visin global del sistema en su conjunto, posteriormente, se analiza cada subsistema con la rama de
la ingeniera adecuada. Una de esas ramas es la ingeniera del software.
La Ingeniera del Software trata, segn Bauer [Bau72], del establecimiento de los principios y mtodos de la ingeniera,
orientados a obtener software econmico, que sea fiable y funcione de manera eficiente sobre mquinas reales.
El sistema es un conjunto de elementos que cooperan entre s para proporcionar una funcionalidad. En el caso de un sistema
informtico hay dos tipos de elementos: Hardware y Software.
1.1.2. La crisis del software

Desde el momento en el que se introdujeron computadores con capacidad para soportar aplicaciones de tamao considerable
(aos 60) empez a ocurrir que las tcnicas de desarrollo para los hasta entonces pequeos sistemas dejaron progresivamente de
ser vlidas. Estas tcnicas consistan bsicamente en codificar y corregir (code-and-fix) que consiste en lo siguiente:
No existe necesariamente una especificacin del producto final, en su lugar se tienen algunas anotaciones sobre
las caractersticas generales del programa. Inmediatamente se empieza la codificacin y simultneamente se va
depurando. Cuando el programa cumple con las especificaciones y parece que no tiene errores se entrega.
Las ventajas son que no se gasta tiempo en planificacin, gestin de los recursos, documentacin, etc. Si el proyecto es de
un tamao muy pequeo y lo realiza una sola persona no es un mal sistema para producir un resultado pronto. Hoy en da es
un mtodo de desarrollo que se usa cuando hay plazos muy breves para entregar el producto final y no existe una exigencia
explcita por parte de la direccin de usar alguna metodologa de ingeniera del software. Puede dar resultado pero la calidad es
imprevisible. Las consecuencias fueron:
1. El costo era mucho mayor de lo originalmente previsto.
2. El tiempo de desarrollo tambin exceda lo proyectado.
3. La calidad del cdigo producido era imprevisible y en promedio baja.
Aunque se han desarrollado tcnicas para paliar estos problemas, hoy en da an se considera normal que una aplicacin rebase
sus proyecciones iniciales de tiempo y dinero y que se descubran bugs (errores informticos) en su ejecucin. Esto se debe a que
todava no se aplica de un modo sistemtico la ingeniera del software durante el desarrollo.
1.1.3. Definicin de metodologa

En la literatura sobre este tema existen muchas definiciones sobre lo que es una metodologa. Ms o menos todas ellas
coinciden en que debera tener al menos las siguientes caractersticas:
1. Define como se divide un proyecto en fases y las tareas a realizar en cada una.
2. Para cada una de las fases est especificado cules son las entradas que recibe y las salidas que produce.
3. Tienen alguna forma de gestionar el proyecto.
Teniendo esto en cuenta establecemos la siguiente definicin: Metodologa es un modo sistemtico de producir software.
1.1 Necesidad de una metodologa
1.1.4. Finalidad de una metodologa

Los atributos deseables en el producto final son:
1. Adecuacin: 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: Es la facilidad en aprender a manejar el sistema por parte de un usuario que no tiene por que ser informtico.
La resistencia de los usuarios a aceptar el nuevo sistema estar relacionada con este atributo.
4. Fiabilidad: Es la capacidad de un sistema de funcionar correctamente durante un tiempo dado. La diferencia con la
correccin es que aqu interesa el tiempo, es decir, no se trata del nmero absoluto de defectos en el sistema sino de los
que se manifiestan 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. Correccin: Densidad de defectos mnima.
6. Eficiencia: El sistema es capaz de realizar su tarea con el mnimo consumo de recursos necesario.
1.1.5. Taxonoma de las metodologas

Existen dos grupos de metodologas en funcin de la mentalidad con la que se aborda el problema: metodologa estructurada
o metodologa orientada a objetos.
Metodologa estructurada
Es la primera aproximacin al problema. Est orientada a procesos, es decir, se centra en especificar y descomponer la
funcionalidad del sistema. Se utilizan varias herramientas:
Diagramas de flujo de datos (DFD): Representan la forma en la que los datos se mueven y se transforman. Incluyen:
Procesos
Flujos de datos
Almacenes de datos
Altas/Bajas peliculas
Gestionar
Altas/Bajas
Peliculas
Disponibles
Gestionar
Pedidos
Pedido
pelicula
Gestionar
Devoluciones
Devolucion
Pelicula
Figura 1.1: Ejemplo de DFD

Los procesos individuales se pueden a su vez explosionar en otros DFD de mayor nivel de detalle.
Especificaciones de procesos: Es lo que se escribe para uno de los procesos definidos en el DFD cuando no se puede
descomponer ms. Puede hacerse en pseudocdigo, con tablas de decisin o en un lenguaje de programacin.
Diccionario de datos: Son los nombres de todos los tipos de datos y almacenes de datos junto con sus definiciones. La
informacin que se incluye en l se puede ver en [Pre01, sec. 12.7].
Diagramas de transicin de estados: Modelan procesos que dependen del tiempo
Diagramas entidad-relacin: 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 programacin tambin reflejan esta dicotoma que existe entre las metodologas; as, existen lenguajes para la
programacin estructurada. Los ms famosos son: Cobol, Fortran, C, Pascal y Modula 2.
Metodologa orientada a objetos
Es una aproximacin posterior.La orientacin a objetos al ser ms reciente cuenta con mayor nmero de adeptos y es previsible que termine sustituyendo a la anterior. Adems cuenta con una serie de ventajas:
1. Est basadas en componentes, lo que significa que es ms fcil reutilizar cdigo hecho por terceras personas.
2. Es fcil de mantener debido a que los cambios estn ms localizados.

La mentalidad que subyace al diseo estructurado es: Cmo se puede dividir el sistema en partes ms pequeas que puedan ser
resueltas por algoritmos sencillos y qu informacin se intercambian?. En el diseo orientado a objetos la idea es sin embargo:
Cules son los tipos de datos que hay que utilizar, qu caractersticas tienen y cmo se relacionan.
La orientacin a objetos supone un paradigma distinto del tradicional (no necesariamente mejor o peor) que supone focalizar
la atencin en las estructuras de datos. El concepto de objetos tuvo sus orgenes en la inteligencia artificial como un modo de
representacin del conocimiento. El primer lenguaje orientado a objetos fue Simula67, desarrollado por Kristen Nggaard y OleJohan Dahl en el centro de clculo 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 ampliacin de C para que soportara objetos, result
muy eficiente y tambin muy complejo. Java es otro lenguaje orientado a objetos derivado del C++ pero ms sencillo y con la
idea de tener menos errores.
Objetos y clases Un objeto consta de una estructura de datos y de una coleccin de mtodos (antes llamados procedimientos
o funciones) que manipulan esos datos. Los datos definidos dentro de un objeto son sus atributos. Un objeto solo puede ser
manipulado a travs de su interfaz, esto es, una coleccin de funciones que implementa y que son visibles al 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: Es una caracterstica intrnseca a los sistemas orientados a objetos. Consiste en que se ocultan los
detalles de implementacin de las clases, lo cual simplifica su manipulacin.
2. Clases: Describen abstracciones de datos y operaciones necesarias para su manipulacin. Dentro de una clase se definen:
Atributos: Es algn tipo de dato contenido en una clase.
Mtodos: Son los algoritmos internos a la clase.
3. Polimorfismo: Es la capacidad de un objeto de presentar varios comportamientos diferentes en funcin de cmo se utilice;
por ejemplo, se pueden definir varios mtodos con el mismo nombre pero diferentes argumentos.
4. Herencia: Es una relacin de generalizacin, cuando varias clases comparten caractersticas comunes, stas se ponen en
una clase antecesora.
5. Asociacin: Es una relacin entre clases que cooperan con alguna finalidad.
Durante la etapa de anlisis se identifican los objetos del dominio del problema. En el diseo se definen cules son las caractersticas de los objetos.
1.2. Ciclo de vida del software

Al igual que en otros sistemas de ingeniera, 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 este es retirado, se identifican varias etapas que en conjunto se
denominan el ciclo de vida del software y en cada caso, en funcin de cuales sean las caractersticas del proyecto, se configurar
el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificacin y anlisis de requisitos, diseo del
sistema, implementacin del software, aplicacin y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas
del desarrollo del software es la documentacin de todos los elementos y especificaciones en cada fase. Dado que esta tarea
siempre estar influida 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 a realizar en cualquier ciclo de vida son:
1. Anlisis: Construye un modelo de los requisitos
2. Diseo: A partir del modelo de anlisis se deducen las estructuras de datos, la estructura en la que descompone el sistema
y la interfaz de usuario.
3. Codificacin: Construye el sistema. La salida de esta fase es cdigo ejecutable.
4. Pruebas: Se comprueba que se cumplen criterios de correccin y calidad.
5. Mantenimiento: En esta fase, que tiene lugar despus de la entrega, se asegura que el sistema siga funcionando y adaptndose a nuevos requisitos.
Las etapas constan de tareas. La documentacin 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 segn se muestra en
la figura 1.2.
Algunos autores dividen la fase del diseo en dos partes: Diseo global o arquitectnico y diseo detallado. En el primero se
transforman los requisitos en una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su conjunto,
se esboza la documentacin y se planifica la integracin. En el detallado, para cada mdulo se refina el diseo y se definen los
requisitos del mdulo y su documentacin.
Las formas de organizar y estructurar la secuencia de ejecucin de las tareas en las diferentes fases de cada uno de los mtodos
pueden dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuacin realizan
estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.
1.2 Ciclo de vida del software
5
Entrada
Etapa
Salida
Figura 1.2: Etapa genrica
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 ingeniera. Es el primero de los propuestos y el ms ampliamente seguido por las organizaciones (se estima que el
90 % de los sistemas han sido desarrollados as). La estructura se muestra en la figura 1.3.
Analisis
Diseo
Codificacion
Pruebas
Mantenimiento
Figura 1.3: Ciclo de vida en cascada
Descripcin
Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento
se puede ver por ejemplo la necesidad de cambiar algo en el diseo, lo cual significa que se harn los cambios necesarios en la
codificacin y se tendrn que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al
mantenimiento hay que recorrer de nuevo el resto de las etapas.
Despus de cada etapa se realiza una revisin 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 especfico. Idealmente,
cada fase podra hacerla un equipo diferente gracias a la documentacin generada entre las fases. Los documentos son:
Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software
Requirements Document).
Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
Codificacin: A partir del S.D.D. produce mdulos. En esta fase se hacen tambin pruebas de unidad.
Pruebas: A partir de los mdulos probados se realizan la integracin y pruebas de todo el sistema. El resultado de las
pruebas es el producto final listo para entregar.
Ventajas
La planificacin es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco cualificado.
Inconvenientes
Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente
definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.
Si se han cometido errores en una fase es difcil volver atrs.

No se tiene el producto hasta el final, esto quiere decir que:
Si se comete un error en la fase de anlisis no lo descubrimos hasta la entrega, con el consiguiente gasto intil de
recursos.
El cliente no ver resultados hasta el final, con lo que puede impacientarse .
No se tienen indicadores fiables del progreso del trabajo (sndrome del 90 %).1
Es comparativamente ms lento que los dems y el coste es mayor tambin.
Tipos de proyectos para los que es adecuado
Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniera.
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 ms 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 consideracin el nivel de abstraccin de
cada una. Una fase adems de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores. Su
estructura est representada en la figura 1.4.
Validacion
Analisis
Nivel de
abstraccion
Diseo
Verficacion
Mantenimiento
Pruebas
Codificacion
Tiempo
Figura 1.4: Ciclo de vida en V
Ciclo de vida tipo sashimi

Segn el modelo en cascada puro una fase slo 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 diseo se comienza a implementar. El nombre
sashimi deriva del estilo de presentacin en rodajas de pescado crudo en Japn. Una ventaja de este modelo es que no necesita
generar tanta documentacin como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los
problemas planteados son:
Es an ms difcil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro.
Al hacer cosas en paralelo, si hay problemas de comunicacin pueden surgir inconsistencias.
La fase de concepto consiste en definir los objetivos del proyecto, beneficios, tipo de tecnologa y tipo de ciclo de vida. El
diseo arquitectnico es el de alto nivel, el detallado el de bajo nivel. En la figura 1.5 se ha representado la estructura del ciclo
de vida sashimi.
Ciclo de vida en cascada con subproyectos
Si, una vez que se ha llegado al diseo arquitectnico, se comprueba que el sistema se divide en varios subsistemas independientes entre s, sera razonable suponer que a partir de ese punto cada uno se puede desarrollar por separado y en consecuencia
en paralelo con los dems. Cada uno tendr seguramente fechas de terminacin 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 ms gente trabajando en paralelo de forma
eficiente. El riesgo es que existan interdependencias entre los subproyectos.
1 Consiste en creer que ya se ha completado el 90 % del trabajo, pero en realidad queda mucho ms porque el 10 % del cdigo da la mayor parte de los
problemas
7
Concepto
Analisis
Diseo arquitectonico
Diseo detallado
Codificacion
Pruebas
Figura 1.5: Ciclo de vida sashimi

Ciclo de vida en cascada incremental
En este caso se va creando el sistema aadiendo pequeas funcionalidades. Cada uno de los pequeos incrementos es comparable a las modificaciones que ocurren dentro de la fase de mantenimiento. La ventaja de este mtodo es que no es necesario
tener todos los requisitos en un principio. El inconveniente es que los errores en la deteccin 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 estn el anlisis y el
diseo global. Por otro lado estn los pequeos incrementos que se lleva a cabo en las fases de diseo detallado, codificacin y
mantenimiento.
Analisis
Diseno
preliminar
Iteracion 1
Iteracion n
Diseno
detallado
Diseno
detallado
Codificacion
y pruebas
. . . .
Mantenimiento
Codificacion
y pruebas
Mantenimiento
Figura 1.6: Cascada incremental
Ciclo de vida en cascada con reduccin 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 slo se descubrir cuando se entregue el producto. Para evitar este problema se puede hacer un desarrollo iterativo
durante las fases de anlisis y diseo global. Esto consistira en:
1. Preguntar al usuario.
2. Hacer el diseo global que se desprende del punto 1.
3. Hacer un prototipo de interfaz de usuario, hacer entrevistas con los usuarios ensendoles el prototipo y volver con ello al
punto 1 para identificar ms requisitos o corregir malentendidos.
El resto es igual al ciclo de vida en cascada.
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 diseo, errores en la implementacin, etc. Un representacin tpica de esta estructura se muestra en la figura 1.7.
Analisis de riesgos
Analisis de riesgos
Prototipo 4
Prototipo 3
Analisis de riesgos
Analisis
de riesgos
Prototipo 2
Prototipo 1
Plan del ciclo de vida

Plan de requisitos
Simulaciones, Modelos, Benchmarks

Concepto de
operacion
Requisitos Sw.
Plan de desarrollo
Diseno
Producto Sw.
Validacion de
requisitos
Codigo
Plan de integracion Verificacion y validacion

y pruebas
del diseno
Planificar fases
siguientes
Imple
mentacion
Prueba de
aceptacion
Diseno detallado
Pruebas
unitarias
Integracion
y prueba
Figura 1.7: Ciclo de vida en espiral

En cada iteracin 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
Caractersticas 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 identificados.
Resolucin de riesgos: La tcnica ms usada es la construccin de prototipos.
Resultados: Es el producto que queda despus de la resolucin de riesgos.
Planes: Lo que se va a hacer en la siguiente fase.
Compromiso: Decisiones de gestin sobre cmo continuar.
Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos; tambin
se verifica que funciona correctamente. El propio cliente evala el producto. No existe una diferencia muy clara entre cundo
termina el proyecto y cundo empieza la fase de mantenimiento. Cuando hay que hacer un cambio, ste puede consistir en un
nuevo ciclo.
Ventajas
No necesita una definicin completa de los requisitos para empezar a funcionar.
Al entregar productos desde el final de la primera iteracin es ms fcil validar los requisitos.
El riesgo en general es menor porque, si todo se hace mal, slo se ha perdido el tiempo y recursos invertidos en una
iteracin (las anteriores iteraciones estn bien).
El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.
Inconvenientes
Es difcil evaluar los riesgos.
Necesita de la participacin continua por parte del cliente.
Cuando se subcontrata hay que producir previamente una especificacin completa de lo que se necesita, y esto lleva tiempo.
Dnde es adecuado
Sistemas de gran tamao.
Proyectos donde sea importante el factor riesgo.
Cuando no sea posible definir 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 anlisis y diseo estructurados, pero el desarrollo
de sistemas orientados a objetos tiene la particularidad de estar basados en un diseado de componentes que se relacionan entre
ellos a travs de interfaces, o lo que es lo mismo, son ms modulares y por lo tanto el trabajo se puede dividir en un conjunto de
miniproyectos. Adems, hoy en da 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 tpico en una metodologa de diseo orientado a objetos es
el ciclo de vida en espiral.
En este texto slo veremos un tipo de ciclo de vida orientado a objetos, que es adems el ms 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 orientacin a objetos y
posiblemente el ms seguido. Un proyecto se divide en las fases:
1. Planificacin del negocio
2. Construccin: Es la ms importante y se divide a su vez en otras cinco actividades: Planificacin, Investigacin, Especificacin, Implementacin y Revisin.
3. Entrega o liberacin.
Madurez
Periodos
Crecimiento
Fases
Mejora 1
Planificacion
ConstruccionLiberacion
del negocio
Actividades
Planificacion
del negocio
Mejora 2
Planificacion
del negocio
Planificacion Investigacion Especificacion Implement. Revision
Figura 1.8: Ciclo de vida fuente

La primera y la tercera fase son independientes de la metodologa de desarrollo orientado a objetos. Adems 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 planifica igual que el periodo anterior, es decir,
con las fases de Planificacin del negocio, Construccin y Entrega.
Cada clase puede tener un ciclo de vida slo 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 figura 1.8 se muestra un esquema de este tipo de
ciclo de vida.
10
1.3. Notaciones de especificacin y diseo (UML)

Una parte esencial de todas las tareas del desarrollo del software, en particular de la especificacin de requisitos y del
diseo, es la utilizacin de una notacin para la descripcin de modelos que permita la mecanizacin parcial del proceso de
produccin. Dado que en la actualidad la fase de implementacin se suele realizar con tecnologas orientadas a objetos, y que
adicionalmente este tipo de enfoque tambin es aplicable en otras fases del desarrollo, es importante que el alumno conozca al
menos los principios bsicos de las notaciones orientadas a objetos, y en especial de la ms extendida ltimamente, la notacin
UML (Unified Modelling Language, Lenguaje Unificado de Modelado).
1.3.1. Introduccin
Modelos
La construccin de todo sistema de ingeniera requiere un estudio previo que consiste en la identificacin de sus componentes
y de las relaciones entre stas, la comprensin de sus propiedades, y la concepcin de su comportamiento dinmico. El resultado
de este estudio es un modelo o representacin del sistema. Un modelo es una representacin de la realidad donde se abstrae lo
no esencial. La abstraccin permite gestionar la complejidad y experimentar con diferentes soluciones. Para un mismo sistema se
puede definir ms de un modelo diferente en funcin del aspecto que interese destacar o el nivel de detalle deseado. El modelado
permite pues ver un sistema desde diferentes perspectivas, haciendo as ms sencillo su entendimiento y desarrollo. Finalmente,
los modelos juegan un papel esencial en la comunicacin con el cliente y entre los profesionales que forman parte del equipo de
desarrollo.
UML, siglas de Unified Modeling Language es un lenguaje concebido, como su nombre indica, para expresar modelos. No
es nada ms que eso, no indica cmo se deben hacer el desarrollo y ni siquiera el anlisis orientados a objetos y, en consecuencia,
no es una metodologa de desarrollo. Es importante tener bien claro que tan slo se trata de una notacin; ahora bien, es la
notacin que se ha convertido en el estndar de facto de la mayor parte de las metodologas de desarrollo orientado a objetos que
existen hoy en da.
El UML se utiliza para la especificacin, visualizacin, construccin y documentacin de sistemas software. De esta frase,
la palabra visualizacin es la ms importante; UML es un lenguaje grfico, 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 fcil de aprender pero rico en
significado, estndar, estable, configurable e independiente de lenguajes de programacin o procesos de desarrollo particulares.
Al mismo tiempo se pretendi que soportara conceptos de desarrollo de alto nivel tales como colaboraciones, armazones (frameworks), patrones y componentes, y permitiera abordar aspectos clave del desarrollo de software actual tales como escalabilidad,
concurrencia, distribucin, ejecutabilidad, etc.
El UML soporta todo el ciclo de vida del desarrollo de software y en distintas reas de aplicacin (sistemas distribuidos, tiempo real, aplicaciones monoproceso, sistemas de informacin corporativos, banca/finanzas, 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 captulo no pretende ser exhaustivo, debe entenderse ms bien como una introduccin inicial abreviada a este lenguaje
de modelado.
Historia
Grady Booch, Jim Rumbaugh e Ivar Jacobson (los apodados "tres amigos") desarrollaron los tres mtodos de desarrollo
orientado a objetos ms seguidas de la industria. De la unificacin del OMT (Object Modeling Technique) de Rumbaugh y el
mtodo de Booch naci la primera versin del UML en el ao 1994. Posteriormente, se incorporaron el mtodo OOSE (ObjectOriented Software Engineering) de Jacobson y algunos conceptos de otros lenguajes de modelado. En la actualidad el UML es
un estndar abierto del grupo OMG (Object Management Group) y se halla en su versin 2.0.
Elementos del lenguaje UML
A continuacin se presenta una clasificacin general de los elementos del lenguaje UML. En las secciones siguientes se
explica cmo estos elementos se combinan para construir diferentes tipos de modelos, y se definen algunos elementos adicionales
que intervienen especficamente en estos modelos.
En el lenguaje UML se distinguen bsicamente tres tipos de elementos:
1. Bloques de construccin: Pueden ser Entidades, Relaciones o Diagramas.
2. Mecanismos comunes: Entre ellos se distinguen Especificaciones, Adornos y Mecanismos de extensin.
3. Reglas de combinacin
Los bloques de construccin se definen como abstracciones y tienen manifestaciones concretas denominadas Instancias. Las
instancias ms comunes son las instancias de clase (Objetos) y las instancias de asociacin (Enlaces). Las instancias pueden
identificarse mediante un nombre o bien ser annimas.
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.
1.3 Notaciones de especificacin y diseo (UML)
11
De agrupamiento: Son los Paquetes. Tipos particulares de paquetes son los Modelos y los Subsistemas. Entre los modelos se distinguen Modelos de casos de uso, Modelos estructurales estticos, Modelos de comportamiento y Modelos
estructurales de implementacin.
De comportamiento: Son, principalmente, las Acciones, los Estados, las Transiciones y los Mensajes.
Las Relaciones, se clasifican principalmente en:
Dependencias
Asociaciones
Generalizaciones
Se distingue entre Diagramas de:
Casos de uso
Clases
Objetos
Secuencia
Colaboracin
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 estticos mediante diagramas de clases y de objetos, los modelos de comportamiento mediante diagramas de secuencia, diagramas de colaboracin,diagramas de estados y diagramas de actividades; y los
modelos estructurales de implementacin mediante diagramas de componentes y diagramas de despliegue.
En cuanto a los Mecanismos comunes se clasifican en:
Especificaciones: Descripciones textuales detalladas de la sintaxis y semntica de un bloque de construccin.
Adornos: Elementos grficos y textuales que pueden aadirse a la notacin grfica bsica para proporcionar detalles
adicionales de la especificacin (smbolos de visibilidad, compartimentos adicionales, notas, roles, representacin de clases
y caractersticas especiales - abstracta, raz, hoja - etc).
Mecanismos de extensin: Posibilidades de extensin controlada del lenguaje para adecuarse a aplicaciones, procesos o
dominios de aplicacin concretos. Se distingue entre Estereotipos, Valores etiquetados y Restricciones.
En las secciones siguientes explicamos los diferentes tipos de modelos que pueden definirse 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
significado. Por lo general no distinguiremos entre los diferentes tipos de adornos o mecanismos de extensin que estos elementos
constituyen, por no considerarlo relevante en el nivel de estudio del lenguaje exigido para esta asignatura. Los smbolos grficos
que los denotan aparecen ilustrados en las figuras de esta seccin, o bien en las figuras del captulo 2 (Descripcin de ejemplos
gua). Las antes mencionadas reglas de combinacin estn implcitas en la descripcin de los diferentes diagramas.
1.3.2. Modelo de casos de uso

Representa la visin que tendra del sistema un usuario externo, y es desarrollado por los analistas con la colaboracin de
los expertos del dominio de aplicacin. Un caso de uso expresa lo que comnmente se denomina una transaccin, esto es, una
interaccin entre el sistema y el usuario u otro sistema que es visto como un actor externo: p.e., un usuario que pulsa el botn
de llamada de un ascensor, o un perifrico que solicita datos de un ordenador central.
Los casos de uso sirven para especificar los requisitos funcionales del sistema e identificar los escenarios de prueba. Normalmente se utilizan en las primeras etapas de desarrollo. En particular, algunas metodologas estn 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 es
preciso asegurarse de que el modelo de casos de uso es coherente con estos modelos.
En UML los casos de uso se definen mediante diagramas de casos de uso y de secuencia, y descripciones textuales (especificaciones) que resultan de cumplimentar unas plantillas estndar.
Entidades
En los casos de uso intervienen dos entidades estructurales:
Casos de uso: Consisten en una secuencia de Acciones (unidades bsicas de comportamiento; habitualmente implementadas por una sentencia de ejecucin), y posibles variantes de estas acciones, que puede realizar el sistema al interaccionar
con los actores.
Actores: Definen un conjunto de roles que desempean los usuarios cuando interaccionan con los casos de uso.
Interviene tambin en los casos de uso una entidad de agrupamiento, el Lmite del sistema, que representa el lmite entre el
sistema fsico y los actores que con l interaccionan.
12
Relaciones
En los modelos de casos de uso pueden estar implicadas relaciones de los tres tipos principales:
Asociacin: Indica la participacin de un actor en un caso de uso (vase la figura 1.9), esto es, la comunicacin de una
instancia de un actor con instancias del caso de uso o de otro actor que interviene en el caso de uso.
Generalizacin: Muestra una taxonoma entre casos de uso o actores generales, y casos de uso o actores ms especficos.
Dependencia: Puede indicar que el comportamiento de un cierto caso de uso extiende el de un caso de uso base, cualificndose con un estereotipo extend, o bien que el comportamiento de un caso de uso incluye el de un caso de uso base,
cualificndose con un estereotipo include (vase la figura 1.10). Cuando un caso de uso extiende a otro, aade algunos
pasos a la secuencia de interacciones por l especificada. Cuando un caso de uso incluye a otro, significa que contiene la
secuencia de interacciones por l especificada. Este ltimo concepto se identifica con el de llamada a subrutinas: Cuando
dos o ms casos de uso tienen una parte significativa en comn, es til definir casos de uso elementales que representan las
secuencias repetidas.
LLamar ascensor
Figura 1.9: Asociacin entre un caso de uso y un actor
Realizar venta
pedido
Comprobar
producto
<<extend>>
<<include>>
Relizar venta
producto
Figura 1.10: Relaciones entre casos de uso
Diagramas
En la figura 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 vern en detalle en la seccin posterior Modelado de comportamiento.
Mecanismos comunes
Como especificaciones de los casos de uso se utilizan las denominadas Descripciones de casos de uso, obtenidas al cumplimentar 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 informacin contenida en estas especificaciones tiene una traduccin diagramtica en los diagramas de casos de uso y
diagramas de secuencia.
Modelado de casos de uso
Al modelar casos de uso es importante asegurarse de que cada caso definido describe una parte significativa del funcionamiento del sistema. Para evitar la definicin de un nmero excesivo de casos de uso, hay que tener presente que un caso de uso
no es un paso, operacin 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 comunicacin entre analistas, desarrolladores
del software y expertos del dominio de aplicacin: deben se entendibles por todos y constituir una descripcin de alto nivel del
sistema que no incorpore conceptos de diseo.
Para identificar casos de uso es recomendado comenzar por modelar el contexto con que habr de relacionarse, fase que
implica los siguientes pasos:
1. Identificacin de los actores que interactan con el sistema.
2. Organizacin de estos actores.
3. Especificacin de la correspondientes vas de comunicacin.
13
A continuacin, para cada uno de estos actores, habrn de identificarse 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 definicin de casos de uso sern pues:
1. Identificacin de las necesidades de los actores.
2. Designacin de estas necesidades como casos de uso.
3. Identificacin de los casos de uso que pueden ser especializaciones de otros y bsqueda de secuencias parciales comunes
en los casos de uso ya encontrados.
Un enfoque alternativo consiste en prestar inicialmente atencin a los Eventos relevantes que condicionan respuestas del
sistema, y buscar despus qu actores y casos de uso estn relacionados con estos eventos.
1.3.3. Modelo estructural esttico

Muestra una visin de la estructura interna del sistema en trminos de las entidades que lo integran y las relaciones que
existen entre ellas, capturando el vocabulario del dominio de aplicacin. Este modelo es desarrollado por analistas, diseadores
y programadores y se define mediante diagramas de clases y de objetos.
Entidades estructurales
Las entidades estructurales implicadas en un modelo estructural esttico son de tipo:
Clase : Descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.
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 aplicacin o bien de la tecnologa utilizada en su desarrollo. Constituyen
el elemento bsico de modelado en el paradigma de orientacin a objetos. Una clase se instancia en objetos excepto cuando se
define como Clase abstracta (un adorno de clase).
Las clases abstractas se utilizan en niveles altos de las jerarquas de clases para definir abstracciones muy generales de las
que derivar otras clases. En una jerarqua de clases existe una clase Raz o base sin Superclases, que da origen a la jerarqua,
y clases Hojas sin Subclases. El significado de estas jerarquas est ligado al concepto de Herencia, que se presentar en una
seccin posterior.
En la figura 1.11 se ilustran las partes de una clase, que se disponen de arriba a abajo en el orden siguiente:
Nombre de la clase
Ascensor
<<Info de identificacion>>
Estereotipo
marca:String = SYBSA
Valor por defecto
modelo:String
numeroSerie:String
<<Info de posicionamiento>>
Restriccion
pisoActual:integer
estadoActual:String
Clase abreviada
Alcance
...
Publico
+ Mover(int,int)
Protegido
# CalcularRuta(integer)
Privado
AlarmaExcesoPeso()
{estadoActual=subiendo
bajando, parado
...
Mueve gente de un piso a otro
Responsabilidades
Calcula ruta que optimiza tiempo
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, nmeros y signos de puntuacin (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 define pues, en notacin BNF: [paquete::]nombre-simple.
14
2. Atributos: Representan propiedades caractersticas compartidas por todos los objetos de la clase. Una clase puede tener
cualquier nmero de atributos. Un nombre de atributo consiste en una cadena de cualquier longitud que puede contener
letras y nmeros. Sobre ellos pueden proporcionarse diferentes informaciones:
a) Tipo: Atributo:Tipo
b) Valor inicial: Atributo:Tipo=Valor Atributo=Valor
c) Restricciones: Condiciones semnticas que pueden expresarse utilizando cualquier lenguaje, incluido el lenguaje natural, si bien UML tiene un lenguaje semi-formal asociado para expresar restricciones: el lenguaje OCL. Se encierran
siempre entre corchetes. llaves
d) Visibilidad o Alcance: Determina en qu medida otras clases pueden hacer uso del atributo. Un atributo pblico (+)
es visible para cualquier clase externa; un atributo protegido (#) es visible para cualquier descendiente en la jerarqua
de herencia; y un atributo privado (-) es slo visible para la propia clase. El valor por defecto de la visibilidad es
siempre pblico.
e) mbito: Puede ser de dos tipos:
Alcance
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 informacin es opcional, de hecho, es comn que en las especificaciones de las clases no se detallen ms 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 aaden
informacin semntica al modelo, se hacen explcitos por claridad o propsitos de diseo.
3. Operaciones: Son servicios bsicos ofrecidos por los objetos de una clase, que con frecuencia provocan cambios en sus
estados (se adornan con query aquellas operaciones que no tienen ningn efecto secundario, esto es, que no modifican el
estado del sistema). Al igual que en el caso de los atributos, pueden especificarse su visibilidad, mbito y propiedades. Se
pueden indicar tambin el tipo de los argumentos que reciben y el tipo del valor que retornan. Tanto si se especifican sus
argumentos como si no, han de aadirse un parntesis abierto y otro cerrado al final de su nombre, de acuerdo a la sintaxis: [visibilidad]nombre([parmetros])[:tipoRetorno][propiedades]. La sintaxis completa de los parmetros
es: [direccin]nombre:tipo[= valorPorDefecto]. La implementacin concreta que una clase hace de una operacin se denomina Mtodo. La descripcin de un mtodo puede realizarse mediante una especificacin textual descrita en
cualquier lenguaje elegido (p.e., el OCL). Al igual que existen clases abstractas existen Operaciones abstractas, esto es,
operaciones que se definen exclusivamente como una signatura. Las clases que contienen este tipo de operaciones requieren subclases que proporcionen mtodos para su implementacin. Las operaciones de las clases hoja de una jerarqua de
clases obligadamente habrn de tener un mtodo asociado.
4. Responsabilidades: Son descripciones de lo que hace la clase en su conjunto. Esta informacin casi nunca se incluye en
los diagramas.
5. Otras: Una clase puede incluir partes adicionales predefinidas (p.e., excepciones) o definidas por el usuario.
La informacin que se ha includo en la figura 1.11 es mucha ms de la que se suele mostrar: una clase puede representarse
con un simple rectngulo que contiene su nombre; vase la figura 1.12. Tambin es comn omitir parte de la informacin de un
apartado. Los puntos suspensivos que aparecen el la figura 1.11 al final de las secciones de atributos y operaciones indican que
la representacin 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 propsito del diagrama en cuestin.
Nombre de la clase
Figura 1.12: La representacin de clase ms sencilla posible

Las instancias de clase se denominan objetos. Los objetos se caracterizan por un estado definido por los valores especficos
de sus atributos en cada instante de tiempo.
La notacin grfica 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] (vsase la figura 1.13).
AscensorA : Ascensor
Figura 1.13: Smbolo en UML de un objeto
Interfaces Las interfaces son conjuntos de operaciones que especifican parte de la funcionalidad (un servicio) proporcionada
por una clase o componente, con independencia de su implementacin. Pueden verse como contratos entre los clientes de la
15
interfaz y sus implementaciones; el programador responsable de la interfaz puede optar por implementar una nueva o bien
adquirir o reutilizar otra implementacin, con tal de que el estipulado contrato se cumpla.
Una interfaz y la clase que la implementa estn relacionadas mediante una realizacin (un tipo particular de relacin de
dependencia), donde una clase puede realizar varias interfaces y una interfaz puede realizarse por ms de una clase. Por otro
lado, una clase cliente puede usar varias interfaces con las que estar relacionada mediante una relacin de uso (otro tipo de
relacin de dependencia).
Las interfaces establecen conexiones entre los componentes de una aplicacin, y representan los principios de modularidad y
ocultacin necesarios en diseos orientados a objetos de calidad.
En cuanto a su representacin diagramtica, las interfaces se muestran como clases sin atributos mediante dos representaciones alternativas que se muestran en la figura 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 pblicas.
Dibujable
<<Interfaz>>
Dibujable
ObjetoGrafico
ObjetoGrafico
Dibujar()
Figura 1.14: Interfaces
Relaciones
Asociacin Es una relacin conceptual, que no es inherente a la naturaleza de las clases sino al papel que juegan en el modelo.
Especifica que las instancias de una clase estn conectadas con las de otra. No se trata de una relacin fuerte, es decir, el tiempo
de vida de dos objetos relacionados es independiente (a menos que exista una restriccin asociada a la relacin que indique lo
contrario).
La representacin grfica de una asociacin (vase la figura 1.15) es bsicamente una lnea que conecta las clases, pero puede
incluir opcionalmente un nombre que da idea de su interpretacin en el dominio de la aplicacin, as como otros adornos en sus
extremos tales como:
Un tringulo relleno que indica su direccin (cuando la asociacin no es simtrica).
Un nombre de rol que cualifica el papel que juega cada una de las partes en la asociacin (una clase puede desempear
distintos roles en distintas asociaciones).
Una indicacin 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 figura 1.17 se ilustra una asociacin no bidireccional: dada una password, no se
puede acceder directamente al usuario a que pertenece (al menos en principio).
Un valor de multiplicidad que especifica por cada clase de la asociacin el nmero de objetos que se relacionan con un
solo objeto de la clase asociada.
Una Calificacin, atributo de la asociacin que permite localizar una cierta instancia cuando la multiplicidad de la asiciacin es mayor que la unidad en el extremo considerado. (vase la figura 1.18).
Un smbolo de Agregacin, que indica una asociacin de tipo todo/parte y se representa con un smbolo de diamante
(vase la figura 1.19). Sirve para modelar elementos que se relacionan utilizando expresiones como: es parte de, tiene
un, consta de, etc. Una asociacin de agregacin fuerte, donde las partes (componentes) no pueden existir independientemente del todo que las integra (entidad compuesta), se denomina (Composicin), y se denota mediante un diamante
negro.
Nombre de la relacion
Empresa
Trabaja para
Empleador
Programador
Empleado
Papel de cada parte
Figura 1.15: Ejemplo de una asociacin

En una composicin, cada componente pertenece a un todo y slo a uno (en la figura 1.19 no se cumple esto, por ejemplo, la
antigua Unin Sovitica tena una parte europea y una parte asitica). En la figura 1.20 vemos un ejemplo de este tipo de relacin.
Es posible que dos clases estn relacionadas entre s por ms de una asociacin o que una clase est relacionada con muchas
clases por diferentes asociaciones. Por lo general, las asociaciones son relaciones simtricas. Se dice que una relacin es reflexiva
cuando asocia entre s a objetos de una misma clase. La notacin con que se expresa la multiplicidad de una asociacin es diversa:
16
1. Nmeros concretos. Un nmero exacto: A. Por ejemplo: 5 (significa exactamente 5).

2. Intervalos. Entre A y B, ambos incluidos: A..B. Por ejemplo: 2..6 (es entre 2 y 6).
3. Asterisco. El smbolo * significa muchos. Si est en un intervalo se pone en el extremo superior. A..* se lee: A o ms. Por
ejemplo: 3..* (es 3 o ms). Si el * est solo significa que puede ser un nmero cualquiera, cero incluido.
4. Combinacin de los elementos anteriores: Por ejemplo: 1..4,6,9..* (que significa entre 1 y 4, 6, 9 ms de 9, es
decir, los valores 0, 5, 7 u 8 no estaran permitidos); 2,4,6 (los valores 2, 4 6 y ninguno ms).
As, en el ejemplo representado en la figura 1.16, se hacen las siguientes suposiciones:
1
matriculado en
1..*
Alumno
1..11
Asignatura
*
hace practicas con
hace proyecto con
0,1
Profesor
Figura 1.16: Relaciones entre alumnos, asignaturas y profesores
Un alumno puede estar matriculado como mnimo en una asignatura (si no est en ninguna no es alumno) y como mximo
en 11.
En una asignatura se puede matricular un nmero ilimitado de alumnos pero tiene que haber al menos un matriculado, o
de lo contrario la asignatura no existe.
Un alumno puede estar haciendo o no el proyecto fin de carrera. En caso afirmativo tendr un profesor asignado como
coordinador.
Existen asignaturas que tienen prcticas y algunas de ellas se realizan entre varios alumnos. Un alumno puede estar asociado con un nmero variable de compaeros para realizarlas, realizarlas individualmente, con un compaero, con dos,
...
Login
Password
Figura 1.17: Navegabilidad
Estudiante
1..*
Cursa
1..11
1
Estudiante
Asignatura
Cursa
N. Matricula
1..11
Asignatura
Figura 1.18: Calificacin

Asociaciones derivadas son aquellas cuyos enlaces pueden deducirse de la existencia de otros enlaces.
Generalizacin Es una relacin entre una abstraccin general y una abstraccin ms concreta. Las relaciones de generalizacin
entre clases (una superclase o clase principal y una subclase o clase secundaria) se denominan relaciones de herencia. Indica que
la subclase hereda las operaciones y atributos definidos en la superclase. Este tipo de conexin se lee como es un tipo de. En
la figura 1.21 se muestra un ejemplo de representacin.
Una clase puede tener ninguna, una (Herencia simple) o varias (Herencia mltiple) superclases. La relacin de generalizacin o herencia permite definir taxonomas de clases. En una jerarqua de herencia, las clases sin superclases se denominan clases
Raz, y las clases sin subclases se denominan clases Hoja. En las jerarquas de herencia se da el Polimorfismo, que consiste
en que un objeto de una subclase puede comportarse como un objeto de cualquiera de sus superclases en cualquier contexto
(el recproco no es cierto). As, si una operacin de la subclase tiene la misma signatura que una operacin de la superclase,
cuando se invoque la operacin de un objeto de la subclase se ejecutar el mtodo definido en la subclase y, cuando se invoque
la operacin de un objeto de la superclase, se ejecutar el mtodo de la operacin de la superclase.
17
Continente
1
1..*
Pais
Figura 1.19: Agregacin

1
Motor
Ascensor
Cable
1
1
Cabina
Figura 1.20: Composicin

Dependencia Es una relacin entre dos entidades estructurales tal que un cambio en una de ellas (la independiente) puede
afectar a la otra (la dependiente). Suele ser unidireccional y se interpreta muchas veces como una relacin de uso, entendindose
que una clase usa a otra cuando sta define el tipo de alguno de los argumentos que aparece en las signaturas de sus operaciones.
As, p.e., la especificacin de un editor grfico podra incluir una clase Objeto_Grfico y una clase Pantalla con una operacin
DibujarObjetoGrafico(o:ObjetoGrfico), tal operacin dibujara una recta, un punto, etc en funcin del objeto grfico
recibido, y se dira que la clase Pantalla usa a la clase ObjetoGrfico (vase la figura 1.22).
En UML se contemplan otros tipos de relaciones de dependencia, tales como derivacin, instanciacin, refinamiento y
realizacin. Esta ltima es una relacin semntica que se da entre clases, una de las cuales especifica un contrato que la otra se
compromete a cumplir. Sirve habitualmente para separar la definicin de un sevicio o contrato y su implementacin, y relaciona,
tpicamente, una interfaz con la clase o componente que la implementa.
Diagramas
Diagrama de clases Es el diagrama central de una especificacin UML. Describe un modelo esttico del sistema en trminos
de las entidades y relaciones descritas en las secciones anteriores (clases; interfaces; y relaciones de asociacin, herencia y
dependencia).
Ilustraremos el modelado con diagrama de clases mediante el ejemplo de una base documental, que contiene objetos de dos
tipos: libros y diccionarios. Objetos de la base documental son, por ejemplo, un ejemplar de La divina comediao un ejemplar
de la enciclopedia Espasa, que est compuesto por varios volmenes. Cada libro tiene una portada y un texto. Los libros se
pueden consultar, abrir, etc; tienen ttulo, autor y un nmero de pginas. Cada ejemplar puede haber sido editado por una editorial
en una fecha determinada. Un libro puede haber sido traducido a varios idiomas y ser citado en algunos diccionarios, los cuales
pueden ser de tipo multivolumen. Los tipos de libros que existen son: con anexo o hipermedia. Los de tipo hipermedia pueden
tener sonido o enlaces. En la figura 1.23 vemos cmo se puede representar esta especificacin en un diagrama de clases.
Diagrama de objetos Este diagrama permite modelar una instantnea del sistema en un momento dado de su funcionamiento.
Ntese que, no obstante, describe un modelo estructural esttico, ya que no incluye informacin alguna sobre evolucin temporal.
Profesor
P.Asociado
P.Ayudante
P.Interino
P.Titular
Catedratico
T.Completo
T.Parcial
Figura 1.21: Herencia; los nombres de las clases abstractas se escriben en cursiva
18
Pantalla
ObjetoGrafico
DibujarObjeto
Figura 1.22: Dependencias

Fecha
Libro
Portada
1..1
Titulo
Autor
Paginas
Ver
Idioma
Texto
1..1
Ver
*
referencia a
Libro con anexo
Consultar
Abrir
Leer
Cerrar
1..1
1..1
> traducido en
> citado en
Libro
traducido
Diccionario
Libro hipermedia
Leer pagina
*
Diccionario
multivolumen
1..1
1 . . 1000
Anexo
video
CDROM
Anexo
Editorial
Anexo
Sonido
Enlace
Contenido
Pagina
destino
Escuchar
Volumen
Rango (AZ)
Activar
hiperenlace
Figura 1.23: Ejemplo de un diagrama de clases; tomado de http://do.ole.com/personal6/biblioteconomie/articulos/

art8.html
Contiene principalmente objetos y enlaces que ligan estos objetos (esto es, instancias de clases y relaciones definidas en los
diagramas de clases). Los objetos pueden aparecer agrupados en paquetes. En los diagramas de clases tambin es posible mostrar
objetos que son instancias de las clases definidas, siempre que se considere relevante para el propsito de la representacin; por
esta razn, los diagramas de objetos pueden verse como diagramas de clases que no contienen clases. En el ejemplo de la figura
1.24, se ilustra la notacin 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. Tambin pueden mostrarse opcionalmente los atributos, con su correspondientes valores, en caso de considerarse relevantes.
3. Al igual que las clases, los objetos pueden estereotiparse.
Mecanismos comunes
En los modelos estructurales estticos suele utilizarse todo tipo de mecanismos comunes del UML. Algunos de ellos han
sido mencionados en las secciones anteriores, donde se ha explicado cmo se aaden a las notaciones bsicas de los bloques de
construccin para enriquecer la representacin (smbolos de visibilidad, estereotipos, etc) Definimos brevemente a continuacin
el sentido preciso de los dos ms comnmente utilizados:
Estereotipos. Suponen una extensin del metamodelo del UML, esto es, del conjunto de conceptos (metaconceptos) predefinidos (tales como clase, atributo, caso de uso, etc.) en trminos de los cuales se definen los modelos. Definir un nuevo
estereotipo supone aadir un nuevo concepto por herencia, de modo que constituya un caso particular de algn concepto
19
: Motor
miCoche : Coche
matricula = WWW 1234
modelo = Citroen ZX 1.9 D
color = verde
: AsientoDelantero
: AsientoDelantero
: AsientoTrasero
: Carroceria
: Salpicadero
Figura 1.24: Diagrama de objetos

ya definido. Est aceptado asimismo definir nuevas notaciones grficas para representar los nuevos conceptos (es el caso
del smbolo de actor, que representa una clase estereotipada como actor.
Notas Anotaciones escritas habitualmente de modo informal, a modo de texto explicativo ligado a algn elemento. Se
representan en la forma indicada en la figura 1.26.
Entidades de agrupamiento
En los modelos estructurales, los Paquetes agrupan clases vinculadas por alguna relacin (su representacin se ilustra en la
figura 1.25). En cuanto a los Subsistemas, agrupan paquetes que participan en un comportamiento, desde una visin de alto nivel
del sistema.
AWT
Button
Canvas
Label
Checkbox
Figura 1.25: Paquete inluido en las libreras estndar de Java para la implementacin de interfaces grficos
Ascensor
No se tiene en cuenta
el coeficiente de seguridad
del cable
Figura 1.26: Nota relativa a una clase
Modelado estructural
Los modelos estructurales son tiles tanto cuando anlisis y diseo 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 estructural
ser especificar la estructura de alto nivel del sistema, para lo que se utilizarn clases con significado arquitectural y entidades de
agrupamiento para gestionar la complejidad (paquetes y subsistemas). En el segundo caso, se tratar de especificar la estructura
de bajo nivel, que se ir refinando a medida que progrese el desarrollo (aadiendo detalles, reclasificando, definiendo nuevas
relaciones, etc.).
Para comenzar un desarrollo especificando el modelo estructural esttico es preciso conocer bien el dominio de aplicacin.
De otro modo, ser ms adecuado utilizar, p.e., un mtodo dirigido por casos de uso, y el modelo estructural habr de definirse
en coherencia con los casos de uso o colaboraciones ya especificados.
Un buen modelo estructural debe constituir un esqueleto extensible y refinable a medida que se profundiza en el conocimiento del dominio de aplicacin. En las primeras fases de definicin siempre es preferible limitarse a utilizar las notaciones
20
ms bsicas, dejando las ms avanzadas para aadir detalles en fases posteriores. En particular, es importante evitar limitar los
modelos iniciales aadiendo aspectos propios de fases de implementacin. Tambin debe evitarse mezclar en un mismo diagrama
entidades descritas en niveles de abstraccin diferentes. Finalmente, constutiye tambin una buena prctica organizar las clases
en paquetes cuando empiezan a resultar numerosas.
1.3.4. Modelo de comportamiento

Un modelo de comportamiento describe la evolucin del estado del sistema y las interacciones que tienen lugar entre sus
elementos. Se expresa mediante diagramas de interaccin (de dos tipos: diagramas de colaboracin y diagramas de secuencias),
diagramas de estado y diagramas de actividad. Entre las entidades de comportamiento, las principales entidades implicadas en
los diagramas de interaccin son los mensajes, mientras que en los diagramas de estado y actividad las entidades protagonistas
son los estados, las transiciones y las acciones. Los cuatro tipos de diagramas de comportamiento pueden implicar asimismo
diferentes entidades estructurales, y los diagramas de colaboracin exhiben, adicionalmente, asociaciones.
Diagramas de interaccin
Un Mensaje es la especificacin de un conjunto de Estmulos comunicados entre instancias de clase, de componente o de
caso de uso, junto con la especificacin de las correspondientes clases, componentes o casos de uso emisores y receptores, del
mensaje previo que los induce y de los subsecuentes procesos desencadenados (nuevos mensajes y acciones).
Los estmulos pueden ser Seales, entendidas como informaciones de datos o de control comunicadas entre instancias, o
invocaciones de operaciones. Una Interaccin es un conjunto de estmulos, intercambiados entre un grupo de instanscias (de
clases, componentes o casos de uso), en un contexto dado, y con un determinado propsito. Se entiende que dos instancias slo
podrn intercambiar estmulos cuando estn ligadas por algn enlace.
Un Evento es una ocurrencia significativa para una instancia; en el contexto de los diagramas de interaccin son, principalmente, Recepciones de estmulos y Satisfaccin de condiciones.
En un diagrama de interaccin figuran:
Instancias (de clases, de componentes o de casos de uso). Entidades con identidad nica a las que se puede aplicar un
conjunto de operaciones, que tienen un estado y almacenan los efectos de estas operaciones.
Acciones. Existen acciones predefinidas (p.e.: CreateAction, CallAction, DestroyAction, UninterpretedAction...), y acciones definidas por el desarrollador.
Estmulos. Las invocaciones de operaciones pueden ser de dos tipos
Sncronas: las instancias en comunicacin tienen que estar sincronizadas, esto es, la instancia que invoca se queda
bloqueada hasta recibir una respuesta.
Asncronas: las instancias en comunicacin no tienen que estar sincronizadas
Las seales siempre son asncronas. Existen algunos tipos caractersticos de seales:
Retorno de invocacin sncrona.

Retorno de invocacin asncrona.
Creacin de instancia.
Destruccin de instancia.
Operaciones. Servicios que pueden solicitarse de las instancias

Como ya hemos mencionado, existen dos tipos de diagramas de interaccin: los diagramas de secuencias y los disgramas de
colaboracin. Adems de los elementos antes listados, en los diagramas de colaboracin pueden figurar explcitamente enlaces
que 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 la
que ocurren (lo que comnmente se denomina escenario en el contexto del software de comunicaciones). Las instancias pueden
ser de clases y tambin de componentes y de casos de uso. Los tres tipos de instancias se ven como objetos nicos, a efectos de
estos modelos. Sirven para documentar el diseo, y especificar y validar los casos de uso. Gracias a estos diagramas se pueden
identificar los cuellos de botella del sistema, reflexionando sobre los tiempos que consumen los mtodos invocados.
En un diagrama de secuencias figuran, adems de los elementos bsicos de un diagrama de interaccin antes presentados:
1. Lnea de vida de un objeto: Es una representacin de la actividad del objeto durante el tiempo en que se desarrolla el
escenario. Se entiende que la dimensin temporal crece de arriba a abajo de la lnea. Se representa con una cabecera en
forma de rectngulo, que incluye el nombre del objeto y una lnea vertical de puntos por debajo. Durante el tiempo en que
la instancia est ejecutando un mtodo, la lnea de puntos se convierte en un rectngulo.
2. Activacin: Punto en que un objeto pasa a tener un mtodo en ejecucin, bien por autoinvocacin de la correspondiente
operacin, bien por invocacin procedente de otro objeto.
3. Tiempo de transicin: Es el tiempo que transcurre entre dos mensajes.
21
obj 1: Clase A
obj 2: Clase B
obj 3: Clase C
[X] msg
[no X] msg
Figura 1.27: Diagrama de secuencias; condicionales

4. Condicional: Representa alternativas de ejecucin o hilos de ejecucin (procesos ligeros) paralelos. Indica que un mensaje
slo se enva si una condicin se satisface. La condicin se escribe entre corchetes y puede referenciar a otro objeto (ver
figura 1.27).
5. Iteracin: Indica una accin que se repite mientras se satisfaga una cierta condicin. Se denota con el smbolo * previo a
la condicin (ver figura 1.28).
:Agenda
:Lista
*[hayMasElementos()]siguiente():Elemento
Figura 1.28: Diagrama de secuencias; iteracin

6. Invocacin recursiva: Se representa superponiendo un rectngulo al que representa al mtodo desde el que se activ (ver
figura 1.29).
obj1:Clase 1
obj2:Clase 1
obj3:Clase 2
mensaje 1
mensaje 2
create
mensaje self
obj4:Clase 3
destroy
Figura 1.29: Diagrama de secuencias; invocacin recursiva y destruccin de objetos

Ntese que, en los diagramas de secuencias, los estmulos se denotan mediante flechas horizontales trazadas desde la lnea de
vida del objeto que los enva hasta la del objeto que los recibe. En cuanto a las seales de creacin y destruccin de objetos, la
creacin se representa mediante un mensaje de creacin que termina en la cabecera de una lnea de vida (la de la nueva instancia
creada), mientras que la destruccin se representa mediante un aspa que figura al final de la lnea de vida del objeto destruido
(vase la figura 1.29).
Diagrama de colaboracin Muestran las interacciones que tiene lugar entre los objetos, organizadas en trminos de los objetos
y de los enlaces que los conectan (vase el ejemplo de la figura 1.30). Proporcionan una visin de la secuencia de interacciones
alternativa de la proporcionada por los diagramas de secuencia. Para cada diagrama de colaboracin existe un diagrama de
secuencias equivalente (se puede generar de un modo automtico un tipo de diagrama a partir del otro).
Diagrama de estados
La evolucin de un sistema a lo largo del tiempo puede modelarse como la transicin entre una serie de estados de un
autmata o mquina de estados. Los diagramas de estados del UML representan el comportamiento de las instancias de clases,
22

jugar()
1:r1:=lanzar()
Jugador
d1:Dado
2:r2:=lanzar()
d2:Dado
Figura 1.30: Diagrama de colaboracin

componentes o casos de uso, como mquinas de estados extendidas que constan siempre de un estado inicial y un estado final. A
cada estado se asignan:
Nombre.
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 de
acciones, parmetros y condiciones que habilitan o no la transicin.
Un estado puede, alternativamente, expandirse en una mquina de estados representable a su vez mediante un diagrama de
estados. Las mquinas de estado representadas por los diagramas de estados soportan concurrencia: esta se representa mediante
un estado compuesto que se expande en un diagrama con ms de un estado de inicio y un nico estado final.
El estado de un sistema en un instante dado resume la historia de eventos pasados. Por ejemplo, imaginemos un ascensor
que en cuanto llega al stano (rea restringida a la que slo se puede acceder con llave) sube a los pocos segundos por s mismo
para evitar que posibles intrusos puedan acceder a las viviendas. Por otra parte el ascensor puede estar subiendo, bajando o
parado. Cuando est bajando al stano se le considera en un cierto estado y, cuando est en el stano, en otro estado diferente. El
comportamiento del ascensor aparece representado mediante un diagrama de estados UML en la figura 1.31.
llegar
bajar
Bajando
Parado
Subiendo
llegar
subir
bajar_stano
timeout
Stano
llegar
Bajando al
stano
Figura 1.31: Diagrama de estados para un ascensor
Diagrama de actividades Representan asimismo un caso particular de mquinas de estado donde las transiciones entre estados
no son motivadas por eventos externos, sino que tienen lugar espontneamente cuando concluyen las actividades a ellos asociadas.
Modelan el comportamiento del sistema haciendo nfasis en la participacin de los objetos en ese comportamiento. Se centran en
mostrar el flujo de control y datos entre objetos y su comportamiento interno (las acciones que conllevan sus operaciones y cmo
se ven afectados por ellas), en lugar de mostrar su respuesta a eventos. Las mquinas de estado representadas por los diagramas
de actividades soportan tambin concurrencia.
Para disearlos se sugiere seguir la siguiente estrategia:
1. Identificar una clase que participa en el comportamiento que se desea modelar, cuyas actividades de proceso deban ser
especificadas.
2. Identificar las distintas actividades cuyo modelado es de inters.
3. Identificar estados, flujos y objetos.
Este tipo de diagrama es til para modelar el flujo de trabajo de un negocio a alto nivel (vase el ejemplo de la figura 1.32).
Los diagramas de actividades constan de los siguientes elementos:
1. Punto inicial. Representa el estado inicial. Se denota mediante un crculo negro.
2. Punto final. Representa el estado diana. Se denota mediante un crculo negro rodeado exteriormente por otro crculo.
3. Actividades. Estados de actividad donde se ejecutan conjuntos de acciones que pueden describir parcial o totalmente una
operacin de clase o acciones de usuario. Un estado de actividad puede expandirse en un nuevo diagrama de actividades
que suponen una descomposicin funcional de la actividad principal. Se simbolizan mediante rectngulos con bordes
redondeados.
4. Transiciones. Suponen el paso de una actividad a otra. Se representan mediante flechas.
5. Actividades concurrentes. Se representan mediante sus correspondientes actividades y una barra negra de la que parten
las transiciones que las inician.
23
Ducha
Desayuno
Ver tele
Cerrar puerta
Esperar 30 segundos
[Deportista]
Ir andando
[Sedentario]
Pulsar apertura
garaje
Abrir puerta
Abrir puerta
Abrir puerta
Conducir
Figura 1.32: Diagrama de actividades; concurrencia, bifurcacin e indicacin

6. Bifurcaciones: Se representan mediante un rombo o sencillamente mediante dos flechas que parten de una actividad hacia
otras dos. En cualquier caso, la condicin se expresa en cada uno de los ramales entre corchetes.
7. Indicaciones: Representan eventos que pueden enviarse o recibirse. El envo se denota mediante un rectngulo acabado en
flecha, y la recepcin mediante la figura complementaria.
En los diagramas de actividades el flujo de control y el flujo de objetos no aparecen separados: ambos se modelan como transiciones de estados. Es aconsejable definir diagramas bien anidados y asegurar que habr una mquina de estados correspondiente
a cada actividad ejecutable, as como evitar el go to en la medida de lo posible.
Modelado del comportamiento
Los diagramas de interaccin habrn de utilizarse principalmente cuando haya inters en conocer cmo se comportan las
instancias implicadas en un caso de uso, en definitiva, cmo interaccionan unas con otras y cmo se reparten las responsabilidades
(cmo atienden los requisitos). Sirven para identificar las interfaces de las clases. Un buen diagrama de interaccin habr de
incluir indicaciones sobre el contexto de la interaccin (mediante especificaciones textuales).
Los diagramas de secuencia permitirn ilustrar escenarios tpicos, mostrando el orden explcito de los estmulos, por lo que
resultarn muy adecuados para el modelado del tiempo real. El flujo deber presentarse de izquierda a derecha y de arriba a abajo.
Los diagramas de colaboracin muestran cmo se coordinan las entidades en la estructura del sistema y cmo el control
pasa de unas instancias a otras. Al hacer explcitas las relaciones entre instancias, ayudan a realizar su agrupacin en mdulos.
Permiten asimismo concentrarse en los efectos de la ejecucin sobre las diferentes instancias.
Los diagramas de estado sern tiles para mostrar el comportamiento de una nica instancia dentro de un caso de uso. Permiten capturar el comportamiento dinmico de sistemas de cierta complejidad, resultando particularmente adecuados para el
modelado de sistemas reactivos orientados a eventos (p.e., interfaces de usuario, dispositivos hardware o protocolos de comunicacin).
Los diagramas de actividad permitirn observar el comportamiento a travs de varios casos de uso o muchos hilos de ejecucin. Sern particularmente tiles en aplicaciones que requieran modelos de flujo de control o de flujo de datos/objetos (p.e.,
modelos de procesos de negocios), en lugar de modelos dirigidos por eventos. En estos casos, el comportamiento no depende
mucho de eventos externos, los pasos se ejecutarn de principio a fin sin ser interrumpidos, y entre pasos se producirn flujos de
objetos/datos. Estos diagramas se construirn normalmente durante el anlisis para estudiar qu actividades ocurren, en lugar de
qu objetos son responsables de ellas (posteriormente se podrn usar Particiones para asignar esas responsabilidades).
24
1.3.5. Modelo estructural de implementacin

El modelo estructural de implementacin muestra los aspectos de implementacin de un sistema: la estructura del cdigo
fuente y objeto, y la estructura de la implementacin en ejecucin. En UML se utilizan dos tipos de diagramas para expresar estos
modelos: los diagramas de componentes y los diagramas de despliegue. Las principales entidades implicadas en los primeros son
componentes y, en los segundos, componentes y nodos.
Un Componente se define como una parte modular, reemplazable y significativa del sistema que empaqueta una implementacin y expone una interfaz. Un Nodo designa un objeto fsico de ejecucin que representa un recurso computacional.
Diagrama de componentes
Modelan una visin esttica del sistema en el nivel de implementacin. Ilustran la organizacin y las dependencias entre
componentes software. Los componentes pueden ser cdigo fuente (clases de implementacin,una implementacin de una interfaz, ficheros de scripts...) binarios, ejecutables, tablas, o cualquier otro tipo de elemento que forme parte de la implementacin
de sistema o de su documentacin. En un diagrama de componentes no necesariamente estarn presentes todos los componentes.
En la figura 1.33) se muestra cmo un componente implementa una interfaz.
Componente
Interface
Figura 1.33: Diagrama de componentes

El estndar de UML define cinco estereotipos para caracterizar tipos de componentes: executable, library, table, file y document.
Ejecutables Estos componentes se modelan siguiendo los siguientes pasos (vase el ejemplo de la figura 1.34):
<<executable>>
Agenda.exe
<<library>>
listas.dll
Figura 1.34: Ejecutable que usa una librera de manipulacin de listas
1. Se identifican los componentes y posibles particiones del sistema en susbsistemas, determinndose cules son susceptibles
de ser reutilizados, se agrupan por nodos y se realiza un diagrama por cada nodo que se desee modelar.
2. Se identifica cada componente con su correspondiente estereotipo.
3. Se relacionan los componentes entre s.
Cdigo fuente Modelar estos componentes es til para expresar las dependencias que existen entre los mdulos, con vistas a
componer libreras o programas ejecutables (vase el ejemplo en la figura 1.35).
<<file>>
A.h
<<file>>
B.h
<<file>>
Agenda.h
<<file>>
Agenda.exe
Figura 1.35: Dependencias entre el cdigo
25
Diagrama de despliegue
Este diagrama refleja la organizacin del hardware. Su entidad central es el nodo. Los nodos pueden o no tener capacidad
para ejecutar componentes. Un nodo lleva asociado un nombre y un conjunto de componentes (que pueden representarse slo
mediante sus nombres o bien mediante un diagrama de componentes). Cada nodo puede estar fsicamente conectado a otros
nodos. La utilidad principal de este tipo de diagramas es la modelizacin de redes (vase el ejemplo de la figura 1.36).
Servidor
BD
Oracle
Cliente
Palencia
Ap. Ventas
Cliente
Madrid
Cliente
Barcelona
Ap. Ventas
Ap. Ventas
Figura 1.36: Diagrama de distribucin
Tutorial posterior
Resumen de contenidos
ste es el captulo introductorio donde se aborda cmo es la divisin en fases de un proyecto (ciclos de vida), las caractersticas de las metodologas que ordenan esas fases y una notacin muy habitual actualmente que se utiliza a lo largo de todo el ciclo
de vida de un proyecto.
1. Metodologas: Es una justificacin del porqu de la ingeniera del software. Se define lo que se entiende por sistema y
por metodologa (una forma podra decirse burocrtica de producir un sistema con costes y tiempos controlados). Se
establece tambin una clasificacin de las metodologas que, al igual que como se ver con los ciclos de vida, pertenecen
a dos tipos principales: estructurada y orientada 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 la que se ordenan estas
fases. Hay una clasificacin de los distintos ciclos de vida que se pueden dar en un proyecto. Bsicamente, hay dos tipos
principales que son: el ciclo de vida en cascada (el ms antiguo y preferido en la metodologa estructurada) y el ciclo de
vida en espiral (el ms nuevo, preferido en la metodologa orientada a objetos) que se dividen a su vez en varios subtipos
para cumplir diferente propsitos. Los ciclos de vida son:
a) Ciclo de vida en cascada. Subtipos: ciclo de vida en V, Sashimi, cascada con subproyectos, cascada incremental y
cascada con reduccin de riesgos.
b) Ciclo de vida en espiral. Subtipos: Fuente y adems los subtipos cascada incremental y cascada con reduccin de
riesgos que tambin se pueden considerar como ciclos de vida en espiral.
c) Notaciones de especificacin y diseo (UML): Se da una introduccin breve a la notacin UML. Existen libros muy
completos al respecto, aqu solo se dan nociones bsicas para comprender un diagrama. El motivo de explicarlo en
este tema es que se trata de una notacin que se puede seguir a lo largo de todas las fases del ciclo de vida.
Ejercicios y actividades propuestas

1. Qu ciclos de vida elegira para cada una de estas aplicaciones?
Desarrollar una biblioteca de clculo numrico para hacer operaciones con matrices de gran tamao.
Desarrollar una agenda electrnica para guardar telfonos, direcciones, etc. Es ms que posible que se quiera ampliar.
2. Cmo representara la siguiente descripcin en UML?:
Una casa est en una ciudad, las casas pueden estar en un edificio y varios edificios forman una manzana. Hay casas que
son chals y los chals pueden estar solos o adosados. Los chals y los edificios estn en una calle, dentro de la cual tienen
un nmero asignado, por otra parte, las casas que forman parte de edificios tienen un nmero que indica el piso y una
letra. Una casa pertenece a una calle. Una zona es un conjunto de calles y cada una es conocida por un cdigo postal. Un
conjunto de zonas es una ciudad, que tiene un nombre y pertenece a una provincia, la cual a su vez pertenece a un pas, el
26
3.
4.
5.
6.
cual est en un continente o como mucho en dos (p. ej Rusia). En una casa viven personas y el nmero de personas que
viven en una casa puede ser cualquier nmero. Una persona puede vivir en ms de una casa (por ejemplo, durante el verano
en una y en el invierno en otra). Una casa es poseda por una o varias personas.
Represente la siguiente situacin en UML:
Una persona pertenece a tres posibles grupos: Estudiante, Trabajador o Jubilado. Un trabajador puede tener empleo o no
y puede cambiar entre cualquiera de estos casos siendo despedido si est trabajando o siendo contratado si est parado.
Cuando llega a los 65 aos 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).
En el ejercicio anterior con los tres grupos de personas, Cmo representara en un diagrama de clases a un estudiante que
trabaja al mismo tiempo?
Represente la siguiente descripcin en UML:
Un paracaidista se tira desde un avin, momento a partir del cual est cayendo deprisa. Pueden pasar dos cosas: el paracadas se abre o no se abre. Si no se abre existe un segundo paracadas 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 de
cayendo despacio. Se puede estar cayendo deprisa un mximo de 30 segundos y cayendo despacio un tiempo que oscila
entre 0 y 5 minutos en funcin del momento en el que se abra uno de los paracadas. Al final el paracaidista llega al suelo.
Represente esta situacin 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 existe
ninguna instancia de C. En caso contrario no hace nada, es decir, slo puede existir una instancia de C. En cualquier caso
devuelve a A una referencia al objeto C, entonces A invoca una funcin de C, tras lo cual A imprime un mensaje y se
autodestruye.
Extensin de conocimientos
Este tema tambin 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 especficos de asignaturas previas o simultneas sobre Ingeniera del Software,
por ejemplo en [Hum95] [Hum01].
La revista en lnea Software Development http://www.sdmagazine.com/, puede ser una buena fuente para encontrar
artculos (en ingls) sobre temas de IS en general. Dentro de The Collection of Computer Science Bibliographies. Tambin
puede ser interesante la gua al SWEBOK (Software Engineering Body of Knowledge) en http://www.swebok.org/ que es una
iniciativa conjunta del IEEE y la ACM para expresar el conjunto de conocimientos bsicos en Ingeniera del Software.
Sobre el lenguaje UML se pueden extender conocimientos en varios libros especficos del tema como [JBR00a, JBR00b,
Fow97] [Sch01b], o bien a travs de las pginas de Internet: http://www.omg.org/technology/uml/ del Object Managenemt Group (OMG).
Hay una herramienta de libre distribucin para la representacin mediante diversos mtodos (incluido UML) en http:
//wwwhome.cs.utwente.nl/~tcm/ llamada TCM (Toolkit for Conceptual Modeling). En http://argouml.tigris.org/ se
puede encontrar A RGO UML que es una herramienta libre (implementada en Java y licencia BSD) especfica para la representacin en UML. Tambin se puede encontrar informacin en http://uml.sourceforge.net/index.php sobre el programa 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.
Captulo 2
Descripcin de ejemplos gua

Tutorial previo
Introduccin
Un forma de facilitar la comprensin de las diferentes fases en el desarrollo del software es utilizar ejemplos. Por este motivo
en este captulo se describirn unos problemas supuestos, cuya solucin progresiva se podr ir utilizando en los temas 3 al 7
para ilustrar cada una de las fases y ayudar al alumno a focalizar las ideas en ejemplos concretos. Para que estos ejemplos sean
efectivos el problema debe ser fcilmente reconocible por los alumnos (para que no se pierdan en el dominio del problema y se
puedan centrar en el desarrollo de la solucin...) y sencillo, aunque no demasiado simple (como un mundo de bloques o similar)
para que tenga suficiente riqueza de detalles que fijen los diferentes elementos del desarrollo del software.
Estos ejemplos son una descripcin ms precisa de lo que un usuario suele ser capaz de proporcionar. Aunque en algn caso
se haya dejado incompleta la descripcin a propsito, para poder utilizar el ejemplo en las fases de especificacin. No es normal
tener tan claros los requisitos de una aplicacin desde el principio, por tanto, el lector no debe creer que esto es lo que se va a
encontrar cuando tenga que construir una aplicacin, esto es la descripcin en lenguaje natural de lo que se puede deducir despus
de las correspondientes entrevistas, cuestionarios, sesiones JAD, etc. Por otra parte, los enunciados han sido simplificados, de
modo que sean tratables en un texto de este tamao, lo cual quiere decir que no son reales, aunque si realistas.

Este tema est dedicado exclusivamente a preparar los ejemplos que se podrn utilizar como ilustracin en los temas 3 al 7
al explicar las fases de desarrollo. Eventualmente podran utilizarse como ejemplos prcticos en la aplicacin de alguna de las
metodologas planteadas en el tema 8 para las herramientas del tema 9.
Objetivos del tema

En este captulo el alumno debe entender los problemas planteados para hacerse una idea clara, posteriormente, de cules son
los pasos que se dan para resolverlos.

Tras el estudio del contenido del tema, con especial nfasis en los apartados de descripcin y muy ligeramente en las plantillas
de solucin propuestas (su contenido quedar ms claro en los siguientes temas), es conveniente que el alumno haga el esfuerzo
de imaginar que l es el cliente que desea una aplicacin para ese problema, y plantear as cules pueden ser sus exigencias. Todo
el material para el estudio de este tema est incluido directamente en esta gua didctica.
Aplicacin de comercio en Web: Descripcin y plantilla propuesta.
Gestin de proceso en una fbrica de productos electrnicos: Descripcin y plantilla propuesta.
Agenda electrnica personal: Descripcin y plantilla propuesta.
2.1. Ejemplo A: Aplicacin de comercio en Web

En primer lugar se plantea un caso muy actual por la utilizacin comercial de Internet. Se trata de una aplicacin de compra/venta por Internet para una tienda o almacn de productos diversos. Bsicamente se desea poder controlar los pedidos realizados por Internet mediante pginas en HTML estndar. El comercio ya dispone en la actualidad de un servidor de HTTP
instalado propio que utiliza solamente para hacer publicidad de la empresa, se desea extender su uso a la gestin de pedidos
desde Internet en conexin con el resto de aplicaciones de gestin normales de la tienda. Se desea aadir al servidor una pgina
web con productos ofertados y demandados (por mayoristas). Esto supone focalizar el problema en una parte del software de la
gestin comercial de la empresa para simplificar el problema, pero por otro lado aporta suficientes dificultades que se han de ir
desentraando en cada una de las fases del desarrollo.
27
28
Uno de los requisitos de la aplicacin es que sea segura, es decir, que no puedan existir terceras personas escuchando, para
ello se puede utilizar el protocolo https. La aplicacin tiene dos partes:
Oferta
1. Cada producto tiene: Foto, descripcin, Cdigo, PVP.
2. Ofertas (p. ej.: Lleve dos y pague tres, etc): Las ofertas son diferentes en funcin de que el cliente sea una persona o una
empresa, y tambin dependiendo de si es o no un buen cliente, por tanto hay que guardar toda la informacin relativa a
cada venta.
3. Forma de hacer pedidos: Se rellena un formulario. Si es la primera vez que se hace el pedido, el cliente rellena un formulario
de datos personales y bancarios que se almacenan en una base de datos.
Demanda
1. Hay una lista de artculos demandados con el mximo nmero de unidades que se admiten y que los mayoristas pueden
consultar.
2. La oferta de un mayorista consiste en una lista de:
a) Nombre de artculo.
b) Precio unitario.
c) Cantidad de artculos a partir de la cual se tiene ese precio unitario. (Cuantos ms artculos se compren menor es ese
precio)
3. Una vez hecha una oferta se almacena en una base de datos.
4. Existe la posibilidad de que el mayorista ofrezca artculos que no estn en la base de datos (novedades).
Cada una de estas ofertas es un lote de productos que el mayorista vende juntos. Un mayorista puede hacer mltiples ofertas. En
funcin de las ofertas de los proveedores se toman las decisiones de seleccionar uno u otro. Las ofertas pueden ser complejas,
pudiendo ofertar un mismo artculo a precios diferentes en funcin de la cantidad de artculos o en ofertas que consisten en un
lote de productos.
2.2. Plantilla de solucin propuesta para el ejemplo A

Los casos de uso son:
1. Dando de alta cliente (ver tabla 2.1).
Caso de uso: Dando de alta cliente
Actor: Cliente
Curso normal
Alternativas
1) El cliente comunica sus datos
2) El sistema le asigna una
2.1) Si el cliente ya est
contrasea al cliente
registrado se informa del error
3) Si el cliente lo desea inicia
por primera vez el caso de uso
Recogiendo pedido de cliente
Cuadro 2.1: Caso de uso para dar de alta un cliente.
2. Dando de alta proveedor (ver tabla 2.2).
Caso de uso: Dando de alta proveedor
Actor: Proveedor
Curso normal
Alternativas
1) El proveedor comunica sus datos
2) El sistema asigna una contrasea 2.1 El proveedor ya estaba registrado
Se informa del error. Fin
3) Si el proveedor lo desea inicia
el caso de uso Recogiendo oferta de
proveedor
Cuadro 2.2: Caso de uso para dar de alta un proveedor
3.
4.
5.
6.
7.
Recogiendo pedido de cliente (ver tabla 2.3).

Recogiendo oferta de proveedor (ver tabla 2.4).
Actualizando contenido de la pgina (ver tabla 2.5). .
Solicitando reposicin (ver tabla 2.6).
Seleccionando proveedor (ver tabla 2.7).
2.2 Plantilla de solucin propuesta para el ejemplo A
29
Caso de uso: Recogiendo pedido de cliente

Actor: Cliente
Curso normal
Alternativas
1) El cliente se identifica correctamente
1.1) El cliente no est en la BD. Fin
2) El cliente selecciona de la lista de
productos las cantidades que necesita.
3) El sistema registra el pedido
3.1) No hay suficiente cantidad de algn
producto . Se llama a Solicitando reposicin
4) El sistema informa de la fecha de entrega
5) El usuario confirma el pedido
5.1) El usuario rechaza el pedido
Cuadro 2.3: Caso de uso para recoger pedido de cliente
Caso de uso: Recogiendo oferta de proveedor
Actor: Proveedor
Curso normal
Alternativas
1) El proveedor se identifica correctamente 1.1) El proveedor no est en la BD. Fin
2) El proveedor escribe la lista de
productos ofertados y precios
3) El sistema graba la informacin
en la base de datos
Cuadro 2.4: Caso de uso para recoger oferta de un proveedor
Clases Las clases necesarias para realizar el primer caso de uso Dando de alta cliente seran:
1. Objetos de entidad
Cliente: Es un objeto del mundo real que el sistema tiene que tener en cuenta para almacenar sus datos. Sirve para
almacenar los datos del cliente.
TablaClientes: Proporciona un conjunto de accesos a la tabla de clientes de la base de datos. Sirve para saber si un
objeto Cliente existe y para insertarlo.
2. Objetos de frontera
FormularioAlta: Para preguntar los datos al cliente.
MensajeError: Para mostrar si el cliente ya estaba registrado.
PreguntaPeticin: Para preguntar si se inicia el caso de uso RecogiendoPedidoCliente.
3. Objetos de control
ControlAltaCliente: Es el objeto que gestionar la comunicacin entre los diferentes objetos.
El resto de los casos de uso tendran un proceso similar.
Diseo arquitectnico Las partes en las que se divide esta aplicacin son las siguientes:
1.
2.
3.
4.
Base de datos
Servidor
Clientes
Una aplicacin en el lado del proveedor que dialoga con la nuestra
En el cliente estaran todos los formularios y se mandara el contenido en la forma de los objetos adecuados al servidor.
Caso de uso: Actualizando contenidos
Actor: Gestor
Curso normal
Alternativas
1) El gestor se identifica correctamente
1.1 ) El gestor no se identifica
correctamente. Se anota la
incidencia. Fin
2) El gestor introduce nuevos elementos
en la B.D. de productos con sus cantidades
y precios de venta al pblico. Cambia las
cantidades de algunos productos
3) El sistema actualiza la B.D. de
productos y registra fecha, gestor, y
cambios realizados
Cuadro 2.5: Caso de uso para actualizar contenido de pgina
30
Cuadro 2.6: Caso de uso de solicitar reposicin

Caso de uso: Solicitando reposicin
Actor: Sistema
Curso normal
Alternativas
1) El nmero de items de algn producto
baja de su umbral
2) El sistema selecciona un proveedor
2.1 No se encuentra proveedor.
Se escribe la incidencia en la base
de datos. Fin del caso de uso.
3) Se establece comunicacin con
el proveedor
4) La aplicacin del proveedor est disponible 4.1 La aplicacin del proveedor
no est disponible. Se elimina
de la lista de proveedores y se
vuelve al punto 2
5) El proveedor registra la peticin
6) El proveedor notifica la entrega
7) El sistema inserta en la base de
datos fecha, producto, cantidad, precio
y proveedor
Caso de uso: Seleccionando proveedor
Actor: Gestor
Curso normal
Alternativas
1) El usuario introduce un tipo de
producto y cantidad
2) El sistema busca el proveedor que
2.1 El sistema no encuentra un
suministre el producto a menor precio y proveedor de ese producto
lo comunica al usuario
y lo comunica al usuario
Cuadro 2.7: Caso de uso de seleccionar proveedor
2.3. Ejemplo B: Gestin de proceso en una fbrica de productos electrnicos

Como complemento al problema anterior se plantea, en una empresa de fabricacin de chips o cualquier otro tipo de productos
electrnicos, el desarrollo de una aplicacin para la gestin integral del proceso de control de movimientos de entrada/salida y
seguimiento de personas, materiales o documentos. Dado que la empresa maneja informacin delicada (secretos industriales) es
necesario llevar un control riguroso de todos los elementos y personas que se mueven en la empresa. Esto se desea automatizar
lo mximo posible para que los miembros del departamento de seguridad tengan plenas garantas del control.
Para simplificar el problema se supone que los sistemas software de control de sensores, cmaras, etc estn ya plenamente
implementados y con toda la documentacin necesaria disponible, por tanto solamente se debe desarrollar la parte correspondiente a la interfaz de manejo y las aplicaciones de gestin de los datos. Este ejemplo puede tener dos partes: gestin del almacn
y gestin de personas.
Un producto estar en el almacn y hay que tener informacin acerca de ese producto. Cada tipo de producto tendr en el
almacn un stock mnimo y mximo, una serie de caractersticas (precio de fabricacin, consumo elctrico, voltaje, etc).
Respecto a las personas, cada una tiene una serie de responsabilidades a las que est asociada, una serie de personas con las
que colabora, un horario, un sueldo que se calcula en funcin de categora, productividad, etc.
Se puede pensar en una reasignacin de tareas en dos situaciones: 1) Cuando una persona est enferma o tenga que desplazarse, para lo cual habr un proceso que seleccione alguien en funcin de aptitudes y disponibilidad dentro de la plantilla y reasigne
tareas y 2) Cuando se realice un nuevo plan de produccin que afecte a toda la fbrica.
2.4. Plantilla de solucin propuesta para el ejemplo B

El DFD inicial (ver figura 2.1) se descompone en dos partes: Gestin del almacn y gestin de personas (ver figura 2.2).
La gestin del almacn se puede descomponer de este modo:
1. Gestin de entradas. Items que entran al almacn. No se tiene en cuenta cual es el proceso que causa la peticin a
los proveedores de estos items.
2. Gestin de salidas. Items que salen al almacn como consecuencia de pedidos.
Ambos procesos actualizarn la base de datos y dejarn un registro de cada entrada y salida.
La gestin de personas se podra descomponer de esta forma:
1. Actualizar plantilla. En el caso de una persona que se ponga enferma o se desplace.
2.5 Ejemplo C: Agenda electrnica personal
Personas
31
Empresa
chips
Aptitudes
Productos
Tareas
Produccion
Pedidos
Clientes
Figura 2.1: DFD 0
Produccion
Productos
Tareas
Gestion
Almacen
1
Gestion
Personas
2
Pedidos
Clientes
Aptitudes
Personas
Figura 2.2: DFD 1

2. Asignacin de tareas. Se selecciona una persona para cubrir esa baja, que es un tipo de obrero cualificado para cubrir
cualquiera de los puestos de una lnea de produccin.
3. Planificacin global. Este proceso se encarga de la replanificacin global en el caso de un nuevo plan de produccin.
2.5. Ejemplo C: Agenda electrnica personal

Uno de los programas prcticos, y relativamente asequible, que se puede hacer para uno mismo, es el de una agenda personal
simple para llevar la informacin sobre personas, libros, msica, citas, etc. En nuestro ejemplo, queremos gestionar los datos
siguientes:
De cada persona: Nombre y Apellidos (obligatorio), NIF, Fecha de nacimiento (para recordatorio de cumpleaos, etc.),
Domicilio (uno o ms), Direccin de correo electrnico (una o ms), Telfonos (pueden ser de cada uno de los domicilios,
del mvil, del trabajo, etc.) y Comentarios (campo de texto de gran tamao para poner informacin no contemplada en los
puntos anteriores).
Para seleccionar en la lista de personas que salen en la interfaz de usuario los tipos de personas que se quieren ver, se podra
tener en algn sitio (quizs una opcin de configuracin del men) un chekbox con las opciones de: Familiares, Amigos,
Compaeros del trabajo, rea secreta, etc.
De los libros: Ttulo (obligatorio), Autor(es), Editorial, Fecha de publicacin, ISBN, Localizacin y Categora (ensayo,
novela, profesional, etc).
De los discos de msica: Ttulo (obligatorio), Autor o grupo, Casa discogrfica, Tipo de soporte, Tipo de msica (pop,
rock, clsica, jazz, etc) y Localizacin.
De los vdeos: Ttulo (obligatorio), Director, Actores principales, Gnero (drama, cine negro, ciencia ficcin, etc), Ao de
produccin, Duracin (en minutos) y Localizacin.
Respecto a las tareas: Fecha y hora de comienzo (obligatorio), Duracin estimada y Descripcin.
Adems se va a dividir la informacin en dos tipos: Pblica y privada. La informacin pblica est a la vista de cualquier persona
que utilice el programa. La informacin privada slo la puede recuperar la persona que la ha introducido, para lo cual ser
necesario que cada persona tenga un login y un password (slo si esa persona quiere introducir o leer informacin en un rea
privada). Esto significa que hay que hacer una gestin de usuarios.
Se desea tambin que exista algn mecanismo para dividir los tipos de personas en categoras, de forma que se distinga entre
compaeros del trabajo, amigos, familiares, etc. Esto puede implementarse como un atributo ms de los relativos a la persona,
pero debe usarse tambin de algn modo en la interfaz de usuario de tal forma que sea fcil seleccionar entre los diferentes tipos
de personas (el usuario no sabe SQL ni similares).
Se cuenta tambin con la posibilidad de recuperar elementos borrados. Cada vez que se borra un elemento no queda borrado
del todo, se almacena en un rea conocida como limbo, del cual se puede recuperar. Si un elemento es eliminado del limbo
desaparece definitivamente.
32
Los datos se pueden guardar de dos formas: en una base de datos o en ficheros. Ambos mtodos tienen sus ventajas e
inconvenientes. En cualquier caso los datos que se guarden como secretos deben ser cifrados (usando alguno de los algoritmos
criptogrficos que hay publicados) con la clave que se pide al usuario para de esa forma evitar cualquier tipo de intrusin.
En algn lugar de la interfaz de usuario hay que poner un reloj (no se especifica si analgico o digital) y la fecha. El reloj
tiene precisin de segundos.
2.6. Plantilla de solucin propuesta para el ejemplo C

2.6.1. Casos de uso
En general existen cuatro tipos de casos de uso en esta aplicacin: De insercin de elementos, de lectura, de borrado y de
modificacin. Adems hay que tener en cuenta los casos de uso de acceso al rea secreta de datos y de acceso al limbo para
recuperar o eliminar definitivamente la informacin.
Caso de uso: Insertar persona.
1.
2.
3.
4.
5.
6.
El usuario selecciona la opcin de personas en la pestaa adecuada.

El sistema cambia la pantalla para mostrar ese tipo de elementos.
El usuario pulsa el icono de insercin o la opcin de men de insercin.
El sistema muestra una pantalla donde est toda la informacin relativa a una persona.
El usuario rellena la informacin anterior.
El sistema comprueba que la informacin es correcta. Si no es correcta puede ser por dos motivos:
El nombre y apellidos estn repetidos. Se muestra el mensaje de error correspondiente y se permite editar este campo
de nuevo.
El nombre y apellidos no han sido escritos. Se muestra el mensaje de error correspondiente y se permite escribir esta
informacin.
7. El sistema realiza la insercin.

8. El sistema borra la pantalla de insercin de datos y actualiza la ventana principal con la nueva informacin.
Entre los puntos 4 y 6 el usuario tiene la opcin de cancelar la operacin de insercin.
Los casos de uso de insercin de discos, tareas, vdeos y libros seran idnticos a este.
Proceso de recuperar informacin.
Se puede hacer de dos formas: Seleccionando la persona de una lista y se muestran sus datos o con una ventana en la que se
pregunta el nombre y el sistema lo busca.
Caso de uso: Buscar persona 1.
1.
2.
3.
4.

El usuario selecciona un nombre de una lista.
El sistema muestra los datos de esa persona en esa misma pantalla.
Caso de uso: Buscar persona 2.

1.
2.
3.
4.
5.
6.

El usuario pulsa el icono de bsqueda o selecciona esa opcin del men.
El sistema muestra una pantalla donde se pregunta el nombre y apellidos de la persona a buscar.
El usuario escribe la informacin.
Pueden ocurrir tres cosas:
No existen personas con ese nombre. El sistema pone un mensaje. Fin del caso de uso.
Slo existe una persona. Se resalta el nombre de esa persona en la lista de personas y se pone su informacin en las
casillas correspondientes de la ventana. Fin del caso de uso.
Existe ms de una persona que se corresponde con ese nombre (puede pasar porque si slo se ha escrito el nombre o
parte de l puede haber varias personas distintas que se correspondan, aunque sea la clave de esta tabla). El sistema
hace una lista de las personas mostradas y esa lista se recorre igual que en el caso de uso buscar persona 1. Fin del
caso de uso.
Al igual que antes, los casos de uso para libros, discos, etc seran idnticos a este.
2.6 Plantilla de solucin propuesta para el ejemplo C
33
Borrado
En este caso necesitamos hacer una bsqueda primero y luego un borrado.
Veamos cmo se borrara una persona. Puede hacerse de dos formas, como en el buscar persona.
Caso de uso: Borrar persona 1.
1.
2.
3.
4.
5.
El usuario selecciona una persona con el caso de uso Buscar persona 1.

El usuario pulsa el icono de borrado o selecciona esa opcin del men.
El sistema pide confirmacin con la ventana correspondiente.
El usuario confirma el borrado o lo rechaza, en cuyo caso termina el caso de uso.
El sistema pone la informacin en el limbo.
Caso de uso: Borrar persona 2.

1.
2.
3.
4.
5.
Se utiliza el caso de uso de buscar personas 2.

El usuario pulsa el icono de borrado o selecciona esa opcin del men.
El sistema pide confirmacin con la ventana correspondiente.
El usuario confirma el borrado o lo rechaza, en cuyo caso termina el caso de uso.
El sistema pone la informacin en el limbo.
Como estos dos casos de uso son prcticamente idnticos podramos pensar en utilizar la parte comn.
Divisin del sistema
Veamos cmo sera la divisin del sistema. Las entidades externas seran los usuarios (ver figura 2.3). Los procesos que hay
que hacer son:
Insercion
Consulta
Borrado
Modificacion
Agenda
Usuario
Creacion
Borrado
Acceder como
Figura 2.3: DFD 0
Gestin de personas (telfonos y direcciones). Insercin, borrado, consulta y modificacin.

Gestin de libros, msica y vdeos (dem que el anterior)
Gestin de usuarios (login, password). Acceder como, Crear usuario, Borrar usuario.
Adems cada uno de estos apartados definira un almacn propio para guardar cada uno de sus tipos de datos. Como se puede ver
(figura 2.4), cada uno de los procesos es totalmente independiente de los dems, no necesitan comunicarse informacin, excepto
en el caso de la gestin de usuarios, que define el usuario actualmente conectado y correctamente identificado por el sistema.
Esta informacin se deja en un almacn al cual pueden acceder el resto de los procesos.
Diseo de la interfaz de usuario
Puede hacerse de muchas formas perfectamente vlidas, la solucin propuesta es slo una de ellas. Las opciones que el
usuario tiene que ver claramente son: Gestin usuarios, Personas, Libros, Msica y Vdeos. La interfaz puede hacerse de muchas
formas: Men, Barra de iconos, o un componente con varias pestaas con cada opcin.
Una barra de iconos quizs sea la mejor opcin desde el punto de vista de la vistosidad, pero hay que tener cuidado de que
esos iconos sean realmente significativos. Es aconsejable adems que exista algn tipo de ayuda, como los mensajes de ayuda
emergentes que salen cuando se pasa el ratn por encima.
Cada vez que se pulse una de las opciones, el diseo de la pantalla debera cambiar para mostrar un conjunto de elementos
visuales relativos a la opcin seleccionada, por otra parte, cada una de las opciones del men, barra o componente, tendra que
poder mostrar en cada una de ellas las opciones de Insercin, Borrado, etc. Si la opcin escogida es un men esto podra hacerse
con submens. Si se escoge una barra de iconos, se puede poner en la pantalla un botn con cada una de las opciones, etc.
Distribucin de la informacin dentro de la pantalla: El objetivo es que encontrar la informacin sea fcil y rpido. Una forma
es tener una lista de Personas, Libros, etc a la izquierda y la lista de atributos de uno de ellos a la derecha y ocupando el resto de
la pantalla. Cada vez que se selecciona una Persona, Libro, etc. cambia el contenido de los atributos mostrando el seleccionado.
34

Insercion
Consulta
Insercion
Gestion
Libros
Consulta
Borrado
Gestion
Musica
Borrado
Modificacion
Modificacion
Nuevo Usuario
Borrar Usuario
Gestion
Usuarios
Usuario
Acceder Como
Insercion
Insercion
Consulta
Gestion
Videos
Consulta
Gestion
Personas
Borrado
Borrado
Modificacion
Modificacion
Figura 2.4: DFD 1
Tutorial posterior
Este captulo consiste simplemente en un conjunto de tres ejemplos que se plantean, tanto en su descripcin, como en el
diseo o preparacin de plantillas de su posible solucin. Estos ejemplos podrn ser utilizados a lo largo del resto de los temas
para ilustrar algunos aspectos de los mismos.
Los ejemplos elegidos son: una aplicacin de comercio en Web, la gestin de proceso en una fbrica de productos elctricos
y una agenda electrnica personal.

1. Como paso para comprobar la comprensin de los problemas que van a plantear a lo largo de los prximos captulos sera
conveniente que el alumno redactase las descripciones dadas por el cliente (o los posibles dilogos con los desarrolladores)
para definir a partir de ellos de una manera grfica o esquemtica los elementos, actores y tareas que pueda identificar.
2. El alumno puede elegir algn problema supuesto por s mismo, y definirlo aqu de manera similar a los propuestos, para
poder utilizarlo como ejercicio para el resto de los temas donde se irn desarrollando los propuestos aqu.
En [Pre01, sec. 28.5] se encuentra una descripcin de un sistema de comercio electrnico, que puede usarse para extraer ms
informacin y descripciones para el primer ejemplo de este captulo. En el apndice A.3 del libro [Som98], se puede encontrar
un conjunto de ejemplos gua alternativos desarrollados en las diferentes fases que pueden resultar muy tiles.
Hay una aplicacin para tienda electrnica de libre distribucin (fuentes incluidos), desarrollado en modo open source (licencia GPL) por O NRICA por encargo de BANESTO, en http://www.cibertienda.org/ que puede servir de gua para el ejemplo
aqu presentado.
Captulo 3
Fase de requisitos
Tutorial previo
Introduccin
El primer paso para atacar un problema es conocerlo con detalle, es decir, cuales son los requisitos funcionales que se deben
cumplir y qu restricciones hay que tener en cuenta que no forman parte de los requisitos funciales. La extraccin u obtencin
de requisitos es el primer paso, que va seguido del anlisis de esos requisitos en base a un modelo del problema. De ese anlisis
obtendremos una especificacin de requisitos que debemos validar frente a las especificaciones iniciales.
Esta fase es la primera que se acomete en el desarrollo del proyecto y es la ms importante porque las consecuencias de un
error en la etapa inicial de un proyecto tiene un coste muy alto en tiempo y dinero. La realizacin de una buena especificacin
no es tan sencillo como se puede pensar en un principio, pues muchas veces el propio cliente no tiene una imagen clara del
sistema final o surgen nuevas necesidades a mitad del desarrollo. Para hacer frente a estos problemas hay que: comunicarse de
forma efectiva con el cliente para obtener los requisitos, comprender el problema a resolver, crear un modelo del problema real
y, por ltimo, revisar la especificacin creada. Todos estos pasos deben dejar un rastro que se pueda seguir en caso de problemas
posteriores (trazabilidad), por lo cual se debe empezar a documentar todo (guardar registro de todas las actividades) desde el
principio.

La extraccin, modelado, anlisis y representacin de requisitos o especificaciones es un problema muy relacionado con la
Ingeniera del Conocimiento, por tanto sera conveniente que el alumno repasara los temas correspondientes en las asignaturas previas relacionadas. Es necesario ejercitar la capacidad de abstraccin para poder expresar lo que pide el cliente en una
representacin formal que responda a sus expectativas.
Objetivos del tema

Es necesario en esta fase separar y entender los conceptos propios de cmo especificar un problema y cmo hacer til esas
especificaciones para posteriores fases del desarrollo. El alumno debe ser capaz de extraer y representar un conjunto de requisitos
expresados en lenguaje natural a una representacin que sirva de entrada a la fase siguiente de diseo.

En el tema se exponen los contenidos tericos genricos junto con las partes correspondientes de los ejemplos gua. El alumno
debe identificar cules son los elementos correspondientes a la obtencin y el anlisis de los requisitos en esos ejemplos para
generalizarlo a otros problemas. Tambin puede realizar los mismos procesos sobre los problemas supuestos por el alumno como
ejercicios en el tema 2.
1. Obtencin de requisitos: se estudia directamente en el material en esta gua.
2. Anlisis de requisitos: este apartado se puede estudiar en [Pre01, secs. 11.1 a 11.3].
3. Representacin de requisitos: el contenido se estudiar en [Pre01, sec. 11.5 y cap. 12] (aunque en este ltimo se denomina
modelado del anlisis).
4. Anlisis orientado a objetos: en [Pre01, cap. 21].
5. Validacin de requisitos: en [Pre01, sec. 11.6] junto con el apartado correspondiente en esta gua.
6. Bases de documentacin: en el contenido del apartado correspondiente de esta gua.
3.1. Obtencin de requisitos

Los mtodos tradicionales en cualquier ingeniera requieren como primer paso la obtencin de los requisitos en forma de
especificaciones por parte del cliente. Este problema habitualmente tiene complicaciones debidas al paso entre el lenguaje natural
35
36
Fase de requisitos
y los lenguajes ms formales en ingeniera. Por lo tanto la obtencin de los requisitos es un paso complejo y que no tiene una
solucin sencilla. Se suelen utilizar los mtodos de pregunta-respuesta o los de cuestionarios plantilla para perfilar la versin
inicial, pero se requieren sucesivas iteraciones (incluso con otras fases de desarrollo) antes de obtener unas especificaciones
adecuadas.
3.1.1. Introduccin
Un requisito es una capacidad que el sistema debe tener porque el cliente lo ha pedido explcita o implcitamente, lgicamente, la determinacin del conjunto de requisitos es el primer paso a dar en la construccin de una aplicacin. Existen dos subtareas
en la obtencin de los requisitos antes de pasar a la fase de diseo:
Anlisis: El problema a resolver es la comprensin del problema del cliente para, de este modo, conseguir una lista de las
caractersticas que debe tener el producto.
Especificacin: Consiste en traducir los requisitos a un documento con un formato concreto que pueda servir de entrada a
la fase siguiente.
La obtencin de requisitos es difcil 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 tcnicos (informticos) por parte del cliente para expresarse con claridad.
Anlisis
La clave es la comunicacin con el cliente. Para facilitar esta comunicacin se han desarrollado varias tcnicas: entrevistas,
prototipos, desarrollo conjunto de aplicaciones (Joint Application Development, JAD), planificacin conjunta de requisitos (Joint
Requirements Planning, JRP) y casos de uso del UML.
Especificacin
El resultado que se persigue aqu es un documento que especifica todos los requisitos, este documento tiene que tener estas
propiedades:
Completitud: Estn todos los requisitos.
Concisin: Es importante no hacer una novela, hay que contar lo que hay pero pensando que quien se lea el documento
cobra por horas.
Legibilidad: Es similar al punto anterior, pero el sentido de este es la claridad.
Consistencia: No existen contradicciones internas.
Facilidades de prueba: De algn 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.
Facilidades de seguimiento: Debe ser posible comprobar si se van cumpliendo los objetivos.
Factibilidad: Los objetivos definidos deben ser conseguibles a un coste razonable.
Tipos de requisitos
Requisitos funcionales: Dicen qu debe hacer el sistema, en el sentido de servicios proporcionados al usuario.
Requisitos no funcionales: Hablan de caractersticas del sistema, como pueda ser la fiabilidad, mantenibilidad, sistema operativo, plataforma hardware, etc.
3.1.2. Tcnicas de obtencin de requisitos

En esta seccin veremos las tcnicas de comunicacin con el cliente.
Entrevistas
Todo el mundo pasa por una entrevista en algn momento de su vida ya sea para un proceso de seleccin de personal, un
examen de oposicin o incluso una conversacin con el jefe se podra considerar como una entrevista. Aunque tambin existan
otras tcnicas, esta siempre la tendremos, al menos al inicio del proyecto. Una entrevista tiene tres fases: Preparacin, Desarrollo
y Anlisis.
3.1 Obtencin de requisitos
Preparacin
37
En general para cualquier entrevista hay cuatro temas que se han de tener en cuenta:
1. Documentacin: El entrevistador se informa acerca del tema a tratar. Puede hacerlo de varias formas:
Estudiar la bibliografa sobre el tema.
Estudiar documentos sobre proyectos similares.
Inmersin dentro de la organizacin para la que se desarrolla el proyecto
2. Personal: Se seleccionan las personas a las que se va a entrevistar.
Directivos: Dan una imagen de alto nivel de la empresa. Puede ser til para determinar la estructura arquitectnica
de la aplicacin.
Empleados: Dan una imagen de un grano ms fino. Son los que pueden concretar las funciones a implementar.
3. Determinar el objetivo de la entrevista. Previamente a la entrevista se pueden distribuir a los entrevistados cuestionarios
sobre el tema a tratar y una introduccin.
4. Logstica: Temas prcticos acerca de como discurre la entrevista: lugar, hora, minimizar interrupciones, encontrar un
momento en el que todos puedan ir, etc.
Desarrollo Hay tres etapas [PV96]:
1. Apertura: El entrevistador se presenta e informa al entrevistado de cuales van a ser los puntos tratados en la entrevista.
2. Desarrollo: No debe durar ms de dos horas. El entrevistado debera hablar el 80 % del tiempo.
Tcnicas utilizadas:
Preguntas abiertas, tambin conocidas como de contexto libre. No se pueden contestar con Si o No. Por ejemplo: Cul es la lista de pasos para dar de baja un producto?. Ms tarde se pasa a preguntas ms concretas.
Forma de expresarse: Se deben evitar los tecnicismos que el entrevistado pueda no conocer.
Psicologa: El problema fundamental de las entrevistas es que se trata con personas en vez de con mquinas, por eso
la informacin conseguida puede tener omisiones o imprecisiones. Hay que tener en cuenta las siguientes reglas entre
muchas otras de la comunicacin no verbal.
No insinuar que el entrevistado debera saber algo que no sabe para que no se ponga a la defensiva. Tambin
hay que dejar claro que los intereses del entrevistador son nicamente la adquisicin de requisitos, no hacer un
examen de conocimientos, y por tanto las lagunas que pueda tener no trascendern a sus superiores.
Lenguaje del cuerpo: Dicen los psiclogos que el 90 % de la comunicacin es no verbal. Se debe estar atento a
los signos que puedan denotar inseguridad en algunos temas para preguntar a otras personas.
Usar tcnicas para mantener la atencin del entrevistado.
3. Terminacin: Se hace un resumen de la informacin recogida (para validar que es correcta) y, de ser necesario, se cita
para la siguiente entrevista. En cualquier caso se debe poder contactar de nuevo con el interesado, por ejemplo para aclarar
algunos puntos. Se agradece al entrevistado que nos haya dedicado su tiempo.
Anlisis Se trata de ver como utilizar los conocimientos adquiridos. Para ello las actividades son:
1. Burocracia, como por ejemplo, pasar a limpio la entrevista.
2. Asimilacin de la informacin: Se contrasta con otras entrevistas, bibliografa, etc. Se llega a conclusiones.
3. Evaluacin de la entrevista: Qu se quera conseguir y qu se ha conseguido?
Para validar una vez ms la entrevista se puede mandar la documentacin generada al entrevistado.
Desarrollo conjunto de aplicaciones (JAD)
En el apartado anterior se vio una somera introduccin a una entrevista clsica desde el punto de vista de que existe un
entrevistador y un entrevistado. Ahora se contempla un tipo de entrevista desarrollada por IBM que se apoya en la dinmica de
grupos. Consiste en un conjunto de reuniones en un periodo de entre dos y cuatro das. Se basa en cuatro principios:
1.
2.
3.
4.
Dinmica de grupo.
Uso de ayudas audiovisuales: Diagramas, transparencias, pizarras, etc.
Modo de trabajo sistemtico.
Filosofa de documentacin WYSIWYG (What You See Is What You Get).
Existen dos tipos de sesiones JAD: JAD/Plan, para obtencin de requisitos y JAD/Design, para el diseo. Veremos el primero.
38
Fase de requisitos
Ventajas del JAD:

1. La informacin obtenida se puede contrastar in situ porque estn todos los interesados. En las entrevistas individuales este
es un proceso lento. Adems en esta contrastacin participan tanto los usuarios como los desarrolladores, esto quiere decir
que 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 exploracin de los
problemas que se plantean, con lo cual la resistencia al cambio ser menor.
Inconvenientes:
1. Al ser un grupo de personas es difcil encontrar un hueco en la agenda de todos para estas reuniones.
2. Es una tcnica complicada.
Participantes: Participan de ocho a doce usuarios a parte de los analistas. Hay seis tipos:
1. Jefe del JAD: Debe tener las caractersticas clsicas de una persona que dirige una reunin: Dotes de comunicacin y
liderazgo. Son deseables tambin conocimientos de psicologa para por ejemplo conseguir que todo el mundo participe o
evitar conflictos, pero sobre todo, para dirigir la sesin a sus objetivos.
2. Analista: La funcin realizada es la de secretario de la sesin. Es la persona encargada de poner por escrito la informacin.
No es una tarea tan trivial como parece, tiene que ser alguien que haya comprendido el tema y lo pueda expresar bien con
las herramientas que se empleen.
3. Patrocinador: A efectos prcticos es el jefe de la empresa contratante porque es quien toma la decisin de seguir o no con
el 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 visin global del sistema. En el
JAD/Design son usuarios.
5. Desarrolladores: Son las personas que pueden informar de las dificultades de implementacin de ciertas caractersticas.
6. Especialistas: Son la autoridad a consultar sobre aspectos puntuales tanto por parte de los usuarios como por parte de
los desarrolladores.
Fases:
1. Adaptacin: El jefe del JAD es quien debe adaptar la sesin a las caractersticas propias del proyecto en curso. Para ello
debe:
Documentarse sobre la organizacin y el proyecto.
Decidir cuestiones organizativas sobre las sesiones JAD: Nmero y duracin, lugar (mejor si es fuera de la empresa
para evitar interrupciones), fechas, etc.
Seleccionar a los participantes adecuados para cada reunin.
2. Sesin JAD: Est dividida en una serie de pasos:
Presentacin: Al igual que en la entrevista individual, el jefe del JAD y el patrocinador ejecutivo se presentan. El
patrocinador explica los motivos del proyecto. El jefe del JAD explica la mecnica de la reunin.
Definicin de requisitos de alto nivel: Esto ya es parte del trabajo productivo. El jefe del JAD hace preguntas del tipo:
Qu beneficios se esperan del sistema? Cules son los recursos disponibles? Estos requisitos se van escribiendo
en algn 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 suficientemente grande se les
puede organizar y decidir el mbito del sistemaDocumentar temas abiertos: Si un tema queda sin resolver se debe documentar para otra sesin y asignar una
persona responsable de su solucin.
Concluir la sesin: El jefe del JAD hace un repaso de la informacin obtenida con los participantes. Es el momento
de hacer correcciones o aadidos.
3. Organizacin de la documentacin: Se trata de producir un documento con la informacin recabada en la fase anterior.
Hay tres partes que se siguen secuencialmente.
Compilar la documentacin: La documentacin recogida se redacta en un documento normalizado.
Revisar la documentacin: Se enva la documentacin a los participantes para que efecten correcciones.
Validar la documentacin: El patrocinador ejecutivo da su aprobacin.
Planificacin conjunta de requisitos (JRP)
Es un subconjunto de las sesiones JAD. Se caracterizan por estar dirigidas a la alta direccin y en consecuencia los productos
resultantes son los requisitos de alto nivel o estratgicos. La planificacin de una sesin consiste en tres pasos:
39
1. Iniciacin: Se delimita el alcance del plan de sistemas de informacin, unidades organizativas afectadas y perfiles necesarios para la reunin.
2. Bsqueda: Se identifican objetivos, situacin actual e informacin al respecto.
3. Lugar: Es importante que al igual que en la sesin JAD sea fuera de la organizacin para evitar interrupciones. La sala
de reuniones debe ser adems confortable y equipada con el mobiliario adecuado. Las ayudas audiovisuales pueden ser
pizarras, proyectores, etc. Se debe contar adems con ordenadores equipados con herramientas CASE, procesadores de
texto, hojas de clculo y herramientas de prototipado.
4. Seleccionar a los participantes. Los perfiles son los siguientes:
Jefe JRP: Debe tener las mismas aptitudes que en el caso del JAD.
Patrocinador: El que respalda econmicamente el proyecto.
Director del proyecto
Consultores: Traduce los requisitos de usuario a informacin estructurada inteligible por los usuarios.
Especialista en modelizacin: Elabora los modelos en la reunin.
Usuarios de alto nivel: Definen los procesos organizativos y los sistemas de informacin afectados por el plan de
sistemas de informacin y las prioridades de implantacin.
5. Redactar la agenda de asuntos a tratar. Esta agenda debe ser planificada asignando tiempos para cada cuestin.
6. Realizacin: Discurre igual que la sesin JAD.
Brainstorming
Este es otro tipo de entrevista de grupo. A diferencia del JAD que est fuertemente estructurada, el brainstorming (tormenta de
ideas) se caracteriza precisamente por lo contrario, porque aunque existe un jefe del grupo, su funcin es meramente anecdtica.
El objetivo es la generacin de ideas novedosas para la resolucin de un problema. Su utilizacin es adecuada al principio del
proyecto, pues puede explorar un problema desde muchos puntos de vista.
Ventajas del brainstorming:
1. Es fcil (la nica norma es que vale todo y no se puede criticar a nadie).
2. No est tan formalizado como el JAD.
Inconvenientes:
1. No proporciona resultados con mucho nivel de detalle.
2. Es difcil reunir a todo el mundo.
Fases del Brainstorming:
1. Preparacin
Se selecciona a las personas involucradas, es decir: Jefe de la reunin, 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 solucin. El jefe da la
palabra a una persona u otra. Cuando se han generado suficientes ideas se termina la reunin. Normas a seguir:
No se permite la crtica a ningn participante, diga lo que diga.
Se promueven las ideas ms creativas aunque no sean factibles para estimular la creatividad del resto del grupo.
Cuantas ms ideas salgan mejor.
Los participantes pueden aadir ideas propias a las ideas de otros.
3. Consolidacin: Es similar a la fase de anlisis en la entrevista individual o la fase de organizacin de la documentacin de
JAD. Se divide en tres partes
Clasificar ideas para agruparlas o fusionarlas.
Descartar ideas peregrinas o poco factibles.
Priorizar ideas en funcin de su importancia.
4. Documentacin: El jefe pone por escrito la informacin que sale de la fase de consolidacin.
40
Fase de requisitos
Prototipos
Un prototipo es una versin reducida de la aplicacin final. Se puede construir con dos filosofas[Som98]:
1. Prototipos de desarrollo rpido. Sirven para obtener y validar requisitos. Cuando han cumplido esta finalidad se desechan.
2. Prototipo inicial: Se desarrolla el sistema de un modo incremental partiendo de una versin inicial.
El segundo caso se ha discutido ya en el captulo dedicado a ciclos de vida. El primer caso sigue el proceso indicado en la figura
3.1.
Requisitos
iniciales
Desarrollo
prototipo
Evaluacion
Especificacion
Desarrollo
sistema
Validacion
Figura 3.1: Obtencin y validacin de requisitos a partir de prototipos [Som98]

Un prototipo no es utilizable como sistema final porque se ha desarrollado con la mxima rapidez y en consecuencia:
1. Los requisitos no funcionales tales como rendimiento, seguridad, etc no se implementan.
2. No hay documentacin.
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 cdigo es mala.
Para el desarrollo rpido de prototipos [Som98] existen tres tcnicas de desarrollo rpido de prototipos que se pueden usar
conjuntamente: Lenguajes de alto nivel, Programacin de bases de datos y Componentes reutilizables.
Lenguajes de alto nivel Son lenguajes de gran nivel de abstraccin que necesitan menos lneas de cdigo para hacer lo mismo
que en un lenguaje de bajo nivel como C. Ejemplos de lenguajes de alto nivel son: Lisp, Smaltalk y Prolog. Los lenguajes de alto
nivel tienen la desventaja de cargar mucho al sistema, razn por la cual no estn ms extendidas, aunque este motivo es cada vez
menos importante dada la potencia de las mquinas actuales.
Cuando se desarrolla un prototipo hay que responder algunas cuestiones para escoger el lenguaje, tales como cual es el
mejor lenguaje para el dominio del problema que se est abordando. Por ejemplo, Lisp y Prolog pueden ser adecuados para
inteligencia artificial, Java si se necesita un software multiplataforma, etc. Se deben tener en cuenta asimismo factores tales como
las facilidades suministradas por la herramienta para la construccin automatizada de interfaces de usuario, la experiencia que
tiene con dichas herramientas el personal con el que contamos, si se puede conectar o forma parte de una herramienta CASE, etc.
Programacin de bases de datos Una base de datos tiene un lenguaje de programacin que permite manipularla y utilidades. Un lenguaje de cuarta generacin es el lenguaje de programacin de la base de datos y su entorno. Son interesantes las
herramientas que permiten acceder a la base de datos a travs de un navegador ya que as se puede acceder desde cualquier
punto.
Componentes reutilizables El principio en el que descansan los componentes es que es ms rpido usar software hecho que
hacerlo, por ejemplo, los beans de Java. Si adems existe algn mecanismo que permita que esos componentes se comuniquen y
se integren fcilmente, 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 desarrollarlos.
41
2. Los componentes existen, pero no son exactamente lo que se necesita y hay que adaptarlos.
El desarrollo de prototipos con reutilizacin se puede hacer a dos niveles:
1. Nivel de aplicacin: Los sistemas que componen la aplicacin pueden ser compartidos por otras aplicaciones. Por ejemplo:
se puede insertar un grfico desarrollado con una aplicacin en otra. Las aplicaciones actan como si estuvieran conectadas
entre si al estilo de las tuberas de Unix.
2. Nivel de componente: Los componentes estn integrados en un armazn estndar, como puede ser un lenguaje de desarrollo de componentes, por ejemplo: P YTHON o P ERL o algo ms general como CORBA, DCOM o JAVA B EANS.
JAVA B EANS es un ejemplo de componentes reutilizables. Son un tipo de componentes escritos en Java, que generalmente tienen
algn tipo de interfaz grfica (Enterprise-JavaBeans sin embargo no es as, pues se ocupa ms de la lgica de la aplicacin). Sus
caractersticas son:
1. Tienen un constructor predeterminado sin parmetros (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 flujo de bytes para por ejemplo poder
ser escrito en disco o recuperado del mismo.
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 mtodos de la forma: getX() y setX(Propiedad
propiedad). Si la propiedad es booleana en vez de getX() se usa isX(). Si la propiedad es indexada se utiliza: getX(int
index) getX() que devuelve un array y los mtodos para asignar valor seran: setX(int index, propiedad)
setX(Propiedad[] propiedad).
Casos de uso
Son una forma de especificar los requisitos de un sistema. Un caso de uso consiste en una interaccin de algo externo al
sistema y el sistema. Fueron introducidos por Jacobson en 1992. Aunque es una tcnica definida dentro del ambiente del anlisis
orientado a objetos no tiene que ver con objetos, se podra utilizar perfectamente dentro del anlisis estructurado. Ms adelante
veremos la tcnica de los casos de uso con el ejemplo gua (ver tema 2) de la aplicacin web. Un caso de uso:
Describe la interaccin 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 observable
por 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 visin de esa funcionalidad.
Identificar conceptos del sistema, clases, atributos y operaciones.
Validar el anlisis y el modelo del diseo.
Proporcionar informacin para las pruebas del sistema y de aceptacin.
Existen dos tipos de elementos:
1. Actores: El actor puede ser tanto una persona como otro sistema que juega un rol en la interaccin con el mismo. Un
mismo rol puede ser desempeado por varias personas y una persona puede desempear ms de un rol. Un usuario no es
un actor, sino que asume un rol cuando interacta con el sistema y por lo tanto funciona como un tipo de actor.
2. Caso de uso: Es la interaccin que se quiere modelar. Pueden agruparse en paquetes y tener relaciones entre ellos.
Identificar actores Un caso de uso se compone de actores y de interacciones de esos actores sobre el sistema. por lo tanto, lo
primero es buscar actores. Teniendo en cuenta lo que es un actor, hay que encontrar la siguiente informacin:
1. Identificar los usuarios del sistema. Para ello tener en cuenta para quien se est diseando o con que personas va a
interactuar de un modo directo (actores principales) y quienes va a tener un papel de supervisin o mantenimiento del
sistema (actores secundarios).
2. Identificar 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. Identificar otros sistemas con los cuales exista comunicacin. Estos sistemas tambin se consideran como actores dado
que son algo externo a nuestro sistema.
42
Fase de requisitos
Identificar operaciones Una vez que se tienen los actores se trata de encontrar los casos de uso, como lo que tenemos en este
momento son los actores, partimos de esta base para encontrar la informacin que falta. Los actores interactuaran con el sistema
realizando un conjunto de tareas que tendremos que enumerar y manejarn informacin, tanto la que suministren al sistema
como 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 las
relaciones 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 diferencias
adaptadas a la forma particular en la que se realiza una tarea.
Aquellas en las que uno usa a otro: En esta situacin un caso de uso es similar a una funcin o subrutina que es llamada
por 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 que
responder. No supone un dilogo como un caso de uso porque ocurre de un modo atmico. Los pasos a seguir en este caso son
por un lado identificar todos los eventos a los que el sistema tiene que responder y luego relacionarlos con los actores adecuados.
Una vez identificados 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 significativas.
Existen diferentes versiones del mismo caso de uso con variaciones significativas.
2. Buscando el caso de uso opuesto a uno dado, por ejemplo, si tengo dando de alta cliente podra existir el caso de uso dando
de baja cliente
3. Preguntarnos que tiene que ocurrir para que se cumplan las precondiciones de un caso de uso, por ejemplo, para hacer un
pedido es necesario que el cliente entre con su password, con lo que tiene que existir un caso de uso para dar de alta.
Dar detalle a los casos de uso descritos Esto que se ha descrito hasta ahora es la forma de construir un armazn de casos de
uso, veamos como se pueden concretar un poco ms. Para cada caso de uso hay que:
Describir la informacin de entrada y de salida.
La descripcin detallada del caso de uso contiene:
Una descripcin textual de su objetivo.
Variantes posibles para realizar este caso de uso. Diagramas de interaccin de detalle (de secuencia o colaboracin).
Errores y excepciones posibles.
Relacionar el caso de uso con la interfaz de usuario que lo representa.
Especificar el dilogo que da solucin al caso de uso.
La descripcin de un caso de uso consta de los siguientes elementos:
1.
2.
3.
4.
Descripcin del escenario.

Suposiciones acerca del escenario.
Condiciones previas para el caso de uso.
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 excepcin y no tienen suficiente
entidad como para ser un caso de uso al que se llegue con una relacin extiende.
5. El nombre del caso de uso se pone en gerundio.
6. Se pone el actor responsable.
7. Resultado una vez terminado el caso de uso.
Aplicacin al Ejemplo A del captulo 2: Veamos primero el caso de uso Dando de alta cliente del ejemplo A en el captulo 2
(ver tabla 3.1). El cliente se relaciona con el sistema con un navegador y lo hace desde su empresa. Una vez terminado, el cliente
queda registrado en la base de datos de la empresa propietaria de la pgina web.
En este ejemplo vemos un caso de uso que opcionalmente puede utilizar a otro (Recogiendo pedido de cliente). En el ejemplo
de la aplicacin web los casos de uso podran ser: Dando de alta cliente, Dando de alta proveedor, Recogiendo pedido de cliente,
Recogiendo oferta de proveedor, Actualizando contenido de la pgina, Solicitando reposicin y Seleccionando proveedor. El
caso de uso seleccionando proveedor puede ser utilizado por otro caso de uso o por el actor Gerente. En la figura 3.2 tenemos la
representacin de las relaciones entre casos de uso.
Actores y casos de uso abstractos
Un caso de uso que slo exista para ser utilizado por otros casos de uso se dice que es abstracto. Como ese caso de uso no
tiene un actor que lo utilice, nos inventamos un actor ficticio (abstracto). En el ejemplo A del captulo 2 tenemos el caso de
uso abstracto Seleccionando proveedor. El actor abstracto que creamos para este caso le damos el nombre: Seleccionador de
43
Caso de uso: Dando de alta cliente

Actor: Cliente
Curso normal
Alternativas
1) El cliente comunica sus datos
2) El sistema asigna una
2.1) Si e cliente ya est
contrasea al cliente
registrado se informa del error
3) Si el cliente lo desea inicia
por primera vez el caso de uso
Cuadro 3.1: Caso de uso para dar de alta un cliente en el ejemplo gua A
Dando de alta proveedor

Dando de alta cliente
Extiende
Extiende
Recogiendo oferta de proveedor

Seleccionando proveedor
Usa
Actualizando contenidos
Cliente
Proveedor
Solicitando reposicion
Gestor
Figura 3.2: Casos de uso de la aplicacin web

proveedor. La manera en la que se relaciona este nuevo actor ficticio con 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 utiliza un caso de uso abstracto heredarn de l. En nuestro ejemplo,
Proveedor hereda de Seleccionador de proveedor (ver figura 3.3). Un actor puede heredar de cualquier otro, tanto si es abstracto
como si no, con lo que hereda tambin todas las funcionalidades a las que puede acceder.
Seleccionador de
proveedor
Proveedor
Figura 3.3: Un actor hereda de otro
Otras clasificaciones de los casos de uso

Casos de uso esenciales y de implementacin
Cuando se est en la fase inicial de recopilar todos los casos de uso, no se
ponen en detalle, se indica su nombre y poco ms (casos de uso esenciales, o de trazo grueso). Cuando se va a implementar el
caso de uso hay que definirlo con ms detalle (caso de uso de implementacin o trazo fino).
Casos de uso temporales Son aquellos iniciados no por un actor, sino por un evento de reloj. Se debe indicar el momento en
el que esto ocurre, p. ej.: cada 500 milisegundos. La notacin consiste en poner el caso de uso en un valo con lnea de puntos o
con smbolo de reloj.
44
Fase de requisitos
Casos de uso primarios y secundarios

Los casos de uso secundarios son aquellos que existen por que son necesarios para
que el sistema funcione pero que no son inherentes a su funcionalidad.
3.2. Anlisis de requisitos

Una vez que hemos extrado 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 esperadas
del conjunto. En este apartado se estudiarn las diferentes estrategias o patrones de modelado del problema.
El contenido de este apartado se estudia en [Pre01, secs. 11.1 a 11.3].
3.3. Representacin de requisitos

Como resultado del anlisis de los requisitos especificados inicialmente, se obtiene un modelo del problema que es necesario
representar de una manera formal que permita la aplicacin de tcnicas sistemticas para su resolucin. Existen diversos lenguajes y mtodos de especificaciones que tienen caractersticas diferentes segn el mtodo posterior del desarrollo. Por ejemplo
diagramas entidad-relacin para modelado, diagramas contextuales, plantillas o marcos conceptuales, diagramas funcionales,
etc. El mtodo ms extendido de representacin es mediante tcnicas orientadas a objetos y los lenguajes asociados a ellas.
El contenido de este apartado se estudia en [Pre01, sec. 11.5 y cap. 12].
3.4. Anlisis orientado a objetos

El anlisis orientado a objetos representa el problema en trminos de clases, sus propiedades y sus relaciones. El modelo que
resulta de este anlisis utiliza tcnicas muy diversas, algunas como la de los casos de uso son perfectamente aplicables tambin al
anlisis estructurado. La ventaja del anlisis orientado a objetos es que la representacin que se logra del mundo es ms prxima
a la realidad. La transformacin de los requisitos en trminos de usuario a la especificacin en trminos de sistema informtico
es ms suave.
El contenido de este apartado se estudia en [Pre01, cap. 21] .
3.5. Validacin de requisitos

Es importante que antes de continuar el desarrollo del software a partir de los requisitos modelados y representados se haga
la comprobacin de su validez, comparando la correspondencia con las descripciones iniciales y si el modelo responde a lo
realmente deseado. Esta parte de la fase de requisitos se suele realizar comprobando que el modelo obtenido responde de la
misma 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 se
haga una idea aproximada del resultado.
Definicin
La validacin de los requisitos comprueba que estos son correctos. Esta fase debe realizarse o de lo contrario se corre el
riesgo de implementar una mala especificacin, con el costo que eso conlleva.
Los parmetros a comprobar por la especificacin son [Som01]:
1. Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener puntos de vista distintos y
necesitar 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 iteracin en curso.
4. Realismo: Se pueden implementar con la tecnologa actual.
5. Verificabilidad: Tiene que existir alguna forma de comprobar que cada requisito se cumple.
El contenido de este apartado se completa con [Pre01, sec. 11.6].
3.6. Bases de documentacin

Ya desde los primeros pasos del desarrollo del software es necesario comenzar a organizar toda la documentacin. En primer
lugar se han de gestionar los formatos en los que se va a escribir la documentacin. Preferiblemente se deben utilizar herramientas de ayuda que semi-automatizan la recopilacin de la documentacin durante el desarrollo. Evidentemente, tanto las
especificaciones iniciales del problema (en lenguaje natural probablemente) como las especificaciones finales de los requisitos
(en un lenguaje formal), pasando por los estados intermedios de anlisis y modelado y las diferentes pruebas de validacin se
deben guardar como parte inicial de la documentacin.
3.6 Bases de documentacin
45
El documento de especificacin de requisitos SRS (Software Requirements Specification) es como el contrato oficial que se
establece entre los desarrolladores y los clientes. Incluye tanto los requisitos funcionales como los no funcionales. Una recoleccin correcta y completa es crucial para el desarrollo de un sistema de informacin exitoso. Para alcanzar el mayor grado de
calidad es esencial que el SRS sea desarrollado de un modo sistemtico e inteligible, en cuyo caso reflejar las necesidades del
usuario y ser til para todos. Lo que sigue es una plantilla del SRS segn el estndar IEEE 830.
En la portada se indican: Nombre de la empresa, Nombre del proyecto, Nmero de versin y Fecha.
El ndice debe constar de las siguientes secciones: Introduccin, Descripcin general, Requisitos especficos, Gestin del
cambio del proceso, Aprobacin del documento e Informacin de soporte. El desarrollo del ndice anterior debe contener la
siguiente informacin:
1. Introduccin. Las siguientes subsecciones dan una visin general del documento.
a) Propsito: Identifica el propsito del documento y el perfil de usuario al que est dirigido.
b) Alcance. En esta subseccin:
Se identifica 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 especificado, incluyendo beneficios y objetivos.
Se debe ser consistente con especificaciones similares de ms alto nivel si existen, es decir, en el caso de que
estas sean las especificaciones de un subsistema.
c) Definiciones, acrnimos y abreviaturas: Es un listado de las definiciones de todos los trminos, acrnimos y abreviaturas necesarios para interpretar correctamente el SRS. La informacin puede ser proporcionada con referencias a
apndices.
d) Referencias:
Se da la lista completa de todos los documentos referenciados en cualquier lugar de la SRS.
Se identifica cada documento por ttulo, versin, fecha y responsable de su redaccin.
Se especifican las fuentes desde las que se pueden obtener las referencias.
e) Visin de conjunto: Describe la organizacin general de la SRS.
2. Descripcin general: Describe los factores generales que afectan al producto y sus requisitos. No se definen requisitos
especficos (seccin 3), slo su contexto.
a) Perspectiva del producto: Relacin del producto con otros similares. Si el producto es independiente y autocontenido
se debe decir aqu. Si es un componente de un sistema mayor aqu deben estar los requisitos para que el sistema mayor
lo pueda utilizar e identifica las interfaces entre el sistema y el software. Se puede poner un diagrama de bloques para
mostrar las interconexiones del sistema con otros e interfaces externas.
b) Interfaces del sistema: Identifica la funcionalidad del software y la descripcin de la interfaz. Especifica:
Caractersticas lgicas de cada interfaz entre el producto y sus usuarios.
Todos los aspectos relativos a la optimizacin de la interfaz con los usuarios.
1) Interfaces hardware: Se especifican las caractersticas de cada interfaz entre el producto y los componentes
hardware. Incluye la configuracin, dispositivos soportados, cmo 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, Mnemnico, Nmero de versin y Fabricante.
b Para cada interfaz se debe desarrollar en: Motivos para interactuar con el producto y Definicin 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 especficas tales como:
1)
2)
3)
4)
Modos de operacin en la empresa del usuario.

Operaciones interactivas y no interactivas.
Funciones de proceso de datos.
Operaciones de backup.
e) Requisitos de instalacin. Se definen:

1) Requisitos para datos y secuencias de inicializacin especficos para un emplazamiento, misin o modo de
operacin.
2) Caractersticas 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 especificaciones de alto nivel. Este resumen:
46
Fase de requisitos
Debe ser inteligible por el cliente con una sola lectura.

Se pueden utilizar elementos textuales o grficos para mostrar las diferentes funciones y sus relaciones. No es
un grfico del diseo, slo muestra relaciones lgicas entre funciones y variables.
g) Caractersticas del usuario: Es una lista de aptitudes y motivos para ellas.
h) Restricciones: Descripcin general de limitaciones que afectarn a los desarrolladores tales como: Polticas, Limitaciones 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
diseo pero un cambio en ellos afectara a los requisitos.
j) Requisitos no implementados: Lista de requisitos que se dejan para futuras versiones.
3. Requisitos especficos: Es una lista de los requisitos a un nivel de detalle lo suficientemente fino que permita a los desarrolladores disear un sistema que los satisfaga. Deben incluir las entradas, las salidas y las funciones suministradas en
respuesta a entradas o para suministrar una salida.
a) Interfaces externos: Es una lista detallada de todas las entradas y salidas. Complementa las descripciones de interfaz
en el apartado 2b pero sin repetir informacin.
b) Requisitos funcionales: Definen las acciones que el software tiene que tomar para producir las salidas a partir de las
entradas. Ejemplos:
Comprobar la correccin de la entrada.
Secuencia correcta de las operaciones.
Respuestas a situaciones anormales.
Relaciones entre entradas y salidas.
c) Requisitos de rendimiento: Especifica requisitos estticos y dinmicos. Un requisito esttico de rendimiento puede ser el nmero de usuarios conectados simultneamente. Un requisito dinmico sera por ejemplo el nmero de
transacciones por minuto. Estos requisitos deben especificarse en unidades medibles.
d) Requisitos relativos a bases de datos: Requisitos lgicos que tiene que tener la informacin que se deje en la base de
datos. Por ejemplo: Tipos de informacin, frecuencia de uso, etc.
e) Restricciones de diseo: Restricciones de diseo que pueden ser impuestas por otros estndares, limitaciones de
hardware, etc.
1) Conformidad con los estndares: Requisitos derivados de la existencia de estndares. Por ejemplo: Formato de
los informes, nombre de los datos, procedimientos de contabilidad o auditoras.
f ) Atributos del sistema software: Son propiedades del sistema. El hecho de tenerlas constituye un requisito. Los ms
importantes son: Fiabilidad, Disponibilidad, Seguridad, Mantenibilidad y Portabilidad.
g) Organizacin de los requisitos. Los requisitos deben ser presentados de un modo jerrquico para que la cantidad de
informacin no sea abrumadora para el lector y se puedan comprender con facilidad. No existe un modo ptimo para
presentarlos. Esto es una lista de posibles criterios.
Modo del sistema: Es el modo de operacin. Algunos sistemas se comportan de un modo muy distinto en funcin
del modo en el que estn.
Clases de usuario: En funcin de a quin est dirigido interesar resaltar unas funciones u otras.
Objetos: Se pueden agrupar las funciones en trminos de las suministradas por jerarquas de objetos.
Caractersticas: Son servicios observables externamente que puede requerir una secuencia de entradas y salidas
en un orden concreto.
Estmulo: Algunos sistemas se describen mejor en trminos de estmulo - respuesta.
Respuesta: Clasificacin en funcin del tipo de respuesta que da el sistema.
Jerarqua funcional: Se trata de organizar el sistema en trminos de funciones con entradas y salidas similares.
h) Comentarios adicionales.
4. Gestin del cambio del proceso: Seleccionar la gestin del proceso de cambio que deba ser usada para identificar, registrar,
evaluar y actualizar el SRS para que refleje el alcance de los cambios en el proyecto y sus requisitos.
5. Aprobacin del documento: Identificar a las personas que deben dar su visto bueno. Deben constar su nombre, firma y
fecha.
6. Informacin de soporte. Hace que este documento sea ms fcil de usar. Incluye ndice y apndices.
Tutorial posterior
En este captulo se ven las formas de captura de requisitos y su representacin. La finalidad de esta fase es producir un
documento que represente los requisitos y que sirva de entrada para la fase de diseo. El anlisis es la forma de conseguir los
3.6 Bases de documentacin
47
requisitos y la especificacin la forma de representarlos.

Tcnicas de obtencin de requisitos
1. Entrevistas: Consiste en hablar con el cliente. Hay que tener sobre todo conocimientos de psicologa para facilitar la
comunicacin.
2. JAD: Consiste en un tipo de entrevista muy estructurada aplicable a grupos de personas. Cada persona juega un papel
concreto y todo lo que se hace est reglamentado.
3. JRP: Es un subconjunto de JAD.
4. Brainstorming: Es un tipo de entrevista que se caracteriza precisamente por lo contrario que la anterior. No tiene ningn
tipo de estructura.
5. Prototipos: Se trata de construir una mini-aplicacin inicial para clarificar algunos puntos y luego tirarla o bien para usarla
como base para aadir ms cosas.
6. Casos de uso: Representan grficamente los requisitos funcionales y relaciones de uso y generalizacin entre ellos. Es la
tcnica definida en UML. No est necesariamente asociada a la programacin orientada a objetos, puede usarse tambin
con metodologas ms clsicas.
Anlisis de requisitos
Caractersticas del anlisis antes de la existencia de tcnica alguna del tema: Monoltico, ambiguo, difcil de mantener y
redundante. Posteriormente (aos 70 y 80) surge el anlisis estructurado moderno que es grfico y soluciona algunos de los problemas anteriores. Su objetivo es modelar por separado los datos, procesos y el control usando como nexo comn el diccionario
de datos.
Tcnicas de representacin de requisitos
1. Diagramas de flujo de datos: Se describen los elementos de los que consta, lo que es el diagrama de contexto y heursticas
para desarrollarlo.
2. Diagramas de flujo de control: Es similar a los DFD.
3. Diagramas de estados: Son un tipo de modelizacin matemtica usada tambin en diseo de circuitos, compiladores, etc.
4. Modelo Entidad / Relacin: Usado para representar los datos y la forma en la que se relacionan entre ellos.
5. Diccionario de datos: Se puede definir como el pegamento que mantiene unido a todo lo anterior. Es una descripcin
detallada de los datos.
Anlisis orientado a objetos
Es la otra forma de ver el problema. Se representa el mundo en funcin sobre todo de los datos, caractersticas e interrelaciones entre ellos en vez de en funcin de los algoritmos o funciones.
Propiedades de un sistema orientado a objetos: Abstraccin, Encapsulamiento, Modularidad, Jerarqua, Polimorfismo, Persistencia.
Conceptos importantes: Clase, Objeto y Atributos.
Sesin CRC: Es una simulacin hecha por personas del funcionamiento dinmico de un sistema orientado a objetos. Se basa
en que cada persona representa una clase y su interaccin con las dems. Cada clase tiene escritas sus propiedades en una
tarjeta.
Identificacin de clases, atributos y relaciones entre clases.
Refinamiento del modelo: Consiste en otro conjunto de heursticas para eliminar elementos sobrantes o identificar otros nuevos
en el modelo anterior.
Validacin de requisitos
Es la comprobacin de que todo el trabajo anterior se ha realizado bien.
Bases de documentacin
Es el documento que resulta de todo lo anterior pero orientado al cliente, es decir, a las obligaciones contradas con l, la idea
no consiste en usar este documento como entrada para otra fase. Se ha tomado la plantilla de documento definida por el estndar
IEEE 830.
48
Fase de requisitos

1. Compare los diagramas del anlisis estructurado y los del UML. Existen similitudes?
1. Qu diferencia existe entre los requisitos que se obtienen en una sesin JAD y una sesin JRP?
2. Si se tiene que construir un sistema novedoso en el que los requisitos estn claros pero se tienen dudas tcnicas acerca de
la mejor solucin discuta que tipos de sesiones seran las ms adecuadas.
3. Un videoclub tiene diferentes tipos de precios para sus pelculas en funcin de su categora. Cada pelcula tiene un cdigo
y aunque haya varias pelculas con el mismo ttulo el cdigo es distinto para cada una. Los datos que interesa guardar de
cada pelcula son: Ttulo, Director, Actores principales, Localizacin, Categora y Cdigo. Los clientes tienen asignado un
Cdigo de cliente y se conoce tambin su Nombre, Direccin, Telfono. El videoclub hace prstamos a sus clientes por
dos das y se podr sancionar a quien se retrase segn el nmero de das.
Desarrolle los DFD que sea posible.
Desarrolle la especificacin de los procesos.
Sobre la obtencin, anlisis y representacin de requisitos tambin se puede estudiar en [Som98, cap. 2 y 3], [Haw98, caps.
5 al 10] [Sch92, caps. 3 y 4]. Sobre el anlisis orientado a objetos tambin se puede ver [RBP+ 96].
El libro [GW89] completo es especfico sobre requisitos.
O UTREACH P ROJECT T OOL es una plataforma de libre distribucin para gestin de proyectos a travs de Web muy orientada
al manejo de los requisitos y la comunicacin entre desarrolladores y clientes. Ver en http://outreach.sourceforge.net/
(hay enlace a una demo interactiva).
Captulo 4
Fase de diseo
Tutorial Previo
Introduccin
Una vez que se han identificado los requisitos para el problema, es necesario idear y componer la forma de la solucin para
el problema. El diseo es la fase en la que se estudia el problema, se identifican las caractersticas que tendra una solucin y
se analiza a su vez cada una de esas caractersticas. En la fase de diseo es ms efectivo utilizar patrones y modelos conocidos
para ir resolviendo partes del problema, es decir modularizar el problema y proyectarlo en mdulos en la solucin. Aunque, el
proceso de diseo es en gran medida ad hoc, es decir, no est tan formalizado como las otras fases y por tanto se apoya bastante
en la experiencia e intuicin de los diseadores.
En este tema se van a proponer las formas de diseo convencionales, una comparacin de los ms utilizados y la validacin
o comprobacin de su adecuacin, junto con la parte correspondiente de documentacin de todo el proceso. Principalmente hay
dos tipos de diseo:
Diseo funcional: Parte de una vista de alto nivel que se va refinando progresivamente. En este caso la atencin se focaliza
en la forma de procesar los datos.
Diseo orientado a objetos: Se entiende el sistema como un conjunto de objetos. Para distinguirlos se identifican los tipos
de datos, sus operaciones y atributos asociados. Los objetos se comunican entre ellos envindose mensajes.
La validacin del diseo comprueba si se siguen las especificaciones del diseo y se cumplen requisitos de calidad. La mejor
forma de redactar la documentacin consiste en seguir una plantilla de un documento estndar rellenando varias secciones.

Para la comprensin de este tema es conveniente tener en mente los diferentes modelos de programacin que han ido estudiando en la carrera y que se utilizarn despus en la fase del tema siguiente. Tambin es necesario haber preparado el tema
de requisitos para entender cules son los elementos de entrada en el diseo. Es necesario saber: descomponer un problema en
otros ms pequeos, identificar las estructuras de datos necesarias e identificar flujos de datos entre subsistemas y cules son las
entradas y salidas necesarias para cada subsistema.
Objetivos del tema

Se deben obtener los conocimientos sobre las tcnicas de diseo ms efectivas y utilizadas, junto con la comprensin de las
diferencias entre esas tcnicas que permitan conocer cul es el mtodo ms apropiado en cada situacin. Se pretende en este
tema introducir los dos tipos de mtodos que existen de disear un sistema y proporcionar un mtodo genrico para redactar la
documentacin.

A la vez que se estudia el contenido terico 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 diseo es en gran medida ad hoc y depende de la experiencia de los diseadores. El
mejor mtodo para aprender a disear es realizar todos los ejercicios propuestos (tanto explcitos, en el tutorial posterior, como
implcitos o genricos mencionados anteriormente).
Conceptos y elementos del diseo. El contenido de este apartado corresponde con [Pre01, cap. 13].
Diseo estructurado. Este apartado se estudiar en [Pre01, caps. 14 y 16] .
Diseo orientado a objetos. Este apartado se estudiar principalmente [Pre01, cap. 22].
Validacin y confirmacin del diseo. Este apartado se incluye en esta misma gua.
Documentacin: especificacin del diseo. Este apartado est contenido en [Pre01, sec. 13.8].
49
50
Fase de diseo
4.1. Conceptos y elementos del diseo

Partiendo de los requisitos para el problema, es necesario decidir cmo se va a realizar la solucin para el problema. Existen
unos cuantos principios de diseo bsicos y elementos que se deben considerar antes de ponerse a decidir un diseo en particular.
En primer lugar el principio de modularidad est presente en casi todos los aspectos del diseo al igual que en muchas otras
reas de ingeniera. Junto con las especificaciones funcionales y de datos hay que considerar tambin el diseo de la interfaz y el
acoplamiento de las diferentes partes.
El contenido de este apartado se estudia en [Pre01, cap. 13].
4.2. Diseo estructurado

Para realizar el diseo de una solucin a un problema concreto se pueden utilizar diferentes enfoques, segn se basen en los
datos en la funcionalidad o en la interaccin. En este tema se describen los dos mtodos ms utilizados: estructurado y orientado
a objetos. El diseo estructurado con estilo procedimental (o funcional) descendente, en el cual se van refinando y dividiendo los
mdulos funcionales de la solucin, se basa en la utilizacin de los elementos: secuencia, condicin y repeticin.
El contenido de este apartado se estudia en [Pre01, caps. 14 y 16].
4.3. Diseo orientado a objetos

El otro tipo de mtodos de diseo es el diseo orientado a objetos, que se basa en dividir jerrquicamente los elementos del
diseo (objetos) y encapsular conjuntamente los datos con sus funciones de acceso, de forma que la interaccin se realiza por
paso de mensajes entre los objetos.
El contenido de este apartado se estudia en [Pre01, cap. 22].
4.4. Validacin y confirmacin del diseo

Para cerrar un paso en la fase de diseo es necesario hacer la validacin de los resultados obtenidos y comprobar si cumplen
con las especificaciones de requisitos que eran la entrada a esta fase. Se trata de un conjunto de actividades para garantizar que se
esta construyendo el producto correcto de la manera adecuada. Cada una de las actividades del diseo deben estar reflejadas en
los planes del mismo, estos planes se actualizaran cuando sea necesario para adaptarse a los cambios que vayan surgiendo pero
cada cambio deber ser revisado y aprobado.
Debe existir un procedimiento de control de diseo que especifique cmo se planifica y desarrolla. Por otra parte, la informacin de entrada al diseo, que es la resultante de la fase anterior debe incluir adems de los requisitos del usuario cosas tales como
requisitos legales y regulaciones que se apliquen al proyecto. Las entradas al diseo deben tener en cuenta cualquier modificacin
del contrato. Los resultados del diseo deben ser documentados de forma que se pueda hacer una verificacin y validacin de los
mismos.
4.4.1. Revisin del diseo

Durante el proceso de diseo se deben planificar algunas revisiones formales del trabajo que se va realizando. Los participantes son todas aquellas personas involucradas en el diseo que se est revisando, as como representantes del cliente. Cuando
finalice la revisin se debe redactar un documento con el resultado de la revisin y las partes afectadas. La forma de revisar el
diseo estar documentada en el procedimiento de control del diseo.
4.4.2. Verificacin del diseo

Las actividades que se realizan son:
Realizacin de clculos alternativos.
Comparacin con diseos preliminares si es aplicable.
Pruebas y demostraciones
Revisin del diseo.
4.4.3. Validacin del diseo

Garantiza que el producto cumple con los requisitos definidos por el cliente. Se realiza despus de la verificacin si esta fue
satisfactoria. Una validacin se realiza en un entorno operativo normal. Tambin esto se realizar conforme al procedimiento de
control del diseo.
4.5 Documentacin: especificacin del diseo
51
4.5. Documentacin: especificacin del diseo

Evidentemente uno de los puntos ms importantes en la documentacin es la especificacin del diseo. Dado que el diseo
tiene una gran componente de invencin, es necesario dejar muy claramente documentadas las decisiones y elementos utilizados
en el diseo. Adems el diseo ser el elemento clave para la fase siguiente de implementacin que debe seguir fielmente los
dictados del diseo.
Para dejar constancia de los diseos se deben utilizar lenguajes lo ms formales posible, como tablas, diagramas y pseudocdigo, que en algunos casos pueden permitir incluso la utilizacin de herramientas para automatizar parcialmente el proceso de
construccin del cdigo en la siguiente fase de implementacin.
El contenido de este apartado est incluido en [Pre01, sec. 13.8].
Tutorial posterior
El diseo es la fase que sigue a la especificacin y el anlisis. Consiste en aadir a la representacin anterior los detalle
necesarios para pasar a la implementacin. Al igual que en el captulo anterior, existen 2 tipos de diseo: orientado a objetos y
estructurado. Tambin existen diferentes formas de realizarlo en funcin de caractersticas del sistema (tiempo real, distribuido,
etc.)
Diseo arquitectnico: Independientemente del tipo de diseo (estructurado u orientado a objetos) existe una primera fase que
consiste en la divisin del sistema en subsistemas. Los apartados a tener en cuenta son:
1. Descomposicin estructural: Descomposicin en subsistemas
2. Intercambio de informacin 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 tendencia
actual. 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 definicin de interfaces. {ATENCIN: CORBA No se trata en este curso, ver en [Pre01, cap. 28]}
Diseo estructurado
Es el anlisis clsico. Esta basado en el flujo de los datos a travs del sistema. En una primera fase se hace un diseo
preliminar y posteriormente un diseo detallado. Objetivos: Comprensin, mantenibilidad, facilidad de pruebas e integracin
con otras aplicaciones. Principios: Abstraccin, modularizacin, independencia, arquitectura, ocultamiento de la informacin y
refinamiento paso a paso. Sus elementos importantes son:
1.
2.
3.
4.
5.
Mdulo: El rbol de mdulos define las relaciones entre los mismos.

Tabla de interfaz: Especifica como son las comunicaciones inter-mdulos.
Cohesin: Un mdulo es cohesivo si sus tareas se realizan con independencia del sistema pero relacionadas entre s.
Acoplamiento: Media de la complejidad de las interfaces de un mdulo.
Diagrama de estructuras: Es un mtodo de descomposicin funcional donde el bloque bsico es el mdulo. Es un rbol
o diagrama jerrquico. Se definen en l: bucles, alternativas y subrutinas.
6. Heursticas de diseo: Consejos a aplicar.
7. Tipos de flujos de informacin: Flujos de transformacin y de transaccin.
Diseo detallado: Es una especificacin con mayor nivel de detalle de las estructuras de datos y algoritmos.
Otras notaciones que forman parte de metodologas pensadas en torno al diseo estructurado son:
1. Diagramas HIPO: Muestran entradas, salidas y funciones. Muestran lo que hace el sistema pero no el cmo. {ATENCIN: los diagramas HIPO No se tratan en este curso}
2. Diagramas de Warnier-Orr: Son una representacin jerrquica de los programas, sistemas y estructuras de datos. Puede
representar iteraciones, secuencias y alternativas.
3. Diagramas de Jackson: Produce un programa a partir de su especificacin. Las entradas y salidas son secuenciales al
igual que el proceso.
52
Fase de diseo
Diseo orientado a objetos

Como se ha dicho antes, es la otra forma de hacer el diseo. Se incluye tambin en este resumen el diseo arquitectnico por
ser parte integrante de la metodologa, aunque lo dicho en el apartado anterior dedicado al tema es igualmente vlido. Hay dos
partes:
1. Diseo del sistema = (Diseo arquitectnico)
2. Diseo de objetos = (Diseo detallado)
Patrones: Consisten en la identificacin de problemas usuales en el anlisis, diseo, codificacin, etc e incluir una plantilla de
solucin.
Frameworks: Son otro mecanismo de reutilizacin pero un framework se puede componer de varios patrones. Generan aplicaciones para un dominio.
Validacin y confirmacin del diseo
Son un conjunto de actividades que garantizan que el producto se est construyendo de la forma adecuada. Se compone de la
revisin, la verificacin y la validacin del diseo.
Documentacin
Se incluye una plantilla para redactar el documento correspondiente al igual que en la fase anterior.

1.
2.
3.
4.
Cules son las principales diferencias entre el diseo estructurado y el orientado a objetos?
Por qu el diseo arquitectnico es el primer paso?
Cules son los tipos de modelos cliente-servidor de tres capas?
{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} Cul es la secuencia de pasos que ocurre cuando un cliente utiliza los servicios
de un servidor en CORBA? Podra el servidor ser cliente de su cliente?
6. Qu nivel de acoplamiento hay entre dos mdulos A y B donde A utiliza una funcin de B pero ambos manipulan el
mismo conjunto de variables globales?
Los contenidos de este tema tambin pueden estudiarse en [Som98, cap. 4], [Haw98, caps. 11 al 14] [Sch92, caps. 5 al 8].
Se puede profundizar en el diseo orientado a objetos, por ejemplo, en los libros [RBP+ 96, Mey98, Boo94, Jac92, WBWW90].
En http://www.nist.gov/dads/ se puede encontrar una recopilacin en forma de diccionario (en ingls) de descripciones
y enlaces sobre algoritmos, estructuras de datos y problemas.
Se puede encontrar informacin sobre CORBA (Arquitectura comn de distribucin de objetos) en [Pre01, sec. 28.9.5] y
tambin un tutorial en la pgina web http://java.sun.com/developer/onlineTraining/corba/corba.html, aparte, por
supuesto, de la pgina propia de CORBA http://www.corba.org/.
Captulo 5
Fase de implementacin
Tutorial Previo
Introduccin
Una vez que se dispone de un diseo para la solucin del problema, incluso en una fase temprana o provisional del diseo,
ya se puede comenzar a plasmar ese diseo en el cdigo que permita realizarlo o implementarlo. En esta fase el programador
recibe las especificaciones del diseo y transforma esas especificaciones, que pueden estar en formatos mezclados formales,
semiformales o manuales, en un programa o mdulo que las efecte. Esta tarea de modificacin puede estar semi-automatizada
en algunos casos o realizarse de forma completamente manual. En cualquiera de los casos se requiere que esa transformacin
se haga de manera sistemtica y coherente. Las particularidades propias de lenguajes de programacin concretos se estudian en
otras asignaturas y por tanto no se incluirn en este tema. Lo que s se estudiarn son las tcnicas o estilos de codificacin formal.
Durante la implementacin se escribe el cdigo de la aplicacin. Existen una serie de "vicios" en el estilo de codificacin que
pueden hacer que el cdigo sea confuso para terceras personas y en consecuencia difcil de mantener; adems, algunas prcticas
pueden inducir errores. Es especialmente recomendable para esta parte seguir las recomendaciones del PSP (Personal Software
Process). Para realizar el trabajo este debe ser dividido en pequeos mdulos que se reparte entre individuos o pequeos grupos
atendiendo a un grfico de dependencias entre tareas y con la idea en mente de paralelizar tanto trabajo como sea posible. A
medida que se van haciendo los mdulos hay que comprobar que cumplen con una cierta calidad, para ello existen varios tipos de
pruebas. En este capitulo se estudia la necesidad de comprobar la ejecucin correcta del mdulo, por tanto interesan las pruebas
que se hacen a nivel de mdulo, tambin llamadas pruebas unitarias. Adems de todo ello hay dos tipos de manuales importantes
que hay que producir en esta etapa: el manual de usuario y el manual tcnico.

En este captulo el alumno debe recordar los conocimientos sobre programacin 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 codificacin y la depuracin. Para comprender la problemtica asociada a la programacin es necesario conocer muy bien al menos un lenguaje de programacin y tener
alguna experiencia con l. Se puede considerar que con las prcticas de programacin de cursos pasados es suficiente.
Objetivos del tema

Los objetivos de este tema son resaltar la importancia de que la codificacin de los programas se haga de una forma ordenada,
sistemtica y documentada, as como de la necesidad de realizar pruebas y depuracin de errores propios de la implementacin.
Se busca aprender algunas recomendaciones para producir cdigo de calidad, poder entregar el cdigo en tiempo mnimo, poder
dividir el trabajo resultante del diseo entre un grupo de personas y tener una plantilla para redactar documentacin para los
manuales de usuario y tcnico.

Despus del estudio del contenido terico del tema, se deben realizar pruebas de codificacin con distintos estilos basndose
en los mismos ejemplos mostrados, utilizando el lenguaje de programacin que mejor conozca o prefiera el alumno. En paralelo
con el estudio del tema podra ser de inters que se desarrollara un pequeo proyecto de programacin donde se pusieran en
prctica los conceptos desarrollados en el captulo.
Para conseguir los objetivos es necesario no slo memorizar el contenido del captulo, sino asimilarlo hasta el punto de
utilizarlo en la prctica habitual de la programacin. Sera ingenuo pensar que se puede conseguir esto en dos das, mas bien
piense que tendr que poner en prctica los consejos propuestos durante un largo periodo de tiempo. La tarea de redactar una
documentacin de calidad no es trivial, son necesarias aptitudes pedaggicas, de estilo de escritura, etc. De todas formas, aunque
difcil, se puede considerar una tarea burocrtica, es decir, al final lo que hay que hacer es seguir un manual de redaccin de
manuales.
Guas de estilo de codificacin. Este apartado se estudia directamente en esta gua.
Tcnicas de depuracin. El contenido de este apartado se encuentra en [Pre01, cap. 18.7].
53
54
Documentacin del cdigo. El contenido se encuentra en esta gua.
5.1. Guas de estilo de codificacin

Dentro de los proyectos en los que trabajan varias personas debe haber una coherencia entre los programas escritos por
diferentes programadores para facilitar la interaccin y la modificacin de los mismos. Por tanto desde el principio del proyecto
debe estar claro el conjunto de normas y estilos que se utilizarn en la programacin: indentado (sangrado), nombres de variables,
eleccin de estructuras, contenido de comentarios, distribucin de los fuentes, etc. Existen herramientas propias de la codificacin
que incorporan automticamente la reescritura del cdigo segn determinadas normas estndar.
La mayor parte del tiempo un programador lo pasa manteniendo cdigo. Si ese cdigo lo ha escrito l mismo puede tener
serios problemas para ello, si lo han escrito terceras personas casi seguro que ser ms prctico rehacer todo ese cdigo porque
tardar menos. El problema es que todos los que hemos escrito alguna vez un programa hemos adquirido una serie de malos
hbitos. En este captulo se vern una serie de normas de escritura de cdigo fuente que dan un formato ms homogneo y por
tanto ms fcilmente mantenible.
Hay muchas propuestas sobre normas de estilo para diversos lenguajes, sobre todo para C y C++. Las empresas tienen sus
propias normas, que suelen ser variantes de estndares publicados, por ejemplo, en este captulo se ver un resumen de las
normas de Ellemtel Telecommunications Systems Laboratories para C++. Tambin veremos una recomendaciones de estilo de
programacin en C y las normas definidas por S UN 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 razn. Por eso definimos esta primera regla: Cada vez que se
rompa una norma se deber documentar el motivo.
5.1.1. Traduccin del diseo a la implementacin

Una vez terminado el diseo, la traduccin de ste a un lenguaje orientado a objetos no debe suponer mayores problemas
porque las estructuras de estos lenguajes soportan los conceptos del diseo. La traduccin del diseo a la implementacin se llama
ingeniera directa y puede ser parcialmente automatizada. La ingeniera inversa es el paso contrario, pasar de la implementacin
al diseo y tambin puede ser automatizada. Lo expuesto en este apartado est bastante aceptado en general y se puede encontrar
tambin en otros sitios (p. ej. [RBP+ 96, JBR00a]).
Casos de uso
Los casos de uso son una descripcin del funcionamiento de un sistema. No se les puede aplicar la ingeniera directa o
inversa para generar cdigo o para obtener casos de uso a partir del cdigo como al resto de diagramas en UML, pero veremos
un conjunto de instrucciones para averiguar cules son los casos de uso de un sistema a partir de su comportamiento (ingeniera
inversa).
Se identifican los actores que interactan con el sistema.
Se investiga la forma en la que el actor interacta con el sistema. Puede cambiar su estado o el de su entorno o responde a
un evento.
Se traza el flujo de eventos de un sistema relativos a cada actor. Primero se consideran los flujos principales y luego los
alternativos.
Identificar casos de uso que se puedan fusionar y los que tengan relaciones de uso o de extensin entre ellos.
Se representan los actores y casos de uso identificados en un diagrama.
Definiciones de clases
Es el primer paso para implementar el diseo. En general, para convertir un diagrama de clases en su equivalente en un
lenguaje, lo primero es identificar las reglas de correspondencia al lenguaje de programacin. Puede ocurrir que no exista una
forma de hacer la correspondencia, por ejemplo, en Java no existe la herencia mltiple, con lo que, o bien se prohibe a los
diseadores usarla, o bien se busca algn subterfugio para poder implementar esa caracterstica, lo que aadir complejidad. Los
atributos y operaciones que se han definido en el diseo se tienen que definir dentro de la clase correspondiente como pblicos,
privados o protegidos, aunque este aspecto es probable que se haya definido en el diseo. Hay que definir tambin su tipo.
Definicin de clases en C++
Una ejemplo de clase en C++:
class Punto
{
private:
// Aqu se definen las variables y mtodos privados.
// Ninguna otra clase puede acceder a ellos.
int x; // Variables privadas
int y;
protected:
5.1 Guas de estilo de codificacin
55
// Variables y mtodos protegidos. Solo la propia clase

// y las que hereden de ella pueden acceder a ellos.
public:
// Variables y mtodos pblicos. Accesibles por todos.
Punto() { ... } // constructor
Punto(int x,int y) // otro constructor
~Punto() { ... } // destructor
}
No puede haber atributos o mtodos con el mismo nombre. Los atributos y mtodos de un tipo (privado, protegido o pblico)
se declaran juntos en su bloque correspondiente. Existe un mtodo pblico sin valor de retorno llamado constructor que tiene el
mismo nombre de la clase y debe ser definido obligatoriamente.
Definicin de clases en Java Una clase en Java:
class Punto
{
private int x; // Variables privadas
private int y;
public Punto(int x,int y);// Constructor
public Punto(); // Otro constructor
}
Creacin y destruccin 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 explcitamente la secuencia de acciones que hay que realizar, lo cual es una actividad propensa a errores, o
bien existe un mecanismo automtico que va eliminando los objetos que no estn referenciados por ningn otro.
Creacin y destruccin de objetos en C++ Los constructores son los mtodos que inicializan un objeto una vez que se ha
reservado memoria para l. Puede haber varios que reciben diferente nmero y tipo de parmetros. La asignacin de memoria se
puede hacer de tres formas: Preasignados en memoria global fija (static), en la pila (automatic) y en el cmulo o heap (dynamic).
Ejemplo:
Punto *p=new Punto(100,30); // Memoria dinmica
Punto p(100,30); // Memoria de pila
static int j; // Memoria global fija
Puede existir un mtodo antagnico al constructor llamado destructor, tambin con el mismo nombre que el constructor pero
precedido de ~ y que es invocado de forma automtica antes de liberar la memoria que ocupa el objeto.
Creacin y destruccin de objetos en java Hay pocas diferencias respecto a C++; los constructores siguen las mismas reglas
y para destruir un objeto se invoca un recolector de basura cuando no queda memoria para liberar la de los objetos que ya no
estn referenciados por ningn otro objeto. Tambin se puede implementar un destructor utilizando la palabra finalize, que
se 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);
};
Invocacin de mtodos
Para llamar a un mtodo se indica al menos el nombre del objeto y el del mtodo, que puede tener parmetros o no.
Invocacin de mtodos en C++
Ejemplo: Tenemos el mtodo DesplazarHorizontalmente de la clase Punto.
Punto *p1, p2;

...
// Invocacin de los mtodos
p1->DesplazarHorizontalmente(10);
p2.DesplazarHorizontalmente(25);
56
Existe un puntero this que hace referencia al propio objeto. Si se recibe un parmetro con el mismo nombre que una variable
definida 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;
}
Invocacin de mtodos en Java
La notacin en java es igual pero sin la versin con punteros.
p.DesplazarHorizontalmente(10);
Uso de la herencia
La herencia es esttica si se determina en el momento de la compilacin, como ocurre en la mayora de los lenguajes, es
implcita si el comportamiento de un objeto depende de su clase y no se puede cambiar y es por grupos si las caractersticas de
herencia se especifican para una clase, no para objetos concretos.
Herencia en C++ Una clase puede heredar de varias clases que se especifican en la declaracin. La subclase se llama derivada.
La forma de heredar puede ser privada, protegida o pblica. El resultado de esto es que los mtodos y variables de la clase
antecesora se heredan con el tipo de acceso de menor grado, por ejemplo, una variable pblica que pertenece a una clase que se
hereda de modo protected se convierte en protected. Ejemplo de la sintaxis:
class Punto: public ObjetoGrafico { ... }
Herencia en Java Est mucho ms limitada. Slo existe herencia simple, aunque una clase puede implementar mltiples
interfaces y las interfaces pueden heredar de mltiples interfaces. Ejemplo:
class Punto extends ObjetoGrafico { ... }
Implementacin de asociaciones
Existen dos formas: punteros y objetos de asociacin. Lo normal es que el lenguaje no tenga definida esta ltima opcin.
Ejemplo: Supongamos que tenemos definido un objeto Recta, que se forma a partir de dos objetos Punto que define el usuario
pinchando en la pantalla, y queremos asociar los dos puntos a la recta. El objeto recibe los dos puntos en su constructor (ver
figura 5.1).
Recta
Consta de
1
Punto
Figura 5.1: Asociacin entre recta y punto
Implementacin en C++
objetos Punto recibidos:
En la implementacin del constructor se copian a los dos punteros de la clase las direcciones de los
class Recta {
private:
Punto *p1,*p2;
public:
Recta(Punto *p1,Punto *p2) {this->p1=p1; this->p2=p2; };
...
}
Implementacin en java El puntero est en el lado de la asociacin que necesita acceder a la otra clase, es decir, si es
navegable 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 relacin con una cardinalidad indeterminada, o lo que es lo mismo, puede
haber 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.
57
5.1.2. Estilo de programacin orientado a objetos

Veremos las directrices generales a seguir para que el cdigo sea reutilizable, extensible, robusto y utilizable en grandes
sistemas [RBP+ 96, cap. 14].
Reusabilidad
La ventaja de la reutilizacin es que la cantidad de cdigo se reduce por lo que la comprensin del mismo tambin es ms
sencilla. Es ms sencillo reutilizar cdigo en lenguajes orientados a objetos debido a que los mdulos son ms cohesivos y menos
acoplados. El inconveniente es que escribir cdigo reutilizable es ms difcil y siempre va a requerir un esfuerzo adicional.
Existen dos tipos de reutilizacin:
Dentro de un mismo proyecto pueden existir partes redundantes, se trata de descubrirlas y compartirlas por los mdulos
que las usen.
Reutilizar cdigo de un proyecto antiguo en proyectos nuevos. Es ms complicado que el punto anterior, requiere que el
cdigo haya sido escrito siguiendo una pautas que ahora veremos.
Reglas generales de estilo para escribir cdigo reutilizable:
Construir mtodos cohesivos. Un mtodo es cohesivo si realiza una nica funcin o varias ntimamente relacionadas. En
caso contrario hay que dividirlo.
Mtodos pequeos. Un mtodo es grande si sobrepasa una o dos pginas, en cuyo caso habr que dividirlo, con lo que
adems de hacerlo ms sencillo puede que uno de los trozos sea reutilizable.
Mantener la congruencia de los mtodos. Un mtodo se dice que es congruente si tiene un nombre similar a mtodos
similares, condiciones, orden de argumentos, valor proporcionado y condiciones de error.
Separar la poltica de la implementacin. Los mtodos de poltica son los de alto nivel y toman decisiones de control.
Son dependientes de la aplicacin, se entienden y se escriben fcilmente. Son los mdulos que deben comprobar el estado
y los errores. Los mtodos de implementacin son los que hacen el trabajo sucio, es decir, son los que tienen definidos
los algoritmos, pero no son los que toman la decisin de ejecutar o no esos algoritmos. Si encuentran un error durante la
ejecucin deben dar un informe a los mdulos superiores, pero no deben tomar acciones por su cuenta, como son mtodos
autocontenidos son fcilmente reutilizables.
Proporcionar una cobertura uniforme. Consiste en redactar mtodos que sean capaces de tratar todas las combinaciones
de las posibles entradas que se puedan dar, y no slo las actuales.
Generalizar los mtodos. Es similar al punto anterior pero en referencia al modo de funcionamiento y al contexto. Cuando
los valores estn vacos o sean extremos o estn un poco ms all del lmite.
Evitar el acoplamiento. Por ejemplo, el que se da cuando se accede a objetos globales y hay que tener conocimiento de
los mismos para poder utilizarlos.
Evitar los modos. Una operacin con modos tiene una forma de funcionamiento segn el modo en el que est. Lo aconsejable es tener un mtodo distinto para cada modo.
Herencia
Otra forma de reutilizar es escribir cdigo de forma que se pueda heredar. Las reglas de estilo en este sentido son:
Mtodos comunes: Se pone el cdigo comn en un mtodo al que invocan los diferentes mtodos. Si ese cdigo comn
est en varias clases se pone en un mtodo de una clase antecesora.
Factorizacin. Cuando tenemos dos mtodos muy parecidos de clases diferentes se puede utilizar otra aproximacin: El
cdigo comn se pone en un mtodo distinto de una clase antecesora, y es ese mtodo el que, en funcin de la clase en la
que estemos llama a un mtodo u otro. Es corriente utilizar la factorizacin con clases abstractas. En el siguiente ejemplo
de C++, los mtodos 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 {
58
B() { ... }
}
Delegacin. Si se tiene que ejecutar un mtodo en una clase A que ya est implementado en la clase B, heredar de B slo
para poder utilizar su mtodo es un error, en vez de eso se delega enviando la operacin a B desde A.
Cdigo externo encapsulado. Si se utiliza cdigo de otra aplicacin con una interfaz diferente, en vez de hacer llamadas
directas a ese cdigo es mejor hacer un mtodo o una clase que se encargue de ello. De esta forma, si hay que hacer
modificaciones, estas estarn ms localizadas.
Extensibilidad
Consiste en aadir nuevas funcionalidades al cdigo. Veamos un conjunto de normas a seguir para facilitarla.
Encapsular las clases. Esto significa que slo una clase puede acceder a sus propios datos e implementacin.
Ocultar las estructuras de datos. El motivo es que las estructuras de datos son propias de los algoritmos. Si se hacen
pblicas ser ms difcil cambiar el algoritmo ms adelante.
Ley de Demeter : Evitar recorrer mltiples enlaces o mtodos. Si a travs de las asociaciones un mtodo llega a una clase
vecina, no deben utilizar los enlaces de sta para acceder a una tercera clase, ms bien debera utilizar un mtodo de su
clase vecina para esta operacin, de esta forma no es necesario que el mtodo tenga conocimiento de todas las asociaciones
del modelo, slo de las clases relacionadas con la propia.
Evitar sentencias case basadas en el tipo de objeto. En su lugar se pueden utilizar mtodos. Solo se deben usar esas
sentencias si van a tener en cuenta los atributos de cada objeto.
Distinguir los mtodos pblicos de los privados. Se debe minimizar el nmero de mtodos pblicos para disminuir la
complejidad de la interfaz y porque si se modifican esto afectar a las clases que los utilicen, por eso deben ser diseados con ms cuidado. Los mtodos privados aaden modularidad, dependen de la implementacin de la clase y pueden
modificarse sin que cause efectos secundarios fuera de la clase.
Robustez
Un mtodo es robusto si no falla incluso ante parmetros incorrectos. Directrices para construir programas robustos:
Proteccin contra errores. Debe tenerse en cuenta que el usuario puede producir entradas incorrectas. El sistema debera
dar un mensaje de error y no colgarse. El sistema operativo, el hardware u otra librera pueden contener errores tambin,
para lo cual se deben instalar comprobaciones internas. Las comprobaciones de errores aumentan el tamao y la lentitud
del cdigo. Las relativas al usuario deberan estar siempre, las dems pueden eliminarse en la versin final que se entregue.
Optimizar despus de que funcione el programa.
Evitar los lmites predefinidos. Es decir, utilizar memoria dinmica en vez de estructuras de datos de tamao fijo. Esto da
ms flexibilidad (y algn que otro error).
Disponer el programa para la depuracin y la monitorizacin del rendimiento. En funcin de las facilidades suministradas por la herramienta de programacin, tendremos que aadir sentencias de depuracin, que se ejecutan en funcin
de una variable que indique el nivel de depuracin. Tambin es posible aadir cdigo que recoja estadsticas sobre por
ejemplo el nmero de invocaciones a una funcin.
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,
modificar o mantener el cdigo. Las directrices que se indican son aplicables tambin para un proyecto unipersonal.
No empezar a programar de forma prematura. Es decir, antes de empezar el proceso de implementacin hay otras cosas
como la especificacin o el diseo.
Crear mtodos comprensibles. Un mtodo es comprensible si terceras personas pueden entender lo que hace.
Hacer que los mtodos sean legibles. Esto significa:
Que los nombres de las variables sean significativos (mejor no utilizar abreviaturas).
Evitar un nivel de anidamiento excesivo.
No utilizar una misma variable temporal para diferentes propsitos en lugares diferentes.
Comprobar la ortografa de los nombres.
Utilizar los mismos nombres que en el modelo de objetos

Seleccionar cuidadosamente los nombres. Deben ser descriptivos y no ambiguos para no llevar a confusin. No se debe
asignar nombres iguales a mtodos semnticamente distintos. Para los mtodos se puede tomar como procedimiento de
asignacin de nombres el formato nombre_objeto, por ejemplo, borrar_pantalla. Dos clases que tengan mtodos con el
mismo nombre deberan tener un mismo ancestro y los mtodos la misma signatura, es decir, el mismo nmero y tipo de
parmetros.
59
Utilizar normas comunes de programacin. En referencia a cosas tales como la indentacin de prrafos, forma de hacer
los comentarios, poner todos los nombres en minsculas, etc.
Documentar las clases y mtodos. Deben existir comentarios en la cabecera de cada clase o mtodo para explicar su
cometido, precondiciones y postcondiciones. As mismo debe haber aclaraciones dentro de cada mtodo acerca de los
pasos seguidos en los algoritmos.
En los apartados siguientes se presentan una serie de normas de estilo para lenguajes concretos.
5.1.3. Normas para programadores en C

Organizacin de ficheros
En general un fichero no debe tener ms de 1000 lneas y las lneas no deben ser demasiado largas (80 caracteres o ms).
Nombres de ficheros
Tienen un nombre base y una extensin, .c para el C, .o para cdigo objeto, etc. Hay ficheros con nombres reservados
como README Makefile (en sistemas UNIX).
Organizacin de los ficheros de cdigo fuente (.c)
Este es el orden sugerido de secciones para un mdulo:
1. Un prlogo que indique:
Descripcin del propsito de los objetos en los ficheros.
Informacin de gestin, p. ej. informacin del control de la revisin o fecha de la ltima modificacin. (Esta informacin es opcional)
Autor. (Opcional)
2. Ficheros .h. Si la razn de que se incluya un fichero no es obvia debe explicarse. En ocasiones ficheros como stdio.h
deben incluirse antes que los del usuario.
3. Defines (macros de constantes, macros de funciones), typedef y enum, por este orden.
4. Declaraciones de datos (externas) en este orden: extern, globales no estticos, globales estticos. Si un conjunto de #define se aplica sobre unas lneas de cdigo, esos #define deben estar justo antes de esas lneas de cdigo o embebidas en
la declaracin de estructuras y correctamente indentados (sangrados).
5. Las funciones van la final en algn orden lgico. Por ejemplo: se ponen juntas las funciones con un grado similar de
abstraccin.
Organizacin de los ficheros de cabecera (.h)
Son ficheros que se incluyen dentro de otros antes de la compilacin por el preprocesador. Contienen declaraciones de datos
y defines necesarios para ms de un fichero.
1. Organizacin: Tienen que estar organizados de un modo funcional, es decir, las declaraciones para subsistemas diferentes
deben estar en ficheros de cabecera distintos. Si un conjunto de declaraciones va a ser cambiado cuando se porte el sistema
a otra plataforma, debera tambin en este caso estar en un .h aparte.
2. Los nombres deben ser distintos de los de las libreras del sistema, como math.h. No se deben usar nombres de ruta
completas, es mejor utilizar las opciones del compilador para indicar el directorio especfico o la opcin -I (para indicar
el directorio de las cabeceras en algunos compiladores).
3. Las cabeceras que definen funciones o variables externas deben ser incluidas en los ficheros que las definen para de esta
forma hacer comprobacin de tipos y que las variables externas siempre sean consistentes con la definicin.
4. No se deben definir variables en un fichero de cabecera.
5. No debera haber ficheros de cabecera anidados. Si es as, se debe poner en el prlogo que ficheros de cabecera son
necesarios.
6. Para evitar incluir la misma cabecera ms de una vez se debe usar la siguiente estructura:
#ifndef EJEMPLO_H
#define EJEMPLO_H
/* Cuerpo de EJEMPLO.H */
#endif
Otros ficheros
El fichero README debe tener una descripcin del proyecto completo. Puede tambin explicar detalles tcnicos acerca
del Makefile, una lista de ficheros dependientes del hardware especfico de la mquina, etc.
60
Comentarios
Cuando el cdigo y los datos se contradicen probablemente ambos estn mal - Norm Schryer
1. Los comentarios deben describir qu est pasando, cmo se est haciendo, qu significan los parmetros, qu variables
globales se estn usando y cualquier restriccin o error. Los comentarios cortos (una lnea) son para expresar el qu. El
cmo se escribe en unas cuantas lneas que preceden al algoritmo.
2. Los comentarios deben justificar el cdigo que parezca errneo 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 funcin deben estar correctamente indentados con el cdigo que comentan. Pueden usarse
tanto comentarios de una lnea como de varias. Si el comentario es muy corto se puede poner seguido a una lnea de cdigo,
y si aparecen varios comentarios de este tipo deben estar a la misma altura.
Declaracin de variables
1. Las declaraciones globales se ponen en la primera columna. Las declaraciones externas de datos deben ir precedidas por
la palabra extern. Los lmites de los arrays hay que repetirlos en la declaracin extern.
2. El * de la declaracin 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 lnea que en los struct typedef y la llave para cerrar } en la lnea
siguiente. Ejemplo:
struct complejo {
real a, b;
};
5. Las variables que deban tener un valor inicial se deben inicializar todas de forma explcita.
6. Cuando un fichero 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 ficheros. Una variable debe poder ser accedida desde otro fichero slo cuando
sea realmente muy necesario y se deber comentar.
7. Los tipos ms importantes deben ser remarcados usando typedef.
8. El tipo de retorno se debe declarar siempre.
Declaracin de funciones
Cada funcin debe llevar un prlogo que indique lo que hace la funcin y cmo usarla. Tambin es conveniente aclarar
decisiones de diseo no triviales.
Se debe poner un tipo de retorno para cada funcin. No usar el tipo int por defecto. Si hay que explicar ese tipo, se hace en
el prlogo.
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 ficheros .h.
5. Comprobar que el tamao de las cadenas es lo suficientemente grande como para que quepa cualquier cosa (si se prueba
una cadena con hola ten la seguridad que llegar el da en el que alguien escribir supercalifragilisticoespialidoso.
6. Si una funcin puede devolver un cdigo de error, lo comprobars cada vez que llames a esa funcin, aunque tripliques el
tamao del cdigo.
7. Estudiars las libreras para asegurarte de no inventar nada que ya exista, as tu cdigo ser corto y legible.
8. Indentars (sangrars) correctamente tus programas para que su estructura sea clara.
1 Utilidad para programadores en C en UNIX que permite detectar declaraciones no usadas, inconsistencias entre tipos, uso de variables antes de su definicin,
cdigo no alcanzable, caminos de ejecucin sin retorno, etc
61
9. Los identificadores externos debern ser nicos desde sus primeros seis caracteres.
10. Escribirs cdigo independiente del hardware de la mquina especfica en la que programes, porque los das de esa mquina
llegarn a su fin antes que los de tu programa.
5.1.4. Normas para programadores en C++

A continuacin veremos un conjunto de reglas y recomendaciones para escribir cdigo en C++. Estas normas son las definidas
por Ellmentel Telecomunications Systems Laboratories. La finalidad de este apartado es ver un ejemplo ms, no es necesario
memorizar, tan solo quedarse con una visin general.
Para que el cdigo sea correcto y fcil de mantener, el programa debera:
Tener un estilo consistente.
Ser fcil 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 deberan ser infringidas mas que por motivos muy serios y las recomendaciones,
que pueden tomarse como consejos.
Ficheros de cdigo fuente
Estructura del cdigo
Reglas:
Las extensiones de los mismos tipos de ficheros sern siempre las mismas. Ejemplo: Include: .h .hh, fuente: .cc,
ficheros inline: .icc. Excepcin: Cuando se utilicen mdulos de C, que no tienen las mismas extensiones.
Los ficheros de implementacin tienen la extensin .cc. Excepcin: Hay compiladores que slo aceptan la extensin
.c.
Los ficheros de definicin inline tienen la extensin .icc.
La finalidad es dar una visin uniforme de los nombres de fichero y distinguir entre los diferentes tipos, entre los de C y los de
C++ y entre los de definicin y los de implementacin. Recomendaciones:
Un fichero include no debe contener ms de una definicin de clase.
Dividir la definicin de las funciones miembro entre tantos ficheros como sea posible.
Colocar el cdigo dependiente de la mquina en un mdulo aparte.
Nombre de los ficheros
Se trata de evitar las colisiones de nombres. Recomendaciones:
Dar siempre nombre de ficheros que sean nicos en un contexto tan grande como sea posible.
El nombre de un fichero include de una clase debera ser: NombreClase + extensin. Respetar las maysculas y minsculas
del nombre de la clase en el nombre del fichero.
Comentarios
Reglas:
Cada fichero con cdigo fuente debe tener una introduccin con informacin sobre el contenido de ese mdulo.
Todos los ficheros deben tener copyright.
Todos los comentarios se deben escribir en Espaol.
Recomendaciones:
Escribir un breve comentario antes de cada funcin.
Es mejor usar // para los comentarios.
Hay que tener en cuenta que los comentarios de los ficheros include van dirigidos a los usuarios de las funciones o clases, y los
de los ficheros de implementacin a los que mantienen el cdigo.
62
Ficheros include
Reglas:
Todos los ficheros include tienen que contar con algn medio que impida mltiples inclusiones de ese archivo.
Los siguientes tipos de definiciones deben estar en ficheros 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 estn definidas
en el fichero.
Las definiciones de clases a las que slo se accede va puntero (*) o referencia (&) no sern incluidas como include.
Nunca especificar las rutas completas en las directivas #include.
Cada fichero de implementacin deber incluir:
Declaraciones de tipos y funciones usados en las funciones que se implementen en el fichero.
Declaraciones de variables y funciones miembro usados en las funciones que se implementen en el fichero.
Recomendaciones:
Usar la directiva #include nombre_de_fichero.hh para los include definidos por el usuario.
Usar la directiva #include <nombre_de_fichero.hh> para los include de las libreras.
Cada fichero de implementacin debera declarar una constante con una variable de cadena que describa el fichero, as, en
un sistema UNIX el comando what podr ser usado para obtener informacin del fichero.
Nunca incluir otros ficheros en un fichero inline.
Asignacin de nombres
Un identificador consta de: Prefijo, Nombre y Sufijo. El prefijo y el sufijo son opcionales. El sufijo suele ser utilizado por
herramientas que generan cdigo. Reglas:
El identificador de cada clase, tipo enumerado, funcin, constante o variable globales en una librera de clases debe empezar
con un prefijo que sea nico para cada librera.
Los nombres de las variables, constantes y funciones deben empezar en minsculas.
Los nombres de los tipos abstractos de datos, estructuras, typedef y tipos enumerados deben empezar en maysculas
Los nombres que consistan en ms de una palabra, las palabras deben ir juntas y la inicial de cada palabra debe ir en
maysculas.
No usar identificadores que comienzan con _.
Si un nombre comienza por mayscula aparece despus de un prefijo.
Si un nombre no empieza por mayscula estar separado de su prefijo por _.
Recomendaciones:
No usar nombres que slo difieran en que una letra sea mayscula o minscula.
Los nombres no deben incluir abreviaturas que no sean aceptadas por todo el mundo.
Una variable visible en un trozo grande de cdigo debe tener un nombre largo.
Los nombres de las variables deberan recordar para qu sirven.
Se debe escribir el cdigo de forma que sea fcil cambiar los prefijos de los identificadores 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: Pblico, protegido y privado. Este es adems el orden que interesa a
la gente. La parte privada la va a leer cualquiera que use la clase, la parte protegida quien quiera heredar y la privada en
general nadie.
No se definen funciones miembro dentro de la definicin de la clase.
Funciones
63
Recomendaciones:
Dar siempre explcitamente el tipo de retorno de cada funcin.

El primer parmetro de la funcin va en la misma lnea que el nombre y si todos los dems caben en esa lnea se ponen, en
caso contrario se escribe uno por lnea.
Escribir el tipo de retorno de cada funcin en una lnea aparte.
Escribir el parntesis izquierdo despus del nombre de la funcin, es decir, que no haya un carcter en blanco. Ejemplo:
int
buscarLista(int intElementos,
cadena *cadenaPunteroLista,
cadena cadenaBuscada);
Bloques
Recomendacin: Los corchetes que delimitan el comienzo ({) o el final (}) de un bloque deben ir en lneas aparte.
Sentencias de control de flujo Recomendacin: Todas las sentencias de control de flujo (if, else, while, for) deben ir
seguidas de un bloque incluso aunque sea vaco. Ejemplo:
for (char *c=charCadena; *c!=A && *c; c++)
{
}
Punteros y referencias Recomendacin: Los operadores * y & deben estar conectados directamente con el tipo de la
variable y no con la variable misma. Ntese que la recomendacin para el lenguaje C es justamente la contraria.
Miscelnea
Recomendacin: No usar espacios alrededor de . -> ni entre operadores u operandos unarios.
Clases
Derechos de acceso
Regla: No especificar nunca un dato como pblico o protegido. Los motivos son que:
Slo la propia clase podr manipular esa variable (encapsulacin).

Cualquier funcin del programa podra cambiar ese valor provocando errores.
Evitando que se modifique externamente una variable, se evita tambin que quien modifique esa variable deba tener en
cuenta la implementacin de la clase.
Funciones inline Una funcin inline es aquella cuyo cdigo compilado se sita donde se utiliza, de esta forma no se hace la
llamada y se consigue ms eficiencia. Recomendaciones:
Las funciones de acceso deben ser inline. (Una funcin de acceso slo devuelve un valor de un dato miembro).
Las funciones que slo llaman a otra funcin deben ser inline.
Los constructores y destructores no deben ser inline.
Funciones friend
de la clase.
Recomendacin: Las funciones amigas estn para proporcionar funciones adicionales que estn mejor fuera
Funciones miembro const
Reglas:
Una funcin 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 modificados por funciones
miembro const.
Constructores y destructores
Reglas:
Una clase que use new para crear instancias gestionadas por la clase debe definir un constructor de copia. Excepciones: Si
una clase tiene un rea de datos compartida no es necesario tener un constructor de copia, tan slo hay asegurarse de que
no 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 definir un destructor virtual.
No usar objetos globales en constructores y destructores.
64
Operadores de asignacin
Reglas:
Una clase que usa new para crear instancias gestionadas por la clase debe definir un operador de asignacin. Excepcin:
Si los objetos de una clase tienen un rea de datos compartida no es necesario definir un operador de asignacin. Hay que
asegurarse de que el rea de datos no se destruye mientras haya punteros que la referencien.
Un operador de asignacin que hace una operacin destructiva debe protegerse de realizar esta accin en el objeto en el
que est operando.
Recomendacin: Un operador de asignacin 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 define un operador y tambin se usa la funcin opuesta es conveniente definir ambos (por ejemplo, == y !=).
Tipos de retorno de las funciones miembro Reglas:
Una funcin pblica miembro no debe devolver nunca una referencia no constante o un puntero a datos miembro.
Una funcin pblica miembro nunca debe devolver una referencia no constante o punteros a datos fuera del objeto a menos
que el objeto comparta datos con otros objetos.
Herencia Recomendaciones:
Si un objeto se compone de otros, no utilizar la herencia para reflejar 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 implementacin
de los mtodos. Como el compilador no detecta este tipo de cosas, hay que tener cuidado.
Hay que tener cuidado con las definiciones mltiples de funciones sobrecargadas junto con la instanciacin de clases
plantilla. Por ejemplo, si definimos una funcin con un tipo determinado y esa misma funcin la sobrecargamos con el tipo
definido en la plantilla podramos tener dos funciones idnticas.
Funciones
Estas reglas son aplicables a las funciones miembro.
Argumentos de las funciones
Recomendaciones:
Regla: No usar argumentos sin especificar (elipsis).
Evitar funciones con muchos argumentos.

Si una funcin almacena un puntero a un objeto que es accedido a travs de un argumento, dejar que el argumento sea del
tipo del puntero.
Usar referencias constantes (const &) en vez de llamadas por valor a menos que se estn usando tipos de datos predefinidos
o punteros
Sobrecarga de funciones Recomendacin: Cuando se sobrecargan funciones, todas las variaciones deben tener la misma
semntica (son usadas para el mismo propsito).
Argumentos formales
en la declaracin.
Regla: Los nombres de los argumentos de las funciones tienen que ser los mismos en la definicin y
Tipos de retorno y valores Reglas:

Especificar siempre el tipo de retorno de una funcin explcitamente.
Una funcin pblica nunca debe devolver una referencia o un puntero a una variable local.
Funciones Inline Regla: No usar la directiva del preprocesador #define para obtener cdigo ms eficiente. En lugar de
eso usar funciones inline.
Recomendacin: Usar funciones inline slo cuando sean realmente necesarias.
65
Objetos temporales Recomendacin: Minimizar el nmero de objetos temporales que son creados como valores de retorno de
funciones o como argumentos a funciones.
General Recomendacin: Evitar funciones largas y complejas.
Constantes
Reglas:
Las constantes deben ser definidas con const o enum. Nunca usando #define
En lugar de utilizar valores numricos en el cdigo usar valores simblicos. La excepcin seran los valores numricos
comnmente utilizados y con significado claro tales como 0, 1, true false.
Variables
Reglas:
Las variables deben ser declaradas con el mnimo 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 inicializacin en vez de la asignacin.
Excepcin: Cuando se asigna a una variable el valor de una expresin complicada puede no ser necesario dar un valor
inicial.
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 simplificar la sintaxis cuando se declaren punteros a funciones.
Conversiones de tipos
Reglas:
Nunca usar conversiones explcitas de tipo (cast). Excepciones:
Una conversin explcita es preferible a una conversin implcita.
Para convertir un puntero a una clase base a un puntero a una clase derivada en un contenedor implementado en una
clase contenedora heterognea.
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 generacin explcita de tipos es necesaria para leer la representacin externa de un objeto.
No escribir cdigo que dependa de funciones que usen conversiones implcitas de tipos.
Nunca convertir punteros a objetos de una clase derivada a punteros a objetos de una clase base virtual. Excepcin: Si
una clase base virtual contiene una funcin virtual pura que convierte un puntero a clase base virtual a un puntero a clase
derivada, esto puede funcionar definiendo la funcin en la clase derivada. Esto significa que todas las clases derivadas
deben ser conocidas en la clase base virtual.
Nunca convertir un const a un no const.
Estructuras de control de flujo
Reglas:
El cdigo que va despus 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 eleccin 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 iteracin y la terminacin
depende de una expresin constante.
while: Cuando la condicin de terminacin se evala al principio de la iteracin.
66
do-while: Si la condicin de terminacin es mejor evaluarla al final.

Usar siempre unsigned para las variables que no pueden tener valores negativos.
Usar lmites inferiores incluyentes (>=) y lmites superiores excluyentes (<).
Evitar el uso de continue.
Usar break para salir de un bucle si esto evita usar flags.
No usar expresiones lgicas del tipo if(test) if(!test) cuando test es un puntero.
Expresiones
Recomendacin: Usar parntesis para clarificar el orden de evaluacin 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 algn otro lo libere ms 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 fcil convertirlo al manejo de excepciones.
Comprobar los cdigos de fallo que se pueden recibir de funciones de librera incluso si esas funciones parecen seguras.
Cdigo portable (multiplataforma)
Abstracciones de datos
Tamao de los tipos
Recomendacin: No usar directamente los tipos de datos predefinidos en las declaraciones.
Recomendaciones:
No suponer que un int y un long tienen el mismo tamao.

No suponer que un int tiene 32 bits (quizs tiene slo 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 ms largo.
No suponer que los punteros y los enteros tienen el mismo tamao.
Usar conversiones explcitas de tipo para operaciones aritmticas usando valores con signo y sin signo.
Representacin de datos
Recomendaciones:
No suponer que se conoce como se representa en memoria la instancia de un objeto.

No suponer que los tipos long, float, double o long double van a comenzar en direcciones de memoria arbitrarias o ajustadas.
Underflow / Overflow
Orden de ejecucin
Recomendacin: No depender del funcionamiento del underflow u overflow de ningn modo.

Recomendaciones:
No suponer que los operandos de una expresin van a ser evaluados en un orden definido.
No suponer que se conoce como han sido implementados los mecanismos de invocacin de una funcin.
No asumir que un objeto es inicializado en un orden concreto en los constructores.
No asumir que los objetos estticos son inicializados en ningn orden concreto.
Objetos temporales
67
Recomendacin: No escribir cdigo que dependa del tiempo de vida de un objeto temporal.
Aritmtica de punteros Recomendaciones:

Evitar usar las operaciones de desplazamiento en lugar de la aritmtica de punteros.
Evitar la aritmtica de punteros.
5.1.5. Normas para programadores en Java

Java, al igual que C++, es un lenguaje orientado a objetos. La mayor parte de las normas que son aplicables a C++ son
igualmente vlidas para Java, no obstante, S UN ha definido una serie de normas en la pgina http://java.sun.com/docs/
codeconv/html/CodeConvTOC.doc.html que exponemos resumidas a continuacin.
Ficheros
La extensin para los archivos de cdigo fuente es .java y para los archivos compilados .class.
Organizacin de ficheros
Cada fichero debera contener una sola clase. Si hay clases privadas e interfaces asociados con esa clase se pueden poner en
el mismo fichero despus de la clase pblica. Las secciones en las que se divide el fichero son:
Comentarios de tipo directorio de todo el mdulo.
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 documentacin).

Sentencia class o interface.
Comentarios acerca de la implementacin de las clases (comentarios de implementacin).
Variables estticas.
Variables de instancia. Tanto las variables estticas como las de instancia se agrupan por su alcance, es decir, por este
orden: pblicas, protegidas y privadas.
Constructores.
Mtodos. Se agrupan por su funcionalidad, no por su alcance.
Formato del texto
S UN define una serie de principios generales:
El sangrado determinado para un bloque es de cuatro espacios.
La longitud de las lneas de cdigo no debe ser superior a 80 caracteres.
La longitud de las lneas de comentarios no debe ser superior a 70 caracteres.
Normas para partir lneas demasiado grandes:
Partir despus de una coma.
Partir despus 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 lnea al comienzo de la anterior. Si esto pudiera causar confusin indentar (sangrar) con 8 espacios.
Comentarios
En Java hay dos tipos de comentarios: De documentacin y de implementacin. Los comentarios de documentacin tienen la
forma: /* ... */. Existe una herramienta llamada Javadoc que genera pginas HTML partiendo de este tipo de comentarios.
El tema de los comentarios se trata en profundidad en el tercer apartado de este captulo.
68
Declaraciones
La recomendacin en este sentido es que no se declare ms de una variable por lnea, poniendo el nombre de la variable
indentada 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 inicializacin dependa de un clculo
posterior.
Las clases e interfaces deben usar la siguiente convencin:
No se ponen espacios entre el nombre de los mtodos y el parntesis (.
La llave de apertura { aparece en la misma lnea que el nombre del mtodo o clase.
La llave de cierre de bloque } aparece en una lnea a parte del bloque, excepto cuando el bloque est vaco.
Los mtodos se separan por una lnea en blanco.
Ejemplo:
class Punto extends ObjetoGrafico {
int x;
int y;
Punto(a,b) {
x=a;
y=b;
}
Sentencias
Debe haber una y slo una sentencia por lnea. Si hay un bloque de sentencias, ste debe ser sangrado con respecto a la
sentencia que lo genera y debe estar entre llaves aunque slo tenga una sentencia para de este modo evitar errores cuando
se aaden 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 definidos por estas sentencias se les aplican las normas definidas en puntos
anteriores. Todos los bloques tienen el mismo nivel de sangrado.
Bucles. Definen un bloque, que sigue las normas anteriores. Si el bucle es vaco (no tiene sentencias) no se abren ni se
cierran llaves.
Las sentencias return no deben usar parntesis.
Separaciones
Incrementan la legibilidad del cdigo. La regla general es que cuanto ms importante sean las partes a separar tanto mayor
debe ser la separacin. En este sentido el criterio es:
Dos lneas: Entre clases e interfaces.
Una lnea: Entre mtodos, declaraciones de variables y la primera instruccin, secciones lgicas diferentes de un mtodo
y antes de un comentario de lnea o de bloque.
Un carcter en blanco: Entre una palabra y un parntesis, despus de una coma, los operadores binarios menos el ., las
expresiones 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 */
5.2 Tcnicas de depuracin
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 asignacin de nombres son:
Paquetes: Nombres en minsculas separados por puntos. Ejemplo: java.io.
Clases e interfaces: Dos o tres nombres con la primera letra en maysculas, sin usar abreviaturas. Ejemplo: ObjetoGrafico.
Mtodos: La primera palabra debera ser un verbo y en minsculas. Ejemplo: desplazarHorizontal.
Variables: Deben ser cortas (pueden ser de una letra) y significativas. Si son varias palabras la primera en minscula.
Ejemplos: i, j, k, unTriangulo.
Constantes: Se escriben en maysculas y si son varias palabras van unidas por un carcter de subrayado. Ejemplo:
MAX_LONG = 1000
5.2. Tcnicas de depuracin

Durante el desarrollo de la fase de implementacin se deben realizar dos tipos de labores relacionadas con la comprobacin
del cdigo obtenido. La primera consiste en elaborar los conjuntos de prueba para los diferentes mdulos que se programan. La
segunda consiste en comprobar si los mdulos cumplen las especificaciones de diseo con esos conjuntos de prueba. Tambin
se puede incluir dentro de este proceso la comprobacin de correccin en la ejecucin de los mdulos y evitar posteriormente la
aparicin de errores frecuentes como prdidas de memoria, comportamientos extraos ante entradas de datos imprevistas, etc.
El contenido de este apartado se encuentra en [Pre01, cap. 18.7].
5.3. Documentacin del cdigo

Adems de la documentacin incluida dentro del cdigo fuente correspondiente, es necesario generar los manuales tcnicos y
de referencia adecuados, as como la parte inicial correspondiente del manual de usuario (que se finalizar en la fase de entrega).
Estos manuales se deben ir escribiendo simultneamente al cdigo y se deben actualizar en concordancia con los cambios en el
mismo.
Esta documentacin es esencial para las fases de pruebas y de mantenimiento, as como para la entrega final del producto.
Por tanto se deben mantener actualizadas y funcionales desde el primer momento.
Adems de las recomendaciones que se han dado para lenguajes especficos vamos a ver de que modo se puede hacer la
documentacin interna de un programa (comentarios). Esta documentacin es importante de cara al mantenimiento futuro del
programa, tanto si lo hacen terceras personas como si lo hace el encargado de programar el cdigo fuente del mdulo. Adems
de estos comentarios en el cdigo se extraen los esbozos para los manuales tcnicos y de referencia.
5.3.1. Tipos de comentarios

Distinguiremos tres tipos de comentarios desde el punto de vista de la parte que comentan y dnde se localizan.
Directorio: Son los situados al principio de cada mdulo. La informacin que contiene es: Lista de funciones o clases
implementadas en el mdulo, Versin, Fecha, Programador, Copyright e Interfaces con otros mdulos.
Prlogo: Cumple la misma funcin que el directorio pero para cada funcin o mtodo. Indica la siguiente informacin:
Finalidad, Comentarios acerca de las variables significativas, Descripcin general del funcionamiento e Informacin para
la reutilizacin (efectos colaterales, variables globales que utiliza, etc.)
70
Explicativo: Aclaraciones acerca de partes del cdigo. Hay dos tipos: de lnea y de bloque.
Las ventajas de los comentarios de bloque es que estn localizados en un punto concreto y no dispersos por varias lneas
entre el cdigo, con lo que adems son fciles de modificar. Los comentarios de una lnea deben ponerse en la misma lnea
del cdigo que se esta comentando y se usan para explicar sentencias complicadas.
Los tipos de comentarios segn cmo estn redactados son estos cinco (de peor a mejor):
Repetir el cdigo: Consiste en expresar el cdigo de otra forma pero sin aadir informacin significativa. Este tipo de
comentarios son innecesarios.
Explicacin del cdigo: Ayudan a comprender el cdigo. Es mejor reescribir el cdigo de modo que sea ms inteligible
que utilizar este tipo de comentarios.
Marcadores: Son notas temporales para la gente que trabaja en el proyecto. Se eliminan cuando el proyecto finaliza.
Resumen del cdigo: Explica en pocas palabras la funcin de un trozo de cdigo.
Descripcin de la finalidad: Explica el por qu. Es el ms fcil de entender.
5.3.2. Consideraciones generales

Los comentarios deben ser entre el 25 % y el 33 % de las lneas de un mdulo.
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 ms el cmo y no el qu.
Los datos se deben comentar cuando el nombre no sea suficiente como para que se entienda. Si un dato se compone de
otros ms pequeos aplicar esta misma regla recursivamente caso de ser necesario.
Tutorial posterior
La implementacin en teora se puede hacer de un modo totalmente automatizado a partir del diseo. Pero como esto en
realidad no es as, se dan una serie de consejos para pasar el diseo a cdigo y como redactar este cdigo en un conjunto de
lenguajes.
Traduccin del diseo a la implementacin
Ingeniera inversa: Consiste en averiguar las especificaciones de un sistema a partir de su funcionamiento. Se dan algunas heursticas para averiguar los casos de uso de un sistema: definiciones de clases, creacin y destruccin de objetos, invocacin
de mtodos, herencia e implementacin de asociaciones.
Estilo de programacin orientado a objetos: Son un conjunto de consejos para conseguir: reusabilidad, reconocer la herencia,
construir mtodos extensibles, cdigo robusto y trabajo en grupo eficaz.
Normas para programadores en C: Son un conjunto de normas que cubren todos los apartados de la codificacin, tanto del
tamao de los ficheros, como de la eleccin de nombres (quizs lo ms importante), indentacin, etc.
Normas para programadores en C++: Es una recopilacin similar para el lenguaje C++. Es ms extenso debido a la complejidad del lenguaje. Estas normas fueron compiladas por Ellmentel Telecomunications System Laboratories.
Normas para programadores en Java: Es un resumen de las normas publicadas por S UN para el lenguaje Java.
Tcnicas de depuracin
Consiste en un conjunto de tcnicas para descubrir errores de codificacin. Incluye tambin un pequeo apartado para procesos concurrentes.
Documentacin del cdigo
Al igual que el diseo el anlisis producen documentos segn una plantilla estndar, el cdigo tiene que tener una documentacin interna. Se distinguen los tipos de comentarios (Directorio, prlogo y explicativo), donde se colocan, que informacin se
incluye en cada uno de ellos y la forma de redaccin de la informacin.
5.3 Documentacin del cdigo
71

1. Suponga que tiene este cdigo:
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 propsito tiene?
b) Es correcto?. Si no es as, a qu se debe?
c) Redacte de nuevo el cdigo de modo que se pueda entender su propsito y funcionamiento de un vistazo.
Asigne nombres significativos a las variables y a la funcin.
Escriba comentarios.
Ponga la indentacin correcta.
Si es necesario cambie la estructura de la funcin.
2. Suponga que tiene un programa en C++ que calcula un fractal y lo dibuja como una imagen en la pantalla. Para estas funciones utiliza un mdulo con una estructura de datos que define los nmeros complejos y las operaciones relativas a ellos:
Producto, Suma, Resta, Potencia. A cada punto de la pantalla se le aplica un algoritmo, lo cual estara en otro mdulo. Se
tendra otro mdulo con las funciones relativas a los grficos: Dibujar matriz de puntos, Zoom, etc.
Redacte la documentacin de cada mdulo del programa: prlogo y comentarios antes de cada funcin (haga las suposiciones que considere oportunas sobre que funciones existiran).
Tambin 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 anlisis y modelado de software A LMA http://www.desnoix.com/guillaume/alma/, permite el anlisis de cdigo fuente orientado a objetos para su representacin y modelado o su transformacin a otros lenguajes. Esta herramienta, A LMA, es muy interesante y al estar implementada en Java es fcilmente instalable en cualquier entorno.
Es interesante hacer notar que existen ciertos lenguajes de programacin que facilitan y promueven con su sintaxis una
codificacin ms clara, ordenada, sistemtica y autodocumentada. Tal es el caso, por ejemplo, del lenguaje P YTHON que,
normalmente, es interpretado pero que auto-precompila cada fichero fuente ejecutado y reutiliza esa versin precompilada
(preanalizada) si no cambia el fuente. Este lenguaje es muy til para hacer prototipos rpidos, pero tambin para aplicaciones ms grandes (por ejemplo vase Z OPE http://www.zope.org/). Prcticamente todas las implementaciones de P YTHON son de libre distribucin. Se puede ver ms informacin en las siguientes pginas Web: http://www.python.org/,
http://www.freenetpages.co.uk/hp/alan.gauld/spanish/ es una traduccin al espaol del libro [Gau01] (un tutorial bsico), el libro de libre distribucin (licencia FDL) [DEM02] en http://www.ibiblio.org/obp/thinkCSpy/ o un libro en lnea
http://diveintopython.org/es/ (traduccin al castellano de Dive into Python) con varias referencias a otra informacin
en espaol, aparte de la pgina http://users.servicios.retecal.es/tjavier/python/Un_poco_de_Python-2.html sobre P YTHON de Toms Javier Robles Prado.
Existe una tcnica de escribir la documentacin incluida dentro del cdigo fuente, conocida por el nombre en ingls de
Literate Programming. Se puede encontrar extensa informacin sobre este tema en la FAQ especfica: http://shelob.ce.
ttu.edu/daves/lpfaq/faq.html. Adems hay algunas otras herramientas de ayuda en la generacin de referencias cruzadas
y documentacin a partir del cdigo fuente, como por ejemplo C XREF http://www.gedanken.demon.co.uk/cxref/, la ms
reciente y completa D OXYGEN http://www.doxygen.org/ (que se puede utilizar para otros lenguajes adems de C). Tambin
es interesante ver el ejemplo de cmo un proyecto enorme, como es el kernel del sistema operativo Linux, tiene un sistema de
referencias cruzadas: http://lxr.linux.no/.
Captulo 6
Fases de pruebas
Tutorial Previo
Introduccin
Este tema incluye en su denominacin Fases, en plural, debido a que realmente no hay una nica fase de pruebas, sino que
las pruebas se van realizado en todas las dems fases. Las pruebas en este caso consisten en la comprobacin de que la salida
obtenida en cada fase corresponde a las especificaciones de entrada correspondientes. Las pruebas consumen mucho tiempo,
pero deben hacerse de un modo sistemtico para asegurar que el resultado cumple con el grado de calidad exigido (densidad
de errores por KLDC, etc). Para medir esta calidad existen algunas mtricas. En esta parte del desarrollo se trata de encontrar
errores, no slo de codificacin, sino tambin los relativos a la especificacin o el diseo, en este sentido se puede distinguir entre
verificacin y validacin. La verificacin trata de comprobar si se est construyendo el producto correctamente, la validacin si
es el producto correcto. Las pruebas que se van haciendo durante el ciclo de vida son: ingeniera del sistema (prueba del sistema),
especificacin (prueba de validacin), diseo (prueba de integracin) y codificacin (prueba de unidad). Los tipos de pruebas
tienen naturaleza diferente y en consecuencia, las tcnicas para cada una de ellas son diferentes; tambin se har un recorrido por
cada una de ellas. Inevitablemente tambin hay que aadir la correspondiente documentacin de las pruebas realizadas.

Este tema est muy relacionado con los anteriores temas 3 al 5 correspondientes a las fases de requisitos, diseo e implementacin, donde se deben distribuir las pruebas correspondientes. Es recomendable, aunque no necesario, haber construido
alguna vez un mdulo que pruebe a otro dando entradas y comprobando si las salidas que proporciona el mdulo probado se
corresponden con lo esperado.
Objetivos del tema

Se debe extraer una idea clara de que los principios de ingeniera requieren la comprobacin y verificacin de todos los
elementos intermedios en el proceso de desarrollo, en este caso, del software. Tambin se deben conocer tcnicas que indiquen
los errores que se comenten, tanto de concepcin de la tarea a realizar como de las funcionalidades que se implementen y que
esta deteccin ocurra lo antes posible.

Es conveniente recapitular y repasar los temas anteriores 3 al 5 para ir identificando dentro de cada una de las fases cules
son las pruebas necesarias para la validacin que se explican en este captulo.
Verificacin y validacin a lo largo del ciclo de vida. El material correspondiente a este apartado se encuentra en [Pre01,
cap. 18.1 y 18.2]
Tcnicas y mtodos de prueba. Este apartado se debe estudiar en [Pre01, cap. 17] y [Pre01, cap. 18.3, 18.4, 18.5 y 18.6] y
[Pre01, cap. 23] (o bien [Pre97, cap. 22] en la 4a edicin).
Documentacin de pruebas. El material est incluido directamente en esta gua.
6.1. Verificacin y validacin a lo largo del ciclo de vida

Uno de los elementos esenciales de todo proceso de ingeniera en general es la verificacin y validacin de los pasos dados
durante el desarrollo. Por tanto es necesario hacer las comprobaciones parciales cuanto antes para realimentar el proceso de
desarrollo segn los resultados de las pruebas.
[Pre01, cap. 18.1 y 18.2]
1
Fases de pruebas
6.2. Tcnicas y mtodos de prueba

Existen diferentes tcnicas para realizar las pruebas de verificacin del software en diferentes fases. La mayora hacen uso
de las caractersticas de modularidad en el diseo e implementacin para ir integrando de forma ascendente o descendente los
mdulos de diferentes niveles.
El contenido de este apartado se estudia en [Pre01, cap. 17] y [Pre01, cap. 118.3, 18.4, 18.5 y 18.6] (o bien [Pre97, cap.
16] y [Pre97, cap. 17] en la 4a edicin) y [Pre01, cap. 23] (o bien [Pre97, cap. 22] en la 4a edicin).
6.3. Documentacin de pruebas

Como una fase ms, todos los elementos preparados para las pruebas y los resultados de las mismas deben ser documentados
y adjuntados a cada versin correspondiente de los productos de las fases anteriores. Esta forma de proceder evitar la repeticin
de pruebas y facilitar la preparacin de nuevas pruebas a partir de otras anteriores.
Plan de pruebas
Son un conjunto de actividades que pretenden demostrar que el producto cumple con lo estipulado en el contrato. En el plan
de pruebas se especifica:
1. Identificador del plan: Debera ser una palabra que lo identificase con su alcance. Hay que incluir adems la versin y
fecha.
2. Alcance: Tipo de prueba y propiedades del software a ser probado.
3. Items a probar: Configuracin a probar y condiciones que se deben satisfacer para ello.
4. Estrategia: Tcnica y herramientas a utilizar. Hay que indicar el nmero mnimo de casos de prueba a realizar y el grado
de automatizacin tanto en la generacin de casos de prueba como en la ejecucin
5. Categorizacin de la configuracin: Condiciones bajo las cuales el plan debe ser:
Suspendido: Si se presentan demasiados defectos o fallos.
Repetido.
Dado por terminado: Si se cumple el nmero mnimo de casos de prueba.
6. Documentacin: Segn el estndar IEEE 829-1983 hay que producir los siguientes documentos:
Plan de prueba.
Especificacin de los requerimientos para el diseo de los casos de prueba.
Casos de prueba. Para cada uno se especifican: Descripcin del procedimiento de prueba y Descripcin del tem a
probar.
Bitcora de pruebas.
Informe de incidentes de prueba.
Resumen de pruebas.
7. Procedimientos especiales: Grafo de las tareas necesarias para preparar y ejecutar las pruebas, as como habilidades
necesarias.
8. Recursos: Pueden ser muy variados
Caractersticas de hardware y software.
Software necesario para hacer las pruebas.
El software a ser probado.
Configuracin del software de apoyo.
Recursos humanos necesarios para el proceso.
Requerimientos especiales: Actualizacin de licencias, espacio de oficina, tiempo de mquina, seguridad, etc.
9. Calendario: Hitos del proceso y grafo de dependencias.
10. Riesgos: Riesgos del plan, acciones para mitigarlos y planes de contingencia.
11. Responsables: Lista de personas y tareas asignadas.
Existen cuatro tipos de pruebas que deben superarse
Pruebas funcionales: Se realizan con los datos de entrada normales en el uso diario del sistema. Se comprueban sobre
todo valores en los lmites de las variables y un poco ms all de los lmites. Tambin algunos valores especiales.
Pruebas de desempeo: Miden el rendimiento del sistema. Tiempos de respuesta, utilizacin de la memoria, trfico
generado en las comunicaciones, etc. Estas pruebas nos van a indicar donde estn los cuellos de botella del sistema.
6.3 Documentacin de pruebas
Pruebas de tensin: Se trata de sobrepasar los lmites de tolerancia del sistema de varias maneras: Conectar ms usuarios
al sistema de los permitidos, si tiene que gestionar x mega-bits por segundo de una lnea de comunicaciones probar a
aumentar ese ancho de banda, etc.
Pruebas estructurales: Es un anlisis de la lgica interna de un programa.
Tutorial posterior
Verificacin y validacin
La Verificacin y validacin se debe llevar a cabo a lo largo de todo el ciclo de vida. Verificacin es comprobar si el producto se
est construyendo correctamente. Validacin es comprobar si estamos construyendo el producto que se nos ha pedido. Se abordan
un conjunto de actividades y tareas para garantizar que se da una respuesta positiva a esas dos cuestiones. Uno de los puntos
importantes es que la V&V debe ser independiente, es decir, no pueden hacerlo las mismas personas que estn construyendo el
producto. Esta independencia se debe dar tanto en la gestin como en la financiacin. Las tareas de V&V se contemplan desde
tres perspectivas: sistemas genricos, sistemas expertos y software reutilizado, y en todas y cada una de las etapas del ciclo de
vida.
Tcnicas y mtodos de prueba
Se trata en esta seccin de realizar las pruebas que den una garanta acerca del cdigo. Se introducen los conceptos de Error,
Defecto y Fallo. Se definen un conjunto de principios que debe seguir toda prueba:
Casos de prueba: Es un conjunto de entradas y salidas esperadas para ellas. Existen dos tipos de pruebas: de caja blanca y de
caja negra. Existe un mtodo para crear casos de prueba para casos de uso.
Pruebas de caja blanca. Tcnicas y medidas: grafo de flujo, complejidad ciclomtica y criterios de cobertura del grafo.
Pruebas de caja negra. Tcnicas: particiones o clases de equivalencia y anlisis de valores lmite.
Cleanroom: Es una metodologa de desarrollo pensada para producir software muy fiable.
Revisiones sin ejecucin de cdigo: wallthroughs, inspecciones y auditoras,
Calidad del software: El modelo de McCall tiene en cuenta una serie de factores de calidad.
Documentacin de pruebas
Como en los dems captulos este es el apartado donde se pone sobre el papel el trabajo realizado con un documento llamado
plan de pruebas que es un documento que pretende demostrar que el producto cumple con lo estipulado en el contrato.
Ejercicios
1. Cules son los motivos por los que es conveniente que las actividades de V&V sean realizadas por un equipo independiente?
2. Cundo es mejor hacer la V&V, despus de construir el producto, antes, despus de una etapa concreta, ...?
3. Dado el programa de la figura 6.1:
Represntelo en algn lenguaje de programacin.
Halle los valores de a y b para cobertura de sentencias, decisiones, condiciones y decisin/condicin.
Hay algn bucle? De qu tipo? Cuntas veces conviene ejecutarlo?
Este tema tambin se puede consultar en [Som98, cap. 7] [BMP87, cap. 16 y 17].
Sobre calidad, pruebas y evaluacin del software, el NIST en Estados Unidos mantiene una pgina muy interesante: http:
//hissa.nist.gov/.
Fases de pruebas
a=a3*b
si
a>1000
no
a<100
no
b<3
si
msg="b es pequeo y a grande"
si
msg="a es pequeo y b da igual"
no
msg="b es grande y a tambien"
Write(msg)
Figura 6.1: Programa
Captulo 7
Fase de entrega y mantenimiento

Tutorial Previo
Introduccin
Como etapa final en el ciclo de vida del software se debe realizar la entrega de la primera versin al cliente y considerar las
posibles modificaciones posteriores de mantenimiento. Dentro del mantenimiento se deben incluir no slo las correcciones de
errores detectados posteriormente por el cliente, sino tambin las modificaciones necesarias para la actualizacin, e incluso las
peticiones de cambios por parte del cliente. Una vez que se entrega el producto, no ha acabado el trabajo, en realidad, es cuando
empieza (y de hecho, existen organizaciones que viven de ello, por ejemplo las que dan soporte para GNU/Linux y para otras
aplicaciones de libre distribucin). Existen varios tipos de mantenimiento, corregir errores es uno de ellos, otros son adaptar
el sistema a nuevos entornos o para proporcionarle nuevas funcionalidades. Es interesante medir el esfuerzo que se gasta en
mantenimiento, para lo que tambin existen sus correspondientes mtricas.
La documentacin describe el sistema desde la especificacin de requisitos hasta la aceptacin por parte del usuario. Esta
informacin debe estar estructurada y ser legible. Existen herramientas CASE que automatizan esta parte (hasta donde es posible).

Este tema presenta los elementos finales del ciclo de vida del software y est relacionado con la planificacin general del
mismo que se present en el primer tema y con las fases de desarrollo en los anteriores.
Objetivos del tema

Determinar cul es la finalizacin del desarrollo del software y la extensin de la vida del software desarrollado. Comprender
la problemtica asociada a mantener una aplicacin. Dar una gua de genrica de como realizar el mantenimiento y dar estrategias
viables para afrontarlo.

El contenido del tema es principalmente terico por lo que la metodologa est ms orientada al estudio de los contenidos y
la reflexin sobre los ejemplos.
Finalizacin del proyecto. Este material se incluye directamente en esta gua didctica.
Planificacin de revisiones y organizacin del mantenimiento. El material correspondiente a este apartado est en [Pre01,
caps. 9 y 30] (o bien [Pre97, caps. 9 y 27] en la 4a edicin).
Recopilacin y organizacin de documentacin. Este apartado est incluido en esta gua didctica.
7.1. Finalizacin del proyecto

Dentro del ciclo de vida del software, y como en cualquier actividad de ingeniera, es necesario tener presente la finalidad
del desarrollo y la obligacin de entrega del producto acabado al cliente. Una vez que el sistema ha pasado las pruebas se trata
de entregrselo al cliente y ponerlo en condiciones de empezar a funcionar. La estrategia de implantacin se decide desde la
fase de especificacin y se tiene en cuenta tanto la cobertura global como la geogrfica. Es recomendable hacer las siguientes
consideraciones:
1.
2.
3.
4.
Nmero de copias de cada parte del software que se va a entregar.

Tipo de medios para cada parte del software, incluyendo formato y versin en lenguaje legible por humanos.
Documentacin de requerimientos estipulados (manuales de usuario).
Derechos de propiedad y asuntos de licencia, sealamientos y acuerdos.
5
5. Custodia de los programas del sistema, incluyendo planes de recuperacin y de contingencia por desastres.
6. Instalacin.
7. Las responsabilidades y obligaciones del personal encargado de informtica y de los usuarios finales deben definirse
teniendo en cuenta lo siguiente:
Acceso a las instalaciones del nuevo usuario.
Disponibilidad y acceso a los sistemas y equipo del usuario final.
Disponibilidad de personal experto en las reas correspondientes.
La necesidad de validacin como parte de cada instalacin debe ser determinada.
Se debe validar el funcionamiento de todo el sistema despus de cada instalacin.
Un procedimiento formal para aprobar cada instalacin al complementarla.
7.1.1. Aceptacin
Se dice que el proyecto ha finalizado cuando todas las actividades tcnicas han terminado o se ha agotado su plazo y se han
facturado todos los conceptos al cliente (se hayan cobrado o no). Para evitar problemas en el momento en el que se pide al cliente
su aceptacin se debe redactar un documento que especifique claramente los requisitos (lgicamente este documento se redacta
en la fase de especificacin). Una vez que el cliente lo firma acepta que est conforme.
7.1.2. Informe de cierre del proyecto

Es un resumen de lo sucedido, de si se han conseguido los objetivos y en caso negativo de las razones para ello. De un modo
esquemtico, la documentacin generada debe contener la siguiente informacin:
Balance de ingresos y gastos.
Valores positivos: Gastos superiores ->Menos beneficio.
Valores negativos: Ahorro ->Ms beneficio.
Informes de situacin finales.
Informe econmico.
Informe de situacin final. Se redacta en lenguaje no tcnico. Incluye:
Datos del proyecto: Nombre, duracin, etc.
Resumen de las incidencias: Modificaciones, problemas, soluciones, sugerencias futuras, etc.
Lista de documentacin generada.
Lista de productos generados.
La documentacin es tambin un modo de preservar el conocimiento de la empresa independientemente de la permanencia de
los empleados, asimismo detecta tendencias en el tipo de requisitos demandados, tipos de errores ms comunes, etc.
7.1.3. Indicadores del proyecto

Son un conjunto de medidas para evaluar de un modo objetivo los resultados.
1. Indicadores econmicos.
Facturacin del proyecto.
Margen del proyecto: Diferencia entre ingresos y costes, en valor absoluto y en porcentaje.
Beneficio del proyecto.
Coste por hora trabajada.
Precio de venta de la hora trabajada.
Componentes del coste del proyecto. Son los porcentajes del coste total del proyecto dedicados a cada uno de estos
apartados.
Valor relativo del esfuerzo propio.
Valor relativo de las subcontrataciones.
Valor relativo de los suministros.
2. Indicadores financieros
Porcentaje de endeudamiento externo (ajeno): Es el montante que hay que afrontar en caso de impago. Es el porcentaje dedicado a subcontrataciones, suministros, viajes y gastos varios.
7.2 Planificacin de revisiones y organizacin del mantenimiento
Porcentaje de endeudamiento interno (propio): Son los gastos que en caso de impago la empresa debera satisfacerse
a si misma. Es el complementario del anterior. Porcentaje de endeudamiento externo + Porcentaje de endeudamiento
propio = 1.
Valor actual neto del proyecto:
n
Fi
VA =
(7.1)
(1
+
r)i
i=1
Donde: Fi son los flujos monetarios del proyecto, n es el nmero de aos o meses desde que se produjo el flujo
monetario y r es la inflacin anual o mensual acumulada desde entonces.
Tasa de rendimiento (R) interno del proyecto.
R=
Ingresos Costes Margen

=
Costes Tiempo
Tiempo
(7.2)
3. Indicadores de ocupacin laboral. Indican la cantidad de personal para cada proyecto, su tasa de ocupacin y como consecuencia si sobra o falta personal.
Carga de trabajo: Nmero de horas para realizar un trabajo.
Nmero de personas necesarias para el proyecto.
ndice de ocupacin.
4. Indicadores de gestin. Hay cuatro indicadores de la calidad de este apartado:
Plazo de ejecucin.
Coste (global y por partidas)
Margen.
Contingencias.
7.2. Planificacin de revisiones y organizacin del mantenimiento

Adicionalmente a las revisiones durante el proceso de desarrollo inicial del software, tambin hay que considerar las posibles
modificaciones y revisiones como consecuencia del mantenimiento y actualizacin del mismo.
Tambin hay que considerar la posibilidad/certeza de que el cliente solicite cambios posteriores no previstos inicialmente, es
decir, hay que estar preparados para esta posibilidad.
El contenido de este apartado se estudia en [Pre01, caps. 9 y 30] (o bien [Pre97, caps. 9 y 27] en la 4a edicin).
7.3. Recopilacin y organizacin de documentacin

Como finalizacin de la parte de documentacin de todo el desarrollo, hay que hacer entrega de la documentacin apropiada
como una parte integral del producto resultante. En esta fase es necesario reunir todos los documentos generados y clasificarlos
segn el nivel tcnico de sus descripciones. Es muy importante distinguir entre la documentacin orientada a futuros desarrollos o
modificaciones de mantenimiento (documentacin de diseo, implementacin y pruebas, manual tcnico, manual de referencia),
frente a la documentacin de uso y aplicacin (introduccin de uso rpido, manual de configuracin, manual de usuario, manual
de interfaz). Una vez que se ha finalizado el proyecto se debe tener una documentacin til para el mantenimiento posterior y
para la operacin normal por parte de los usuarios. Esta seccin es una enumeracin bastante exhaustiva de esta documentacin.
7.3.1. Motivos de la documentacin

Hay dos motivos para contar con una buena documentacin:
1. Facilita el mantenimiento porque:
Ayuda a localizar donde hay que modificar o aadir cdigo.
Los mantenedores necesitarn menos tiempo para comprender cada mdulo.
Supone una forma de comunicacin entre profesionales, sobre todo si la forma en la que se ha realizado sigue un
estndar, por ejemplo, todo el mundo sabe interpretar un diagrama de clases de UML.
Una buena documentacin facilita que el mantenimiento lo puedan realizar terceras empresas o personas.
2. Facilita la auditora. Una auditora es un examen del sistema que se puede hacer desde varios puntos de vista. Por ejemplo,
aqu nos interesa saber si se estn cumpliendo plazos o las normas de la empresa en la redaccin del cdigo.
7.3.2. Directrices a seguir para la redaccin de un documento

Muchas organizaciones tienen un programa de documentacin, que es un procedimiento estandarizado de redactar los manuales tcnico y de usuario. Los procedimientos de documentacin deben ser estandarizados para que de esta forma la comunicacin
sea rpida, no ambigua y reduzca costes de personal, es decir, se debe huir de las florituras lingsticas propias de la literatura
haciendo nfasis en la claridad y la concisin.
En general todos los tipos de documentos deben tener un estilo homogneo, para ello se debe seguir un formato que tenga
estos elementos:
1. Un prembulo con: Autor(es) del manual, fecha, versin y revisores.
2. Un ndice con secciones y subsecciones. A la hora de empezar a redactar un documento se hace un primer esbozo de las
secciones a cubrir. Posteriormente, a medida que se van escribiendo se pueden hacer cambios, aadir o quitar subsecciones,
pero no en los puntos principales.
3. Se debe seguir un conjunto de normas respecto a dos cosas:
Respecto a la forma. P. ej: Tipo de letra Times new roman 11pt, los prrafos se indentarn con cuatro espacios, etc.
Respecto al contenido. P. ej: Se pondrn ejemplos explicativos, se tender a la brevedad, etc.
4. Se deberan usar las mismas herramientas de proceso de textos para todos los documentos, preferiblemente de alguna que
haya demostrado su continuidad en el tiempo, por ejemplo, LATEX, porque nunca se sabe cuanto durar el mantenimiento
(quizs dcadas).
5. Se cuidar en especial la claridad de expresin, los manuales deben tener ejemplos.
6. Los diagramas deben tener distribuidos los ejemplos de un modo lgico, no se deben poner demasiados en un nico
diagrama.
7. Al final debe existir un glosario de trminos.
8. Consistencia interna: No debe haber contradicciones.
9. Completitud: Se documentarn todas las partes del sistema.
10. Actualizacin con los cambios: Cada cambio en el sistema debe corresponderse con un cambio en las partes involucradas
de la documentacin.
7.3.3. Tipos de documentos

Existen tres tipos de documentos:
La dirigida a usuarios, que se centra en la operacin del sistema.
La dirigida al mantenimiento.
La dirigida al desarrollo.
Veremos ahora una lista de documentos. En un proyecto no es necesario que estn todos, sobre todo en proyectos pequeos donde
posiblemente no se haga un anlisis de riesgo o un anlisis costo-beneficio.
La informacin que se recoge en estos documentos deber ser actualizada durante el mantenimiento o cuando se hagan
cambios en los requisitos durante el desarrollo para conservar la consistencia entre lo que dice la documentacin y la realidad.
1. Estudio de viabilidad: Es una evaluacin de un proyecto, requisitos y objetivos y sus posibles alternativas.
2. Anlisis de riesgo: Identifica puntos vulnerables, sus posibles consecuencia, su importancia, causas y posibles soluciones.
Este documento ser actualizado en cada fase de desarrollo.
3. Anlisis costo-beneficio: Es una evaluacin de lo que va a costar el sistema y los beneficios esperados. Uno de los usos de
este anlisis es la seleccin de proyectos a desarrollar. Cada modificacin que se proponga al sistema tendr un impacto en
este anlisis, con lo que ser necesario revisarlo.
4. Informe de decisin de sistemas: Es el lugar donde est la informacin para la toma de decisiones de desarrollo. Incluye:
Necesidades a cubrir, Objetivos de cada uno de los hitos, Riesgos, Alternativas, Coste-beneficio y Planes de administracin
o justificacin de decisiones.
5. Plan de proyecto: Define los objetivos y actividades para cada fase. Incluye estimaciones de recursos y objetivos de
los hitos a lo largo de todo el ciclo de vida. Es donde estn definidos los procedimientos para diseo, documentacin,
notificacin de problemas y control del cambio. Se detallan las herramientas y tcnicas seguidas.
6. Requisitos funcionales: Son una lista de los servicios que suministra el sistema a los usuarios, que estarn definidos en
trminos cualitativos y cuantitativos. Tambin estn los requisitos de seguridad y control interno.
7. Requisitos de datos: Enumeracin de los tipos de datos, su descripcin y modo de captura. Deben identificarse especialmente los datos crticos para tener localizados los riesgos que de ellos se deriven y poder idear mecanismos de recuperacin
y seguridad.
8. Especificaciones de sistema/subsistema: Es un documento para los analistas de sistemas y programadores. Son los requisitos, entorno operativo, caractersticas de diseo y especificaciones de seguridad y control para el sistema o subsistemas.
9. Especificaciones del programa: Es otro documento dirigido a los desarrolladores. Son los requisitos, entorno operativo y
caractersticas de diseo de cada uno de los ejecutables.
7.3 Recopilacin y organizacin de documentacin
10. Especificaciones de la base de datos: Descripcin fsica y lgica de la base de datos junto a las especificaciones de
seguridad y control.
11. Pruebas: Estrategia de pruebas del sistema, con especificaciones detalladas, descripciones y procedimientos, as como
datos de prueba y criterios de evaluacin.
12. Manual de usuario: Describe las funciones del sistema. No debe usar jerga tcnica.
13. Manual de operacin: Descripcin del software y del entorno operativo para que pueda funcionar el software.
14. Manual de mantenimiento: Informacin acerca del cdigo fuente, sistemas y subsistemas para que el equipo de mantenimiento pueda entender el funcionamiento del programa y hacer cambios.
15. Plan de instalacin: Una vez que el sistema haya superado todas las pruebas est listo para ser instalado. Este manual
describe como se realiza el proceso en diferentes entornos.
16. Anlisis de la prueba e informe de evaluacin de seguridad: Son el resultado de las pruebas. Se muestran las fortalezas
y debilidades del sistema. Debe incluir un informe de evaluacin de seguridad para certificar el sistema.
7.3.4. Manual de usuario

La importancia de la documentacin de usuario estriba en que los usuarios no aceptarn un sistema que no puedan operar por
tener un manejo poco claro; un porcentaje alto de la culpa del fracaso en la aceptacin de los sistemas recae en una documentacin
pobre. Por otra parte, cuando se mantiene un sistema es deseable tener a mano la informacin de cmo estn hechas las cosas, de
otro modo puede ser ms fcil tirarlo todo y rehacer el sistema de nuevo.
Desde el punto de vista de los usuarios la opinin generalizada es que la documentacin:
1. No se entiende por usar tecno-jerga con la que el usuario no est familiarizado.
2. No se entiende porque el estilo de redaccin es oscuro y presupone conocimientos tanto tcnicos como del sistema que el
usuario no tiene por que tener.
3. No es completa.
4. Est mal estructurada y como consecuencia es difcil encontrar la informacin.
5. O lo que es peor: No existe o es escasa.
Recursos
Cunto esfuerzo se debera dedicar a la documentacin? En la empresa desarrolladora en total (anlisis, diseo, implementacin, pruebas y manuales tcnico y de usuario) entre un 20 y un 30 %. Durante el mantenimiento: para estudiar la documentacin
6 % y para actualizar la documentacin 6 %.
Objetivos del manual de usuario
1.
2.
3.
4.
Que el usuario sepa introducir los datos de entrada y obtener los de salida.
Que el usuario pueda interpretar correctamente los mensajes de error.
Es deseable que una parte del mismo pueda servir como tutorial del sistema.
Una parte debe ser un manual de referencia.
Es importante tener en cuenta a qu personas va dirigido el manual, no se redacta igual para un directivo, que probablemente
est ms interesado en una visin general del sistema que no va a usar directamente que a un empleado de base que se dedica
a introducir algunos datos o que un miembro administrativo que usar el sistema para por ejemplo sacar estadsticas de ventas.
Como existen diferentes perfiles de utilizacin el manual de usuario deber reflejar esto estructurndose en mdulos dirigidos a
tipos diferentes de personas.
Dentro de cada uno de los mdulos deberan existir procedimientos especficos para funcionalidades concretas. Un procedimiento sera una lista ordenada de acciones para conseguir algo. Las posibles bifurcaciones de cada procedimiento respecto al
camino principal debern documentarse igualmente.
Existen estndares de documentacin que especifican el ndice del manual (y algunos como el de GNU incluso el formato,
que debe ser T EXINFO para as poder ser traducido automticamente a otros formatos). En cualquier caso, el ndice deber
contener los siguientes puntos:
1. Instalacin del producto. Se indicarn los requisitos, tanto software como hardware.
2. Configuraciones posibles, teniendo en cuenta los diferentes perfiles de usuario.
3. Si el manual tiene varios mdulos en funcin de los perfiles de usuario, para cada uno de ellos:
Se indica un procedimiento para obtener cada funcionalidad. Debe indicarse la secuencia en la que se ejecutan las
acciones y las posibles bifurcaciones.
Cada procedimiento se entiende mucho mejor si tiene ejemplos.
Es deseable que exista un tutorial, ya sea en la aplicacin o en el manual.
Si se manejan documentos de entrada y/o salida se dar si ha lugar una breve explicacin sobre su nombre, formato,
origen, localizacin, usuarios que lo manejan y procesos de backup.
10
4. Manual de referencia: Es el documento que contiene toda la informacin en detalle.

5. Lista de errores con su significado y posible solucin, el usuario no tendr que recurrir a esta parte del manual si esta
informacin est disponible en la propia aplicacin. Esta parte puede estar en el manual de referencia.
6. Glosario de trminos.
Procedimientos y tutoriales
Formularios de entrada/salida: Especifica las normas para rellenar los formularios de entrada/salida (si es que existen).
Pantallas y mensajes: Contiene las instrucciones de operacin para los procesos on-line, incluyendo el flujo de pantalla
para cada uno de ellos, los mensajes del sistema y las asignaciones de las teclas de funcin. Confeccionar un glosario,
preferentemente on-line, con todos los mensajes de error que puede generar el sistema.
Informes del sistema: Presenta el inventario, el ejemplo y la descripcin detallada de los informes del sistema, incluyendo su ordenamiento, cortes de control, frecuencia de emisin, nmero de copias y forma de distribucin. Dividirlos en
categoras de acuerdo al nivel de los usuarios a quienes estn orientados.
Procedimientos de control: Describe la estructura general de los controles del sistema y define su relacin con los controles
manuales. Incluye la descripcin de los mecanismos para efectuar controles cualitativos y cuantitativos sobre los datos que
ingresan al sistema, los que se transfieren entre los distintos programas y sobre la informacin de salida, asegurando su
integridad y confiabilidad.
Procedimientos de usuario: Son los procedimientos requeridos para el uso del sistema. Deben quedar reflejadas las responsabilidades de cada sector usuario, en cuanto al envo y/o carga de informacin (tiempos y oportunidad de proceso), como
tambin sus responsabilidades en cuanto al control y aprobacin de las salidas del sistema.
Procedimientos de reabastecimiento: Son los procedimientos requeridos para la provisin de los insumos para utilizar el
sistema, como: formularios preimpresos, etiquetas, recargas para impresoras, diskettes, cintas, etc.
Soporte a usuarios: Son los procedimientos disponibles para obtener ayuda sobre el uso del sistema. Deben quedar reflejadas las opciones que tiene el usuario para solucionar una duda identificando el o los sectores responsables del servicio.
Material de capacitacin: Inventario de cada una de las opciones disponibles para capacitacin, ya sea autoasistida o a
travs de cursos, tutoriales, etc.
7.3.5. Manual del sistema

Desde el punto de vista de las personas que hacen el mantenimiento los problemas que se encuentran es que la documentacin:
1.
2.
3.
4.
5.
Nunca existi o se ha perdido!

Es incompleta o escasa.
No est actualizada con los cambios que se han ido haciendo al sistema.
Tiene contradicciones con el contenido real del cdigo.
No es clara.
Objetivos
Documentar en forma detallada las caractersticas de cada componente de la arquitectura tcnica del sistema.
Servir como base para el mantenimiento futuro de los procesos y programas del sistema.
Contenidos
1. Descripcin general del sistema
Identificacin del sistema: Nombre y siglas que lo identifican.
Objetivos: Descripcin breve del objetivo general del nuevo sistema, incluyendo referencia a las funciones del negocio
(planificacin, gestin, etc) qu cubre y cmo lo hace.
Alcance: Diagrama de contexto que muestre la interaccin del sistema con el resto de los sistemas de la organizacin.
Caractersticas generales. Descripcin breve de las siguientes especificaciones funcionales y/o tcnicas:
Enfoque de desarrollo (a medida, paquete de software, etc).

Herramientas de desarrollo.
Tipo de procesos.
Tecnologa de implementacin (hardware, software, comunicaciones, etc).
Polticas relacionadas con su uso. Siguiendo las polticas, normas y estndares vigentes, se debern adjuntar:
Identificacin del responsable de los datos.
Identificacin de informacin confidencial y pblica para su tratamiento.
Principales sectores usuarios.
11
Perfiles de usuarios y esquema general de seguridad.

Plan de contingencia que explique los mtodos de trabajo alternativos ante fallas.
Plan de recuperacin que explique los procesos de recuperacin y reinicio ante los casos eventuales de destruccin o desastre.
Principales funciones: Narrativa breve que describa las principales funciones del sistema. Se podr acompaar de un
esquema donde se identifiquen las actividades del negocio cubiertas por el sistema y sus necesidades de informacin.
Observaciones: Cualquier informacin que no haya sido especificada antes y que se considere de inters.
2. Arquitectura general del sistema
Requisitos funcionales: Expresar los requisitos funcionales que debe satisfacer el sistema
Eventos del sistema: Extraer del modelo de eventos una lista conteniendo todas aquellas funciones ejecutadas por los
distintos usuarios que originan una entrada al sistema. Indicando:
a)
b)
c)
d)
e)
Nmero de evento.
Descripcin.
Origen de la informacin.
Destino de la informacin.
Flujo de datos.
Procesos del sistema: Contiene el inventario y la descripcin general de cada una de las opciones de la aplicacin,
incluyendo imgenes de las pantallas utilizadas.
Dilogo del sistema: Muestra la comunicacin entre las distintas pantallas de la aplicacin identificando las condiciones que provocan la navegacin entre las mismas.
Modelo de procesadores: Muestra de manera grfica los distintos dispositivos fsicos requeridos, la asignacin de
tareas y la conectividad entre ellos.
Esquema de mdulos:Esquema donde se visualice el sistema como un conjunto de bloques, cada uno de los cuales
representa un mdulo o subsistema del mismo.
3. Especificaciones de los mdulos. Por cada mdulo deber tenerse la siguiente informacin:
Nombre del mdulo.
Descripcin detallada del mdulo y sus funciones.
Diagrama general del mdulo.
Flujo de pantallas (si corresponde)
Lista de componentes que lo implementan.
Lista de bases de datos.
Lista de archivos y tablas que utiliza.
Lista de las vistas lgicas de los datos.
Lista de los informes que genera.
4. Especificaciones de los procesos
Inventario general de procesos del sistema: Es una lista de todos los procesos, la cual contendr los siguientes datos:
Nombre del proceso, Descripcin breve y Mdulo al que pertenece mdulos que incluye.
Dejar documentado que para obtener informacin particular de cada proceso se deber relacionar este manual con el
manual de operaciones.
5. Especificaciones de programacin: Para cada componente de programacin del sistema (dependiendo del lenguaje a
utilizar: programa, subrutina, procedimiento o funcin), deber incluirse la siguiente informacin:
Nombre del componente.
Descripcin y objetivos.
Diagrama general del componente.
6. Especificaciones de los datos
Modelo conceptual de datos: Permite visualizar las entidades de datos requeridas por el sistema y sus relaciones. Se
debern adjuntar:
Diagrama general.
Diagrama de las distintas vistas (si fuese necesario).
Definicin de las entidades.
Diccionario de datos.
12
Diseo lgico de base de datos: Documenta la base de datos segn la perspectiva de los desarrolladores de aplicaciones y los usuarios finales, sin preocuparse por su implementacin fsica en un DBMS (Database Management
System) particular. Se debern adjuntar:
Diagrama de tablas y sus relaciones.
Diagrama de las distintas vistas (si fuese necesario).
Definicin de atributos y dominios.
Diseo fsico de base de datos: Contiene las definiciones detalladas de todos los archivos y/o bases de datos del sistema y cada uno de sus componentes (tablas, columnas, claves, ndices, integridad referencial, triggers, etc). Adjuntar
la forma en que cada programa los accede y procesa sus datos, su localizacin fsica y la descripcin de su sistema de
backup. Para aquellos que tengan proceso de mantenimiento independiente del sistema, se deber adjuntar la forma
de acceso al men correspondiente y las instrucciones para su uso.
7.3.6. Manual de mantenimiento

Objetivos
Contener los procedimientos requeridos para asegurar el mantenimiento del sistema despus de su instalacin.
Identificar los materiales necesarios para el proceso de mantenimiento.
Documentar la ubicacin de cada componente del sistema susceptible de ser modificado.
Contenidos
1. Documentacin del sistema: Contiene el inventario y una breve descripcin del contenido de cada uno de los manuales
que conforman la documentacin del sistema, as como el nmero de copias emitidas, su distribucin y las ubicaciones
fsicas en las que se encuentran almacenadas. Esta informacin permite asegurar que todas las modificaciones que se
efecten sobre el sistema despus de su instalacin se reflejen en la documentacin existente.
2. Libreras del sistema: Presenta el inventario de todas las libreras fuente y objeto del sistema, detallando para cada una de
ellas los siguientes datos:
Nombre, versin, fecha, ubicacin, tipo y uso (de test, produccin, etc.)
Contenido (directorio de cada librera).
Instrucciones de uso.
Lista de autorizaciones de acceso.
3. Modelo de pruebas del sistema: Contiene toda la informacin generada para la ejecucin de las pruebas del sistema
(pruebas unitarias, prueba de integracin, pruebas de usuario y prueba de aceptacin del usuario).
4. Material de capacitacin: Incluye el inventario y la descripcin del material de capacitacin disponible (manual del
instructor, guas de participante, casos prcticos, etc.) incluyendo su ubicacin, nmero de copias existentes y la audiencia
a las que se encuentran orientados.
5. Instrucciones de soporte a usuarios: Define los procedimientos de servicio al usuario para dar respuesta a las llamadas
de emergencias, los requisitos de mejoras o absorber consultas especficas acerca del sistema. Asimismo especifica los
procedimientos para registrar las fallas o problemas que se presenten durante la operacin diaria del sistema.
Tutorial posterior
Finalizacin del proyecto
El objetivo llegados a este punto consiste en entregar el producto al cliente y ponerlo en condiciones de funcionar. La
aceptacin ocurre cuando han terminado todas las actividades. Se adjunta una plantilla para el informe de cierre del proyecto.
Los indicadores del proyecto son un conjunto de medidas para evaluar de un modo objetivo los resultados. Son de varios tipos:
econmicos, financieros, de ocupacin laboral y de gestin.
Planificacin de revisiones y organizacin del mantenimiento
Se definen los 4 tipos de mantenimiento (perfectivo, correctivo, adaptativo y preventivo) y la problemtica asociada. Se define
el concepto de cdigo heredado (legacy code) y se da una descripcin de como se debe gestionar el mantenimiento. Se define
a su vez una plantilla de documento para esta tarea. El objetivo de la planificacin del mantenimiento es asignar recursos
lo antes posible para que estn disponibles en su momento, para ello se define un plan de mantenimiento. Las tcnicas de
mantenimiento son: ingeniera inversa, identificacin de componentes funcionales, reestructuracin y reingeniera.
13
Recopilacin y organizacin de la documentacin

Se exponen los motivos para documentar, directrices genricas a seguir para la redaccin de un documento, una clasificacin de los documentos y una plantilla a seguir para los ms importantes. El tipo de documentos que se contemplan aqu son
los dirigidos a usuarios o mantenedores. Se hace hincapi en el manual de usuario, el manual del sistema y el manual de
mantenimiento.

1. Qu es la barrera del mantenimiento? Hay alguna solucin?
2. Qu cosas debe tener en cuenta el plan de mantenimiento?
3. Las pruebas de regresin son las mismas pruebas que se han aplicado antes pero que vuelven a pasarse cada vez que se
hace un cambio. Es razonable pasar las pruebas de regresin de los mdulos que no se cambian?.
4. Cules son los objetivos del manual de usuario?
5. En qu manuales situara la siguiente documentacin?
Arquitectura general del sistema
Lista de mensajes de error
Tutorial
Diseo lgico de la base de datos
Diseo fsico de la base de datos
Informacin acerca de las pruebas
Especificacin de los procesos
Los contenidos de este tema tambin se puede estudiar en [Som98, cap. 8], [Haw98, cap. 19] [Sch92, cap. 11].

Temario Completo de Ingenieria de Software

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Temario Completo de Ingenieria de Software

Transféré par

Droits d'auteur :

Formats disponibles

ndice general

1. Contexto de la asignatura en la Ingeniera de Software

2. Descripcin de ejemplos gua

4.5. Documentacin: especificaci del diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7. Fase de entrega y mantenimiento

Contexto de la asignatura en la Ingeniera de

Relacin con otros temas

Objetivos del tema

Gua de estudio y esquema

Contexto de la asignatura en la Ingeniera de Software

1.1. Necesidad de una metodologa

1.1.2. La crisis del software

1.1.3. Definicin de metodologa

1.1 Necesidad de una metodologa

1.1.4. Finalidad de una metodologa

1.1.5. Taxonoma de las metodologas

Figura 1.1: Ejemplo de DFD

Contexto de la asignatura en la Ingeniera de Software

2. Es fcil de mantener debido a que los cambios estn ms localizados.

1.2. Ciclo de vida del software

1.2 Ciclo de vida del software

Figura 1.2: Etapa genrica

1.2.1. Ciclos de vida en cascada

Figura 1.3: Ciclo de vida en cascada

Contexto de la asignatura en la Ingeniera de Software

Si se han cometido errores en una fase es difcil volver atrs.

Figura 1.4: Ciclo de vida en V

Ciclo de vida tipo sashimi

1.2 Ciclo de vida del software

Figura 1.5: Ciclo de vida sashimi

Figura 1.6: Cascada incremental

Ciclo de vida en cascada con reduccin de riesgos

Contexto de la asignatura en la Ingeniera de Software

El resto es igual al ciclo de vida en cascada.

1.2.2. Modelo de ciclo de vida en espiral

Plan del ciclo de vida

Simulaciones, Modelos, Benchmarks

Plan de integracion Verificacion y validacion

Figura 1.7: Ciclo de vida en espiral

1.2 Ciclo de vida del software

1.2.3. Ciclos de vida orientados a objetos

Planificacion Investigacion Especificacion Implement. Revision

Figura 1.8: Ciclo de vida fuente

Contexto de la asignatura en la Ingeniera de Software

1.3. Notaciones de especificacin y diseo (UML)

1.3 Notaciones de especificacin y diseo (UML)

1.3.2. Modelo de casos de uso

Contexto de la asignatura en la Ingeniera de Software

Figura 1.9: Asociacin entre un caso de uso y un actor

Figura 1.10: Relaciones entre casos de uso

1.3 Notaciones de especificacin y diseo (UML)

1.3.3. Modelo estructural esttico

Valor por defecto

Figura 1.11: Plantilla para una clase en UML

Contexto de la asignatura en la Ingeniera de Software

de instancia: cuando cada objeto tiene su propio valor,

Figura 1.12: La representacin de clase ms sencilla posible

Figura 1.13: Smbolo en UML de un objeto

1.3 Notaciones de especificacin y diseo (UML)

Figura 1.14: Interfaces

Papel de cada parte

Figura 1.15: Ejemplo de una asociacin

Contexto de la asignatura en la Ingeniera de Software