Realizar la lectura a la ISO/IEC 42010, en cipas presentar un ensayo, éste debe contener la

contextualización del tema de acuerdo al texto, se formula una pregunta o hipótesis y llegar a unas
conclusiones.

La norma internacional ISO/IEC 42010:2007(E) ISO (Organización Internacional de Normalización) y

IEC (Comisión Electrotécnica Internacional) forman el sistema especializado para la normalización
mundial. Los órganos nacionales que son miembros de la ISO o de la CEI participan en la
elaboración de las Normas Internacionales por conducto de comités técnicos establecidos por la
organización respectiva para ocuparse de determinadas esferas de actividad técnica. Los comités
técnicos de la ISO y la CEI colaboran en esferas de interés mutuo. Otras organizaciones
internacionales, gubernamentales y no-gubernamentales, en coordinación con la ISO y la CEI,
también participan en los trabajos. En la esfera de la tecnología de la información, la ISO y la CEI
han establecido un comité técnico conjunto, la ISO/CEI JTC 1. Tecnología de la información,
Subcomité SC 7, Software e ingeniería de sistemas, en paralelo a su aprobación por los órganos
nacionales de la ISO y la CEI. La IEEE Computer Society cooperará en el mantenimiento de esta
norma internacional como enlace de categoría A con SC 7.

Los documentos de Normas IEEE se desarrollan dentro de las Sociedades IEEE y los Comités de
Coordinación de Estándares de la Asociación de Estándares IEEE-SA (IEEE-SA). Miembros de los
comités con carácter evolutivo y sin indemnización. No son necesariamente miembros del
Instituto. Las normas promocionadas en el IEEE representan un consenso de los amplios
conocimientos especializados sobre el tema en el Instituto, así como las actividades fuera del IEEE
que han expresado interés en participar en el desarrollo de la norma

El uso de una norma IEEE es totalmente voluntario. La existencia de una norma IEEE no implica
que no existan otras formas de producir, probar, medir, comprar, comercializar o prestar otros
bienes y servicios relacionados con el ámbito de aplicación de la norma IEEE. Además, el punto de
vista expresado en el momento de aprobar y rechazar una norma está sujeto a cambios
provocados por la evolución del estado de la técnica y los comentarios recibidos de los usuarios de
la norma. Cada norma IEEE se somete a revisión al menos cada cinco años para su revisión o
reafirmación. Cuando un documento tiene más de cinco años y no se ha reafirmado, es rea-
sonable concluir que su contenido, aunque todavía de cierto valor, no refleja totalmente el estado
actual del arte. Se advierte a los usuarios que comprueben que tienen la última edición de
cualquier norma IEEE.

Los comentarios para la revisión de las Normas IEEE son bienvenidos de cualquier parte
interesada, independientemente de la afiliación de miembros con IEEE. Las sugerencias de
cambios en los documentos deben revestir la forma de un cambio propuesto de alcance, junto con
las observaciones de apoyo apropiadas.

Interpretaciones: De vez en cuando pueden surgir preguntas sobre el significado de las partes de
las normas como su relación con aplicaciones específicas. Cuando se señale a la atención del IEEE
la necesidad de interpretaciones, el Instituto iniciará acciones para preparar respuestas
apropiadas. Dado que las Normas IEEE representan un consenso de todos los intereses
interesados, es importante asegurarse de que cualquier interpretación también ha recibido la
concurrencia de intereses abalance. Por esta razón, la IEEE y los miembros de sus sociedades y
comités de coordinación de normas no pueden dar una respuesta instantánea a las solicitudes de
interpretación, salvo en los casos en que la cuestión haya sido objeto de un examen formal.

Los comentarios sobre las normas y solicitudes de interpretaciones deben dirigirse a:

Secretario, IEEE-SA Standards Board

445 hoes Lane

P.O. Box 1331

Piscataway, NJ 08855-1331

USA

Nota: Se llama la atención sobre la posibilidad de que la implementación de esta norma requiera
el uso de la materia cubierta por los derechos de patente. Mediante la publicación de esta norma,
no se toma ninguna posición con respecto a la existencia o validez de ningún derecho de patente
en relación con la misma. El IEEE no será responsable de identificar las patentes para las cuales
una licencia puede ser exigida por un estándar de IEEE o para realizar consultas sobre la validez
legal o el alcance de aquellas patentes que se señalan a su atención.

IEEE es la única entidad que puede autorizar el uso de marcas de certificación, marcas comerciales
u otras denominaciones para indicar el cumplimiento de los materiales aquí establecidos.

IEEE Introducción

Durante mucho tiempo se ha reconocido que la "arquitectura" tiene una fuerte influencia sobre el
ciclo de vida de un sistema. En el pasado, los aspectos arquitectónicos del hardware-relacionados
eran dominantes, mientras que la integridad arquitectónica del software-relacionada, cuando
existió, fue a menudo sacrificada primero en el curso del desarrollo del sistema. Hoy en día, los
sistemas software-intensivos son omnipresentes. El coste del desarrollo de software y la creciente
complejidad de los sistemas informáticos han modificado el equilibrio relativo. La tecnología del
software está madurando rápidamente. La práctica del desarrollo del sistema puede beneficiarse
enormemente de la adhesión a los preceptos arquitectónicos.

Sin embargo, los conceptos de arquitectura no han sido definidos y aplicados sistemáticamente
dentro del ciclo de vida de los sistemas software-intensivos. A pesar de la importante actividad
industrial y de investigación en este ámbito, no existe un marco único y aceptado para codificar el
pensamiento arquitectónico, facilitando así la aplicación común y la utilización común de las
prácticas arquitectónicas disponibles y emergentes.

El Grupo de Planificación de Arquitectura (APG) del IEEE se constituyó en agosto de 1995 para
atender esta necesidad. El APG fue fletado por el Comité de Normas de Ingeniería de Software
(SESC) del IEEE para establecer una dirección para el pensamiento arquitectónico de la
incorporación en las normas del IEEE. El resultado de las deliberaciones de la APG fue recomendar
una actividad IEEE con los siguientes objetivos:

- definir términos, principios y directrices útiles para la aplicación coherente de preceptos

arquitectónicos a los sistemas a lo largo de su ciclo de vida
- elaborar preceptos arquitectónicos y sus beneficios previstos para los productos de
software, sistemas, y sistemas agregados (i.e., "sistemas de sistemas")
- proporcionar un marco para la colisión y consideración de atributos arquitectónicos e
información relacionada para su uso en normas IEEE
- proporcionar una hoja de ruta útil para la incorporación de preceptos arquitectónicos en
la generación, Revisión y aplicación de las normas IEEE

En abril de 1996, la SESC creó el Grupo de Trabajo de Arquitectura (GTE) para aplicar esas
recomendaciones.

Práctica recomendada por IEEE para la descripción arquitectónica de sistemas intensivos-software

1. Descripción
1.1 Alcance

Esta práctica recomendada aborda la descripción arquitectónica de los sistemas software-

intensivos. El sistema Asoftware-intensivo es cualquier sistema donde el software contribuye
influencias esenciales al diseño, construcción, despliegue y evolución del sistema en su conjunto.
El alcance de esta práctica recomendada abarca los productos de desarrollo de sistemas que
captan información arquitectónica. Esto incluye descripciones arquitectónicas que se utilizan para
lo siguiente:

a) Presión del sistema y su evolución.

b) Comunicación entre los actores del sistema.

c) Evaluación y comparación de arquitecturas de manera consistente.

d) Planificación, gestión y ejecución de las actividades de desarrollo del sistema.

e) Expresión de las características persistentes y principios de apoyo de un sistema para guiar el

cambio aceptable

f) Verificación del cumplimiento de una implementación del sistema con una descripción
arquitectónica.

g) Registro de las contribuciones al cuerpo de conocimiento de la arquitectura de sistemas de

software intensivo.

1.2 Propósito
El propósito de esta práctica recomendada es facilitar la expresión y la comunicación de las
arquitecturas y, por lo tanto, sentar las bases de la calidad y el aumento de los costos mediante la
estandarización de elementos y prácticas para la descripción de la arquitectura.

A pesar de los esfuerzos significativos para mejorar las prácticas y tecnologías de ingeniería, el
sistema de software intensivo continúa presentando riesgos y dificultades formidables en su
diseño, construcción, implementación y evolución. Los intentos recientes de abordar estas
dificultades se han centrado en el primer período de toma de decisiones y evaluación de diseño,
Cada vez más referido como el nivel arquitectónico del desarrollo del sistema. Las frases nivel
arquitectónico y arquitectura son ampliamente utilizadas, aunque de manera imprecisa. Su uso
refleja la aceptación de una metáfora arquitectónica en el análisis y desarrollo de sistemas de
software intensivo. Una premisa clave de esta metáfora es que se pueden tomar decisiones
importantes al principio del desarrollo del sistema de una manera similar a la toma de decisiones
temprana que se encuentra en el desarrollo de proyectos de arquitectura civil.

Muchas innovaciones se derivan de esta atención al nivel arquitectónico, entre ellos los lenguajes
de descripción arquitectónica y las herramientas y entornos asociados; Marcos arquitectónicos,
modelos, y patrones. Y técnicas para el análisis arquitectónico, la evaluación y la reutilización
basada en la arquitectura. Si bien estos esfuerzos difieren considerablemente en aspectos
importantes, existen puntos en común suficientes para justificar el desarrollo de una práctica
recomendada para codificar sus elementos comunes.

Estas innovaciones se están produciendo y están madurando rápidamente en muchas

comunidades de investigación y aplicación, y reflejan diferentes intereses, influencias, ideas e
intenciones. Existe un consenso general sobre la importancia del nivel arquitectónico del
desarrollo de sistemas, y ese nivel consiste en una toma de decisiones temprana sobre la
estructura de diseño general, los objetivos, los requisitos y las estrategias de desarrollo. Sin
embargo, aún no ha surgido ningún consenso confiable sobre una definición precisa de la
arquitectura de un sistema, es decir, cómo debe describirse, qué usos puede servir esa descripción
o dónde y cuándo debe definirse. Los límites y las relaciones entre las tendencias y prácticas
arquitectónicas y otras prácticas; y entre la tecnología arquitectónica y otras tecnologías, todavía
no están ampliamente reconocidas.

En tales situaciones, el progreso a menudo depende de influencias mediadoras. Los adoptantes

potenciales de las prácticas y tecnología arquitectónicas necesitan un marco de referencia dentro
del cual abordar las decisiones de implementación y adopción. Los desarrolladores de tecnología
necesitan un marco de referencia dentro del cual puedan comunicar los conceptos motivadores de
su tecnología y acumular y apreciar los comentarios de una adopción temprana.

Con estos fines, esta práctica recomendada pretende reflejar tendencias generalmente aceptadas
en las prácticas para la descripción de la arquitectura y proporcionar un marco técnico para una
mayor evolución en esta área. Además, establece un marco conceptual de conceptos y términos
de referencia dentro de los cuales los futuros desarrollos en sistemas arquitectónicos La
tecnología puede ser desplegada. Esta práctica recomendada codifica aquellos elementos sobre
los cuales hay consenso; específicamente el uso de múltiples vistas, especificaciones reutilizables
para modelos dentro de vistas y la relación de la arquitectura con el contexto del sistema.

1.3 Usuarios previstos

La clase principal de usuarios para esta práctica recomendada comprende partes interesadas en el
desarrollo y la evolución del sistema, incluidos los siguientes: - Aquellos que usan, poseen y
adquieren el sistema (usuarios, operadores y adquirentes, o clientes) - Aquellos que desarrollan,
describen y arquitecturas de documentos (arquitectos): aquellas que desarrollan, entregan y
mantienen el sistema (arquitectos, diseñadores, programadores, mantenedores, evaluadores,
ingenieros de dominio, personal de control de calidad, personal de administración de la
configuración, proveedores y gerentes o desarrolladores de proyectos) - Aquellos que supervisan y
evalúan los sistemas y su desarrollo (directores de información, auditores y asesores
independientes) Una clase secundaria de usuarios de esta práctica recomendada comprende
aquellos involucrados en las actividades de infraestructura de toda la empresa que abarcan
múltiples desarrollos de sistemas, incluidos metodólogos, procesos e Ingenieros, investigadores,
productores de estándares, constructores de herramientas y capacitadores en pro de la mejora del
proceso.

1.4 Conformidad con esta práctica recomendada

Una descripción arquitectónica se ajusta a esta práctica recomendada si esa descripción cumple
con los requisitos enumerados en la Cláusula 5.

2. Referencias Esta práctica recomendada se utilizará junto con las siguientes publicaciones.
Cuando se reemplacen los estándares siguientes por una revisión aprobada, se aplicará la revisión.
PEEE 610.12−1990, Glosario IEEE estándar de terminología de ingeniería de software.1IEEE / EIA
Std 12207.0−1996, Estándar IEEE / EIA: Implementación industrial de ISO / IEC 12207: 1995,
Tecnología de la información — Procesos del ciclo de vida del software.

3. Definiciones Para los fines de esta norma, se aplican los siguientes términos y definiciones. El
Diccionario Estándar IEEE de Términos Eléctricos y Electrónicos [B2], 2 IEEE Std 610.12−1990, o
IEEE / EIA Std 12207.0−1996 debe ser referenciado para términos no definidos en esta cláusula.

3.1 adquirente: Una organización que adquiere un sistema, un producto de software, o servicio de
software de un proveedor. (El comprador puede ser un comprador, cliente, propietario, usuario o
comprador).

3.2 arquitecto: la persona, equipo u organización responsable de la arquitectura de sistemas.

3.3 Arquitectura: las actividades de definir, documentar, mantener, mejorar y certificar la

implementación adecuada. De una arquitectura.

3.4 descripción arquitectónica (AD): una colección de productos para documentar una
arquitectura.
3.5 arquitectura: la organización fundamental de un sistema incorporado en sus componentes, sus
relaciones entre sí y con el medio ambiente, y los principios que guían su diseño y el modelo de
ciclo de vida evolutivo.

3.6: un marco que contiene los procesos, actividades y tareas involucradas en el desarrollo,
operación y mantenimiento de un producto de software, que abarca la vida útil del sistema desde
la definición de sus requisitos hasta La terminación de su uso. Sistema

3.7: una colección de componentes organizados para cumplir una función específica o un
conjunto de funciones.

3.8 partes interesadas del sistema: Un individuo, equipo u organización (o clases del mismo) con
intereses o inquietudes relacionadas con una vista de sistema.

3.9: Una representación de todo un sistema desde la perspectiva de un conjunto de inquietudes

relacionadas.

3.10 punto de vista: Especificación de las convenciones para construir y usar una vista. Un patrón o
plantilla a partir del cual desarrollar vistas individuales mediante el establecimiento de los
propósitos y la audiencia de una vista y las técnicas para su creación y análisis.

4. Marco conceptual Esta cláusula introduce un marco conceptual, o marco de referencia, para la
descripción arquitectónica. El marco establece términos y conceptos relacionados con el
contenido y el uso de las descripciones arquitectónicas. Estos términos y conceptos se utilizarán
en cláusulas subsiguientes.

