Modelos de Desarrollo de Programas - FIWIKIMDP_Objetos.pdf · Modelos de Desarrollo de Programas 1. Ciclo de vida del software 1.1. Introduccion´ Una computadora consta de dos partes

Modelos de Desarrollo de Programas

Modelos de Desarrollo Orientados a Objetos

Adriana Castro Bonenfant

Curso 2009/2010


Indice1. Ciclo de vida del software 3

1.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Concepto de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Ingenierıa del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5. Ciclo de vida clasico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5.2. Ingenierıa del Sistema o Analisis del Sistema . . . . . . . . . . . . . . 41.5.3. Analisis de los Requisitos del Software . . . . . . . . . . . . . . . . . 51.5.4. Diseno de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.5. Codificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5.6. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5.7. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.6. Complejidad del desarrollo del Software . . . . . . . . . . . . . . . . . . . . . 81.7. Modelos de Desarrollo de Programas . . . . . . . . . . . . . . . . . . . . . . . 91.8. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.9. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Fundamentos de la orientacion a objetos 122.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3. Estructura de un problema orientado a objetos . . . . . . . . . . . . . . . . . . 122.4. Objetos, clases y mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1. Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.2. Clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.3. Mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5. Relaciones entre clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.1. Asociacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.2. Agregacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.3. Generalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.4. Dependencia (uso) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3. Metodologıa basica de desarrollo OO 213.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3. Introduccion al Proceso Unificado (PU) . . . . . . . . . . . . . . . . . . . . . 223.4. Captura y Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4.2. Encontrar actores y casos de uso . . . . . . . . . . . . . . . . . . . . . 243.4.3. Detallar los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 263.4.4. Definir un prototipo de interfaz de usuario . . . . . . . . . . . . . . . . 273.4.5. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Adriana Castro 1 FI - UPM


3.4.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5. Anlalisis y Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.3. Disenar la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.4. Disenar los casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.5. Diagramas de Secuencia de la Agenda Personal . . . . . . . . . . . . . 333.5.6. Disenar las clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5.7. Iteraciones (refinado de diseno) . . . . . . . . . . . . . . . . . . . . . 443.5.8. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.5.9. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.6. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.6.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.6.3. Implementar la arquitectura . . . . . . . . . . . . . . . . . . . . . . . 513.6.4. Implementar las clases . . . . . . . . . . . . . . . . . . . . . . . . . . 533.6.5. Realizar pruebas de unidad . . . . . . . . . . . . . . . . . . . . . . . . 593.6.6. Integrar el sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.7.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.7.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.7.3. Planificar y disenar las pruebas . . . . . . . . . . . . . . . . . . . . . . 613.7.4. Realizar las pruebas de integracion . . . . . . . . . . . . . . . . . . . . 633.7.5. Realizar las pruebas del sistema . . . . . . . . . . . . . . . . . . . . . 633.7.6. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.7.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64



1. Ciclo de vida del software

1.1. IntroduccionUna computadora consta de dos partes fundamentales: el hardware (o quincallerıa) que com-

prende todos los componentes informaticos, y el software (la parte blanda) que se compone detodos los programas informaticos existentes en la computadora.

El desarrollo de un programa informatico es un proceso de ingenierıa que requiere, al igual quecualquier otro proceso de ingenierıa, el desarrollo de una serie de fases, etapas y tareas, lo quese denomina el Ciclo de Vida del Software.

Para que un problema de la vida real se pueda resolver en una computadora hay que utilizarun Modelo de Desarrollo de Programas que transforme el problema en uno o varios progra-mas informaticos. Esto se consigue aplicando paso a paso a ese problema el Ciclo de Vida delSoftware.

1.2. ObjetivosConocer el concepto de Software y de Ingenierıa del Software.

Conocer el Ciclo de Vida del Software clasico.

Conocer la clasificacion del desarrollo de software segun su complejidad.

Conocer el concepto de Modelo de Desarrollo de Programas.

Conocer el concepto de Metodologıa de Desarrollo de Programas y su relacion con losModelos de Desarrollo.

1.3. Concepto de Software“Conjunto de programas informaticos que se desarrollan en el entorno de una computado-

ra”

Tres tipos:

Programas de control: controlan y supervisan la ejecucion de todas las tareas y procesosque tienen lugar en la computadora (ej.: el Sistema Operativo).

Programas de proceso: sirven para que el usuario desarrolle sus propios programas (ej.:compiladores, interpretes, montadores, etc.).

Programas de aplicacion: desarrollados por y para el usuario de la computadora pararesolverle problemas especıficos.

Los dos primeros tipos reciben el nombre de software del sistema.El tercer tipo se denomina software de aplicacion.



1.4. Ingenierıa del softwareEn los anos 60 se produce la Crisis del software: “el ingeniero del software se sentıa incapaz

de desarrollar proyectos de una dimension acorde con los avances tecnologicos de la epoca”.

En 1968 se reune el Comite Cientıfico de la OTAN, bajo la direccion de F. L. Bauer, y se cons-tata que el desarrollo de software es un proceso de ingenierıa (como el de otras disciplinas deingenierıa). Y su fin es “la produccion industrial de programas eficientes, fiables y robustos,elaborados con el mınimo coste y tiempo posibles

El Desarrollo de software (o el Desarrollo de programas) es un proceso de ingenierıa queprecisa durante su ejecucion desarrollar una serie de fases, etapas y tareaspara obtener un pro-grama que funcione correctamente.

1.5. Ciclo de vida clasico1.5.1. Introduccion

Ciclo de vida: describe que ocurre desde que se decide hacer un programa hasta que dejade utilizarse.

Ciclo de vida clasico o ciclo de vida en cascada. Fue disenado por Royce en 1970.

Tiene tres fases: una de Planificacion (¿que se debe hacer?), otra de Desarrollo (¿como se debehacer?) y una tercera de Mantenimiento (¿que cambios hay que hacer?)

Y seis etapas (Ingenierıa del Sistema, Analisis de los Requisitos, Diseno, Codificacion, Pruebasy Mantenimiento) tradicionales del ciclo de vida.

1.5.2. Ingenierıa del Sistema o Analisis del Sistema

Objetivo: realizar un analisis global del sistema (el software es por lo general una parte delsistema) y ver si es viable tecnica y economicamente. Existen tareas manuales que se debentratar dentro del sistema.

Productos:

Especificacion del Sistema, que consta de los siguientes documentos:

1. Objetivos generales del sistema: definen los fines del sistema, su funcionamiento yrendimiento requerido, las entradas y salidas, y las restricciones impuestas.

2. Especificacion de Requisitos de cada elemento del sistema: definen los requisitos delsoftware, del hardware, de las bases de datos, del personal y de los otros elementosque conforman el sistema.

3. Analisis Tecnico: evalua la viabilidad tecnica del sistema propuesto y recoge infor-macion sobe el rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad deproduccion.

4. Analisis Economico: es un analisis de coste-beneficio que evalua los costes estima-dos para la produccion y mantenimiento del sistema y los contrasta con los benefi-cios previstos.



5. Viabilidad del Sistema: evalua la viabilidad economica y de mercado, tecnica y legal,junto con un analisis del riesgo en desarrollar el sistema. Si el riesgo es grande suviabilidad disminuye.

6. Especificacion de la Arquitectura del sistema: consiste en definir un diagrama ge-neral de la arquitectura del sistema, un diagrama de los flujos de informacion quecirculan por el sistema, y una descripcion de los subsistemas que lo componen.

7. Definicion de las pruebas globales del sistema (denominadas “pruebas del siste-ma”).

Plan software: establece los requisitos del software (objetivos generales del sistema, re-quisitos del software, requisitos de las Bases de Datos, arquitectura del sistema).

1.5.3. Analisis de los Requisitos del Software

Objetivo: es un proceso de descubrimiento, refinamiento, modelado y especificacion quelleva a cabo el ingeniero del software para obtener la especificacion de requisitos del software.

Producto: Especificacion de Requisitos de Software (ERS) Consta de los siguientes docu-mentos:

1. Introduccion: describe los fines y objetivos del software a desarrollar.

2. Descripcion de la Informacion: describe los flujos y las estructuras de la informacion,ası como el hardware, el software y las interfaces hombre-maquina.

3. Descripcion Funcional: describe cada funcion (proceso) requerida para resolver el pro-blema.

4. Descripcion del Comportamiento: describe el comportamiento del software mediante dia-gramas de estado, con una especificacion de eventos y acciones.

5. Criterios de Validacion: incorpora las pruebas que deben realizarse al software, los lımitesde rendimiento y la respuesta esperada para que el cliente acepte el producto (pruebas devalidacion).

1.5.4. Diseno de Software

Objetivo: producir con detalle un modelo del problema real que sera implementado masadelante. Es la parte central del desarrollo del software, y tiene un Diseno Preliminar y unDiseno Detallado.

Diseno preliminar Consiste en establecer las estructuras de datos, desarrollar una es-tructura funcional y modular del sistema (los modulos se contemplan como “cajas ne-gras”) y definir la interfaz de usuario.

Producto: “Documento de Diseno General” Consta de la siguiente informacion:

1. Diseno de datos: consiste en identificar todas las estructuras de datos y operacionesque pueden realizarse sobre ellas. Tambien se establece un diccionario de datos.



2. Diseno arquitectonico: consiste en desarrollar una estructura modular del softwarey representar las relaciones de control entre los modulos.

3. Diseno de la interfaz hombre-maquina: consiste en disenar una interfaz de usuarioque proporcione una comunicacion bidireccional con el sistema.

4. Pruebas de integracion: consiste en disenar las pruebas que habra que aplicar a losdiferentes subsistemas que componen el sistema software.

Diseno detallado Objetivo: definir los detalles algorıtmicos de cada modulo (diseno pro-cedimental), refinar las estructuras de datos y la interfaz de usuario.

Producto: “Documento de Diseno Detallado” (Doc. de Diseno Final), que contiene:

1. Diseno detallado de los datos: consiste en revisar el diseno de datos preeliminar alfinalizar el diseno procedimental y producir el diseno fısico de cada uno de los datosque participan en el sistema.

2. Diseno arquitectonico: es el obtenido durante el diseno preliminar.

3. Diseno detallado de la interfaz hombre-maquina: consiste en revisar el diseno pre-liminar de la interfaz al finalizar el diseno procedimental y detallar su contenido.

4. Diseno procedimental de cada modulo: consiste especificar para cada modulo: untexto explicativo, una descripcion de su interfaz, una descripcion del modulo en unlenguaje de diseno, modulos que utiliza, organizacion de los datos y comentarios.

5. Pruebas para cada modulo: consiste en definir que pruebas hay que realizar a cadauno de los modulos (pruebas de unidad).

1.5.5. Codificacion

Objetivo: creacion de los programas informaticos aplicando algun paradigma y utilizandoun lenguaje apropiado de programacion.

Producto: “Codigo fuente”

Se debe codificar con un estilo que produzca un codigo comprensible, bien comentado y docu-mentado, y siguiendo convenciones de la organizacion.

En concreto, se debe tener en cuenta lo siguiente:

Debe documentarse con identificadores que sean significativos, incorporando comenta-rios al principio de cada modulo que indiquen lo que hace el modulo. Ası mismo, seincorporaran comentarios descriptivos en el cuerpo del modulo para describir funcionesde procesamiento.

Los datos se deben declarar en aquellos lugares que proporcionan un acceso rapido a lahora de identificarlos dentro de una sentencia.

Las sentencias deben ser simples y faciles de seguir.

Las entradas/salidas deben codificarse cuidadosamente, ya que son origen de multipleserrores difıciles de localizar.



1.5.6. Pruebas

Objetivo: descubrir errores en el software.Es un elemento crıtico para la garantıa de calidad del software.

Tipos de pruebas (por su ambito):

Pruebas del sistema: comprobar que todo el sistema satisface todas las necesidades delcliente.

Pruebas de validacion: comprobar que el software desarrollado satisface todos los requi-sitos de software.

Pruebas de integracion: comprobar que los subsistemas se han construido correctamente.

Prueba de unidad: comprobar que cada modulo funciona correctamente.

Tipos (por su diseno):

