Proyecto Práctico de Diseño de Software

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

Download "Proyecto Práctico de Diseño de Software"

Transcripción

1 Ingeniería del Software II Ingeniería Informática, 4 Curso Proyecto Práctico de Diseño de Software Curso Gonzalo Génova 1 Presentación Profesores Grupo M Gonzalo Génova (ggenova [at] inf.uc3m.es) - COORDINADOR Eduardo Barra (ebarra [at] inf.uc3m.es) Grupo T Vicente Palacios (palacios [at] di.uc3m.es) Eduardo Barra (ebarra [at] inf.uc3m.es) Grupo C Roberto Galindos (rgalindo [at] inf.uc3m.es) Dirección para entregas de la práctica: is.uc3m [at] gmail.com Web de la asignatura Un curso de análisis y diseño en dos asignaturas: IS1: requisitos del usuario (captura) y requisitos del software (análisis) IS2: diseño arquitectónico (alto nivel) y diseño detallado (bajo nivel) 2

2 Objetivos de la asignatura Especificación del diseño de alto y bajo nivel de una aplicación informática Aprender... Redacción de un documento completo de diseño Desarrollo dirigido por modelos (MDA-MDD-MDE), evolución de USDP Estándares de documentación de proyectos Técnicas de la orientación a objetos para diseño arquitectónico y detallado Desarrollar capacidades Abstracción y resolución de problemas Lectura crítica y reflexiva Trabajo en equipo Exposición de resultados propios Revisión de trabajos ajenos Aprendizaje a partir de errores propios y ajenos 3 Programa de la asignatura: teoría Tema III Diseño arquitectónico (diseño de alto nivel) Unidad 14 La transición del análisis al diseño Unidad 15 Introducción al diseño arquitectónico Unidad 16 Modelado arquitectónico con UML Unidad 17 Herramientas de modelado UML (laboratorio) Unidad 18 Vistas arquitectónicas Unidad 19 Estilos arquitectónicos Unidad 20 Qué es diseño orientado a objetos? (artículo y examen) Tema IV Diseño detallado (diseño de bajo nivel) Unidad 21 Introducción al diseño detallado Unidad 22 Diseño detallado con UML (1): polimorfismo Unidad 23 Diseño detallado con UML (2): interacciones Unidad 24 Diseño detallado con UML (3): máquinas de estados Unidad 25 Patrones de diseño (1) Unidad 26 Patrones de diseño (2) Unidad 27 Implementación de asociaciones UML en Java (artículo y examen) Unidad 28 Herencia múltiple 4

3 Programa de la asignatura: prácticas Equipos de 4 alumnos (atención: alumnos que no han cursado IS1) Trabajo en 2+2 fases (URD/SRD + ADD/DDD) Actividades en cada fase Desarrollo y documentación del proyecto conforme al índice de la práctica recuento de horas dedicadas al proyecto y métricas contabilizadas al principio de cada documento enviadas aparte por correo según las plantillas (horas, métricas) Sesiones de tutoría colectivas, asistencia voluntaria cada equipo tendrá oportunidad de presentar su borrador y recibir críticas Revisiones cruzadas informes de revisión redactados conforme a las normas Exposiciones en público y defensa del proyecto entrega de transparencias impresas el primer día de exposiciones ( 2xPág!) exposición individual de una parte del proyecto respuestas a los revisores y a los profesores 5 Documentación entregada Atención a nombres de archivos y fechas de entrega Dos documentos parciales (el segundo completa al primero): ej. ProyectoIS2-M05.doc: equipo M05, etc. envío por correo a is.uc3m [at] gmail.com y miembros del equipo revisor ver índice adaptado del estándar ESA PSS-05-0 Dos documentos de revisión: ej. RevisiónIS2-M05-R07.doc: equipo M05 revisado por equipo M07, etc. envío por correo a los profesores y a los miembros del equipo revisado Proyecto final revisado (normas): documento final + presentaciones + recuento de horas + métricas ej. ProyectoIS2-M05.doc + etc. envío por correo is.uc3m [at] gmail.com ejemplar impreso encuadernado en espiral con tapas duras, incluyendo: revisiones recibidas y respuestas, revisiones enviadas transparencias de las dos presentaciones Propuesta de preguntas teóricas para el examen de test 6

4 Descripción de la práctica Ingeniería del Software 1 Realizar un proyecto de ingeniería inversa sobre un portal inmobiliario real. Describir brevemente el alcance total de la funcionalidad ofrecida por el portal. Seleccionar un subconjunto coherente de la funcionalidad ofrecida por el portal, de forma que sea abarcable dentro de los límites de carga de trabajo de la asignatura. Describir este subconjunto en forma de requisitos y con los modelos necesarios. Realizar una evaluación del portal (la parte seleccionada). Ingeniería del Software 2: A partir de los requisitos especificados en IS1. Realizar un diseño arquitectónico de la aplicación (ADD), sólo del subconjunto escogido para especificar los requisitos. Realizar un diseño detallado (DDD), sólo de uno de los componentes especificados en el diseño arquitectónico. Proyecto Práctico de Ingeniería de Requisitos 7 Formato de los documentos Word, Times New Roman 12 ó Arial 10, interlineado sencillo. Impreso a doble cara Opcionalmente, formato PDF (con permisos de lectura y copia). Extensión (porque queremos calidad, no cantidad): ADD: 15 a 20 páginas. DDD: 30 a 40 páginas. TOTAL: 45 a 60 páginas (sin contar índices ni anexos). Trabajo excesivo? Factor de penalización en la calificación del documento por exceso de páginas. penalización 1 1-(p-60)/ páginas 8

5 Trabajo en equipo y dedicación a la práctica Un total de 60 horas/alumno dedicadas a la práctica es razonable (58 h/a en IS1). Equivale a una hora de trabajo práctico por cada hora de clase teórica. 20 horas de clase + 20 horas de trabajo personal = 40 horas/semana. La proporción entre trabajo individual y en equipo debería ser 4/1 ó 3/1. Para conseguirlo la distribución y coordinación del trabajo deben ser adecuadas. Si el número de horas es igual para todos falta sinceridad pero si no se califica! En IS1 la proporción ha sido 1,5 / 1: aún falta distribuir mejor el trabajo individual. Nombre Ind. Eq. TOTAL Ana García Juan Gómez Isabel López Pedro Fernández TOTAL MAL Nombre Ind. Eq. TOTAL Ana García Juan Gómez Isabel López Pedro Fernández TOTAL BIEN Proyecto Práctico de de Ingeniería Diseño de Software Requisitos 9 Calendario de la asignatura Dedicación a la asignatura, aproximadamente: 30 horas de clase teórica 30 horas de otras actividades en clase 60 horas de trabajo personal y en equipo Clases teóricas Asistencia no controlada. Dos sesiones en laboratorio. El examen de Test es un reflejo directo del aprovechamiento de las clases teóricas, de ahí la importancia que se le da en la nota final. Tutorías colectivas Asistencia voluntaria. Sirven para que el profesor pueda hacer un seguimiento efectivo del proyecto. Aprovechad la tutoría llevando un borrador bien trabajado. Exposiciones/Revisiones Asistencia obligatoria a todas las exposiciones, aunque no toque exponer. Dos miembros exponen la práctica, dos responden a revisores y profesores. Tiempo máximo de exposición: 20 minutos entre ambos. Calendario completo Atención a las fechas de entregas. Atención a la fecha de confirmación de equipos de prácticas. Proyecto Práctico de Ingeniería de Requisitos 10

6 Evaluación de la asignatura Práctica Teoría Individual Equipo Tutorías* 00% Exp/Preparación 05% Exp/Ejecución** 05% Documentación 30% Exp/Respuestas 05% Revisiones 05% Exámenes parciales*** 10% Examen final 30% Propuesta de preguntas 50% 10% 50% 50% 50% 100% * Asistencia NO obligatoria a tutorías colectivas ** Asistencia obligatoria a las exposiciones ajenas (0,5 penalización por falta no justificada) *** Se tiene en cuenta la participación en el debate posterior Posible bonificación global por participación e interés (sólo a los aprobados) Más detalles Proyecto Práctico de Ingeniería de Requisitos 11 Bibliografía Diseño arquitectónico, diseño detallado Eric Braude. Software Engineering. An Object-Oriented Perspective. John Wiley & Sons, Capítulos 5 y 6 Ian Sommerville. Software Engineering, 7th ed. Pearson-Addison Wesley, Capítulos Roger Pressman. Ingeniería del software: un enfoque práctico, 6ª ed. McGraw-Hill. Capítulos 9-11 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of reusable Object-Oriented software. Addison-Wesley, Modelado con UML Martin Fowler, Kendall Scott. UML Distilled. A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, Jim Arlow, Ila Neustadt. UML and the Unified Process. Practical Object-Oriented Analysis & Design. Addison-Wesley, Perdita Stevens, Rob Pooley. Using UML. Software Engineering with Objects and Components. Addison-Wesley, Más en la ficha de la asignatura 12

