Unidades14a28-PPT.pdf

1 Proyecto Práctico de Diseño de Software

Ingeniería del Software IIIngeniería Informática, 4°Curso

Proyecto Práctico de Diseño de Software

Curso 2010-2011

Gonzalo Génova


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– http://www.ie.inf.uc3m.es/grupo/docencia/reglada/Is1y2/IS2.htm

• 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)


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


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


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


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

7 Proyecto Práctico de Ingeniería de Requisitos

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.


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.

60 120 páginas

1

0

0

penalización

1-(p-60)/60

9 Proyecto Práctico de Diseño de SoftwareProyecto Práctico de Ingeniería de Requisitos

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 25 35 60

Juan Gómez 25 35 60

Isabel López 25 35 60

Pedro Fernández 25 35 60

TOTAL 100 140 240

Nombre Ind. Eq. TOTAL

Ana García 40 15 55

Juan Gómez 43 11 54

Isabel López 47 16 63

Pedro Fernández 50 18 68

TOTAL 180 60 240

MAL BIEN

10 Proyecto Práctico de Ingeniería de Requisitos

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.

11

* 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)

Proyecto Práctico de Ingeniería de Requisitos

Evaluación de la asignatura

Individual Equipo

Práctica

Tutorías* 00% Exp/Preparación 05%

50%Exp/Ejecución** 05% Documentación 30%

Exp/Respuestas 05% Revisiones 05%

TeoríaExámenes parciales*** 10% Propuesta de

preguntas10% 50%

Examen final 30%

50% 50% 100%

Más detalles


Bibliografía

• Diseño arquitectónico, diseño detallado– Eric Braude. Software Engineering. An Object-Oriented Perspective. John Wiley & Sons,

2001.• Capítulos 5 y 6

– Ian Sommerville. Software Engineering, 7th ed. Pearson-Addison Wesley, 2004. • Capítulos 11-16

– 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, 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.

• Más en la ficha de la asignatura


Tema IIIDiseñ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)


Especificación

Vista abstracta

modelo especificativo abstracto del dominio

modelo especificativo abstracto del sistema

Vista

concreta

modelo especificativo

concreto del dominio

modelo especificativo

concreto del sistema

Descripción

Vista

abstracta

modelo descriptivo

abstracto del dominio

modelo descriptivo

abstracto del sistema

Vista concreta

modelo descriptivo concreto del dominio

modelo descriptivo concreto del sistema

Dominio Sistema

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


Transformación de modelos: del análisis al diseño

A

B

C

propósito

abstracción

especificación

abstractosistema

descripción

concreto

realidaddominio


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)

Análisis

(versión 3)

Diseño

(versión 1)

Diseño

(versión 2)

Implementación

(versión 1)


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-05• 3.5. 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


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

– 5.3.1. 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-05

• 3.6. 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


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


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.”

3. Arquitectura2. Clases deDominio

Vehículo

Camino

vehículo

Camino

4. Diseño

Detallado

Cable

Cable

Columna

Columna

Barandilla

Adaptado de E. Braude,

Software Engineering:

An Object-Oriented Perspective

Relación entre análisis, arquitectura y diseño detallado


Estilos arquitectónicos de puentes


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. 1471-2000

– 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.


Cohesión y acoplamiento

1

2 3 4

5 6Alta cohesión Bajo acoplamientoPuente

componente

componente


Software Engineering: An Object-Oriented Perspective


Cómo lograr una buena descomposición modular

A B C

D E F

Mal

A D E

B C F

Bien

¿Cómo acertar de antemano? � Estilos arquitectónicos


Descomposición modular recursiva: 7±2


Criterios para la selección de una arquitectura

• Criterios clásicos:

– Extensibilidad

– Modificabilidad

– Simplicidad

– Eficiencia

• Otros criterios:

– Reuso

– Escalabilidad

– Coste

– Requisitos no funcionales


Reutilización

• Diseños reutilizables

– 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


Descomposición basada en marcos de trabajo

Capa de marcos

Capa de aplicación

Java.awt

MiAplicación

Window

VentanaDialogo Empleado

1 ventanaEmpleado

29