4.1 Descripción arquitectónica en contexto Para los fines de esta práctica recomendada, el
término sistema abarca aplicaciones individuales, sistemas en el Sentido tradicional, subsistemas,
sistemas de sistemas, líneas de productos, familias de productos, empresas enteras y otras
agregaciones de interés. Un sistema habita un entorno. El entorno de un sistema puede influir en
ese sistema. El entorno, o contexto, determina el entorno y las circunstancias de las influencias de
desarrollo, operacionales, políticas y otras sobre ese sistema. El entorno puede incluir otros
sistemas que interactúan con el sistema de interés, ya sea directamente a través de interfaces o
indirectamente de otras maneras. El entorno determina los límites que definen el alcance del
sistema de interés en relación con otros sistemas. Un sistema tiene una o más partes interesadas.
Cada parte interesada generalmente tiene intereses o preocupaciones relacionadas con ese
sistema. Las preocupaciones son aquellos intereses que se relacionan con el desarrollo del
sistema, su funcionamiento o cualquier otro aspecto que sea crítico o importante para una o más
partes interesadas. Las inquietudes incluyen consideraciones del sistema, como el rendimiento, la
confiabilidad, la seguridad, la distribución y la capacidad de evolución. Existe un sistema para
cumplir una o más misiones en su entorno. Una misión es un uso u operación para la cual un
sistema está diseñado por una o más partes interesadas para cumplir con un conjunto de
objetivos. Cada sistema tiene una arquitectura, en los términos de esta práctica recomendada.
Una arquitectura puede estar grabada por una descripción arquitectónica (ver Figura 1). Esta
práctica recomendada distingue la arquitectura de un sistema, que es conceptual, de las
descripciones particulares de esa arquitectura, que son productos o artefactos concretos. Las
descripciones arquitectónicas (AD) son el tema de esta práctica recomendada. En el marco
conceptual de esta práctica recomendada, una descripción arquitectónica se organiza en uno o
más constituyentes llamados vistas (arquitectónicas). Cada vista aborda una o más de las
preocupaciones de los interesados del sistema. El término vista se usa para referirse a la expresión
de la arquitectura de un sistema con respecto a un punto de vista particular.

NOTA: Esta práctica recomendada no usa términos como arquitectura funcional, arquitectura
física y arquitectura técnica, como se usa con frecuencia de manera informal. En el marco
conceptual de la práctica recomendada, los equivalentes aproximados de estos términos
informales serían vista funcional, vista física y vista técnica, respectivamente. Otra información, no
contenida en ninguna vista constituyente, puede aparecer en un AD, como resultado de una
Prácticas de documentación de la organización. Ejemplos de dicha información son la descripción
general del sistema, el contexto del sistema, las partes interesadas del sistema y sus inquietudes
clave, y el fundamento arquitectónico. Un punto de vista establece las convenciones mediante las
cuales se crea, describe y analiza una vista. De esta manera, se ajusta a un punto de vista. El punto
de vista determina los idiomas (incluidos los tipos de notación, modelo o producto) que se
utilizarán para describir la vista, y cualquier método de modelado asociado o las técnicas de
análisis que se deben utilizar aplicado a estas representaciones de la vista. Estos lenguajes y
técnicas se utilizan para obtener resultados relevantes para las inquietudes abordadas por el
punto de vista. Una descripción arquitectónica selecciona uno o más puntos de vista para su uso.
La selección de puntos de vista generalmente se basará en la consideración de las partes
interesadas a quienes se dirige el AD y sus inquietudes. Una definición del punto de vista puede
originarse con un AD, o puede haber sido definida en otro lugar. En esta práctica recomendada se
hace referencia a un punto de vista que se define en otra parte como un punto de vista de
biblioteca. Una vista puede consistir en uno o más modelos arquitectónicos. Cada uno de estos
modelos arquitectónicos se desarrolla utilizando los métodos establecidos por su punto de vista
arquitectónico asociado. Un modelo arquitectónico puede participar más de una vista.

NOTA: En un sistema complejo, los AD pueden desarrollarse para los componentes del sistema, así
como para el sistema como un todo. En este caso, puede ser que un AD tenga una vista
correspondiente a un punto de vista particular y otro AD tendrá una vista correspondiente al
mismo punto de vista. Aunque el sistema descrito por estas dos vistas tiene una relación entre la
parte integral, esto no es una instancia de múltiples vistas correspondientes a un punto de vista.
Los AD se consideran separados aunque estén relacionados por los sistemas que describen.
NOTA: la Figura 1 proporciona un resumen informativo de los conceptos clave introducidos por
esta práctica recomendada y sus interrelaciones. La figura presenta estos conceptos en el contexto
de una arquitectura para un sistema particular y una descripción arquitectónica asociada. Esto no
implica ni requiere que un sistema tenga una sola arquitectura o que solo haya una descripción de
la arquitectura que describa esa arquitectura. En la figura, los cuadros representan clases de cosas.
Las líneas que conectan cuadros representan asociaciones entre cosas. Una asociación tiene dos
roles (uno en cada dirección). Un rol se puede nombrar opcionalmente con una etiqueta. El rol de
A a B es el más cercano a B, y viceversa. Por ejemplo, las funciones entre SISTEMA y MEDIO
AMBIENTE pueden leerse: un SISTEMA habita en un AMBIENTE y un AMBIENTE influye en un
SISTEMA. En la figura, los roles son uno a uno a menos que se indique lo contrario. Un rol puede
tener una multiplicidad, por ejemplo, un rol marcado con "1... *" se usa para denotar muchos,
como en una asociación de uno a muchos o de muchos a muchos. Un diamante (al final de una
línea de asociación) denota una parte de la relación. Por ejemplo, VIEWS es parte de una
ARCHITECTURALDESCRIPTION. Esta nota es de la Especificación del lenguaje de modelado
unificado [B5].
4.2 Grupos de interés y sus roles Los titulares de cargos tienen varios roles con respecto a la
creación y el uso de descripciones arquitectónicas. Los interesados incluyen clientes, usuarios,
arquitectos, desarrolladores y evaluadores. Dos roles clave entre los interesados son el comprador
(o cliente) y el arquitecto. El arquitecto desarrolla y mantiene una arquitectura para que un
sistema satisfaga al adquirente. El arquitecto puede trabajar a partir de los requisitos
proporcionados por un adquirente o puede ser responsable de obtener y desarrollar requisitos
como parte del desarrollo de la arquitectura. El rol de la adquirente puede ser desempeñado por
un comprador, cliente, propietario, usuario o comprador (consulte IEEE / EIA Std 12207.0−19963).
El rol del arquitecto puede ser ocupado por diferentes personas, equipos u organizaciones a lo
largo del ciclo de vida de la arquitectura. El arquitecto registra la arquitectura para los interesados
del sistema en forma de una descripción arquitectónica. De esta forma, la arquitectura sirve para
guiar a los desarrolladores del sistema.

4.3 Actividades arquitectónicas en el ciclo de vida La arquitectura contribuye al desarrollo, la

operación y el mantenimiento de un sistema desde su concepto inicial hasta su retiro del uso.
Como tal, la arquitectura se entiende mejor en un contexto de ciclo de vida, no simplemente como
una actividad única en un punto de ese ciclo de vida. La arquitectura se refiere al desarrollo de
conceptos de sistemas satisfactorios y viables, manteniendo la integridad de esos conceptos de
sistemas a través del desarrollo, certificando sistemas construidos para use y asegure estos
conceptos de sistemas a través de fases operativas y evolutivas. Las actividades detalladas de
ingeniería de sistemas, como la definición detallada de requisitos y la especificación de la interfaz
y la arquitectura de los subsistemas principales son tareas que generalmente siguen el desarrollo
de la arquitectura del sistema. Esta práctica recomendada no asume ni prescribe una vida
específica modelo de ciclo: un modelo de ciclo de vida debe ser elegido por separado por los
usuarios de la práctica recomendada. Los escenarios en 4.3.1–4.3.4 están destinados a sugerir el
rango de usos de la práctica recomendada dentro del ciclo de vida del sistema.

4.3.3.1 Escenario: arquitectura de sistemas únicos Para la construcción de nuevos sistemas, en los
casos en que el usuario y el adquirente son idénticos La arquitectura se lleva a cabo en respuesta a
la visión del sistema, los objetivos del sistema y las necesidades y limitaciones de los interesados.
Las principales partes interesadas son el usuario adquirente y los desarrolladores del sistema. La
descripción arquitectónica se puede utilizar a lo largo del ciclo de vida para predecir la idoneidad
para el uso de un sistema cuya arquitectura se ajuste a la descripción arquitectónica. Además, el
AD normalmente evolucionará a lo largo del ciclo de vida y, por lo tanto, puede actuar como un
medio para evaluar los cambios en el sistema.

4.3.2 Escenario: arquitectura iterativa para sistemas evolutivos. Bajo este escenario, la
arquitectura, los sistemas entregados y las partes interesadas co evolucionan. Se prepara una
arquitectura inicial en respuesta a las necesidades actuales y esperadas de los usuarios utilizando
capacidades tecnológicas actuales y estimadas. Los sistemas iniciales se entregan utilizando esta
arquitectura. A medida que la arquitectura evoluciona en respuesta a las necesidades de los
interesados, los sistemas se entregan en función de la arquitectura actual en el momento del
desarrollo. Asimismo, el conjunto de interesados en los sistemas y la arquitectura cambiará a
medida que la arquitectura evolucione. Para los sistemas evolutivos, la descripción arquitectónica
se utiliza para el desarrollo y evaluación del sistema, pero sus usos y desarrollo son concurrentes.
Las necesidades de los interesados se reevalúan con cada iteración de la arquitectura; el AD se usa
para guiar cada sistema a medida que avanza a través del desarrollo, y las versiones AD adecuadas
se usan para evaluar cada sistema en la entrega. Las arquitecturas desarrolladas en este escenario,
naturalmente, harán que la flexibilidad y la adaptabilidad sean más importantes que las
arquitecturas de un solo sistema. Las descripciones arquitectónicas de los sistemas en evolución se
desarrollarán típicamente en un patrón iterativo, o ritmo, de cambios de versión. El desarrollo de
la arquitectura normalmente lo llevará a cabo el desarrollador como parte de la actividad general
de desarrollar una secuencia de sistemas. El comprador también puede establecer la arquitectura
como una forma de organizar la adquisición y evolución de una secuencia de sistemas. Este
enfoque es una forma de evolucionar una arquitectura de línea de producto. La evolución de la
arquitectura normalmente será patrocinada por el adquirente como parte de la actividad general
de desarrollo secuencial o, en el caso de software comercial, despliegue de sistemas.

4.3.3 Escenario: arquitectura de sistemas existentes. Se produce un tercer escenario. Cuando el

desarrollo del sistema ha tenido lugar sin una descripción arquitectónica, o cuando el AD, y quizás
el arquitecto, ya no están disponibles. El sistema construido tendrá una arquitectura (ya que cada
sistema tiene una arquitectura, ya sea conocida o no) pero carecerá de una descripción
arquitectónica. En este caso, se puede crear un AD a través de un esfuerzo de ingeniería inversa.
Con esta práctica recomendada, un la descripción arquitectónica del sistema existente se
construye por primera vez. Este AD se usa luego para desarrollar un nuevo sistema, para guiar
actividades de mantenimiento o evolución, o para establecer una arquitectura evolutiva como en
los escenarios anteriores (ver 4.3.1 y 4.3.2). En algunos casos, se necesita una nueva AD porque la
descripción original no proporciona vistas que son necesarias más adelante en el ciclo de vida de
un sistema.

4.3.4 Escenario: evaluación arquitectónica El propósito de la evaluación es determinar la calidad

de una descripción arquitectónica y predecir La calidad de los sistemas cuyas arquitecturas se
ajustan a la descripción arquitectónica. La calidad de una descripción arquitectónica se refiere a su
capacidad para satisfacer las necesidades y preocupaciones de los interesados en quien fue
construido. Estas inquietudes suelen incluir comprensibilidad, consistencia, plenitud y capacidad
de análisis de la descripción. La predicación de la calidad de los sistemas resultante de la
descripción arquitectónica incluye tales cualidades como factibilidad, eficiencia y confiabilidad.
Para evaluar la conformidad de una arquitectura a una arquitectura Descripción, se necesita un
proceso para revertir la ingeniería de una descripción arquitectónica de una implementación (ver
4.3.3).

4.4 Usos de las descripciones arquitectónicas Las descripciones arquitectónicas son aplicables a
una variedad de usos, por parte de una variedad de partes interesadas, a lo largo del ciclo de vida.
Estos usos incluyen, pero no se limitan a lo siguiente:

a) Análisis de arquitecturas alternativas.

b) Planificación comercial para la transición de una arquitectura heredada a una nueva
arquitectura

c) Comunicaciones entre organizaciones involucradas en el desarrollo, producción, puesta en

campo, operación y mantenimiento de un sistema.

d) Comunicaciones entre adquirentes y desarrolladores como parte de las negociaciones del

contrato.

e) Criterios para certificar la conformidad de las implementaciones a la arquitectura.

f) Documentación de desarrollo y mantenimiento, incluido material para reutilizar repositorios y

materiales de capacitación.

g) Entrada a las actividades posteriores de diseño y desarrollo del sistema.

h) Entrada a herramientas de generación y análisis de sistemas.

i) Apoyo operacional y de infraestructura; gestión de configuración y reparación; rediseño y

mantenimiento de sistemas, subsistemas y componentes

j) Planificación y apoyo presupuestario.

k) Preparación de documentos de adquisición (por ejemplo, solicitudes de propuestas y

declaraciones de trabajo)

l) Revisión, análisis y evaluación del sistema a lo largo del ciclo de vida.

m) Especificación para un grupo de sistemas que comparten un conjunto común de características

(por ejemplo, líneas de productos

5. Prácticas de descripción arquitectónica. Esta cláusula define las prácticas de descripción

arquitectónica que permiten los usos descritos en 4.4. Una descripción arquitectónica conforme a
esta práctica recomendada cumple con los requisitos establecidos en esta cláusula. Las
descripciones arquitectónicas de conformación incluyen los siguientes elementos (como se
describe en el resto de esta cláusula):

a) Identificación de AD, versión e información general (ver 5.1)

b) Identificación de las partes interesadas del sistema y sus inquietudes que se consideran
relevantes para la arquitectura (ver 5.2)

c) Especificaciones de cada punto de vista que se ha seleccionado para organizar la representación

de la arquitectura y la justificación de esas selecciones (ver 5.3)

d) Una o más vistas arquitectónicas (ver 5.4)

e) Un registro de todas las inconsistencias conocidas entre los componentes requeridos de la
descripción arquitectónica (ver 5.5)

f) Una justificación para la selección de la arquitectura (ver 5.6)

NOTA: esta práctica recomendada no especifica un formato de entrega para una descripción
arquitectónica.

5.1 Documentación arquitectónica. Un AD deberá contener la siguiente información relativa al AD

en su conjunto:

a) Fecha de emisión y estado.

b) organización emisora

c) cambiar la historia

d) Resumen

e) Alcance

f) contexto

g) Glosario

h) Referencias

La forma detallada y el contenido de los ítems de información correspondientes se determinarán

por la organización de uso. Estos elementos fueron seleccionados para permitir que los usuarios
cumplan con los requisitos de IEEE / EIA Std 12207.0–1996.

5.2 Identificación de las partes interesadas e inquietudes

Un anuncio debe identificar a las partes interesadas consideradas por el arquitecto al formular el
concepto arquitectónico para el sistema. Como mínimo, las partes interesadas identificadas deben
incluir lo siguiente:

a) Usuarios del sistema.

b) Adquirentes del sistema.

c) Desarrolladores del sistema.

d) Mantenedores del sistema

Un anuncio identificará las preocupaciones consideradas por el arquitecto al formular el concepto

