1 tema 4: diseño. 2 contenidos 1.- introducción 2.- el rol del diseño dentro del cv 3.-...
TRANSCRIPT
1
Tema 4: Diseño
2
Contenidos• 1.- Introducción• 2.- El rol del diseño dentro del CV• 3.- Artefactos • 4.- Dos posibles patrones de diseño para acceder al
nivel de datos (almacenamiento) – Usando un sistema OO– Usando un SGBD relacional
Anexos: modelo de despliegue, trabajadores y flujo de actividades
3
1. Introducción• Encontrar la forma (o solución) del sistema que cumpla con todos los
requisitos (+ no funcion.) – Modelo del análisis: comprensión de todos los requisitos.
• 1) Escoger herramientas (LP, SO, SGBD, GUI, concurrencia, distribución, componentes,…)• 2) Obtener buena entrada a la fase de implementación
– Que implementar sea directo a partir del diseño • 3) Permitir implementación por varios equipos
– Capturar las interfaces – Usar una notación común
4
2. Rol del Flujo de Trabajo de diseño en el CV
Requisitos
Diseño
Implementación
Prueba
Análisis
ite r.# 1
ite r.# 2
ite r.# n
ite r.# n+1
ite r.# n+2
iter.#m
ite r.#m +1
Inicio Elaboración Construcción Transición
Iteraciones:
Foco durante final de la fase de elaboración y comienzo de construcción
- obtener arquitectura estable - y “anteproyecto” de implementación
El modelo de diseño SÍ se MANTIENE en todo el proyecto
5
El CV del PUD de Rational separa el “diseño” del “despliegue”
Diseño
Despliegue
6
3. Artefactos a obtener en el FT de diseño
• Modelo del diseño• Subsistema de diseño • Clase de diseño• Realización de caso de uso -- Diseño• Interfaz• Descripción de la arquitectura (vista del diseño)• Modelo de despliegue• Desc. de la arquitectura (vista del
despliegue)
diseño
despliegue(NO LO
TRATAREMOS)
7
MODELO DEL ANÁLISIS (MA)
PAQUETE DE ANÁLISIS
CLASES DE ANÁLISIS REALIZACIÓN-ANÁLISIS DE CU
contiene
- Realizaciones de CU
- Clases de análisis
- Otros paquetes de análisis
MODELO DEL DISEÑO (MDiseño)
SISTEMA DE
DISEÑO
CLASES DE DISEÑO REALIZACIÓN-DISEÑO DE CU
contiene
- Realizaciones de CU
- Clases de diseño
- Interfaces
- Otros subsistemas de diseño
: IU-1 : Gesto : Libo elLibro
1: ucir
2: Aceptar
3: obtenerLibro(signaturaLibro:String)
4: getSignatura()
encuentre
elLibro
5: getCopias()
6: isCoda()
NOMBRE DE L
atributo1,...
método1 (ám),…
NOMBRE DE L
método1 (parám),método2 (parám)
INTER-FACES
+ MODELO de DESPLIEGUE
JERARQUÍA DE SUBSISTEMAS DE DISEÑO
8
Artefacto: Clase de diseño
• Una clase de diseño es una abstracción de una clase (o constructor similar existente) en el LP– Operaciones, parámetros, atributos y tipos– Visibilidad de atributos y operaciones– Asociaciones y agregaciones (aunque luego se
implementen añadiendo atributos) – Generalizaciones (con la semántica del LP utilizado)
9
Artefacto: Clase de diseño II
• Los métodos se especifican en lenguaje natural o en pseudocódigo
• Pueden especificarse requisitos de implementación de una clase
• Pueden ponerse estereotipos– “class module”, “form”, “user control” en VB– “interface” en Java
10
Artefacto: Realización de CU -- diseño
• Es una colaboración que indica cómo se realiza/ejecuta un CU, en términos de las clases de diseño y sus objetos
• Para cada CU habrá que añadir– El diagrama de secuencia– Flujo de eventos (en el diseño) – Requisitos de implementación
11
Diagrama de Secuencia en UML
obj1: IU_CU_X
2: busca(d)
obj2: Gestor_X
3: getAtributoY()
obj3: Clase_X
return v
............
: ACTOR
1: escribe d y solicita
tiem
po
OBJETOS
PASO DE MENSAJES / LLAMADAS A MÉTODOS
12
tiem
po
FOCO DE CONTROL: período en el que el objeto
ejecuta algo
LÍNEA DE LA VIDA: período en el que el objeto
existe
obj1: IU_CU_X
2: busca(d)
obj2: Gestor_X
3: getAtributoY()
obj3: Clase_X
return v
............
: ACTOR
1: escribe d y solicita
Diagrama de Secuencia en UML
Nota: no seremos muy rigurosos señalando el foco de control
13
tiem
po
Los objetos se pueden crear con el método NEW (comienza su línea de vida y foco de control mientras
ejecutan cosas) y se pueden destruir con el método DESTROY (se termina su línea de vida)
new hazX()
: C3
hazY()
destroy
: C2: C1
Diagrama de Secuencia en UML
14
obj1: IU_CU_X
2: busca(d)
obj2: Gestor_X
3: getAtributoY()
obj3: Clase_X
return v
............
: ACTOR
1: escribe d y solicita
tiem
po
Significa que la clase Gestor_X debe proporcionar el método busca. Así se
DISEÑAN las clases, esto es, se identifican sus MÉTODOS a partir de las RESPONSABILIDADES definidas
durante el FT del análisis
Gestor_X
busca(a:tipoD): tipoRes
Diagrama de Secuencia en UML
15
Una llamada a un método puede devolver un valor (mensaje “return valor” en línea con puntos suspensivos).
Generalmente sólo se pondrá en el diagrama de secuencia cuando proporcione información interesante
obj2: Gestor_X
getAtributoY()
obj3: Clase_X
return v
....
Diagrama de Secuencia en UML
16
En este caso NO ES NECESARIO. Es evidente que le estamos preguntando al objeto “pp” por su nombre, y eso será lo que nos devolverá. Nos ahorraremos una línea en el
diagrama de secuencia y será más fácil de leer.
: Gestor_Personas
getNombre()
pp: Persona
return nombre
Diagrama de Secuencia en UML
17
En este caso SÍ ES NECESARIO. Así podemos ver que ponemos como nombre del jefe de departamento el nombre del objeto “pp”.
: Gestor_Personas
getNombre()
pp: Persona
return nombre
: Departamento
setNombreJefe(nombre)
Diagrama de Secuencia en UML
18
Una llamada a un método NO puede devolver MÁS de un valor. Eso no es
posible utilizando un lenguaje OO
: Gestor_Emps
getNombreYCategoría()
emp: Empleado
return nombre y categoría
....
Diagrama de Secuencia en UML
19
tiem
po
Los diagramas de secuencias muestran los envíos de mensajes entre objetos en orden secuencial (se añaden números de secuencia 1: 2:, …). SE PUEDEN
AÑADIR CONDICIONES. Los números de secuencia continúan independientemente en cada rama. NO HAY QUE ABUSAR DE LAS CONDICIONES. Es mejor realizar distintos diagramas de secuencia.
obj1: IU_CU_X
2: busca(d)
obj2: Gestor_X
[está] 6: hazX()
obj3: Clase_X
............
: ACTOR
1: escribe d y solicita
[no está] 6: hazY()
7: hazW() ....
5: … CONDICIÓN
Diagrama de Secuencia en UML
20
SE PUEDE AÑADIR REPETICIONES. De esta manera se indica que a varios objetos de la clase
Clase_X se les pide ejecutar el método getAtributoY()
2: busca(d)
obj2: Gestor_X
3: getAtributoY()
:Clase_X
Objetos múltiples de Clase_X
Diagrama de Secuencia en UML
21
2: busca(d)
obj2: Gestor_X
3: getAtributoY()
obj3: Clase_X
i=1..*
Esta es otra manera de especificar una repetición: usando un rectángulo en el que se encuadran todos los pasos de mensajes que se van a repetir. Se puede indicar la cardinalidad de cuántas veces se repite o
una condición de hasta cuándo se repite.
Se repite de 1 a n veces.
4: añadir(i)
Se puede usar el valor i.
Diagrama de Secuencia en UML
22
2: busca(d)
obj2: Gestor_X
3: getAtributoY()
obj3: Clase_X
Esta es otra manera de especificar una repetición: utilizando una nota UML
Repetimos hasta encontrar elvalor buscado
Diagrama de Secuencia en UML
23
Aunque hemos dicho que una llamada a un método NO PUEDE DEVOLVER MÁS DE UN VALOR, permitiremos esto como una notación abreviada …
: Gestor_Emps
getHijos()
emp: Empleado
return h1, h2, … hN
hi :Persona
getNombre()
Diagrama de Secuencia en UML
24
… notación abreviada de este diagrama de
secuencia
: Gestor_Emps
getHijos()
emp: Empleado
return vec
vec :Vector
getNext()
getNombre()
:Persona
*
Recorrer todos los elementos del vector
Diagrama de Secuencia en UML
25
Artefacto: Interfaz• Las interfaces se usan para especificar operaciones • Separan la especificación de la funcionalidad de su
implementación• Las interfaces definen cómo se interactúa entre los
subsistemas. – Las interfaces son requisitos para los equipos de desarrollo
y sirven para que los distintos equipos puedan trabajar concurrentemente.
26
• Supongamos que hay dos equipos de trabajo implicados en el SI de la biblioteca y que se han dividido el trabajo– Uno se encarga de los subsistemas SOCIOS y CATÁLOGO – Otro se encarga del subsistema PRÉSTAMOS
• Es evidente que cada equipo puede necesitar ciertos métodos del otro.
• Lo que tienen que hacer es definirlos utilizando interfaces – clases con sólo métodos no implementados
Interfaz
27
• ¿Qué pueden necesitar del subsistema SOCIOS?– Un método que dado un número de socio
devuelva una referencia al objeto socio.– Un método para añadir un nuevo socio al sistema.– Un método para …
buscaSocio(número)
: Gestor_Socios
Es una INTERFAZ que el equipo de PRÉSTAMOS puede utilizar. El equipo de SOCIOS ya proporcionará una implementación
Interfaz
28
Artefacto: descripción de la arquitectura (diseño)
• Es una descripción que contiene la vista arquitectural del modelo del diseño
• Los siguientes artefactos son arquitecturalmente significativos:– Descomposición del modelo en subsistemas junto con
sus interfaces– Clases de diseño claves– Realizaciones de casos de uso con funcionalidad crítica
29
4. Dos patrones de diseño para acceder a los datos
• 1) Usando un lenguaje/sistema OO para el almacenamiento de datos que permita trabajar con objetos “persistentes” – Es posible si se utiliza un SGBD OO – O si se usa Java + mecanismos de serialización de Java
• 2) Usando un SGBD relacional para el almacenamiento– Es posible si disponemos de un lenguaje con un API que
permita conectarse con un SGBD, por ejemplo si se usa Java + JDBC
30
Acceso a los datos usando un sistema OO
• El diseño es prácticamente equivalente al diagrama de colaboración de análisis– Usar nombres de métodos y no responsabilidades– Varias clases de diseño que sean interfaces gráficas – Detallar casos excepcionales
Las clases de diseño que corresponden a las clases entidad pueden tener métodos
31
Acceso a los datos usando un SGBD relacional
• El diseño cambia con respecto al diagrama de colaboración de análisis– MODELO DEL DOMINIO / CLASES ENTIDAD (OO) ESQUEMA LÓGICO DE UNA BD RELACIONAL
• Se trata en la asignatura DBD. Supondremos que se sabe ya.
– CLASE DISEÑO (GESTOR BD) permite ejecutar SQL• SQL se trata en FBD y DBD. Supondremos que se sabe ya.
– Las CLASES ENTIDAD NO pueden tener MÉTODOS
32
Acceso a los datos usando un SGBD relacional
GestorBD
execSQL(actualiz: String): void
execSQL(pregunta: String): ResultadoSQL
ResultadoSQL
next(): boolean
get(nombreAtributo: String): String
Para INSERT/DELETE/UPDATE Para SELECT
Se posiciona en siguiente tupla
Devuelve false si no hay más tuplas Obtiene
valor del atributo
33
Acceso a los datos usando un SGBD relacional
execSQL(preg1)
: GestorBD
: ResultadoSQLnew
next()
[quedan tuplas] get(“NOMBRE”)
get(“EDAD”)
hasta que no queden tuplas
Preg1 = SELECT NOMBRE, EDAD
FROM PERSONA
WHERE EDAD>25
34Realización diseño – CU Tomar en Préstamo Copia Libro (solución usando sistema OO)
elSocio
IU-TPCL GestorLibro Libro elLibro:Libro :CopiaLibro GestorSocios Socio
1: Introducir Signatura y numSocio()
2: Aceptar()
3: obtenerLibro(signaturaLibro:String)
4: getSignatura()
Se repite hasta que seencuentre un libro
con la signatura que estamos buscando
elLibro()
6: getCopias()
7: getEstado()
Se repite hasta que seencuentre una copia
no prestada o se acabenlas copias
8: [hay al menos una copia NO prestada]: obtenerSocio(numSocio:int)
9: getNumSocio()
elSocio:Socio
11: isLímitePréstamo()
IUError12: [alcanzado el máximo de préstamos]: new()
13: Aceptar()
IUReserva8: [Todas las copias prestadas]: new(elLibro:Libro, elSocio:Socio)
9: añadirReserva(elSocio:Socio)10: añadirReserva(elLibro:Libro)
CU: Tomar en Préstamo Copia de Libro
GestorPrestamos
5: obtenerCopiaLibre(elLibro:Libro)
laCopiaLibre()
10: haLLegadoLimite(elSocio:Socio)
12: [no ha llegado al límite]: registrarPrestamo(elSocio:Socio, laCopiaLibre:CopiaLibro, HOY:Date)
prestamo13: new(elSocio:Socio, laCopiaLibre:CopiaLibro, HOY:Date)
35
Realización diseño – CU Tomar en
Préstamo Copia Libro (solución usando sistema
SGBD)
Se podría hacercon una únicapregunta SQL
GestorBD
Socio
IU-TPCL GestorLibro GestorSocios
1: Introducir Signatura y numSocio()
2: Aceptar()3: obtenerCopiaLibre(signatura:String)
4: execSQL(c1:String)
8: next()
9 [Resultado no vacío]: get("NumCopia")
IUError
C1:SELECT NumCopia
FROM CopiaLibro as CWHERE Estado="Disponible" AND Signatura=%signatura
ResultadoSQL5: new()
10: destroy()
11: isLímitePréstamo(numSocio:int)
12: execSQL(c2:String)
ResultadoSQL
C2:SELECT MaxLibros
FROM SOCIOWHERE NumSocio=%numSocio
13: new()
14: next()
15: get( "MaxLibros")
16: destroy()
ResultadoSQL
17: execSQL(c3:String)
18: new()
C3:SELECT *
FROM PRÉSTAMOWHERE NumSocio=%numSocio
19: next()
Se repite tantas veces comotuplas hay en el resultado
20: destroy()
22: execSQL(C4:String)C4:UPDATE CopiaLibro
SET Estado="Prestada" WHERE Signatura=%signatura AND NumCopia=%numCopia
C5:INSERT INTO
PRÉSTAMO(Signatura, NumCopia, NumSocio, Fecha) VALUES (%signatura, %numCopia, %numSocio, HOY)
23: execSQL(C5:String)
21b: [Límite alcanzado]: new()
22: aceptar()
23: destroy()
IUReserva9b: new(signatura:String, numSocio:int)
10b: reservar()
11b: execSQL(C6:String)
C6:INSERT INTO
RESERVA(Signatura, NumSocio) VALUES (%signatura,%numSocio)
GestorPrest
21: [Límite no alcanzado]: registrarPrestamo(socio:String, copia:String, fecha:Date)
CU: Tomar en Préstamo Copia de Libro
36
Anexo: Artefacto:Modelo de despliegue
• Es un modelo de objetos que describe la distribución física del sistema en términos de cómo se distribuye la funcionalidad entre los distintos nodos– Cada nodo representa un recurso computacional (procesador,
dispositivo hardware,…). – Las relaciones entre nodos representan formas de comunicación
entre ellos (internet, intranet, bus,…). – La funcionalidad de un nodo se define por los componentes
desplegados en él.• El modelo de despliegue es la correspondencia entre la
arquitectura del software y la arquitectura del sistema
37
Artefacto: descripción de la arquitectura (despliegue)
• Es una descripción que contiene la vista arquitectural del modelo del despliegue
• Todos los aspectos del modelo de despliegue deben mostrarse en la vista de la arquitectura
38
Anexo: Trabajadores
• Arquitecto– Responsable de la integridad del modelo de diseño y de
despliegue• Ingeniero de casos de uso
– Responsable de la integridad de los casos de uso• Ingeniero de componentes
– Define y mantiene las operaciones métodos, atributos, relaciones y requisitos de implementación de clases de diseño. Debe mantener la integridad de los subsistemas controlando que se realizan los interfaces.
39
Anexo: Actividades en el FT de diseño
• 1.- Diseño de la arquitectura• Identificar nodos y configuraciones de red• Identificar subsistemas y sus interfaces• Identificar clases de diseño arquitecturalmente significantes• Identificar mecanismo de diseño genéricos
• 2.- Diseñar caso de uso• Identificar clases de diseño participantes• Describir interacciones de objetos de diseño• Identificar los subsistemas participantes e interfaces• Describir interacciones entre subsistemas• Capturar requisitos de implementación
40
• 3.- Diseñar clase• Perfilar la clase de diseño• Identificar las operaciones• Identificar los atributos• Identificar asociaciones y agregaciones• Identificar generalizaciones• Describir los métodos• Describir los estados• Tratar los requisitos especiales
• 4.- Diseñar subsistema• Mantener dependencias entre subsistemas• Mantener los interfaces proporcionados por el subsistema• Mantener los contenidos del subsistema
Actividades en el FT de diseño