DISEÑO ARQUITECTÓNICO

 

* Patrones de Diseño:

Se trata de plantillas que identifican problemas en el sistema y proporciona soluciones apropiadas a problemas generales a los que se han enfrentado los desarrolladores durante un largo período de tiempo, a través de prueba y error.

Tipos de patrones de diseño:

Se compone por tres categorías principales las cuales son:

-Patrones creacionales: Son aquellos que proporcionan diversos mecanismos de creación de objetos, que aumenta la flexibilidad y la reutilización del código existente de una manera adecuada a la situación. Esto le da al programa más flexibilidad para decidir qué objetos deben crearse para un caso de uso dado.

Los patrones creacionales son los siguientes:

Ø  Abstract Factory: Una interfaz crea conjuntos o familias de objetos relacionados sin especificar el nombre de la clase.

Ø  Builder Patterns: Permite producir diferentes tipos y representaciones de un objeto utilizando el mismo código de construcción, se utiliza para la creación etapa por etapa de un objeto complejo combinando objetos simples, en donde la creación final de objetos depende de las etapas del proceso creativo, pero es independiente de otros objetos.

Ø  Factory Method: Proporciona una interfaz para crear objetos en una superclase, pero permite que las subclases alteren el tipo de objetos que se crearán. Proporciona instanciación de objetos implícita a través de interfaces comunes.

Ø  Prototype: Es aquel que permite copiar objetos existentes sin hacer que su código dependa de sus clases. Se utiliza para restringir las operaciones de memoria / base de datos manteniendo la modificación al mínimo utilizando copias de objetos.

Ø  Singleton: Este patrón de diseño restringe la creación de instancias de una clase a un único objeto.

-Patrones estructurales: Son los patrones que facilitan soluciones y estándares eficientes con respecto a las composiciones de clase y las estructuras de objetos. El concepto de herencia se utiliza para componer interfaces y definir formas de componer objetos para obtener nuevas funcionalidades.

Ø  Adapter: Se utiliza para vincular dos interfaces que no son compatibles y utilizan sus funcionalidades. El adaptador permite que las clases trabajen juntas de otra manera que no podrían al ser interfaces incompatibles.

Ø  Bridge: En este patrón hay una alteración estructural en las clases principales y de implementador de interfaz sin tener ningún efecto entre ellas. Estas dos clases pueden desarrollarse de manera independiente y solo se conectan utilizando una interfaz como puente.

Ø  Composite: Se usa para agrupar objetos como un solo objeto. Permite componer objetos en estructuras de árbol y luego trabajar con estas estructuras como si fueran objetos individuales.

Ø  Decorator: Este patrón restringe la alteración de la estructura del objeto mientras se le agrega una nueva funcionalidad. La clase inicial permanece inalterada mientras que una clase decorator proporciona capacidades adicionales.

Ø  Facade: Proporciona una interfaz simplificada para una biblioteca, un marco o cualquier otro conjunto complejo de clases.

Ø  Flyweight: Se usa para reducir el uso de memoria y reducir la creación de objetos para así mejorar el rendimiento. El patrón busca objetos similares que ya existen para reutilizarlo en lugar de crear otros nuevos que sean similares.

Ø  Proxy: Se utiliza para crear objetos que pueden representar funciones de otras clases u objetos y la interfaz se utiliza para acceder a estas funcionalidades.

-Patrones de comportamiento: Son aquellos que se ocupan de la comunicación entre objetos de clase, se utilizan para detectar la presencia de patrones de comunicación ya presentes y pueden manipular estos patrones. Estos patrones de diseño están específicamente relacionados con la comunicación entre objetos.

Ø  Chain of responsibility: Es un patrón de comportamiento que evita acoplar el emisor de una petición a su receptor dando a más de un objeto la posibilidad de responder a una petición.

Ø  Command: Convierte una solicitud en un objeto independiente que contiene toda la información sobre la solicitud. Esta transformación permite parametrizar métodos con diferentes solicitudes, retrasar o poner en cola la ejecución de una solicitud y respaldar operaciones que no se pueden deshacer.

Ø  Interpreter: Se utiliza para evaluar el lenguaje o la expresión al crear una interfaz que indique el contexto para la interpretación.

Ø  Iterator: Su utilidad es proporcionar acceso secuencial a un número de elementos presentes dentro de un objeto de colección sin realizar ningún intercambio de información relevante.

Ø  Mediator: Este patrón proporciona una comunicación fácil a través de su clase que permite la comunicación para varias clases.

Ø  Memento: Permite recorrer elementos de una colección sin exponer su representación subyacente

Ø  Observer: Permite definir un mecanismo de suscripción para notificar a varios objetos sobre cualquier evento que le suceda al objeto que está siendo observado.

