tema 4 – diseño del software
enrique barreiro
departamento de informática
universidade de vigo
escuela superior de ingeniería informática
ingeniería del software de gestión

introducción y objetivos del diseño
tema 4 – diseño del software
diseño de sistemas: transformación del modelo de
análisis en un modelo de diseño del sistema
se definen los objetivos de diseño del proyecto
se descompone el sistema en subsistemas más pequeños
que pueden ser realizados por diferentes equipos
Ingeniería de
se seleccionan estrategias para la construcción del
requerimientos
sistema
plataforma de hardware y software en la que se ejecutará
Modelo de casos
el sistema
de uso
estrategia de almacenamiento de datos persistentes
:Modelo
arquitectura estructural del sistema
flujo de control global
Análisis
política de control de acceso
Modelo de condiciones de interfaz
análisis
...
:Modelo
resultado del diseño: modelo de diseño
descripción clara de las estrategias
Diseño
descomposición en subsistemas
diagramas que muestran la correspondencia entre
Modelo de
hardware y software
diseño
modelo de objetos que describe la realización física de los
:Modelo
casos de uso
muestra el impacto en el sistema de requisitos funcionales,
no funcionales y restricciones
sirve de abstracción de la implementación del sistema,
convirtiéndose en el input fundamental de las actividades
de implementación
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 125

evolución del diseño de software
tema 4 – diseño del software
proceso continuo durante tres décadas
criterios de desarrollo de programas modulares
refinamiento de arquitectura software top-down
programación estructurada
diseño estructurado
diseño orientado a objetos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 3 / 125

calidad y diseño del software
tema 4 – diseño del software
El principio de la sabiduría de un ingeniero del software
El principio de la sabiduría de un ingeniero del software
es reconocer la diferencia entre conseguir que funcione
es reconocer la diferencia entre conseguir que funcione
un programa, y hacerlo bien.
un programa, y hacerlo bien.
M.A. Jackson, 1975
M.A. Jackson, 1975
concepto clave: CALIDAD
un diseño de calidad:
proporciona representaciones del software en las que se puede evaluar la calidad
permite una “traducción” correcta de los requisitos en un programa
sirve como fundamento para las actividades posteriores (implementación, prueba
y mantenimiento)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 4 / 125

calidad y diseño del software
tema 4 – diseño del software
Sin diseño de calidad:
Dificultades de gestión (el “destino cósmico” de los proyectos)
Sistemas poco satisfactorios e improductivos
45% del tiempo en pruebas y corrección
Myers: se intenta resolver el problema apurando en el proceso de diseño
para dejar tiempo suficiente al final del proyecto para corregir los errores
cometidos por apurar en el proceso de diseño.
Sistemas poco fiables: pruebas poco fiables (“parece que funciona”) y
sistemas que escapan al control de sus creadores.
Sistemas ineficientes: un buen diseño garantiza que se mantendrá el
rendimiento a pesar de las modificaciones que se realicen.
Sistemas poco flexibles y difíciles de mantener:
70% del coste en mantenimiento
El mantenimiento es caro:
1) Entender cómo funciona el sistema (o por qué no funciona)
Los tres primeros casos se
Los tres primeros casos se
agravan con un mal diseño 2) Diseñar la modificación
agravan con un mal diseño
3) Verificar el impacto
4) Realizar la modificación
5) Probar el sistema modificado
6) Planificar, organizar, coordinar, medir y documentar estas
actividades
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 5 / 125

conceptos esenciales del diseño
tema 4 – diseño del software
principios básicos para el proceso de diseño (Davis, 1995)
1. Usar enfoques alternativos
2. Rastrear los requisitos en el diseño
3. Reutilizar si es posible
4. Representar la estructura del dominio del problema
5. Presentación uniforme e integrada
6. Estructurado para permitir cambios
7. Estructurado para degradarse poco a poco ante errores o
circunstancias inusuales
8. Evaluación de la calidad del diseño mientras se realiza
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 6 / 125

conceptos esenciales del diseño
tema 4 – diseño del software
REFINAMIENTO
REFINAMIENTO
La arquitectura de un programa se
La arquitectura de un programa se
ABSTRACCIÓN
ABSTRACCIÓN desarrolla refinando sucesivamente
desarrolla refinando sucesivamente
niveles de detalle procedimental.
niveles de detalle procedimental.
-- Procedimental Conceptos complementarios
Procedimental Se desarrolla una jerarquía
Se desarrolla una jerarquía
-- De datos
De datos descomponiendo una abstracción
descomponiendo una abstracción
-- De control
De control procedimental para, paso a paso,
procedimental para, paso a paso,
llegar a los enunciados del
llegar a los enunciados del
lenguaje de programación
lenguaje de programación
La abstracción permite especificar
La abstracción permite especificar
procedimientos y datos suprimiendo detalles de
procedimientos y datos suprimiendo detalles de
bajo nivel.
bajo nivel.
El refinamiento ayuda a revelar detalles de bajo
El refinamiento ayuda a revelar detalles de bajo
nivel a medida que progresa el diseño.
nivel a medida que progresa el diseño.
- Requisitos familiares en el ámbito del
problema
abstracción
niveles de
- Diseño arquitectónico
- Diseño procedimental
- Código
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 7 / 125

conceptos esenciales del diseño
tema 4 – diseño del software
MODULARIDAD
MODULARIDAD
-- Componentes identificables y tratables
Componentes identificables y tratables
por separado
por separado
-- Permite a un programa ser manejable
Permite a un programa ser manejable
intelectualmente
intelectualmente
-- Criterios que permiten evaluar un
Criterios que permiten evaluar un
método de diseño con respecto a su
método de diseño con respecto a su
capacidad de definir un sistema modular
capacidad de definir un sistema modular
eficaz:
eficaz:
Capacidad de descomposición
Capacidad de descomposición
modular
modular
Capacidad de empleo de
Capacidad de empleo de
Costes totales
componentes modulares
componentes modulares del software
(reutilización)
(reutilización)
Costes o esfuerzo
Coste de
Capacidad de comprensión
Capacidad de comprensión integración
modular (entender un módulo sin M
modular (entender un módulo sin
referencias a otros, o con las menos
referencias a otros, o con las menos Región de
posibles)
posibles) costes
mínimos
Continuidad modular (cambios en
Continuidad modular (cambios en Coste/módulo
módulos y con poco impacto)
módulos y con poco impacto)
Protección modular
Protección modular Fuente: Ingeniería del Software. Un enfoque práctico. R. S. Pressman
Número de módulos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 8 / 125

conceptos esenciales del diseño
tema 4 – diseño del software
ACOPLAMIENTO
INDEPENDENCIA FUNCIONAL
INDEPENDENCIA FUNCIONAL
• • Consecuencia de la aplicación de conceptos Medida de la interdependencia relativa entre componentes,
Consecuencia de la aplicación de conceptos
como la modularidad, la abstracción y la y depende de la interfaz entre éstos, es decir, de la
como la modularidad, la abstracción y la
ocultación de la información cantidad y tipo de datos que comparten.
ocultación de la información
• • Componentes con “función única” y poca
Componentes con “función única” y poca
interacción con otros Objetivo durante el diseño: minimizar el acoplamiento
interacción con otros
• Más fáciles de mantener y probar utilizando conexiones sencillas entre los módulos.
• Más fáciles de mantener y probar
• Menos efectos secundarios por
• Menos efectos secundarios por
modificaciones Formas de reducir el acoplamiento:
modificaciones
• • Reducida propagación de errores • Eliminando relaciones innecesarias
Reducida propagación de errores
• • Facilita la reutilización • Reduciendo las relaciones necesarias
Facilita la reutilización
Beneficios de un bajo acoplamiento:
• Menor transmisión de defectos (efectos secundarios)
• Posibilidad de cambiar un componente (clase, subsistema,
COHESIÓN módulo,...) sin incidir sobre otros
• En el mantenimiento de un componente no hay que tener
Medida del grado de “fuerza funcional” de un en cuenta el contenido de otros
componente: cuanto menor sea el número de tareas
(elementos de procesamiento) que realiza un
componente, mayor será su cohesión. Conceptos complementarios
Conceptos complementarios
Diferentes grados de cohesión: Maximizar la cohesión es casi
Maximizar la cohesión es casi
lo mismo que minimizar el
lo mismo que minimizar el
COMPONENTE CON DIVERSAS
acoplamiento
COMPONENTE CON
acoplamiento
TAREAS POCO O NADA
TAREA SIMPLE
RELACIONADAS
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 9 / 125

proceso del diseño
tema 4 – diseño del software
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 10 / 125

proceso del diseño
tema 4 – diseño del software
Diseño arquitectónico
Identificación y documentación de los subsistemas que
forman el sistema y sus relaciones
Especificación abstracta
Especificación de servicios y restricciones bajo los que
funcionará cada subsistema
Diseño de la interfaz
Diseño y documentación de la interfaz de cada subsistema
con otros subsistemas
Diseño de componentes
Asignación de servicios a los componentes y diseño de sus
interfaces
Diseño de la estructura de datos
Diseño de algoritmos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 11 / 125

diseño arquitectónico
tema 4 – diseño del software
Los grandes sistemas
se descomponen en <<subsistema>>
Sistema de
subsistemas que visión
proporcionan <<subsistema>>
conjuntos de
servicios relacionados <<subsistema>> <<subsistema>>
Controlador del Co ntrolador del
brazo asidero
<<subsistema>>
Sistema d e i dentificaci ón
de objetos
<<subsistema>>
<<subsistema>>
<<subsistema>>
Contro lado r de cinta
<<subsistema>>
Sistema de selección
transportadora
Sistema de
de embalajes
embalaje
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 12 / 125

diseño arquitectónico
tema 4 – diseño del software
diseño arquitectónico
proceso inicial del diseño para identificar los subsistemas y
establecer un marco de trabajo para el control y comunicación
entre ellos
actividades principales
Estructuración
del sistema
estructuración del sistema en varios subsistemas principales
modelado del control entre las partes del sistema
descomposición modular: cada subsistema se descompone en
módulos interconectados
Modelado del
salida del diseño arquitectónico: documento con diversas
control
perspectivas de la arquitectura
modelo estructural estático: subsistemas o componentes a
desarrollar como unidades separadas
Des compos ición
modelo de proceso dinámico: organización del sistema en tiempo
modular
de ejecución, y que puede ser distinto al modelo estático
modelo de interfaz: definición de los servicios ofrecidos por cada
subsistema a través de su interfaz pública
modelos de relación: relaciones de, por ejemplo, el flujo de
datos entre subsistemas
modelo de distribución: cómo se distribuyen los subsistemas
entre los componentes físicos del sistema (computadores, nodos
de red,…)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 13 / 125

diseño arquitectónico
tema 4 – diseño del software
diseño arquitectónico y requisitos no funcionales
la arquitectura puede estar en función de requisitos no
funcionales (rendimiento, robustez, mantenibilidad, etc)
necesarios para el sistema y que en ocasiones pueden exigir
arquitecturas contradictorias
rendimiento: si se necesita un elevado rendimiento se
utilizarán pocos subsistemas con poca comunicación
seguridad: las aplicaciones con elevado nivel de seguridad
necesitarán estructurarse en capas con los recursos críticos
protegidos en las capas más internas, que contarán con
elevados nivel de validación
disponibilidad: puede obligar a incluir componentes
redundantes que puedan reemplazarse y actualizarse sin
detener el sistema
mantenibilidad: mejora cuando se utilizan componentes más
pequeños, que pueden intercambiarse con facilidad
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 14 / 125

diseño arquitectónico: arquitectura
tema 4 – diseño del software
diseño arquitectónico > arquitectura
arquitectura o estructuración:
identificación de subsistemas o capas clave
a desarrollar de forma independiente
identificación de las relaciones entre
Estructuración
del sistema
subsistemas
efectivo para la comunicación entre los
participantes en el proyecto y el reparto de
tareas entre distintos grupos
Modelado del
control
modelos específicos de arquitectura
modelo de depósito o repositorio
modelo cliente/servidor
Des compos ición
modelo de máquina abstracta o en capas
modular
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 15 / 125

modelo de repositorio
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo de depósito
modelo de repositorio (o depósito)
arquitectura en la que todos los datos compartidos se ubican en una
base de datos central a la que acceden todos los subsistemas
útil en sistemas que utilizan grandes cantidades de datos, generados
por un subsistema y utilizados por otro
sistemas de información corporativa
sistemas CAD y CASE
sistemas de control de procesos
...
generador
generador
editor de diseño de código
editor de diseño de código
traductor editor de
traductor editor de
Depósito de proyectos
de diseño programas
de diseño programas
arquitectura de un conjunto integrado de
herramientas CASE conjunto integrado de
arquitectura de un
herramientas CASE
analizador generador fuente: Ingeniería de Software, I. Sommerville,
analizador degenerador
de diseño informes fuente: Ingeniería de Software, I. Sommerville,
de diseño de informes
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 16 / 125

modelo de repositorio
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo de depósito
Ventajas Inconvenientes
los subsistemas deben estar acordes al
modelo de depósito de datos, lo que lleva
a un compromiso entre las necesidades
compartición eficiente de grandes específicas de cada herramienta, lo que
cantidades de datos, sin necesidad de puede afectar a cuestiones como el
transmitir datos explícitamente de un rendimiento.
subsistema a otro.
difícil o imposible integrar subsistemas
cuyos modelos de datos no se ajusten al
esquema.
los subsistemas que producen datos no
genera un gran volumen de información y
necesitan saber cómo son utilizados por
es difícil hacer evolucionar el sistema.
otros subsistemas.
diferentes subsistemas pueden tener
centralización de actividades de
diferentes requerimientos de políticas de
administración del depósito: respaldo,
seguridad, recuperación y respaldo. El
seguridad, control de acceso y
modelo de depósito impone la misma
recuperación de errores.
política a todos los subsistemas.
las herramientas compatibles con el difícil distribuir el depósito en varias
modelo de datos se integran máquinas (problemas de inconsistencia y
directamente redundancia de los datos)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 17 / 125

modelo cliente/servidor
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo cliente / servidor
modelo cliente/servidor
modelo de sistemas distribuido que muestra cómo datos
y procesamiento se distribuyen a lo largo de varios
procesadores
componentes
conjunto de servidores independientes que ofrecen
servicios a otros subsistemas
servidores de impresión
servidores de administración de archivos
servidores de bases de datos
...
conjunto de clientes
invocan los servicios ofrecidos por los servidores mediante un
protocolo de petición-respuesta (por ejemplo, http en la WWW)
existen varias instancias de un programa cliente que se ejecuta
de forma concurrente
tienen que conocer los nombres de los servidores disponibles y
los servicios que suministran, pero los servidores no conocen a
los clientes
una red que permite a los clientes acceder a los servicios
no existe una relación 1:1 entre procesos y
procesadores: un computador servidor puede ejecutar
varios procesos servidores (confusión entre servidor-
proceso y servidor-computador)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 18 / 125