7 Tema III Diseño arquitectónico Unidad 14 La transición del análisis al diseño Unidad 15 Introducción al diseño arquitectónico Unidad 16 Modelado arquitectónico con UML Unidad 17 Herramientas de modelado (laboratorio) Unidad 18 Vistas arquitectónicas Unidad 19 Estilos arquitectónicos Unidad 20 Qué es diseño orientado a objetos? (artículo y examen) 13 Transformación de modelos: del análisis al diseño Dos trayectorias típicas: modelo del mundo real ( modelo de análisis en un sentido) análisis de requisitos ( modelo de análisis en otro sentido) modelo de diseño modelo descriptivo concreto del sistema heredado modelo descriptivo abstracto del sistema heredado modelo especificativo abstracto del sistema nuevo modelo especificativo concreto del sistema nuevo Especificación Vista abstracta Vista concreta modelo especificativo abstracto del dominio modelo especificativo concreto del dominio modelo especificativo abstracto del sistema modelo especificativo concreto del sistema Descripción Vista abstracta Vista concreta modelo descriptivo abstracto del dominio modelo descriptivo concreto del dominio modelo descriptivo abstracto del sistema modelo descriptivo concreto del sistema Dominio Sistema 14

8 Transformación de modelos: del análisis al diseño propósito especificación B descripción A C abstracto dominio sistema realidad concreto abstracción 15 Relación lógico-temporal entre el análisis y el diseño Iteración 1 Iteración 2 Iteración 3 Análisis (versión 1) Análisis (versión 2) Diseño (versión 1) Análisis (versión 3) Diseño (versión 2) Implementación (versión 1) 16

9 El diseño arquitectónico en el Estándar ESA ESA software engineering standards (PSS-05-0) Chapter 4. The architectural design phase 4.3. Actividades: modelo físico (estático y dinámico) Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1) Chapter 3. Using Object-Oriented Methods with PSS Modelo físico, reutilización, criterios de calidad del diseño Guide to the software architectural design phase (PSS-05-04) Chapter 2. The architectural design phase 2.3. Construcción del modelo físico (descomposición, NFR, calidad...) 2.4. Especificación del diseño arquitectónico (funciones componentes) 2.7. Revisión de los requisitos del software Chapter 5. The architectural design document 5.1. Introducción: lo que debe ser, lo que no debe ser 5.2. Estilo: claridad, consistencia, modificabilidad Preguntas más frecuentes 17 El diseño detallado en el Estándar ESA ESA software engineering standards (PSS-05-0) Chapter 5. The detailed design and production phase 5.3. Actividades: diseño detallado / no producción Descomponer componentes arquitectónicos en módulos programables 5.4. Salidas: omitir código y manual de usuario Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1) Chapter 3. Using Object-Oriented Methods with PSS Conversión automática modelo código (round-trip engineering) Guide to the software detailed design and production phase (PSS-05-05) Chapter 2. The detailed design and production phase 2.3. Descomposición, diseño defensivo, optimización, etc. Chapter 5. The detailed design and production document 5.1. Introducción: lo que debe ser, lo que no debe ser 5.2. Estilo: claridad, consistencia, modificabilidad 18

10 Introducción al diseño arquitectónico Arquitectura del software analogía con la arquitectura civil: requisitos diseño madurez de la arquitectura del software Cómo lograr una descomposición modular eficaz? alta cohesión y bajo acoplamiento descomposición recursiva diseñar para el mantenimiento reducir la complejidad de las dependencias Criterios para la selección de una arquitectura criterios clásicos otros criterios Reutilización de diseños y componentes 19 Relación entre análisis, arquitectura y diseño detallado 1. Análisis Los vehículos deben poder viajar desde la parte alta a 120 km/h en línea recta y llegar a la parte baja en no más de 3 minutos. 2. Clases de Dominio Vehículo Camino 3. Arquitectura Columna Cable Barandilla vehículo 4. Diseño Detallado Cable Camino Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective Columna 20

11 Estilos arquitectónicos de puentes 21 Arquitectura del software: definiciones Paul Clements 1996 La arquitectura del software es a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. Len Bass 1998 La arquitectura del software de un programa o sistema de computación es la estructura o las estructuras del sistema, que contienen componentes de software, las propiedades externamente visibles de dichos componentes y las relaciones entre ellos. IEEE Std La arquitectura del software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y con el entorno, y los principios que orientan su diseño y evolución. 22

12 Cohesión y acoplamiento 1 componente componente Alta cohesión Puente 5 6 Bajo acoplamiento Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 23 Cómo lograr una buena descomposición modular A B C A D E D E F B C F Mal Bien Cómo acertar de antemano? Estilos arquitectónicos 24

13 Descomposición modular recursiva: 7±2 25 Criterios para la selección de una arquitectura Criterios clásicos: Extensibilidad Modificabilidad Simplicidad Eficiencia Otros criterios: Reuso Escalabilidad Coste Requisitos no funcionales 26

14 Diseños reutilizables Reutilización Estilos arquitectónicos: formas típicas de sistemas Marcos (frameworks): aplicaciones o sistemas incompletos Líneas de productos: generalizaciones de aplicaciones exitosas Patrones de diseño: heurísticas para solución con formas típicas Componentes reutilizables Dificultades para el reuso Elección de componentes para el reuso Desarrollo para el reuso 27 Descomposición basada en marcos de trabajo Java.awt Window 1 ventanaempleado Capa de marcos Capa de aplicación MiAplicación VentanaDialogo Empleado 28

15 Noción de componente Unidad autónoma, reemplazable y reutilizable, habitualmente ejecutable 29 Niveles de descomposición modular (UML 2.x) Nivel 1 Subsistema Nivel 2 Componente (...) Nivel N-1 Componente Nivel N Clase (UML 1.x) (UML 1.x) 30

16 Noción de dependencia <<component>> A Dependencia A C: A requiere la presencia de C Los cambios de C pueden afectar a A <<component>> B <<component>> C E F 31 Noción de interfaz Dos componentes pueden ofrecer la misma interfaz Dos interfaces no necesariamente disjuntas 32

