FLUJO DE TRABAJO

DISEÑO: PUDS Y UML

M.Sc. : Ing. Angélica Garzón Cuellar

1
Conceptos

 Es el proceso de aplicar distintas técnicas y

principios para definir un sistema con
suficiente detalle como para permitir su
realización física
 El diseñador debe crear un modelo o
representación de una entidad que se va a
crear posteriormente

2
Características de los métodos de
diseño

 Mecanismos para la transformación

 Notación para representar funciones y
datos
 Heurísticas para el refinamiento y partición
 Criterios para validar la calidad

3
Principios del Diseño
 Se debería poder seguir los pasos del
diseño hasta el modelado del análisis
 No debe inventar nada que ya esté
inventado
 Debería presentar uniformidad e integración
 debería estructurase para admitir cambios
 El diseño no es escribir código, y escribir
código no es diseñar
 Se debería valorar la calidad en el proceso

4
Abstracción

 Permite concentrarse en un problema a nivel

de generalización independiente de detalles
 Cada fase del proceso de desarrollo
constituye un nivel de abstracción
 Abstracción procedimental
 Abstracción de datos
 Abstracción de control

5
Modularidad

 Divide el software en componentes

identificables y tratables por separado, que
están integrados para satisfacer los
requisitos del programa
 Mientras mas subdividimos el esfuerzo
requerido es mínimo
 Modularidad Vs. Integración

6
Arquitectura del Software

 Es la estructura global del software y la

manera que esa estructura proporciona
integridad conceptual a un sistema
 A partir de esta versión se lleva a cabo
actividades de diseño mas detalladas
 Representan la arquitectura como una
colección organizada de componentes.

7
Estructura de datos

 Representación lógica entre elementos

individuales de datos
 Alternativas de organización, métodos de
acceso, capacidad de acceso y
procesamiento de información
 Elemento escalar, arreglos, listas, pilas,
colas, grafos, estructuras jerárquicas

8
Independencia funcional

 Se consigue con módulos con módulos con

una sola función y una aversión a excesiva
interacción con otros módulos
 Cohesión: es una medida de la fuerza
relativa funcional de un modulo
 Acoplamiento: es una medida de la
interdependencia relativa entre módulos.

9
 Diseño - Actividades

Diseño de la
Arquitecto arquitectura

Diseñar un caso de
Ingeniero de uso
casos de uso

Diseñar una clase Diseñar un

Ingeniero de subsistema
componentes
 Diseño - Actividades

 Diseño de la arquitectura

Subsistema
Modelo de Interfaz
Arquitecto
casos de uso

Clase de
diseño
Requisitos
adicionales Diseño de la
arquitectura
Modelo de
despliegue
Modelo de
análisis Descripción de la Descripción arquitectura
arquitectura (vista del (vista de modelo de
modelo de análisis) diseño y despliegue)
 Diseño - Actividades

 Diseño de un caso de uso

Realización caso
Modelo de de uso - diseño
casos de uso Ingeniero de
casos de uso
Requisitos
adicionales Clase de
diseño
Diseñar un caso de
uso
Modelo de
análisis Subsistema

Modelo de Modelo de Interfaz

diseño despliegue
 Diseño - Actividades

 Diseño de una clase

Realización caso
de uso - diseño Ingeniero de
componentes

Clase de
diseño
Diseñar una clase Clase de diseño
(completa)
Interfaz

Clase del análisis

(completa)
Diseño - Actividades

 Diseño de un subsistema

Ingeniero de
Descripción arquitectura
componentes
(vista modelo de diseño)
Subsistema
(terminado)

Subsistema
(esbozado) Diseñar un
subsistema
Interfaz
Interfaz (terminada)
(esbozada)
 Rol del Flujo de Trabajo de
diseño en el CV
Inicio Elaboración Construcción Transición
Requisitos

Análisis

Diseño

Implementación

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 elaboración y El modelo de diseño
SÍ se MANTIENE en
comienzo de construcción todo el proyecto
- obtener arquitectura estable
- y “anteproyecto” de implementación 15
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.

16
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

17
Actividades en el FT de
diseño
 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
18
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

19
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

20
… Diagrama de Despliegue
 La vista de despliegue representa la
disposición de las instancias de componentes
de ejecución en instacias de nodos
conectados por enlaces de comunicación.
 Un nodo es un recurso de ejecución tal como
 Dispositivos

 Procesadores

 Memoria

 Los nodos se interconectan mediante soportes

bidireccionales que pueden a su vez estereotiparse

21
Diagramas de despliegue

 Los nodos se interconectan mediante

soportes bidireccionales que pueden a
su vez estereotiparse.
 Esta vista permite determinar las
consecuencias de la distribución y la
asignación de recursos.

22
Diagrama de Despliegue

 Los Diagramas de Despliegue muestran la

disposición física de los distintos nodos que
componen un sistema y el reparto de los
componentes sobre dichos nodos

N o do

23
 III. El Paradigma OO: Diagrama de Despliegue

… Diagrama de Despliegue
 Ejemplo de conexión entre nodos:

<<Cliente>> <<Servidor>>
Terminal Punto <<TCP/IP>>
Base de
de Venta Datos

<<RDSI>>
<<RDSI>>
Podemos distinguir tipos Control
de nodos y connexiones
por estereotipado

24
a) Diseño de la Arquitectura

25
 Identificación de nodos y
configuraciones de red
• configuraciones físicas de la red
Cliente del
comprador – gran influencia sobre la arquitectura del software
– las configuraciones habituales utilizan una
arquitectura en tres capas (por ejemplo, cliente /
Intranet servidor)
• capa de clientes (interacciones de usuarios)
Servidor del • capa de funcionalidad de la base de datos
comprador
• capa de lógica de negocio o aplicación
– aspectos importantes de las configuraciones de red
internet
• número de nodos necesarios y capacidad en
Servidor términos de potencia de proceso y tamaño de
internet
del vendedor memoria
• tipo de conexiones entre los nodos y protocolos de
int ernet
comunicaciones a utilizar
intranet
• características de las conexiones y protocolos en
Servidor del aspectos como ancho de banda, disponibilidad y
banco
calidad
Cliente del
vendedor
– las configuraciones de red se muestran en
diagramas de despliegue

diseño orientado a objetos > diseño de la arquitectura

> identificación de nodos y configuraciones de red
26
 Identificación de nodos y
configuraciones de red
Cliente del Ejemplo de un sistema de comercio
comprador electrónico.

Se ejecuta sobre tres nodos servidores y un cierto

Intranet
número de nodos cliente.

En primer lugar existe un nodo servidor para el

Servidor del comprador y uno para el vendedor, debido a que
comprador
cada una de las organizaciones compradoras o
vendedoras necesitan un servidor central para sus
internet
objetos de negocio y su procesamiento.
Servidor Los usuarios finales, como el Comprador, acceden
del vendedor
internet al sistema mediante nodos cliente. Estos nodos se
comunican mediante el protocolo TCP/IP de
int ernet
Internet (o de intranets).
intranet
Servidor del También existe un tercer nodo servidor para el
banco propio banco. En él se producen los verdaderos
Cliente del pagos de facturas (es decir, las transferencias
vendedor entre cuentas).

27
Identificación de subsistemas de
la aplicación
• Subsistemas de la aplicación
– Identificación de los subsistemas de las capas específica y general de la
aplicación
– Si hubo descomposición adecuada en paquetes en el análisis, se pueden
utilizar para identificar subsistemas en el modelo de diseño

Capa específica de la aplicación

Capa general de la aplicación

Capa intermedia

Capa de software del sistema

28
Diseño de la Interfaz
Entrada de datos

29
 Introducción Diseño
 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

30
 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 diseño
 Interfaz
 Descripción de la arquitectura (vista del
diseño)
 Modelo de despliegue
 Desc. de la arquitectura despliegue (vista
del despliegue) (NO LO
31
TRATAREMOS)
 JERARQUÍA DE SUBSISTEMAS
DE DISEÑO
MODELO DEL ANÁLISIS (MA) MODELO DEL DISEÑO (MDiseño)

PAQUETE DE SISTEMA DE
ANÁLISIS
DISEÑO

contiene
contiene
- Realizaciones de CU
- Realizaciones de CU
- Clases de diseño
- Clases de análisis
- Interfaces
- Otros paquetes de análisis
- Otros subsistemas de diseño

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

1: ucir
NOMBRE DE L método1 (parám),
2: Aceptar encuentre método2 (parám)
3: obtenerLibro(signaturaLibro:String) atributo1,...

4: getSignatura() método1 (ám),…

elLibro
5: getCopias()
CLASES DE CLASES INTER-
6: isCoda()
REALIZACIÓN-ANÁLISIS DE CU ANÁLISIS REALIZACIÓN-DISEÑO DE CU DE DISEÑO FACES

+ MODELO de DESPLIEGUE
32
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)

33
 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

34
 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
35
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 MÉTODOS

36
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: LÍNEA DE LA VIDA:

período en el que el objeto período en el que el objeto
ejecuta algo existe
Nota: no seremos muy rigurosos señalando el foco de control
37
Diagrama de Secuencia en UML
: C1 : C2 : C3

new
hazX()

hazY()

destroy

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)
38
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 método busca. Así se Gestor_X
DISEÑAN las clases, esto es, se
identifican sus MÉTODOS a partir de busca(a:tipoD): tipoRes
las RESPONSABILIDADES definidas
39
durante el FT del análisis
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 línea en el
diagrama de secuencia y será más fácil de leer.
40
Diagrama de Secuencia en UML
: Gestor_Emps emp: Empleado

getNombreYCategoría()
return nombre y categoría
....

Una llamada a un método NO puede

devolver MÁS de un valor. Eso no es
posible utilizando un lenguaje OO
41
Diagrama de Secuencia en UML
obj1: IU_CU_X obj2: Gestor_X obj3: Clase_X
: ACTOR
1: escribe d
y solicita 2: busca(d)
.... .... ....
CONDICIÓN 5: …
[está] 6: hazX()
7: hazW() ....
[no está] 6: hazY()

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
42
CONDICIONES. Es mejor realizar distintos diagramas de secuencia.
Diagrama de Secuencia en UML
Objetos múltiples de Clase_X

obj2: Gestor_X :Clase_X

2: busca(d)
3: getAtributoY()

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()
43
Diagrama de Secuencia en UML
obj2: Gestor_X obj3: Clase_X

2: busca(d)
i=1..* 3: getAtributoY()
4: añadir(i)

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

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. 44
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 repetición:

utilizando una nota UML 45
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 método NO PUEDE DEVOLVER
MÁS DE UN VALOR, permitiremos
esto como una notación abreviada … 46
Diagrama de Secuencia en UML
: Gestor_Emps emp: Empleado vec :Vector

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

Recorrer todos los … notación abreviada

elementos del vector
de este diagrama de
secuencia 47
 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.

48
 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”)

49
 CU: Tomar en Préstamo Copia de Libro

IU-TPCL GestorLibro GestorPrestamos Libro elLibro:Libro :CopiaLibro GestorSocios Socio elSocio:Socio

1: Introducir
elSocio Signatura y numSocio()
Se repite hasta que se
2: Aceptar() encuentre un libro
con la signatura que
3: obtenerLibro(signaturaLibro:String)
estamos buscando
4: getSignatura()

elLibro()

5: obtenerCopiaLibre(elLibro:Libro) Se repite hasta que se

encuentre una copia
6: getCopias() no prestada o se acaben
las copias
7: getEstado()

laCopiaLibre()

8: [hay al menos una copia NO prestada]: obtenerSocio(numSocio:int)

9: getNumSocio()

10: haLLegadoLimite(elSocio:Socio)

11: isLímitePréstamo()

12: [no ha llegado al límite]: registrarPrestamo(elSocio:Socio, laCopiaLibre:CopiaLibro, HOY:Date)

13: new(elSocio:Socio, laCopiaLibre:CopiaLibro, HOY:Date)

prestamo
12: [alcanzado el máximo de préstamos]: new()
IUError

13: Aceptar()

8: [Todas las copias prestadas]: new(elLibro:Libro, elSocio:Socio)

IUReserva

9: añadirReserva(elSocio:Socio)
10: añadirReserva(elLibro:Libro)

Realización diseño – CU Tomar en Préstamo

Copia Libro (solución usando sistema OO) 50
 CU: Tomar en Préstamo Copia de Libro
Realización
diseño – CU
IU-TPCL GestorPrest GestorLibro GestorBD GestorSocios

Tomar en
1: Introducir Signatura y numSocio() C1:
Socio SELECT NumCopia
2: Aceptar()
FROM CopiaLibro as C
3: obtenerCopiaLibre(signatura:String)

Préstamo Copia
WHERE Estado="Disponible"
4: execSQL(c1:String) AND Signatura=%signatura

