DISEÑO DEL SOFTWARE

Descripción breve
Este material ha sido compilado con fines exclusivamente didácticos

Cecilia Milena Hinojosa Raza

cmhinojosa@espe.edu.ec
Tabla de contenido
DISEÑO DEL SOFTWARE ............................................................................................. 2
1. Contexto del diseño de software (Bruegge & Dutoit, 2010) ............................... 2
2. Conceptos de diseño ........................................................................................ 3
2.1 Correspondencia entre hardware y software:.............................................. 3
2.2 Administración de datos .............................................................................. 3
2.3 Control de acceso:....................................................................................... 4
2.4 Flujo de control ........................................................................................... 4
2.5 Condiciones de frontera .............................................................................. 4
3. Proceso de diseño de software (IEEE Computer Society, 2008) ........................ 4
4. Principios de diseño de software (IEEE Computer Society, 2014) ..................... 5
4.1 Abstracción ................................................................................................. 5
4.2 Acoplamiento y cohesión............................................................................. 5
4.3 Descomposición y modularización .............................................................. 5
4.4 La encapsulación y la ocultación de información ......................................... 5
4.5 Separación de interfaz e implementación .................................................... 5
4.6 Suficiencia, integridad y primitivismo ......................................................... 5
4.7 Separación de intereses .............................................................................. 5
5. Notaciones de diseño de software (IEEE Computer Society, 2014) ................... 6
5.1. Descripciones estructurales (vista estática) ................................................ 6
5.2. Descripciones de comportamiento (Vista dinámica) ................................... 6
5. Referencias .......................................................................................................... 7

Fundamentos de Ingeniería de Software Material compilado por Cecilia Hinojosa Pág. 1

 DISEÑO DEL SOFTWARE

1. Contexto del diseño de software (Bruegge & Dutoit, 2010)

El análisis da como resultado el modelo de requerimientos, el cual está conformado por los siguientes
productos:

 Un conjunto de requerimientos no funcionales y restricciones, como tiempo máximo de

respuesta, producción mínima, confiabilidad, plataforma de sistema operativo, etcétera.
(documento denominado “especificación de requerimientos del software” – ERS).
 Un modelo de caso de uso que describe la funcionalidad del sistema desde el punto de vista
de los actores.
 Un modelo de objetos que describe las entidades manipuladas por el sistema.
 Un diagrama de secuencia para cada caso de uso que muestra Ia secuencia de interacciones
entre los objetos que participan en el caso de uso.

El modelo de análisis describe el sistema por completo desde el punto de vista de los actores y sirve
como la base de comunicación entre el cliente y los desarrolladores. Sin embargo, el modelo de análisis
no contiene información acerca de la estructura interna del sistema, su configuración de hardware o,
en términos más generales, la manera en que se debe realizar el sistema.

El diseño de software es la actividad del ciclo de vida de ingeniería de software en la que se analizan
los requisitos de software para producir una descripción de la estructura interna del software que servirá
de base para su construcción: como se expresa en la Fig.1. Un diseño de software (el resultado) 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.

Fig.1 Transformación del modelo de análisis al modelo de diseño (Pressman & Maxim, 2015)

Fundamentos de Ingeniería de Software Material compilado por Cecilia Hinojosa Pág. 2

El diseño de software juega un papel importante en el desarrollo de software: durante el diseño del
software, los ingenieros de software producen varios modelos que forman una especie de modelo de
la solución a implementar. Podemos analizar y evaluar estos modelos para determinar si nos permitirán
cumplir con los diversos requisitos.

También podemos examinar y evaluar soluciones alternativas y compensaciones. Finalmente, podemos

usar los modelos resultantes para planificar actividades de desarrollo posteriores, como la verificación
y validación del sistema, además de usarlos como entradas y como punto de partida para la
construcción y las pruebas.

El diseño del sistema da como resultado los siguientes productos:

 Una lista de objetivos de diseño que describe las cualidades del sistema que deben optimizar
