Modelos de Desarrollo de Programas

Transcripción

1 Modelos de Desarrollo Orientados a Objetos Adriana Castro Bonenfant Curso 2009/2010

2 Índice 1. Ciclo de vida del software Introducción Objetivos Concepto de Software Ingeniería del software Ciclo de vida clásico Introducción Ingeniería del Sistema o Análisis del Sistema Análisis de los Requisitos del Software Diseño de Software Codificación Pruebas Mantenimiento Complejidad del desarrollo del Software Modelos de Desarrollo de Programas Ejercicios Conclusiones Fundamentos de la orientación a objetos Introducción Objetivos Estructura de un problema orientado a objetos Objetos, clases y mensajes Objeto Clase Mensaje Relaciones entre clases Asociación Agregación Generalización Dependencia (uso) Ejercicios Conclusiones Metodología básica de desarrollo OO Introducción Objetivos Introducción al Proceso Unificado (PU) Captura y Requisitos Introducción Encontrar actores y casos de uso Detallar los casos de uso Definir un prototipo de interfaz de usuario Ejercicios Adriana Castro 1 FI - UPM

3 Conclusiones Anlálisis y Diseño Introducción Objetivos Diseñar la arquitectura Diseñar los casos de uso Diagramas de Secuencia de la Agenda Personal Diseñar las clases Iteraciones (refinado de diseño) Ejercicios Conclusiones Implementación Introducción Objetivos Implementar la arquitectura Implementar las clases Realizar pruebas de unidad Integrar el sistema Pruebas Introducción Objetivos Planificar y diseñar las pruebas Realizar las pruebas de integración Realizar las pruebas del sistema Ejercicios Conclusiones Adriana Castro 2 FI - UPM

4 1. Ciclo de vida del software 1.1. Introducción Una computadora consta de dos partes fundamentales: el hardware (o quincallería) que comprende todos los componentes informáticos, y el software (la parte blanda) que se compone de todos los programas informáticos existentes en la computadora. El desarrollo de un programa informático es un proceso de ingeniería que requiere, al igual que cualquier otro proceso de ingeniería, el desarrollo de una serie de fases, etapas y tareas, lo que se denomina el Ciclo de Vida del Software. Para que un problema de la vida real se pueda resolver en una computadora hay que utilizar un Modelo de Desarrollo de Programas que transforme el problema en uno o varios programas informáticos. Esto se consigue aplicando paso a paso a ese problema el Ciclo de Vida del Software Objetivos Conocer el concepto de Software y de Ingeniería del Software. Conocer el Ciclo de Vida del Software clásico. Conocer la clasificación del desarrollo de software según su complejidad. Conocer el concepto de Modelo de Desarrollo de Programas. Conocer el concepto de Metodología de Desarrollo de Programas y su relación con los Modelos de Desarrollo Concepto de Software Conjunto de programas informáticos que se desarrollan en el entorno de una computadora Tres tipos: Programas de control: controlan y supervisan la ejecución de todas las tareas y procesos que tienen lugar en la computadora (ej.: el Sistema Operativo). Programas de proceso: sirven para que el usuario desarrolle sus propios programas (ej.: compiladores, intérpretes, montadores, etc.). Programas de aplicación: desarrollados por y para el usuario de la computadora para resolverle problemas específicos. Los dos primeros tipos reciben el nombre de software del sistema. El tercer tipo se denomina software de aplicación. Adriana Castro 3 FI - UPM

5 1.4. Ingeniería del software En los años 60 se produce la Crisis del software: el ingeniero del software se sentía incapaz de desarrollar proyectos de una dimensión acorde con los avances tecnológicos de la época. En 1968 se reúne el Comité Científico de la OTAN, bajo la dirección de F. L. Bauer, y se constata que el desarrollo de software es un proceso de ingeniería (como el de otras disciplinas de ingeniería). Y su fin es la producción 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 que precisa durante su ejecución desarrollar una serie de fases, etapas y tareaspara obtener un programa que funcione correctamente Ciclo de vida clásico Introducción Ciclo de vida: describe qué ocurre desde que se decide hacer un programa hasta que deja de utilizarse. Ciclo de vida clásico o ciclo de vida en cascada. Fue diseñado por Royce en Tiene tres fases: una de Planificación ( qué se debe hacer?), otra de Desarrollo ( cómo se debe hacer?) y una tercera de Mantenimiento ( qué cambios hay que hacer?) Y seis etapas (Ingeniería del Sistema, Análisis de los Requisitos, Diseño, Codificación, Pruebas y Mantenimiento) tradicionales del ciclo de vida Ingeniería del Sistema o Análisis del Sistema Objetivo: realizar un análisis global del sistema (el software es por lo general una parte del sistema) y ver si es viable técnica y económicamente. Existen tareas manuales que se deben tratar dentro del sistema. Productos: Especificación del Sistema, que consta de los siguientes documentos: 1. Objetivos generales del sistema: definen los fines del sistema, su funcionamiento y rendimiento requerido, las entradas y salidas, y las restricciones impuestas. 2. Especificación de Requisitos de cada elemento del sistema: definen los requisitos del software, del hardware, de las bases de datos, del personal y de los otros elementos que conforman el sistema. 3. Análisis Técnico: evalúa la viabilidad técnica del sistema propuesto y recoge información sobe el rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad de producción. 4. Análisis Económico: es un análisis de coste-beneficio que evalúa los costes estimados para la producción y mantenimiento del sistema y los contrasta con los beneficios previstos. Adriana Castro 4 FI - UPM

6 5. Viabilidad del Sistema: evalúa la viabilidad económica y de mercado, técnica y legal, junto con un análisis del riesgo en desarrollar el sistema. Si el riesgo es grande su viabilidad disminuye. 6. Especificación de la Arquitectura del sistema: consiste en definir un diagrama general de la arquitectura del sistema, un diagrama de los flujos de información que circulan por el sistema, y una descripción de los subsistemas que lo componen. 7. Definición de las pruebas globales del sistema (denominadas pruebas del sistema ). Plan software: establece los requisitos del software (objetivos generales del sistema, requisitos del software, requisitos de las Bases de Datos, arquitectura del sistema) Análisis de los Requisitos del Software Objetivo: es un proceso de descubrimiento, refinamiento, modelado y especificación que lleva a cabo el ingeniero del software para obtener la especificación de requisitos del software. Producto: Especificación de Requisitos de Software (ERS) Consta de los siguientes documentos: 1. Introducción: describe los fines y objetivos del software a desarrollar. 2. Descripción de la Información: describe los flujos y las estructuras de la información, así como el hardware, el software y las interfaces hombre-máquina. 3. Descripción Funcional: describe cada función (proceso) requerida para resolver el problema. 4. Descripción del Comportamiento: describe el comportamiento del software mediante diagramas de estado, con una especificación de eventos y acciones. 5. Criterios de Validación: incorpora las pruebas que deben realizarse al software, los límites de rendimiento y la respuesta esperada para que el cliente acepte el producto (pruebas de validación) Diseño de Software Objetivo: producir con detalle un modelo del problema real que será implementado más adelante. Es la parte central del desarrollo del software, y tiene un Diseño Preliminar y un Diseño Detallado. Diseño preliminar Consiste en establecer las estructuras de datos, desarrollar una estructura funcional y modular del sistema (los módulos se contemplan como cajas negras ) y definir la interfaz de usuario. Producto: Documento de Diseño General Consta de la siguiente información: 1. Diseño de datos: consiste en identificar todas las estructuras de datos y operaciones que pueden realizarse sobre ellas. También se establece un diccionario de datos. Adriana Castro 5 FI - UPM

