stringtranslate.com

Ingeniería de dominio

La ingeniería de dominios es el proceso completo de reutilización del conocimiento del dominio en la producción de nuevos sistemas de software . Es un concepto clave en la reutilización sistemática de software y la ingeniería de líneas de productos . Una idea clave en la reutilización sistemática de software es el dominio . La mayoría de las organizaciones trabajan solo en unos pocos dominios. Construyen repetidamente sistemas similares dentro de un dominio determinado con variaciones para satisfacer diferentes necesidades de los clientes. En lugar de construir cada nueva variante del sistema desde cero, se pueden lograr ahorros significativos reutilizando partes de sistemas anteriores en el dominio para construir otros nuevos.

El proceso de identificar dominios, delimitarlos y descubrir puntos en común y variabilidades entre los sistemas del dominio se denomina análisis de dominio . Esta información se captura en modelos que se utilizan en la fase de implementación del dominio para crear artefactos como componentes reutilizables, un lenguaje específico del dominio o generadores de aplicaciones que se pueden utilizar para crear nuevos sistemas en el dominio.

En la ingeniería de línea de productos, tal como se define en la norma ISO26550:2015, la ingeniería de dominio se complementa con la ingeniería de aplicación , que se ocupa del ciclo de vida de los productos individuales derivados de la línea de productos. [1]

Objetivo

La ingeniería de dominio está diseñada para mejorar la calidad de los productos de software desarrollados mediante la reutilización de artefactos de software. [2] La ingeniería de dominio muestra que la mayoría de los sistemas de software desarrollados no son sistemas nuevos sino más bien variantes de otros sistemas dentro del mismo campo. [3] Como resultado, mediante el uso de la ingeniería de dominio, las empresas pueden maximizar las ganancias y reducir el tiempo de comercialización al utilizar los conceptos e implementaciones de sistemas de software anteriores y aplicarlos al sistema de destino. [2] [4] La reducción de costos es evidente incluso durante la fase de implementación. Un estudio mostró que el uso de lenguajes específicos del dominio permitió reducir el tamaño del código, tanto en número de métodos como en número de símbolos , en más del 50%, y el número total de líneas de código en casi un 75%. [5]

La ingeniería de dominio se centra en capturar el conocimiento obtenido durante el proceso de ingeniería de software . Al desarrollar artefactos reutilizables, los componentes se pueden reutilizar en nuevos sistemas de software a bajo costo y con alta calidad. [6] Debido a que esto se aplica a todas las fases del ciclo de desarrollo de software , la ingeniería de dominio también se centra en las tres fases principales: análisis, diseño e implementación, en paralelo con la ingeniería de aplicaciones. [7] Esto produce no solo un conjunto de componentes de implementación de software relevantes para el dominio, sino también requisitos y diseños reutilizables y configurables. [8]

Dado el crecimiento de los datos en la Web y el crecimiento de la Internet de las cosas , un enfoque de ingeniería de dominio también se está volviendo relevante para otras disciplinas. [9] La aparición de cadenas profundas de servicios web resalta que el concepto de servicio es relativo. Los servicios web desarrollados y operados por una organización pueden ser utilizados como parte de una plataforma por otra organización. Como los servicios pueden usarse en diferentes contextos y, por lo tanto, requieren diferentes configuraciones, el diseño de familias de servicios puede beneficiarse de un enfoque de ingeniería de dominio.

Fases

Ingeniería de dominio en comparación con ingeniería de aplicaciones. Los resultados de cada fase de la ingeniería de dominio se incorporan a las fases posteriores de la ingeniería de dominio, así como a las fases correspondientes de la ingeniería de aplicaciones.

La ingeniería de dominio, al igual que la ingeniería de aplicaciones, consta de tres fases principales: análisis, diseño e implementación. Sin embargo, mientras que la ingeniería de software se centra en un solo sistema, la ingeniería de dominio se centra en una familia de sistemas. [7] Un buen modelo de dominio sirve como referencia para resolver ambigüedades más adelante en el proceso, como repositorio de conocimientos sobre las características y la definición del dominio, y como especificación para los desarrolladores de productos que forman parte del dominio. [10]

Análisis de dominio

El análisis de dominio se utiliza para definir el dominio, recopilar información sobre el dominio y producir un modelo de dominio . [11] A través del uso de modelos de características (inicialmente concebidos como parte del método de análisis de dominio orientado a características ), el análisis de dominio tiene como objetivo identificar los puntos comunes en un dominio y los puntos variables en el dominio. [12] A través del uso del análisis de dominio, es posible el desarrollo de requisitos y arquitecturas configurables , en lugar de configuraciones estáticas que se producirían mediante un enfoque de ingeniería de aplicaciones tradicional. [13]

El análisis de dominio es significativamente diferente de la ingeniería de requisitos y, como tal, los enfoques tradicionales para derivar requisitos son ineficaces para el desarrollo de requisitos configurables como los que estarían presentes en un modelo de dominio. Para aplicar eficazmente la ingeniería de dominio, la reutilización debe considerarse en las fases anteriores del ciclo de vida del desarrollo de software . A través del uso de la selección de características de los modelos de características desarrollados, la consideración de la reutilización de la tecnología se realiza muy temprano y se puede aplicar adecuadamente durante todo el proceso de desarrollo. [14]

