1
Índice
Arquitectura de software Definición……………………………………………………………………….. Pag.3 Tipos…………………………………………………………………………….. Pag.3,4 Elementos que lo conforman…………………………………………………..Pag.10 Estándares según IEEE/ANSI…………………………………………………Pag.11 Métricas para la selección de la arquitectura y su verificación…………….Pag.14 Bibliografías……………………………………………………………………...Pag.19
2
Arquitectura del Software Se conoce como un conjunto de patrones que suministran un marco de referencia necesario para guiar la construcción de un software, permitiendo a los programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir el cumplimiento de todos los objetivos y restricciones de la aplicación. Esta 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.
Tipos de arquitecturas Para utilizar la arquitectura de software se sigue un conjunto de patrones arquitectónicos Un patrón arquitectónico es una solución general y reutilizable a un problema común en la arquitectura de software dentro de un contexto dado. Los patrones arquitectónicos son similares al patrón de diseño de software pero tienen un alcance más amplio. Entre los cuales podemos encontrar:
3
1. Patrón de capas Este patrón se puede utilizar para estructurar programas que se pueden descomponer en grupos de sub tareas, cada una de las cuales se encuentra en un nivel particular de abstracción. Cada capa proporciona servicios a la siguiente capa superior. 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 )
Uso
Aplicaciones de escritorio generales.
Aplicaciones web de comercio electrónico.
4
2. Patrón cliente-servidor Este patrón consiste en dos partes; un servidor y múltiples clientes. 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. Uso
Aplicaciones en línea como correo electrónico, uso compartido de documentos y banca.
3. Patrón maestro-esclavo Este patrón consiste en dos partes; maestro y esclavos. El componente maestro distribuye el trabajo entre componentes esclavos idénticos y calcula el resultado final de los resultados que devuelven los esclavos. Uso
En la replicación de la base de datos, la base de datos maestra se considera como la fuente autorizada y las bases de datos esclavas se sincronizan con ella.
Periféricos conectados a un bus en un sistema informático (unidades maestra y esclava).
5
4. Patrón de filtro de tubería
Este patrón se puede usar para estructurar sistemas que producen y procesan una secuencia de datos. Cada paso de procesamiento se incluye dentro de un componente de filtro. Los datos que se procesarán se pasan a través de las tuberías. Estas tuberías se pueden utilizar para el almacenamiento en búfer o con fines de sincronización. Uso:
Compiladores Los filtros consecutivos realizan análisis léxico, análisis sintáctico y generación de código.
Flujos de trabajo en bioinformática.
5. Patrón del agente Este patrón se usa para estructurar sistemas distribuidos con componentes desacoplados. Estos componentes pueden interactuar entre sí mediante invocaciones de servicios remotos. Un componente de intermediario es responsable de la coordinación de la comunicación entre los componentes. Los servidores publican sus capacidades (servicios y características) a un intermediario. Los clientes solicitan un servicio del intermediario y el intermediario redirecciona al cliente a un servicio adecuado desde su registro. Uso: Software de Message Broker Como Apache ActiveMQ , Apache Kafka , RabbitMQ y JBoss Messaging .
6
6. Patrón de igual a igual En este patrón, los componentes individuales se conocen como pares. Los pares pueden funcionar tanto como un cliente, solicitando servicios de otros pares, y como un servidor, proporcionando servicios a otros pares. Un par puede actuar como un cliente o como un servidor o como ambos, y puede cambiar su rol dinámicamente con el tiempo. Uso
Redes de intercambio de archivos como Gnutella y G2 )
Protocolos multimedia como P2PTV y PDTP. 7. Patrón de bus de evento
Este patrón trata principalmente con eventos y tiene 4 componentes principales; fuente de evento, escucha de evento, canal y bus de evento. Las fuentes publican mensajes en canales particulares en un bus de eventos. Los oyentes se suscriben a canales particulares. Los oyentes son notificados de los mensajes que se publican en un canal al que se han suscrito anteriormente. Uso
Desarrollo de Android
Servicios de notificación
7
8. Patrón de modelo-vista-controlador Este patrón, también conocido como patrón MVC, divide una aplicación interactiva en 3 partes, como 1. modelo — contiene la funcionalidad y los datos básicos 2. vista : muestra la información al usuario (se puede definir más de una vista) 3. 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. Uso
Arquitectura para aplicaciones World Wide Web en los principales lenguajes de programación.
Marcos web como Django y Rails. Modelo-vista-controlador 9. Patrón de pizarra Este patrón es útil para problemas para los que no se conocen estrategias de solución deterministas. El patrón de pizarra consta de 3 componentes principales.
pizarra : una memoria global estructurada que contiene objetos del espacio de solución
8
fuente de conocimiento : módulos especializados con su propia representación
componente de control: selecciona, configura y ejecuta módulos.
Todos los componentes tienen acceso a la pizarra. Los componentes pueden producir nuevos objetos de datos que se agregan a la pizarra. Los componentes buscan tipos particulares de datos en la pizarra, y pueden encontrarlos por coincidencia de patrones con la fuente de conocimiento existente. Uso:
Reconocimiento de voz
Identificación y seguimiento del vehículo
Identificación de la estructura proteica
Sonar señala la interpretación 10.
Patrón de intérprete
Este patrón se usa para diseñar un componente que interpreta programas escritos en un lenguaje dedicado. Especifica principalmente cómo evaluar las líneas de programas, conocidas como oraciones o expresiones escritas en un idioma particular. La idea básica es tener una clase para cada símbolo del idioma. Uso
Lenguajes de consulta de base de datos como SQL.
Idiomas utilizados para describir los protocolos de comunicación. 9
Elementos conforman La Arquitectura del Software 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.
Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa. Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:
La visión estática: describe qué componentes tiene la arquitectura. La visión funcional: describe qué hace cada componente. La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y cómo interactúan entre sí.
10
Estándares según IEEE/ANSI El IEEE es una autoridad líder y de máximo prestigio en las áreas técnicas derivadas de la eléctrica original: desde ingeniería computacional, tecnologías biomédica y aeroespacial, hasta las áreas de energía eléctrica, control, telecomunicaciones y electrónica de consumo, entre otras. Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales. ANSI Instituto Nacional Estadounidense de Estándares: Organización Privada sin fines de lucro fundada en 1918, la cual administra y coordina el sistema de estandarizar voluntaria del sector privado de los Estados Unidos .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. 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 ANSI acredita a organizaciones que realizan certificaciones de productos o de personal de acuerdo con los requisitos definidos en los estándares internacionales. ISO/IEC 42010:2007 ISO/IEC/IEEE 42010 define los requisitos que debe cumplir las descripciones que se hagan de arquitecturas empresariales, de sistemas o de software. Su principal objetivo es estandarizar la práctica de descripción de arquitecturas, presentando un glosario común y un fundamento conceptual que faciliten la especificación de requisitos, la definición, comunicación y revisión de arquitecturas a partir de las descripciones que se realicen de la misma - a través de marcos de trabajo y de lenguajes para la descripción de arquitecturas.
11
ISO/IEC 42207:2008 La estructura del estándar ha sido concebida de manera que pueda ser adaptada a las necesidades de cualquiera que lo use. Para conseguirlo, el estándar se basa en dos principios fundamentales: modularidad y responsabilidad. Con la modularidad se pretende conseguir procesos con un mínimo acoplamiento y una máxima cohesión. En cuanto a la responsabilidad, se busca establecer un responsable para cada proceso, facilitando la aplicación del estándar en proyectos en los que pueden existir distintas personas u organizaciones involucradas, no importando el uso que se le dé a este
IEEE 1012 El estándar consiste en la verificación y validación de un software, es un procedimiento que está basado en normas de calidad en algunos modelos de vida de un software Se describen los procesos de verificación y validación de software, que determinan si los productos de desarrollo de una actividad determinada cumplen con los requisitos de esa actividad, y si el software satisface su uso previsto y las necesidades del usuario. Esta determinación puede incluir análisis, evaluación, revisión, inspección, evaluación y prueba de productos y procesos de software. Los procesos de V&V evalúan el software en el contexto del sistema, incluidos el entorno operativo, el hardware, el software de interfaz, los operadores y los usuarios.
12
IEEE 1471 IEEE 1471 es el nombre corto de un estándar conocido formalmente como ANSI / IEEE 1471-2000, Práctica recomendada para la descripción de arquitectura de sistemas de software intensivo. Dentro del lenguaje del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), esta es una "práctica recomendada", la menos normativa de sus estándares. En 2007, ISO / IEC JTC1 / SC7 adoptó esta norma como ISO / IEC 42010: 2007, Ingeniería de sistemas y software. Práctica recomendada para la descripción arquitectónica de sistemas de software intensivo.
IEEE/ISO/IEC 24765 ISO / IEC / IEEE 24765: 2017 proporciona un vocabulario común aplicable a todos los trabajos de ingeniería de sistemas y software. Fue preparado para recopilar y estandarizar la terminología. ISO / IEC / IEEE 24765: 2017 está destinado a servir como una referencia útil para aquellos en el campo de la tecnología de la información y para fomentar el uso de estándares de ingeniería de software y sistemas preparados por la ISO y las organizaciones de enlace IEEE Computer Society y Project Management Institute. ISO / IEC / IEEE 24765: 2017 incluye referencias a los estándares de fuente activa para definiciones, de modo que los conceptos y requisitos de ingeniería de sistemas y software puedan explorarse más a fondo.
13
Métricas para la selección de la arquitectura y su verificación. A continuación se definirán recomendaciones a tener en cuenta además de los procedimientos que deben ejecutar los integrantes del equipo. A su vez, las tareas de SQA en el proceso de diseño deben comprender:
Verificación de que todos los elementos de diseño que no cumplieran con la calidad requerida sean procesados de acuerdo a los estándares y procedimientos establecidos. Verificación de la existencia y uso de una matriz de trazabilidad para todos los requerimientos de diseño. Verificación de la contemplación de todos los requerimientos especificados referidos a materia de diseño.
Especificar la Arquitectura
A fin de asegurar que la arquitectura seleccionada sea la adecuada para llevar a cabo el desarrollo, el equipo de trabajo deberá definir un proceso de evaluación iterativo para las diferentes arquitecturas pre-seleccionadas. Dicho proceso de evaluación deberá definir mínimamente las siguientes actividades:
Recopilación de escenarios: desarrollar un conjunto de casos de uso (o user stories) para representar al sistema desde el punto de vista del usuario. Deducción de requisitos, restricciones y descripciones del entorno: asegurar que se entienden todas las preocupaciones de los participantes. Descripción de los estilos/patrones arquitectónicos elegidos para dirigir los escenarios y requisitos. Evaluación de los atributos de calidad: la evaluación de un diseño arquitectónico deberá tener en cuenta la confiabilidad, desempeño, seguridad, facilidad de mantenimiento, flexibilidad, facilidad de prueba, portabilidad, facilidad de reutilización e interoperabilidad.
14
Identificación de la sensibilidad de los atributos: la realización de pequeños cambios en la arquitectura para identificar el impacto que tienen los mismos sobre un atributo de calidad específico. Análisis de las arquitecturas alternas (descritas en el paso 3) empleando el análisis de sensibilidad aplicado en el paso 5.
El empleo de este proceso permitirá descartar aquellas arquitecturas que no son idóneas para desarrollar el producto, o modificar aquellas que tienen potencial pero no cumplen con los requisitos necesarios. Una vez que se tiene este conjunto reducido, se aplica nuevamente el proceso hasta obtener la arquitectura óptima.
Especificar los Componentes
El equipo deberá definir lineamientos generales que le permitan avanzar en el diseño de componentes. Dichos lineamientos son:
Definir convenciones de asignación de nombres para los componentes. Modelar las dependencias de izquierda a derecha y la herencia de abajo (componentes derivados) hacia arriba (componentes principales).
Las técnicas sugeridas para el diseño de componentes son:
Minimizar dependencias entre componentes evitando propagar los cambios entre muchos componentes y por ende sus pruebas. Diseñar componentes cohesivos que encapsulen un conjunto de responsabilidades. Aislar las dependencias con tecnologías Middleware. Utilizar la descomposición para estructurar componentes jerárquicamente. Reducir al mínimo las llamadas entre componentes, ya que pueden resultar costosas si los componentes se distribuyen.
Especificar las Interfaces
La estructura de las páginas deberá ser fragmentada en varias secciones de manera tal de generar un flujo visual óptimo que le permita al usuario encontrar lo que desea con el menor esfuerzo posible. El siguiente esquema ofrece una estructuración básica que deberá tener una GUI. En la misma se destacan las siguientes secciones: 15
Cabecera: donde se proporciona la información básica acerca de la página. Aquí se destaca el logotipo de la organización encargada de la página y la fecha actual. Contenidos: donde están estructurados los diferentes contenidos que se ofrecen Menú: se presentan las opciones de navegación de la página Pie de Página: se muestra información respecto al creador de la página y derechos de copyright.
Aspectos de Usabilidad
No deberá tener funciones ambiguas u engorrosas de utilizar. No deben haber 2 caminos diferentes para completar la misma función, es decir, cada función debe usarse siempre de la misma manera. La interfaz debe (de ser posible) anticiparse a las necesidades del usuario. Cada cambio u error en el sistema debe ser comunicado al usuario. Se deberá destacar aquellas funcionalidades que son relevantes Los iconos gráficos deberán representar las mismas funciones en distintas interfaces.(Ejemplo: Un icono de tilde verde no puede representar un operación bien realizada en una GUI, y en otra GUI representar la operación de añadir algun dato) Se deberán usar frases cortas y concisas al comunicarse con el usuario.
Métricas Sugeridas
A continuación se sugieren una serie de métricas que el equipo deberá tener en cuenta a lo largo del proceso de diseño.
Métricas de Diseño Arquitectónico: en este punto se sugiere el uso de las métricas de Fenton para comparar diferentes arquitecturas de un programa mediante un conjunto de dimensiones directas (por ejemplo: tamaño, profundidad, anchura, relación arco-nodo). Métricas de Diseño de Componentes: estas métricas están centradas en la cohesión, acoplamiento y complejidad del módulo. Para las métricas de cohesión se sugiere utilizar las métricas establecidas por Bieman y Ott. 16
Para las métricas de acoplamiento se sugiere utilizar el enfoque de Dhama que establece la siguiente métrica para el acoplamiento de un módulo: mc = k/M Donde k=1 es una constante de proporcionalidad y M queda definido de la siguiente manera: M = di + a* ci + do + b*co + gd + c*gc + w + r Donde: a=b=c=2 di = número de parámetros de datos de entrada ci = número de parámetros de control de entrada do = número de parámetros de datos de salida co = número de parámetros de control de salida gd = número de variables globales usadas como datos gc = número de variables globales usadas como control w = número de módulos llamados (expansión) r = número de módulos que llaman al módulo en cuestión (concentración) Cuanto mayor es el valor de mc, menor es el acoplamiento de módulo. Para las métricas de complejidad, se recomienda el uso de la métrica de Complejidad Ciclomática.
Métricas de Diseño de Interfaces: se sugiere la conveniencia de la representación (CR) como métrica de diseño para interfaces hombremáquina. Una GUI típica usa entidades de representación, iconos gráficos, texto, menús, ventanas y otras para ayudar al usuario a completar tareas. Para realizar una tarea dada usando una GUI, el usuario debe moverse de una entidad de representación a otra. Las posiciones absolutas y relativas de cada entidad de representación, la frecuencia con que se utilizan y el “costo” de la transición de una entidad de representación a la siguiente contribuirá a la conveniencia de la interfaz. Para una representación específica se pueden asignar costos a cada secuencia de acciones de acuerdo con la siguiente relación:
Costos = Ó[frecuencia de transición (ki) x costos de transición (ki)] Donde k es la transición i específica de una entidad de representación a la siguiente cuando se realiza una tarea específica. Esta suma se da con todas las 17
transiciones de una tarea en particular o conjunto de tareas requeridas para conseguir alguna función de la aplicación. El costo puede estar caracterizado en términos de tiempo, retraso del proceso o cualquier otro valor razonable, tal como la distancia que debe moverse el ratón entre entidades de la representación. Para calcular la representación óptima de una GUI, la superficie de la interfaz (el área de la pantalla) se divide en una cuadrícula. Cada cuadro de la cuadrícula representa una posible posición de una entidad de la representación. Para una cuadrícula con N posibles posiciones y K diferentes entidades de representación para colocar, el número posible de distribuciones se representa de la siguiente manera: Número posible de distribuciones = [N !/ (K! * (N - K)!] * K! Es importante Hay que destacar que la selección de un diseño de GUI puede guiarse con métricas tales como CR, pero el árbitro final debería ser la respuesta del usuario basada en prototipos de GUI. -Herramientas: A fin de automatizar y reducir la carga de trabajo sobre el equipo, se sugiere el uso de las siguientes herramientas:
Django: el desarrollo de aplicaciones sobre esta herramienta ofrece una arquitectura MVC compuesta por Models y Views, en donde el programador define la lógica de su aplicación en los Models y la forma de presentar los datos en los Views. A su vez, ofrece un nivel de definición de los componentes mediante los egg packages, que permite hacer utilización de un componente específico en varios fuentes.
A nivel de desarrollo visual de las páginas web, Django permite hacer uso de los llamados template tags, que posibilitan el reuso de componentes HTML a lo largo de varios archivos HTML.
Dreamviewer: esta herramienta posibilita la creación de páginas web utilizando un esquema de drag&drop, que facilita el trabajo de los diseñadores. Proporciona un conjunto de plugins que pueden ser añadidos para mejorar la presentación.
18
BibliografĂas https://martinez2019blog.blogspot.com/2019/05/ieee-1012-el-estandar-enla.html https://martinez2019blog.blogspot.com/2019/05/arquitectura-del-softwarela.html http://redesitemas2016.blogspot.com/2016/06/organizaciones-mundiales.html https://www.ecured.cu/Arquitectura_de_software https://medium.com/@maniakhitoccori/los-10-patrones-comunes-dearquitectura-de-software-d8b9047edf0b https://unpsjb.github.io/ids3t/diseno.html
19