7 2. Diseño arquitectónico: consiste en desarrollar una estructura modular del software y representar las relaciones de control entre los módulos. 3. Diseño de la interfaz hombre-máquina: consiste en diseñar una interfaz de usuario que proporcione una comunicación bidireccional con el sistema. 4. Pruebas de integración: consiste en diseñar las pruebas que habrá que aplicar a los diferentes subsistemas que componen el sistema software. Diseño detallado Objetivo: definir los detalles algorítmicos de cada módulo (diseño procedimental), refinar las estructuras de datos y la interfaz de usuario. Producto: Documento de Diseño Detallado (Doc. de Diseño Final), que contiene: 1. Diseño detallado de los datos: consiste en revisar el diseño de datos preeliminar al finalizar el diseño procedimental y producir el diseño físico de cada uno de los datos que participan en el sistema. 2. Diseño arquitectónico: es el obtenido durante el diseño preliminar. 3. Diseño detallado de la interfaz hombre-máquina: consiste en revisar el diseño preliminar de la interfaz al finalizar el diseño procedimental y detallar su contenido. 4. Diseño procedimental de cada módulo: consiste especificar para cada módulo: un texto explicativo, una descripción de su interfaz, una descripción del módulo en un lenguaje de diseño, módulos que utiliza, organización de los datos y comentarios. 5. Pruebas para cada módulo: consiste en definir qué pruebas hay que realizar a cada uno de los módulos (pruebas de unidad) Codificación Objetivo: creación de los programas informáticos aplicando algún paradigma y utilizando un lenguaje apropiado de programación. Producto: Código fuente Se debe codificar con un estilo que produzca un código comprensible, bien comentado y documentado, y siguiendo convenciones de la organización. En concreto, se debe tener en cuenta lo siguiente: Debe documentarse con identificadores que sean significativos, incorporando comentarios al principio de cada módulo que indiquen lo que hace el módulo. Así mismo, se incorporarán comentarios descriptivos en el cuerpo del módulo para describir funciones de procesamiento. Los datos se deben declarar en aquellos lugares que proporcionan un acceso rápido a la hora de identificarlos dentro de una sentencia. Las sentencias deben ser simples y fáciles de seguir. Las entradas/salidas deben codificarse cuidadosamente, ya que son origen de múltiples errores difíciles de localizar. Adriana Castro 6 FI - UPM

8 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 ámbito): Pruebas del sistema: comprobar que todo el sistema satisface todas las necesidades del cliente. Pruebas de validación: comprobar que el software desarrollado satisface todos los requisitos de software. Pruebas de integración: comprobar que los subsistemas se han construido correctamente. Prueba de unidad: comprobar que cada módulo funciona correctamente. Tipos (por su diseño): Pruebas de caja negra. Se llevan a cabo sobre la interfaz del software, pretenden demostrar 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 procedimentales. Se comprueban los caminos de los algoritmos del software (bucles, sentencias de bifurcación, etc.). A continuación, se representa gráficamente la relación existente entre las distintas etapas del ciclo 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 figura y recorriendo las diferentes semicircunferencias superiores, desde la más interna a la más externa, en el sentido contrario a las agujas del reloj. Durante la semicircunferencia más interna se produce la etapa de Ingeniería del Sistema, que incorpora el diseño de las pruebas del sistema. Durante la siguiente semicircunferencia se produce la etapa de Análisis de los Requisitos del Software, que incorpora el diseño de las pruebas de validación. Durante la semicircunferencia siguiente se produce la etapa de Diseño, que incorpora el diseño de las pruebas de integración y de unidad. Y por último durante la semicircunferencia más externa se produce la etapa de Codificación. Adriana Castro 7 FI - UPM

9 Proceso de pruebas del sistema: Se inician las pruebas partiendo del centro de la figura y recorriendo las diferentes semicircunferencias inferiores, desde la más externa a la más interna, en el sentido de las agujas del reloj. Durante la semicircunferencia más externa se realizan las pruebas de unidad, que las lleva a cabo el programador. Durante la semicircunferencia anterior se realizan las pruebas de integración, que las lleva a cabo el diseñador. Durante la semicircunferencia anterior se realizan las pruebas de validación, que las lleva a cabo el analista de aplicaciones. Y por último durante la semicircunferencia más interna se realizan las pruebas del sistema, que las lleva a cabo el ingeniero de sistemas. Debe señalarse que, generalmente, se considera como implementación la unión de las dos etapas de codificación y pruebas de unidad (es decir, Implementación = codificación + pruebas). Por lo tanto no puede decirse que la implementación y la codificación sean lo mismo Mantenimiento El software debe ser mantenido, ya que sufrirá cambios debidos a: Corregir los errores encontrados ( mantenimiento correctivo ). A cambios en el entorno externo al que el software debe adaptarse ( mantenimiento adaptativo ). Por ejemplo pasar de Windows a Unix, o bien adaptarse al cambio de moneda de pesetas a euros. El cliente requiere ampliaciones funcionales o mejoras ( mantenimiento perfectivo ). NOTA Como este ciclo de vida se aplica a problemas bien definidos (consistentes, precisos, no ambiguos y determinados), se pasa de una etapa a la siguiente cuando la anterior ha sido básicamente resuelta, existiendo un proceso de reciclaje para verificar que la etapa siguiente cubre las especificaciones de la etapa anterior 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 código): puede ser desarrollado por una persona en pocos meses. Utilizar una metodología en su desarrollo puede ser deayuda. Ej. Programa que realiza las altas en la Nómina. b) El proyecto simple (< l.c.): es ya un proyecto formal. Se necesita la dedicación de 3 ó 4 analistas/programadores y una duración de 6 a 12 meses. Utilizar una metodología en su desarrollo produce un producto más mantenible. Ej. Sistema Retributivo de una empresa. c) El proyecto difícil (< l.c.): suele ocupar a un equipo de 6 a 12 informáticos durante 2 ó 3 años. Utilizar una metodología en su desarrollo es indispensable para tener una esperanza razonable de que se pueda terminar en el tiempo previsto y dentro del presupuesto estimado. Ej. Sistema General de Gestión de Personal de una empresa grande. Adriana Castro 8 FI - UPM

10 d) El proyecto complejo (< l.c.): exige entre 50 y 100 personas durante un período de 3 a 5 años o más. Utilizar una metodología en su desarrollo es esencial para acabar el proyecto. Ej. Gestión Integrada de un centro de proceso de datos ( Personal, Centros, Económica, etc.) e) El proyecto casi imposible (< l.c.): se impone en su desarrollo una metodología orientada a objetos. Durante el desarrollo de estos proyectos se producirán cambios tecnológicos, de personal, de usuarios, etc. difíciles de controlar. f) El proyecto imposible (más de l.c.): como es obvio no procede su planteamiento. Programación en pequeño (o Desarrollo de Programas ): trata el desarrollo de programas triviales, e incluso simples. Se centra en la fase de Desarrollo. Programación en grande (o Ingeniería del Software ): trata el desarrollo de programas simples en adelante. El peso del proceso cae en la Planificación, Mantenimiento y Gestión del proyecto Modelos de Desarrollo de Programas Modelo de desarrollo: es una filosofía de desarrollo para obtener un software de unas determinadas características. Metodología de desarrollo: es un proceso concreto de desarrollo (con sus fases, etapas y actividades) 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 en un conjunto de objetos que interactúan entre sí para resolver el problema. Se presentará la Metodología básica de desarrollo orientado a objetos basada en el proceso unificado de Rational (RUP). 2. Modelo orientado a procedimientos y datos: trata de obtener un programa independizando las estructuras de datos de los procedimientos. Estos actúan sobre los datos para resolver el problema. Se presentará la Metodología orientada al flujo de datos, también llamada metodología estructurada Ejercicios 1. Un programa de control sirve para que el usuario desarrolle sus propios programas? No 2. Un videojuego qué tipo de software es? Programa de aplicación. 3. Qué fases tiene el ciclo de vida clásico? Planificación, Desarrollo y Mantenimiento Adriana Castro 9 FI - UPM

11 4. Para qué sirve el Plan Software? Para establecer los requisitos del software 5. Validar software quiere decir que se está construyendo correctamente el producto? No, quiere decir que se está construyendo el producto correcto 6. En qué etapa del ciclo de vida se diseña la interfaz de usuario? Diseño Preliminar 7. Cuándo se diseñan las pruebas de integración? Diseño Preliminar 8. Cambiar en un programa software todos los literales, comentarios y la interfaz de usuario del español al inglés qué tipo de mantenimiento exige? Adaptativo 9. Para qué 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 de desarrollo o una metodología? Una metodología 1.9. Conclusiones El Software está formado por Programas de Control, de Proceso y de Aplicación. El Desarrollo de Software (o el Desarrollo de Programas) es un proceso de ingeniería que está formado por fases, etapas y tareas. El desarrollo clásico (ciclo de vida clásico) tiene 3 fases: Planificación, Desarrollo y Mantenimiento. Y seis etapas: Ingeniería del Sistema, Análisis de los Requisitos, Diseño, Codificación, Pruebas y Mantenimiento. La Ingeniería del Sistema realiza un análisis global del sistema y ve si es viable. Produce la especificación del sistema, parte de la cual es el Plan software. El Análisis de los Requisitos del Software produce la especificación de los requisitos del software (ERS). El Diseño del Software consta de un Diseño Preliminar que establece las estructuras de datos, funcional y modular del sistema y define la interfaz de usurario. Y un Diseño Detallado que define el diseño procedimental del sistema y refina las estructuras anteriores. Se realizan Pruebas del sistema, de validación, de integración y de unidad. Y estas pueden 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 proyectos: trivial (<1000 l.c), simple (< l.c.), difícil (< l.c.), complejo (< l.c.), casi imposible (< l.c.); e imposible (> l.c.) Adriana Castro 10 FI - UPM

