stringtranslate.com

Ver modelo

La matriz TEAF de visiones y perspectivas.

Un modelo de vista o marco de puntos de vista en ingeniería de sistemas , ingeniería de software e ingeniería empresarial es un marco que define un conjunto coherente de vistas que se utilizarán en la construcción de una arquitectura de sistemas , una arquitectura de software o una arquitectura empresarial . Una vista es una representación de todo el sistema desde la perspectiva de un conjunto relacionado de preocupaciones. [1] [2]

Desde principios de los años 1990 se han hecho varios esfuerzos para prescribir enfoques para describir y analizar arquitecturas de sistemas. Uno de los resultados de estos esfuerzos ha sido la definición de un conjunto de vistas (o puntos de vista). A veces se los denomina marcos de arquitectura o marcos de arquitectura empresarial , pero normalmente se los llama "modelos de vista".

Por lo general, una vista es un producto de trabajo que presenta datos de arquitectura específicos para un sistema determinado. Sin embargo, a veces se utiliza el mismo término para referirse a una definición de vista , que incluye el punto de vista particular y la guía correspondiente que define cada vista concreta. El término modelo de vista está relacionado con las definiciones de vista.

Descripción general

El propósito de las vistas y puntos de vista es permitir a los seres humanos comprender sistemas muy complejos , organizar los elementos del problema y la solución en torno a dominios de especialización y separar las preocupaciones . En la ingeniería de sistemas físicamente intensivos, los puntos de vista a menudo corresponden a capacidades y responsabilidades dentro de la organización de ingeniería. [3]

La mayoría de las especificaciones de sistemas complejos son tan extensas que ninguna persona puede comprender por completo todos los aspectos de las especificaciones. Además, todos tenemos diferentes intereses en un sistema determinado y diferentes razones para examinar las especificaciones del sistema . Un ejecutivo de negocios hará preguntas diferentes sobre la estructura de un sistema que un implementador de sistemas. Por lo tanto, el concepto de marco de puntos de vista es proporcionar puntos de vista separados sobre la especificación de un sistema complejo dado para facilitar la comunicación con las partes interesadas. Cada punto de vista satisface a una audiencia con interés en un conjunto particular de aspectos del sistema. Cada punto de vista puede utilizar un lenguaje de puntos de vista específico que optimice el vocabulario y la presentación para la audiencia de ese punto de vista. El modelado de puntos de vista se ha convertido en un enfoque eficaz para abordar la complejidad inherente de los grandes sistemas distribuidos.

Las prácticas de descripción de arquitectura, como se describe en la norma IEEE Std 1471-2000 , utilizan múltiples vistas para abordar varias áreas de interés, cada una de las cuales se centra en un aspecto específico del sistema. Entre los ejemplos de marcos de arquitectura que utilizan múltiples vistas se incluyen el modelo de vista "4+1" de Kruchten , el marco Zachman , TOGAF , DoDAF y RM-ODP .

Historia

En la década de 1970, comenzaron a aparecer métodos en ingeniería de software para modelar con múltiples vistas. En 1977, Douglas T. Ross y KE Schoman introdujeron los constructos contexto, punto de vista y punto de vista para organizar el proceso de modelado en la definición de requisitos de sistemas. [4] Según Ross y Schoman, un punto de vista "aclara qué aspectos se consideran relevantes para lograr... el propósito general [del modelo]" y determina ¿Cómo observamos [un tema que se está modelando]?

Como ejemplos de puntos de vista, el documento ofrece: puntos de vista técnicos, operativos y económicos. En 1992, Anthony Finkelstein y otros publicaron un documento muy importante sobre puntos de vista. [5] En ese trabajo: "Un punto de vista puede considerarse como una combinación de la idea de un "actor", "fuente de conocimiento", "rol" o "agente" en el proceso de desarrollo y la idea de una "visión" o "perspectiva" que mantiene un actor". Una idea importante en este documento fue distinguir "un estilo de representación , el esquema y la notación mediante los cuales el punto de vista expresa lo que puede ver" y "una especificación , las declaraciones expresadas en el estilo del punto de vista que describen dominios particulares". Trabajos posteriores, como IEEE 1471 , preservaron esta distinción utilizando dos términos separados: punto de vista y vista, respectivamente.

Desde principios de los años 1990 ha habido una serie de esfuerzos para codificar enfoques para describir y analizar arquitecturas de sistemas. Estos a menudo se denominan marcos de arquitectura o, a veces, conjuntos de puntos de vista . Muchos de estos han sido financiados por el Departamento de Defensa de los Estados Unidos , pero algunos han surgido de esfuerzos internacionales o nacionales en ISO o el IEEE . Entre estos, la Práctica recomendada del IEEE para la descripción arquitectónica de sistemas intensivos en software ( IEEE Std 1471-2000 ) estableció definiciones útiles de vista, punto de vista, parte interesada y preocupación y pautas para documentar una arquitectura de sistema mediante el uso de múltiples vistas aplicando puntos de vista para abordar las preocupaciones de las partes interesadas . [6] La ventaja de las múltiples vistas es que los requisitos ocultos y los desacuerdos de las partes interesadas se pueden descubrir más fácilmente. Sin embargo, los estudios muestran que en la práctica, la complejidad adicional de conciliar múltiples vistas puede socavar esta ventaja. [7]

IEEE 1471 (ahora ISO/IEC/IEEE 42010:2011 , Ingeniería de sistemas y software: descripción de la arquitectura ) prescribe los contenidos de las descripciones de la arquitectura y describe su creación y uso en una serie de escenarios, incluidos el diseño sin precedentes, el diseño evolutivo y la captura del diseño de sistemas existentes. En todos estos escenarios, el proceso general es el mismo: identificar a las partes interesadas , suscitar inquietudes, identificar un conjunto de puntos de vista que se utilizarán y luego aplicar estas especificaciones de puntos de vista para desarrollar el conjunto de puntos de vista relevantes para el sistema de interés. En lugar de definir un conjunto particular de puntos de vista, el estándar proporciona mecanismos y requisitos uniformes para que los arquitectos y las organizaciones definan sus propios puntos de vista. En 1996, se publicó el Modelo de referencia ISO para procesamiento distribuido abierto ( RM-ODP ) para proporcionar un marco útil para describir la arquitectura y el diseño de sistemas distribuidos a gran escala.

Ver temas del modelo

Vista

Una vista de un sistema es una representación del sistema desde la perspectiva de un punto de vista. Este punto de vista de un sistema implica una perspectiva que se centra en preocupaciones específicas relacionadas con el sistema, que suprime los detalles para proporcionar un modelo simplificado que solo tiene aquellos elementos relacionados con las preocupaciones del punto de vista. Por ejemplo, un punto de vista de seguridad se centra en las preocupaciones de seguridad y un modelo de punto de vista de seguridad contiene aquellos elementos que están relacionados con la seguridad desde un modelo más general de un sistema. [8]

Una vista permite al usuario examinar una parte de un área de interés particular. Por ejemplo, una Vista de información puede presentar todas las funciones, organizaciones, tecnología, etc. que utilizan una pieza particular de información, mientras que la Vista organizacional puede presentar todas las funciones, tecnología e información de interés para una organización en particular. En el marco de Zachman, las vistas comprenden un grupo de productos de trabajo cuyo desarrollo requiere una especialización analítica y técnica porque se centran en el “qué”, el “cómo”, el “quién”, el “dónde”, el “cuándo” o el “por qué” de la empresa. Por ejemplo, los productos de trabajo de la Vista funcional responden a la pregunta “¿cómo se lleva a cabo la misión?”. Son más fáciles de desarrollar por expertos en descomposición funcional utilizando el modelado de procesos y actividades. Muestran la empresa desde el punto de vista de las funciones. También pueden mostrar componentes organizacionales y de información, pero solo en la medida en que se relacionan con las funciones. [9]

Puntos de vista

