INGENIERÍA DE SOFTWARE

UNIVERSIDAD DE NARIÑO

DISEÑO DE SOFTWARE

COLOMBIA - PASTO – NARIÑO

8 DE MAYO DE 2020
DISEÑO DE SOFTWARE Pág. 2

INGENIERÍA DE SOFTWARE - GRUPO 1

UNIVERSIDAD DE NARIÑO

DISEÑO DE SOFTWARE

Presentado por:

JULIÁN ESTEBAN CAÑAR LITUMA

NAYELY ANDREA ERASO CALPA

Docente:

SANDRA VALLEJO

COLOMBIA - PASTO – NARIÑO

8 DE MAYO DE 2020
DISEÑO DE SOFTWARE Pág. 3

TABLA DE CONTENIDOS

1) Introducción
2) Diseño de software
2.1. Conceptos generales de diseño de software
2.2. Contexto de diseño de software
2.3. Proceso de diseño de software
2.4. Principios de diseño de software
3) Problemas clave en el diseño de software
3.1. Concurrencia
3.2. Control y manejo de eventos
3.3. Persistencia de datos
3.4. Distribución de componentes
3.5. Manejo de errores y excepciones y tolerancia a fallas
3.6. Interacción y presentación
3.7. Seguridad
4) Estructura y arquitectura de software
4.1. Estructuras arquitectónicas y miradores
4.2. Estilos arquitectónicos
4.3. Patrones de diseño
4.4. Decisiones de diseño de arquitectura
4.5. Familias de programas y marcos
5) Diseño de la interfaz de usuario
5.1. Principios generales de diseño de la interfaz de usuario
5.2. Problemas de diseño de la interfaz de usuario
5.3. El diseño de las modalidades de interacción del usuario
5.4. El diseño de la presentación de la información
5.5. Proceso de diseño de la interfaz de usuario
5.6. Localización e internacionalización
5.7. Metáforas y modelos conceptuales
6) Análisis y evaluación de la calidad del diseño de software
6.1. Atribuciones de calidad
6.2. Técnicas de análisis y evaluación de la calidad
6.3. Medidas
7) Notaciones de diseño de software
7.1. Descripciones estructurales (Vistas estáticas)
7.2. Descripciones de comportamiento (Vista Dinámica)
8) Estrategias y métodos de diseño de software
8.1. Estrategias generales
8.2. Diseño (estructurado) orientado a funciones
DISEÑO DE SOFTWARE Pág. 4

8.3. Diseño orientado a objetos

8.4. Diseño centrado en la estructura de datos
8.5. Diseño basado en Componentes
8.6. Otros métodos
9) Herramientas de diseño de software
10) Conclusiones
11) Recomendaciones
DISEÑO DE SOFTWARE Pág. 5

1. Introducción

El diseño se define como “el proceso de definir la arquitectura, los

componentes, las interfaces y otras características de un sistema o
componente” y como “el resultado de ese proceso”. Visto como un proceso, el
diseño de software es la actividad del ciclo de vida de la ingeniería de software
en la que se analizan los requisitos del software para producir una descripción
de la estructura interna del software que servirá como base para su
construcción. Un diseño de software describe la arquitectura del software, es
decir, cómo se descompone y organiza el software en componentes, y las
interfaces entre esos componentes.
También debe describir los componentes con un nivel de detalle que permita
su construcción

El diseño de software juega un papel importante en el desarrollo de software:

durante el diseño de software, los ingenieros de software producen varios
modelos
que forman una especie de plano de la solución a implementar. Podemos
analizar y evaluar estos modelos para determinar si nos permitirán cumplir con
los distintos requisitos. También podemos examinar y evaluar soluciones
alternativas y compensaciones. Finalmente, podemos utilizar los modelos
resultantes para planificar actividades de desarrollo posteriores, como la
verificación y validación del sistema, además de utilizarlos como entradas y
como punto de partida de la construcción y las pruebas.

Esta área de conocimiento de Diseño de Software está relacionada

específicamente con las áreas de conocimiento de Requisitos de Software,
Construcción de Software, Gestión de Ingeniería de Software, Modelos y
Métodos de Ingeniería de Software, Calidad de Software y Fundamentos de
Computación.

2. Fundamentos del diseño de software

Los conceptos, nociones y terminología presentados aquí forman una base

