Unidades 14 A 28

Ingeniera del Software II Ingeniera Informtica, 4Curso
Proyecto Prctico de Diseo de Software

Curso 2010-2011
Gonzalo Gnova
Presentacin
Profesores
Grupo M Gonzalo Gnova (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)
Direccin para entregas de la prctica: is.uc3m [at] gmail.com Web de la asignatura

http://www.ie.inf.uc3m.es/grupo/docencia/reglada/Is1y2/IS2.htm
Un curso de anlisis y diseo en dos asignaturas:

IS1: requisitos del usuario (captura) y requisitos del software (anlisis) IS2: diseo arquitectnico (alto nivel) y diseo detallado (bajo nivel)
Proyecto Prctico de Diseo de Software 2
Objetivos de la asignatura
Especificacin del diseo de alto y bajo nivel de una aplicacin informtica Aprender...
Redaccin de un documento completo de diseo Desarrollo dirigido por modelos (MDA-MDD-MDE), evolucin de USDP Estndares de documentacin de proyectos Tcnicas de la orientacin a objetos para diseo arquitectnico y detallado
Desarrollar capacidades
Abstraccin y resolucin de problemas Lectura crtica y reflexiva Trabajo en equipo Exposicin de resultados propios Revisin de trabajos ajenos Aprendizaje a partir de errores propios y ajenos
Programa de la asignatura: teora

Tema III Diseo arquitectnico (diseo de alto nivel)
Unidad 14 La transicin del anlisis al diseo Unidad 15 Introduccin al diseo arquitectnico Unidad 16 Modelado arquitectnico con UML Unidad 17 Herramientas de modelado UML (laboratorio) Unidad 18 Vistas arquitectnicas Unidad 19 Estilos arquitectnicos Unidad 20 Qu es diseo orientado a objetos? (artculo y examen)
Tema IV Diseo detallado (diseo de bajo nivel)

Unidad 21 Introduccin al diseo detallado Unidad 22 Diseo detallado con UML (1): polimorfismo Unidad 23 Diseo detallado con UML (2): interacciones Unidad 24 Diseo detallado con UML (3): mquinas de estados Unidad 25 Patrones de diseo (1) Unidad 26 Patrones de diseo (2) Unidad 27 Implementacin de asociaciones UML en Java (artculo y examen) Unidad 28 Herencia mltiple
Programa de la asignatura: prcticas

Equipos de 4 alumnos (atencin: alumnos que no han cursado IS1) Trabajo en 2+2 fases (URD/SRD + ADD/DDD) Actividades en cada fase
Desarrollo y documentacin del proyecto conforme al ndice de la prctica recuento de horas dedicadas al proyecto y mtricas contabilizadas al principio de cada documento enviadas aparte por correo segn las plantillas (horas, mtricas) Sesiones de tutora colectivas, asistencia voluntaria cada equipo tendr oportunidad de presentar su borrador y recibir crticas Revisiones cruzadas informes de revisin redactados conforme a las normas Exposiciones en pblico y defensa del proyecto entrega de transparencias impresas el primer da de exposiciones (2xPg!) exposicin individual de una parte del proyecto respuestas a los revisores y a los profesores
Documentacin entregada
Atencin a nombres de archivos y fechas de entrega Dos documentos parciales (el segundo completa al primero):
ej. ProyectoIS2-M05.doc: equipo M05, etc. envo por correo a is.uc3m [at] gmail.com y miembros del equipo revisor ver ndice adaptado del estndar ESA PSS-05-0
Dos documentos de revisin:

ej. RevisinIS2-M05-R07.doc: equipo M05 revisado por equipo M07, etc. envo por correo a los profesores y a los miembros del equipo revisado
Proyecto final revisado (normas):

documento final + presentaciones + recuento de horas + mtricas ej. ProyectoIS2-M05.doc + etc. envo 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 tericas para el examen de test

Descripcin de la prctica
Ingeniera del Software 1
Realizar un proyecto de ingeniera 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 lmites de carga de trabajo de la asignatura. Describir este subconjunto en forma de requisitos y con los modelos necesarios. Realizar una evaluacin del portal (la parte seleccionada).
Ingeniera del Software 2:

A partir de los requisitos especificados en IS1. Realizar un diseo arquitectnico de la aplicacin (ADD), slo del subconjunto escogido para especificar los requisitos. Realizar un diseo detallado (DDD), slo de uno de los componentes especificados en el diseo arquitectnico.
Proyecto Prctico de Ingeniera de Requisitos
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).
Extensin (porque queremos calidad, no cantidad):

ADD: 15 a 20 pginas. DDD: 30 a 40 pginas. TOTAL: 45 a 60 pginas (sin contar ndices ni anexos). Trabajo excesivo? Factor de penalizacin en la calificacin del documento por exceso de pginas.
penalizacin 1
1-(p-60)/60
0 0 60
120
pginas
8
Trabajo en equipo y dedicacin a la prctica

Un total de 60 horas/alumno dedicadas a la prctica es razonable (58 h/a en IS1).
Equivale a una hora de trabajo prctico por cada hora de clase terica. 20 horas de clase + 20 horas de trabajo personal = 40 horas/semana.
La proporcin entre trabajo individual y en equipo debera ser 4/1 3/1.

Para conseguirlo la distribucin y coordinacin del trabajo deben ser adecuadas. Si el nmero de horas es igual para todos falta sinceridad pero si no se califica! En IS1 la proporcin ha sido 1,5 / 1: an falta distribuir mejor el trabajo individual.
Nombre Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez
Ind. Eq. TOTAL 25 25 25 25 35 35 35 35 60 60 60 60 240
Nombre Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez
Ind. Eq. TOTAL 40 43 47 50 15 11 16 18 60 55 54 63 68 240
TOTAL 100 140 MAL
TOTAL 180 BIEN
Proyecto Proyecto Prctico Prctico dede Ingeniera Diseo de deSoftware Requisitos
Calendario de la asignatura
Dedicacin a la asignatura, aproximadamente:
30 horas de clase terica 30 horas de otras actividades en clase 60 horas de trabajo personal y en equipo
Clases tericas
Asistencia no controlada. Dos sesiones en laboratorio. El examen de Test es un reflejo directo del aprovechamiento de las clases tericas, de ah la importancia que se le da en la nota final.
Tutoras colectivas
Asistencia voluntaria. Sirven para que el profesor pueda hacer un seguimiento efectivo del proyecto. Aprovechad la tutora llevando un borrador bien trabajado.
Exposiciones/Revisiones
Asistencia obligatoria a todas las exposiciones, aunque no toque exponer. Dos miembros exponen la prctica, dos responden a revisores y profesores. Tiempo mximo de exposicin: 20 minutos entre ambos.
Calendario completo
Atencin a las fechas de entregas. Atencin a la fecha de confirmacin de equipos de prcticas.
Proyecto Prctico de Ingeniera de Requisitos 10
Evaluacin de la asignatura
Individual Tutoras* Prctica Exp/Ejecucin** Exp/Respuestas Teora Equipo 00% Exp/Preparacin 05% 05% Documentacin 05% Revisiones 30% 05% 10% 50% 50% 100% 50%
Exmenes parciales*** 10% Propuesta de Examen final 30% preguntas 50%
* Asistencia NO obligatoria a tutoras colectivas ** Asistencia obligatoria a las exposiciones ajenas (0,5 penalizacin por falta no justificada) *** Se tiene en cuenta la participacin en el debate posterior Posible bonificacin global por participacin e inters (slo a los aprobados)
Ms detalles
Proyecto Prctico de Ingeniera de Requisitos 11
Bibliografa
Diseo arquitectnico, diseo detallado
Eric Braude. Software Engineering. An Object-Oriented Perspective. John Wiley & Sons, 2001. Captulos 5 y 6 Ian Sommerville. Software Engineering, 7th ed. Pearson-Addison Wesley, 2004. Captulos 11-16 Roger Pressman. Ingeniera del software: un enfoque prctico, 6 ed. McGraw-Hill. Captulos 9-11 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of reusable Object-Oriented software. Addison-Wesley, 1994.
Modelado con UML

