*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.

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful