Elaboración de Un Proyecto de Software

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)
Objetivos de la asignatura
Especificacin del diseo de alto y bajo nivel de una aplicacin informtica
Aprender...
Redaccin de un documento completo de diseo

Desarrollo dirigido por modelos (MDA-MDD-MDE), evolucin de USDP
Estndares de documentacin de proyectos
Tcnicas de la orientacin a objetos para diseo arquitectnico y detallado
Desarrollar capacidades
Abstraccin y resolucin de problemas

Lectura crtica y reflexiva
Trabajo en equipo
Exposicin de resultados propios
Revisin de trabajos ajenos
Aprendizaje a partir de errores propios y ajenos
Programa de la asignatura: teora
Tema III Diseo arquitectnico (diseo de alto nivel)
Unidad 14 La transicin del anlisis al diseo

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

Unidad 22 Diseo detallado con UML (1): polimorfismo
Unidad 23 Diseo detallado con UML (2): interacciones
Unidad 24 Diseo detallado con UML (3): mquinas de estados
Unidad 25 Patrones de diseo (1)
Unidad 27 Implementacin de asociaciones UML en Java (artculo y examen)
Unidad 28 Herencia mltiple
Programa de la asignatura: prcticas
Equipos de 4 alumnos (atencin: alumnos que no han cursado IS1)

Trabajo en 2+2 fases (URD/SRD + ADD/DDD)
Actividades en cada fase
Desarrollo y documentacin del proyecto conforme al ndice de la prctica
recuento de horas dedicadas al proyecto y mtricas
contabilizadas al principio de cada documento
enviadas aparte por correo segn las plantillas (horas, mtricas)
Sesiones de tutora colectivas, asistencia voluntaria
cada equipo tendr oportunidad de presentar su borrador y recibir crticas
Revisiones cruzadas
informes de revisin redactados conforme a las normas
Exposiciones en pblico y defensa del proyecto
entrega de transparencias impresas el primer da de exposiciones (2xPg!)
exposicin individual de una parte del proyecto
respuestas a los revisores y a los profesores
Documentacin entregada
Atencin a nombres de archivos y fechas de entrega

Dos documentos parciales (el segundo completa al primero):
ej. ProyectoIS2-M05.doc: equipo M05, etc.
envo por correo a is.uc3m [at] gmail.com y miembros del equipo revisor
ver ndice adaptado del estndar ESA PSS-05-0
Dos documentos de revisin:

ej. RevisinIS2-M05-R07.doc: equipo M05 revisado por equipo M07, etc.
envo por correo a los profesores y a los miembros del equipo revisado
Proyecto final revisado (normas):
documento final + presentaciones + recuento de horas + mtricas

ej. ProyectoIS2-M05.doc + etc.
envo por correo is.uc3m [at] gmail.com
ejemplar impreso encuadernado en espiral con tapas duras, incluyendo:
revisiones recibidas y respuestas, revisiones enviadas
transparencias de las dos presentaciones
Propuesta de preguntas tericas para el examen de test

Descripcin de la prctica
Ingeniera del Software 1

Realizar un proyecto de ingeniera inversa sobre un portal inmobiliario real.
Describir brevemente el alcance total de la funcionalidad ofrecida por el portal.
Seleccionar un subconjunto coherente de la funcionalidad ofrecida por el portal,
de forma que sea abarcable dentro de los lmites de carga de trabajo de la
asignatura.
Describir este subconjunto en forma de requisitos y con los modelos necesarios.
Realizar una evaluacin del portal (la parte seleccionada).
Ingeniera del Software 2:

A partir de los requisitos especificados en IS1.
Realizar un diseo arquitectnico de la aplicacin (ADD), slo del subconjunto
escogido para especificar los requisitos.
Realizar un diseo detallado (DDD), slo de uno de los componentes
especificados en el diseo arquitectnico.
Proyecto Prctico de Ingeniera de Requisitos
Formato de los documentos
Word, Times New Roman 12 Arial 10, interlineado sencillo.

Impreso a doble cara
Opcionalmente, formato PDF (con permisos de lectura y copia).
Extensin (porque queremos calidad, no cantidad):
ADD: 15 a 20 pginas.
DDD: 30 a 40 pginas.
TOTAL: 45 a 60 pginas (sin contar ndices ni anexos). Trabajo excesivo?
Factor de penalizacin en la calificacin del documento por exceso de pginas.
penalizacin
1
1-(p-60)/60
0
0
60
120
pginas
8
Trabajo en equipo y dedicacin a la prctica
Un total de 60 horas/alumno dedicadas a la prctica es razonable (58 h/a en IS1).

Equivale a una hora de trabajo prctico por cada hora de clase terica.
20 horas de clase + 20 horas de trabajo personal = 40 horas/semana.
La proporcin entre trabajo individual y en equipo debera ser 4/1 3/1.

Para conseguirlo la distribucin y coordinacin del trabajo deben ser adecuadas.
Si el nmero de horas es igual para todos falta sinceridad pero si no se califica!
En IS1 la proporcin ha sido 1,5 / 1: an falta distribuir mejor el trabajo individual.
Nombre
Ind. Eq. TOTAL
Nombre
Ind. Eq. TOTAL
Ana Garca
25
35
60
Ana Garca
40
15
55
Juan Gmez
25
35
60
Juan Gmez
43
11
54
Isabel Lpez
25
35
60
Isabel Lpez
47
16
63
Pedro Fernndez
25
35
60
Pedro Fernndez
50
18
68
TOTAL 100 140
240
TOTAL 180
60
240
MAL
BIEN
9
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.
10
Evaluacin de la asignatura
Individual
Tutoras*
00% Exp/Preparacin 05%
Prctica Exp/Ejecucin**
Exp/Respuestas
Teora
Equipo
05% Documentacin
30%
05% Revisiones
05%
Exmenes parciales*** 10% Propuesta de

Examen final
30% preguntas
50%
50%
10%
50%
50%
100%
* 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
11
Bibliografa
Diseo arquitectnico, diseo detallado

