Está en la página 1de 27

Prefacio

ISO ( la Organizacin Internacional de Normalizacin ) e IEC (Comisin Electrotcnica


Internacional ) forman el sistema especializado para la normalizacin mundial. Los organismos
nacionales que son miembros de ISO e IEC participan en el desarrollo de las Normas
Internacionales a travs de comits tcnicos establecidos por la organizacin respectiva, para
tratar con campos particulares de la actividad tcnica . ISO y los comits tcnicos de la CEI
colaboran en campos de inters mutuo. Otras organizaciones internacionales , gubernamentales y
no gubernamentales , en coordinacin con ISO e IEC , tambin participan en el trabajo. En el
campo de la tecnologa de la informacin , ISO e IEC han establecido un comit tcnico conjunto ,
ISO / IEC JTC 1 . Documentos estndares IEEE se desarrollan dentro de las Sociedades de la
IEEE y las Normas de Coordinacin Comits de la Asociacin de Estndares IEEE (IEEE -SA )
Consejo de Normas . El IEEE desarrolla sus normas a travs de un proceso de consenso ,
aprobado por el Instituto Americano de Estndares Nacionales , que rene a los voluntarios que
representan a distintos puntos de vista e intereses para lograr el producto final. Los voluntarios no
son necesariamente miembros del Instituto y sirven sin compensacin. Mientras que el IEEE
administra el proceso y establece reglas para promover la equidad en el proceso de desarrollo de
consenso, el IEEE no evala de forma independiente , probar o verificar la exactitud de la
informacin contenida en sus normas. Las Normas Internacionales se redactan de acuerdo con las
reglas establecidas en la ISO / IEC, Parte 2 . La tarea principal de la norma ISO / IEC JTC 1 es
preparar Normas Internacionales . Proyectos de Normas Internacionales adoptados por la comisin
tcnica conjunta se circulan a los organismos nacionales para votacin. La publicacin como
Norma Internacional requiere la aprobacin por al menos el 75 % de los organismos nacionales
con derecho a voto . Se llama la atencin sobre la posibilidad de que la aplicacin de esta norma
puede requerir el uso de la materia protegida por los derechos de patente . Por la publicacin de
esta norma , no se toma posicin con respecto a la existencia o validez de los derechos de patente
en relacin con la misma . ISO / IEEE no es responsable de la identificacin de las patentes
esenciales o reclamaciones de patentes para las que puede ser necesaria una licencia, para la
realizacin de investigaciones sobre la validez legal o alcance de las patentes o solicitudes de
patentes o la determinacin de si los trminos o condiciones de la licencia se da en relacin con la
presentacin de una carta de garanta o una Declaracin de Patentes y formulario de declaracin
de licencia , si los hubiera, o en los acuerdos de licencia son razonables y no discriminatorias. Se
advierte expresamente a los usuarios de esta norma que la determinacin de la validez de los
derechos de patente , y el riesgo de violacin de esos derechos , es enteramente su propia
responsabilidad . Ms informacin se puede obtener de ISO o de la Asociacin IEEE Normas. ISO /
IEC / IEEE 42010 fue preparada por el Comit Tcnico Conjunto ISO / IEC JTC 1 , Tecnologa de la
informacin , Subcomit SC 7 , software e ingeniera de sistemas , en cooperacin con el Software
y el Comit de Normas de Ingeniera de Sistemas de la Sociedad de Computacin del IEEE , en el
marco del Normas acuerdo de cooperacin entre la Organizacin de Desarrollo socio ISO e IEEE .
Esta primera edicin de la norma ISO / IEC / IEEE 42010 anula y sustituye a la norma ISO / IEC
42010:2007 , que ha sido revisada tcnicamente .

Introduccin

La complejidad de los sistemas hechos por el hombre ha llegado a un nivel sin precedentes . Esto
ha dado lugar a nuevas oportunidades, pero tambin al aumento de los desafos para las
organizaciones que crean y utilizan sistemas. Conceptos, principios y procedimientos de la
arquitectura de se aplican cada vez ms para ayudar a manejar la complejidad que enfrentan los
actores del sistema . Conceptualizacin de la arquitectura de un sistema , tal como se expresa en
una descripcin de la arquitectura , ayuda a la comprensin de la esencia del sistema y las
propiedades clave relativos a su comportamiento , composicin y evolucin , que a su vez afecta a
preocupaciones tales como la viabilidad , utilidad y facilidad de mantenimiento del sistema .
Arquitectura descripciones son utilizados por las partes que crean, utilizan y gestionan los sistemas
modernos para mejorar la comunicacin y la cooperacin , que les permite trabajar de una manera
integrada y coherente. Marcos Arquitectura y descripcin arquitectura idiomas estn siendo
creadas como activos que codifican las convenciones y prcticas comunes de la arquitectura y la
descripcin de arquitecturas dentro de las diferentes comunidades y mbitos de aplicacin. Esta
norma aborda la creacin , el anlisis y el mantenimiento de las arquitecturas de los sistemas
mediante el uso de descripciones arquitectura. Esta Norma Internacional proporciona una ontologa
base para la descripcin de arquitecturas. Las disposiciones de esta Norma Internacional sirven
para reforzar las propiedades deseadas de las descripciones de la arquitectura. Esta norma
tambin especifica las disposiciones que aplican las propiedades deseadas de los marcos de la
arquitectura y lenguajes de descripcin de arquitectura ( ADL ) , con el fin de aportar una
contribucin til al desarrollo y uso de las descripciones de la arquitectura. Esta Norma
Internacional proporciona una base sobre la cual comparar e integrar los marcos de arquitectura y
ADL , proporcionando una ontologa comn para especificar su contenido. Esta norma se puede
utilizar para establecer una prctica coherente para el desarrollo de descripciones de la
arquitectura, la arquitectura y los marcos descripcin arquitectura idiomas en el contexto de un
ciclo de vida y sus procesos (no definido en esta Norma Internacional ) . Esta Norma Internacional
puede utilizarse adems para evaluar la conformidad de una descripcin de la arquitectura , de un
marco de arquitectura , de un lenguaje de descripcin de la arquitectura , o de un punto de vista de
la arquitectura de sus disposiciones . Se aconseja a los usuarios de esta Norma Internacional de
consultar la clusula 4 para ganar reconocimiento de la ontologa siempre , sus conceptos y
principios.

Sistemas e ingeniera de software - Descripcin de Arquitectura

1
Alcance
Esta Norma Internacional especifica la manera en que las descripciones de la arquitectura de los
sistemas se organizan y expresan. Esta Norma Internacional especifica los puntos de vista de la
arquitectura, los marcos de la arquitectura y la descripcin arquitectura idiomas para su uso en la
descripcin de la arquitectura. Esta Norma Internacional tambin proporciona motivaciones de los
trminos y conceptos utilizados ; presenta orientacin sobre la especificacin de los puntos de vista
de arquitectura , y demuestra el uso de esta Norma Internacional con otras normas.

2
Conformidad
Los requisitos de esta Norma Internacional estn contenidas en las clusulas 5 , 6 y 7 . Hay cuatro
situaciones en las que las reclamaciones de conformidad con las disposiciones de esta norma se

pueden hacer. _ Cuando la conformidad se pretenda que una descripcin de la arquitectura, la


reclamacin deber demostrar que la descripcin de la arquitectura con los requisitos estipulados
en la Clusula 5 . _ Cuando la conformidad se pretenda que un punto de vista la arquitectura, la
reclamacin deber demostrar que el punto de vista de la arquitectura con los requisitos
estipulados en la clusula 7 . _ Cuando la conformidad se pretenda que un marco de arquitectura ,
la reclamacin deber demostrar que el marco de la arquitectura cumple con los requisitos
enumerados en el punto 6.1 . _ Cuando la conformidad se pretenda que una descripcin de la
arquitectura lenguaje, la reclamacin deber demostrar que el lenguaje de descripcin de la
arquitectura cumple con los requisitos enumerados en el apartado 6.3 . Requisitos de esta Norma
Internacional se caracterizan por el uso del verbo "deber" . Las recomendaciones estn marcadas
por el uso del verbo "deber" . Los permisos se caracterizan por el uso de la palabra "podr " . En
caso de conflicto entre las figuras normativas y textos , el texto tiene prioridad. Por favor reporte
cualquier conflicto aparente . NOTA Esta Norma Internacional est diseado de tal manera que "
adaptacin " no es ni necesario ni permitido para su uso cuando se hacen declaraciones de
conformidad.

Trminos y definiciones

A los efectos de este documento , los siguientes trminos y definiciones.

