Transparencias Tema 3 Diseno Orientado A Objetos

Introducción al Diseño Orientado
a Objetos en UML
TEMA 3
Departamento de Ingeniería Informática

© Elena Orta
Tema 3. Introdución al Diseño Orientado a Objetos
en UML
3.1. Introducción al diseño de software.
3.2. Introducción a los patrones de diseño.
3.3. Patrón arquitectónico: Arquitectura en capas.
3.4. Diseño en UML.
3.4.1. Introducción.
3.4.2. Diseño de la capa de dominio.
3.4.3. Diagramas de interacción.
3.4.4. Diagrama de clases de diseño.
Bibliografía.
Objetivos Específicos
El alumno debe ser capaz de:
 Describir el objetivo y los principales resultados del Diseño del

Software.
 Definir qué es un patrón de diseño y diferenciar los diferentes

tipos de patrones de diseño.
 Describir y aplicar el patrón de diseño arquitectónico en capas

y en tres capas.
 Describir y aplicar los patrones de diseño GRASP.
 Describir el objetivo de los Diagramas de Interacción.
 Realizar Diagramas de Interacción: Diagramas de Secuencia y

Diagramas de Colaboración.
 Realizar Diagramas de Clases de Diseño.

Introducción al Diseño de Software
Etapas del desarrollo de software

Análisis de Requisitos
¿Qué sistema hay que construir?
Especificación
Independiente de ¿Qué ha de hacer el sistema?
la tecnología Especificación
del sistema
software
Dependiente de la Diseño
tecnología
¿Cómo lo hace el sistema?
Implementación
4
Introducción al Diseño de Software
Punto de Partida:
 Resultado de la Especificación: ¿Qué ha de hacer el
sistema?
 Tecnología: ¿Con qué recursos? Recursos hardware y
software disponibles
Proceso de Actividad de aplicar distintas técnicas

y principios con la finalidad de definir
Diseño un sistema con suficiente detalle para
que se pueda implementar
Resultado: ¿Cómo lo hace el sistema?

 Arquitectura del sistema software:
Descripción de los subsistemas y componentes de un
sistema software y las relaciones entre ellos.
 Diseño detallado del sistema software
5 Diseño de los componentes del Sistema.
Diseño en UML
Especificación Diseño
El sistema software se ve como una Cada clase de objetos tiene sus propias
sóla clase de objetos que engloba operaciones de manipulación de
toda la información y todas las información. Los objetos interactúan para
operaciones satisfacer las operaciones del sistema
sistema software
sistema software
: Clase 2
: Clase 3 : Clase 4
Diseño en UML
Especificación: ¿Qué hace el sistema software?
Resultado de la Especificación:
– Modelo de casos de uso:

 ¿Qué interacción hay entre los actores y las funciones del sistema software?
– Esquema conceptual de datos:

 ¿Cuáles son los conceptos relevantes del mundo real de referencia?
– Diagramas de secuencia del sistema:

 ¿Qué respuesta da el sistema a los eventos externos?¿Qué operaciones ha de
tener el sistema?
– Contratos de las operaciones

 ¿Qué hacen las operaciones del sistema?
Diseño en UML
Diseño: ¿Cómo estructuramos el sistema para que haga lo

que tiene que hacer?
Resultado del Diseño:
– Modelo de casos de uso:
 Define la interacción real, con una interfaz concreta
– Diagrama de clases de diseño:

 Describe las clases del software y sus operaciones
– Diagramas de secuencia:
 Define la interacción entre las clases de objetos para responder a un evento
externo
– Contratos de las operaciones:

 Definen qué hacen las operaciones de las clases de objetos
Diseño en UML
Especificación
– Los modelos definen los conceptos del mundo real (dominio del
problema)
– No tiene en cuenta las propiedades a lograr ni la tecnología que
se usará para implementar el sistema software
El enfoque de los modelos es