12 El desarrollo de programas (objeto de esta asignatura) se centra en programas pequeños (triviales o simples), mientras que la ingeniería del software aborda proyectos más complejos. Un modelo de desarrollo de programas es una filosofía de desarrollo para obtener un software de unas determinadas características, mientras que una metodología de desarrollo es un proceso concreto de desarrollo que implementa el modelo de desarrollo. Adriana Castro 11 FI - UPM

13 2. Fundamentos de la orientación a objetos 2.1. Introducción En 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 ese problema. Este proceso es bastante similar a la forma en la que se resuelve un problema en la vida real. Por ejemplo, si queremos construir una casa pedimos (enviamos un mensaje) al arquitecto para que nos haga los planos de la casa. El arquitecto pedirá al Colegio de Arquitectos que le apruebe los planos. Posteriormente, pediremos a un constructor que nos la construya. Y éste pedirá al Ayuntamiento que le de la cédula de habitabilidad. Finalmente iremos a vivir en la casa. Por otra parte, estos objetos suelen estar relacionados entre sí, por ejemplo el arquitecto ha de pertenecer al Colegio de Arquitectos para solicitar que le aprueben los planos de la casa. Y el terreno donde se construya la casa ha de estar ubicado en el municipio del ayuntamiento que proporcione la cédula de habitabilidad Objetivos Comprender 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: asociación, agregación, generalización/herencia, y dependencia Estructura de un problema orientado a objetos El modelo orientado a objetos (OO) transforma el problema real en un mundo de objetos en lugar de procedimientos y datos (ej. Loïc, MDP, Juan son objetos) Los objetos interactúan entre sí mandándose mensajes para resolver el problema (ej. son mensajes Calcular Matrícula, Devolver créditos). Cada objeto es una instancia de una clase (una clase representa un conjunto de objetos similares). Una clase implementa un tipo abstracto de datos. (Son ejemplos de clase: Profesor, Asignatura, Alumno). Los objetos (o las clases) están relacionados unos con otros (ej. Juan está matriculado en MDP: relaciona al objeto Juan de la clase Alumno con el objeto MDP de la clase Asignatura) Objetos, clases y mensajes Objeto Un objeto es (según Grady Booch): Adriana Castro 12 FI - UPM

14 Algo tangible o visible (ej. una bicicleta). Algún concepto que puede ser comprendido intelectualmente (ej. un número entero). Algo hacia lo que se dirige el procesamiento o la acción (ej. una pila de datos). Un objeto tiene un estado (atributos y valores), un comportamiento (una actuación ante los mensajes, lo que produce un posible cambio de estado) y una identidad (que permite distinguir a unos objetos de otros, como pueden ser el nombre de una variable que representa al objeto o la dirección en la que se almacena dicho objeto). Para la descripción de los conceptos OO (objetos, clases, mensajes, etc.) se utilizará la Notación UML (siglas de Unified Modelling Language o Lenguaje Unificado de Modelado), en su versión 2.1. El lenguaje UML fue creado por Grady Booch, James Rumbaugh, Ivor Jacobson y otros autores. El lenguaje UML permite usar el lenguaje de implementación (C++, Java,...) para la definición de atributos y operaciones. Notación de Objeto en UML: Presenta varias posibilidades: Un rectángulo con dos partes: En la parte superior, el nombre del objeto y la clase subrayados. En la parte inferior, los atributos del objeto con sus valores. Un rectángulo con el nombre del objeto subrayado (nos referimos a un objeto concreto sin indicar la clase). Un rectángulo con el nombre de la clase subrayado (nos referimos a un objeto genérico de una clase determinada). En este caso se presenta a modo de ejemplo la representación UML del objeto mdp de la clase Asignatura, con los atributos: curso, cuatrimestre, créditos, nombre,..., y sus valores correspondientes. Debe señalarse que la aparición de la parte dedicada a atributos es opcional. Esto quiere decir que en la versión (a) se podría haber eliminado esa parte de la notación y que en las variantes (b) y (c) se podría haber añadido. Adriana Castro 13 FI - UPM

15 Clase Una clase es un marco o plantilla que permite crear objetos de la misma estructura y comportamiento (puede verse como la representación de un conjunto de objetos que comparten una estructura y comportamiento comunes. Ojo: no es una colección, es decir no es un objeto que almacena otros objetos). Las clases son elementos estáticos que corresponden 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 operaciones (que definen el comportamiento de los objetos, es decir, cómo reacciona cualquier objeto de la clase ante cada mensaje). Los atributos y operaciones de una clase son comunes a todas sus instancias. Notación de Clase en UML: Una clase al igual que un objeto presenta varias posibilidades: Un rectángulo con el nombre de la clase. Un rectángulo dividido en dos partes, una con el nombre de la clase y con sus atributos. Un rectángulo 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, el nombre del atributo, el tipo del atributo y, opcionalmente un valor por defecto del atributo. En la parte inferior se ponen las operaciones. Cada operación tiene una visibilidad, el nombre de la operación, sus argumentos entre paréntesis y, finalmente, el tipo de retorno de la operación (si la operación devuelve un resultado). La visibilidad puede ser: + (público), # (protegido), - (privado). Visibilidad pública (+) quiere decir que ese atributo u operación es accesible por todos los objetos de cualquier clase. Visibilidad protegida (#) quiere decir que ese atributo u operación es accesible por los objetos de su clase y de las clases derivadas. Visibilidad privada (-) quiere decir que ese atributo u operación sólo es accesible por los objetos de su clase. Adriana Castro 14 FI - UPM

16 Ejemplo: La clase Alumno tiene los atributos nombre y nummat como privados (que es lo más habitual y recomendable) y los métodos AsignarMateria y CalcularImporteMatrícula como públicos (que es lo usual). Nota: un método es la implementación de una operación para una clase. Ej. la clase Archivo puede tener la operación Imprimir que se puede implementar con distintos métodos: imprimir en ASCII, imprimir una imagen, imprimir un documento. Todos los métodos efectúan la misma operación lógica de impresión, pero diferente acción Mensaje Un mensaje es la comunicación que se envía a un objeto para que realice un servicio. Como respuesta a ese mensaje, el objeto ejecutará una operación que está definida en la clase correspondiente. En otras palabras, son los mensajes los que provocan que los objetos ejecuten los métodos definidos en sus respectivas clases. En general un mensaje consta de tres partes: 1. El identificador del objeto receptor del mensaje (objeto que trabajará ) 2. El nombre de la operación que debe ejecutarse. 3. Los argumentos de la operación (si los tiene). Ejemplo: Vamos a definir al alumno?luis Martínez?, con número de matrícula: , y le vamos a enviar dos mensajes: El m1 le indica que se matricule en la asignatura mdp. El m2 le indica que calcule el importe de la matrícula y lo imprima. El código en C++ sería: Alumno a1( Luis Martinez, ); a1.asignarmartricula(mdp); // m1 cout << a1.calcularimportemartricula(); //m2 Nota: a1 es el objeto receptor del mensaje (identificador). AsignarMartricula y CalcularImporteMatricula son nombres de las operaciones. La sintaxis del envío de mensajes depende del lenguaje de programación. En el ejemplo anterior de C++ se recoge la sintaxis más habitual y que se aplica en más lenguajes (como C++, Java, C#, etc.), pero en otros lenguajes la sintaxis puede ser muy diferente. Adriana Castro 15 FI - UPM

17 2.5. Relaciones entre clases Asociación Es una conexión semántica entre clases: es un grupo de enlaces entre instancias de clases. Ejemplos: Un país tiene una ciudad como capital (las clases son país y ciudad, y la asociación es la capitalidad). Un alumno estudia una o varias asignaturas (las clases son alumno y asignatura, y la asociación es estudia). Notación UML para la Asociación: Se representan como una línea (para relaciones binarias) o como un rombo unido con líneas a las clases participantes (para relaciones n-arias). Cardinalidad: Indica cuántos elementos de una clase se asocian con un elemento de la otra clase. Puede ser: 0..* (cuando se relaciona un elemento de una clase con 0 ó varios de la otra) Esta cardinalidad se puede abreviar como * (cuando se relaciona un elemento de una clase con 0 ó un elemento de la otra) (cuando se relaciona un elemento de una clase con un solo elemento de la otra) Esta cardinalidad se puede abreviar como * (cuando se relaciona un elemento de una clase con 2 ó varios elementos de la otra). Asociaciones Clase (son asociaciones que son clases con sus propios atributos y operaciones) Ej. Una persona está contratada por una o varias empresas en las que interesa consignar la fecha de contratación (Persona y Empresa están asociadas por un Contrato que a su vez es una clase con el atributo fecha). Ejemplos: Adriana Castro 16 FI - UPM