En ingeniería de sistemas, un punto de vista es una división o restricción de las preocupaciones de un sistema. La adopción de un punto de vista es útil para que las cuestiones de esos aspectos se puedan abordar por separado. Una buena selección de puntos de vista también divide el diseño del sistema en áreas específicas de especialización. [3]

Los puntos de vista proporcionan las convenciones, reglas y lenguajes para construir, presentar y analizar vistas. En ISO/IEC 42010:2007 ( IEEE-Std-1471-2000 ), un punto de vista es una especificación para una vista individual. Una vista es una representación de un sistema completo desde la perspectiva de un punto de vista. Una vista puede constar de uno o más modelos arquitectónicos . [10] Cada uno de estos modelos arquitectónicos se desarrolla utilizando los métodos establecidos por su sistema arquitectónico asociado, así como para el sistema en su conjunto. [6]

Perspectivas de modelado

Las perspectivas de modelado son un conjunto de diferentes formas de representar aspectos preseleccionados de un sistema. Cada perspectiva tiene un enfoque, una conceptualización, una dedicación y una visualización diferentes de lo que representa el modelo .

En los sistemas de información , la forma tradicional de dividir las perspectivas de modelado es distinguir entre las perspectivas estructural, funcional y conductual/procesual. Esto, junto con las perspectivas de reglas, objetos, comunicación y actores y roles, es una forma de clasificar los enfoques de modelado [11].

Modelo de punto de vista

En cualquier punto de vista, es posible crear un modelo del sistema que contenga únicamente los objetos que son visibles desde ese punto de vista, pero que también capture todos los objetos, relaciones y restricciones que están presentes en el sistema y son relevantes para ese punto de vista. Se dice que un modelo de este tipo es un modelo de punto de vista o una vista del sistema desde ese punto de vista. [3]

Una vista dada es una especificación del sistema en un nivel particular de abstracción desde un punto de vista dado. Los diferentes niveles de abstracción contienen diferentes niveles de detalle. Las vistas de nivel superior permiten al ingeniero diseñar y comprender todo el diseño e identificar y resolver problemas en general. Las vistas de nivel inferior permiten al ingeniero concentrarse en una parte del diseño y desarrollar las especificaciones detalladas. [3]

Ilustración de las vistas, productos y datos en Architecture Framework.

Sin embargo, en el sistema mismo, todas las especificaciones que aparecen en los distintos modelos de puntos de vista deben abordarse en los componentes realizados del sistema. Y las especificaciones para cualquier componente dado pueden extraerse desde muchos puntos de vista diferentes. Por otra parte, las especificaciones inducidas por la distribución de funciones sobre componentes específicos y las interacciones de componentes normalmente reflejarán una partición de preocupaciones diferente de la reflejada en los puntos de vista originales. Por lo tanto, también pueden ser útiles puntos de vista adicionales, que aborden las preocupaciones de los componentes individuales y la síntesis ascendente del sistema. [3]

Descripción de la arquitectura

Una descripción de la arquitectura es una representación de la arquitectura de un sistema, en cualquier momento, en términos de sus componentes, cómo funcionan esas partes, las reglas y restricciones bajo las cuales funcionan esas partes y cómo se relacionan esas partes entre sí y con el entorno. En una descripción de la arquitectura, los datos de la arquitectura se comparten entre varias vistas y productos.

En la capa de datos se encuentran los elementos de datos de la arquitectura y sus atributos y relaciones definitorios. En la capa de presentación se encuentran los productos y las vistas que respaldan un medio visual para comunicar y comprender el propósito de la arquitectura, lo que describe y los diversos análisis arquitectónicos realizados. Los productos proporcionan una forma de visualizar los datos de la arquitectura como representaciones gráficas, tabulares o textuales. Las vistas brindan la capacidad de visualizar los datos de la arquitectura que provienen de los productos, organizando lógicamente los datos para una perspectiva específica u holística de la arquitectura.

Tipos de modelos de vista del sistema

Enfoque de tres esquemas

La noción de un modelo de tres esquemas fue introducida por primera vez en 1977 por la arquitectura de tres niveles ANSI/X3/SPARC , que determinó tres niveles para modelar datos. [12]