Eric Braude. Software Engineering. An Object-Oriented Perspective. John Wiley & Sons,
2001.
Captulos 5 y 6
Ian Sommerville. Software Engineering, 7th ed. Pearson-Addison Wesley, 2004.
Captulos 11-16
Roger Pressman. Ingeniera del software: un enfoque prctico, 6 ed. McGraw-Hill.
Captulos 9-11
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements
of reusable Object-Oriented software. Addison-Wesley, 1994.
Modelado con UML

Martin Fowler, Kendall Scott. UML Distilled. A Brief Guide to the Standard Object
Modeling Language. Addison-Wesley, 2004.
Jim Arlow, Ila Neustadt. UML and the Unified Process. Practical Object-Oriented
Analysis & Design. Addison-Wesley, 2002.
Perdita Stevens, Rob Pooley. Using UML. Software Engineering with Objects and
Components. Addison-Wesley, 2000.
Ms en la ficha de la asignatura
12
Tema III
Diseo arquitectnico
Unidad 14 La transicin del anlisis al diseo

Unidad 15 Introduccin al diseo arquitectnico
Unidad 16 Modelado arquitectnico con UML
Unidad 17 Herramientas de modelado (laboratorio)
Unidad 18 Vistas arquitectnicas
Unidad 19 Estilos arquitectnicos
Unidad 20 Qu es diseo orientado a objetos? (artculo y examen)
13
Transformacin de modelos: del anlisis al diseo
Dos trayectorias tpicas:

modelo del mundo real (modelo de anlisis en un sentido)
anlisis de requisitos (modelo de anlisis en otro sentido)
modelo de diseo
modelo descriptivo concreto del sistema heredado
modelo descriptivo abstracto del sistema heredado
modelo especificativo abstracto del sistema nuevo
modelo especificativo concreto del sistema nuevo
Especificacin
Descripcin
Vista
abstracta
modelo especificativo
abstracto del dominio
abstracto del sistema
Vista
concreta
concreto del dominio
concreto del sistema
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
14
Transformacin de modelos: del anlisis al diseo

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

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

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

Chapter 2. The architectural design phase
2.3. Construccin del modelo fsico (descomposicin, NFR, calidad...)
2.4. Especificacin del diseo arquitectnico (funciones componentes)
2.7. Revisin de los requisitos del software
Chapter 5. The architectural design document
5.1. Introduccin: lo que debe ser, lo que no debe ser
5.2. Estilo: claridad, consistencia, modificabilidad
Preguntas ms frecuentes
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
18
Introduccin al diseo arquitectnico

Arquitectura del software
analoga con la arquitectura civil: requisitos diseo
madurez de la arquitectura del software
Cmo lograr una descomposicin modular eficaz?
alta cohesin y bajo acoplamiento

descomposicin recursiva
disear para el mantenimiento
reducir la complejidad de las dependencias
Criterios para la seleccin de una arquitectura

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

1. Anlisis
Los vehculos deben
poder viajar desde la
parte alta a 120 km/h
en lnea recta y llegar
a la parte baja en no
ms de 3 minutos.
2. Clases de
Dominio
3. Arquitectura
Cable
Vehculo
Camino
Columna
vehculo
Barandilla
Cable
4. Diseo
Detallado
Adaptado de E. Braude,
Software Engineering:
An Object-Oriented Perspective
Camino
Columna
20
Estilos arquitectnicos de puentes
21
Arquitectura del software: definiciones
Paul Clements 1996

La arquitectura del software es a grandes rasgos, una vista del sistema que
incluye los componentes principales del mismo, la conducta de esos componentes
segn se percibe desde el resto del sistema y las formas en que los componentes
interactan y se coordinan para alcanzar la misin del sistema.
Len Bass 1998

La arquitectura del software de un programa o sistema de computacin es la
estructura o las estructuras del sistema, que contienen componentes de software,
las propiedades externamente visibles de dichos componentes y las relaciones
entre ellos.
IEEE Std. 1471-2000

La arquitectura del software es la organizacin fundamental de un sistema
encarnada en sus componentes, las relaciones entre ellos y con el entorno, y los
principios que orientan su diseo y evolucin.
22
Cohesin y acoplamiento
componente
1
2
componente
Alta cohesin
Puente
Bajo acoplamiento
Software Engineering: An Object-Oriented Perspective
23
Cmo lograr una buena descomposicin modular

A
Bien
Mal
Cmo acertar de antemano? Estilos arquitectnicos

24
Descomposicin modular recursiva: 72
25
Criterios para la seleccin de una arquitectura

Criterios clsicos:
Extensibilidad
Modificabilidad
Simplicidad
Eficiencia
Otros criterios:
Reuso
Escalabilidad
Coste
Requisitos no funcionales
26
Reutilizacin
Diseos reutilizables
Estilos arquitectnicos: formas tpicas de sistemas

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

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

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

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

package GestinEmpleados;
El componente proporciona
slo una interfaz, el tipo
abstracto de datos.
public interface iEmpleado {

public modificar( ) { };
}
public class EmpleadoFijo implements iEmpleado {
Es necesario que la clase

cliente (Departamento)
conozca las clases concretas
EmpleadoFijo, etc.: estas
clases deben ser pblicas.
public class EmpleadoTemporal implements iEmpleado {

Nada le impide usarlas slo

para invocar los constructores
(salvo el buen estilo del
programador).
====================
La dependencia es
potencialmente peligrosa.
class Departamento {
iEmpleado e = new EmpleadoFijo( );
e.modificar( );
}
34

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( )
}
====================
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).
int e = ge.crearEmpleado ( ); // se supone que existe GestorEmpleados ge
La clase cliente slo usa el

ge.modificarEmpleado(e);
gestor y los identificadores

}
pblicos.
35