los desarrolladores. Los objetivos de diseño se derivan de los requerimientos no funcionales.
 Una arquitectura de software que describe la descomposición en subsistemas desde el punto
de vista de responsabilidades del subsistema, dependencias entre subsistemas,
correspondencia de los subsistemas con el hardware y decisiones de política principales, como
el flujo de control, control de acceso y almacenamiento de datos.

2. Conceptos de diseño
Sin importar el método de diseño que se utilice, debe aplicarse un conjunto de conceptos básicos al
diseño en el nivel de datos, arquitectura, interfaz y componentes. La descomposición en subsistemas
constituye la mayor parte del diseño del sistema. Los desarrolladores dividen el sistema en partes
manejables para tratar la complejidad: cada subsistema se asigna a un equipo y se realiza en forma
independiente. Sin embargo, para que esto sea posible, los desarrolladores necesitan enfrentar los
siguientes asuntos:

2.1 Correspondencia entre hardware y software:

¿Cuál es la configuración de hardware del sistema? ¿Cuál nodo es responsable de cuál funcionalidad'?
¿Cómo se realiza la comunicación entre nodos? ¿Cuáles servicios se realizan usando componentes de
software existentes? ¿Cómo se encapsulan estos componentes? El establecimiento de la
correspondencia entre hardware y software conduce, con frecuencia, a la definición de subsistemas
adicionales dedicados a mover datos de un nodo hacia otro, manejando los asuntos de concurrencia
y confiabilidad. Los componentes ya hechos y adquiridos a terceros, permiten que los desarrolladores
realicen servicios complejos en forma más económica. Los paquetes de interfaz de usuario y los
sistemas de administración de bases de datos son muy buenos ejemplos de componentes ya hechos.

2.2 Administración de datos:

¿Cuáles datos necesitan ser persistentes? ¿Dónde deben guardarse los datos persistentes? ¿Cómo se
tiene acceso a ellos? Los datos persistentes representan un cuello de botella en muchos frentes
diferentes del sistema: la mayor parte de la funcionalidad del sistema se relaciona con la creación o
manipulación de datos persistentes. Por esta razón, el acceso a los datos debe ser rápido y confiable.
Si la recuperación de los datos es lenta, el sistema completo será lento. Si es probable la corrupción de
los datos, también es probable Ia falla completa del sistema. Estos asuntos necesitan manejarse en
forma consistente en el nivel de sistema. Con frecuencia, esto conduce a la selección de un sistema de

Fundamentos de Ingeniería de Software Material compilado por Cecilia Hinojosa Pág. 3

administración de base de datos y a un subsistema adicional dedicado a la administración de datos
persistentes.

2.3 Control de acceso:

¿Quién puede tener acceso a cuáles datos? ¿Puede cambiar de manera dinámica el control de acceso?
¿Cómo se especifica y realiza el control de acceso? El control de acceso y la seguridad son asuntos en
el nivel de sistema. El control de acceso debe ser consistente por todo el sistema. En otras palabras, la
política usada para especificar quién puede y quién no puede tener acceso a determinados datos debe
ser la misma en todos los subsistemas.

2.4 Flujo de control:

¿Cómo pone el sistema en secuencia a las operaciones? ¿El sistema es manejado por eventos? ¿Puede
manejar más de una interacción de usuario a la vez? La selección del control de flujo tiene impacto en
las interfaces de los subsistemas. Si se selecciona un control de flujo manejado por eventos, los
subsistemas proporcionarán manejadores de eventos. Si se seleccionan hilos de proceso, los
subsistemas deben garantizar la exclusión mutua en secciones críticas.

2.5 Condiciones de frontera:

¿Cómo se inicia el sistema? ¿Cómo se le apaga? ¿Cómo se detectan manejan los casos excepcionales?
La iniciación y apagado del sistema representan, a menudo, Ia parte más grande de Ia complejidad del
sistema, en especial en un ambiente distribuido. La iniciación, el apagado y el manejo de excepciones
tienen impacto en Ia interfaz de todos los subsistemas.