El enfoque de tres esquemas para el modelado de datos, introducido en 1977, puede considerarse uno de los primeros modelos de vista. Es un enfoque para la construcción de sistemas de información y la gestión de información de sistemas, que promueve el modelo conceptual como la clave para lograr la integración de datos . [13] El enfoque de tres esquemas define tres esquemas y vistas:

En el centro, el esquema conceptual define la ontología de los conceptos tal como los usuarios piensan en ellos y hablan sobre ellos. El esquema físico describe los formatos internos de los datos almacenados en la base de datos , y el esquema externo define la vista de los datos que se presentan a los programas de aplicación . [14] El marco intentó permitir el uso de múltiples modelos de datos para los esquemas externos. [15]

Con el paso de los años, la habilidad y el interés en la creación de sistemas de información ha crecido enormemente. Sin embargo, en su mayor parte, el enfoque tradicional para la creación de sistemas se ha centrado únicamente en definir los datos desde dos puntos de vista distintos, el "punto de vista del usuario" y el "punto de vista de la computadora". Desde el punto de vista del usuario, al que se hará referencia como el "esquema externo", la definición de datos se da en el contexto de informes y pantallas diseñados para ayudar a las personas a realizar sus trabajos específicos. La estructura requerida de los datos desde un punto de vista de uso cambia con el entorno empresarial y las preferencias individuales del usuario. Desde el punto de vista de la computadora, al que se hará referencia como el "esquema interno", los datos se definen en términos de estructuras de archivos para el almacenamiento y la recuperación. La estructura requerida de los datos para el almacenamiento en la computadora depende de la tecnología informática específica empleada y de la necesidad de un procesamiento eficiente de los datos. [16]

Modelo de arquitectura con vista 4+1

Ilustración del modelo o arquitectura de vista 4+1 .

4+1 es un modelo de vista diseñado por Philippe Kruchten en 1995 para describir la arquitectura de sistemas intensivos en software, basado en el uso de múltiples vistas concurrentes. [17] Las vistas se utilizan para describir el sistema desde el punto de vista de diferentes partes interesadas, como usuarios finales, desarrolladores y gerentes de proyectos. Las cuatro vistas del modelo son la vista lógica, la vista de desarrollo, la vista de proceso y la vista física:

Las cuatro vistas del modelo se refieren a:

Además, se utilizan casos de uso o escenarios seleccionados para ilustrar la arquitectura. Por lo tanto, el modelo contiene 4+1 vistas. [17]

Tipos de vistas de arquitectura empresarial

El marco de arquitectura empresarial define cómo organizar la estructura y las vistas asociadas con una arquitectura empresarial . Debido a que la disciplina de la arquitectura y la ingeniería empresariales es tan amplia y a que las empresas pueden ser grandes y complejas, los modelos asociados con la disciplina también tienden a ser grandes y complejos. Para gestionar esta escala y complejidad, un marco de arquitectura proporciona herramientas y métodos que pueden enfocar la tarea y permitir que se produzcan artefactos valiosos cuando más se necesitan.

Los marcos de arquitectura se utilizan habitualmente en la tecnología de la información y en la gobernanza de sistemas de información . Una organización puede desear exigir que se produzcan determinados modelos antes de que se pueda aprobar un diseño de sistema . De manera similar, puede desear especificar que se utilicen determinadas vistas en la documentación de los sistemas adquiridos: el Departamento de Defensa de los EE. UU. estipula que los proveedores de equipos deben proporcionar vistas específicas del DoDAF para proyectos de capital superiores a un determinado valor.

Marco de Zachman

Ilustración simplificada del marco Zachman con una explicación de las filas. [18] El marco original es más avanzado, consulte un ejemplo aquí.

El Zachman Framework , concebido originalmente por John Zachman en IBM en 1987, es un marco para la arquitectura empresarial que proporciona una forma formal y altamente estructurada de ver y definir una empresa.