dos interfaces, el tipo
abstracto de datos y el gestor.
public interface iEmpleado {

public interface iGestorEmpleados {

public iEmpleado crearEmpleado( ); // el gestor debe mantener algn 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.
36
Caso 3
(parmetros iEmpleado)
Caso 1
Caso 2
(parmetros int)
37
Interfaces proporcionadas y requeridas
proporciona,
realiza
requiere,
usa
38
Cableado de componentes
ball and socket
cableado
independiente
cableado
en rbol
cableado con
dependencia
39
Anidamiento de componentes
puerto
delegacin
El conjunto de interfaces de un
puerto debe ser consistente
40
Diagrama de despliegue
dispositivo
hardware
nodo
ruta de comunicacin
entorno de
ejecucin
software
41
Herramientas de modelado UML: Altova UModel

Objetivo de las herramientas CASE
Otras herramientas alternativas
Altova UModel
Instalacin
Licencias
Requisitos HW y SW
Diagramas de Componentes y Clases
Diagramas de Despliegue
Ejercicios en clase: transparencias 31-41
42
Objetivo de las herramientas CASE

Mejorar la productividad, el tiempo y coste de desarrollo.
Mejorar la planificacin de un proyecto.
Automatizar desarrollo del software, documentacin, generacin
de cdigo, pruebas de errores y gestin del proyecto.
Ayuda a la reutilizacin del software.
Gestin global en todas las fases de desarrollo de software con
una misma herramienta.
Facilitar el uso de las distintas metodologas propias de la
ingeniera del software.
43
Otras herramientas alternativas
Visio http://www.softwarestencils.com/uml/index.html
Telelogic Tau http://www.telelogic.com/products/modeler/index.cfm
swReuser http://www.reusecompany.com/producto.aspx?id=2
Star UML http://staruml.sourceforge.net/en/
44
Altova Umodel: Instalacin
Ir a:
http://www.altova.com/download/umodel/uml_tool_enterprise.html
Download UModel 2008 Enterprise Edition Setup now
Seleccionar el botn Ejecutar:
Seguir con la instalacin, presionando el botn Next cuando sea

conveniente, y por ltimo, el botn Install.
Cuando se encuentre Altova UModel instalado completamente en el
ordenador, se debe pedir una licencia de evaluacin (Request a FREE
Evaluation Key).
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).
46
Aspecto de la herramienta
47
Diagramas importantes para IS2

Diagrama de Componentes
Diagrama de Clases
Diagrama de Despliegue
48
El modelo de 4+1 vistas arquitectnicas
Vista lgica
(conceptual)
Vista de desarrollo
(implementacin)
Vista de casos de uso
Vista de proceso
(ejecucin)
Vista fsica
(despliegue)
Ingeniera del Software I
Ingeniera del Software II

49
Caractersticas de cada vista en el modelo 4+1

Vista
Lgica
(conceptual)
Proceso
(ejecucin)
Desarrollo
(implementacin)
Fsica
(despliegue)
Aspecto
Modelo de
informacin
Concurrencia y
sincronizacin
Organizacin del software

en el entorno de desarrollo
Correspondencia
software-hardware
Stakeholders
Usuarios
finales
Integradores del sistema
Programadores
Ingenieros de sistemas
Requisitos
Funcionales
Rendimiento
Disponibilidad
Fiabilidad
Concurrencia
Distribucin
Seguridad
Gestin del software

Reuso
Portabilidad
Mantenibilidad
Restricciones impuestas
por la plataforma o el
lenguaje
Rendimiento
Disponibilidad
Fiabilidad
Escalabilidad
Topologa
Comunicaciones
Notacin
Clases y
asociaciones
Procesos y
comunicaciones
Componentes y
relaciones de uso
Nodos y rutas de
comunicacin
50
Relaciones entre las cuatro vistas

minimizar dependencias
nuevas clases de diseo
Vista lgica
(conceptual)
Vista de desarrollo
(implementacin)
?
identificar
clases
activas
Vista de proceso
(ejecucin)
Vista fsica
(despliegue)
requisitos no funcionales
51
Vista de casos de uso
52
Vista lgica (conceptual)
53
Vista de proceso (ejecucin)
54
Vista de desarrollo (implementacin)
55
Vista fsica (despliegue)
56
Estilos arquitectnicos (Shaw & Garlan)
Flujo de datos
Tuberas y filtros
Secuencial por lotes
Componentes independientes
Sistemas cliente-servidor
Procesos paralelos
Sistemas de eventos
Mquinas virtuales
Repositorios
Bases de datos
Entornos de desarrollo
Editores
Sistemas hipertexto
Arquitectura en capas
Arquitectura MVC / RUP
Arquitectura en cuatro capas
Arquitectura en tres escalones
57
Arquitectura de flujo de datos: DFDs

tiempo de llegada de clientes
- n de cajeros
- velocidad media de cada cajero
- tiempo medio de llegada entre clientes
tiempo medio entre

llegadas de clientes
crear
cliente
crear
banco
lista de cajeros libres
cola de clientes
asignar
cliente a
cajero
cajero
finaliza con
cliente
lista de clientes / cajeros
log de estadsticas
Adaptado de W. Haythorn,
What Is Object-Oriented Design?
informar
58
Arquitectura de tuberas y filtros

stream >
filter
pipe
filter
filter
filter
filter
filter
pipe
< stream
59
Arquitectura cliente-servidor
Client 1
Client 2
Client 3
Client 4
Video
server
Picture
server
Web server
Film clip
files
Digitised
photographs
Film and
photo info
Internet
Catalogue
server
Library
catalogue
Adaptado de I. Sommerville,
Software Engineering
60
Arquitectura de procesos paralelos
Customer:
customer n
Customer:
customer n+1
Session:
session m
create
Session:
session k
Account:
customer n
checking
Account:
customer
n+1 saving
retrieve
create
retrieve
deposit
withdraw
61
Arquitectura de sistema de eventos
Sub-system
1
Sub-system
2
Sub-system
3
Sub-system
4
Event and message handler
62
Arquitectura de mquina virtual

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

260Mhz & 32MB
63
Arquitectura de repositorio
Design
editor
Design
translator
Code
generator
Project
repository
Design
analyser
Program
editor
Report
generator
64
Arquitectura en capas: modelo OSI
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
Data link
Data link
Data link
Physical
Physical
Physical
Communications medium
65
Arquitectura en capas: juegos interactivos

Ejecucin de movimientos
Lanzamiento
de Dado
Seleccin
de Ficha
Avance y Captura
Definicin de reglas
del juego
Movimiento
Jugador
Turno
Representacin
grfica
66
Arquitectura modelo-vista-controlador (original)
Acciones del
usuario
Modificaciones
en la vista
Controlador
Informacin
al usuario
Vista
Consultas al
modelo
C
V
M
Consultas y
modificaciones
en el modelo
Modelo
67
Arquitectura modelo-vista-controlador (moderna)
Comunicacin
con el usuario
Comportamientos
complejos
Vista
V
C
M
Controlador
Consultas y modificaciones
en el modelo
Consultas en
el modelo
Modelo
C
V
M
Modelo-Vista-Controlador original
68
Arquitectura en Cuatro Capas
69
Arquitectura en Tres Escalones
70
Tema IV
Diseo detallado
Unidad 21 Introduccin al diseo detallado: diseo por contratos

Unidad 22 Diseo detallado con UML (1): polimorfismo
Unidad 23 Diseo detallado con UML (2): interacciones
Unidad 24 Diseo detallado con UML (3): mquinas de estados
Unidad 27 Implementacin de asociaciones UML en Java (artculo y ex.)
Unidad 28 Herencia mltiple
71
Introduccin al diseo detallado: diseo por contratos

Qu es el diseo detallado
Nivel de detalle en el modelo de diseo
Diseo por contratos
Nocin de contrato
Especificacin formal del contrato: sintaxis y semntica
Uso de pre- y post- condiciones
Invariantes de clase
Contratos y herencia: subcontratacin
Especificacin de algoritmos
Diagramas de actividad
Pseudocdigo
72
Diseo por contratos: PPCs e invariantes

PPCs de operacin
CuentaCorriente.meterDinero(cantidad: Moneda)
Pre:
Post: saldo = saldo + cantidad
CuentaCorriente.sacarDinero(cantidad: Moneda)
Pre: saldo cantidad 0
Post: saldo = saldo cantidad
CuentaCorriente
saldo
meterDinero(cantidad)
sacarDinero(cantidad)
Invariantes de clase
CuentaCorriente: saldo 0
73
Diseo por contratos: subcontratacin
PPCs de operacin
CuentaCorriente.sacarDinero(cantidad: Moneda)
Pre: saldo cantidad 0
PPCs de operacin redefinida en la subclase

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

CuentaCorriente: saldo 0
CuentaCredito: (credito 0) AND (saldo + credito 0)
74
Diseo por contratos: uso correcto de jerarquas
CaminoOblicuo.distancia.post
d = ( x2 x1 ) 2 + ( y2 y1 ) 2
CaminoOblicuo
origen: Punto
destino: Punto
CaminoEsquinado.distancia.post
distancia( ): Float
d = ( x2 x1 ) + ( y2 y1 )
Cul sera
correcta?
(x2, y2)
CaminoEsquinado
origen: Punto
destino: Punto
distancia( ): Float
(x1, y1)
75
Especificacin de algoritmos
Bisiesto (x) =
m4(x)
AND
(
(NOT m100(x)
OR
(m100(x) AND m400(x))
)
[no]
m4
[s]
m100
[no]
[s]
= m4(x) AND (NOT m100(x) OR m400(x))
NoBisiesto (x) =
NOT m4(x) OR (m100(x) AND NOT m400(x))
[no]
no bisiesto
m400
[s]
bisiesto
76
Diseo detallado con UML (1): polimorfismo

Asignacin polimrfica
variables y argumentos
Invocacin polimrfica de operaciones

interfaz y comportamiento
Redefinicin polimrfica de operaciones

sobreescritura y sobrecarga
Signatura de la operacin
distincin de operaciones por su signatura
Visibilidad
Interfaces
Clases y operaciones abstractas
Generalizacin vs. Realizacin
77
Asignacin polimrfica de variables
public class CuentaCorriente {

}
public class CuentaCredito extends CuentaCorriente {
}
public class Persona {
private CuentaCorriente titularDe;
public asignarCuenta (CuentaCorriente cc) {
titularDe = cc;
}
}
public class Main {

public static void main(String[] args) {
Persona juan = new Persona();
CuentaCorriente ccr = new CuentaCredito();
juan.asignarCuenta(ccr);
}
}
CuentaCorriente
titularDe
Persona
CuentaCredito
Variable polimrfica
: CuentaCredito
juan: Persona
Argumento polimrfico
78
Invocacin polimrfica de operaciones

public Moneda saldo;
public void sacarDinero (Moneda cantidad) { } }
public class CuentaCredito extends CuentaCorriente {
public Moneda credito;
public void sacarDinero (Moneda cantidad) { } }
titularDe = cc; }
public sacarDinero (Moneda cantidad) {
titularDe.sacarDinero(cantidad); }
}
CuentaCorriente
saldo
sacarDinero(cantidad) titularDe
Persona
CuentaCredito
credito
Asignacin polimrfica
Invocacin polimrfica
public class Main {

CuentaCorriente ccr = new CuentaCredito();
juan.asignarCuenta(ccr);
juan.sacarDinero(100); }
}
: CuentaCredito
juan: Persona
sacarDinero(100)
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( )
sobrecarga
CuentaCredito
credito
80
Signatura de la operacin
Define los elementos que identifican unvocamente una operacin:
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...
nombre de operacin, nmero (orden) y tipo de los parmetros.
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
p1 : Punto
posicinX = 3
posicinY = -5
Punto
posicinX: Coordenada
posicinY: Coordenada
obtenerPosicin( ): CoordenadasPolares
obtenerPosicin( ): CoordenadasCartesianas
instance of
c := obtenerPosicin ( )
Qu operacin se invoca?
Depende del tipo de c...
Clase mal
definida
81
Distincin de operaciones por su signatura
En funcin del nombre de la operacin, su signatura, y su clase, puede ser:
una operacin distinta,