3. Proceso de diseño de software (IEEE Computer Society, 2008)

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

 El primer paso del diseño es el diseño arquitectónico, también denominado diseño de alto nivel
o diseño de nivel superior, describe cómo se organiza el software en componentes. Su
resultado se conoce como arquitectura del software. La arquitectura del software es la
descripción de los elementos que lo forman y de las interrelaciones entre ellos. Representa el
enlace entre la especificación de requisitos y el diseño. Puede llevarse a cabo en paralelo con
actividades de especificación de requisitos. Implica un esfuerzo creativo, de forma que las
actividades a realizar pueden cambiar según la naturaleza del sistema a desarrollar.

 El segundo paso corresponde al diseño detallado, en este paso se refina y expande el diseño
preliminar de un sistema o componente en la medida en que el diseño sea lo suficientemente
completo para permitir la codificación y las pruebas. Para el efecto se realizan las siguientes
actividades:
o se desarrolla un diseño detallado de cada componente de software, que describe
las unidades de software que se construirán;
o se definen las interfaces externas de cada unidad de software; y
o se establece la coherencia y la trazabilidad entre el diseño detallado y los requisitos
y el diseño arquitectónico.

Fundamentos de Ingeniería de Software Material compilado por Cecilia Hinojosa Pág. 4

4. Principios de diseño de software (IEEE Computer Society, 2014)
Un principio es "una ley, doctrina o suposición integral y fundamental" [7]. 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 de diseño de software incluyen 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.

4.1 Abstracción
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" [1] (ver Abstracción en el KA de Fundamentos de
Computación). En el contexto del diseño de software, dos mecanismos de abstracción clave son la
parametrización y la especificación. La abstracción por parametrización se extrae 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 de procedimiento,
abstracción de datos y abstracción de control (iteración).

4.2 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".

4.3 Descomposición y modularización

La descomposición y la modularización significa que el software grande se divide en una serie de
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.

4.4 La encapsulación y la ocultación de información

Significa agrupar y empaquetar los detalles internos de una abstracción y hacer que esos detalles sean
inaccesibles para entidades externas.

4.5 Separación de interfaz e implementación

La separación de la interfaz y la implementación implica la definición de un componente mediante la
especificación de 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 ocultación de información más arriba).

4.6 Suficiencia, integridad y primitivismo.

Lograr la suficiencia y la integridad significa garantizar que un componente de software capture todas
las características importantes de una abstracción y nada más. El carácter primitivo significa que el
diseño debe basarse en patrones que sean fáciles de implementar.

4.7 Separación de intereses

Una preocupación es un "área de interés con respecto a un diseño de software" [8]. Una preocupación
de diseño es un área de diseño que es relevante para uno o más de sus interesados. Cada vista de
arquitectura enmarca una o más preocupaciones. La separación de las preocupaciones por puntos de
vista permite a los interesados centrarse en algunas cosas a la vez y ofrece un medio para gestionar la
complejidad [9].

Fundamentos de Ingeniería de Software Material compilado por Cecilia Hinojosa Pág. 5

5. Notaciones de diseño de software (IEEE Computer Society,
2014)
Existen diversas notaciones para representar artefactos de diseño de software. Algunos se utilizan para
describir la organización estructural de un diseño, otros para representar el comportamiento del
software. Ciertas notaciones se usan principalmente durante el diseño arquitectónico y otras
principalmente durante el diseño detallado, aunque algunas se pueden usar para ambos propósitos.
Además, algunas anotaciones se utilizan principalmente en el contexto de métodos de diseño
específicos. 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 vista estructural (estática) frente a la vista
de comportamiento (dinámica).

5.1. Descripciones estructurales (vista estática)

Las siguientes notaciones, en su mayoría, pero no siempre gráficas, describen y representan los
aspectos estructurales de un diseño de software, es decir, 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.
 Diagramas de clase y objeto: se utilizan para representar un conjunto de clases (y objetos) y
sus interrelaciones.
 Diagramas de componentes: se utilizan para representar un conjunto de componentes