Martin Fowler, Kendall Scott. UML Distilled. A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, 2004. Jim Arlow, Ila Neustadt. UML and the Unified Process. Practical Object-Oriented Analysis & Design. Addison-Wesley, 2002. Perdita Stevens, Rob Pooley. Using UML. Software Engineering with Objects and Components. Addison-Wesley, 2000.
Ms en la ficha de la asignatura
12
Tema III
Diseo arquitectnico
Unidad 14 La transicin del anlisis al diseo Unidad 15 Introduccin al diseo arquitectnico Unidad 16 Modelado arquitectnico con UML Unidad 17 Herramientas de modelado (laboratorio) Unidad 18 Vistas arquitectnicas Unidad 19 Estilos arquitectnicos Unidad 20 Qu es diseo orientado a objetos? (artculo y examen)
13
Transformacin de modelos: del anlisis al diseo

Dos trayectorias tpicas:
modelo del mundo real (modelo de anlisis en un sentido) anlisis de requisitos (modelo de anlisis en otro sentido) modelo de diseo modelo descriptivo concreto del sistema heredado modelo descriptivo abstracto del sistema heredado modelo especificativo abstracto del sistema nuevo modelo especificativo concreto del sistema nuevo
Vista abstracta Vista concreta Vista abstracta Vista concreta modelo especificativo abstracto del dominio modelo especificativo concreto del dominio modelo descriptivo abstracto del dominio modelo descriptivo concreto del dominio Dominio modelo especificativo abstracto del sistema modelo especificativo concreto del sistema modelo descriptivo abstracto del sistema modelo descriptivo concreto del sistema Sistema
Especificacin
Descripcin
14
Transformacin de modelos: del anlisis al diseo

propsito
especificacin B descripcin A C realidad abstracto concreto dominio sistema
abstraccin
15
Relacin lgico-temporal entre el anlisis y el diseo
Iteracin 1 Anlisis (versin 1)
Iteracin 2 Anlisis (versin 2) Diseo (versin 1)
Iteracin 3 Anlisis (versin 3) Diseo (versin 2) Implementacin (versin 1)
16
El diseo arquitectnico en el Estndar ESA

ESA software engineering standards (PSS-05-0)
Chapter 4. The architectural design phase 4.3. Actividades: modelo fsico (esttico y dinmico)
Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)

Chapter 3. Using Object-Oriented Methods with PSS-05 3.5. Modelo fsico, reutilizacin, criterios de calidad del diseo
Guide to the software architectural design phase (PSS-05-04)

Chapter 2. The architectural design phase 2.3. Construccin del modelo fsico (descomposicin, NFR, calidad...) 2.4. Especificacin del diseo arquitectnico (funciones componentes) 2.7. Revisin de los requisitos del software Chapter 5. The architectural design document 5.1. Introduccin: lo que debe ser, lo que no debe ser 5.2. Estilo: claridad, consistencia, modificabilidad
Preguntas ms frecuentes
El diseo detallado en el Estndar ESA

