Attribute-Driven Design (ADD) 2.0

El método ADD es un enfoque a la definición de una arquitectura de software en el que se basa el proceso de diseño de los requisitos del software de atributos de calidad. ADD es un proceso de diseño recursivo que descompone un sistema o elemento del sistema mediante la aplicación de tácticas arquitectónicas [Bass 03] y los patrones que satisfacen los drivers. ADD sigue esencialmente el ciclo “Plan, Do, and Check”:

• Plan: Los atributos de calidad y las restricciones de diseño son consideradas para seleccionar qué tipos de elementos se utilizan en la arquitectura.
• Do: Los elementos son instanciados para satisfacer los atributos de calidad, así como los requisitos funcionales.
• Check: El resultado es analizado para determinar si los requisitos son satisfechos.

Este proceso se repite hasta que todos los requisitos de gran importancia arquitectónica se cumplen.

-->

Paso 1: Confirmar que existe suficiente información sobre los requerimientos

¿Que se hace en el paso 1?

En el primer paso, usted confirma que hay suficiente información acerca de los requisitos para proceder con el paso 2. En esencia, se asegura que los stakeholders ​​han dado prioridad a los requisitos de acuerdo a los objetivos de negocio y a la misión. También debe confirmar que se dispone de información suficiente sobre los atributos de calidad para proceder.

Como arquitecto, se debe priorizar la lista de requerimientos para determinar en qué elementos del sistema se deben concentrarse durante el diseño. Se deben considerar los requisitos y su impacto potencial en la estructura de la arquitectura, en orden descendente de importancia para los stakeholders. Los requisitos que no han sido priorizadas deberán ser marcados y devueltos a para su clasificación.

Además, se debe determinar si existe suficiente información acerca de los atributos de calidad del sistema. Cada atributo de calidad debe ser expresado de la forma "estímulo-respuesta", de la misma manera como escenarios de atributos de calidad [Bass 03]. Each requirement should be described as the system’s measurable quality attribute response to a specific stimulus with the following made explicit:

• Estímulo fuente

• Estímulo

• Artefacto

• Entorno

• Respuesta

• Respuesta de medida

Conocer esta información para cada atributo de calidad ayuda al arquitecto para seleccionar varios patrones de diseño y tácticas para lograr esos requisitos. Si esta información no está disponible, usted debe crear requisitos derivados o trabajar con los interesados ​​para aclarar los requisitos. En cualquier caso, los escenarios de atributos de calidad se puede utilizar para documentar estos requisitos.

¿Que decisiones de diseño se toman durante el paso 1?: No se toman decisiones de diseño durante este paso.

-->

Paso 2: Seleccionar un elemento del sistema para descomponer

¿Que se hace en el paso 2?

En este segundo paso, se debe elegir qué elemento del sistema será el enfoque de diseño en los pasos subsiguientes (el elemento con el cual se va a trabajar). Se puede llegar a este paso en una de las siguientes dos maneras:

• Caso 1: Primera iteración. Si se accede por primera vez a la Etapa 2 como parte de una "nueva creación" de desarrollo. El único elemento que puede descomponerse es el propio sistema. Por defecto, todos los requisitos son asignados a ese sistema.
• Caso 2: Más de una iteración. Se están perfeccionando un sistema parcialmente diseñado y se ha visitado el paso 2 anteriormente. En este caso, el sistema se ha dividido en dos o más elementos, y los requisitos han sido asignados a estos elementos. Debe elegir uno de estos elementos como el elemento central de las etapas subsiguientes.

En el segundo caso, es posible elegir el elemento que se centran en base a una de las cuatro áreas de interés:

1. Conocimiento de la arquitectura actual
   1. Si es el único elemento que puede elegir (por ejemplo, todo el sistema o el último elemento de la izquierda)
   2. El número de dependencias que tiene con otros elementos del sistema (por ejemplo, mayor o menor dependencias)
2. Riesgo y dificultad
3. Criterio de negocio
4. Criterio de la organización

¿Que decisiones de diseño se toman durante el paso 1?: No se toman decisiones de diseño durante este paso.

-->

Paso 3: Identificar los drivers arquitecturales candidatos

¿Que se hace en el paso 3?

En este punto, usted ha elegido un elemento del sistema a descomponerse, y las partes interesadas han dado prioridad a los requisitos que afecten a ese elemento. Durante este paso, podrás clasificar estos mismos requisitos por segunda vez en función de su impacto relativo en la arquitectura. Esta segunda clasificación puede ser tan simple como la asignación de "alto impacto", "medio impacto" o "bajo impacto" para cada requisito.