Pruebas de caja negra. Se llevan a cabo sobre la interfaz del software, pretenden demos-trar que las entradas se aceptan de forma adecuada y que se produce una salida correcta.

Pruebas de caja blanca. Se basan en un minucioso examen de los detalles procedimen-tales. Se comprueban los caminos de los algoritmos del software (bucles, sentencias debifurcacion, etc.).

A continuacion, se representa graficamente la relacion existente entre las distintas etapas delciclo de vida y las fases de pruebas realizadas sobre el sistema.

La figura anterior se interpreta como sigue:

Proceso de desarrollo del sistema: Se inicia su desarrollo partiendo del centro de la fi-gura y recorriendo las diferentes semicircunferencias superiores, desde la mas internaa la mas externa, en el sentido contrario a las agujas del reloj.

Durante la semicircunferencia mas interna se produce la etapa de Ingenierıa del Sistema,que incorpora el diseno de las pruebas del sistema. Durante la siguiente semicircunferen-cia se produce la etapa de Analisis de los Requisitos del Software, que incorpora el disenode las pruebas de validacion. Durante la semicircunferencia siguiente se produce la eta-pa de Diseno, que incorpora el diseno de las pruebas de integracion y de unidad. Y porultimo durante la semicircunferencia mas externa se produce la etapa de Codificacion.



Proceso de pruebas del sistema: Se inician las pruebas partiendo del centro de la figuray recorriendo las diferentes semicircunferencias inferiores, desde la mas externa a lamas interna, en el sentido de las agujas del reloj.

Durante la semicircunferencia mas externa se realizan las pruebas de unidad, que las llevaa cabo el programador. Durante la semicircunferencia anterior se realizan las pruebas deintegracion, que las lleva a cabo el disenador. Durante la semicircunferencia anterior serealizan las pruebas de validacion, que las lleva a cabo el analista de aplicaciones. Y porultimo durante la semicircunferencia mas interna se realizan las pruebas del sistema, quelas lleva a cabo el ingeniero de sistemas.

Debe senalarse que, generalmente, se considera como implementacion la union de las dosetapas de codificacion y pruebas de unidad (es decir, Implementacion = codificacion +pruebas). Por lo tanto no puede decirse que la implementacion y la codificacion sean lomismo.

1.5.7. Mantenimiento

El software debe ser mantenido, ya que sufrira cambios debidos a:

Corregir los errores encontrados (“mantenimiento correctivo”).

A cambios en el entorno externo al que el software debe adaptarse (“mantenimiento adap-tativo”). Por ejemplo pasar de Windows a Unix, o bien adaptarse al cambio de monedade pesetas a euros.

El cliente requiere ampliaciones funcionales o mejoras (“mantenimiento perfectivo”).

NOTAComo este ciclo de vida se aplica a problemas bien definidos (consistentes, precisos, no ambi-guos y determinados), se pasa de una etapa a la siguiente cuando la anterior ha sido basicamenteresuelta, existiendo un proceso de reciclaje para verificar que la etapa siguiente cubre las espe-cificaciones de la etapa anterior.

1.6. Complejidad del desarrollo del Software[Yourdon, 1979] realiza la siguiente taxonomıa de la complejidad del software:

a) El proyecto trivial (<1.000 lıneas de codigo): puede ser desarrollado por una persona enpocos meses. Utilizar una metodologıa en su desarrollo puede ser deayuda. Ej. Programaque realiza las altas en la Nomina.

b) El proyecto simple (<10.000 l.c.): es ya un proyecto formal. Se necesita la dedicacion de3 o 4 analistas/programadores y una duracion de 6 a 12 meses. Utilizar una metodologıaen su desarrollo produce un producto mas mantenible. Ej. Sistema Retributivo de unaempresa.

c) El proyecto difıcil (<100.000 l.c.): suele ocupar a un equipo de 6 a 12 informaticos duran-te 2 o 3 anos. Utilizar una metodologıa en su desarrollo es indispensable para tener unaesperanza razonable de que se pueda terminar en el tiempo previsto y dentro del pre-supuesto estimado. Ej. Sistema General de Gestion de Personal de una empresa grande.



d) El proyecto complejo (<1.000.000 l.c.): exige entre 50 y 100 personas durante un perıodode 3 a 5 anos o mas. Utilizar una metodologıa en su desarrollo es esencial para acabarel proyecto. Ej. Gestion Integrada de un centro de proceso de datos ( Personal, Centros,Economica, etc.)

e) El proyecto casi imposible (< 10.000.000 l.c.): se impone en su desarrollo una metodo-logıa orientada a objetos. Durante el desarrollo de estos proyectos se produciran cam-bios tecnologicos, de personal, de usuarios, etc. difıciles de controlar.

f) El proyecto imposible (mas de 10.000.000 l.c.): como es obvio no procede su plantea-miento.

Programacion en pequeno (o “Desarrollo de Programas”): trata el desarrollo de programastriviales, e incluso simples. Se centra en la fase de Desarrollo.

Programacion en grande (o “Ingenierıa del Software”): trata el desarrollo de programassimples en adelante. El peso del proceso cae en la Planificacion, Mantenimiento y Gestion delproyecto.

1.7. Modelos de Desarrollo de ProgramasModelo de desarrollo: es una filosofıa de desarrollo para obtener un software de unas de-

terminadas caracterısticas.

Metodologıa de desarrollo: es un proceso concreto de desarrollo (con sus fases, etapas y acti-vidades) que implementa el modelo de desarrollo.

En este curso nos centraremos en dos modelos:

1. Modelo orientado a objetos: trata de obtener un programa que estructura el problema enun conjunto de objetos que interactuan entre sı para resolver el problema.

• Se presentara la Metodologıa basica de desarrollo orientado a objetos basada en el pro-ceso unificado de Rational (RUP).

2. Modelo orientado a procedimientos y datos: trata de obtener un programa independi-zando las estructuras de datos de los procedimientos. Estos actuan sobre los datos pararesolver el problema.

• Se presentara la Metodologıa orientada al flujo de datos, tambien llamada metodologıaestructurada.

1.8. Ejercicios1. ¿Un programa de control sirve para que el usuario desarrolle sus propios programas?

No

2. Un videojuego ¿que tipo de software es?Programa de aplicacion.

3. ¿Que fases tiene el ciclo de vida clasico?Planificacion, Desarrollo y Mantenimiento



4. ¿Para que sirve el Plan Software?Para establecer los requisitos del software

5. ¿Validar software quiere decir que se esta construyendo correctamente el producto?No, quiere decir que se esta construyendo el producto correcto

6. ¿En que etapa del ciclo de vida se disena la interfaz de usuario?Diseno Preliminar

7. ¿Cuando se disenan las pruebas de integracion?Diseno Preliminar

8. Cambiar en un programa software todos los literales, comentarios y la interfaz de usuariodel espanol al ingles ¿que tipo de mantenimiento exige?Adaptativo

9. ¿Para que es necesario utilizar una metodologıa en un proyecto difıcil?Para poderlo terminar en el tiempo previsto y dentro del presupuesto razonable

10. El desarrollo de software orientado al flujo de datos de E. Yourdon, ¿es un modelo dedesarrollo o una metodologıa?Una metodologıa

1.9. ConclusionesEl Software esta formado por Programas de Control, de Proceso y de Aplicacion.

El Desarrollo de Software (o el Desarrollo de Programas) es un proceso de ingenierıaque esta formado por fases, etapas y tareas. El desarrollo clasico (ciclo de vida clasico)tiene 3 fases: Planificacion, Desarrollo y Mantenimiento. Y seis etapas: Ingenierıa delSistema, Analisis de los Requisitos, Diseno, Codificacion, Pruebas y Mantenimiento.

La Ingenierıa del Sistema realiza un analisis global del sistema y ve si es viable. Producela especificacion del sistema, parte de la cual es el Plan software.

El Analisis de los Requisitos del Software produce la especificacion de los requisitosdel software (ERS).

El Diseno del Software consta de un Diseno Preliminar que establece las estructuras dedatos, funcional y modular del sistema y define la interfaz de usurario. Y un Diseno De-tallado que define el diseno procedimental del sistema y refina las estructuras anteriores.

Se realizan Pruebas del sistema, de validacion, de integracion y de unidad. Y estas pue-den ser de caja negra o de caja blanca.

El Mantenimiento puede ser correctivo, adaptativo o perfectivo.

La Complejidad del desarrollo de software se clasifica en los siguientes tipos de proyec-tos: trivial (<1000 l.c), simple (<10.000 l.c.), difıcil (<100.000 l.c.), complejo (<1.000.000l.c.), casi imposible (<10.000.000 l.c.); e imposible (> 10.000.000 l.c.)



El desarrollo de programas (objeto de esta asignatura) se centra en programas pequenos(triviales o simples), mientras que la ingenierıa del software aborda proyectos mas com-plejos.

Un modelo de desarrollo de programas es una filosofıa de desarrollo para obtener unsoftware de unas determinadas caracterısticas, mientras que una metodologıa de desa-rrollo es un proceso concreto de desarrollo que implementa el modelo de desarrollo.



2. Fundamentos de la orientacion a objetos

2.1. IntroduccionEn el Modelo de Desarrollo Orientado a Objetos (MDOO) el problema real se modela en la

computadora mediante un conjunto de objetos a los que se les envıa mensajes para resolver eseproblema.

Este proceso es bastante similar a la forma en la que se resuelve un problema en la vida real. Porejemplo, si queremos construir una casa pedimos (enviamos un mensaje) al arquitecto para quenos haga los planos de la casa. El arquitecto pedira al Colegio de Arquitectos que le apruebelos planos. Posteriormente, pediremos a un constructor que nos la construya. Y este pedira alAyuntamiento que le de la cedula de habitabilidad. Finalmente iremos a vivir en la casa.

Por otra parte, estos objetos suelen estar relacionados entre sı, por ejemplo el arquitecto ha depertenecer al Colegio de Arquitectos para solicitar que le aprueben los planos de la casa. Y elterreno donde se construya la casa ha de estar ubicado en el municipio del ayuntamiento queproporcione la cedula de habitabilidad.

2.2. ObjetivosComprender la estructura de un problema orientado a objetos.

Comprender los elementos principales del modelo de objetos: objetos, clases, mensajes.

Comprender las relaciones entre objetos y clases: asociacion, agregacion, generaliza-cion/herencia, y dependencia.

2.3. Estructura de un problema orientado a objetosEl modelo orientado a objetos (OO) transforma el problema real en un mundo de objetosen lugar de procedimientos y datos (ej. Loıc, MDP, Juan son objetos)

Los objetos interactuan entre sı mandandose mensajes para resolver el problema (ej. sonmensajes Calcular Matrıcula, Devolver creditos).

Cada objeto es una instancia de una clase (una clase representa un conjunto de objetossimilares). Una clase implementa un tipo abstracto de datos. (Son ejemplos de clase:Profesor, Asignatura, Alumno).

Los objetos (o las clases) estan relacionados unos con otros (ej. Juan esta matriculadoen MDP: relaciona al objeto Juan de la clase Alumno con el objeto MDP de la claseAsignatura).

2.4. Objetos, clases y mensajes2.4.1. Objeto

Un objeto es (segun Grady Booch):



Algo tangible o visible (ej. una bicicleta).

Algun concepto que puede ser comprendido intelectualmente (ej. un numero entero).

Algo hacia lo que se dirige el procesamiento o la accion (ej. una pila de datos).

Un objeto tiene un estado (atributos y valores), un comportamiento (una actuacion ante losmensajes, lo que produce un posible cambio de estado) y una identidad (que permite distinguira unos objetos de otros, como pueden ser el nombre de una variable que representa al objeto ola direccion en la que se almacena dicho objeto).

Para la descripcion de los conceptos OO (objetos, clases, mensajes, etc.) se utilizara la Nota-cion UML (siglas de Unified Modelling Language o Lenguaje Unificado de Modelado), en suversion 2.1.

El lenguaje UML fue creado por Grady Booch, James Rumbaugh, Ivor Jacobson y otrosautores.

El lenguaje UML permite usar el lenguaje de implementacion (C++, Java, ...) para ladefinicion de atributos y operaciones.