ESA software engineering standards (PSS-05-0)
Chapter 5. The detailed design and production phase 5.3. Actividades: diseo detallado / no produccin
5.3.1. Descomponer componentes arquitectnicos en mdulos programables
5.4. Salidas: omitir cdigo 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-05 3.6. Conversin automtica modelo cdigo (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. Descomposicin, diseo defensivo, optimizacin, etc. Chapter 5. The detailed design and production document 5.1. Introduccin: lo que debe ser, lo que no debe ser 5.2. Estilo: claridad, consistencia, modificabilidad
18
Introduccin al diseo arquitectnico Arquitectura del software

analoga con la arquitectura civil: requisitos madurez de la arquitectura del software alta cohesin y bajo acoplamiento descomposicin recursiva disear para el mantenimiento reducir la complejidad de las dependencias diseo
Cmo lograr una descomposicin modular eficaz?
Criterios para la seleccin de una arquitectura

criterios clsicos otros criterios
Reutilizacin de diseos y componentes
19
Relacin entre anlisis, arquitectura y diseo detallado

1. Anlisis Los vehculos deben poder viajar desde la parte alta a 120 km/h en lnea recta y llegar a la parte baja en no ms de 3 minutos. 2. Clases de Dominio Vehculo Camino Columna 3. Arquitectura Cable
Barandilla Cable 4. Diseo Detallado
vehculo
Camino
Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective
Columna
Estilos arquitectnicos 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 segn se percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema.
Len Bass 1998

La arquitectura del software de un programa o sistema de computacin 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. 1471-2000

La arquitectura del software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y con el entorno, y los principios que orientan su diseo y evolucin.
22
Cohesin y acoplamiento
componente 4
1 2 3
componente
Alta cohesin
Puente
Bajo acoplamiento
Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective Proyecto Prctico de Diseo de Software 23
Cmo lograr una buena descomposicin modular A B C A D E
Mal
Cmo acertar de antemano?
Bien
Estilos arquitectnicos
24
Descomposicin modular recursiva: 72
25
Criterios para la seleccin de una arquitectura Criterios clsicos:

Extensibilidad Modificabilidad Simplicidad Eficiencia
Otros criterios:
Reuso Escalabilidad Coste Requisitos no funcionales
26
Reutilizacin Diseos reutilizables

Estilos arquitectnicos: formas tpicas de sistemas Marcos (frameworks): aplicaciones o sistemas incompletos Lneas de productos: generalizaciones de aplicaciones exitosas Patrones de diseo: heursticas para solucin con formas tpicas
Componentes reutilizables
Dificultades para el reuso Eleccin de componentes para el reuso Desarrollo para el reuso
27
Descomposicin basada en marcos de trabajo

Java.awt
Window Capa de marcos
1 ventanaEmpleado
Capa de aplicacin
MiAplicacin
VentanaDialogo
Empleado
28
Nocin de componente
Unidad autnoma, reemplazable y reutilizable, habitualmente ejecutable
29
Niveles de descomposicin modular (UML 2.x)

Nivel 1 Subsistema Nivel 2 Componente (...) Nivel N-1 Componente Nivel N Clase
(UML 1.x)
(UML 1.x)
30
Nocin de dependencia
Dependencia A C:
<<component>> A
A requiere la presencia de C Los cambios de C pueden afectar a A
<<component>> B
<<component>> C
31
Nocin de interfaz
Dos componentes pueden ofrecer la misma interfaz
Dos interfaces no necesariamente disjuntas
32
Representacin de interfaces: abreviada y completa

Novedad en UML2
33
Cmo instanciar las interfaces de un componente (1)

package GestinEmpleados; 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 slo una interfaz, el tipo abstracto de datos. Es necesario que la clase cliente (Departamento) conozca las clases concretas EmpleadoFijo, etc.: estas clases deben ser pblicas. Nada le impide usarlas slo para invocar los constructores (salvo el buen estilo del programador). La dependencia es potencialmente peligrosa.
34

package GestinEmpleados; public interface iGestorEmpleados { public int crearEmpleado( ); // el gestor debe mantener algn 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( ) } ====================
El componente proporciona slo una interfaz, el gestor.
GestorEmpleados no puede recibir ni devolver valores de tipo EmpleadoFijo, EmpleadoTemporal, etc. Es necesario un mecanismo de traduccin de los identificadores pblicos a las instancias de EmpleadoFijo, etc. (una lista interna).
class Departamento { int e = ge.crearEmpleado ( ); // se supone que existe GestorEmpleados ge La clase cliente slo usa el ge.modificarEmpleado(e); gestor y los identificadores } pblicos.
35

package GestinEmpleados; 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 algn 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
Caso 3 (parmetros iEmpleado)
Caso 1
Caso 2 (parmetros int)

Interfaces proporcionadas y requeridas
proporciona, realiza
requiere, usa
38
Cableado de componentes
ball and socket
cableado independiente cableado con dependencia

cableado en rbol
39
Anidamiento de componentes
puerto
delegacin
El conjunto de interfaces de un puerto debe ser consistente
40
Diagrama de despliegue
dispositivo hardware nodo ruta de comunicacin
entorno de ejecucin software
41
Herramientas de modelado UML: Altova UModel Objetivo de las herramientas CASE Otras herramientas alternativas Altova UModel
Instalacin Licencias Requisitos HW y SW Diagramas de Componentes y Clases Diagramas de Despliegue Ejercicios en clase: transparencias 31-41
42
Objetivo de las herramientas CASE Mejorar la productividad, el tiempo y coste de desarrollo. Mejorar la planificacin de un proyecto. Automatizar desarrollo del software, documentacin, generacin de cdigo, pruebas de errores y gestin del proyecto. Ayuda a la reutilizacin del software. Gestin global en todas las fases de desarrollo de software con una misma herramienta. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.
43
Otras herramientas alternativas

Visio http://www.softwarestencils.com/uml/index.html Telelogic Tau http://www.telelogic.com/products/modeler/index.cfm swReuser http://www.reusecompany.com/producto.aspx?id=2 Star UML http://staruml.sourceforge.net/en/
44
Altova Umodel: Instalacin

Ir a:
http://www.altova.com/download/umodel/uml_tool_enterprise.html Download UModel 2008 Enterprise Edition Setup now
Seleccionar el botn Ejecutar:
Seguir con la instalacin, presionando el botn Next cuando sea conveniente, y por ltimo, el botn Install. Cuando se encuentre Altova UModel instalado completamente en el ordenador, se debe pedir una licencia de evaluacin (Request a FREE Evaluation Key).
Licencias y requisitos HW y SW Licencias

Solicitud de licencia por 30 das. Instalar el software en un solo ordenador del equipo de prcticas 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 mnimo 2 GB de disco duro con un mnimo de 650 MB de espacio libre.
Software:
UModel es una aplicacin Windows de 32-bit que se puede instalar en Windows 2000 / 2003, Windows XP y Windows Vista. Se pueden descargar mdulos de integracin con Visual Studio .NET (Enterprise Edition) y Eclipse (Enterprise Edition).
Aspecto de la herramienta
47
Diagramas importantes para IS2 Diagrama de Componentes
Diagrama de Clases
Diagrama de Despliegue
48
El modelo de 4+1 vistas arquitectnicas
Vista lgica (conceptual)
Vista de desarrollo (implementacin)
Vista de casos de uso
Vista de proceso (ejecucin)
Vista fsica (despliegue)
Ingeniera del Software I
Ingeniera del Software II

49
Caractersticas de cada vista en el modelo 4+1

Vista Lgica (conceptual) Modelo de informacin Usuarios finales Proceso (ejecucin) Concurrencia y sincronizacin Integradores del sistema Desarrollo (implementacin) Organizacin del software en el entorno de desarrollo Programadores Fsica (despliegue) Correspondencia software-hardware Ingenieros de sistemas
Aspecto
Stakeholders
Requisitos
Funcionales
Rendimiento Disponibilidad Fiabilidad Concurrencia Distribucin Seguridad
Gestin del software Reuso Portabilidad Mantenibilidad Restricciones impuestas por la plataforma o el lenguaje
Rendimiento Disponibilidad Fiabilidad Escalabilidad Topologa Comunicaciones
Notacin
Clases y asociaciones
Procesos y comunicaciones
Componentes y relaciones de uso
Nodos y rutas de comunicacin
50
Relaciones entre las cuatro vistas

minimizar dependencias nuevas clases de diseo
? identificar clases activas
requisitos no funcionales
51
Vista de casos de uso
52
53
54
55
56
Estilos arquitectnicos (Shaw & Garlan)

Flujo de datos
Tuberas y filtros Secuencial por lotes
Componentes independientes
Sistemas cliente-servidor Procesos paralelos Sistemas de eventos
Mquinas 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

tiempo de llegada de clientes - n de cajeros - velocidad media de cada cajero - tiempo medio de llegada entre clientes tiempo medio entre llegadas 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 estadsticas
Adaptado de W. Haythorn, What Is Object-Oriented Design?
informar
58
Arquitectura de tuberas y filtros stream > filter pipe filter filter pipe filter filter
filter
< stream
Arquitectura cliente-servidor
Client 1 Client 2 Client 3 Client 4
Internet
Catalogue server Library catalogue
Video server Film clip files
Picture server Digitised photographs
Web server Film and photo info
Adaptado de I. Sommerville, Software Engineering Proyecto Prctico de Diseo de Software 60
Arquitectura de procesos paralelos
Customer: customer n Customer: customer n+1
Session: session m create
Session: session k retrieve create
Account: customer n checking Account: customer n+1 saving
deposit withdraw
retrieve
Arquitectura de sistema de eventos
Sub-system 1
Sub-system 2
Sub-system 3
Sub-system 4
Event and message handler
Arquitectura de mquina virtual

assemble { { 260MHz & 64MB } and { { 400MHz & 128MB } and { 260MHz & 32MB } } }
400Mhz & 128MB
260Mhz & 64MB 260Mhz & 32MB

63
Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective
Arquitectura de repositorio
Design editor
Code generator
Design translator
Project repository
Program editor
Design analyser
Report generator
Arquitectura en capas: modelo OSI
7 6 5 4 3 2 1
Application Presentation Session Transport Network Data link Physical Network Data link Physical Communications medium
Application Presentation Session Transport Network Data link Physical
Arquitectura en capas: juegos interactivos Ejecucin de movimientos Lanzamiento de Dado Definicin de reglas del juego Jugador Representacin grfica
Seleccin de Ficha
Avance y Captura
Movimiento
Turno
Arquitectura modelo-vista-controlador (original)
Acciones del usuario
Modificaciones en la vista
Controlador
Vista
Informacin al usuario
Consultas al modelo
C V M
Consultas y modificaciones en el modelo
Modelo
Arquitectura modelo-vista-controlador (moderna)
Comunicacin con el usuario
Comportamientos complejos
Vista
Controlador
V C M
C V M
Consultas y modificaciones en el modelo Consultas en el modelo
Modelo
Modelo-Vista-Controlador original
68
Arquitectura en Cuatro Capas
69
Arquitectura en Tres Escalones
70
Tema IV
Diseo detallado
Unidad 21 Introduccin al diseo detallado: diseo por contratos Unidad 22 Diseo detallado con UML (1): polimorfismo Unidad 23 Diseo detallado con UML (2): interacciones Unidad 24 Diseo detallado con UML (3): mquinas de estados Unidad 25 Patrones de diseo (1) Unidad 26 Patrones de diseo (2) Unidad 27 Implementacin de asociaciones UML en Java (artculo y ex.) Unidad 28 Herencia mltiple
71
Introduccin al diseo detallado: diseo por contratos Qu es el diseo detallado Nivel de detalle en el modelo de diseo Diseo por contratos
Nocin de contrato Especificacin formal del contrato: sintaxis y semntica Uso de pre- y post- condiciones Invariantes de clase Contratos y herencia: subcontratacin
Especificacin de algoritmos
Diagramas de actividad Pseudocdigo
72
Diseo por contratos: PPCs e invariantes PPCs de operacin

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
Diseo por contratos: subcontratacin

PPCs de operacin
CuentaCorriente.sacarDinero(cantidad: Moneda) Pre: saldo cantidad 0 Post: saldo = saldo cantidad
CuentaCorriente saldo sacarDinero(cantidad)
PPCs de operacin redefinida en la subclase

CuentaCredito.sacarDinero(cantidad: Moneda) Pre: saldo + credito cantidad 0 Post: saldo = saldo cantidad Pre: menos restrictiva, o igual Post: ms restrictiva, o igual
CuentaCredito credito sacarDinero(cantidad) Es correcta esta generalizacin?
Invariantes de clase (ms restrictivo, o igual)

CuentaCorriente: saldo 0 CuentaCredito: (credito 0) AND (saldo + credito 0)
Diseo por contratos: uso correcto de jerarquas

CaminoOblicuo.distancia.post
d = ( x2 x1 ) 2 + ( y2 y1 ) 2
CaminoEsquinado.distancia.post
CaminoOblicuo origen: Punto destino: Punto distancia( ): Float Cul sera correcta?
d = ( x2 x1 ) + ( y2 y1 )
(x2, y2)
CaminoEsquinado origen: Punto destino: Punto

(x1, y1)
distancia( ): Float
75
Especificacin 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 [s]
[no]
m100 [s]
[no]
NoBisiesto (x) = NOT m4(x) OR (m100(x) AND NOT m400(x))
[no]
m400
[s]
no bisiesto
bisiesto
76
Diseo detallado con UML (1): polimorfismo Asignacin polimrfica

variables y argumentos
Invocacin polimrfica de operaciones

interfaz y comportamiento
Redefinicin polimrfica de operaciones

sobreescritura y sobrecarga
Signatura de la operacin
distincin de operaciones por su signatura
Visibilidad Interfaces
Clases y operaciones abstractas Generalizacin vs. Realizacin
77
Asignacin polimrfica de variables
public class CuentaCorriente { } public class CuentaCredito extends CuentaCorriente { } public class Persona { private CuentaCorriente titularDe; public asignarCuenta (CuentaCorriente cc) { titularDe = cc; } }
CuentaCorriente
titularDe
Persona
CuentaCredito
Variable polimrfica
public class Main { public static void main(String[] args) { Persona juan = new Persona(); CuentaCorriente ccr = new CuentaCredito(); juan.asignarCuenta(ccr); } }
: CuentaCredito
juan: Persona
Argumento polimrfico
78
Invocacin polimrfica de operaciones

public class CuentaCorriente { public Moneda saldo; public void sacarDinero (Moneda cantidad) { } } 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); } }
CuentaCorriente saldo sacarDinero(cantidad) titularDe
Persona
CuentaCredito credito sacarDinero(cantidad)