muy diferente en las dos etapas
Diseño
– Los modelos definen los conceptos que se desarrollarán para
proporcionar una solución a las necesidades del mundo real
(dominio de la solución)
– Puede ser necesario cambiar los modelos de especificación para
conseguir determinadas propiedades:
 Añadir información derivada (atributos y/o asociaciones), simplificar
jerarquías de generalización/especialización, añadir calificadores,
añadir clases redundantes,etc.
Diseño en UML
Ejemplo
Problema
Esquema conceptual de especificación (dominio del problema):
Persona Local
Afición
nombre: String * * * * dirección:String
nombre:String
tiene > se practica > ciudad: String
locales-a-ir ():locales
locales = {dirección}
Consideraciones:
– La operación locales-a-ir devuelve la lista de locales donde la

persona puede practicar sus aficiones. Esta operación es muy
utilizada.
– Se quiere que esta operación sea lo más eficiente posible.
Diseño en UML
Ejemplo
Solución
– Añadir una asociación derivada /Puede-ir entre persona y local
– Esta asociación podía no ser relevante en el dominio del problema
Diagrama de clases de diseño (dominio de la solución)
/ Puede-ir
Persona Local
Afición
* *
nombre: String * * dirección:String
tiene > nombre:String se practica >
ciudad: String
locales-a-ir ():locales
locales = {dirección}
Arquitectura del software
¿Qué se hace en general?
Dependiendo de:
– Propiedades que se quiere que cumpla el sistema
(requisitos no funcionales)
– Recursos tecnológicos disponibles
 Lenguajes de programación
 Sistema de gestor de bases de datos/Sistema de ficheros
 Etc.
Se determina
• La arquitectura del sistema software.

• Patrones que se usarán en el diseño del sistema.
Arquitectura del software
¿Cómo lo haremos en la asignatura?

Propiedades del sistema:
– Cambiabilidad y portabilidad.
Recursos tecnológicos:
– Lenguaje de programación orientado a objetos.
– Sistema de gestión de bases de datos.
• Arquitectura en tres capas.

• Orientación a objetos Capa Presentación y Capa del Dominio.
• Modelo de datos del SGBD: Relacional.
Patrones de Diseño
Contexto
• Situación donde se presenta el problema de diseño.
Problema
• Problema a resolver.
• Fuerzas: Aspectos que se han de considerar en la solución.
Solución
• Esquema de solución del problema que equilibra las fuerzas.
Patrones de Diseño
Patrón arquitectónico
• Expresa un esquema de organización estructural para sistemas software.
• Proporciona un conjunto de subsistemas predefinidos, especifica sus
responsabilidades e incluye reglas y guías para organizar las relaciones
entre ellas.
Patrón de diseño
• Una vez determinado el patrón arquitectónico, un patrón de diseño da un
esquema para refinar sus subsistemas o componentes, o las relaciones
entre ellos.
• Describe la estructura de una solución a un problema que aparece
repetidamente.
• Resuelve un problema de diseño general en un contexto particular.
Modismo
• Describe la estructura de la solución dependiendo del lenguaje de
programación.
Patrón arquitectónico: Arquitectura en capas
Contexto
• Un sistema grande que requiere su descomposición en grupos de
subtareas (componentes) tales que cada grupo de subtareas está en un
nivel determinado de abstracción.
Problema
• Hay que diseñar un sistema con la característica dominante de incluir
aspectos de alto y bajo nivel (de abstracción), donde las tareas de alto nivel
se basan en las de bajo nivel.
• Las tareas de alto nivel no se pueden implementar utilizando directamente los
servicios de la plataforma, a causa de su complejidad. Se necesitan servicios
intermedios.
Problema
• Fuerzas a equilibrar:
• Cambios en el código no deberían propagarse en todo el sistema

(mantenible).
• Los componentes se deberían poder reutilizar y reemplazar por

implementaciones alternativas (reusabilidad, separación de
interfaz e implementación).
• Responsabilidades similares se deberían agrupar para favorecer

