Você está na página 1de 72

Ingeniera del Software II Ingeniera Informtica, 4Curso

Proyecto Prctico de Diseo de Software


Curso 2010-2011
Gonzalo Gnova

Proyecto Prctico de Diseo de Software

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
Proyecto Prctico de Diseo de Software 3

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
Proyecto Prctico de Diseo de Software 4

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
Proyecto Prctico de Diseo de Software 5

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


Proyecto Prctico de Diseo de Software 6

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
Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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)

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

14

Transformacin de modelos: del anlisis al diseo


propsito

especificacin B descripcin A C realidad abstracto concreto dominio sistema

abstraccin

Proyecto Prctico de Diseo de Software

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)

Proyecto Prctico de Diseo de Software

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
Proyecto Prctico de Diseo de Software 17

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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
Proyecto Prctico de Diseo de Software 20

Estilos arquitectnicos de puentes

Proyecto Prctico de Diseo de Software

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.

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

Descomposicin modular recursiva: 72

Proyecto Prctico de Diseo de Software

25

Criterios para la seleccin de una arquitectura Criterios clsicos:


Extensibilidad Modificabilidad Simplicidad Eficiencia

Otros criterios:
Reuso Escalabilidad Coste Requisitos no funcionales

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

27

Descomposicin basada en marcos de trabajo


Java.awt

Window Capa de marcos

1 ventanaEmpleado

Capa de aplicacin

MiAplicacin

VentanaDialogo

Empleado

Proyecto Prctico de Diseo de Software

28

Nocin de componente

Unidad autnoma, reemplazable y reutilizable, habitualmente ejecutable

Proyecto Prctico de Diseo de Software

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)

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

31

Nocin de interfaz
Dos componentes pueden ofrecer la misma interfaz

Dos interfaces no necesariamente disjuntas

Proyecto Prctico de Diseo de Software

32

Representacin de interfaces: abreviada y completa


Novedad en UML2

Proyecto Prctico de Diseo de Software

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( ); }
Proyecto Prctico de Diseo de Software

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

Cmo instanciar las interfaces de un componente (2)


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.
Proyecto Prctico de Diseo de Software

35

Cmo instanciar las interfaces de un componente (3)


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.

Proyecto Prctico de Diseo de Software

36

Cmo instanciar las interfaces de un componente (4)

Caso 3 (parmetros iEmpleado)

Caso 1

Caso 2 (parmetros int)


Proyecto Prctico de Diseo de Software 37

Interfaces proporcionadas y requeridas

proporciona, realiza

requiere, usa

Proyecto Prctico de Diseo de Software

38

Cableado de componentes

ball and socket

cableado independiente cableado con dependencia


Proyecto Prctico de Diseo de Software

cableado en rbol

39

Anidamiento de componentes

puerto

delegacin

El conjunto de interfaces de un puerto debe ser consistente

Proyecto Prctico de Diseo de Software

40

Diagrama de despliegue
dispositivo hardware nodo ruta de comunicacin

entorno de ejecucin software

Proyecto Prctico de Diseo de 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

Proyecto Prctico de Diseo de Software

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.

Proyecto Prctico de Diseo de 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/

Proyecto Prctico de Diseo de Software

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).
Proyecto Prctico de Diseo de Software 45

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).
Proyecto Prctico de Diseo de Software 46

Aspecto de la herramienta

Proyecto Prctico de Diseo de Software

47

Diagramas importantes para IS2 Diagrama de Componentes

Diagrama de Clases

Diagrama de Despliegue

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

50

Relaciones entre las cuatro vistas


minimizar dependencias nuevas clases de diseo

Vista lgica (conceptual)

Vista de desarrollo (implementacin)

? identificar clases activas

Vista de proceso (ejecucin)

Vista fsica (despliegue)

requisitos no funcionales

Proyecto Prctico de Diseo de Software

51

Vista de casos de uso

Proyecto Prctico de Diseo de Software

52

Vista lgica (conceptual)

Proyecto Prctico de Diseo de Software

53

Vista de proceso (ejecucin)

Proyecto Prctico de Diseo de Software