Ø  State: En el patrón state, el comportamiento de una clase varía con su estado y por lo tanto está representado por el objeto de contexto.

Ø  Strategy: Permite definir una familia de algoritmos, poner cada uno de ellos en una clase separada y hacer que sus objetos sean intercambiables.

Ø  Template method: Se usa con componentes que tienen similitud donde se puede implementar una plantilla del código para probar ambos componentes. El código se puede cambiar con pequeñas modificaciones.

Ø  Visitor: El propósito de este patrón es definir una nueva operación sin introducir las modificaciones a una estructura de objeto existente.

 

 * Modelado del diseño:

Las siguientes metodologías se utilizan para moldear el diseño:

v  Diseño de datos: Es aquel que transforma el modelo del dominio de información que se crea durante el análisis en las estructuras de datos que se necesitarán para implementar el software. Los objetos de datos, las relaciones definidas en el diagrama relación entidad y el contenido de datos son la base de esta actividad. Un buen diseño de datos es importante porque puede conducir a una mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida.

Principios para el diseño de datos:

1.- Deben identificarse todas las estructuras de datos y las operaciones que se han de realizar sobre cada una de ellas.

2.- Debe establecerse y usarse un diccionario de datos para definir el diseño de los datos del programa.

3.- El diseño de datos de bajo nivel debe realizarse hasta el diseño detallado.

4.- El lenguaje de programación debe soportar la especificación y la realización de tipos abstractos de datos.

El objetivo principal del diseño arquitectónico es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos.

Los métodos de diseño disponibles para realizar el diseño arquitectónico son:

a) Diseño orientado al flujo de datos: Es un conjunto de pasos de diseño que permiten convertir un DFD, con características de flujo de transformación en una estructura de programa. Además, es una herramienta gráfica que se utiliza para describir el flujo de la información transformándola en una estructura de programa.

b) Diseño orientado a los objetos: El diseño orientado a objetos (DOO) es una fase de la metodología orientada a objetos para el desarrollo de software. Su uso induce a desarrolladores y programadores a pensar en términos de objetos, en vez de procedimientos, cuando planifican el código.

c) Diseño orientado a los datos: Es una representación gráfica del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas.

v Diseño de componentes: El diseño a nivel de componentes o también llamado diseño procedimental es aquel que transforma los elementos estructurales de la arquitectura del software en una descripción procedimental de los componentes del software. La información que se obtiene de EP, EC y de DTE sirve como base para el diseño de los componentes. Es importante ya que facilita la legibilidad, prueba y mantenimiento de cada componente.

Notaciones del diseño procedimental:

a).- Diagrama de Flujo: Es una notación gráfica muy usada en el diseño procedimental. Se utilizan símbolos gráficos para representar la secuencia, las condiciones y las estructuras de control.

b) Tablas de Decisión: Muchas veces en un módulo se puede requerir evaluar una compleja combinación de condiciones, y las tablas de decisión es una notación que traduce las condiciones y acciones en una forma tabular.

c) Lenguaje Estructurado o Pseudocodigo: Es una combinación de lenguaje natural ( español ) y la sintaxis general de un lenguaje de programación. Esta notación de diseño procedimental hace uso de texto directamente insertado en estructuras sintácticas. El pseudocodigo puede remplazar a los diagramas de flujo y reducir una buena cantidad de documentación para describir al sistema

v Diseño de interfaces: Describe la manera de comunicarse el software dentro de sí mismo, con sistemas que interoperan dentro de él y con las personas que lo utilizan. Una interfaz implica un flujo de información y un tipo específico de comportamiento. Además ayuda a minimizar el tiempo de entrenamiento para usar el sistema, genera confiabilidad y mayor portabilidad.

* Evaluación del diseño:

A continuación se dará a conocer cuatros métodos de evaluación de arquitectura de software que permiten analizar un atributo de calidad especifico

Architecture Level Modifiability Analysis (ALMA)

El atributo de calidad que analiza ALMA, es la facilidad de modificación. Esto se refiere a la capacidad de un sistema para ser ajustado debido a cambios en requerimientos, o en el entorno, así como la adición de alguna nueva funcionalidad. ALMA es el resultado de los trabajos de investigación realizados por Bengtsson y Lassing en el año 2000.

ALMA es un método de evaluación orientado a metas. En donde se usa primordialmente para las siguientes tres metas:

•Predicción del costo de mantenimiento: Consiste en estimar el esfuerzo requerido para modificar la arquitectura a cambios requeridos en un futuro.

•Evaluación de riesgos: Identifica los tipos de cambios que pueden ser complejos o que sean inflexibles en la arquitectura de software.