la comprensibilidad y mantenibilidad (cohesión).
• Se desea portabilidad a otras plataformas.

Solución
Sistema
• Estructurar el sistema en un número Cliente Software
apropiado de capas.
Nivel más alto de
• Colocar las capas verticalmente. Capa N abstracción
• Todos los componentes de una misma

capa han de trabajar en el mismo nivel de Capa N-1
abstracción.
• Los servicios que proporciona la capa j

utilizan servicios proporcionados por la
capa j-1. Al mismo tiempo, los servicios de Nivel más bajo
la capa j pueden depender de otros Capa 1 de abstracción
servicios en la misma capa.
Dispositivos Físicos
Patrón: Arquitectura en tres capas
Arquitectura en tres capas

Eventos presentación: menú
selecciónado, botón pulsado,
mostrar ventana
Responsable de la interacción
Capa Presentación con el usuario
Capa del Dominio

Responsable de la
implementación de las
Capa de Gestión de datos funcionalidades del sistema
Sistemas gestión bases de datos/ficheros

Responsable de la interacción
con el SGBD/Ficheros
Operaciones:
entrada/salida
eventos presentación
Presentación
• Se entera peticiones usuario.
• Ordena ejecución acciones.
• Comunica resultado acciones a usuarios.
• Tratamiento de: ventanas, diálogos, menús, botones, listados.
Sabe cómo presentar los datos al usuario, pero no sabe qué

transformaciones hay que hacer para dar respuesta a las
peticiones del usuario.
eventos externos, respuestas resultados

consultas
Dominio
Presentación
eventos externos respuestas, resultados
Dominio
• Recibe eventos • Ejecuta acciones
• Controla validez eventos • Obtiene los resultados
• Cambio estado del dominio • Envía respuestas Capa Presentación
La capa de dominio sabe cómo satisfacer las peticiones del

usuario, pero ignora dónde se guardan los datos y cómo se
presentan al usuario
operaciones de consulta y
modificación de datos respuestas, resultados
Gestión de datos
Dominio
operaciones de consulta y respuestas, resultados

modificación de datos
Gestión de Datos
• Permite que el dominio pueda ignorar dónde están los datos
• Las funciones concretas de esta capa dependen del SGBD que se use
• La capa de gestión de datos sabe dónde y cómo están almacenados los

datos, pero desconoce cómo tratarlos
• Transforma operaciones conceptuales en operaciones físicas
modificación en el lenguaje de respuestas, resultados
bases de datos y ficheros
Sistemas de gestión bases de datos/ficheros

Gestión de Datos
modificación de datos en el respuestas,
lenguaje de las bases de datos resultados
y ficheros
Esquema SGBDi …….. SGFj
Se encarga de mantener una representación

persistente y concreta del estado de dominio
Recibo
Cliente 1 código: String :Sistema

* :Usuario
fecha: Fecha
nombre: String Tiene > nuevo-recibo(wcódigo, wcliente,
importe: Integer
wfecha, wimporte)
Claves externas
Contrato de la operación “nuevo recibo”:

Nombre: nuevo-recibo (wcodigo, wcliente, wfecha, wimporte).
Responsabilidades: registrar un nuevo recibo de un cliente.
Precondiciones:
Existe un cliente con nombre = wcliente y no tiene ningún recibo con código =
wcódigo.
Postcondiciones:
Se crea un objeto R de Recibo con R.codigo = wcódigo, R.fecha=wfecha y
R.importe=wimporte.
Se crea un enlace de la asociación “Tiene” entre el objeto R de Recibo y el
objeto de la clase cliente con nombre = wnombre.
Presentación
nuevoRecibo(wcodigo, wcliente, wfecha, respuesta

wimporte)
Dominio
ExisteCliente?(wcliente) ExisteRecibo?(wcódigo) CreaRecibo(wcodigo, wcliente, wfecha,

wimporte)
Gestión de Datos
Select clientes from Select código from Recibos Insert into Recibos …
Clientes where where
SGBD
Tablas:
Clientes (cliente,...)
Recibos (codigo, fecha, importe, cliente, …)
Capa de Dominio (Patrones GRASP)
Patrones GRASP
Patrones de Principios Generales para Asignar
Responsabilidades
– Principios fundamentales para guiar la asignación de responsabilidades
a objetos.
– La asignación de responsabilidades a objetos se hace durante el