El análisis de dominio se deriva principalmente de artefactos producidos a partir de experiencias pasadas en el dominio. [11] Los sistemas existentes, sus artefactos (como documentos de diseño , documentos de requisitos y manuales de usuario ), estándares y clientes son todas fuentes potenciales de entrada para el análisis de dominio. [11] [15] Sin embargo, a diferencia de la ingeniería de requisitos, el análisis de dominio no consiste únicamente en la recopilación y formalización de información; también existe un componente creativo. Durante el proceso de análisis de dominio, los ingenieros apuntan a extender el conocimiento del dominio más allá de lo que ya se conoce y categorizar el dominio en similitudes y diferencias para mejorar la reconfigurabilidad. [11]

El análisis de dominio produce principalmente un modelo de dominio , que representa las propiedades comunes y variables de los sistemas dentro del dominio. [11] El modelo de dominio ayuda a la creación de arquitecturas y componentes de una manera configurable al actuar como una base sobre la cual diseñar estos componentes. [16] Un modelo de dominio eficaz no solo incluye las características variables y consistentes en un dominio, sino que también define el vocabulario utilizado en el dominio y define conceptos, ideas y fenómenos dentro del sistema. [11] [17] Los modelos de características descomponen los conceptos en sus características requeridas y opcionales para producir un conjunto completamente formalizado de requisitos configurables. [18]

Diseño de dominio

El diseño de dominio toma el modelo de dominio producido durante la fase de análisis de dominio y apunta a producir una arquitectura genérica a la que todos los sistemas dentro del dominio puedan ajustarse. [19] De la misma manera que la ingeniería de aplicaciones utiliza los requisitos funcionales y no funcionales para producir un diseño, la fase de diseño de dominio de la ingeniería de dominio toma los requisitos configurables desarrollados durante la fase de análisis de dominio y produce una solución configurable y estandarizada para la familia de sistemas. El diseño de dominio apunta a producir patrones arquitectónicos que resuelvan un problema común en todos los sistemas dentro del dominio, a pesar de las diferentes configuraciones de requisitos. [20] Además del desarrollo de patrones durante el diseño de dominio, los ingenieros también deben tener cuidado de identificar el alcance del patrón y el nivel en el que el contexto es relevante para el patrón. La limitación del contexto es crucial: demasiado contexto da como resultado que el patrón no sea aplicable a muchos sistemas, y muy poco contexto da como resultado que el patrón no sea lo suficientemente potente para ser útil. [21] Un patrón útil debe ser a la vez recurrente y de alta calidad. [22]

El objetivo del diseño de dominios es satisfacer tantos requisitos del dominio como sea posible, manteniendo al mismo tiempo la flexibilidad que ofrece el modelo de características desarrollado. La arquitectura debe ser lo suficientemente flexible para satisfacer todos los sistemas dentro del dominio y lo suficientemente rígida para proporcionar un marco sólido sobre el cual basar la solución. [23]

Implementación de dominio

La implementación del dominio es la creación de un proceso y herramientas para generar eficientemente un programa personalizado en el dominio.

Crítica

La ingeniería de dominio ha sido criticada por centrarse demasiado en la "ingeniería para la reutilización" o la "ingeniería con reutilización" de características genéricas de software en lugar de concentrarse en la "ingeniería para el uso", de modo que la visión del mundo, el lenguaje o el contexto de un individuo se integren en el diseño del software. [24]

Véase también

Referencias

  1. ^ ISO 26550:2015 – Ingeniería de software y sistemas. Modelo de referencia para la ingeniería y gestión de líneas de productos.
  2. ^ Véase Frakes y Kang 2007, pág. 2
  3. ^ Frakes y Kang 2007, pág. 1
  4. ^ Czarnecki y Eisenecker 2000, pág. 19
  5. ^ Batory y otros, 2002, pág. 19
  6. ^ Czarnecki y Eisenecker 2000, pág. 20
  7. ^ de Czarnecki y Eisenecker 2000, pág. 21
  8. ^ Harsu 2002, pág. 8
  9. ^ Reinhartz-Berger y otros, 2013, pág. xii
  10. ^ Falbo, Guizzardi y Duarte 2002, p. 2
  11. ^ abcdef Czarnecki y Eisenecker 2000, pág. 23
  12. ^ Czarnecki y Eisenecker 2000, pág. 38
  13. ^ Kang y otros, 2004, pág. 7
  14. ^ Kang y otros, 2004, pág. 3
  15. ^ Kang y otros, 2004, pág. 4
  16. ^ Frakes y Kang 2007, pág. 3
  17. ^ Czarnecki y Eisenecker 2000, pág. 84
  18. ^ Czarnecki y Eisenecker 2000, pág. 86
  19. ^ Czarnecki y Eisenecker 2000, pág. 24
  20. ^ Czarnecki y Eisenecker 2000, pág. 25
  21. ^ Buschmann, Henney y Schmidt 2007, pág. 42
  22. ^ Buschmann, Henney y Schmidt 2007, pág. 31
  23. ^ Czarnecki y Eisenecker 2000, pág. 28
  24. ^ Mettler 2017, pág. 5

Fuentes