Flujo de trabajo: Diseo

1
 Contenidos
1.- Introduccin
2.- El rol del diseo dentro del CV
3.- Artefactos
4.- Dos posibles patrones de diseo para
acceder al nivel de datos (almacenamiento)
Usando un sistema OO
Usando un SGBD relacional
Anexos: modelo de despliegue, trabajadores y
flujo de actividades
2
 1. Introduccin
Encontrar la forma (o solucin) del sistema que
cumpla con todos los requisitos (+ no funcion.)
Modelo del anlisis: comprensin de todos los requisitos.
1) Escoger herramientas (LP, SO, SGBD, GUI,
concurrencia, distribucin, componentes,)
2) Obtener buena entrada a la fase de implementacin
Que implementar sea directo a partir del diseo
3) Permitir implementacin por varios equipos
Capturar las interfaces
Usar una notacin comn 3
 2. Rol del Flujo de Trabajo
de diseo en el CV
Inicio Elaboracin Construccin Transicin
Requisitos

Anlisis

Diseo

Implementacin

Prueba

ite r. ite r. ite r. ite r. ite r. ite r. ite r.

Iteraciones: #1 #2 #n # n+ 1 # n+ 2 #m #m +1

Foco durante final de la

fase de elaboracin y El modelo de diseo
S se MANTIENE en
comienzo de construccin todo el proyecto
- obtener arquitectura estable 4
- y anteproyecto de implementacin
El CV del PUD de Rational separa
el diseo del despliegue

Diseo

Despliegue

5
 3. Artefactos a obtener en
el FT de diseo
Modelo del diseo
Subsistema de diseo
Clase de diseo
Realizacin de caso de uso -- Diseo diseo
Interfaz
Descripcin de la arquitectura
(vista del diseo)
Modelo de despliegue
Desc. de la arquitectura despliegue
(NO LO 6
(vista del despliegue) TRATAREMOS)
 JERARQUA DE SUBSISTEMAS
DE DISEO
MODELO DEL ANLISIS (MA) MODELO DEL DISEO (MDiseo)

PAQUETE DE SISTEMA DE
ANLISIS
DISEO

contiene
contiene
- Realizaciones de CU
- Realizaciones de CU
- Clases de diseo
- Clases de anlisis
- Interfaces
- Otros paquetes de anlisis
- Otros subsistemas de diseo

: IU-1 : Gesto : Libo elLibro NOMBRE DE L

1: ucir
NOMBRE DE L mtodo1 (parm),
2: Aceptar encuentre mtodo2 (parm)
3: obtenerLibro(signaturaLibro:String) atributo1,...

4: getSignatura() mtodo1 (m),

elLibro
5: getCopias()
CLASES DE CLASES6: isCoda()
INTER-
REALIZACIN-ANLISIS DE CU ANLISIS REALIZACIN-DISEO DE CU DE DISEO FACES

7
+ MODELO de DESPLIEGUE
 Artefacto:
Clase de diseo
Una clase de diseo es una abstraccin de una
clase (o constructor similar existente) en el LP
Operaciones, parmetros, atributos y tipos
Visibilidad de atributos y operaciones
Asociaciones y agregaciones (aunque luego se
implementen aadiendo atributos)
Generalizaciones (con la semntica del LP
utilizado) 8
 Artefacto:
Clase de diseo II
Los mtodos se especifican en
lenguaje natural o en pseudocdigo
Pueden especificarse requisitos de
implementacin de una clase
Pueden ponerse estereotipos
class module, form, user control en VB
interface en Java
9
 Artefacto: Realizacin
de CU -- diseo
Es una colaboracin que indica cmo se
realiza/ejecuta un CU, en trminos de las
clases de diseo y sus objetos
Para cada CU habr que aadir
El diagrama de secuencia
Flujo de eventos (en el diseo)
Requisitos de implementacin 10
Diagrama de Secuencia en UML
OBJETOS

obj1: IU_CU_X obj2: Gestor_X obj3: Clase_X

: ACTOR
1: escribe d
y solicita 2: busca(d)
3: getAtributoY()
.... .... return v
....

PASO DE MENSAJES / LLAMADAS A MTODOS11

Diagrama de Secuencia en UML

obj1: IU_CU_X obj2: Gestor_X obj3: Clase_X

: ACTOR
1: escribe d
y solicita 2: busca(d)
3: getAtributoY()
.... .... return v

....

FOCO DE CONTROL: LNEA DE LA VIDA:

perodo en el que el objeto perodo en el que el objeto
ejecuta algo existe
12
Nota: no seremos muy rigurosos sealando el foco de control
Diagrama de Secuencia en UML
: C1 : C2 : C3