Asignacin polimrfica Invocacin polimrfica
: CuentaCredito
sacarDinero(100)
juan: Persona
79
Redefinicin polimrfica de operaciones

Polimorfismo: capacidad de ejecutar distintos comportamientos en respuesta al mismo mensaje (= invocacin de operacin). Una operacin polimrfica es aqulla que tiene muchas implementaciones. No confundir sobreescritura con sobrecarga de operaciones:
sobreescribir: redefinir en otra clase el comportamiento de la misma operacin el mtodo se selecciona en tiempo de ejecucin sobrecargar: reutilizar el nombre de operacin, pero con distintos parmetros el mtodo se selecciona en tiempo de compilacin, no es polimorfismo
sobreescritura (polimorfismo)
CuentaCorriente saldo sacarDinero(cantidad) sacarDinero( )
sobrecarga
CuentaCredito credito sacarDinero(cantidad)
Signatura de la operacin
Define los elementos que identifican unvocamente una operacin:
nombre de operacin, nmero (orden) y tipo de los parmetros.
Una clase no puede tener dos operaciones con la misma signatura o firma. Los nombres de los parmetros no pertenecen a la signatura. Pertenece el tipo del valor de retorno a la signatura? Depende...
Segn el estndar de UML, s. Pero el tipo del retorno no sirve para distinguir qu operacin hay que ejecutar. No se puede usar para sobrecargar operaciones
Punto posicinX: Coordenada posicinY: Coordenada obtenerPosicin( ): CoordenadasPolares obtenerPosicin( ): CoordenadasCartesianas
p1 : Punto posicinX = 3 posicinY = -5
instance of
c := obtenerPosicin ( ) Qu operacin se invoca? Depende del tipo de c...

Clase mal definida

81
Distincin de operaciones por su signatura

En funcin del nombre de la operacin, su signatura, y su clase, puede ser:
una operacin distinta, una operacin sobrecargada, una operacin sobreescrita, o un error (detectable por el compilador).
Clase Resultado distinta misma distinta subclase igual misma igual subclase sobreescritura error sobrecarga CuentaCredito credito sacarDinero(cantidad: Moneda) sacarDinero(cantidad: MonedaEuropea) sobrecarga CuentaCorriente saldo sacarDinero(cantidad: Moneda) sacarDinero(cantidad: MonedaEuropea)
Nombre Signatura distinto
82
Visibilidad Niveles de visibilidad (diferentes en cada lenguaje):