arquitectónico para el sistema.

Como mínimo, las inquietudes identificadas deben incluir lo siguiente:

El propósito o misiones del sistema.

- Lo apropiado del sistema para usarlo en el cumplimiento de sus misiones.

- La viabilidad de construir el sistema.

- Los riesgos del desarrollo y operación del sistema para los usuarios, compradores y
desarrolladores del sistema.

- Mantenibilidad, implementabilidad y evolvibilidad del sistema.

La intención específica de los términos misión, adecuación y viabilidad variará de un sistema a

otro. Un anuncio especificará más detalladamente las preocupaciones identificadas en el contexto
del sistema de interés.

5.3 Selección de puntos de vista arquitectónicos.

Un anuncio debe identificar los puntos de vista seleccionados para su uso en el mismo.

Cada punto de vista deberá ser especificado por:

a) Un nombre de punto de vista

b) Las partes interesadas a ser abordadas por el punto de vista.

c) Las inquietudes a ser abordadas por el punto de vista.

d) El lenguaje, las técnicas de modelado o los métodos analíticos que se utilizarán para construir
una vista basada en el punto de vista

e) La fuente, para el punto de vista de una biblioteca (la fuente podría incluir el autor, la fecha o la
referencia a otros documentos, según lo determine la organización que lo utilice). Una
especificación del punto de vista puede incluir información adicional sobre las prácticas
arquitectónicas asociadas con el uso del punto de vista, como sigue:

- Pruebas de coherencia e integridad formales o informales que se aplicarán a los modelos que
conforman una vista asociada.

- Técnicas de evaluación o análisis a aplicar a los modelos.

- Heurísticas, patrones u otras pautas para ayudar a sintetizar una vista asociada

Las especificaciones de los puntos de vista pueden incorporarse por referencia (por ejemplo, a una
práctica recomendada adecuada o una práctica previamente definida).

Un AD incluirá una justificación para la selección de cada punto de vista. El razonamiento deberá
abordar la medida en que los puntos de vista seleccionados bajo esta cláusula cubren a las partes
interesadas y las inquietudes requeridas en 5.2.
NOTA: La práctica recomendada no requiere que ningún punto de vista en particular sea
seleccionado por una descripción arquitectónica. Sin embargo, la justificación para la selección de
los puntos de vista muestra que los puntos de vista seleccionados cubren el mínimo conjunto de
partes interesadas y preocupaciones requeridas en 5.2.

Cada parte interesada y cada inquietud identificada en un AD de acuerdo con 5.2 deben ser
abordadas por al menos un punto de vista seleccionado de acuerdo con 5.3. Una parte interesada
o una inquietud puede ser abordada por más de un punto de vista en una descripción
arquitectónica.

NOTAS:

1: Se prevé que a través de la selección de puntos de vista adecuados, un anuncio puede lograr
conformidad con otros estándares de desarrollo o arquitectura.

.2 — El Anexo C y el Anexo D contienen ejemplos de puntos de vista y especificaciones de puntos

de vista

5.4 Vistas arquitectónicas:

Un anuncio deberá contener una o más vistas arquitectónicas.

Cada vista en un anuncio debe corresponder exactamente a un punto de vista, según lo

seleccionado de acuerdo con 5.3.

Cada vista en un anuncio se ajustará a la especificación de su punto de vista correspondiente.

Cada vista incluirá:

a) Un identificador y otra información introductoria, según lo definido por la organización usuaria

b) Representación del sistema construido con los lenguajes, métodos y técnicas de modelado o
analíticas del punto de vista asociado.

c) Información de configuración, según lo definido por la organización de uso. Una vista

arquitectónica puede consistir en uno o más modelos arquitectónicos.

5.5 Coherencia entre vistas arquitectónicas

Un anuncio debe registrar cualquier inconsistencia conocida entre sus vistas arquitectónicas.

Un anuncio debe contener un análisis de consistencia en todas sus vistas arquitectónicas.

5.6 Justificación arquitectónica

Un anuncio incluirá la justificación de los conceptos arquitectónicos seleccionados.

Un anuncio debe proporcionar evidencia de la consideración de conceptos arquitectónicos
alternativos y la justificación de las elecciones realizadas.

Cuando el anuncio describe un sistema que preexiste al desarrollo del anuncio, se presentarán los
fundamentos de la arquitectura de sistema de sistemas heredados, si se conocen.

5.7 Ejemplo de uso

(Informativo)

Un breve ejemplo muestra cómo los requisitos normativos de la Cláusula 5 se interconectan. Para
reclamar la conformidad con esta práctica recomendada, el arquitecto debe producir una
descripción arquitectónica que cumpla con los requisitos de 5.1 a 5.6.

La subcláusula 5.1 requiere que el AD incluya información documental básica.

En 5.2, el anuncio debe identificar a las partes interesadas y preocupaciones arquitectónicamente

relevantes. Por ejemplo, una parte interesada debe ser el creador del sistema, y una de las
preocupaciones de esa parte interesada podría ser el comportamiento de entrada / salida del
sistema. Esta práctica recomendada solo impone requisitos mínimos a las preocupaciones
seleccionadas y se considera arquitectónica. La organización que utiliza y el arquitecto deben
hacer la elección central de qué preocupaciones abordar.

La subcláusula 5.3 requiere que se seleccione, defina y analice un conjunto de puntos de vista para
la cobertura y que se ofrezcan las razones para su selección. Por lo tanto, el arquitecto puede
seleccionar un punto de vista de comportamiento que describa el comportamiento de entrada /
salida del sistema. El arquitecto también estaría obligado a definir qué lenguajes o modelos se
emplearán para describir el comportamiento del sistema bajo ese punto de vista. No se coloca
ninguna restricción en el idioma o la técnica de modelado utilizada, pero debe especificarse
explícitamente de acuerdo con 5.3.

La subcláusula 5.4 requiere la representación de la arquitectura resultante a través de una o más

vistas. El arquitecto construirá una vista de comportamiento del sistema, y esa vista de
comportamiento debe ajustarse al punto de vista de comportamiento definido anteriormente.

La subcláusula 5.5 requiere que todas las inconsistencias conocidas entre las vistas (por ejemplo,
entre la vista de comportamiento y la vista estructural proporcionada) se incluyan en la
descripción arquitectónica.

Finalmente, de acuerdo con 5.6, el anuncio debe contener una justificación para las decisiones
arquitectónicas y las decisiones tomadas por el arquitecto.

NOTAS:

1: Los materiales correspondientes a 5.2 y 5.3, las partes interesadas, las inquietudes y los puntos
de vista, deben ser elementos fácilmente reutilizables para las organizaciones de arquitectos
activas. Es probable que dichas organizaciones adopten conjuntos comunes de puntos de vista y
especificaciones comunes, es decir, acuerdo y especificación sobre las preocupaciones abordadas
y los métodos utilizados. De hecho, la estandarización de puntos de vista podría ser una actividad
fructífera dentro de dominios donde se construyen repetidamente sistemas similares. Algunos
estándares arquitectónicos existentes se pueden refundir como estándares en la selección y
especificación de puntos de vista, con esta práctica recomendada convirtiéndose en un punto de
referencia común para conciliar la arquitectura en varios dominios.

2: el Anexo D proporciona una descripción de cómo se puede aplicar la práctica recomendada en

el contexto del uso de otros estándares arquitectónicos

Anexo B

(Informativo)

Notas sobre la terminología.

Esta práctica recomendada hace uso de tres términos, arquitectura, vista y punto de vista, que
reflejan el consenso de la comunidad, pero, sin embargo, se emplean de maneras diferentes a
algunos usos actuales. Este anexo discute los términos para aclarar los conceptos fundamentales
de la práctica recomendada.

La arquitectura se define por la práctica recomendada como la organización fundamental de un

sistema, incorporada en sus componentes, sus relaciones entre sí y con el entorno, y los principios
que rigen su diseño y evolución. Esta definición pretende abarcar una variedad de usos del
término arquitectura al reconocer sus elementos comunes subyacentes. La principal de ellas es la
necesidad de comprender y controlar los elementos del diseño del sistema que capturan la
utilidad, el costo y el riesgo del sistema. En algunos casos, estos elementos son los componentes
físicos del sistema y sus relaciones. En otros casos, estos elementos no son físicos, sino
componentes lógicos. En otros casos, estos elementos son principios o patrones duraderos que
crean estructuras organizativas duraderas. La definición pretende abarcar estos usos distintos,
pero relacionados, al tiempo que fomenta una definición más rigurosa de lo que constituye la
organización fundamental de un sistema dentro de dominios particulares.

Los términos vista y punto de vista son fundamentales para la práctica recomendada. Dentro del
marco conceptual de la práctica recomendada, se refieren a cosas distintas y sus definiciones
varían de algunos usos actuales de esos términos. Sin embargo, sus definiciones reflejan el uso
establecido en estándares e investigación de ingeniería. Estas notas analizan los dos conceptos
para motivar la distinción y justificar la necesidad de ambos términos.

Un objetivo básico de la práctica recomendada es abarcar las prácticas existentes de descripción

arquitectónica proporcionando una terminología y conceptos comunes. Una observación
fundamental es que muchas prácticas existentes representan arquitecturas a través de colecciones
de modelos. Típicamente, estos modelos son grupos intocohesivos más organizados. La cohesión
de un grupo de modelos está determinada por la observación de que todos los modelos incluidos
abordan las inquietudes relacionadas. Lo que ha faltado es algún mecanismo para formalizar estos
grupos y los modelos utilizados para hacer las representaciones. En esta práctica recomendada, el
punto de vista se refiere a un modelo o plantilla para representar un conjunto de preocupaciones
relativas a una arquitectura, mientras que una vista es la representación real de un sistema en
particular. Un punto de vista proporciona la formalización de las agrupaciones de modelos.

Una vista es una representación o descripción de todo el sistema desde una única perspectiva. En
contraste con aviewpoint, una vista se refiere a una arquitectura particular de un sistema (es decir,
un sistema individual, una línea de productos, un sistema de sistemas, etc.). Una vista se compone
principalmente de modelos, aunque también tiene atributos adicionales. Los modelos
proporcionan la descripción específica o el contenido de una arquitectura. Por ejemplo, una vista
estructural puede consistir en un conjunto de modelos de la estructura del sistema. Los elementos
de dichos modelos podrían incluir componentes del sistema identificables y sus interfaces, e
interconexiones entre esos componentes.

La necesidad de múltiples vistas en las descripciones arquitectónicas es ampliamente reconocida

en la literatura. Para argumentar de otra manera, en los términos de esta práctica recomendada,
es afirmar que una arquitectura puede ser descrita adecuadamente por un conjunto de modelos
correspondientes a una única perspectiva conceptual. Alternativamente, se podría argumentar
que todas las partes interesadas y las inquietudes pueden abordarse mediante un único conjunto
de métodos de modelado.

El uso de múltiples vistas para describir una arquitectura es, por lo tanto, un elemento
fundamental de esta práctica recomendada. Sin embargo, aunque el uso de múltiples vistas está
muy extendido, los autores difieren en lo que se refiere a las vistas y en los métodos apropiados
para expresar cada vista.

Debido a la amplia gama de opiniones sobre la selección de vistas apropiadas, esta práctica
recomendada no prescribe un conjunto fijo de vistas, sino que introduce el concepto de un punto
de vista para designar los medios utilizados para construir vistas individuales.

En la práctica recomendada, el término punto de vista se utiliza para designar un medio para
construir una vista que no depende de un sistema en particular. El término se eligió para alinearlo
con el del Modelo de referencia ISO de procesamiento distribuido abierto (RM-ODP) [B3], que
define el punto de vista de la siguiente manera (pero no tiene un término separado para la vista):

Punto de vista (en un sistema): una forma de abstracción que se logra utilizando un conjunto
seleccionado de construcciones arquitectónicas y reglas de estructuración, con el fin de centrarse
en preocupaciones particulares dentro de un sistema.

La relación entre el punto de vista y la vista es análoga a la de una plantilla y una instancia de esa
placa de tiempo, o usar una metáfora de programación orientada a objetos:

Punto de vista: ver:: clase: objeto4

De acuerdo con la práctica recomendada, un punto de vista debe ser especificado por las partes
interesadas y las preocupaciones que aborda y los idiomas, modelos y técnicas que emplea. Esto
proporciona un medio para capturar los considerables elementos comunes encontrados entre las
técnicas existentes.

Al definir los puntos de vista, al requerir que los puntos de vista se especifiquen en un anuncio
antes de su uso en las vistas y al no requerir puntos de vista específicos, la práctica recomendada
proporciona una estrategia para la personalización y la evolución de las prácticas arquitectónicas.
De esta manera, se pretende satisfacer las necesidades de los usos específicos del dominio, donde
el dominio puede ser, por ejemplo, específico de la aplicación, específico del método o específico
de la organización.

Una organización que desee producir un marco de arquitectura para un dominio particular puede
hacerlo especificando un conjunto de puntos de vista y haciendo que la selección de esos puntos
de vista sea normativa para cualquier reclamo de anuncios de conformidad con el marco
arquitectónico específico del dominio. Se espera que los fondos arquitectónicos existentes, como
el Modelo de Referencia ISO para Procesamiento Distribuido Abierto (RM-ODP) [B4], el Marco de
Arquitectura Empresarial de Zachman [B9]), y el enfoque de Bass, Clements y Kazman [B1] puedan
Alinearse con el estándar de esta manera.

Al construir una descripción arquitectónica, un arquitecto primero selecciona los puntos de vista,
luego construye un conjunto de vistas correspondientes. Se puede pensar que los puntos de vista
se extraen de una biblioteca de puntos de vista, independientemente de si esa biblioteca de
puntos de vista existe o no. El arquitecto selecciona los puntos de vista de la biblioteca de puntos
de vista que se utilizarán en una descripción de arquitectura particular. Imaginamos que las
bibliotecas reales llegarán a existas, la práctica recomendada se pone en uso.

Cuando se selecciona un punto de vista para un anuncio en particular, se debe personalizar

parcialmente. La personalización se encuentra en la elección de qué partes interesadas y
preocupaciones se utilizarán para cubrir en esta descripción arquitectónica. Las partes interesadas
exactas y las preocupaciones que deben cubrirse son específicas de un determinado sistema y
anuncio, por lo que no pueden especificarse cuidadosamente en la biblioteca de puntos de vista.
Esto sugiere además que un punto de vista es básicamente una plantilla.

Dentro de una descripción arquitectónica particular, cada vista está asociada con exactamente un
punto de vista, que debe haber sido seleccionado para esa descripción arquitectónica. La relación
requerida entre ese punto de vista y su vista es que la vista se ajusta al punto de vista. Una vista se
ajusta a un punto de vista si consta solo de modelos que se ajustan a los métodos de modelado
requeridos en la especificación del punto de vista.

En principio, una vista dada podría ajustarse a múltiples puntos de vista, pero debería ajustarse a
un solo punto de vista dentro de una descripción arquitectónica específica. Sin embargo, un punto
de vista puede, y debe, ser reutilizado en muchas descripciones arquitectónicas. Por ejemplo, un
punto de vista estructural que requiere el uso de un método de modelado particular y una técnica
de análisis puede seleccionarse mediante muchas descripciones arquitectónicas diferentes.