("partes físicas y reemplazables de un sistema que [se ajustan] y [proporcionan] la realización
de un conjunto de interfaces" [18]) y sus interrelaciones.
 Tarjetas de clase-responsabilidad-colaboración (CRC): se utilizan para denotar los nombres de
los componentes (clase), sus responsabilidades y los nombres de sus 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 los aspectos físicos del software.
 Diagramas entidad relación (ERD): se utilizan para representar modelos conceptuales de datos
almacenados en repositorios de información.
 Lenguajes de descripción de interfaz (IDL): lenguajes de programación utilizados para definir
las interfaces (nombres y tipos de operaciones exportadas) de componentes de software.
 Gráficos de estructura: se utilizan para describir la estructura de llamada de los programas.

5.2. Descripciones de comportamiento (Vista dinámica)

Las siguientes anotaciones y lenguajes, algunos gráficos y otros textuales, se utilizan para describir el
comportamiento dinámico de los sistemas y componentes de software. Muchas de estas anotaciones
son útiles principalmente, pero no exclusivamente, durante el diseño detallado. Por otra parte, las
descripciones del comportamiento pueden incluir una justificación de la decisión de diseño tales como
la forma de un diseño cumplirá con los requisitos de seguridad.

 Diagramas de actividad: se utiliza para mostrar el flujo de control de una actividad a. Se puede
usar para representar actividades concurrentes.
 Diagramas de comunicación: se usan para mostrar las interacciones que ocurren entre un
grupo de objetos; se hace hincapié en los objetos, sus enlaces, y los mensajes que
intercambian en estos enlaces.
 Diagramas de flujo de datos (DFD): se utilizan para mostrar el flujo de datos entre elementos.
Un diagrama de flujo de datos proporciona “una descripción basada en el modelado de la
circulación de información alrededor de una red de elementos operativos, con cada elemento
haciendo uso de o la modificación de la información que fluye en ese elemento. Los flujos de
datos (y, por lo tanto, los diagramas de flujo de datos) se pueden utilizar para el análisis de

Fundamentos de Ingeniería de Software Material compilado por Cecilia Hinojosa Pág. 6

 seguridad, ya que ofrecen la identificación de posibles rutas para el ataque y la divulgación de
información confidencial.
 Tablas y diagramas de decisión: 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 a
realizar.
 Diagramas de secuencia: se utilizan para mostrar las interacciones entre un grupo de objetos,
con énfasis en el orden de tiempo de los mensajes que se pasan entre los objetos.
 Diagramas de transición estados: se utiliza para mostrar el flujo de control de estado a estado
y cómo el comportamiento de un componente cambia en función de su estado actual en una
máquina de estados.
 Lenguajes formales de especificación: lenguajes textuales que utilizan nociones básicas de las
matemáticas (por ejemplo, lógica, conjunto, secuencia) para definir rigurosa y abstractamente
las interfaces y el comportamiento de los componentes de software, a menudo en términos
de condiciones previas y posteriores. (Ver también los modelos de ingeniería de software y
métodos KA).
 Pseudo lenguajes: programación estructurada utilizada para describir el comportamiento de
un procedimiento o método, generalmente en la etapa de diseño detallado.

5. Referencias
Bruegge, B., & Dutoit, A. (2010). Ingeniería de Software Orientada a Objetos. México:
Pearson Educación.

IEEE. (1990). IEEE Standard Glossary of software terminology. IEEE.

IEEE. (01 de 09 de 2019). ISO 25000. Obtenido de

https://iso25000.com/index.php/normas-iso-25000/iso-25010

IEEE Computer Society. (2008). Systems and software engineering — Software life
cycle processes. Génova: IEEE.

IEEE Computer Society. (2014). Swebok V3.0. IEEE.

Pressman, R., & Maxim, B. (2015). Software Engineering: A practitioner´s approach.

New York: Mc Graw Hill.

Fundamentos de Ingeniería de Software Material compilado por Cecilia Hinojosa Pág. 7