3.1
architecting
proceso de concebir , definir, expresar , documentar , comunicar, Certificacin de buena gestin
de , el mantenimiento y la mejora de la arquitectura a lo largo de ciclo de vida de un sistema
NOTA Architecting tiene lugar en el contexto de una organizacin ( " persona o grupo de personas
e instalaciones con una disposicin de responsabilidades, autoridades y relaciones " ) y / o un
proyecto ( "procurar con inicio y final criterios asumidos para crear un producto definido o servicio
de acuerdo con los recursos y los requisitos especificados ") [ISO / IEC 12207 , ISO / IEC 15288 ] .

3.2

Arquitectura

_system _ conceptos fundamentales o las propiedades de un sistema en su entorno plasmada en


sus elementos , relaciones y en los principios de su diseo y evolucin
3.3
Descripcin de la arquitectura del producto del trabajo
AD
se utiliza para expresar una arquitectura convenios marco arquitectura
3.4 principios y prcticas para la descripcin de arquitecturas establecido dentro de un dominio
especfico de aplicacin y / o de la comunidad de interesados

Ejemplo 1 Generalizadas Arquitectura y metodologas de referencia Empresa ( GERAM ) [ISO


15704 ] es un marco de arquitectura.
Ejemplo 2 Modelo de referencia de procesamiento distribuido abierto ( RM- ODP) [ISO / IEC
10746 ] es un marco de arquitectura.

3.5 vista de la arquitectura producto de trabajo que expresa la arquitectura de un sistema desde el
punto de vista de las preocupaciones especficas del sistema

3.6 Arquitectura producto de trabajo mirador establecer los convenios para la construccin, la
interpretacin y el uso de puntos de vista de arquitectura para enmarcar problemas especficos del
sistema

3.7 preocupacin _system _ inters en un sistema correspondiente a una o ms de sus grupos de


inters Nota Una preocupacin se refiere a ninguna influencia sobre un sistema en su entorno ,
incluyendo el desarrollo, tecnolgico, comercial , operacional , organizacional , poltico , econmico,
jurdico
,
reglamentario
,
ecolgico
y
las
influencias
sociales.
3.8 _system ambiente _ contexto para determinar el entorno y las circunstancias de todas las
influencias en un sistema NOTA El entorno de un sistema incluye el desarrollo, tecnolgico,
empresarial , influencias operativas, organizativas, polticas , econmicas, legales , regulatorios,
ecolgica y social.

3.9 Convenciones especie modelo para un tipo de modelado NOTA Ejemplos de clases modelo
incluyen diagramas de flujo de datos , diagramas de clase , redes de Petri , balances ,
organigramas y modelos de transicin de estado.

3.10 interesados _system _ individuales , el equipo , la organizacin, o las clases de los mismos,
que tengan inters en un sistema.

4 Fundamentos conceptuales

4.1 Introduccin

Esta clusula introduce los fundamentos conceptuales de la descripcin de la arquitectura que


comprende un modelo conceptual de la descripcin de la arquitectura ( vase el punto 4.2 ), el
papel de la arquitectura de del ciclo de vida (ver 4.3 ) ; utiliza descripciones de arquitectura (ver
4.4 ), y los marcos de la arquitectura y la descripcin arquitectura idiomas (ver 4.5 ) . Los conceptos
introducidos en esta clusula se utilizan en las Clusulas 5 a 7 para expresar necesidades. NOTA
El Anexo A proporciona mayor discusin de los trminos y conceptos utilizados en esta Norma
Internacional y presenta ejemplos de su uso.

4.2 Modelo conceptual de la descripcin de la arquitectura

4.2.1 Contexto de la descripcin de la arquitectura

La figura 1 representa conceptos clave relativos a los sistemas y sus arquitecturas como un
contexto para la comprensin de la prctica de la descripcin de la arquitectura.

NOTA La figura utiliza las convenciones de diagramas de clases definidas en [ISO / IEC 19501 ] .
Figura 1 - Contexto de la descripcin de la arquitectura del sistema de expresin se utiliza en esta
Norma Internacional para referirse a las entidades cuyas arquitecturas son de inters. El trmino
pretende incluir , pero no se limita a , las entidades dentro de los siguientes dominios : _ sistemas
como se describe en [ISO / IEC 15288 ] : " los sistemas que son artificiales y se puede configurar
con uno o ms de los siguientes : hardware, software, datos, personas, los procesos (por ejemplo ,
los procedimientos para la prestacin del servicio a los usuarios) , procedimientos (por ejemplo, las
instrucciones del operador ) , instalaciones , materiales y entidades presentes en la naturaleza " ; _
los productos y servicios de software como se describe en [ISO / IEC 12207 ] ;
sistemas intensivos en software como se describe en [IEEE Std 1471:2000 ] : " cualquier sistema
donde el software contribuye in_uences esenciales para el diseo, construccin , implementacin y
evolucin del sistema en su conjunto" para abarcar " las aplicaciones individuales , sistemas en el
tradicional sentido , subsistemas , sistemas de sistemas , lneas de productos , familias de
productos , empresas integrales y otras agrupaciones de inters " . Esta Norma Internacional no se
pronuncia sobre lo que constituye un sistema dentro de esos dominios - o en otro lugar. La
naturaleza de los sistemas no se define en esta Norma Internacional. Esta Norma Internacional
est diseado para su uso en los mbitos de los sistemas antes mencionados, sin embargo, nada

de lo impide su uso para la descripcin de la arquitectura de las entidades de inters fuera de los
dominios (por ejemplo, los sistemas naturales y los sistemas conceptuales) . Los actores de un
sistema son las partes con intereses en ese sistema. Los intereses de las partes interesadas se
expresan preocupaciones (vase 4.2.3). Las partes interesadas atribuyen diversos fines a un
sistema. Propsitos son un tipo de preocupacin. NOTA 1 El propsito trmino usado en esta
norma internacional se deriva de su uso en la norma ISO / IEC 15288:2008 , 4.31 : un sistema es
una combinacin de elementos interactuantes organizadas para lograr uno o ms objetivos
expresados. Un sistema se encuentra en un entorno . El medio ambiente determina la totalidad de
las influencias sobre el sistema a lo largo de su ciclo de vida , incluyendo sus interacciones con ese
entorno . El entorno de un sistema puede contener otros sistemas . NOTA 2 En esta Norma
Internacional , el medio ambiente de un sistema est limitado por y entendido a travs de la
identificacin y anlisis de los actores del sistema y sus intereses (vase 4.2.3) . La arquitectura de
un sistema constituye lo que es esencial acerca de que el sistema considerado en relacin con su
entorno . No existe una caracterizacin nica de lo que es esencial o fundamental a un sistema;
que la caracterizacin podra pertenecer a cualquiera o todos los siguientes: _ componentes o
elementos del sistema ; _ cmo se organizan o relacionados entre s los elementos del sistema ; _
principios de la organizacin o el diseo del sistema ; y _ principios relativos a la evolucin del
sistema a lo largo de su ciclo de vida. Arquitectura descripciones se utilizan para expresar
arquitecturas para sistemas de inters ( ver 4.2.2 ) . NOTA 3 El mismo sistema puede ser entendida
a travs de varias arquitecturas distintas ( por ejemplo , cuando se considera en diferentes
entornos ) . Una arquitectura podra ser expresada a travs de varias descripciones arquitectura
distintos ( por ejemplo, cuando se emplean diferentes marcos de arquitectura ) . La misma
arquitectura puede caracterizar ms de un sistema ( por ejemplo, una familia de sistemas
comparten una arquitectura comn )

4.2.2 Arquitecturas y descripciones de la arquitectura

Arquitectura descripciones son productos de trabajo de los sistemas y arquitectura de software. La


figura 2 muestra los conceptos relacionados con la prctica de la descripcin de la arquitectura en
la aplicacin de esta norma internacional para producir una descripcin de la arquitectura expresa
una arquitectura para un sistema de intereses . En esta Norma Internacional , el trmino del
sistema de inters ( o, simplemente , del sistema) se refiere al sistema cuya arquitectura est bajo
consideracin en la preparacin de una descripcin de la arquitectura . Las cifras y el texto en el
resto de 4.2 constituyen un modelo conceptual de la descripcin de la arquitectura.

NOTA 1 La figura utiliza las convenciones de diagramas de clases definidas en [ISO / IEC 19501 ] .
NOTA 2 La Figura 3 proporciona ms detalles sobre las correspondencias y las reglas de
correspondencia. Figura 4 proporciona detalles adicionales sobre la arquitectura lgica.

Figura 2 - Modelo conceptual de una descripcin de la arquitectura

Una descripcin de la arquitectura expresa una arquitectura de un sistema de intereses . Esta


Norma Internacional distingue una arquitectura de un sistema a partir de una descripcin de la
arquitectura . Arquitectura descripciones, no arquitecturas, son el objeto de esta Norma
Internacional. Mientras que una descripcin de la arquitectura es un producto de trabajo , una
arquitectura es abstracto , que consta de los conceptos y propiedades. Esta norma internacional
especifica los requisitos sobre las descripciones de arquitectura. No hay requisitos de esta norma
internacional relativa a las arquitecturas o los sistemas o para su entorno. Esta Norma Internacional
no especifica ningn formato o medio para grabar las descripciones de arquitectura. Se pretende
que sea til para una amplia gama de enfoques para la descripcin de la arquitectura como en
documentos, basado en modelos y tcnicas de repositorio de base . Esta Norma Internacional no
prescribe el proceso o mtodo utilizado para producir descripciones arquitectura. Esta Norma
Internacional no asume ni prescribir mtodos especficos architecting , modelos , anotaciones o
tcnicas utilizadas para producir descripciones arquitectura.

4.2.3 Las partes interesadas y preocupaciones


Las partes interesadas de un sistema tienen preocupaciones con respecto al sistema de intereses

considerados en relacin con su entorno . Una preocupacin puede ser agarrado por uno o ms
grupos de inters. Las preocupaciones surgen en todo el ciclo de vida de las necesidades y
requisitos del sistema , desde opciones de diseo y de las consideraciones de implementacin y
funcionamiento. Una preocupacin puede manifestarse de muchas formas , por ejemplo en
relacin con una o ms necesidades de los interesados , objetivos , expectativas ,
responsabilidades , requisitos, restricciones de diseo , las hiptesis , las dependencias, los
atributos de calidad , las decisiones de arquitectura , riesgos u otros problemas relacionados con el
sistema. Ejemplos A continuacin se sospecha que en los trminos de esta norma : la
funcionalidad, viabilidad , uso, efectos del sistema, las caractersticas del sistema , las propiedades
del sistema , las limitaciones conocidas , la estructura , el comportamiento , el rendimiento, la
utilizacin de recursos , la fiabilidad , la seguridad, la seguridad de la informacin , la complejidad,
evolvability , transparencia , concurrencia , autonoma, costos, plazos , calidad de servicio ,
flexibilidad , agilidad, modificabilidad , modularidad , el control, la comunicacin entre procesos ,
callejn sin salida, cambio de estado , la integracin del subsistema , accesibilidad a los datos , la
privacidad , el cumplimiento con la regulacin , control , negocios objetivos y estrategias,
experiencia del cliente , facilidad de mantenimiento , accesibilidad y facilidad de disposicin . Las
transparencias de distribucin descritos en el modelo de referencia de procesamiento distribuido
abierto [ISO / IEC 10746-1 ] son preocupaciones en los trminos de esta Norma Internacional.
Propiedades del software tal como se describe en la Plaza de [ISO / IEC 25010:2011 , 4.2 ] se
refiere a su nombre en los trminos establecidos en esta Norma Internacional.
4.2.4 Arquitectura opiniones y puntos de vista
Una descripcin de la arquitectura incluye una o ms vistas de arquitectura. Una vista de la
arquitectura (o simplemente, vista ) se dirige a una o varias de las preocupaciones de los actores
del sistema . Una vista de la arquitectura expresa la arquitectura del sistema de intereses de
acuerdo con un punto de vista de la arquitectura (o simplemente , punto de vista ) . Hay dos
aspectos de un punto de vista : las preocupaciones que los marcos para las partes interesadas y
de los convenios que establece en las vistas. Una arquitectura punto de vista frames1 uno o ms
preocupaciones. Una preocupacin puede ser enmarcado por ms de un punto de vista . Una vista
se rige por su punto de vista : el punto de vista establece las convenciones para la construccin ,
interpretacin y anlisis de la vista para abordar las preocupaciones enmarcados por ese punto de
vista . Convenciones Viewpoint pueden incluir idiomas , notaciones , tipos de modelos, normas de
diseo y / o mtodos de modelado , tcnicas de anlisis y otras operaciones en las vistas . La
figura 2 muestra las relaciones entre los puntos de vista y puntos de vista dentro de una
descripcin de la arquitectura . NOTA 1 Esta Norma Internacional no utiliza frases como "
arquitectura de negocios ", " arquitectura fsica " y " arquitectura tcnica " . En los trminos de esta
norma , la arquitectura de un sistema es una concepcin holstica de las propiedades
fundamentales de ese sistema , entiende mejor a travs de mltiples puntos de vista de la
arquitectura . Por lo tanto , equivalentes aproximados de las frases anteriores son " visin de
negocios ", "vista fsico " , y " vista tcnico" , respectivamente . NOTA 2 La clusula 7 se
especifican los requisitos de los puntos de vista de arquitectura. Anexo B proporciona orientacin
sobre la especificacin de puntos de vista.
4.2.5 modelos Arquitectura
Una vista de la arquitectura se compone de uno o ms modelos de arquitectura . Un modelo de
arquitectura utiliza las convenciones de modelado adecuada a las preocupaciones que deben
abordarse. Estas convenciones son especificados por el modelo tipo que rige ese modelo. Dentro
de una descripcin de la arquitectura , un modelo de arquitectura puede ser una parte de ms de
una vista de la arquitectura . La Figura 2 representa el uso de modelos de arquitectura y tipos
modelo dentro de una descripcin de la arquitectura . NOTA Esta Norma Internacional utiliza el
modelo tipo de plazo en lugar de " modelo de diseo arquitectnico " hacer hincapi en que las
clases modelos no necesitan ser til exclusivamente en las descripciones de la arquitectura
4.2.6 Los elementos de AD y correspondencias

Un elemento AD es cualquier construccin en una descripcin de la arquitectura . Elementos de AD


son las construcciones ms primitivas discutidos en esta Norma Internacional. Todos los grupos de
inters , la preocupacin , mirador arquitectura, vista de la arquitectura , el modelo tipo , modelo de
la arquitectura, la decisin de la arquitectura y la justificacin (ver 4.2.7 ) se considera un elemento
AD . Cuando los puntos de vista y tipos de modelo estn definidas y sus modelos se completan , se
introducen elementos adicionales AD . Una correspondencia define una relacin entre los
elementos de AD . Las correspondencias se utilizan para expresar las relaciones arquitectura de
inters dentro de una descripcin de la arquitectura ( o entre las descripciones de arquitectura ) .
Las correspondencias se regirn por reglas de correspondencia . Reglas de correspondencia se
utilizan para hacer cumplir las relaciones dentro de una descripcin de la arquitectura (o entre las
descripciones de arquitectura ) . La Figura 3 representa los conceptos de elementos de AD y
correspondencias . NOTA La figura utiliza las convenciones de diagramas de clases definidas en
[ISO / IEC 19501 ] . Figura 3 - Modelo conceptual de los elementos de AD y correspondencias
Ejemplos Correspondencias y reglas de correspondencia se utilizan para expresar y hacer cumplir
las relaciones de arquitectura , como la composicin , el refinamiento , la consistencia , la
trazabilidad , la dependencia, la restriccin y la obligacin. Requisitos Nota sobre el uso de las
correspondencias y las reglas de correspondencia se especifican en 5.7 . Ejemplos de su uso se
dan en A.6.
4.2.7 decisiones Arquitectura y justificacin
Arquitectura lgica registros explicacin , justificacin o razonamiento sobre decisiones de
arquitectura que se han hecho . La justificacin de una decisin puede incluir la base para una
decisin , las alternativas y compensaciones considerado, las posibles consecuencias de la
decisin y citas de fuentes de informacin adicional. Las decisiones se refieren a las
preocupaciones del sistema , sin embargo , a menudo no existe una correlacin sencilla entre los
dos. Una decisin puede afectar a la arquitectura de varias maneras . Estos pueden ser reflejados
en la descripcin de la arquitectura de la siguiente manera : _ requiere la existencia de elementos
publicitarios; _ cambiar las propiedades de los elementos publicitarios; _ activacin anlisis tradeoff en el que se revisan algunos de los elementos de AD , como otras decisiones y
preocupaciones ; _ sensibilizacin nuevas preocupaciones . La figura 4 muestra los conceptos
relativos
a
las
decisiones
de
la
arquitectura
y
la
justificacin.
NOTA La figura utiliza las convenciones de diagramas de clases definidas en [ISO / IEC 19501 ] .
Figura 4 - Modelo conceptual de decisiones sobre la arquitectura y la justificacin
Requisitos nota para la captura de las decisiones y la justificacin dentro de una descripcin de la
arquitectura se especifican en 5.8.
4.3 Arquitectura de en el ciclo de vida
Architecting contribuye al desarrollo, operacin y mantenimiento de un sistema desde su
concepcin inicial hasta su retirada del uso y eliminacin. Architecting tiene lugar en el contexto de
un proyecto y / o de la organizacin . Architecting se lleva a cabo en todo el ciclo de vida del
sistema , no slo dentro de una etapa del ciclo de vida . Por lo tanto , la arquitectura de un sistema
potencialmente influye en los procesos en todo el ciclo de vida del sistema . Una descripcin de la
arquitectura es un producto de trabajo como resultado de la ejecucin de arquitectura de las
actividades dentro del ciclo de vida del sistema de inters . Un ciclo de vida prescribe las etapas y
la manera en la que el contenido de una descripcin de la arquitectura conforme se van a producir .
Incluso cuando una descripcin de la arquitectura resultados de un nico ciclo de actividad de la
vida , su contenido es probable que sean el resultado de mltiples actividades . Alternativamente ,
una descripcin de la arquitectura puede ser producida por la agregacin de la informacin de otros
productos de trabajo desarrollados por las actividades del ciclo de vida . Esta Norma Internacional
no depende , asumir o prescribe ningn ciclo de vida particular. NOTA Anexo C muestra cmo esta
norma puede ser utilizada en la aplicacin de los procesos del ciclo de vida de ISO / IEC 12207 e
ISO / IEC 15288 . ISO / IEC 12207 e ISO / IEC 15288 proporcionan procesos del ciclo de vida
distintas para el diseo arquitectnico. Esto no contradice el concepto de arquitectura de que se

lleva a cabo durante todo el ciclo de vida por dos razones : ( 1 ) Cualquier proceso de ISO / IEC
12207 o ISO / IEC 15288 puede considerarse como la ejecucin de todo el ciclo de vida , (2 ) el
uso de " diseo arquitectnico " en la norma ISO / IEC 12207 e ISO / IEC 15288 es ms estrecha
que el concepto de arquitectura de en esta Norma Internacional.
4.4 Usos de las descripciones de la arquitectura
_ Como documentacin de desarrollo y mantenimiento; _ documentar los aspectos esenciales de
un sistema , como por ejemplo : o empleo y el medio ambiente previsto; o principios, suposiciones
y limitaciones para orientar los cambios futuros , o puntos de flexibilidad o limitaciones del sistema
con respecto a los cambios futuros ; o decisiones de arquitectura , sus fundamentos e
implicaciones ; _ como entrada para las herramientas automatizadas para la simulacin ,
generacin y anlisis de sistemas ; _ especificar un grupo de sistemas que comparten
caractersticas comunes ( como los estilos arquitectnicos , arquitecturas de referencia y
arquitecturas de lneas de productos ), _ la comunicacin entre las partes involucrados en el
desarrollo, produccin , despliegue, operacin y mantenimiento de un sistema; _ como base para la
preparacin de los documentos de adquisicin (por ejemplo, solicitudes de propuestas y
declaraciones de trabajo); _ comunicacin entre los clientes , compradores , proveedores y
desarrolladores como parte de negociaciones del contrato ; _ documentar las caractersticas,
prestaciones y diseo de un sistema para potenciales clientes , compradores , propietarios,
operadores e integradores ; _ la planificacin para la transicin de una arquitectura legado a una
nueva arquitectura, _ como gua para el apoyo operativo y de infraestructura y gestin de la
configuracin , _ como apoyo a la planificacin de sistemas , programacin y presupuestacin
actividades ; _ el establecimiento de criterios para las implementaciones de certificacin para el
cumplimiento de una arquitectura , _ como mecanismo de cumplimiento a la poltica exterior y de
proyecto y / o la organizacin (por ejemplo , la legislacin, los principios arquitectnicos generales )
_ como base para la revisin , anlisis y evaluacin del sistema a travs de su ciclo de vida, _
como base para el anlisis y evaluacin de arquitecturas alternativas; _ compartir las lecciones
aprendidas y la reutilizacin de conocimiento arquitectnico a travs de puntos de vista, los
patrones y estilos ; _ la formacin y la educacin de los grupos de inters y otras partes sobre las
mejores prcticas en la arquitectura y la evolucin del sistema . NOTA Anexo C describe el uso de
descripciones de la arquitectura en el contexto de otras normas.
4,5 marcos Arquitectura y descripcin arquitectura idiomas
Marcos Arquitectura y lenguajes de descripcin de arquitectura ( AVD ) son dos mecanismos
utilizados en arquitectura de . Marcos Arquitectura y descripcin arquitectura idiomas se
especifican mediante la construccin de los conceptos de la descripcin de la arquitectura
presentada en esta Norma Internacional. Un marco de arquitectura establece un procedimiento
comn para la creacin, la interpretacin , el anlisis
Arquitectura descripciones tienen muchos usos por una variedad de grupos de inters en todo el
ciclo de vida del sistema. Usos para las descripciones de arquitectura incluyen , pero no se limitan
a : _ como base para el diseo del sistema y las actividades de desarrollo ; _ como base para
analizar
y
evaluar
las
implementaciones
alternativas
de
una
arquitectura
;
Usos de los marcos de arquitectura incluyen, pero no se limitan a : la creacin de descripciones de
la arquitectura , el desarrollo de herramientas de modelado de arquitectura y arquitectura de los
mtodos y el establecimiento de procesos para facilitar la comunicacin , los compromisos y la
interoperacin entre varios proyectos y / u organizaciones. NOTA 1 marcos Arquitectura frecuencia
abarcan ambas disposiciones para la descripcin de la arquitectura y las prcticas architecting
adicionales. Ejemplos Los siguientes son los marcos de arquitectura en los trminos de esta norma
: los sistemas de marco de arquitectura [ 44 ] , el Ministerio de Arquitectura de Defensa Marco
Reino Unido [ 27 ] , Architecture Framework The Open Group ( TOGAF ) [ 41 ] , de Kruchten " 4 1
informacin de Zachman " vista de modelo [ 23 ] , Siemens 4 vistas mtodo [ 10 ] , modelo de
referencia para el procesamiento distribuido abierto ( RM- ODP), [ISO / IEC 10746 ] y generalizada
Arquitectura Empresarial Referencia ( GERA ) [ISO 15704 ] . La figura 5 muestra el contenido de un

marco de arquitectura . NOTA La figura utiliza la notacin de diagramas de clases definidas en [ISO
/ IEC 19501 ] .
Figura 5 - Modelo conceptual de un marco de arquitectura
NOTA 2 Los requisitos de los marcos de la arquitectura se especifican en el punto 6.1 . Un lenguaje
de descripcin de la arquitectura (ADL ) es cualquier forma de expresin para su uso en la
descripcin de la arquitectura. Un ADL proporciona una o ms clases modelo como un medio para
enmarcar algunas de las preocupaciones de la audiencia de los interesados . El ADL se puede
enfocar estrictamente, definir un modelo nico tipo , o muy centrado para proporcionar varios tipos
de modelos, opcionalmente organizadas en puntos de vista. A menudo, un ADL es apoyada por
herramientas automatizadas para ayudar a la creacin, el uso y el anlisis de sus modelos .
Ejemplos Rapide [ 25 ] , Wright [ 43 ] , SysML [ 31 ] , ArchiMate [ 40] y las lenguas punto de vista
RM- ODP [ISO 10746 ] son las AVD en los trminos de esta Norma Internacional.
5 Arquitectura descripciones
5.1 Introduccin
Esta clusula especifica las caractersticas de las descripciones de la arquitectura que permiten a
los usos indicados en el apartado 4.4 . Arquitectura descripciones incluyen el siguiente contenido ,
segn se especifica en el resto de esta clusula : _ Descripcin de la arquitectura de informacin
de identificacin y descripcin (ver 5.2 ) ; _ identificacin de los actores del sistema y sus intereses
( vase el punto 5.3 ) ; _ la definicin de cada punto de vista de la arquitectura utilizada en la
descripcin de la arquitectura (vase 5.4 ) ; _ una vista de la arquitectura y los modelos de
arquitectura para cada punto de vista de la arquitectura utilizados (ver 5.5 y 5.6 ) ; _ normas
aplicables AD correspondencia , correspondencia AD y un registro de inconsistencias conocidas
entre los contenidos necesarios de la descripcin de la arquitectura (vase 5,7 ) ; _ razones para
decisiones de arquitectura realizadas ( vase 5.8 ) ; el verbo incluyen cuando se utiliza en la
clusula 5, indica que, o bien la informacin est presente en la descripcin de la arquitectura o
referencia a que la informacin se proporciona en el mismo. NOTA 1 Esta Norma Internacional no
especifica un formato para las descripciones de la arquitectura. NOTA 2 Con el fin de producir
mltiples descripciones de la arquitectura de diferentes arquitecturas o expresiones alternativas de
la misma arquitectura , el usuario se aplicara lo dispuesto en la presente clusula para cada
descripcin de la arquitectura . Los resultados pueden ser combinados o por separado presentan ,
de manera que no se define en esta Norma Internacional.
5.2 Arquitectura identificacin descripcin y resumen
Una descripcin de la arquitectura debe identificar el sistema de intereses e incluir informacin
adicional como se determina por el proyecto y / o de la organizacin . El contenido detallado de
identificacin y elementos de informacin complementarios ser el especificado por la organizacin
y / o proyecto. NOTA Ejemplos de identificacin y la informacin suplementaria en una descripcin
de la arquitectura son: fecha de emisin y el estado , autores , revisores, autoridad de aprobacin,
la organizacin emisora , historial de cambios , resumen ; alcance ; contexto , glosario , informacin
de control de versiones , gestin de la informacin de configuracin y referencias . Ver [ISO / IEC
15289 ] o [ISO / IEC TR 15504-6:2008 , B.1 ] para ver ejemplos. Los resultados de las
evaluaciones de la arquitectura o la descripcin de la arquitectura se incluirn.
5.3 Identificacin de los grupos de inters y las preocupaciones
Una descripcin de la arquitectura deber identificar a los actores del sistema que tienen
preocupaciones consideradas fundamentales para la arquitectura del sistema de inters . Las
siguientes partes se considerarn en su caso, identificados en la descripcin de la arquitectura : _
los usuarios del sistema ; _ operadores del sistema , - adquirentes del sistema , - los propietarios
del sistema , - proveedores del sistema , - los desarrolladores de la sistema ; - constructores del
sistema ; - mantenedores del sistema . Una descripcin de la arquitectura debe identificar los

problemas considerados fundamentales para la arquitectura del sistema de inters . Los siguientes
preocupaciones se considerarn , y cuando corresponda , identificados en la descripcin de la
arquitectura : - los efectos del sistema ; - la idoneidad de la arquitectura para el logro de los
propsitos del sistema; - la viabilidad de la construccin e implantacin del sistema ; - los riesgos
potenciales y los impactos del sistema a sus grupos de inters de todo su ciclo de vida ; _ la
mantenibilidad y la capacidad de evolucin del sistema. Una descripcin de la arquitectura deber
asociar cada problema identificado con los grupos de inters identificados con esa preocupacin.
NOTA 1 En general , la asociacin de las preocupaciones con las partes interesadas es de muchos
a muchos. NOTA 2 Esta Norma Internacional no prescribe : la granularidad de las preocupaciones ,
cmo se interrelacionan las preocupaciones con otras preocupaciones , o cmo las
preocupaciones se relacionan con otras declaraciones acerca de un sistema como necesidades de
los interesados , los objetivos del sistema o requisitos. Estas cuestiones son temas para los marcos
de arquitectura especficos , mtodos architecting u otras prcticas.
5.4 Arquitectura puntos de vista
Una descripcin de la arquitectura deber incluir cada punto de vista de la arquitectura utilizada en
el mismo. Cada punto de vista de la arquitectura incluido se especificar de conformidad con lo
dispuesto en la Clusula 7 . Cada problema identificado de conformidad con 5.3 , se enmarca en al
menos un punto de vista. NOTA 1 Esta Norma Internacional no requiere puntos de vista
particulares que se utilizarn. NOTA 2 Anexos B y C proporcionan informacin adicional
relacionada con los puntos de vista de arquitectura.
5.5 Vistas Arquitectura
Una descripcin de la arquitectura deber incluir exactamente una vista de la arquitectura de cada
punto de vista de la arquitectura utilizada. Cada vista de la arquitectura debe adherirse a las
convenciones de su punto de vista de la arquitectura de gobierno. Cada vista de la arquitectura
deber incluir: a) la identificacin y la informacin complementaria segn lo especificado por la
organizacin y / o proyecto , b ) la identificacin de su punto de vista de gobierno , modelos de
arquitectura que se ocupan de todos los problemas enmarcados por su punto de vista de gobierno
c ) y cubrir todo el sistema desde ese punto de vista ; d ) de grabacin de los problemas conocidos
dentro de una vista con respecto a su punto de vista de gobierno . NOTA 1 Vase 5.2 NOTA
ejemplos de identificacin e informacin adicional por a) . NOTA 2 El requisito per c ) que cada
vista de la arquitectura abarca todo el sistema con respecto a las preocupaciones enmarcadas por
su punto de vista de gobierno es esencial para la asignacin completa de las preocupaciones
dentro de una descripcin de la arquitectura . Dentro de un punto de vista, uno o ms modelos de
arquitectura se pueden utilizar para presentar selectivamente porciones del sistema para resaltar
los puntos de inters , sin violar este requisito ( ver 5.6 ) . NOTA 3 " Problemas conocidos " por d )
incluyen cuestiones no resueltas , excepciones y desviaciones de las convenciones. Cuestiones
abiertas pueden conducir a decisiones que tomar . Las excepciones y las desviaciones pueden ser
documentados como resultados de la decisin y las razones (por 5,8 ) . Una descripcin de la
arquitectura puede incluir informacin que no forma parte de cualquier vista de la arquitectura .
Ejemplos instancias de informacin no forma parte de ningn punto de vista son visin general del
sistema , correspondencias modelo y la arquitectura lgica.
5.6 modelos Arquitectura
Una vista de la arquitectura se compone de uno o ms modelos de arquitectura . Cada modelo de
la arquitectura debe incluir la identificacin versin especificado por la organizacin y / o proyecto.
Cada modelo de la arquitectura debe identificar su modelo de gobierno bueno y adherirse a las
convenciones
de
ese
modelo
tipo
(vase
el
punto
5.4)
.
Un modelo de arquitectura puede ser una parte de ms de una vista de la arquitectura . NOTA 1
Los modelos de arquitectura de comparticin entre vistas de arquitectura permite una descripcin
de la arquitectura para enmarcar problemas distintos pero relacionados sin redundancia o
repeticin de la misma informacin en mltiples puntos de vista, y reduce las posibilidades de

incompatibilidad. El intercambio de modelos de arquitectura tambin permite un estilo orientado a


aspectos de la descripcin de la arquitectura: modelos de arquitectura compartidos a travs de
puntos de vista de arquitectura se puede utilizar para expresar las perspectivas arquitectnicas
( ver [ 36 ] ), modelos de arquitectura compartidos dentro de una vista de la arquitectura pueden ser
usados para expresar texturas arquitectnicas ( ver [ 34 ] ) . Modelos de arquitectura se puede
utilizar como " contenedores " para la aplicacin de patrones de arquitectura [ 4 ] o estilos de la
arquitectura para expresar planes fundamentales (tales como capas , , , punto a punto , modelovista- controlador de tres niveles ) en vistas de arquitectura. NOTA 2 Esta Norma Internacional no
prescribe cmo se crean los modelos de arquitectura . Pueden ser construidos individualmente,
derivados de o basados en otros modelos.
5.7 Relaciones Arquitectura
5.7.1 Consistencia en una descripcin de la arquitectura
Una descripcin de la arquitectura se expondrn las inconsistencias conocidas a travs de sus
modelos de la arquitectura y sus puntos de vista. NOTA Mientras descripciones arquitectura
consistentes son preferibles , a veces es imposible o poco prctico para resolver todas las
inconsistencias , por razones de tiempo, esfuerzo o informacin insuficiente. En tales situaciones ,
las inconsistencias son conocidos para ser registrada . Una descripcin de la arquitectura debe
incluir un anlisis de la consistencia de sus modelos de la arquitectura y sus puntos de vista.
Correspondencias y reglas de correspondencia, segn se especifica en 5.7.2 y 5.7.3 , se puede
utilizar para expresar , registrar , aplicar y analizar la coherencia entre los modelos , vistas y otros
elementos de AD dentro de una descripcin de la arquitectura.
5.7.2 Correspondencias
Cada una correspondencia en una descripcin de la arquitectura se identificar e identificar los
elementos que participan AD . AD elementos pueden ser instancias de cualquier construccin
introducida en 4.2 ( actores , preocupaciones del sistema , puntos de vista de arquitectura , vistas
Arquitectura , tipos de modelos, modelos de arquitectura, arquitectura de decisiones y la
justificacin ) . Cuando se definen puntos de vista y los tipos de modelos, tipos adicionales de
elementos de AD pueden introducir . Cada una correspondencia en una descripcin de la
arquitectura sealar las normas que rigen la correspondencia (vase 5.7.3 ) . Nota elementos en
una correspondencia no tiene por qu ser distinto . Una correspondencia se puede definir entre un
elemento AD y l mismo.
5.7.3 reglas de correspondencia
Una descripcin de la arquitectura deber incluir cada regla de la correspondencia que le sea
aplicable . NOTA 1 Una regla de correspondencia se aplica a una descripcin de la arquitectura
podra originarse en la descripcin de la arquitectura , en un punto de vista ( vase el captulo 7 ), o
en un marco de la arquitectura o la descripcin de la arquitectura lengua ( vase el captulo 6 ) .
Para cada regla de correspondencia identificada, una descripcin de la arquitectura har constar si
la regla se mantiene o no registrar todos los violacines conocidos. Una regla de correspondencia
se mantiene si una correspondencia asociada se puede demostrar que cumplir la norma. Una regla
de correspondencia es violada si una correspondencia asociada puede demostrar que no cumplan
la
norma
o
cuando
no
existe
correspondencia
asociada
.
NOTA 2 Correspondencias en esta Norma Internacional estn diseados para ser compatibles con
Vista correspondencias en RM- ODP [ISO / IEC 10746 y 19793 ] (vase A.6 ) . NOTA 3
Correspondencias y reglas de correspondencia se pueden aplicar a mltiples descripciones
arquitectura para expresar las relaciones correspondientes a varias arquitecturas o sistemas .
Generalizando elemento AD a otros elementos de informacin , un proyecto y / u organizacin
podra aplicar correspondencias ya definido entre las descripciones de arquitectura y otros
productos de trabajo (tales como especificaciones de requisitos ) para expresar otras relaciones de
inters arquitectnico (como la trazabilidad de los elementos de AD a los requisitos ).