modelo cliente/servidor
tema 4 – diseño del software
Servidor de
catálogosde
Servidor
catálogos
Cliente 1
Catálogo Cliente 1
Catálogo
Servidor de vídeos
Servidor de vídeos
Cliente 2
Cliente 2
Archivos de vídeos
Archivos de vídeos
INTERNET
Servidor de
imágenesde
Servidor
imágenes
Cliente 3
Cliente 3
Fotografías
Fotografías
digitalizadas
digitalizadas
Servidor web
Servidor web
Cliente 4
Cliente 4
Páginas web
Páginas web
Cliente 1
Cliente 1
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 19 / 125

modelo cliente/servidor
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo cliente / servidor
distintas arquitecturas cliente/servidor
tres capas lógicas
capa de presentación: se encarga de mostrar
la información e interactuar con el usuario.
capa de procesamiento de la aplicación:
implementa la lógica de la aplicación
Capa de
presentación
capa de administración de datos: se refiere a
todas las operaciones de la base de datos
modelo en dos capas físicas:
la arquitectura más simple. La aplicación se
Capa de organiza como un servidor (o varios
procesamiento de idénticos) y un conjunto de clientes
la aplicación
modelo de “cliente delgado”
todo el procesamiento de la aplicación y la
administración de datos se realiza en el servidor
el cliente únicamente ejecuta el software
Capa de
administración de
modelo de “cliente grueso”
datos
el servidor sólo es responsable de la
administración de datos
el software del cliente implementa toda o gran
parte de la lógica de la aplicación y las
interacciones del usuario con el sistema
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 20 / 125

modelo cliente/servidor
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente delgado
modelo de cliente delgado
utilizado cuando los sistemas heredados centralizados (p.ejemplo,
sistemas basados en mainframes – grandes servidores corporativos)
evolucionan a una arquitectura cliente/servidor
la interfaz migra a los PCs, estaciones de trabajo o a dispositivos de red
sencillos
sistemas basados en tecnologías web: los dispositivos de red ejecutan un
navegador, que implementa la interfaz de usuario
la aplicación misma actúa como servidor y maneja todo el procesamiento
de la aplicación y administración de datos
desventajas
implica una gran carga de procesamiento en el servidor
el servidor realiza todos los cálculos, lo que provoca tráfico en la red
entre cliente y servidor
desaprovecha la capacidad de cálculo de equipos como los PCs
Servidor
Servidor
Presentación
Cliente
Cliente Administrador de datos
Administrador de datos
Procesamiento de la
Procesamiento de la
aplicación
aplicación
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 21 / 125

modelo cliente/servidor
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente grueso
modelo de cliente grueso
distribuye al cliente procesamiento
lógico de la aplicación y la presentación
Cliente
Cliente Servidor aprovecha la capacidad de
Servidor
Procesamiento de las
Procesamiento de las
procesamiento disponible en los
aplicaciones y presentación
aplicaciones y presentación Administrador de datos
Administrador de datos
clientes
ejemplo: sistemas bancarios ATM
(cajeros automáticos)
los ATM no se conectan directamente a
la base de datos del cliente sino al
gestor de transacciones
gestor de transacciones: sistema
middleware que
organiza las comunicaciones con
los clientes remotos
Servidor
coloca en serie las transacciones
de cuentas
de los clientes para ser
ATM
procesadas por la base de datos,
ATM
lo que permite al sistema
Monitor de Base de recuperarse de fallos sin
teleprocesa- datos de corromper los datos
miento cuentas
inconvenientes
administración del sistema más
compleja al distribuirse la
ATM
ATM
funcionalidad de la aplicación en
diferentes computadores
mantenimiento: reinstalación en cada
computador cliente si cambia la
aplicación
ATM
ATM
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 22 / 125

modelo cliente/servidor
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo cliente / servidor
problemas del enfoque de dos capas físicas
las tres capas lógicas (presentación,
Servidor
de cuentas procesamiento y administración de datos) deben
asociarse a dos sistemas de cómputo
problemas de escalabilidad y rendimiento en el
Base de
modelo de cliente delgado
SQL datos de
cuentas problemas de administración del sistema en el
modelo de cliente grueso
alternativa: utilizar tres capas físicas
Consultas SQL
las tres capas lógicas son procesos separados
lógicamente
no implica la existencia de tres sistemas de
Servidor Servidor
cómputo conectados a la red pero si es necesario
web web
se pueden separar fácilmente y ejecutar en
procesadores separados
son más escalables que las arquitecturas de dos
Provisión del servicio Provisión del servicio
niveles
de la cuenta de la cuenta
ejemplo: sistema bancario en Internet:
administración de datos: suministrado por la base
de datos del banco (normalmente en un
Interacción HTTP
mainframe)
servicios de aplicación (transferencias, consulta de
movimientos, pago de facturas,...) suministrados
por un servidor Web
presentación: el cliente es el computador del
usuario con un navegador web
sistema escalable: se pueden añadir fácilmente
servidores web cuando aumenta el número de
clientes
Clientes web
Clientes web
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 23 / 125

modelo cliente/servidor
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo cliente / servidor
Código móvil: applets de Java y
controles ActiveX
permiten implementar un modelo
cliente/servidor a medio camino entre los
Servidor
de cliente delgado y grueso
web
funcionamiento
parte del software de procesamiento se
Administración datos
descarga en el cliente como applet,
Procesamiento
aplicación
aligerando la carga del servidor
la interfaz de usuario se construye
utilizando un navegador Web que ejecuta
los applets o los controles ActiveX
Interacción HTTP
problemas
diferencias en las implementaciones de
Java en navegadores de distintos
Cliente fabricantes
web
necesidad de una velocidad de
transmisión aceptable para descargar los
applets
Presentación
problemas de seguridad
Ejecución applets
libertad de configuración por el usuario
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 24 / 125

modelo cliente/servidor
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo cliente / servidor
Arquitectura Aplicaciones
Aplicaciones de sistemas heredados donde no es práctico
separar el procesamiento de las aplicaciones y la
administración de datos.
C/S de dos capas con
Aplicaciones computacionalmente intensivas como los
clientes delgados
compiladores con poca o ninguna administración de datos.
Aplicaciones intensivas en datos (navegar y consultar) con
poco o ningún procesamiento de la aplicación.
Aplicaciones con procesamiento de datos computacionalmente
intensivo (por ejemplo, visualización de datos, animaciones
gráficas,...)
C/S de dos capas con
clientes gruesos Aplicaciones con funcionalidad para el usuario final
relativamente estable utilizadas en un entorno con
administración de sistemas bien establecido.
Aplicaciones de gran escala con cientos o miles de clientes.
C/S de tres capas o Aplicaciones donde tanto los datos como la aplicación son
múltiples capas volátiles.
Aplicaciones donde se integran datos de diversas fuentes.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 25 / 125

modelo en capas
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo en estratos
modelo en capas o de máquina
abstracta
modela la interacción entre los
subsistemas organizando un sistema en
Usuarios
una serie de capas
cada capa presta servicios a la capa
Gestión de configuraciones del sistema
inmediatamente superior y actúa como
cliente de la que queda encerrada
Gestión de objetos del sistema
el diseño incluye los protocolos que
establecen cómo interactuará cada par
Base de datos del sistema
de capas
arquitectura cambiable y portable:
Sistema
preservando la interfaz, una capa se
operativo
puede reemplazar por otra
cuando cambian las interfaces de las
capas sólo afecta a la capa adyacente
desventajas
difícil estructurar los sistemas pues es
posible que el usuario requiera acceso a
capas internas (p.ej., bases de datos) lo
que subvierte el modelo
Modelo de capas de un sistema de gestión de versiones.
Fuente: Ingeniería del Software, I. Sommerville
el rendimiento puede resultar afectado
por los múltiples niveles de
interpretación de órdenes que se
requieren a veces
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 26 / 125

modelo en capas: ejemplos
tema 4 – diseño del software
diseño arquitectónico > arquitectura > modelo en estratos
Arquitectura de red OSI
Aplicación Aplicación
Transferencia de información de
Presentación Presentación
las aplicaciones
Sesión Sesión
Transferencia de datos
Transporte Transporte
Red Red Red
Enlace de datos Enlace de datos Enlace de datos Interconexión física
Física Física Física
MEDIOS DE COMUNICACIÓN
Arquitectura de red TCP/IP
Aplicación TELNET FTP SMTP DNS
Transporte TCP UDP
Interred IP
Host a red ARPANET INTERNET SATNET LAN
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 27 / 125

diseño arquitectónico: modelado del control
tema 4 – diseño del software
diseño arquitectónico > modelado del control
modelos de control
representan la forma en que los
subsistemas se controlan para que sus
servicios se entreguen en el lugar correcto y
en el momento justo
Estructuración
del sistema
el arquitecto organiza los subsistemas
acorde a un modelo de control
dos modelos de control genéricos:
control centralizado: un subsistema es el
Modelado del
responsable de controlar, iniciar y detener
control
otros subsistemas. También puede pasar el
control a otros subsistemas, pero espera
que se le devuelva esa responsabilidad de
control.
Des compos ición
control basado en eventos: cada subsistema
modular
puede responder a eventos generados en el
exterior, provenientes de otros subsistemas
o del entorno del sistema
complementan los modelos estructurales, y
todos éstos se pueden llevar a cabo
utilizando un control centralizado u
orientado a eventos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 28 / 125

control centralizado
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control centralizado
sistemas de control centralizado
un subsistema tiene la responsabilidad de controlar
el sistema y administrar la ejecución de otros
programa
programa
subsistemas
principal
principal
dos clases, según se ejecuten secuencialmente o en
paralelo
rutina 1 rutina 2 rutina 3
modelo de llamada-retorno (ejecución secuencial):
rutina 1 rutina 2 rutina 3
el control se inicia en la parte superior de una jerarquía y
por medio de llamadas a subrutinas pasa a los niveles del
árbol
rutina 1.1 rutina 1.2 rutina 3.1 rutina 3.2 no es un modelo estructural, por lo que no es necesario,
rutina 1.1 rutina 1.2 rutina 3.1 rutina 3.2
por ejemplo, que la Rutina 1.1. forme parte de la Rutina 1
sólo se aplica a sistemas secuenciales
utilizado por lenguajes de programación como Ada, Pascal
y C, aunque también en lenguajes OO.
ventaja: es relativamente sencillo analizar los flujos de
control y conocer cómo responderá el sistema a cierto tipo
procesos procesos de entradas
del sensor del actuador
inconveniente: las excepciones a operaciones normales
son complicadas de gestionar
modelo del administrador:
se aplica a los modelos concurrentes
controlador
controlador un componente del sistema se designa como
sistema
sistema administrador y controla el inicio, detención y coordinación
del sistema según las variables de estado del sistema.
Verifica si otros procesos han producido información para
procesar o si ha que pasarles información para el
procesos interfaz de controlador procesamiento.
interfaz de controlador
de cálculo usuario de fallos un proceso es un subsistema o módulo que se ejecuta en
usuario de fallos
paralelo con otros procesos
utilizado en sistemas de tiempo real “suaves” (con
restricciones de tiempo no muy estrictas)
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 29 / 125

