- Definir los módulos principales
- Definir las responsabilidades que tendrá cada uno de estos módulos
- Definir la interacción que existirá entre dichos módulos:
- Control y flujo de datos
- Secuenciación de la información
- Protocolos de interacción y comunicación
- Ubicación en el hardware
Características:
· Parte del diseño de software.
· Nivel del diseño de software donde se definen la estructura y propiedades globales del sistema.
· Incluye sus componentes, las propiedades observables de dichos componentes y las relaciones que se establecen entre ellos.
· Un aspecto crítico: Una arquitectura errónea puede llevar a problemas incontables
· Representación de alto nivel de la estructura del sistema describiendo las partes que lo integran.
· Puede incluir los patrones que supervisan la composición de sus componentes y las restricciones al aplicar los patrones.
· Trata aspectos del diseño y desarrollo que no pueden tratarse adecuadamente dentro de los módulos que forman el sistema.
Objetivos
· Comprender y mejorar la estructura de las aplicaciones complejas.
· Reutilizar dicha estructura (o partes de ella) para resolver problemas similares.
· Planificar la evolución de la aplicación, identificando las partes mutables e inmutables de la misma, así como los costes de los posibles cambios.
· Analizar la corrección de la aplicación y su grado de cumplimiento respecto a los requisitos iniciales.
· Permitir el estudio de alguna propiedad específica del dominio.
Modelos
Modelos estructurales: Sostienen que la AS está compuesta por componentes, conexiones entre ellos y (usualmente) otros aspectos tales como configuración, estilo, restricciones, semántica, análisis, propiedades, racionalizaciones, requerimientos, necesidades de los participantes. El trabajo en esta área está caracterizada por el desarrollo de lenguajes de descripción arquitectónica (ADLs).
Modelos de framework: Son similares a la vista estructural, pero su énfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composición. Los modelos de framework a menudo se refieren a dominios o clases de problemas específicos. El trabajo que ejemplifica esta variante incluye arquitecturas de software específicas de dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes específicos, como PRISM.
Modelos dinámicos: Enfatizan la cualidad conductual de los sistemas. “Dinámico” puede referirse a los cambios en la configuración del sistema, o a la dinámica involucrada en el progreso de la computación, tales como valores cambiantes de datos.
Modelos de proceso: Se concentran en la construcción de la arquitectura, y en los pasos o procesos involucrados en esa construcción. En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el actual trabajo sobre programación de procesos para derivar arquitecturas.
Modelos funcionales: Una minoría considera la arquitectura como un conjunto de componentes funcionales, organizados en capas que proporcionan servicios hacia arriba. Es tal vez útil pensar en esta visión como un framework particular.
Ninguna de estas vistas excluye a las otras, ni representa un conflicto fundamental sobre lo que es o debe ser la AS. Por el contrario, representan un espectro en la comunidad de investigación sobre distintos énfasis que pueden aplicarse a la arquitectura: sobre sus partes constituyentes, su totalidad, la forma en que se comporta una vez construida, o el proceso de su construcción.
Marcos de trabajo
Definen una arquitectura adaptada a las particularidades de un determinado dominio de aplicación, definiendo de forma abstracta una serie de componentes y sus interfaces y estableciendo las reglas y mecanismos de interacción entre ellos.
• Suele incluirse la implementación de algunos de los componentes e incluso varias implementaciones alternativas.
• El usuario
– Selecciona, instancia, extiende y reutiliza los componentes del marco.
– Completa la arquitectura con nuevos componentes específicos dentro de las relaciones estructurales del marco.
Básicamente se presentan como un diseño reutilizable de todo o parte de un sistema, representado por un conjunto de componentes abstractos y la forma en que los componentes interactúan.
• Una alternativa es verlos como un esqueleto de una aplicación que debe ser adaptado por el programador según sus necesidades concretas.
• Un marco de trabajo define el patrón arquitectónico que relaciona los componentes de un sistema
Presentan dos niveles:
– Especificación de la arquitectura marco.
– Implementación del marco de trabajo (normalmente un lenguaje orientado a objetos).
• Al desarrollo de aplicaciones a partir de un marco de trabajo se le denomina extensión del marco:
– Puntos de entrada (hot spots): Componentes o procedimientos cuya implementación final depende de la aplicación concreta.
– Definidos por el diseñador del marco para que sean la forma natural de la extensión del mismo.
Dependiendo de la extensión tenemos:
Marcos de trabajo de caja blanca
Que se extienden mediante herencia, concretamente mediante la implementación de las clases y métodos abstractos definidos como puntos de entrada. Se tiene acceso al código del marco y se permite reutilizar la funcionalidad de sus clases mediante herencia y redefinición de métodos.
Marcos de trabajo de caja de cristal
Admiten la inspección de su estructura e implementación, pero no su modificación ni extensión, excepto en los puntos de entrada.
Dependiendo de su aplicabilidad tenemos:
Marcos de trabajo horizontales
Válidos para todos los dominios de aplicación concretados en un aspecto del sistema.
Infraestucturas de comunicación, interfaces de usuario, entornos visuales, etc.
Marcos de trabajo distribuidos (Middelware Application Frameworks) o Plataforma de Componentes Distribuidos para integrar componentes distribuidas.
Aíslan las dificultades conceptuales y técnicas del desarrollo de aplicaciones distribuidas basadas en componentes.
No hay comentarios:
Publicar un comentario