5.8 Arquitectura lgica


5.8.1 Justificacin de la grabacin
Una descripcin de la arquitectura deber incluir una justificacin de cada punto de vista de la
arquitectura incluido para su uso por 5,4 en trminos de sus grupos de inters , las preocupaciones
, los tipos de modelos, notaciones y mtodos. Una descripcin de la arquitectura deber incluir
lgica para cada decisin considerada para ser una decisin arquitectura de clave (por 5.8.2 ) .
Una descripcin de la arquitectura debe proporcionar evidencia de la consideracin de alternativas
y la justificacin de las decisiones tomadas.
5.8.2 Decisin de grabacin
Una descripcin de la arquitectura debe registrar decisiones de arquitectura que se consideran
clave para la arquitectura del sistema de inters . No es prctico para registrar todas las decisiones
acerca de la arquitectura de un sistema . Una grabacin de decisin y estrategia de intercambio
deben ser aplicadas por la organizacin y / o proyecto de establecer criterios para la seleccin de
las decisiones clave que se registr y apoyado con fundamentos en la descripcin de la
arquitectura . Los criterios a tener en cuenta son : - las decisiones relativas a los requisitos de gran
importancia arquitectnica , - las decisiones que requieren una gran inversin de esfuerzo o tiempo
para hacer , poner en prctica o hacer cumplir , - las decisiones que afectan a las partes
interesadas clave o un nmero de partes interesadas , - las decisiones que requieren razonamiento
complejo o no evidentes ; - las decisiones que son muy sensibles a los cambios , - las decisiones
que podran ser costosos para cambiar ; _ decisiones que forman una base para la planificacin y
gestin de proyectos ( por ejemplo , el trabajo de creacin de la estructura de desglose , el
seguimiento de la puerta de la calidad) ; _ decisiones que resultan en gastos de capital o los costes
indirectos . Al grabar las decisiones , se debe considerar lo siguiente: - la decisin se identifica , - la
decisin se afirma , - la decisin est vinculada a las preocupaciones del sistema a que
corresponde
,
se
identifica
al
propietario
de
la
decisin;
- La decisin est vinculada a elementos AD afectadas por la decisin , - no hay justificacin
vinculada a la decisin de conformidad con 5.8.1 ; - se identifican las limitaciones y supuestos que
influyen en la decisin ; - alternativas que se han considerado , y sus posibles consecuencias , se
registran , se registran _ consecuencias de la decisin ( en relacin con otras decisiones ) ; _
record marcas de tiempo en que se tom la decisin , cuando fue aprobada y cuando fue
cambiado, se proporcionan _ citaciones a las fuentes de informacin adicional. NOTA 1 Puede ser
til registrar alternativas no adoptadas y la justificacin de los rechazos. Puede darse el caso de
que en el futuro estas razones ya no se aplican y la decisin debe ser reconsiderada. NOTA 2
Puede ser til para registrar las relaciones entre las decisiones de arquitectura . Ejemplos de tipos
de relaciones son : constrie , influencias , permite , triggers , fuerzas, subsume , refina, los
conflictos - con , y es - compatible - con ( ver [ 23 , 44 ] ) .
6 marcos Arquitectura y descripcin arquitectura idiomas
6,1 marcos Arquitectura
Un marco de arquitectura deber incluir: a) informacin que identifica el marco de arquitectura ; b )
la identificacin de uno o ms problemas (por 5,3 ) , y c) la identificacin de uno o ms grupos de
inters que tienen esas preocupaciones ( por 5,3 ) , d ) uno o ms puntos de vista de la
arquitectura que enmarcan esas preocupaciones ( por 7 ), e) las reglas de correspondencia ( por
5,7 ) . El verbo incluye cuando se usa en la Clusula 6 indica que, o bien la informacin est
presente en el marco de la arquitectura o la referencia a la informacin que se proporciona en el
mismo. Un marco de arquitectura debe incluir las condiciones de aplicabilidad . Ejemplos La
siguientes son las condiciones de aplicabilidad : _ Una descripcin de la arquitectura con la
arquitectura marco AF1 tiene que identificar a los actores A, M y P cuando el sistema de intereses
opera dentro de la jurisdiccin J. _ Una descripcin de la arquitectura con la arquitectura marco