subyacente para comprender el papel y el alcance del diseño de software.

2.1. Conceptos generales de diseño

En un sentido general, el diseño puede verse como una forma de

resolución de problemas. Por ejemplo, el concepto de un problema
DISEÑO DE SOFTWARE Pág. 6

perverso, un problema sin solución definitiva, es interesante en términos

de comprender los límites del diseño. Varias otras nociones y conceptos
también son de interés para comprender el diseño en su sentido general:
objetivos, limitaciones, alternativas, representaciones y soluciones.

2.2. Contexto del diseño de software

El diseño de software es una parte importante del proceso de desarrollo

de software. Para entender el papel del diseño de software, debemos ver
cómo encaja en el ciclo de vida del desarrollo de software. Por lo tanto,
es importante comprender las principales características del análisis de
requisitos de software, el diseño de software, construcción de software,
pruebas de software y el mantenimiento de software.

2.3. Proceso de diseño de software

El diseño de software generalmente se considera un proceso de dos

pasos:
• El diseño arquitectónico (también conocido como diseño de alto nivel y
diseño de nivel superior) describe cómo se organiza el software en sus
componentes.
• Diseño detallado: describe el comportamiento deseado de estos
componentes.
El resultado de estos dos procesos es un conjunto de modelos y
artefactos que registran las principales decisiones que se han tomado,
junto con una explicación del fundamento de cada decisión no trivial.
Al registrar la justificación, se mejora la capacidad de mantenimiento a
largo plazo del producto de software.

2.4. Principios de diseño de software

Un principio es “una ley, doctrina o suposición integral y fundamental”.

Los principios de diseño de software son nociones clave que
proporcionan la base para muchos enfoques y conceptos de diseño de
software diferentes. Los principios del diseño de software incluyen la
abstracción; acoplamiento y cohesión; descomposición y modularización;
encapsulación/ocultación de información; separación de interfaz e
implementación; suficiencia, integridad y primitividad; y separación de
preocupaciones.
DISEÑO DE SOFTWARE Pág. 7

• La abstracción es “una vista de un objeto que se enfoca en la

información relevante para un propósito particular e ignora el resto de la
información”. En el contexto del diseño de software, dos mecanismos
clave de abstracción son la parametrización y la especificación. La
abstracción por parametrización se abstrae de los detalles de las
representaciones de datos al representar los datos como parámetros con
nombre. La abstracción por especificación conduce a tres tipos
principales de abstracción: abstracción procedimental, abstracción de
datos y abstracción de control.
• Acoplamiento y Cohesión. El acoplamiento se define como "una medida
de la interdependencia entre módulos en un programa de computadora",
mientras que la cohesión se define como "una medida de la fuerza de
asociación de los elementos dentro de un módulo".
• Descomposición y modularización. Descomponer y modularizar
significa que el software grande se divide en varios componentes con
nombre más pequeños que tienen interfaces bien definidas que
describen las interacciones de los componentes. Por lo general, el
objetivo es colocar diferentes funcionalidades y responsabilidades en
diferentes componentes.
• Encapsular y ocultar información significa agrupar y empaquetar los
detalles internos de una abstracción y hacer que esos detalles sean
inaccesibles para entidades externas.
• Separación de interfaz e implementación. Separar la interfaz y la
implementación implica definir un componente especificando una interfaz
pública (conocida por los clientes) que está separada de los detalles de
cómo se realiza el componente (ver encapsulación y
información escondida arriba).
• Suficiencia, integridad y primitividad. Lograr la suficiencia e integridad
significa asegurarse de que un componente de software capture todas
las características importantes de una abstracción y nada más.
Primitividad significa que el diseño debe basarse en patrones que sean
fáciles de implementar.
• Separación de intereses. Una preocupación es un área de interés con
respecto al diseño de un software”. Una preocupación de diseño es un
área de diseño que es relevante para una o más de sus partes
interesadas. Cada vista de la arquitectura enmarca una o más
preocupaciones. Separar las preocupaciones por puntos de vista permite
a las partes interesadas centrarse en unas pocas cosas a la vez y ofrece
un medio para gestionar la complejidad.
DISEÑO DE SOFTWARE Pág. 8

3. Problemas clave en el diseño de software

Se tiene que tomar en cuenta algunas cuestiones claves al momento de diseñar