control centralizado: ejemplo
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control centralizado
Ejemplo del modelo del administrador centralizado
400 Hz 100 Hz
60 Hz
Proceso detector
Proceso detector Proceso sensor de Proceso sensor de
de movimiento Proceso sensor de Proceso sensor de
de movimiento puertas ventanas
puertas ventanas
class BuildingMOnitor extends Thread {
class BuildingMOnitor extends Thread {
Estado del detector
BuildingSensor win, door, move ;
Estado del sensor BuildingSensor win, door, move ;
560 Hz Estado del sensor
Siren siren = new Siren () ;
Lights lights = new Lights () ;;
Siren siren = new Siren ()
Lights lights = new Lights () ;
DoorSensors doors = new DoorSensors (30) ;
DoorSensors doors = new DoorSensors (30) ;
Proceso de
Proceso de
monitorización ( ... )
monitorización ( ... )
edificio
edificio
BuldingMonitor()
{ BuldingMonitor()
{
Número de habitación //inicializar sensores e iniciar procesos
( ... ) //inicializar sensores e iniciar procesos
} ( ... )
}
public void run ()
{ public void run ()
Proceso del {
Proceso del int room = 0 ;
sistema de alarma
while (true) 0 ;
int room =
sistema de alarma
{ while (true)
{
//sondear movimiento sensores (400Hz)
move = movements.getVal () ; (400Hz)
//sondear movimiento sensores
move = movements.getVal () ;
fuente: Ingeniería de Software, I. Sommerville ( ... )
( ... )
}
}
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 30 / 125

control dirigido por eventos
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control dirigido por eventos
sistemas de control dirigido por eventos
se rigen por eventos generados en el exterior (señal de un
sensor, comando desde un menú,…)
diferentes tipos de sistemas dirigidos por eventos
hojas de cálculo (el valor cambiante de las celdas provoca que
otras se modifiquen)
sistemas de producción basados en reglas (por ejemplo, de
Inteligencia Artificial) en los que una condición que se
convierte en verdadera provoca que se dispare una acción
objetos activos, en los que el cambio de valor de un atributo
del objeto dispara algunas acciones
dos tipos de modelos principales
modelos de transmisión (broadcast): los subsistemas registran
un interés en eventos específicos y cuando ocurren el control
se transfiere al subsistema que puede manejar el evento
modelos dirigidos por interrupciones: especialmente útiles para
sistemas de tiempo real que necesitan manejar rápidamente
eventos generados en el exterior
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 31 / 125

control por eventos: modelos de transmisión
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión
modelos de transmisión
se diferencia del modelo del administrador en
que la política de control no está contenida en
el controlador de eventos y mensajes, sino
que los subsistemas deciden qué eventos
requieren y el controlador asegura que estos
eventos sean enviados a dichos subsistemas
efectivos para integrar subsistemas
distribuidos a lo largo de diferentes
computadores de una red
utilizados por los agentes de solicitud de
objetos (ORBs) para las comunicaciones de
objetos distribuidos
subsistema subsistema subsistema
ventajas:
subsistema subsistema subsistema
1 2 3
1 2 3 la evolución es relativamente sencilla pues se
pueden integrar nuevos subsistemas
registrando sus eventos en el controlador de
eventos
cualquier subsistema puede activar otros
subsistemas sin conocer su nombre o
Controlador de eventos y mensajes
ubicación
los subsistemas se pueden incrementar en
máquinas distribuidas, de forma transparente
para otros subsistemas
desventaja:
subsistema subsistema
subsistema subsistema los subsistemas no saben si los eventos se
4 5
4 5 manejarán ni cuando lo harán
cuando un subsistema genera un evento no
sabe qué otros subsistemas han registrado un
interés en ese evento
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 32 / 125

modelos de transmisión: objetos distribuidos
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos
modelos de transmisión: arquitecturas de objetos
distribuidos
consiste en eliminar la distinción entre cliente y servidor y
diseñar la arquitectura del sistema como una arquitectura de
objetos distribuidos
los componentes fundamentales son
objetos que proveen una interfaz a un conjunto de servicios que
suministran
otros objetos llaman a estos servicios sin ninguna distinción lógica
entre un cliente (receptor de un servicio) y un servidor (proveedor de
un servicio)
funcionamiento
o3
o1 o2
los objetos se distribuyen a lo largo de varios computadores sobre
una red
se comunican a través de middleware (una especie de “bus de
s(o3)
s(o1) s(o2) software” que provee un conjunto de servicios que permiten
comunicación, agregación y destrucción de objetos del sistema
middleware: agente de solicitud de objetos (ORB, Object Request
Broker) y provee una interfaz transparente entre objetos
ventajas
permite retrasar las decisiones sobre dónde y cómo se deben
ORB
suministrar los servicios pues los objetos proveedores de servicios se
pueden ejecutar en cualquier nodo de la red
arquitectura abierta: permite agregar nuevos recursos si es necesario
pues los estándares del ORB (p.ej., CORBA) se han desarrollado para
permitir la comunicación y servicios entre objetos escritos en
diferentes lenguajes
o5
o4
sistema flexible y escalable: se pueden crear diferentes instancias del
sistema con el mismo servicio suministrado por objetos diferentes o
por réplicas de objetos para hacer frente a diversas cargas del
sistema
s(o5)
s(o4)
desventajas
más complejas de diseñar que los sistemas cliente/servidor clásicos
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 33 / 125

modelos de transmisión: objetos distribuidos
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos
utilización de una arquitectura de objetos distribuidos
como modelo lógico para estructurar y organizar el sistema
se piensa únicamente en cómo proveer de funcionalidad a la
aplicación (servicios y combinaciones de servicios)
identificación de cómo suministrar los servicios utilizando
varios objetos distribuidos
objetos de “grano grueso” (también llamados “objetos de negocio”)
que suministran servicios específicos del dominio. Por ejemplo,
objetos de control de existencias, comunicaciones con el cliente,
pedidos,...
como un enfoque flexible para implementar sistemas
cliente/servidor
el modelo lógico del sistema es un modelo c/s en el que
clientes y servidores se realizan como objetos distribuidos que
se comunican a través del ORB
el sistema se puede cambiar fácilmente de dos capas a uno de
múltiples capas (implementando el servidor o el cliente como
un objeto compuesto de varios objetos pequeños que
suministran servicios especializados)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 34 / 125

modelos de transmisión: objetos distribuidos
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos
ejemplo de arquitectura de objetos
distribuidos
sistema de minería de datos que busca
relaciones entre datos almacenados en varias
bases de datos diferentes
cada base de datos se encapsula como un
objeto distribuido con una interfaz que
suministra acceso de sólo lectura
generador informes
los objetos integradores recolectan
Base de datos 1
información de todas las bases de datos para
tratar de deducir relaciones específicas (cada
uno tiene su especialidad, como variaciones
Integrador 1
por temporadas, relaciones entre tipos de
bienes,...)
los objetos visualizadores interactúan con los
integradores para visualizar o generar
Base de datos 2 visualizador
informes
la arquitectura de objetos distribuidos es más
adecuada para este tipo de aplicaciones que
una c/s
Integrador 2
el modelo lógico del sistema no es
suministrar información proporcionada por
Base de datos 3
diferentes servicios de administración de
pantalla
datos (como en los ATM)
el número de bases de datos se puede
incrementar sin perturbar el sistema pues
son objetos distribuidos que pueden residir
en diferentes máquinas
se pueden explorar nuevos tipos de
relaciones agregando nuevos objetos
integradores que no necesitan conocer a los
ya existentes
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 35 / 125

control por eventos: modelos dirigidos por
interrupciones
tema 4 – diseño del software
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos dirigidos por interrupciones
modelos dirigidos por interrupciones
útiles para
sistemas de tiempo real que necesitan manejar muy
interrupciones
rápidamente eventos generados en el exterior (por
ejemplo, sistemas de seguridad en automóviles)
combinado con el modelo de administrador centralizado: el
administrador central maneja la ejecución normal del
vector de sistema utilizando el control basado en interrupciones para
interrupción
casos de emergencia
interrupciones
existen varios tipos de interrupciones conocidas con un
controlador definido para cada tipo
controlador controlador controlador controlador cada tipo de interrupción se asocia con la ubicación de
controlador controlador controlador controlador
1 2 3 4 memoria en la que se almacena la dirección del controlador
1 2 3 4
cuando se recibe una interrupción de un determinado tipo,
un interruptor de hardware transfiere el control al
controlador adecuado
proceso proceso proceso proceso
el controlador puede iniciar o detener otros procesos en
proceso proceso proceso proceso
1 2 3 4
respuesta a los eventos recibidos por el interruptor
1 2 3 4
ventaja: permite dar respuestas rápidas a los eventos
desventajas
fuente: Ingeniería de Software, I. Sommerville
complejo de programar y difícil de validar
si el número de interrupciones está limitado por el
hardware, cuando se alcanza el límite no se pueden
gestionar más tipos de eventos (se pueden asignar distintos
tipos de eventos a una interrupción, dejando que el
controlador detecte qué evento ha ocurrido, pero disminuye
el rendimiento
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 36 / 125

computación distribuida interorganizacional
tema 4 – diseño del software
Computación distribuida interorganizacional
Por seguridad e interoperabilidad se ha utilizado sobre todo
computación distribuida intraorganizacional
Servidores dentro de la misma organización
Facilidad de aplicación de estándares locales y procesos
operacionales
Modelos más recientes de computación distribuida
interorganizacional
Computación peer-to-peer (p2p)
Sistemas orientados a servicios
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 37 / 125

arquitecturas peer-to-peer
tema 4 – diseño del software
Sistemas peer-to-peer (p2p)
Sistemas descentralizados:
los cálculos se pueden realizar en cualquier nodo de la red
no se distingue, a priori, entre clientes y servidores
Sistemas diseñados para aprovechar la ventaja de potencia
computacional y disponibilidad de almacenamiento de
grandes redes
Estándares y protocolos de comunicaciones embebidos en la
propia aplicación y cada nodo ejecuta una copia de la
aplicación
Usados sobre todo en sistemas personales
Compartición de ficheros (Gnutella, Kazaa, eMule,…)
Sistemas de mensajería instantánea (ICQ, Messenger,…)
Otras aplicaciones (SETI@home, Freenet,…)
Comienza a utilizarse en entornos corporativos para
aplicaciones con grandes necesidades computacionales
(Intel, Boeing,…)
Problemas: protección, autentificación,…
Utilización en sistemas de información no críticos o cuando
existen relaciones de trabajo entre las organizaciones
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 38 / 125

arquitecturas peer-to-peer
tema 4 – diseño del software
teóricamente, cada nodo en la red puede conocer
cualquier otro nodo, pero como es inviable se organizan
por “localidades”, con nodos-puente entre localidades
arquitecturas p2p descentralizadas
arquitecturas p2p semicentralizadas
n8
n8
n6 n13
n6 n13
n4
n4
n7 n12
n7 n12
n3
n3
n9
n9
n2 n14
n2 n14
n10
n10
n11
n11
n5
n5
n1
n1
fuente: Ingeniería del Software, Ian Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 39 / 125

arquitecturas peer-to-peer
tema 4 – diseño del software
arquitectura p2p descentralizada
los nodos de red actúan como interruptores de
comunicaciones, encaminando datos y señales de control
entre nodos.
búsqueda de un documento
se envía comando de búsqueda a los nodos de la localidad
los nodos comprueban si tienen el documento
si lo tienen, lo devuelven al solicitante
si no lo tienen, encaminan la búsqueda a otros nodos
al encontrar el documento, el nodo que lo posee lo encamina
de vuelta al nodo solicitante.
ventaja: muy redundante y por lo tanto tolerante a fallos y a
desconexiones de nodos
desventajas
sobrecargas (la misma búsqueda es realizada por muchos
nodos)
replicaciones de comunicaciones entre nodos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 40 / 125

arquitecturas peer-to-peer
tema 4 – diseño del software
arquitectura p2p semicentralizada
nodos que actúan como servidores para facilitar las comunicaciones
entre nodos
establecimiento de contactos entre nodos
coordinación de cálculos
una vez que se localizan los nodos disponibles se establecen
comunicaciones directas y no es necesaria la conexión con el servidor
Buscador de
servicios
n1
n1
n4
n4
n3
n3
n6
n6
n2 n5
n2 n5
fuente: Ingeniería del Software, Ian Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 41 / 125

arquitectura de sistemas orientados a servicios
tema 4 – diseño del software
servicio web
representación estándar para cualquier recurso computacional o de
información que pueda ser usado por otros programas
permite que la provisión de un servicio sea independiente de la aplicación
que lo utiliza
las organizaciones pueden hacer accesible información a diferentes
programas definiendo y publicando una interfaz de servicio web, que define
los datos disponibles
cómo acceder a los datos
proveedores de servicios: desarrollan y ofertan servicios a usuarios y
permiten construir aplicaciones enlazando servicios de diferentes
proveedores
diferentes tipos que se ajustan al mismo modelo
Registro de
Registro de
servicios
servicios Publicar
Buscar
Solicitante de Suministrador
Solicitante de Suministrador Servicio
Servicio
servicios de servicios
servicios de servicios
Enlazar
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 42 / 125

arquitectura de sistemas orientados a servicios
tema 4 – diseño del software
algunas ventajas
los usuarios pueden pagar por los servicios sólo en función
del uso
aplicaciones más pequeñas (manejos de excepciones como
servicios externos)
construcción a medida de nuevos servicios, enlazando
servicios existentes
estándares basados en XML
SOAP (Simple Object Access Protocol): define una
organización para intercambio de datos estructurados entre
servicios web
WSDL (Web Services Description Language): define cómo
pueden representarse las interfaces de servicios web
UDDI (Universal Description, Discovery and Integration):
estándar de búsqueda que define cómo puede organizarse la
información de descripción de servicios
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 43 / 125

arquitectura de sistemas orientados a servicios
tema 4 – diseño del software
Información del tráfico de carreteras
fuente: Ingeniería del Software, Ian Sommerville
Localizador de Información
Localizador de Información
Información de
Información de carreteras de tráfico
carreteras de tráfico
utilidades
utilidades
Información
Información
del tiempo
del tiempo
Coordenadas GPS
Coordenadas GPS
Coordenadas GPS
Servicio de información móvil Buscador de
servicios
Traductor
Traductor
Reúne información
Información
Encuentra un
del lenguaje
servicio disponible
Comando de
coordenadas
GPS
Interfaz de
Transmisor
Receptor usuario
Recibe un flujo de Recibe peticiones
Envía la posición y la
información desde del usuario
petición de
los servicios información al servicio
Radio Localizador
Traduce la Encuentra la
información digital posición del
a señal de radio vehículo Sistema software de vehículos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 44 / 125

arquitecturas de aplicaciones
tema 4 – diseño del software
las empresas tienen necesidades similares de
información (facturación, recursos humanos,
contabilidad,…)
similares arquitecturas de las aplicaciones
diferencias en las funcionalidades específicas
arquitecturas genéricas según el tipo de aplicación
aplicaciones de procesamiento de datos
procesamiento de datos por lotes con poca o nula interacción
del usuario
aplicaciones de procesamiento de transacciones
procesan peticiones del usuario para obtener información y
para actualizar información en una base de datos
sistemas de procesamiento de eventos
aplicaciones controladas por órdenes del usuario o cambios en
valores de variables (juegos, hojas de cálculo, presentación de
información,…)
sistemas de procesamiento de lenguajes
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 45 / 125

arquitecturas de aplicaciones: sistemas de
procesamiento de datos
tema 4 – diseño del software
sistemas de procesamiento de datos
dan soporte a parte del negocio como pago de nóminas, cálculo e
impresión de facturas, renovación de suscripciones o pólizas,…
trabajan con grandes bases de datos
componentes
entrada: reúne entradas desde una o más fuentes
procesamiento: realiza cálculos utilizando las entradas
salida: genera salidas para ser escritas en la base de datos y/o impresas
modelo arquitectónico simple pero suele corresponderse con una compleja
arquitectura de datos
Sistema
Sistema
Entrada Procesamiento Salida
Entrada Procesamiento Salida
Base de datos
Base de datos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 46 / 125

arquitecturas de aplicaciones: sistemas de
procesamiento de datos
tema 4 – diseño del software
Escribir transacciones Transacciones
Escribir transacciones Transacciones
Registros de
Registros de de impuestos de impuestos
de impuestos de impuestos
empleados
empleados
Gasto deducible +
número SS + oficina
tributaria
Escribir datos
Escribir datos
Tasas de pagos Datos de
Tasas de pagos Datos de
de pensiones
Leer registro de pensiones
mensuales
Leer registro pensiones
mensuales pensiones
de empleado
de empleado
Pensión deducible +
Registro de número SS
empleado
Registro válido
Datos del empleado +
de empleado
Validar datos
Validar datos Calcular Imprimir
Calcular Imprimir
deducciones
de empleado IMPRESORA
de empleado salario nómina
salario nómina
Información de Pago neto + información
pagos de cuenta bancaria
Leer datos de pagos
Leer datos de pagos Transacciones
Escribir transacción Transacciones
Escribir transacción
mensuales Tablas de
mensuales Tablas de del banco
bancaria del banco
bancaria
impuestos
impuestos
Deducción de la SS +
número SS
Escribir datos de la Datos de la
Escribir datos de la Datos de la
Datos de
Datos de
Seguridad Social Seguridad Social
Seguridad Social Seguridad Social
pagos
pagos
mensuales
mensuales
fuente: Ingeniería del Software, Ian Sommerville
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 47 / 125

arquitecturas de aplicaciones: sistemas de
procesamiento de transacciones
tema 4 – diseño del software
sistemas de procesamiento de transacciones
procesan peticiones de usuario para obtener información o
para actualizar una base de datos
transacción de una base de datos: secuencia de operaciones
tratada como una única unidad, en la que todas las
operaciones tienen que ser completadas antes de que los
cambios en la base de datos sean permanentes
ejemplo: reintegro en un cajero automático
normalmente son sistemas interactivos en los que el usuario
realiza peticiones de servicios de forma asíncrona
Procesamiento Lógica de la Gestor de
Procesamiento Lógica de la Gestor de Base de
Base de
de E/S aplicación transacciones
de E/S aplicación transacciones datos
datos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 48 / 125

arquitecturas de aplicaciones: sistemas de
procesamiento de transacciones
tema 4 – diseño del software
la estructura entrada-proceso-salida también se aplica a muchos
sistemas de procesamiento de transacciones (versiones
interactivas de sistemas de procesamiento por lotes)
Entrada Proceso Salida
Obtener el
Obtener el
Imprimir
Imprimir
identificador de
identificador de
detalles
detalles
cuenta del cliente
cuenta del cliente Consultar la
Consultar la
cuenta
cuenta
Validar la Devolver la
Validar la Devolver la
tarjeta tarjeta
tarjeta tarjeta
Actualizar la
Actualizar la
cuenta
cuenta
Seleccionar el Dispensar
Seleccionar el Dispensar
servicio efectivo
servicio efectivo
ATM Base de Datos ATM
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 49 / 125

arquitecturas de aplicaciones: sistemas de
procesamiento de transacciones
tema 4 – diseño del software
Bases de datos de cuentas
Monitor de teleprocesamiento
Monitor de teleprocesamiento
(middleware)
(middleware)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 50 / 125

arquitecturas de aplicaciones: sistemas de
procesamiento de transacciones
tema 4 – diseño del software
sistemas de información y de gestión de recursos: sistemas con
gran interacción con una base de datos compartida
sistemas gestión documental
sistemas de ayuda a la toma de decisiones
sistemas de horarios
sistemas de gestión de tráfico aéreo
sistemas de biblioteca Interfaz de usuario
Interfaz de usuario
sistemas de comercio electrónico
…
Comunicaciones del usuario
Comunicaciones del usuario
Recuperación y modificación de información
Recuperación y modificación de información
Base de datos de gestión de transacciones
Base de datos de gestión de transacciones
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 51 / 125

arquitecturas de aplicaciones: sistemas de
procesamiento de transacciones
tema 4 – diseño del software
Arquitectura de un sistema de
Arquitectura de un sistema de
asignación de recursos
gestión de documentos
Interfaz del navegador web Interfaz de usuario
Interfaz del navegador web Interfaz de usuario
Identificación Gestor de consultas Gestor de Identificación Entrega de Gestión
de usuario y formularios impresión de usuario recursos de consultas
Control de políticas
Búsqueda Recuperación Gestor de Registro de Gestión Asignación
de recursos
distribuida de documentos derechos cuentas de recursos de recursos
Gestión de transacciones de
Índice de biblioteca Gestión de transacciones de
Índice de biblioteca lala base de datos de recursos
base de datos de recursos
BD1 BD2 BD3 BD4 BDn
BD1 BD2 BD3 BD4 BDn
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 52 / 125

descomposición modular
tema 4 – diseño del software
diseño arquitectónico > descomposición modular
descomposición modular
después de diseñar la arquitectura estructural se
descomponen los subsistemas en módulos
no existe una distinción rígida entre la
Estructuración
descomposición del sistema y la descomposición
del sistema
modular:
los modelos arquitectónicos se pueden aplicar aquí
sin embargo, los componentes en los módulos son más
pequeños que los subsistemas, por lo que se utilizan
modelos alternativos de descomposición
Modelado del
control modelos principales de descomposición modular
modelo orientado a objetos:
el sistema se descompone en un conjunto de objetos que
se comunican entre ellos
Des compos ición los módulos son objetos con estado privado y operaciones
definidas sobre ese estado
modular
modelo de flujo de datos (o estructurado):
el sistema se descompone en módulos funcionales que
reciben datos y los transforman en datos de salida
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 53 / 125

diseño orientado a objetos: actividades
tema 4 – diseño del software
diseño orientado a objetos > actividades
actividades (según el Proceso Unificado de
Desarrollo)
diseño de la arquitectura
realizado por los arquitectos
esbozan distintos componentes
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
subsistemas principales e interfaces
Diseño de la
clases del diseño importantes (como las
arquitectura
activas)
mecanismos genéricos de diseño del modelo de
diseño
diseño de casos de uso
Diseñar un Diseñar una
lo realizan los ingenieros de casos de uso
caso de uso clase
detallan cada caso de uso en términos de
clases y/o subsistemas del diseño
participantes y sus interfaces
las realizaciones de casos de uso resultantes
establecen los requisitos de comportamiento
para cada clase o subsistema
diseño de clases
Diseñar un
lo realizan los ingenieros de componentes
subsistema
integran los requisitos dentro de cada clase
(creando operaciones, atributos y relaciones)
diseño de subsistemas
lo realizan los ingenieros de componentes
se identifican candidatos para ser
subsistemas, especificando las interfaces
entre ellos
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 54 / 125

diseño de la arquitectura
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura
diseño de la arquitectura
el objetivo es esbozar los modelos
de diseño y despliegue y su
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
arquitectura mediante la
Diseño de la
arquitectura
identificación de los siguientes
elementos:
nodos y configuraciones de red
Diseñar un Diseñar una
subsistemas e interfaces entre ellos
caso de uso clase
clases del diseño significativas para
la arquitectura
mecanismos de diseño genéricos
derivados de requisitos no
funcionales (persistencia,
distribución, rendimiento,...)
Diseñar un
identificados durante el análisis
subsistema
los arquitectos consideran distintas
posibilidades de reutilización (partes
de sistemas parecidos o de
productos software generales)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 55 / 125

identificación de nodos y configuraciones de red
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de nodos y configuraciones de red
configuraciones físicas de la red
Cliente del
gran influencia sobre la arquitectura del software
comprador
las configuraciones habituales utilizan una
arquitectura en tres capas (por ejemplo, cliente /
servidor)
Intranet
capa de clientes (interacciones de usuarios)
capa de funcionalidad de la base de datos
Servidor del
capa de lógica de negocio o aplicación
comprador
aspectos importantes de las configuraciones de
red
internet número de nodos necesarios y capacidad en
términos de potencia de proceso y tamaño de
Servidor
memoria
del vendedor
tipo de conexiones entre los nodos y protocolos de
internet
comunicaciones a utilizar
características de las conexiones y protocolos en
int ernet aspectos como ancho de banda, disponibilidad y
calidad
intranet
Servidor del
necesidad de capacidades de redundancia de
banco
procesos, gestión de fallos, migración de procesos,
política de copias de seguridad,...
Cliente del
una vez conocidos se pueden aplicar distintas
vendedor
tecnologías
ORB (Object Request Broker)
servicios de replicación de datos
...
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
las configuraciones de red se muestran en
diagramas de despliegue
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 56 / 125

identificación de nodos y configuraciones de red
tema 4 – diseño del software
Cliente del
Ejemplo de un sistema de comercio
comprador
electrónico.
Se ejecuta sobre tres nodos servidores y un cierto
Intranet
número de nodos cliente.
Servidor del
En primer lugar existe un nodo servidor para el
comprador
comprador y uno para el vendedor, debido a que
cada una de las organizaciones compradoras o
vendedoras necesitan un servidor central para sus
internet
objetos de negocio y su procesamiento.
Servidor
del vendedor
Los usuarios finales, como el Comprador, acceden
internet
al sistema mediante nodos cliente. Estos nodos se
comunican mediante el protocolo TCP/IP de
int ernet
Internet (o de intranets).
intranet
Servidor del
banco
También existe un tercer nodo servidor para el
propio banco. En él se producen los verdaderos
Cliente del
vendedor pagos de facturas (es decir, las transferencias
entre cuentas).
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 57 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
identificación de subsistemas y sus interfaces
arquitectura
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas
Diseñar un
subsistema
subsistemas
forma de organizar el modelo de
diseño en piezas manejables
representan varios tipos de
subsistemas
Capa específica
software desarrollado
de la aplicación
internamente en el proyecto
productos reutilizados
recursos existentes en la
Capa general de la
empresa
aplicación
pasos en la identificación de
subsistemas
identificación de subsistemas de
Capa
aplicación
intermedia
identificación de subsistemas
intermedios y de software del
sistema
Capa de software
definición de dependencias entre
del sistema
subsistemas
identificación de interfaces entre
subsistemas
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 58 / 125

identificación de subsistemas de la aplicación
tema 4 – diseño del software
Subsistemas de la aplicación
Identificación de los subsistemas de las capas específica y general de la
aplicación
Si hubo descomposición adecuada en paquetes en el análisis, se pueden
utilizar para identificar subsistemas en el modelo de diseño
Capa específica de la aplicación
Capa general de la aplicación
Capa intermedia
Capa de software del sistema
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 59 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
identificación de subsistemas de la aplicación
arquitectura
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas de la aplicación
Diseñar un
subsistema
se parte de la descomposición de paquetes realizada en el análisis y,
según los casos, puede ser necesario refinar esa identificación de
subsistemas
parte de un paquete (subsistema) del análisis puede ser compartida por varios
otros subsistemas, por lo que en sí puede ser un subsistema
algunas partes de un paquete del análisis se realizan mediante productos
reutilizados, por lo que esas funciones se pueden asignar a capas intermedias o
subsistemas de software del sistema
los paquetes del análisis no representan una adecuada división del trabajo
los paquetes del análisis no representan la incorporación de un sistema
heredado, que se puede encapsular mediante un subsistema de diseño
independiente
los paquetes del análisis no están preparados para una distribución sobre los
nodos decididos, por lo que se podrían dividir de forma que cada uno de ellos
pueda asignarse a un nodo determinado. Luego se refinarán para minimizar el
tráfico de la red
<<paquet e del análisis>> <<paquete del aná li sis>>
Gestión de facturas del Modelo de análisis
Gestión de cuentas
c omprador
<<paquet e del diseño>>
<<paquete del diseño>>
Gestión facturas comprador
Modelo de diseño
Gestión cuentas
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 60 / 125

identificación de subsistemas de la aplicación
tema 4 – diseño del software
MODELO DE ANÁLISIS
MODELO DE DISEÑO <<trace>>
<<trace>>
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 61 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
identificación de subsistemas de la aplicación
arquitectura
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas de la aplicación
Diseñar un
subsistema
Durante el diseño se identificó el subsistema de
Gestión facturas
servicio Gestión de se identificó el subsistema de
Durante el diseño Planificación de Pagos para
comprador
proporcionar un servicio general que puedanpara
servicio Gestión de Planificación de Pagos
utilizar diferentes realizaciones de que puedan
proporcionar un servicio general casos de uso
capa específica de la aplicación utilizar diferentes realizaciones de casos de uso
capa general de la aplicación
Gestión de planificación Gestión de
de p agos cuentas
El subsistema Gestión Facturas Comprador se
descompone recursivamente en tres nuevos se
El subsistema Gestión Facturas Comprador
subsistemas para tratar su distribuciónnuevos
descompone recursivamente en tres entre los
subsistemas para tratar su distribución entre los
distintos nodos
distintos nodos
<< subsistema de diseño >>
Cliente del
comprador
Gestión facturas comprador
Intranet
IU del Gestión solicitudes pago Gestión de facturas
comprador
Servidor del
comprador
procesamiento
Gestor pedidos
procesamie
IU facturas
nto
solicitud
internet
solicitudes confirmación
de pago de pago factura
Servidor
pedidos
del vendedor
internet
int ernet
intranet
Servidor del
banco
Cliente del
Cliente Servidor Servidor
vendedor
comprador comprador vendedor
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 62 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
subsistemas intermedios y de software del sistema
arquitectura
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas intermedios y del sistema
Diseñar un
subsistema
Identificación de subsistemas
Abstract Windowing Remote Method
intermedios y de software del
Toolkit Invocation
sistema
toda la funcionalidad descansa sobre
Java.applet Java.awt Java.rmi
sistemas operativos
sistemas de gestión de bases de
datos
software de comunicaciones
Navegador web Máquina virtual
tecnologías de distribución de
ja va
Capa intermedia objetos
tecnologías de gestión de
transacciones
software de diseño de interfaces de
Capa de software TCP / IP
usuario
del sistema
compra de middleware y software del
sistema
En este ejem plo, el sis tem a de be ejecutarse en
poco o nulo control sobre su
diferentes ti pos de m áqui nas y la empresa decid ió
evolución
im plem entar esta arquitectura me diante los
importante mantener libertad de
pa quetes Java AWT, RMI y Appl et, que se
acción y evitar hacerse totalmente
ejecutan sobre l a m áqui na virtual Java.
dependientes de un producto o
Ad emás, h ay q ue uti li zar un naveg ador para cargar
fabricante
pá ginas w eb.
considerar cada producto software
A baj o n ive l, el sistema se construye so bre comprado como un subsistema
independiente con interfaces explícitos
so ftware del si stema, como el pro tocolo TCP/IP
para el resto de sistemas
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 63 / 125

definición de dependencias entre subsistemas
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > dependencias entre subsistemas
dependencias
Gestión
facturas
deben definirse si hay
capa específica de la aplicación
relaciones entre los
contenidos de unos
subsistemas y otros
Gestión de planif icación
Gestión de
de pagos
la dirección de la
cuentas
capa general de
dependencia es la misma
la aplicación
que la de la relación
(navegabilidad)
Java.applet Java.awt Java.rmi
Navegador web
Máquina virtual
java
capa intermedia
capa de software TCP / IP
del sistema
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 64 / 125

identificación de interfaces entre subsistemas
tema 4 – diseño del software
Una clase que hace
referencia a
TransferenciaEntreCuentas
desde el exterior
MODELO DE ANÁLISIS
<<trace>>
MODELO DE DISEÑO
Transferencias
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 65 / 125

identificación de interfaces entre subsistemas
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > identificación de interfaces
interfaces proporcionadas
por un subsistema
definen operaciones que
son accesibles “desde
fuera” del subsistema
vienen proporcionadas
<<subsystem >>
por
Gestión de
facturas ReceptorDeFacturas clases
subsistemas dentro
del subsistema
Capa específica de la aplicación
además hay que
identificar las
Capa general de la aplicación
operaciones que se
pueden definir sobre las
SolicitudDePago
interfaces (se hace en el
diseño de casos de uso)
<<subsystem>> <<subsystem >>
Gestión de planificación
Gestión de
de pagos
cuentas
Transferencias
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 66 / 125

identificación de mecanismos genéricos de diseño
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de mecanismos genéricos de diseño
requisitos especiales identificados durante el análisis
decidir cómo tratarlos, teniendo en cuenta las tecnologías
de diseño e implementación disponibles
cuestiones relacionadas con diversas cuestiones, como:
persistencia
distribución transparente de objetos
características de seguridad
detección y recuperación de errores
gestión de transacciones
ejemplos
se necesita que algunos objetos sean accesibles desde varios
nodos de red
Necesita diseñarse un sistema distribuido
java.rmi.UnicastRemoteObject
Posible solución: implementar esa distribución de objetos haciendo
que cada clase distribuida sea subclase de la clase abstracta de
Java, java.rmi.UnicastRemoteObject, que soporta RMI (técnica de
Java para obtener una distribución transparente de objetos)
se necesita que algunos objetos sean persistentes (por
ejemplo, Pedido y Factura)
Solución: utilizar un gestor de bases de datos orientado a objetos
Factura
(buen rendimiento con estructuras de objetos complejas,
migración difícil desde un sistema relacional,...)
Solución: utilizar un gestor de bases de datos relacional (mejor
rendimiento para datos tabulares, tecnología más madura,...)
Necesario documentar en la solución cómo se tratarán los aspectos
de persistencia
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 67 / 125

identificación de mecanismos genéricos: patrones
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de mecanismos genéricos de diseño
identificación de colaboraciones genéricas (patrones)
pueden servir como patrones utilizados por diferentes casos
de uso en el modelo de diseño
ejemplo: un actor crea un objeto de negocio (pedido,
factura,...) y lo envía a otro actor
ejemplo 1: cuando un comprador solicita un pedido, invoca el
caso de uso realizar pedido. el caso de uso permite al
comprador especificar y enviar electrónicamente un pedido al
vendedor
ejemplo 2: cuando un vendedor decide enviar una factura a un
comprador, invoca el caso de uso enviar factura al comprador,
que permite al vendedor escoger una factura y enviarla
electrónicamente al comprador
se trata de un comportamiento común que se puede
representar mediante una colaboración genérica (utilización de
clases abstractas)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 68 / 125

identificación de mecanismos genéricos: patrones
tema 4 – diseño del software
diseño orientado a objetos > diseño de la arquitectura > identificación de mecanismos genéricos de diseño
1: enviar objeto de negocio
Creación de objeto
de negocio
: Objeto de
Negocio
: Emisor 3: crear( )
2: crearObjetoDeNegocio
Al diseñar el caso de uso
Al diseñar el caso de uso
Enviar Factura al Comprador,
Enviar Factura al Comprador,
:
se puede hacer que algunas
5: obtenerInformación( )
se puede hacer que algunas
ControlProcesamientoEmisor
clases sean subtipos de cada
clases sean subtipos de cada
: Procesamiento
una de las clases abstractas
Receptor
4: recibirObjetoDeNegocio( objetoDeNegocio)
una de las clases abstractas
que participan en la
que participan en la
colaboración genérica
6: presentarObjetoDeNegocio(ObjetoDeNegocio)
colaboración genérica
IU Present ación de
7: presentar objeto de negocio
objeto de negocio
: Recept or
Clasificadores abstractos
que participan en la ControlProcesamie Objeto de ControlProcesamie IU Present. de
IU Creación de : Receptor
colaboración genérica de ntoEmisor negocio ntoReceptor objeto de negocio
objeto de negocio
: Emisor
envío de objetos de
negocio
Clasificadores concretos
que participan en la ControlProcesamie Factura Procesamiento IU Present. de
IU Creación de
realización del caso de ntoFacturas SolicitudesPago objeto de facturas
facturas
uso Enviar Factura al
Comprador : Comprador
: Vendedor
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 69 / 125

diseño de un caso de uso
tema 4 – diseño del software
diseño orientado a objetos > diseño de casos de uso
actividades del diseño de un caso
de uso
identificar las clases del diseño y/o
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
subsistemas cuyas instancias son
arquitectura
necesarias para llevar a cabo el
flujo de sucesos del caso de uso
describir las interacciones entre
Diseñar un Diseñar una
objetos del diseño
caso de uso clase
identificar los subsistemas e
interfaces participantes
describir las interacciones entre
subsistemas
Diseñar un
identificar requisitos no
subsistema
funcionales
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 70 / 125

Diseño de un caso de uso
tema 4 – diseño del software
Definir objetos
Definir objetos
participantes
participantes
Definir objetos Definir objetos Definir objetos
Definir objetos Definir objetos Definir objetos
conceptuales de interfaz de control
conceptuales de interfaz de control
Definir
Definir
interacciones
interacciones
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 71 / 125

Identificación de objetos de interfaz
tema 4 – diseño del software
objetos de interfaz
representan la interfaz del sistema con los actores
en cada caso de uso cada actor interactúa con, al menos, un
objeto de interfaz
recopilan la información del actor y la traduce para que
pueda ser usada por los objetos de entidad y por los objetos
de control
modelan la interfaz del usuario a un nivel muy básico, que
evolucionará durante el desarrollo
identificación de los objetos de interfaz
identificar formularios y ventanas que el usuario necesita para
introducir datos en el sistema (por ejemplo,
FormularioInformeDeEmergencia, BotónInformeEmergencia,...)
identificar noticias y mensajes que el sistema usa para
responder al usuario (por ejemplo AcuseDeRecibo)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 72 / 125

Identificación de objetos de interfaz
tema 4 – diseño del software
Ubicación Descripción del caso de uso
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar
1. Emergencia en su PDA. la función Informar
El OficialCampo activa
Estación Emergencia en su PDA.
OficialCampo 2. El sistema COMUNICA responde presentando
2. unEl sistema COMUNICA responde presentando
formulario al OficialCampo. El formulario
incluye un menúal OficialCampo. El formulario
un formulario de tipos de emergencia
(incendio, un menú de tipos de emergencia
incluye accidente, disturbios,...) y campos
(incendio, accidente, disturbios,...) y campos
para introducir la ubicación, descripción del
para introducir la ubicación, descripción del
incidente, petición de recursos,...
incidente, petición de recursos,...
3. El OficialCampo cubre el formulario, y puede
3. El OficialCampo cubre el formulario, y puede
también describir respuestas posibles a la
también describir respuestas posibles a la
situación de emergencia y solicitar recursos
específicos.de emergencia y llenado el
situación Una vez que ha solicitar recursos
específicos. Una vez que ha llenado el
formulario, el OficialCampo lo envía oprimiendo
el formulario, el OficialCampo lo envía oprimiendo
botón “Enviar Informe” y en ese momento se
le el botónal Controlador y en ese momento se
notifica “Enviar Informe”
le notifica al Controlador
4. Al Controlador se le notifica un nuevo informe
4. deAl Controlador se le notifica un de diálogo
incidente mediante un cuadro nuevo informe
Estación
Aviso usado para desplegar el acuse de recibo del Controlador
desplegable. Elmediante un cuadro la diálogo
de incidente Controlador revisa de
Controlador
AcuseDeRecibo
desplegable. El Controlador revisa la
información recibida y crea un Incidente en la
hacia el OficialCampo
base de datos recibida y al caso de uso
información llamando crea un Incidente en la
AbrirIncidente. Toda la informaciónde uso
base de datos llamando al caso contenida
enAbrirIncidente. Toda la informaciónincluye
el formulario del OficialCampo se contenida
Estación Ordenador utilizado por el Controlador
automáticamente en el Incidente. El se incluye
en el formulario del OficialCampo Controlador
selecciona una respuestaIncidente. El Controlador
automáticamente en el asignando recursos al
Controlador
incidente (con el caso de uso AsignarRecursos) al
selecciona una respuesta asignando recursos
y da un acuse deel caso al informe de
incidente (con recibo de uso AsignarRecursos)
y da un acuse de recibo al informe de
emergencia enviando un mensaje breve al
BotónInforme Botón usado por el OficialCampo para iniciar el caso de uso
OficialCampo. enviando un mensaje breve al
emergencia
OficialCampo.
Emergencia InformarEmergencia
Estación 5. El OficialCampo recibe el acuse de recibo y la
OficialCampo 5. respuesta seleccionada. el acuse de recibo y la
El OficialCampo recibe
respuesta seleccionada.
Formulario usado para dar los datos de InformarEmergencia. Este
formulario se le presenta al OficialCampo en la
Formulario EstaciónOficialCampo cuando se selecciona la función
Informe InformarEmergencia. El FormularioInformeEmergencia contiene
Emergencia campos para especificar todos los atributos de un informe de
emergencia y un botón (u otro control) para enviar el formulario
cuando está cubierto.
EstaciónOficialCampo Ordenador móvil utilizado por el OficialCampo
Formulario usado para la creación de Incidente. Este formulario se
le presenta al Controlador en la EstaciónControlador cuando se
FormularioIncidente recibe el InformeEmergencia. El Controlador también usa este
formulario para asignar recursos y dar el acuse del recibo al informe
del OficialCampo.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 73 / 125

Identificación de objetos de control
tema 4 – diseño del software
objetos de control
responsables de la coordinación entre objetos de interfaz y
conceptuales
no representan entidades del dominio del problema
se crean al inicio del caso de uso y dejan de existir cuando termina
es responsable de la recopilación de información de los objetos de
interfaz y de enviarla a los objetos de entidad
control del flujo de formularios en un proceso de negocio
control de las colas de “deshacer” e historiales
envío de información en sistemas distribuidos
...
identificación de objetos de control
identificar un objeto de control por caso de uso o más si el caso de uso es
complejo y si puede dividirse en flujos de eventos más cortos
identificar un objeto de control por actor en el caso de uso
la vida de un objeto de control debe ser la del caso de uso o la de la
sesión del usuario
si es difícil de identificar inicio y final de la activación de un objeto de
control puede deberse a que el caso de uso no tiene condiciones de
entrada y salida bien definidas
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 74 / 125

Identificación de objetos de control
tema 4 – diseño del software
Ubicación Descripción del caso de uso
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar
1. Emergencia en su PDA. la función Informar
El OficialCampo activa
Estación
Estación Emergencia en su PDA.
OficialCampo
OficialCampo 2. El sistema COMUNICA responde presentando
2. unEl sistema COMUNICA responde presentando
formulario al OficialCampo. El formulario
incluye un menúal OficialCampo. El formulario
un formulario de tipos de emergencia
(incendio, un menú de tipos de emergencia
incluye accidente, disturbios,...) y campos
(incendio, accidente, disturbios,...) y campos
para introducir la ubicación, descripción del
para introducir la ubicación, descripción del
incidente, petición de recursos,...
incidente, petición de recursos,...
3. El OficialCampo cubre el formulario, y puede
3. El OficialCampo cubre el formulario, y puede
también describir respuestas posibles a la
también describir respuestas posibles a la
situación de emergencia y solicitar recursos
específicos.de emergencia y llenado el
situación Una vez que ha solicitar recursos
específicos. Una vez que ha llenado el
formulario, el OficialCampo lo envía oprimiendo
el formulario, el OficialCampo lo envía oprimiendo
botón “Enviar Informe” y en ese momento se
le el botónal Controlador y en ese momento se
notifica “Enviar Informe”
le notifica al Controlador
4. Al Controlador se le notifica un nuevo informe
4. deAl Controlador se le notifica un de diálogo
incidente mediante un cuadro nuevo informe
Estación
Estación
desplegable. Elmediante un cuadro la diálogo
de incidente Controlador revisa de
Controlador
Controlador
desplegable. El Controlador revisa la
información recibida y crea un Incidente en la
base de datos recibida y al caso de uso
información llamando crea un Incidente en la
AbrirIncidente. Toda la informaciónde uso
base de datos llamando al caso contenida
enAbrirIncidente. Toda la informaciónincluye
el formulario del OficialCampo se contenida
automáticamente en el Incidente. El se incluye
en el formulario del OficialCampo Controlador
selecciona una respuestaIncidente. El Controlador
automáticamente en el asignando recursos al
incidente (con el caso de uso AsignarRecursos) al
selecciona una respuesta asignando recursos
Gestiona la función de informe de InformarEmergencia en la
y da un acuse deel caso al informe de
incidente (con recibo de uso AsignarRecursos)
y da un acuse de recibo al informe de
emergencia enviando un mensaje breve al
EstaciónOficialCampo. Este objeto se crea cuando el OficialCampo
OficialCampo. enviando un mensaje breve al
emergencia
OficialCampo.
Estación
selecciona el botón InformarEmergencia. Luego crea un
Estación 5. El OficialCampo recibe el acuse de recibo y la
OficialCampo
OficialCampo 5. respuesta seleccionada. el acuse de recibo y la
El OficialCampo recibe
FormularioInformeEmergencia y lo presenta al OficialCampo.
respuesta seleccionada.
ControlInformar
Después del envío del formulario crea un InformeEmergencia y se lo
Emergencia
pasa al Controlador. El objeto de control luego espera la llegada de
un acuse de recibo desde la EstaciónControlador. Cuando llega el
acuse de recibo, el objeto ControlInformarEmergencia crea un
MensajeAcuseDeRecibo y la despliega ante el OficialCampo.
Gestiona la función de informe de InformarEmergencia en la
EstaciónControlador. Este objeto se crea cuando se recibe un
InformeEmergencia. Luego crea un FormularioIncidente y lo
ControlAdministrar
despliega ante el Controlador. Una vez que el Controlador ha creado
Emergencia
un Incidente, le ha asignado Recursos y ha enviado un acuse de
recibo, ControlAdministrarEmergencia envía el acuse de recibo a la
EstaciónOficialCampo.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 75 / 125

modelado de interacciones entre objetos
tema 4 – diseño del software
diagramas de interacción
representan el comportamiento del sistema desde la perspectiva de
un solo caso de uso
permiten ver cómo el sistema realiza un caso de uso o un escenario
particular del caso de uso mostrando la distribución de su
comportamiento entre los objetos participantes
dos tipos
diagramas de colaboración
diagramas de secuencia
muestran casi la misma información (se pueden derivar directamente uno
del otro con herramientas CASE)
BotónInformar ControlInformar FormularioInformar
Emergencia Emergencia Emergencia
1: oprimir( )
: OficialCampo
Bot ónInformar 2: crear( )
Emergencia
oprimir( )
crear( )
ControlInformar
: OficialC ampo Emergencia
crear( )
4: cubrirContenido( )
5: enviar( )
6: enviarInforme( )
cubrirContenido( )
3: crear( )
enviar( )
enviarInforme( )
FormularioInformar
Emergencia
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 76 / 125

modelado de interacciones entre objetos
tema 4 – diseño del software
componentes de los diagramas de interacción
objetos
se muestra como un rectángulo (o con un icono en función del
estereotipo utilizado), que se etiqueta con el nombre del objeto y la clase
BotónInformar
a la que pertenece: nombreObjeto:nombreClase
Emergencia : Botón
la clase tiene que figurar en el modelo de clases
puede haber dos o más objetos diferentes de una misma clase
enlaces (en los diagramas de colaboración): los enlaces entre objetos
son instancias de las asociaciones del modelo de clases. Por tanto, si
hay enlace tiene que haber asociación
actores
aparecen los actores involucrados en el caso de uso
tienen que aparecer en el diagrama de casos de uso
puede haber varios actores, pero por lo general hay uno que inicia la
acción
interacciones:
se muestra la secuencia de mensajes que pasan entre los distintos
objetos
aparecen junto a los enlaces e indican la dirección de la navegabilidad
Bot ónInformar 2: crear( )
el objeto destino tiene que “entender” el mensaje, es decir, tiene que
Emergencia
poder proporcionar la operación adecuada
Cont rolInformar
Emergencia
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 77 / 125

modelado de interacciones entre objetos
tema 4 – diseño del software
diagrama de secuencia
los enlaces no aparecen de forma explícita pero están
subyacentes en el intercambio de mensajes
el tiempo pasa según nos movemos de arriba abajo en el
diagrama
reglas para la realización de diagramas de secuencia
primera columna: actor que inicia el caso de uso
segunda columna: objeto de interfaz que usa el actor para
iniciar el caso de uso
tercera columna: objeto de control que gestiona el resto del
caso de uso
los objetos de control son creados por objetos de interfaz que
inician el caso de uso
los objetos de interfaz son creados por objetos de control
los objetos de entidad son accedidos por objetos de control y
de interfaz
los objetos de entidad nunca tienen acceso a los objetos de
frontera o control (pueden utilizarse en distintos casos de uso,
con diferentes objetos de interfaz y de control)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 78 / 125

tema 4 – diseño del software
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 79 / 125

modelado de interacciones entre objetos
tema 4 – diseño del software
Formul arioInfo rmar MensajeAcuse Formulari o Incidente
BotónInformar ControlInformar Informe ControlAdministr AcuseDeRecibo
Emergencia DeRecibo Incidente
Emergencia Emergencia Emergencia arEmergencia
: Controlador
:
OficialCampo
oprimir( )
crear( )
crear( )
cubrirContenido( )
enviar( )
enviarInforme( )
crear( )
enviarInformeAControlador( ) crear( )
ver
crearIncidente( )
crear( )
enviarAcuseDeRecibo( )
crear( )
enviarAcuseDeRecibo( )
i nform eAcu seDe Reci bo( )
crear( )
ver
Al modelar el comportamiento del sistema se descubren los objetos AcuseDeRecibo y MensajeAcuseDeRecibo, lo
que provoca cambios en la descripción del caso de uso InformarEmergencia y en la relación de objetos de entidad y
de interfaz. fuente: Ingeniería del Software Orientado a Objetos, B.Bruegge y A.H. Dutoit, pp. 147-149
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 80 / 125

modelado de interacciones entre objetos
tema 4 – diseño del software
diagrama de colaboración
compuesto por
objetos: puede haber dos o más objetos de una misma clase
enlaces
actores
interacciones
se muestra la secuencia de mensajes que pasa entre los objetos
(interacciones)
Men sajeAc use
DeRecibo Inf orme
Emergencia
7: crear( )
18: v er 17: crear( )
4: cubrirContenido( )
5: env iar( ) 8: env i arIn fo rmeA Contro lador( )
6: env iarInf orme( )
ControlInformar ControlAdministr
Emergencia
FormularioInf ormar arEmergencia
Eme rge nci a
16: inf ormeAcuseDeRecibo( )
3: crear( )
: Of icialCampo
1: oprimir( )
15: env iarAcuseDeRecibo( )
2: crear( ) Incidente 10: ver
9: crear( )
BotónInf ormar : Controlador
12: crear( )
Formulario
Emergencia
Incidente 11: crearIncidente( )
AcuseDeR
13: env iarAcuseDeRecibo( )
ecibo
14: crear( )
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 81 / 125

modelado de interacciones entre objetos
tema 4 – diseño del software
mensajes desde un objeto a sí mismo
socioBiblioteca okTomarPréstamoLibro
socioBiblioteca
okTomarPréstamoLibro
eliminación de comportamiento detallado: utilización de
paquetes
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 82 / 125

modelado de interacciones entre objetos
tema 4 – diseño del software
comportamiento condicional
libro
socioBiblioteca
socioBiblioteca
pedirPréstamo
okTomarPrestado
s i prés tamoPosible = s i
tomarPrestado
si no
préstamoDenegado
...
fin si
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 83 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
Patrones GRASP (General Responsibility Assignment
Software Patterns)
Describen los principios fundamentales del diseño de objetos
y la asignación de responsabilidades, expresados como
patrones
Cinco patrones
Experto en Información
Creador
Alta Cohesión
Bajo Acoplamiento
Controlador
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 84 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
Patrón Experto en información (asignación de
responsabilidades)
Problema: ¿Qué principio general se puede seguir para
asignar responsabilidades a los objetos?
Solución: asignar una responsabilidad al experto en
información, es decir, a la clase que tiene la información
necesaria para realizar la responsabilidad
Localización de clases:
Buscar primero en el Modelo de Diseño, si hay clases
relevantes
Si no hay, buscar en el Modelo de Dominio y utilizar (o
ampliar) las clases para crear las correspondientes clases de
diseño
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 85 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
Ejemplo: en el sistema PDV se necesita conocer el total de una
venta
¿Quién debería ser responsable de conocer el total de una venta?
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 86 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 87 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
Patrón Creador
Problema: ¿Quién es el responsable de crear una nueva
instancia de alguna clase?
Solución: se asignará a la clase B la responsabilidad de crear
una instancia de la clase A si se cumple uno o más de los
casos siguientes:
B agrega objetos de A
B contiene objetos de A
B registra instancias de objetos de A
B tiene datos de inicialización que se pasan a un objeto de A
cuando es creado
La creación de instancias es una de las actividades más
comunes en un sistema orientado a objetos
Buena asignación implica
Bajo acoplamiento
Mayor claridad
Mejor encapsulación y reutilización
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 88 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
Ejemplo: ¿quién debe crear una instancia de LineaDeVenta?
Solución: Venta, pues agrega muchos objetos LineaDeVenta
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 89 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
Patrón Controlador
Problema: ¿Quién controla un evento de entrada al sistema?
Solución: se asignará la responsabilidad de recibir o manejar
un mensaje de evento del sistema a una clase Controlador
de caso de uso
Evento de entrada al sistema: evento generado por un actor
externo
Controlador
objeto que no pertenece a la interfaz de usuario, responsable
de recibir o manejar un evento del sistema
recibe la solicitud de servicio desde la capa de IU y coordina su
realización, normalmente delegando en otros objetos
Ventajas
Mayor potencial de reutilización: la lógica de la aplicación no se
encuentra en la capa de interfaz
“Razonamiento” sobre el estado del caso de uso
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 90 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 91 / 125

diseño de objetos con responsabilidades
tema 4 – diseño del software
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 92 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
identificación de las clases del diseño
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de casos de uso > identificación de clases del diseño
subsistema
clases que participan en la
realización del caso de uso
Diagrama de clases parcial estudiar las clases del
análisis que participan en
la realización del caso de
uso-análisis, identificando
las clases del diseño que
poseen una traza hacia
esas clases del análisis
estudiar requisitos
especiales identificados en
el caso de uso-análisis,
identificando las clases del
diseño que realizan esos
requisitos especiales
identificación de todas las
clases necesarias
diagrama de clases
parcial: muestra las
clases del diseño que
participan en la realización
del caso de uso
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 93 / 125

identificación de las clases del diseño
tema 4 – diseño del software
:Artículo
: : AltaArticulo : F ormularioAltaArt ículo : ValidarArtículo : ProcesarAltaArtículo : MensajeResultado
: A dmi nistra dor
:OpcionesMantenCatálogo
Navegar
Mostrar
<<link>>
Mostrar
Introducir datos artículo Validar artículo
Si datos correctos
Enviar datos
Introducir datos
Alta artículo( )
Si es correcto insertar
Construir
Mostrar
Si no es correcto insertar Construir
Si datos i ncorrectos
Fin Si
Mostrar mensaje error
Fin Si
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 94 / 125

identificación de las clases del diseño
tema 4 – diseño del software
<<link>> AltaArtículo
<<Client Page>>
<<include>>
: OpcionesMantenCatálogo
<<ClientScript Object>>
ValidarArtículo
<<include>>
<<Form>>
FormularioAltaArtículo
<<Client Page>>
MensajeResultado
<<submit>>
<<build>>
<<Server Page>>
ProcesarAlt aA rt ículo
+insertar
Diagrama de clases
Diagrama de clases
parcial Articulo
parcial
(from Logical View)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 95 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
identificación de subsistemas e interfaces
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de casos de uso > identificación de subsistemas e interfaces
subsistema
identificar subsistemas e interfaces
a veces es útil diseñar un caso de uso en
términos de los subsistemas y/o interfaces
que participan en él
pasos
estudiar las clases del análisis que
participan en las correspondientes
realizaciones del caso de uso-análisis,
<<subsistema diseño>> <<subsistema diseño>>
identificando (si existen) los paquetes del
IU Comprador Gestión de solicitudes
análisis que contienen esas clases del
de pago análisis. Después, identificar los
subsistemas del diseño que poseen una
traza hacia esos paquetes del análisis
estudiar los requisitos especiales de las
Solicitud de pago realizaciones de caso de uso-análisis,
identificando las clses del diseño que las
realizan, si existen. Después, identificar
los subsistemas del diseño que contienen
<<subsistema diseño> > <<subsistema diseño> > esas clases.
Gestión de planificación Gestión de facturas mostrar los subsistemas que participan en
de pagos una realización de caso de uso en un
diagrama de clases parcial, mostrando:
las dependencias entre esos subsistemas y
las interfaces que se utilicen en la
realización del caso de uso
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 96 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
requisitos de implementación
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de casos de uso > requisitos de implementación
subsistema
captura de requisitos de implementación
se incluye en la realización del caso de uso todos los
requisitos identificados durante el diseño que deben tenerse
en cuenta durante la implementación, como los no
funcionales
ejemplo de requisito de implementación del caso de uso
Pagar Factura:
Un objeto de la clase Procesamiento de Solicitudes de Pago
debería ser capaz de soportar 10 clientes de Comprador
diferentes sin un retraso perceptible para cada uno de los
compradores
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 97 / 125

diseño de clases
tema 4 – diseño del software
diseño orientado a objetos > diseño de clases
actividades
esbozar la clase del diseño
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
identificar operaciones
Diseño de la
arquitectura
identificar atributos
identificar asociaciones y
agregaciones
Diseñar un Diseñar una
caso de uso clase
identificar generalizaciones
describir los métodos
describir estados
tratar requisitos especiales
Diseñar un
subsistema
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 98 / 125

clase del diseño
tema 4 – diseño del software
diseño orientado a objetos > diseño de clases
clase del diseño: abstracción de una clase o construcción
similar en la implementación del sistema
el lenguaje utilizado para especificar la clase del diseño
puede ser el que se utilizará para su implementación
se suele especificar la visibilidad de los atributos y las
operaciones
los métodos de la clase tienen correspondencia directa con
el correspondiente método en la implementación del código
de las clases
pueden incorporarse estereotipos que hagan corresponder la
<<form>>
clase con una construcción específica del lenguaje de
Pedido
programación (por ejemplo, en VisualBasic, “class module”,
“form”, “user control”,...)
pueden indicarse interfaces si tiene sentido en el lenguaje de
programación (por ejemplo, una clase de diseño que se
implementa como una clase Java)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 99 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
esbozar clases de diseño
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de clases > esbozar la clase del diseño
subsistema
esbozar la clase del diseño
clases de interfaz
depende de la tecnología de interfaz a utilizar. Por ejemplo, clases
diseñadas en Visual Basic implican clases del diseño estereotipadas como
<<forms>> o <<controls>> de ActiveX
en esta fase es esencial utilizar los prototipos de interfaz realizados
anteriormente
clases de entidad con información persistente: su diseño requiere
utilizar tecnologías de bases de datos específicas
adoptar una estrategia para hacer corresponder el modelo de diseño
orientado a objetos con, por ejemplo, tablas en un modelo de datos
relacional
requiere trabajadores específicos (diseñadores de bases de datos),
actividades de diseño de bases de datos y modelos distintos (modelos
entidad-relación, por ejemplo)
clases de control: implica considerar diferentes aspectos
aspectos de distribución (separación de clases en diferentes nodos de una
red, por ejemplo)
aspectos de rendimiento
aspectos de transacción: los diseños deben incorporar cualquier
tecnología de gestión de transacciones existente que se esté utilizando
las clases de diseño identificadas deben ser asignadas trazando
dependencias a las correspondientes clases de análisis que son
diseñadas
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 100 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
identificación de operaciones
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de clases > identificar operaciones
subsistema
identificación de las operaciones que
necesitan las clases de diseño
descripción de las operaciones utilizando la
sintaxis de los lenguajes de programación a
Obj eto de
negocio
utilizar, lo que incluye especificar la
visibilidad de cada operación (por ejemplo,
crea r()
en C++, public, protected, private)
enviar()
plan ifi car()
datos importantes a tener en cuenta en esta
cerrar()
fase
responsabilidades de cualquier clase del
análisis que tenga una traza con la clase del
diseño (una responsabilidad puede implicar
una o varias operaciones)
Factura
requisitos especiales de cualquier clase de
análisis que tenga una traza con la clase del
diseño
interfaces que la clase de diseño necesita
proporcionar
las realizaciones de caso de uso-diseño en las
que la clase participa
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 101 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
identificación de operaciones
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de clases > identificar operaciones
subsistema
Operaciones de la clase Factura
Operaciones de la clase Factura
La clase Factura participa en varias realizaciones de casos de uso,
La clase Factura participa en varias realizaciones de casos de uso,
como aquellas de Pagar Factura, Enviar Aviso yy Enviar Factura al
como aquellas de Pagar Factura, Enviar Aviso Enviar Factura al
Comprador. Cada una de estas realizaciones leen oo cambian ele
Comprador. Cada una de estas realizaciones leen cambian ele
Obj eto de
stado de los objetos Factura. El caso de uso Enviar Factura al
negocio stado de los objetos Factura. El caso de uso Enviar Factura al
Comprador crea yy envía facturas. El caso de uso Pagar Factura
Comprador crea envía facturas. El caso de uso Pagar Factura
planifica Facturas, yy así todos. Cada una de estas realizaciones de
planifica Facturas, así todos. Cada una de estas realizaciones de
crea r() casos de uso, por tanto, utiliza objetos Facutra de forma diferente;
casos de uso, por tanto, utiliza objetos Facutra de forma diferente;
enviar() en otras palabras, la clase Factura yy sus objetos desempeñan
en otras palabras, la clase Factura sus objetos desempeñan
plan ifi car() distintos papeles en estas realizaciones de casos de uso.
distintos papeles en estas realizaciones de casos de uso.
cerrar()
Primero, los ingenieros de componentes pensaron en implementar
Primero, los ingenieros de componentes pensaron en implementar
estos cambios de estado como una operación llamada setStatus,
estos cambios de estado como una operación llamada setStatus,
que tenía un parámetro que indicaba la acción deseada yy el estado
que tenía un parámetro que indicaba la acción deseada el estado
destino (por ejemplo, setStatus(Planificada)). Pero entonces
destino (por ejemplo, setStatus(Planificada)). Pero entonces
decidieron que era preferible implementar operaciones explícitas
decidieron que era preferible implementar operaciones explícitas
para cada transición de estados. Es más, decidieron utilizar este
Factura para cada transición de estados. Es más, decidieron utilizar este
enfoque no sólo para la clase Factura, sino también para la clase
enfoque no sólo para la clase Factura, sino también para la clase
Objeto de Negocio, de la cual es un subtipo la clase Factura. La
Objeto de Negocio, de la cual es un subtipo la clase Factura. La
clase Objeto de Negocio soporta de esta forma las siguientes
clase Objeto de Negocio soporta de esta forma las siguientes
operaciones (cada una de las cuales cambia el estado de Objeto de
operaciones (cada una de las cuales cambia el estado de Objeto de
Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estas
Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estas
operaciones son solamente operaciones virtuales que definen un
operaciones son solamente operaciones virtuales que definen un
patrón. Las clases que son subtipos de la clase Objeto de Negocio
patrón. Las clases que son subtipos de la clase Objeto de Negocio
tienen que definir cada una un método concreto que realice estas
tienen que definir cada una un método concreto que realice estas
operaciones.
operaciones.
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 102 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
identificación de atributos
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de clases > identificar atributos
subsistema
identificación de atributos
utilizar la sintaxis del lenguaje de programación
considerar los atributos de cualquier clase de análisis que tenga una
traza con la clase de diseño (a veces implican más de un atributo en
la clase de diseño)
los tipos de atributos están restringidos por el lenguaje de
programación
una instancia única de atributo no puede ser compartida por varios
objetos de diseño. Si fuera necesario, el atributo necesita ser definido
en una clase separada
si hay muchos atributos o son complejos los atributos de una clase se
puede ilustrar ésta en un diagrama de clases separado que muestre
solamente el apartado de atributos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 103 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
asociaciones, agregaciones y generalizaciones
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de clases > identificar asociaciones y agregaciones
subsistema
identificación de asociaciones y agregaciones
estudiar la transmisión de mensajes en los
diagramas de secuencia para determinar qué
asociaciones son necesarias
el número de relaciones debe estar minimizado,
dando respuesta a las demandas de varias
realizaciones de casos de uso
en ocasiones hay que modelar rutas de búsqueda
óptimas a través de asociaciones y agregaciones
para gestionar aspectos de rendimiento
refinar la multiplicidad, nombres de rol,... según
el soporte del lenguaje de programación utilizado
identificación de generalizaciones
Objeto de negocio
deben ser utilizadas con la misma semántica
definida en el lenguaje de programación
si el lenguaje no admite herencia, las
asociaciones y/o agregaciones deben utilizarse en
vez de la generalización
Factura Pedido
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 104 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
métodos y estados
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de clases > descripción de métodos y estados
subsistema
descripción de los métodos
pueden especificarse algoritmos que se van a
creada
utilizar para realizar una operación, en
seudocódeigo o lenguaje natural
enviar()
la mayoría de los métodos no se especifican
durante el diseño
pendiente
descripción de estados
planificar
algunos objetos del diseño son estados
controlados, es decir, sus estados determinan su
planificada
comportamiento cuando reciben un mensaje
[fuera de plaz o:
cerrar()
se utilizan diagramas de estado para describir las
retraso en fecha de
transiciones de estado de un objeto
pago]
vencida y Los objetos Factura cambian de estado según sean creados, enviados,
Los objetos Factura cambian de estado según sean creados, enviados,
no pagada planificados o cerrados. Como todos los objetos de negocio, estos estados
planificados o cerrados. Como todos los objetos de negocio, estos estados
cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede
cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede
ser planificada antes de haber sido enviada.
cerrar() ser planificada antes de haber sido enviada.
Una factura se crea cuando un vendedor quiere que un comprador pague un
Una factura se crea cuando un vendedor quiere que un comprador pague un
cerrada
pedido. Entonces la factura es enviada al comprador, y el estado cambia a
pedido. Entonces la factura es enviada al comprador, y el estado cambia a
pendiente. Cuando elcomprador decide pagar, el etado de la factur a pasa a
pendiente. Cuando elcomprador decide pagar, el etado de la factur a pasa a
planificada. Entonces, si el comprador no paga a tiempo, el estado de la factura
planificada. Entonces, si el comprador no paga a tiempo, el estado de la factura
pasa a vencida y no pagada. Finalmente, cuandola factura se ha pagado, el
pasa a vencida y no pagada. Finalmente, cuandola factura se ha pagado, el
estado pasa a cerrada.
estado pasa a cerrada.
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 105 / 125

Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
arquitectura
requisitos especiales
Diseñar un Diseñar una
caso de uso clase
tema 4 – diseño del software
Diseñar un
diseño orientado a objetos > diseño de clases > requisitos especiales
subsistema
requisitos especiales
estudiar los requisitos formulados en la realización de los casos de
uso en los que la clase participa
estudiar los requisitos especiales de cualquier clase de análisis que
tenga una traza con la clase de diseño
algunos requisitos se posponen hasta la implementación (requisitos
de implementación)
Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el
UnicastRemoteObject Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el
Servidor del Comprador yy desde el Servidor del Vendedor. La Factura tiene que
Servidor del Comprador desde el Servidor del Vendedor. La Factura tiene que
ser diseñada, pues, para un sistema dsitribuido. En este ejemplo se
ser diseñada, pues, para un sistema dsitribuido. En este ejemplo se
implementa esta distribución de objetos haciendo la clase Factura una subclase
implementa esta distribución de objetos haciendo la clase Factura una subclase
de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la
de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la
Invocación de Mensajes Remotos (RMI). Este mecanismo de diseño está
Invocación de Mensajes Remotos (RMI). Este mecanismo de diseño está
identificado yy descrito por el arquitecto en la actividad de diseño arquitectónico.
identificado descrito por el arquitecto en la actividad de diseño arquitectónico.
Factura
Ejemplo requisito de implementación:
Ejemplo requisito de implementación:
Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz
Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz
de gestionar 10 clientes de Comprador diferentes sin un retardo
de gestionar 10 clientes de Comprador diferentes sin un retardo
perceptible para los compradores.
perceptible para los compradores.
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 106 / 125

Diseño de un subsistema
tema 4 – diseño del software
actividades
definición de las dependencias
entre subsistemas
Arquitecto Ingeniero de casos de uso Ingeniero de componentes
Diseño de la
definición de las interfaces
arquitectura
proporcionadas por el
subsistema
refinar los contenidos de los
Diseñar un Diseñar una
caso de uso clase
subsistemas
Diseñar un
subsistema
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 107 / 125

el diseño estructurado
tema 4 – diseño del software
Los modelos del análisis facilitan la información
necesaria para crear los modelos del diseño
Descripción procedimental
Descripción procedimental
de los componentes del
de los componentes del
software
software
Es
es pe
ad ci f
id
t i ca
en ci ó
de n
n de
ció
rip pr
sc oc
Diagrama
De Diagrama es
Entidad- os Cómo se comunica el
de Flujo de
Cómo se comunica el
Relación
Diseño sistema consigo mismo,
Datos
sistema consigo mismo,
con otros sistemas y con
procedimental
DICCIONARIO
con otros sistemas y con
DE DATOS los operadores
los operadores
Diseño de
Diagrama de
interfaz
Transición de Estados
Relación entre los
Relación entre los
principales elementos
Diseño principales elementos
estructurales del programa
arquitectónico
Especificación de control
estructurales del programa
MODELOS DEL ANÁLISIS
MODELOS DEL ANÁLISIS
Diseño de
datos
Estructuras de datos
Estructuras de datos
MODELOS DEL DISEÑO necesarias para
MODELOS DEL DISEÑO necesarias para
implementar el software
implementar el software
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 108 / 125

conceptos del diseño estructurado
tema 4 – diseño del software
diseño estructurado > conceptos
jerarquía de control
Organización de los módulos de un sistema.
Jerarquía de control.
No se representan necesariamente aspectos procedimentales
Notación: diagrama estructurado (Constantine)
Profundidad: indica el número de niveles de control
Anchura: indica el ámbito global de control
Grado de salida: número de módulos controlados
directamente por otro módulo.
Grado de entrada: número de módulos que controlan
directamente a un módulo determinado.
Visibilidad: conjunto de componentes que pueden invocarse
o cuyos datos pueden ser usados por un componente dado,
incluso aunque se haga indirectamente.
Conectividad: conjunto de componentes que son invocados
directamente o cuyos datos son usados por un componente
determinado.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 109 / 125

Conceptos del diseño estructurado
tema 4 – diseño del software
diseño estructurado > conceptos
M
grado de
salida
a b c
d e k l m
profundidad
f g h n o p q
grado de
entrada
i j r
Anchura
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 110 / 125

conceptos del diseño estructurado
tema 4 – diseño del software
diseño estructurado > conceptos
PARTICIÓN ESTRUCTURAL
PARTICIÓN ESTRUCTURAL
función 1 función 3
Partición horizontal:
Partición horizontal:
ramas separadas para cada función
ramas separadas para cada función
principal.
principal.
Beneficios: facilidad de prueba yy
Beneficios: facilidad de prueba
mejora, mantenimiento, menos efectos
mejora, mantenimiento, menos efectos
secundarios.
secundarios.
Desventajas: mayor flujo de datos y
Desventajas: mayor flujo de datos y
control global del flujo del programa más
control global del flujo del programa más
función 2
complicado.
complicado.
Partición vertical (factoring): control y trabajo
Partición vertical (factoring): control y trabajo partición horizontal
distribuidos de manera descendiente en la
distribuidos de manera descendiente en la
arquitectura del programa. módulos de toma
arquitectura del programa.
Módulos de nivel superior: control yy
Módulos de nivel superior: control de decisiones
poco procesamiento.
poco procesamiento.
Módulos de nivel inferior:
Módulos de nivel inferior:
procesamiento (entradas, cálculos y
procesamiento (entradas, cálculos y
salida)
salida)
Mejor capacidad de mantenimiento.
Mejor capacidad de mantenimiento.
Cambios en módulos de control: más
Cambios en módulos de control: más
probabilidad de propagar efectos
probabilidad de propagar efectos
secundarios, pero son menos habituales. módulos
secundarios, pero son menos habituales.
“de trabajo”
Cambios en módulos de trabajo: partición vertical
Cambios en módulos de trabajo:
habituales, pero con poca probabilidad de
habituales, pero con poca probabilidad de
propagar efectos secundarios.
propagar efectos secundarios.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 111 / 125

conceptos del diseño estructurado
tema 4 – diseño del software
diseño estructurado > conceptos
ACOPLAMIIENTO
INDEPENDENCIA FUNCIONAL
INDEPENDENCIA FUNCIONAL Medida de la interdependencia relativa entre los módulos, y depende de
la interfaz entre éstos, es decir, de la cantidad y tipo de datos que
• • Consecuencia de la modularidad, la
Consecuencia de la modularidad, la comparten.
abstracción yy la ocultación de la información
abstracción la ocultación de la información
• • Módulos con “función única” y poca Objetivo durante el diseño: minimizar el acoplamiento utilizando
Módulos con “función única” y poca
interacción con otros conexiones sencillas entre los módulos.
interacción con otros
• Más fáciles de mantener y probar
• Más fáciles de mantener y probar Formas de reducir el acoplamiento:
• • Menos efectos secundarios por
Menos efectos secundarios por • Eliminando relaciones innecesarias
modificaciones
modificaciones • Reduciendo las relaciones necesarias
• • Reducida propagación de errores
Reducida propagación de errores
• Facilita la reutilización Beneficios de un bajo acoplamiento:
• Facilita la reutilización
• Menor transmisión de defectos (efectos secundarios)
• Posibilidad de cambiar un módulo sin incidir sobre otros
• En el mantenimiento de un módulo no hay que tener en cuenta el
contenido de otros
COHESIÓN
Medida del grado de “fuerza funcional” de un módulo: cuanto menor
sea el número de tareas (elementos de procesamiento) que realiza
un módulo, mayor será su cohesión. Maximizar la cohesión es
Maximizar la cohesión es
Diferentes grados de cohesión: casi lo mismo que
casi lo mismo que
minimizar el acoplamiento
CONCEPTOS minimizar el acoplamiento
CONCEPTOS
MÓDULO CON DIVERSAS COMPLEMENTARIOS
MÓDULO CON COMPLEMENTARIOS
TAREAS POCO O NADA
TAREA SIMPLE
RELACIONADAS
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 112 / 125

acoplamiento en el diseño estructurado
tema 4 – diseño del software
diseño estructurado > conceptos
-
ACOPLAMIENTO NORMAL
ACOPLAMIENTO NORMAL
De datos: dos módulos se comunican por parámetros, siendo cada parámetro una
De datos: dos módulos se comunican por parámetros, siendo cada parámetro una
porción elemental de datos.
porción elemental de datos.
Evitar datos que circulen sin necesidad.
Evitar datos que circulen sin necesidad.
Fomentar conexiones formadas por pocos datos.
Fomentar conexiones formadas por pocos datos.
Compuesto: un módulo pasa al otro un dato compuesto.
Compuesto: un módulo pasa al otro un dato compuesto.
Introduce una cierta conexión indirecta (Diccionario de Datos)
Introduce una cierta conexión indirecta (Diccionario de Datos)
Evitar datos compuestos con subdatos innecesarios.
Evitar datos compuestos con subdatos innecesarios.
Evitar agrupamientos de datos que no tienen nada en común.
Evitar agrupamientos de datos que no tienen nada en común.
De control: un módulo pasa a otro información de control destinada a controlar la
De control: un módulo pasa a otro información de control destinada a controlar la
lógica interna del segundo.
lógica interna del segundo.
Grado de acoplamiento
ACOPLAMIENTO
ACOPLAMIENTO
ACOPLAMIENTO COMÚN
ACOPLAMIENTO COMÚN
TIPOS DE
TIPOS DE
Dos módulos hacen referencia a una misma área de datos globales. No es recomendable
Dos módulos hacen referencia a una misma área de datos globales. No es recomendable
por:
por:
Posibilidad de que los errores se trasladen de unos módulos a otros.
Posibilidad de que los errores se trasladen de unos módulos a otros.
Baja flexibilidad modular
Baja flexibilidad modular
Complica el mantenimiento
Complica el mantenimiento
Diferentes significados de los datos según el módulo que lo utilice
Diferentes significados de los datos según el módulo que lo utilice
Si se cambia un módulo es difícil identificar los datos que hay que cambiar.
Si se cambia un módulo es difícil identificar los datos que hay que cambiar.
Excepción: BASES DE DATOS (no son volátiles, son diseñadas con disciplinas
Excepción: BASES DE DATOS (no son volátiles, son diseñadas con disciplinas
específicas y las conexiones son restringidas y controladas, no aleatorias).
específicas y las conexiones son restringidas y controladas, no aleatorias).
ACOPLAMIENTO DE CONTENIDO
ACOPLAMIENTO DE CONTENIDO
Existe cuando un módulo se refiere de algún modo al contenido de otro. Es más habitual
Existe cuando un módulo se refiere de algún modo al contenido de otro. Es más habitual
en lenguajes de bajo nivel.
en lenguajes de bajo nivel.
+
Hay que evitarlo pues ataca al concepto de caja negra.
Hay que evitarlo pues ataca al concepto de caja negra.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 113 / 125

cohesión en el diseño estructurado
tema 4 – diseño del software
diseño estructurado > conceptos
Principio asociativo: los
Principio asociativo: los
elementos de procesamiento o tareas
elementos de procesamiento o tareas módulo
se agrupan en base a algún tipo de
se agrupan en base a algún tipo de Tarea o elemento de
pertenencia entre ellos.
pertenencia entre ellos. procesamiento:
La cohesión se aplica sobre todos los
La cohesión se aplica sobre todos los órdenes en el
pares de tareas
pares de tareas módulo y procesos
que resultan de
llamadas a módulos
subordinados
Cohesión funcional: sus elementos contribuyen a la
resolución de una y sólo una tarea.
+
Cohesión secuencial: los datos de salida de una tarea
sirven como datos de entrada para el siguiente
elemento.
Cohesión comunicacional: todos sus elementos operan
sobre los mismos conjuntos de entrada y/o producen los
Grado de cohesión
mismos datos de salida.
Cohesión procedural: las tareas efectúan diferentes (y
seguramente no relacionadas) actividades y se efectúan
en un orden determinado.
Cohesión temporal: sus elementos desarrollan
actividades que se relacionan en el tiempo.
Las tareas que se encuentran
Cohesión lógica: las tareas desarrollan actividades de la
dentro de un módulo
misma clase, pero para utilizar el módulo hay que
subordinado no figuran en la
seleccionar la/s actividades que se necesitan
cohesión del módulo que lo
-
Cohesión casual: las tareas no tienen relación invoca
significativa entre ellas
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 114 / 125

Diseño
procedimental
el diseño de datos
Diseño de interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño de datos
Diseño de datos
Diseño de datos:
Profunda influencia en la calidad del software:
Influye en la estructura del programa
Influye en la complejidad procedimental
Fundamentos: ocultación de información y abstracción de datos
Actividades:
escoger estructuras de datos para los datos identificados en el análisis.
Identificar los módulos del programa que deben operar directamente
sobre las estructuras de datos
Principios del diseño de datos
1) Estudiar alternativas de estructuras de datos
2) Especificar las operaciones a llevar a cabo sobre los datos
3) Utilización del Diccionario de Datos
4) Retrasar las decisiones de bajo nivel
5) Representación de los datos conocida sólo por los módulos que
hacen uso directo de los datos en la estructura
6) Crear bibliotecas de estructuras de datos
7) Soporte del lenguaje para los tipos abstractos de datos
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 115 / 125

Diseño
procedimental
el diseño arquitectónico
Diseño de interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño arquitectónico
Diseño de datos
En cierta forma, el diseño arquitectónico
desarrolla los “planos” del programa
Objetivos:
Desarrollar una estructura de programa modular
Representar las relaciones de control entre los módulos
Combina la estructura del programa y la de datos,
definiendo interfaces que permiten el flujo de datos a través
del programa
Diversos métodos de diseño arquitectónico
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 116 / 125

Diseño
procedimental
el diseño arquitectónico
Diseño de interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño arquitectónico
Diseño de datos
Factura_Proveedor
Confirmación_Pedido Producto_Stock
Pago_Cliente
Petición_Comprobación_Crédito
Pedido Cliente
1 3 Pedido_Proveedor
RECIBIR GESTIONAR
Detalles_Crédito Stock
PEDIDO STOCK
Pago_Proveedor
Cliente
Dirección_Envío
Clientes
Producto_Devuelto
Detalles_Pedido 2 Factura_Cliente
ENVIAR
PEDIDO
Envío_Cliente
Detalles_Pedido Productos Devueltos
Número_Empleado
Producto_Devuelto
Dirección_Factura
Cliente
Representante Ventas
4
RECIBIR Reintegro_Cliente
DISEÑO ORIENTADO
DEVOLUCIONES
Nombre_Empleado_y_Supervisor
DISEÑO ORIENTADO
5 Project Name: Sample Yourdon process model
AL FLUJO DE DATOS
GENERAR Project Path: c:ecwinsamplesyddfd
Políticas_Ventas_ Informe_Ventas
INFORMES Chart File: dfd0.dfd
y_Cuotas Devolución_Cliente
AL FLUJO DE DATOS
VENTAS Chart Name: Process Orders
Created On: Feb-18-1993
Created By: Wayne McDonald
Modified On: Dec-12-1993
Modified By: EasyCASE
DESCRIPCIÓN ESTRUCTURADA
FLUJO INFORMACIÓN
(Diagramas de estructura)
(DFD)
TIPOS DE FLUJOS:
TIPOS DE FLUJOS:
1) De Transformación:
1) De Transformación:
a) La información entra en el sistema a lo largo de caminos que transforman los datos
a) La información entra en el sistema a lo largo de caminos que transforman los datos
externos a un formato interno: flujo de entrada
externos a un formato interno: flujo de entrada
b) Esta información pasa a través de un centro de transformación
b) Esta información pasa a través de un centro de transformación
c) Los datos pasan por uno o más caminos que conducen hacia “fuera” del software:flujo de
c) Los datos pasan por uno o más caminos que conducen hacia “fuera” del software:flujo de
salida.
salida.
2) De Transacción: datos que se mueven a lo largo de un camino de entrada que convierte la
2) De Transacción: datos que se mueven a lo largo de un camino de entrada que convierte la
información exterior en una transacción. Ésta se evalúa y, basándose en ese valor, se inicia el flujo a
información exterior en una transacción. Ésta se evalúa y, basándose en ese valor, se inicia el flujo a
lo largo de uno de muchos caminos posibles de acción. El proceso del que parten los caminos de
lo largo de uno de muchos caminos posibles de acción. El proceso del que parten los caminos de
acción se llama centro de transacción.
acción se llama centro de transacción.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 117 / 125

