Lenguaje+Wrigth

**Grupo Nº 8**

 * < **Cédula Identidad** ||< **Nombre y Apellido** ||
 * < ===//15073731//=== ||< ===//Alvarado Yecenia//=== ||
 * < ===//18838921//=== ||< ===//Guarirapa Yanira//=== ||
 * < ===//19430515//=== ||< ===//Mirelis Andreina//=== ||
 * < ===//17291419//=== ||< ===//Rangel Franci//=== ||



Se puede caracterizar sucintamente como una herramienta de formalización de conexiones arquitectónicas. Ha sido desarrollado por la Escuela de Ciencias Informáticas de la Universidad Carnegie Mellon, como parte del proyecto mayor ABLE. Este proyecto a su vez se articula en dos iniciativas: la producción de una herramienta de diseño, que ha sido Aesop, y una especificación formal de descripción de arquitecturas, que es propiamente Wright.

**Objetivo principal **

Wright es probablemente la herramienta más acorde con criterios académicos de métodos formales. Su objetivo declarado es la integración de una metodología formal con una descripción arquitectónica y la aplicación de procesos formales tales como álgebras de proceso y refinamiento de procesos a una verificación automatizada de las propiedades de las arquitecturas de software. El trabajo de Wright se ha centrado en el concepto de tipos de conectores explícitos, en el uso de la comprobación automatizada de características arquitectónicas, y en la formalización de estilos arquitectónicos. Para los desarrolladores de ayuda adicionales en la realización y la explotaciónde las abstracciones arquitectónicas, Wright define un conjunto de consistencia normal y comprobaciones de integridad que pueden ser usados ​​para aumentar la confianza del diseñador en el diseño de un sistema. Estos controles están definidos con precisión en términos del modelo de base de Wright en la CSP, yse puede comprobar con la tecnología estándar de verificación de modelos.

La descripción de un componente en WRIGHT consta de dos apartados: la interfaz y la computación. En WRIGHT, la interfaz consta de cierto número de puertos, y cada puerto define una de las interacciones (independientes) en las que el componente puede participar.

**Estilos **

Una descripción de un estilo consta de dos partes: vocabulario y restricciones sobre las configuraciones. El vocabulario se construye mediante la simple definición de tipos de componente y conector, mientras que las restricciones son predicados que deben cumplirse en cualquier sistema del estilo en cuestión. Basándose en descripciones de estilos, la posterior descripción de un sistema es mucho más simple, ya que no es necesario repetir la información contenida en la descripción del estilo. En Wright se introduce un vocabulario común declarando un conjunto de tipos de componentes y conectores y un conjunto de restricciones. Cada una de las restricciones declaradas por un estilo representa un predicado que debe ser satisfecho por cualquier configuración de la que se declare que es miembro del estilo. La notación para las restricciones se basa en el cálculo de predicados de primer orden. Las restricciones se pueden referir a los conjuntos de componentes, conectores y attachments, a los puertos y a las computaciones de un componente específico y a los roles y ligamentos (glue) de un conector particular. Es asimismo posible definir sub-estilos que heredan todas las restricciones de los estilos de los que derivan. No existe, sin embargo, una manera de verificar la conformidad de una configuración a un estilo canónico estándar.

**Interfaces **

En Wright los puntos de interfaz se llaman puertos (ports).

**Semántica **

Mientras muchos lenguajes de tipo ADL no soportan ninguna especificación semántica de sus componentes más allá de la descripción de sus interfaces, Wright y Rapide permiten modelar la conducta de sus componentes. En Wright existe una sección especial de la especificación llamada Computation que describe la funcionalidad de los componentes.

**Análisis y verificación automática **

Al basarse en CSP (proceso secuencial comunicante), como modelo semántico, Wright permite analizar los conectores para verificar que no haya deadlocks. Wright define verificaciones de consistencia que se aplican estáticamente, y no mediante simulación. Esto lo hace más confiable que, por ejemplo, Rapide. También se puede especificar una forma de compatibilidad entre un puerto y un rol, de modo que se pueda cambiar el proceso de un puerto por el proceso de un rol sin que la interacción del conector detecte que algo ha sido modificado. Esto permite implementar relaciones de refinamiento entre procesos. En Wright existen además recaudos (basados en teoremas formales relacionados con CSP) que garantizan que un conector esté libre de deadlocks en todos los escenarios posibles. Esta garantía no se obtiene directamente sobre Wright, sino implementando un verificador de modelos comercial para CSP llamado FDR. <span style="display: block; font-family: Arial,sans-serif; font-size: 16px; text-align: justify;">Herramientas complementarias generan datos de entrada para FDR a partir de una especificación Wright. Cualquier herramienta de análisis o técnica que pueda usarse para CSP se puede utilizar también para especificaciones en Wright.

**<span style="font-family: 'Arial','sans-serif';">Interfaz gráfica **

<span style="display: block; font-family: Arial,sans-serif; font-size: 16px; text-align: justify;">Wright no proporciona notación gráfica en su implementación nativa.

**<span style="font-family: 'Arial','sans-serif';">Generación de código **

<span style="display: block; font-family: Arial,sans-serif; font-size: 16px; text-align: justify;">Wright se considera como una notación de modelado autocontenida y no genera (al menos en forma directa) ninguna clase de código ejecutable.

**<span style="font-family: 'Arial','sans-serif';">Implementación de referencia **