El marco se utiliza para organizar "artefactos" arquitectónicos de una manera que tenga en cuenta tanto a quién está dirigido el artefacto (por ejemplo, el propietario de la empresa y el constructor) como qué problema particular (por ejemplo, datos y funcionalidad) se está abordando. Estos artefactos pueden incluir documentos de diseño, especificaciones y modelos. [19]

El Marco Zachman se menciona a menudo como un enfoque estándar para expresar los elementos básicos de la arquitectura empresarial . El Gobierno Federal de los Estados Unidos ha reconocido que el Marco Zachman ha recibido "aceptación mundial como un marco integrado para gestionar el cambio en las empresas y los sistemas que las respaldan". [20]

Vistas de RM-ODP

El modelo de vista RM-ODP , que proporciona cinco puntos de vista genéricos y complementarios sobre el sistema y su entorno.

El Modelo de Referencia para Procesamiento Distribuido Abierto ( RM-ODP ) de la Organización Internacional de Normalización (ISO) [21] especifica un conjunto de puntos de vista para dividir el diseño de un sistema distribuido de software/hardware. Dado que la mayoría de los problemas de integración surgen en el diseño de dichos sistemas o en situaciones muy análogas, estos puntos de vista pueden resultar útiles para separar las preocupaciones de integración. Los puntos de vista del RM-ODP son: [3]

El RMODP define además un requisito para que un diseño contenga especificaciones de coherencia entre puntos de vista, incluyendo: [3]

Vistas del DoDAF

El Marco de Arquitectura del Departamento de Defensa (DoDAF) define una forma estándar de organizar una arquitectura empresarial (EA) o una arquitectura de sistemas en vistas complementarias y consistentes. Es especialmente adecuado para sistemas grandes con desafíos complejos de integración e interoperabilidad, y es aparentemente único en su uso de " vistas operativas " que detallan el dominio operativo del cliente externo en el que operará el sistema en desarrollo.

Vínculos DoDAF entre vistas. [22]

El DoDAF define un conjunto de productos que actúan como mecanismos para visualizar, comprender y asimilar el amplio alcance y las complejidades de una descripción de arquitectura a través de medios gráficos, tabulares o textuales. Estos productos se organizan en cuatro vistas:

Cada vista representa ciertas perspectivas de una arquitectura, como se describe a continuación. Por lo general, solo se crea un subconjunto del conjunto de vistas DoDAF completo para cada desarrollo de sistema. La figura representa la información que vincula la vista operativa , la vista de sistemas y servicios y la vista de estándares técnicos. Las tres vistas y sus interrelaciones impulsadas (por elementos de datos de arquitectura comunes) proporcionan la base para derivar medidas como la interoperabilidad o el rendimiento, y para medir el impacto de los valores de estas métricas en la misión operativa y la eficacia de las tareas. [22]

Vistas de la arquitectura empresarial federal

En la arquitectura empresarial federal de Estados Unidos , las arquitecturas de empresa, de segmento y de solución ofrecen diferentes perspectivas empresariales al variar el nivel de detalle y abordar cuestiones relacionadas pero distintas. Así como las empresas están organizadas jerárquicamente, también lo están las diferentes vistas que ofrece cada tipo de arquitectura. La Guía de prácticas de arquitectura empresarial federal (2006) ha definido tres tipos de arquitectura: [23]

Niveles y atributos de la arquitectura empresarial federal [23]

Por definición, la arquitectura empresarial (AE) se ocupa fundamentalmente de identificar activos comunes o compartidos, ya sean estrategias, procesos de negocio, inversiones, datos, sistemas o tecnologías. La AE está impulsada por la estrategia; ayuda a una agencia a identificar si sus recursos están alineados adecuadamente con la misión de la agencia y sus objetivos y metas estratégicas. Desde una perspectiva de inversión, la AE se utiliza para impulsar decisiones sobre la cartera de inversiones en TI en su conjunto. En consecuencia, los principales interesados ​​de la AE son los altos directivos y ejecutivos encargados de garantizar que la agencia cumpla su misión de la forma más eficaz y eficiente posible. [23]