Notacion de Objeto en UML: Presenta varias posibilidades:

• Un rectangulo con dos partes: En la parte superior, el nombre del objeto y la clasesubrayados. En la parte inferior, los atributos del objeto con sus valores.

• Un rectangulo con el nombre del objeto subrayado (nos referimos a un objeto con-creto sin indicar la clase).

• Un rectangulo con el nombre de la clase subrayado (nos referimos a un objetogenerico de una clase determinada).

• En este caso se presenta a modo de ejemplo la representacion UML del objeto mdpde la clase Asignatura, con los atributos: curso, cuatrimestre, creditos, nombre,...,y sus valores correspondientes.

Debe senalarse que la aparicion de la parte dedicada a atributos es opcional. Esto quieredecir que en la version (a) se podrıa haber eliminado esa parte de la notacion y que en lasvariantes (b) y (c) se podrıa haber anadido.



2.4.2. Clase

Una clase es un marco o plantilla que permite crear objetos de la misma estructura ycomportamiento (puede verse como la representacion de un conjunto de objetos quecomparten una estructura y comportamiento comunes. Ojo: no es una coleccion, es decirno es un objeto que almacena otros objetos). Las clases son elementos estaticos quecorresponden al texto del programa (ej. Son clases Alumno, Empleado, ...).

Los objetos son instancias de una clase.

Una clase define atributos (que definen la estructura del estado de los objetos) y opera-ciones (que definen el comportamiento de los objetos, es decir, como reacciona cualquierobjeto de la clase ante cada mensaje). Los atributos y operaciones de una clase son co-munes a todas sus instancias.

Notacion de Clase en UML:

Una clase al igual que un objeto presenta varias posibilidades:

Un rectangulo con el nombre de la clase.

Un rectangulo dividido en dos partes, una con el nombre de la clase y con sus atributos.

Un rectangulo dividido en tres partes (formato general):

− En la parte superior se pone el nombre de la clase.

− En la parte intermedia se ponen los atributos. Cada atributo tiene una visibilidad, elnombre del atributo, el tipo del atributo y, opcionalmente un valor por defecto delatributo.

− En la parte inferior se ponen las operaciones. Cada operacion tiene una visibilidad,el nombre de la operacion, sus argumentos entre parentesis y, finalmente, el tipo deretorno de la operacion (si la operacion devuelve un resultado).

La visibilidad puede ser: + (publico), # (protegido), - (privado).

− Visibilidad publica (+) quiere decir que ese atributo u operacion es accesible portodos los objetos de cualquier clase.

− Visibilidad protegida (#) quiere decir que ese atributo u operacion es accesible porlos objetos de su clase y de las clases derivadas.

− Visibilidad privada (-) quiere decir que ese atributo u operacion solo es accesiblepor los objetos de su clase.



Ejemplo:

La clase Alumno tiene los atributos nombre y nummat como privados (que es lo mashabitual y recomendable) y los metodos AsignarMateria y CalcularImporteMatrıculacomo publicos (que es lo usual).

Nota: un metodo es la implementacion de una operacion para una clase. Ej. la clase “Ar-chivo” puede tener la operacion “Imprimir” que se puede implementar con distintos metodos:imprimir en ASCII, imprimir una imagen, imprimir un documento. Todos los metodos efectuanla misma operacion logica de impresion, pero diferente accion.

2.4.3. Mensaje

Un mensaje es la comunicacion que se envıa a un objeto para que realice un servicio.Como respuesta a ese mensaje, el objeto ejecutara una operacion que esta definida en la clasecorrespondiente.

En otras palabras, son los mensajes los que provocan que los objetos ejecuten los metodosdefinidos en sus respectivas clases.

En general un mensaje consta de tres partes:

1. El identificador del objeto receptor del mensaje (objeto que “trabajara”)

2. El nombre de la operacion que debe ejecutarse.

3. Los argumentos de la operacion (si los tiene).

Ejemplo:

Vamos a definir al alumno ?Luis Martınez?, con numero de matrıcula: 15129460, y le vamos aenviar dos mensajes: El m1 le indica que se matricule en la asignatura mdp. El m2 le indica quecalcule el importe de la matrıcula y lo imprima.

El codigo en C++ serıa:

Alumno a1(‘‘Luis Martinez’’, 15129460);a1.AsignarMartricula(mdp); // m1cout << a1.CalcularImporteMartricula(); //m2

Nota: a1 es el objeto receptor del mensaje (identificador). AsignarMartricula y CalcularImpor-teMatricula son nombres de las operaciones.

La sintaxis del envıo de mensajes depende del lenguaje de programacion. En el ejemplo anteriorde C++ se recoge la sintaxis mas habitual y que se aplica en mas lenguajes (como C++, Java,C#, etc.), pero en otros lenguajes la sintaxis puede ser muy diferente.



2.5. Relaciones entre clases2.5.1. Asociacion

Es una conexion semantica entre clases: “es un grupo de enlaces entre instancias de cla-ses”.

Ejemplos:

• Un paıs tiene una ciudad como capital (las clases son paıs y ciudad, y la asociacion es lacapitalidad).

• Un alumno estudia una o varias asignaturas (las clases son alumno y asignatura, y laasociacion es estudia).

Notacion UML para la Asociacion:

Se representan como una lınea (para relaciones binarias) o como un rombo unido conlıneas a las clases participantes (para relaciones n-arias).

Cardinalidad: Indica cuantos elementos de una clase se asocian con un elemento de la otraclase. Puede ser:

0..* (cuando se relaciona un elemento de una clase con 0 o varios de la otra) Esta cardi-nalidad se puede abreviar como *.

0..1 (cuando se relaciona un elemento de una clase con 0 o un elemento de la otra).

1..1 (cuando se relaciona un elemento de una clase con un solo elemento de la otra) Estacardinalidad se puede abreviar como 1.

2..* (cuando se relaciona un elemento de una clase con 2 o varios elementos de la otra).

Asociaciones Clase (son asociaciones que son clases con sus propios atributos y operaciones)Ej. Una persona esta contratada por una o varias empresas en las que interesa consignar la fechade contratacion (Persona y Empresa estan asociadas por un Contrato que a su vez es una clasecon el atributo fecha).

Ejemplos:



• En un paıs solo hay una ciudad (1) que sea capital, y una ciudad puede ser o no (0..1)capital de un paıs.

• Un alumno estudia 0 o varias asignaturas (0..*), y una asignatura es estudiada por 0 o va-rios alumnos (0..*).

• Una persona esta contratada por 0 o varias empresas (0..*), y una empresa contrata a 1o varias personas (1..*).

2.5.2. Agregacion

Especifica que un objeto es una parte de otro objeto (el agregado). El objeto agregado nopuede existir (no tiene sentido) sin que existan los objetos “parte” (o componentes) correspon-dientes.

Ejemplos:

• Un cuadro consta de marco, cristal, lamina (cuadro es el agregado, y marco, cristal, ylamina son los componentes).

• Una ventana de un entorno grafico de usuario tiene: tıtulo, menu principal, panel decontenido (ventana es el agregado, y tıtulo, menu y contenido los componentes).

Hay dos tipos de agregacion:

Debil: las partes pueden existir fuera del agregado (ej. En el cuadro: el marco, el cristal yla lamina pueden existir sin que formen un cuadro).

Fuerte (composicion): las partes solo existen dentro del agregado (ej. Si la ventana deWindows desaparece no existen ni el tıtulo, ni el menu principal, ni el panel de contenido).Dicho de otro modo, no puede existir un tıtulo ni un menu ni un panel de contenido si noestan asociados a una ventana).

Notacion UML para la Agregacion:

La agregacion se representa como una asociacion, pero con un rombo en el extremo del agrega-do. Si la agregacion es debil se representa con un rombo sin rellenar. Si la agregacion es fuertese representa con un rombo relleno.

Ejemplos:

• Un cuadro esta formado por 0 o 1 marco, 0 o 1 cristal, y por 0 o 1 lamina. Tambien indicaque el marco, cristal y la lamina pertenecen a 0 o 1 cuadro. La agregacion es debil porquesi desaparece el cuadro permanecen los componentes.



• Una ventana Windows esta formada por 0 o 1 tıtulo, 0 o 1 menu principal, y por 1 panel decontenido. Es decir, que la ventana Windows puede existir solo con el panel de contenido.Tambien indica que el tıtulo, menu principal y panel de contenido pertenecen a una solaventana Windows. La agregacion es fuerte porque si desaparece la ventana Windowsdesaparecen los componentes.

2.5.3. Generalizacion

Esta relacion especifica una “clase de” objetos (“es un”).

Ejemplos:

• Un alumno es una persona.

• Hay tres tipos de empleados: funcionarios, interinos, laborales.

Notacion UML para la Generalizacion: La generalizacion se representa con una flecha queparte de la subclase (clase mas especıfica) y va dirigida hacia la superclase (clase mas general).

Ideas sobre generalizacion:

Importante: La generalizacion no relaciona objetos, relaciona clases.

La generalizacion es una relacion entre una clase y una o mas versiones especializadasde la misma clase.

Las subclases heredan atributos y operaciones de las superclases. Ademas las subclasespueden definir nuevos atributos y operaciones.

Puede haber varios niveles de generalizacion, lo que define una “Jerarquıa de herencia”.Es en estas jerarquıas donde tiene sentido utilizar los atributos y operaciones protegidos,que solo pueden ser accedidos por objetos que son instancias de subclases de una dada.

La generalizacion no tiene cardinalidad.

2.5.4. Dependencia (uso)

Las relaciones de asociacion, agregacion y generalizacion son relaciones estructurales(afectan a la estructura del objeto). Mientras que la relacion de Dependencia no es estructu-ral.

Se dice que una clase tiene una relacion de dependencia con otra clase cuando requiere la exis-tencia de la otra clase para su definicion o implementacion.

Existe una relacion de dependencia de uso entre clases cuando una clase A utiliza las opera-ciones de otra clase B (y por lo tanto A depende del funcionamiento de B).



Notacion UML para la Dependencia de uso:

Se representa con una flecha de trazo que parte de la clase dependiente a la independiente.Encima de la flecha va una etiqueta con la palabra usa entre << y >> (este tipo de etiquetas sedenomina estereotipo en UML).

Ejemplo: La clase Documento usa a la clase Impresora porque para Imprimir utiliza como ar-gumento un objeto de la clase Impresora.

Existen mas tipos de relaciones de dependencia considerados en UML. Entre ellos destaca ladependencia de creacion (<<crea>>) cuando un objeto crea objetos de otra clase y la depen-dencia de destruccion (<<destruye>>) cuando un objeto elimina objetos de otra clase.

2.6. Ejercicios1. ¿Que tres elementos tiene un objeto?

Un estado,un comportamiento y una identidad.

2. ¿Una clase es un conjunto (Set) de objetos?No, es un marco o plantilla que permite crear objetos de la misma estructura.

3. ¿Cuales son los elementos que definen una clase?Los atributos y las operaciones.

4. ¿Que visibilidad suelen tener los atributos y las operaciones de una clase?Los atributos son privados, y las operaciones son publicas.

5. ¿Cuando mandamos un mensaje a un objeto, se puede negar el objeto receptor a ejecutarel mensaje?No, si ese mensaje se corresponde con una operacion del objeto.

6. ¿Cuales son las relaciones estructurales que existen en el modelo de objetos?Asociacion, Agregacion y Herencia.

7. Dados los objetos Persona y Coche, y la relacion de asociacion Conduce ¿que cardinali-dad existe en dicha relacion?Una persona conduce 0..* coches; un coche es conducido por 0..* personas.

8. ¿Que tipo de agregacion y cardinalidad existen en la figura geometrica Casa formada porun triangulo (tejado), un cuadrado grande (el cuerpo de la casa), cuadrados pequenos (lasventanas), y un rectangulo (la puerta)?El tipo de agregacion es debil. La cardinalidad de triangulo, cuadrados y rectangulo conCasa es de 0..1. La cardinalidad de Casa con triangulo, cuadrado grande y rectanguloes de 0..1. La cardinalidad de Casa con ventana es de 0..*.

9. ¿Que relacion existe entre Medio de Transporte y Coche, Autobus, Tren, Avion?Relacion de Generalizacion, siendo Medio de Transporte la clase padre..



10. ¿Un Coche hereda los atributos de un Autobus?No.

11. ¿Podemos decir que existe una relacion de Dependencia de Uso entre un Conductor y unCoche?No, existe una relacion de asociacion: Un conductor conduce un coche.

12. ¿Como se representan graficamente las relaciones de Asociacion, Agregacion, Generali-zacion y Dependencia de Uso?Asociacion con una lınea para relaciones binarias y un rombo para las n-arias. Agrega-cion como una asociacion pero anadiendo en el agregado un rombo sin rellenar para laagregacion debil, y relleno para la agregacion fuerte. Generalizacion con una flecha. YDependencia de uso con una flecha de trazo que va de la clase dependiente a la indepen-diente.

2.7. ConclusionesUn problema OO transforma el problema real en un mundo de objetos que interaccionanentre sı mandandose mensajes para resolver el problema.

Un objeto es una instancia de una clase y tiene un estado (definido por sus atributosy valores), un comportamiento (definido por sus operaciones) y una identidad (que lodistingue de los demas objetos).

Una clase define un conjunto de objetos similares (no es una coleccion de objetos) me-diante unos atributos (que definen el estado de cada objeto) y unas operaciones (quedefinen el comportamiento del objeto).

Un mensaje es la comunicacion que se envıa a un objeto para que realice un servicio.Este servicio lo realiza ejecutando una operacion definida en su clase.

Una asociacion es una relacion estructural semantica entre instancias de clases. Se repre-senta por una lınea (si es binaria) o por un rombo (si es n-aria).

Una agregacion es una relacion estructural que especifica que un objeto es una partede otro objeto. La agregacion es fuerte si al desaparecer el agregado desaparecen laspartes (se representa por un rombo relleno en el agregado). La agregacion es debil si aldesaparecer el agregado no desaparecen las partes componentes ( se representa por unrombo sin rellenar).

Una generalizacion es una relacion estructural que especifica una clase de objeto. Lassubclases heredan los atributos y operaciones de las superclases. Se representa con unaflecha que va de la subclase a la superclase.

La dependencia de uso es una relacion no estructural entre clases y se produce cuandouna clase utiliza las operaciones de otra clase. Se representa con una flecha de trazo.



3. Metodologıa basica de desarrollo OO

3.1. IntroduccionPara disenar un programa orientado a objetos podemos utilizar diferentes metodologıas de

desarrollo. Ha habido muchos investigadores que han desarrollado alguna metodologıa especıfi-ca de desarrollo de software OO.

Por ejemplo, Grady Booch desarrollo la metodologıa denominada “Object-Oriented Analysisand Design”, Ivor Jacobsson la denominada “Object-Oriented Software Engineering”, BertranMeyer la denominada “Object-Oriented Software Construction”, James Rumbaugh la denomi-nada “Object-Oriented Modelling and Design”, etc.

Pero la que ha quedado como metodologıa estandar de desarrollo OO es la que han desarrolladoconjuntamente G.Booch, I. Jacobsson y J. Rumbaugh dentro de la empresa Rational (ahora par-te de IBM) y que se denomina el “Proceso Unificado” (PU) de desarrollo de software orientadoa objetos.

En este tema se describe, a traves de tres lecciones, una Metodologıa Basica basada en el Proce-so Unificado de Rational para modelar software OO. Es decir, se describen aquellas Disciplinasy Actividades del Proceso Unificado que permiten desarrollar programas triviales y simples. Atal efecto:

a) En la primera leccion se vera:

• Una introduccion al Proceso Unificado.

− Caracterısticas, fases y disciplinas.

• La Captura de Requisitos:

− Encontrar Actores y Casos de Uso, Detallar los Casos de Uso, Disenar un Pro-totipo de la IU.

b) En la segunda leccion se tratara:

• El Analisis y el Diseno:

− Analizar los Casos de Uso y las clases, Disenar la Arquitectura, los Casos deUso y las Clases.

c) En la tercera leccion se describira:

• La Implementacion:

− Implementar la Arquitectura y las Clases, Realizar Pruebas de Unidad e Integrarel Sistema.

• Las Pruebas,

3.2. ObjetivosConocer al Proceso Unificado, en concreto sus caracterısticas, disciplinas y fases.



Conocer la diferencia que existe entre el desarrollo de todo el Proceso Unificado y laMetodologıa Basica que se utiliza para programas pequenos.

Comprender la naturaleza de los casos de uso.

Utilizar la tecnica de casos de uso para descubrir y averiguar lo que se desea que haga elsistema (es lo que se llama captura de requisitos).

Utilizar tecnicas basicas para definir un prototipo de la interfaz de usuario.

3.3. Introduccion al Proceso Unificado (PU)El Proceso Unificado es un proceso de desarrollo de software que describe “el conjunto de

actividades necesarias para transformar los requisitos del usuario en un sistema software”. Esun proceso iterativo e incremental.

Consta de nueve Disciplinas (o flujos de trabajo) y cuatro Fases.

Las Disciplinas son:

Seis de Desarrollo: (1) modelado del negocio, (2) captura de requisitos, (3) analisis ydiseno, (4) implementacion, (5) pruebas y (6) despliegue.

Tres de Soporte: (a) configuracion y administracion de cambios, (b) gestion de proyectos,y (c) ambiente.

Las Fases son: (1) Inicio, (2) Elaboracion, (3) Construccion y (4) Transicion.

Cada iteracion (o ciclo) trata las nueve disciplinas y produce una nueva version, que incorporaen el software mas funcionalidad y esta mas refinado.

Cada fase, que consta de una o varias iteraciones, define un estado del software y termina conun hito que plantea una serie de objetivos que se han tenido que alcanzar. Al finalizar cada hitola direccion del proyecto tiene que decidir si el trabajo puede continuar con la siguiente fase.

Para el desarrollo de programas pequenos se van a considerar unicamente cuatro disciplinasde desarrollo con una unica iteracion: (1) Captura de Requisitos, (2) Analisis y Diseno (3)Implementacion y (4) Pruebas.



3.4. Captura y Requisitos3.4.1. Introduccion

Objetivo final: tiene como objetivo final descubrir y averiguar lo que se desea que haga elsistema informatico, a traves de Casos de Uso.

Caso de Uso: Un Caso de Uso especifica una secuencia de acciones, incluyendo varian-tes, que puede realizar el sistema y que ofrece un resultado observable o tangible para undeterminado usuario. Ej. El proceso de Sacar Dinero de un Cajero automatico proporcio-na un resultado tangible al cliente, por lo que Sacar Dinero es un Caso de Uso.

Las actividades fundamentales de esta disciplina son tres:

Encontrar actores y casos de uso.

Detallar los casos de uso.

Definir un prototipo de la interfaz de usuario.

Vamos a aplicar esta Metodologıa al ejemplo de modelar una agenda personal en OO:

Realizar un programa que gestione una agenda personal. En esta agenda el usuario podra al-macenar dos tipos de elementos: datos de las personas que conoce (amistades o contactos deempresa) y datos de las citas que tiene con esas personas.

• Personas:

− Conocidas: nombre completo, numero de telefono y direccion de correo electronico.

− Empresa: nombre completo, numero de telefono y nombre de empresa.

• Citas: fecha, horas de comienzo y fin, persona con la que se establece y el lugar.

Las operaciones que puede realizar el usuario con su agenda son de dos tipos: modificacion dela agenda y consulta de la informacion almacenada.

• Agregar elementos en la agenda (personas conocidas, personas de empresa y citas), paralo cual debera proporcionar todos los datos correspondientes al tipo de elemento creado.

• Eliminar elementos, identificando el elemento que desee eliminar. Para ello debera pro-porcionar el nombre completo (para las personas) o la fecha y hora de comienzo (paralas citas).

• Consultar la informacion contenida en la agenda. Por un lado podra solicitar todos losdatos de una persona (incluido su tipo), dado su nombre debera proporcionar el nombrecompleto (para las personas) o la fecha y hora de comienzo (para las citas). Por otro,podra obtener una lista de las citas pendientes para un dıa concreto.

Por ultimo, deben tenerse en cuenta las siguientes restricciones al funcionamiento de la agen-da:

• Las personas deben ordenarse por orden alfabetico del nombre completo. Las citas debenordenarse por fecha de celebracion y, si hay dos citas el mismo dıa, se ordenaran por horade comienzo.



• No pueden existir dos personas que tengan el mismo nombre completo, aunque sean dedistinto tipo. El programa debera comprobarlo cuando se metan datos de una nuevapersona.

• No pueden existir dos citas el mismo dıa y a la misma hora. El programa debera probarlocuando se creen nuevas citas.

• Todas las citas que se introduzcan deberan ser con personas que aparezcan en la agenda.El programa debera comprobarlo cuando se creen nuevas citas.

3.4.2. Encontrar actores y casos de uso

Objetivos:Los objetivos de esta actividad son:

Separar el sistema de su entorno: que debe hacer el sistema y que deben hacer los usuariosy sistemas externos.

Identificar el tipo de usuarios que va a tener el sistema.

Definir como debe responder el sistema dependiendo del tipo de uso que se haga de el.

Esta actividad se divide en tres pasos: identificar actores, identificar casos de uso ydescribir elmodelo de casos de uso.

a) Identificar actores

Objetivo: consiste en encontrar los actores principales del sistema.

Un actor es:

Un tipo de usuario cuando este interacciona con el sistema en un caso de uso. Ej.El cliente cuando saca dinero del cajero automatico.

Un sistema externo que interacciona con el sistema en algun momento. Ej. El bancodel cliente conectado con el cajero automatico para validar la tarjeta de credito.

Resultado: Para cada actor se pone un nombre y una breve descripcion, indicando quienes y para que usa el sistema.

En el caso de la agenda personal el unico actor es el usuario de la agenda que interactuacon ella.

Usuario: persona que usa la agenda para gestionar sus contactos y citas.

b) Identificar casos de uso

Objetivo: identificar los casos de uso partiendo de los actores.

Criterios a seguir:



El caso de uso debe proporcionar un valor (o resultado) al actor que lo inicia. Conello se evita que los casos de uso sean demasiado pequenos. Ej. El caso de uso SacarDinero de un cajero automatico proporciona un valor al cliente que inicia el procesode sacar dinero. En cambio, Introducir la tarjeta en el cajero es una interacciondemasiado pequena que no proporciona un resultado al usuario.

El caso de uso debe proporcionar un valor a usuarios individuales reales y una solafuncionalidad (ası no sera demasiado grande). Ej. En un cajero automatico no serıaun buen caso de uso el siguiente: entrar, recargar un movil, consultar los ultimosmovimientos del mes y sacar dinero. Lo razonable serıa dividirlo en tres casos: (1)recargar un movil, (2) consultar movimientos y (3) sacar dinero.

Resultado: para cada caso de uso se debe especificar: un nombre (deberıa empezar converbo en infinitivo) y una breve descripcion.

Los casos de uso de la agenda personal son los 7 que se indican a continuacion. A tıtulode ejemplo se realiza una breve descripcion del caso de uso “Agregar persona conocida”.

Agregar persona conocida: “El usuario solicita agregar una persona conocida. La agen-da pide datos (nombre, telefono y email) y comprueba si existe una persona con el mismonombre. Si ya existe entonces termina la operacion con error. En otro caso, crea una per-sona y la almacena.”

Agregar persona de empresa

Consultar persona

Eliminar persona

Agregar cita

Consultar cita

Eliminar cita

c) Describir el modelo de casos de uso

Objetivo: consiste en describir como se relacionan los casos de uso entre sı y con losactores.

Resultado: Es el “Diagrama de casos de uso”.

La notacion que se utiliza para disenar el diagrama de casos de uso es la siguiente:

A continuacion se presenta el Diagrama de Casos de Uso de la agenda personal:Hay un unico actor (el usuario) que es quien inicia todos los casos de uso y los 7 casosde uso identificados anteriormente.



3.4.3. Detallar los casos de uso