Dado que las stakeholders clasificaron los requisitos inicialmente, la segunda clasificación basada en el impacto arquitectura tiene el efecto de ordenar parcialmente los requisitos en un grupos. Si utiliza simples rankings alta / media / baja, los grupos serían:

(H,H) (H,M) (H,L) (M,H) (M,M) (M,L) (L,H) (L,M) (L,L)

-->

Paso 4: Elige un concepto de diseño que satisfaga los drivers arquitecturales

¿Que se hace en el paso 4?

En el paso 4, debe elegir los tipos principales de elementos que aparecerán en la arquitectura y los tipos de relaciones entre ellos. Restricciones de diseño y los atributos de calidad (que son los aspirantes a drivers de arquitectura) se utilizan para determinar los tipos de elementos, relaciones y sus interacciones.

Como arquitecto, debe seguir estos seis sub-pasos:

1. Identificar los problemas de diseño que se asocian con los drivers arquitectónicos candidatos. Por ejemplo, para un requisito de atributo de calidad en cuanto a disponibilidad, las preocupaciones principales de diseño podría ser la prevención de fallo, detección de fallos, y la recuperación de fallos [Bass 03].
2. Para cada problema de diseño, crear una lista de patrones alternativos que responden a la preocupación. Los patrones en la lista se derivan de:
   1. Conocimientos, habilidades y experiencia con la que los patrones.
   2. Táctica de arquitectura conocida para lograr los atributos de calidad [Bass 03] Si un driver arquitectónico candidato se refiere a más de un atributo de calidad, se pueden aplicar múltiples tácticas.
   3. Otras fuentes, como libros, documentos, material para conferencias, motores de búsqueda, productos comerciales, etc.

Para cada patrón en su lista, usted debe

• Identificar los parámetros discriminantes de cada modelo para ayudar a elegir entre los patrones y tácticas en la lista. Por ejemplo, en cualquier patrón de reinicio (por ejemplo, warm restart, cold restart), la cantidad de tiempo que le toma a un reinicio es un parámetro discriminante. Para los patrones usados ​​para lograr la modificabilidad (por ejemplo, layers), un parámetro discriminante es el número de dependencias que existen entre los elementos en el patrón.
• Estimar los valores de los parámetros discriminantes

 Si te interesa conocer los pasos 4, 5, 6, 7, 8 de ADD consulta  ADDv2.0 o enviame un correo!

Bridge **

Cuando se especifica un diseño usando Layers o Domain Object...

… debemos tener en cuenta que la implementación de los objetos puede variar independientemente de sus interfaces.

✦✦✦

Un objeto puede tener una de varias implementaciones diferentes. La diferencia entre estas implementaciones podría ser específico de la plataforma, o una decisión de ejecución. La utilización de la herencia para separar el interfaz y la implementación, sin embargo, puede exponer el cliente del objeto a las decisiones sobre su implementación.

La herencia es un acercamiento típico a la separación del interfaz y la implementación: una interfaz declara la funcionalidad visible del objeto, e implementa los métodos declarados en la interfaz. De ser accesado vía la clase concreta, no obstante, existe un acoplamiento que se convierte en un pasivo en la lucha para un diseño estable: el código de cliente ahora depende del tipo de aplicación subyacente. Si se accede constantemente a través de la interfaz, los usuarios de objeto no se verán afectados por los cambios en la clase de implementación subyacente, pero no están libres de todas las dependencias de la implementación: en el momento de la creación, el cliente debe tomar una decisión sobre el tipo subyacente, que puede estorbar y complicar el código de cliente.

Por lo tanto:

Dividir el objeto en dos partes: una abstracción handle que ofrece una interfaz y una jerarquía de impulsor separada que proporciona las distintas implementaciones para el cuerpo. 

NOTA

Tipo: Estructura

Desacopla una clase abstracta de su implementación para que puedan variar independientemente.

Reflection *

Cuando DOMAIN MODEL se transforma en una arquitectura de software técnica...

.. . a veces debe proporcionar un diseño que se prepara para la evolución y la integración de los cambios imprevistos.

✦✦✦

Apoyar la variación es la clave para arquitecturas sostenibles de aplicaciones de larga vida: con el tiempo, deben responder a las nuevas y cambiantes tecnologías, requisitos y plataformas. Sin embargo, es difícil predecir lo que puede variar en una aplicación y cuando debe responder a una petición de variación específica.

Para complicar las cosas, la necesidad de variación puede ocurrir en cualquier momento, específicamente, mientras la aplicación está en uso productivo. Las variaciones también pueden ser de cualquier escala, desde ajustes locales de un algoritmo para modificaciones fundamentales de la infraestructura de distribución. Sin embargo, mientras que la variación de la aplicación debe ser posible en el momento apropiado, la complejidad asociada con las variaciones particulares deben ser ocultados de mantenedores, y debe haber un mecanismo uniforme para soportar diferentes tipos de variación.

Por lo tanto:

Objetivar la información acerca de las propiedades y aspectos variantes de la estructura de la aplicación, el comportamiento y estado en un conjunto de metaobjects.

NOTA

Tipo: Arquitectónico

Proporciona un medio para cambiar dinámicamente la estructura y el comportamiento de un software.

Microkernel **

Cuando se realiza una transformación de DOMAIN MODEL (182) en una arquitectura de software técnica....

…. Debemos diseñar para soportar la escalabilidad y adaptabilidad en diferentes escenarios de desarrollo...

✦✦✦

Algunas aplicaciones existen en múltiples versiones. Cada versión ofrece diferente conjunto diferente de funcionalidad a los usuarios, o se diferencia de otras versiones en aspectos específicos, tales como su interfaz de usuario. A pesar de sus diferencias, sin embargo, todas las versiones de la aplicación debe estar basado en una arquitectura común y el núcleo funcional.

El objetivo es evitar la deriva de la arquitectura entre las versiones de la aplicación y reducir al mínimo esfuerzo de desarrollo y mantenimiento de la funcionalidad compartida. Además, actualizar una versión de la aplicación a otra mediante la adición y eliminación de características, o mediante el cambio de su aplicación, no debería requerir más que modificaciones mínimas partes del sistema. De manera similar, debe ser fácil proporcionar una versión de la aplicación particular, con diferentes interfaces de usuario, y también para ejecutar la versión en distintas plataformas, permitiendo a los clientes la utilización más adecuadamente dentro de sus entornos específicos.

Componer diferentes versiones de un aplicación extendiendo un core común vía plug and play con un mínimo de cambio en la infraestructura.

Un microkernel implementa la funcionalidad compartida por todas las versiones de las aplicaciones y proporciona la infraestructura para la integración de la funcionalidad específica de la versión. Servidores internos autónomos implementan la versión de la funcionalidad específica, y los servidores externos de las interfaces específicas de la versión de usuario o APIs. Configurar una versión de la aplicación específica mediante la conexión de los servidores internos correspondientes con el microkernel, y la adecuada servidores externos para acceder a su funcionalidad. En consecuencia, todas las versiones de la aplicación comparten un núcleo común funcional y la infraestructura, pero proporcionar un conjunto de funciones look-and-feel.

✦✦✦

Una arquitectura MICROKERNEL asegura que cada versión de la aplicación, pueden adaptarse para su propósito. Los usuarios o sistemas cliente sólo obtiene la funcionalidad y el look-and-feel que requieren, pero no tienen que incurrir en el costo de todo lo que no necesita. En general, la evolución de una versión particular hacia las funciones nuevas o diferentes "sólo" requiere reconfigurarla con las correspondientes servidores internos y externos: el propio microkernel no se ve afectado por dichas actualizaciones.

Los servidores internos y externos y otras versiones de la aplicación son igualmente afectados. Además, una arquitectura micronúcleo minimiza los esfuerzos de desarrollo y el mantenimiento de todos los miembros de la familia de aplicación: cada servicio, la interfaz de usuario, o API se aplica sólo una vez.

La estructura interna de la microkernel se basa típicamente en capas (185). Los resúmenes capa inferior de la plataforma del sistema subyacente, apoyando así la portabilidad de todos los niveles superiores. La segunda capa implementa la funcionalidad de la infraestructura, tales como la gestión de los recursos, en la que el microkernel depende. La capa superior aloja la funcionalidad de dominio que es compartida por todas las versiones de la aplicación. La capa superior incluye los mecanismos para la configuración de servidores internos con el micronúcleo, así como para el encaminamiento de las peticiones de los servidores externos a su destinatario.

Cada función específica y autónoma y responsabilidad dentro de la microkernel puede ser realizado como un objeto de dominio (208), que apoya su implementación independiente y evolución. La funcionalidad de enrutamiento del microkernel se implementa a menudo como un mediador (410) que recibe las solicitudes a través de una interfaz uniforme y envía estas solicitudes a las funciones de dominio correspondientes en el microkernel o los servidores internos. Para reducir al mínimo el consumo de recursos, particularmente la memoria, la capa de enrutamiento puede utilizar un configurador de componentes (490) o un administrador de objetos (492) para cargar los servidores internos de la demanda, descargarlos después de su uso, y controlar su ciclo de vida. Este diseño también permite la actualización de una versión de la aplicación particular, con una funcionalidad nueva, distinta, o modificados de forma dinámica en tiempo de ejecución.

NOTA

Tipo: Arquitectónico

Dentro de un software, separa un núcleo funcional de la funcionalidad añadida.

Presentation-Abstraction-Control

Al transformar un modelo de dominio (182) en una arquitectura de software técnica. . .

. . . hay que considerar que en ocasiones diferentes responsabilidades funcionales de una aplicación puede requerir diferentes paradigmas de interfaz de usuario.

✦✦✦

Una interfaz hombre-máquina permite a los usuarios interactuar con una aplicación a través de un 'paradigma', como formularios o menús y cuadros de diálogo. Sin embargo, algunas aplicaciones están mejor operado a través de un paradigma de interfaz distinta para cada tipo de funcionalidad que se ofrecen.

Por ejemplo, en un sistema de control del robot, la funcionalidad para la definición de una misión requiere una interfaz de usuario diferente de la funcionalidad de control de un robot móvil durante una misión. Sin embargo, debemos asegurarnos de que todas las funciones y sus interfaces de usuario forman un sistema coherente. Además, los cambios en cualquier interfaz de usuario no afecta a la aplicación de su funcionalidad correspondiente, ni la de las demás funciones y sus interfaces de usuario asociados. Del mismo modo, los cambios en las implementaciones de una función distinta no debe afectar a las interfaces de usuario y las implementaciones de otras funciones.

Por lo tanto:

La estructura de la aplicación interactúa como una jerarquía de agentes desconectados: un agente de nivel superior, varios agentes de nivel intermedio, y muchos agentes de nivel inferior. Cada agente es responsable de una funcionalidad específica de la aplicación y proporciona una interfaz de usuario especial para ello.

Los agentes de nivel inferior implementan de forma autónoma la funcionalidad con la que los usuarios pueden interactuar, por ejemplo la administración, manejo de errores, y la manipulación de datos. En el nivel medio se localizan los coordinar que son múltiples agentes relacionados con los agentes de nivel inferior, por ejemplo, todos los puntos de vista que visualizan un determinado tipo de datos. El agente de alto nivel proporciona la funcionalidad básica que es compartido por todos los agentes, como el acceso a una base de datos.

Dividir cada agente en tres partes. Una parte de la presentación define el agente de la interfaz de usuario. Una parte de la abstracción proporciona un agente específico del dominio funcionalidad. Una parte de control conecta la presentación con la abstracción y permite al agente comunicarse con otro agentes. La conexión de los agentes en la jerarquía se realiza a través de sus controles.

Dividir cada agente en tres partes. A parte de la presentación se definen los usuarios interactúan con un agente a través de su presentación. Todas las peticiones de usuario a la funcionalidad respectiva en su abstracción están mediados por el control del agente. Si una acción del usuario requiere el acceso o la coordinación de otros agentes, mediar esta solicitud a los mandos de estos agentes, ya sea hacia arriba o hacia abajo en la jerarquía, y de allí a sus abstracciones.

Los usuarios interactúan con un agente a través de su presentación. Todas las peticiones de usuario a la funcionalidad respectiva en su abstracción se realizan mediante el agente del control. Si una acción del usuario requiere el acceso o la coordinación de otros agentes, mediar esta solicitud a los controles de estos agentes, ya sea hacia arriba o hacia abajo en la jerarquía, y de allí a sus abstracciones.

✦✦✦

Una arquitectura PRESENTATION-ABSTRACTION-CONTROL ayuda a conectar múltiples subsistemas autónomos o aplicaciones completas, incluso con modelos especializados de interacción hombre-máquina a un sistema coherente (distribuido). La desventaja es su complejidad: varias interfaces de usuario debe ser proporcionada, y las acciones promovidas por una interfaz de usuario específico debe ser coordinada cuidadosamente y de forma explícita si el flujo de control se extiende por varios subsistemas y las reacciones de las causas o ver los cambios en su interfaz de usuario asociados. En consecuencia, una arquitectura PRESENTATION-ABSTRACTION-CONTROL sólo es rentable si un sistema de software no puede ser aplicado por un paradigma de interfaz de usuario única.

Para especificar una PRESENTATION-ABSTRACTION-CONTROL (PAC), la arquitectura, identificar todas las responsabilidades independientes que la aplicación debe ofrecer a sus usuarios. Cada responsabilidad se encapsula dentro del nivel bajo del agente. Si varios agentes de la funcionalidad social o necesidad de coordinación, factor cabo esta funcionalidad (coordinación) en un agente de nivel intermedio. No puede haber múltiples niveles de agentes de nivel intermedio dentro de una arquitectura PAC. Funcionalidad compartida por todos los agentes es proporcionado por el agente de nivel superior. Tal disociación soporta la modificación independiente de los agentes sin afectar a otros agentes, y permite a cada agente proporcionar su propia interfaz de usuario. Proporcionar a todos los agentes una arquitectura modelo-vista-controlador (188): la abstracción correspondiente con el modelo y su división en objetos de dominio (208), y la presentación de las vistas y controladores. Cambios en la interfaz del agente por lo tanto afectará a su realización.

El desacoplar la abstracción de un agente de su presentación a través de un componente de control que es un MEDIATOR (410) con una doble responsabilidad. En primer lugar, debe encaminar todas las solicitudes de los usuarios de la presentación del agente para la funcionalidad adecuada en su abstracción. También debe encaminar todos notificaciones de propagación del cambio de la abstracción a las opiniones de la presentación. En segundo lugar, el control debe coordinar la cooperación entre los agentes. Si una solicitud de usuario recibida por un agente particular no puede ser manejado por el agente sólo, las rutas de control de la solicitud a los controles apropiados de agentes de alto o de nivel inferior, junto con sus datos de entrada asociados. Los resultados se devuelven en la misma forma, pero a la inversa. De manera similar, el control de un agente puede recibir solicitudes y datos de los controles de otros agentes. Las solicitudes para ser enrutados se pueden encapsular dentro de objetos COMMAND (412), y los datos que contiene DATA TRANSFER OBJECTS (418). Los controles son la clave para un acoplamiento débil entre los agentes: si cambia de un agente de extracción, los efectos sobre otros agentes se limitan a sus controles.

NOTA

Tipo: Arquitectónico

Descompone un software interactivo en una jerarquía de agentes que colaboran. Cada agente desempeña alguna función de presentación por pantalla, funcionalidad básica (abstracción) o comunicación entre agentes (control).

Model-View-Controller **

Al transformar un modelo de dominio (182) en una arquitectura de software técnica, o especificando un agente en una configuración PRESENTATION-ABSTRACTION- CONTROL (191). . .

. . . debemos tener en cuenta que la interfaz de usuario de una aplicación cambia con más frecuencia que su funcionalidad del dominio.

✦✦✦

Las interfaces de usuario son propensas a solicitudes de cambio: algunos deben soportar múltiples look-and-feel skins, otras deben abordar las preferencias específicas del cliente. Sin embargo, los cambios en una interfaz de usuario no debe afectar a la funcionalidad de una aplicación subyacente, que generalmente es independiente de su presentación, y también cambia con menos frecuencia.

Los cambios en una interfaz de usuario debe ser fácil y local a la parte de interfaz modificada. Una interfaz de usuario modificable sin embargo no debe degradar la calidad de la aplicación del servicio: en cualquier momento se debe mostrar el estado actual de la computación, y responder a los cambios de estado de inmediato. Para complicar aún más las cosas, en un sistema que admite múltiples skins look-and-feel, cada skin puede cambiar a un ritmo diferente, que requiere desacoplamiento adicional de diferentes partes de la interfaz de usuario.

Divide la aplicación interactiva en tres partes disociadas: procesamiento, entrada y salida. Garantiza la coherencia de las tres partes, con la ayuda de un mecanismo de propagación de cambios.

Encapsula el núcleo funcional de la aplicación dentro de un modelo cuya aplicación es independiente de la interfaz de usuario específica look-and-feel and mechanics. Para cada aspecto del modelo que se presentará en la interfaz de usuario de la aplicación, introduce uno o más vistas autónomas. Asociar cada vista con un conjunto de controladores independientes que reciben la entrada del usuario y traducir esta entrada en las solicitudes de ya sea el modelo o la vista asociada. Permite a los usuarios interactuar con la aplicación únicamente a través de los controladores.

NOTA:

Tipo: Arquitectonico

Descompone un software interactivo en tres componentes: el modelo que tiene la funcionalidad y los datos, la vista que presenta la información en la pantalla, y el controlador que trata las entradas de información.

LAYER

Layers **

Cuando transformas un modelo de dominio (182) en una técnica de arquitectura de software o se realiza un BROKER (237), DATABASE ACCESS LAYER (438), MICROKERNEL (194), o HALF-SYNC/HALF-ASYNC (359) . . .

.. . hay que apoyar el desarrollo independiente y la evolución de diferentes partes del sistema.

✦✦✦

Independientemente de las interacciones y de acoplamiento entre las diferentes partes de un sistema de software, hay una necesidad de desarrollar y evolucionar de manera independiente, por ejemplo debido al tamaño del sistema y los requisitos de tiempo de salida al mercado. Sin embargo, sin una separación clara y razonada de las preocupaciones de la arquitectura software del sistema, las interacciones entre las partes no pueden contar con el apoyo adecuado, ni tampoco su desarrollo independiente.

El desafío es encontrar un equilibrio entre un diseño que divide la aplicación en partes significativas y tangibles que se pueden desarrollar y desplegar de forma independiente, pero que no se pierda en una gran variedad de detalles para que la visión de la arquitectura y las cuestiones operativas, tales como el rendimiento y la escalabilidad se traten adecuadamente. Un grupo especial, el diseño monolítico no es una opción viable para resolver el problema. Si bien permite la calidad de los aspectos de servicio a abordar más directamente, es probable que resulte en una estructura espagueti que degrada las cualidades de desarrollo tales como comprensibilidad y facilidad de mantenimiento.

Definir una o más capas para el software en desarrollo, con cada capa que tiene una responsabilidad diferente y específico.

Asignar la funcionalidad del sistema a las respectivas capas, y dejar que la funcionalidad de una capa particular sólo se base en la funcionalidad ofrecida por las mismas capas o inferior. Proporcionar todas las capas con una interfaz que esté separada de su aplicación, y dentro de cada programa de capa usar estas interfaces sólo cuando se accede a otras capas.

✦✦✦

Una arquitectura en CAPAS define una partición horizontal de la funcionalidad de un software de acuerdo con subsistemas, de manera que cada grupo de funcionalidades está claramente encapsulado y puede evolucionar independientemente. Los criterios específicos de partición se puede definir a lo largo de varias dimensiones, tales como la abstracción, granularidad, distancia hardware, y la tasa de cambio.

Por ejemplo, una disposición en capas, con las siguientes particiones de una arquitectura: presentación, lógica de aplicación, y los datos persistentes que sigue la dimensión abstracción. Una capa que introduce los objetos de negocio cuyas entidades son utilizados por una capa de procesos de negocios sigue dimensión de granularidad, mientras que uno que sugiere un sistema operativo, una capa de protocolo de comunicación, y una capa con la funcionalidad de la aplicación sigue la dimensión distancia hardware.

Un desafío clave es encontrar el "correcto" número de capas. Muy pocas capas pueden no separar suficientemente los diferentes temas en el sistema que puede evolucionar de forma independiente. Por el contrario, demasiadas capas pueden fragmentar una arquitectura de software en pedazos sin una clara visión y alcance, lo que hace que sea difícil para ellos evolucionan en absoluto.

Normalmente, cada responsabilidad autónoma y coherente dentro de una capa se realiza como un objeto de dominio por separado, para dividir aún más la capa en partes tangibles que pueden ser desarrolladas y evolucionaron de forma independiente.

NOTA

 

Tipo: Arquitectónico

Estructura una aplicación en diferentes en grupos - de diferentes niveles - subtareas.

DOMAIN MODEL

Cuando se empieza a construir una aplicación (distribuida). . . necesitamos una estructura inicial para el software que se está desarrollando.

✦✦✦

Los requisitos y las restricciones informan la funcionalidad, calidad del servicio, y aspectos de desarrollo del sistema software, pero no sugieren la estructura concreta que dirija el desarrollo. Sin una visión precisa y razonada en el alcance de un sistema y su dominio de aplicación, no obstante, su realización se puede convertir en una gran bola de barro que será difícil de entender y transmitir a los clientes, y una pobre base arquitectónica sobre la que se pueda construir.  

Una lista de requerimientos muestra el dominio del problema de una aplicación, pero no es el dominio de la solución. Sin embargo, los requerimientos de un sistema debe ser dirigidas por las entidades concretas de software. Si las entidades y sus interacciones están relacionadas con la principal aplicación del negocio, sin embargo, va a ser difícil de comprender y comunicar lo que el sistema realmente hace. Del mismo modo, será difícil cumplir con la calidad de los requerimientos de servicio, ya que no se pueden asignar claramente a los elementos de software cuando sean pertinentes. Sin una visión clara del dominio de aplicación de un sistema, por lo tanto, los arquitectos de software no puede determinar si sus diseños son correctos, completos, coherentes y lo suficientemente acotado para servir como la base para el desarrollo.

Crear un modelo que define las responsabilidades y alcances de un sistema de negocio y sus variaciones: los elementos del modelo son abstracciones significativas en el dominio de aplicación, mientras que sus roles e interacciones reflejan el flujo de trabajo del dominio.

El modelo de dominio es la base para la arquitectura software de un sistema, que se convertirá en una expresión del modelo a medida que evoluciona.

✦✦✦

