Diseño de Software

Felipe Aliaga Cavero

Manual – Unidad 1
2 Manual
 Índice
Introducción .........................................................................................................................................5
Organización de la Asignatura ........................................................................................................7
Unidades didácticas.......................................................................................................................7
Tiempo mínimo de estudio ............................................................................................................8
UNIDAD 1: DISEÑO DE LA ARQUITECTURA DE SOFTWARE ........................................................... 9
Diagrama de organización ..........................................................................................................9
Tema N.º 1: Fundamentos del diseño de la arquitectura de software ............................. 10
1.1. Conceptos generales ................................................................................................. 11
1.2. Cohesión y acoplamiento ......................................................................................... 13
Tema N.º 2: Patrones y tipos de diseño de la arquitectura de software .......................... 16
2.1. Arquitectura de software ........................................................................................... 16
2.2. Visitas arquitectónicas ................................................................................................ 17
2.3. Patrones arquitectónicos o arquitecturas .............................................................. 18
De la teoría a la práctica ............................................................................................................ 22
Glosario de la Unidad 1 ................................................................................................................... 24
Bibliografía de la Unidad 1 .............................................................................................................. 25

3
4 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

5
6 Manual
 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.

7
 Tiempo mínimo de estudio

UNIDAD 1 UNIDAD 2 UNIDAD 3 UNIDAD 4

24 horas 24 horas 24 horas 24 horas

8 Manual
UNIDAD 1: DISEÑO DE LA ARQUITECTURA DE

SOFTWARE

Diagrama de organización

9
 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

10 Manual
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

mental de la realidad. (Pressman, 2010)

11
 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

efectivo 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)

12 Manual
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 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.

13
 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)

14 Manual
 Figura 5. Dependencia entre nodos. Tomado de Diagramas de UML: Ilustración

de Despliegue, por Diagramas de UML, 2017.

15
 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)

16 Manual
 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. Visitas 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.

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.

17
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.

18 Manual
 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 (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.

19
 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.

5. Arquitectura Llamar-Regresar. Este estilo arquitectónico permite

obtener una estructura de programa que es relativamente fácil

de modificar y escalar.

20 Manual
 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.

21
 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

22 Manual
 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):

 ¿Qué funcionalidad implementa?

 ¿Qué riesgos mitiga?

 ¿Cumple las restricciones impuestas por el cliente?

 ¿Qué cuestiones deja en el aire?

23
 Glosario de la Unidad 1

Arquitectura. Representación de los componentes de un software y la

interacción entre ellos.

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.

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ó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.

Patrón. Estructura que conforma parte de un software, que ha sido diseñada y

probada por autores especialistas o expertos.

Servidor. Software que otorga servicios a los softwares clientes, como por

ejemplo servicio de páginas web, servicios de base de datos, etc.

24 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

[Enlace]

Diagramas de UML (2017). Ilustración de paquetes [Figura]. Recuperado de

[Enlace]

Diagramas de UML. (2017). Diagramas de UML [Página Web]. Recuperado de

[Enlace]

Issuu.com (2015). Ingeniería de software es la aplicación de un enfoque

sistemático [Página Web]. Recuperado de [Enlace]

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

25
26 Manual