+ ~ # public: visible para todas las clases (opcin por defecto para operaciones). package: visible para todas las clases que estn en el mismo paquete. protected: visible para las subclases. private: visible slo para la clase (opcin por defecto para atributos).
UML Public
Java Public Protected
VB.NET (C#) Public Protected-Friend Friend (Internal) Protected
Package
Protected friendly
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.
class Main { public static void main(String[] args) { Elemento e1=new Elemento(e1); Elemento e2=new Elemento(e2); e1.prueba(e2); } } Ejecucin y resultado: C:\java Main e3 A travs de la operacin pblica prueba, el objeto e1 manipula el atributo privado nombre de e2, e invoca su operacin privada escribir. Cul es el problema? En realidad, ninguno, si se entiende bien qu significa la visibilidad privada.
public class Elemento { private String nombre; private void escribir() { System.out.println(this.nombre); } public void prueba(Elemento p) { p.nombre=e3; p.escribir(); } public Elemento(String n) { nombre=n; } }
84
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.
Siendo Cuadrado subclase de Rectngulo, las instancias de la clase Cuadrado tienen una base y una altura, y por tanto parece que deberan poder acceder a ellas. Compilacin y resultado: La clase Cuadrado no puede ver los atributos base y altura: error de compilacin. Aun resolviendo este error, la clase Cuadrado no redefine correctamente la operacin invariante, ya que no puede verla. Sera considerada una operacin distinta, no una operacin redefinida. No es detectado por el compilador, lo cual es grave. En cambio, corrigiendo la visibilidad de los atributos base y altura, la operacin area s quedara bien redefinida. Los objetos de la clase Cuadrado tienen esos atributos, pero no son accesibles desde esta clase. Cul es el problema? En realidad, ninguno, si se entiende bien qu significa la visibilidad privada. Solucin: usar visibilidad protected.
public class Rectngulo { private int base, altura; private boolean invariante ( ) { return (base > 0) && (altura > 0) } public int area() { return base * altura } } public class Cuadrado extends Rectngulo { private boolean invariante ( ) { return (base > 0) && (base = altura) } public int area () { return base * base } }
85
Clases y operaciones abstractas

Operacin abstracta: slo se especifica la signatura, no la implementacin.
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 (polimrficas).
Figura posicin dibujar( )
Clase abstracta: est incompleta, no puede tener radio instancias directas. dibujar( )
Puede tener instancias indirectas a travs de sus subclases concretas. Una clase concreta... no puede tener operaciones abstractas. debe proporcinar implementaciones para todas las operaciones abstractas heredadas.
Crculo
Rectngulo base altura dibujar( )
Cuadrado {base=altura} dibujar( )
86
Interfaces
Encapsulamiento: separacin de interfaz e implementacin 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 implementacin de las operaciones (mtodos). una interfaz no puede tener atributos ni asociaciones navegables (esta restriccin ha desaparecido en UML 2.0). anloga a una clase abstracta con todas sus operaciones abstractas: no puede tener instancias directas. distinta de interfaz natural: conjunto de operaciones pblicas de una clase (accesibles a travs de cualquier asociacin navegable hacia la clase).
Impresora Imprimible Impresora interface Imprimible imprimir( ) Documento Documento
Notaciones para uso y realizacin de interfaces

Generalizacin vs. Realizacin

La realizacin puede entenderse como una generalizacin dbil: se hereda la interfaz, pero no la implementacin:
reduce la dependencia. disminuye la reutilizacin. alternativa a la generalizacin mltiple, no soportada por muchos lenguajes.
interface Imprimible
interface Figura
Las interfaces son elementos generalizables:

jerarquas mixtas de interfaces y clases.
Criterio de diseo: comprometerse slo con la interfaz.

declarar el tipo de las variables y parmetros de operaciones como interfaces, no como clases. servir cualquier instancia compatible con la interfaz.
Crculo Rectngulo
Ejemplo:
Figura f = new Cuadrado ( ); f.imprimir
Cuadrado
88
Diseo detallado con UML (2): interacciones Diagramas de interaccin: colaboracin y secuencia
Mensajes y operaciones Foco de control Nmeros de secuencia
Mensajes sncronos y asncronos

Flujo de informacin y flujo de control Hilos de ejecucin concurrente
Tipos de relaciones entre clases en UML

Dependencias inducidas por las relaciones entre clases
Tipos de enlaces de comunicacin: estructurales y contextuales

Correspondencia diagramas de interaccin-diagramas de clases Creacin y destrucin de objetos y enlaces
Ley de Demetra (Law of Demeter): No hable con desconocidos

Modelado dinmico: diagramas de interaccin

Transferencia de dinero entre dos cuentas: - sacar dinero de una cuenta, y - meter el dinero en la otra cuenta.
banco : Banco
Diagrama de secuencia
cuenta1 : Cuenta
cuenta2 : Cuenta
Diagrama de colaboracin
sacarDinero( )
cuenta1 : Cuenta
meterDinero( )
1: sacarDinero( )
Mensaje Objeto
banco : Banco 2: meterDinero( )
cuenta2 : Cuenta
90
Quin 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 anlisis se omiten detalles de interfaz de usuario por simplicidad.
banco : Banco Ana : Cliente emitirTransferencia( )
origen : Cuenta
destino : Cuenta
sacarDinero( ) meterDinero( )
El sistema entero se puede representar como un nico objeto, en un diagrama con slo dos lneas de vida que representa la comunicacin actor-sistema.
Mensajes y operaciones
Un mensaje es una peticin de servicio al objeto receptor:
Se corresponde (tpicamente) con la invocacin de una operacin. La operacin debe estar definida en la (super)clase del objeto receptor. Puede cambiar el estado del objeto receptor.
Argumentos y valores de retorno. Invocacin local de operaciones (autodelegacin).

b : Banco cc : CuentaCrdito CuentaCorriente saldo obtenerSaldo( )
ok := esDisponible(cantidad) c := obtenerCredito( ) ok := (cantidad <= c + s) s := obtenerSaldo( ) CuentaCrdito credito obtenerCredito( ) esDisponible(cantidad): boolean
92
Diagramas de secuencia: foco de control

El foco de control muestra el periodo de tiempo durante el cual un objeto est ejecutando una operacin como respuesta a un mensaje recibido:
Retorno implcito al final (puede hacerse explcito): no es un nuevo mensaje, y por tanto debe ser annimo (aunque en algunas herramientas no sea as). Anidamiento de ejecuciones (sombreado opcional): mecanismo de delegacin.
banco : Banco Ana : Cliente emitirTransferencia( )
origen : Cuenta
destino : Cuenta
sacarDinero( )
meterDinero( )
93
Diagramas de colaboracin: nmeros de secuencia

Forma alternativa de expresar la secuencia de mensajes y el anidamiento. Esquema de numeracin anidada:
El nmero del mensaje recibido se usa como prefijo para los mensajes enviados. Activador: mensaje que invoca la operacin desde la que se envan otros. Predecesor: mensajes anteriores enviados en la misma ejecucin.
banco : Banco Ana : Cliente emitirTransferencia( ) sacarDinero( ) origen : Cuenta destino : Cuenta
origen : Cuenta
meterDinero( )
1.1: sacarDinero( )
banco : Banco Ana : Cliente 1: emitirTransferencia (origen, destino, cantidad) 1.2: meterDinero( )
destino : Cuenta
94
Mensajes sncronos y asncronos

Invocacin sncrona de operacin:
El mensaje incluye el retorno (implcito o explcito), el emisor queda bloqueado. Comunicacin bidireccional con un nico mensaje.
Envo asncrono de seal:

El mensaje no incluye el retorno, el emisor no queda bloqueado (concurrencia). Puede tener argumentos, pero no valor de retorno. La comunicacin bidireccional requiere un nuevo mensaje de respuesta. El mensaje lleva el nombre de la seal (no necesariamente un verbo). Seales que aceptan los objetos de una clase
Banco
banco1 : Banco
banco2 : Banco
banco3 : Banco
transferenciaSolicitada(nmero, datos) transferenciaSolicitada(nmero, datos) transferenciaAceptada(nmero) transferenciaDenegada(nmero)
signal transferenciaSolicitada( ) signal transferenciaAceptada( ) signal transferenciaDenegada( )

95
Hilos de ejecucin concurrente

Un objeto activo posee un hilo de ejecucin propio. Clases y objetos activos se representan con doble trazo vertical a los lados. Quin puede enviar un mensaje? Un objeto activo. Un objeto pasivo que tenga el foco de control. Quin puede recibir un mensaje asncrono? Slo los objetos activos. Un mensaje sncrono desva el hilo de ejecucin al objeto delegado. Un mensaje asncrono puede comunicar dos hilos de ejecucin distintos, o desdoblar un hilo existente.
a p
q r s
96
Tipos de relaciones entre clases en UML

Dependencia
El elemento dependiente requiere la presencia del elemento independiente. Los cambios en el elemento independiente pueden afectar al elemento dependiente. Especificacin de un conjunto de conexiones entre instancias. Representan la estructura y posibilidades de comunicacin del sistema.
Asociacin
Relacin entre un elemento general y un elemento especfico. Generalizacin El elemento especfico puede aadir informacin y debe ser consistente con el elemento general. Relacin donde un elemento realiza o implementa la especificacin dada por otro elemento.
Realizacin
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
generalizacin
FiguraColoreada
Color
Figura
asociacin
Vector
1 miColor
Posicion
FiguraColoreada
Color
parmetro
variable local
(asociaciones contextuales)
98
Enlaces de comunicacin estructurales y contextuales

El envo de mensajes tiene lugar en un contexto determinado, normalmente la ejecucin de una operacin. El contexto delimita los destinos vlidos. A quin puedo enviar un mensaje? Mis conocidos son...
Un objeto conectado mediante un enlace navegable (instancia de asociacin). Un objeto recibido como parmetro en esta activacin (parameter). Un objeto creado localmente en esta activacin, o variable local (local). Yo mismo, el emisor del mensaje (self).
1.1.1: ok := esDisponible(cantidad)
Por cierto, cmo se nombran los objetos? origen : Cuenta - nombre arbitrario - valor identificador - nombre de parmetro parameter - nombre de variable
self
1.1: sacarDinero(cantidad) parameter
banco : Banco Ana : Cliente 1: emitirTransferencia (origen, destino, cantidad)
destino : Cuenta 1.2: meterDinero(cantidad)

99
Diagramas de interaccin 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 interaccin 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 interaccin (modelo dinmico) Objeto Enlace Mensaje Diagramas de clases (modelo esttico) Instancia de clase Instancia de asociacin (excepto enlaces contextuales) Operacin o seal visible en la (super)clase receptora
Creacin y destruccin 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 : CuentaCrdito
1: s := obtenerSaldo( ) banco : Banco 3: cerrarCuenta( )
cuenta1 : CuentaCorriente {destroyed}
2: abrirCuenta(s)
cuenta2 : CuentaCrdito {new}

{transient} = {new} + {destroyed}
101
Creacin y destruccin de enlaces

Implcita en la creacin/destruccin de un objeto:
El enlace creado puede ser estructural o contextual (local).
Creacin de un enlace con un objeto existente:

El enlace contextual parameter se transforma en un nuevo enlace estructural. Si asociacin unidireccional: slo el objeto origen puede crear o destruir enlaces.
Destruccin del enlace sin destruir el objeto enlazado.

banco : Banco 1: asignarTitular(titular) 2: desasignarTitular(titular)
cuenta1 : Cuenta
{new}
titular : Titular
{destroyed}
cuenta2 : Cuenta
102
Ley de Demetra: No hable con desconocidos Si dos objetos pueden comunicarse, entonces el cdigo de sus respectivas clases debe manifestarlo claramente (dependencias explcitas). El objeto x, en respuesta al mensaje m(a, b, c...), puede enviar mensajes slo 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 trminos de UML 1.x:

Todo enlace es instancia de una asociacin (estructural / contextual). Toda asociacin debe ser declarada (dependencia explcita).
La Ley de Demetra no es una regla absoluta.

Qu prohbe 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(); } } Cul es el problema? La clase Persona tiene una dependencia implcita, poco clara, con la clase Moneda. Solucin: en lugar de enviar un mensaje al objeto devuelto por otro mensaje, declarar una variable local, haciendo explcita la dependencia. public class Persona { private CuentaCorriente titularDe; public asignarCuenta (CuentaCorriente cc) { titularDe = cc; } public void mostrarSaldoActual() { Moneda saldo = titularDe.obtenerSaldo(); saldo.escribir(); } }
104
Diseo detallado con UML (3): mquinas 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. Comunicacin entre mquinas de estados. Diseo e implementacin de mquinas de estados.
Secuencia de acciones en un cambio de estado.
Aplicacin de las mquinas de estados al diseo de interfaces.
105
Mquinas de estados: estados, eventos y transiciones