Un modelo de dominio constituye el paso inicial en la transformación de los requerimientos en una arquitectura software sostenible y la implementación. La definición de un modelo preciso para la estructura y el flujo de trabajo de un dominio de aplicación, incluyendo sus variantes, ayuda a trazar los requisitos para las entidades de software concretos y comprobar si los requisitos están completos y consistente. Los requisitos que no puede ser identificado, los requisitos confusos, y los requisitos innecesarios son eliminados. Como resultado, las responsabilidades y los límites de la arquitectura de un sistema están en el ámbito correcto. Un modelo de dominio bien formado también hace que sea más fácil cumplir con la calidad de un sistema de requisitos de servicio, debido a que pueden ser asignados a los elementos específicos y flujos de trabajo a que se aplican en el modelo. Un modelo de dominio también fomenta la comunicación entre los profesionales de software, expertos de dominio y clientes, debido a que sus elementos se basan en la terminología utilizada en el dominio de aplicación.

Una vez que el modelo de dominio ha madurado hasta el punto en el que retrata adecuadamente las responsabilidades funcionales de una aplicación, así como sus variaciones, el siguiente paso es transformar el modelo en una arquitectura concreta que se expresa y que soporta esta funcionalidad, que aborda los requisitos de calidad del servicio, tales como el rendimiento, la escalabilidad, disponibilidad, adaptabilidad y capacidad de ampliación. Varios patrones ayudan a organizar y conectar los elementos de un dominio del modelo para apoyar a estilos específicos de cálculo. Por ejemplo:

PIPES AND FILTERS (200) es adecuado para aplicaciones que procesan flujos de datos, SHARED REPOSITORY (202) ayuda a organizar aplicaciones data-driven y BLACKBOARD (205) es adecuado para aplicaciones que trabajan con datos incompletos, o para algoritmos de soluciones no determinísticas...

ARQUITECTURA DE SOFTWARE

El concepto de Arquitectura de Software es una extensión de la Ingeniería de Software para la producción y evaluación de software de alta calidad [18]; de acuerdo al Software Engineering Institute (SEI), la Arquitectura de Software se refiere a “las estructuras de un sistema, compuestas de elementos con propiedades visibles de forma externa y las relaciones que existen entre ellos”; que satisface el subconjunto de requerimientos, tales como: atributos de calidad, requerimientos funcionales primarios y restricciones, denominados drivers de la arquitectura. Ahora bien, el desarrollo de la arquitectura software se divide en las etapas de: Requerimientos, Diseño, Documentación y Evaluación. Será durante la etapa de diseño de la arquitectura de software que se tomen decisiones de diseño que definirán y guiarán el desarrollo de un sistema de software; para después crear un conjunto de estructuras que satisfagan los drivers arquitecturales. Por ende durante el desarrollo de un sistema software existirán una gran cantidad de decisiones que se entrelazan, de tal manera, que un cambio en las decisiones pueden afectar significativamente a otros aspectos del diseño, por lo que un arquitecto de software debe ser capaz de analizar y evaluar los efectos de las decisiones de diseño. Así, este proceso ha sido tradicionalmente considerado como un trabajo altamente creativo, que requiere una experiencia especial, juicio y  talento [13].  Las decisiones de diseño arquitectónico subyacen en el software arquitectura y se define como el conjunto de adiciones, sustracciones y modificaciones en la arquitectura software, así como también incluye, los fundamentos, las reglas y limitaciones de diseño, y requerimientos adicionales [14]. Como tal, las arquitecturas de software puede ser visto como el resultado de un conjunto de decisiones de diseño arquitectónico [10]. La práctica indica que la toma de decisiones es realizada a través del conocimiento arquitectural (Architectural Knowledge, AK) que engloba los conceptos de decisiones de diseño, justificación, alternativas y diseño arquitectural. Este conocimiento es expresado en términos de estilos arquitectónicos, patrones, mejores prácticas, arquitecturas de referencia, tácticas, frameworks, entre otros [13].

DESARROLLO DE UNA METODOLOGÍA PARA EL DISEÑO DE SISTEMAS EMPOTRADOS BAJO EL PARADIGMA DE MEJORA DEL PROCESO SOFTWARE

Desde el 2002, los Sistemas Empotrados (SE) están cada vez más presentes en la sociedad [Solingen, 2002], abarcando diversas áreas, como el transporte, la electrónica de consumo, la distribución de energía, la medicina, el control industrial, las estaciones de red, entre otras [Noergaard, 2005]. De acuerdo a [Graaf, Lormans & Toetenel, 2002] y [Noergaard, 2005], el campo de los SE es cada vez más amplio, variado y complejo; por lo que las inversiones en la industria de las tecnologías de Ingeniería de Software Empotrado para el desarrollo de este tipo de sistemas tenderán a aumentar considerablemente.

