Diseño de Software

Felipe Aliaga Cavero

Manual – Unidad 1
 Índice
Introducción ............................................................................................................................................. 3
Organización de la Asignatura ........................................................................................................... 4
Unidades didácticas .......................................................................................................................... 4
Tiempo mínimo de estudio ............................................................................................................... 4
UNIDAD 1: Diseño de la arquitectura de software ........................................................................ 5
Diagrama de organización .............................................................................................................. 5
Tema n.° 1: Fundamentos del diseño de la arquitectura de software ................................ 6
1.1. Conceptos Generales ..................................................................................................... 6
1.2. Cohesión y Acoplamiento .............................................................................................. 7
Tema n.° 2: Patrones y tipos de diseño de la arquitectura de software ........................... 10
2.1. Arquitectura de Software ............................................................................................. 10
2.2. Vistas Arquitectónicas .................................................................................................... 10
2.3. Patrones Arquitectónicos o Arquitecturas ............................................................... 11
De la teoría a la práctica ............................................................................................................... 14
Glosario de la Unidad 1 ....................................................................................................................... 16
Bibliografía de la Unidad 1 ................................................................................................................. 17

2 Manual
 Introducción
El diseño de software es una disciplina de la ingeniería de software, que se
enfoca desde la teoría y la práctica. Todo software debe ser analizado y
diseñado. Las metodologías de desarrollo de software tradicionales incorporan
el diseño como una etapa formal en su proceso de desarrollo. En las
metodologías ágiles, el diseño se desarrolla dentro de las iteraciones o sprints,
donde el desarrollador multidisciplinario ejecuta el análisis, diseño o
programación de acorde a sus necesidades o criterios.

La primera parte fundamental del diseño de software, lo constituyen las

arquitecturas; proceso donde se estructura el software a ser construido o
implementado, desde diferentes vistas o ángulos, de modo que permite diseñar
los diversos aspectos de composición, funcionalidad, y operatividad del
software. El diseño de arquitecturas es relevante y define la base sobre la cual
se erige un software firme, dando facilidad y confiabilidad a las posteriores
etapas del desarrollo.

El autor

Universidad Continental | Manual 3

 Organización de la Asignatura
Resultado de aprendizaje de la asignatura
Al finalizar la asignatura, el estudiante será capaz de elaborar el diseño de
software según los requerimientos identificados en el análisis y la ingeniería
de requerimientos.

Unidades didácticas
UNIDAD 1 UNIDAD 2 UNIDAD 3 UNIDAD 4
Diseño de la Diseño de la Diseño de Datos Diseño y
arquitectura de interfaz de usuario Evaluación de
software Componentes

Resultado de Resultado de Resultado de Resultado de

aprendizaje aprendizaje aprendizaje aprendizaje
Al finalizar la Al finalizar la Al finalizar la Al finalizar la
unidad, el unidad, el unidad, el unidad, el
estudiante será estudiante será estudiante será estudiante será
capaz de diseñar capaz de diseñar capaz de diseñar capaz de
arquitecturas de las interfaces de los modelos de transformar los
software, a partir interacción datos, a partir de elementos
de los requisitos del humano- las arquitecturas e estructurales del
software y computadora, que interfaces, que se diseño de
produciendo una servirá para su utilizará como software, en una
descripción de la ulterior plataforma del descripción de sus
estructura interna implementación software. componentes
del software, por los evaluando su
programadores del respectiva calidad.
que servirá como
software.
la base para su
posterior
construcción.

Tiempo mínimo de estudio

UNIDAD 1 UNIDAD 2 UNIDAD 3 UNIDAD 4

24 horas 24 horas 24 horas 24 horas

4 Manual
 UNIDAD 1: Diseño de la arquitectura de
software
Diagrama de organización

Diseño de la
arquitectura de
software

Fundamentos del Patrones y tipos de

diseño de la diseño de la
arquitectura de arquitectura de
software software

Universidad Continental | Manual 5

 Tema n.° 1: Fundamentos del diseño de la arquitectura de software

El diseño de software es la segunda etapa en el desarrollo de un software en