Diseño
procedimental
el diseño arquitectónico
Diseño de interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño arquitectónico
Diseño de datos
Análisis de transformación
Revisar el modelo
Revisar y refinar los DFDs
Determinar las características de los DFDs
Aislar el centro de transformación
Descomposición inicial: establecer un “controlador principal” y otros
controladores subordinados para entradas, transformaciones y salidas.
Descomposición de 2º nivel: convertir los procesos del DFD en los módulos
correspondientes de la estructura del programa. Se pueden convertir varios
procesos en un módulo, un proceso en varios módulos,...
Refinar (aplicar directrices de diseño)
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 118 / 125

Diseño
procedimental
el diseño arquitectónico
Diseño de interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño arquitectónico
Diseño de datos
Análisis de transacción
Revisar el modelo
Revisar y refinar los DFDs
Determinar las características de los DFDs
Identificar el centro de transacción y las características del flujo de cada camino
Descomponer y refinar la estructura y las ramas: el flujo de transacción se
convierte en una estructura de programa que contiene una rama de entrada y
una rama de distribución. Ésta contiene un módulo distribuidor que controla
todos los módulos de acción subordinados. Cada flujo de acción se convierte en
una estructura según sus características.
Refinar (aplicar directrices de diseño)
Transacción
Centro de
transacción
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 119 / 125