Esta actividad consta de dos pasos que se realizan para cada caso de uso: disenar el diagra-ma de transicion de estados y realizar una descripcion textual completa.

a) Disenar diagramas de estados de cada caso de uso

El Diagrama de Estados es un grafo que describe el comportamiento dinamico del casose uso ante los sucesos (eventos) que se producen en el mismo.

El Diagrama de Estados esta formado por nodos y arcos:

Los nodos son los estados del caso de uso y los arcos son transiciones etiquetadascon los nombres de los eventos que las producen.

Cada transicion es una secuencia de acciones que se realizan cuando se recibe unevento.

En el Diagrama de Estados se distinguen el camino basico y los caminos alterna-tivos.

A continuacion se presenta el Diagrama de Estados de “Agregar Persona Conocida” (seresalta el camino basico):



b) Descripcion textual de casos de uso

La descripcion del caso de uso se realiza usando el lenguaje del cliente y tiene el siguien-te contenido:

Precondicion: indica el estado inicial del que parte el caso de uso y que quieren losactores.Flujo de Eventos del camino basico:• Describe la interaccion de los actores con el sistema y lo que intercambian.• Debe indicar quien hace cada cosa.

Caminos alternativos: Es una descripcion de los flujos de eventos de cada caminoalternativo que exista en el Diagrama de Estados del caso de uso.Poscondicion: Describe el estado final cuando termina el caso de uso y que obtienenlos actores.Atributos del caso de uso: son objetos o recursos del sistema que se utilizan en elcaso de uso y que definen el estado. Estos atributos pueden utilizarse para encontrarclases y atributos en la disciplina de analisis y diseno.

Ejemplo: Descripcion del caso de uso “Agregar persona conocida”

3.4.4. Definir un prototipo de interfaz de usuario

Objetivo:Esta actividad tiene como objetivo realizar un diseno en borrador de las interfaces de usuario



que se van a utilizar en cada caso de uso. Para ello, se definen:

Los elementos que participan en cada interfaz de usuario: describiendo las pantallas consu contenido (entradas y salidas) y los documentos (impresos o en formato electronico).

Los caminos entre esos elementos.

La notacion que se utiliza es la siguiente:

Pantalla: es un sımbolo de nota de UML (similar a una nota adhesiva) dividida en trespartes (nombre de la pantalla, informacion de entrada (→) o de salida (←), y accionesdel usuario). item Documento: es una sımbolo de nota dividida en dos partes (nombre deldocumento y contenido).

Ejemplo: prototipo de interfaz para “agregar persona conocida”.

3.4.5. Ejercicios

1. Enumerar las Disciplinas de Desarrollo del Proceso Unificado.Modelado del negocio, captura de requisitos, analisis y diseno, implementacion, pruebas,y despliegue.

2. ¿Por que se dice que el Proceso Unificado es iterativo e incremental?Es iterativo porque en cada ciclo se produce una version mas refinada que la anterior, yes incremental porque en cada ciclo se incorpora mas funcionalidad en el software.

3. ¿Que actividades incorpora la Captura de Requisitos?Encontrar actores y casos de uso, detallar los casos de uso, y definir un prototipo de lainterfaz de usuario.

4. ¿Para que sirve el Diagrama de Casos de Uso?Para describir graficamente como se relacionan los casos de uso entre sı y con los acto-res.

5. ¿Como se detallan los casos de uso?Disenando para cada caso de uso su diagrama de transicion de estados, y realizando unadescripcion textual completa del mismo.



6. ¿Que incorpora la descripcion textual de un caso de uso?Tiene el siguiente contenido: Precondicion, Flujo de Eventos del camino basico, Caminosalternativos, Poscondicion, Atributos.

7. ¿El prototipo de interfaz de usuario se disena con componentes graficos?No, con notas.

8. ¿Que tipo de notas se utilizan en el prototipo de interfaz de usuario?La Pantalla (dividida en tres partes: nombre de la pantalla, informacion de E/S, y ac-ciones del usuario), y el Documento (dividido en dos partes: nombre del documento y sucontenido).

3.4.6. Conclusiones

El Proceso Unificado consta de nueve disciplinas (modelado del negocio, captura derequisitos, analisis y diseno, implementacion, pruebas, despliegue, configuracion y admi-nistracion de cambios, gestion de proyectos, y ambiente) y cuatro fases (inicio, elabora-cion, construccion y transicion).

El Proceso Unificado es iterativo e incremental.

La Captura de Requisitos tiene como objetivo descubrir y averiguar lo que desea quehaga el sistema, a traves de casos de uso. Ello implica: encontrar actores y casos de uso,detallar los casos de uso, y definir un prototipo de la interfaz de usuario.

Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que puederealizar el sistema y que ofrece un resultado observable o tangible para un determinadousuario.

Encontrar actores y casos de uso implica: identificar actores (usuarios o sistemas exter-nos), identificar casos de uso (una funcionalidad que proporcione un resultado tangible aun usuario), y describir el modelo de casos de uso mediante el diagrama de casos de uso.

Detallar los casos de uso implica: disenar los diagramas de estados de cada caso deuso (grafo que describe el comportamiento dinamico del caso de uso), y realizar unadescripcion textual de los casos de uso utilizando el lenguaje del cliente.

Definir un prototipo de la interfaz de usuario consiste en realizar un borrador de lasinterfaces de usuario que se van a utilizar en cada caso de uso, describiendo las pantallascon su contenido y los documentos impresos de E/S.

3.5. Anlalisis y Diseno3.5.1. Introduccion

El Proceso Unificado distingue, para proyectos grandes, entre los modelos de analisis y lade diseno:

Modelo de analisis: es un modelo conceptual de objetos que refina y estructura los re-quisitos, de forma que facilita su comprension, modificacion y mantenimiento.



Modelo de diseno: es un modelo fısico del sistema a implementar que es mas formal queel del analisis y debe ser mantenido durante todo el ciclo de vida del software.

En programas pequenos solo se realizara el modelo de diseno.

Las actividades de la disciplina de diseno son tres que se realizaran de forma iterativa:

Disenar la arquitectura.

Disenar los casos de uso.

Disenar las clases.

3.5.2. Objetivos

Comprender el uso del diagrama de despliegue para disenar la arquitectura de un progra-ma.

Realizar un diseno del programa (modelo implementable), partiendo del modelo de casosde uso:

• Disenando los casos de uso, mediante la identificacion de clases y la descripcion dela interaccion entre objetos con diagramas de secuencia.

• Disenando cada una de las clases, mediante la identificacion de operaciones, deatributos, de asociaciones y agregaciones, de generalizaciones, y mediante la des-cripcion de metodos y de estados de las clases.

Realizar iteraciones en el diseno (de los casos de uso y de las clases) hasta llegar al disenofinal.

3.5.3. Disenar la arquitectura

Esta actividad tiene por objeto especificar si el sistema esta centralizado (un solo nodo deproceso) o distribuido. Para el caso de programas pequenos esta actividad tiene solo un paso.

Objetivo: consiste en identificar los nodos de proceso y su configuracion de red.

Resultado: es el Modelo de Despliegue que es un diagrama que muestra nodos de proceso, ac-tores y relaciones entre ellos. Un nodo de proceso se representa como un prisma (un rectangulocon efecto tridimensional).

El Modelo de Despliegue de la agenda personal, al tener un unico usuario y un unico nodo deproceso (no se trata de una agenda distribuida), es el siguiente:



3.5.4. Disenar los casos de uso

Objetivo: consiste en identificar las clases de diseno de cada caso de uso y distribuir elcomportamiento de los casos de uso entre los objetos de esas clases.

a) Identificar clases de diseno

Objetivo: consiste en identificar las clases de diseno de cada caso de uso y sus relacionesbasicas.

Las clases que se pueden identificar en la primera iteracion son:

Clases que sirven de interfaz entre los actores y el sistema. Habra una clase de estetipo para cada actor identificado.

Clases que llevan el control de la ejecucion del sistema. En general hay una clase deeste tipo para cada caso de uso, pero en programas pequenos se pueden unir todasen una unica clase de control.

Clases que almacenan informacion (entidades) que gestiona el sistema. Estas clasessalen de los atributos de los casos de uso.

De acuerdo con lo anterior, en el caso de la agenda personal habra:

Una clase interfaz porque solo tenemos a un actor (el usuario de la agenda).

Una clase control porque se trata de un programa pequeno.

Tres clases entidad para almacenar informacion de Personas Conocidas, Personasde Empresas y Citas.

El resultado son las clases de diseno que se indican a continuacion:

Las relaciones basicas entre estas clases de diseno son las siguientes:

El usuario se relaciona con la clase Interfaz (que es por donde introduce los datos yrecibe respuestas) y esta a su vez se relaciona con la clase Agenda, para que controlela ejecucion de las ordenes del usuario.

La clase Agenda se relaciona a su vez con las tres clases entidad: PConocida, PEm-presa y Cita, a las cuales tendra que solicitar que realicen una serie de acciones.

La clase Cita se relaciona con las clases PConocida y PEmpresa, ya que puede existiruna cita con cualquiera de ellas.

El resultado de estas relaciones basicas es el Diagrama de Clases Inicial que se indicaen la figura adjunta. En este diagrama inicial de diseno no se indican ni las relaciones deagregacion o generalizacion, ni las cardinalidades.



b) Describir interacciones entre objetos de diseno

Objetivo: consiste en describir como interaccionan entre sı los objetos correspondientesa las clases de diseno descritas anteriormente.

Resultado: como resultado se obtienen Diagramas de Secuencia (uno para cada caso deuso; pueden ser mas si hay caminos alternativos). Tambien se incluyen Diagramas deSecuencia para dos situaciones especiales: el arranque del sistema (Inicio) y el final de laejecucion (Salida).

Notacion de un Diagrama de Secuencia:

Incorpora en la parte superior los actores y los objetos de clase que participan en eseDiagrama de Secuencia.

Los actores y los objetos interactuan mandandose mensajes (flecha continua conpunta cerrada) y responden a los mensajes (flecha discontinua con punta abierta).Engeneral no se representan las respuestas en el diagrama. Solo se hace si la respuestadevuelve algo significativo (por ejemplo, un nuevo objeto que utiliza posteriormen-te).

Cuando un objeto recibe un mensaje se abre una lınea de vida (un rectangulo alar-gado) que esta abierta hasta que el objeto finaliza las acciones que tiene que realizarpara responder al mensaje.

Cuando un mensaje (o mensajes) se ejecuta varias veces (por ejemplo, para todos losobjetos de una clase), se encuadra en un fragmento denominado loop. La condicionde ejecucion del bucle se define entre corchetes dentro del fragmento.

Cuando un mensaje se ejecuta dependiendo de una condicion, se encuadra en unfragmento denominado alt. La parte superior del fragmento se realiza si se producela condicion [existe] y la parte inferior sino se produce [else]. Esta notacion admitecondiciones multiples (del tipo “case of”).

Cuando se quiere aclarar un concepto se incorpora una nota (un rectangulo con laesquina superior derecha doblada).

A continuacion se pone un ejemplo de esta notacion.



3.5.5. Diagramas de Secuencia de la Agenda Personal

Inicio del sistema:

“El Usuario pide al objeto Interfaz que inicie la ejecucion de la agenda personal (Ini-ciar()). Interfaz crea la Agenda (<<create >> Agenda).”

Agregar persona conocida:

“El Usuario pide a nterfaz que agregue una persona conocida en la agenda (AgregarP-Conocida()). Interfaz solicita al Usuario que le proporcione el nombre (n), el telefono(t) y el e-mail (e) de esa persona (esta solicitud no se representa en el diagrama de se-cuencia, ya que es consecuencia de la peticion del usuario). Seguidamente, Interfaz pidea Agenda que agregue esa persona en la agenda (AgergarPConocida(n,t,e)).

Agenda pregunta a todas las personas conocidas (PConocida) y a todas las personas deempresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si no existe ningunapersona con ese nombre entonces crea una persona conocida con esos datos (((create))PConocida(n,t,e)).”



Agregar persona empresa:

“El Usuario pide a Interfaz que agregue una persona de empresa en la agenda (Agregar-PEmpresa()). Interfaz solicita al Usuario que le proporcione el nombre (n), el telefono(t) y el nombre de la empresa (ne) de esa persona. Seguidamente, Interfaz pide a Agendaque agregue esa persona en la agenda (AgergarPEmpresa(n,t,ne)).

Agenda pregunta a todas las personas conocidas (PConocida) y a todas las personas deempresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si no existe ningunapersona con ese nombre entonces crea una persona de empresa con esos datos (((create))PEmpresa(n,t,ne)).”

Consultar persona:

“El Usuario pide a Interfaz que quiere consultar una persona (ConsultarPersona()). In-terfaz obtiene el nombre (n) de la persona que quiere consultar. Seguidamente, Interfazpide a Agenda que le proporcione informacion de la persona n (ConsultarPersona(n)).



Agenda pregunta a todas las personas conocidas (PConocida) si su nombre es n (Com-pararNombre(n)). Si la encuentra le pide que proporcione sus datos (EscribirDatos()). Sino la encuentra, pregunta a todas las personas de empresa (PEmpresa) si su nombre esn (CompararNombre(n)). Si la encuentra le pide que proporcione sus datos (EscribirDa-tos()).”

Eliminar persona:

“El Usuario pide a Interfaz que elimine a una persona de la agenda (EliminarPersona()).Interfaz obtiene el nombre (n) de esa persona y pide a Agenda que elimine a la personan de la agenda (EliminarPersona(n)).

Agenda pregunta a todas las personas conocidas (PConocida) y a todas las personas deempresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si la encuentra, preguntaa todas las citas (Cita) si hay alguna cita con esa persona (IgualNombrePersona(n)). Paraello cada cita pregunta a su persona si su nombre es n (CompararNombre(n)), si es ciertose lo comunica a Agenda y esta destruye esa cita (<<destroy>>Cita). Seguidamente,Agenda destruye a la persona conocida o la persona de empresa que haya encontrado(<<destroy>>PConocida o <<destroy>> PEmpresa).”



Agregar cita:

“El Usuario pide a Interfaz que agregue una cita en la agenda (AgregarCita()). Interfazsolicita al Usuario el nombre de la persona(n), la fecha de la cita (f), la hora de inicio de lacita (hi), la hora de fin (hf) y el lugar de la cita (l). Seguidamente, Interfaz pide a Agendaque agregue esa cita en la agenda (AgergarCita(n, f, hi, hf, l)).

Agenda pregunta a todas las personas conocidas (PConocida) y a todas las personasde empresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si encuentra a unapersona p con ese nombre, entonces pregunta a Cita si existe alguna cita con esa fechay esa hora de inicio (CompararFechaHora (f, hi)), si no existe ninguna crea una cita conesos datos (<<create>> Cita(p, f, hi, hf, l)), pasandole la persona (y no su nombre) comoparametro.”



Consultar citas:

“El Usuario dice a Interfaz que quiere consultar las citas de una determinada fecha(ConsultarCitas()). Interfaz solicita al Usuario que le proporcione la fecha (f) y pide aAgenda que le proporcione toda la informacion de las citas de fecha f (ConsultarCitas(f)).

Agenda pregunta a cada Cita si tiene esa fecha (CompararFecha(f)). Si la fecha es igual,pide a la cita que escriba todos sus datos (EscribirDatos()). Como la cita no conoce elnombre de su persona, le pide, segun sea conocida o de empresa, que escriba su nombre(EscribirNombre()).”

Eliminar cita:

“El Usuario pide a Interfaz que elimine una cita de la agenda (EliminarCita()). Interfazsolicita al Usuario que le proporcione la fecha (f) y hora de inicio (hi) de la cita. Segui-damente, Interfaz pide a Agenda que elimine esa cita de la agenda (EliminarCita(f, hi)).



Agenda pregunta a cada Cita si tiene esa fecha y hora de inicio (CompararFechaHora(f,hi)). Si la encuentra la destruye (<<destroy>>Cita).”

Salida del sistema:

“El Usuario dice a Interfaz que quiere salir de la aplicacion (Salir()). Entonces, In-terfaz da la orden a la Agenda para que se destruya (<<destroy>> Agenda). Paraello, Agenda destruye todas las citas (<<destroy>>Cita), seguidamente destruye to-das las personas conocidas (<<destroy>>PConocida) y todas las personas de empresa(<<destroy>>PEmpresa)).”

3.5.6. Disenar las clases

En esta actividad se disena cada una de las clases, siguiendo los 6 pasos siguientes:

Identificar operaciones, Identificar atributos, Identificar asociaciones y agregaciones, Identifi-car generalizaciones, Describir metodos, y Describir estados de las clases.

a) Identificar operaciones

Objetivo: consiste en identificar las operaciones de cada clase.

Criterios:



Se identifican los mensajes a los que debe responder la clase en cada diagrama desecuencia en el que aparece.Para ((destroy)): Se pone como operacion ∼<nombre clase>. Esta operacion sedenomina (Destructor).Se define la visibilidad de cada operacion (normalmente sera publica).Se declaran las operaciones usando la sintaxis de UML o la sintaxis del lenguaje deprogramacion de implementacion.

Ejemplo:

Las operaciones de la clase PConocida, obtenidas de los diagramas de secuencia,son:<<create>>PConocida(n,t,e),<<destroy>>∼PConocida(), CompararNombre(n),EscribirDatos() y EscribirNombre(). Y su visibilidad es publica.Las operaciones de la clase Cita, obtenidas de los diagramas de secuencia, son:<<create>>Cita(p, f, hi hf, l) para p=PConocida, <<create>> Cita(p, f, hi, hf, l)para p=PEmpresa, <<destroy>>∼Cita(), IgualNombrePersona(n), CompararFe-chaHora(f, h), CompararFecha(f), y EscribirDatos(). Y su visibilidad es publica.

Graficamente, en UML, se representarıan ası:

b) Identificar atributos

Objetivo: consiste en identificar los atributos de cada clase. Criterios:

Los atributos definen el estado de los objetos y deben ser los requeridos por la clasepara realizar sus operaciones.Los tipos de los atributos se restringen a los disponibles en el lenguaje de progra-macion de implementacion.No se deben definir atributos correspondientes a las relaciones.Generalmente su visibilidad debe ser privada (-). Pueden tener visibilidad protegida(#) si existe una jerarquıa de herencia.

Ejemplo:

Los atributos de las clases de la agenda personal son los que se indican a continuacion:



c) Identificar asociaciones y agregaciones

Objetivo: consiste en identificar las relaciones obtenidas de los diagramas de secuenciay definir cuales son asociaciones, agregaciones y dependencias.

Criterios:

Se parte de las asociaciones existentes en el diagrama de clases inicial.

Se estudian los diagramas de secuencia y se ve que relaciones son realmente nece-sarias: para cada mensaje del diagrama de secuencia debe existir una relacion queuna la clase origen con la clase destino.

Se identifica cuales son asociaciones y cuales dependencias.

Se identifican aquellas asociaciones que son agregaciones (relaciones todo – parte,en las cuales la participacion en la relacion forma parte de la esencia del “todo”).

Se define si las agregaciones son fuertes o debiles.

Se definen las cardinalidades.

Ejemplo:

• En el caso de la agenda personal, se ve que la clase Agenda es un agregado fuerte delas clases PConocida, PEmpresa y Cita. Y Cita es una asociacion con PConocida yPEmpresa (unidas por un OR, dado que la cita tiene que ser con una u otra persona).

• Cardinalidades: La Agenda puede tener 0 o varias personas conocidas, de empre-sa y citas. Y estas pertenecen a una unica Agenda. Una Cita es con una personaconocida o de empresa. Y una persona puede tener 0 o varias citas.

El Diagrama de Clases de la agenda personal con agregaciones y cardinalidades esel siguiente:

El Diagrama de Clases Completo antes de la herencia es:



d) Identificar generalizaciones

Objetivo: consiste en identificar generalizaciones (jerarquıas de herencia) entre clases dediseno.

Criterios:

Si hay clases con atributos y operaciones comunes se estudiara la creacion de unaclase mas general que sea superclase de las otras.

Al introducir clases generales hay que reestructurar atributos, operaciones y relacio-nes entre clases.

Una clase abstracta no tiene objetos directos. Por ejemplo, la clase Persona de la quederivan Persona Conocida y Persona de Empresa, no tiene instancias de esa clase.

• Igualmente los metodos abstractos que tienen las clases abstractas no tienenimplementacion (en algunos lenguajes de programacion son llamados metodosvirtuales).

Partiendo del Diagrama de Clases completo anterior, realizamos las siguientes acciones:

Se define la clase Persona (clase abstracta), con atributos y operaciones comunes aPConocida y PEmpresa:

• Son atributos comunes: el nombre de la persona(n), y el telefono(t).• Son operaciones comunes: CompararNombre(n) y EscribirNombre(). Como

EscribirDatos() es una operacion que existe en PConocida y PEmpresa, perocon diferente implementacion, es por lo que debe figurar en la clase Personacomo metodo abstracto.• La clase Persona tambien debe incorporar su constructor <<create>>Persona(n,t),

y su destructor <<destroy>>∼Persona().

La clase PConocida, queda reducida a:

• Atributos: el e-mail (e)• Operaciones: el constructor <<create>>PConocida(n,t,e), el destructor<<destroy>>∼PConocida(), y EscribirDatos().

La clase PEmpresa, queda reducida a:

• Atributos: al nombre de la empresa (ne).



• Operaciones: el constructor <<create>>PEmpresa(n,t,ne), el destructor<<destroy>>∼PEmpresa(), y EscribirDatos().◦ La relacion de agregacion de Agenda es ahora con la clase Persona, ya que

PConocida y PEmpresa son subclases de Persona. Y por la misma razon, larelacion de agregacion asociacion de Cita es con la clase Persona.

Como resultado se tienen los Diagramas de Clases que se indican a continuacion:

Al incorporar la clase Persona habra que disenar los Diagramas de Secuencia en que par-ticipe esta clase para verificar que la generalizacion realizada ha sido correcta.

A tıtulo de ejemplo se describen los correspondientes a AgregarPConocida() y Eliminar-Persona().

AgregarPConocida

El Usuario pide a Interfaz que agregue una persona conocida, e Interfaz se lo pide aAgenda. Entonces Agenda pregunta a cada Persona si tiene una persona con ese nombre(CompararNombre(n)), sino existe Agenda la crea (<<create>>PConocida(n, t, e)).



Eliminar Persona

El Usuario pide a Interfaz que elimine una persona de nombre n, e Interfaz se lopide a Agenda. Entonces Agenda pregunta a cada Persona si tiene el con nombre n(CompararNombre(n)). Si existe esa persona Agenda pregunta a cada Cita si es conesa persona (IgualNombrePersona(n)), si existen citas que cumplen esta condicion, en-tonces Agenda las destruye (<<destroy>>Cita). Finalmente se destruye a la persona(<<destroy>>Persona).

e) Describir los metodos

Objetivo: consiste en describir como se realizan las operaciones.

Notacion: en la descripcion se utiliza un lenguaje natural, o pseudocodigo, o diagramasarborescentes, o diagramas de ChapinChapin (estos dos tipos de diagramas se explicaranen la metodologıa estructurada).

Nota: Cuando los programas son pequenos (como en este caso) los metodos se describendirectamente durante la Implementacion, utilizando un lenguaje de programacion.

f) Describir estados



Objetivo: consiste en describir los estados por los que puede pasar un objeto de una clase.

Notacion: se utilizan los Diagrama de Transicion de Estados(DTE).

Criterios:

Estos DTE se realizan cuando los objetos de una clase tienen estados que controlansu comportamiento: como respuesta a un mensaje pueden comportarse de unamanera u otra en funcion de su estado. Es decir, que el control de la ejecucion delmismo mensaje depende del estado.

Estos DTE son utiles para derivar nuevos atributos (“de estado”) e incluso operacio-nes privadas (“transiciones”) que no se detectan con los diagramas de secuencia.

Tambien se utilizan para verificar que no faltan operaciones por identificar en esaclase y que los metodos descritos son correctos.

En la agenda personal no hay clases de ese tipo.