Si bien la relación entre las vistas y los puntos de vista (dentro de una descripción arquitectónica
dada) es de uno a uno, debe entenderse que esta relación es más general fuera de una descripción
arquitectónica dada. Si, dentro de una descripción arquitectónica, una vista corresponde a dos o
Más puntos de vista, significa que los puntos de vista son redundantes. Las partes interesadas y las
preocupaciones de interés para el conjunto de puntos de vista están siendo abordadas por una
colección de modelos que utilizan un método de modelado, por lo que las partes interesadas y las
preocupaciones pueden ser agregadas en un solo punto de vista. Si un anuncio se escribe para un
sistema, y luego otro anuncio se escribe para un componente del sistema, como podría suceder en
un sistema complejo, entonces es muy probable que se seleccionen los puntos de vista de sam
para ambos anuncios. Punto de vista (por ejemplo, un punto de vista estructural) tendrá una vista
correspondiente de todo el sistema y una vista correspondiente del subsistema. La relación es de
uno a uno, dentro de cada anuncio. Desde la perspectiva de esta práctica recomendada, la
situación no es diferente que si se hubiera tomado el mismo punto de vista de una biblioteca y se
hubiera utilizado en dos sistemas completamente diferentes.

La relación entre las vistas y los puntos de vista se puede imaginar imaginando una biblioteca de
puntos de vista mantenida por una organización de arquitectos y un conjunto de anuncios para
una variedad de sistemas producidos por esa misma organización. Cada descripción arquitectónica
selecciona un conjunto de puntos de vista de la biblioteca de puntos de vista. Cada anuncio
contiene vistas que describen un sistema en particular.

Además de la conformidad requerida de una vista a su punto de vista, hay otra forma de
verificación requerida por la práctica recomendada. Un punto de vista cubre intereses y
preocupaciones particulares. Todos los interesados y las preocupaciones deben estar cubiertos
por al menos un punto de vista, y pueden ser abordados por varios puntos de vista.

El anexo C ofrece ejemplos de puntos de vista.

Anexo C

(informativo)

Ejemplos de puntos de vista

Este anexo proporciona algunos ejemplos del concepto central de punto de vista. Se pueden
encontrar ejemplos adicionales en el Anexo D. Los dos primeros puntos de vista (punto de vista
estructural y punto de vista del comportamiento) se usan con frecuencia en la arquitectura de
software, pero rara vez se definen explícitamente. Los siguientes dos puntos de vista (punto de
vista de interconexión física y punto de vista de tasa de error de bits de enlace) son construcciones
informales destinadas a ilustrar la aplicación del concepto de punto de vista fuera de la
arquitectura de software.
C.1 El punto de vista estructural en arquitectura de software.

Este punto de vista está motivado por el trabajo actual en los lenguajes de descripción de
arquitectura orientados a la estructura. El punto de vista estructural se ha desarrollado en el
campo de la arquitectura de software desde 1994 y tiene un uso generalizado. Este punto de vista
a menudo está implícito en los lenguajes de descripción de la arquitectura contemporánea.

Tal vez en el artículo más antiguo sobre arquitectura de software, la definición de elementos de
Perry y Wolf [B6] implica lo siguiente:

Por analogía con la arquitectura de construcción, proponemos el siguiente modelo de arquitectura

de software: Arquitectura de software = {Elementos, Forma, Justificación}

Perry y Wolf [B6] distinguen tres clases de elementos de la siguiente manera:

a) Elementos de procesamiento: “aquellos componentes que suministran la transformación de

elementos de datos”

b) Elementos de datos: “aquellos que contienen la información que se utiliza y transforma”.

c) Elementos de conexión: esos "elementos (que a veces pueden ser elementos de procesamiento
o de datos, o de ambos) son el pegamento que mantiene unidas las diferentes piezas de la
arquitectura"

Shaw y Garlan [B8] adoptan un enfoque similar:

El marco que adoptaremos es tratar una arquitectura de un sistema específico como una colección
de componentes computacionales, o simplemente componentes, junto con una descripción de las
interacciones entre estos componentes, los conectores. ... Un estilo arquitectónico, entonces,
define una familia de tales sistemas en términos de un patrón de organización estructural. Más
específicamente, un estilo arquitectónico determina el vocabulario de los componentes y
conectores que se pueden usar en instancias de ese estilo, junto con un conjunto de restricciones
sobre cómo se pueden combinar.

El punto de vista estructural se puede especificar de la siguiente manera:

Preocupaciones

- ¿Cuáles son los elementos computacionales de un sistema y la organización de esos elementos?

- ¿Qué elementos de software componen el sistema?

- ¿Cuáles son sus interfaces?

- ¿Cómo se interconectan?

- ¿Cuáles son los mecanismos de interconexión?

Idioma del punto de vista

El punto de vista estructural depende de las siguientes entidades:

—Componentes (unidades individuales de cómputo)

- Los componentes tienen puertos (interfaces)

—Conectores (representan las interconexiones entre los componentes para la comunicación y la

coordinación)

- Los conectores tienen roles (donde se unen a los componentes)

Los componentes y conectores pueden ser escritos. Todas las entidades enumeradas
anteriormente pueden tener atributos de diferentes tipos.

Metodos analiticos

El punto de vista estructural soporta los siguientes tipos de verificación:

- Fijación (¿los conectores están conectando correctamente los componentes?)

- Tipo de coherencia (¿son los tipos de componentes y conectores utilizados de forma coherente
con sus accesorios y algún estilo u otra restricción?)

La mayoría de los lenguajes de descripción arquitectónicos que soportan el punto de vista

estructural proporcionan algún tipo de comprobación de sintaxis de las entidades anteriores.

C.2 Punto de vista del comportamiento

El punto de vista del comportamiento tiene una larga historia, antes de su uso en arquitectura en
las comunidades de ingeniería de sistemas, simulación, ingeniería de software y diseño. Los
ejemplos incluyen redes de Petri, expresiones de ruta paralelas y expresiones restringidas.

El punto de vista del comportamiento se puede especificar de la siguiente manera:

Preocupaciones

- ¿Cuáles son las acciones dinámicas de y dentro de un sistema?

- ¿En qué tipo de acciones el sistema produce y participa?

- ¿Cómo se relacionan esas acciones (ordenamiento, sincronización, etc.)?

- ¿Cuáles son los comportamientos de los componentes del sistema? ¿Cómo interactúan?

Metodos de modelado

Eventos, procesos, estados y operaciones en esas entidades.

Metodos analiticos

Algunos ejemplos son: la comunicación de procesos secuenciales, el cálculo pi y conjuntos de

eventos parcialmente ordenados.

C.3 Punto de vista de la interconexión física.

Preocupaciones

- ¿Qué son las interconexiones de comunicaciones físicas y su estratificación entre los

componentes del sistema?

- ¿Cuál es la viabilidad de la construcción, el cumplimiento de las normas y la evolvibilidad?

Idioma del punto de vista

Defina el sistema con un conjunto de uno o más diagramas de bloques utilizando el siguiente
glosario visual:

Se proporciona un diagrama para cada capa de comunicación identificada. Cada diagrama está
anotado para mostrar el direccionamiento, el acceso al enlace y las estrategias de enrutamiento /
conmutación en cada enlace.

C.4 Punto de vista de tasa de error de bit de enlace

Preocupaciones

- ¿Cuál es la tasa de error de bits en un enlace de comunicaciones?

- ¿Cuál es la viabilidad de crear y mantener la coherencia con los flujos de información

operacional?
Idioma del punto de vista

Calcular la tasa de error de bits de

Anexo d

(informativo)

Relación con otras normas.

Las descripciones arquitectónicas se pueden utilizar en una variedad de configuraciones y modelos

de ciclo de vida. Este anexo muestra cómo las descripciones arquitectónicas que se ajustan a esta
práctica recomendada se pueden usar para cumplir con los requisitos de otras normas.

D.1 Uso con IEEE / EIA Std 12207.0-1996