una operacin sobrecargada,
una operacin sobreescrita, o
un error (detectable por el compilador).
Nombre Signatura
Clase
Resultado
distinto
distinta
misma
sobrecarga
subclase
sobrecarga
misma
error
CuentaCorriente
saldo
sacarDinero(cantidad: Moneda)
sacarDinero(cantidad: MonedaEuropea)
distinta
igual
igual
subclase sobreescritura
CuentaCredito
credito
sacarDinero(cantidad: Moneda)
sacarDinero(cantidad: MonedaEuropea)
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
Java
VB.NET (C#)
Public
Public
Public
Protected
Protected-Friend
Package
Protected
Friend
(Internal)
friendly
Private
Private
Protected
Private
83
Visibilidad privada entre objetos de la misma clase
La visibilidad es una propiedad de las clases, no de los objetos: un objeto puede

acceder a operaciones y atributos privados de otros objetos de la misma clase.
public class Elemento {

private String nombre;
private void escribir() {
System.out.println(this.nombre);
}
public void prueba(Elemento p) {
p.nombre=e3;
p.escribir();
}
public Elemento(String n) {
nombre=n;
}
}
class Main {
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.
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.
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 }
}
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.
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( )
Crculo
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.
Rectngulo
base
altura
dibujar( )
Cuadrado
{base=altura}
dibujar( )
86
Interfaces
Encapsulamiento: separacin de interfaz e implementacin en una clase:

una clase puede realizar una o varias interfaces.
una interfaz puede ser realizada por una o varias clases.
Interfaz: conjunto de operaciones que ofrecen un servicio coherente:

no contiene la implementacin de las operaciones (mtodos).
una interfaz no puede tener atributos ni asociaciones navegables
(esta restriccin ha desaparecido en UML 2.0).
anloga a una clase abstracta con todas sus operaciones abstractas: no puede
tener instancias directas.
distinta de interfaz natural: conjunto de operaciones pblicas de una clase
(accesibles a travs de cualquier asociacin navegable hacia la clase).
Impresora
Imprimible
interface
Imprimible
Impresora
imprimir( )
Documento
Documento
Notaciones para uso y realizacin de interfaces

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.
Las interfaces son elementos generalizables:
Criterio de diseo: comprometerse slo con la

interfaz.
interface
Imprimible
interface
Figura
jerarquas mixtas de interfaces y clases.
declarar el tipo de las variables y parmetros de

operaciones como interfaces, no como clases.
servir cualquier instancia compatible con la interfaz.
Crculo
Rectngulo
Ejemplo:
Figura f = new Cuadrado ( );
f.imprimir
Cuadrado
88
Diseo detallado con UML (2): interacciones

Diagramas de interaccin: colaboracin y secuencia
Mensajes y operaciones
Foco de control
Nmeros de secuencia
Mensajes sncronos y asncronos

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

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

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

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.
Diagrama de secuencia
banco : Banco
cuenta1 : Cuenta
cuenta2 : Cuenta
Diagrama de colaboracin
sacarDinero( )
meterDinero( )
cuenta1 : Cuenta
Mensaje
1: sacarDinero( )
Objeto
banco : Banco
cuenta2 : Cuenta
2: meterDinero( )
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
origen : Cuenta
destino : Cuenta
Ana : Cliente
emitirTransferencia( )
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.
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
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
origen : Cuenta
destino : Cuenta
Ana : Cliente
sacarDinero( )
meterDinero( )
93
Diagramas de colaboracin: nmeros de secuencia
Forma alternativa de expresar la secuencia de mensajes y el anidamiento.

Esquema de numeracin anidada:
El nmero del mensaje recibido se usa como prefijo para los mensajes enviados.
Activador: mensaje que invoca la operacin desde la que se envan otros.
Predecesor: mensajes anteriores enviados en la misma ejecucin.
banco : Banco
origen : Cuenta
destino : Cuenta
Ana : Cliente
origen : Cuenta
sacarDinero( )
meterDinero( )
1.1: sacarDinero( )
banco : Banco
Ana : Cliente
1: emitirTransferencia
(origen, destino, cantidad)
destino : Cuenta
1.2: meterDinero( )
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).
banco1 : Banco
banco2 : Banco
Seales que
aceptan los objetos
de una clase
banco3 : Banco
transferenciaSolicitada(nmero, datos)
Banco
transferenciaSolicitada(nmero, datos)
transferenciaAceptada(nmero)
signal transferenciaSolicitada( )
signal transferenciaAceptada( )
signal transferenciaDenegada( )
transferenciaDenegada(nmero)
95
Hilos de ejecucin concurrente
Un objeto activo posee un hilo de ejecucin propio.

Clases y objetos activos se representan con doble trazo vertical a los lados.
Quin puede enviar un

mensaje?
Un objeto activo.
Un objeto pasivo que
tenga el foco de control.
Quin puede recibir un
mensaje asncrono?
Slo los objetos activos.
Un mensaje sncrono desva
el hilo de ejecucin al objeto
delegado.
Un mensaje asncrono puede
comunicar dos hilos de
ejecucin distintos, o
desdoblar un hilo existente.
p
q
r
s
96
Tipos de relaciones entre clases en UML

Dependencia
El elemento dependiente requiere la presencia del

elemento independiente.
Los cambios en el elemento independiente pueden
afectar al elemento dependiente.
Asociacin
Especificacin de un conjunto de conexiones entre

instancias.
Representan la estructura y posibilidades de
comunicacin del sistema.
Relacin entre un elemento general y un elemento

especfico.
Generalizacin
El elemento especfico puede aadir informacin y
debe ser consistente con el elemento general.
Realizacin
Relacin donde un elemento realiza o implementa la

