Apuntes del docente

3. Ingeniería de software
UNIDAD 4 Diseño del software

4. 01Diseño| Diseño del sistema
El diseño puede definirse como (1) el proceso para definir la
arquitectura, los componentes, los interfaces, y otras
características de un sistema o componente, y (2) como el
resultado de este proceso.
(IEEE)
Definición

5. 02Diseño| Diseño del sistema
El diseño se descompone en dos subprocesos:
I. Diseño de la arquitectura o de alto nivel, en el cual se
describe cómo descomponer el sistema y organizarlo en los
diferentes componentes (arquitectura de software)
II.Diseño detallado, en el que se describe el comportamiento
específico de cada uno de los componentes de software
identificados.
Subprocesos

6. Reflexión:
¿Por qué es importante diseñar antes de
codificar?
03Diseño | Diseño de sistemas

7. El proyecto
y sus
característi
cas
Arquitectura de
sistemas
0
4
La arquitectura de un sistema software es la
organización fundamental de dicho sistema
plasmada en sus componentes, las
relaciones entre éstos y con el entorno, y
los principios que guían su diseño e
implementación.
Existen diferentes técnicas:
A.Arquitectura funcional
B.Estilos arquitectónicos
C.Arquitectura de la base de datos
D.Arquitectura hardware y de red
Diseño| Diseño del sistema

8. 05Diseño| Diseño del sistema
A. Arquitectura funcional
Basada en la descripción de las distintas funciones del
sistema. En este enfoque, el criterio de división en
subsistemas puede ser:
Vertical o funcional de usuario, donde la descomposición se
basa en agrupar funcionalidades que provienen de los
requisitos funcionales.
Transversal a las funcionalidades, incluyendo todos los
aspectos que no son específicos de ciertos grupos
funcionales.

9. 06Diseño| Diseño del sistema
Ejemplo
Ejemplo:
En una aplicación para la enseñanza virtual, podrían
considerarse subsistemas la gestión de contenidos, la
gestión de comunicaciones con los alumnos, y el subsistema
de gestión y administración académica (vertical).
Un subsistema de seguridad (políticas de control y derechos
de acceso) o un subsistema de persistencia que agrupa
todos los servicios relacionados con el almacenamiento
(transversal).

10. 07Diseño| Diseño del sistema
Implementan la arquitectura
funcional, haciendo referencia a cada
uno de los diferentes modelos de
representación conceptual en que se
pueden organizar los componentes
dentro de una arquitectura de
software.
Filtro – tubería
o
procesamiento
por lotes
Orientado a
objetos
Arquitectura
basada en
eventos
Control de
procesos
Procesos
distribuidos
Estilos
B. Estilos arquitectónicos

11. 08Diseño| Diseño del sistema
Filtro – tubería o procesamiento por lotes
Basado en el flujo de datos donde
un componente transforma una
entrada en una salida que a su
vez es la entrada para otro
componente
Orientado a objetos
Se representa principalmente mediante un
diagrama de clases, que se podría definir
como un grafo cuyos nodos son objetos y los
arcos son los conectores que comunican los
objetos mediante los métodos.

12. 09Diseño| Diseño del sistema
Arquitectura basada en eventos
•En lugar de producirse
invocaciones de métodos
explícitas, en este modelo los
componentes anuncian sus
eventos y otros registran su
interés en ser notificados cuando
se produzcan ciertos eventos.
•Ejemplo: en la interfaz de
usuario, el clic del ratón dispara
la ejecución de ciertas funciones
previamente asociadas a dicho
evento.

13. 10Diseño| Diseño del sistema
Control de procesos
Asocia componentes de control a
la entrada o salida de un
determinado proceso para
supervisar su comportamiento y
asegurar así que el
comportamiento de dicho
componente es el esperado.
Procesos distribuidos
La funcionalidad global del sistema se divide
en diferentes procesos generalmente
distribuidos en diferentes máquinas.
Módulo 1Control

14. 11Diseño| Diseño del sistema
Lenguajes arquitectónicos
Los lenguajes arquitectónicos
(ADL) describen arquitecturas
software mediante sus
componentes, conectores y
enlaces de comunicación.
ACME – Architecture Based
Languages and Environments
MODAF / DoDAF Architectural Model
(MAF)
SysML
UML

15. Pie de foto.
12Diseño| Diseño del sistema
Métodos de diseño
Métodos
estructurados
Diseño
orientado a
objetos
Métodos
orientados a
datos

16. Pie de foto.
13Diseño| Diseño del sistemaMétodos estructurados
Se basan en una aproximación descendente (top –
down) que aboga por descomponer el sistema
completo en niveles funcionales desde la
perspectiva global completa hasta el nivel de
detalle necesario para su implementación.
Especificación de datos
DIAGRMAS E/R
Especificación de datos
DIAGRMAS DFD
Especificación de control
DIAGRMAS TRANSICIONES DE
ESTADO
Las características más importantes de
estos métodos son la descomposición
funcional, el modelado de datos y la
representación del flujo de información.
Diccionario
de datos

17. Pie de foto.
14Diseño| Diseño del sistema
Técnicas para describir estas vistas en los métodos estructurados
Diagramas entidad/relación (E/R)Diagramas de flujo de datos

18. Pie de foto.
15Diseño| Diseño del sistema
Técnicas para describir estas vistas en los métodos estructurados
Diagramas de estructuraDiccionario de datos
CLIENTE = @DNI + NOMBRE_CLIENTE + DIRECCION +
{NUM_TFNO}
DIRECCION = [CALLE + NUM + PROV I APT_CORREOS]
@ precede a todo identificador
{ } indican iteración
+ representa composición
[ ] selección

