Modelos de Desarrollo de Programas

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Diagramas de Clase en UML 1.1

Diagramas de Clase en UML 1.1 Diagramas de Clase en UML. Francisco José García Peñalvo Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de la Universidad de Burgos. fgarcia@.ubu.es Carlos Pardo Aguilar

Más detalles

El modelo de casos de uso. Ingeniería de la Programación

El modelo de casos de uso. Ingeniería de la Programación El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

PROCESO UNIFICADO CAPTURA DE REQUISITOS

PROCESO UNIFICADO CAPTURA DE REQUISITOS PROCESO UNIFICADO CAPTURA DE REQUISITOS El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified software development process, Ivar Jacobson,

Más detalles

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos: Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende

Más detalles

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Introducción al UML Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Contenido Qué es UML?. Diagramas Utilizados en UML. Ejemplos. Qué es UML UML es un Lenguaje de Modelado

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera Departamento de Lenguajes y Sistemas Informáticos INDICE 1. Introducción. 2. Documentación del Proyecto de Fin de

Más detalles

Notación UML para modelado Orientado a Objetos

Notación UML para modelado Orientado a Objetos 1 Notación UML para modelado Orientado a Objetos 2 Notación UML para modelado Orientado a Objetos Índice 1.1. Qué es UML?.. 3 1.2. Por qué interesa UML en la asignatura de Programación Orientada a Objetos?3

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010 INTRODUCCION Un concepto fundamental que debemos tener en cuenta a la hora de modelar la realidad por medio de objetos es que los mismos no son entidades aisladas. Los objetos interactúan entre ellos constantemente

Más detalles

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de:

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: UML UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: Conceptos de modelado de datos (diagramas entidad-relación) Modelado de negocios (flujos de trabajo) Modelado de objetos Modelado

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Tema 5. Diseño detallado.

Tema 5. Diseño detallado. Ingeniería del Software II 2011 Tema 5. Diseño detallado. Diseño del Software. Los requisitos y el análisis orientado a objetos se centran en aprender a hacer lo correcto: Entender los objetos de nuestro

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

QUÉ ES Y PARA QUÉ SIRVE UML? VERSIONES DEL LENGUAJE UNIFICADO DE MODELADO. TIPOS DE DIAGRAMAS. INGENIERÍA DEL SOFTWARE (DV00205D)

QUÉ ES Y PARA QUÉ SIRVE UML? VERSIONES DEL LENGUAJE UNIFICADO DE MODELADO. TIPOS DE DIAGRAMAS. INGENIERÍA DEL SOFTWARE (DV00205D) APRENDERAPROGRAMAR.COM QUÉ ES Y PARA QUÉ SIRVE UML? VERSIONES DEL LENGUAJE UNIFICADO DE MODELADO. TIPOS DE DIAGRAMAS. INGENIERÍA DEL SOFTWARE (DV00205D) Sección: Divulgación Categoría: Lenguajes y entornos

Más detalles

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software 2. Conceptos básicos Hoy en día las aplicaciones son demasiado voluminosas y complejas para ser manejadas por una sola persona. Las aplicaciones de software son complejas porque modelan la complejidad

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles

Guía del Curso Analista Programador PHP Javascript

Guía del Curso Analista Programador PHP Javascript Guía del Curso Analista Programador PHP Javascript Modalidad de realización del curso: Número de Horas: Titulación: Online 180 Horas Diploma acreditativo con las horas del curso OBJETIVOS UML usa técnicas

Más detalles

UNIDAD 11 VALIDACION DE REQUISITOS

UNIDAD 11 VALIDACION DE REQUISITOS UNIDAD 11 VALIDACION DE REQUISITOS 11. VALIDACIÓN DE REQUISITOS... 1 11.1. REVISIÓN DE REQUISITOS... 3 11.2. PROTOTIPOS... 6 11.3. GENERACIÓN DE CASOS DE PRUEBA... 9 El proceso de validación de requisitos

Más detalles

Un Método Práctico para comenzar la Especificación de Requerimientos

Un Método Práctico para comenzar la Especificación de Requerimientos DEPARTAMENTO DE INFORMÁTICA. ÁREA SISTEMAS Y GESTIÓN. Casos de Uso Un Método Práctico para comenzar la Especificación de Requerimientos 1. Introducción 1.1. Objetivo de este apunte En uno de los párrafos

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos I. INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial.

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