especificacin dada por otro elemento.
97
Dependencias inducidas por las relaciones entre clases

public class FiguraColoreada extends Figura {
private Color miColor;
public void desplazar (Vector desplazamiento) {
Posicion p = new Posicion ( );
...
}
...
Figura
generalizacin
FiguraColoreada
asociacin
Figura
Vector
FiguraColoreada
Color
1
miColor
Color
parmetro
Posicion
variable local
(asociaciones contextuales)
98
Enlaces de comunicacin estructurales y contextuales
El envo de mensajes tiene lugar en un contexto determinado, normalmente

la ejecucin de una operacin. El contexto delimita los destinos vlidos.
A quin puedo enviar un mensaje? Mis conocidos son...
Un objeto conectado mediante un enlace navegable (instancia de asociacin).

Un objeto recibido como parmetro en esta activacin (parameter).
Un objeto creado localmente en esta activacin, o variable local (local).
Yo mismo, el emisor del mensaje (self).
Por cierto, cmo se nombran los objetos?

origen : Cuenta
- nombre arbitrario
- valor identificador
- nombre de parmetro
parameter
- nombre de variable
self
1.1.1: ok :=
esDisponible(cantidad)
1.1: sacarDinero(cantidad)
parameter
banco : Banco
Ana : Cliente
1: emitirTransferencia
(origen, destino, cantidad)
destino : Cuenta
1.2: meterDinero(cantidad)
99
Diagramas de interaccin vs. Diagramas de clases
Un diagramas de clases especifica la estructura del sistema, que sirve de

base para su comportamiento: asociaciones, operaciones.
Un diagrama de interaccin ilustra un comportamiento posible del sistema
(es decir, ejemplifica, no especifica).
Las diversas interacciones ayudan a detectar las clases, asociaciones y
operaciones requeridas: reglas de coherencia.
Diagramas de interaccin
(modelo dinmico)
Diagramas de clases
(modelo esttico)
Objeto
Instancia de clase
Enlace
Instancia de asociacin
(excepto enlaces contextuales)
Mensaje
Operacin o seal visible en la

(super)clase receptora
100
Creacin y destruccin de objetos

banco : Banco
cuenta1 : CuentaCorriente
s := obtenerSaldo( )
Cancelar una cuenta y

transferir el saldo a
una nueva de otro tipo
abrirCuenta(s)
cuenta2 : CuentaCrdito
cerrarCuenta( )
1: s := obtenerSaldo( )
cuenta1 : CuentaCorriente
{destroyed}
banco : Banco
3: cerrarCuenta( )
{transient}
=
{new} + {destroyed}
cuenta2 : CuentaCrdito
{new}
2: abrirCuenta(s)
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)
cuenta1 : Cuenta
2: desasignarTitular(titular)
{new}
titular : Titular
{destroyed}
cuenta2 : Cuenta
102
Ley de Demetra: No hable con desconocidos

Si dos objetos pueden comunicarse, entonces el cdigo de sus
respectivas clases debe manifestarlo claramente
(dependencias explcitas).
El objeto x, en respuesta al mensaje m(a, b, c...), puede enviar
mensajes slo a:
El objeto x (self).
Los argumento del mensaje m: a, b, c... (parameter).
Objetos creados por x en el curso de su respuesta a m (local).
Objetos directamente enlazados con x (association).
Formulada en trminos de UML 1.x:

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

103
Qu prohbe la Ley de Demetra?

Cul es el problema?

private Moneda saldo;
public Moneda obtenerSaldo() { }
}
La clase Persona tiene una dependencia

implcita, poco clara, con la clase Moneda.

titularDe = cc; }
public void mostrarSaldoActual() {
titularDe.obtenerSaldo().escribir();
}
}
public class Main {
CuentaCorriente cc = new CuentaCorriente();
juan.asignarCuenta(cc);
juan.mostrarSaldoActual();
}
}
Solucin: en lugar de enviar un mensaje al objeto

devuelto por otro mensaje, declarar una variable
local, haciendo explcita la dependencia.
titularDe = cc; }
public void mostrarSaldoActual() {
Moneda saldo = titularDe.obtenerSaldo();
saldo.escribir();
}
}
104
Diseo detallado con UML (3): mquinas de estados

Estados, eventos y transiciones.
Estados y transiciones.
Eventos y transiciones.
Transiciones con guardas.
Transiciones con acciones.
Estados con acciones y actividades.
Correspondencia diagramas de estados-diagramas de clases.

Comunicacin entre mquinas de estados.
Diseo e implementacin de mquinas de estados.
Secuencia de acciones en un cambio de estado.
Aplicacin de las mquinas de estados al diseo de interfaces.
105
Mquinas de estados: estados, eventos y transiciones

Estado
Evento
Clase Avin
Transicin
despegar
Estacionado
Volando
aterrizar
Pseudoestado
inicial
retirar
colisionar
Estado final
Los eventos causan las
transiciones entre estados.
Los eventos de creacin y destruccin

pueden ser implcitos o explcitos.
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
Empresa
1..*
contratar
0..1
Jubilado
despedir
Clase Persona
Trabajando
jubilar
107
Eventos y transiciones
Un evento representa la ocurrencia de un suceso, dentro o fuera del objeto,

que provoca un cambio de estado en el objeto (dispara una 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
play
Apagado
Parado
Reproduccin
off
Clase Reproductor
after(60 s)
stop
when(velocidad < 5 cm/s)
108
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.).
play[(not hayCinta) or atascada]
play[hayCinta and (not atascada)]
on
Apagado
Parado
Reproduccin
off
Clase Reproductor
Guardas
stop
after(60 s)
when(velocidad < 5 cm/s)
109
Transiciones con acciones
Una accin es un comportamiento que se ejecuta de modo instantneo