54

Vista de desarrollo (implementacin)

Proyecto Prctico de Diseo de Software

55

Vista fsica (despliegue)

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

58

Arquitectura de tuberas y filtros stream > filter pipe filter filter pipe filter filter

filter

< stream
Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective Proyecto Prctico de Diseo de Software 59

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

Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective Proyecto Prctico de Diseo de Software 61

Arquitectura de sistema de eventos

Sub-system 1

Sub-system 2

Sub-system 3

Sub-system 4

Event and message handler

Adaptado de I. Sommerville, Software Engineering Proyecto Prctico de Diseo de Software 62

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

Proyecto Prctico de Diseo de Software

Arquitectura de repositorio

Design editor

Code generator

Design translator

Project repository

Program editor

Design analyser

Report generator

Adaptado de I. Sommerville, Software Engineering Proyecto Prctico de Diseo de Software 64

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

Adaptado de I. Sommerville, Software Engineering Proyecto Prctico de Diseo de Software 65

Arquitectura en capas: juegos interactivos Ejecucin de movimientos Lanzamiento de Dado Definicin de reglas del juego Jugador Representacin grfica
Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective Proyecto Prctico de Diseo de Software 66

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

Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective Proyecto Prctico de Diseo de Software 67

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

Proyecto Prctico de Diseo de Software

68

Arquitectura en Cuatro Capas

Proyecto Prctico de Diseo de Software

69

Arquitectura en Tres Escalones

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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)
Proyecto Prctico de Diseo de Software 74

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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)
Proyecto Prctico de Diseo de Software 80

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


Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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
Proyecto Prctico de Diseo de Software

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; } }

Proyecto Prctico de Diseo de Software

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 } }

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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


Proyecto Prctico de Diseo de Software 87

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
Proyecto Prctico de Diseo de Software

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


Proyecto Prctico de Diseo de Software 89

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

Proyecto Prctico de Diseo de Software

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.
Proyecto Prctico de Diseo de Software 91

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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
Proyecto Prctico de Diseo de Software 100

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}


Proyecto Prctico de Diseo de Software

{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

Proyecto Prctico de Diseo de Software

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.


Proyecto Prctico de Diseo de Software 103

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

Proyecto Prctico de Diseo de Software

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.

Proyecto Prctico de Diseo de Software

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.
Proyecto Prctico de Diseo de Software 106

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

Proyecto Prctico de Diseo de Software

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)

Proyecto Prctico de Diseo de Software

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)

Proyecto Prctico de Diseo de Software

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)

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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( )
Proyecto Prctico de Diseo de Software

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( )
Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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.
Proyecto Prctico de Diseo de Software 116

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

Proyecto Prctico de Diseo de Software

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)

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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
Proyecto Prctico de Diseo de Software 120

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?

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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.

Proyecto Prctico de Diseo de Software

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.
Proyecto Prctico de Diseo de Software 124

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 128

Herencia vs. Delegacin

C x( )

1 c x( )

1 c

A x( ) x( )

c.x( )
Dos formas de reutilizar / refactorizar

c.x( )

Proyecto Prctico de Diseo de Software

129

Flexibilidad: combinar herencia y delegacin

La combinacin de asociacin/delegacin y herencia posibilita modificar el comportamiento en tiempo de ejecucin.


Proyecto Prctico de Diseo de Software 130

Decorator: ejemplo (editor de texto)

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 131

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

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 132

Decorator: patrn

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 133

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

Proyecto Prctico de Diseo de Software

Command: ejemplo (men y paste)

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 135

Command: ejemplo (open y macro)

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 136

Command: patrn

Adaptado de E. Gamma et al., Design Patterns: Elements of reusable Object-Oriented software Proyecto Prctico de Diseo de Software 137

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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
Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

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

Proyecto Prctico de Diseo de Software

Herencia mltiple: problemas conceptuales

D x p( )

E x p( ) x p( )

Qu hace G.p( )?

x p( )

Qu es G.x?

Proyecto Prctico de Diseo de Software

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( )
Proyecto Prctico de Diseo de Software 144