Noción de “componente”

Unidad autónoma, reemplazable y reutilizable, habitualmente ejecutable…



Niveles de descomposición modular (UML 2.x)

Nivel 1Subsistema

Nivel 2Componente

(...)Nivel N-1

ComponenteNivel NClase

(UML 1.x)

(UML 1.x)


Noción de dependencia

<<component>>

A

<<component>>

B

<<component>>

C

E F

Dependencia A�C:

• A requiere la presencia de C

• Los cambios de C pueden afectar a A


Noción de interfaz

Dos componentes pueden ofrecer la misma interfaz

Dos interfaces no necesariamente

disjuntas


Representación de interfaces: abreviada y completa

Novedad en UML2


Cómo instanciar las interfaces de un componente (1)package GestiónEmpleados;

public interface iEmpleado {

public modificar( ) { };

…

}

public class EmpleadoFijo implements iEmpleado {


…

}

public class EmpleadoTemporal implements iEmpleado {


…

}

====================

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”.



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( )

…

}

====================


…

int e = ge.crearEmpleado ( ); // se supone que existe GestorEmpleados ge

…

ge.modificarEmpleado(e);

…

}

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).

El componente proporciona sólo una interfaz, el gestor.

La clase cliente sólo usa el gestor y los identificadores públicos.



public interface iEmpleado {


…

}

public interface iGestorEmpleados {

public iEmpleado crearEmpleado( ); // el gestor debe mantener algún tipo de lista

public modificarEmpleado(iEmpleado e);

…

}

====================


…

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.

El componente proporciona dos interfaces, el tipo abstracto de datos y el gestor.


Cómo instanciar las interfaces de un componente (4)

Caso 1 Caso 2(parámetros int)

Caso 3 (parámetros iEmpleado)


Interfaces proporcionadas y requeridas

requiere,

usa

proporciona,

realiza


Cableado de componentes

“ball and socket”

cableado “en árbol”

cableado “independiente”

cableado con dependencia


Anidamiento de componentes

delegación

puerto

El conjunto de interfaces de un puerto debe ser consistente


Diagrama de despliegue

entorno de ejecución software

dispositivo hardware

nodo ruta de comunicación


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 31-41

43

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.


44

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/

• …



Altova Umodel: Instalación

• Ir a:

– http://www.altova.com/download/umodel/uml_tool_enterprise.html

– 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).


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 delcuatrimestre.

– 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).


Aspecto de la herramienta


Diagramas importantes para IS2

• Diagrama de Componentes

• Diagrama de Clases

• Diagrama de Despliegue


El modelo de 4+1 vistas arquitectónicas

Vista lógica(conceptual)

Vista de proceso(ejecución)

Vista de desarrollo(implementación)

Vista física(despliegue)

Vista de casos de uso

Ingeniería del Software I Ingeniería del Software II


Características de cada vista en el modelo 4+1

VistaLógica

(conceptual)Proceso

(ejecución)Desarrollo

(implementación)Física

(despliegue)

AspectoModelo de información

Concurrencia y sincronización

Organización del software en el entorno de desarrollo

Correspondencia software-hardware

StakeholdersUsuarios

finalesIntegradores 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ónClases y

asociacionesProcesos y

comunicaciones

Componentes y

relaciones de uso

Nodos y rutas de comunicación



Relaciones entre las cuatro vistas

Vista lógica(conceptual)

Vista de proceso(ejecución)

identificar clases

activas

Vista de desarrollo(implementación)

minimizar dependencias

nuevas clases de diseño

Vista física(despliegue)

requisitos no funcionales

?



Vista de casos de uso



Vista lógica (conceptual)



Vista de proceso (ejecución)



Vista de desarrollo (implementación)



Vista física (despliegue)



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



Arquitectura de flujo de datos: DFDs

crear

cliente

cajero

finaliza con

cliente

asignar

cliente a

cajero

informar

log de estadísticas

lista de clientes / cajeros

lista de cajeros libres cola de clientes

tiempo de llegada de clientes

tiempo medio entre

llegadas de clientes

- nº de cajeros

- velocidad media de cada cajero

- tiempo medio de llegada entre clientes

crear

banco

Adaptado de W. Haythorn,

What Is Object-Oriented Design?


Arquitectura de tuberías y filtros

filter

filter

filter

filter filter

filter

pipe

< stream

stream >



pipe


Arquitectura cliente-servidor

Catalogue

server

Librarycatalogue

Video

server

Film clip

files

Picture

server

Digitised

photographs

Web server

Film and

photo info

Client 1 Client 2 Client 3 Client 4

Internet

Adaptado de I. Sommerville,

Software Engineering


Arquitectura de procesos paralelos

Customer:customer n

withdraw

Customer:customer n+1

Session:session k

Session:session m

deposit

create

Account:customer n+1 saving

Account:customer nchecking

create retrieve

retrieve






Arquitectura de sistema de eventos

Sub-system

1

Event and message handler

Sub-system

2

Sub-system

3

Sub-system

4


Arquitectura de máquina virtual

260Mhz & 64MB

400Mhz & 128MB

260Mhz & 32MB

assemble {

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

}






Arquitectura de repositorio

Project

repository

Design

translatorProgram

editor

Design

editor

Code

generator

Design

analyser

Report

generator


Arquitectura en capas: modelo OSI

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communications medium

Application

Presentation

Session

Transport

Network

Data link

Physical

Application

Network

Data link

Physical




Arquitectura en capas: juegos interactivos

Definición de reglas

del juego

Jugador TurnoMovimiento

Lanzamiento

de Dado

Selección

de Ficha

Avance y Captura

Ejecución de movimientos

Representación

gráfica




Arquitectura modelo-vista-controlador (original)



C

M

V

Acciones del

usuario

Información

al usuario

Controlador

Modelo

Vista

Modificaciones en la vista

Consultas y

modificaciones

en el modelo

Consultas al

modelo


Arquitectura modelo-vista-controlador (moderna)

Vista

Modelo

Controlador

Comunicación con el usuario

Comportamientos complejos

Consultas en

el modelo

Consultas y modificaciones

en el modelo

V

M

C

C

M

VModelo-Vista-Controlador original


Arquitectura en Cuatro Capas


Arquitectura en Tres Escalones


Tema IVDiseñ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


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


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

• Invariantes de clase

– CuentaCorriente: saldo ≥ 0

CuentaCorriente

saldo

meterDinero(cantidad)

sacarDinero(cantidad)


Diseño por contratos: subcontratación

• PPC’s de operación

– CuentaCorriente.sacarDinero(cantidad: Moneda)

• Pre: saldo – cantidad ≥ 0


• PPC’s de operación redefinida en la subclase

– CuentaCredito.sacarDinero(cantidad: Moneda)

• Pre: saldo + credito – cantidad ≥ 0


– 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


CuentaCredito

credito


¿Es correcta esta generalización?


Diseño por contratos: uso correcto de jerarquías

• CaminoOblicuo.distancia.post

• CaminoEsquinado.distancia.post

2

12

2

12 )()( yyxxd −+−=

)()( 1212 yyxxd −+−=

CaminoOblicuo

origen: Punto

distancia( ): Float

destino: Punto

CaminoEsquinado

origen: Punto

distancia( ): Float

destino: Punto

¿Cuál sería correcta?

(x1, y1)

(x2, y2)


Especificación de algoritmos

m4

m100

m400

no bisiesto bisiesto

[sí]

[sí]

[no]

[no]

[no]

[sí]

Bisiesto (x) =

m4(x) AND (

(NOT m100(x) OR

(m100(x) AND m400(x)))

= m4(x) AND (NOT m100(x) OR m400(x))

NoBisiesto (x) =NOT m4(x) OR (m100(x) AND NOT m400(x))


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


Asignación polimórfica de “variables”

: CuentaCredito juan: Persona

public class CuentaCorriente {

}

public class CuentaCredito extends CuentaCorriente {

}

public class Persona {

private CuentaCorriente titularDe;public asignarCuenta (CuentaCorriente cc) {

titularDe = cc;

}

}

public class Main {

public static void main(String[] args) {

Persona juan = new Persona();

CuentaCorriente ccr = new CuentaCredito();juan.asignarCuenta(ccr);

}

}

PersonaCuentaCorrientetitularDe

CuentaCredito

Variable polimórfica

Argumento polimórfico


Invocación polimórfica de operaciones


public Moneda saldo;

public void sacarDinero (Moneda cantidad) { } }

public class CuentaCredito extends CuentaCorriente {

public Moneda credito;

public void sacarDinero (Moneda cantidad) { } }


private CuentaCorriente titularDe;

public asignarCuenta (CuentaCorriente cc) {

titularDe = cc; }

public sacarDinero (Moneda cantidad) {

titularDe.sacarDinero(cantidad); }}

public class Main {



CuentaCorriente ccr = new CuentaCredito();

juan.asignarCuenta(ccr);

juan.sacarDinero(100); }

}

sacarDinero(100)

: CuentaCredito juan: Persona

Persona

CuentaCorriente

titularDesaldo


CuentaCredito

credito


Asignación polimórfica

Invocación polimórfica


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

sobrecargasobreescritura (polimorfismo)

CuentaCorriente

saldo


CuentaCredito

credito


sacarDinero( )


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 = 3posiciónY = -5

PuntoposiciónX: CoordenadaposiciónY: CoordenadaobtenerPosición( ): CoordenadasPolaresobtenerPosición( ): CoordenadasCartesianas

c := obtenerPosición ( )¿Qué operación se invoca? Depende del tipo de “c”...

«instance of»

Clase mal definida


Distinción de operaciones por su signatura

Nombre Signatura Clase Resultado

distinto distinta

igual

distintamisma sobrecarga

subclase sobrecarga

igualmisma error

subclase sobreescritura

• 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).

CuentaCorriente

saldo

sacarDinero(cantidad: Moneda)sacarDinero(cantidad: MonedaEuropea)

CuentaCredito

credito

sacarDinero(cantidad: Moneda)sacarDinero(cantidad: MonedaEuropea)


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

Protected Protected-Friend

friendlyFriend

(Internal)Protected

Private Private Private


Visibilidad privada entre objetos de la misma clase

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;

}

}

class Main {

public static void main(String[] args) {Elemento e1=new Elemento(“e1”);

Elemento e2=new Elemento(“e2”);

e1.prueba(e2);

}

}

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.

• 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.


Visibilidad privada entre clase y 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)

}

public int area () { return base * base }

}

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.

� 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.

• 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.


Figuraposición

dibujar( )

Rectángulobase

altura

dibujar( )

Cuadrado{base=altura}

dibujar( )

Círculoradio

dibujar( )

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).

• 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.


• 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).

Notaciones para uso y realización de interfaces

Documento

ImprimibleImpresora

Interfaces

Documento

«interface»Imprimible

imprimir( )

Impresora


«interface»

Figura

Círculo Rectángulo

Cuadrado

«interface»

Imprimible

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


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”


banco : Banco

cuenta1 : Cuenta

cuenta2 : Cuenta

1: sacarDinero( )

2: meterDinero( )

banco : Banco cuenta1 : Cuenta cuenta2 : Cuenta

sacarDinero( )

meterDinero( )

Modelado dinámico: diagramas de interacción

Diagrama de colaboración

Transferencia de dinero entre dos cuentas:- sacar dinero de una cuenta, y- meter el dinero en la otra cuenta.

Mensaje

Diagrama de secuencia

Objeto


banco : Banco

Ana : Cliente

origen : Cuenta destino : Cuenta

sacarDinero( )

meterDinero( )

emitirTransferencia( )

¿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.

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.


CuentaCorrientesaldo

obtenerSaldo( )

CuentaCréditocredito

obtenerCredito( )

esDisponible(cantidad): boolean

ok :=

(cantidad <= c + s)

b : Banco cc : CuentaCrédito

ok := esDisponible(cantidad)

s := obtenerSaldo( )

c := obtenerCredito( )

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).


banco : Banco

Ana : Cliente


sacarDinero( )

meterDinero( )


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

Ana : Cliente

origen : Cuenta

destino : Cuenta

1.1: sacarDinero( )