Por el contrario, la arquitectura de segmentos define una hoja de ruta sencilla para un área de misión central, un servicio comercial o un servicio empresarial. La arquitectura de segmentos está impulsada por la gestión empresarial y ofrece productos que mejoran la prestación de servicios a los ciudadanos y al personal de la agencia. Desde una perspectiva de inversión, la arquitectura de segmentos impulsa las decisiones para un caso de negocio o un grupo de casos de negocio que respaldan un área de misión central o un servicio común o compartido. Los principales interesados ​​en la arquitectura de segmentos son los propietarios y gerentes de empresas. La arquitectura de segmentos está relacionada con la arquitectura empresarial a través de tres principios: estructura, reutilización y alineación. En primer lugar, la arquitectura de segmentos hereda el marco utilizado por la arquitectura empresarial, aunque puede ampliarse y especializarse para satisfacer las necesidades específicas de un área de misión central o un servicio común o compartido. En segundo lugar, la arquitectura de segmentos reutiliza activos importantes definidos a nivel empresarial, incluidos: datos; procesos e inversiones comerciales comunes; y aplicaciones y tecnologías. En tercer lugar, la arquitectura de segmentos se alinea con elementos definidos a nivel empresarial, como estrategias comerciales, mandatos, estándares y medidas de desempeño. [23]

Conjunto nominal de vistas

En busca de un "Marco para modelar arquitecturas de sistemas espaciales", Peter Shames y Joseph Skipper (2006) definieron un "conjunto nominal de vistas", [6] derivado de CCSDS RASDS, RM-ODP, ISO 10746 y compatible con IEEE 1471 .

Ilustración del “Conjunto nominal de vistas” [24]

Este "conjunto de vistas", como se describe a continuación, es una lista de posibles puntos de vista de modelado. No todas estas vistas se pueden utilizar para un proyecto en particular y se pueden definir otras vistas según sea necesario. Tenga en cuenta que, para algunos análisis, los elementos de varios puntos de vista se pueden combinar en una nueva vista, posiblemente utilizando una representación en capas.

En una presentación posterior, este conjunto nominal de vistas se presentó como una Derivación del Modelo de Información Semántica RASDS Extendido. [24] De este modo, RASDS significa Arquitectura de Referencia para Sistemas de Datos Espaciales. Ver segunda imagen.

Punto de vista empresarial [6]
Punto de vista de la información [6]
Arquitectura de referencia para sistemas de datos espaciales. [24]
Punto de vista funcional [6]
Punto de vista físico [6]
Ontología de nivel superior MBED basada en el conjunto nominal de vistas. [6]
Punto de vista de la ingeniería [6]
Punto de vista tecnológico [6]

A diferencia de los modelos de vista enumerados anteriormente, este "conjunto nominal de vistas" enumera una amplia gama de vistas, que permiten desarrollar enfoques potentes y extensibles para describir una clase general de arquitecturas de sistemas con uso intensivo de software. [6]

Véase también