17 Representación de interfaces: abreviada y completa Novedad en UML2 33 Cómo instanciar las interfaces de un componente (1) package GestiónEmpleados; public interface iempleado { public modificar( ) { ; public class EmpleadoFijo implements iempleado { public modificar( ) { ; public class EmpleadoTemporal implements iempleado { public modificar( ) { ; ==================== class Departamento { iempleado e = new EmpleadoFijo( ); e.modificar( ); El componente proporciona sólo una interfaz, el tipo abstracto de datos. Es necesario que la clase cliente (Departamento) conozca las clases concretas EmpleadoFijo, etc.: estas clases deben ser públicas. Nada le impide usarlas sólo para invocar los constructores (salvo el buen estilo del programador). La dependencia es potencialmente peligrosa. 34

18 Cómo instanciar las interfaces de un componente (2) package GestiónEmpleados; public interface igestorempleados { public int crearempleado( ); // el gestor debe mantener algún tipo de lista public modificarempleado(int e); class EmpleadoFijo { // no visible desde fuera, idem EmpleadoTemporal public class GestorEmpleados implements igestorempleados { public int crearempleado( ) { ; // usa new EmpleadoFijo( ) public modificarempleado (int e) { ; // usa EmpleadoFijo.modificar( ) ==================== class Departamento { int e = ge.crearempleado ( ); // se supone que existe GestorEmpleados ge ge.modificarempleado(e); El componente proporciona sólo una interfaz, el gestor. GestorEmpleados no puede recibir ni devolver valores de tipo EmpleadoFijo, EmpleadoTemporal, etc. Es necesario un mecanismo de traducción de los identificadores públicos a las instancias de EmpleadoFijo, etc. (una lista interna). La clase cliente sólo usa el gestor y los identificadores públicos. 35 Cómo instanciar las interfaces de un componente (3) package GestiónEmpleados; public interface iempleado { public modificar( ) { ; El componente proporciona dos interfaces, el tipo abstracto de datos y el gestor. public interface igestorempleados { public iempleado crearempleado( ); // el gestor debe mantener algún tipo de lista public modificarempleado(iempleado e); ==================== class Departamento { iempleado e = ge.crearempleado ( ); // se supone que existe GestorEmpleados ge e.modificar( ); La clase cliente no puede usar el constructor directamente, pero sí el tipo abstracto en el resto de operaciones. 36

19 Cómo instanciar las interfaces de un componente (4) Caso 3 (parámetros iempleado) Caso 1 Caso 2 (parámetros int) 37 Interfaces proporcionadas y requeridas proporciona, realiza requiere, usa 38

20 Cableado de componentes ball and socket cableado independiente cableado en árbol cableado con dependencia 39 Anidamiento de componentes puerto delegación El conjunto de interfaces de un puerto debe ser consistente 40

21 Diagrama de despliegue dispositivo hardware nodo ruta de comunicación entorno de ejecución software 41 Herramientas de modelado UML: Altova UModel Objetivo de las herramientas CASE Otras herramientas alternativas Altova UModel Instalación Licencias Requisitos HW y SW Diagramas de Componentes y Clases Diagramas de Despliegue Ejercicios en clase: transparencias

22 Objetivo de las herramientas CASE Mejorar la productividad, el tiempo y coste de desarrollo. Mejorar la planificación de un proyecto. Automatizar desarrollo del software, documentación, generación de código, pruebas de errores y gestión del proyecto. Ayuda a la reutilización del software. Gestión global en todas las fases de desarrollo de software con una misma herramienta. Facilitar el uso de las distintas metodologías propias de la ingeniería del software. 43 Otras herramientas alternativas Visio Telelogic Tau swreuser Star UML 44

23 Altova Umodel: Instalación Ir a: Download UModel 2008 Enterprise Edition Setup now Seleccionar el botón Ejecutar : Seguir con la instalación, presionando el botón Next cuando sea conveniente, y por último, el botón Install. Cuando se encuentre Altova UModel instalado completamente en el ordenador, se debe pedir una licencia de evaluación (Request a FREE Evaluation Key). 45 Licencias y requisitos HW y SW Licencias Solicitud de licencia por 30 días. Instalar el software en un solo ordenador del equipo de prácticas cada vez, para asegurar la disponibilidad del software a lo largo del cuatrimestre. Software disponible en las aulas. Hardware: 133 MHz, Pentium-compatible CPU, o superior. 64 megabytes (MB) de memoria RAM como mínimo 2 GB de disco duro con un mínimo de 650 MB de espacio libre. Software: UModel es una aplicación Windows de 32-bit que se puede instalar en Windows 2000 / 2003, Windows XP y Windows Vista. Se pueden descargar módulos de integración con Visual Studio.NET (Enterprise Edition) y Eclipse (Enterprise Edition). 46

24 Aspecto de la herramienta 47 Diagrama de Componentes Diagramas importantes para IS2 Diagrama de Clases Diagrama de Despliegue 48

25 El modelo de 4+1 vistas arquitectónicas Vista lógica (conceptual) Vista de desarrollo (implementación) Vista de casos de uso Vista de proceso (ejecución) Vista física (despliegue) Ingeniería del Software I Ingeniería del Software II 49 Características de cada vista en el modelo 4+1 Vista Lógica (conceptual) Proceso (ejecución) Desarrollo (implementación) Física (despliegue) Aspecto Modelo de información Concurrencia y sincronización Organización del software en el entorno de desarrollo Correspondencia software-hardware Stakeholders Usuarios finales Integradores del sistema Programadores Ingenieros de sistemas Requisitos Funcionales Rendimiento Disponibilidad Fiabilidad Concurrencia Distribución Seguridad Gestión del software Reuso Portabilidad Mantenibilidad Restricciones impuestas por la plataforma o el lenguaje Rendimiento Disponibilidad Fiabilidad Escalabilidad Topología Comunicaciones Notación Clases y asociaciones Procesos y comunicaciones Componentes y relaciones de uso Nodos y rutas de comunicación 50

26 Relaciones entre las cuatro vistas minimizar dependencias nuevas clases de diseño Vista lógica (conceptual) Vista de desarrollo (implementación)? identificar clases activas Vista de proceso (ejecución) Vista física (despliegue) requisitos no funcionales 51 Vista de casos de uso 52

27 Vista lógica (conceptual) 53 Vista de proceso (ejecución) 54

28 Vista de desarrollo (implementación) 55 Vista física (despliegue) 56

29 Estilos arquitectónicos (Shaw & Garlan) Flujo de datos Tuberías y filtros Secuencial por lotes Componentes independientes Sistemas cliente-servidor Procesos paralelos Sistemas de eventos Máquinas virtuales Repositorios Bases de datos Entornos de desarrollo Editores Sistemas hipertexto Arquitectura en capas Arquitectura MVC / RUP Arquitectura en cuatro capas Arquitectura en tres escalones 57 Arquitectura de flujo de datos: DFDs - nº de cajeros - velocidad media de cada cajero - tiempo medio de llegada entre clientes tiempo medio entre llegadas de clientes tiempo de llegada de clientes crear banco crear cliente lista de cajeros libres cola de clientes cajero finaliza con cliente asignar cliente a cajero lista de clientes / cajeros log de estadísticas Adaptado de W. Haythorn, What Is Object-Oriented Design? informar 58

30 Arquitectura de tuberías y filtros stream > pipe filter filter filter filter filter filter pipe < stream Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 59 Arquitectura cliente-servidor Client 1 Client 2 Client 3 Client 4 Internet Catalogue server Video server Picture server Web server Library catalogue Film clip files Digitised photographs Film and photo info Adaptado de I. Sommerville, Software Engineering 60

31 Arquitectura de procesos paralelos Customer: customer n Customer: customer n+1 withdraw create deposit Session: session m Session: session k create retrieve retrieve Account: customer n checking Account: customer n+1 saving Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 61 Arquitectura de sistema de eventos Sub-system 1 Sub-system 2 Sub-system 3 Sub-system 4 Event and message handler Adaptado de I. Sommerville, Software Engineering 62

32 Arquitectura de máquina virtual assemble { { 260MHz & 64MB and { { 400MHz & 128MB and { 260MHz & 32MB 400Mhz & 128MB 260Mhz & 64MB Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 260Mhz & 32MB 63 Arquitectura de repositorio Design editor Code generator Design translator Project repository Program editor Design analyser Report generator Adaptado de I. Sommerville, Software Engineering 64

33 Arquitectura en capas: modelo OSI 7 Application Application 6 Presentation Presentation 5 Session Session 4 Transport Transport 3 Network Network Network 2 Data link Data link Data link 1 Physical Physical Physical Communications medium Adaptado de I. Sommerville, Software Engineering 65 Arquitectura en capas: juegos interactivos Ejecución de movimientos Lanzamiento de Dado Definición de reglas del juego Jugador Selección de Ficha Movimiento Avance y Captura Turno Representación gráfica Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 66

34 Arquitectura modelo-vista-controlador (original) Acciones del usuario Controlador Modificaciones en la vista Vista Información al usuario C V M Consultas y modificaciones en el modelo Modelo Consultas al modelo Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective 67 Arquitectura modelo-vista-controlador (moderna) Comunicación con el usuario Vista Comportamientos complejos Controlador V C M Consultas en el modelo Modelo Consultas y modificaciones en el modelo C V M Modelo-Vista-Controlador original 68

35 Arquitectura en Cuatro Capas 69 Arquitectura en Tres Escalones 70

36 Tema IV Diseño detallado Unidad 21 Introducción al diseño detallado: diseño por contratos Unidad 22 Diseño detallado con UML (1): polimorfismo Unidad 23 Diseño detallado con UML (2): interacciones Unidad 24 Diseño detallado con UML (3): máquinas de estados Unidad 25 Patrones de diseño (1) Unidad 26 Patrones de diseño (2) Unidad 27 Implementación de asociaciones UML en Java (artículo y ex.) Unidad 28 Herencia múltiple 71 Introducción al diseño detallado: diseño por contratos Qué es el diseño detallado Nivel de detalle en el modelo de diseño Diseño por contratos Noción de contrato Especificación formal del contrato: sintaxis y semántica Uso de pre- y post- condiciones Invariantes de clase Contratos y herencia: subcontratación Especificación de algoritmos Diagramas de actividad Pseudocódigo 72

37 Diseño por contratos: PPCs e invariantes PPCs de operación CuentaCorriente.meterDinero(cantidad: Moneda) Pre: Post: saldo = saldo + cantidad CuentaCorriente.sacarDinero(cantidad: Moneda) Pre: saldo cantidad 0 Post: saldo = saldo cantidad CuentaCorriente saldo meterdinero(cantidad) sacardinero(cantidad) Invariantes de clase CuentaCorriente: saldo 0 73 Diseño por contratos: subcontratación PPC s de operación CuentaCorriente.sacarDinero(cantidad: Moneda) Pre: saldo cantidad 0 Post: saldo = saldo cantidad PPC s de operación redefinida en la subclase CuentaCredito.sacarDinero(cantidad: Moneda) Pre: saldo + credito cantidad 0 Post: saldo = saldo cantidad Pre: menos restrictiva, o igual Post: más restrictiva, o igual Invariantes de clase (más restrictivo, o igual) CuentaCorriente: saldo 0 CuentaCredito: (credito 0) AND (saldo + credito 0) CuentaCorriente saldo sacardinero(cantidad) CuentaCredito credito sacardinero(cantidad) Es correcta esta generalización? 74

38 Diseño por contratos: uso correcto de jerarquías CaminoOblicuo.distancia.post d = ( x y x1) + ( y2 1) CaminoEsquinado.distancia.post d = ( x2 x1) + ( y2 y1) (x 2, y 2 ) (x 1, y 1 ) Cuál sería correcta? CaminoOblicuo origen: Punto destino: Punto distancia( ): Float CaminoEsquinado origen: Punto destino: Punto distancia( ): Float 75 Especificación de algoritmos Bisiesto (x) = m4(x) AND ( (NOT m100(x) OR (m100(x) AND m400(x)) ) = m4(x) AND (NOT m100(x) OR m400(x)) m4 [no] [sí] m100 [no] [sí] NoBisiesto (x) = NOT m4(x) OR (m100(x) AND NOT m400(x)) m400 [no] [sí] no bisiesto bisiesto 76

39 Diseño detallado con UML (1): polimorfismo Asignación polimórfica variables y argumentos Invocación polimórfica de operaciones interfaz y comportamiento Redefinición polimórfica de operaciones sobreescritura y sobrecarga Signatura de la operación distinción de operaciones por su signatura Visibilidad Interfaces Clases y operaciones abstractas Generalización vs. Realización 77 Asignación polimórfica de variables public class CuentaCorriente { public class CuentaCredito extends CuentaCorriente { CuentaCorriente titularde Persona public class Persona { private CuentaCorriente titularde; public asignarcuenta (CuentaCorriente cc) { titularde = cc; CuentaCredito Variable polimórfica public class Main { public static void main(string[] args) { Persona juan = new Persona(); CuentaCorriente ccr = new CuentaCredito(); juan.asignarcuenta(ccr); : CuentaCredito juan: Persona Argumento polimórfico 78

40 Invocación polimórfica de operaciones public class CuentaCorriente { public Moneda saldo; public void sacardinero (Moneda cantidad) { CuentaCorriente saldo sacardinero(cantidad) titularde Persona public class CuentaCredito extends CuentaCorriente { public Moneda credito; public void sacardinero (Moneda cantidad) { public class Persona { private CuentaCorriente titularde; public asignarcuenta (CuentaCorriente cc) { titularde = cc; public sacardinero (Moneda cantidad) { titularde.sacardinero(cantidad); public class Main { public static void main(string[] args) { Persona juan = new Persona(); CuentaCorriente ccr = new CuentaCredito(); juan.asignarcuenta(ccr); juan.sacardinero(100); CuentaCredito credito sacardinero(cantidad) Asignación polimórfica Invocación polimórfica : CuentaCredito juan: Persona sacardinero(100) 79 Redefinición polimórfica de operaciones Polimorfismo: capacidad de ejecutar distintos comportamientos en respuesta al mismo mensaje (= invocación de operación). Una operación polimórfica es aquélla que tiene muchas implementaciones. No confundir sobreescritura con sobrecarga de operaciones: sobreescribir: redefinir en otra clase el comportamiento de la misma operación el método se selecciona en tiempo de ejecución sobrecargar: reutilizar el nombre de operación, pero con distintos parámetros el método se selecciona en tiempo de compilación, no es polimorfismo sobreescritura (polimorfismo) CuentaCorriente saldo sacardinero(cantidad) sacardinero( ) CuentaCredito credito sacardinero(cantidad) sobrecarga 80

41 Signatura de la operación Define los elementos que identifican unívocamente una operación: nombre de operación, número (orden) y tipo de los parámetros. Una clase no puede tener dos operaciones con la misma signatura o firma. Los nombres de los parámetros no pertenecen a la signatura. Pertenece el tipo del valor de retorno a la signatura? Depende... Según el estándar de UML, sí. Pero el tipo del retorno no sirve para distinguir qué operación hay que ejecutar. No se puede usar para sobrecargar operaciones p1 : Punto posiciónx = 3 posicióny = -5 «instance of» Punto posiciónx: Coordenada posicióny: Coordenada obtenerposición( ): CoordenadasPolares obtenerposición( ): CoordenadasCartesianas c := obtenerposición ( ) Qué operación se invoca? Depende del tipo de c... Clase mal definida 81 Distinción de operaciones por su signatura En función del nombre de la operación, su signatura, y su clase, puede ser: una operación distinta, una operación sobrecargada, una operación sobreescrita, o un error (detectable por el compilador). Nombre Signatura Clase Resultado distinto distinta misma sobrecarga distinta subclase sobrecarga igual misma error igual subclase sobreescritura saldo CuentaCorriente sacardinero(cantidad: Moneda) sacardinero(cantidad: MonedaEuropea) credito CuentaCredito sacardinero(cantidad: Moneda) sacardinero(cantidad: MonedaEuropea) 82

42 Visibilidad Niveles de visibilidad (diferentes en cada lenguaje): + public: visible para todas las clases (opción por defecto para operaciones). ~ package: visible para todas las clases que estén en el mismo paquete. # protected: visible para las subclases. private: visible sólo para la clase (opción por defecto para atributos). UML Java VB.NET (C#) Public Public Public Package Protected friendly Protected Protected-Friend Friend (Internal) Protected Private Private Private 83 Visibilidad privada entre objetos de la misma clase La visibilidad es una propiedad de las clases, no de los objetos: un objeto puede acceder a operaciones y atributos privados de otros objetos de la misma clase. public class Elemento { private String nombre; private void escribir() { System.out.println(this.nombre); class Main { public static void main(string[] args) { Elemento e1=new Elemento( e1 ); Elemento e2=new Elemento( e2 ); e1.prueba(e2); public void prueba(elemento p) { p.nombre= e3 ; p.escribir(); public Elemento(String n) { nombre=n; Ejecución y resultado: C:\java Main e3 A través de la operación pública prueba, el objeto e1 manipula el atributo privado nombre de e2, e invoca su operación privada escribir. Cuál es el problema? En realidad, ninguno, si se entiende bien qué significa la visibilidad privada. 84

43 Visibilidad privada entre clase y superclase La visibilidad es una propiedad de las clases, no de los objetos: un objeto no puede acceder a sus operaciones y atributos privados definidos en una superclase. public class Rectángulo { private int base, altura; private boolean invariante ( ) { return (base > 0) && (altura > 0) public int area() { return base * altura public class Cuadrado extends Rectángulo { private boolean invariante ( ) { return (base > 0) && (base = altura) Siendo Cuadrado subclase de Rectángulo, las instancias de la clase Cuadrado tienen una base y una altura, y por tanto parece que deberían poder acceder a ellas. Compilación y resultado: La clase Cuadrado no puede ver los atributos base y altura: error de compilación. Aun resolviendo este error, la clase Cuadrado no redefine correctamente la operación invariante, ya que no puede verla. Sería considerada una operación distinta, no una operación redefinida. No es detectado por el compilador, lo cual es grave. En cambio, corrigiendo la visibilidad de los atributos base y altura, la operación area sí quedaría bien redefinida. public int area () { return base * base Los objetos de la clase Cuadrado tienen esos atributos, pero no son accesibles desde esta clase. Cuál es el problema? En realidad, ninguno, si se entiende bien qué significa la visibilidad privada. Solución: usar visibilidad protected. 85 Clases y operaciones abstractas Operación abstracta: sólo se especifica la signatura, no la implementación. Una clase con una o varias operaciones abstractas está incompleta: no puede tener instancias directas. Tanto las operaciones abstractas como las concretas pueden ser redefinidas (polimórficas). Figura posición dibujar( ) Clase abstracta: está incompleta, no puede tener instancias directas. Puede tener instancias indirectas a través de sus subclases concretas. Una clase concreta... no puede tener operaciones abstractas. debe proporcinar implementaciones para todas las operaciones abstractas heredadas. Círculo radio dibujar( ) Rectángulo base altura dibujar( ) Cuadrado {base=altura dibujar( ) 86

44 Interfaces Encapsulamiento: separación de interfaz e implementación en una clase: una clase puede realizar una o varias interfaces. una interfaz puede ser realizada por una o varias clases. Interfaz: conjunto de operaciones que ofrecen un servicio coherente: no contiene la implementación de las operaciones (métodos). una interfaz no puede tener atributos ni asociaciones navegables (esta restricción ha desaparecido en UML 2.0). análoga a una clase abstracta con todas sus operaciones abstractas: no puede tener instancias directas. distinta de interfaz natural : conjunto de operaciones públicas de una clase (accesibles a través de cualquier asociación navegable hacia la clase). Impresora Imprimible Impresora «interface» Imprimible Documento Notaciones para uso y realización de interfaces Documento imprimir( ) 87 Generalización vs. Realización La realización puede entenderse como una generalización débil : se hereda la interfaz, pero no la implementación: reduce la dependencia. disminuye la reutilización. alternativa a la generalización múltiple, no soportada por muchos lenguajes. Las interfaces son elementos generalizables: jerarquías mixtas de interfaces y clases. Criterio de diseño: comprometerse sólo con la interfaz. declarar el tipo de las variables y parámetros de operaciones como interfaces, no como clases. servirá cualquier instancia compatible con la interfaz. Ejemplo: Figura f = new Cuadrado ( ); f.imprimir Círculo «interface» Imprimible «interface» Figura Rectángulo Cuadrado 88

45 Diseño detallado con UML (2): interacciones Diagramas de interacción: colaboración y secuencia Mensajes y operaciones Foco de control Números de secuencia Mensajes síncronos y asíncronos Flujo de información y flujo de control Hilos de ejecución concurrente Tipos de relaciones entre clases en UML Dependencias inducidas por las relaciones entre clases Tipos de enlaces de comunicación: estructurales y contextuales Correspondencia diagramas de interacción-diagramas de clases Creación y destrución de objetos y enlaces Ley de Demetra (Law of Demeter): No hable con desconocidos 89 Modelado dinámico: diagramas de interacción Transferencia de dinero entre dos cuentas: - sacar dinero de una cuenta, y - meter el dinero en la otra cuenta. Diagrama de secuencia banco : Banco cuenta1 : Cuenta cuenta2 : Cuenta Diagrama de colaboración sacardinero( ) cuenta1 : Cuenta meterdinero( ) 1: sacardinero( ) Mensaje banco : Banco cuenta2 : Cuenta Objeto 2: meterdinero( ) 90

46 Quién activa la secuencia de mensajes? El iniciador puede ser... Un objeto del sistema, que solicita un servicio de otra parte del sistema. Un actor externo al sistema (instancia de actor). En análisis se omiten detalles de interfaz de usuario por simplicidad. banco : Banco origen : Cuenta destino : Cuenta Ana : Cliente emitirtransferencia( ) sacardinero( ) meterdinero( ) El sistema entero se puede representar como un único objeto, en un diagrama con sólo dos líneas de vida que representa la comunicación actor-sistema. 91 Mensajes y operaciones Un mensaje es una petición de servicio al objeto receptor: Se corresponde (típicamente) con la invocación de una operación. La operación debe estar definida en la (super)clase del objeto receptor. Puede cambiar el estado del objeto receptor. Argumentos y valores de retorno. Invocación local de operaciones (autodelegación). b : Banco cc : CuentaCrédito CuentaCorriente saldo obtenersaldo( ) ok := esdisponible(cantidad) ok := (cantidad <= c + s) c := obtenercredito( ) CuentaCrédito credito s := obtenersaldo( ) obtenercredito( ) esdisponible(cantidad): boolean 92

47 Diagramas de secuencia: foco de control El foco de control muestra el periodo de tiempo durante el cual un objeto está ejecutando una operación como respuesta a un mensaje recibido: Retorno implícito al final (puede hacerse explícito): no es un nuevo mensaje, y por tanto debe ser anónimo (aunque en algunas herramientas no sea así). Anidamiento de ejecuciones (sombreado opcional): mecanismo de delegación. banco : Banco origen : Cuenta destino : Cuenta Ana : Cliente emitirtransferencia( ) sacardinero( ) meterdinero( ) 93 Diagramas de colaboración: números de secuencia Forma alternativa de expresar la secuencia de mensajes y el anidamiento. Esquema de numeración anidada: El número del mensaje recibido se usa como prefijo para los mensajes enviados. Activador: mensaje que invoca la operación desde la que se envían otros. Predecesor: mensajes anteriores enviados en la misma ejecución. banco : Banco origen : Cuenta destino : Cuenta Ana : Cliente emitirtransferencia( ) sacardinero( ) origen : Cuenta meterdinero( ) 1.1: sacardinero( ) Ana : Cliente 1: emitirtransferencia (origen, destino, cantidad) banco : Banco 1.2: meterdinero( ) destino : Cuenta 94

48 Mensajes síncronos y asíncronos Invocación síncrona de operación: El mensaje incluye el retorno (implícito o explícito), el emisor queda bloqueado. Comunicación bidireccional con un único mensaje. Envío asíncrono de señal: El mensaje no incluye el retorno, el emisor no queda bloqueado (concurrencia). Puede tener argumentos, pero no valor de retorno. La comunicación bidireccional requiere un nuevo mensaje de respuesta. El mensaje lleva el nombre de la señal (no necesariamente un verbo). banco1 : Banco banco2 : Banco banco3 : Banco transferenciasolicitada(número, datos) transferenciasolicitada(número, datos) transferenciaaceptada(número) transferenciadenegada(número) Señales que aceptan los objetos de una clase Banco «signal» transferenciasolicitada( ) «signal» transferenciaaceptada( ) «signal» transferenciadenegada( ) 95 Hilos de ejecución concurrente Un objeto activo posee un hilo de ejecución propio. Clases y objetos activos se representan con doble trazo vertical a los lados. Quién puede enviar un mensaje? Un objeto activo. Un objeto pasivo que tenga el foco de control. Quién puede recibir un mensaje asíncrono? Sólo los objetos activos. Un mensaje síncrono desvía el hilo de ejecución al objeto delegado. Un mensaje asíncrono puede comunicar dos hilos de ejecución distintos, o desdoblar un hilo existente. a b c d e p q r s 96

49 Tipos de relaciones entre clases en UML Dependencia Asociación Generalización El elemento dependiente requiere la presencia del elemento independiente. Los cambios en el elemento independiente pueden afectar al elemento dependiente. Especificación de un conjunto de conexiones entre instancias. Representan la estructura y posibilidades de comunicación del sistema. Relación entre un elemento general y un elemento específico. El elemento específico puede añadir información y debe ser consistente con el elemento general. Realización Relación donde un elemento realiza o implementa la especificación dada por otro elemento. 97 Dependencias inducidas por las relaciones entre clases public class FiguraColoreada extends Figura { private Color micolor; public void desplazar (Vector desplazamiento) { Posicion p = new Posicion ( ); Figura generalización FiguraColoreada Color Figura asociación Vector Posicion FiguraColoreada 1 micolor Color parámetro variable local (asociaciones contextuales) 98

50 Enlaces de comunicación estructurales y contextuales El envío de mensajes tiene lugar en un contexto determinado, normalmente la ejecución de una operación. El contexto delimita los destinos válidos. A quién puedo enviar un mensaje? Mis conocidos son... Un objeto conectado mediante un enlace navegable (instancia de asociación). Un objeto recibido como parámetro en esta activación («parameter»). Un objeto creado localmente en esta activación, o variable local («local»). Yo mismo, el emisor del mensaje («self»). Por cierto, cómo se nombran los objetos? - nombre arbitrario - valor identificador - nombre de parámetro - nombre de variable origen : Cuenta «parameter» «self» 1.1.1: ok := esdisponible(cantidad) 1.1: sacardinero(cantidad) Ana : Cliente 1: emitirtransferencia (origen, destino, cantidad) «parameter» banco : Banco destino : Cuenta 1.2: meterdinero(cantidad) 99 Diagramas de interacción vs. Diagramas de clases Un diagramas de clases especifica la estructura del sistema, que sirve de base para su comportamiento: asociaciones, operaciones. Un diagrama de interacción ilustra un comportamiento posible del sistema (es decir, ejemplifica, no especifica). Las diversas interacciones ayudan a detectar las clases, asociaciones y operaciones requeridas: reglas de coherencia. Diagramas de interacción (modelo dinámico) Objeto Enlace Mensaje Diagramas de clases (modelo estático) Instancia de clase Instancia de asociación (excepto enlaces contextuales) Operación o señal visible en la (super)clase receptora 100

51 Creación y destrucción de objetos banco : Banco cuenta1 : CuentaCorriente Cancelar una cuenta y transferir el saldo a una nueva de otro tipo s := obtenersaldo( ) abrircuenta(s) cerrarcuenta( ) cuenta2 : CuentaCrédito banco : Banco 2: abrircuenta(s) 1: s := obtenersaldo( ) 3: cerrarcuenta( ) cuenta2 : CuentaCrédito {new cuenta1 : CuentaCorriente {destroyed {transient = {new + {destroyed 101 Creación y destrucción de enlaces Implícita en la creación/destrucción de un objeto: El enlace creado puede ser estructural o contextual («local»). Creación de un enlace con un objeto existente: El enlace contextual «parameter» se transforma en un nuevo enlace estructural. Si asociación unidireccional: sólo el objeto origen puede crear o destruir enlaces. Destrucción del enlace sin destruir el objeto enlazado. banco : Banco 1: asignartitular(titular) 2: desasignartitular(titular) cuenta1 : Cuenta {new titular : Titular {destroyed cuenta2 : Cuenta 102

52 Ley de Demetra: No hable con desconocidos Si dos objetos pueden comunicarse, entonces el código de sus respectivas clases debe manifestarlo claramente (dependencias explícitas). El objeto x, en respuesta al mensaje m(a, b, c...), puede enviar mensajes sólo a: El objeto x («self»). Los argumento del mensaje m: a, b, c... («parameter»). Objetos creados por x en el curso de su respuesta a m («local»). Objetos directamente enlazados con x («association»). Formulada en términos de UML 1.x: Todo enlace es instancia de una asociación (estructural / contextual). Toda asociación debe ser declarada (dependencia explícita). La Ley de Demetra no es una regla absoluta. 103 Qué prohíbe la Ley de Demetra? public class CuentaCorriente { private Moneda saldo; public Moneda obtenersaldo() { public class Persona { private CuentaCorriente titularde; public asignarcuenta (CuentaCorriente cc) { titularde = cc; public void mostrarsaldoactual() { titularde.obtenersaldo().escribir(); public class Main { public static void main(string[] args) { Persona juan = new Persona(); CuentaCorriente cc = new CuentaCorriente(); juan.asignarcuenta(cc); juan.mostrarsaldoactual(); Cuál es el problema? La clase Persona tiene una dependencia implícita, poco clara, con la clase Moneda. Solución: en lugar de enviar un mensaje al objeto devuelto por otro mensaje, declarar una variable «local», haciendo explícita la dependencia. public class Persona { private CuentaCorriente titularde; public asignarcuenta (CuentaCorriente cc) { titularde = cc; public void mostrarsaldoactual() { Moneda saldo = titularde.obtenersaldo(); saldo.escribir(); 104

53 Diseño detallado con UML (3): máquinas de estados Estados, eventos y transiciones. Estados y transiciones. Eventos y transiciones. Transiciones con guardas. Transiciones con acciones. Estados con acciones y actividades. Correspondencia diagramas de estados-diagramas de clases. Comunicación entre máquinas de estados. Diseño e implementación de máquinas de estados. Secuencia de acciones en un cambio de estado. Aplicación de las máquinas de estados al diseño de interfaces. 105 Máquinas de estados: estados, eventos y transiciones Clase Avión Estado Evento Transición despegar Estacionado Volando aterrizar Pseudoestado inicial retirar colisionar Estado final Los eventos causan las transiciones entre estados. Los eventos de creación y destrucción pueden ser implícitos o explícitos. 106

54 Estados y transiciones Un estado es una situación en la vida de un objeto caracterizada por satisfacer una condición, realizar una acción o esperar un evento. Un estado tiene duración, una transición es instantánea. Cada estado tiene un nombre (sustantivo, participio, gerundio...). El estado de un objeto está relacionado con los valores de sus atributos, los enlaces con otros objetos y las actividades que esté realizando. Estados distintos implican reacciones distintas ante el mismo evento. Persona edad 1..* jubilar Parado Empresa 0..1 contratar Jubilado despedir Clase Persona Trabajando jubilar 107 Eventos y transiciones Un evento representa la ocurrencia de un suceso, dentro o fuera del objeto, que provoca un cambio de estado en el objeto (dispara una transición). La sucesión de eventos marca el camino seguido por el objeto entre los estados. Estados y eventos representan respectivamente intervalos / instantes de tiempo. Es un elemento esencial: toda transición debe tener un y sólo un evento. Tipos de eventos: Evento de llamada: recepción de mensaje síncrono / operación misma notación Evento de señal: recepción de mensaje asícrono / señal Evento de cambio: comprobación continua de una condición lógica / when( ) Evento temporal: tiempo transcurrido desde la entrada en el estado / after( ) Los mensajes recibidos, síncronos o asíncronos, pueden tener parámetros. on Apagado Parado Reproducción off play stop Clase Reproductor after(60 s) when(velocidad < 5 cm/s) 108

55 Transiciones con guardas Una guarda es una condición lógica que es evaluada en el momento de recibir el evento y autoriza o no la transición de estado (guarda tras evento). Si la transición no es autorizada por la guarda, el evento no tiene efecto. Varias transiciones disparadas por un mismo evento pueden estar guardadas por condiciones mutuamente exclusivas. La condición lógica debe ser evaluable (expresión lógica) en el contexto de la clase propietaria (parámetros del evento, atributos y enlaces del objeto, etc.). play[(not haycinta) or atascada] Guardas play[haycinta and (not atascada)] on Apagado Parado Reproducción off stop Clase Reproductor after(60 s) when(velocidad < 5 cm/s) 109 Transiciones con acciones Una acción es un comportamiento que se ejecuta de modo instantáneo (con tiempo de ejecución despreciable) y atómico (no interrumpible). Está asociada a un evento que dispara una transición. Es completada antes de que la transición alcance el nuevo estado. Puede definirse recursivamente como secuencia de acciones. Efectos: En el propio objeto: modificar atributos o enlaces, invocar operaciones locales. En otros objetos: mensajes síncronos (operaciones) o asíncronos (señales). play[(not haycinta) or atascada] play[haycinta and (not atascada)]/altavoz.on on Apagado Parado Reproducción off stop/altavoz.off Acciones Clase Reproductor after(60 s) when(velocidad < 5 cm/s)/altavoz.off 110

56 Estados con acciones y actividades Dentro de un estado pueden ejecutarse dos tipos de comportamientos: Acciones asociadas a eventos puntuales que ocurren dentro de un estado: acción de entrada / entry acción de salida / exit acción por evento interno / evento Actividades asociadas al estado como tal / do una actividad es duradera e interrumpible. puede modificar una condición que genere un evento de cambio. No confundir evento interno con autotransición (sale y entra en el estado). Reproducción entry / altavoz.on exit / altavoz.off do / reproducir Autotransición cambiarvolumen(delta) /vol:= vol + delta Evento interno Reproducción cambiarvolumen(delta) / vol:= vol + delta do / reproducir 111 Diagramas de estados vs. Diagramas de clases Eventos: operaciones o señales de la clase receptora. Guardas y eventos de cambio: valores de atributos (y asociaciones). Acciones: operaciones locales o mensajes enviados a otros objetos. Actividades: operaciones de la clase receptora. Reproductor haycinta atascada velocidad volumen «signal» on( ) «signal» off( ) «signal» play( ) «signal» stop( ) «signal» cambiarvolumen(delta) reproducir( ) 1 altavoz Altavoz on( ) off( ) Mensajes salientes: destinatario(s) designado(s) por el nombre de rol 112

57 Comunicación entre máquinas de estados Elemento «signal» mover( ) levantar( ) sentar( ) 1 siguiente Sentado mover /levantar after(2 s) /sentar; siguiente.mover Levantado 1.2: sentar( ) 2.2: sentar( ) 3.2: sentar( ) 1: mover( ) e1 : Elemento e2 : Elemento e3 : Elemento 2: mover( ) 3: mover( ) 4: mover( ) 1.1: levantar( ) 2.1: levantar( ) 3.1: levantar( ) 113 Diseño e implementación de máquinas de estados Estado implícito. Estado explícito. almacenado en un atributo del objeto. sentencias de control para variar el comportamiento en función del estado. Patrón estado (variante del anterior): asociación con un objeto estado que almacena el estado actual. responde de modo polimórfico a los eventos recibidos (por cada estado hay una subclase con una única instancia en cada momento). Reproductor «signal» on( ) «signal» off( ) «signal» play( ) «signal» stop( ) 1 estado Estado on( ): Estado off( ): Estado play( ): Estado stop( ): Estado Apagado Parado Reproducción 114

58 Secuencia de acciones en un cambio de estado El reproductor recibe la señal on( ). Delega el cambio de estado en el objeto que representa estado actual (Apagado). El objeto estado crea un objeto que representa el nuevo estado (Parado), y lo devuelve como resultado de ejecutar la operación on( ). Se destruye el viejo estado (Apagado). Reproductor «signal» on( ) «signal» off( ) «signal» play( ) «signal» stop( ) Apagado Parado 1 estado Estado on( ): Estado off( ): Estado play( ): Estado stop( ): Estado Reproducción r : Reproductor estado : Apagado o : Oyente on( ) estado := on( ) new( ) nuevo : Parado 115 Aplicación de las máquinas de estados al diseño de interfaces Evitar ventanas superfluas y callejones sin salida. Habilitar en cada momento sólo los botones que realmente pueden ejecutar una acción significativa. Los botones habilitados guían al usuario eficazmente por la aplicación. Un buen diseño hace la navegación mucho más intuitiva. 116

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

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

DISEÑO DE APLICACIONES ORIENTADAS A OBJETOS

DISEÑO DE APLICACIONES ORIENTADAS A OBJETOS ASIGNATURA DE GRADO: DISEÑO DE APLICACIONES ORIENTADAS A OBJETOS Curso 2015/2016 (Código:71022011) 1.PRESENTACIÓN DE LA ASIGNATURA El objetivo de esta guía es orientar al alumno en el estudio de la asignatura.

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

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

UML 2 Iniciación, ejemplos y ejercicios corregidos

UML 2 Iniciación, ejemplos y ejercicios corregidos Ediciones ENI UML 2 Iniciación, ejemplos y ejercicios corregidos (3ª edición) Colección Recursos Informáticos Contenido Contenido 1 Capítulo 1 Introducción 1. Motivaciones de la obra.....................................

Más detalles

Diseño Basado en Componentes. Curso 2008/09

Diseño Basado en Componentes. Curso 2008/09 Tabla de contenidos Diseño Basado en Componentes Técnicas relacionadas con Reutilización Introducción: por qué reutilizar?, qué reutilizar? Técnicas: Ingeniería de dominios Líneas de productos (Product-lines)

Más detalles

TIPOS DE PATRONES. PATRONES DE DISEÑO: Las soluciones probadas para el diseño de software. En estas nos vamos a centrar.

TIPOS DE PATRONES. PATRONES DE DISEÑO: Las soluciones probadas para el diseño de software. En estas nos vamos a centrar. TIPOS DE PATRONES Hoy, podemos encontrar literalmente miles de patrones definidos. Resulta imposible para un programador conocerlos todos, ni mucho menos probarlos o valorarlos. Así que necesitamos una

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

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: ARQUITECTURA DEL SISTEMA DE SOFTWARE NIVELES DE DISEÑO DE LOS SISTEMAS DE SOFTWARE CUALIDADES DE LAS ARQUITECTURAS ESTILOS Y PATRONES - ESTILOS ARQUITECTÓNICO - PATRÓN ARQUITECTÓNICO FRAMEWORK

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

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

IN77J Orientación al Objeto para el e-business. 6. Diseño

IN77J Orientación al Objeto para el e-business. 6. Diseño IN77J Orientación al Objeto para el e-business 6. Diseño Temario 6. Diseño Descomposición Realización de Casos de Uso Taller Patrones de Diseño 2 Descomposición Una de las principales técnicas para abordar

Más detalles

Una Arquitectura para una Herramienta de Patrones de Diseño

Una Arquitectura para una Herramienta de Patrones de Diseño Una Arquitectura para una Herramienta de Patrones de Diseño José Sáez Martínez 1, Jesús García Molina, Pedro J. Jiménez García Departamento de Informática, Lenguajes y Sistemas. Campus de Espinardo C.P.

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

Modelado Estático Avanzado (Generalizaciones) Diseño de Software Avanzado Departamento de Informática

Modelado Estático Avanzado (Generalizaciones) Diseño de Software Avanzado Departamento de Informática Modelado Estático Avanzado (Generalizaciones) Generalización y Clasificación Principio de sustitución: Extensión: todos los objetos de la subclase son también de la superclase. Intensión: la definición

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Patrones de Diseño. Ezequiel Postan. 1 Libro e índice. 2 Introducción

Patrones de Diseño. Ezequiel Postan. 1 Libro e índice. 2 Introducción Patrones de Diseño Ezequiel Postan 1 Libro e índice Gamma, E., Helm, R., Johnson, R., Vlissides, J., Patrones de diseño, Addison-Wesley, 2003. Páginas 2-69: Introducción. Composite. Strategy. Decorator.

Más detalles

Planificaciones. 7510 - Técnicas de Diseño. Docente responsable: PANTALEO GUILLERMO GUSTAVO. 1 de 5

Planificaciones. 7510 - Técnicas de Diseño. Docente responsable: PANTALEO GUILLERMO GUSTAVO. 1 de 5 Planificaciones 7510 - Técnicas de Diseño Docente responsable: PANTALEO GUILLERMO GUSTAVO 1 de 5 OBJETIVOS En este curso se busca introducir a los alumnos en el concepto de diseño de software. Para lograrlo

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje PATRONES DE DISEÑO 1. Generalidades 2. Patrones Gof 2.1. Patrones Creacionales 2.1.1.Fábrica Abstracta 2.1.2.Constructor 2.1.3.Método de Factoría 2.1.4.Prototipo 2.1.5.Singleton 2.2. Patrones Estructurales

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Patrones de Diseño EJERCICIOS

Patrones de Diseño EJERCICIOS EJERCICIOS Ingeniería del Software I Carlos Blanco Universidad de Cantabria Introducción Un patrón es una solución probada que se puede aplicar con éxito a un determinado tipo de problemas que aparecen

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1.

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. 3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. Compartimento del nombre...21 3.2.2.2. Compartimento de la lista

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

UNIVERSIDAD AUTÓNOMA DE YUCATÁN FACULTAD DE MATEMÁTICAS MISIÓN

UNIVERSIDAD AUTÓNOMA DE YUCATÁN FACULTAD DE MATEMÁTICAS MISIÓN UNIVERSIDAD AUTÓNOMA DE YUCATÁN FACULTAD DE MATEMÁTICAS MISIÓN Formar profesionales altamente capacitados, desarrollar investigación y realizar actividades de extensión, en Matemáticas y Computación, así

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Curso de Java POO: Programación orientada a objetos

Curso de Java POO: Programación orientada a objetos Curso de Java POO: Programación orientada a objetos Luis Guerra Velasco Curso INEM 02830. Programación en Java Marzo 2010 Índice 1 Introducción a la POO 2 Herencia y polimorfismo 3 Empaquetado de proyectos

Más detalles

CLASE 10: MÁS PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

CLASE 10: MÁS PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez CLASE 10: MÁS PATRONES Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez Polimorfismo Problema: Cómo manejar las alternativas basadas en el tipo? Cómo crear componentes conectables?

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

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

Í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

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

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Capítulo 4 Patrones y Patrones de Diseño (ii)

Capítulo 4 Patrones y Patrones de Diseño (ii) Capítulo 4 Patrones y Patrones de Diseño (ii) Orientado a Objetos Ingeniería Informática Ingeniería Técnica de Informática de Sistemas y Gestión Optativa (6 créditos) http://www.info-ab.uclm.es/asignaturas/42579

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

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

Escuela Técnica Superior de Ingeniería. Informática. Grado en Ingeniería Informática

Escuela Técnica Superior de Ingeniería. Informática. Grado en Ingeniería Informática Escuela Técnica Superior de Ingeniería Informática Grado en Ingeniería Informática GUÍA DOCENTE DE LA ASIGNATURA: (Diseño Arquitectónico y Patrones) Curso Académico 2013/2014 Fecha: 24/05/2013 MODELO GUIA

Más detalles

Qué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura

Más detalles

FORMACIÓN Principios de la programación orientada a objetos

FORMACIÓN Principios de la programación orientada a objetos FORMACIÓN Principios de la programación orientada a objetos En un mercado laboral en constante evolución, la formación continua de los profesionales debe ser una de sus prioridades. En Galejobs somos conscientes

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación.

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación. Departamento de Informática Universidad de Valladolid Programación III.I.T.I. de Sistemas Patrones 1 Contenidos Programación III.I.T.I. de Sistemas Patrones de diseño Patrones de diseño Introducción Conceptos

Más detalles

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

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

ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA:

ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA: UNIDAD 04: PATRONES DE DISEÑO WEB. ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA: Técnico en Ingeniería en Sistemas y

Más detalles

PROGRAMA DE CURSO DE FORMACIÓN PROFESIONAL OCUPACIONAL

PROGRAMA DE CURSO DE FORMACIÓN PROFESIONAL OCUPACIONAL MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES PROGRAMA DE CURSO DE FORMACIÓN PROFESIONAL OCUPACIONAL Programador de lenguajes orientados a objetos DATOS GENERALES DEL CURSO 1. Familia Profesional: INFORMÁTICA

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

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

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

Introducción a la Programación de Videojuegos y Gráficos

Introducción a la Programación de Videojuegos y Gráficos Introducción a la Programación de Videojuegos y Gráficos GRADO EN INGENIERÍA INFORMÁTICA CURSO 2012/2013 T2: ARQUITECTURA Y LÓGICA DE VIDEOJUEGO 2.1. Ingeniería del software aplicada a videojuegos (paradigmas

Más detalles

Tema X: Introducción al Paradigma Orientado. a Objetos. Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión. www.kybele.urjc.

Tema X: Introducción al Paradigma Orientado. a Objetos. Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión. www.kybele.urjc. Tema X: Introducción al Paradigma Orientado Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión a Objetos Índice Introducción Elementos Clases y Objetos Mensajes y Métodos Atributos y Estado

Más detalles

Arquitectura de Software

Arquitectura de Software Arquitectura de Software (Estilos Arquitectónicos) Universidad de los Andes Demián Gutierrez Mayo 2011 1 Diseño Arquitectónico Diseño Arquitectónico Arquitectura del Software Estilos Arquitectónicos Frameworks

Más detalles

Introducción. Herencia y Polimorfismo. Ejemplos (I) Ejemplos (II) Control de Acceso. Herencia

Introducción. Herencia y Polimorfismo. Ejemplos (I) Ejemplos (II) Control de Acceso. Herencia Introducción Herencia y Polimorfismo Se pueden definir jerarquías de clases, con clases generales que definen el comportamiento común a unos objetos y clases específicas que sólo añaden o redefinen el

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

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

Patrones de diseño en Java Los 23 modelos de diseño: descripción y soluciones ilustradas en UML 2 y Java

Patrones de diseño en Java Los 23 modelos de diseño: descripción y soluciones ilustradas en UML 2 y Java Introducción a los patrones de diseño 1. Design patterns o patrones de diseño 15 2. Descripción de los patrones de diseño 17 3. Catálogo de patrones de diseño 18 4. Cómo escoger y utilizar un patrón de

Más detalles

Programación Avanzada para Sistemas de Telecomunicación. Objetos y clases. J.C. Cruellas. Objetos y clases

Programación Avanzada para Sistemas de Telecomunicación. Objetos y clases. J.C. Cruellas. Objetos y clases Programación Avanzada para Sistemas de Telecomunicación Objetos y clases Juan Carlos Cruellas cruellas@ac.upc.es Objetos y clases Concepto de objeto. Concepto de clase. Clases, objetos y programas. Clases

Más detalles

Tema III. DISEÑO ARQUITECTÓNICO (diseño de alto nivel) 14. Presentación / La transición del análisis al diseño

Tema III. DISEÑO ARQUITECTÓNICO (diseño de alto nivel) 14. Presentación / La transición del análisis al diseño Ingeniería del Software 2 Curso 2009-2010 29 Tema III. DISEÑO ARQUITECTÓNICO (diseño de alto nivel) 14. Presentación / La transición del análisis al diseño Presentación de IS2 Profesorado. Web de la asignatura

Más detalles

Arquitectura del Software. Estableciendo la estructura global de un sistema de software

Arquitectura del Software. Estableciendo la estructura global de un sistema de software Arquitectura del Software Estableciendo la estructura global de un sistema de software Puntos relevantes Complementario al diseño Tiene en cuenta el aspecto dinámico Existencia de estilos División en subsistemas

Más detalles

PROGRAMACION ORIENTADA A OBJETOS CON PHP

PROGRAMACION ORIENTADA A OBJETOS CON PHP PROGRAMACION ORIENTADA A OBJETOS CON PHP COMO SE DEFINE EN PHP La programación orientada a objetos es una metodología de programación avanzada y bastante extendida, en la que los sistemas se modelan creando

Más detalles

Patrones de diseño en PHP Los 23 modelos de diseño: descripciones y soluciones ilustradas en UML2 y PHP

Patrones de diseño en PHP Los 23 modelos de diseño: descripciones y soluciones ilustradas en UML2 y PHP Introducción a los patrones de diseño 1. Design patterns o patrones de diseño 15 2. Descripción de los patrones de diseño 17 3. Catálogo de patrones de diseño 18 4. Cómo escoger y utilizar un patrón de

Más detalles

Guía Docente Curso 2012-2013

Guía Docente Curso 2012-2013 ESCUELA TÉCNIICA SUPERIIOR DE IINGENIIERÍÍA Guía Docente Curso 2012-2013 Titulación Ingeniería Informática DATOS DE LA ASIGNATURA * * Asignatura en experiencia piloto de implantación del sistema de créditos

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

Lo que necesitaremos para programar en Java, será un editor de texto o IDE y la JDK.

Lo que necesitaremos para programar en Java, será un editor de texto o IDE y la JDK. Introducción Java surgió en 1991 dentro de la empresa Sun Microsystems como un lenguaje de programación sencillo y universal destinado a electrodomésticos. La reducida potencia de cálculo y memoria de

Más detalles

con certif icado de profesionalidad

con certif icado de profesionalidad CARACTERÍSTICAS El diseño web está cambiando en poco tiempo. Las nuevas tecnologías y estándares de programación están revolucionando tanto la forma de crear web como de interactuar con ellas. En nuestro

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

GESTIÓN DE REDES PARTE III

GESTIÓN DE REDES PARTE III PARTE III Arquitectura de Gestión OSI 3.1 Introducción La gestión de red OSI, pensada inicialmente para la gestión de las propias redes OSI, debe su implantación práctica al ser adoptada por los estándares

Más detalles

Tema 6º: Diseño Orientado a Objetos

Tema 6º: Diseño Orientado a Objetos Tema 6º: Diseño Orientado a Objetos Diseño preliminar y Diseño detallado Modelado de la Arquitectura del Sistema Abstracciones y mecanismos clave Elementos básicos del Diseño Orientado a Objetos Diagramas

Más detalles

Repaso de las características más importantes de la programación Java y su adaptación a Android

Repaso de las características más importantes de la programación Java y su adaptación a Android Repaso de las características más importantes de la programación Java y su adaptación a Android 1. Entorno de programación en java 2. Variables y tipos de datos 3. Operaciones y operadores 4. Clases y

Más detalles

Estilos y Patrones Arquitectónicos

Estilos y Patrones Arquitectónicos Lic. Ariel Trellini Estilos y Patrones Arquitectónicos Llamando a las cosas por su nombre Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Arquitectura y Diseño de Sistemas

Más detalles

GUÍA DOCENTE DE LA ASIGNATURA

GUÍA DOCENTE DE LA ASIGNATURA GUÍA DOCENTE DE LA ASIGNATURA G658 - Ingeniería del Software I Grado en Ingeniería Informática Obligatoria. Curso 3 Curso Académico 04-05 . DATOS IDENTIFICATIVOS Título/s Grado en Ingeniería Informática

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

Herencia e Interfaces

Herencia e Interfaces Herencia Introducción En C# cualquier dato es un objeto porque todos los tipos derivan implícitamente de este tipo, y heredan los métodos y campos definidos en dicha clase. Cada nuevo tipo tiene todo lo

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Introducción. El curso se compone de dos módulos:

Introducción. El curso se compone de dos módulos: Introducción El programa de certificación ORACLE en Java SE, ofrece el nivel de certificación Oracle Certified Professional, Java SE 7 Programmer y está diseñado para personas que poseen una base sólida

Más detalles

Clases abstractas e interfaces

Clases abstractas e interfaces Clases abstractas e interfaces Clases abstractas Una clase abstracta es una clase que no se puede instanciar se usa únicamente para definir subclases Cuándo es una clase abstracta? En cuanto uno de sus

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Curso: Diseño Orientado a Objetos Patrones de Diseño

Curso: Diseño Orientado a Objetos Patrones de Diseño Curso: Diseño Orientado a Objetos Patrones de Diseño DISEÑO ORIENTADO A OBJETOS PATRONES DE DISEÑO... 1 OBJETIVO...1 AUDIENCIA...1 CONTENIDO...1 BIBLIOGRAFÍA...2 DOCENTE...3 MODALIDAD DEL DESARROLLO...3

Más detalles

Modelo de Objetos Distribuidos

Modelo de Objetos Distribuidos Remote Method Invocation Modelo de Objetos Distribuidos Un objeto remoto es un objeto cuyos métodos pueden ser invocados desde otra máquina virtual de java, potencialmente en un host diferente. Modelo

Más detalles

2.2.- Paradigmas de la POO

2.2.- Paradigmas de la POO 2.2.- Paradigmas de la POO Los principios propios de la orientación a objetos son: 2.2.1.- Abstracción de Datos 2.2.2.- Encapsulamiento 2.2.3.- Ocultamiento 2.2.4.- Herencia 2.2.5.- Polimorfismo Cualquier

Más detalles

Carrera: SCM - 0426 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: SCM - 0426 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Programación orientada a objetos Ingeniería en Sistemas Computacionales SCM - 0426

Más detalles

Diplomado Java. Descripción. Objetivo. A quien está dirigido. Requisitos. Beneficios

Diplomado Java. Descripción. Objetivo. A quien está dirigido. Requisitos. Beneficios Diplomado Java Descripción El lenguaje de programación Java es uno de los más utilizados hoy en día. Su potencia, simplicidad, funcionalidad y capacidad hacen que este lenguaje sea una de las herramientas

Más detalles

Arquitecturas Software. Arquitecturas Software. Arquitecturas Software. Juan José Moreno Navarro. Motivación: Idea principal: Características:

Arquitecturas Software. Arquitecturas Software. Arquitecturas Software. Juan José Moreno Navarro. Motivación: Idea principal: Características: Arquitecturas Software Juan José Moreno Navarro (Curso de Software basado en Componentes, junto a Lars-Ake Fredlund) Arquitecturas Software Motivación: Complejidad creciente de aplicaciones. Sistemas distribuidos

Más detalles

Guía docente de la asignatura

Guía docente de la asignatura Guía docente de la asignatura Asignatura Materia DISEÑO DE SOFTWARE DESARROLLO DE SOFTWARE Módulo Titulación Grado en INGENIERÍA INFORMÁTICA Plan 463 Código 45203 Periodo de impartición S5 Tipo/Carácter

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO MF0492_3 PROGRAMACION WEB EN EL ENTORNO SERVIDOR (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 240 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 217 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

Más detalles

ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL

ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL 1 Reservados todos los derechos. El contenido de esta obra está protegido por la Ley, que establece penas de prisión y/o multas, además de las correspondientes

Más detalles

Técnicas de desarrollo de aplicaciones en Métrica V3

Técnicas de desarrollo de aplicaciones en Métrica V3 Índice de contenido Técnicas de desarrollo de aplicaciones en Métrica V3 Técnicas de desarrollo de aplicaciones en Métrica V3...1 Licencia...1 Introducción...1 Técnicas de desarrollo...1 Análisis coste-beneficio...2

Más detalles

Patrones Creacionales Builder. Patrones Creacionales Abstract Factory. Patrones Creacionales Singleton. Patrones Creacionales Prototype

Patrones Creacionales Builder. Patrones Creacionales Abstract Factory. Patrones Creacionales Singleton. Patrones Creacionales Prototype Temario Patrones de Diseño de Software Fundamentos de Ingeniería de SW Jocelyn Simmonds GOF: Patrones Creacionales Patrones Estructurales ILI-236 (JS) Patrones II 1 / 31 ILI-236 (JS) Patrones II 2 / 31

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS (L40629) Sabino Miranda-Jiménez

PROGRAMACIÓN ORIENTADA A OBJETOS (L40629) Sabino Miranda-Jiménez PROGRAMACIÓN ORIENTADA A OBJETOS (L40629) Sabino Miranda-Jiménez Paradigmas de programación 2 Paradigmas de programación Paradigma de programación estructurada Enfatiza la separación datos de un programa

Más detalles

EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011

EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011 EXAMEN FINAL Metodología y Programación Orientada a Objetos. Curso 2010 2011. Cuatrimestre de otoño. 17 de Enero de 2011 1. (0,75 PUNTOS) Identificad a continuación las sentencias que son ciertas, descartando

Más detalles

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS Dámaso López Aragón Introducción En la actualidad, la orientación a objetos es una nueva forma de comprender los problemas y modelar el negocio de una empresa,

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles