Departamento de Lenguajes y

Sistemas Informáticos

BLOQUE I: Arquitectura del Software

Diseño del Software

Tema 1

Arquitectura e Integración de Sistemas Software

Curso 2023/2024
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados y deuda técnica
▪ Resumen
▪ Bibliografía

2
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados y deuda técnica
▪ Resumen
▪ Bibliografía

3
Diseño del software
¿Qué es?

El diseño del software es un

proceso iterativo por medio del
cual se traducen los requisitos
en un “plano” para construir el
software.
R. Pressman

4
 Diseño del software
¿Qué es?

El Descripción
diseño de software
de los es lasubsistemas
actividad del ciclo de vida del software
y componentes de unen la
cual se analizan
sistema softwarelos requisitos para producir una
y de las interrelaciones descripción
entre ellos. de la
estructura del software que sirva de base para su construcción.

5
 Diseño del software
¿Por qué es importante?

Los “planos” (modelos) desarrollados como resultado del diseño:

▪ Proporcionan una visión general del sistema, más fácil de

entender que el código fuente, sobre la que poder discutir y tomar
decisiones.

▪ Permiten evaluar la calidad del software antes de que se

implemente, momento en el que es fácil y barato corregir errores.

▪ Sirven para guiar las siguientes fases del desarrollo.

6
 Diseño del software
¿Cuándo se realiza?

El diseño del software comienza una vez que se han capturado y

analizado los requisitos.

Análisis del problema Diseño arquitectura Diseño detallado

Producto

Cliente

Empleado

ListaEmpleados

7
 Diseño del software
¿Cuándo se realiza?

El diseño del software podrá evolucionar a lo largo del desarrollo y el

tiempo de vida de la aplicación. El diseño es una actividad iterativa.

8
 Diseño del software
¿Cuál es el producto final?

El resultado principal de la fase de diseño son modelos que

representan los principales elementos del software y sus posibles
interacciones.

9
 Diseño del software
¿Qué influye en el diseño?

“Un atributo de
Descripción decalidad es una propiedad
los subsistemas medible o testable
y componentes de unque es
usada
sistemapara indicar cómo
software de bien
y de las el sistema satisface
interrelaciones las necesidades
entre ellos.
de sus usuarios.”
Bass et al.

Requisitos no funcionales
Requisitos funcionales
(atributos de calidad)

10
 Diseño del software
¿Qué influye en el diseño?

Rendimiento Reusabilidad

ATRIBUTOS
Disponibilidad
DE CALIDAD Mantenibilidad

Interoperabilidad Seguridad
Otros
11
 Diseño del software
¿Qué influye en el diseño?
Rendimiento. Recursos computacionales empleados por el sistema
(tiempo, memoria, etc.).

Disponibilidad. Tiempo que un sistema está operativo.

Interoperabilidad. Habilidad del sistema para comunicarse e

intercambiar datos con sistemas externos.

Seguridad. Capacidad del sistema para proteger datos sensibles de

usos no autorizados.

Mantenibilidad. Facilidad con la que la que se pueden introducir cambios.

Reusabilidad. Facilidad con la que se pueden reutilizar partes del sistema.

12
 Diseño del software
¿Qué influye en el diseño?

Algunos atributos de calidad entran en conflicto

Mantenibilidad vs. Rendimiento

La modularidad y el uso de intermediarios minimiza el impacto de los cambios
pero hace que la comunicación entre los componentes sea más lenta (latencia).

Mantenibilidad Rendimiento

13
 Diseño del software
¿Qué influye en el diseño?

Algunos atributos de calidad entran en conflicto

Seguridad vs. Rendimiento

Aumentar la seguridad suele requerir mecanismos de control de
acceso y encriptación más lentos.

Seguridad Rendimiento

14
 Diseño del software
¿Quién lo hace?

▪ El ingeniero de software es el responsable de diseñar la aplicación a

partir de los requisitos.

▪ El programador construye el sistema a partir de los modelos de diseño.

15
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados y deuda técnica
▪ Resumen
▪ Bibliografía

16
 Principios de diseño
Nociones clave a tener en cuenta para el
diseño efectivo de sistemas software.

17
 Principios de diseño
Abstracción

Abstracción: Omitir detalles no relevantes.

Alto nivel de abstracción Bajo nivel de abstracción

18
 Principios de diseño
Abstracción (Ejemplos)
Programación Orientada a Objetos: los objetos o conceptos del mundo real
como clases, que son planos para crear instancias conocidas como objetos. Las
clases definen las propiedades (atributos) y el comportamiento (métodos) de
los objetos, encapsulando la complejidad y los detalles de los datos y
operaciones que representan.

Aplicación de simulación de tráfico

Coches Clase: COCHE

velocidad
color
marca
posición
acelerar(…)
frenar(…)
girar(…)

19
 Principios de diseño
Abstracción (Ejemplos)
Application Programming Interfaces (APIs): definen un conjunto de reglas y
protocolos que permiten que diferentes aplicaciones de software se
comuniquen entre sí. Proporcionan una interfaz simplificada que oculta la
complejidad de los sistemas subyacentes.
API de Google Maps

20
 Principios de diseño
Abstracción

Durante el diseño se recomienda comenzar con un alto grado de

abstracción y refinar sucesivamente hasta el diseño detallado.

21
 Principios de diseño
Modularidad

Modularidad: Dividir el software en partes o módulos de manera

que sea fácil de entender y mantener.

Descomposición: Dividir los problemas en problemas

más pequeños (divide y vencerás).

22
Principios de diseño
Modularidad (Ejemplos)

23
 Principios de diseño
Separación de responsabilidades

Separación de responsabilidades: Cada elemento del sistema debe

tener una única responsabilidad. Cada módulo debería ser
funcionalmente independiente y ofrecer una interfaz sencilla para
que pueda ser invocado desde otras partes del sistema.

La independencia funcional se
logra desarrollando módulos
“miopes” que tengan “aversión” a
la interacción excesiva con otros
módulos.
R. Pressman

24
 Principios de diseño
Separación de responsabilidades (Ejemplo)

25
 Principios de diseño
Ocultamiento de la información

Ocultamiento de la información: Diseñar módulos de forma que

la información (algoritmos y datos) contenida en un módulo sea
inaccesible para los que no necesiten de ella.

Los módulos deberían intercambiar sólo aquella información

necesaria para lograr la función del software.

Objetivo: Evitar dependencias

innecesarias para facilitar el
mantenimiento del software.

26
 Principios de diseño
Ocultamiento de la información (Ejemplo)

Módulo

B a1,a2
métodoA(a1,a2)
b1 b1,b2

b2

c1
d1,d2,d3

D Output: d2

27
 Principios de diseño
Variaciones protegidas

Variaciones protegidas. Intentar proteger de los cambios al resto

del sistema.

Objetivo: Lograr que los cambios

involucren la menor cantidad de
código posible y estén lo más
acotados posible.

28
 Principios de diseño
Variaciones protegidas

Ejemplo: Uso de ficheros de configuración para cambiar aspectos

como la interfaz de usuario, idiomas, control de acceso, etc.

layout.css.devPixelsPerPx = 5

layout.css.devPixelsPerPx = 3

layout.css.devPixelsPerPx = -1

29
 Principios de diseño
Cohesión

Cohesión. Es un indicador cualitativo del grado en el que un

módulo se centra en hacer una sola cosa. La cohesión de un
diseño debe ser alta.

Un elemento es altamente cohesivo

si todos sus elementos trabajan
juntos para proporcionar algún
comportamiento bien delimitado.

Grady Booch

30
 Principios de diseño
Acoplamiento

Acoplamiento. Es un indicador cualitativo del grado en el que un

módulo está conectado con otros y el mundo exterior. El
acoplamiento debe ser bajo.

Nulo Bajo

Alto
31
 Principios de diseño
Cohesión

Los conceptos de dominio relacionados se representan con el mismo color

Baja cohesión Alta cohesión Alta cohesión

Alto acoplamiento Alto acoplamiento Bajo acoplamiento

https://blog.ttulka.com/how-cohesion-and-coupling-correlate/ 32
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados y deuda técnica
▪ Resumen
▪ Bibliografía

33
 Patrones de diseño

UnDescripción
patrón es una solución
de los general para
subsistemas un problema de
y componentes de diseño
un
recurrente
sistema que expresa
software unalas
y de relación entre un contexto,
interrelaciones un problema y
entre ellos.
una solución.

Un patrón no es una solución completa sino una guía/esqueleto que

debe ser adaptado para cada problema específico.

Idea intuitiva: “Cuando encuentres este problema, aplica esta

solución”.

Problema Solución
34
 Patrones de diseño

La solución está determinada por el problema y el contexto.

Contexto: Casa de dos plantas.

Problema: Desplazarse entre las plantas de un edificio.
Solución: Construir unas escaleras.

Contexto: Edificio de 50 plantas.

Problema: Desplazarse entre las plantas de un edificio.
Solución: Instalar un ascensor.

35
 Patrones de diseño

La descripción del problema suele incluir las fuerzas que se

deberían tener en cuenta para dar una solución:

▪ Requisitos.
– Se debe poder ir de la planta baja a la planta más alta en menos de
60 segundos.
– La solución debe ser válida para personas con movilidad reducida.

▪ Restricciones.
– El sistema empleado no puede consumir energía.

▪ Propiedades deseadas.
– El sistema debería ser fácil de reemplazar.
– El sistema debería ser fácil de mantener.

36
 Patrones de diseño

Existen distintos tipos de patrones software, entre otros:

▪ Patrones orientados a objetos (o de diseño).

▪ Ej. ¿Cómo desacoplar mi programa del SGBD?

▪ Patrones arquitectónicos.
▪ Ej. ¿Cómo podemos ejecutar tareas de procesamiento complejas
sobre datos manteniendo la independencia y la flexibilidad?

▪ Patrones de integración.
▪ Ej. ¿Cómo podemos conectar una aplicación cerrada a un sistema
de mensajería de manera que pueda enviar y recibir mensajes?

37
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados y deuda técnica
▪ Resumen
▪ Bibliografía

38
Artefactos reutilizables

Un buen ingeniero no
reinventa la rueda

39
 Artefactos reutilizables
Servicios web

El W3CDescripción
define servicio
de web como un sistema
los subsistemas software diseñado
y componentes de un para dar
soportesistema
a la interacción
softwareinteroperable máquina-a-máquina
y de las interrelaciones entrea ellos.
través de una red.

Permiten intercambiar información entre

aplicaciones software desarrolladas en
lenguajes de programación diferentes y
ejecutadas sobre distintas plataformas.

Son la base para la integración web.

Podemos usar los servicios web no solo para transmitir datos, también para
hacer uso de la funcionalidad implementada por otros sistemas.
40
 Artefactos reutilizables
Servicios web

El W3CDescripción
define servicio
de web como un sistema
los subsistemas software diseñado
y componentes de un para dar
soportesistema
a la interacción
softwareinteroperable máquina-a-máquina
y de las interrelaciones entrea ellos.
través de una red.

Ventajas:
▪ Facilita la interoperabilidad entre
sistemas diversos.
▪ Uso de protocolos abiertos.

Inconvenientes:
▪ Rendimiento.

41
 Artefactos reutilizables
Librerías

Una librería proporciona

Descripción de los código reutilizable
subsistemas que puede ser de
y componentes empleado
un
porsistema
los desarrolladores
software ydedeaplicaciones.
las interrelaciones entre ellos.
Ejemplos: Librería de funciones matemáticas Math.lib para C, o la librería Guava
de Google para Java

sin
floor
log
sqrt C
…
>_

▪ Pueden incorporarse al programa en tiempo de compilación (ej. lib,jar) o en

tiempo de ejecución (ej. DLLs).
▪ El desarrollo de librerías puede ser una buena idea para facilitar el uso de nuestras
aplicaciones por parte de terceros. Ej. Amazon SDK para Java. 42
 Artefactos reutilizables
Frameworks

UnDescripción
framework esdeunlosconjunto integradoy de
subsistemas artefactos software
componentes de un(tales
como clases
sistema y ficheros
software de interrelaciones
y de las configuración) que
entreimplementan
ellos. una
arquitectura reutilizable para el desarrollo de aplicaciones relacionadas.

Les falta la funcionalidad que es propia de la

aplicación, pero implementan la funcionalidad
común como la seguridad, componentes de
interfaz de usuario, etc.

Los frameworks suelen implementar distintos patrones y estilos

arquitectónicos. El uso de frameworks va a determinar en gran medida la
arquitectura del sistema.

43
 Artefactos reutilizables
Frameworks

Un framework es
Descripción de unlosconjunto integrado
subsistemas y de artefactos software
componentes de un(tales
como clases
sistema y ficheros
software de interrelaciones
y de las configuración) que
entreimplementan
ellos. una
arquitectura reutilizable para el desarrollo de aplicaciones relacionadas.

44
 Artefactos reutilizables
Librerías vs. frameworks

Librería Framework

Código de nuestra
aplicación

45
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados y deuda técnica
▪ Resumen
▪ Bibliografía

46
 Sistemas heredados

Un sistema heredado
Descripción (legacy systemy en
de los subsistemas inglés) es undeprograma
componentes un
software
sistemaque ha quedado
software y de anticuado, pero que es
las interrelaciones crítico
entre para el negocio
ellos.
y debe seguir siendo usado y mantenido.

47
 Sistemas heredados

▪ A menudo desarrollados con lenguajes de programación obsoletos,

para los que resulta difícil encontrar a programadores con
experiencia.

▪ Los sucesivos cambios suelen hacer que la documentación quede

anticuada. En algunos casos, la única documentación existente es el
código fuente del sistema.

▪ Son sistemas difíciles de entender y por lo tanto difíciles de

mejorar, extender y reemplazar.

▪ Suelen ser sistemas cerrados, no diseñados para ser integrados con

otros sistemas.

48
¿Qué debemos hacer para evitar que nuestras
aplicaciones se conviertan en
sistemas heredados?

¿Qué es la gestión de la configuración?

49
 Deuda Técnica

“La deuda técnica es la deuda que se acumula cuando los desarrolladores,

consciente o inconscientemente, toman decisiones de diseño erróneas o
no óptimas”1

▪ “Costo implícito del retrabajo adicional causado

por elegir una solución fácil en lugar de utilizar un
enfoque que llevaría más tiempo en su desarrollo e
implementación”

▪ “Resta valor al producto software y que no se ve…”

▪ “El sobre esfuerzo a pagar para mantener un

producto software mal hecho, y lo que conlleva,
como el coste de la mala imagen frente a los
clientes, etc.”

[1] Refactoring for Software Design Smells, Managing Technical Debt. 2015, Pages 1-7 50
 Deuda Técnica
¿Razones por las que se genera la deuda técnica?

Componentes
Presión en fechas y Definición inicial
estrechamente acoplados
planes insuficiente

Falta de pruebas de Falta de Cambios de especificación

software conocimiento de última hora

51
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados y deuda técnica
▪ Resumen
▪ Bibliografía

52
 Resumen
¿Qué hemos aprendido?
▪ El diseño del software…
▪ describe la estructura del software y guía su construcción.
▪ es una etapa estándar en cualquier metodología de desarrollo.
▪ comienza una vez que se han analizado los requisitos. Es un proceso
iterativo.
▪ se realiza a partir de los requisitos funcionales y, sobre todo, los no
funcionales (atributos de calidad).
▪ es realizado por arquitectos del software.
▪ produce como principal resultado una serie de modelos.
▪ Principios de diseño: abstracción, cohesión, acoplamiento, etc.
▪ Patrones de diseño. Definición y tipos.
▪ Artefactos reutilizables: servicios web, librerías y frameworks.
▪ Sistemas heredados y deuda técnica.
53
 Índice

▪ Diseño del software

▪ Principios de diseño
▪ Patrones de diseño
▪ Artefactos reutilizables
▪ Sistemas heredados
▪ Resumen
▪ Bibliografía

54
 Bibliografía

Pressman R.S. Ingeniería del software: Un enfoque

práctico. McGraw-Hill. 7ª edición. 2009. (Capítulos 8
y 12)

Sommerville I. Ingeniería de Software. Pearson. 9ª

edición. 2011. (Capítulos 6, 7 y 16)

Bass L., Clemments P, Kazman R. Software

Architecture in Practice. Addison-Wesley
Professional. 3rd edition. 2003 (Chapters 1 and 2)

55
 Bibliografía

Buschmann F. et al .Pattern-Oriented Software

Architecture. John Wiley & Sons. 1996 (Capítulo 2)

Douglas C Schmidt, Aniruddha Gokhale, and

Balachandran Natarajan. 2004. Leveraging
Application Frameworks. Queue 2, 5 (July 2004), 66-
75. http://dx.doi.org/10.1145/1016998.1017005

56
 Enlaces

▪ Legacy systems (sistemas heredados)

• https://en.wikipedia.org/wiki/Legacy_system

▪ Deuda técnica
• Refactoring for Software Design Smells, Managing
Technical Debt. 2015, Pages 1-7
• https://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica

57
 Disclaimer and Terms of Use

All material displayed on this presentation is for teaching and personal use only.

Many of the images that have been used in the presentation are Royalty Free
images taken from http://www.everystockphoto.com/. Other images have been
sourced directly from the Public domain, from where in most cases it is unclear
whether copyright has been explicitly claimed. Our intention is not to infringe
any artist’s copyright, whether written or visual. We do not claim ownership of
any image that has been freely obtained from the public domain. In the event
that we have freely obtained an image or quotation that has been placed in the
public domain and in doing so have inadvertently used a copyrighted image
without the copyright holder’s express permission we ask that the copyright
holder writes to us directly, upon which we will contact the copyright holder to
request full written permission to use the quote or images.