Please enable JavaScript.
Coggle requires JavaScript to display documents.
DISEÑO ARQUITECTÓNICO dise-o-arquitectonico_orig - Coggle Diagram
DISEÑO ARQUITECTÓNICO
Sistemas Distribuidos
el procesamiento de la información se distribuye sobre varias computadoras.
Por seguridad e interoperabilidad
se ha utilizado sobre todo computación distribuida
intraorganizacional
Ventajas:
compartición de recursos
apertura
concurrencia
escalabilidad
tolerancia a defectos
Desventajas:
complejidad
seguridad
manejabilidad
impredecibilidad del sistema
Sistemas peer-to-peer (p2p).
Son sistemas descentralizados
los cálculos se pueden realizar en cualquier nodo de la red
no se distingue, a priori, entre clientes y servidores.
diseñados para aprovechar
la ventaja de potencia computacional
disponibilidad de almacenamiento de grandes redes.
Utilizan estándares y protocolos de comunicaciones embebidos en la propia aplicación
y cada nodo ejecuta una copia de la misma.
Teóricamente cada nodo en la red puede conocer a cualquier otro nodo
se organizan por “localidades” con nodos-puente entre ellas.
Existen dos arquitecturas p2p:
Arquitectura descentralizada
Muy redundante y por lo tanto tolerante a fallos
puede sufrir sobrecargas y replicaciones de
comunicación.
Arquitectura semicentralizada:
Los nodos actúan como servidores para facilitar las comunicaciones
los nodos se establecen conexiones directas y no es necesario el servidor.
Calidad y diseño del software
proporciona representaciones del software
se puede evaluar la calidad del mismo
permite una “traducción” correcta de los requisitos en un programa
(implementación, prueba y mantenimiento).
sirve como fundamento para las actividades posteriores
El resultado de un proyecto sin diseño
construcción de un sistema poco fiable
se escapa al control de sus creadores
es difícil de corregir y mejorar
sistemas ineficientes
suelen ser poco flexibles y por lo tanto difíciles de
mantener
no escalable y difícil de probar
Sistemas de sistemas orientados a servicios
El desarrollo de la www permitió que se pudiera acceder a información de otras organizaciones bajo el formato HTML.
Servicio web
Componentes:
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
incluye código para llamar al servicio y procesa el resultado.
Representación estándar para cualquier recurso computacional o de información que pueda ser usado por otros programas.
Permite que la provisión de un servicio sea independiente de la aplicación que lo utiliza.
Las organizaciones pueden hacer accesible información a diferentes programas
definiendo y publicando una interfaz de servicio web
que defina los datos y su forma de acceso.
Ventajas:
Los usuarios pueden pagar por los servicios sólo en función del uso. No hay por qué comprar componentes caros que rara vez se utilicen.
Aplicaciones más pequeñas
(manejos de excepciones como servicios externos)
Construcción a medida de nuevos servicios, enlazando servicios existentes.
Diseño Arquitectónico
Las actividades principales son decisiones:
Estructuración del sistema en varios subsistemas principales.
Descomposición modular donde cada subsistema se divide en componentes o módulos interconectados.
Descomposición modular donde cada subsistema se divide en componentes o módulos interconectados.
Construye una salida
serie de documentos con diversas perspectivas de la arquitectura del sistema:
Modelo estructural estático
Describe subsistemas o componentes a
desarrollar como unidades separadas.
Modelo de proceso dinámico
Describe la organización del sistema en
tiempo de ejecución.
Modelo de interfaz
Describe la definición de los servicios ofrecidos por cada subsistema a través de su interfaz pública.
Modelos de relación
Describe las relaciones entre los distintos módulos o subsistemas, por ejemplo: los flujos de datos entre subsistemas.
Modelo de distribución
Describe como se distribuyen los subsistemas entre los componentes físicos (computadores, nodos de red…)
En función de requisitos no funcionales
Las principales condiciones no funcionales y sus
“restricciones” son:
Rendimiento
Si se necesita un elevado rendimiento se utilizarán pocos subsistemas con poca comunicación.
Protección
Las aplicaciones con elevado nivel de seguridad necesitarán estructurarse en capas con los recursos críticos protegidos
en las capas más internas
y contarán con elevados niveles de validación.
Disponibilidad
Puede obligar a incluir componentes redundantes que puedan reemplazarse y actualizarse sin detener el sistema.
Mantenibilidad
Mejora cuando se utilizan componentes más pequeños que pueden intercambiarse con facilidad.
El proceso de diseño inicial que identifica estos subsistemas y establece como se lleva a cabo su control y comunicación
Los grandes sistemas siempre se descomponen en subsistemas que proporcionan conjuntos de servicios relacionados.
Descomposición Modular
Después de diseñar la arquitectura estructural se descomponen los subsistemas en módulos
Modelos principales de descomposición modular:
Modelo orientado a objetos
El sistema se descompone en un conjunto de objetos que se comunican entre ellos
Los módulos son objeto con estado privado y operaciones definidas sobre ese estado.
Entidades reales fácilmente comprensibles, mejor reutilización.
Difícil representar entidades más complejas.
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.
Los datos fluyen de una función a otra y se van transformando
Incluye información sobre la secuencia de operaciones y resulta intuitivo para ciertas
personas.
Modelado de Control
Representa 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 de forma acorde a un modelo de control.
Existen dos modelos de control genéricos:
Control centralizado
Un subsistema es el responsable de controlar, iniciar y detener otros subsistemas
Existen dos clases:
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 diferentes niveles del árbol.
No es un modelo estructural por lo que no es necesario que, por ejemplo, la Rutina 1.1 forme parte de la Rutina 1.
Utilizado por lenguajes de programación como Ada, Pascal y C aunque también con
lenguajes Orientados a Objetos (OO).
Ventaja:
Es relativamente sencillo analizar los flujos de control
conocer cómo responderá el sistema a cierto tipo de entradas.
Inconveniente:
Las excepciones a operaciones normales son complicadas de gestionar.
Modelo del administrador (concurrente)
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 de pasarles información para el procesamiento.
Un proceso es un subsistema o módulo que se ejecuta en paralelo con otros procesos.
Utilizado en sistemas de tiempo real “suaves”, es decir, con restricciones de tiempo no muy estrictas.
Llamado también modelo de ciclos de eventos.
Control dirigido por eventos:
Existen dos tipos de modelos dirigidos por eventos:
Modelos de transmisión (broadcast)
Los subsistemas registran un interés en eventos
específicos
y cuando ocurren esos eventos el control se transfiere al subsistema que puede manejar el evento.
el controlador asegura que estos eventos sean enviados a dichos subsistemas.
Los subsistemas deciden que eventos requieren
son utilizados por los agentes de solicitud de objetos (ORBs)
para comunicaciones de objetos distribuidos.
Ventajas:
La evolución es relativamente sencilla pues se pueden integrar nuevos subsistemas registrando sus eventos en el controlador de eventos.
Cualquier subsistema puede activar otros subsistemas sin conocer su nombre o ubicación.
Los subsistemas se pueden implementar en máquinas distribuidas de forma transparente para otros subsistemas.
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 han registrado un interés en ese evento
Modelos dirigidos por interrupciones
Especialmente útiles para sistemas de tiempo
real que necesitan manejar rápidamente eventos generados desde el exterior.
Se pueden combinar con el modelo de administrador centralizado
de manera que el administrador central maneja la ejecución normal el sistema
utilizando el control basado en
interrupciones para casos de emergencia.
Interrupciones:
Existen varios tipos de interrupciones conocidas con un controlador definido para cada tipo.
Cada tipo de interrupción se asocia con la ubicación de memoria en la que se almacena la dirección del controlador.
Cuando se recibe una interrupción de un determinado tipo, un interruptor de hardware transfiere el control al controlador adecuado.
El controlador puede iniciar o detener otros procesos en respuesta a los eventos recibidos por el interruptor
Ventajas:
Permite dar respuestas muy rápidas a los eventos.
Desventajas:
Complejo de programar y difícil de validar
(replicación de ocurrencias)
Si el número de interrupciones está limitado por el hardware, cuando se alcanza el límite no se pueden gestionar más tipos de eventos.
Cada subsistema puede responder a eventos generados en el exterior provenientes de otros subsistemas o del entorno del sistema.
Organización del sistema Arquitectura
Definición genérica para todos los modelos:
se basa en la identificación de subsistemas o capas
desarrollar de forma independiente
relaciones entre subsistemas
efectivo para la comunicación
entre los participantes en el proyecto
realizar el reparto de tareas
entre distintos grupos o recursos.
Los modelos organizacionales más usados son:
Modelo de repositorios
todos los datos compartidos se ubican en una base de datos central a la que acceden todos los subsistemas
Resulta útil en sistemas que emplean grandes cantidades de datos
Ventajas
Compartición eficiente
Se comparten grandes cantidades de datos sin necesidad de transmitir datos explícitamente de un subsistema a otro.
Ligera abstracción el manejo de datos
Los subsistemas que producen datos no necesitan saber cómo son utilizados por otros subsistemas.
Centralización
Centralización de actividades de administración del repositorio
(respaldo, seguridad, control de acceso y recuperación de errores).
Integración directa
Las herramientas compatibles con el modelo de datos se integran directamente.
Desventajas
Modelo de datos común
Los subsistemas deben utilizar un mismo modelo de datos que el que esté implementado en el repositorio
Difícil integración de subsistemas “externos”
. Resulta muy difícil o incluso imposible integrar subsistemas
cuyos modelos de datos no se ajusten al esquema del repositorio
Dificulta la evolución
Genera un gran volumen de información y es difícil hacer evolucionar el sistema.
Estandarización de las políticas
Diferentes subsistemas pueden tener diferentes
políticas de seguridad, de recuperación y respaldo
pero el repositorio impone la misma política a todos los subsistemas.
Dificultad para distribuir
Difícil distribuir el repositorio en varias máquinas por los posibles problemas de inconsistencia
o de redundancia de datos.
Modelo Cliente-Servidor
Componentes:
Conjunto de servidores
Servidores independientes que ofrecen servicios a otros subsistemas
(servidores de impresión, de administración de archivos…).
Conjunto de clientes
Los clientes invocan los servicios ofrecidos por los servidores mediante un protocolo de petición-respuesta
Una red
Un sistema de comunicación que permita a los clientes acceder a los servicios
(no es estrictamente necesario).
Modelo cliente-servidor en Dos capas
Modelo de “cliente delgado.”
Ventajas:
Se suele utilizar cuando se heredan sistemas centralizados.
La interfaz migra a los PC’s.
La aplicación misma actúa como servidor y maneja todo el procesamiento y la administración de los datos.
Desventajas
Implica una gran carga de procesamiento para el servidor.
El servidor realiza todos los cálculos, lo que provoca una gran cantidad de tráfico en la red entre el cliente y el servidor.
Desaprovecha la capacidad de cálculo de las máquinas de los procesos cliente.
Todo el procesamiento de la aplicación y la
administración de datos se realiza en el servidor.
Modelo de “cliente grueso”.
Ventajas:
Distribuye al cliente el procesamiento lógico y la presentación.
Aprovecha la capacidad de procesamiento de los clientes.
Los ATM no se conectan directamente a la base de datos del cliente sino al gestor de transacciones.
Desventajas:
Administración del sistema más compleja al distribuirse la funcionalidad de la aplicación.
Aumenta el coste del mantenimiento ya que es necesario la reinstalación o actualización de cada computador si la aplicación cambia.
El servidor sólo es responsable de la administración de datos
La arquitectura cliente-servidor más simple
La aplicación se organiza como un servidor y un conjunto de clientes.
Modelo cliente-servidor en Tres capas
Componentes:
Administración de datos
Suministrado por la base de datos
(normalmente es un mainframe).
Servicios de aplicación
Suministrados por un servidor Web.
Presentación
El cliente es el computador del usuario con un sistema de presentación o interfaz.
La principal ventaja
con respecto al sistema en dos capas
es escalable de forma sencilla
Las tres capas son procesos separados lógicamente
se ejecutan en procesadores separados
Son más escalables que las arquitecturas en dos niveles.
Este modelo de sistema se organiza como un conjunto de servicios y servidores asociados
junto con los clientes que acceden y usan dichos servicios.
La ventaja más importante:
es que es un modelo de sistemas distribuido
no existe una relación 1:1 entre procesos y procesadores
El diseño debe reflejar la estructura lógica de la aplicación:
Capa de presentación
Esta capa se encarga de mostrar la información e interactuar con el usuario.
Capa de procesamiento de la aplicación
Esta capa implementa la lógica de la aplicación.
Capa de administración de datos
En esta capa se realizan todas las operaciones de la base de datos.
Modelo de capas (máquina abstracta)
Modela la interacción entre subsistemas mediante una organización en capas
cada capa presta servicios a la capa inmediatamente superior
actúa como cliente de la inferior (en la
que queda encerrada)
El diseño incluye los protocolos que establecen cómo interactuará cada par de capas
Ventajas
Preservando la interfaz, una capa se puede reemplazar por otra.
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 pues es posible que el usuario requiera acceso a capas internas lo que subvierte el modelo
El rendimiento puede resultar afectado por los múltiples niveles de interpretación de órdenes que se requieran
Introducción, Objetivos del diseño
Para la transformación del modelo de análisis en un modelo de diseño del sistema
se definen los objetivos de diseño del proyecto
se descompone el sistema en subsistemas más pequeños que pueden ser realizados por diferentes equipos
se seleccionan estrategias para la construcción del sistema
El modelo de diseño:
Descripción clara de las estrategias.
Descomposición en subsistemas.
Diagramas que muestran la correspondencia entre hardware y software.
Modelo de objetos que describe la realización física de los casos de uso.
Muestra el impacto en el sistema de requisitos funcionales, no funcionales y restricciones.
Sirve de abstracción de la implementación del sistema, convirtiéndose en la entrada fundamental de las actividades de implementación.
Ventajas del modelo de diseño:
Reutilización a gran escala: posibilidad de tener partes ya hechas del sistema.
Gestión de la complejidad: descomposición del problema.
Herramienta de comunicación entre los participantes.
Análisis más detallado del sistema.