DCU Diagramas de casos de uso

DCU Diagramas de casos de uso DCU Diagramas de casos de uso Universidad de Oviedo Departamento de Informática Contenidos Introducción Elementos básicos Más sobre los actores Más sobre los casos de uso Más sobre las asociaciones Otros

Más detalles

Metodología de Diseño para Gestión de Procesos Documentales (MDPD)

Metodología de Diseño para Gestión de Procesos Documentales (MDPD) Metodología de Diseño para Gestión de Procesos Documentales (MDPD) Aquilino A. Juan Fuente Profesor de la Universidad de Oviedo aquilino@lsi.uniovi.es Juan Manuel Cueva Lovelle Catedrático de Escuela de

Más detalles

Manual de ayuda para crear y gestionar Tareas, como actividad evaluable

Manual de ayuda para crear y gestionar Tareas, como actividad evaluable Manual de ayuda para crear y gestionar Tareas, como actividad evaluable Contenido TAREAS.... 3 CONFIGURACIÓN.... 3 GESTIÓN Y CALIFICACIÓN DE TAREAS.... 8 TAREAS. Mediante esta herramienta podemos establecer

Más detalles

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones Sistema de Administración de Farmacias Plan de SQA Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 29/08/2014 1.0 Realización del documento Resp. SQA Plan de SQA Página 1 de 15 ÍNDICE

Más detalles

Contenido TEMARIO... 2 INTRODUCCIÓN... 4 INGENIERÍA DEL SOFTWARE... 5 EL INICIO... 6 GESTIÓN DE PROYECTOS... 10 INGENIERÍA DE SISTEMAS...

Contenido TEMARIO... 2 INTRODUCCIÓN... 4 INGENIERÍA DEL SOFTWARE... 5 EL INICIO... 6 GESTIÓN DE PROYECTOS... 10 INGENIERÍA DE SISTEMAS... Contenido TEMARIO... 2 INTRODUCCIÓN... 4 INGENIERÍA DEL SOFTWARE... 5 EL INICIO... 6 GESTIÓN DE PROYECTOS... 10 INGENIERÍA DE SISTEMAS... 20 ANÁLISIS DE REQUERIMIENTOS... 22 DISEÑO DE LA SOLUCIÓN... 30

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

B.1 Checklist: evaluación heurística del producto software

B.1 Checklist: evaluación heurística del producto software Apéndice B Plantillas En las siguientes secciones se describen las plantillas textuales necesarias para la descripción de los documentos empleados en OPSOA. B.1 Checklist: evaluación heurística del producto

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

Índice de contenido 1.Introducción...3 1.1Propósito...3 1.2Vista preliminar...3 2.Requisitos técnicos de instalación...4 2.1Software...4 2.2Red...

Índice de contenido 1.Introducción...3 1.1Propósito...3 1.2Vista preliminar...3 2.Requisitos técnicos de instalación...4 2.1Software...4 2.2Red... Guía de Instalación Índice de contenido 1.Introducción...3 1.1Propósito...3 1.2Vista preliminar...3 2.Requisitos técnicos de instalación...4 2.1Software...4 2.2Red...5 3.Proceso de instalación...7 Paso

Más detalles

El Desarrollo de Software desde un enfoque de procesos

El Desarrollo de Software desde un enfoque de procesos El Desarrollo de Software desde un enfoque de procesos Planteamiento del Problema Desarrollo de Software Software Proceso: conjunto de actividades interrelacionadas que permiten

Más detalles

B.2.2. Principios para la gestión de proyectos

B.2.2. Principios para la gestión de proyectos B.2.2. Principios para la gestión de proyectos La gestión de proyectos es la aplicación de conocimientos, conocimiento técnico, herramientas y técnicas para planificar actividades a fin de satisfacer o

Más detalles

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

Más detalles

El Proceso Unificado Rational para el Desarrollo de Software.

El Proceso Unificado Rational para el Desarrollo de Software. Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Software de gestión hostelera. con menú digital

Software de gestión hostelera. con menú digital Universidad de Valladolid E. U. DE INFORMÁTICA (SEGOVIA) Grado en Ingeniería Informática de Servicios y Aplicaciones Software de gestión hostelera con menú digital Alumno: Tutora: Pilar Grande González