AF2 est permitido omitir V1 punto de vista cuando se han identificado problemas de sistema en
tiempo real. _ Cuando se utiliza la arquitectura marco AF3 , modelo de tipo MK se puede omitir en
V2 punto de vista menos S es un actor determinado . Un marco de arquitectura deber establecer
su compatibilidad con las disposiciones del modelo conceptual en 4.2 . NOTA El requisito anterior
se puede cumplir a travs de un metamodelo , un mapeo del marco construye para el modelo en
4,2 , un texto narrativo , o de alguna otra manera.
6.2 El cumplimiento de una descripcin de la arquitectura de un marco de arquitectura
Una descripcin de la arquitectura se adhiere a un marco de arquitectura cuando: _ cada grupo de
inters aplicable, organizada en el marco de la arquitectura se ha considerado e identificado en la
descripcin de la arquitectura (por 5,3 ) ; _ preocupacin cada caso identificado en el marco de la
arquitectura se ha considerado e identificado en la arquitectura Descripcin (por 5,3 ) ; _ cada
punto de vista , igualmente especificado por el marco de arquitectura (por 6.1 ) se incluye (por 5.4 )
en la descripcin de la arquitectura ; _ cada regla de correspondencia aplicable especificado por el
marco de arquitectura est incluido en la descripcin de la arquitectura (por 5,7 . 3 ), y _ la
descripcin de la arquitectura se ajusta a los requisitos de la clusula 5 . Aplicable significa que
cuando se cumplen las condiciones de aplicabilidad ( ver seccin 6.1 ) . Un marco de arquitectura
podr establecer normas adicionales para la adhesin . NOTA Una descripcin de la arquitectura
podra adherirse a uno o ms marcos de arquitectura , o para no marcos . Para una descripcin de
la arquitectura de adherirse a ms de un marco supondra una conciliacin entre las partes
interesadas de cada marco contiene , inquietudes , puntos de vista , los tipos de modelos y reglas
de correspondencia dentro de la descripcin de la arquitectura.
6.3 Descripcin de Arquitectura idiomas
Una descripcin de la arquitectura idioma deber especificar: a) la identificacin de uno o ms
problemas para ser expresadas por la ADL (por 5,3 ) , b) la identificacin de uno o ms grupos de
inters que tienen esas preocupaciones ( por 5,3 ) , y c) el modelo tipo implementado por la ADL
que enmarcan esas preocupaciones ( por la clusula 7 , d ) ), d ) cualquier punto de vista de
arquitectura ( por la clusula 7 ) Nota Un ADL no necesita dar ningn punto de vista de arquitectura
, sino que puede definir una o ms clases de modelo para su uso en puntos de vista de la
arquitectura definida en otro lugar . e) reglas de correspondencia ( por 5,7 ) en relacin a sus
clases al modelo C).
7 Arquitectura puntos de vista
Un punto de vista de la arquitectura se especificar: a) uno o ms problemas enmarcados por este
punto de vista (por 5,3 ), b) las partes interesadas tpicas para problemas enmarcados en este
punto de vista ( por 5,3 ), c) uno o ms tipos de modelos utilizados en este punto de vista ;
d ) para cada modelo tipo identificado en el c ) , los idiomas , notaciones , las convenciones , las
tcnicas de modelado , los mtodos analticos y / u otras operaciones que se utilizan en los
modelos de este tipo , e) las referencias a las fuentes. Nota 1 punto d ) se reuni con un
metamodelo para el modelo tipo que define la estructura y las convenciones de sus modelos .
Punto e) puede incluir autor, fecha, URLs, y / o citas de otros documentos. Un punto de vista de la
arquitectura debe incluir informacin sobre las tcnicas architecting utilizados para crear ,
interpretar o analizar una vista regido por este punto de vista , como por ejemplo : - las reglas de
correspondencia , criterios y procedimientos para la comprobacin de coherencia (vase 5.7.1 ) y
la integridad ( vase el apartado 5.5 d ) ; - mtodos de evaluacin o anlisis; _ mtodos
heursticos , mtricas , modelos , normas de diseo o directrices, mejores prcticas y ejemplos
para ayudar en el concepto de la creacin y de sntesis. Un punto de vista de la arquitectura se
puede definir como una parte de una descripcin de la arquitectura ( clusula 5 ) , como parte de
un marco de arquitectura (Clusula 6 ) o el uso de forma individual los requisitos de esta Clusula.
Un punto de vista biblioteca es un punto de vista de la arquitectura producida fuera del contexto de
una sola descripcin de la arquitectura de tal manera que se puede utilizar en muchas
descripciones arquitectura . NOTA 2 Esta norma no requiere puntos de vista particulares que se

utilizarn. NOTA 3 Anexo B proporciona orientacin sobre la especificacin de puntos de vista.


Anexo C contiene ejemplos de los puntos de vista de arquitectura.
Notas acerca de los trminos y conceptos
A.1 Introduccin
Este anexo describe los principios de diseo , conceptos y trminos en que se basa esta Norma
Internacional. Esta norma define los requisitos mnimos sobre las descripciones de arquitectura
para apoyar el alcance establecidos en la clusula 1 . El enfoque consiste en permitir la utilizacin
de organizaciones la mxima flexibilidad en la aplicacin de la norma al tiempo que demuestra la
conformidad con los requisitos establecidos en las clusulas 5 , 6 y 7. Dado el carcter
multidisciplinar de la arquitectura de , la intencin es satisfacer las necesidades de mltiples partes
interesadas y permitir diferentes maneras de describir un sistema. La organizacin de las
descripciones de la arquitectura en vistas usando puntos de vista proporciona un mecanismo para
la separacin de preocupacin entre los grupos de inters , mientras que proporciona la vista de
todo el sistema que es fundamental para el concepto de la arquitectura . Establecer la calidad de
una arquitectura que se describe por una descripcin de la arquitectura conforme ( Es una buena
arquitectura ? ) O la calidad de la propia descripcin de la arquitectura (Es esta descripcin de la
arquitectura completa ? ) Son factores para la evaluacin de la descripcin de la arquitectura . Esta
norma no pretende imponer las condiciones que se requieren para las consideraciones de calidad .
Se requiere que los resultados de estas evaluaciones se registran , por 5,2 . Las evaluaciones de
calidad de las arquitecturas y de las descripciones de la arquitectura son temas para los futuros
esfuerzos de normalizacin. Esta Norma Internacional se utilizan varios trminos : la arquitectura ,
la preocupacin , el modelo , la vista y punto de vista , que estn en uso amplio con varios
significados diferentes . Este anexo describe estos trminos , las motivaciones de sus definiciones
en esta norma internacional , y contrasta estas definiciones con otros usos.
A.2 Sistemas y arquitecturas
En esta Norma Internacional, el trmino arquitectura se pretende transmitir la esencia o los
fundamentos de un sistema. Hay varios aspectos clave para la definicin de la arquitectura en esta
norma ( 3.2 ) . Esta definicin fue elegida para abarcar una variedad de usos anteriores del trmino
" arquitectura" reconociendo sus temas comunes subyacentes. La principal de ellas es la
necesidad de comprender y controlar los elementos de un sistema de intereses que contribuyen a
su utilidad , el costo , el tiempo y el riesgo en su entorno . En algunos casos , los elementos
fundamentales son componentes fsicos o estructurales del sistema y sus relaciones . A veces , los
elementos fundamentales son elementos funcionales o lgicos . En otros casos , lo que es
fundamental y esencial para la comprensin de un sistema de inters son sus principios o pautas
generales . La definicin de la arquitectura en esta norma se pretende que abarque estos usos
distintos, pero relacionados entre s , fomentando al mismo tiempo una delimitacin ms rigurosa
de lo que constituye la arquitectura de un sistema. Los " conceptos o propiedades " frase se utiliza
en la definicin ( 3.2 ) para permitir que dos filosofas diferentes para usar esta norma y sin
prejuicios. Estas dos filosofas son: La arquitectura como concepto : la arquitectura ( de un
sistema ) es una concepcin de un sistema en la mente de uno , y la arquitectura como la
propiedad : arquitectura ( de un sistema ) es una propiedad de ese sistema. Los estudios empricos
han descubierto cuatro metforas de la arquitectura que se encuentran en las organizaciones
[ 39 ] : - arquitectura como modelo , - la arquitectura como la literatura
- La arquitectura como lenguaje ; - la arquitectura como decisin. La base conceptual de esta
norma no supone una de estas metforas , sino que funciona igual de bien con cualquiera de ellos .
La existencia de estos mltiples metforas apoya un principio central del diseo de esta norma :
que la arquitectura se basa intrnsecamente en mltiples actores con mltiples problemas del
sistema.
A.3 Preocupaciones

La Norma Internacional utiliza el trmino inters para significar cualquier tema de inters
relacionados con el sistema . Las partes interesadas en un sistema tienen estas preocupaciones.
Algunas preocupaciones impulsan la arquitectura y por lo tanto, esta norma requiere su
identificacin como parte de la descripcin de la arquitectura. La motivacin de este trmino viene
de la frase " separacin de intereses " en el software e ingeniera de sistemas , acuado por
Edsger W. Dijkstra en 1974 : Permtanme tratar de explicar a usted , qu es de mi gusto es
caracterstico de todo el pensamiento inteligente. Es que uno est dispuesto a profundizar en un
aspecto de uno de los temas tratados en aislamiento por el bien de su propia consistencia , todo el
tiempo sabiendo que uno se est ocupando slo uno de los aspectos . Sabemos que un programa
debe ser correcta y podemos estudiarlo slo desde ese punto de vista , tambin sabemos que
debe ser eficiente y podemos estudiar su eficacia en otro da , por as decirlo. En otro estado de
nimo , podemos preguntarnos si , y si es as , por qu el programa es deseable. Pero no se gana
nada , todo lo contrario ! - Haciendo frente a estos diversos aspectos simultneamente. Es lo que a
veces he llamado " la separacin de intereses ", que , aunque no perfectamente posible, sin
embargo, es la nica tcnica disponible para la ordenacin eficaz de los propios pensamientos, que
yo sepa . Esto es lo que quiero decir con " la atencin de uno se centra en algn aspecto ": esto no
significa ignorar los otros aspectos , que slo est haciendo justicia al hecho de que desde el punto
de vista de este aspecto , el otro es irrelevante. Es ser uno y mltiple -track mente al mismo tiempo.
[ 7 ] Segn lo especificado en esta norma internacional , cada punto de vista de arquitectura tramas
una o varias preocupaciones ( vase el punto 5.4 ) de manera que una vista que corresponde a las
direcciones conocidas preocupaciones especficas para el sistema de intereses punto de vista.
Separar el tratamiento de las preocupaciones de los puntos de vista permite a los actores
interesados a centrarse en un par de cosas a la vez y ofrece una forma de gestionar la complejidad
(ver 5.5 ) . La literatura de los sistemas e ingeniera de software registra un gran inventario de tales
preocupaciones . Los ejemplos se dan en 4.2.3 . Although concerns incluyen riesgos y hazards
( ver 5,3 ) el term no debera ser understood ser synonymous con " riesgos " o " worries " pero
como referring a cualquier topic de interest.
A.4 Arquitectura opiniones y puntos de vista
Los trminos de vista de la arquitectura y el punto de vista de la arquitectura son fundamentales en
esta Norma Internacional. Aunque a veces se utilizan como sinnimos , en esta norma se refieren a
distintos tipos de cosas. Es un objetivo de la Norma Internacional para abarcar descripcin estudios
de arquitectura existentes , proporcionando terminologa y conceptos comunes . Muchas de las
prcticas actuales arquitecturas expresan a travs de colecciones de modelos. Por lo general ,
estos modelos estn adems organizadas en grupos cohesivos , llamado puntos de vista. La
cohesin de un grupo de modelos se determina por las preocupaciones de actuacin de dicho
grupo de modelos . Lo que ha faltado en la prctica reciente es un trmino distinto para el
mecanismo para la formalizacin de estas agrupaciones y en referencia a los convenios por los
que se fabrican los modelos. En esta Norma Internacional , punto de vista se refiere a las
convenciones para expresar una arquitectura con respecto a una serie de preocupaciones : Un
punto de vista es una forma de ver los sistemas , un punto de vista es el resultado de aplicar un
punto de vista de un sistema de inters particular.
El uso de mltiples puntos de vista para expresar una arquitectura es una premisa fundamental de
la Norma Internacional. Se reconoce ampliamente la necesidad de mltiples puntos de vista en las
descripciones de la arquitectura. Mientras que el uso de mltiples vistas es generalizada , los
autores difieren en lo que se necesitan puntos de vista y sobre los mtodos apropiados para la
expresin de cada vista . Debido a la amplia gama de opinin, esta norma no requiere un conjunto
predefinido de puntos de vista , sino que fomenta la prctica de definir o seleccionar puntos de
vista pertinentes al sistema de intereses , y el tratamiento de los puntos de vista como elementos
de primera clase de las descripciones de la arquitectura. El primer trabajo sobre los puntos de vista
de primera clase aparece en el Anlisis Estructurado de Ross ( TDAA ) en 1977 [ 35 ] . En la
ingeniera de requisitos , Nuseibe , Kramer y Finkelstein tratar puntos de vista como entidades de
primera clase , con atributos y operaciones [ 29 ] asociados . Estas obras inspir la formulacin de
puntos de vista de arquitectura como se especifica en la clusula 7 . El trmino tambin se eligi