general. Independientemente de la metodología de desarrollo que se utilice,
pudiendo ser tradicional o ágil el diseño de software estará presente ya sea
como una etapa tradicional o como parte de las iteraciones ágiles.

El diseño es lo que casi todo ingeniero quiere hacer. Es el lugar en el que las
reglas de la creatividad — los requerimientos de los participantes, las
necesidades del negocio y las consideraciones técnicas — se unen para
formular un producto o sistema. El diseño crea una representación o modelo del
software, pero, a diferencia del modelo de los requerimientos (que se centra en
describir los datos que se necesitan, la función y el comportamiento), el modelo
de diserto proporciona detalles sobre arquitectura del software, estructuras de
datos, interfaces y componentes que se necesitan para implementar el sistema.
(Pressman, 2010, p.183)

El diseño de software es el proceso para definir la arquitectura, los componentes,

las interfaces, y otras características de un software o un componente. Visto
como proceso, el diseño del software es la actividad del ciclo de vida de la
cual, los requisitos del software se analizan para producir una descripción de la
estructura interna del software que servirá como la base para su construcción.
(Sánchez et al., 2012, p.175)

Pressman (2010), señala que el trabajo principal que se produce durante el

diseño del software es un modelo de diseño que agrupa las representaciones
arquitectónicas, interfaces en el nivel de componente y despliegue. El modelo
de diseño es evaluado por el equipo de software en un esfuerzo por determinar
si contiene errores, inconsistencias u omisiones, si existen mejores alternativas y si
es posible implementar el modelo dentro de las restricciones, plazo y costo que
se hayan establecido. (p.183)

Más exacto, el diseño del software (el resultado) debe describir: la arquitectura
del software, la descomposición del software, la organización de los
componentes, y las interfaces entre los mismos componentes. Debe también
describir los componentes en un nivel de detalle que permita su construcción. El
diseño del software desempeña un papel importante en el desarrollo de
software: permite que la Ingeniería del software produzca los diversos modelos
para la solución que se pondrá en desarrollo. Podemos analizar y evaluar estos
modelos para determinar si o no permitirán que se satisfaga los requisitos.
(Issuu.com, 2015)

1.1. Conceptos Generales

Módulo. Es una porción de un software. De las varias tareas que debe

realizar un programa para cumplir con su función u objetivos, un módulo
realizará, comúnmente, una de dichas tareas (o varias, en algún caso).

Abstracción. Es un proceso mental que se aplica al seleccionar algunas

características y propiedades de un conjunto de cosas del mundo real,
excluyendo otras no pertinentes. En otras palabras, es una representación

6 Manual
 mental de la realidad. (Pressman, 2010)

Figura 1: Descomposición modular. Fuente: Elaboración propia.

Patrón. Un patrón de diseño describe una estructura de diseño que

resuelve un problema particular del diseño dentro de un contexto
específico. El patrón es “común” y el problema también suele ser
“común”. (Pressman, 2010)

División de Problemas. Sugiere que cualquier problema complejo puede

manejarse con más facilidad si se subdivide en elementos susceptibles de
resolverse u optimizarse de manera independiente. Al separar un
problema en sus piezas más pequeñas y por ello más manejables, se
requiere menos esfuerzo y tiempo para resolverlo. (Pressman, 2010)

Modularidad. Es la manifestación más común de la división de problemas.

El software se divide en componentes con nombres distintos y abordables
por separado, en ocasiones llamados módulos, que se integran para
satisfacer los requerimientos del problema. (Pressman, 2010)

Ocultamiento de Información. El ocultamiento implica que la

modularidad efectiva se logra definiendo un conjunto de módulos
independientes que intercambien sólo aquella información necesaria
para lograr la función del software. (Pressman, 2010)

1.2. Cohesión y Acoplamiento

Cohesión. Medida de la fuerza funcional relativa de un módulo.

(Pressman, 2010)

Acoplamiento. Medida de interdependencia entre módulos. (Pressman,

2010)

Relación entre Cohesión y Acoplamiento. Un bajo acoplamiento y una

alta cohesión es señal de un sistema bien estructurado y de un buen
diseño de software. (Pressman, 2010).