software, preocupaciones que todo software debería cumplir, rendimiento,
seguridad confiabilidad, usabilidad, etc. Varias de estas cuestiones claves y
transversales serán discutidas en la siguiente sección:

3.1 Concurrencia

El diseño para la concurrencia se ocupa de descomponer el software en

procesos, tareas y subprocesos para después abordar los problemas
relacionados con la eficiencia, atomicidad, sincronización y programación.

3.2 Control y manejo de evento

Este problema de diseño tiene que ver con cómo organizar los datos y
controlar el flujo, así como para manejar eventos reactivos y temporales a
través de varios mecanismos como la invocación implícita y devoluciones de
datos.

3.3 Persistencia de Datos

Este problema de diseño tiene que ver con el manejo de datos de larga vida o
larga duración.

3.4 Distribución de Componentes

Este problema de diseño se refiere a cómo distribuir el software a través del

hardware (incluido el hardware de la computadora y el hardware de red).
Además de cómo se comunica el software con el hardware y cómo hacer para
que estos sean compatibles.

3.5 Manejo de errores y excepciones y fallas

Este problema de diseño tiene que ver con cómo prevenir, tolerar y procesar
errores y tratarlos con condiciones excepcionales.

3.6 Interacción y presentación

DISEÑO DE SOFTWARE Pág. 9

Este problema de diseño también se refiere a cómo estructurar y organizar las

interacciones con los usuarios. como la presentación de información. Esto no
toma en cuenta el tema de interfaz de usuario.

3.7 Seguridad

El diseño para la seguridad se preocupa por cómo prevenir la divulgación,

creación, cambio, supresión o denegación de acceso a la información y otros
recursos. También se ocupa de cómo tolerar ataques o violaciones
relacionados con la seguridad, limitar el daño, brindar servicio continuo,
reparación y recuperación veloz. Además de un uso adecuado de criptología.

4. Estructura y arquitectura del software

En sentido estricto, una arquitectura de software es “el conjunto de estructuras

necesarias para razonar sobre el sistema, que comprende elementos de
software, relaciones entre ellos y propiedades de ambos”. Sin embargo, a
mediados de la década de 1990, la arquitectura de software comenzó a surgir
como una disciplina más amplia que involucraba el estudio de estructuras y
arquitecturas de software de una manera más genérica. Esto dio lugar a una
serie de conceptos interesantes sobre el diseño de software en diferentes
niveles de abstracción. Algunos de estos conceptos pueden ser útiles durante
el diseño arquitectónico (por ejemplo, estilos arquitectónicos) así como durante
el diseño detallado (por ejemplo, patrones de diseño). Estos conceptos de
diseño también se pueden utilizar para diseñar familias de programas (también
conocidas como líneas de productos). Curiosamente, la mayoría de estos
conceptos pueden verse como intentos de describir y, por lo tanto, reutilizar el
conocimiento del diseño.

4.1. Estructuras arquitectónicas y miradores

Se pueden describir y documentar diferentes facetas de alto nivel de un

diseño de software. Estas facetas a menudo se denominan vistas: "Una
vista representa un aspecto parcial de una arquitectura de software que
muestra propiedades específicas de un sistema de software". Las vistas
pertenecen a distintos problemas asociados con el diseño de software,
por ejemplo, la vista lógica (que satisface los requisitos funcionales)
frente a la vista del proceso.
DISEÑO DE SOFTWARE Pág. 10

(problemas de concurrencia) frente a la vista física (problemas de

distribución) frente a la vista de desarrollo (cómo el diseño se divide en
unidades de implementación con representación explícita de las
dependencias entre las unidades). Varios autores utilizan diferentes
terminologías, como vistas de modelado de datos, funcionales,
funcionales, estructurales y de comportamiento. En resumen, un diseño
de software es un artefacto multifacético producido por el proceso de
diseño y generalmente compuesto por
Vistas relativamente independientes y ortogonales.

4.2. Estilos arquitectónicos

Un estilo arquitectónico es “una especialización de tipos de elementos y