diseño, al definir las operaciones de cada clase de objetos.
– La asignación de responsabilidades se muestra en los diagramas de

interacción mediante mensajes que se envían a las clases de objetos.
Patrones GRASP básicos
– Experto en Información.
– Creador.
– Controlador.
– Alta Cohesión.
– Bajo Acoplamiento.
Patrón Experto en Información

 Contexto: Asignación de responsabilidades a objetos
 Problema: ¿Cuál es el principio general para asignar

responsabilidades a los objetos? Decidir a qué clase hemos de
asignar una responsabilidad concreta.
 Solución:
– Asignar una responsabilidad a la clase que tiene la información
necesaria para realizarla.
– La aplicación del patrón requiere tener claramente definidas las
responsabilidades que se quieren asignar (postcondiciones de
las operaciones).
– No siempre existe un único experto, sino que pueden existir
diversos expertos parciales que tendrán que colaborar.
 Ejemplo: ¿Quién es el responsable de conocer el total de una venta?
Diagrama de Venta Producto

Clases fecha contiene LíneaVenta descrito por artículoID
hora cantidad 1 descripción
Conceptual 1 1..* *
precio
• ¿Qué información se necesita para determinar el total? Es necesario conocer todas

las instancias de LineaVenta de una venta y la suma de sus subtotales. Una instancia
de Venta las contiene: Según Experto en Información, se asigna a la clase Venta la
responsabilidad de conocer su total.
• ¿Qué información se necesita para determinar el subtotal de la LíneaVenta? Se

necesitan LineaVenta.cantidad y Producto.precio. La LineaVenta las conoce, la
LíneaVenta conoce su cantidad y el Producto asociado; por tanto, según el Experto en
Información se asigna a la clase LíneaVenta la responsabilidad de conocer su subtotal.
• Para determinar el subtotal, LíneaVenta necesita conocer el precio del producto,

Producto es un Experto en Información que proporciona su precio.
Diagrama de Clases de Diseño
Venta Producto
LíneaVenta artículoID
fecha contiene descrito por
hora descripción
1 1..* cantidad * 1 precio
getSubtot ()
getTotal () getPrecio ()
Clase Diseño Responsabilidad

Venta Conocer total venta: getTotal ()
LíneaVenta Conocer subtotal línea venta: getSubtot ()
Producto Conocer precio artículo: getPrecio ()
• Diagrama de Interacción (Diagrama de Secuencia)
V:Venta P:Producto
Lv:Venta
Total:= getTotal ()
* Subtot := getSubtot ( )
Precio := getPrecio ( )
• Diagrama de Clases de Diseño
Venta Producto
LíneaVenta artículoID
fecha contiene cantidad descrito por
hora 1 1..* * 1 descripción
getSubtot () precio
getTotal ()
getPrecio ()
Venta Producto
fecha contiene LíneaVenta descrito por artículoID
hora cantidad
1 1..* * 1 descripción
getTotal () getSubtot () precio
getPrecio ()
Clase Diseño Responsabilidad

Venta Conocer total venta: getTotal ()
LíneaVenta Conocer subtotal línea venta: getSubtot ()
Producto Conocer precio artículo: getPrecio ()
Patrón Creador
 Problema: ¿Quién ha de tener la responsabilidad de crear una

instancia de una clase?
 Solución: Asignar a la clase B la responsabilidad de crear una

