Arquitectura de software
Autor: Graciela Gonzรกlez Profesor: Ing. Johnny Herrera Salcedo Sistemas I Agosto 2020
Contenidos 4
Arquitectura de software
6
Tipos de Arquitecturas
18 Elementos de la arquitectura 22 Estándares según IEEE/ANSI 28 Métricas para la selección de la arquitectura y su verificación 36 Bibliografía
Arquitectura de software Conjunto de patrones que proporcionan un marco de referencia necesario para guiar la construcción de un software. La arquitectura de software es el diseño de más alto nivel de la estructura de un sistema.
Es considerada el nivel más alto en el diseño de la arquitectura de un sistema puesto que establecen la estructura, funcionamiento e interacción entre las partes del software.
En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".
La arquitectura de software forma la columna vertebral para construir un sistema de software, es en gran medida responsable de permitir o no ciertos atributos de calidad del sistema entre los que se destacan la confiabilidad y el rendimiento del software. Ejemplos de atributos de calidad son el rendimiento, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o
presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos. La manera en que se estructura un sistema permitirá o impedirá que se satisfagan los atributos de calidad. Además de los atributos de calidad, la arquitectura de software juega un papel fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se enfoca en partir el sistema en componentes que serán desarrollados por individuos o grupos de individuos. En En resumen, resumen, la la arquitectura arquitectura del del software software es es una una disciplina disciplina que que merece merece la la pena pena estudiar estudiar en en profundidad, profundidad, necesaria necesaria para para la la creación creación de de software software con con éxito. éxito. Cualquier Cualquier programador programador profesional profesional debería debería estudiar estudiar las las arquitecturas arquitecturas yy los los estilos estilos arquitectónicos arquitectónicos más más comunes comunes y, y, por por supuesto, supuesto, tenerlos tenerlos en en cuenta cuenta al al desarrollar desarrollar las las aplicaciones. aplicaciones.
Tipos de Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Para algunos autores existe una sutil diferencia entre tipos de arquitectura (o estilos de arquitectura) y patrones de arquitectura. Diciendo que un estilo de arquitectura es una manera conceptual como se creará o trabajará el sistema, mientras que un patrón de arquitectura describe una solución para la aplicación de un estilo de arquitectura a nivel de subsistemas o módulos y sus relaciones. Para otros autores son conceptos similares.
arquitecturas
Como te decíamos al principio, la arquitectura de software sigue una serie de pasos en su construcción, pero ¿sabes
cuáles son? Aunque existen distintos modelos de arquitectura y procesos de desarrollo, podemos encontrar los siguientes arquetipos comunes, que describen los elementos y la relación entre ellos:
Cliente-Servidor La Arquitectura Cliente Servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada usuario.
El Cliente-Servidor es un sistema distribuido entre múltiples Procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. El componente del servidor proporcionará servicios a múltiples componentes del cliente. Los clientes solicitan servicios del servidor y el servidor proporciona servicios relevantes a esos clientes. Además, el servidor sigue escuchando las solicitudes de los clientes.
Funciones de los ClientesServidor • Manejo de la interfaz de usuario. • Captura y validación de los datos de entrada. • Generación de consultas e informes sobre las bases de datos. Por su parte los servidores realizan, entre otras, las siguientes funciones: • Gestión de periféricos compartidos. • Control de accesos concurrentes a bases de datos compartidas. • Enlaces de comunicaciones con otras redes de área local o extensa.
Ejemplos Aplicaciones en línea como correo electrónico, uso compartido de documentos y banca.
Arquitectura por capas Especialización de la arquitectura clienteservidor, que se puede utilizar para estructurar programas que se pueden descomponer en grupos de subtareas con un reparto claro de funciones. Una capa solamente tiene relación con la siguiente.
Las 4 capas más comúnmente encontradas de un sistema de información general son las siguientes. • Capa de presentación (también conocida como capa UI) • Capa de aplicación (también conocida como capa de servicio) • Capa de lógica de negocios (también conocida como capa de dominio) • Capa de acceso a datos (también conocida como capa de persistencia)
El estilo de arquitectura basado en capas se identifica por las siguientes características: • Describe la descomposición de servicios de forma que la mayoría de la interacción ocurre solamente entre capas vecinas. • Las capas de una aplicación pueden residir en la misma maquina física (misma capa) o puede estar distribuido sobre diferentes computadores (ncapas). • Los componentes de cada capa se comunican con otros componentes en otras capas a través de interfaces muy bien definidas. • Este modelo ha sido descrito como una “pirámide invertida de re-uso” donde cada capa agrega responsabilidad y abstracción a la capa directamente sobre ella.
EJEMPLOS Algunos tipos comunes de aplicaciones por capas incluyen: • Aplicaciones de línea de negocios (LOB), como contabilidad, y sistemas de gestión de clientes. • Aplicaciones web Corporativas y sitios Web • Aplicaciones corporativas de escritorio o clientes inteligentes con servidores centralizados de aplicación con lógica de negocios.
Arquitectura Orientada a servicios La arquitectura orientada a servicios (SOA, siglas del inglés Service Oriented Architecture) permite que la funcionalidad de la aplicación se exponga y consuma como un conjunto de servicios. Los servicios usan una forma estándar de interacción que les permiten ser invocados, publicados y descubiertos. Los servicios SOA están enfocados en proveer un esquema y una interacción basada en mensajes con una aplicación. Los servicios SOA proveen interfaces con alcance de aplicación en vez de interfaces del nivel de componente u objeto. En otras palabras un servicio SOA no debe ser tratado como un servicio proveído por un componente.
BENEFICIOS Los mayores beneficios del estilo de arquitectura SOA son: • Alineación con el Dominio. El re-uso de servicios comunes con interfaces estándar incrementa las oportunidades de negocios y reduce costos. • Abstracción. Los servicios son autónomos y se accede a ellos a través de un contrato formal lo que provee desacople y abstracción. • Capacidad de Descubrimiento. Los servicios pueden exponer descripciones que permiten a otras aplicaciones y servicios localizarlos y determinar de forma automática la interfaz.
El estilo de arquitectura SOA se
EJEMPLOS
caracteriza por:
Ejemplos comunes de aplicaciones orientadas a servicios incluyen:
• Estar basado en el diseño de servicios que reflejan las actividades del negocio en el mundo real, estas actividades forman parte de los procesos de negocio de la compañía.
• Sistemas que comparten información médica. (Harvard Medical School)
• Representar los servicios utilizando descripciones de negocio para asignarles un contexto de negocio.
• Sistemas de reservas (Starwood Hotels and Resorts)
• Requerir un conjunto de pruebas que determinen que es un buen servicio.
• Sistemas de WorkFlow. (State Children’s Health Insurance Program)
• Tener requerimientos de infraestructura específicos y únicos para este tipo de arquitectura, en general se recomienda el uso de estándares abiertos para la interoperabilidad y transparencia en la ubicación de servicios.
Arquitectura en pizarra La arquitectura de software en pizarra es un modelo arquitectónico de software habitualmente utilizado en sistemas expertos, sistemas multiagente y, en general, sistemas basados en el conocimiento. Es útil para problemas para los que no se conocen estrategias de solución deterministas. Arquitectura en pizarra consta de 3 componentes principales. pizarra: una memoria global estructurada que contiene objetos del espacio de solución. fuente de conocimiento: módulos especializados con su propia representación. componente de control: selecciona, configura y ejecuta módulos.
BENEFICIO Esta arquitectura es tremendamente útil cuando el problema a resolver (o algoritmo a implementar) es extremadamente complejo en términos cognitivos. Es decir, cuando el flujo de control del algoritmo es enrevesado, o simplemente, no se tiene un conocimiento completo del problema a resolver.
El estilo de arquitectura en pizarra se identifica por las siguientes características: • La arquitectura en pizarra consta de múltiples elementos funcionales, denominados agentes, y un instrumento de control denominado pizarra.
• Los agentes suelen estar especializados en una tarea concreta o elemental. Todos ellos cooperan para alcanzar una meta común, si bien, sus objetivos individuales no están aparentemente coordinados.
• El comportamiento básico de cualquier agente consiste en examinar la pizarra, realizar su tarea y escribir sus conclusiones en la misma pizarra. De esta manera, otro agente puede trabajar sobre los resultados generados por otro.
• La computación termina cuando se alcanza alguna condición deseada entre los resultados escritos en la pizarra.
EJEMPLOS Reconocimiento de voz
• La pizarra tiene un doble papel. Por una Identificación y
parte, coordina a los distintos agentes y, seguimiento del vehículo por otra, facilita su intercomunicación. El Identificación de la estado inicial de la pizarra es una descripción del problema que resolver y el estructura proteica estado final será la solución del problema. Sonar señala la interpretación. • Los resultados generados por los agentes deben responder a un lenguaje y semántica común. En general, se suelen utilizar formalismos lógicos o matemáticos, tales como expresiones lógicas de primer orden.
Modelo–vista– controlador Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que separa los datos y principalmente lo que es la lógica de negocio de una aplicación de su representación y el módulo encargado de gestionar los eventos y las comunicaciones. Este patrón divide una aplicación interactiva en 3 partes: Modelo: contiene la funcionalidad y los datos básicos. Vista: muestra la información al usuario (se puede definir más de una vista). Controlador : maneja la entrada del usuario.
Esto se hace para separar las representaciones internas de información de las formas en que se presenta y acepta la información del usuario. Desacopla los componentes y permite la reutilización eficiente del código. Características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.
Ventajas de MVC Las principales ventajas del uso del patrón MVC son (4):
Ejemplos
• La separación del Modelo y
• Arquitectura para
la Vista, lo cual logra separar los datos, de su representación visual.
• Facilita el manejo de errores. • Permite que el sistema sea escalable si es requerido.
• Es posible agregar múltiples representaciones de los datos.
aplicaciones World Wide Web en los principales lenguajes de programación.
• Marcos web como Django y Rails.
Elementos de la arquitectura de software Un componente es un objeto de software específicamente diseñado para cumplir con cierto propósito.
Componentes La arquitectura de software se compone por:
• clientes y servidores. • bases de datos. • filtros. • niveles en sistemas jerárquico.
Interacciones Entre los componentes de la arquitectura de software existe un conjunto de interacciones entre las que sobresalen :
• llamadas a procedimientos. • comportamiento de variables. • protocolos cliente servidor. • transmisión asíncrona de eventos.
Elementos para generar una arquitectura de software
Sistemas de patrones arquitectónicos Los patrones arquitectónicos, o patrones de arquitectura, también llamados arquetipos 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.
Modelos de arquitectura de software, ¿los conoces?
desarrollo del software, de manera que la arquitectura es el resultado de seguir un script Cada nivel de diseño y desarrollo Modelo de Referencia de estos sistemas presenta sus propias técnicas de análisis, sus Un modelo de Referencia es una división de funcionalidad reglas de composición, sus junto con el flujo de datos entre problemas, sus ventajas, etc., las piezas. Es un estándar de entre sus modelos podemos descomposición de un encontrar: problema conocido, en partes Modelo dinámico. Aquí, el objetivo que cooperativamente es describir el comportamiento del resuelven el problema. sistema a través del tiempo, y sus Modelo arquitectónico de componentes son: modelo de Referencia máquina de estados, vista de actividades, vista de interacción. Es un modelo de referencia mapeado en elementos de software que Modelo estructural. Sirve para cooperativamente describir los distintos tipos y relaciones estáticas que existen implementan la funcionalidad definida en el modelo de entre los distintos objetos de un referencia y flujos de datos sistema. En él encontramos: diagramas de clases, de casos de entre ellos. Requerimientos funcionales y no funcionales Modelos de proceso. Pone el foco Generalmente se considera en los pasos involucrados en el que los requerimientos de un uso, de secuencia.
sistema se pueden dividir en dos categorías: Requerimientos Funcionales (RFs) y Requerimientos No Funcionales (RNFs).
• Requerimientos de usuario.
Comportamiento del sistema, frecuentemente se expresan en forma de casos de uso. • Requerimientos funcionales detallados. Requerimientos funciones. Son • Requerimientos de sistema. declaraciones de los servicios que Describen el mínimo hardware y proveerá el sistema, de manera software para que un sistema de en que éste reaccionará en información pueda funcionar. situaciones particulares. Por otra parte, los RNFs tienen Requerimientos no funcionales. que ver con la manera en que el Son restricciones de los servicios sistema soporta a los RFs. Estos o funciones ofrecidos por el incluyen: sistema. Incluyen restricciones de • Reglas de negocio. expresan tiempo, sobre el proceso de reglas de la organización que desarrollo, estándares, etc. deben ser soportadas por el sistema. De acuerdo a Wiegers , los RFs • Atributos de calidad. engloban los distintos tipos de • Restricciones. Expresan requerimientos que se reflejan en aspectos que deben los comportamientos de la considerarse al realizar el diseño aplicación y que incluyen: y limitan las decisiones que se pueden tomar. • Requerimientos de negocio. Interfaces externas. Motivación de negocio para que • Especificaciones de interfaces exista un sistema. de otros sistemas con los que se interactúa.
Estándares según IEEE/ANSI
El internet tiene sus libertades, pero también tiene reglamentos o lineamientos que ayuda a poder llevar a cabo una eficaz y buena organización de la conexión, así como lo que se debe hacer para lograr una. Aquí mostraremos las dos mas importantes, veamos de que tratan….
El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) fue Creada el 1 de enero de 1963 esta Es la asociación profesional mas grande del mundo sin fines de lucro. Su objetivo principal es aplicar y avanzar innovación tecnológica de excelencia a beneficio de la humanidad y esta esta dedicada principalmente a la estandarización.
Creación estándar IEEE 802.X El proyecto IEEE 802 fue creado en Febrero de 1980. Fue desarrollado simultáneamente y en cooperación al modelo OSI ya que comparten características e interactúan muy bien. Se crea con el fin de desarrollar estándares para que tecnologías de diferentes fabricantes pudieran trabajar juntas e integrarse sin problemas.
Características y fundamentos estándar IEEE 802.X
Los comités 802 del IEEE se concentran principalmente en la interfaz física relacionada con los niveles físicos y de enlace de datos del modelo de referencia OSI de la ISO. Los productos que siguen las normas 802 incluyen tarjetas de la interfaz de red, bridges, utilizados para crear LANs de par trenzado y cable coaxial. El nivel de enlace se divide en 2 subniveles MAC y LLC. Las especificaciones 802 definen El proyecto IEEE 802 define aspectos relacionados al cableado estándares para las Tarjetas de red (NIC), Componentes de redes de área físico y transmisión de datos global (WAN, Wide Área Networks), correspondiente a las capas Componentes utilizadas para crear físicas y enlace de datos. Esta redes de cable coaxial y de par dividido según la funciones necesarias para el funcionamiento trenzado, Las especificaciones 802 definen la forma en que las tarjetas de de la LAN. Identificado por un numero 802.x para referirse a los red acceden y transfieren datos sobre el medio físico. Éstas incluyen estándares que proponen, conexión, mantenimiento y algunos de los cuales son muy conocidos: Ethernet (IEEE 802.3), desconexión de dispositivos de red, La selección del protocolo a ejecutar en el o Wi- Fi (IEEE 802.11). Está, nivel de enlace de datos es la decisión incluso, intentando estandarizar más importante que se debe tomar Bluetooth en el 802.15 (IEEE cuando se diseña una red de área local 802.15). (LAN).
Normas IEEE
Características Estándar IEEE 802.X
IEEE 802.1 Describe la interrelación entre las partes del documento y su relación con el Modelo de Referencia OSI. También contiene información sobre normas de gestión de red e interconexión de redes. Establece los estándares de interconexión relacionados con la gestión de redes.
IEEE 802.1 : Protocolos superiores de redes de área local.
IEEE 802.2 Define el control de enlace lógico (LLC), que es la parte superior de la capa enlace en las redes de área local. La subcapa LLC presenta un interfaz uniforme al usuario del servicio enlace de datos, normalmente la capa de red.
IEEE 802.5 : Token Ring .
IEEE 802.3 La primera versión fue un intento de estandarizar Ethernet aunque hubo un campo de la cabecera que se definió de forma diferente, posteriormente ha habido ampliaciones sucesivas al estándar que cubrieron las ampliaciones de velocidad.
IEEE 802.8 : Grupo de Asesoría Técnica sobre fibra óptica (abandonado) .
IEEE 802.2 : Control de enlace lógico. IEEE 802.3 : Ethernet . IEEE 802.4 : Token Bus (abandonado) .
IEEE 802.6 : Red de área metropolitana (abandonado) . IEEE 802.7 : Grupo de Asesoría Técnica sobre banda ancha (abandonado).
IEEE 802.9 : RAL de servicios integrados (abandonado) . IEEE 802.10 : Seguridad interoperable en RAL(abandonado) .
IEEE 802.11 : Red local inalámbrica, también conocido como Wi-Fi . IEEE 802.12 : Prioridad de demanda. IEEE 802.13 : (no usado) . IEEE 802.14 : Cable módems, es decir módems para televisión por cable. (abandonado) . IEEE 802.15 : Red de área personal inalámbrica, que viene a ser Bluetooth. IEEE 802.16 : Acceso inalámbrico de Banda Ancha, también llamada WiMAX, para acceso inalámbrico desde casa. IEEE 802.17 : Anillos de paquetes con recuperación, se supone que esto es aplicable a cualquier tamaño de red, y está bastante orientado a anillos de fibra óptica. IEEE 802.18 : Grupo de Asesoría Técnica sobre Normativas de Radio.
IEEE 802.19 : Grupo de Asesoría Técnica sobre Coexistencia. IEEE 802.20 : Acceso inalámbrico de Banda ancha móvil, que viene a ser como el 16 pero en movimiento. IEEE 802.21 : Interoperabilidad independiente del medio. IEEE 802.22 : Red inalámbrica de área regional.
ANSI es un estándar publicado por el Instituto Nacional Estadounidense de Estándares (ANSI), para el lenguaje de programación C. Se recomienda a los desarrolladores de software en que cumplan con los requisitos descritos en el documento para facilitar así la portabilidad del código. ANSI acredita a organizaciones que realizan certificaciones de productos o de personal de acuerdo con los requisitos definidos en los estándares internacionales. Los programas de acreditación ANSI se rigen de acuerdo a directrices internacionales en cuanto a la verificación gubernamental y a la revisión de las validaciones. Estos estándares aseguran que las características y las prestaciones de los productos son consistentes, es decir, que la gente use dichos productos en los mismos términos y que esta categoría de productos se vea afectada por las mismas pruebas de validez y calidad. Esta organización aprueba estándares que se obtienen como fruto del desarrollo de tentativas de estándares por parte de otras organizaciones, agencias gubernamentales, compañías y otras entidades.
Creación estándar ANSI En1918, cinco sociedades dedicadas al mundo de la ingeniería y tres agencias gubernamentales fundaron el Comité Estadounidense de Estándares para la Ingeniería (en inglés AESC: American Engineering Standards Committee). Este comité se convirtió más tarde en el año 1928 en la Asociación de Estándares Estadounidense (en inglés ASA: American Standards Association). En 1966, ASA sufrió una reorganización para convertirse en el Instituto de Estándares de los Estados Unidos de América (en inglés USASI: The United States of América Standards Institute). El nombre tal cual lo conocemos actualmente fue adoptado en 1969 Y es publicado como el Instituto Nacional Estadounidense de Estándares (ANSI en ingles American National Standards Institute)
ANSI C ANSI C es un estándar publicado por el Instituto Nacional Estadounidense de Estándares (ANSI), para el lenguaje de programación C. Se recomienda a los desarrolladores de software en C que cumplan con los requisitos descritos en el documento para facilitar así la portabilidad del código. El primer estándar que se publicó para C fue el de ANSI, si bien este estándar fue adoptado posteriormente por la International Organization for Standardization (ISO) y revisiones posteriores publicadas por ISO han sido adoptadas por ANSI. El término ANSI C es de uso más frecuente en la industria que ISO C. Un término más neutral es estándar C.
Meticas para la selección de la arquitectura y su verificación En el desarrollo de software, la detección temprana de problemas de arquitectura de software es clave. Ayuda a mitigar el riesgo de un mal rendimiento, y reduce el coste de reparación de éstos problemas. Así que, se mencionaran las métricas de la arquitectura de software para construir proyectos escalables.
Las cuatro métricas clave de Nicole Forsgren, descritas en el libro Accelerate, y denominadas “Adopt” en el Thoughtworks Radar, diferencian entre organizaciones de tecnología de bajo, medio y alto rendimiento: plazo de entrega, frecuencia de despliegue, tiempo medio de restablecimiento (MTTR) y porcentaje de fallo de cambio. De hecho, se ha descubierto que estas cuatro métricas clave son una herramienta sencilla y a la vez poderosa para ayudar tanto a los líderes como a los equipos a centrarse en la medición y la mejora de lo que importa. También se utilizan algunas métricas específicas del proyecto relacionadas con el rendimiento. Acoplamiento y Cohesión a través de los módulos.
Métricas desde un punto de vista estructural – Tamaño del componente (número de declaraciones) – Acoplamiento de componentes
– Cohesión de los componentes – Complejidad de los componentes (WMC o complejidad media)
Componente
Métricas desde un punto de vista estructural
Se mide el rendimiento y la
clases del componente) y el escalabilidad mediante el uso porcentaje de código que el de funciones automatizadas componente representa en de acondicionamiento físico toda la base de código. continuo que funcionan en la Los que impactan la producción. modularidad y la cohesión del sistema. La complejidad También se hace un seguimiento del acoplamiento del componente de los componentes (entrante, (complejidad ciclomática) es saliente y total), el tamaño del una buena métrica que apunta a la sostenibilidad componente (número de general del código. declaraciones en todas las
Un componente es un objeto de software específicamente diseñado para cumplir con cierto propósito. (Ejemplo, espacio de nombres o un paquete Java.)
Cohesión y acoplamiento Es importante tener una alta cohesión en los módulos, y un bajo acoplamiento en toda la arquitectura. El bajo acoplamiento es muy importante porque disminuye el riesgo de efecto dominó al hacer cambios en el programa. Por lo tanto, el bajo acoplamiento es muy importante para mantener la arquitectura sostenible. La mantenibilidad es la cualidad más importante que muestra un bajo acoplamiento.
Métricas
Desacoplamiento Otro enfoque muy interesante es, en lugar de medir el acoplamiento, medir el desacoplamiento, es decir, la modularidad de la arquitectura. Una buena modularidad significa fácil mantenimiento y reutilización.
Complejidad Otra métrica muy importante es la complejidad. Afecta a la comprensibilidad de la arquitectura y posiblemente al rendimiento. Puede expresarse por el número de clases en la arquitectura, o el número de enlaces entre clases en la arquitectura.
Propagación del Cambio
Métricas
Matriz de probabilidades La matriz de probabilidades de propagación del cambio entre componentes, para que el arquitecto pueda, de un vistazo, evaluar la dificultad y analizar el costo de las operaciones de mantenimiento.
La Propagación del Cambio evalúa la mantenibilidad de una arquitectura basada en la probabilidad de que un cambio en una clase tenga un impacto en otras clases.
Densidad del patrón La densidad del patrón de diseño mide el porcentaje de clases en la arquitectura que forman parte de un patrón de diseño. Ayuda al diseñador a evaluar la madurez de una arquitectura. Cuanto más madura es una arquitectura, más patrones de diseño se ponen en ella, y más alta es la densidad del patrón de diseño. Es muy bueno cuando se aplica en marcos, que deben ser muy densos en patrones de diseño. Un marco con alta densidad de patrones es más comprensible y probablemente más eficaz. Esta métrica parece ser bastante difícil de usar ya que no expresa en una escala fija la madurez del diseño, sino más bien en una escala que depende del problema con el que el software trata.
Garantía de Calidad del Software arquitectónico Otra cosa interesante que hay que mencionar es la técnica de Garantía de Calidad del Software arquitectónico (SQA) para proporcionar una técnica ligera, cuyo objetivo es evaluar la calidad de la arquitectura del software así como priorizar las cosas en las que trabajar. También permite equilibrar los atributos de calidad de la arquitectura. Además, esta técnica necesita tener una arquitectura basada en componentes o en servicios para ser fácil de usar. El siguiente paso es definir un mapeo de las mediciones de calidad a niveles SQA. Dado que la técnica SQA pone énfasis en el equilibrio y la priorización entre las cualidades, es necesario utilizar la misma escala para todas las métricas.
Métricas de SO El modelo propuesto se lleva a cabo en tres pasos:
1) Modelado, identificar los Además, hay cuatro métricas específicas de SO para satisfacer las necesidades específicas de un diseño. Cada métrica evalúa respectivamente: Granularidad del servicio, Acoplamiento del servicio, Cohesión del servicio y Convergencia de la entidad comercial.
servicios en el proceso de negocio y modelar la estructura de la cartera identificada.
2) Medición, utilizar el modelo
para medir las características de calidad de los servicios en la cartera con la ayuda de las correspondientes métricas de diseño.
3) Evaluación: evaluación general de los servicios establecidos mediante la normalización de las métricas y la adición de algunos pesos, que cualquier diseñador puede personalizar para adaptar el modelo a sus necesidades.
Bibliografía Arquitectura de software. (2020, 11 de junio). Wikipedia, La enciclopedia libre. Desde https://es.wikipedia.org/w/index.php? title=Arquitectura_de_software&oldid=126848481. Arquitectura de software. Ecured. Desde https://www.ecured.cu/Arquitectura_de_software#Caracter.C3.ADs ticas ¿Qué es la arquitectura del software?. (2020, 03 de febrero). José M. Baquero García. Desde https://www.arsys.es/blog/arquitectura-software/ Arquitectura de Software. Autor Humberto Cervantes. Desde https://sg.com.mx/revista/27/arquitectura-software Patrones de arquitectura. (2020, 11 de marzo). Wikipedia, La enciclopedia libre. Desde https://es.wikipedia.org/w/index.php? title=Patrones_de_arquitectura&oldid=124188576. Patrones comunes de arquitecturas de software. (2020, 27 de febrero). Autor Juan Carlos Pelaez. Desde https://conasa.grupocibernos.com/blog/patrones-comunes-dearquitecturas-de-software
BibliografĂa Los 10 patrones comunes de arquitectura de software. (2018, 07 de septiembre). Wilber Ccori huaman. Desde https://medium.com/@maniakhitoccori/los-10-patronescomunes-de-arquitectura-de-software-d8b9047edf0b. Cliente-Servidor. Ecured. Desde https://www.ecured.cu/Cliente-Servidor. Arquitectura basada en capas. (2009, 30 mayo). Autor Juan Carlos Pelaez. Desde https://geeks.ms/jkpelaez/2009/05/30/arquitectura-basadaen-capas/. Arquitectura orientada a servicios. (2020, 1 de julio). Wikipedia, La enciclopedia libre. Desde https://es.wikipedia.org/w/index.php? title=Arquitectura_orientada_a_servicios&oldid=127390241. Arquitectura orientada a servicios. (2009, 30 de mayo). Autor Juan Carlos Pelaez. Desde https://geeks.ms/jkpelaez/2009/05/30/arquitectura-orientada-aservicios-soa/ Arquitectura en pizarra (informĂĄtica). (2019, 31 de agosto). Wikipedia, La enciclopedia libre. Desde https://es.wikipedia.org/w/index.php? title=Arquitectura_en_pizarra_(inform %C3%A1tica)&oldid=118764963.
Bibliografía Modelo–vista–controlador. (2020, 30 de julio). Wikipedia, La enciclopedia libre. Desde https://es.wikipedia.org/w/index.php?title=Modelo %E2%80%93vista %E2%80%93controlador&oldid=128123214. Arquitectura basada en Componentes.(2009, 30 de mayo). Autor Juan Carlos Pelaez. Desde https://geeks.ms/jkpelaez/2009/04/18/arquitectura-basadaen-componentes/ Diseño de software. Autor Voigtmann GmbH. Desde https://www.voigtmann.de/es/desarrollo-desoftware/arquitectura-de-software/ Requerimientos y Arquitectura. Autor Humberto Cervantes. Desde https://sg.com.mx/revista/28/requerimientos-y-arquitectura Resultados: métricas clave de la arquitectura de software. (2020, 07 de julio). Autor ekaterina novoseltseva. Desde https://apiumhub.com/es/tech-blog-barcelona/resultadosmetricas-clave-de-la-arquitectura-de-software/