18 En un país sólo 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 ó varias asignaturas (0..*), y una asignatura es estudiada por 0 ó varios alumnos (0..*). Una persona está contratada por 0 ó varias empresas (0..*), y una empresa contrata a 1 ó varias personas (1..*) Agregación Especifica que un objeto es una parte de otro objeto (el agregado). El objeto agregado no puede existir (no tiene sentido) sin que existan los objetos parte (o componentes) correspondientes. Ejemplos: Un cuadro consta de marco, cristal, lámina (cuadro es el agregado, y marco, cristal, y lámina son los componentes). Una ventana de un entorno gráfico de usuario tiene: título, menú principal, panel de contenido (ventana es el agregado, y título, menú y contenido los componentes). Hay dos tipos de agregación: Débil: las partes pueden existir fuera del agregado (ej. En el cuadro: el marco, el cristal y la lámina pueden existir sin que formen un cuadro). Fuerte (composición): las partes sólo existen dentro del agregado (ej. Si la ventana de Windows desaparece no existen ni el título, ni el menú principal, ni el panel de contenido). Dicho de otro modo, no puede existir un título ni un menú ni un panel de contenido si no están asociados a una ventana). Notación UML para la Agregación: La agregación se representa como una asociación, pero con un rombo en el extremo del agregado. Si la agregación es débil se representa con un rombo sin rellenar. Si la agregación es fuerte se representa con un rombo relleno. Ejemplos: Un cuadro está formado por 0 ó 1 marco, 0 ó 1 cristal, y por 0 ó 1 lámina. También indica que el marco, cristal y la lámina pertenecen a 0 ó 1 cuadro. La agregación es débil porque si desaparece el cuadro permanecen los componentes. Adriana Castro 17 FI - UPM

19 Una ventana Windows está formada por 0 ó 1 título, 0 ó 1 menú principal, y por 1 panel de contenido. Es decir, que la ventana Windows puede existir sólo con el panel de contenido. También indica que el título, menú principal y panel de contenido pertenecen a una sola ventana Windows. La agregación es fuerte porque si desaparece la ventana Windows desaparecen los componentes Generalización Esta relación especifica una clase de objetos ( es un ). Ejemplos: Un alumno es una persona. Hay tres tipos de empleados: funcionarios, interinos, laborales. Notación UML para la Generalización: La generalización se representa con una flecha que parte de la subclase (clase más específica) y va dirigida hacia la superclase (clase más general). Ideas sobre generalización: Importante: La generalización no relaciona objetos, relaciona clases. La generalización es una relación entre una clase y una o más versiones especializadas de la misma clase. Las subclases heredan atributos y operaciones de las superclases. Además las subclases pueden definir nuevos atributos y operaciones. Puede haber varios niveles de generalización, lo que define una Jerarquía de herencia. Es en estas jerarquías donde tiene sentido utilizar los atributos y operaciones protegidos, que sólo pueden ser accedidos por objetos que son instancias de subclases de una dada. La generalización no tiene cardinalidad Dependencia (uso) Las relaciones de asociación, agregación y generalización son relaciones estructurales (afectan a la estructura del objeto). Mientras que la relación de Dependencia no es estructural. Se dice que una clase tiene una relación de dependencia con otra clase cuando requiere la existencia de la otra clase para su definición o implementación. Existe una relación de dependencia de uso entre clases cuando una clase A utiliza las operaciones de otra clase B (y por lo tanto A depende del funcionamiento de B). Adriana Castro 18 FI - UPM

20 Notación 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 se denomina estereotipo en UML). Ejemplo: La clase Documento usa a la clase Impresora porque para Imprimir utiliza como argumento un objeto de la clase Impresora. Existen más tipos de relaciones de dependencia considerados en UML. Entre ellos destaca la dependencia de creación (<<crea>>) cuando un objeto crea objetos de otra clase y la dependencia de destrucción (<<destruye>>) cuando un objeto elimina objetos de otra clase Ejercicios 1. Qué 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. Cuáles son los elementos que definen una clase? Los atributos y las operaciones. 4. Qué visibilidad suelen tener los atributos y las operaciones de una clase? Los atributos son privados, y las operaciones son públicas. 5. Cuándo mandamos un mensaje a un objeto, se puede negar el objeto receptor a ejecutar el mensaje? No, si ese mensaje se corresponde con una operación del objeto. 6. Cuáles son las relaciones estructurales que existen en el modelo de objetos? Asociación, Agregación y Herencia. 7. Dados los objetos Persona y Coche, y la relación de asociación Conduce qué cardinalidad existe en dicha relación? Una persona conduce 0..* coches; un coche es conducido por 0..* personas. 8. Qué tipo de agregación y cardinalidad existen en la figura geométrica Casa formada por un triángulo (tejado), un cuadrado grande (el cuerpo de la casa), cuadrados pequeños (las ventanas), y un rectángulo (la puerta)? El tipo de agregación es débil. La cardinalidad de triángulo, cuadrados y rectángulo con Casa es de La cardinalidad de Casa con triángulo, cuadrado grande y rectángulo es de La cardinalidad de Casa con ventana es de 0..*. 9. Qué relación existe entre Medio de Transporte y Coche, Autobús, Tren, Avión? Relación de Generalización, siendo Medio de Transporte la clase padre.. Adriana Castro 19 FI - UPM

21 10. Un Coche hereda los atributos de un Autobús? No. 11. Podemos decir que existe una relación de Dependencia de Uso entre un Conductor y un Coche? No, existe una relación de asociación: Un conductor conduce un coche. 12. Cómo se representan gráficamente las relaciones de Asociación, Agregación, Generalización y Dependencia de Uso? Asociación con una línea para relaciones binarias y un rombo para las n-arias. Agregación como una asociación pero añadiendo en el agregado un rombo sin rellenar para la agregación débil, y relleno para la agregación fuerte. Generalización con una flecha. Y Dependencia de uso con una flecha de trazo que va de la clase dependiente a la independiente Conclusiones Un problema OO transforma el problema real en un mundo de objetos que interaccionan entre sí mandándose mensajes para resolver el problema. Un objeto es una instancia de una clase y tiene un estado (definido por sus atributos y valores), un comportamiento (definido por sus operaciones) y una identidad (que lo distingue de los demás objetos). Una clase define un conjunto de objetos similares (no es una colección de objetos) mediante unos atributos (que definen el estado de cada objeto) y unas operaciones (que definen el comportamiento del objeto). Un mensaje es la comunicación que se envía a un objeto para que realice un servicio. Este servicio lo realiza ejecutando una operación definida en su clase. Una asociación es una relación estructural semántica entre instancias de clases. Se representa por una línea (si es binaria) o por un rombo (si es n-aria). Una agregación es una relación estructural que especifica que un objeto es una parte de otro objeto. La agregación es fuerte si al desaparecer el agregado desaparecen las partes (se representa por un rombo relleno en el agregado). La agregación es débil si al desaparecer el agregado no desaparecen las partes componentes ( se representa por un rombo sin rellenar). Una generalización es una relación estructural que especifica una clase de objeto. Las subclases heredan los atributos y operaciones de las superclases. Se representa con una flecha que va de la subclase a la superclase. La dependencia de uso es una relación no estructural entre clases y se produce cuando una clase utiliza las operaciones de otra clase. Se representa con una flecha de trazo. Adriana Castro 20 FI - UPM

22 3. Metodología básica de desarrollo OO 3.1. Introducción Para diseñar un programa orientado a objetos podemos utilizar diferentes metodologías de desarrollo. Ha habido muchos investigadores que han desarrollado alguna metodología específica de desarrollo de software OO. Por ejemplo, Grady Booch desarrolló la metodología denominada Object-Oriented Analysis and Design, Ivor Jacobsson la denominada Object-Oriented Software Engineering, Bertran Meyer la denominada Object-Oriented Software Construction, James Rumbaugh la denominada Object-Oriented Modelling and Design, etc. Pero la que ha quedado como metodología estándar de desarrollo OO es la que han desarrollado conjuntamente G.Booch, I. Jacobsson y J. Rumbaugh dentro de la empresa Rational (ahora parte de IBM) y que se denomina el Proceso Unificado (PU) de desarrollo de software orientado a objetos. En este tema se describe, a través de tres lecciones, una Metodología Básica basada en el Proceso Unificado de Rational para modelar software OO. Es decir, se describen aquellas Disciplinas y Actividades del Proceso Unificado que permiten desarrollar programas triviales y simples. A tal efecto: a) En la primera lección se verá: Una introducción al Proceso Unificado. Características, fases y disciplinas. La Captura de Requisitos: Encontrar Actores y Casos de Uso, Detallar los Casos de Uso, Diseñar un Prototipo de la IU. b) En la segunda lección se tratará: El Análisis y el Diseño: Analizar los Casos de Uso y las clases, Diseñar la Arquitectura, los Casos de Uso y las Clases. c) En la tercera lección se describirá: La Implementación: Implementar la Arquitectura y las Clases, Realizar Pruebas de Unidad e Integrar el Sistema. Las Pruebas, 3.2. Objetivos Conocer al Proceso Unificado, en concreto sus características, disciplinas y fases. Adriana Castro 21 FI - UPM