(con tiempo de ejecucin despreciable) y atmico (no interrumpible).
Est asociada a un evento que dispara una transicin.
Es completada antes de que la transicin alcance el nuevo estado.
Puede definirse recursivamente como secuencia de acciones.
Efectos:
En el propio objeto: modificar atributos o enlaces, invocar operaciones locales.
En otros objetos: mensajes sncronos (operaciones) o asncronos (seales).
play[(not hayCinta) or atascada]
play[hayCinta and (not atascada)]/altavoz.on
on
Apagado
Parado
off
Clase Reproductor
after(60 s)
Reproduccin
stop/altavoz.off
Acciones
when(velocidad < 5 cm/s)/altavoz.off
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
Evento interno
Reproduccin
Reproduccin
entry / altavoz.on
exit / altavoz.off
do / reproducir
cambiarVolumen(delta)
/vol:= vol + delta
cambiarVolumen(delta) / vol:= vol + delta

do / reproducir
111
Diagramas de estados vs. Diagramas de clases
Eventos: operaciones o seales de la clase receptora.

Guardas y eventos de cambio: valores de atributos (y asociaciones).
Acciones: operaciones locales o mensajes enviados a otros objetos.
Actividades: operaciones de la clase receptora.
Reproductor
hayCinta
atascada
velocidad
volumen
signal on( )
signal off( )
signal play( )
signal stop( )
signal cambiarVolumen(delta)
reproducir( )
Altavoz
1
on( )
altavoz off( )
Mensajes salientes:
destinatario(s) designado(s)
por el nombre de rol
112
Comunicacin entre mquinas de estados

Sentado
Elemento
mover
/levantar
signal mover( )
1
levantar( )
siguiente
sentar( )
after(2 s)
/sentar; siguiente.mover
Levantado
1.2: sentar( )
2.2: sentar( )
e1 : Elemento
3.2: sentar( )
e2 : Elemento
e3 : Elemento
2: mover( )
1: mover( )
1.1: levantar( )
3: mover( )
2.1: levantar( )
4: mover( )
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
signal on( )
signal off( )
signal play( )
signal stop( )
Apagado
Estado
on( ): Estado
estado off( ): Estado
play( ): Estado
stop( ): Estado
Parado
Reproduccin
114
Secuencia de acciones en un cambio de estado
Reproductor
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).
r : Reproductor
signal on( )
signal off( )
signal play( )
signal stop( )
Apagado
Estado
1
on( ): Estado
estado
off( ): Estado
play( ): Estado
stop( ): Estado
Parado
Reproduccin
estado : Apagado
o : Oyente
on( )
estado := on( )
new( )
nuevo : Parado
115
Aplicacin de las mquinas de estados al diseo de interfaces
Evitar ventanas superfluas y

callejones sin salida.
Habilitar en cada momento slo
los botones que realmente pueden
ejecutar una accin significativa.
Los botones habilitados guan al
usuario eficazmente por la
aplicacin.
Un buen diseo hace la
navegacin mucho ms intuitiva.
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
117
El catlogo de patrones de diseo

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

enumerar los hijos
crear compuestos
Builder
Memento
Composite
combinadas usando
Iterator
definir la
gramtica
Flyweight
Decorator
compartir estrategias
definir recorridos
aadir operaciones
Command
Visitor
compartir
smbolos
terminales
cambiar la piel en
vez de las tripas
definir la cadena
compartir estados
Strategy
evitar la histresis
compartir
compuestos
aadir responsabilidades a objetos
Chain of Responsibility
Interpreter
aadir operaciones
State
definir los pasos de
un algoritmo
Mediator
Template Method
configurar fabricas
dinmicas
Prototype
suele usar
Abstract Factory
instancia nica
gestin de
dependencias
complejas
Observer
Implementado usando
Factory Method
instancia nica
Singleton
Facade
Adaptado de E. Gamma et al., Design Patterns:

Elements of reusable Object-Oriented software
119
Descripcin de un patrn de diseo

Abreviada
1.
2.
3.
4.
Nombre
Problema
Solucin
Consecuencias
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
120
Abstract Factory: introduccin
Con este patrn se pretende resolver un problema bsico de programacin:

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

// Cdigo problemtico
public class Z {
A a;
switch () {
case : a = new B( ); break;
case : a = new C( ); break;
}
}
Resulta que Z no depende slo de A, tambin

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

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

ScrollBar sb = new WindowsScrollBar();
ScrollBar sb = new MacScrollBar();
Si se crean muchos Widgets (como suele ocurrir en aplicaciones de cierta

complejidad) ser muy difcil cambiar de una apariencia a otra, dado que hay
que modificar muchas instrucciones que estn diseminadas por diferentes
partes del programa (problema de mantenimiento).
Solucin: patrn de diseo Abstract Factory (fbrica abstracta).

Una fbrica es un objeto que se encarga de crear otros objetos.
Los elementos de este patrn son:

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

Widget
Para toda la aplicacin:

- una fbrica abstracta
- dos fbricas concretas
ScrollBar
Button
scrollTo()
press()
Menu
popUp()
GUIFactory
createScrollBar()
createButton()
createMenu()
WindowsScrollBar
MacScrollBar
scrollTo()
WindowsFactory
MacFactory
scrollTo()
Por cada tipo de Widget:

- un producto abstracto
createScrollBar()
createButton()
createMenu()
createScrollBar()
createButton()
createMenu()
- dos productos concretos
125
Caso de estudio (4): solucin al problema de mantenimiento
Creacin de Widgets con contructores concretos, antes

ScrollBar sb = new WindowsScrollBar();
ScrollBar sb = new MacScrollBar();
y despus, a travs de operaciones abstractas de la fbrica.

ScrollBar sb = guiFactory.createScrollBar();
Hemos transformado la ramificacin condicional en invocacin polimrfica.
La variable global guiFactory debe ser inicializada al comienzo del

programa con una de las fbricas concretas:
GUIFactory guiFactory = new MacFactory();
Las operaciones de creacin en las fbricas concretas usan los constructores