relaciones, junto con un conjunto de restricciones sobre cómo pueden
usarse”. Por tanto, se puede considerar que un estilo arquitectónico
proporciona la organización de alto nivel del software. Varios autores han
identificado varios estilos arquitectónicos importantes:
• Estructuras generales (por ejemplo, capas, tuberías y filtros, pizarra)
• Sistemas distribuidos (por ejemplo, cliente-servidor, tres niveles,
corredor)
• Sistemas interactivos (por ejemplo, Controlador de vista de modelo,
Presentación-Abstracción-Control)
• Sistemas adaptables (por ejemplo, microkernel, reflexión)
• Otros (por ejemplo, lotes, intérpretes, control de procesos, basados en
reglas).

4.3. Patrones de diseño

Descrito sucintamente, un patrón es "una solución común a un problema

común en un contexto dado". Si bien los estilos arquitectónicos pueden
verse como patrones que describen la organización de alto nivel del
software, se pueden usar otros patrones de diseño para describir detalles
en un nivel inferior. Estos patrones de diseño de nivel inferior incluyen lo
siguiente:
• Patrones de creación (por ejemplo, constructor, fábrica, prototipo, único)
• Patrones estructurales (por ejemplo, adaptador, puente, compuesto,
decorador, fachada, peso mosco, proxy)
• Patrones de comportamiento (por ejemplo, comando, intérprete,
iterador, mediador, recuerdo, observador, estado, estrategia, plantilla,
visitante).
DISEÑO DE SOFTWARE Pág. 11

4.4. Decisiones de diseño de arquitectura

El diseño arquitectónico es un proceso creativo. Durante el proceso de

diseño, los diseñadores de software deben tomar una serie de decisiones
fundamentales que afectan profundamente el software y el proceso de
desarrollo. Es útil pensar en el proceso de diseño arquitectónico desde
una perspectiva de toma de decisiones más que desde una perspectiva
de actividad. A menudo, el impacto en los atributos de calidad y las
compensaciones entre los atributos de calidad en competencia son la
base para las decisiones de diseño.

4.5. Familias de programas y marcos

Un enfoque para permitir la reutilización de diseños y componentes de

software es diseñar familias de programas, también conocidas como
líneas de productos de software. Esto se puede hacer identificando los
puntos en común entre los miembros de dichas familias y diseñando
componentes reutilizables y personalizables para tener en cuenta la
variabilidad entre los miembros de la familia.

En la programación orientada a objetos (OO), una noción clave

relacionada es la de un marco: un sistema de software parcialmente
completado que puede ampliarse creando instancias adecuadas de
extensiones específicas (como complementos).

5. Diseño de la interfaz de usuario

El diseño de la interfaz de usuario es una parte esencial del proceso de diseño

de software. Este debe asegurar que la interacción entre el ser humano y la
máquina proporciona un funcionamiento eficaz hacia el control de la máquina.
Para que el software pueda alcanzar su máximo potencial, la interfaz de
usuario debe estar diseñado para que coincida con las habilidades, la
experiencia y las expectativas de sus usuarios anticipados.

5.1. Principios generales de diseño de la interfaz de usuario

• Capacidad de aprendizaje: El software debe ser fácil de aprender para

que el usuario pueda comenzar a trabajar rápidamente con él.
DISEÑO DE SOFTWARE Pág. 12

• Familiaridad del usuario: La interfaz debe usar términos y conceptos

extraídos de las experiencias de las personas que utilizarán el software.
• Coherencia: La interfaz debe ser coherente para que las operaciones
comparables se activen de la misma manera.
• Mínima sorpresa: El comportamiento del software no debe sorprender
a los usuarios.
• Recuperabilidad: La interfaz debe proporcionar mecanismos que
permiten a los usuarios recuperarse de errores.
• Orientación al usuario: La interfaz debe dar retroalimentación
significativa cuando ocurren errores y proporcionar ayuda relacionada
con el contexto a los usuarios.
• Diversidad de usuarios: La interfaz debe proporcionar mecanismos de
interacción adecuados. para diversos tipos de usuarios y para usuarios
con diferentes capacidades (ciego, mala vista, sordos, daltónicos, etc.)

5.2. Problemas de diseño de la interfaz de usuario:

El diseño de la interfaz de usuario debería resolver dos preguntas clave:

• ¿Cómo debe interactuar el usuario con el software?
• ¿Cómo debería la información del software presentarse al usuario?
El diseño de la interfaz de usuario debe integrar al usuario interacción y
presentación de información.

5.3. El diseño de las modalidades de interacción del usuario

La interacción del usuario implica la emisión de comandos y proporcionar