23 Conocer la diferencia que existe entre el desarrollo de todo el Proceso Unificado y la Metodología Básica que se utiliza para programas pequeños. Comprender la naturaleza de los casos de uso. Utilizar la técnica de casos de uso para descubrir y averiguar lo que se desea que haga el sistema (es lo que se llama captura de requisitos). Utilizar técnicas básicas para definir un prototipo de la interfaz de usuario Introducción 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. Es un 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) análisis y diseño, (4) implementación, (5) pruebas y (6) despliegue. Tres de Soporte: (a) configuración y administración de cambios, (b) gestión de proyectos, y (c) ambiente. Las Fases son: (1) Inicio, (2) Elaboración, (3) Construcción y (4) Transición. Cada iteración (o ciclo) trata las nueve disciplinas y produce una nueva versión, que incorpora en el software más funcionalidad y está más refinado. Cada fase, que consta de una o varias iteraciones, define un estado del software y termina con un hito que plantea una serie de objetivos que se han tenido que alcanzar. Al finalizar cada hito la dirección del proyecto tiene que decidir si el trabajo puede continuar con la siguiente fase. Para el desarrollo de programas pequeños se van a considerar únicamente cuatro disciplinas de desarrollo con una única iteración: (1) Captura de Requisitos, (2) Análisis y Diseño (3) Implementación y (4) Pruebas. Adriana Castro 22 FI - UPM

24 3.4. Captura y Requisitos Introducción Objetivo final: tiene como objetivo final descubrir y averiguar lo que se desea que haga el sistema informático, a través de Casos de Uso. Caso de Uso: Un Caso de Uso especifica una secuencia de acciones, incluyendo variantes, que puede realizar el sistema y que ofrece un resultado observable o tangible para un determinado usuario. Ej. El proceso de Sacar Dinero de un Cajero automático proporciona 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 podrá almacenar dos tipos de elementos: datos de las personas que conoce (amistades o contactos de empresa) y datos de las citas que tiene con esas personas. Personas: Conocidas: nombre completo, número de teléfono y dirección de correo electrónico. Empresa: nombre completo, número de teléfono 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: modificación de la agenda y consulta de la información almacenada. Agregar elementos en la agenda (personas conocidas, personas de empresa y citas), para lo cual deberá proporcionar todos los datos correspondientes al tipo de elemento creado. Eliminar elementos, identificando el elemento que desee eliminar. Para ello deberá proporcionar el nombre completo (para las personas) o la fecha y hora de comienzo (para las citas). Consultar la información contenida en la agenda. Por un lado podrá solicitar todos los datos de una persona (incluido su tipo), dado su nombre deberá proporcionar el nombre completo (para las personas) o la fecha y hora de comienzo (para las citas). Por otro, podrá obtener una lista de las citas pendientes para un día concreto. Por último, deben tenerse en cuenta las siguientes restricciones al funcionamiento de la agenda: Las personas deben ordenarse por orden alfabético del nombre completo. Las citas deben ordenarse por fecha de celebración y, si hay dos citas el mismo día, se ordenarán por hora de comienzo. Adriana Castro 23 FI - UPM

25 No pueden existir dos personas que tengan el mismo nombre completo, aunque sean de distinto tipo. El programa deberá comprobarlo cuando se metan datos de una nueva persona. No pueden existir dos citas el mismo día y a la misma hora. El programa deberá probarlo cuando se creen nuevas citas. Todas las citas que se introduzcan deberán ser con personas que aparezcan en la agenda. El programa deberá comprobarlo cuando se creen nuevas citas Encontrar actores y casos de uso Objetivos: Los objetivos de esta actividad son: Separar el sistema de su entorno: qué debe hacer el sistema y qué deben hacer los usuarios y sistemas externos. Identificar el tipo de usuarios que va a tener el sistema. Definir cómo debe responder el sistema dependiendo del tipo de uso que se haga de él. Esta actividad se divide en tres pasos: identificar actores, identificar casos de uso ydescribir el modelo de casos de uso. a) Identificar actores Objetivo: consiste en encontrar los actores principales del sistema. Un actor es: Un tipo de usuario cuando éste interacciona con el sistema en un caso de uso. Ej. El cliente cuando saca dinero del cajero automático. Un sistema externo que interacciona con el sistema en algún momento. Ej. El banco del cliente conectado con el cajero automático para validar la tarjeta de crédito. Resultado: Para cada actor se pone un nombre y una breve descripción, indicando quién es y para qué usa el sistema. En el caso de la agenda personal el único actor es el usuario de la agenda que interactúa con 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: Adriana Castro 24 FI - UPM

26 El caso de uso debe proporcionar un valor (o resultado) al actor que lo inicia. Con ello se evita que los casos de uso sean demasiado pequeños. Ej. El caso de uso Sacar Dinero de un cajero automático proporciona un valor al cliente que inicia el proceso de sacar dinero. En cambio, Introducir la tarjeta en el cajero es una interacción demasiado pequeña que no proporciona un resultado al usuario. El caso de uso debe proporcionar un valor a usuarios individuales reales y una sola funcionalidad (así no será demasiado grande). Ej. En un cajero automático no sería un buen caso de uso el siguiente: entrar, recargar un móvil, consultar los últimos movimientos del mes y sacar dinero. Lo razonable sería dividirlo en tres casos: (1) recargar un móvil, (2) consultar movimientos y (3) sacar dinero. Resultado: para cada caso de uso se debe especificar: un nombre (debería empezar con verbo en infinitivo) y una breve descripción. Los casos de uso de la agenda personal son los 7 que se indican a continuación. A título de ejemplo se realiza una breve descripción del caso de uso Agregar persona conocida. Agregar persona conocida: El usuario solicita agregar una persona conocida. La agenda pide datos (nombre, teléfono y ) y comprueba si existe una persona con el mismo nombre. Si ya existe entonces termina la operación con error. En otro caso, crea una persona 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 cómo se relacionan los casos de uso entre sí y con los actores. Resultado: Es el Diagrama de casos de uso. La notación que se utiliza para diseñar el diagrama de casos de uso es la siguiente: A continuación se presenta el Diagrama de Casos de Uso de la agenda personal: Hay un único actor (el usuario) que es quien inicia todos los casos de uso y los 7 casos de uso identificados anteriormente. Adriana Castro 25 FI - UPM

27 Detallar los casos de uso Esta actividad consta de dos pasos que se realizan para cada caso de uso: diseñar el diagrama de transición de estados y realizar una descripción textual completa. a) Diseñar diagramas de estados de cada caso de uso El Diagrama de Estados es un grafo que describe el comportamiento dinámico del caso se uso ante los sucesos (eventos) que se producen en el mismo. El Diagrama de Estados está formado por nodos y arcos: Los nodos son los estados del caso de uso y los arcos son transiciones etiquetadas con los nombres de los eventos que las producen. Cada transición es una secuencia de acciones que se realizan cuando se recibe un evento. En el Diagrama de Estados se distinguen el camino básico y los caminos alternativos. A continuación se presenta el Diagrama de Estados de Agregar Persona Conocida (se resalta el camino básico): Adriana Castro 26 FI - UPM

28 b) Descripción textual de casos de uso La descripción del caso de uso se realiza usando el lenguaje del cliente y tiene el siguiente contenido: Precondición: indica el estado inicial del que parte el caso de uso y qué quieren los actores. Flujo de Eventos del camino básico: Describe la interacción de los actores con el sistema y lo que intercambian. Debe indicar quién hace cada cosa. Caminos alternativos: Es una descripción de los flujos de eventos de cada camino alternativo que exista en el Diagrama de Estados del caso de uso. Poscondición: Describe el estado final cuando termina el caso de uso y qué obtienen los actores. Atributos del caso de uso: son objetos o recursos del sistema que se utilizan en el caso de uso y que definen el estado. Estos atributos pueden utilizarse para encontrar clases y atributos en la disciplina de análisis y diseño. Ejemplo: Descripción del caso de uso Agregar persona conocida Definir un prototipo de interfaz de usuario Objetivo: Esta actividad tiene como objetivo realizar un diseño en borrador de las interfaces de usuario Adriana Castro 27 FI - UPM