Regularmente es difícil describir a los SE ya que se encuentran en constante evolución por los avances tecnológicos, sin embargo, las descripciones coinciden en que se trata de “una mezcla de hardware y software dedicado a una aplicación especifica” [Graaf, Lormans & Toetenel, 2002]; que además “implica un desarrollo paralelo de software y de hardware” [Berger, 2002]. Su diseño se basa en los modelos clásicos de la Ingeniería de Sistemas (Bing-bang model, cascada, espiral, Code-and-fix model, etc.) y en dos elementos conceptuales: la arquitectura de hardware y la arquitectura de software. Lo anterior origina que el desarrollo de los SE sea interdisciplinario [Pearson, Giuma & Harris, 2008], involucrando así a ingenieros y técnicos especializados tanto en el diseño de hardware como en el diseño de software.

Las necesidades de las sociedades actuales, han ocasionado que los SE incrementen su complejidad y que por ende se destine mayor importancia al tiempo de desarrollo de los mismos. Ahora bien, durante el proceso de desarrollo es necesario considerar que los requisitos de los SE son únicos e impactan directamente sobre los métodos y herramientas utilizadas para su desarrollo [Ibrahim, Zhao & Kinghorn, 2006], además de la importancia que el software tiene en la funcionalidad del sistema [Liggesmeyer & Trapp, 2009].

El cambio constante en los requisitos y la complejidad variante provocaron que las metodologías de diseño actuales ya no fueran suficientes [Sangiovanni & Martin, 2001], pues los sistemas modernos exigían nuevos enfoques para su especificación, diseño y desarrollo. Debido a esto, las organizaciones que participan en el diseño, desarrollo y logística de los SE deben cambiar fundamentalmente la manera en que los desarrollan, gestionando adecuadamente la complejidad operativa y ambiental [Srinivasan, Dobrin & Lundqvist, 2009].

Con el objetivo de aumentar la calidad del producto, reducir el tiempo de comercialización, y reducir los costos de desarrollo, en [Liggesmeyer & Trapp, 2009] se recomienda que las metodologías empleadas para el desarrollo de SE deben integrar correctamente los paradigmas esenciales del diseño de software y hardware, evitando así los problemas que actualmente se presentan durante la etapa de integración [Srinivasan, Dobrin & Lundqvist, 2009].

De acuerdo a [Srinivasan, Dobrin & Lundqvist, 2009], las metodologías utilizadas actualmente en la industria de los SE no son específicas del dominio de éstos y no se encuentran estandarizadas. Es decir, estos sistemas carecen de una metodología eficaz por lo que en la industria, la sensación general es que la práctica actual de desarrollo de software y SE es insatisfactoria.

En este sentido, Graaf, Lormans y Toetenel estudiaron a siete empresas europeas en [Graaf, Lormans & Toetenel, 2003] para determinar el estado de la práctica de la Ingeniería de Software Empotrado. Una de las conclusiones clave del estudio fue que “los sistemas de decisión de ingeniería son en gran parte impulsados por las limitaciones de hardware, que a su vez, impactan los esfuerzos de software en dos etapas del ciclo de vida cuando se desarrollan los requisitos de software a nivel componente”. A pesar de que el estudio no indica de forma concisa cuáles son estas dos etapas del ciclo de vida que son afectadas, los datos ofrecidos en el estudio permiten identificar que se refieren a la Especificación de Requisitos y Diseño. Sin embargo, es claro que desde el 2000 han existido propuestas que intentan agregar formalidad al proceso de desarrollo. Algunas de estas propuestas han proporcionado metodologías para el desarrollo de SE, tales como: PROFES [Birk et al., 1998], BOOTSTRAP [Kuvaja & Bicego, 1994], REMES [Seceleanu, Vulgarakis & Petterson, 2009], PECOS [Genßler et. al., 2002], POLIS [Kang, Kwon & Lee, 2005], Métodos Ágiles [Greene, 2004], entre otros.

Desafortunadamente, las metodologías disponibles para el desarrollo de software (adaptadas al desarrollo de SE) no consideran las necesidades específicas de este tipo de sistemas [Srinivasan, Dobrin & Lundqvist, 2009].

Por todo lo anteriormente expuesto, resulta evidente que el problema actual de los SE no es la falta de normas o modelos para su desarrollo, sino la falta de una estrategia eficaz para aplicarlas con éxito. Si a esto le sumamos la extensa variedad de herramientas y métodos para desarrollar los SE, el problema se dificulta todavía más. Por lo que resulta necesario establecer una metodología de desarrollo propia para los SE; que considere la estrecha relación que existe entre el software y el hardware; que proporcione una fácil integración en el menor tiempo posible, y que refleje la calidad adecuada.

Tesis de M.C., disponible en:   jupiter.utm.mx/~tesis_dig/11487.pdf