Más detalles

Anexo I MÓDULOS PROFESIONALES. 1. Evalúa sistemas informáticos identificando sus componentes y características.

Anexo I MÓDULOS PROFESIONALES. 1. Evalúa sistemas informáticos identificando sus componentes y características. Página I / Anexo I Núm. 135 BOLETÍN OFICIAL DE LA RIOJA Viernes, 21 de octubre de 2011 Módulo Profesional: Sistemas informáticos. Código: 0483 Equivalencia en créditos ECTS: 10 Curso: 1º Duración: 170

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

El conjunto de conocimientos científicos y técnicos que hacen posible la resolución de forma automática de problemas por medio de las computadoras.

El conjunto de conocimientos científicos y técnicos que hacen posible la resolución de forma automática de problemas por medio de las computadoras. 1 Conceptos Generales 1.1 Definición de Informática Una posible definición de informática podría ser: El conjunto de conocimientos científicos y técnicos que hacen posible la resolución de forma automática

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Instructivo para la elaboración de un Manual Técnico

Instructivo para la elaboración de un Manual Técnico Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

3 - PROCESOS DE LA DIRECCIÓN DE PROYECTOS

3 - PROCESOS DE LA DIRECCIÓN DE PROYECTOS PROCESOS DE LA DIRECCIÓN DE PROYECTOS La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Arturo Cepeda Pérez. Software Engineering Tutor

Arturo Cepeda Pérez. Software Engineering Tutor Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...

Más detalles

CONTROL DE ASISTENCIA DE PERSONAL

CONTROL DE ASISTENCIA DE PERSONAL CONTROL DE ASISTENCIA DE PERSONAL PARA UNA EMPRESA INITE, S.C. no es responsable del contenido, de la veracidad de los datos, opiniones y acontecimientos vertidos en el presente proyecto. La finalidad

Más detalles

Documento de Arquitectura de Software IEEE-1471-2000

Documento de Arquitectura de Software IEEE-1471-2000 Documento de Arquitectura de Software Control del documento IEEE-1471-2000 Proyecto Sistema Restaurant Título Arquitectura del Sistema [v1.0 al 02 de Julio de 2009] Generado por Magister en Informática

Más detalles

Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado

Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado DIAGRAMAS DE CLASES RELACIONES ENTRE CLASES Una vez que tengamos todas nuestras clases, será necesario que estas se asocien, con el fin de mostrar la

Más detalles

Modelado de datos Relacional Modelado de datos Orientado a Objeto Modelado de datos Objeto-Relacional

Modelado de datos Relacional Modelado de datos Orientado a Objeto Modelado de datos Objeto-Relacional 2. 1 Modelado de Datos El manejo de información implica el saber como organizar los datos. Un apoyo lo encontramos en las herramientas de bases de datos que a su vez se apoyan en el modelo de datos. Para

Más detalles

Instructivo para la operación del sistema PAI

Instructivo para la operación del sistema PAI Instructivo para la operación del sistema PAI 1. Presentación De conformidad con el ordenamiento vigente, las auditorías internas del sector público deben comunicar sus planes anuales a la Contraloría

Más detalles

Conceptos Básicos. Capítulo 1. 1.1 Informática

Conceptos Básicos. Capítulo 1. 1.1 Informática Capítulo 1 Conceptos Básicos 1.1 Informática... 17 1.2 Computador... 18 1.3 Sistema operativo... 19 1.4 Aplicaciones... 20 1.5 Algoritmos y programas... 21 1.6 Ejercicios... 27 1.7 Comentarios bibliográficos...

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

MODULO DE PROGRAMACION JAVA Nivel Básico-Intermedio

MODULO DE PROGRAMACION JAVA Nivel Básico-Intermedio MODULO DE PROGRAMACION JAVA Nivel Básico-Intermedio Objetivo general: Introducir al participante en los conceptos y herramientas más importantes del lenguaje javo para la programación de objetos. Duración

Más detalles

PROCEDIMIENTO OPERATIVO DESARROLLAR SISTEMAS INFORMÁTICOS PDO-COCTI-DTIN-04