29 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 con su contenido (entradas y salidas) y los documentos (impresos o en formato electrónico). Los caminos entre esos elementos. La notación que se utiliza es la siguiente: Pantalla: es un símbolo de nota de UML (similar a una nota adhesiva) dividida en tres partes (nombre de la pantalla, información de entrada ( ) o de salida ( ), y acciones del usuario). item Documento: es una símbolo de nota dividida en dos partes (nombre del documento y contenido). Ejemplo: prototipo de interfaz para agregar persona conocida Ejercicios 1. Enumerar las Disciplinas de Desarrollo del Proceso Unificado. Modelado del negocio, captura de requisitos, análisis y diseño, implementación, pruebas, y despliegue. 2. Por qué se dice que el Proceso Unificado es iterativo e incremental? Es iterativo porque en cada ciclo se produce una versión más refinada que la anterior, y es incremental porque en cada ciclo se incorpora más funcionalidad en el software. 3. Qué actividades incorpora la Captura de Requisitos? Encontrar actores y casos de uso, detallar los casos de uso, y definir un prototipo de la interfaz de usuario. 4. Para qué sirve el Diagrama de Casos de Uso? Para describir gráficamente cómo se relacionan los casos de uso entre sí y con los actores. 5. Cómo se detallan los casos de uso? Diseñando para cada caso de uso su diagrama de transición de estados, y realizando una descripción textual completa del mismo. Adriana Castro 28 FI - UPM

30 6. Qué incorpora la descripción textual de un caso de uso? Tiene el siguiente contenido: Precondición, Flujo de Eventos del camino básico, Caminos alternativos, Poscondición, Atributos. 7. El prototipo de interfaz de usuario se diseña con componentes gráficos? No, con notas. 8. Qué tipo de notas se utilizan en el prototipo de interfaz de usuario? La Pantalla (dividida en tres partes: nombre de la pantalla, información de E/S, y acciones del usuario), y el Documento (dividido en dos partes: nombre del documento y su contenido) Conclusiones El Proceso Unificado consta de nueve disciplinas (modelado del negocio, captura de requisitos, análisis y diseño, implementación, pruebas, despliegue, configuración y administración de cambios, gestión de proyectos, y ambiente) y cuatro fases (inicio, elaboración, construcción y transición). El Proceso Unificado es iterativo e incremental. La Captura de Requisitos tiene como objetivo descubrir y averiguar lo que desea que haga el sistema, a través 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 puede realizar el sistema y que ofrece un resultado observable o tangible para un determinado usuario. Encontrar actores y casos de uso implica: identificar actores (usuarios o sistemas externos), identificar casos de uso (una funcionalidad que proporcione un resultado tangible a un usuario), y describir el modelo de casos de uso mediante el diagrama de casos de uso. Detallar los casos de uso implica: diseñar los diagramas de estados de cada caso de uso (grafo que describe el comportamiento dinámico del caso de uso), y realizar una descripción 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 las interfaces de usuario que se van a utilizar en cada caso de uso, describiendo las pantallas con su contenido y los documentos impresos de E/S Anlálisis y Diseño Introducción El Proceso Unificado distingue, para proyectos grandes, entre los modelos de análisis y la de diseño: Modelo de análisis: es un modelo conceptual de objetos que refina y estructura los requisitos, de forma que facilita su comprensión, modificación y mantenimiento. Adriana Castro 29 FI - UPM

31 Modelo de diseño: es un modelo físico del sistema a implementar que es más formal que el del análisis y debe ser mantenido durante todo el ciclo de vida del software. En programas pequeños sólo se realizará el modelo de diseño. Las actividades de la disciplina de diseño son tres que se realizarán de forma iterativa: Diseñar la arquitectura. Diseñar los casos de uso. Diseñar las clases Objetivos Comprender el uso del diagrama de despliegue para diseñar la arquitectura de un programa. Realizar un diseño del programa (modelo implementable), partiendo del modelo de casos de uso: Diseñando los casos de uso, mediante la identificación de clases y la descripción de la interacción entre objetos con diagramas de secuencia. Diseñando cada una de las clases, mediante la identificación de operaciones, de atributos, de asociaciones y agregaciones, de generalizaciones, y mediante la descripción de métodos y de estados de las clases. Realizar iteraciones en el diseño (de los casos de uso y de las clases) hasta llegar al diseño final Diseñar la arquitectura Esta actividad tiene por objeto especificar si el sistema está centralizado (un solo nodo de proceso) o distribuido. Para el caso de programas pequeños esta actividad tiene sólo un paso. Objetivo: consiste en identificar los nodos de proceso y su configuración de red. Resultado: es el Modelo de Despliegue que es un diagrama que muestra nodos de proceso, actores y relaciones entre ellos. Un nodo de proceso se representa como un prisma (un rectángulo con efecto tridimensional). El Modelo de Despliegue de la agenda personal, al tener un único usuario y un único nodo de proceso (no se trata de una agenda distribuida), es el siguiente: Adriana Castro 30 FI - UPM

32 Diseñar los casos de uso Objetivo: consiste en identificar las clases de diseño de cada caso de uso y distribuir el comportamiento de los casos de uso entre los objetos de esas clases. a) Identificar clases de diseño Objetivo: consiste en identificar las clases de diseño de cada caso de uso y sus relaciones básicas. Las clases que se pueden identificar en la primera iteración son: Clases que sirven de interfaz entre los actores y el sistema. Habrá una clase de este tipo para cada actor identificado. Clases que llevan el control de la ejecución del sistema. En general hay una clase de este tipo para cada caso de uso, pero en programas pequeños se pueden unir todas en una única clase de control. Clases que almacenan información (entidades) que gestiona el sistema. Estas clases salen de los atributos de los casos de uso. De acuerdo con lo anterior, en el caso de la agenda personal habrá: Una clase interfaz porque sólo tenemos a un actor (el usuario de la agenda). Una clase control porque se trata de un programa pequeño. Tres clases entidad para almacenar información de Personas Conocidas, Personas de Empresas y Citas. El resultado son las clases de diseño que se indican a continuación: Las relaciones básicas entre estas clases de diseño son las siguientes: El usuario se relaciona con la clase Interfaz (que es por donde introduce los datos y recibe respuestas) y ésta a su vez se relaciona con la clase Agenda, para que controle la ejecución de las órdenes del usuario. La clase Agenda se relaciona a su vez con las tres clases entidad: PConocida, PEmpresa y Cita, a las cuales tendrá que solicitar que realicen una serie de acciones. La clase Cita se relaciona con las clases PConocida y PEmpresa, ya que puede existir una cita con cualquiera de ellas. El resultado de estas relaciones básicas es el Diagrama de Clases Inicial que se indica en la figura adjunta. En este diagrama inicial de diseño no se indican ni las relaciones de agregación o generalización, ni las cardinalidades. Adriana Castro 31 FI - UPM

33 b) Describir interacciones entre objetos de diseño Objetivo: consiste en describir cómo interaccionan entre sí los objetos correspondientes a las clases de diseño descritas anteriormente. Resultado: como resultado se obtienen Diagramas de Secuencia (uno para cada caso de uso; pueden ser más si hay caminos alternativos). También se incluyen Diagramas de Secuencia para dos situaciones especiales: el arranque del sistema (Inicio) y el final de la ejecución (Salida). Notación de un Diagrama de Secuencia: Incorpora en la parte superior los actores y los objetos de clase que participan en ese Diagrama de Secuencia. Los actores y los objetos interactúan mandándose mensajes (flecha continua con punta cerrada) y responden a los mensajes (flecha discontinua con punta abierta).en general no se representan las respuestas en el diagrama. Sólo se hace si la respuesta devuelve algo significativo (por ejemplo, un nuevo objeto que utiliza posteriormente). Cuando un objeto recibe un mensaje se abre una línea de vida (un rectángulo alargado) que está abierta hasta que el objeto finaliza las acciones que tiene que realizar para responder al mensaje. Cuando un mensaje (o mensajes) se ejecuta varias veces (por ejemplo, para todos los objetos de una clase), se encuadra en un fragmento denominado loop. La condición de ejecución del bucle se define entre corchetes dentro del fragmento. Cuando un mensaje se ejecuta dependiendo de una condición, se encuadra en un fragmento denominado alt. La parte superior del fragmento se realiza si se produce la condición [existe] y la parte inferior sino se produce [else]. Esta notación admite condiciones múltiples (del tipo case of ). Cuando se quiere aclarar un concepto se incorpora una nota (un rectángulo con la esquina superior derecha doblada). A continuación se pone un ejemplo de esta notación. Adriana Castro 32 FI - UPM

34 Diagramas de Secuencia de la Agenda Personal Inicio del sistema: El Usuario pide al objeto Interfaz que inicie la ejecución de la agenda personal (Iniciar()). 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 teléfono (t) y el (e) de esa persona (esta solicitud no se representa en el diagrama de secuencia, ya que es consecuencia de la petición del usuario). Seguidamente, Interfaz pide a 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 de empresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si no existe ninguna persona con ese nombre entonces crea una persona conocida con esos datos ( create PConocida(n,t,e)). Adriana Castro 33 FI - UPM