instancia de una clase A si satisface una de las siguientes
condiciones:
– B es un agregado de objetos de A.
– B contiene objetos de A.
– B tiene los datos necesarios para inicializar un objeto de A
(B tiene los valores de los parámetros del constructor de A).
– B usa muchos objetos de A.
– B guarda instancias de objetos de A.
 Ejemplo: ¿Quién es el responsable de crear una línea de venta de una

venta?
 La clase Venta contiene instancias de la clase LíneaVenta. Según Creador,
se asigna a la clase Venta la responsabilidad de crear una LíneaVenta.
• Diagrama de Clases Conceptual
Venta Producto
fecha contiene LíneaVenta descrito por artículoID
hora 1..*
cantidad * 1 descripción
1
precio
• Diagrama de Interacción (Diagrama de Secuencia)

:Clase
Control V:Venta
añadirLíneaVenta
(Refv,prod,cant)
crearLíneaVenta (prod,cant)
create (prod,cant)
Lv:LíneaVenta
Venta
fecha contiene LíneaVenta
hora cantidad
1 1..*
crearLíneaVenta (prod,cant) create (prod,cant)
descrito por
Producto
artículoID
descripción
precio
Patrón de diseño controlador

 Contexto:
– Los sistemas software reciben eventos externos.
– Una vez recibido un evento en la capa de presentación, algún
objeto de la capa de dominio ha de recibir este evento y ejecutar
las acciones correspondientes.
 Problema:
– ¿Qué objeto es el responsable de tratar un evento externo?
 Solución:
– Asignar esta responsabilidad a un controlador.
– Un controlador es un objeto de una clase (no pertenece a la
interfaz usuario).
– Posibles controladores:
 Controlador de Fachada: Una clase que representa todo el sistema.
 Controlador de Caso de uso: Una clase que representa una instancia de
un caso de uso.
La Tienda Plus
presiona botón Artículo ID:
Cantidad:
Cajero
Introducir Artículo Cancelar
actionPerformed (actionEvent)
mensaje de evento del

Capa de Interfaz :JFrameVenta sistema
IntroducirArtículo (artículoID, cant)
Capa del Dominio : ???
• ¿Qué clase de objetos es la responsable de recibir este mensaje de evento

del sistema?
• Se suele denominar “controlador” . Normalmente no hace el trabajo, sino que
lo delega a otros objetos. Es una especie de “fachada” sobre la capa de
dominio para la capa de interfaz
Opciones de controlador
Capa de Interfaz
:IU :SistemaControl :Obj1 :Obj2 ...

Controlador de Fachada: controla
todos los eventos del Sistema
:IntroducirArtículo
:IU :Obj1 ...
Control :Obj2

Controlador de Caso de Uso:
controla todos los eventos del sistema
de un escenario de un caso de uso
Acoplamiento
Medida del grado de conexión, conocimiento y dependencia de una
clase respecto a otras clases

 Problema: ¿Cómo soportar bajas dependencias, bajo impacto del
cambio e incremento de reutilización?
 Hay un acoplamiento de la clase A a la clase B si: B

– A tiene un atributo de tipo B
– A tiene una asociación navegable con B
– B es un parámetro o el retorno de una operación de A
– Una operación de A hace referencia a un objeto de B
– A es una subclase directa o indirecta de B
A
atributo: B
operac (b:B): B
Acoplamiento
 Solución: El acoplamiento entre clases ha de ser bajo para:
– Evitar que cambios en una clase tengan efecto sobre otras clases.
– Facilitar la comprensión de las clases (sin recurrir a otras).
– Facilitar la reutilización.
Cohesión
Medida del grado de relación y de concentración de las distintas
responsabilidades de una clase
 Contexto: Asignación de responsabilidades a objetos.
 Problema: ¿Cómo mantener la complejidad controlable?
 Solución: Asignar responsabilidades de manera que la cohesión

permanezca alta.
Cohesión
 Una clase con cohesión alta:
– Tiene pocas responsabilidades en un área funcional.
– Colabora con otras clases para hacer las tareas.
– Suele tener pocas operaciones muy relacionadas funcionalmente.
– Ventajas: fácil comprensión y fácil reutilización y mantenimiento.
 Una clase con cohesión baja:

– Tiene muchas responsabilidades de distintas áreas funcionales.
– Tiene muchas operaciones poco relacionadas funcionalmente.
– Inconvenientes: difícil de comprender, difícil de reutilizar y de
mantener, sensible a los cambios.
 Ejemplo: Los controladores fachada suelen ser poco cohesivos.

Diagramas de Interacción
 Interacción: Comportamiento que comprende un conjunto de

mensajes intercambiados entre un conjunto de objetos dentro de un
contexto para lograr un propósito.
 Mensaje: especificación de una comunicación entre objetos que

transmite información, con la expectativa de desencadenar una
actividad.
 Se describe cómo los objetos colaboran entre sí para realizar cierta activida
(interacción)
 Dos tipos de Diagramas de Interacción:
– Diagramas de Secuencia
 Destacan la ordenación temporal de los mensajes
– Diagramas de Colaboración
 Destacan la organización estructural de los objetos participantes
 Equivalencia semántica (prácticamente isomorfos)
 Notación general diagramas interacción:
– Instancia de una clase, mismo símbolo con texto subrayado

Venta :Venta v1:Venta
– Sintaxis mensajes:
 return := mensaje (parametro: tipoParametro): tipoRetorno
Diagramas de Secuencia
 Representan escenarios.
 Incluye:
– Objetos y su línea de vida.
– Mensajes.
– Información de control: condiciones y marcas de iteración.
– Indicar el objeto devuelto por el mensaje: return.
:A :B :C
z:= Mensaje 1 parámetros
resultado
Mensaje 2 (x,y)
línea vida
objeto destinatario
emisor
Orden envío: posición s/eje vertical

 Focos de control y cajas de activación

– Se pueden mostrar los focos de control (llamada de rutina ordinaria,
la operación está en la pila de llamadas) utilizando cajas de
activación.
:A :B :A
msj1( ) msj1()
msj2( )
msj2( )
msj3( )
msj4( )
 Mensajes a “self” o “this”

– Mensaje que se envía de un objeto a él mismo utilizando caja de
activación anidada.
 Creación de objetos
– Mensaje de creación apunta al símbolo del objeto.
 Destrucción de objetos
– Fin de la línea de vida del objeto.
estereotipos
:A
<<create>>
:B
<<destroy>>
 No se suele representar el retorno de un mensaje ( )

 Mensajes condicionales
:A :B
msj1( )
[X] msj2( )
 Mensajes condicionales mutuamente exclusivos
:A :B :C
msj1( )
[X] msj2( )
[Y] msj3( )
 Iteración para un único mensaje
:A :B
msj1( )
* [X]: msj2( )
 Iteración de una serie de mensajes
:A :B :C
msj1( )
msj2( )
msj3( )
* [X]
msj4( )
 Iteración sobre una colección (multiobjeto)
:A :B
msj1( )
*: msj2( )
 Mensajes a objetos de clase
:A :B
msj1( )
msj2( ) no subrayada,
es una clase
– Llamada a los métodos de clase o estáticos.

Diagramas de Colaboración
 Representan escenarios.
 Incluye:
– Objetos y ENLACES (relaciones estructurales objetos).
– Mensajes.
– Información de control: condiciones y marcas de iteración.
– Indicar el objeto devuelto por el mensaje: return.
msj1( )
:InstanciaClaseA
1: msj2 ( )
2: msj3 ( )
:InstanciaClaseB
Ejemplos de Diagramas de Interacción
 Ejemplo de diagrama de secuencia: realizarPago
:ControlVenta :Venta
realizarPago(dinero
entregado)
realizarPago(dinero entregado) create (dinero entregado)
:Pago
 Ejemplo de diagrama de colaboración: realizarPago