Ejemplo: Se tiene un interruptor que permite apagar y encender una bombilla.Al hacer el Diagrama de Secuencia se obtienen los metodos PulsarOn() que produce elencendido de la bombilla, y PulsarOff() que produce el apagado de la bombilla. Pero alhacer el diagrama de transicion de estados del Interruptor aparece un metodo privadoAveriado() que representa la respuesta del interruptor en caso de averıa. Este metodo sedescubre al describir los estados del Interruptor.

3.5.7. Iteraciones (refinado de diseno)

En este instante se tiene un Diagrama de Clases en el ambito del dominio; es decir, contodas las clases identificadas en el enunciado del problema. Ahora hay que obtener un Diagra-ma de Clases en el ambito del sistema (del computador); es decir, con todas las clases que



sean necesarias para que se tenga una buena implementacion en el computador. A tal fin, se vanrealizando varias iteraciones, refinando de forma incremental el diseno, hasta que se define elsistema final.Para ello, se repiten las actividades “disenar los casos de uso” y “disenar las clases” hasta quese considera que el diseno presenta una buena implementacion.

El Diagrama de Clases de la agenda personal que hemos obtenido hasta ahora es el siguiente:

Sobre este Diagrama de Clases se puede realizar el siguiente refinamiento: incorporar dos clasesque gestionen las colecciones de datos. Una para gestionar las personas (ListaPersonas) y otrapara gestionar las citas (ListaCitas). Como resultado se obtiene el siguiente Diagrama de Clasesrefinado:

Con las nuevas clases hay que refinar el diseno de casos de uso mediante los diagramas desecuencia.

Iniciar:

“Interfaz crea Agenda y esta crea ListaPersonas y ListaCitas.”



Agregar persona conocida:

“Agenda pide a ListaPersonas que agregue la persona conocida, y es ListaPersonas la querealiza todas las acciones que realizaba antes Agenda.”

Agregar persona empresa:

“Agenda pide a ListaPersonas que agregue la persona de empresa, y es ListaPersonas la querealiza todas las acciones que realizaba antes Agenda.”

Consultar persona:

“Agenda pide a ListaPersonas que proporcione datos de una persona, y es ListaPersonaspreguntando a Persona la que realiza todas las acciones para la consulta.”

Eliminar persona:

“Agenda pide a ListaCitas que elimine las citas de esa persona, y posteriormente pide a Lista-Personas que elimine a esa persona.”



Agregar cita:

“Agenda pide a ListaPersonas que busque a la persona citada, para lo cual pregunta a Personasi existe esa persona. Si la persona citada existe, Agenda pide a ListaCitas que incorpore esanueva cita en el caso de que la cita no exista.”

Consultar citas:

“Agenda pide a ListaCitas que le proporcione los datos de esa cita, para lo cual ListaCitaspregunta a Cita si existe esa cita, y en caso afirmativo que proporcione todos sus datos.”



Eliminar cita:

“Agenda pide a ListaCitas que elimine esa cita, para lo cual ListaCitas pregunta a Cita siexiste una cita con esa fecha y hora de inicio. En caso afirmativo, ListaCitas la elimina.”

Salir:

“Interfaz destruye la Agenda, para lo cual Agenda destruye ListaCitas, que a su vez destruyetodas la citas de la lista. Seguidamente, Agenda destruye ListaPersonas, para lo cual Lista-Personas destruye a todas las personas de la lista. Se destruyen primero las citas y luego laspersonas, porque si se hace al reves todos los enlaces de las personas a sus citas quedarıancolgando.”

El Diagrama Final de Clases con listas se presenta a continuacion:Interesa notar que de los diagramas de secuencia se obtienen relaciones de uso (de instanciacion)<<create>> entre ListaPersonas y los tipos PConocida y PEmpresa.



3.5.8. Ejercicios

1. ¿Como son el Modelo de analisis y el Modelo de diseno?El modelo de analisis es un modelo conceptual de objetos. Y el Modelo de diseno es masformal, es un modelo fısico del sistema a implementar.

2. ¿Que actividades implica el Diseno?Disenar la arquitectura, los casos de uso y las clases.

3. ¿Que se obtiene como resultado al disenar la arquitectura?El modelo de despliegue que muestra nodos de proceso, actores y relaciones entre ellos.

4. ¿Que pasos hay que realizar para disenar los casos de uso?Identificar las clases de diseno, y describir las interacciones entre los objetos de diseno.

5. ¿Que tipo de clases de analisis existen?De interfaz, de control y de entidad.

6. ¿Que herramienta se utiliza para describir las interacciones entre objetos?El Diagrama de Secuencia.



7. ¿Que pasos hay que realizar para disenar las clases?Identificar operaciones, atributos, asociaciones y agregaciones, generalizaciones, des-cribir los metodos, describir los estados, y refinar este diseno.

8. ¿Como se identifican las operaciones de una clase?A partir de los mensajes que recibe esa clase en los Diagramas de Secuencia.

9. ¿Que tipos de atributos son las relaciones?Las relaciones no son atributos.

10. ¿Como se identifican las relaciones de dependencia, asociacion y agregacion?A partir de los Diagramas de Secuencia viendo que objetos estan relacionados en el envıode mensajes.

11. ¿Como se identifican las generalizaciones?Viendo que clases tienen atributos y operaciones comunes.

12. ¿Con que se describen los metodos?Con el lenguaje natural, pseudocodigo, diagramas arborescentes o de Chapin.

13. ¿Que aporta describir el estado de los objetos?Nuevos atributos, operaciones privadas, y verificar que no faltan operaciones por identi-ficar.

14. ¿En que consiste refinar el diseno?En obtener un Diagrama de Clases en el ambito del sistema. Es decir, con todas las clasesque son necesarias para obtener una buena implementacion en el computador.

3.5.9. Conclusiones

La disciplina de Analisis y Diseno consiste en obtener los modelos de analisis y de diseno.En programas pequenos solo se realiza el modelo de diseno.

Esta disciplina tiene las siguientes actividades: Disenar la arquitectura, disenar los casosde uso, y disenar las clases.

El diseno de la arquitectura tiene como objetivo identificar los nodos de proceso y suconfiguracion en red. Obtiene cono resultado el Modelo de Despliegue.

El diseno de los casos de uso implica identificar las clases de diseno (interfaz, control,e identidad), y describir las interacciones entre los objetos mediante los Diagramas deSecuencia de cada caso de uso.

Disenar las clases comporta: identificar las operaciones de cada clase utilizando los Dia-gramas de Secuencia, identificar los atributos de cada clase, identificar las relaciones deasociacion y agregacion mediante los Diagramas de Secuencia, identificar generalizacio-nes viendo si hay atributos y operaciones comunes a varias clases, describir los metodos,describir los estados de los objetos para obtener nuevos atributos y operaciones privadas,y refinar el diseno obtenido.



Durante el diseno de las clases se obtienen varios diagramas de clases: El Diagrama deClases antes de la herencia (con asociaciones y agregaciones), el Diagrama de Clasesen el ambito del dominio, y finalmente el Diagrama de Clases Final al refinar el disenoanterior.

3.6. Implementacion3.6.1. Introduccion

Modelar la estructura del codigo fuente mediante un diagrama de componentes, asignan-do cada componente al nodo de proceso que corresponda.

Generar el esqueleto del programa partiendo del diseno, mediante la declaracion de lasclases y el desarrollo del programa principal en el lenguaje de programacion elegido.

Codificar cada operacion de cada clase, partiendo de los diagramas de secuencia del di-seno y de la especificacion de cada operacion.

Comprender como se aplican las pruebas de unidad en un programa orientado a objetos.

Conocer las tecnicas para decidir una estrategia adecuada para ir integrando componentes(clases) con el resto del programa ya terminado.

Conocer la utilizacion de casos de prueba para definir las pruebas y para realizarlas.

3.6.2. Objetivos

Implementar las clases dentro de componentes (ficheros).

Asignar componentes ejecutables a nodos.

Probar los componentes individualmente.

Integrarlos en el sistema de forma incremental.

3.6.3. Implementar la arquitectura

Objetivo: disenar el Modelo de Implementacion.

a) Identificar componentes

Objetivo: consiste en identificar los componentes (ficheros) que forman el programa ysus relaciones (dependencias).

Criterios:

Normalmente se identifica un componente para cada clase.

Se pueden agrupar clases de tipos parecidos.

En C++: un par de ficheros .h, .cpp se representara como un unico componente.



Resultado: Diagrama de Componentes.

Notacion: La notacion utilizada para disenar el Diagrama de Componentes es la siguiente(ver graficos adjuntos):

Programa principal: Un rectangulo con estereotipo <<artifact>> que incorpora elnombre el programa y un icono de documento vacıo.

Componente: Un rectangulo con estereotipo <<component>> que incorpora elnombre del componente y un icono de componente (un rectangulo con dos rectangu-los mas pequenos en el lado izquierdo).

Relacion de uso: Una flecha de trazos que indica que el componente 1 usa al com-ponente 2.

Nota informativa: Proporciona informacion sobre un componente o un relacion deuso.

Agenda: diagrama de componentes.

b) Asignar componentes a nodos

Objetivo: consiste en asignar componentes a los nodos de proceso del Diagrama de Des-pliegue obtenido en la fase de diseno.



3.6.4. Implementar las clases

Objetivo: consiste en Generar el codigo fuente de las clases e Implementar las operaciones.

a) Generar el codigo fuente de las clases

Objetivo: consiste en declarar las clases en el lenguaje de programacion y codificar elprograma principal (main).Criterios:

Se parte de la descripcion de cada clase obtenida en la fase de diseno.

Se declaran las operaciones y los atributos de cada clase.

Se declaran las relaciones de asociacion y agregacion que dependeran del lenguajede programacion (en C++ seran punteros y en Java referencias)-

En este punto se implementa el programa principal.

Ejemplo: Vamos a declarar las clases CAgenda, CPersona, CPConocida y CCita enC++ a partir del Diagrama de Clases Final (Al declarar la clase CCita aparecen las clasesauxiliares CFecha, CHora).

Para CAgenda se parte del diagrama parcial siguiente:



Para las clases CPersona y CPConocida se parte del diagrama parcial siguiente:



Para la clase CCita se parte del diagrama parcial siguiente:



El codigo en lenguaje C++ del programa principal (main) de la agenda personal es elsiguiente:

// Tipo enumerado para representar los codigos de operacionenum TOp {OpAgregarPersonaConocida=1, OpAgregarPersonaEmpresa,

OpConsultarPersona, OpEliminarPersona, OpAgregarCita,OpConsultarCita, OpEliminarCita, OpSalir};

// Programa principalvoid main(void) {

CAgenda agenda;TOp tp;int cod;

char nombre[50]; long telefono; char email[50]; char nemp[50];...

// Bucle mientras el usuario no desee salirdo{

// Mostrar menu de opciones y leer opcion del usuariocout<<endl<<"AGENDA PERSONAL"<<endl;cout<<"---------------"<<endl;cout<<"Indique la operacion que desea realizar:";cout<<endl<<endl;cout<<" 1 agregar persona conocida"<<endl;cout<<" 2 agregar persona empresa"<<endl;cout<<" 3 consultar los datos de una persona"<<endl;cout<<" 4 eliminar de la agenda una persona"<<endl;cout<<" 5 agregar a la agenda una cita"<<endl;



cout<<" 6 consultar en la agenda una cita"<<endl;cout<<" 7 eliminar de la agenda una cita"<<endl;cout<<" 8 Salir del programa"<<endl<<endl;cin >> cod;tp = TOp(cod);while (cin.get()!=’\n’);cout << endl;// Llamar al metodo correspondiente de la agendaswitch (tp){

case OpAgregarPersonaConocida:// Leer todos los datos de una persona

cout<< "Nombre completo: "; cin.getline(nombre,50);cout << "N\’umero de telefono: ";

cin >> telefono;while (cin.get()!=?\n?);

cout << "Email: "; cin.getline(email,50);// Hacer el trabajo

agenda.AgregarPersonaConocida(nombre, telefono, email);break;

case OpAgregarPersonaEmpresa:// Leer datos persona empresacout << ...// Hacer el trabajoagenda.AgregarPersonaEmpresa(nombre, telefono,