35 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 teléfono (t) y el nombre de la empresa (ne) de esa persona. Seguidamente, Interfaz pide a Agenda que agregue esa persona en la agenda (AgergarPEmpresa(n,t,ne)). Agenda pregunta a todas las personas conocidas (PConocida) y a todas las personas de empresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si no existe ninguna persona 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()). Interfaz obtiene el nombre (n) de la persona que quiere consultar. Seguidamente, Interfaz pide a Agenda que le proporcione información de la persona n (ConsultarPersona(n)). Adriana Castro 34 FI - UPM

36 Agenda pregunta a todas las personas conocidas (PConocida) si su nombre es n (CompararNombre(n)). Si la encuentra le pide que proporcione sus datos (EscribirDatos()). Si no la encuentra, pregunta a todas las personas de empresa (PEmpresa) si su nombre es n (CompararNombre(n)). Si la encuentra le pide que proporcione sus datos (EscribirDatos()). 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 persona n de la agenda (EliminarPersona(n)). Agenda pregunta a todas las personas conocidas (PConocida) y a todas las personas de empresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si la encuentra, pregunta a todas las citas (Cita) si hay alguna cita con esa persona (IgualNombrePersona(n)). Para ello cada cita pregunta a su persona si su nombre es n (CompararNombre(n)), si es cierto se 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). Adriana Castro 35 FI - UPM

37 Agregar cita: El Usuario pide a Interfaz que agregue una cita en la agenda (AgregarCita()). Interfaz solicita al Usuario el nombre de la persona(n), la fecha de la cita (f), la hora de inicio de la cita (hi), la hora de fin (hf) y el lugar de la cita (l). Seguidamente, Interfaz pide a Agenda que agregue esa cita en la agenda (AgergarCita(n, f, hi, hf, l)). Agenda pregunta a todas las personas conocidas (PConocida) y a todas las personas de empresa (PEmpresa), si su nombre es n (CompararNombre(n)). Si encuentra a una persona p con ese nombre, entonces pregunta a Cita si existe alguna cita con esa fecha y esa hora de inicio (CompararFechaHora (f, hi)), si no existe ninguna crea una cita con esos datos (<<create>> Cita(p, f, hi, hf, l)), pasándole la persona (y no su nombre) como parámetro. Adriana Castro 36 FI - UPM

38 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 a Agenda que le proporcione toda la información 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 el nombre de su persona, le pide, según 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()). Interfaz solicita al Usuario que le proporcione la fecha (f) y hora de inicio (hi) de la cita. Seguidamente, Interfaz pide a Agenda que elimine esa cita de la agenda (EliminarCita(f, hi)). Adriana Castro 37 FI - UPM

39 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 aplicación (Salir()). Entonces, Interfaz da la orden a la Agenda para que se destruya (<<destroy>> Agenda). Para ello, Agenda destruye todas las citas (<<destroy>>cita), seguidamente destruye todas las personas conocidas (<<destroy>>pconocida) y todas las personas de empresa (<<destroy>>pempresa)) Diseñar las clases En esta actividad se diseña cada una de las clases, siguiendo los 6 pasos siguientes: Identificar operaciones, Identificar atributos, Identificar asociaciones y agregaciones, Identificar generalizaciones, Describir métodos, y Describir estados de las clases. a) Identificar operaciones Objetivo: consiste en identificar las operaciones de cada clase. Criterios: Adriana Castro 38 FI - UPM

40 Ejemplo: Se identifican los mensajes a los que debe responder la clase en cada diagrama de secuencia en el que aparece. Para destroy : Se pone como operación <nombre clase>. Esta operación se denomina (Destructor). Se define la visibilidad de cada operación (normalmente será pública). Se declaran las operaciones usando la sintaxis de UML o la sintaxis del lenguaje de programación de implementación. 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 pública. 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), CompararFechaHora(f, h), CompararFecha(f), y EscribirDatos(). Y su visibilidad es pública. Gráficamente, en UML, se representarían así: b) Identificar atributos Objetivo: consiste en identificar los atributos de cada clase. Criterios: Ejemplo: Los atributos definen el estado de los objetos y deben ser los requeridos por la clase para realizar sus operaciones. Los tipos de los atributos se restringen a los disponibles en el lenguaje de programación de implementación. 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. Los atributos de las clases de la agenda personal son los que se indican a continuación: Adriana Castro 39 FI - UPM

41 c) Identificar asociaciones y agregaciones Objetivo: consiste en identificar las relaciones obtenidas de los diagramas de secuencia y definir cuáles son asociaciones, agregaciones y dependencias. Criterios: Ejemplo: Se parte de las asociaciones existentes en el diagrama de clases inicial. Se estudian los diagramas de secuencia y se ve qué relaciones son realmente necesarias: para cada mensaje del diagrama de secuencia debe existir una relación que una la clase origen con la clase destino. Se identifica cuáles son asociaciones y cuáles dependencias. Se identifican aquellas asociaciones que son agregaciones (relaciones todo parte, en las cuales la participación en la relación forma parte de la esencia del todo ). Se define si las agregaciones son fuertes o débiles. Se definen las cardinalidades. En el caso de la agenda personal, se ve que la clase Agenda es un agregado fuerte de las clases PConocida, PEmpresa y Cita. Y Cita es una asociación con PConocida y PEmpresa (unidas por un OR, dado que la cita tiene que ser con una u otra persona). Cardinalidades: La Agenda puede tener 0 ó varias personas conocidas, de empresa y citas. Y éstas pertenecen a una única Agenda. Una Cita es con una persona conocida o de empresa. Y una persona puede tener 0 ó varias citas. El Diagrama de Clases de la agenda personal con agregaciones y cardinalidades es el siguiente: El Diagrama de Clases Completo antes de la herencia es: Adriana Castro 40 FI - UPM

42 d) Identificar generalizaciones Objetivo: consiste en identificar generalizaciones (jerarquías de herencia) entre clases de diseño. Criterios: Si hay clases con atributos y operaciones comunes se estudiará la creación de una clase más general que sea superclase de las otras. Al introducir clases generales hay que reestructurar atributos, operaciones y relaciones entre clases. Una clase abstracta no tiene objetos directos. Por ejemplo, la clase Persona de la que derivan Persona Conocida y Persona de Empresa, no tiene instancias de esa clase. Igualmente los métodos abstractos que tienen las clases abstractas no tienen implementación (en algunos lenguajes de programación son llamados métodos virtuales). Partiendo del Diagrama de Clases completo anterior, realizamos las siguientes acciones: Se define la clase Persona (clase abstracta), con atributos y operaciones comunes a PConocida y PEmpresa: Son atributos comunes: el nombre de la persona(n), y el teléfono(t). Son operaciones comunes: CompararNombre(n) y EscribirNombre(). Como EscribirDatos() es una operación que existe en PConocida y PEmpresa, pero con diferente implementación, es por lo que debe figurar en la clase Persona como método abstracto. La clase Persona también debe incorporar su constructor <<create>>persona(n,t), y su destructor <<destroy>> Persona(). La clase PConocida, queda reducida a: Atributos: el (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). Adriana Castro 41 FI - UPM

43 Operaciones: el constructor <<create>>pempresa(n,t,ne), el destructor <<destroy>> PEmpresa(), y EscribirDatos(). La relación de agregación de Agenda es ahora con la clase Persona, ya que PConocida y PEmpresa son subclases de Persona. Y por la misma razón, la relación de agregación asociación de Cita es con la clase Persona. Como resultado se tienen los Diagramas de Clases que se indican a continuación: Al incorporar la clase Persona habrá que diseñar los Diagramas de Secuencia en que participe esta clase para verificar que la generalización 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 a Agenda. 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)). Adriana Castro 42 FI - UPM

44 Eliminar Persona El Usuario pide a Interfaz que elimine una persona de nombre n, e Interfaz se lo pide 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 con esa persona (IgualNombrePersona(n)), si existen citas que cumplen esta condición, entonces Agenda las destruye (<<destroy>>cita). Finalmente se destruye a la persona (<<destroy>>persona). e) Describir los métodos Objetivo: consiste en describir cómo se realizan las operaciones. Notación: en la descripción se utiliza un lenguaje natural, o pseudocódigo, o diagramas arborescentes, o diagramas de ChapinChapin (estos dos tipos de diagramas se explicarán en la metodología estructurada). Nota: Cuando los programas son pequeños (como en este caso) los métodos se describen directamente durante la Implementación, utilizando un lenguaje de programación. f) Describir estados Adriana Castro 43 FI - UPM