realizarPago(dinero
entregado) 1: realizarPago(dinero entregado)
:Control
:Venta
Venta
1.1: create(dineroentregado)
:Pago
 Enlaces
– Camino de conexión entre dos objetos. Indica que es posible alguna forma
de navegación entre los objetos.
1: mensaje 1 ()
2: mensaje 2 ( )
:A :B
2.1: mensaje 3 ( )
línea del enlace
En un mismo enlace puede haber múltiples mensajes en ambas direcciones.
 Mensajes
– Expresión del mensaje y flecha que indica la dirección. Añadir número de
secuencia para mostrar el orden secuencial.
msj1 () 1: msj2()
2: msj3()
3: msj4()
:Registro :Venta
3.1: msj5()
 Mensajes a “self” o “this”

– Mensaje desde un objeto a él mismo.
msj1()
:Registro
 Creación de instancias 1: limpiar ()

– Convenio: mensaje create. Si se utiliza otro nombre, añadir estereotipo
“create”.
– Mensaje create puede incluir parámetros (valores iniciales). Opcionalmente
se puede añadir la propiedad {new}.
1: create (cajero)
:Registro :Venta {new}
<<create>>
1: hacer (cajero)
:Registro :Venta {new}
 Secuencia de números de mensajes

– El orden de los mensajes se representa mediante números de secuencia:
 No se numera el primer mensajes
 El orden y anidamiento de los siguientes mensajes se muestra con un número.
El anidamiento se denota anteponiendo el número del mensaje entrante al
mensaje saliente.
segundo
tercero
msj1() 1: msj2()
:Clase A :Clase B
1.1: msj3()
primero 2.1: msj5()
2: msj4()
:Clase C
quinto
cuarto 2.2: msj6()
sexto :Clase D
 Mensajes condicionales
msj1 () 1[condición]: msj2 ()

:Clase A :Clase B
 Caminos condicionales
Incondicional después del 1a y 1b son caminos condicionales

msj3 o el msj5 :Clase E mutuamente exclusivos
2: msj6 ()
msj1 () 1a [condición1]: msj2 ()

:Clase A :Clase B
1b [no condición1]: msj4 ()

1a.1: msj3 ()
1b.1: msj5 ()
:Clase D :Clase C
Modificar las expresiones de la secuencia con una letra de camino condicional.

 Iteración o bucle
msj1 () 1* [i = 1..N]: msj2 ()

:Clase A :Clase B
La iteración se indica con un * y una cláusula de iteración opcional a

continuación del número de secuencia
 Iteración sobre una colección (multiobjeto)
msj1 () 1*: msj2 ()

:Clase B
:Clase A
*
Estos dos símbolos * utilizados conjuntamente implican iteración la doble caja indica un
sobre el multiobjeto y el envío del mensaje msj2 a cada uno de los multiobjeto (colección)
miembros
 Mensaje a un objeto clase
msj1 () msj2 ()
:Clase A Clase B
Mensaje a una clase o invocación a método estático no subrayada, es una clase

Diagrama Secuencia Vs Diagrama Colaboración
 Equivalencia semántica.
 Simples para comportamientos simples.
 Si hay mucho comportamiento condicional, usar diferentes escenarios.
 Diagramas de secuencia muestran mejor el orden en que se ejecutan los
mensajes.
 Diagramas de colaboración muestran claramente los objetos con los que
interactúa un determinado objeto.
 A partir de los Diagramas de Interacción realizados durante el Diseño,

obtener el Diagrama de Clases de Diseño:
– Clases que participan en las interacciones.

– Relaciones entre las clases necesarias para que las clases colaboren.
– Atributos de las clases de diseño.
– Operaciones de las clases de diseño: mensajes que reciben las
clases.
 El Diagrama de Clases de Diseño ≠ Diagrama de Clases Conceptual.

Bibliografía
• Booch, G.; Jacobson, J.; Rumbaugh, J.M. El lenguaje unificado de