datos asociados al software. Los estilos de interacción se pueden
clasificar en los siguientes estilos primarios:

• Pregunta respuesta: La interacción está esencialmente restringida a

una sola pregunta-respuesta. Intercambio de información entre el usuario
y el software. El usuario envía una pregunta al software y el software
devuelve la respuesta a la pregunta.
• Manipulación directa: Los usuarios interactúan con objetos en la
pantalla de la computadora. A menudo incluye un dispositivo de
señalamiento (como un mouse, TrackBall o un dedo en pantallas táctiles)
que manipula un objeto e invoca acciones que especifican qué debe
hacerse con ese objeto.
• Selección de menú: El usuario selecciona un comando de una lista de
comandos del menú.
DISEÑO DE SOFTWARE Pág. 13

• Relleno de formulario: El usuario completa los campos de un

formulario. A veces, los campos incluyen menús, en cuyo caso el
formulario tiene botones de acción para el usuario para iniciar la acción.
• Lenguaje de mando: El usuario emite un comando y proporciona
parámetros relacionados para dirigir al software y señalarle que hacer
• Lenguaje natural: El usuario emite un comando en lenguaje natural.
Es decir, ejecuta una interfaz para un lenguaje de comandos, se analiza
y se traduce en comandos de software.

5.4. El diseño de la presentación de información

La presentación de la información puede ser de naturaleza textual o

gráfica. El enfoque MVC (Modelo-Vista-Control) es una forma eficaz de
mantener la presentación de la información separándose de la
información que se presenta. El tiempo de respuesta es generalmente
medido desde el punto en el que un usuario ejecuta una determinada
acción de control hasta que el software responde con una respuesta. Es
deseable una indicación del progreso mientras el software prepara la
respuesta. Las visualizaciones abstractas se pueden usar cuando se
presentan grandes cantidades de información. Según el estilo de
presentación de la información, los diseñadores también pueden utilizar
el color para mejorar la interfaz. Hay varias pautas importantes:
• Limite la cantidad de colores utilizados.
• Utilice el cambio de color para mostrar el cambio de estado del software.
• Utilice códigos de colores para respaldar la tarea del usuario.
• Utilice la codificación de colores de una manera reflexiva y coherente.
• Utilice colores para facilitar el acceso de las personas con daltonismo o
deficiencia de color
• No dependa solo del color para transmitir

5.5. Proceso de diseño de la interfaz de usuario

El diseño de la interfaz de usuario es un proceso iterativo; Los prototipos

de interfaz se utilizan a menudo para determinar las características, la
organización y el aspecto de la interfaz de usuario del software. Este
proceso incluye tres Actividades centrales las cuales son:

• Análisis de usuarios: En esta fase, el diseñador analiza las tareas de

los usuarios, el entorno de trabajo, otros softwares y cómo interactúan
los usuarios con otras personas.
DISEÑO DE SOFTWARE Pág. 14

• Creación de prototipos de software: Desarrollo de prototipos de

software ayuda a los usuarios a guiar la evolución de La interfaz.
• Evaluación de interfaz: Los diseñadores pueden observar
experiencias de los usuarios con la interfaz en evolución.

5.6. Localización e internacionalización

El diseño de la interfaz de usuario a menudo debe considerar la

internacionalización y la localización, que son medios de adaptar el
software a los diferentes idiomas, diferentes regionales y los requisitos
técnicos de un mercado objetivo. La internacionalización es el proceso
de diseño de una aplicación de software para que se puede adaptarse a
varios idiomas y regiones sin grandes cambios de ingeniería. La
localización es el proceso de adaptar el software internacionalizado para
una región o idioma específico agregando componentes específicos de
la localidad y la traducción del texto. La localización y la
internacionalización deben considere factores como símbolos, números,
moneda, tiempo y unidades de medida.

5.7. Metáforas y modelos conceptuales

Los diseñadores de interfaces de usuario pueden utilizar metáforas y

modelos conceptuales para establecer mapeos entre los softwares y
algún sistema de referencia conocido por el usuario en el mundo real, lo
que puede ayudar a los usuarios a aprenda y usar de manera más fácil
la interfaz. Por ejemplo, la operación "eliminar archivo" se puede convertir
en una metáfora usando el icono de un bote de basura. Al diseñar una
interfaz de usuario, los ingenieros de software deben tener cuidado de no
utilizar más de una metáfora de cada concepto. Las metáforas también
presentan problemas potenciales con respecto a la internacionalización,
ya que no todas las metáforas son significativas. o se aplican de la misma
manera en todas las culturas.