<span style="display: block; font-family: Arial,sans-serif; font-size: 16px; text-align: justify;">Aunque se ha señalado su falta de características explícitas de escalabilidad, Wright se utilizó para modelar y analizar la estructura de runtime del Departamento de Defensa de Estados Unidos. Se asegura que permitió condensar la especificación original y detectar varias inconsistencias en ella.

**<span style="font-family: Arial,sans-serif; font-size: 16px; text-align: center;">Disponibilidad de plataforma **

<span style="display: block; font-family: Arial,sans-serif; font-size: 16px; text-align: justify;">Wright es en principio independiente de plataforma y es un lenguaje formal, antes que una herramienta paquetizada. Debido a que se basa en CSP (proceso secuencial comunicante), cualquier solución que pueda tratar código CSP en plataforma Windows es apta para obtener ya sea una visualización del modelo o verificar la ausencia de deadlocks o la consistencia del modelo. El código susceptible de ser manejado por herramientas de CSP académicas o comerciales requiere tratamiento previo por un módulo de Wright que por el momento existe sólo para Linux o SunOS; pero una vez que se ha generado el CSP (lo cual puede hacerse manualmente insertando unos pocos tags) se puede tratar en Windows con cualquier solución ligada a ese lenguaje, ya sea FDR o alguna otra. CSP no está ligado a plataforma alguna, y fue elaborado a 43mediados de la década de 1970 por Sir Tony Hoare, actualmente Senior Researcher en Microsoft Research, Cambridge. <span style="display: block; font-family: Arial,sans-serif; font-size: 12pt; text-align: justify;">WRIGHT se basa en la descripción formal del comportamiento abstracto de los componentes y conectores. Modela los diversos tipos de conector como patrones abstractos de interacción mediante una notación inspirada en CSP y define los estilos arquitectónicos como predicados que restringen las posibles configuraciones.

<span style="background-color: #00b4ff; color: #000000; display: block; font-size: 16px; text-align: center;">**Aspectos Importantes**

<span style="display: block; font-family: Arial,sans-serif; font-size: 16px; text-align: justify;">El uso de notaciones precisas como WRIGHT facilita la comunicación de ideas entre arquitectos. Además, proporciona una base para analizar las arquitecturas. Se pueden usar las descripciones de conectores para determinar si el conector satisface ciertas propiedades críticas, como la consistencia interna del protocolo y si los papeles están lo suficientemente restringidos como para garantizar un comportamiento correcto de los componentes. Por supuesto, las descripciones de componentes y conectores juegan el papel de “tipos” en el sentido de que son generales y abstractas, y en el sistema final intervendrán instancias concretas de los mismos. <span style="display: block; font-family: Arial,sans-serif; font-size: 16px; text-align: justify;">Las configuraciones de sistema en WRIGHT son jerárquicas; cada componente de un sistema puede describirse mediante una especificación de componente propiamente dicha o mediante una nueva descripción de sistema.

media type="youtube" key="bVBdo5xkUtg" height="408" width="546" align="center"



La arquitectura de software puede considerase como el “puente” entre los requerimientos del sistema y la implementación (Hofmeister et al., 2000). Las actividades que culminan en la definición de la arquitectura pueden ubicarse en las fases tempranas del ciclo de desarrollo del sistema: luego del análisis de los requerimientos y el análisis de riesgos, y justo antes del diseño detallado. Desde esta perspectiva, la arquitectura constituye un artefacto de la actividad de diseño (Hofmeister et al., 2000), que servirá de medio de comunicación entre los miembros del equipo de desarrollo, los clientes y usuarios finales, dado que contempla los aspectos que interesan a cada uno (Kazman et al., 2001). Además, pasa a ser la base del diseño del sistema a desarrollar, razón por la cual en la literatura la arquitectura es considerada como plan de diseño del sistema (Hofmeister et al., 2000), debido a que es usada como guía para el resto de las tareas del desarrollo.


 * Sistema Propuesto **

** Aplicación Web para el control de las operaciones administrativas y gestión de consultas de Estados Financieros de los asociados en la Caja de Ahorro y Préstamo de las Fuerzas Armadas Policiales del Estado Barinas (CAYPEFAPEB). ** Esta aplicacion web viene a solventar todos los inconvenientes que presenta el socio al momento de dirigirse habitualmente a la Caja de Ahorro, ya que todos no son adyacentes a la capital sino que pertenecen a los demás Municipios del Estado Barinas; lo cual genera que estos pierdan tiempo y dinero al dirigirse a la organización para consultar sus estados de cuentas, realizar pagos, solicitar cualquier tipo de Préstamos, entre otras cosas las cuales requieren una dedicación para realizar dichos procesos. El sistema consta de una serie de medidas desarrolladas en la aplicación a las insuficiencias localizadas en la organización.

El sistema está estructurado por una sucesión de módulos, los cuales desempeñan funciones concretas, entre los que se detallan la captura de datos del socio, los que permiten visualizar los procesos de creación de un usuario, consulta de estados de cuentas, requisitos para la solicitud de créditos, disponibilidad de préstamo y la emisión de reportes de sus operaciones. Además consta de un módulo de seguridad que permite asignar y quitar privilegios a los usuarios. Esta función solo la debe cumplir el administrador del sistema que autorice la administración de La Caja de Ahorro y Préstamos.

**Determinación de Requerimientos Funcionales del Sistema Propuesto**



** Diagrama de componentes del sistema propuesto **