Diagramas de componentes. Describen los elementos físicos del sistema

Universidad Continental | Manual 7

 y sus relaciones. Muestran las opciones de realización incluyendo código
fuente, binario y ejecutable. Los componentes representan todos los tipos
de elementos software que entran en la fabricación de aplicaciones
informáticas. Pueden ser simples archivos, paquetes, bibliotecas
cargadas dinámicamente, etc. (Diagramas de UML, 2017).

Figura 2: Bajo acoplamiento y alta cohesión.

Fuente: Elaboración propia.

Figura 3: Alto acoplamiento y baja cohesión.

Fuente: Elaboración propia.

Figura 4. Dependencia entre paquetes. Tomado de Diagramas de UML:

Ilustración de Paquetes, por Diagramas de UML, 2017.

Diagramas de Distribución. Muestran la disposición física de los distintos

nodos que componen un sistema y el reparto de los componentes sobre
dichos nodos. Un nodo es un elemento físico que existe en tiempo de
ejecución y representa un recurso computacional, que generalmente
tiene algo de memoria y, a menudo, capacidad de procesamiento. Los
nodos se utilizan para modelar la topología del hardware sobre el que se
ejecuta el sistema. Representa típicamente un procesador o un
dispositivo sobre el que se pueden desplegar los componentes.
(Diagramas de UML, 2017)

8 Manual
 Figura 5. Dependencia entre nodos. Tomado de Diagramas de UML:
Ilustración de Despliegue, por Diagramas de UML, 2017.

Universidad Continental | Manual 9

 Tema n.° 2: Patrones y tipos de diseño de la arquitectura de software

El diseño arquitectónico representa la estructura de los datos y de los

componentes del programa que se requieren para construir un sistema basado
en computadora. Considera el estilo de arquitectura que adoptará el sistema,
la estructura y las propiedades de los componentes que lo constituyen y las
interrelaciones que ocurren entre sus componentes arquitectónicos. Aunque es
un ingeniero de software quien puede diseñar tanto los datos como la
arquitectura, es frecuente que, si deben construirse sistemas grandes y
complejos, el trabajo lo realicen especialistas. El diseñador de una base de
datos o data warehouse crea la arquitectura de los datos para un sistema. El
"arquitecto del sistema" selecciona un estilo arquitectónico apropiado a partir
de los requerimientos obtenidos durante el análisis de los datos. Ud. no intentaría
construir una casa sin un plano, ¿o sí? Tampoco comenzaría los planos con el
dibujo de la plomería del lugar. Antes de preocuparse por los detalles,
necesitaría tener el panorama general: la casa en sí. Eso es lo que hace el diseño
arquitectónico, da el panorama y asegura que sea el correcto. (Pressman, 2010,
p.206)

2.1. Arquitectura de Software

La arquitectura de un sistema software es la organización fundamental de dicho

sistema, plasmada en sus componentes, las relaciones entre estos y con el
entorno, y los principios que guían su diseño e implementación. (ISO/IEC
42010:2007)

Es imposible representar toda la información relevante sobre la arquitectura de

un sistema en un solo modelo arquitectónico, ya que cada uno presenta
únicamente una vista o perspectiva del sistema. Por lo general se necesita
presentar múltiples vistas de la arquitectura de un software, que permita su
entendimiento integral. (Sommerville, 2011)

2.2. Vistas Arquitectónicas

Sommerville (2011), propone las siguientes vistas:

1. Una vista lógica, que indique las abstracciones clave en el sistema como
objetos o clases de objeto. En este tipo de vista se tienen que relacionar
los requerimientos del sistema con entidades.

2. Una vista de proceso, que muestre cómo, en el tiempo de operación, el

sistema está compuesto de procesos en interacción. Esta vista es útil para
hacer juicios acerca de las características no funcionales del sistema,
como el rendimiento y la disponibilidad.

3. Una vista de desarrollo, que muestre cómo el software está

descompuesto para su desarrollo, esto es, indica la descomposición del
software en elementos que se implementen mediante un solo
desarrollador o equipo de desarrollo. Esta vista es útil para
administradores y programadores de software.

10 Manual
 4. Una vista física, que exponga el hardware del sistema y cómo los
componentes de software se distribuyen a través de los procesadores en
el sistema. Esta vista es útil para los ingenieros de sistemas que planean
una implementación de sistema.

2.3. Patrones Arquitectónicos o Arquitecturas

Un patrón arquitectónico se puede considerar como una descripción abstracta

estilizada de buena práctica, que se ensayó y puso a prueba en diferentes
sistemas y entornos. De este modo, un patrón arquitectónico debe describir una
organización de sistema que ha tenido éxito en sistemas previos. Debe incluir
información sobre cuándo es y cuándo no es adecuado usar dicho patrón, así
como sobre las fortalezas y debilidades del patrón. (Sommerville, 2011)

Sommerville (2011), define las siguientes arquitecturas:

1. Arquitectura en Capas. Organiza el sistema en capas con funcionalidad

relacionada con cada capa. Una capa da servicios a la capa de
encima, de modo que las capas de nivel inferior representan servicios
núcleo que es probable se utilicen a lo largo de todo el sistema.

Figura 6. Arquitectura en Capas.

Tomado de Software Engineering, por Sommerville, 2011.

2. Arquitectura de Repositorio. Todos los datos en un sistema se gestionan

en un repositorio central, accesible a todos los componentes del sistema.
Los componentes no interactúan directamente, sino tan sólo a través del
repositorio.

3. Arquitectura Cliente-Servidor. La funcionalidad del sistema se organiza en

servicios, y cada servicio lo entrega un servidor independiente. Los
clientes son usuarios de dichos servicios y para utilizarlos ingresan a los
servidores.

4. Arquitectura Tubería-Filtro. El procesamiento de datos en un sistema se

organiza de forma que cada componente de procesamiento (filtro) sea
discreto y realice un tipo de transformación de datos. Los datos fluyen

Universidad Continental | Manual 11

 (como en una tubería) de un componente a otro para su procesamiento.

Figura 7. Arquitectura en Capas.

Tomado de Software Engineering, por Sommerville, 2011.

Figura 8. Arquitectura Cliente-Servidor.

Tomado de Software Engineering, por Sommerville, 2011.

Figura 9. Arquitectura Tubería-Filtro.

Tomado de Software Engineering, por Sommerville, 2011.

12 Manual
 5. Arquitectura Llamar-Regresar. Este estilo arquitectónico permite obtener
una estructura de programa que es relativamente fácil de modificar y
escalar.

Figura 10. Arquitectura Llamar-Regresar.

Tomado de Software Engineering, por Sommerville, 2011.

Figura 11. Proceso de Diseño de la Arquitectura del Software.

Adaptado de Software Engineering, por Sommerville, 2011.

Universidad Continental | Manual 13

De la teoría a la práctica

¿Cómo diseñar las arquitecturas de software?

Paso 1: Responder las preguntas, que definan el entorno del software a ser
diseñado (De la Torre, Zorrilla, Ramos y Calvarro, 2010).

• ¿Qué tipo de aplicación se va a construir (Web, RIA, Rich Client…)?

• ¿Qué estructura lógica va a tener la aplicación (N-Capas,
Componentes…)?
• ¿Qué estructura física va a tener la aplicación (Cliente/Servidor, N-
Tier…)?
• ¿Qué riesgos hay que afrontar y cómo hacerlo (Seguridad, Rendimiento,
Flexibilidad…)?
• ¿Qué tecnologías vamos a usar (WCF, WF, WPF, Silverlight, Entity
Framework, etc.)?

Paso 2: Examinar los requerimientos funcionales. Tener en cuenta los

requerimientos de sistema, usuario y negocio. La arquitectura por diseñar
deberá dar soporte a todos los requerimientos involucrados.

Paso 3: Precisar qué requisitos no funcionales (o de calidad) debe que tener la

aplicación. Los requisitos no funcionales son propiedades de la solución y no
funcionalidad, pero influyen directamente en los puntos clave de la arquitectura
que sí son funcionalidad del sistema. Los requisitos no funcionales son la
especificación de las propiedades del sistema y los puntos clave de la
implementación (De la Torre, Zorrilla, Ramos y Calvarro, 2010).

Paso 4: Realizar un Esquema de la Aplicación (De la Torre, Zorrilla, Ramos y

Calvarro, 2010).

• Aplicaciones para dispositivos móviles: Se trata de aplicaciones web con

una interfaz adaptada para dispositivos móviles o aplicaciones de usuario
desarrolladas para el terminal.
• Aplicaciones de escritorio: Son las aplicaciones clásicas que se instalan
en el equipo del usuario que la vaya a utilizar.
• RIA (Rich Internet Applications): Se trata de aplicaciones que se ejecutan
dentro del navegador gracias a un plug-in y que ofrecen una mejor
respuesta que las aplicaciones web y una interfaz de calidad similar a las
aplicaciones de usuario con la ventaja de que no hay que instalarlas.
• Servicios: Se trata de aplicaciones que exponen una funcionalidad
determinada en forma de servicios web para que otras aplicaciones los
consuman.
• Aplicaciones web: Son aplicaciones que se consumen mediante un
navegador y que ofrecen una interfaz de usuario estándar y
completamente interoperable.

Paso 5: Crear Arquitecturas Candidatas. Una vez realizados los pasos anteriores,
se tendrá una arquitectura candidata que podremos evaluar. Cualquier
arquitectura candidata debería responder a las siguientes preguntas (De la
Torre, Zorrilla, Ramos y Calvarro, 2010):

14 Manual
 • ¿Qué funcionalidad implementa?
• ¿Qué riesgos mitiga?
• ¿Cumple las restricciones impuestas por el cliente?
• ¿Qué cuestiones deja en el aire?

Universidad Continental | Manual 15

 Glosario de la Unidad 1
A
Arquitectura. Representación de los componentes de un software y la
interacción entre ellos.

C
Cliente. Software que consume servicios en una arquitectura Cliente-Servidor.

Componente. Es un módulo de un software. El término módulo se usa desde los

inicios del desarrollo de software; mientras que componente es un término
relativamente moderno.

D
Despliegue. Distribución del hardware y red de interconexión que dará soporte
al diseño de un software.

Diseño. Actividad que consiste en idear y proyectar cómo serán los

componentes de un software, y cómo se integrarán a la arquitectura de dicho
software.

M
Módulo. Parte o porción lógica de un software. Puede ser una parte del código
fuente, una pantalla GUI, una página web, una tabla de base de datos, un
archivo de texto, una librería, entre otros.

P
Patrón. Estructura que conforma parte de un software, que ha sido diseñada y
probada por autores especialistas o expertos.

S
Servidor. Software que otorga servicios a los softwares clientes, como por
ejemplo servicio de páginas web, servicios de base de datos, etc.

16 Manual
 Bibliografía de la Unidad 1
De la Torre, C., Zorrilla, U., Ramos, M. A. y Calvarro, J. (2010). Guía de Arquitectura
N-Capas orientada al Dominio con .NET 4.0. España: Microsoft Ibérica Krasis
PRESS
Diagramas de UML (2017). Ilustración de despliegue. [Figura]. Recuperado de
https://diagramasuml.com/despliegue/
Diagramas de UML (2017). Ilustración de paquetes [Figura]. Recuperado de
https://diagramasuml.com/paquetes/
Diagramas de UML. (2017). Diagramas de UML [Página Web]. Recuperado de
https://diagramasuml.com/#estructurales
Issuu.com (2015). Ingeniería de software es la aplicación de un enfoque
sistemático [Página Web]. Recuperado de
https://issuu.com/kelvin91/docs
Pressman, R. (2010). Ingeniería del software. Un enfoque práctico. 7 ª ed. México:
McGraw-Hill.
Sánchez, S., Sicilia, M., Rodríguez, D. (2012). Ingeniería del Software, un enfoque
desde la guía SWEBOK. México: Alfaomega
Sommerville, L. (2011). Software Engineering. 9ª ed. New York, Estados Unidos:
Pearson Education

Universidad Continental | Manual 17

18 Manual