•Selección de un conjunto de arquitecturas: Compara dos o más arquitecturas propuestas y selecciona aquella que proporcione mayor soporte a cambios.  Donde este método se apoya en el uso de escenarios de cambio, los cuales describen eventos posibles que provocarían cambios al sistema, y cómo se llevarían acabo éstos.

Este método se realiza a través de los siguientes pasos:

1. Definir la meta de evaluación: Dependiendo del objetivo de la evaluación, se selecciona alguna de las tres metas.

2. Describir la arquitectura de software: Se recolecta la información más relevante de la arquitectura: sus principales componentes, las relaciones entre éstos, así como las relaciones con el entorno del sistema.

3. Obtener escenarios: Se definen los escenarios de cambio y se agrupan en categorías, seguidamente se eligen aquellos escenarios relacionados con el propósito de evaluación.

4. Evaluar escenarios: Se realiza un análisis de impacto, el cual consiste en identificar los componentes afectados por los escenarios previamente definidos, se determina el efecto del cambio sobre los componentes así como también se determina los efectos del cambio en otros componentes. Los resultados de este análisis se deben expresar ya sea de manera cuantitativa o cualitativa.

5. Interpretar resultados: Finalmente se interpretan los resultados, así como las conclusiones del análisis dependiendo de la meta de evaluación seleccionada.



Performance Assessment of Software Architecture (PASA)

El atributo de calidad que analiza PASA, es el desempeño. El cual se interesa por conocer qué tanto tiempo le toma al sistema de software responder cuando uno o varios eventos ocurrentes, así como determinar el número de eventos procesados en un intervalo de tiempo dado. PASA también es un modelo basado en escenarios. Asimismo, puede aplicarse una vez que la arquitectura se ha especificado, o posteriormente, cuando ya ha sido implementada. Los escenarios generados en este método proveen una medida de razonamiento con respecto al desempeño del sistema. Si se requieren análisis más detallados, los escenarios sirven como punto de partida para construir modelos de desempeño.

Para utilizar este método, la arquitectura de software debe estar previamente documentada. En caso de que se encuentre parcialmente documentada, es necesario extraer la información faltante de los miembros del equipo, así como de códigos fuente.

Los pasos para llevar acabo este método son:

1. Presentar el método de evaluación. Se comunica al equipo y directivos el objetivo de la evaluación, y se explica el método PASA.

2. Presentar la arquitectura. El equipo de desarrollo presenta la arquitectura actual de una manera general y sin entrar en detalles.

3. Identificar casos de uso críticos: Se seleccionan los casos de uso que son importantes para la operación del sistema, así como aquellos que demandan una respuesta de tiempo rápida para el usuario, u otros que presentan algún riesgo de desempeño.

4. Seleccionar los escenarios de desempeño principales: Por cada caso de uso crítico, se debe identificar los escenarios significativos con respecto al desempeño.

5. Identificar objetivos de desempeño: Por cada escenario de desempeño principal, se debe especificar al menos un objetivo de desempeño, estos mismos pueden ser expresados de distintas maneras. Por ejemplo: expresarlos en tiempo de respuesta, capacidad de respuesta, restricciones o utilización de recursos. Para poder medirlo es necesario que el objetivo de desempeño sea cuantitativo.

6. Clarificar la arquitectura y discutirla: En este paso se estudia más a detalle la arquitectura, por lo que se tienen reuniones con el arquitecto y equipo de desarrollo para aclarar dudas. Si existe información acerca del desempeño del sistema, se recolectan métricas.

7. Analizar la arquitectura. En este paso se utilizan diferentes técnicas para analizar el desempeño de la arquitectura. Con la finalidad de detectar aquellos efectos negativos en el desempeño, además, se identifican anti-patrones de desempeño que documentan problemas comunes.

8. Identificar alternativas: Si se encontraron problemas de desempeño, se identifican alternativas de solución, estas pueden incluir el cambio del estilo arquitectónico, seguidamente modifica la arquitectura para eliminar anti-patrones de desempeño, o alternativas para optimizar la interacción entre los componentes.

9. Presentar resultados: Finalmente se elabora un documento con los resultados de la evaluación que incluye los objetivos de la evaluación, hallazgos encontrados, pasos específicos a seguir y recomendaciones.

 


Scenario based Architecture Level UsabiliTy Analysis (SALUTA)

SALUTA es el método desarrollado para evaluar la arquitectura desde la perspectiva de la facilidad de uso del sistema. En el cual este método hace uso de un marco de referencia elaborado por los mismos autores en el que se expresan las relaciones que existen entre la facilidad de uso y la arquitectura de software. Este marco de referencia incluye un conjunto integrado de soluciones de diseño tales como patrones de diseño y propiedades que tienen un efecto positivo sobre la facilidad de uso en un sistema de software.