Libro (solución
5: new()
ResultadoSQL
8: next()

9 [Resultado no vacío]: get("NumCopia")

10: destroy()
usando sistema
11: isLímitePréstamo(numSocio:int)
C2:
SELECT MaxLibros
FROM SOCIO
SGBD)
WHERE NumSocio=%numSocio
12: execSQL(c2:String)
13: new()
ResultadoSQL

14: next()

15: get( "MaxLibros") Se podría hacer

con una única
16: destroy() C3:
SELECT *
FROM PRÉSTAMO
pregunta SQL
17: execSQL(c3:String)
WHERE NumSocio=%numSocio

18: new() Se repite tantas veces como

ResultadoSQL tuplas hay en el resultado
21: [Límite no alcanzado]: registrarPrestamo(socio:String, copia:String, fecha:Date)
19: next()
20: destroy()
C4: 22: execSQL(C4:String)
UPDATE CopiaLibro
SET Estado="Prestada" C5:
WHERE Signatura=%signatura INSERT INTO
AND NumCopia=%numCopia 23: execSQL(C5:String) PRÉSTAMO(Signatura, NumCopia, NumSocio, Fecha)
VALUES (%signatura, %numCopia, %numSocio, HOY)
21b: [Límite alcanzado]: new()
IUError

22: aceptar()
23: destroy()
9b: new(signatura:String, numSocio:int)
IUReserva C6:
10b: reservar() INSERT INTO
11b: execSQL(C6:String)
RESERVA(Signatura, NumSocio) 51
VALUES (%signatura,%numSocio)
…UML
DIAGRAMA DE SECUENCIA

52
Diagrama de secuencia

 Es una forma de diagrama de interacción

 Muestra los objetos como líneas de vida
 Muestra las interacciones ordenadas en el
tiempo como mensajes desde la línea de vida
origen hasta la línea de vida destino
 No están pensados para mostrar lógicas de
procedimientos complejos

53
Para que sirven?

 Mostrar qué objetos se comunican con qué

otros objetos y qué mensajes disparan esas
comunicaciones
 Para especificar casos de uso
 Para diseñar casos de uso
 Para diseñar operaciones de clases

54
Línea de vida

 Representa un
participante individual y
usualmente tiene un
rectángulo que contiene el
nombre del objeto
 Algunas veces tendrá una
línea de vida con un
símbolo del elemento actor
o clases del análisis, si es
contenido por un caso de
uso

55
Mensajes

 Es el mecanismo de interacción
entre objetos
 Se muestran como flechas
 Los mensajes pueden ser
síncronos o asíncronos
 En el ejemplo:
 El primer mensaje es un mensaje
síncrono (denotado por una punta
de flecha oscura), completo con un
mensaje de retorno implícito
 El segundo mensaje es asíncrono
(denotado por una punta de flecha
en línea)
 El tercero es un mensaje de
retorno asíncrono (denotado por
una línea punteada)

56
Foco de control

 Denota la
ocurrencia de
ejecución o
activación de un Mensaje Self :
foco de control • Llamada recursiva
de un objeto de una operación
 Es representado • Un método llamando
a otro método
como un
perteneciente al
rectángulo fino a mismo objeto
lo largo de la
línea de vida

57
Inicio y final de línea de vida

 Se puede crear o destruir

objetos durante la escala
de tiempo
 Representación:
 El símbolo al inicio de la
línea de vida se muestra en
un nivel más bajo del objeto
que causó la creación
 La línea de vida se termina
por un símbolo de
detención, representado
como una cruz

58
Fragmentos combinados

 Mecanismos que permiten agregar lógica de

procedimiento y se ejecutan bajo circunstancias
definidas por los operadores
 Operadores:
 Alternativas “alt” modela estructuras switch….
 Opción “opt” modela estructuras if…then…
 Paralelo “par” modela procesos concurrentes
 Critico “critical” se ejecutan sin interrupcion
 Bucle “loop” serie de mensajes iterativos

59
Operador “Opt”
sd SintaxisOpt

:Objet1 :Object2 :Object3

a()

opt
[expresion1]
b()

c()

e()
[expresion2]

d()

60
Operador “loop”

s d e j e m I te r a c i o n

: u se rI n t e rf a c e : d a t a C o n t ro l : d a t a S o u rc e

so l i c i t a rV e c t o r()

n = o b t T a m V e c t o r()

lo o p
[i = 1 ..n ]
o b t E l e m e n t o (i )

e n t re g a V e c t o r()

61