1.2: meterDinero( )1: emitirTransferencia(origen, destino, cantidad)

banco : Banco

Ana : Cliente


sacarDinero( )

meterDinero( )


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.


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).

Señales que aceptan los objetos

de una clasebanco1 : Banco banco2 : Banco banco3 : Banco

transferenciaSolicitada(número, datos)

transferenciaSolicitada(número, datos)

transferenciaAceptada(número)

transferenciaDenegada(número)

Banco

«signal» transferenciaSolicitada( )

«signal» transferenciaAceptada( )

«signal» transferenciaDenegada( )


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

r

p

q

s


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.

Asociación

Especificación de un conjunto de conexiones entre instancias.

Representan la estructura y posibilidades de

comunicación del sistema.

Generalización

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ónRelación donde un elemento realiza o implementa la especificación dada por otro elemento.


Figura

FiguraColoreada Color1

miColor

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

FiguraColoreada Color

PosicionVector

generalización

asociación

variable localparámetro

(asociaciones contextuales)


banco : Banco

Ana : Cliente

origen : Cuenta

destino : Cuenta

«parameter»

1.1: sacarDinero(cantidad)

«parameter»

1.2: meterDinero(cantidad) 1: emitirTransferencia

(origen, destino, cantidad)

«self»

1.1.1: ok :=

esDisponible(cantidad)

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


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)

Diagramas de clases

(modelo estático)

Objeto Instancia de clase

EnlaceInstancia de asociación

(excepto enlaces contextuales)

MensajeOperación o señal visible en la

(super)clase receptora


banco : Banco cuenta1 : CuentaCorriente

cuenta2 : CuentaCrédito

s := obtenerSaldo( )

abrirCuenta(s)

cerrarCuenta( )

Creación y destrucción de objetos

{transient}=

{new} + {destroyed}

Cancelar una cuenta y transferir el saldo a una nueva de otro tipo

banco : Banco

cuenta1 : CuentaCorriente

{destroyed}

cuenta2 : CuentaCrédito

{new}

1: s := obtenerSaldo( )

3: cerrarCuenta( )

2: abrirCuenta(s)


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

titular : Titularcuenta1 : Cuenta cuenta2 : Cuenta

2: desasignarTitular(titular)

{destroyed}{new}

1: asignarTitular(titular)


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.


¿Qué prohíbe la Ley de Demetra?


private Moneda saldo;

public Moneda obtenerSaldo() { }

}


private CuentaCorriente titularDe;

public asignarCuenta (CuentaCorriente cc) {

titularDe = cc; }

public void mostrarSaldoActual() {titularDe.obtenerSaldo().escribir();

}

}

public class Main {



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.


private CuentaCorriente titularDe;public asignarCuenta (CuentaCorriente cc) {

titularDe = cc; }

public void mostrarSaldoActual() {

Moneda saldo = titularDe.obtenerSaldo();

saldo.escribir();}

}


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.


Estacionado VolandoEstacionado Volando

despegar

aterrizar

retirar colisionar

Máquinas de estados: estados, eventos y transiciones

Transición

EstadoEvento

Pseudo-estado inicial

Estado final

Los eventos causan las

transiciones entre estados.

Los eventos de creación y destrucciónpueden ser implícitos o explícitos.

Clase Avión


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.

Personaedad

Empresa1..*

0..1 Jubilado

Parado

Trabajando

Jubilado

Parado

Trabajando

jubilar

jubilar

contratardespedir

Clase Persona


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– 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.

ReproducciónApagado Parado ReproducciónApagado Parado

on

off

play

stop

after(60 s) when(velocidad < 5 cm/s)

misma notación

Clase Reproductor



on

off

play[hayCinta and (not atascada)]

stop

after(60 s) when(velocidad < 5 cm/s)

play[(not hayCinta) or atascada]

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.).

Clase Reproductor

Guardas


• 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).

Transiciones con acciones

Clase Reproductor

Acciones


on

off

play[hayCinta and (not atascada)]/altavoz.on

stop/altavoz.off

after(60 s) when(velocidad < 5 cm/s)/altavoz.off

play[(not hayCinta) or atascada]