SALUTA analiza cuatro atributos que están directamente relacionados con la facilidad de uso en un sistema de software, estos son: facilidad de aprendizaje, eficiencia de uso, confiabilidad y satisfacción.

Se recomienda efectuar la evaluación una vez que la especificación de la arquitectura ha finalizado, pero antes de que se implemente. Este método se basa en escenarios de uso, los cuales se agrupan en uno o más perfiles de uso. Cada uno representa la facilidad de uso requerida por el sistema de software.

SALUTA está compuesto por los siguientes pasos:

1. Crear perfiles de uso: Se identifican los usuarios y se organizan en categorías. Luego se identifican las tareas más significativas del sistema y el contexto donde será usado el sistema, así mismo se determinan los valores para los atributos: facilidad de aprendizaje, eficiencia de uso, confiabilidad y satisfacción, donde a cada uno se le asigna un valor numérico no repetido entre 1 y 4. Esto se hace para reflejar la diferencia en la prioridad de los atributos y seleccionar los escenarios más representativos que tienen mayor prioridad con respecto a sus atributos.

2. Describir la facilidad de uso proporcionada: Se recolecta la información de la arquitectura de software para determinar el nivel de soporte en los escenarios de uso. Esto se realiza efectuando un análisis basado en patrones, o basado en propiedades

3. Evaluar escenarios: Se evalúa cada uno de los escenarios que forman parte del perfil de uso. Por cada escenario se analizan los patrones y propiedades previamente identificados. Se recomienda usar el marco de referencia para analizar cómo un patrón, o propiedad particular afecta a un atributo específico en un escenario de uso. Finalmente, se expresan de manera cuantitativa los resultados del análisis, que indican el grado de soporte de facilidad de uso en cada uno de los escenarios.

4.Interpretar resultados: En este paso se obtienen los resultados de la evaluación, que contienen el grado de facilidad de uso que soporta la arquitectura evaluada.

 


 

 

 

Survivable Network Analysis (SNA)

Es un método desarrollado por el CERT (Computer Emergency Response Team) que forma parte del SEI. Este método ayuda a identificar la capacidad de supervivencia en un sistema, analizando su arquitectura.

La supervivencia en un sistema se refiere a la capacidad que tiene ese sistema para completar su misión a tiempo, ante la presencia de ataques, fallas o accidentes. SNA utiliza tres propiedades clave para evaluar la supervivencia en un sistema:

ü  Resistencia. Es la capacidad del sistema para repeler ataques, fallas o accidentes.

ü  Reconocimiento. Es la capacidad de detectar ataques, fallas o accidentes, y si estos ocurren, evaluar los daños.

ü  Recuperación. Es la capacidad de mantener en operación los servicios esenciales en presencia de ataques, fallas o accidentes.

Este método puede ser aplicado después de la especificación de una arquitectura, durante la implementación de ésta, o posteriormente.

SNA se basa en escenarios de uso, e identifica dos tipos de escenarios. El primer tipo son los escenarios normales que se componen de una serie de pasos donde los usuarios invocan a servicios y obtienen acceso a activos, tales como bases de datos. El segundo tipo son los escenarios de intrusión, en los que se representan diferentes tipos de ataques al sistema.

SNA está compuesto por los siguientes pasos:

1. Definición del sistema. En este paso se obtiene la misión del sistema, se discute el entorno de uso en términos de capacidades y ubicaciones de los usuarios, se analizan posibles riesgos que el sistema pueda presentar en condiciones adversas, finalmente se analiza la arquitectura de software.

2. Definición de las capacidades esenciales: Se deben seleccionar aquellos servicios y activos que sean críticos para garantizar en condiciones adversas, la misión del sistema. Una vez seleccionados, estos se trazan a través de la arquitectura, para identificar los componentes que participan en proporcionar los servicios esenciales.

3. Definición de las capacidades que comprometen al sistema. En este paso se selecciona un conjunto representativo de posibles ataques, basados en el entorno de operación del sistema. Se definen los escenarios de intrusión y se trazan a través de la arquitectura, para identificar componentes que comprometan la supervivencia del sistema, logrando así el acceso y daño a éste.

4. Analizar la supervivencia: Finalmente se identifican los escenarios de intrusión que contienen los componentes esenciales y que comprometen la supervivencia del sistema. Por cada componente identificado se procede a analizarlo en términos de las capacidades de resistencia, reconocimiento y recuperación. Estos análisis se colocan en una tabla llamada: mapa de supervivencia, que contiene por cada escenario de intrusión, las estrategias de supervivencia actuales y las recomendadas con respecto a cada una de las capacidades.



Comentarios

Entradas populares de este blog

Introducción