Unidad 6. Evaluacion Arquitectonica
UNIDAD
6 EVALUACION ARQUITECTONICA
La evaluación de una arquitectura es dar a conocer que es lo que se
quiere evaluar. De manera que es posible establecer la base para para la
evaluación puesto que la intención es saber qué se puede evaluar y qué no. la
arquitectura de software, es posible también determinar la estructura del
proyecto de desarrollo del sistema, sobre elementos como el control de
configuración, calendarios, control de recursos, metas de desempeño, estructura
del equipo de desarrollo y otras actividades que se realizan con la
arquitectura del sistema como apoyo principal.
La evaluación da la arquitectura presenta varios tipos posibles a la
hora de ser una evaluación de una arquitectura en diversas situaciones entre
ella están Comparación de alternativas
similares, Comparación de la arquitectura original y la modificada, Comparación
de la arquitectura de software con respecto a los requerimientos del sistema,
Comparación de una arquitectura de software con una propuesta teórica,
Valoración de una arquitectura en base a escalas específicas. Las técnicas a
usar para la evaluación de una arquitectura de software que permiten hacer una evaluación
cuantitativa sobre los atributos de calidad a nivel arquitectónico, pero se
tienen pocos medios para predecir el máximo (o mínimo) teórico para las
arquitecturas de software. Evaluación basada en escenarios, evaluación basada
en simulación, evaluación basada en modelos matemáticos y evaluación basada en
experiencia.
La evaluación basada en escenario es una corta descripción de una
interacción de un stakeholder con el sistema. Por ejemplo, un usuario describe
como utiliza el sistema para realizar una tarea, sus escenarios serán muy
parecidos a los casos de uso. Un escenario de un desarrollador se centrará en
usar la arquitectura para construir el sistema o predecir su performance.Los
escenarios proveen un vehículo para tomar las cualidades de tiempo de
desarrollo vagas, como ser modifiability, y transformarlas en algo concreto.
Los escenarios también son útiles para entender las cualidades de tiempo de
ejecución como performance o availability. Coinciden en la importancia del uso
de los escenarios, no sólo para efectos de la evaluación de arquitecturas de
software. Entre las ventajas de su uso están: Son simples de crear y entender,
Son poco costosos y no requieren mucho entrenamiento, Son efectivos.
El escenario se basa en estructuras en un ejercicio que escriban
escenarios utilizando el formato tripartito. Las tres partes son estímulo,
entorno y respuesta. El estímulo es la parte del escenario que explica o
describe lo que hace un stakeholder para iniciar una interacción con el
sistema, por ejemplo invocar una función. El entorno describe que está pasando al tiempo del estímulo. Por ejemplo, ¿cuál es el
estado del sistema?, ¿cuáles son las condiciones inusuales. La evaluación basada en simulación utiliza
una implementación de alto nivel de la arquitectura de software. La finalidad
es evaluar el comportamiento de la arquitectura bajo diversas circunstancias.
Una vez disponibles estas implementaciones, pueden usarse los perfiles
respectivos para evaluar los atributos de calidad.
Unidad 5. Patrones de diseño
UNIDAD 5: PATRONES DE DISEÑO
Los patrones de diseño son
una herramienta que brinda flexibilidad y robustez al desarrollo de sistemas de
software facilitando el reuso del diseño y la arquitectura, pero un uso
excesivo o inadecuado de ellos puede añadir mayor complejidad sin aporte de
beneficio alguno. También el contexto en
el que se estén utilizando interviene a la hora de seleccionar los patrones, por
eso es que este framework no pretende ser inflexible y deja la posibilidad de
aplicar otros patrones, según sea cada uno de los casos particulares. Tres
patrones fueron utilizados en este framework, el patrón Mediator [3] para el
manejo de las interfaces de usuario, el patrón Data Transfer Object [4] para
reducir el número de llamadas al servidor y el patrón Registry [4] para acceder
a los objetos persistentes.
La clasificación de los
patrones según por la etapa del desarrollo del software son: 1. Creacional:
Cómo se puede crear un objeto. Habitualmente esto incluye aislar los detalles
de la creación del objeto, de forma que su código no dependa de los tipos de
objeto que hay y por lo tantok, no tenga que cambiarlo cuando añada un nuevo
tipo de objeto. Este capítulo presenta los patrones Singleton, Fábricas
(Factories), y Constructor (Builder).
2. Estructural: Esto afecta
a la manera en que los objetos se conectan con otros objetos para asegurar que
los cambios del sistema no requieren cambiar esas conexiones. Los patrones
estructurales suelen imponerlos las restricciones del proyecto. En este
capítulo verá el Proxy y el Adaptador (Adapter).
3. Comportacional: Objetos
que manejan tipos particulares de acciones dentro de un programa. Éstos
encapsulan procesos que quiere que se ejecuten, como interpretar un lenguaje,
completar una petición, moverse a través de una secuencia (como en un iterador)
o implementar un algoritmo. Este capítulo contiene ejemplos de Comando
(Command), Método Plantilla (TemplateMethod), Estado (State), Estrategia
(Strategy), Cadena de Responsabilidad (Chain of Responsibility), Observador
(Observer), FIXME: Despachador Múltiple (MultipleDispatching) y Visitador
(Visitor). El GoF incluye una sección
sobre cada uno de los 23 patrones, junto con uno o más ejemplos de cada uno,
típicamente en C++ aunque a veces en SmallTalk. Este libro no repite los detalles
de los patrones mostrados en GoF, ya que aquél FIXME: "stands
onitsown" y debería estudiarse aparte. La descripción y los ejemplos que
se dan aquí intentan darle una visión de los patrones.
Integrantes:
Carlos Espinoza
Marlon Núñez
Garykel Torres
Shalon Zapata
LudrickMartinez
Yenderlys Solórzano
Unidad 4. Patrones Arquitectonicos.
Los patrones
arquitectónicos, o patrones de arquitectura, son patrones de diseño de software que
ofrecen soluciones a problemas de arquitectura de software en Ingeniería de software. Dan una descripción de los
elementos y el tipo de relación que tienen junto con un conjunto de
restricciones sobre cómo pueden ser usados. Un patrón arquitectónico expresa un
esquema de organización estructural esencial para un sistema de software, que
consta de subsistemas, sus responsabilidades e interrelaciones. En comparación
con los patrones de diseño, los patrones arquitectónicos tienen un nivel de
abstracción mayor.
Se definen tres tipos de patrones.
•Patrones
arquitectónicos sobre aspectos fundamentales de la estructura de un sistema
software. Especifican un conjunto predefinido de subsistemas con sus
responsabilidades y una serie de recomendaciones para organizar los distintos
componentes.
•Patrones de
diseño sobre aspectos relacionados con el diseño de los subsistemas. Por tanto
se centran en aspectos más específicos.
•Un Idiom
que es un patrón de bajo nivel específico de un lenguaje de programación o
entorno de desarrollo.
Integrantes:
Carvajal
Patricia
Contreras
Flor
Delgado
Igdalyas
Farfán
Frannys
Siso
Abraham
Unidad 3. Estilos Arquitectonicos
ESTILOS ARQUITECTONICOS
Se dice que los estilos arquitectónicos son un conjunto
de reglas de diseño que identifica las clases de componentes y conectores que
se pueden utilizar para componer en sistema o subsistema, junto con los
aparejados por el uso del estilo. Sin duda un estilo describe entonces una
clase de arquitectura, o piezas identificables de las arquitecturas
empíricamente dadas..Esas piezas se encuentran repetidamente en la práctica,
trasuntando la existencia de decisiones estructurales coherentes. Una vez que
se han identificado los estilos, es lógico y natural pensar en re-utilizarlos
en situaciones semejantes que se presenten en el futuro [Kaz01]. Igual que los
patrones de arquitectura y diseño, todos los estilos tienen un nombre: cliente-servidor,
modelo-vista-controlador, tubería-filtros, arquitectura en capas.
Estilos
De Datos estos o Estilos centrados en datos:
Enfatiza la integrabilidad de los datos. Se estima
apropiada para sistemas que se fundan en acceso y actualización de datos en
estructuras de almacenamiento. Sub-estilos característicos además de que
constituyen una de las principales ramas de investigación sobre arquitectura de
computadores y de esta manera alcanzar las cualidades de reusó y
modificabilidad.
Estilos de Llamada y Retorno:
Estilos de Llamada y RetornoEsta
familia de estilos enfatiza la modificabilidad y la escalabilidad. Son los
estilos más generalizados en sistemas en gran escala. Miembros de la familia
son las arquitecturas de programa principal y subrutina, los sistemas basados
en llamadas a procedimientos remotos, los sistemas orientados a objeto y los
sistemas jerárquicos en capas.
Estilos
de Código Móvil
Esta familia de estilos enfatiza la portabilidad.
Ejemplos de la misma son los intérpretes, lossistemas basados en reglas y los
procesadores de lenguaje de comando. Fuera de las máquinas virtuales y los
intérpretes, los otros miembros del conjunto han sido rara vez estudiados desde
el punto de vista estilístico. Los
sistemas basados en reglas, que a veces se agrupan como miembros de la familia
de estilos basados en datos, han sido estudiados particularmente por
Murrell, Gamble, Stiger y
Plant [MPG96] [SG97] [GSP99].
Estilos heterogéneos
Antes de
pasar a la familia más fuertemente referida en los últimos tiempos, incluyo en
este grupo formas compuestas o indóciles a la clasificación en las categorías
habituales. Es por cierto objetable y poco elegante que existan clases
residuales de este tipo en una taxonomía, pero ninguna clasificación conocida
ha podido resolver este dilema conceptual. En este apartado podrían agregarse
formas que aparecen esporádicamente en los censos de estilos, como los sistemas
de control de procesos industriales, sistemas de transición de estados,
arquitecturas específicas de dominios
[GS94] o estilos derivados de otros estilos, como GenVoca, C2 o REST
Estilos Peer-to-Peer
Esta familia, también
llamada de componentes independientes, enfatiza la modificabilidad por medio de
la separación de las diversas partes que intervienen en la computación.
Consiste por lo general en procesos
independientes o entidades que se comunican a través de mensajes. Cada entidad puede enviar mensajes a otras
entidades, pero no controlarlas directamente. Los mensajes pueden ser enviados a componentes
nominados o propalados mediante broadcast.
Miembros de la familia son los estilos basados en eventos, en mensajes
(Chiron-2), en servicios y en recursos.
Gregory Andrews [And91] elaboró la taxonomía más detallada a la fecha de estilos basados en transferencia de mensajes,
distinguiendo ocho categorías: (1) Flujo de datos en un sentido a través de redes de filtros.
(2) Requerimientos y respuestas entre clientes y servidores. (3) Interacción de ida y vuelta o
pulsación entre procesos vecinos. (4) Pruebas y ecos en grafos incompletos. (5) Broadcasts entre
procesos en grafos completos. (6) Tokenpassingasincrónico. (7) Coordinación
entre procesos de servidor decentralizados. (8) Operadores replicados que comparten una bolsa de tareas.
Integrantes:
Delgado Jesús.
Mirabal José.
Mujica Liliana.
Rangel Ana.
Rico Dayana.
Suscribirse a:
Entradas (Atom)