Upload
edmundo-alvarez-ceballos
View
253
Download
0
Embed Size (px)
Citation preview
tema 4 – diseño del software
enrique barreirodepartamento de informática
universidade de vigo
escuela superior de ingeniería informáticaingeniería del software de gestión
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
2 / 125
introducción y objetivos del diseño
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 proyectose descompone el sistema en subsistemas más pequeños que pueden ser realizados por diferentes equiposse seleccionan estrategias para la construcción del sistema
plataforma de hardware y software en la que se ejecutaráel sistemaestrategia de almacenamiento de datos persistentesarquitectura estructural del sistemaflujo de control globalpolítica de control de accesocondiciones de interfaz...
resultado del diseño: modelo de diseñodescripción clara de las estrategiasdescomposición en subsistemasdiagramas que muestran la correspondencia entre hardware y softwaremodelo de objetos que describe la realización física de los casos de usomuestra el impacto en el sistema de requisitos funcionales, no funcionales y restriccionessirve de abstracción de la implementación del sistema, convirtiéndose en el input fundamental de las actividades de implementación
Ingeniería derequerimientos
Análisis
Modelo de casosde uso
:Modelo
Modelo deanálisis:Modelo
Diseño
Modelo dediseño
:Modelo
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
3 / 125
evolución del diseño de software
proceso continuo durante tres décadascriterios 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
4 / 125
calidad y diseño del software
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)
El principio de la sabiduría de un ingeniero del software es reconocer la diferencia entre conseguir que funcione un programa, y hacerlo bien.
M.A. Jackson, 1975
El principio de la sabiduría de un ingeniero del software es reconocer la diferencia entre conseguir que funcione un programa, y hacerlo bien.
M.A. Jackson, 1975
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
5 / 125
calidad y diseño del software
Sin diseño de calidad:Dificultades de gestión (el “destino cósmico” de los proyectos)
Sistemas poco satisfactorios e improductivos45% 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 mantenimientoEl mantenimiento es caro:
1) Entender cómo funciona el sistema (o por qué no funciona)2) Diseñar la modificación3) Verificar el impacto4) Realizar la modificación5) Probar el sistema modificado6) Planificar, organizar, coordinar, medir y documentar estas
actividades
Los tres primeros casos se agravan con un mal diseñoLos tres primeros casos se
agravan con un mal diseño
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
6 / 125
conceptos esenciales del diseño
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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
7 / 125
ABSTRACCIÓN
- Procedimental- De datos- De control
ABSTRACCIÓN
- Procedimental- De datos- De control
REFINAMIENTO
La arquitectura de un programa se desarrolla refinando sucesivamente niveles de detalle procedimental. Se desarrolla una jerarquía descomponiendo una abstracción procedimental para, paso a paso, llegar a los enunciados del lenguaje de programación
REFINAMIENTO
La arquitectura de un programa se desarrolla refinando sucesivamente niveles de detalle procedimental. Se desarrolla una jerarquía descomponiendo una abstracción procedimental para, paso a paso, llegar a los enunciados del lenguaje de programación
- Requisitos familiares en el ámbito del problema
- Diseño arquitectónico
- Diseño procedimental
- Código
nive
les
deab
stra
cció
n
Conceptos complementarios
La abstracción permite especificar procedimientos y datos suprimiendo detalles de bajo nivel.El refinamiento ayuda a revelar detalles de bajo nivel a medida que progresa el diseño.
La abstracción permite especificar procedimientos y datos suprimiendo detalles de bajo nivel.El refinamiento ayuda a revelar detalles de bajo nivel a medida que progresa el diseño.
conceptos esenciales del diseño
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
8 / 125
conceptos esenciales del diseño
MODULARIDAD
- Componentes identificables y tratables por separado- Permite a un programa ser manejable intelectualmente- Criterios que permiten evaluar un método de diseño con respecto a su capacidad de definir un sistema modular eficaz:
Capacidad de descomposición modular
Capacidad de empleo de componentes modulares (reutilización)
Capacidad de comprensión modular (entender un módulo sin referencias a otros, o con las menos posibles)
Continuidad modular (cambios en módulos y con poco impacto)
Protección modular
MODULARIDAD
- Componentes identificables y tratables por separado- Permite a un programa ser manejable intelectualmente- Criterios que permiten evaluar un método de diseño con respecto a su capacidad de definir un sistema modular eficaz:
Capacidad de descomposición modular
Capacidad de empleo de componentes modulares (reutilización)
Capacidad de comprensión modular (entender un módulo sin referencias a otros, o con las menos posibles)
Continuidad modular (cambios en módulos y con poco impacto)
Protección modular
Número de módulos
M
Cos
tes
o es
fuer
zo
Costes totalesdel software
Coste/módulo
Coste deintegración
Región decostesmínimos
Fuente: Ingeniería del Software. Un enfoque práctico. R. S. Pressman
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
9 / 125
INDEPENDENCIA FUNCIONAL
• Consecuencia de la aplicación de conceptos como la modularidad, la abstracción y la ocultación de la información• Componentes con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización
INDEPENDENCIA FUNCIONAL
• Consecuencia de la aplicación de conceptos como la modularidad, la abstracción y la ocultación de la información• Componentes con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización
COHESIÓN
Medida del grado de “fuerza funcional” de un componente: cuanto menor sea el número de tareas (elementos de procesamiento) que realiza un componente, mayor será su cohesión.Diferentes grados de cohesión:
COMPONENTE CONTAREA SIMPLE
COMPONENTE CON DIVERSASTAREAS POCO O NADARELACIONADAS
ACOPLAMIENTO
Medida de la interdependencia relativa entre componentes, y depende de la interfaz entre éstos, es decir, de la cantidad y tipo de datos que comparten.
Objetivo durante el diseño: minimizar el acoplamiento utilizando conexiones sencillas entre los módulos.
Formas de reducir el acoplamiento:• Eliminando relaciones innecesarias• Reduciendo las relaciones necesarias
Beneficios de un bajo acoplamiento:• Menor transmisión de defectos (efectos secundarios)• Posibilidad de cambiar un componente (clase, subsistema, módulo,...) sin incidir sobre otros• En el mantenimiento de un componente no hay que tener en cuenta el contenido de otros
conceptos esenciales del diseño
Conceptos complementariosMaximizar la cohesión es casi lo mismo que minimizar el acoplamiento
Conceptos complementariosMaximizar la cohesión es casi lo mismo que minimizar el acoplamiento
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
10 / 125
proceso del diseño
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
11 / 125
proceso del diseño
Diseño arquitectónicoIdentificación y documentación de los subsistemas que forman el sistema y sus relaciones
Especificación abstractaEspecificación de servicios y restricciones bajo los que funcionará cada subsistema
Diseño de la interfazDiseño y documentación de la interfaz de cada subsistema con otros subsistemas
Diseño de componentesAsignació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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
12 / 125
diseño arquitectónico
Los grandes sistemas se descomponen en subsistemas que proporcionan conjuntos de servicios relacionados
<<subsistema>>
Controlador del brazo
<<subsistema>>
Sistema de visión
<<subsistema>>
Sistema de identificación de objetos
<<subsistema>>
<<subsistema>>
Sistema de embalaje
<<subsistema>>Sistema de selección de embalajes
<<subsistema>>
Controlador del asidero
<<subsistema>>
Contro lador de cinta transportadora
<<subsistema>>
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
13 / 125
diseño arquitectónico
diseño arquitectónicoproceso inicial del diseño para identificar los subsistemas y establecer un marco de trabajo para el control y comunicación entre ellos
actividades principalesestructuración del sistema en varios subsistemas principalesmodelado del control entre las partes del sistemadescomposición modular: cada subsistema se descompone en módulos interconectados
salida del diseño arquitectónico: documento con diversas perspectivas de la arquitectura
modelo estructural estático: subsistemas o componentes a desarrollar como unidades separadasmodelo de proceso dinámico: organización del sistema en tiempo de ejecución, y que puede ser distinto al modelo estáticomodelo de interfaz: definición de los servicios ofrecidos por cada subsistema a través de su interfaz públicamodelos de relación: relaciones de, por ejemplo, el flujo de datos entre subsistemasmodelo de distribución: cómo se distribuyen los subsistemas entre los componentes físicos del sistema (computadores, nodos de red,…)
Estructuración del sistema
Modelado del control
Descomposición modular
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
14 / 125
diseño arquitectónico
diseño arquitectónico y requisitos no funcionalesla 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ónseguridad: 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óndisponibilidad: puede obligar a incluir componentes redundantes que puedan reemplazarse y actualizarse sin detener el sistemamantenibilidad: mejora cuando se utilizan componentes más pequeños, que pueden intercambiarse con facilidad
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
15 / 125
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 subsistemas
efectivo para la comunicación entre los participantes en el proyecto y el reparto de tareas entre distintos grupos
modelos específicos de arquitecturamodelo de depósito o repositoriomodelo cliente/servidormodelo de máquina abstracta o en capas
diseño arquitectónico > arquitectura
Estructuración del sistema
Modelado del control
Descomposición modular
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
16 / 125
modelo de repositorio
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 corporativasistemas CAD y CASEsistemas de control de procesos...
editor de diseñoeditor de diseño generador de código
generador de código
editor de programaseditor de
programas
generador de informesgenerador
de informesanalizador de diseño
analizador de diseño
traductor de diseño
traductor de diseño Depósito de proyectos
arquitectura de un conjunto integrado de herramientas CASE
fuente: Ingeniería de Software, I. Sommerville,
arquitectura de un conjunto integrado de herramientas CASE
fuente: Ingeniería de Software, I. Sommerville,
diseño arquitectónico > arquitectura > modelo de depósito
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
17 / 125
modelo de repositorio
las herramientas compatibles con el modelo de datos se integran directamente
centralización de actividades de administración del depósito: respaldo, seguridad, control de acceso y recuperación de errores.
los subsistemas que producen datos no necesitan saber cómo son utilizados por otros subsistemas.
compartición eficiente de grandes cantidades de datos, sin necesidad de transmitir datos explícitamente de un subsistema a otro.
Ventajas
difícil distribuir el depósito en varias máquinas (problemas de inconsistencia y redundancia de los datos)
diferentes subsistemas pueden tener diferentes requerimientos de políticas de seguridad, recuperación y respaldo. El modelo de depósito impone la misma política a todos los subsistemas.
genera un gran volumen de información y es difícil hacer evolucionar el sistema.
los subsistemas deben estar acordes al modelo de depósito de datos, lo que lleva a un compromiso entre las necesidades específicas de cada herramienta, lo que puede afectar a cuestiones como el rendimiento.
difícil o imposible integrar subsistemas cuyos modelos de datos no se ajusten al esquema.
Inconvenientes
diseño arquitectónico > arquitectura > modelo de depósito
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
18 / 125
modelo cliente/servidor
modelo cliente/servidormodelo de sistemas distribuido que muestra cómo datos y procesamiento se distribuyen a lo largo de varios procesadores
componentesconjunto de servidores independientes que ofrecen servicios a otros subsistemas
servidores de impresiónservidores de administración de archivosservidores de bases de datos...
conjunto de clientesinvocan 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 concurrentetienen 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)
diseño arquitectónico > arquitectura > modelo cliente / servidor
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
19 / 125
modelo cliente/servidor
Servidor de catálogos
Servidor de catálogos
CatálogoCatálogo
Servidor de vídeosServidor de vídeos
Archivos de vídeosArchivos de vídeos
Servidor de imágenes
Servidor de imágenes
Fotografías digitalizadas
Fotografías digitalizadas
Servidor webServidor web
Páginas webPáginas web
INTE
RN
ET
Cliente 1Cliente 1
Cliente 2Cliente 2
Cliente 3Cliente 3
Cliente 4Cliente 4
Cliente 1Cliente 1
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
20 / 125
modelo cliente/servidor
distintas arquitecturas cliente/servidortres 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óncapa 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 organiza como un servidor (o varios idénticos) y un conjunto de clientes
modelo de “cliente delgado”todo el procesamiento de la aplicación y la administración de datos se realiza en el servidorel cliente únicamente ejecuta el software
modelo de “cliente grueso”el servidor sólo es responsable de la administración de datosel software del cliente implementa toda o gran parte de la lógica de la aplicación y las interacciones del usuario con el sistema
diseño arquitectónico > arquitectura > modelo cliente / servidor
Capa de presentación
Capa de procesamiento de
la aplicación
Capa de administración de
datos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
21 / 125
modelo cliente/servidor
modelo de cliente delgadoutilizado 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 sencillossistemas basados en tecnologías web: los dispositivos de red ejecutan un navegador, que implementa la interfaz de usuariola 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 servidorel 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
ClienteClienteServidor
Administrador de datosProcesamiento de la
aplicación
Servidor
Administrador de datosProcesamiento de la
aplicación
Presentación
diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente delgado
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
22 / 125
modelo cliente/servidor
modelo de cliente gruesodistribuye al cliente procesamiento lógico de la aplicación y la presentación
aprovecha la capacidad de procesamiento disponible en los 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 transaccionesgestor de transacciones: sistema middleware que
organiza las comunicaciones con los clientes remotoscoloca en serie las transacciones de los clientes para ser procesadas por la base de datos, lo que permite al sistema recuperarse de fallos sin corromper los datos
inconvenientesadministración del sistema más compleja al distribuirse la funcionalidad de la aplicación en diferentes computadoresmantenimiento: reinstalación en cada computador cliente si cambia la aplicación
diseño arquitectónico > arquitectura > modelo cliente / servidor > modelo de cliente grueso
ClienteProcesamiento de las
aplicaciones y presentación
ClienteProcesamiento de las
aplicaciones y presentaciónServidor
Administrador de datos
Servidor
Administrador de datos
ATMATM
ATMATM
ATMATM
Monitor de teleprocesa-
miento
Base de datos de cuentas
Servidorde cuentas
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
23 / 125
modelo cliente/servidor
problemas del enfoque de dos capas físicaslas tres capas lógicas (presentación, procesamiento y administración de datos) deben asociarse a dos sistemas de cómputo
problemas de escalabilidad y rendimiento en el modelo de cliente delgado
problemas de administración del sistema en el modelo de cliente grueso
alternativa: utilizar tres capas físicaslas tres capas lógicas son procesos separados lógicamente
no implica la existencia de tres sistemas de cómputo conectados a la red pero si es necesario se pueden separar fácilmente y ejecutar en procesadores separados
son más escalables que las arquitecturas de dos niveles
ejemplo: sistema bancario en Internet:administración de datos: suministrado por la base de datos del banco (normalmente en un mainframe)servicios de aplicación (transferencias, consulta de movimientos, pago de facturas,...) suministrados por un servidor Webpresentación: el cliente es el computador del usuario con un navegador websistema escalable: se pueden añadir fácilmente servidores web cuando aumenta el número de clientes
Consultas SQL
Clientes webClientes web
Interacción HTTP
diseño arquitectónico > arquitectura > modelo cliente / servidor
Provisión del servicio de la cuenta
Servidorweb
Provisión del servicio de la cuenta
Servidorweb
SQLBase de datos de cuentas
Servidorde cuentas
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
24 / 125
modelo cliente/servidor
Código móvil: applets de Java y controles ActiveX
permiten implementar un modelo cliente/servidor a medio camino entre los de cliente delgado y grueso
funcionamientoparte del software de procesamiento se descarga en el cliente como applet, aligerando la carga del servidorla interfaz de usuario se construye utilizando un navegador Web que ejecuta los applets o los controles ActiveX
problemasdiferencias en las implementaciones de Java en navegadores de distintos fabricantesnecesidad de una velocidad de transmisión aceptable para descargar los appletsproblemas de seguridadlibertad de configuración por el usuario
diseño arquitectónico > arquitectura > modelo cliente / servidor
Administración datosProcesamiento aplicación
Servidorweb
PresentaciónEjecución applets
Clienteweb
Interacción HTTP
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
25 / 125
modelo cliente/servidor
C/S de tres capas o múltiples capas
C/S de dos capas con clientes gruesos
C/S de dos capas con clientes delgados
Arquitectura
Aplicaciones de gran escala con cientos o miles de clientes.
Aplicaciones donde tanto los datos como la aplicación son volátiles.
Aplicaciones donde se integran datos de diversas fuentes.
Aplicaciones con procesamiento de datos computacionalmenteintensivo (por ejemplo, visualización de datos, animaciones gráficas,...)
Aplicaciones con funcionalidad para el usuario final relativamente estable utilizadas en un entorno con administración de sistemas bien establecido.
Aplicaciones de sistemas heredados donde no es práctico separar el procesamiento de las aplicaciones y la administración de datos.
Aplicaciones computacionalmente intensivas como los 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
diseño arquitectónico > arquitectura > modelo cliente / servidor
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
26 / 125
modelo en capas
modelo en capas o de máquina abstracta
modela la interacción entre los subsistemas organizando un sistema en una serie de capas
cada capa presta servicios a la capa inmediatamente superior y actúa como cliente de la que queda encerrada
el diseño incluye los protocolos que establecen cómo interactuará cada par de capas
arquitectura cambiable y portable: preservando la interfaz, una capa se puede reemplazar por otracuando cambian las interfaces de las capas sólo afecta a la capa adyacente
desventajasdifícil estructurar los sistemas pues es posible que el usuario requiera acceso a capas internas (p.ej., bases de datos) lo que subvierte el modeloel rendimiento puede resultar afectado por los múltiples niveles de interpretación de órdenes que se requieren a veces
Gestión de configuraciones del sistema
Gestión de objetos del sistema
Base de datos del sistema
Sistema operativo
diseño arquitectónico > arquitectura > modelo en estratos
Usuarios
Modelo de capas de un sistema de gestión de versiones.Fuente: Ingeniería del Software, I. Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
27 / 125
modelo en capas: ejemplos
Aplicación
Presentación
Sesión
Transporte
Red
Enlace de datos
Física
Aplicación
Presentación
Sesión
Transporte
Red
Enlace de datos
Física
MEDIOS DE COMUNICACIÓN
Red
Enlace de datos
Física
Arquitectura de red OSI
Aplicación
Transporte
Interred
Host a red
TELNET FTP SMTP DNS
TCP UDP
IP
ARPANET INTERNET SATNET LAN
Arquitectura de red TCP/IP
Interconexión física
Transferencia de datos
Transferencia de información delas aplicaciones
diseño arquitectónico > arquitectura > modelo en estratos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
28 / 125
diseño arquitectónico: modelado del control
modelos de controlrepresentan la forma en que los subsistemas se controlan para que sus servicios se entreguen en el lugar correcto y en el momento justo
el arquitecto organiza los subsistemas acorde a un modelo de control
dos modelos de control genéricos:control centralizado: un subsistema es el responsable de controlar, iniciar y detener otros subsistemas. También puede pasar el control a otros subsistemas, pero espera que se le devuelva esa responsabilidad de control.control basado en eventos: cada subsistema 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
diseño arquitectónico > modelado del control
Estructuración del sistema
Modelado del control
Descomposición modular
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
29 / 125
control centralizado
sistemas de control centralizadoun subsistema tiene la responsabilidad de controlar el sistema y administrar la ejecución de otros subsistemas
dos clases, según se ejecuten secuencialmente o en paralelo
modelo de llamada-retorno (ejecución secuencial): el control se inicia en la parte superior de una jerarquía y por medio de llamadas a subrutinas pasa a los niveles del árbolno es un modelo estructural, por lo que no es necesario, por ejemplo, que la Rutina 1.1. forme parte de la Rutina 1sólo se aplica a sistemas secuencialesutilizado 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 de entradasinconveniente: las excepciones a operaciones normales son complicadas de gestionar
modelo del administrador: se aplica a los modelos concurrentes un componente del sistema se designa como 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 procesamiento.un proceso es un subsistema o módulo que se ejecuta en paralelo con otros procesosutilizado en sistemas de tiempo real “suaves” (con restricciones de tiempo no muy estrictas)
programaprincipal
programaprincipal
rutina 1rutina 1 rutina 2rutina 2 rutina 3rutina 3
rutina 1.1rutina 1.1 rutina 1.2rutina 1.2 rutina 3.1rutina 3.1 rutina 3.2rutina 3.2
procesosdel sensor
controladorsistema
controladorsistema
procesosdel actuador
procesosde cálculo interfaz de
usuariointerfaz de
usuario controladorde fallos
controladorde fallos
diseño arquitectónico > modelado del control > control centralizado
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
30 / 125
control centralizado: ejemplo
Proceso detector de movimiento
Proceso detector de movimiento Proceso sensor de
puertasProceso sensor de
puertas Proceso sensor de ventanas
Proceso sensor de ventanas
Proceso de monitorización
edificio
Proceso de monitorización
edificio
Proceso del sistema de alarma
Proceso del sistema de alarma
400 Hz 60 Hz 100 Hz
560 Hz
Número de habitación
Estado del sensorEstado del sensorEstado del detector class BuildingMOnitor extends Thread {
BuildingSensor win, door, move ;
Siren siren = new Siren () ;Lights lights = new Lights () ;DoorSensors doors = new DoorSensors (30) ;
( ... )
BuldingMonitor(){
//inicializar sensores e iniciar procesos( ... )}public void run (){
int room = 0 ;while (true){//sondear movimiento sensores (400Hz)move = movements.getVal () ;
( ... )
}
class BuildingMOnitor extends Thread {
BuildingSensor win, door, move ;
Siren siren = new Siren () ;Lights lights = new Lights () ;DoorSensors doors = new DoorSensors (30) ;
( ... )
BuldingMonitor(){
//inicializar sensores e iniciar procesos( ... )}public void run (){
int room = 0 ;while (true){//sondear movimiento sensores (400Hz)move = movements.getVal () ;
( ... )
}
fuente: Ingeniería de Software, I. Sommerville
diseño arquitectónico > modelado del control > control centralizado
Ejemplo del modelo del administrador centralizado
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
31 / 125
control dirigido por eventos
sistemas de control dirigido por eventosse rigen por eventos generados en el exterior (señal de un sensor, comando desde un menú,…)
diferentes tipos de sistemas dirigidos por eventoshojas 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ónobjetos activos, en los que el cambio de valor de un atributo del objeto dispara algunas acciones
dos tipos de modelos principalesmodelos 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 eventomodelos dirigidos por interrupciones: especialmente útiles para sistemas de tiempo real que necesitan manejar rápidamente eventos generados en el exterior
diseño arquitectónico > modelado del control > control dirigido por eventos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
32 / 125
control por eventos: modelos de transmisión
modelos de transmisiónse 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
ventajas: la evolución es relativamente sencilla pues se pueden integrar nuevos subsistemas registrando sus eventos en el controlador de eventoscualquier subsistema puede activar otros subsistemas sin conocer su nombre o ubicaciónlos subsistemas se pueden incrementar en máquinas distribuidas, de forma transparente para otros subsistemas
desventaja: los subsistemas no saben si los eventos se manejarán ni cuando lo haráncuando un subsistema genera un evento no sabe qué otros subsistemas han registrado un interés en ese evento
Controlador de eventos y mensajes
subsistema1
subsistema1 subsistema
2subsistema
2 subsistema3
subsistema3
subsistema4
subsistema4 subsistema
5subsistema
5
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
33 / 125
modelos de transmisión: 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 suministranotros 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)
funcionamientolos objetos se distribuyen a lo largo de varios computadores sobre una red se comunican a través de middleware (una especie de “bus de software” que provee un conjunto de servicios que permiten comunicación, agregación y destrucción de objetos del sistemamiddleware: agente de solicitud de objetos (ORB, Object RequestBroker) y provee una interfaz transparente entre objetos
ventajaspermite retrasar las decisiones sobre dónde y cómo se deben suministrar los servicios pues los objetos proveedores de servicios se pueden ejecutar en cualquier nodo de la redarquitectura 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 lenguajessistema 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
desventajasmás complejas de diseñar que los sistemas cliente/servidor clásicos
ORB
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos
fuente: Ingeniería de Software, I. Sommerville
o1
s(o1)
o2
s(o2)
o3
s(o3)
o4
s(o4)
o5
s(o5)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
34 / 125
modelos de transmisión: objetos distribuidos
utilización de una arquitectura de objetos distribuidoscomo 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 ORBel 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)
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
35 / 125
modelos de transmisión: 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 lecturalos objetos integradores recolectan información de todas las bases de datos para tratar de deducir relaciones específicas (cada uno tiene su especialidad, como variaciones por temporadas, relaciones entre tipos de bienes,...)los objetos visualizadores interactúan con los integradores para visualizar o generar informes
la arquitectura de objetos distribuidos es más adecuada para este tipo de aplicaciones que una c/s
el modelo lógico del sistema no es suministrar información proporcionada por diferentes servicios de administración de 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áquinasse pueden explorar nuevos tipos de relaciones agregando nuevos objetos integradores que no necesitan conocer a los ya existentes
Base de datos 1
Base de datos 2
Base de datos 3
Integrador 1
Integrador 2
generador informes
pantalla
visualizador
fuente: Ingeniería de Software, I. Sommerville
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos de transmisión > arquitecturas de objetos distribuidos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
36 / 125
control por eventos: modelos dirigidos por interrupciones
modelos dirigidos por interrupcionesútiles para
sistemas de tiempo real que necesitan manejar muy 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 sistema utilizando el control basado en interrupciones para casos de emergencia
interrupcionesexisten varios tipos de interrupciones conocidas con un controlador definido para cada tipocada tipo de interrupción se asocia con la ubicación de memoria en la que se almacena la dirección del controladorcuando se recibe una interrupción de un determinado tipo, un interruptor de hardware transfiere el control al controlador adecuadoel controlador puede iniciar o detener otros procesos en respuesta a los eventos recibidos por el interruptor
ventaja: permite dar respuestas rápidas a los eventos
desventajascomplejo de programar y difícil de validarsi 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
interrupciones
vector deinterrupción
controlador1
controlador1 controlador
2controlador
2 controlador3
controlador3 controlador
4controlador
4
proceso1
proceso1 proceso
2proceso
2 proceso3
proceso3 proceso
4proceso
4
diseño arquitectónico > modelado del control > control dirigido por eventos > modelos dirigidos por interrupciones
fuente: Ingeniería de Software, I. Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
37 / 125
computación distribuida interorganizacional
Computación distribuida interorganizacionalPor seguridad e interoperabilidad se ha utilizado sobre todo computación distribuida intraorganizacional
Servidores dentro de la misma organizaciónFacilidad 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
38 / 125
arquitecturas peer-to-peer
Sistemas peer-to-peer (p2p)Sistemas descentralizados:
los cálculos se pueden realizar en cualquier nodo de la redno 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
39 / 125
arquitecturas peer-to-peer
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
n1n1
n2n2
n4n4
n3n3
n5n5
n9n9
n6n6
n7n7
n8n8
n10n10n11n11
n12n12
n13n13
n14n14
fuente: Ingeniería del Software, Ian Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
40 / 125
arquitecturas peer-to-peer
arquitectura p2p descentralizadalos nodos de red actúan como interruptores de comunicaciones, encaminando datos y señales de control entre nodos.
búsqueda de un documentose envía comando de búsqueda a los nodos de la localidadlos nodos comprueban si tienen el documentosi lo tienen, lo devuelven al solicitantesi no lo tienen, encaminan la búsqueda a otros nodosal 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
desventajassobrecargas (la misma búsqueda es realizada por muchos nodos)replicaciones de comunicaciones entre nodos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
41 / 125
arquitecturas peer-to-peer
arquitectura p2p semicentralizadanodos que actúan como servidores para facilitar las comunicaciones entre nodos
establecimiento de contactos entre nodoscoordinació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
n1n1
n2n2
n4n4n3n3
n5n5
n6n6
Buscador deservicios
fuente: Ingeniería del Software, Ian Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
42 / 125
arquitectura de sistemas orientados a servicios
servicio webrepresentació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 disponiblescó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 deservicios
Registro deservicios
Suministradorde servicios
Suministradorde servicios
Solicitante deservicios
Solicitante deservicios ServicioServicio
PublicarBuscar
Enlazar
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
43 / 125
arquitectura de sistemas orientados a servicios
algunas ventajaslos 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 XMLSOAP (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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
44 / 125
arquitectura de sistemas orientados a servicios
Reúne información
Servicio de información móvil
Recibe un flujo de información desde
los servicios
Receptor
Envía la posición y la petición de
información al servicio
Transmisor
Recibe peticiones del usuario
Interfaz de usuario
Traduce la información digital
a señal de radio
Radio
Encuentra la posición del
vehículo
Localizador
Encuentra un servicio disponible
Buscador de servicios
Información del tráfico de carreteras
Localizador decarreteras
Localizador decarreteras
Informaciónde tráfico
Informaciónde tráfico
Coordenadas GPS
Información deutilidades
Información deutilidades
Informacióndel tiempo
Informacióndel tiempo
Coordenadas GPS
Coordenadas GPS
Sistema software de vehículos
TraductorTraductorInformacióndel lenguaje
Comando decoordenadas
GPS
fuente: Ingeniería del Software, Ian Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
45 / 125
arquitecturas de aplicaciones
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ónaplicaciones de procesamiento de datos
procesamiento de datos por lotes con poca o nula interacción del usuario
aplicaciones de procesamiento de transaccionesprocesan peticiones del usuario para obtener información y para actualizar información en una base de datos
sistemas de procesamiento de eventosaplicaciones 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
46 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de datos
sistemas de procesamiento de datosdan 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
componentesentrada: reúne entradas desde una o más fuentesprocesamiento: realiza cálculos utilizando las entradassalida: 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
SistemaSistema
EntradaEntrada ProcesamientoProcesamiento SalidaSalida
Base de datosBase de datos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
47 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de datos
Registros de empleados
Registros de empleados
Datos de pagos
mensuales
Datos de pagos
mensuales
Leer registro de empleadoLeer registro de empleado
Leer datos de pagos mensuales
Leer datos de pagos mensuales
Validar datos de empleado
Validar datos de empleado
Calcularsalario
Calcularsalario
Escribir transacciones de impuestos
Escribir transacciones de impuestos
Escribir datosde pensiones
Escribir datosde pensiones
Imprimirnómina
Imprimirnómina
Escribir transacción bancaria
Escribir transacción bancaria
Escribir datos de la Seguridad Social
Escribir datos de la Seguridad Social
Transacciones de impuestos
Transacciones de impuestos
Datos de pensionesDatos de pensiones
Transacciones del banco
Transacciones del banco
Datos de la Seguridad Social
Datos de la Seguridad Social
IMPRESORA
Información depagos
Registro deempleado
Registro válidode empleado
Tasas de pagos mensuales
Tasas de pagos mensuales
Tablas de impuestosTablas de impuestos
Pensión deducible + número SS
Gasto deducible +número SS + oficinatributaria
Datos del empleado +deducciones
Pago neto + informaciónde cuenta bancaria
Deducción de la SS +número SS
fuente: Ingeniería del Software, Ian Sommerville
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
48 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de transacciones
sistemas de procesamiento de transaccionesprocesan 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 de E/S
Procesamiento de E/S
Lógica de la aplicación
Lógica de la aplicación
Gestor de transaccionesGestor de
transaccionesBase dedatos
Base dedatos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
49 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de transacciones
Obtener el identificador de
cuenta del cliente
Obtener el identificador de
cuenta del cliente
Validar la tarjeta
Validar la tarjeta
Seleccionar el servicio
Seleccionar el servicio
Imprimir detalles
Imprimir detalles
Devolver la tarjeta
Devolver la tarjeta
Dispensar efectivo
Dispensar efectivo
Consultar la cuenta
Consultar la cuenta
Actualizar la cuenta
Actualizar la cuenta
ATM ATMBase de Datos
Entrada Proceso Salida
la estructura entrada-proceso-salida también se aplica a muchos sistemas de procesamiento de transacciones (versiones interactivas de sistemas de procesamiento por lotes)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
50 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de transacciones
Monitor de teleprocesamiento(middleware)
Monitor de teleprocesamiento(middleware)
Bases de datos de cuentas
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
51 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de transacciones
sistemas de información y de gestión de recursos: sistemas con gran interacción con una base de datos compartida
sistemas gestión documentalsistemas de ayuda a la toma de decisionessistemas de horariossistemas de gestión de tráfico aéreosistemas de bibliotecasistemas de comercio electrónico…
Interfaz de usuarioInterfaz de usuario
Comunicaciones del usuarioComunicaciones del usuario
Recuperación y modificación de informaciónRecuperación y modificación de información
Base de datos de gestión de transaccionesBase de datos de gestión de transacciones
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
52 / 125
arquitecturas de aplicaciones: sistemas de procesamiento de transacciones
Interfaz del navegador webInterfaz del navegador web
Identificaciónde usuario
Gestor de consultasy formularios
Gestor deimpresión
Búsquedadistribuida
Recuperaciónde documentos
Gestor dederechos
Registro decuentas
Índice de bibliotecaÍndice de biblioteca
BD1BD1 BD2BD2 BD3BD3 BD4BD4 BDnBDn
Interfaz de usuarioInterfaz de usuario
Identificaciónde usuario
Entrega derecursos
Gestiónde consultas
Gestión de recursos
Control de políticasde recursos
Asignaciónde recursos
Gestión de transacciones dela base de datos de recursos
Gestión de transacciones dela base de datos de recursos
Arquitectura de un sistema deasignación de recursos
Arquitectura de un sistema degestión de documentos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
53 / 125
descomposición modular
descomposición modulardespués de diseñar la arquitectura estructural se descomponen los subsistemas en módulos
no existe una distinción rígida entre la descomposición del sistema y la descomposición 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
modelos principales de descomposición modularmodelo orientado a objetos:
el sistema se descompone en un conjunto de objetos que se comunican entre elloslos módulos son objetos con estado privado y operaciones definidas sobre ese estado
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
diseño arquitectónico > descomposición modular
Estructuración del sistema
Modelado del control
Descomposición modular
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
54 / 125
diseño orientado a objetos: actividades
actividades (según el Proceso Unificado de Desarrollo)
diseño de la arquitecturarealizado por los arquitectosesbozan distintos componentes
subsistemas principales e interfacesclases del diseño importantes (como las activas)mecanismos genéricos de diseño del modelo de diseño
diseño de casos de usolo realizan los ingenieros de casos de usodetallan cada caso de uso en términos de clases y/o subsistemas del diseño participantes y sus interfaceslas realizaciones de casos de uso resultantes establecen los requisitos de comportamiento para cada clase o subsistema
diseño de claseslo realizan los ingenieros de componentesintegran los requisitos dentro de cada clase (creando operaciones, atributos y relaciones)
diseño de subsistemaslo realizan los ingenieros de componentesse identifican candidatos para ser subsistemas, especificando las interfaces entre ellos
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > actividades
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
55 / 125
diseño de la arquitectura
diseño de la arquitecturael objetivo es esbozar los modelos de diseño y despliegue y su arquitectura mediante la identificación de los siguientes elementos:
nodos y configuraciones de redsubsistemas e interfaces entre ellosclases del diseño significativas para la arquitecturamecanismos de diseño genéricos derivados de requisitos no funcionales (persistencia, distribución, rendimiento,...) identificados durante el análisis
los arquitectos consideran distintas posibilidades de reutilización (partes de sistemas parecidos o de productos software generales)
diseño orientado a objetos > diseño de la arquitectura
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
56 / 125
identificación de nodos y configuraciones de red
configuraciones físicas de la redgran influencia sobre la arquitectura del software
las configuraciones habituales utilizan una arquitectura en tres capas (por ejemplo, cliente / servidor)
capa de clientes (interacciones de usuarios)capa de funcionalidad de la base de datoscapa de lógica de negocio o aplicación
aspectos importantes de las configuraciones de red
número de nodos necesarios y capacidad en términos de potencia de proceso y tamaño de memoriatipo de conexiones entre los nodos y protocolos de comunicaciones a utilizarcaracterísticas de las conexiones y protocolos en aspectos como ancho de banda, disponibilidad y calidadnecesidad de capacidades de redundancia de procesos, gestión de fallos, migración de procesos, política de copias de seguridad,...una vez conocidos se pueden aplicar distintas tecnologías
ORB (Object Request Broker)servicios de replicación de datos...
las configuraciones de red se muestran en diagramas de despliegue
diseño orientado a objetos > diseño de la arquitectura > identificación de nodos y configuraciones de red
Cliente del comprador
Servidor del comprador
Servidor del vendedor
Servidor del banco
Cliente del vendedor
Intranet
internet
internet
internetintranet
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
57 / 125
identificación de nodos y configuraciones de red
Ejemplo de un sistema de comercio electrónico.
Se ejecuta sobre tres nodos servidores y un cierto número de nodos cliente.
En primer lugar existe un nodo servidor para el comprador y uno para el vendedor, debido a que cada una de las organizaciones compradoras o vendedoras necesitan un servidor central para sus objetos de negocio y su procesamiento.
Los usuarios finales, como el Comprador, acceden al sistema mediante nodos cliente. Estos nodos se comunican mediante el protocolo TCP/IP de Internet (o de intranets).
También existe un tercer nodo servidor para el propio banco. En él se producen los verdaderos pagos de facturas (es decir, las transferencias entre cuentas).
Cliente del comprador
Servidor del comprador
Servidor del vendedor
Servidor del banco
Cliente del vendedor
Intranet
internet
internet
internetintranet
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
58 / 125
identificación de subsistemas y sus interfaces
subsistemasforma de organizar el modelo de diseño en piezas manejables
representan varios tipos de subsistemas
software desarrollado internamente en el proyectoproductos reutilizadosrecursos existentes en la empresa
pasos en la identificación de subsistemas
identificación de subsistemas de aplicaciónidentificación de subsistemas intermedios y de software del sistemadefinición de dependencias entre subsistemasidentificación de interfaces entre subsistemas
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas
Capa específica de la aplicación
Capa general de la aplicación
Capa intermedia
Capa de software del sistema
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
59 / 125
identificación de subsistemas de la aplicación
Subsistemas de la aplicaciónIdentificació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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
60 / 125
Gestión cuentas<<paquete del diseño>>
Gestión de facturas del comprador
<<paquete del análisis>>Gestión de cuentas
<<paquete del análisis>>Modelo de análisis
Modelo de diseñoGestión facturas comprador<<paquete del diseño>>
identificación de subsistemas de la aplicación
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 subsistemaalgunas 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 sistemalos paquetes del análisis no representan una adecuada división del trabajolos paquetes del análisis no representan la incorporación de un sistema heredado, que se puede encapsular mediante un subsistema de diseño independientelos 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
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas de la aplicación
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
61 / 125
identificación de subsistemas de la aplicación
<<trace>> <<trace>>
MODELO DE ANÁLISIS
MODELO DE DISEÑO
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
62 / 125
identificación de subsistemas de la aplicación
Gestión facturas comprador
Gestión de planificación de pagos
Gestión de cuentas
capa específica de la aplicación
capa general de la aplicación
Durante el diseño se identificó el subsistema de servicio Gestión de Planificación de Pagos para proporcionar un servicio general que puedan utilizar diferentes realizaciones de casos de uso
Durante el diseño se identificó el subsistema de servicio Gestión de Planificación de Pagos para proporcionar un servicio general que puedan utilizar diferentes realizaciones de casos de uso
El subsistema Gestión Facturas Comprador se descompone recursivamente en tres nuevos subsistemas para tratar su distribución entre los distintos nodos
El subsistema Gestión Facturas Comprador se descompone recursivamente en tres nuevos subsistemas para tratar su distribución entre los distintos nodos
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas de la aplicación
<< subsistema de diseño >>Gestión facturas comprador
IU delcomprador
Gestión solicitudes pago Gestión de facturas
IUsolicitudde pago
procesamiento
solicitudes de pago
Gestor pedidos
confirmaciónpedidos
procesamiento facturas
factura
Clientecomprador
Servidorcomprador
Servidorvendedor
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
Cliente del comprador
Servidor del comprador
Servidor del vendedor
Servidor del banco
Cliente del vendedor
Intranet
internet
internet
internetintranet
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
63 / 125
subsistemas intermedios y de software del sistema
Identificación de subsistemas intermedios y de software del sistema
toda la funcionalidad descansa sobresistemas operativossistemas de gestión de bases de datossoftware de comunicacionestecnologías de distribución de objetostecnologías de gestión de transaccionessoftware de diseño de interfaces de usuario
compra de middleware y software del sistema
poco o nulo control sobre su evoluciónimportante mantener libertad de acción y evitar hacerse totalmente dependientes de un producto o fabricante
considerar cada producto software comprado como un subsistema independiente con interfaces explícitos para el resto de sistemas
Java.applet Java.awt Java.rmi
Navegador web Máquina virtual java
TCP / IP
Abstract Windowing Toolkit
Remote Method Invocation
Capa intermedia
Capa de softwaredel sistema
En este ejem plo, el sis tem a debe ejecutarse en diferentes tipos de m áquinas y la empresa decid ió im plem entar esta arquitectura mediante los paquetes Java AWT, RMI y Applet, que se ejecutan sobre la m áquina virtual Java. Además, hay que uti lizar un navegador para cargar páginas web.A bajo n ive l, el sistema se construye sobre software del sistema, como el protocolo TCP/IP
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > subsistemas intermedios y del sistema
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
64 / 125
definición de dependencias entre subsistemas
dependenciasdeben definirse si hay relaciones entre los contenidos de unos subsistemas y otros
la dirección de la dependencia es la misma que la de la relación (navegabilidad)
Java.applet Java.awt Java.rmi
Navegador webMáquina virtual
java
TCP / IP
Gestión de planif icación de pagos Gestión de
cuentas
Gestión facturas
capa específica de la aplicación
capa general dela aplicación
capa intermedia
capa de softwaredel sistema
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > dependencias entre subsistemas
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
65 / 125
identificación de interfaces entre subsistemas
Una clase que hace referencia a
TransferenciaEntreCuentasdesde el exterior
MODELO DE ANÁLISIS
MODELO DE DISEÑO
Transferencias
<<trace>>
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
66 / 125
identificación de interfaces entre subsistemas
interfaces proporcionadas por un subsistema
definen operaciones que son accesibles “desde fuera” del subsistema
vienen proporcionadas por
clasessubsistemas dentro del subsistema
además hay que identificar las operaciones que se pueden definir sobre las interfaces (se hace en el diseño de casos de uso)
diseño orientado a objetos > diseño de la arquitectura > identificación de subsistemas > identificación de interfaces
Gestión de facturas
<<subsystem >>
Gestión de planificación de pagos
<<subsystem>>
Gestión de cuentas
<<subsystem >>
Capa específica de la aplicación
Capa general de la aplicación
ReceptorDeFacturas
SolicitudDePago
Transferencias
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
67 / 125
identificación de mecanismos genéricos de diseño
requisitos especiales identificados durante el análisisdecidir cómo tratarlos, teniendo en cuenta las tecnologías de diseño e implementación disponibles
cuestiones relacionadas con diversas cuestiones, como:persistenciadistribución transparente de objetoscaracterísticas de seguridaddetección y recuperación de erroresgestión de transacciones
ejemplosse necesita que algunos objetos sean accesibles desde varios nodos de red
Necesita diseñarse un sistema distribuidoPosible solución: implementar esa distribución de objetos haciendo que cada clase distribuida sea subclase de la clase abstracta deJava, 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 (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
diseño orientado a objetos > diseño de la arquitectura > identificación de mecanismos genéricos de diseño
java.rmi.UnicastRemoteObject
Factura
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
68 / 125
identificación de mecanismos genéricos: patrones
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 vendedorejemplo 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 compradorse trata de un comportamiento común que se puede representar mediante una colaboración genérica (utilización de clases abstractas)
diseño orientado a objetos > diseño de la arquitectura > identificación de mecanismos genéricos de diseño
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
69 / 125
identificación de mecanismos genéricos: patrones
Creación de objeto de negocio
: Emisor
: ControlProcesamientoEmisor
1: enviar objeto de negocio
2: crearObjetoDeNegocio
: Objeto de Negocio
3: crear( )
: Procesamiento Receptor4: recibirObjetoDeNegocio( objetoDeNegocio)
5: obtenerInformación( )
IU Presentación de objeto de negocio
6: presentarObjetoDeNegocio(ObjetoDeNegocio)
: Receptor
7: presentar objeto de negocio
Al diseñar el caso de uso Enviar Factura al Comprador, se puede hacer que algunas clases sean subtipos de cada una de las clases abstractas que participan en la colaboración genérica
Al diseñar el caso de uso Enviar Factura al Comprador, se puede hacer que algunas clases sean subtipos de cada una de las clases abstractas que participan en la colaboración genérica
diseño orientado a objetos > diseño de la arquitectura > identificación de mecanismos genéricos de diseño
IU Creación de objeto de negocio
ControlProcesamientoEmisor
Objeto denegocio
ControlProcesamientoReceptor
IU Present. de objeto de negocio : Receptor
: Emisor
: Comprador : Vendedor
IU Creación de facturas
ControlProcesamientoFacturas
Factura ProcesamientoSolicitudesPago
IU Present. de objeto de facturas
Clasificadores abstractos que participan en la colaboración genérica de envío de objetos de negocio
Clasificadores concretos que participan en la realización del caso de uso Enviar Factura al Comprador
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
70 / 125
diseño de un caso de uso
actividades del diseño de un caso de uso
identificar las clases del diseño y/o subsistemas cuyas instancias son necesarias para llevar a cabo el flujo de sucesos del caso de uso
describir las interacciones entre objetos del diseño
identificar los subsistemas e interfaces participantes
describir las interacciones entre subsistemas
identificar requisitos no funcionales
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de casos de uso
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
71 / 125
Diseño de un caso de uso
Definir objetosparticipantes
Definir objetosparticipantes
Definir objetosconceptuales
Definir objetosconceptuales Definir objetos
de interfazDefinir objetos
de interfaz Definir objetosde control
Definir objetosde control
Definir interacciones
Definir interacciones
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
72 / 125
Identificación de objetos de interfaz
objetos de interfazrepresentan 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 interfazidentificar 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
73 / 125
Identificación de objetos de interfaz
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar Emergencia en su PDA.
2. El sistema COMUNICA responde presentando un formulario al OficialCampo. El formulario incluye un menú de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicación, descripción del incidente, petición de recursos,...
3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la situación de emergencia y solicitar recursos específicos. Una vez que ha llenado el formulario, el OficialCampo lo envía oprimiendo el botón “Enviar Informe” y en ese momento se le notifica al Controlador
4. Al Controlador se le notifica un nuevo informe de incidente mediante un cuadro de diálogo desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos llamando al caso de uso AbrirIncidente. Toda la información contenida en el formulario del OficialCampo se incluye automáticamente en el Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al OficialCampo.
5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar Emergencia en su PDA.
2. El sistema COMUNICA responde presentando un formulario al OficialCampo. El formulario incluye un menú de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicación, descripción del incidente, petición de recursos,...
3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la situación de emergencia y solicitar recursos específicos. Una vez que ha llenado el formulario, el OficialCampo lo envía oprimiendo el botón “Enviar Informe” y en ese momento se le notifica al Controlador
4. Al Controlador se le notifica un nuevo informe de incidente mediante un cuadro de diálogo desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos llamando al caso de uso AbrirIncidente. Toda la información contenida en el formulario del OficialCampo se incluye automáticamente en el Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al OficialCampo.
5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.
Estación OficialCampo
Estación Controlador
Estación OficialCampo
Formulario usado para la creación de Incidente. Este formulario se le presenta al Controlador en la EstaciónControlador cuando se recibe el InformeEmergencia. El Controlador también usa este formulario para asignar recursos y dar el acuse del recibo al informe del OficialCampo.
FormularioIncidente
Ordenador móvil utilizado por el OficialCampoEstaciónOficialCampo
Formulario usado para dar los datos de InformarEmergencia. Este formulario se le presenta al OficialCampo en la EstaciónOficialCampo cuando se selecciona la función InformarEmergencia. El FormularioInformeEmergencia contiene 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.
FormularioInformeEmergencia
Botón usado por el OficialCampo para iniciar el caso de uso InformarEmergencia
BotónInformeEmergencia
Ordenador utilizado por el ControladorEstaciónControlador
Aviso usado para desplegar el acuse de recibo del Controladorhacia el OficialCampoAcuseDeRecibo
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
74 / 125
Identificación de objetos de control
objetos de controlresponsables 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 negociocontrol de las colas de “deshacer” e historialesenvío de información en sistemas distribuidos...
identificación de objetos de controlidentificar 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 cortosidentificar un objeto de control por actor en el caso de usola vida de un objeto de control debe ser la del caso de uso o la de la sesión del usuariosi 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
75 / 125
Identificación de objetos de control
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar Emergencia en su PDA.
2. El sistema COMUNICA responde presentando un formulario al OficialCampo. El formulario incluye un menú de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicación, descripción del incidente, petición de recursos,...
3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la situación de emergencia y solicitar recursos específicos. Una vez que ha llenado el formulario, el OficialCampo lo envía oprimiendo el botón “Enviar Informe” y en ese momento se le notifica al Controlador
4. Al Controlador se le notifica un nuevo informe de incidente mediante un cuadro de diálogo desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos llamando al caso de uso AbrirIncidente. Toda la información contenida en el formulario del OficialCampo se incluye automáticamente en el Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al OficialCampo.
5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.
Ubicación Descripción del caso de uso
1. El OficialCampo activa la función Informar Emergencia en su PDA.
2. El sistema COMUNICA responde presentando un formulario al OficialCampo. El formulario incluye un menú de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicación, descripción del incidente, petición de recursos,...
3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la situación de emergencia y solicitar recursos específicos. Una vez que ha llenado el formulario, el OficialCampo lo envía oprimiendo el botón “Enviar Informe” y en ese momento se le notifica al Controlador
4. Al Controlador se le notifica un nuevo informe de incidente mediante un cuadro de diálogo desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos llamando al caso de uso AbrirIncidente. Toda la información contenida en el formulario del OficialCampo se incluye automáticamente en el Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al OficialCampo.
5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.
Estación OficialCampo
Estación OficialCampo
Estación Controlador
Estación Controlador
Estación OficialCampo
Estación 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 despliega ante el Controlador. Una vez que el Controlador ha creado un Incidente, le ha asignado Recursos y ha enviado un acuse de recibo, ControlAdministrarEmergencia envía el acuse de recibo a la EstaciónOficialCampo.
ControlAdministrarEmergencia
Gestiona la función de informe de InformarEmergencia en la EstaciónOficialCampo. Este objeto se crea cuando el OficialCamposelecciona el botón InformarEmergencia. Luego crea un FormularioInformeEmergencia y lo presenta al OficialCampo. Después del envío del formulario crea un InformeEmergencia y se lo 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.
ControlInformarEmergencia
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
76 / 125
modelado de interacciones entre objetos
diagramas de interacciónrepresentan 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 escenarioparticular del caso de uso mostrando la distribución de su comportamiento entre los objetos participantes
dos tiposdiagramas de colaboracióndiagramas de secuenciamuestran casi la misma información (se pueden derivar directamente uno del otro con herramientas CASE)
BotónInformarEmergencia
: OficialCampo
ControlInformarEmergencia
FormularioInformarEmergencia
oprimir( )crear( )
crear( )
cubrirContenido( )enviar( )
enviarInforme( )
BotónInformarEmergencia
: OficialCampoControlInformar
Emergencia
FormularioInformarEmergencia
1: oprimir( )2: crear( )
3: crear( )
4: cubrirContenido( )5: enviar( )
6: enviarInforme( )
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
77 / 125
modelado de interacciones entre objetos
componentes de los diagramas de interacciónobjetos
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 a la que pertenece: nombreObjeto:nombreClasela clase tiene que figurar en el modelo de clasespuede 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
actoresaparecen los actores involucrados en el caso de usotienen que aparecer en el diagrama de casos de usopuede 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 objetosaparecen junto a los enlaces e indican la dirección de la navegabilidadel objeto destino tiene que “entender” el mensaje, es decir, tiene que poder proporcionar la operación adecuada
BotónInformarEmergencia : Botón
BotónInformarEmergencia
2: crear( )
ControlInformarEmergencia
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
78 / 125
modelado de interacciones entre objetos
diagrama de secuencialos 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 secuenciaprimera columna: actor que inicia el caso de usosegunda columna: objeto de interfaz que usa el actor para iniciar el caso de usotercera columna: objeto de control que gestiona el resto del caso de usolos objetos de control son creados por objetos de interfaz que inician el caso de usolos objetos de interfaz son creados por objetos de controllos objetos de entidad son accedidos por objetos de control y de interfazlos 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
79 / 125
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
80 / 125
modelado de interacciones entre objetos
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
BotónInformarEmergencia
: OficialCampo
ControlInformarEmergencia
FormularioInformarEmergencia
ControlAdministrarEmergencia
FormularioIncidente
Incidente AcuseDeRecibo
: Controlador
MensajeAcuseDeRecibo
InformeEmergencia
oprimir( )crear( )
crear( )
cubrirContenido( )enviar( )
enviarInforme( )
crear( )
enviarInformeAControlador( ) crear( )ver
crearIncidente( )crear( )
enviarAcuseDeRecibo( )
crear( )
inform eAcuseDeRecibo( )
crear( )
ver
enviarAcuseDeRecibo( )
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
81 / 125
modelado de interacciones entre objetos
diagrama de colaboracióncompuesto por
objetos: puede haber dos o más objetos de una misma claseenlacesactoresinteracciones
se muestra la secuencia de mensajes que pasa entre los objetos (interacciones)
BotónInf ormarEmergencia
: Of icialCampo
ControlInformarEmergenciaFormularioInf ormar
Emergencia
ControlAdministrarEmergencia
Inf ormeEmergencia
FormularioIncidente
Incidente
AcuseDeRecibo
: Controlador
MensajeAc useDeRecibo
2: crear( )
1: oprimir( )
4: cubrirContenido( )5: env iar( )
3: crear( )
6: env iarInf orme( )
7: crear( )
8: env iarIn formeAContro lador( )
16: inf ormeAcuseDeRecibo( )
17: crear( )
9: crear( )
15: env iarAcuseDeRecibo( )10: ver
11: crearIncidente( )13: env iarAcuseDeRecibo( )
12: crear( )
14: crear( )
18: v er
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
82 / 125
modelado de interacciones entre objetos
mensajes desde un objeto a sí mismo
eliminación de comportamiento detallado: utilización de paquetes
socioBiblioteca
okTomarPréstamoLibrosocioBiblioteca
okTomarPréstamoLibro
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
83 / 125
modelado de interacciones entre objetos
comportamiento condicional
socioBiblioteca
socioBiblioteca libro
pedirPréstamo
okTomarPrestado
tomarPrestado
s i préstamoPosible = s i
si no
préstamoDenegado
fin si ...
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
84 / 125
diseño de objetos con responsabilidades
Patrones GRASP (General Responsibility AssignmentSoftware Patterns)
Describen los principios fundamentales del diseño de objetos y la asignación de responsabilidades, expresados como patrones
Cinco patronesExperto en InformaciónCreadorAlta CohesiónBajo AcoplamientoControlador
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
85 / 125
diseño de objetos con responsabilidades
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 relevantesSi 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
86 / 125
diseño de objetos con responsabilidades
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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
87 / 125
diseño de objetos con responsabilidades
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
88 / 125
diseño de objetos con responsabilidades
Patrón CreadorProblema: ¿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 AB contiene objetos de AB registra instancias de objetos de AB 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 implicaBajo acoplamientoMayor claridadMejor encapsulación y reutilización
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
89 / 125
diseño de objetos con responsabilidades
Ejemplo: ¿quién debe crear una instancia de LineaDeVenta?Solución: Venta, pues agrega muchos objetos LineaDeVenta
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
90 / 125
diseño de objetos con responsabilidades
Patrón ControladorProblema: ¿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 sistemarecibe la solicitud de servicio desde la capa de IU y coordina su realización, normalmente delegando en otros objetos
VentajasMayor 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áticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
91 / 125
diseño de objetos con responsabilidades
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
92 / 125
diseño de objetos con responsabilidades
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
93 / 125
identificación de las clases del diseño
clases que participan en la realización del caso de uso
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
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de casos de uso > identificación de clases del diseño
Diagrama de clases parcial
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
94 / 125
identificación de las clases del diseño
: Admi nistra dor : :OpcionesMantenCatálogo
: AltaArticulo : FormularioAltaArt ículo : ValidarArtículo : ProcesarAltaArtículo :Artículo : MensajeResultado
Mostrar
Fin Si
Navegar
Mostrar
<<link>>
Mostrar
Introducir datos artículo Validar artículo
Si datos correctosEnviar datos
Introducir datos
Alta artículo( )
ConstruirSi es correcto insertar
Si no es correcto insertar Construir
Si datos i ncorrectosMostrar mensaje error
Fin Si
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
95 / 125
identificación de las clases del diseño
ValidarArtículo<<ClientScript Object>>
:OpcionesMantenCatálogo<<Client Page>> AltaArtículo
FormularioAltaArtículo<<Form>>
<<link>><<include>>
<<include>>
MensajeResultado<<Client Page>>
ProcesarAltaArt ículo<<Server Page>>
<<submit>><<build>>
Articulo(from Logical View)
+insertar
Diagrama de clases parcial
Diagrama de clases parcial
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
96 / 125
identificación de subsistemas e interfaces
identificar subsistemas e interfacesa veces es útil diseñar un caso de uso en términos de los subsistemas y/o interfaces que participan en él
pasosestudiar las clases del análisis que participan en las correspondientes realizaciones del caso de uso-análisis, identificando (si existen) los paquetes del análisis que contienen esas clases del análisis. Después, identificar los subsistemas del diseño que poseen una traza hacia esos paquetes del análisisestudiar los requisitos especiales de las 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 esas clases.mostrar los subsistemas que participan en una realización de caso de uso en un diagrama de clases parcial, mostrando:
las dependencias entre esos subsistemas ylas interfaces que se utilicen en la realización del caso de uso
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de casos de uso > identificación de subsistemas e interfaces
IU Comprador<<subsistema diseño>>
Gestión de solicitudes de pago
<<subsistema diseño>>
Gestión de planificación de pagos
<<subsistema diseño>>
Solicitud de pago
Gestión de facturas<<subsistema diseño>>
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
97 / 125
requisitos de implementación
captura de requisitos de implementaciónse 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
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de casos de uso > requisitos de implementación
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
98 / 125
diseño de clases
actividadesesbozar la clase del diseño
identificar operaciones
identificar atributos
identificar asociaciones y agregaciones
identificar generalizaciones
describir los métodos
describir estados
tratar requisitos especiales
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de clases
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
99 / 125
clase del diseño
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 clase con una construcción específica del lenguaje de 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)
Pedido<<form>>
diseño orientado a objetos > diseño de clases
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
100 / 125
esbozar clases de diseño
esbozar la clase del diseñoclases 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 ActiveXen 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 relacionalrequiere 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 aspectosaspectos de distribución (separación de clases en diferentes nodos de una red, por ejemplo)aspectos de rendimientoaspectos 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
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de clases > esbozar la clase del diseño
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
101 / 125
identificación de operaciones
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 utilizar, lo que incluye especificar la visibilidad de cada operación (por ejemplo, en C++, public, protected, private)
datos importantes a tener en cuenta en esta 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)requisitos especiales de cualquier clase de análisis que tenga una traza con la clase del diseñointerfaces que la clase de diseño necesita proporcionarlas realizaciones de caso de uso-diseño en las que la clase participa
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de clases > identificar operaciones
Objeto de negocio
crear()enviar()plan ificar()cerrar()
Factura
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
102 / 125
identificación de operaciones
Operaciones de la clase Factura
La clase Factura participa en varias realizaciones de casos de uso, como aquellas de Pagar Factura, Enviar Aviso y Enviar Factura alComprador. Cada una de estas realizaciones leen o cambian ele stado de los objetos Factura. El caso de uso Enviar Factura al Comprador crea y envía facturas. El caso de uso Pagar Factura planifica Facturas, y así todos. Cada una de estas realizaciones de casos de uso, por tanto, utiliza objetos Facutra de forma diferente; en otras palabras, la clase Factura y sus objetos desempeñan distintos papeles en estas realizaciones de casos de uso.
Primero, los ingenieros de componentes pensaron en implementar estos cambios de estado como una operación llamada setStatus, que tenía un parámetro que indicaba la acción deseada y el estado destino (por ejemplo, setStatus(Planificada)). Pero entonces decidieron que era preferible implementar operaciones explícitas 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 Objeto de Negocio, de la cual es un subtipo la clase Factura. Laclase Objeto de Negocio soporta de esta forma las siguientes operaciones (cada una de las cuales cambia el estado de Objeto de Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estasoperaciones son solamente operaciones virtuales que definen un 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 operaciones.
Operaciones de la clase Factura
La clase Factura participa en varias realizaciones de casos de uso, como aquellas de Pagar Factura, Enviar Aviso y Enviar Factura alComprador. Cada una de estas realizaciones leen o cambian ele stado de los objetos Factura. El caso de uso Enviar Factura al Comprador crea y envía facturas. El caso de uso Pagar Factura planifica Facturas, y así todos. Cada una de estas realizaciones de casos de uso, por tanto, utiliza objetos Facutra de forma diferente; en otras palabras, la clase Factura y sus objetos desempeñan distintos papeles en estas realizaciones de casos de uso.
Primero, los ingenieros de componentes pensaron en implementar estos cambios de estado como una operación llamada setStatus, que tenía un parámetro que indicaba la acción deseada y el estado destino (por ejemplo, setStatus(Planificada)). Pero entonces decidieron que era preferible implementar operaciones explícitas 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 Objeto de Negocio, de la cual es un subtipo la clase Factura. Laclase Objeto de Negocio soporta de esta forma las siguientes operaciones (cada una de las cuales cambia el estado de Objeto de Negocio): Crear, Enviar, Planificar y Cerrar. No obstante, estasoperaciones son solamente operaciones virtuales que definen un 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 operaciones.
diseño orientado a objetos > diseño de clases > identificar operaciones
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
Objeto de negocio
crear()enviar()plan ificar()cerrar()
Factura
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
103 / 125
identificación de atributos
identificación de atributosutilizar 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
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de clases > identificar atributos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
104 / 125
asociaciones, agregaciones y generalizaciones
identificación de asociaciones y agregacionesestudiar 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 generalizacionesdeben 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
diseño orientado a objetos > diseño de clases > identificar asociaciones y agregaciones
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
Objeto de negocio
Factura Pedido
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
105 / 125
métodos y estados
descripción de los métodospueden especificarse algoritmos que se van a utilizar para realizar una operación, en seudocódeigo o lenguaje natural
la mayoría de los métodos no se especifican durante el diseño
descripción de estadosalgunos objetos del diseño son estados controlados, es decir, sus estados determinan su comportamiento cuando reciben un mensaje
se utilizan diagramas de estado para describir las transiciones de estado de un objeto
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de clases > descripción de métodos y estados
creada
pendiente
planificada
vencida y no pagada
cerrada
enviar()
planificar
cerrar()
[fuera de plazo: retraso en fecha de
pago]
cerrar()
Los objetos Factura cambian de estado según sean creados, enviados, planificados o cerrados. Como todos los objetos de negocio, estos estados cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede ser planificada antes de haber sido enviada.
Una factura se crea cuando un vendedor quiere que un comprador pague un 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 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 estado pasa a cerrada.
Los objetos Factura cambian de estado según sean creados, enviados, planificados o cerrados. Como todos los objetos de negocio, estos estados cambian siguiendo una estricta secuencia. Por ejemplo, una factura no puede ser planificada antes de haber sido enviada.
Una factura se crea cuando un vendedor quiere que un comprador pague un 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 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 estado pasa a cerrada.
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
106 / 125
requisitos especiales
requisitos especialesestudiar 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)
Factura
UnicastRemoteObject Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el Servidor del Comprador y desde el Servidor del Vendedor. La Factura tiene que ser diseñada, pues, para un sistema dsitribuido. En este ejemplo se implementa esta distribución de objetos haciendo la clase Factura una subclase de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la Invocación de Mensajes Remotos (RMI). Este mecanismo de diseño estáidentificado y descrito por el arquitecto en la actividad de diseño arquitectónico.
Los objetos Factura necesitan ser accedidos desde diferentes nodos, desde el Servidor del Comprador y desde el Servidor del Vendedor. La Factura tiene que ser diseñada, pues, para un sistema dsitribuido. En este ejemplo se implementa esta distribución de objetos haciendo la clase Factura una subclase de la clase abstracta de java java.rmi.UnicastRemoteObject, que soporta la Invocación de Mensajes Remotos (RMI). Este mecanismo de diseño estáidentificado y descrito por el arquitecto en la actividad de diseño arquitectónico.
Ejemplo requisito de implementación:
Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz de gestionar 10 clientes de Comprador diferentes sin un retardo perceptible para los compradores.
Ejemplo requisito de implementación:
Un objeto de la clase Procesamiento de Solicitud de pago debe ser capaz de gestionar 10 clientes de Comprador diferentes sin un retardo perceptible para los compradores.
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
diseño orientado a objetos > diseño de clases > requisitos especiales
fuente: El proceso unificado de desarrollo de software, Jacobson, Booch, Rumbaugh
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
107 / 125
Diseño de un subsistema
actividadesdefinición de las dependencias entre subsistemas
definición de las interfaces proporcionadas por el subsistema
refinar los contenidos de los subsistemas
Diseño de la arquitectura
Diseñar un caso de uso
Diseñar una clase
Diseñar un subsistema
Ingeniero de componentesIngeniero de casos de usoArquitecto
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
108 / 125
el diseño estructurado
Los modelos del análisis facilitan la información necesaria para crear los modelos del diseño
DICCIONARIODE DATOS
Diagrama de Flujo de
Datos
Diagrama deTransición de Estados
Diagrama Entidad-Relación
Descripció
n de entidades Especificación de procesos
Especificación de control
Diseñoprocedimental
Diseño deinterfaz
Diseñoarquitectónico
Diseño dedatos
MODELOS DEL ANÁLISISMODELOS DEL ANÁLISIS
MODELOS DEL DISEÑOMODELOS DEL DISEÑOEstructuras de datos necesarias para implementar el software
Estructuras de datos necesarias para implementar el software
Relación entre los principales elementos estructurales del programa
Relación entre los principales elementos estructurales del programa
Cómo se comunica el sistema consigo mismo, con otros sistemas y con los operadores
Cómo se comunica el sistema consigo mismo, con otros sistemas y con los operadores
Descripción procedimental de los componentes del software
Descripción procedimental de los componentes del software
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
109 / 125
conceptos del diseño estructurado
jerarquía de controlOrganizació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.
diseño estructurado > conceptos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
110 / 125
Conceptos del diseño estructurado
M
cba
ed k l m
hgf qpon
ji r
Anchura
grado desalida
grado deentrada
profundidad
diseño estructurado > conceptos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
111 / 125
conceptos del diseño estructurado
función 1
función 2
función 3
partición horizontal
partición vertical
módulos de tomade decisiones
módulos “de trabajo”
PARTICIÓN ESTRUCTURAL
Partición horizontal:ramas separadas para cada función
principal.Beneficios: facilidad de prueba y
mejora, mantenimiento, menos efectos secundarios.
Desventajas: mayor flujo de datos y control global del flujo del programa más complicado.
Partición vertical (factoring): control y trabajo distribuidos de manera descendiente en la arquitectura del programa.
Módulos de nivel superior: control y poco procesamiento.
Módulos de nivel inferior: procesamiento (entradas, cálculos y salida)
Mejor capacidad de mantenimiento.Cambios en módulos de control: más
probabilidad de propagar efectos secundarios, pero son menos habituales.
Cambios en módulos de trabajo: habituales, pero con poca probabilidad de propagar efectos secundarios.
PARTICIÓN ESTRUCTURAL
Partición horizontal:ramas separadas para cada función
principal.Beneficios: facilidad de prueba y
mejora, mantenimiento, menos efectos secundarios.
Desventajas: mayor flujo de datos y control global del flujo del programa más complicado.
Partición vertical (factoring): control y trabajo distribuidos de manera descendiente en la arquitectura del programa.
Módulos de nivel superior: control y poco procesamiento.
Módulos de nivel inferior: procesamiento (entradas, cálculos y salida)
Mejor capacidad de mantenimiento.Cambios en módulos de control: más
probabilidad de propagar efectos secundarios, pero son menos habituales.
Cambios en módulos de trabajo: habituales, pero con poca probabilidad de propagar efectos secundarios.
diseño estructurado > conceptos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
112 / 125
conceptos del diseño estructurado
INDEPENDENCIA FUNCIONAL
• Consecuencia de la modularidad, la abstracción y la ocultación de la información• Módulos con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización
INDEPENDENCIA FUNCIONAL
• Consecuencia de la modularidad, la abstracción y la ocultación de la información• Módulos con “función única” y poca interacción con otros• Más fáciles de mantener y probar• Menos efectos secundarios por modificaciones• Reducida propagación de errores• Facilita la reutilización
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.Diferentes grados de cohesión:
MÓDULO CONTAREA SIMPLE
MÓDULO CON DIVERSASTAREAS POCO O NADARELACIONADAS
ACOPLAMIIENTO
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 comparten.
Objetivo durante el diseño: minimizar el acoplamiento utilizando conexiones sencillas entre los módulos.
Formas de reducir el acoplamiento:• Eliminando relaciones innecesarias• Reduciendo las relaciones necesarias
Beneficios de un bajo acoplamiento:• 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
CONCEPTOSCOMPLEMENTARIOSCONCEPTOS
COMPLEMENTARIOS
Maximizar la cohesión es casi lo mismo que minimizar el acoplamiento
Maximizar la cohesión es casi lo mismo que minimizar el acoplamiento
diseño estructurado > conceptos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
113 / 125
acoplamiento en el diseño estructuradoTI
POS
DE
AC
OPL
AM
IEN
TOTI
POS
DE
AC
OPL
AM
IEN
TO
ACOPLAMIENTO NORMAL
De datos: dos módulos se comunican por parámetros, siendo cada parámetro una porción elemental de datos.
Evitar datos que circulen sin necesidad.Fomentar conexiones formadas por pocos datos.
Compuesto: un módulo pasa al otro un dato compuesto.Introduce una cierta conexión indirecta (Diccionario de Datos)Evitar datos compuestos con subdatos innecesarios.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 lógica interna del segundo.
ACOPLAMIENTO NORMAL
De datos: dos módulos se comunican por parámetros, siendo cada parámetro una porción elemental de datos.
Evitar datos que circulen sin necesidad.Fomentar conexiones formadas por pocos datos.
Compuesto: un módulo pasa al otro un dato compuesto.Introduce una cierta conexión indirecta (Diccionario de Datos)Evitar datos compuestos con subdatos innecesarios.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 lógica interna del segundo.
ACOPLAMIENTO COMÚN
Dos módulos hacen referencia a una misma área de datos globales. No es recomendable por:
Posibilidad de que los errores se trasladen de unos módulos a otros.Baja flexibilidad modularComplica el mantenimientoDiferentes significados de los datos según el módulo que lo utiliceSi 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 específicas y las conexiones son restringidas y controladas, no aleatorias).
ACOPLAMIENTO COMÚN
Dos módulos hacen referencia a una misma área de datos globales. No es recomendable por:
Posibilidad de que los errores se trasladen de unos módulos a otros.Baja flexibilidad modularComplica el mantenimientoDiferentes significados de los datos según el módulo que lo utiliceSi 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 específicas y las conexiones son restringidas y controladas, no aleatorias).
ACOPLAMIENTO DE CONTENIDO
Existe cuando un módulo se refiere de algún modo al contenido de otro. Es más habitual en lenguajes de bajo nivel.Hay que evitarlo pues ataca al concepto de caja negra.
ACOPLAMIENTO DE CONTENIDO
Existe cuando un módulo se refiere de algún modo al contenido de otro. Es más habitual en lenguajes de bajo nivel.Hay que evitarlo pues ataca al concepto de caja negra. +
-
Gra
do d
e ac
opla
mie
nto
diseño estructurado > conceptos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
114 / 125
cohesión en el diseño estructurado
Tarea o elemento de procesamiento:órdenes en el módulo y procesos que resultan de llamadas a módulos subordinados
módulo
Principio asociativo: los elementos de procesamiento o tareas se agrupan en base a algún tipo de pertenencia entre ellos.La cohesión se aplica sobre todos los pares de tareas
Principio asociativo: los elementos de procesamiento o tareas se agrupan en base a algún tipo de pertenencia entre ellos.La cohesión se aplica sobre todos los pares de tareas
Las tareas que se encuentran dentro de un módulo subordinado no figuran en la cohesión del módulo que lo invoca
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 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.
Cohesión lógica: las tareas desarrollan actividades de la misma clase, pero para utilizar el módulo hay que seleccionar la/s actividades que se necesitan
Cohesión casual: las tareas no tienen relación significativa entre ellas
+
-
Gra
do d
e co
hesi
ón
diseño estructurado > conceptos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
115 / 125
el diseño de datos
Diseño de datos:Profunda influencia en la calidad del software:
Influye en la estructura del programaInfluye 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 datos1) 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
Diseñoprocedimental
Diseño de interfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño de datos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
116 / 125
el diseño arquitectónico
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
En cierta forma, el diseño arquitectónicodesarrolla los “planos” del programa
Diseñoprocedimental
Diseño de interfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño arquitectónico
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
117 / 125
el diseño arquitectónicoDiseño
procedimental
Diseño de interfaz
Diseño arquitectónico
Diseño de datos
FLUJO INFORMACIÓN(DFD)
DESCRIPCIÓN ESTRUCTURADA(Diagramas de estructura)
DISEÑO ORIENTADOAL FLUJO DE DATOSDISEÑO ORIENTADO
AL FLUJO DE DATOS
TIPOS DE FLUJOS:
1) De Transformación: a) La información entra en el sistema a lo largo de caminos que transforman los datos
externos a un formato interno: flujo de entradab) Esta información pasa a través de un centro de transformaciónc) Los datos pasan por uno o más caminos que conducen hacia “fuera” del software:flujo de
salida.
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 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.
TIPOS DE FLUJOS:
1) De Transformación: a) La información entra en el sistema a lo largo de caminos que transforman los datos
externos a un formato interno: flujo de entradab) Esta información pasa a través de un centro de transformaciónc) Los datos pasan por uno o más caminos que conducen hacia “fuera” del software:flujo de
salida.
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 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.
1
RECIBIRPEDIDO
Productos Devueltos
2
ENVIARPEDIDO
4
RECIBIRDEVOLUCIONES
5GENERARINFORMES VENTAS
3
GESTIONARSTOCKStock
Detalles_Pedido
Clientes
Representante Ventas
Cliente
Pago_Cliente
Pedido ClientePedido_Proveedor
Pago_Proveedor
Producto_Stock
Factura_Proveedor
Petición_Comprobación_Crédito
Detalles_Crédito
Informe_Ventas
Factura_Cliente
Envío_Cliente
Devolución_Cliente
Reintegro_Cliente
Producto_DevueltoNúmero_Empleado
Cliente
Detalles_Pedido
Producto_DevueltoDirección_Envío
Nombre_Empleado_y_Supervisor
Políticas_Ventas_y_Cuotas
Confirmación_Pedido
Dirección_Factura
Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:
Sample Yourdon process modelc:\ecwin\samples\yddfd\dfd0.dfdProcess OrdersFeb-18-1993Wayne McDonaldDec-12-1993EasyCASE
diseño estructurado > diseño arquitectónico
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
118 / 125
el diseño arquitectónico
Análisis de transformaciónRevisar 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)
Diseñoprocedimental
Diseño de interfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño arquitectónico
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
119 / 125
el diseño arquitectónico
Análisis de transacciónRevisar 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 detransacción
Diseñoprocedimental
Diseño de interfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño arquitectónico
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
120 / 125
el diseño arquitectónico
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 rendimientoSimular el rendimiento en tiempo de ejecuciónSeleccionar los módulos que ocupen demasiado tiempo y rediseñarlosCodificarAislar, rediseñar o recodificar para mejorar la eficiencia
Diseñoprocedimental
Diseño de interfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño arquitectónico
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
121 / 125
el diseño de interfaz
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
Diseñoprocedimental
Diseño deinterfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño de interfaz
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
122 / 125
el diseño de interfaz
Diseñador deinterfaces
MODELO DE DISEÑO:Representaciones de datos, arquitectónicas, de interfaces y procedimentales. El diseño de interfaz suele ser secundario con respecto a éste, excepto en sistemas altamente interactivos.
MODELO DE USUARIO:Perfil de los usuarios finales del sistema (edad, capacidades físicas, estudios, nivel cultural, motivación,...). Pueden ser usuarios novatos, esporádicos o frecuentes.
PERCEPCIÓN DEL SISTEMA:imagen del sistema que percibe el usuario final. La exactitud de su descripción dependerá de su perfil.
IMAGEN DEL SISTEMA:Combinación del aspecto externo del sistema con toda la información de soporte que describen sintaxis y semántica del sistema.
Cuando coinciden, los usuarios se sienten a gusto con el software y lo utilizan eficazmente.
Cuando coinciden, los usuarios se sienten a gusto con el software y lo utilizan eficazmente.
Diseñoprocedimental
Diseño deinterfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño de interfaz
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
123 / 125
el diseño de interfaz
aspectos del diseño de interfaz persona-máquinatiempo de respuesta
duraciónvariabilidad
mensajes de errordescripción del problemainformación constructiva.consecuencias negativas posiblesseñal audible o visibleevitar juicios al usuario
etiquetado de órdenespoco habituales en entornos visualesórdenes para todas las opcionesformato de las órdenesfacilidad de aprendizaje y de recordarmacros de órdenesconvenios para uso en diferentes aplicaciones
ayuda al usuariointegradaagregada
Diseñoprocedimental
Diseño deinterfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño de interfaz
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
124 / 125
el diseño de interfaz
DIRECTRICES INTERACCIÓN
Consistencia de formatoRespuestas significativasVerificación de acciones destructivasDeshacer accionesEficiencia diálogo: distancia que debe moverse el ratón,...Autoprotección del sistema ante erroresCohesión órdenes y acciones: organización de órdenes por tipoAyudas sensibles al contextoVerbos y frases sencillos para las órdenes
DIRECTRICES INTERACCIÓN
Consistencia de formatoRespuestas significativasVerificación de acciones destructivasDeshacer accionesEficiencia diálogo: distancia que debe moverse el ratón,...Autoprotección del sistema ante erroresCohesión órdenes y acciones: organización de órdenes por tipoAyudas sensibles al contextoVerbos y frases sencillos para las órdenes
DIRECTRICES ENTRADA DE DATOS
Minimizar número acciones entrada: reducir la cantidad de escritura necesaria, usando el ratón, macros,...Consistencia visualización-introducciónPersonalizar entrada: órdenes personalizadas, eliminar mensajes de advertencia y verificación,...Interacción personalizada: por ejemplo, escoger teclado o ratón.Desactivar órdenes inapropiadasEliminar entradas innecesarias: .00 en cantidades enteras, información disponible automáticamente o que se puede calcular,...
DIRECTRICES ENTRADA DE DATOS
Minimizar número acciones entrada: reducir la cantidad de escritura necesaria, usando el ratón, macros,...Consistencia visualización-introducciónPersonalizar entrada: órdenes personalizadas, eliminar mensajes de advertencia y verificación,...Interacción personalizada: por ejemplo, escoger teclado o ratón.Desactivar órdenes inapropiadasEliminar entradas innecesarias: .00 en cantidades enteras, información disponible automáticamente o que se puede calcular,...
DIRECTRICES VISUALIZACIÓN
Información relevante en el contexto actualNo abrumar con datos: usar gráficos y esquemasMantener contexto visualEtiquetas consistentes, abreviaciones estándar y colores predeciblesMensajes de error significativosUso de ventanasPresentaciones analógicasGeografía de la pantalla
DIRECTRICES VISUALIZACIÓN
Información relevante en el contexto actualNo abrumar con datos: usar gráficos y esquemasMantener contexto visualEtiquetas consistentes, abreviaciones estándar y colores predeciblesMensajes de error significativosUso de ventanasPresentaciones analógicasGeografía de la pantalla
DIRECTRICES PARA EL DISEÑO DE INTERFACES HOMBRE -MÁQUINA
DIRECTRICES PARA EL DISEÑO DE INTERFACES HOMBRE -MÁQUINA
Diseñoprocedimental
Diseño deinterfaz
Diseño arquitectónico
Diseño de datos diseño estructurado > diseño de interfaz
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 4 – diseño del software
125 / 125
bibliografía
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