new
hazX()

hazY()

destroy

Los objetos se pueden crear con el mtodo NEW

(comienza su lnea de vida y foco de control mientras
ejecutan cosas) y se pueden destruir con el mtodo
DESTROY (se termina su lnea de vida) 13
Diagrama de Secuencia en UML
obj1: IU_CU_X obj2: Gestor_X obj3: Clase_X
: ACTOR
1: escribe d
y solicita 2: busca(d)
3: getAtributoY()
.... .... return v

....

Significa que la clase Gestor_X debe

proporcionar el mtodo busca. As se Gestor_X
DISEAN las clases, esto es, se
identifican sus MTODOS a partir de busca(a:tipoD): tipoRes
las RESPONSABILIDADES definidas 14
durante el FT del anlisis
Diagrama de Secuencia en UML
obj2: Gestor_X obj3: Clase_X

getAtributoY()
return v

....

Una llamada a un mtodo puede devolver un valor

(mensaje return valor en lnea con puntos suspensivos).
Generalmente slo se pondr en el diagrama de secuencia
cuando proporcione informacin interesante 15
Diagrama de Secuencia en UML
: Gestor_Personas pp: Persona

getNombre()
return nombre

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 lnea en el
diagrama de secuencia y ser ms fcil de leer. 16
Diagrama de Secuencia en UML
: Gestor_Personas pp: Persona : Departamento

getNombre()
return nombre

setNombreJefe(nombre)

En este caso S ES NECESARIO. As podemos

ver que ponemos como nombre del jefe de
departamento el nombre del objeto pp.
17
Diagrama de Secuencia en UML
: Gestor_Emps emp: Empleado

getNombreYCategora()
return nombre y categora
....

Una llamada a un mtodo NO puede

devolver MS de un valor. Eso no es
posible utilizando un lenguaje OO 18
Diagrama de Secuencia en UML
obj1: IU_CU_X obj2: Gestor_X obj3: Clase_X
: ACTOR
1: escribe d
y solicita 2: busca(d)
.... .... ....
CONDICIN 5:
[est] 6: hazX()
7: hazW() ....
[no est] 6: hazY()

Los diagramas de secuencias muestran los envos de mensajes entre objetos

en orden secuencial (se aaden nmeros de secuencia 1: 2:, ). SE PUEDEN
AADIR CONDICIONES. Los nmeros de secuencia continan
independientemente en cada rama. NO HAY QUE ABUSAR DE LAS 19
CONDICIONES. Es mejor realizar distintos diagramas de secuencia.
Diagrama de Secuencia en UML
Objetos mltiples de Clase_X

obj2: Gestor_X :Clase_X

2: busca(d)
3: getAtributoY()

SE PUEDE AADIR REPETICIONES. De esta

manera se indica que a varios objetos de la clase
Clase_X se les pide ejecutar el mtodo getAtributoY()
20
Diagrama de Secuencia en UML
obj2: Gestor_X obj3: Clase_X

2: busca(d)
i=1..* 3: getAtributoY()
4: aadir(i)

Se repite de 1 a n veces. Se puede usar el valor i.

Esta es otra manera de especificar una repeticin:

usando un rectngulo en el que se encuadran todos
los pasos de mensajes que se van a repetir. Se puede
indicar la cardinalidad de cuntas veces se repite21o
una condicin de hasta cundo se repite.
Diagrama de Secuencia en UML
obj2: Gestor_X obj3: Clase_X

2: busca(d)
3: getAtributoY()

Repetimos hasta encontrar el

valor buscado

Esta es otra manera de especificar una repeticin:

utilizando una nota UML 22
Diagrama de Secuencia en UML
: Gestor_Emps emp: Empleado hi :Persona

getHijos()
return h1, h2, hN
getNombre()

Aunque hemos dicho que una llamada a

un mtodo NO PUEDE DEVOLVER
MS DE UN VALOR, permitiremos
esto como una notacin abreviada 23
Diagrama de Secuencia en UML
: Gestor_Emps emp: Empleado vec :Vector

getHijos()
:Persona
return vec
* getNext()
getNombre()

Recorrer todos los notacin abreviada

elementos del vector
de este diagrama de
24
secuencia
 Artefacto: Interfaz
Las interfaces se usan para especificar
operaciones
Separan la especificacin de la funcionalidad de
su implementacin
Las interfaces definen cmo se interacta entre
los subsistemas.
Las interfaces son requisitos para los equipos de
desarrollo y sirven para que los distintos equipos
puedan trabajar concurrentemente.
25
 Interfaz
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
CATLOGO
Otro se encarga del subsistema PRSTAMOS
Es evidente que cada equipo puede necesitar
ciertos mtodos del otro.
Lo que tienen que hacer es definirlos
utilizando interfaces
clases con slo mtodos no implementados
26
 Interfaz