19. Pie de foto.
16Diseño| Diseño del sistema
La descripción de módulos individuales
puede hacerse mediante numerosas
técnicas, como:
Tablas de transiciones o de decisión que
definen en forma matricial reglas con
acciones a realizar dadas ciertas
condiciones
Árboles de decisión

20. Pie de foto.
17Diseño| Diseño del sistema
La descripción de módulos individuales
puede hacerse mediante numerosas
técnicas, como:
Tablas de transiciones o de decisión que
definen en forma matricial reglas con
acciones a realizar dadas ciertas
condiciones
Árboles de decisión

21. 18Diseño| Diseño del sistemaMétodos orientados a datos
Primero se obtiene el modelo E/R (modelo
conceptual)
Después se normaliza para obtener el diseño lógico
de la BD.
Finalmente se obtiene el modelo físico que refleja
aspectos de implementación que no se deducen del
modelo lógico de manera evidente, tales como
índices, tipos de estructuras, etc.

22. 19Diseño| Diseño del sistemaDiseño orientado a objetos
• Un modelo captura una vista de un sistema abstrayendo y describiendo un
apropiado nivel de detalle.
• Los modelos a su vez se representan mediante diagramas, que son
representaciones gráficas de un conjunto de elementos de modelado y sus
relaciones.
• En UML (lenguaje unificado de modelado) los diagramas se clasifican en:
1. Diagramas de estructura que reflejan la estructura física (estática) del
sistema por medio de sus clases, métodos, atributos, interfaces, paquetes,
etc. y sus relaciones.
2. Diagramas de comportamiento que muestran la forma en que los distintos
elementos del sistema interaccionan, colaboran y cambian de estado
durante la ejecución del sistema para proveer la funcionalidad requerida.

23. 20Diseño| Diseño del sistema
Diagramas de despliegue
Un diagrama de despliegue muestra la configuración de los nodos que participan en
la ejecución y de los artefactos que residen en ellos.
La mayoría de las veces, esto implica modelar la topología del hardware sobre el que
se ejecuta el sistema.
Los diagramas de despliegue contienen:
Nodos
Hay dos tipos de nodos:
1. Recursos de nodos de computación del dispositivo que tienen capacidades de
procesamiento y la capacidad de ejecutar programas (PC, portátil o teléfono
móvil).
2. Nodo de entorno de ejecución, o EEN. Un EEN es cualquier sistema
informático que reside dentro de un nodo de dispositivo (sistema operativo,
contenedor de servlets).

24. 21Diseño| Diseño del sistema
Diagramas de despliegue
Si el nodo es parte de un paquete, su nombre puede
contener también el del paquete. Puede dividir al cubo en
comportamientos que agreguen información (como
componentes colocados en el nodo)
Otra forma de indicar los componentes
distribuidos es la de mostrarlos en
relaciones de dependencia con un nodo

25. 22Diseño| Diseño del sistema
Diagramas de despliegue
Normalmente se utilizan los diagramas de despliegue
de una de las tres siguientes maneras:
1.Modelar sistemas embebidos
2.Modelar sistemas cliente/servidor
3.Modelar sistemas completamente distribuidos

26. 23Diseño| Diseño del sistema
Modelar sistemas embebidos
Un sistema embebido es una colección de hardware
con gran cantidad de software que interactúa con el
mundo físico. Involucran software que controlan
dispositivos como motores, actuadores y pantallas que
están controlados por estímulos externos tales como
entradas de sensores, movimientos y cambios de
temperatura.

27. 24Diseño| Diseño del sistema
Modelar sistemas cliente/servidor
Un sistema cliente/servidor es una arquitectura muy
extendida que se basa en hacer una clara separación
de intereses entre la interfaz de usuario del sistema
(que reside en el cliente) y los datos persistentes del
sistema (que residen en el servidor)

28. 25Diseño| Diseño del sistema
Modelar sistemas completamente
distribuidos
Los sistemas distribuidos incluyen varios niveles de
servidores.

29. 26Diseño| Diseño del sistema
Diagramas de componentes
Un diagrama de componentes contiene componentes, interfaces y relaciones.

30. 27Diseño| Diseño del sistema
Diagramas de componentes
Se puede mostrar los componentes en relaciones de dependencia con un nodo

31. 28Diseño| Diseño del sistema
Otras técnicas de diseño
Marcos de trabajo:
Un marco de trabajo es un conjunto de clases, interfaces y sus
relaciones que proporcionan un diseño reusable para un sistema
software o parte de un sistema diseñado específicamente para ser
extendido y no como aplicación final.
Ejemplos: El marco de trabajo para pruebas unitarias de JUnit, o el de
interfaces de usuario GUI donde el usuario se centra en desarrollo de la
interfaz abstrayéndose de cómo se implementan sus distintos
componentes (botones, ventanas, adornos, etc.)

32. 29Diseño| Diseño del sistema
Evaluación y métricas en el diseño
Extensibilidad
Solidez
Fiabilidad
Tolerancia a fallos
Compatibilidad
Reusabilidad

33. Gracias.
©2020
Es responsabilidad exclusiva de los autores el respeto de los derechos de autor sobre los contenidos e imágenes en el presente
documento, en consecuencia, la BUAP no se hace responsable por el uso no autorizado, errores, omisiones o manipulaciones de los
derechos de autor y estos serán atribuidos directamente al Responsable de Contenidos, así como los efectos legales y éticos
correspondientes.