Estado Clase Avin
despegar Estacionado aterrizar Volando
Evento
Transicin
Pseudoestado inicial
retirar
colisionar
Estado final Los eventos causan las transiciones entre estados. Los eventos de creacin y destruccin pueden ser implcitos o explcitos.
Estados y transiciones
Un estado es una situacin en la vida de un objeto caracterizada por satisfacer una condicin, realizar una accin o esperar un evento. Un estado tiene duracin, una transicin es instantnea. 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.
jubilar
Parado Persona edad 1..* 0..1 Empresa contratar despedir
Jubilado
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 transicin).
La sucesin 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 transicin debe tener un y slo un evento.
Tipos de eventos:
Evento de llamada: recepcin de mensaje sncrono / operacin misma notacin Evento de seal: recepcin de mensaje ascrono / seal Evento de cambio: comprobacin continua de una condicin lgica / when( ) Evento temporal: tiempo transcurrido desde la entrada en el estado / after( )
Los mensajes recibidos, sncronos o asncronos, pueden tener parmetros.

on Apagado off Parado stop when(velocidad < 5 cm/s)
108
play Reproduccin
Clase Reproductor
after(60 s)
Transiciones con guardas

Una guarda es una condicin lgica que es evaluada en el momento de recibir el evento y autoriza o no la transicin de estado (guarda tras evento).
Si la transicin 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 condicin lgica debe ser evaluable (expresin lgica) en el contexto de la clase propietaria (parmetros del evento, atributos y enlaces del objeto, etc.). Guardas
play[(not hayCinta) or atascada] on Apagado off Parado stop when(velocidad < 5 cm/s)
play[hayCinta and (not atascada)] Reproduccin
Clase Reproductor
after(60 s)
109
Transiciones con acciones

Una accin es un comportamiento que se ejecuta de modo instantneo (con tiempo de ejecucin despreciable) y atmico (no interrumpible).
Est asociada a un evento que dispara una transicin. Es completada antes de que la transicin 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 sncronos (operaciones) o asncronos (seales).
play[(not hayCinta) or atascada] on Apagado off Parado play[hayCinta and (not atascada)]/altavoz.on Reproduccin stop/altavoz.off when(velocidad < 5 cm/s)/altavoz.off
Acciones
Clase Reproductor
after(60 s)
110
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: accin de entrada / entry accin de salida / exit accin por evento interno / evento Actividades asociadas al estado como tal / do una actividad es duradera e interrumpible. puede modificar una condicin que genere un evento de cambio.
No confundir evento interno con autotransicin (sale y entra en el estado).

Autotransicin
Reproduccin Reproduccin entry / altavoz.on exit / altavoz.off do / reproducir cambiarVolumen(delta) /vol:= vol + delta cambiarVolumen(delta) / vol:= vol + delta do / reproducir
111
Evento interno
Diagramas de estados vs. Diagramas de clases

Eventos: operaciones o seales 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( )
Altavoz
on( ) altavoz off( )
Mensajes salientes: destinatario(s) designado(s) por el nombre de rol

112
Comunicacin entre mquinas de estados

