Diseño > Arquitectura

Información de la versión

Proyecto: Herramienta de Gestión de Expediente
Número Interno de Versión: 0.1.0
Documentos Relacionados:
LIGAS A ESTÁNDARES RELEVANTES
LIGAS A OTROS DOCUMENTOS
TAREAS: Responda a las preguntas que se encuentran abajo para ayudarlo a definir la arquitectura de su sistema. Se incluyen textos de ejemplo.

Resumen

¿Cuáles son los hechos más importantes que un desarrollador debería saber acerca de esta arquitectura de sistema?
PÁRRAFO o VIÑETAS
¿Que estilo de arquitectura de software está siendo usado?
Aplicación de escritorio para proceso simple (con módulos de extensión de plug-ins).
Cliente-servidor con clientes delgados y servidor personalizados.
Aplicación Web de 2-puertos: servidor web/servidor de aplicaciones, base de datos.
Aplicación Web de 3-puertos: servidor web/servidor de aplicaciones, base de datos.
Servicio web simple: servidor de aplicaciones, base de datos.
Servicios de Red o Web.
Cliente-a-cliente sin servidor central.
Con tuberías y filtros.
Malla de computadoras / servidores distribuidos.
¿Cuáles son los objetivos clasificados de esta arquitectura?
  1. Facilidad de integración
  2. Extensibilidad
  3. Ajuste a la capacidad

Componentes

¿Cuáles son los componentes de este sistema?
Los componentes de este sistema estan definidos claramente en este Diagrama UML con Diagrama de Componentes.
Los componentes de este sistema se encuentran listados abajo por tipo:

Entrega

¿Cómo serán entregados los componentes a los procesos o los equipos?
La entrega de componentes a los procesos y a los equipos se encuentra claramente definida en este Modelo UML con Diagrama de Entrega.
La entrega de componentes a los procesos y los equipos se encuentra claramente definida a continuación:
La entrega de componentes a los procesos y los equipos se encuentra claramente definida a continuación:
¿Qué aspectos/recursos de su ambiente se encuentran compartidos?
Todo se encuentra en un solo servidor de forma que todos los recursos de los equipos se encuentran compartidos por todos los componentes.
Todas los equipos comparten el mismo ancho de banda hacia Internet. Todos los equipos accesan el mismo servidor de archivos. Así que, si un componente hace uso de los recursos intensivamente, los otros componentes tendrán que esperar.
¿Cómo son manejadas las respuestas en los servidores redundantes o de balance de carga?
No estamos haciendo ninguna clase de balance de carga o redundancia en caso de fallas.
El balance de la carga es manejado en los servidores frontales por un dispositivo de balance de carga del que podemos pocas suposiciones. De cualquier forma, una vez que se ha establecido una sesión de usuario, el mismo srvidor frontal se utilizará para todas las solicitudes durante esa sesión.
¿Qué alternativas de configuraciones de entrega son posibles?
Solo hay una forma de entrega posible.
La base de datos podría ser movida a un equipo diferente con un cambio relativamente sencillo a un archivo de configuración. De otra forma no se puede cambiar nada respecto a la entrega.
Tenemos la habilidad de mover el proceso de la base de datos a un equipo separado. Tenemos la habilidad de añadir más servidores frontales. La lógica de la aplicación que corre en el servidor de aplicaciones no puede se dividida o balanceada.

Integración

¿Cómo serán integrados los componentes? Específicamente, ¿cómo se communicarán?
Todo nuestro código utiliza llamadas directas a procedimiento. La base de datos es accesada con un controlador.
Los componentes dentro del mismo proceso usan llamdas directas a procedimientos o eventos Java estándar. Los plug-ins son accesados también por medio de una API de llamadas directas a procedimientos y eventos estándar. La comunicación con la base de datos utiliza un controlador JDBC. La comunicación entre los servidores frontales y los de procesos utlliza XML-RPC.
¿Qué mecanismos arquitecturales se utilizan para facilitar futuras extensiones o modificaciones?
Podriamos cambiar la base de datos cambiando los controladores. De otra forma las extensiones y las modificacione solo pueden ser hechas a nivel de diseño.
Nuevos componentes frontales podrían ser añadidos mientras accesen hacia atrás de la misma forma. Nuevos componentes de plug-in pueden ser cargados dinámicamente, mientras satisfagan la API de plug-ins. De otra manera, no será posible añadir o cambiar componentes, debido a que esta arquitectura utiliza dependencias directas entre sus componentes en lugar de invocación implícita. Las extensiones y modificationes pueden ser hechas a nivel de diseño, pero añadir estos cambios requiere recompilación y tiempo fuera de línea.

Escenarios de Arquitectura

TAREAS: Provea escenarios de arquitectura que muestren como los objetos se comunicarán mediante componentes, procesos y equipos. Concéntrese en escenarios donde la arquitectura misma este cambiando, por ejemplo, inicio del sistema, apagado, mientras se añaden o actualizan componentes, en balance de carga o en caída.

La siguiente secuencia de diagramas brinda descripciones paso a paso de cómo los componentes se comunican en algunos escenarios importantes de uso:

Lista de pendientes de arquitectura

TAREAS: Evalue su arquitectura respecto a cada uno de sus objetivos.
Facilite la integración: ¿se han previsto mecanismos para cada tipo necesario de integración?
Sí. En este sistema, todos los componentes están diseñados para trabajar juntos. Y los componentes reusados son integrados con interfaces simples.
Extensibilidad: ¿Qué tipos de componentes pueden ser añadidos después y cómo?
Véase arriba.
Ajuste a la Capacidad: ¿Cómo esta arquitectura se ha ajustado las necesidades de recursos de los componentes a los equipos?
La base de datos puede estar en un equipo con discos RAID y una fuente de poder intercambiable, mientras los componentes frontales pueden estar en euqipos más baratos que pueden fallar individualmente sin causar caídas al sistema. Los servidores frontales y el servidor de aplicaciones utlizan intensivamente el poder de procesamiento, por lo que serán montados en diferentes equipos. La base de datos hace uso intensivo del disco, por lo que puede ser instalada en el mismo equipo que el servidor de aplicaciones con solo una moderada competencia por recursos.
2004-2011 United Nations Development Programme