6. Análisis y evaluación de la calidad del diseño de software

Esta sección incluye una serie de temas de análisis y evaluación de la calidad

que están específicamente relacionados con el diseño de software.

6.1. Atributos de calidad

DISEÑO DE SOFTWARE Pág. 15

Varios atributos contribuyen a la calidad de un diseño de software,

incluyendo varias "-ilidades" (mantenibilidad, portabilidad, capacidad de
prueba, usabilidad) y "-osidades" (corrección, robustez).
Existe una distinción interesante entre los atributos de calidad
discernibles en tiempo de ejecución (por ejemplo, rendimiento,
seguridad, disponibilidad, funcionalidad, usabilidad), aquellos que no se
pueden discernir en tiempo de ejecución (por ejemplo, modificabilidad,
portabilidad, reutilización, capacidad de prueba) y los relacionados con la
arquitectura. cualidades intrínsecas (por ejemplo, integridad conceptual,
corrección, integridad).

6.2. Técnicas de análisis y evaluación de la calidad

Varias herramientas y técnicas pueden ayudar a analizar y evaluar la

calidad del diseño del software.
• Revisiones de diseño de software: técnicas informales y formalizadas
para determinar la calidad de los artefactos de diseño (por ejemplo,
revisiones de arquitectura, revisiones de diseño e inspecciones; técnicas
basadas en escenarios; rastreo de requisitos). Las revisiones de diseño
de software también pueden evaluar la seguridad. Se pueden revisar las
ayudas para la instalación, operación y uso (por ejemplo, manuales y
archivos de ayuda).
• Análisis estático: análisis estático formal o semiformal (no ejecutable)
que se puede utilizar para evaluar un diseño (por ejemplo, análisis de
árbol de fallas o verificación cruzada automatizada). Se puede realizar un
análisis de vulnerabilidad de diseño (por ejemplo, análisis estático de
debilidades de seguridad) si la seguridad es un problema. El análisis de
diseño formal utiliza modelos matemáticos que permiten a los
diseñadores predecir el comportamiento y validar el rendimiento del
software en lugar de tener que depender completamente de las pruebas.
El análisis de diseño formal se puede utilizar para detectar
especificaciones residuales y errores de diseño (quizás causados por
imprecisión, ambigüedad y, a veces, otros tipos de errores).
• Simulación y creación de prototipos: técnicas dinámicas para evaluar
un diseño (por ejemplo, simulación de rendimiento o prototipos de
viabilidad).

6.3. Medidas
DISEÑO DE SOFTWARE Pág. 16

Las medidas se pueden utilizar para evaluar o estimar cuantitativamente

varios aspectos de un diseño de software; por ejemplo, tamaño,
estructura o calidad. La mayoría de las medidas que se han propuesto
dependen del enfoque utilizado para producir el diseño. Estas medidas
se clasifican en dos amplias categorías:
• Medidas de diseño (estructuradas) basadas en funciones: medidas
obtenidas mediante el análisis de la descomposición funcional;
generalmente se representa mediante un diagrama de estructura (a
veces llamado diagrama jerárquico) en el que se pueden calcular varias
medidas.
• Medidas de diseño orientadas a objetos: la estructura de diseño se
suele representar como un diagrama de clases, en el que se pueden
calcular varias medidas. También se pueden calcular medidas sobre las
propiedades del contenido interno de cada clase.

7. Notaciones de diseño de software

Existen muchas notaciones para representar el diseño de software. Algunos se

utilizan para describir la estructura organizada de un diseño, otros para
representar el comportamiento del software. Ciertas notaciones se utilizan
principalmente durante el diseño arquitectónico y otros principalmente durante
el diseño detallado, aunque algunas notaciones se pueden utilizar para ambos
propósitos. Además, algunas notaciones se utilizan principalmente en el
contexto de métodos de diseño. Tenga en cuenta que el diseño de software a
menudo se logra utilizando múltiples notaciones. Aquí, se clasifican en
notaciones para describir la estructura (estática) vista frente a la vista
conductual (dinámica).

7.1. Descripciones estructurales (vista estática)