Diseño
procedimental
el diseño arquitectónico
Diseño de interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño arquitectónico
Diseño de datos
Optimización:
Representación que satisfaga los requisitos FUNCIONALES y de
RENDIMIENTO
Simplicidad
Aplicaciones de rendimiento crítico (entre el 10-20% del software
ocupa el 50-80% del tiempo de procesamiento):
Diseñar y refinar sin ocuparse del rendimiento
Simular el rendimiento en tiempo de ejecución
Seleccionar los módulos que ocupen demasiado tiempo y rediseñarlos
Codificar
Aislar, rediseñar o recodificar para mejorar la eficiencia
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 120 / 125

Diseño
procedimental
el diseño de interfaz
Diseño de
interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño de interfaz
Diseño de datos
Tres áreas principales:
Diseño de interfaces entre los módulos software (interfaz
interna): depende de los datos que deben fluir entre los
módulos y las características del lenguaje de programación.
Diseño de interfaces entre el software y sistemas externos
(interfaz externa): se evalúa cada entidad externa,
determinando requisitos de datos y control de la misma, y
se diseñan las interfaces externas adecuadas.
Diseño de interfaces hombre-máquina
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 121 / 125

Diseño
procedimental
el diseño de interfaz
Diseño de
interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño de interfaz
Diseño de datos
MODELO DE DISEÑO:
Representaciones de MODELO DE USUARIO:
datos, arquitectónicas, Perfil de los usuarios
de interfaces y finales del sistema (edad,
procedimentales. El Diseñador de capacidades físicas,
diseño de interfaz suele interfaces estudios, nivel cultural,
ser secundario con motivación,...). Pueden
respecto a éste, excepto ser usuarios novatos,
en sistemas altamente esporádicos o frecuentes.
interactivos.
PERCEPCIÓN DEL IMAGEN DEL
SISTEMA: SISTEMA:
imagen del sistema Combinación del
que percibe el aspecto externo del
usuario final. La sistema con toda la
exactitud de su información de
descripción soporte que describen
dependerá de su sintaxis y semántica
perfil. del sistema.
Cuando coinciden, los usuarios se
Cuando coinciden, los usuarios se
sienten aa gusto con el software y lo
sienten gusto con el software y lo
utilizan eficazmente.
utilizan eficazmente.
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 122 / 125

