Please enable JavaScript.
Coggle requires JavaScript to display documents.
Diseño arquitectónico - Coggle Diagram
Diseño arquitectónico
Organización del sistema
Modelo Cliente-Servidor
se organiza como un conjunto de servicios y servidores asociados
junto con los clientes que acceden
Componentes
Conjunto de clientes
Los clientes invocan los servicios ofrecidos por los servidores mediante un protocolo
Una red
Un sistema de comunicación que permita a los clientes acceder a los servicios
Conjunto de servidores
Servidores independientes que ofrecen servicios a otros
subsistemas
un modelo de sistemas distribuido
no existe una relación 1:1 entre procesos y procesadores
suele ser de tres
capas
Capa de procesamiento de la aplicación
Capa de administración de datos
Capa de presentación
Modelo de repositorios
ventajas
Ligera abstracción el manejo de datos
Centralización
Integración directa
Compartición eficiente
desventajas
Difícil integración de subsistemas externos
Dificulta la evolución
Modelo de datos común
Estandarización de las políticas
Dificultad para distribuir
todos los datos compartidos se ubican en una base de datos central
Modelo cliente-servidor en Tres capas
procesos separados lógicamente que se
ejecutan en procesadores separados
Componentes
Servicios de aplicación
Presentación
Administración de datos
ventaja con respecto al sistema en dos capas es que es escalable de forma sencilla
Modelo cliente-servidor en Dos capas
La arquitectura cliente-servidor más simple es un modelo en dos capas
Modelo de cliente delgado
ventajas
La interfaz migra a los PC’s
La aplicación misma actúa como servido
Se suele utilizar cuando se heredan sistemas centralizados
desventajas
El servidor realiza todos los cálculos
Desaprovecha la capacidad de cálculo de las máquinas
Implica una gran carga de procesamiento para el servidor
administración de datos se realiza en el servidor
El cliente únicamente es responsable
de la presentación del os datos.
Modelo de cliente grueso
Ventajas
Distribuye al cliente el procesamiento lógico y la presentación
Los ATM no se conectan directamente a la base de datos del cliente sino al
gestor de transacciones
Aprovecha la capacidad de procesamiento de los clientes
Desventajas
Administración del sistema más compleja al distribuirse la funcionalidad de la
aplicación
Administración del sistema más compleja al distribuirse la funcionalidad de la
aplicación
. El servidor sólo es responsable de la administración de
datos
software del cliente implementa toda o gran parte de la lógica de la
aplicación
problemas
poco escalable y su rendimiento es menor
identificación de subsistemas o capas
clave a desarrollar de forma independiente
las relaciones entre subsistemas
Modelo de capas (máquina abstracta)
ventajas
Preservando la interfaz
Cuando cambian las interfaces de las capas sólo afecta a
las capas adyacentes
Sólo hay que reimplementar las capas más internas
desventajas
Resulta difícil estructurar los sistemas
El rendimiento puede resultar afectado por los múltiples niveles de interpretación de
órdenes que se requieran
cada capa
presta servicios a la capa inmediatamente superior
Por ejemplo las arquitecturas de red OSI y TCP/IP
El diseño incluye los protocolos que establecen cómo interactuará cada par de capas
Sistemas de Sistemas Orientados a Servicios
Servicio web
provisión de un servicio sea independiente
accesible información
interfaz de servicio web
Representación estándar
Componentes de un servicio web
Proveedor de servicios
Desarrollan y ofertan servicios a usuarios
permiten construir
aplicaciones enlazando servicios de diferentes proveedores
Solicitante del servicio
Enlaza este servicio a su aplicación
Diferentes tipos que se ajustan al mismo modelo
Ventajas
x Aplicaciones más pequeñas
Construcción a medida de nuevos servicios
Los usuarios pueden pagar por los servicios sólo en función del uso
Estándares basados en XML
WSDL
Define como pueden representarse las
interfaces de servicios web
UDDI
Estándar de búsqueda que
define como puede organizarse la información de descripción de servicios
SOAP
Define una organización para intercambio de
datos estructurados entre servicios web
Sistemas Distribuidos
ventajas
concurrencia
escalabilidad
apertura
tolerancia a defectos
compartición de recursos
desventajas
seguridad
manejabilidad
se centran en la complejidad
impredecibilidad del sistema
el
procesamiento
se distribuye sobre varias computadoras
Modelado de Control
Control por eventos
Modelos de
Transmisión
Ventajas
Cualquier subsistema puede activar otros subsistemas
Los subsistemas se pueden implementar en máquinas distribuidas
La evolución es relativamente sencilla
Desventajas
Los subsistemas no saben si los eventos se manejarán ni cuando lo harán
Cuando un subsistema genera un evento no sabe que otros subsistemas
Se diferencia del control centralizado
sino que los subsistemas
deciden qué eventos requieren
el controlador asegura que
estos eventos sean enviados
agentes de solicitud de objetos (ORBs)
Modelos
dirigidos por Interrupciones
útiles para sistemas de tiempo real
Se pueden combinar con el modelo de administrador centralizado
Interrupciones
un interruptor de hardware transfiere el control al
controlador adecuado
El controlador puede iniciar o detener otros procesos
Cada tipo de interrupción se asocia con la ubicación de memoria
Existen varios tipos de interrupciones conocidas con un controlador
Desventajas
número de interrupciones está limitado por el hardware
Complejo de programar y difícil de validar
Ventajas
Permite dar respuestas muy rápidas a los eventos
Se rigen por eventos generados en el exterio
Modelos de transmisión (broadcast)
Los subsistemas registran un interés
Modelos dirigidos por interrupciones
. Especialmente útiles para sistema
Control centralizado
ventajas
Es relativamente sencillo analizar los flujos de control
desventajas
módulo que se ejecuta en
paralelo con otros procesos
Utilizado en sistemas de tiempo real suaves
Un componente del sistema se designa como administrador
Llamado también modelo de ciclos de eventos
Las excepciones a operaciones normales son complicadas de gestionar
Modelo de llamada-retorno (ejecución secuencial)
El control se inicia en la parte superior de una jerarquía
No es un modelo estructural
Utilizado por lenguajes de programación como Ada, Pascal y C
El arquitecto organiza los subsistemas de forma acorde a un modelo de control
Existen dos modelos de control genéricos
Control centralizado
Un subsistema es el responsable de controlar
Control basado en eventos
Cada subsistema puede responder a eventos generados
en el exterior
Sistemas peer-to-peer (p2p).
Son sistemas descentralizados
están diseñados para aprovechar la ventaja de potencia computacional
Existen dos arquitecturas p2p
Arquitectura descentralizada
tolerante a fallos
uede sufrir sobrecargas
Arquitectura semicentralizada
Los nodos actúan como
servidores para facilitar las comunicaciones
Descomposición modular
Modelo orientado a objetos
Los módulos son objeto con estado privado
operaciones definidas sobre ese estado
Entidades reales fácilmente comprensibles, mejor reutilización
El sistema se descompone en un conjunto de objetos que se comunican entre ellos
Difícil representar entidades más complejas
Modelo de flujo de datos (o estructurado)
Los datos fluyen de una función a otra y se van transformando
Incluye información sobre la secuencia de operaciones
resulta intuitivo para ciertas
personas
El sistema se descompone en módulos funcionales
No existe una distinción rígida entre la
descomposición del sistema
y la descomposición
modular
Calidad y Diseño del software
diseño de calidad
se puede evaluar
la calidad
permite un entendimiento correcto de los requisitos
fundamento para las actividades posteriores
Sin diseño
riesgo de construir un sistema inestable
no escalable y difícil de probar
grandes dificultades en la gestión del proyecto
sistema poco fiable
poco flexibles y por lo tanto difíciles de
mantener
Diseño Arquitectónico
se descomponen en
subsistemas
proporcionan conjuntos de servicios
relacionados
actividades principales
Descomposición modular
Modelado del control
Estructuración del sistema
Modelo estructural estático
Modelo de interfaz
Modelo de proceso dinámico
Modelos de relación
Modelo de distribución
puede estar en función de requisitos no funcionales
Protección
elevado nivel de seguridad necesitarán estructurarse
en capas
Disponibilidad
Puede obligar a incluir componentes redundantes
Rendimiento
se utilizarán pocos subsistemas
con poca comunicación
Mantenibilidad
se utilizan componentes más pequeños
Objetivos del Diseño
modelo de diseño
se descompone el sistema en subsistema
se seleccionan estrategias para la
construcción
El modelo de diseño
Diagramas que muestran la correspondencia
entre hardware y software
Modelo de objetos que describe la realización
física de los casos de uso
Descomposición en subsistemas
Muestra el impacto en el sistema de requisitos funcionales, no funcionales y
restricciones
Descripción clara de las estrategias
Sirve de abstracción de la implementación del sistema
Ventajas del modelo de diseño
Gestión de la complejidad
descomposición del problema
Herramienta de comunicación entre los participantes
Reutilización a gran escala
posibilidad de tener partes ya hechas del sistema
Análisis más detallado del sistema