Sentado
Elemento
signal mover( ) 1 levantar( ) siguiente sentar( )
mover /levantar
after(2 s) /sentar; siguiente.mover Levantado
1.2: sentar( )
2.2: sentar( )
3.2: sentar( )
e1 : Elemento 1: mover( ) 2: mover( )
e2 : Elemento 3: mover( )
e3 : Elemento 4: mover( )
1.1: levantar( )
2.1: levantar( )
3.1: levantar( )
113
Diseo e implementacin de mquinas de estados

Estado implcito. Estado explcito.
almacenado en un atributo del objeto. sentencias de control para variar el comportamiento en funcin del estado.
Patrn estado (variante del anterior):

asociacin con un objeto estado que almacena el estado actual. responde de modo polimrfico a los eventos recibidos (por cada estado hay una subclase con una nica instancia en cada momento).
Reproductor
Estado
signal on( ) signal off( ) signal play( ) signal stop( )
on( ): Estado estado off( ): Estado play( ): Estado stop( ): Estado
Apagado
Parado
Reproduccin
114
Secuencia de acciones en un cambio de estado

El reproductor recibe la seal 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 operacin on( ). Se destruye el viejo estado (Apagado).
Reproductor signal on( ) signal off( ) signal play( ) signal stop( ) 1 Estado on( ): Estado estado off( ): Estado play( ): Estado stop( ): Estado
Apagado
Parado
Reproduccin
r : Reproductor o : Oyente on( )
estado : Apagado
estado := on( )
new( )
nuevo : Parado
115
Aplicacin de las mquinas de estados al diseo de interfaces
Evitar ventanas superfluas y callejones sin salida. Habilitar en cada momento slo los botones que realmente pueden ejecutar una accin significativa. Los botones habilitados guan al usuario eficazmente por la aplicacin. Un buen diseo hace la navegacin mucho ms intuitiva.
Patrones de diseo
Introduccin a los patrones de diseo (Gamma, Helm, Johnson & Vlissides)
El catlogo de patrones de diseo Relaciones entre patrones de diseo Relaciones entre marcos y patrones Relaciones entre estilos arquitectnicos y patrones de diseo Descripcin de un patrn de diseo
Caso de estudio: Abstract Factory

Problema de mantenimiento: creacin de objetos Fbricas y productos
Cmo resolver problemas con patrones de diseo: Herencia vs. Delegacin Otros patrones de diseo
Decorator Command
Cmo seleccionar y usar un patrn de diseo
117
El catlogo de patrones de diseo

Propsito Creacin Clase
(Compilacin)
Estructura Adapter Adapter Bridge Composite Decorator Facade Flyweight Proxy
Comportamiento Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
Factory Method Abstract Factory Builder Prototype Singleton
mbito
Objeto
(Ejecucin)
118
Relaciones entre patrones de diseo

crear compuestos enumerar los hijos
guardar el estado de la iteracin
Memento Iterator
evitar la histresis
Builder
aadir responsabilidades a objetos compartir compuestos
Composite
combinadas usando
definir la gramtica
definir recorridos aadir operaciones
Decorator
compartir estrategias cambiar la piel en vez de las tripas
Flyweight
compartir smbolos terminales
Visitor
definir la cadena
Command
Strategy
compartir estados
Chain of Responsibility Interpreter

aadir operaciones gestin de dependencias complejas
State
definir los pasos de un algoritmo
Mediator Template Method
Prototype
configurar fabricas dinmicas
suele usar Implementado usando
Observer
instancia nica
Abstract Factory
instancia nica
Factory Method Facade Singleton

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software 119
Descripcin de un patrn de diseo

Abreviada Extendida
1. Nombre y clasificacin 2. Propsito 3. Tambin conocido como 4. Motivacin 5. Aplicabilidad 6. Estructura 7. Participantes 8. Colaboraciones 9. Consecuencias 10. Implementacin 11. Cdigo de ejemplo 12. Usos conocidos 13. Patrones relacionados
1. 2. 3. 4.
Nombre Problema Solucin Consecuencias
Abstract Factory: introduccin

Con este patrn se pretende resolver un problema bsico de programacin: los constructores no pueden invocarse de modo polimrfico.
Es decir, para instanciar un objeto es necesario mencionar su clase concreta. Esto genera ramificaciones condicionales y acoplamiento con las subclases. La solucin es un truco para acceder a los constructores de modo polimrfico, y as desacoplar al cliente de los constructores concretos.
Z declara una variable polimrfica de tipo A: cmo se le asigna un valor?
121
Abstract Factory: el problema y la solucin

// Cdigo problemtico public class Z { A a; switch () { case : a = new B( ); break; case : a = new C( ); break; } }
Resulta que Z no depende slo de A, tambin depende de B y C, y adems hay sentencias de ramificacin mltiple. En la solucin, en todo caso, siempre es necesario referirse a una clase concreta en algn lugar, dentro o fuera de Z. Pero usando Abstract Factory, la nica clase concreta mencionada es la factora concreta. Su utilidad es general, pero especialmente se manifiesta cuando la factora es capaz de responsabilizarse de una familia de productos.
// Cdigo mejorado public class Z { // instanciacin de f Factora f = ; // constructor polimrfico A a = f.createA( ); }
122
Caso de estudio (1): Abstract Factory Una situacin real:

Se desea desarrollar una aplicacin con interfaz grfica de usuario (GUI), que sea fcil de portar a dos sistemas operativos: Windows y Macintosh. Las GUI manejan una serie de objetos, generalmente conocidos como Widgets, tales como: ScrollBar, List, Button, etc.
Problema de diseo:
La GUI presenta una apariencia diferente (look and feel) para cada uno de de estos objetos en cada sistema operativo. La aplicacin debe poder crear los objetos con la apariencia apropiada para cada sistema operativo.
123
Caso de estudio (2): problema de mantenimiento

La creacin de Widgets es diferente en cada sistema:
ScrollBar sb = new WindowsScrollBar(); ScrollBar sb = new MacScrollBar();
Si se crean muchos Widgets (como suele ocurrir en aplicaciones de cierta complejidad) ser muy difcil cambiar de una apariencia a otra, dado que hay que modificar muchas instrucciones que estn diseminadas por diferentes partes del programa (problema de mantenimiento). Solucin: patrn de diseo Abstract Factory (fbrica abstracta).
Una fbrica es un objeto que se encarga de crear otros objetos.
Los elementos de este patrn son:

Una fbrica abstracta y varias fbricas concretas. Un familia de productos abstractos y varias familias de productos concretos.
Caso de estudio (3): fbricas y productos

Para toda la aplicacin: - una fbrica abstracta - dos fbricas concretas
ScrollBar scrollTo() GUIFactory createScrollBar() createButton() createMenu() Button press() Menu popUp() Widget
WindowsScrollBar scrollTo()
MacScrollBar scrollTo()
WindowsFactory createScrollBar() createButton() createMenu()
MacFactory createScrollBar() createButton() createMenu()
Por cada tipo de Widget: - un producto abstracto - dos productos concretos
125
Caso de estudio (4): solucin al problema de mantenimiento

Creacin de Widgets con contructores concretos, antes
ScrollBar sb = new WindowsScrollBar(); ScrollBar sb = new MacScrollBar();
y despus, a travs de operaciones abstractas de la fbrica.