Referencias

  1. ^ ISO/IEC/IEEE 42010:2011, Sistemas y demás— Descripción de la arquitectura
  2. ^ ISO/IEC 10746-1, Tecnología de la información — Procesamiento distribuido abierto — Modelo de referencia: Descripción general
  3. ^ abcdefg Edward J. Barkmeyer ea (2003). Conceptos para la automatización de la integración de sistemas NIST 2003.
  4. ^ Douglas T. Ross y KE Schoman, Jr. "Análisis estructurado para la definición de requisitos". IEEE Transactions on Software Engineering, SE-3(1), enero de 1977.
  5. ^ A. Finkelstein , J. Kramer, B. Nuseibeh, L. Finkelstein y M. Goedicke. "Puntos de vista: un marco para integrar múltiples perspectivas en el desarrollo de sistemas". Revista internacional de ingeniería de software e ingeniería del conocimiento, 2(1):31-58, 1992.
  6. ^ abcdefghijk Peter Shames, Joseph Skipper. "Hacia un marco para modelar arquitecturas de sistemas espaciales" Archivado el 27 de febrero de 2009 en Wayback Machine . NASA, JPL.
  7. ^ Easterbrook, S.; Yu, E.; Aranda, J.; Yuntian Fan; Horkoff, J.; Leica, M.; Qadir, RA (2005). "¿Los puntos de vista conducen a mejores modelos conceptuales? Un estudio de caso exploratorio". 13.ª Conferencia Internacional IEEE sobre Ingeniería de Requisitos (RE'05) . pp. 199–208. CiteSeerX  10.1.1.78.4594 . doi :10.1109/RE.2005.23. ISBN. 978-0-7695-2425-2.
  8. ^ Sinan Si Alhir (2003). "Comprensión de la arquitectura basada en modelos (MDA)". En: Métodos y herramientas . Otoño de 2003.
  9. ^ Consejo del Director de Información del Departamento del Tesoro de los Estados Unidos (2000). Treasury Enterprise Architecture Framework. Versión 1, julio de 2000. Archivado el 18 de marzo de 2009 en Wayback Machine.
  10. ^ IEEE-1471-2000
  11. ^ John Krogstie , (2003). Modelado conceptual, archivado el 16 de marzo de 2007 en Wayback Machine .
  12. ^ Matthew West y Julian Fowler (1999). Desarrollo de modelos de datos de alta calidad Archivado el 21 de diciembre de 2008 en Wayback Machine . El Ejecutivo de enlace técnico de STEP de las industrias de procesos europeas (EPISTLE).
  13. ^ CORREA SECCIÓN 2 ENFOQUE. Recuperado el 30 de septiembre de 2008.
  14. ^ John F. Sowa (2004). ["El desafío de la sopa de conocimientos"]. Publicado en: Tendencias de investigación en educación científica, tecnológica y matemática . Editado por J. Ramadas y S. Chunawala, Centro Homi Bhabha, Mumbai, 2006.
  15. ^ Gad Ariav y James Clifford (1986). Nuevas direcciones para los sistemas de bases de datos: versiones revisadas de los artículos . Escuela de Posgrado en Administración de Empresas de la Universidad de Nueva York. Centro de Investigación sobre Sistemas de Información, 1986.
  16. ^ itl.nist.gov (1993) Definición de integración para modelado de información (IDEFIX) Archivado el 3 de diciembre de 2013 en Wayback Machine . 21 de diciembre de 1993.
  17. ^ ab Kruchten, Philippe (1995, noviembre). Architectural Blueprints — The “4+1” View Model of Software Architecture [Planos arquitectónicos: el modelo de vista “4+1” de la arquitectura de software]. IEEE Software 12 (6), págs. 42-50.
  18. ^ Departamento de Asuntos de Veteranos de los Estados Unidos (2008) Un tutorial sobre el marco de arquitectura Zachman Archivado el 13 de julio de 2007 en Wayback Machine . Consultado el 6 de diciembre de 2008.
  19. ^ Una comparación de las cuatro principales metodologías de arquitectura empresarial Archivado el 9 de abril de 2008 en Wayback Machine , Roger Sessions, Centro de arquitectura de la red de desarrolladores de Microsoft,
  20. ^ Marco de arquitectura empresarial federal Archivado el 16 de septiembre de 2008 en Wayback Machine .
  21. ^ ISO/IEC 10746-1:1998 Tecnología de la información – Procesamiento distribuido abierto: Modelo de referencia – Parte 1: Descripción general, Organización Internacional de Normalización, Ginebra, Suiza, 1998.
  22. ^ ab DoD (2007) DoD Architecture Framework Version 1.5. 23 de abril de 2007 Archivado el 11 de marzo de 2005 en Wayback Machine .
  23. ^ abcd Oficina de Gestión del Programa de Arquitectura Empresarial Federal (2006). Guía práctica de la FEA [ enlace roto ] .
  24. ^ abc Peter Shames y Joseph Skipper (2006). Hacia un marco para modelar arquitecturas de sistemas espaciales Archivado el 27 de mayo de 2010 en Wayback Machine . 25 de mayo de 2006.
Atribución

Dominio público Este artículo incorpora material de dominio público del Instituto Nacional de Estándares y Tecnología.

Enlaces externos