Qu pueden necesitar del subsistema
SOCIOS?
Un mtodo que dado un nmero de socio
devuelva una referencia al objeto socio.
Un mtodo para aadir un nuevo socio al sistema.
Un mtodo para
: Gestor_Socios

Es una INTERFAZ que el

buscaSocio(nmero) equipo de PRSTAMOS
puede utilizar. El equipo de
SOCIOS ya proporcionar
una implementacin 27
Artefacto: descripcin de
la arquitectura (diseo)
Es una descripcin que contiene la vista
arquitectural del modelo del diseo
Los siguientes artefactos son arquitecturalmente
significativos:
Descomposicin del modelo en subsistemas junto
con sus interfaces
Clases de diseo claves
Realizaciones de casos de uso con funcionalidad
crtica 28
 4. Dos patrones de diseo
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
serializacin 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
29
SGBD, por ejemplo si se usa Java + JDBC
 Acceso a los datos
usando un sistema OO
El diseo es prcticamente equivalente al
diagrama de colaboracin de anlisis
Usar nombres de mtodos y no responsabilidades
Varias clases de diseo que sean interfaces grficas
Detallar casos excepcionales

Las clases de diseo que corresponden a

las clases entidad pueden tener mtodos
30
 Acceso a los datos usando
un SGBD relacional
El diseo cambia con respecto al diagrama de
colaboracin de anlisis
MODELO DEL DOMINIO / CLASES ENTIDAD (OO)
ESQUEMA LGICO DE UNA BD RELACIONAL
Se trata en la asignatura DBD. Supondremos que se sabe ya.
CLASE DISEO (GESTOR BD) permite ejecutar SQL
SQL se trata en FBD y DBD. Supondremos que se sabe ya.
Las CLASES ENTIDAD NO pueden tener MTODOS
31
Acceso a los datos usando
un SGBD relacional
GestorBD
Para INSERT/DELETE/UPDATE Para SELECT

execSQL(actualiz: String): void

execSQL(pregunta: String): ResultadoSQL

ResultadoSQL
Se posiciona en siguiente tupla
Devuelve false si no hay ms tuplas
next(): boolean Obtiene
valor del
get(nombreAtributo: String): String 32
atributo
 Acceso a los datos usando
un SGBD relacional
Preg1 = SELECT NOMBRE, EDAD
FROM PERSONA
WHERE EDAD>25

: GestorBD

execSQL(preg1)
new : ResultadoSQL

hasta que next()

no queden
tuplas [quedan tuplas] get(NOMBRE)

get(EDAD)
33
 Anexo: Artefacto:
Modelo de despliegue
Es un modelo de objetos que describe la distribucin
fsica del sistema en trminos de cmo se distribuye la
funcionalidad entre los distintos nodos
Cada nodo representa un recurso computacional
(procesador, dispositivo hardware,).
Las relaciones entre nodos representan formas de
comunicacin 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 34
Artefacto: descripcin de la
arquitectura (despliegue)

Es una descripcin que contiene la vista

arquitectural del modelo del despliegue
Todos los aspectos del modelo de despliegue
deben mostrarse en la vista de la arquitectura

35
 Anexo: Trabajadores
Arquitecto
Responsable de la integridad del modelo de diseo 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 mtodos, atributos,
relaciones y requisitos de implementacin de clases de
diseo. Debe mantener la integridad de los subsistemas
controlando que se realizan los interfaces.
36
Anexo: Actividades en el
FT de diseo
1.- Diseo de la arquitectura
Identificar nodos y configuraciones de red
Identificar subsistemas y sus interfaces
Identificar clases de diseo arquitecturalmente significantes
Identificar mecanismo de diseo genricos
2.- Disear caso de uso
Identificar clases de diseo participantes
Describir interacciones de objetos de diseo
Identificar los subsistemas participantes e interfaces
Describir interacciones entre subsistemas
Capturar requisitos de implementacin
37
 Actividades en el FT de
diseo
3.- Disear clase
Perfilar la clase de diseo
Identificar las operaciones
Identificar los atributos
Identificar asociaciones y agregaciones
Identificar generalizaciones
Describir los mtodos
Describir los estados
Tratar los requisitos especiales
4.- Disear subsistema
Mantener dependencias entre subsistemas
Mantener los interfaces proporcionados por el subsistema
38
Mantener los contenidos del subsistema