para alinearse con el modelo de referencia ISO de procesamiento distribuido abierto ( RM-ODP ) ,
que utiliza el trmino en estas formas : Un punto de vista ( en un sistema ) es una abstraccin que
produce una especificacin de todo el sistema relacionado con un conjunto particular de
preocupaciones . [ISO / IEC 10746-1:1998 , 6.2.2 ] punto de vista (en un sistema ) : una forma de
abstraccin logra mediante un conjunto seleccionado de construcciones arquitectnicas y reglas
que estructuran , con el fin de centrarse en las preocupaciones particulares de un sistema. [ ISO /
IEC 10746-2:2009 , 3.2.7 ] Sin embargo , en esta Norma Internacional utiliza vista de la
arquitectura para referirse a la aplicacin de un punto de vista de un sistema en particular , RMODP utiliza la especificacin de punto de vista plazo. La relacin entre la perspectiva y punto de
vista sugiere esta metfora : Vista : mirador :: programa : Programacin idioma2 Un punto de vista
especifica las convenciones (como notaciones, lenguajes y tipos de modelos) para la construccin
de un cierto tipo de vista . Ese punto de vista puede ser aplicado a muchos sistemas . Cada punto
de vista es una de estas aplicaciones . Del mismo modo , un programa es una instancia de la
aplicacin de un lenguaje de programacin para una situacin o diseo problema especfico . Otra
metfora para entender la diferencia entre la vista y el punto de vista es : vistas: mirador :: mapa: la
leyenda Una leyenda define las convenciones utilizadas en la preparacin de un mapa (como su
tamao, color y otras simbologas ) para ayudar a los lectores en la interpretacin que se asignan
segn lo previsto . Al igual que cada mapa debe tener una leyenda , cada vista de la arquitectura
debe tener un punto de vista de la arquitectura especificando los convenios para la interpretacin
de los contenidos de la vista . Otro trmino , ViewType , introducido por Clements et al. [ 5 ] ,
establece una clasificacin de los puntos de vista en los trminos establecidos en esta Norma
Internacional. Hay tres categoras de puntos de vista se describen en su trabajo : viewtypes
mdulo, componente y el conector , y la asignacin . Dentro de una descripcin individual
arquitectura, esta norma exige que cada vista tiene que ser gobernado por exactamente un punto
de vista. Esto significa que cada vista se ajusta a un conjunto de convenciones ( posiblemente
mltiples tipos modelo ) . Este requisito no impide que los usuarios de esta Norma Internacional
combinacin o composicin de los puntos de vista de arquitectura para fines especficos ( de
manera que no se define en esta Norma Internacional ) , siempre y cuando el requisito se cumple
dentro de una descripcin individual arquitectura. En esta Norma Internacional , cada vista de la
arquitectura tiene que representar a todo el sistema desde la perspectiva del sistema se refiere
enmarcado por su punto de vista de gobierno. Esto refleja el carcter global de la arquitectura. Por
ejemplo , una vista del rendimiento de un sistema en red de la red debe tener en cuenta tanto
los retardos de transmisin ( en un modelo ) y tiempos de procesamiento ( en otro modelo ) para
producir una vista de extremo - a - extremo holstica del rendimiento de todo el sistema . Una
descripcin de la arquitectura puede centrarse en el sistema de inters en un punto de tiempo
especfico ( por ejemplo, cuando se entrega a un cliente ) , o considerar la evolucin del sistema a
travs de muchas escalas de tiempo . Cualquier punto de vista puede estar compuesta de una
serie de modelos , cada uno representando el sistema de inters en un punto dado del tiempo. La
composicin de tales modelos dentro de un punto de vista sera describir la forma en que el
sistema evoluciona con el tiempo , sin dejar de cumplir el requisito de que la vista se ocupa de todo
el sistema . Hay dos enfoques comunes para la construccin de puntos de vista : el enfoque
sinttico y el enfoque proyectivo . En el enfoque sinttico , un arquitecto construye vistas del
sistema de intereses e integra estos puntos de vista dentro de una descripcin de la arquitectura
mediante correspondencias modelo . En el enfoque proyectivo , arquitecto deriva cada vista a
travs de alguna rutina , posiblemente mecnica , procedimiento de extraccin a partir de un
depsito subyacente. Esta Norma Internacional se puede utilizar con cualquiera de estos enfoques
a puntos de vista. Mary Shaw escribe [ 38 ] : Diseo de rutina consiste en resolver los problemas
familiares , la reutilizacin de gran parte de las soluciones anteriores. ... La mayora de las
disciplinas de ingeniera capturar, organizar y compartir los conocimientos de diseo para hacer el
diseo ms simple rutina . Manuales y manuales suelen ser los portadores de la informacin
organizada. La naturaleza " reutilizable " los puntos de vista de arquitectura (y los marcos de
arquitectura, conjuntos punto de vista como coordinados ) destaca su utilidad como mecanismos
para capturar el conocimiento de arquitectura estratgica , dentro de una organizacin o en la
comunidad de arquitectura de mayor tamao. Codificar Puntos de vista especfico de la aplicacin ,
el mtodo especfico u organizacin especficos de enfoques , y apoyar as el crecimiento y la

evolucin de las prcticas de la arquitectura. Anexos B y C proporcionan ms informacin y