modelado. Manual de Referencia, 2ª ed. Ed. Addison Wesley, 2007.
• Booch, G.; Jacobson, J.; Rumbaugh, J.M. El lenguaje unificado de

modelado. Guía de Usuario, 2ª ed. Ed. Addison Wesley, 2007.
• Gómez, C., Mayol, E., Olivé, A., Teniente, E. Diseño de sistemas

software en UML. Edicions UPC, 2003.
Bibliografía
• C. Larman. UML y Patrones: Una introducción al análisis y diseño

orientado a objetos y al proceso unificado. 2ª ed. Prentice-Hall, 2003.

Transparencias Tema 3 Diseno Orientado A Objetos

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

Transparencias Tema 3 Diseno Orientado A Objetos

Cargado por

Copyright:

Formatos disponibles

Introducción al Diseño Orientado

Departamento de Ingeniería Informática

3.1. Introducción al diseño de software.

3.2. Introducción a los patrones de diseño.

3.3. Patrón arquitectónico: Arquitectura en capas.

3.4. Diseño en UML.

3.4.2. Diseño de la capa de dominio.

3.4.3. Diagramas de interacción.

3.4.4. Diagrama de clases de diseño.

El alumno debe ser capaz de:

 Describir el objetivo y los principales resultados del Diseño del

 Definir qué es un patrón de diseño y diferenciar los diferentes

 Describir y aplicar el patrón de diseño arquitectónico en capas

 Describir y aplicar los patrones de diseño GRASP.

 Describir el objetivo de los Diagramas de Interacción.

 Realizar Diagramas de Interacción: Diagramas de Secuencia y

 Realizar Diagramas de Clases de Diseño.

Etapas del desarrollo de software

Proceso de Actividad de aplicar distintas técnicas

Resultado: ¿Cómo lo hace el sistema?

Especificación: ¿Qué hace el sistema software?

– Modelo de casos de uso:

– Esquema conceptual de datos:

– Diagramas de secuencia del sistema:

– Contratos de las operaciones

Diseño: ¿Cómo estructuramos el sistema para que haga lo

– Diagrama de clases de diseño:

– Contratos de las operaciones:

El enfoque de los modelos es

– La operación locales-a-ir devuelve la lista de locales donde la

Diagrama de clases de diseño (dominio de la solución)

¿Qué se hace en general?

• La arquitectura del sistema software.

¿Cómo lo haremos en la asignatura?

• Arquitectura en tres capas.

• Cambios en el código no deberían propagarse en todo el sistema

• Los componentes se deberían poder reutilizar y reemplazar por

• Responsabilidades similares se deberían agrupar para favorecer

• Se desea portabilidad a otras plataformas.

• Todos los componentes de una misma

• Los servicios que proporciona la capa j

Arquitectura en tres capas

Capa del Dominio

Sistemas gestión bases de datos/ficheros

Sabe cómo presentar los datos al usuario, pero no sabe qué

eventos externos, respuestas resultados

eventos externos respuestas, resultados

La capa de dominio sabe cómo satisfacer las peticiones del

operaciones de consulta y respuestas, resultados

• La capa de gestión de datos sabe dónde y cómo están almacenados los

Sistemas de gestión bases de datos/ficheros

Esquema SGBDi …….. SGFj

Se encarga de mantener una representación

Cliente 1 código: String :Sistema

Contrato de la operación “nuevo recibo”:

nuevoRecibo(wcodigo, wcliente, wfecha, respuesta

ExisteCliente?(wcliente) ExisteRecibo?(wcódigo) CreaRecibo(wcodigo, wcliente, wfecha,

– La asignación de responsabilidades a objetos se hace durante el

– La asignación de responsabilidades se muestra en los diagramas de

Patrones GRASP básicos

Patrón Experto en Información

 Problema: ¿Cuál es el principio general para asignar

 Ejemplo: ¿Quién es el responsable de conocer el total de una venta?