concretos (Factory Method: invocar un constructor mediante una operacin):
public ScrollBar createScrollBar() {return new WindowsScrollBar();}
public ScrollBar createScrollBar() {return new MacScrollBar();}
126
Abstract Factory: ejemplo
Adaptado de E. Gamma et al.,

Design Patterns: Elements of reusable Object-Oriented software
127
Abstract Factory: patrn

128
Herencia vs. Delegacin
x( )
1
c
x( )
A
x( )
B
x( )
c.x( )
c.x( )
Dos formas de reutilizar / refactorizar
129
Flexibilidad: combinar herencia y delegacin
La combinacin de asociacin/delegacin y herencia posibilita

modificar el comportamiento en tiempo de ejecucin.
130
Decorator: ejemplo (editor de texto)

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

132
Decorator: patrn

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
Command: ejemplo (men y paste)

135
Command: ejemplo (open y macro)
Adaptado de E. Gamma et al., Design Patterns:

Elements of reusable Object-Oriented software
136
Command: patrn

137
Cmo seleccionar un patrn de diseo

Objetivo
Patrn
Proporcionar una interfaz nica que d acceso a un

conjunto de objetos de diversas clases
Facade
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
State
Iterator
Facilitar la respuesta de entidades interesadas en los

cambios de una fuente de informacin
Observer
Interpretar sentencias escritas en una gramtica formal
Interpreter
138
Herencia mltiple
Qu es la herencia mltiple
Frente a clasificacin mltiple
Frente a interfaces mltiples
Cundo es necesaria
Desempear dos o ms roles
Reutilizar y redefinir cdigo
Soluciones parciales
Interfaces
Delegacin
Problemas conceptuales
Estrategia de implementacin
Limitaciones
139
Qu es la herencia mltiple?
A
x
p( )
y
q( )
x
p( )
y
q( )
Interface
A
Interface
B
p( )
q( )
C
instance of
p( )
instance of
instance of
x
y
p( )
q( )
instance of
c1
c1
c1
Herencia mltiple
Clasificacin mltiple
Interfaces mltiples
140
Cundo es necesaria la herencia mltiple?

A
p( )
Reutilizar y
redefinir
operaciones
q( )
C
p( )
q( )
instance of
Desempear
roles
distintos
c1
public class C extends A, B {

public p ( ) {
...
super.p( );
...
};
public q ( ) {
...
super.q( );
...
};
}
// ficticio!
public class Main {

C c1 = new C( );
A a1 = c1;
B b1 = c1;
a1.p( );
b1.q( );
}
}
141
Herencia mltiple: soluciones parciales

Interface
A
Interface
B
p( )
q( )
p( )
a
q( )
1
p( )
q( )
a.p( )
b.q( )
p( )
q( )
instance of
instance of
c1
c1
Interfaces: desempear roles distintos
Delegacin: reutilizar y redefinir operaciones
142
Herencia mltiple: problemas conceptuales
D
x
p( )
x
p( )
x
p( )
Qu hace G.p( )?
x
p( )
Qu es G.x?
143
Herencia mltiple: estrategia de implementacin
Interface
iA
Interface
iB
p( )
q( )
p( )
q( )
p( )
C
p( )
q( )
q( )
Ca
1
ca
p( )
q( )
Cb
cb
ca.p( )
cb.q( )
144

Elaboración de Un Proyecto de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Elaboración de Un Proyecto de Software

Cargado por

Copyright:

Formatos disponibles

Ingeniera del Software II

Ingeniera Informtica, 4Curso

Proyecto Prctico de Diseo de Software

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

Un curso de anlisis y diseo en dos asignaturas:

Especificacin del diseo de alto y bajo nivel de una aplicacin informtica

Redaccin de un documento completo de diseo

Abstraccin y resolucin de problemas

Programa de la asignatura: teora

Tema III Diseo arquitectnico (diseo de alto nivel)

Unidad 14 La transicin del anlisis al diseo

Tema IV Diseo detallado (diseo de bajo nivel)

Unidad 21 Introduccin al diseo detallado

Programa de la asignatura: prcticas

Equipos de 4 alumnos (atencin: alumnos que no han cursado IS1)

Atencin a nombres de archivos y fechas de entrega

Dos documentos de revisin:

Proyecto final revisado (normas):

documento final + presentaciones + recuento de horas + mtricas

Propuesta de preguntas tericas para el examen de test

Ingeniera del Software 1

Ingeniera del Software 2:

Proyecto Prctico de Ingeniera de Requisitos

Formato de los documentos

Word, Times New Roman 12 Arial 10, interlineado sencillo.

Extensin (porque queremos calidad, no cantidad):

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

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

Ind. Eq. TOTAL

Ind. Eq. TOTAL

TOTAL 100 140

Dedicacin a la asignatura, aproximadamente:

00% Exp/Preparacin 05%

Exmenes parciales*** 10% Propuesta de

* Asistencia NO obligatoria a tutoras colectivas

Diseo arquitectnico, diseo detallado

Modelado con UML

Proyecto Prctico de Diseo de Software

Unidad 14 La transicin del anlisis al diseo

Proyecto Prctico de Diseo de Software

Transformacin de modelos: del anlisis al diseo

Dos trayectorias tpicas:

Proyecto Prctico de Diseo de Software

Transformacin de modelos: del anlisis al diseo

Proyecto Prctico de Diseo de Software

Relacin lgico-temporal entre el anlisis y el diseo

Proyecto Prctico de Diseo de Software

El diseo arquitectnico en el Estndar ESA

ESA software engineering standards (PSS-05-0)

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

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

El diseo detallado en el Estndar ESA

ESA software engineering standards (PSS-05-0)

5.4. Salidas: omitir cdigo y manual de usuario

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

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

Proyecto Prctico de Diseo de Software

Introduccin al diseo arquitectnico

Cmo lograr una descomposicin modular eficaz?

alta cohesin y bajo acoplamiento

Criterios para la seleccin de una arquitectura

Reutilizacin de diseos y componentes