referencias relativas a los puntos de vista de arquitectura.
A.5 modelos , productos de trabajo y modelos de arquitectura
Los modelos y los modelos base de gran parte de los sistemas y arquitectura de software . La
nocin de modelo es fundamental para la comprensin de esta Norma Internacional. Diferentes
comunidades usan modelos de diferentes maneras. Por lo tanto , es importante entender el trmino
como se usa en esta norma : M es un modelo de S si M se puede utilizar para responder a
preguntas sobre S.3 Esta afirmacin tiene dos consecuencias importantes : ( 1 ) Cada modelo tiene
un tema. ( 2 ) Un modelo puede ser cualquier cosa : ( i ) un modelo puede ser un concepto ( un "
modelo mental " ) , o ( ii ) un modelo puede ser un producto de trabajo . En esta Norma
Internacional, el trmino modelo se utiliza de dos maneras. En primer lugar, se utiliza en su sentido
lenguaje ordinario , como explicado anteriormente. En segundo lugar , se utiliza en un sentido
especializado para definir una parte clave de la arquitectura de , encarnado en el modelo de
arquitectura plazo ( vase el apartado 5.6 ) .
En el primer sentido del trmino , hay varios tipos de modelos relacionados con la arquitectura de
que se describen en esta Norma Internacional. La diferencia entre ( 2 ) ( i) y ( 2 ) ( ii ) es crucial
para la comprensin de la distincin en la Norma Internacional entre una arquitectura y una
descripcin de la arquitectura . En el sentido de ( 2 ) ( i ) , la arquitectura es un concepto (es decir ,
un modelo mental) de un sistema til para responder a algunas preguntas sobre ese sistema. En el
sentido de ( 2 ) ( ii ) , hay tres tipos de modelos definidos por el Estndar Internacional se dio
cuenta que los productos de trabajo : - una descripcin de la arquitectura es un producto de trabajo
que modela la arquitectura de un sistema de intereses , y su objeto es las preguntas de los grupos
de inters identificados "sobre todos los problemas del sistema identificadas para ese sistema , una vista de la arquitectura es un producto de trabajo , y su tema es un conjunto especfico de
preocupaciones de los interesados enmarcadas por su punto de vista de gobierno , - un modelo de
arquitectura es un producto de trabajo , y su objeto es determinado por su tipo de modelo. Cuando
un producto de trabajo se entiende en esta Norma Internacional como un " artefacto asociado con
la ejecucin de un proceso de " [ ISO / IEC 15504-1:2004 , 3,55 ] .
A.6 Correspondencias
Cuando varios modelos se desarrollan de un sujeto, estos modelos pueden ser incompatibles . En
las descripciones de arquitectura , una de las consecuencias del empleo de mltiples puntos de
vista es la necesidad de expresar y mantener la coherencia entre esos puntos de vista . En la
edicin 2000 de la norma IEEE Std 1471, esta necesidad fue reconocida en cuanto a los requisitos
para analizar y registrar inconsistencias conocidas a travs de puntos de vista de una descripcin
de la arquitectura (vase 5.7.1 ) . En ese momento , no hubo prctica bien establecida que se
codi_ed por la norma para la expresin o la aplicacin de esta coherencia. Esta edicin de la
Norma Internacional presenta correspondencias para expresar las relaciones entre descripcin
arquitectura elementos ( elementos AD ) . Las correspondencias tienen un nmero de usos . Ellos
se pueden utilizar para expresar la consistencia , la trazabilidad , la composicin , el refinamiento y
la transformacin de modelos , o dependencias de cualquier tipo que abarca ms de un solo
modelo de tipo . Un estudio de los usos de las relaciones del modelo junto con una taxonoma y la
clasificacin de los mecanismos de relacin se encuentra en [ 2 ] . Las correspondencias pueden
ser utilizados para cumplir con los requisitos de 5.7.1 para grabacin de vista consistencia y
inconsistencias . El resto de esta subclusula se presentan ejemplos de las correspondencias y las
reglas de correspondencia. Las caractersticas del mecanismo de correspondencia , en relacin a
los mecanismos similares en la literatura , se discuten . Ejemplo 1 se presenta un modelo simple de
correspondencia. Ejemplo 1 Considere dos vistas de un sistema S : una visin hardware , HW
( S ) , y una vista de componentes de software , SC ( S ) . Teniendo en cuenta que SC ( S ) incluye
elementos de software , e1 , ... e6 y HW ( S ) incluye las plataformas de hardware , P1, P4, ... una
correspondencia expresando que los elementos de software se ejecutan en la que se muestra en la
Figura A.1 plataformas

.
El ejemplo cumple el requisito de 5.7.2 : tiene un nombre nico ( ExecutesOn ) , identifica los
elementos participantes ( los eis y pjs ) , e identifica una regla de correspondencia opcional ( R1).
Una regla de correspondencia expresa una restriccin a forzar una correspondencia . Ejemplo 2
presenta una regla de correspondencia simple. Ejemplo 2 Considere dos puntos de vista ,
hardware y componentes de software. Una regla de la correspondencia relativa a los dos es: R1:
Cada elemento de software, ei, segn la definicin de los componentes de software necesita para
ejecutar una o ms plataformas , PJ, segn la definicin de Hardware . El ExecutesOn
correspondencia Ejemplo 1 viola la regla R1 del Ejemplo 2 , ya que algunos elementos de software
de SC ( S ) (E5 y E6 ) no se han asignado para ejecutar en cualquier plataforma. La mayora de las
correspondencias se expresarn en trminos de elementos de los modelos de participantes , pero
esto no se requiere . Ejemplos 3 y 4 muestran otras formas de correspondencias . Ejemplo 3
Considere la siguiente regla de correspondencia :
Tareas - Interacciones : Cada instancia de modelo tipo de tareas debe tener un refinamiento a una
instancia de modelo Interacciones especie. Esta regla de correspondencia modelo podra ser
satisfecha por la correspondencia se muestra en la Figura A.2 donde existen usuarios, operadores
y Auditores . Cada modelo de tareas (que se ilustra como un tringulo ) se refina en un modelo de
interaccin ( ilustrado como un pentgono ).
Ejemplo 3 En los participantes en la correspondencia no son elementos de los modelos , pero los
modelos de s mismos. Una correspondencia se relacionan los elementos antidumping (vase 4.2.5
y 5.7.2 ) , los usuarios de la norma internacional podrn introducir otros tipos de elementos de AD
se adapte a sus propsitos. Muchas correspondencias sern binario, pero esto no es necesario.
Una correspondencia se puede relacionar un nmero arbitrario de elementos EA. Ejemplo 4 ilustra
una regla de correspondencia n -aria . Ejemplo 4: Considere la siguiente regla de correspondencia
del modelo:
Ver - versiones : El identificador de versin de cada vista tiene que ser mayor que 1,5 antes de la
publicacin . El trmino "correspondencia" fue elegido para alinearse con RM- ODP . El mecanismo
de la correspondencia est diseado para ser compatible con vista correspondencias en RM - ODP
[ ISO / IEC 19793 ] ; sin embargo, hay algunas diferencias . Diferencias ms importantes son: ( 1 )
El trmino "correspondencia" se utiliza en esta norma en lugar de " visin de correspondencia " .
En RM- ODP, cada vista es homognea , una sola lengua mirador se utiliza la especificacin punto
de vista. Esta Norma Internacional permite vistas heterogneos : cada vista se compone de uno o
ms modelos de arquitectura en la que cada modelo utiliza un lenguaje de modelado diferente ( ver
5.6 ) . Es til para poder establecer una correspondencia entre los modelos en diferentes lenguajes
de modelado , no slo entre los puntos de vista. Por lo tanto , "vista la correspondencia " es un
caso especial de lo que se necesita en esta norma internacional , y ese trmino es algo engaoso
en este caso ms general , (2 ) ver las correspondencias RM -ODP son relaciones binarias ,
mientras que las correspondencias modelo en esta Norma Internacional son relaciones n -arias , y (
3 ) ver las correspondencias RM -ODP se definen en los elementos de las especificaciones punto
de vista , mientras que las correspondencias modelo en esta norma no tiene por qu referirse a los
elementos individuales de los modelos , sino elementos arbitrarios AD . ( 4 ) Correspondencias y
reglas de correspondencia se pueden utilizar para expresar las relaciones a travs de
descripciones arquitectura . Matemticamente , una correspondencia es una relacin n -aria . Una
regla de correspondencia es una definicin intensional de una relacin n -aria . Relaciones incluyen
asignaciones de 1-1 ( isomorfismos ) y funciones como casos especiales , ambos de los cuales son
demasiado restrictiva para muchas aplicaciones de correspondencias . Relaciones tienen
propiedades tiles que permiten la composicin y el razonamiento , y permiten la representacin y
la manipulacin eficiente ( ver [ 28 ] y las referencias en l ) . Ejemplo 5 muestra algunos de los
ejemplos anteriores expresadas como relaciones en la notacin de conjuntos . Ejemplo 5
ExecutesOn ( R1) = {( e1, p1 ) , ( e1, p4 ) , ( e2 , p2 ) , ( e2 , p3 ) , ( e3 , p3 ) , (e4 , p4 ) } Usuarios
( tareas Interacciones) = {( OperatorTasks , OperatorInteractions ) , ( CustomerTasks ,
CustomerInteractions ) , ( AuditorTasks , AuditorInteractions ) } LatestVersion ( View- versiones ) =
{( view1 , v2.0 ) ( view2 , v2.0 ) ( view3 , v2.0 ) , ( view4 , v2.0 ) , ( view5 , v2.0 ) }
A.7
marcos
Arquitectura
y
descripcin
arquitectura
idiomas

En los sistemas e ingeniera de software , la nocin de marco de arquitectura se remonta a la


dcada de 1970 [ 6 , 44 ] . La motivacin para la definicin de la expresin ( 3.6 ) y su
especificacin ( en 6,1 ) en esta norma es proporcionar un medio para definir los marcos de
arquitectura actuales y futuros de una manera uniforme para promover el intercambio de
informacin sobre los sistemas, arquitecturas y tcnicas para Descripcin de la arquitectura , entre
otras - de trabajo que permita mejorar la comprensin y la interoperabilidad entre las comunidades
de arquitectura que estn utilizando diferentes bases conceptuales . La definicin uniforme de
puntos de vista de la arquitectura y las colecciones coordinadas de esos puntos de vista se puede
promover la reutilizacin de herramientas y tcnicas a las comunidades que utilizan estos marcos .
La especificacin del marco de arquitectura tiene por objeto establecer las relaciones entre un
marco de arquitectura y otros conceptos en esta norma internacional (ilustrada en las figuras 2 y 4 )
. Marcos Arquitectura menudo incluyen contenido adicional , las recetas y las relaciones, tales
como los requisitos del proceso , las conexiones del ciclo de vida , y los formatos de la
documentacin , no se define en esta Norma Internacional , pero posibles futuras reas de
estandarizacin. El trmino arquitectura lenguaje de descripcin (ADL ) ha estado en uso desde la
dcada de 1990 en el software , los sistemas y las comunidades de arquitectura empresarial . En el
modelo conceptual de esta Norma Internacional, una descripcin de la arquitectura idioma es un
idioma para usar en una descripcin de la arquitectura . Por lo tanto un ADL puede ser utilizado por
uno o ms puntos de vista para enmarcar las preocupaciones del sistema identificados dentro de
una descripcin de la arquitectura . Los primeros ADLs incluyen Rapide (Stanford ) [ 25 ] , Wright
( CMU ) [ 43 ] , y Darwin (Imperial College) . ADL se centraron en problemas estructurales :
organizacin del sistema a gran escala se expresa en trminos de componentes, conectores y
configuraciones diferentes y de apoyo para la formulacin de los problemas de conducta . Ms
recientemente , las AVD " de amplio espectro " se han desarrollado que soportan una amplia gama
de preocupaciones. Estos incluyen arquitectura Anlisis y Lenguaje de descripcin ( AADL ) [ 37 ] ,
SysML [ 31], y ArchiMate [ 40 ] . Ejemplos 1 y 2 describen dos ADLs contemporneos con
referencia a su relacin con el modelo conceptual definido en esta Norma Internacional . Ejemplo 1
ArchiMate organiza AD en varias capas de preocupaciones: de negocios, aplicaciones y tecnologa
(o infraestructura) ; varios aspectos de preocupacin en cada una de esas capas : aspectos
estructurales , de comportamiento y la Informacin , y define dieciocho puntos de vista bsicos
para estos. Cada punto de vista se define a travs de su propia metamodelo , sobre ese punto de
vista a los dems, y la especificacin de los grupos de inters , la preocupacin , el propsito, las
capas y los aspectos . Ejemplo 2 El Lenguaje de Modelado de Sistemas ( SysML ) se basa en UML
. SysML define varios tipos de diagramas : Actividad, secuencia , estado de la mquina , el uso de
casos, definicin de bloque , bloque interno , Paquete , Parametric , y los diagramas de exigencia .
En los trminos de esta norma , cada tipo de diagrama SysML es un modelo tipo . SysML
proporciona construcciones de primera clase para los grupos de inters , preocupaciones ,
opiniones y Puntos de Vista de manera que los usuarios pueden crear nuevos puntos de vista de
acuerdo con esta Norma Internacional. Al igual que un marco de arquitectura , una frames ADL un
conjunto especfico de las preocupaciones por una audiencia de los interesados , mediante la
definicin de una o varias especies modelo , junto con los mtodos de anlisis asociados o
herramientas. Similar a un marco de arquitectura o punto de vista de la arquitectura , un ADL es un
recurso - es reutilizable no se limita en uso a un sistema individual o descripcin de la arquitectura .
Gua para los puntos de vista de arquitectura
B.1 Introduccin
Este anexo proporciona una plantilla para la documentacin de los puntos de vista de arquitectura
y una gua anotada a una muestra de puntos de vista disponibles en la actualidad.
B.2 Una plantilla para documentar los puntos de vista de la arquitectura
B.2.1 resumen plantilla
Se presenta un modelo para los puntos de vista de arquitectura. Un punto de vista de la
arquitectura que se documenta en esta forma cumplir con los requisitos de la Clusula 7. La

plantilla se compone de un conjunto de ranuras o elementos de informacin (a travs de B.2.11


B.2.2). Cada ranura se identifica por un nombre (B.2.X nombre de ranura) seguido por una breve
descripcin de su contenido previsto, orientacin para el desarrollo de ese contenido, y en algunos
casos "sub ranuras". No se necesita cada ranura para la documentacin de cada punto de vista.
Esta plantilla se basa en una propuesta en [9]. B.2.2 nombre Mirador El nombre del punto de vista.
Si hay sinnimos u otros nombres comunes por los que se conoce el punto de vista, registre aqu.
B.2.3 resumen Mirador
Una visin abstracta o breve del punto de vista y sus caractersticas principales.
B.2.4 Preocupaciones y "anti-preocupaciones" Una lista de las preocupaciones relacionadas con la
Arquitectura de ser enmarcada en este punto de vista por 7 a). Esta informacin es crtica para un
arquitecto, ya que ayuda a decidir si este punto de vista ser til para un sistema de inters
particular. Puede ser til para documentar los tipos de problemas un punto de vista no es apropiado
para. La articulacin de anti-preocupacin puede ser un buen antdoto para ciertos modelos y
anotaciones utilizadas excesivamente.
B.2.5 actores tpicos
Un listado de los diferentes actores del sistema se espera que sean usuarios o destinatarios de los
puntos de vista elaborados con este punto de vista por 7 b ) . NOTA Cuando se selecciona un
punto de vista para su uso y se aplica en una descripcin de la arquitectura , el AD tiene que
documentar la asociacin de actores reales del sistema con problemas enmarcados por cada punto
de vista (por 5,3 )
B.2.6 tipos de modelos
B.2.6.1 Introduccin
Identificar cada modelo tipo especificado por el punto de vista por 7 c ) . Para cada modelo tipo
utilizado , describir sus convenciones , el lenguaje o las tcnicas de modelado. Estos son los
recursos clave de modelado que el punto de vista pone a disposicin y determinar los vocabularios
para la construccin de la vista. Estos incluyen las operaciones en los modelos del modelo de clase
( B.2.6.5 ) La Norma Internacional no especifica un estilo para documentar tipos de modelos. Un
modelo tipo puede ser documentado en una serie de maneras, incluyendo: ( 1 ) mediante la
especificacin de un metamodelo que define sus construcciones bsicas , (2 ) , proporcionando
una plantilla modelo para rellenar por los usuarios , (3 ) a travs de una definicin de lenguaje o por
referencia a un lenguaje de modelado existente , o ( 4 ) por alguna combinacin de estos mtodos .
Se proporciona orientacin sobre los mtodos ( 1 ) a travs de ( 3 ) a continuacin.
B.2.6.2 modelo tipo : metamodelo
Un metamodelo se presentan los elementos de AD que componen el vocabulario de un modelo tipo
. Hay diferentes maneras de representar metamodelos . El metamodelo debe presentar : Entidades : Cules son los principales tipos de elementos que estn presentes en los modelos de
este tipo? - Atributos : Qu propiedades hacen las entidades poseen en modelos de este tipo? Las relaciones : Qu relaciones se de_ned entre las entidades de los modelos de este tipo? Restricciones: Qu tipos de restricciones existen en las entidades, atributos y / o relaciones en los
modelos de este tipo? Entidades , atributos , relaciones y restricciones son elementos AD en el
sentido de 3,4 (vase tambin 4.2.5 y 5.7 ) . NOTA Cuando un punto de vista especifica varios tipos
modelo a menudo es til para especificar un solo punto de vista metamodelo unificar la definicin
de los modelos de clases . Adems , a menudo es til usar una sola metamodelo para expresar
mltiples , puntos de vista relacionados (como en la definicin de un marco de arquitectura)
.
B.2.6.3 modelo tipo : Plantillas

Proporcionar una plantilla o la forma que especifica el formato y / o el contenido de los modelos de
este modelo tipo .
B.2.6.4 modelo tipo : idiomas
Identificar una notacin o el modelo de lenguaje existente o definir uno que puede ser utilizado para
los modelos de este modelo tipo . Describe la sintaxis , la semntica , soporte de herramientas ,
segn sea necesario.
B.2.6.5 modelo tipo : operaciones
Operaciones De_ne disponible en los modelos de la clase . Vase el anlisis de las operaciones en
las vistas en
B.2.7 reglas de correspondencia
Documentar las reglas de correspondencia definidos por este punto de vista o sus tipos de
modelos. Por lo general , estas normas sern " modelo de cruz" o " vista ", ya que las limitaciones
dentro de un modelo tipo se han especificado en el marco de las convenciones de ese modelo
tipo
.
B.2.8 Las operaciones en vistas
Operaciones de_ne los mtodos que han de aplicarse a las opiniones oa sus modelos. Las
operaciones se pueden dividir en categoras : - los mtodos de creacin son el medio por el que las
opiniones se preparan con este punto de vista . Estos pueden ser en forma de gua de procesos
( cmo empezar, qu hacer a continuacin ), o el trabajo de orientacin de producto ( plantillas para
los puntos de vista de este tipo ) ; heurstica , estilos , patrones , o otros lenguajes . - Mtodos
interpretativos son el medio por el que las opiniones se ha de entender por el lector y el sistema de
grupos de inters. - Los mtodos de anlisis se utilizan para comprobar , razonar sobre ,
transformar, predecir , aplicar y evaluar los resultados arquitectnicos de este punto de vista . Diseo o aplicacin mtodos se utilizan para realizar o construir sistemas que utilizan la
informacin de este punto de vista .
B.2.9Ejemplos
Esta seccin proporciona ejemplos para el lector.

B.2.10 Notes
Cualquier informacin adicional que los usuarios de este punto de vista podra necesaria o til .
B.2.11 Fuentes
Identificar las fuentes de este punto de vista , en su caso , incluido el autor , la historia , las
referencias de la literatura , de la tcnica, por 7 e).
B.3 gua comentada de los puntos de vista de arquitectura
Los siguientes representan algunos recursos para los puntos de vista arquitectnicos bien
documentados . No todos ellos estn documentados de acuerdo con los requisitos de esta Norma
Internacional , pero se podra utilizar en una descripcin de la arquitectura ni comprendidos en un
marco de arquitectura de una manera conforme. - Callo -Arias , Amrica y Avgeriou , " De_ning
puntos de vista de ejecucin de un sistema de software de obra grande y compleja " [ 4 ]
Documentos de un " catlogo punto de vista de ejecucin " para la comprensin de la ejecucin de
los sistemas intensivos en software complejos. Los cuatro puntos de vista son: perfil de ejecucin ,

despliegue ejecucin , uso de recursos y la simultaneidad de ejecucin . Tambin se incluyen