nemp);break;

case OpConsultarPersona:// Leer nombre de persona

cout << "Nombre completo: "; cin.getline(nombre,50);// Hacer el trabajoagenda.ConsultarPersona(nombre);break;

case OpEliminarPersona:// Leer nombre de persona

cout << "Nombre completo: "; cin.getline(nombre,50);// Hacer el trabajoagenda.EliminarPersona(nombre);break;

case OpAgregarCita:// Leer datos de nueva citacout << ...// Hacer el trabajoagenda.AgregarCita(fecha, hi, hf, nombre,

lugar);



break;case OpConsultarCita:

// Leer fechacout << ...// Hacer el trabajoagenda.ConsultarCitas(fecha);break;

case OpEliminarCita:// Leer fecha y hora de iniciocout << ...// Hacer el trabajoagenda.EliminarCita(fecha, hi);break;

case OpSalir:// Despedirsecout << "Adios" << endl;break;

default:// No es una operacion valida. No hacer nadacout << "Codigo de operacion no valido: ";cout << int(tp) << endl;

}// Pausa despues de cada operacion (excepto al salirif (tp != OpSalir){

cout << "ENTER para continuar ...";while (cin.get()!=?\n?);

}}while (tp!=OpSalir);

}

b) Implementar las operaciones

Objetivo: consiste en implementar como metodos las operaciones de las clases.Criterios:

Se parte de la descripcion de los metodos realizada durante el diseno de las clases(si no se han descrito en aquel momento se describen ahora).

Conviene usar los Diagramas de Secuencia en que participa esa operacion

Ejemplo:Vamos a implementar la operacion de agregar persona conocida de la agenda personal.Para ello se utilizara el Diagrama de Secuencia siguiente:



3.6.5. Realizar pruebas de unidad

Objetivo: consiste en probar de forma aislada cada uno de los componentes (ficheros).Posibilidades: las pruebas pueden ser de especificacion (de caja negra) y/o de estructura (decaja blanca).

Las pruebas de especificacion (caja negra):

• Verifican el comportamiento observable externamente.• Se realizan dando unas determinadas entradas al componente y comprobando las

salidas obtenidas.• No tienen en cuenta como se implementa dicho comportamiento en el componente.• Cuando el numero de combinaciones de entradas y salidas es grande, se dividen en

clases de equivalencia y se utilizan tecnicas estadısticas de muestreo.



Las pruebas de estructura (caja blanca):

• Verifican la implementacion interna de la unidad.

• Para cada componente se estudia su implementacion interna y se trata de verificarsu correcto comportamiento algorıtmico.

• Se comprobaran los caminos comunes, los crıticos, los menos conocidos y otrosasociados con riesgos altos.

Ejemplo:

En el caso de la agenda personal, para probar el componente “Cita” se usara un driver quesimule las llamadas a los metodos de la clase CCita y un stub que simule el comportamiento delcomponente “Persona”).

Nota:Un driver es un modulo ficticio que simula el comportamiento de un componente real que llamaa otros modulos.Un stub es igualmente un modulo ficticio que simula el comportamiento de un componente realal que se le llama.La existencia de un driver o un stub es debida a que todavıa no se ha codificado ese componentepor lo que hay que simular su funcionalidad.

El Driver realizara las siguientes acciones:

Creara una Persona p, una Fecha f, una Hora de inicio hi, una Hora de fin hf, y una Citac (ej. CCita c(p,f,hi,hf, “lugar”)).

Realizara las siguientes llamadas: c.CompararFechaHora(f,hi); c.CompararFecha (f);c.EscribirDatos(); c.IgualNombrePersona(“un nombre”).

El Stub simulara a la clase CPersona descrita anteriormente.

3.6.6. Integrar el sistema

Objetivos: consiste en integrar los componentes implementados individualmente en el sis-tema. Ello comporta:

Crear un plan de integracion de componentes.

Integrar cada componente antes de pruebas de integracion.

Criterios:

La integracion ha de ser incremental, anadiendo componentes poco a poco.

Se parte del programa principal, con el fin de tener prototipos ejecutables.

Sera necesario incorporar algunos stubs para poder realizar las pruebas.

Interesa implementar los casos de uso.



Ejemplo:

El plan de integracion de la agenda personal partiendo de Diagrama de Componentes disenadoserıa:

3.7. Pruebas3.7.1. Introduccion

La disciplina de Pruebas consiste en realizar un conjunto de pruebas sobre la estructura delsistema con los modulos implementados para comprobar que el sistema funciona satisfactoria-mente, de modo que el sistema informatico construido sea operativo y aceptado por el cliente.Las pruebas del software son un elemento crıtico para la garantıa de calidad del mismo y repre-senta una revision final de las especificaciones, el diseno y la codificacion.

3.7.2. Objetivos

Objetivos: Esta disciplina tiene por objeto realizar pruebas sobre la estructura del sistemaque se ha formado con los modulos implementados. Existen dos tipos de pruebas: integracion ysistema.

Las actividades que comportan las pruebas son tres:

Planificar y disenar las pruebas.

Realizar las pruebas de integracion.

Realizar las pruebas del sistema.

3.7.3. Planificar y disenar las pruebas

Objetivo: consiste en planificar y disenar los casos de prueba y el orden en el que se llevana cabo.

a) Disenar pruebas de integracion

Objetivo: se trata de verificar que los componentes interaccionan entre sı de un modoapropiado despues de haber sido integrados en el sistema.Resultado: Un conjunto de Casos de prueba de integracion.

Un Caso de Prueba de Integracion incorpora la siguiente informacion:



Caso de uso que se prueba.

Componentes que se integran.

Componentes simulados (Stubs).

Pasos que deben seguirse:

• Acciones del usuario.• Resultados del sistema.• Salidas temporales (de los stubs).

Ejemplo:

Un Caso de Prueba de Integracion para el caso de uso “Consultar Persona” de la agendapersonal serıa:PR. INT. 07. Caso: “Consultar persona”Componentes: Agenda, ListaPersonasStubs: PersonaPasos:

1. El sistema inserta 5 personas conocidas (“p1” a “p5”).

Para todas: telefono=0 y email=“a”.Cada Persona creada muestra su nombre.

2. El sistema muestra el menu principal.

3. El usuario selecciona 3 (Consultar persona).

4. El sistema solicita el nombre completo.

5. El usuario introduce el nombre “p3”.

6. El sistema localiza la persona. Comportamiento stub:

Cada “CompararPersona” un mensaje.La 3a persona debe contestar que el nombre es igual.

...

b) Disenar pruebas del sistema

Objetivo: se trata de probar que el sistema funciona globalmente de forma correcta.

Resultado: Un conjunto de Casos de prueba del sistema.

Un Caso de Prueba del sistema incorpora la siguiente informacion:

Casos de usos probados (pueden ser varios).

Pasos que deben seguirse:

• Acciones del usuario.• Resultados del sistema.



3.7.4. Realizar las pruebas de integracion

Los pasos a realizar son:

Ejecutar las pruebas de integracion.

Comparar los resultados con lo esperado y ver las diferencias.

Analizar los componentes y las pruebas disenadas que presentaron esas discrepanciaspara un posible rediseno del componente o cambios en la prueba.

3.7.5. Realizar las pruebas del sistema

Criterios:

Las pruebas del sistema pueden empezar cuando las pruebas de integracion indican queel sistema satisface los requisitos de calidad (ej. el 90 % de las pruebas de integracion conexito).

Las pruebas del sistema se llevan a cabo de forma similar que las pruebas de integracion.

Los disenadores de las pruebas evaluan los resultados de la prueba, fundamentalmente apartir de dos metricas:

• Completitud de la prueba: porcentaje de casos de prueba que han sido ejecutadoscorrectamente y el porcentaje de codigo que ha sido probado.

• Fiabilidad: analisis de la tendencia en los errores detectados y de los resultadosesperados. Lo usual es que el numero de errores se incremente rapidamente al iniciode las pruebas, se mantenga estable posteriormente durante un tiempo y finalmenteempiece a decrecer.

Posibles decisiones consecuencia del resultado de las pruebas:

• Sugerir realizar pruebas adicionales.

• Relajar el criterio de pruebas si los objetivos de calidad se pusieron muy altos.

• Revisar la parte del sistema que no cumple los requisitos de calidad.

3.7.6. Ejercicios

1. ¿Que actividades comporta la Implantacion del Software OO? Implementar la Arquitec-tura, Implementar las Clases, Realizar Pruebas de Unidad, e Integrar el Sistema.

2. ¿Cual es el objetivo de implementar la arquitectura y que pasos comporta? El objetivoconsiste en disenar el Modelo de Implementacion, y tiene los siguientes pasos: Identificarcomponentes, y Asignar componentes a nodos.

3. ¿Cual es el resultado de la identificacion de componentes? El Diagrama de Componentes.

4. ¿Un componente equivale a una clase de diseno? No, un componente puede contenervarias clases.



5. ¿Que pasos comporta Implementar las clases? Generar el codigo fuente de las clases, eImplementar las operaciones.

6. ¿En que consiste generar el codigo fuente de las clases? En declarar las clases (sus atri-butos, operaciones, y las relaciones entre clases) en un lenguaje de programacion y encodificar el programa principal.

7. ¿Cuando se realizan las pruebas de unidad de que tipo pueden ser? Pruebas de especifi-cacion (caja negra) y Pruebas de estructura (caja blanca).

8. ¿Para probar un componente por que se utilizan stubs y drivers? Los drivers se utili-zan para simular las llamadas que hay que hacer a los metodos del componente que seesta probando. Y los stubs se utilizan para simular las llamadas que los metodos delcomponente hacen a otros componentes.

9. ¿Como se realiza la integracion del sistema? De un modo incremental, anadiendo com-ponentes poco a poco, partiendo del programa principal.

10. ¿Que actividades comportan las Pruebas? Planificar y disenar las pruebas, Realizar laspruebas de integracion, y Realizar las pruebas del sistema.

11. ¿Cual es resultado del diseno de las pruebas? Un conjunto de Casos de Prueba.

12. ¿Que posibles decisiones se pueden tomar como resultado de las pruebas del sistema?Sugerir realizar pruebas adicionales, relajar el criterio de pruebas, o revisar la parte delsistema que no cumple los requisitos de calidad.

3.7.7. Conclusiones

La Implementacion del Software OO es una disciplina que comprende las siguientesactividades: Implementar la Arquitectura, Implementar las Clases, Realizar Pruebas deUnidad, e Integrar el Sistema.

Implementar la arquitectura consiste en disenar el Modelo de Implementacion, y preci-sa para ello: Identificar los componentes (dando como resultado el Diagrama de Compo-nentes), y asignar los componentes a los nodos definidos en el Diagrama de Despliegue.

Implementar las clases consiste en generar el codigo fuente de las clases, e Implementarlas operaciones.

Generar el codigo fuente de las clases consiste en declarar las clases (sus atributos,operaciones y las relaciones entre clases) en un lenguaje de programacion, y codificar elprograma principal. Como herramienta se utiliza el Diagrama de Clases Final.

Implementar las operaciones consiste en codificar los metodos de las clases. Para ello,se utiliza la descripcion de los metodos realizada durante el diseno (si se hizo), y losDiagramas de Secuencia que participan en esa operacion.



Las Pruebas de Unidad consisten en probar aisladamente cada componente. Estas prue-bas pueden ser de especificacion o de caja negra (verifican el comportamiento externo delcomponente) y de estructura o de caja blanca (verifican la implementacion interna de launidad).

Para probar un componente hay que disenar stubs y drivers. Los drivers sirven parasimular las llamadas que hay que hacer a los metodos del componente que se esta proban-do. Y los stubs sirven para simular las llamadas que los metodos del componente hacen aotros componentes.

Integrar el sistema consiste en integrar incrementalmente (uno a uno) los componentesen el sistema, a partir del programa principal.


Documents

Modelos de Desarrollo de Programas - FIWIKIMDP_Objetos.pdf · Modelos de Desarrollo de Programas 1. Ciclo de vida del software 1.1. Introduccion´ Una computadora consta de dos partes