Las siguientes notaciones, en su mayoría, pero no siempre gráficas,

describen y representan la estructura y aspectos de un diseño de
software, es decir, son Diseños de software utilizado para describir los
componentes principales y cómo están interconectados (vista estática):

• Lenguajes de descripción de arquitectura (ADL): lenguajes

textuales, a menudo formales, utilizados para describir la arquitectura del
software en términos de componentes y conectores.
DISEÑO DE SOFTWARE Pág. 17

• Diagramas de clases y objetos: se utilizan para representar un

conjunto de clases (y objetos) y sus interrelaciones.
• Diagramas de componentes: se utilizan para representar un conjunto
de componentes y sus interrelaciones.
• Tarjetas de colaborador de responsabilidad de clase (CRC): se
utiliza para denotar los nombres de los componentes (clase), sus
responsabilidades y los nombres de los componentes colaboradores.
• Diagramas de implementación: se utilizan para representar un
conjunto de nodos (físicos) y sus interrelaciones, y, por lo tanto, para
modelar el aspecto del software.
• Diagramas entidad-relación (ERD): utilizado para representar
modelos conceptuales de datos almacenados en repositorios de
información.
• Idiomas de descripción de interfaz (IDL): lenguajes de programación
utilizados para definir las interfaces (nombres y tipos de operaciones) de
componentes de software.
• Gráficos de estructura: se utilizan para describir la llamada estructural
de los programas (qué módulos llaman y cuales son llamados por otros
módulos).

7.2. Descripciones de comportamiento (vista dinámica)

Las siguientes notaciones y lenguajes, algunos gráficos y algunos

textuales, se utilizan para describir el comportamiento dinámico de los
sistemas de software y sus componentes. Muchas de estas notaciones
son útiles principalmente, pero no exclusivamente, durante el diseño.
Además, las descripciones de comportamiento pueden incluir una
justificación para la decisión del diseño, por ejemplo, el cómo un diseño
cumplirá con los requisitos de seguridad.
• Diagramas de actividad: se utilizan para mostrar el flujo de control de
las actividades. Puede usarse para representar actividades concurrentes.
• Diagramas de comunicación: se utilizan para mostrar las
interacciones que ocurren entre un grupo de objetos; el énfasis está en
los objetos, sus enlaces y los mensajes que intercambian en esos
enlaces.
• Diagramas de flujo de datos (DFD): se utilizan para mostrar flujos de
datos entre elementos. Un diagrama de flujo de datos proporciona "una
descripción basada en el modelado del flujo de información en una red
de elementos operativos, con cada elemento haciendo uso o modificando
la información” por lo tanto, los diagramas de flujo de datos pueden ser
DISEÑO DE SOFTWARE Pág. 18

utilizados para el análisis de seguridad, ya que ofrecen identificación de

posibles rutas de ataque y divulgación de información confidencial.
• Tablas de decisión y diagramas: se utilizan para representar
combinaciones complejas de condiciones y acciones.
• Diagramas de flujo: se utilizan para representar el flujo de control y las
acciones asociadas.
• Diagramas de secuencia: se utilizan para mostrar las interacciones
entre un grupo de objetos, con énfasis en la ordenación temporal de los
mensajes entre objetos.
• Diagramas de transición de estado y diagrama de estado: Se utiliza
para mostrar el flujo de control de un estado a otro y cómo el
comportamiento de un componente cambia basado en su estado actual.
• Lenguajes de especificación formal: lenguajes textuales que utilizan
nociones básicas de las matemáticas (por ejemplo, lógica, conjunto,
secuencia). para definir de forma rigurosa y abstracta el software. A
menudo en términos de condiciones previas y posteriores.
• Lenguajes de diseño de programas y pseudocódigo (PDL):
lenguajes de programación estructurados que se utilizan para describir,
generalmente en la etapa de diseño detallado, el comportamiento de un
procedimiento o método.

8. Estrategias y métodos de diseño de software

Existen varias estrategias generales para ayudar a guiar el proceso de diseño.

A diferencia de las estrategias generales, los métodos son más específicos en
el sentido de que generalmente proporcionan un conjunto de notaciones que
se utilizarán con el método, una descripción del proceso que se utilizará al
seguir el método y un conjunto de pautas para utilizar el método. Estos
métodos son útiles como marco común para los equipos de ingenieros de
software.