reglas de correspondencia entre los puntos de vista. - Clements , et al , documentacin
Arquitecturas de Software : Vistas y ms all [ 5 ] Proporciona gran cantidad de recursos para la
definicin de las 3 categoras de puntos de vista. . Estas categoras , llamadas viewtypes (vase
A.4 ) , son mdulos , componentes y Conector y viewtypes asignacin . Dentro de cada ViewType ,
se
definen
una
serie
de
estilos
.
Eeles y Cripps , el proceso de Arquitectura de Software [ 8 ] De_nes un proceso para arquitectos
de software , utilizando el modelo IEEE 1471:2000 como una fundacin . Proporciona una plantilla
de punto de vista y catlogo punto de vista , incluyendo: Requisitos, funcional , implementacin ,
validacin de aplicaciones, infraestructura , sistemas de gestin , disponibilidad, rendimiento,
seguridad , y los " productos de trabajo " (es decir , tipo de modelo) para cada uno. - ISO / IEC
42010 Puntos de vista repositorio [ 42 ] La pgina web es un repositorio de puntos de vista de
arquitectura presentados por la comunidad. - Kruchten , " El '4 +1' ver modelo de la arquitectura "
[ 23 ] Define puntos de vista para las vistas lgica , Desarrollo, proceso y fsica . Las vistas
resultantes se integran a travs de Escenarios . - Rozansky y Woods , Sistemas Arquitectura de
Software : Trabajar con los interesados mediante Puntos de vista y perspectivas [ 36 ] Define un
catlogo de puntos de vista : funcional , informacin , concurrencia , desarrollo, despliegue y
operativa puntos de vista y perspectivas ( vase 5.6 , nota 1 ) : Seguridad, Rendimiento y
escalabilidad , disponibilidad y capacidad de adaptacin , y las perspectivas de evolucin de
sistemas intensivos en software.
Relacin con otras normas
C.1 Introduccin
Arquitectura descripciones se pueden utilizar en una variedad de configuraciones y modelos de
ciclo de vida . En este anexo se ilustra como descripciones arquitectura creadas de conformidad
con esta norma internacional puedan cumplir los requisitos de otras normas. Un enfoque general
para el cumplimiento de los requisitos de otras normas durante el uso de esta Norma Internacional
es definir uno o ms puntos de vista que se refiere a la estructura del sistema relacionado con los
requisitos y producir puntos de vista que cumplan tales requisitos como parte de una descripcin
de la arquitectura . Los puntos de vista definidos en el presente anexo se especifican aqu , de
acuerdo
con
los
requisitos
de
la
Clusula
7
.
C.2
Uso
con
la
norma
ISO
/
IEC
12207:2008
C.2.1 general
ISO / IEC 12207:2008 define dos procesos relacionados especficamente con la arquitectura :
diseo arquitectnico del sistema ( vase la norma ISO / IEC 12207:2008 , 6.4.3 ) y el software de
diseo arquitectnico ( vase la norma ISO / IEC 12207:2008 , 7.1.3) . El concepto de arquitectura
en esta norma est en consonancia con los procesos de diseo arquitectnico de la norma ISO /
IEC 12207 . Sin embargo , la norma ISO / IEC 12207 impone requisitos sobre la descripcin de la
arquitectura , adems de los de esta Norma Internacional. En concreto, un diseo arquitectnico
sistema debe incluir una identificacin de los elementos hardware , elementos software y
elementos de operacin manual incluidas en el sistema y una asignacin de los requisitos del
sistema a dichos elementos. Diseos arquitectnicos del sistema deben ser evaluados en relacin
con los criterios de trazabilidad , y la coherencia con los requisitos del sistema , la idoneidad de las
normas y mtodos de diseo , y la viabilidad de las operaciones de software y manual. El uso
previsto de una descripcin de la arquitectura puede incluir otros procesos de la ISO / IEC 12207 .
En particular, una descripcin arquitectnica puede ser utilizado en actividades distintas de la
actividad de diseo de la arquitectura del sistema para facilitar las comunicaciones entre el
adquirente y el desarrollador . El Software Proceso de Diseo Arquitectnico de la norma ISO / IEC
12207 es un ejemplo de un enfoque descomposicional a la arquitectura. Su objetivo principal es
para descomponer los elementos de software del sistema en componentes y , a continuacin,
asignar requisitos con esos componentes. Tanto la descripcin de la arquitectura del sistema y los
productos de otros puntos de vista en la descripcin de la arquitectura contribuiran a esta actividad
y sus productos. Una descripcin de la arquitectura puede ajustarse a esta norma y la norma ISO /

IEC 12207 . Una forma de " conformidad conjunta" es tener un punto de vista que se centra
especficamente en la produccin de los 12.207 productos arquitectnicos ISO / IEC . Un ejemplo
de un punto de vista para este propsito se define en C.2.2 .
C.2.2 descomposicin y mirador asignacin
La descomposicin y marcos punto de vista de asignacin de estas preocupaciones : _
identificacin de los requisitos del sistema ; _ descomposicin del sistema en objetos ; _ asignacin
de los requisitos de los artculos; _ verificacin de que todos los requisitos se asignan a los
elementos
.
Cada requisito se identifica de forma nica . Si es necesario , los requisitos se descomponen y se
extendieron en los requisitos derivados de proporcionar un conjunto completo de requisitos del
sistema . El sistema se descompone en un conjunto de elementos , donde cada elemento es un
elemento de hardware, un elemento de software o un elemento del manual de operaciones .
Tambin se identifican los interfaces entre los elementos. Requisitos del sistema se asignan a los
elementos , de manera que cada elemento cumple uno o varios requisitos , y cada requisito se
asigna a por lo menos un elemento. La descomposicin inicial y la asignacin produce un conjunto
de elementos con los requisitos asignados . Esto se describe en trminos de un sistema
Descripcin arquitectnico ( vase la norma ISO / IEC 12207:2008 , 6.4.3.3.1 ) . Los elementos de
software iniciales se descomponen en componentes subordinados. Requisitos asignados a cada
elemento de software se asignan adems a uno o ms componentes . Descripciones de interfaz se
proporcionan entre componentes de software , y entre los componentes de software y elementos
de hardware y elementos de operacin manual . Esto se describe en trminos de un software
Descripcin Servicios de arquitectura ( vase la norma ISO / IEC 12207:2008 , 7.1.3.3.1 ) .
C.3 uso con la norma ISO / IEC 15288:2008
C.3.1 general
ISO / IEC 15288:2008 define un proceso especficamente relacionadas con la arquitectura: diseo
arquitectnico. El concepto de arquitectura en esta norma est en consonancia con el proceso de
diseo de la arquitectura de la norma ISO / IEC 15288 . Sin embargo , la norma ISO / IEC 15288
impone requisitos sobre la descripcin arquitectnica , adems de las aqu . Especficamente , un
diseo arquitectnico necesita incluir una identificacin de los elementos del sistema incluidas en el
sistema y una asignacin de los requisitos del sistema a esos artculos . El uso previsto de una
descripcin arquitectnica puede incluir otros procesos de la ISO / IEC 15288 . En particular, una
descripcin arquitectnica puede ser utilizado en actividades distintas de la actividad de diseo de
la arquitectura del sistema para facilitar las comunicaciones entre el adquirente y las funciones de
desarrolladores. Una descripcin de la arquitectura puede ajustarse a esta norma y la norma ISO /
IEC 15288 . Una forma de ' conformidad joint ' es tener un punto de vista que se centra
especficamente en la produccin de los productos arquitectnicos 15288 ISO / IEC . Un ejemplo
de un punto de vista definido para este propsito se define en C.3.2 .
C.3.2
descomposicin
y
mirador
asignacin
La descomposicin y marcos punto de vista de asignacin de estas preocupaciones : _
identificacin de los requisitos del sistema ; _ descomposicin del sistema en objetos ; _ asignacin
de los requisitos de los artculos; _ verificacin de que todos los requisitos se asignan a los
elementos . Cada requisito se identifica de forma nica . Si es necesario , los requisitos se
descomponen y se extendieron en los requisitos derivados de proporcionar un conjunto completo
de requisitos del sistema . El sistema se descompone en un conjunto de elementos . Tambin se
identifican los interfaces entre los elementos . Requisitos del sistema se asignan a los elementos,
de manera que cada elemento cumple uno o varios requisitos , y cada requisito se asigna a por lo
menos un elemento . La descomposicin inicial y la asignacin produce un conjunto de elementos
con los requisitos asignados . Esto se describe en trminos de un software Descripcin Servicios
de arquitectura ( vase la norma ISO / IEC 15288:2008 , 6.4.3.3 ( c ) ) .
C.4 Uso de las normas de proceso abierto distribuido

C.4.1 general
El modelo de referencia de procesamiento distribuido abierto ( RM- ODP) define un marco de
arquitectura para los sistemas de procesamiento distribuido , " . En que los componentes discretos
pueden ser ubicados en lugares diferentes, o cuando la comunicacin entre los componentes
pueden sufrir retraso o puede fallar " sistemas ( vase la Norma ISO / IEC 10746-2 . ) El marco de
RM-ODP define cinco puntos de vista para especificar los sistemas de PAO y un conjunto de
correspondencias entre ellos . Para cada punto de vista , hay un punto de vista idioma asociado
que define " los conceptos y las reglas para la especificacin de sistemas de PAO desde el punto
de vista correspondiente " . Una descripcin de la arquitectura conforme con esta Norma
Internacional y con la norma ISO / IEC 10746-3 incluira los puntos de vista definidos por la norma
ISO / IEC 10746-3 y vistas a poner en prctica estos puntos de vista . Una descripcin de la
arquitectura conforme no tiene por qu limitarse a los cinco puntos de vista predefinidos de la
norma ISO / IEC 10746-3 , la descripcin de la arquitectura puede incluir puntos de vista y las
opiniones adicionales , segn sea necesario. Los elementos de esa especificacin concreta a las
descripciones de arquitectura (como actores ) se omiten aqu, ya que son particulares a los
sistemas individuales. Salvo que se indique , todos los contenidos son citas directas o cercanas
parfrasis de ISO / IEC 10746-3:1996 . NOTA La Norma ISO / IEC 19793 define un perfil UML para
la especificacin de los sistemas de procesamiento distribuido abierto con estos puntos de vista .
C.4.2 punto de vista empresarial
Los marcos mirador Enterprise estas preocupaciones : _ el propsito , el alcance y las polticas
para un sistema ODP ; _ funciones desempeadas por el sistema; _ las actividades realizadas por
el sistema; _ declaraciones de poltica sobre el sistema . En la empresa Language , un sistema
ODP y su entorno se representan como una comunidad de objetos. La comunidad se define en
trminos de: _ objetos empresariales que comprenden la comunidad ; _ funciones desempeadas
por cada uno de esos objetos ; _ polticas que rigen las interacciones entre objetos de empresa que
cumplen papeles , papeles _ polticas que rigen la creacin , uso y eliminacin de los recursos por
los objetos empresariales que cumplan ; _ polticas que rigen la configuracin de objetos de
empresa y la asignacin de funciones a los objetos de empresa ; _ las polticas relativas a los
contratos de medio ambiente que rigen el sistema . NOTA 1 Roles restringen el comportamiento de
los objetos que las cumplan . NOTA 2 Las polticas se definen en trminos de permisos ,
obligaciones y prohibiciones. NOTA 3 La Empresa El lenguaje se define en la norma ISO / IEC
15414.

C.4.3 mirador Informacin


Los marcos mirador Informacin estas preocupaciones : la semntica de la informacin y
procesamiento de la informacin en un sistema ODP . La informacin del idioma se define en
trminos de los tres esquemas : _ esquema invariante : predicados en los objetos que siempre
tienen que ser verdad ; _ esquema esttico : estado de uno o varios objetos en un cierto punto en
el tiempo; _ esquema dinmico : los cambios de estado permitidos de uno o ms objetos .
C.4.4 punto de vista computacional
Los marcos punto de vista computacional estas preocupaciones : una descomposicin funcional
del sistema en objetos que interactan en las interfaces . El lenguaje computacional abarca
conceptos para especificar : _ objetos computacionales ; _ interfaces con objetos y definiciones de
interfaz ; _ interacciones en las interfaces , ya sea como operaciones o flujos continuos ; _ enlaces
implcitos y explcitos y objetos compuestos de unin .
C.4.5 punto de vista de ingeniera

Los marcos punto de vista de ingeniera estas preocupaciones : los mecanismos y funciones
necesarias para apoyar la interaccin distribuida entre objetos en el sistema. La Ingeniera Idioma
incluye conceptos para especificar : _ configuraciones de objetos de ingeniera para fines de
gestin , incluyendo nodos (por recursos ) , cpsulas ( de proteccin) y clusters ( para la
activacin ) ; _ la estructura de canales de comunicacin que conectan objetos de ingeniera , en
trminos de talones , aglutinantes, protocolos e interceptores ; _ plantillas para proporcionar
transparencias requeridos, tales como la migracin , la deslocalizacin , la replicacin y la
insuficiencia transparencias
.
C.4.6 mirador Tecnologa
Los marcos mirador Tecnologa estas inquietudes: la seleccin de las normas realizables para el
sistema, su implementacin y pruebas. The Language Technology incluye conceptos a : _ capturar
la eleccin de la tecnologa a utilizar, en cuanto a la seleccin de las normas vigentes o las
especificaciones de dominio especfico para estas tecnologas ; _ expresa cmo se implementan
las especificaciones de un sistema ODP ; _ prestar apoyo a pruebas .