DESARROLLO DE SOFTWARE ORIENTADO A

OBJETOS

TEMA 4. DISEÑO ORIENTADO A OBJETOS

Presenta: Mtro. David Martínez Torres

Universidad Tecnológica de la Mixteca
Instituto de Computación
Oficina No. 37
dtorres@gs.utm.mx
Contenido

1. Diferencia entre análisis y diseño

2. Artefactos involucrados
3. Personas involucradas y sus actividades
4. Introducción a los patrones de diseño
5. Modelado de diseño
Introducción

 Los requisitos y el AOO se han centrado en aprender a hacer lo

correcto, es decir, en entender algunos de los objetivos importantes
del sistema a desarrollar, las reglas y restricciones relacionadas.
 Por el contrario, el diseño se enfocará en hacerlo correcto, esto es,
diseñar con destreza una solución que satisfaga los requisitos de cada
iteración.
Retomando el ejemplo del diseño en el Desarrollo Orientado a
Objetos[16]
Los casos de uso no son artefactos orientados a objetos -- son
simplemente historias escritas --. Sin embargo, son una herramienta muy
popular en el análisis de requisitos y son una parte importante del
Proceso Unificado. Ejemplo, versión breve del caso de uso Jugar una
partida de Dados:

Jugar una partida de dados: Un jugador recoge y lanza los dados. Si

el valor de las caras de los dados suman siete, gana; en otro caso,
pierde.
 Ejemplo con Desarrollo Orientado a Objetos[16]
Ejemplo del Modelo del dominio parcial del juego de dados. Este modelo
ilustra los conceptos importantes Jugador, Dado, JuegoDados, con sus
asociaciones y atributos.
Nótese que un
modelo del dominio
no es una descripción
de los objetos
software,
es una visualización
de los conceptos en
el dominio del
mundo real.
Retomando el ejemplo del diseño en el Desarrollo Orientado a
Objetos[16]
Definición de los diagramas de interacción
La finalidad del diseño orientado a objetos es definir los objetos
software y sus colaboraciones. Una notación habitual para ilustrar estas
colaboraciones es el diagrama de interacción. Muestra el flujo de
mensajes entre los objetos software y, por tanto, la invocación de
métodos.
Retomando el ejemplo del diseño en el Desarrollo Orientado a
Objetos[16]

El diagrama de
interacción, ilustra
los pasos
esenciales del
juego, enviando
mensajes a las
clases JuegoDados
y Dado.
Retomando el ejemplo del diseño en el Desarrollo Orientado a
Objetos[16]

Observe que, aunque en el mundo

real un jugador lanza los dados, en
el diseño de software, el objeto
JuegoDados “tira” los dados (es
decir, envía mensajes a los objetos
Dado). Los diseños de los objetos
software y los programas se
inspiran en los dominios del
mundo real, pero no son modelos
directos o simulaciones del mundo
real.
Retomando el ejemplo del diseño en el Desarrollo Orientado a
Objetos[16]
Además de la vista dinámica de las colaboraciones entre los objetos que
se muestra mediante los diagramas de interacción, es útil crear una vista
estática de las definiciones de las clases mediante un diagrama de clases
de diseño.
Retomando el ejemplo del
diseño en el Desarrollo
Orientado a Objetos[16]
El diagrama de interacción
conduce al diagrama de
clases de diseño parcial.
Dado que se envía el
mensaje jugar al objeto
JuegoDados, entonces,
JuegoDados requiere un
método jugar, mientras la
clase Dado requiere los
métodos lanzar y
obtenerValorCara.
1. Diferencia entre el análisis y diseño [2, 13]

 El Análisis da prioridad al conocimiento de los requerimientos, los

conceptos y las operaciones relacionadas con el sistema. Es decir, se
centra en el qué: cuales son los procesos, los conceptos etc.
 El propósito del análisis es transformar los requisitos del sistema en
una estructura que pueda ser convertida en software, a través de un
conjunto de clases y subsistemas.
 Esta transformación es manejada por los casos de uso, es decir, el
manejo de los requisitos funcionales y está complementada por los
requisitos no funcionales; del modelo del dominio y de diagramas de
secuencia del sistema.
 Esto se hace para simplificar la representación, de forma que el
análisis expresa una imagen cercana a un sistema ideal.
1. Diferencia entre el análisis y diseño [2, 13]

 El Diseño por su parte, pone énfasis en una solución conceptual que

satisface los requisitos, en vez de ponerlo en la implementación. Por
ejemplo, una descripción del esquema de una base de datos y objetos
software.
 El diseño se centra en la definición de los objetos software y en cómo
colaboran para satisfacer los requisitos. Por ejemplo, en el sistema de
la biblioteca, un objeto software Libro podría tener un atributo titulo y
un método obtenerCapitulo.
1. Diferencia entre el análisis y diseño [2]

 En la fase de Diseño se crea una solución lógica fundamentada en el

paradigma OO. Su esencia es la elaboración del diagrama de
interacción y con este el diagrama de clases (e interfaces)
 Adapta los resultados del análisis a las restricciones impuestas por los
requisitos no funcionales, ambiente de implementación, requisitos de
rendimiento, etc.
Relación del contrato con
otros artefactos [13]
2. Artefactos involucrados

Los artefactos más significativos son:

 El diagrama de interacción, que muestra gráficamente cómo los
objetos se comunicarán entre ellos a fin de cumplir con los
requerimientos.
 El diagrama de clases (del diseño) resume la definición de las clases
software (e interfaces) que se van a implementar en software.
 El Documento de Arquitectura del Sistema, el cual captura varias
vistas de la arquitectura del sistema.
Dependencias
de los
artefactos
durante la
fase de
construcción
[16]
3. Personas involucradas y sus actividades

 Arquitecto de software. Este dirige y coordina las actividades y

artefactos utilizados en esta parte del proyecto. Establece la
estructura global de cada vista de la arquitectura: la vista de
descomposición, el agrupamiento de elementos, y las interfaces entre
los principales agrupamientos.
 Diseñador. Define las responsabilidades, operaciones, atributos y
relaciones de una o muchas clases y determina como estas serán
ajustadas al ambiente de implementación
3. Personas involucradas y sus actividades

 Diseñador de base de datos. Es necesario cuando el sistema

requiere de una base de datos.

 Revisor de arquitectura y revisor de diseño. Son especialistas que

revisan los artefactos producidos por el flujo de trabajo.
Recordando el Modelo
del dominio parcial,
considerando las
recomendaciones y
agregados algunos
atributos [13].
4. Introducción a los patrones de diseño

 Después de la identificación de requisitos y la creación de un modelo

del dominio, entonces se realiza el diseño de objetos, añadiendo
métodos a las clases del software, y definiendo el paso de mensajes
entre los objetos para satisfacer los requisitos.
 La decisión de qué métodos, dónde colocarlos y cómo deberían
interactuar los objetos, es muy importante y nada trivial. Esta es una
etapa crítica; es la parte esencial de lo que entendemos por
desarrollar un sistema orientado a objetos, no el dibujo de diagramas
del dominio, diagramas de paquetes, etc.
4. Introducción a los patrones de diseño
4. Introducción a los patrones de diseño

 Los patrones GRASP (General Responsibility Assignment Software

Patterns, Patrones Generales de Software para Asignar
Responsabilidades) son un apoyo para la enseñanza que ayuda a
entender el diseño de objetos esencial y aplica el razonamiento para el
diseño de una forma sistemática, racional y explicable.
 UML define una responsabilidad como "un contrato u obligación de un
clasificador (clase)". Las responsabilidades están relacionadas con las
obligaciones de un objeto en cuanto a su comportamiento. Las
responsabilidades son de dos tipos:
 Conocer
 Hacer
4. Introducción a los patrones de diseño: GRASP

 Entre las responsabilidades de hacer de un objeto se

encuentran:
 Hacer algo él mismo, como crear un objeto o hacer un cálculo
 Iniciar una acción en otros objetos
 Controlar y coordinar actividades en otros objetos
4. Introducción a los patrones de diseño

 Entre las responsabilidades de conocer de un objeto se

encuentran:
 Conocer los datos privados encapsulados
 Conocer los objetos relacionados
 Conocer las cosas que puede derivar o calcular
4. Introducción a los patrones de diseño

 Las responsabilidades se asignan a las clases de los objetos durante el

diseño de objetos.
 Ej. "una Venta" es responsable de la creación de una LineaDeVenta
(un hacer), o "una Venta" es responsable de conocer su total (un
conocer).
 Las responsabilidades relevantes relacionadas con "conocer"
normalmente se pueden inferir del modelo del dominio, debido a los
atributos y asociaciones que describe.
4. Introducción a los patrones de diseño

 Una responsabilidad no es lo mismo que un método, pero los métodos

se implementan para llevar acabo responsabilidades.
 Ej. la clase Venta podría definir uno o más métodos para conocer su
total; podría ser getTotal. Para realizar esa responsabilidad, la Venta
podría colaborar con otros objetos, ej. enviando el mensaje
getSubtotal a cada objeto LineaDeVenta solicitando su subtotal.
 4. Introducción a los patrones de
diseño: Responsabilidades y los
diagramas de interacción

A los objetos Venta se les ha otorgado la responsabilidad de crear Pagos, que se

invoca con el mensaje realizarPago() y se maneja con el correspondiente método
realizarPago. Además, la realización de esta responsabilidad requiere colaboración
para crear el objeto LineaDeVenta e invocar a su constructor.
4. Introducción a los patrones de diseño

Los desarrolladores orientados a objetos con experiencia acumulan un

repertorio tanto de principios generales como de soluciones basadas en
aplicar ciertos estilos que les guían en la creación de software. Estos
principios y estilos, si se codifican con un formato estructurado que
describa el problema y la solución, y se les da un nombre, podría
llamarse patrones.
4. Introducción a los patrones de diseño [13]

En la tecnología de objetos, un patrón es un par problema/solución con

un nombre que se puede aplicar en nuevos contextos, con consejos
acerca de cómo aplicarlo en nuevas situaciones y discusiones sobre sus
compromisos.
La noción formal de patrones nació con los patrones arquitectónicos (de
construcción) de Christofer Alexander[AIS77]. Los patrones de software
se originaron con Kent Beck, 80’s, quien llegó a ser consciente del trabajo
con los patrones de Alexander en arquitectura y entonces los desarrolló
junto con Ward Cunningham [BC87, Beck94]
4. Introducción a los patrones de diseño

Resumiendo:
 La asignación hábil de responsabilidades es extremadamente
importante en el diseño de objetos.
 La decisión acerca de la asignación de responsabilidades,
normalmente tiene lugar durante la creación de los diagramas de
interacción y con seguridad durante la programación.
 Los patrones codifican buenos consejos y principios relacionados con
frecuencia con la asignación de responsabilidades.
4. Introducción a los patrones de diseño: GRASP

¿Qué son los patrones GRASP?

Describen los principios fundamentales del diseño de objetos y la
asignación de responsabilidades, expresados como patrones.
El nombre de estos patrones sugieren la importancia de aprehender
(grasping en inglés) estos principios para diseñar con éxito el software
OO.
4. Introducción a los patrones de diseño: GRASP

Como aplicar los patrones GRASP [Larman , 2003]

 Patrón Experto en Información (o Experto) [pág 207]

 Patrón Creador [pág 211]
 Patrón Bajo acoplamiento [pág 214]
 Patrón Alta cohesión [pág 217]
 Patrón Controlador [pág 221]
4. Introducción a los patrones de diseño: GRASP

Notación del diagramas de clases en UML

Proceso de
Desarrollo de
Software:
Modelado del
diseño [16,17]
5. Modelado del diseño

Las actividades que se realizan en la etapa de Diseño son las siguientes [9,13]:

1. Definir los Casos de Uso Reales (se estudiaron en tema 2. requerimientos).

2. Definir Informes e Interfaz de Usuario.
3. Refinar la Arquitectura del Sistema.
4. Definir los Diagramas de Interacción.
5. Definir el Diagrama de Clases de Diseño. (en paralelo con los Diagramas de
Interacción)
6. Definir el Esquema de Base de Datos
5. Modelado del diseño: Diagrama de interacción

 UML incluye los diagramas de interacción para ilustrar el modo en el

que los objetos interaccionan por medio de mensajes en un caso de
uso particular.
 Para analizar el comportamiento de las clases de un sistema, el
diagrama de interacción describe como colaboran los objetos
 El diagrama de interacción es una generalización de dos tipos de
diagramas UML más especializados: Diagramas de colaboración y
Diagramas de secuencia.
5. Modelado del diseño: Diagrama de interacción

 Los diagramas de interacción son importantes, pero un problema en

proyectos de tecnología de objetos es que no se aprecia su valor.
 La creación de los diagramas de interacción requieren la aplicación de
los principios para la asignación de responsabilidades y el uso de los
principios y patrones de diseño.
 Se recomienda crear los diagramas de interacción por parejas para un
mejor aprendizaje.
5. Modelado del diseño:
Diagrama de
colaboración vs
Diagrama de secuencia
[13]
5. Modelado del diseño: Diagrama de colaboración vs Diagrama
de secuencia [13]
5. Modelado del diseño: Ejemplo diagrama de colaboración CU
realizar pago [13]
5. Modelado del diseño: Ejemplo diagrama de secuencia CU
realizar pago [13]
 5. Modelado del diseño: Notación general de los diagramas de
interacción [13]
Notación para mostrar una instancia de una clase en un diagrama de
interacción, se utiliza el símbolo gráfico para una clase, pero con el
nombre subrayado.
 Notación de los
diagramas de
colaboración
A lo largo del mismo
enlace pueden fluir
múltiples mensajes, y
mensajes en ambas
direcciones.

Mensaje a "this". Se puede enviar un mensaje

desde un objeto a él mismo.
Creación de instancias, en UML existe el convenio de utilizar para este fin
el mensaje create., en otro caso se puede añadir al mensaje el
estereotipo «create».
Notación,
diagrama de
colaboración,
secuencia de
numeración
compleja.
No se numera
el primer
mensaje.
Notación básica de los diagramas de secuencia (DS) [13]

Los DS no muestran
enlaces. Los mensajes
entre objetos se
representan con una
expresión de mensaje
sobre una línea con
punta de flecha.
El orden en el tiempo
se organiza de arriba
abajo.
Notación básica de los diagramas de secuencia (DS)

 Focos de control y
cajas de activación

 Representación de
retornos (opcional),
mediante una línea
punteada con la punta
de flecha abierta, al
final de una caja de
activación
Notación básica de los diagramas de secuencia (DS)

Mensajes a "self" o "this"

Se puede enviar un mensaje

desde un objeto a él mismo,
utilizando una caja de activación
anidada.
Creación de
instancias y
línea de vida
de los objetos
con la línea
punteada [13]
Destrucción de objetos
Mensajes condicionales
La clausula condicional se coloca entre corchetes. El mensaje sólo se
envía si la evaluación de la cláusula es verdadera.
Mensajes condicionales mutuamente exclusivos [13]
La notación es un tipo de línea de mensaje con forma de ángulo que nace
de un mismo punto
Iteración para un único mensaje
Iteración de una serie de mensajes
Iteración sobre un multiobjeto
Un algoritmo típico es iterar sobre todo los miembros de una
colección (como una lista o una tabla), enviando un mensaje a cada
uno de ellos
Mensajes de objetos a una Clase
Las llamadas a los métodos de clase o estáticos, no se subraya el
nombre de la clase.
5. Modelado del diseño: Arquitectura de software

Arquitectura de capas inicial

 En este paso se trata de determinar los paquetes o capas más
generales en que podría dividirse al sistema y las relaciones existentes
entre estos. Se supone que este sea un primer acercamiento al control
de la arquitectura.
 Los paquetes, capas y dependencias serán refinados posteriormente
en el diseño de la arquitectura.
 Aunque existen varios modelos para la organización de las
aplicaciones, el más popular está basado en capas.
5. Modelado del diseño: Arquitectura de software [17]

 Un sistema bien diseñado puede agruparse en paquetes. Cada

paquete realiza una acción, o un conjunto de acciones bien definido.
Los paquetes pueden ubicarse en deferentes capas del sistema,
creando así aplicaciones multicapa.
 El diagrama de paquetes muestra el diseño de capas de la aplicación y
las relaciones entre las diferentes capas y paquetes.
Referencias
1. Fowler, Martin & Scott, Kendall. UML gota a gota. Pearson Education.
1999.
2. Fernández y Fernández Carlos A. Desarrollo de Software Orientado a
Objetos. Universidad Tecnológica de la Mixteca.
3. Fowler Martin. UML distilled: A brief guide to the standard object
modeling language. 2003, 3rd edition. Addison-Wesly
4. Jacobson, Ivar., Booch, Grady., Rumbaugh, James. The unified modeling
language user guide. 2005, Addison Wesley
5. Rumbaugh, James., Jacobson, Ivar., Booch, Grady. The unified modeling
language reference manual. 2004, Addison-Wesley Professional
6. Jacobson, Ivar., Booch, Grady., Rumbaugh, James. The Unified Software
Development Process. 1999. Addison-Wesley Professional.
7. Oestereich, Bernd. Developing Software with UML: Object-Oriented
Analysis and Design in Practice. 2002, 2nd Edition, Addison-Wesley
Professional
Referencias
8. Booch, Grady. Object-oriented analysis and design with applications. 1994, 2a
edition, Addison-Wesley
9. Ferré Grau Xavier, Sánchez Segura María I. Desarrollo de Software Orientado a
Objetos con UML. Universidad Politécnica de Madrid.
10. OpenUP https://www.utm.mx/~caff/doc/OpenUPWeb/index.htm
11. Kendal Simon Object Oriented Programming Using Java.
12. Dugarte, P. G. Modelado y simulación de un proceso de desarrollo de Software
dirigido por el método de craig larman: una Aplicación de la dinámica de sistemas.
2015. Trabajo de fin de master. Universidad Carlos III de Madrid
13. Larman Craig. UML y Patrones. Una introducción al análisis y diseño orientado a
objetos y al proceso unificado. Prentice-Hall. 2ª edicion 2003.
14. Letelier, Torres P. Desarrollo de software orientado a objetos usando UML.
Departamento de Sistemas Informáticos y Computación(DSIC) Universidad
Politécnica de Valencia. 2002.
Referencias

15. Rodriguez, Tello E. Curso Ingeniería de software. CINVESTAV-Tamaulipas. 2012

16. Larman Craig. UML y Patrones. Introducción al análisis y diseño orientado a
objetos. Prentice-Hall. 1ª edicion 1999.
17. Algunos temas sobre la ingeniería de software.
https://www.calaixagil.com/esp/articles/introenginyeria/
18. Hernández, Orallo E. El Lenguaje Unificado de Modelado (UML). Revista digital.
2002
19. Méndez, Pozo G. Aplicación del método de Larman a la construcción de entornos
virtuales. Tesis, Complutense University of Madrid, 2000.
20. Balduino, Ricardo. Basic Unified Process: A Process for Small and Agile Projects.
https://www.eclipse.org/proposals/beacon/Basic%20Unified%20Process.pdf
21. Kendall Scott, Fast Track UML 2.0, Apress 2004
22. Ortiz, Leticia. Casos a incluir y casos a extender.
https://www.abiztar.com.mx/articulos/casos-a-incluir-casos-a-extender.html