*Arquitectura de Diseño. Unidad #2 Contenido.

1-.)Trazabilidad de los requerimientos en el diseño.
1.1 Dimensiones. 1.2 Establecer y Mantener la Trazabilidad de Requerimientos. 1.3 Etapas del Proceso de Trazabilidad. 1.4 Modelos de trazabilidad. 1.5 Técnicas de trazabilidad. 1.6 Lenguajes de trazabilidad

2-. ) Notación para representar las Arquitecturas del Software.
2.1 UML (Unified Modeling Language). 2.2 Vista de Usuario 2.3 Vista Estructural 2.4 Vista de Comportamiento 2.5 Vista de Ambiente 2.6 Vista de Implementación

3-.)Evaluación del Diseño.
3.1Evaluación de Arquitecturas de Software. 3.2Mediciones que se realizan sobre una Arquitectura de Software. 3.4Técnicas de Evaluación de Arquitecturas de Software.

1-.)La Trazabilidad de Requerimientos.
Es la habilidad para describir y seguir la vida de un requerimiento, hacia delante y hacia atrás, idealmente a través de todo el ciclo de vida de los sistemas. Es vista como una medida de la calidad de los sistemas y es ordenada por muchos estándares que gobiernan el desarrollo de sistemas. Responsabilidad: Reducir el costo elevado en desarrollo y mantenimiento. Ideal: Soporte automatizado de trazabilidad.

Generalmente se distinguen cuatro tipos de enlaces de trazabilidad.
• Hacia delante desde los requerimientos (R ->): La responsabilidad para el logro de requerimientos debe ser asignada a los componentes del sistema, así tal responsabilidad es establecida y el impacto del cambio de requerimientos puede ser evaluado.

muchas herramientas de trazabilidad inicial enlazan documentos de diseño en un sistema de hipertexto. y los gold-plating (diseños para los cuales los requerimientos no existen) deben ser evitados. • Hacia atrás desde los requerimientos (<.1-) Dimensiones. La trazabilidad es. • Hacia delante a los requerimientos (-> R): Los cambios en las necesidades de los stakeholders.• Hacia atrás a los requerimientos (R <-): La conformidad de los componentes del sistema con los requerimientos debe ser verificada. Deben capturarse uniones entre los documentos producidos durante el proceso de requerimientos.R): Las necesidades subyacentes son cruciales en la validación de requerimientos. así como en suposiciones técnicas. * Los dos siguientes tipos de enlaces (“⇒ •” y “⇐ •”) posibilitan la pre-trazabilidad. * Los dos primeros tipos de trazos (“• ⇒” y “• ⇐”) son frecuentemente incluidos en una categoría denominada post-trazabilidad. 1. De hecho. un subproceso de desarrollo evolutivo del sistema que proporciona y utiliza estos trazos. Estos enlazan requerimientos al diseño e i implementación. Dimensión Representativa. Visto como un producto. Estos documentan el contexto racional y sociopolítico del cual los requerimientos emergen. verificación de acuerdos. especialmente en altas imposiciones políticas. documentando asignaciones de responsabilidad. Una vez que se establece qué grado de trazabilidad es deseable. tiene sentido definir trazos como productos que satisfacen las propiedades de trazabilidad deseadas. un trazo debe documentar las tres dimensiones de los procesos de ingeniería de requerimientos. podrían requerir una revaluación radical de relevancia de requerimientos. o análisis de impacto de un requerimiento. o simplemente guardando los enlaces en una hoja de cálculo independiente de los documentos en sí mismos. . entonces.

Dimensión de Cooperación Humana Cómo. y se los enlaza de una manera significativa. los stakeholders contribuyen al desarrollo y satisfacción de requerimientos. (Decisiones tomadas. Un modelo de trazos puede proveer distintas maneras de extraer la información registrada en él. teniendo en cuenta límites y restricciones impuestos por distintos requerimientos. los requerimientos a ser estudiados y las derivaciones de unos en otros (inducciones). en donde se definen los tipos de trazos existentes. es necesaria para alinear continuamente la práctica de trabajo humano de los usuarios.3) Etapas del Proceso de Trazabilidad. la información relacionada con los requerimientos y los requerimientos relacionados con el trabajo del personal. que es anotado por un procedimiento de comprobación de compatibilidad.Dimensión Cognoscitiva. especificando sus tipos y las restricciones bajo las cuales estos elementos pueden ser relacionados. Etapa de Producción de Trazos: La Producción de Trazos es un aspecto importante de los modelos de trazos. Se pueden visualizar. Puede ser. -cuestiones organizacionales. y las características de la extracción de un determinado modelo de trazos depende en cómo fue definido y producido el trazo. no solamente porque se pueden trazar las relaciones y vinculaciones disponibles a simple vista u “obvias”. -No obstante. porque las mismas se pueden inferir. Trabaja con la trazabilidad de requerimientos basados en personas. Establecen estructuras conteniendo elementos y relaciones entre ellos. así como las relaciones que se pueden generar entre ellos. Esta extracción puede realizarse de distintas maneras. Etapa de Extracción de Trazos: Si se quiere rastrear un trazo.. también. por ejemplo.4) Modelos de trazabilidad. Son utilizados para registrar la información de los trazos en BD para su futura extracción. Los modelos de Trazabilidad o Trazos proveen métodos para la representación. La Trazabilidad se basa en la definición por anticipado de tres métodos importantes : Etapa de Definición de Trazos: La definición de Trazos puede llevarse a cabo utilizando Modelos de trazos. 1. el procedimiento más apropiado. dependiendo del método de trazabilidad que se esté utilizando. -Potencia la capacidad para manejar el cambio y así mantener la competitividad. un requisito puede enlazarse a los responsables de componentes de diseño para satisfacerlo mediante un enlace. Por ej. Un trazo captura los objetos conceptuales. Modelo guiado por BD. para que se utilice. en el proceso de diseño. alternativas consideradas. sino. producción y extracción de los trazos. Representa los trazos como relaciones entre documentos de diferentes tipos. es necesario extraer la representación registrada asociada a él. mediante la ejecución de trazos “hacia atrás” y “hacia delante”. definición. Este tipo de modelos garantiza la utilización y recuperación de la información en su formato original. un modelo de hipertexto.2) Establecer y Mantener la Trazabilidad de Requerimientos. Modelo centrado en documentos. -Es un requisito clave que las herramientas actuales sólo satisfacen en grado limitado. Transforma en "trazables" las fuentes humanas de los requerimientos. adopciones subyacentes y metas del stakeholder). y las tecnologías de sistemas de información. en cada caso de extracción. 1. Modelo de Estructura Contributiva. -Es un esfuerzo costoso y políticamente sensible. . 1.

Esto corresponde a la vista física del modelo 4+1 (Kruchten. Matrices de Trazabilidad. de actividades. En la intersección se marca la relación y su importancia. relaciones. de secuencia. 1. comportamiento por interacción. UML permite la descripción de componentes en la arquitectura de software en dos niveles. en filas. UML provee una notación para la descripción de la proyección de los componentes de software en el hardware. que son: de clases. Estos elementos se pueden representar mediante nueve tipos de diagramas. Existen muchos lenguajes de especificación con distintas características que permiten representar relación entre los distintos elementos. de componentes y de desarrollo. Son las actividades específicas y sus productos o elementos resultantes utilizados para lograr la trazabilidad de requerimientos. de objetos.La ventaja de este modelo es que facilita su utilización a una gran diversidad de usuarios y entornos. componentes. Esquemas de referencias cruzadas e indexados Son referencias marcadas entre distintos elementos para indicar relación entre ellos. Los requerimientos se enlistan en columnas y los programas. etc.. o listas de índices conteniendo los elementos relacionados a cada uno. clases abstractas. 1999). UML ofrece soporte para clases. seleccionando los elementos y trazos más importantes para cada ocasión. entre otros.5) Técnicas de trazabilidad. 1999). empaquetamiento. -Lenguaje tipo query Muchas herramientas de trazabilidad utilizan lenguajes convencionales de BD para inspeccionar y recuperar información de sus BD -Expresiones regulares 2-. de colaboración. . UML Unified Modeling Language UML (Lenguaje de Modelado Unificado) ha conseguido un rol importante en el proceso de desarrollo de software en la actualidad (Booch et al. 1. Son utilizadas para relacionar requerimientos con elementos o características del SFW.6) Lenguaje de trazabilidad. de casos de uso. se puede especificar sólo el nombre del componente o especificar las clases o interfaces que implementan estos. de estados. De igual forma. módulos de diseño. ) Notación para representar las Arquitecturas del Software. Lenguajes de trazabilidad Existen muchos lenguajes de especificación con distintas características que permiten representar relación entre los distintos elementos.

3-. Se basa en la estructura lógica de la programación modular. Diagramas de actividad: se usan para mostrar el flujo de control de actividad (ejecución continua noatómica dentro de una máquina de estado) a otra actividad. El primer paso para la evaluación de una arquitectura es conocer qué es lo que se quiere evaluar. selección e iteración. Típicamente estos diagramas pueden ser usados para representar aspectos de distribución. sus enlaces y los mensajes que intercambian en estos enlaces.Algunas descripciones estructurales. Cartas de estructuras: se usan para describir la estructura de llamado de un programa. Vista Estática. Algunas descripciones conductuales. puesto que la intención es saber qué se puede evaluar y qué no. en diversos tipos de situaciones. Pseudocódigo y lenguajes de diseño de programas: son lenguajes estructurados similares a programación que se usan para describir en la etapa de diseño detallado la conducta de un procedimiento o método. la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que viven en ellos. Estos diagramas son inherentes de la aproximación de diseño orientado a la función. archivos y documentos. tablas. A pesar que su uso principal es durante la construcción. estos diagramas pueden ser usados durante diseño. cosas físicas (y sus relaciones) como ejecutables. La arquitectura de software posee un gran impacto sobre la calidad de un sistema. Diagramas de Jackson: se usan para describir las estructuras de datos manipuladas por un programa en términos de secuencia. es decir. mientras que los diagramas de colaboración ponen el énfasis en los objetos.)Evaluación de arquitecturas de software. cliente/servidor o sistemas distribuidos. Vista Dinámica. por ejemplo. De esta forma. por lo que es muy importante estar en capacidad de tomar decisiones acertadas sobre ella. es posible establecer la base para la evaluación. cuál módulo es invocado por otro módulo. Estos diagramas vienen en dos tipos: diagramas de secuencia ponen el énfasis en el ordenamiento temporal de los mensajes. librerías. es decir. Diagramas de interacción: se usan para mostrar las interacciones entre un grupo de objetos. Diagramas de flujo de datos: se usan para mostrar el flujo de datos entre un conjunto de procesos. Diagramas de componentes: se usan para modelas la vista de implementación estáticas de un sistema. entre las cuales destacan: Comparación de alternativas similares Comparación de la arquitectura original y la modificada Comparación de la arquitectura de software con respecto a los requerimientos del sistema . Diagramas de transición de estados y diagramas de statecharts (gráficos de estado): se usan para mostrar el flujo de control de estado a estado en una máquina de estados. Diagramas de deployment (despliegue): se usan para modelar la vista de deployment estático de un sistema. por ejemplo un modelo empotrado. es decir.

sin mayor nivel de detalle. la garantía de una arquitectura correcta cumple un papel fundamental en el éxito general del proceso de desarrollo. sobre elementos como el control de configuración. La segunda variante consiste en realizar la evaluación de la arquitectura cuando ésta se encuentra establecida y la implementación se ha completado. Máximos y mínimos teóricos. calendarios. Este tipo de medición brinda respuestas afirmativas o negativas.Comparación de una arquitectura de software con una propuesta teórica Valoración de una arquitectura en base a escalas específicas 3-1 Evaluación de Arquitecturas de Software. o tomar decisiones sobre ella. se establece que mientras mayor es el nivel de especificación. En este punto. estructura del equipo de desarrollo y otras actividades que se realizan con la arquitectura del sistema como apoyo principal. control de recursos. Su planteamiento establece que es posible realizarla en cualquier momento. resulta interesante resaltar que es posible efectuar decisiones sobre la arquitectura a cualquier nivel. como lo es el caso de los requerimientos de desempeño. También otros autores afirman que la evaluación de una arquitectura de software es una tarea no trivial. puesto que se pretende medir propiedades del sistema en base a especificaciones abstractas. Para la primera variante. puesto que puede observarse el cumplimiento de los atributos de calidad asociados al sistema. puesto que se pueden imponer distintos tipos de cambios arquitectónicos. pero propone dos variantes que agrupan dos etapas distintas: temprano y tarde. Los objetivos que menciona son tres: Cualitativos. Este enfoque permite establecer comparaciones. El esquema general es la comparación con márgenes establecidos. mejores son los resultados que produce la evaluación. Por ello. es posible también determinar la estructura del proyecto de desarrollo del sistema. indicando las ocasiones en que se hace posible hacer la evaluación de una arquitectura. y esto abarca desde las fases tempranas de diseño y a lo largo del desarrollo. amplían el panorama clásico. Cuantitativos. Las mediciones que se realizan sobre una arquitectura de software pueden tener distintos objetivos. la intención es más bien la evaluación del potencial de la arquitectura diseñada para alcanzar los atributos de calidad requeridos. para establecer el grado de cumplimiento de una arquitectura candidata. pero se ve limitado en tanto no se conozcan . Mediante la arquitectura de software. Este es el caso general que se presenta al momento de la adquisición de un sistema ya desarrollado. el interés se centra en determinar el momento propicio para efectuar la evaluación de una arquitectura. En este sentido. En este sentido. De esta manera. La medición cuantitativa busca la obtención de valores que permitan tomar decisiones en cuanto a los atributos de calidad de una arquitectura de software. producto de una evaluación en función de los atributos de calidad esperados. dependiendo de la situación en la que se encuentre el arquitecto y la aplicabilidad de las técnicas que emplea. y cómo será su comportamiento general.2 Mediciones que se realizan sobre una Arquitectura de Software. además del cumplimiento de los atributos de calidad del sistema. se establece que no es necesario que la arquitectura esté completamente especificada para efectuar la evaluación. Ahora bien. como por ejemplo los diseños arquitectónicos. Los autores consideran muy útil la evaluación del sistema en este punto. 3. La medición cualitativa: se aplica para la comparación entre arquitecturas candidatas y tiene relación con la intención de saber la opción que se adapta mejor a cierto atributo de calidad . metas de desempeño.

sino que explica cuáles son los puntos de riesgo del diseño evaluado.no”. en ocasiones. Un escenario consta de tres partes: El estímulo. Por ejemplo. un desarrollador se enfocará en el uso de la arquitectura para efectos de su construcción o predicción de su desempeño. un encargado de mantenimiento hará referencia a cambios que deban realizarse sobre el sistema. la medición de máximo y mínimo teórico contempla los valores teóricos para efectos de la comparación de la medición con los atributos de calidad especificados. El contexto. en muchos casos los arquitectos de software evalúan cualitativamente. Este último elemento es el que permite establecer cuál es el atributo de calidad asociado. son necesarias técnicas que requieran poca información detallada y puedan conducir a resultados relativamente precisos. La respuesta. cómo debería responder el sistema ante el estímulo.3 Técnicas de evaluación de arquitecturas de software. El conocimiento de los valores máximos o mínimos permite el establecimiento claro del grado de cumplimiento de los atributos de calidad. . Por último.Los valores teóricos máximos y mínimos de las mediciones con las que se realiza la comparación. En vista de que el interés es tomar decisiones de tipo arquitectónico en las fases tempranas del desarrollo. un usuario hará la descripción en términos de la ejecución de una tarea. Estas técnicas requieren información del sistema a desarrollar que no está disponible durante el diseño arquitectónico. la evaluación de una arquitectura de software no produce valores numéricos que permiten la toma de decisiones de manera directa. etc. Puede incluir ejecución de tareas. En este sentido se afirman que de la evaluación de una arquitectura no se obtienen respuestas del tipo “si . con distintos niveles de especificación.75 de 10”. configuración. La respuesta describe. cambios en el sistema. 3. para decidir entre las alternativas de diseño. El estímulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interacción con el sistema. En líneas generales. pero se tienen pocos medios para predecir el máximo (o mínimo) teórico para las arquitecturas de software. Sin embargo. a través de la arquitectura. el planteamiento anterior presenta los objetivos para efectos de la medición de los atributos de calidad. Ante la posibilidad de efectuar evaluaciones a cualquier nivel del proceso de diseño. se propone un esquema general en relación a la evaluación de una arquitectura con respecto a sus atributos de calidad. Sin embargo. sino al principio del diseño detallado del sistema. Existen diferentes técnicas de evaluación entre las cuales se pueden mencionar : 3. Las técnicas utilizadas para la evaluación de atributos de calidad requieren grandes esfuerzos por parte del ingeniero de software para crear especificaciones y predicciones. debido al costo de realizar este tipo de evaluación. Un escenario es una breve descripción de la interacción de alguno de los involucrados en el desarrollo del sistema con éste. Las técnicas existentes en la actualidad para evaluar arquitecturas permiten hacer una evaluación cuantitativa sobre los atributos de calidad a nivel arquitectónico.4 Evaluación basada en escenarios. “bueno – malo” o “6. El contexto describe qué sucede en el sistema al momento del estímulo. ejecución de pruebas.