Reproducción

entry / altavoz.onexit / altavoz.offdo / reproducir

Reproducción

entry / altavoz.onexit / altavoz.offdo / reproducir

cambiarVolumen(delta)/vol:= vol + delta

Reproducción

cambiarVolumen(delta) / vol:= vol + deltado / reproducir

Reproducción

cambiarVolumen(delta) / vol:= vol + deltado / reproducir

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).

AutotransiciónEvento interno


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.

Mensajes salientes: destinatario(s) designado(s) por el nombre de rol

ReproductorhayCintaatascada

velocidadvolumen

«signal» on( )«signal» off( )«signal» play( )

«signal» stop( )«signal» cambiarVolumen(delta)

reproducir( )

Altavoz

on( )

off( )

1

altavoz


Comunicación entre máquinas de estados

Sentado

Levantado

Sentado

Levantado

mover/levantar after(2 s)

/sentar; siguiente.mover

Elemento

«signal» mover( )levantar( )sentar( )

1

siguiente

e1 : Elemento e2 : Elemento e3 : Elemento

2: mover( ) 3: mover( )1: mover( )

1.1: levantar( )

1.2: sentar( )

2.1: levantar( )

2.2: sentar( )

3.1: levantar( )

4: mover( )

3.2: sentar( )


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( )

Apagado Parado

Estado

on( ): Estadooff( ): Estadoplay( ): Estadostop( ): Estado

Reproducción

1

estado


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

Estado

on( ): Estado

off( ): Estado

play( ): Estado

stop( ): Estado

Reproducción

1

estado

r : Reproductor estado : Apagado

o : Oyente

nuevo : Parado

on( )estado := on( )

new( )


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.


Patrones de diseño

• Introducción a los patrones de diseño (Gamma, Helm, Johnson & Vlissides)

– El catálogo de patrones de diseño

– Relaciones entre patrones de diseño

– Relaciones entre marcos y patrones

– Relaciones entre estilos arquitectónicos y patrones de diseño

– Descripción de un patrón de diseño

• Caso de estudio: Abstract Factory

– Problema de mantenimiento: creación de objetos

– Fábricas y productos

• Cómo resolver problemas con patrones de diseño: Herencia vs. Delegación

• Otros patrones de diseño

– Decorator

– Command

• Cómo seleccionar y usar un patrón de diseño


El catálogo de patrones de diseño

Propósito

Creación Estructura Comportamiento

Ámbito

Clase(Compilación)

Factory Method Adapter Interpreter

Template Method

Objeto(Ejecución)

Abstract Factory

Builder

Prototype

Singleton

Adapter

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

Chain of Responsibility

CommandIterator

Mediator

Memento

Observer

State

Strategy

Visitor


Relaciones entre patrones de diseñoMemento

Iterator

Builder

Command

Composite

Decorator Flyweight

Visitor

Interpreter

Chain of ResponsibilityStrategy

Mediator

Observer

State

Template Method

Prototype

Singleton

Facade

Abstract Factory

Factory Methodinstancia única

instancia única

configurar fabricas dinámicas

definir los pasos de un algoritmo

cambiar la piel en vez de las tripas

Implementado usando

gestión de dependencias

complejas

suele usar

crear compuestos

añadir responsabilidades a objetoscompartir

compuestos

compartir estrategias

compartir estados

añadir operaciones

añadir operaciones

compartir símbolos

terminales

definir la gramática

guardar el estado de la

iteración

evitar la histéresis

enumerar los hijos

combinadas usando

definir la cadena

definir recorridos

Adaptado de E. Gamma et al., Design Patterns:

Elements of reusable Object-Oriented software


Descripción de un patrón de diseño

Abreviada Extendida

1. Nombre

2. Problema

3. Solución

4. Consecuencias

1. Nombre y clasificación

2. Propósito

3. También conocido como

4. Motivación

5. Aplicabilidad

6. Estructura

7. Participantes

8. Colaboraciones

9. Consecuencias

10. Implementación

11. Código de ejemplo

12. Usos conocidos

13. Patrones relacionados

121

Abstract Factory: introducción