ScrollBar sb = guiFactory.createScrollBar();
Hemos transformado la ramificacin condicional en invocacin polimrfica. La variable global guiFactory debe ser inicializada al comienzo del programa con una de las fbricas concretas:
GUIFactory guiFactory = new MacFactory();
Las operaciones de creacin en las fbricas concretas usan los constructores concretos (Factory Method: invocar un constructor mediante una operacin):
public ScrollBar createScrollBar() {return new WindowsScrollBar();} public ScrollBar createScrollBar() {return new MacScrollBar();}
126
Abstract Factory: ejemplo
Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 127
Abstract Factory: patrn
Herencia vs. Delegacin
C x( )
1 c x( )
1 c
A x( ) x( )
c.x( )
Dos formas de reutilizar / refactorizar
c.x( )
129
Flexibilidad: combinar herencia y delegacin
La combinacin de asociacin/delegacin y herencia posibilita modificar el comportamiento en tiempo de ejecucin.

Decorator: ejemplo (editor de texto)
Decorator: ejemplo (scroll y borde)

Advertencias sobre la notacin en Gamma: los roles se nombran al revs que en UML la flecha negra indica multiplicidad mnima 1. component->Draw( ) component.Draw( ) Decorator::Draw( ) super.Draw( )
Decorator: patrn
Decorator: alternativas
No requieren aadir generalizacin a TextView. Preservan la identidad de los objetos. Pero se pierde la esencia de Decorator: que el objeto no sepa que ha sido decorado. Alternativa 1
El nmero y tipo de decoradores est rgidamente determinado en tiempo de compilacin. Hay que aadir un atributo a TextView por cada decorador y modificar la operacin draw original (y todas las operaciones decoradas).
Alternativa 2
Menor impacto sobre TextView: aadir un solo atributo, modificar una vez todas las operaciones para iterar sobre todos los decoradores. Variante: cadena en lugar de lista (patrn Chain of Responsibility)
134
Command: ejemplo (men y paste)
Command: ejemplo (open y macro)
Command: patrn
Cmo seleccionar un patrn de diseo

Objetivo Proporcionar una interfaz nica que d acceso a un conjunto de objetos de diversas clases Conseguir que un objeto se comporte de manera determinada por su estado actual Encapsular diversas formas de visitar los objetos de una coleccin, de tal modo que el cdigo cliente pueda seleccionar una de ellas en tiempo de ejecucin Facilitar la respuesta de entidades interesadas en los cambios de una fuente de informacin Interpretar sentencias escritas en una gramtica formal Patrn Facade State Iterator Observer Interpreter
138
Herencia mltiple Qu es la herencia mltiple

Frente a clasificacin mltiple Frente a interfaces mltiples
Cundo es necesaria
Desempear dos o ms roles Reutilizar y redefinir cdigo
Soluciones parciales
Interfaces Delegacin
Problemas conceptuales Estrategia de implementacin

Limitaciones
139
Qu es la herencia mltiple?
A x p( ) y q( ) B x p( ) A y q( ) B Interface A p( ) Interface B q( )
C p( ) instance of instance of x y p( ) q( )
instance of c1 c1
instance of c1
Herencia mltiple
Clasificacin mltiple
Interfaces mltiples
140
Cundo es necesaria la herencia mltiple?

A p( ) q( ) B public class C extends A, B { public p ( ) { ... super.p( ); ... }; public q ( ) { ... super.q( ); ... }; } // ficticio!
Reutilizar y redefinir operaciones
C p( ) q( ) instance of c1
Desempear roles distintos
public class Main { public static void main(String[] args) { C c1 = new C( ); A a1 = c1; B b1 = c1; a1.p( ); b1.q( ); } }
141
Herencia mltiple: soluciones parciales

Interface A p( ) Interface B p( ) q( ) a 1 A q( ) b 1 B
C p( ) q( ) p( ) q( )
C a.p( ) b.q( ) instance of c1
instance of c1
Interfaces: desempear roles distintos
Delegacin: reutilizar y redefinir operaciones

142
Herencia mltiple: problemas conceptuales
D x p( )
E x p( ) x p( )
Qu hace G.p( )?
x p( )
Qu es G.x?
143
Herencia mltiple: estrategia de implementacin

Interface iA p( ) A p( ) q( ) p( ) B A q( ) B Interface iB q( )
C p( ) q( )
Ca
1 ca p( ) q( )
1 cb
Cb
ca.p( ) cb.q( )

Unidades 14 A 28

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unidades 14 A 28

Uploaded by

Copyright:

Available Formats

Ingeniera del Software II Ingeniera Informtica, 4Curso

Proyecto Prctico de Diseo de Software

Proyecto Prctico de Diseo de Software

Direccin para entregas de la prctica: is.uc3m [at] gmail.com Web de la asignatura

Un curso de anlisis y diseo en dos asignaturas:

Programa de la asignatura: teora

Tema IV Diseo detallado (diseo de bajo nivel)

Programa de la asignatura: prcticas

Dos documentos de revisin:

Proyecto final revisado (normas):

Propuesta de preguntas tericas para el examen de test

Ingeniera del Software 2:

Proyecto Prctico de Ingeniera de Requisitos

Formato de los documentos

Extensin (porque queremos calidad, no cantidad):

Trabajo en equipo y dedicacin a la prctica

La proporcin entre trabajo individual y en equipo debera ser 4/1 3/1.

Nombre Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez

Ind. Eq. TOTAL 25 25 25 25 35 35 35 35 60 60 60 60 240

Nombre Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez

Ind. Eq. TOTAL 40 43 47 50 15 11 16 18 60 55 54 63 68 240

TOTAL 100 140 MAL

TOTAL 180 BIEN

Proyecto Proyecto Prctico Prctico dede Ingeniera Diseo de deSoftware Requisitos

Exmenes parciales*** 10% Propuesta de Examen final 30% preguntas 50%

Modelado con UML

Proyecto Prctico de Diseo de Software

Proyecto Prctico de Diseo de Software

Transformacin de modelos: del anlisis al diseo

Proyecto Prctico de Diseo de Software

Transformacin de modelos: del anlisis al diseo

especificacin B descripcin A C realidad abstracto concreto dominio sistema

Proyecto Prctico de Diseo de Software

Relacin lgico-temporal entre el anlisis y el diseo

Iteracin 1 Anlisis (versin 1)

Iteracin 2 Anlisis (versin 2) Diseo (versin 1)

Iteracin 3 Anlisis (versin 3) Diseo (versin 2) Implementacin (versin 1)

Proyecto Prctico de Diseo de Software

El diseo arquitectnico en el Estndar ESA

Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)

Guide to the software architectural design phase (PSS-05-04)

El diseo detallado en el Estndar ESA

5.4. Salidas: omitir cdigo y manual de usuario

Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)

Guide to the software detailed design and production phase (PSS-05-05)

Proyecto Prctico de Diseo de Software

Introduccin al diseo arquitectnico Arquitectura del software

Cmo lograr una descomposicin modular eficaz?

Criterios para la seleccin de una arquitectura

Reutilizacin de diseos y componentes

Proyecto Prctico de Diseo de Software

Relacin entre anlisis, arquitectura y diseo detallado

Barandilla Cable 4. Diseo Detallado

Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective

Estilos arquitectnicos de puentes

Proyecto Prctico de Diseo de Software

Arquitectura del software: definiciones

Len Bass 1998

IEEE Std. 1471-2000

Proyecto Prctico de Diseo de Software

Cmo lograr una buena descomposicin modular A B C A D E

Proyecto Prctico de Diseo de Software

Descomposicin modular recursiva: 72