IEEE / EIA Std 12207.0−1996 define dos actividades relacionadas con la arquitectura: diseño
arquitectónico del sistema y diseño arquitectónico del software. El concepto de arquitectura en
esta práctica recomendada es consistente con la actividad de diseño arquitectónico del sistema de
IEEE / EIA Std 12207.0-1996. Sin embargo, IEEE / EIA Std12207.0-1996 establece requisitos en una
descripción arquitectónica además de los de esta práctica recomendada. Específicamente, el
diseño arquitectónico del sistema debe incluir una identificación de los elementos de hardware,
elementos de software y elementos de operación manual incluidos en el sistema. Los diseños
arquitectónicos del sistema también deben evaluarse de acuerdo con los criterios que incluyen la
trazabilidad y la coherencia con los requisitos del sistema, la adecuación de los estándares y
métodos de diseño y la viabilidad del software y las operaciones manuales. Un enfoque para
cumplir con estos requisitos utilizando esta práctica recomendada es definir uno o más puntos de
vista que cumplan con los requisitos IEEE / EIA Std 12207.0-1996. Un ejemplo de un punto de vista
para satisfacer IEEE / EIA Std 12207.0-1996 se define en D.1.1.

El uso esperado de una descripción arquitectónica puede incluir elementos de otras actividades
IEEE / EIA Std 12207.0-1996. En particular, una descripción arquitectónica se puede usar en
actividades distintas de la actividad de diseño arquitectónico del sistema para facilitar las
comunicaciones entre el adquirente y los roles de desarrollador.

La actividad de diseño arquitectónico de software de IEEE / EIA Std 12207.0-1996 ejemplifica una
aproximación de la descomposición a la arquitectura. Su objetivo principal es descomponer los
elementos de software del sistema en componentes y luego asignar requisitos a esos
componentes. Tanto el anuncio de sistema como los productos de otras vistas en la descripción
arquitectónica contribuirían a esta actividad y sus productos.

NOTA: Las disposiciones de IEEE / EIA Std 12207.0-1996 relevantes para la arquitectura son
idénticas a las que se encuentran en ISO / IEC 12207: 1995.

Una descripción arquitectónica puede ajustarse a esta práctica recomendada, según IEEE / EIA Std
12207.0-1996 y IEEE / EIA Std 12207.1-1997. Un enfoque para la conformidad conjunta es tener un
punto de vista centrado específicamente en la producción de los productos arquitectónicos IEEE /
EIA Std 12207.0-1996. Un ejemplo de un punto de vista definido para este propósito se muestra
en D.1.1.

D.1.1 Punto de vista de la descomposición y asignación.

Preocupaciones

- Identificar los requisitos del sistema.

- Descomponer el sistema en elementos.

- Asignar requisitos a los artículos.

- Asegúrese de que todos los requisitos se asignan a los artículos

Técnicas de modelización y métodos analíticos.

Cada requisito se identifica de forma única. Si es necesario, los requisitos se descomponen y se

amplían los requisitos para proporcionar un conjunto completo de requisitos para el 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 de operaciones manuales. También se
identifican las interfaces entre los elementos.

Los requisitos del sistema se asignan a los elementos, de modo que cada elemento satisface uno o
más requisitos, y cada requisito se asigna a al menos un elemento.

La descomposición inicial y la asignación producen un conjunto de elementos con requisitos

asignados. Esto se describe en términos de una descripción arquitectónica del sistema (consulte
IEEE / EIA Std 12207.0−1996).
Los elementos de software iniciales se descomponen en componentes subordinados. Los
requisitos asignados a cada elemento del software se asignan a uno o más componentes. Las
descripciones de la interfaz se proporcionan entre los componentes del software, y entre los
componentes de software y los elementos de hardware y los elementos de operación manual.
Esto se describe en términos de una Descripción arquitectónica del software (consulte IEEE / EIA
Std 12207.0−1996)

D.2 Uso con modelo de referencia de procesamiento distribuido abierto

El modelo de referencia de procesamiento distribuido abierto (RM-ODP) [B3] define un marco

arquitectónico para sistemas de procesamiento distribuido; Sistemas "en los que los componentes
discretos pueden ubicarse en diferentes lugares, o donde la comunicación entre los componentes
puede sufrir un retraso o puede fallar".

El marco RM-ODP define cinco puntos de vista para especificar sistemas ODP.

Para cada punto de vista, hay un lenguaje de punto de vista asociado que define "los conceptos y
las reglas para especificar sistemas ODP desde el punto de vista correspondiente".

Una descripción arquitectónica que cumpla con esta práctica recomendada y que use 10746-3:
1996 [B4] incluiría los puntos de vista definidos por ISO / IEC 10746-3: 1996 y las vistas para
implementar estos puntos de vista. Una descripción arquitectónica de conformación no debe
limitarse a los cinco puntos de vista predefinidos de ISO / IEC 10746-3: 1996; La descripción
arquitectónica puede incluir puntos de vista adicionales y vistas, según sea necesario.

Los cinco puntos de vista definidos por ISO / IEC 10746-3: 1996 se especifican aquí de acuerdo con
los requisitos de la subcláusula 5.3 (D.2.1 – D.2.5). Los elementos de esa especificación específicos
de las descripciones arquitectónicas (como las partes interesadas) se omiten aquí, ya que son
específicos de los sistemas individuales. A menos que se indique, todos los contenidos son citas
directas o paráfrasis cerradas de [B4].

D.2.1 Punto de vista de la empresa.

Preocupaciones

- El propósito, alcance y políticas de un sistema ODP

- Roles que desempeña el sistema.

- Actividades emprendidas por el sistema.

- Declaraciones de política sobre el sistema.

Idioma del punto de vista

Desde el punto de vista de la empresa, un sistema ODP y su entorno se representan como una
comunidad de objetos. La comunidad se define en términos de:
- Objetos empresariales que componen la comunidad.

- Roles cumplidos por cada uno de esos objetos.

- Políticas que gobiernan las interacciones entre objetos empresariales que cumplen roles.

- Políticas que rigen la creación, uso y eliminación de recursos por parte de objetos empresariales
que cumplen roles

- Políticas que rigen la configuración de objetos empresariales y la asignación de roles a objetos

empresariales

- Políticas relativas a los contratos ambientales que regulan el sistema. Con objetos definidos en
términos de permisos, obligaciones, prohibiciones y comportamiento.

NOTA: ISO / IEC JTC 1 / SC 7 está desarrollando un lenguaje empresarial.

D.2.2 Punto de vista de la información.

Preocupaciones

- La semántica de la información y el procesamiento de la información en un sistema ODP.

Idioma del punto de vista

El lenguaje de la información se define en términos de tres esquemas:

- Esquema invariante: predicados en objetos que siempre deben ser verdaderos.

- Esquema estático: estado de uno o más objetos en algún momento en el tiempo

- Esquema dinámico: cambios de estado permitidos de uno o más objetos

D.2.3 Punto de vista computacional.

Preocupaciones

- Una descomposición funcional del sistema en objetos que interactúan en las interfaces.

Idioma del punto de vista

El lenguaje computacional cubre conceptos para:

- Objetos computacionales.

- Encuadernación de objetos.

- Interacciones

- Interfaces
D.2.4 Punto de vista de la ingeniería.

Preocupaciones

- Los mecanismos y funciones requeridos para soportar la interacción distribuida entre objetos en
el sistema.

Idioma del punto de vista

El lenguaje de la ingeniería incluye conceptos para:

- Estructuras de nodos.

- Canales que conectan objetos.

- Interfaces

- Encuadernaciones

- Reubicación / migración

- agrupamiento

- Nodos

- Tipos de falla

D.2.5 Punto de vista de la tecnología.

Preocupaciones

- Captura la elección de la tecnología en el sistema.

- Cómo se implementan las especificaciones.

- Especificación de tecnologías relevantes.

- Soporte para pruebas.

Idioma del punto de vista

El lenguaje tecnológico abordó los estándares e implementaciones implementables.