45 Objetivo: consiste en describir los estados por los que puede pasar un objeto de una clase. Notación: se utilizan los Diagrama de Transición de Estados(DTE). Criterios: Estos DTE se realizan cuando los objetos de una clase tienen estados que controlan su comportamiento: como respuesta a un mensaje pueden comportarse de una manera u otra en función de su estado. Es decir, que el control de la ejecución del mismo mensaje depende del estado. Estos DTE son útiles para derivar nuevos atributos ( de estado ) e incluso operaciones privadas ( transiciones ) que no se detectan con los diagramas de secuencia. También se utilizan para verificar que no faltan operaciones por identificar en esa clase y que los métodos 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 métodos PulsarOn() que produce el encendido de la bombilla, y PulsarOff() que produce el apagado de la bombilla. Pero al hacer el diagrama de transición de estados del Interruptor aparece un método privado Averiado() que representa la respuesta del interruptor en caso de avería. Este método se descubre al describir los estados del Interruptor Iteraciones (refinado de diseño) En este instante se tiene un Diagrama de Clases en el ámbito del dominio; es decir, con todas las clases identificadas en el enunciado del problema. Ahora hay que obtener un Diagrama de Clases en el ámbito del sistema (del computador); es decir, con todas las clases que Adriana Castro 44 FI - UPM

46 sean necesarias para que se tenga una buena implementación en el computador. A tal fin, se van realizando varias iteraciones, refinando de forma incremental el diseño, hasta que se define el sistema final. Para ello, se repiten las actividades diseñar los casos de uso y diseñar las clases hasta que se considera que el diseño presenta una buena implementación. 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 clases que gestionen las colecciones de datos. Una para gestionar las personas (ListaPersonas) y otra para gestionar las citas (ListaCitas). Como resultado se obtiene el siguiente Diagrama de Clases refinado: Con las nuevas clases hay que refinar el diseño de casos de uso mediante los diagramas de secuencia. Iniciar: Interfaz crea Agenda y ésta crea ListaPersonas y ListaCitas. Adriana Castro 45 FI - UPM

47 Agregar persona conocida: Agenda pide a ListaPersonas que agregue la persona conocida, y es ListaPersonas la que realiza todas las acciones que realizaba antes Agenda. Agregar persona empresa: Agenda pide a ListaPersonas que agregue la persona de empresa, y es ListaPersonas la que realiza todas las acciones que realizaba antes Agenda. Consultar persona: Agenda pide a ListaPersonas que proporcione datos de una persona, y es ListaPersonas preguntando 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. Adriana Castro 46 FI - UPM

48 Agregar cita: Agenda pide a ListaPersonas que busque a la persona citada, para lo cual pregunta a Persona si existe esa persona. Si la persona citada existe, Agenda pide a ListaCitas que incorpore esa nueva 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 ListaCitas pregunta a Cita si existe esa cita, y en caso afirmativo que proporcione todos sus datos. Adriana Castro 47 FI - UPM

49 Eliminar cita: Agenda pide a ListaCitas que elimine esa cita, para lo cual ListaCitas pregunta a Cita si existe 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 destruye todas 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 las personas, porque si se hace al revés todos los enlaces de las personas a sus citas quedarían colgando. El Diagrama Final de Clases con listas se presenta a continuación: Interesa notar que de los diagramas de secuencia se obtienen relaciones de uso (de instanciación) <<create>> entre ListaPersonas y los tipos PConocida y PEmpresa. Adriana Castro 48 FI - UPM

50 Ejercicios 1. Cómo son el Modelo de análisis y el Modelo de diseño? El modelo de análisis es un modelo conceptual de objetos. Y el Modelo de diseño es más formal, es un modelo físico del sistema a implementar. 2. Qué actividades implica el Diseño? Diseñar la arquitectura, los casos de uso y las clases. 3. Qué se obtiene como resultado al diseñar la arquitectura? El modelo de despliegue que muestra nodos de proceso, actores y relaciones entre ellos. 4. Qué pasos hay que realizar para diseñar los casos de uso? Identificar las clases de diseño, y describir las interacciones entre los objetos de diseño. 5. Qué tipo de clases de análisis existen? De interfaz, de control y de entidad. 6. Qué herramienta se utiliza para describir las interacciones entre objetos? El Diagrama de Secuencia. Adriana Castro 49 FI - UPM

51 7. Qué pasos hay que realizar para diseñar las clases? Identificar operaciones, atributos, asociaciones y agregaciones, generalizaciones, describir los métodos, describir los estados, y refinar este diseño. 8. Cómo se identifican las operaciones de una clase? A partir de los mensajes que recibe esa clase en los Diagramas de Secuencia. 9. Qué tipos de atributos son las relaciones? Las relaciones no son atributos. 10. Cómo se identifican las relaciones de dependencia, asociación y agregación? A partir de los Diagramas de Secuencia viendo qué objetos están relacionados en el envío de mensajes. 11. Cómo se identifican las generalizaciones? Viendo qué clases tienen atributos y operaciones comunes. 12. Con qué se describen los métodos? Con el lenguaje natural, pseudocódigo, diagramas arborescentes o de Chapin. 13. Qué aporta describir el estado de los objetos? Nuevos atributos, operaciones privadas, y verificar que no faltan operaciones por identificar. 14. En qué consiste refinar el diseño? En obtener un Diagrama de Clases en el ámbito del sistema. Es decir, con todas las clases que son necesarias para obtener una buena implementación en el computador Conclusiones La disciplina de Análisis y Diseño consiste en obtener los modelos de análisis y de diseño. En programas pequeños sólo se realiza el modelo de diseño. Esta disciplina tiene las siguientes actividades: Diseñar la arquitectura, diseñar los casos de uso, y diseñar las clases. El diseño de la arquitectura tiene como objetivo identificar los nodos de proceso y su configuración en red. Obtiene cono resultado el Modelo de Despliegue. El diseño de los casos de uso implica identificar las clases de diseño (interfaz, control, e identidad), y describir las interacciones entre los objetos mediante los Diagramas de Secuencia de cada caso de uso. Diseñar las clases comporta: identificar las operaciones de cada clase utilizando los Diagramas de Secuencia, identificar los atributos de cada clase, identificar las relaciones de asociación y agregación mediante los Diagramas de Secuencia, identificar generalizaciones viendo si hay atributos y operaciones comunes a varias clases, describir los métodos, describir los estados de los objetos para obtener nuevos atributos y operaciones privadas, y refinar el diseño obtenido. Adriana Castro 50 FI - UPM

52 Durante el diseño de las clases se obtienen varios diagramas de clases: El Diagrama de Clases antes de la herencia (con asociaciones y agregaciones), el Diagrama de Clases en el ámbito del dominio, y finalmente el Diagrama de Clases Final al refinar el diseño anterior Implementación Introducción Modelar la estructura del código fuente mediante un diagrama de componentes, asignando cada componente al nodo de proceso que corresponda. Generar el esqueleto del programa partiendo del diseño, mediante la declaración de las clases y el desarrollo del programa principal en el lenguaje de programación elegido. Codificar cada operación de cada clase, partiendo de los diagramas de secuencia del diseño y de la especificación de cada operación. Comprender cómo se aplican las pruebas de unidad en un programa orientado a objetos. Conocer las técnicas para decidir una estrategia adecuada para ir integrando componentes (clases) con el resto del programa ya terminado. Conocer la utilización de casos de prueba para definir las pruebas y para realizarlas Objetivos Implementar las clases dentro de componentes (ficheros). Asignar componentes ejecutables a nodos. Probar los componentes individualmente. Integrarlos en el sistema de forma incremental Implementar la arquitectura Objetivo: diseñar el Modelo de Implementación. a) Identificar componentes Objetivo: consiste en identificar los componentes (ficheros) que forman el programa y sus 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 representará como un único componente. Adriana Castro 51 FI - UPM

53 Resultado: Diagrama de Componentes. Notación: La notación utilizada para diseñar el Diagrama de Componentes es la siguiente (ver gráficos adjuntos): Programa principal: Un rectángulo con estereotipo <<artifact>> que incorpora el nombre el programa y un icono de documento vacío. Componente: Un rectángulo con estereotipo <<component>> que incorpora el nombre del componente y un icono de componente (un rectángulo con dos rectángulos más pequeños en el lado izquierdo). Relación de uso: Una flecha de trazos que indica que el componente 1 usa al componente 2. Nota informativa: Proporciona información sobre un componente o un relación de uso. Agenda: diagrama de componentes. b) Asignar componentes a nodos Objetivo: consiste en asignar componentes a los nodos de proceso del Diagrama de Despliegue obtenido en la fase de diseño. Adriana Castro 52 FI - UPM