PROCEDIMIENTO OPERATIVO DESARROLLAR SISTEMAS INFORMÁTICOS PDO-COCTI-DTIN-04 Autorización Este documento entra en vigor a partir del 2 de agosto del 2005, a través de su autorización por parte del Dr. Francisco Javier Rojas Monroy, Coordinador de Operaciones, Calidad y Teclogía

Más detalles

Soporte lógico de computadoras

Soporte lógico de computadoras Soporte lógico de computadoras Software: Sistemas Operativos Lenguajes de programación Lenguajes de Programación. Clasificación Proximidad del lenguaje al que entiende el ordenador: Bajo nivel: específico

Más detalles

Programación Orientada a Objetos INTRODUCCIÓN Y CONCEPTOS

Programación Orientada a Objetos INTRODUCCIÓN Y CONCEPTOS Programación Orientada a Objetos INTRODUCCIÓN Y CONCEPTOS Programación OO Vista Macro: La programación orientada a objetos trata sobre el desarrollo de software utilizando un paradigma que descompone el

Más detalles

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo 1 CAPITULO 2 ANÁLISIS DEL SISTEMA 1. Introducción Como se definió en el plan del presente proyecto, este será desarrollado bajo la metodología orientada a objetos. El objetivo del análisis será marcar

Más detalles

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS GUIA PROGRAMACIÓN ORIENTADA A OBJETOS 1. Por qué la P.O.O? R= A medida que se van desarrollando los lenguajes, se va desarrollando también la posibilidad de resolver problemas más complejos. En la evolución

Más detalles

ÍNDICE. Introducción... 4. Agradecimientos... 5. Objetivos... 5. a. Objetivo General... 5. b. Objetivos Específicos... 5

ÍNDICE. Introducción... 4. Agradecimientos... 5. Objetivos... 5. a. Objetivo General... 5. b. Objetivos Específicos... 5 ÍNDICE Introducción... 4 Agradecimientos... 5 Objetivos... 5 a. Objetivo General... 5 b. Objetivos Específicos... 5 Capítulo I: Desarrollo de Sistema de Información Usando Metodología Rumbaugh (OMT)...

Más detalles

DATOS DE IDENTIFICACION DEL CURSO DEPARTAMENTO:

DATOS DE IDENTIFICACION DEL CURSO DEPARTAMENTO: DATOS DE IDENTIFICACION DEL CURSO DEPARTAMENTO: Departamento de Ciencias Computacionales ACADEMIA A LA QUE PERTENECE: Ingeniería de Software NOMBRE DE LA MATERIA: Ingeniería de Software II CLAVE: CC305

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Fundamentos de Ingeniería del Software Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Cap 3. Análisis de Requisitos Estructura 1. Actividades iniciales. 2. Técnicas de recogida de la

Más detalles

Manual del Profesor Campus Virtual UNIVO

Manual del Profesor Campus Virtual UNIVO Manual del Profesor Campus Virtual UNIVO Versión 2.0 Universidad de Oriente UNIVO Dirección de Educación a Distancia INDICE 1. Campus Virtual. 03 1.1 Accesos al Curso 04 1.2 Interfaz del Curso...06 1.3

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

Java Inicial (20 horas)

Java Inicial (20 horas) Java Inicial (20 horas) 1 Temario 1. Programación Orientada a Objetos 2. Introducción y Sintaxis Java 3. Sentencias Control Flujo 4. POO en Java 5. Relaciones entre Objetos 6. Polimorfismo, abstracción

Más detalles

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación Ingeniería Software software 4º Físicas 4º de Físicas Análisis de requisitos y especificación de una aplicación José M. Drake Computadores y Tiempo Real Santander, 1 Ingeniería de Programación (4º Físicas)

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

Analista Programador PHP Javascript

Analista Programador PHP Javascript TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Analista Programador PHP Javascript Duración: 420 horas Precio: 0 * Modalidad: Online * hasta 100

Más detalles

Modelado de objetos con UML

Modelado de objetos con UML Modelado de objetos con UML José Vicente Núñez Zuleta (jose@eud.com, josevnz@yahoo.com) Líder de desarrollo para El Diario El Universal División de Nuevos Medios Puntos a tratar Qué es UML? Tipos de diagramas.

Más detalles

Modelado arquitectónico con UML