• Con este patrón se pretende resolver un problema básico de programación:

los constructores no pueden invocarse de modo polimórfico.

– Es decir, para instanciar un objeto es necesario mencionar su clase concreta.

– Esto genera ramificaciones condicionales y acoplamiento con las subclases.

– La solución es un “truco” para acceder a los constructores de modo “polimórfico”, y así desacoplar al cliente de los constructores concretos.

• Z declara una variable polimórfica de tipo A: ¿cómo se le asigna un valor?


122

Abstract Factory: el problema y la solución

• Resulta que Z no depende sólo de A, también depende de B y C, y además hay sentencias de ramificación múltiple.

• En la solución, en todo caso, siempre es necesario referirse a una clase concreta en algún lugar, dentro o fuera de Z. Pero usando Abstract Factory, la única clase concreta mencionada es la factoría concreta.

• Su utilidad es general, pero especialmente se manifiesta cuando la factoría es capaz de responsabilizarse de una familia de productos.

// Código problemáticopublic class Z {

…

A a;

switch (…) {case …: a = new B( ); break;

case …: a = new C( ); break;

…

}

}

// Código mejoradopublic class Z {

…// instanciación de fFactoría f = …;

…

// “constructor” polimórficoA a = f.createA( ); …

}



Caso de estudio (1): Abstract Factory

• Una situación real:

– Se desea desarrollar una aplicación con interfaz gráfica de usuario (GUI),

que sea fácil 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 diseño:

– La GUI presenta una apariencia diferente (look and feel) para cada uno

de de estos objetos en cada sistema operativo.

– La aplicación debe poder crear los objetos con la apariencia apropiada para cada sistema operativo.


Caso de estudio (2): problema de mantenimiento

• La creación 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 difícil cambiar de una apariencia a otra, dado que hay

que modificar muchas instrucciones que están diseminadas por diferentes

partes del programa (problema de mantenimiento).

• Solución: patrón de diseño Abstract Factory (fábrica abstracta).

– Una “fábrica” es un objeto que se encarga de crear otros objetos.

• Los elementos de este patrón son:

– Una fábrica abstracta y varias fábricas concretas.

– Un familia de productos abstractos y varias familias de productos concretos.


Caso de estudio (3): fábricas y productos

WindowsFactoryWindowsFactoryWindowsFactoryWindowsFactory

createScrollBar()

createButton()

createMenu()

MacFactoryMacFactoryMacFactoryMacFactory

createScrollBar()

createButton()

createMenu()

GUIFactoryGUIFactoryGUIFactoryGUIFactory

createScrollBar()createButton()

createMenu()

WidgetWidgetWidgetWidget

WindowsScrollBarWindowsScrollBarWindowsScrollBarWindowsScrollBar

scrollTo()

MacScrollBarMacScrollBarMacScrollBarMacScrollBar

scrollTo()

ScrollBarScrollBarScrollBarScrollBar

scrollTo()

ButtonButtonButtonButton

press()

MenuMenuMenuMenu

popUp()

Para toda la aplicación:

- una fábrica abstracta

- dos fábricas concretas

Por cada tipo de Widget:

- un producto abstracto

- dos productos concretos


Caso de estudio (4): solución al problema de mantenimiento

• Creación de Widgets con contructores concretos, antes…– ScrollBar sb = new WindowsScrollBar();

– ScrollBar sb = new MacScrollBar();

• …y después, a través de operaciones abstractas de la fábrica.– ScrollBar sb = guiFactory.createScrollBar();

• Hemos transformado la ramificación condicional en invocación polimórfica.

• La variable global guiFactory debe ser inicializada al comienzo del programa con una de las fábricas concretas:– GUIFactory guiFactory = new MacFactory();

• Las operaciones de creación en las fábricas concretas usan los constructores concretos (Factory Method: invocar un constructor mediante una operación):– public ScrollBar createScrollBar() {return new WindowsScrollBar();}

– public ScrollBar createScrollBar() {return new MacScrollBar();}


Abstract Factory: ejemplo

Adaptado de E. Gamma et al.,

Design Patterns: Elements of reusable Object-Oriented software


Abstract Factory: patrón