Diseño
procedimental
el diseño de interfaz
Diseño de
interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño de interfaz
Diseño de datos
aspectos del diseño de interfaz persona-máquina
tiempo de respuesta
duración
variabilidad
mensajes de error
descripción del problema
información constructiva.
consecuencias negativas posibles
señal audible o visible
evitar juicios al usuario
etiquetado de órdenes
poco habituales en entornos visuales
órdenes para todas las opciones
formato de las órdenes
facilidad de aprendizaje y de recordar
macros de órdenes
convenios para uso en diferentes aplicaciones
ayuda al usuario
integrada
agregada
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 123 / 125

Diseño
procedimental
el diseño de interfaz
Diseño de
interfaz
Diseño arquitectónico
tema 4 – diseño del software
diseño estructurado > diseño de interfaz
Diseño de datos
DIRECTRICES ENTRADA DE DATOS
DIRECTRICES ENTRADA DE DATOS
DIRECTRICES PARA EL DISEÑO Minimizar número acciones entrada: reducir la
DIRECTRICES PARA EL DISEÑO Minimizar número acciones entrada: reducir la
DE INTERFACES HOMBRE - - cantidad de escritura necesaria, usando el
DE INTERFACES HOMBRE cantidad de escritura necesaria, usando el
MÁQUINA ratón, macros,...
MÁQUINA ratón, macros,...
Consistencia visualización-introducción
Consistencia visualización-introducción
Personalizar entrada: órdenes personalizadas,
Personalizar entrada: órdenes personalizadas,
eliminar mensajes de advertencia yy
eliminar mensajes de advertencia
verificación,...
verificación,...
Interacción personalizada: por ejemplo, escoger
Interacción personalizada: por ejemplo, escoger
teclado oo ratón.
teclado ratón.
Desactivar órdenes inapropiadas
Desactivar órdenes inapropiadas
Eliminar entradas innecesarias: .00 en
Eliminar entradas innecesarias: .00 en
cantidades enteras, información disponible
cantidades enteras, información disponible
automáticamente oo que se puede calcular,...
automáticamente que se puede calcular,...
DIRECTRICES VISUALIZACIÓN
DIRECTRICES VISUALIZACIÓN
DIRECTRICES INTERACCIÓN
Información relevante en el contexto actual DIRECTRICES INTERACCIÓN
Información relevante en el contexto actual
No abrumar con datos: usar gráficos yy
No abrumar con datos: usar gráficos
Consistencia de formato
esquemas Consistencia de formato
esquemas
Respuestas significativas
Mantener contexto visual Respuestas significativas
Mantener contexto visual
Verificación de acciones destructivas
Etiquetas consistentes, abreviaciones Verificación de acciones destructivas
Etiquetas consistentes, abreviaciones
Deshacer acciones
estándar yy colores predecibles
estándar colores predecibles Deshacer acciones
Eficiencia diálogo: distancia que debe moverse el ratón,...
Mensajes de error significativos Eficiencia diálogo: distancia que debe moverse el ratón,...
Mensajes de error significativos
Autoprotección del sistema ante errores
Uso de ventanas Autoprotección del sistema ante errores
Uso de ventanas
Cohesión órdenes yy acciones: organización de órdenes por tipo
Cohesión órdenes acciones:
organización de órdenes por tipo
Presentaciones analógicas
Presentaciones analógicas
Ayudas sensibles al contexto
Geografía de la pantalla Ayudas sensibles al contexto
Geografía de la pantalla
Verbos yy frases sencillos para las órdenes
Verbos frases sencillos para las órdenes
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 124 / 125

bibliografía
tema 4 – diseño del software
C. Larman: UML y Patrones. Capítulos 15 y 16
Jacobson, Booch, Rumbaugh: El Proceso Unificado de Desarrollo de
Software. Capítulo 9
I. Sommerville: Ingeniería del Software, Capítulos 11, 12, 13 y 14
escuela superior de ingeniería informática
© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 125 / 125