Tema 4: Diseño

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



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


14

obj1: IU_CU_X

2: busca(d)

obj2: Gestor_X

3: getAtributoY()

obj3: Clase_X

return v

............

: ACTOR


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


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

....


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


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)


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

....


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


[no está] 6: hazY()

7: hazW() ....

5: … CONDICIÓN


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


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.


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


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


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


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


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


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)


ResultadoSQL

C2:SELECT MaxLibros

FROM SOCIOWHERE NumSocio=%numSocio

13: new()

14: next()

15: get( "MaxLibros")

16: destroy()

ResultadoSQL


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

Tema 4: Diseño

Documents

Transcript of Tema 4: Diseño