Herencia vs. Delegación

c.x( ) c.x( )

A

x( )

B

x( )

C

x( )

1

c

1

c

Dos formas de reutilizar / refactorizar

A B

C

x( )


Flexibilidad: combinar herencia y delegación

La combinación de asociación/delegación y herencia posibilita modificar el comportamiento en tiempo de ejecución.



Decorator: ejemplo (editor de texto)




Decorator: ejemplo (scroll y borde)



Advertencias sobre la notación en Gamma:

• los roles se nombran al revés que en UML

• la flecha negra indica multiplicidad mínima 1.

• component->Draw( ) ≡ component.Draw( )

• Decorator::Draw( ) ≡ super.Draw( )


Decorator: patrón




Decorator: alternativas

• No requieren añadir generalización 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 número y tipo de decoradores está

rígidamente determinado en tiempo de compilación.

– Hay que añadir un atributo a TextView por cada decorador y modificar la operación draworiginal (y todas las operaciones decoradas).

• Alternativa 2– Menor impacto sobre TextView: añadir un

solo atributo, modificar una vez todas las operaciones para iterar sobre todos los decoradores.

– Variante: cadena en lugar de lista (patrón Chain of Responsibility)



Command: ejemplo (menú y paste)




Command: ejemplo (open y macro)

Adaptado de E. Gamma et al., Design Patterns:

Elements of reusable Object-Oriented software


Command: patrón




Cómo seleccionar un patrón de diseño

Objetivo Patrón

Proporcionar una interfaz única que dé acceso a un

conjunto de objetos de diversas clasesFacade

Conseguir que un objeto se comporte de manera

determinada por su estado actualState

Encapsular diversas formas de “visitar” los objetos de

una colección, de tal modo que el código cliente pueda

seleccionar una de ellas en tiempo de ejecución

Iterator

Facilitar la respuesta de entidades interesadas en los

cambios de una fuente de informaciónObserver

Interpretar sentencias escritas en una gramática formal Interpreter

139

Herencia múltiple

• Qué es la herencia múltiple

– Frente a clasificación múltiple

– Frente a interfaces múltiples

• Cuándo es necesaria

– Desempeñar dos o más roles

– Reutilizar y redefinir código

• Soluciones parciales

– Interfaces

– Delegación

• Problemas conceptuales

• Estrategia de implementación

– Limitaciones


140

Axp( )

Byq( )

c1

«instance of» «instance of»

¿Qué es la herencia múltiple?

Cxyp( )q( )

c1

«Interface»A

p( )

«Interface»B

q( )

«instance of»

Axp( )

Byq( )

C

p( )

c1

«instance of»

Herencia múltiple Clasificación múltiple Interfaces múltiples


141

A

p( )

B

q( )

C

p( )q( )

c1

«instance of»

¿Cuándo es necesaria la herencia múltiple?

public class C extends A, B { // ¡ficticio!public p ( ) {

...super.p( );...

};public q ( ) {

...super.q( );...

};}

public class Main {public static void main(String[] args) {

C c1 = new C( );A a1 = c1;B b1 = c1;a1.p( );b1.q( );

}}

Reutilizar y redefinir operaciones

Desempeñar roles distintos


142

Interfaces: desempeñar roles distintos

C

p( )q( )

c1

«Interface»A

p( )

«Interface»B

q( )

«instance of»

Delegación: reutilizar y redefinir operaciones

a.p( ) b.q( )

A

p( )

B

q( )

C

p( )q( )

c1

1a 1b

«instance of»

Herencia múltiple: soluciones parciales


143

¿Qué hace G.p( )? ¿Qué es G.x?

Herencia múltiple: problemas conceptuales

Dxp( )

Exp( )

Fxp( )

Gxp( )


144

Herencia múltiple: estrategia de implementación

ca.p( ) cb.q( )

A

p( )

B

q( )

C

p( )q( )

«Interface»iA

p( )

«Interface»iB

q( )

Ca Cb1

ca

1

cb

A

p( )

B

q( )

C

p( )q( )


Unidades14a28-PPT.pdf

Documents

Transcript of Unidades14a28-PPT.pdf