Modelado arquitectónico con UML Modelado arquitectónico con UML Qué es la arquitectura de software El modelo de 4+1 vistas arquitectónicas Cohesión y acoplamiento Cómo lograr una descomposición modular eficaz Criterios para la selección

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Visual Chart 6. Diseño de sistemas 3 Departamento de formación www.visualchart.com

Visual Chart 6. Diseño de sistemas 3 Departamento de formación www.visualchart.com 3 Departamento de formación www.visualchart.com Diseño de sistemas con Visual Chart 6 CONTENIDO 1. INTRODUCCIÓN A LOS SISTEMAS AUTOMÁTICOS. 2. LOS ENTORNOS DE PROGRAMACIÓN DE VISUAL CHART 6. 3. DISEÑO

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Programación del curso

Programación del curso Ingeniería Software 4º Físicas Programación del curso José M. Drake (drakej@unican.es) Patricia López Martínez ( lopezpa@unican.es ) Computadores y Tiempo Real Santander, 2008 Ingeniería de Programación

Más detalles

Programación: QBASIC

Programación: QBASIC 1. QBASIC Programación: QBASIC Guía del alumno Qbasic es una versión moderna del lenguaje BASIC. Se trata de un lenguaje de alto nivel. En un lenguaje de alto nivel las instrucciones tienen un formato

Más detalles

K2BIM Plan de Proyecto Versión 1.5

K2BIM Plan de Proyecto Versión 1.5 K2BIM Plan de Proyecto Versión 1.5 Historia de revisiones Fecha VersiónDescripción Autor 23/08/2009 1.0 Versión inicial Juan Saavedra 25/08/2009 1.1 Entregable Juan Saavedra 30/08/ 1.2 Se incluyen recursos

Más detalles

Tema 8º: Aspectos prácticos

Tema 8º: Aspectos prácticos Tema 8º: Aspectos prácticos Gestión y planificación Administración de personal Gestión de versiones Reutilización Control de calidad del software Documentación Herramientas Temas especiales Las ventajas

Más detalles

INGENIERÍA DE COMPUTADORES I

INGENIERÍA DE COMPUTADORES I ASIGNATURA DE GRADO: INGENIERÍA DE COMPUTADORES I Curso 2010/2011 (Código:71901066) 1.PRESENTACIÓN DE LA ASIGNATURA El objetivo de esta guía es orientar al alumno en el estudio de la asignatura. Se recomienda

Más detalles

TEMA 5. Contenido. 3.4. Relaciones entre clases... 16

TEMA 5. Contenido. 3.4. Relaciones entre clases... 16 TEMA 5 Contenido 1. INTRODUCCIÓN A LA ORIENTACIÓN A OBJETOS.... 3 El enfoque estructurado.... 3 Enfoque orientado a objetos.... 4 2. CONCEPTOS DE ORIENTACIÓN A OBJETOS.... 5 2.1. Ventajas de la orientación

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

SISTEMA DE EVALUACIÓN EN INGENIERÍA DEL SOFTWARE 2

SISTEMA DE EVALUACIÓN EN INGENIERÍA DEL SOFTWARE 2 SISTEMA DE EVALUACIÓN EN INGENIERÍA DEL SOFTWARE 2 NORBERTO DÍAZ-DIAZ ROBERTO RUIZ FRANCISCO GÓMEZ-VELA JESÚS S. AGUILAR-RUIZ Departamento de Deporte e Informática Escuela Politécnica Superior Universidad

Más detalles

Desarrollo de Software

Desarrollo de Software Especialización en Telemática Desarrollo de Software Arquitecturas de Sistemas Telemáticos Dr. Ing. Álvaro Rendón Gallón Cali, mayo de 2012 Temario 2 Tarea 1: Ordenar datos Tarea 2: Un juego en red Consideraciones

Más detalles

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Curso académico 2008-2009 1 Introducción La práctica de Integración de Sistemas consistirá en el diseño e implementación de

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS

PROGRAMACIÓN ORIENTADA A OBJETOS PROGRAMACIÓN ORIENTADA A OBJETOS Clase 1. Introducción Profesor: Diego Sánchez Gómez Introducción a la programación orientada a objetos 1. Introducción a la programación orientada a objetos 2. Las clases

Más detalles