8.1. Estrategias generales

Algunos ejemplos de estrategias generales útiles en el proceso de diseño

que se citan con frecuencia incluyen las estrategias divide y vencerás y
las estrategias de refinamiento paso a paso, las estrategias de arriba
hacia abajo frente a las de abajo hacia arriba y las estrategias que utilizan
heurísticas, uso de patrones y patrones lenguajes y el uso de un enfoque
iterativo e incremental.
DISEÑO DE SOFTWARE Pág. 19

8.2. Diseño (estructurado) orientado a funciones

Este es uno de los métodos clásicos de diseño de software, donde la

descomposición se centra en identificar las principales funciones del
software y luego elaborarlas y refinarlas de manera jerárquica de arriba
hacia abajo. El diseño estructurado se utiliza generalmente después del
análisis estructurado, produciendo así (entre otras cosas) diagramas de
flujo de datos y descripciones de procesos asociados. Los investigadores
han propuesto varias estrategias (por ejemplo, análisis de
transformación, análisis de transacciones) y heurísticas (por ejemplo,
fan-in / fan-out, alcance de efecto versus alcance de control) para
transformar un DFD en una arquitectura de software generalmente
representada como un diagrama de estructura.

8.3. Diseño orientado a objetos

Se han propuesto numerosos métodos de diseño de software basados

en objetos. El campo ha evolucionado desde los primeros diseños
orientados a objetos (OO) de mediados de la década de 1980 (sustantivo
= objeto; verbo = método; adjetivo = atributo), donde la herencia y el
polimorfismo juegan un papel clave, al campo del diseño basado en
componentes, donde se puede definir y acceder a la metainformación (a
través de la reflexión, por ejemplo). Aunque las raíces del diseño OO se
derivan del concepto de abstracción de datos, el diseño impulsado por la
responsabilidad se ha propuesto como un enfoque alternativo al diseño
OO.

8.4. Diseño centrado en la estructura de datos

El diseño centrado en la estructura de datos comienza a partir de las

estructuras de datos que manipula un programa en lugar de la función
que realiza. El ingeniero de software primero describe las estructuras de
datos de entrada y salida y luego desarrolla la estructura de control del
programa basándose en estos diagramas de estructura de datos. Se han
propuesto varias heurísticas para tratar casos especiales, por ejemplo,
cuando hay un desajuste entre las estructuras de entrada y salida.

8.5. Diseño basado en componentes (CBD)

DISEÑO DE SOFTWARE Pág. 20

Un componente de software es una unidad independiente, que tiene

interfaces y dependencias bien definidas que se pueden componer e
implementar de forma independiente. El diseño basado en componentes
aborda cuestiones relacionadas con la provisión, desarrollo e integración
de dichos componentes para mejorar la reutilización. Los componentes
de software reutilizados y listos para usar deben cumplir los mismos
requisitos de seguridad que el software nuevo. La gestión de la confianza
es una preocupación de diseño; los componentes tratados como si
tuvieran un cierto grado de confiabilidad no deberían depender de
componentes o servicios menos confiables.

8.6. Otros métodos

También existen otros enfoques interesantes. Los métodos intensivos y

adaptativos implementan incrementos de software y reducen el énfasis
en los requisitos y el diseño rigurosos del software.

El diseño orientado a aspectos es un método mediante el cual se

construye software utilizando aspectos para implementar las
preocupaciones transversales y las extensiones que se identifican
durante el proceso de requisitos de software. La arquitectura orientada a
servicios es una forma de crear software distribuido utilizando servicios
web ejecutados en computadoras distribuidas. Los sistemas de software
a menudo se construyen utilizando servicios de diferentes proveedores
porque los protocolos estándar (como HTTP, HTTPS, SOAP) se han
diseñado para soportar la comunicación de servicios y el intercambio de
información de servicios.

9. Herramientas de diseño de software

Se pueden utilizar herramientas de diseño de software para respaldar la

creación de los artefactos de diseño durante el proceso de desarrollo de
software. Pueden apoyar parte o la totalidad de las siguientes actividades:

• Traducir el modelo de requisitos en una representación de diseño

• Proporcionar soporte para la representación de componentes funcionales y
su interfaz
• Implementar el refinamiento heurístico y fraccionamiento
• Proporcionar directrices para la evaluación de la calidad.