P. 1
Arquitectura de diseño unidad # 2 (1)

Arquitectura de diseño unidad # 2 (1)

|Views: 29|Likes:
Publicado porpatriciacd_19

More info:

Published by: patriciacd_19 on Apr 19, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

12/20/2013

pdf

text

original

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

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

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

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

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

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

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

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

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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->