como desempeño y confiabilidad.Los escenarios proveen un vehículo que permite concretar y entender atributos de calidad. Es utilizada para evaluar requerimientos de calidad operacional. se encuentran los lenguajes de descripción arquitectónica. y los modelos de colas. pueden usarse los perfiles respectivos para evaluar los atributos de calidad. . En el ámbito de las simulaciones. Entre las ventajas de su uso están: Son simples de crear y entender Son poco costosos y no requieren mucho entrenamiento Son efectivos 3. y otras partes que constituyen el contexto del sistema de software. por lo que estas partes pueden ser tomadas directamente de la descripción de diseño. Simulación del sistema e inicio del perfil. Se obtiene un resultado de evaluación con mayor exactitud. a su vez. Implementación del perfil. y obtendrá resultados de acuerdo al atributo de calidad que está siendo evaluado. La descripción del diseño arquitectónico debe definir. El comportamiento de los componentes en respuesta a eventos sobre sus interfaces puede no ser especificado claramente. Dependiendo del tipo de simulación y del atributo de calidad evaluada. que requieren ser condensados. La exactitud de los resultados de la evaluación depende. de la exactitud del perfil utilizado para evaluar el atributo de calidad y de la precisión con la que el contexto del sistema simula las condiciones del mundo real. así como también ejecutar un perfil completo usando selección aleatoria. por lo menos. el perfil asociado necesitará ser implementado en el sistema. Esto permite hacer conclusiones acerca del comportamiento del sistema. Implementación de los componentes arquitectónicos. El enfoque básico consiste en la implementación de componentes de la arquitectura y la implementación La finalidad es evaluar el comportamiento de la arquitectura bajo diversas circunstancias. El proceso de evaluación basada en simulación sigue los siguientes pasos: Definición e implementación del contexto. descritos en la sección 7. Para su uso se necesita mayor información sobre el desarrollo y disponibilidad del hardware. Dependiendo del atributo de calidad que el arquitecto de software intenta evaluar usando simulación. En términos de los instrumentos asociados a las técnicas de evaluación basadas en simulación. Esta técnica implementa una parte de la arquitectura de software y la ejecuta en el contexto del sistema.5 Evaluación basada en simulación. se puede disponer de cantidades excesivas de datos. se encuentra la técnica de implementación de prototipos (prototyping). por lo que éste decide el nivel de detalle de la implementación. El arquitecto de software ejecutará la simulación y activará escenarios de forma manual o automática. Consiste en identificar las interfaces de la arquitectura de software con su contexto. aunque generalmente existe un conocimiento común y es necesario que el arquitecto lo interprete. basado en los pesos normalizados de los mismos. Una vez disponibles estas implementaciones. Predicción de atributos de calidad. y decidir cómo será simulado el comportamiento del contexto en tales interfaces. La evaluación basada en simulación utiliza una implementación de alto nivel de la arquitectura de software. El arquitecto de software debe ser capaz de activar escenarios individuales. las interfaces y las conexiones de los componentes.

la arquitectura necesita ser representada en términos del modelo. En muchas ocasiones los arquitectos e ingenieros de software otorgan valiosas ideas que resultan de utilidad para la evasión de decisiones erradas de diseño. que es realizada por los arquitectos de software durante el proceso de diseño. Representación de la arquitectura en términos del modelo. la evaluación externa. Por lo tanto. El proceso de evaluación basada en modelos matemáticos sigue los siguientes pasos: Selección y adaptación del modelo matemático. los cuales tienden a ser muy elaborados y detallados. requiere datos de entrada que no están incluidos en la definición básica de la arquitectura. El modelo matemático seleccionado y adaptado no asume necesariamente que el sistema que intenta modelar consiste de componentes y conexiones. Permite una evaluación estática de los modelos de diseño arquitectónico. y pueden ser la base de otros enfoques de evaluación. La mayoría de los centros de investigación orientados a atributos de calidad han desarrollado modelos matemáticos para medir sus atributos de calidad. 3. es realizada por equipos externos de evaluación de arquitecturas. y se presentan como alternativa a la simulación.3. es decir. utilizando los resultados de uno como entrada para el otro. Existen dos tipos de evaluación basada en experiencia: la evaluación informal.6 Evaluación basada en modelos matemáticos. Aunque todas estas experiencias se basan en evidencia anecdótica. . Ambos enfoques pueden ser combinados. y la técnica requiere mucho esfuerzo para la evaluación arquitectónica. Parte de estos datos requeridos no están disponibles a nivel de arquitectura. Es necesario estimar y deducir estos datos de la especificación de requerimientos y de la arquitectura diseñada. Estimación de los datos de entrada requeridos. basada en factores subjetivos como la intuición y la experiencia. dado que evalúan el mismo tipo de atributos.7 Evaluación basada en experiencia. El modelo matemático aún cuando ha sido adaptado. así como también requieren de cierto tipo de datos y análisis. por lo que el arquitecto de software se ve obligado a adaptar el modelo. Sin embargo. La evaluación basada en modelos matemáticos se utiliza para evaluar atributos de calidad operacionales. la mayoría de ellas puede ser justificada por una línea lógica de razonamiento.

Sign up to vote on this title
UsefulNot useful