Transcription
Centro de Investigación enMatemáticas, A.C.Attribute Driven Design (ADD)y Software Product Line (SPL)REPORTE TÉCNICOQue para obtener el grado deMaestro en Ingeniería de SoftwareP r e s e n t a:Heriberto Ortega DomínguezDirector de Tesis:Dr. Cuauhtémoc Lemus OlaldeZacatecas, Zac. Julio de 2010
Attribute Driven Design y Software Product LineReporte n .4Definición del problema y alcance del Reporte Técnico .4Contenido del Reporte Técnico .4Criterios de selección de fuentes de consulta .5El Método Attribute Driven Design (ver. 2.0) .6Qué es el método ADD .6Pasos del método ADD .8Aplicaciones del Método ADD .21Estado del Arte .223.1 Tendencias de la arquitectura en Software Product Line .243.2 Aplicaciones de ADD en Software Product Line.243.2.1 Caso de Estudio, Bottom-up Software Product Line Design .243.2.1.1 Diseño de la arquitectura en SPL .273.2.1.2 Resultados de aplicar ADD al ABB Robotics Software. .333.2.1.3 Trabajos futuros a realizar en el ABB Robotics Software. .333.2.2 Otras aplicaciones del método ADD en Software Product Line. .334Conclusiones .355Glosario .366Referencias .392 / 41
Attribute Driven Design y Software Product LineReporte TécnicoÍndice de FigurasFigura 1. Pasos del método add .7figura 2. Ejemplo de escenario de calidad .8figura 3. Priorizando drivers arquitectónicos.9figura 4. Tipos de patrones arquitectónicos .10figura 5. Tácticas del atributo de calidad availability.11figura 6. Identificando tácticas, patrones subordinados y alternativos .12figura 7. Matriz de selección de patrones alternativos.13figura 8. Vista funcional de elementos de software en la arquitectura y su relación, deacuerdo a los elementos identificados .15figura 9. Ejemplo de responsabilidades del proxy con health monitor .18figura 10. Arquitectura product line, atributos de calidad.22y componentes de software .22figura 11. Definición de product line .23figura 12. Dominios del sistema abb robotics software .25figura 13. Funciones con características similares por dominio .25figura 14. Diseño product line, requerimientos y metas.26figura 15. Vista de la línea de producción y módulo de sistema .27figura 16. Ingeniería de dominio, funcionalidades comunes .28figura 17. Mapeo de funcionalidad de componentes, arquitectura anterior (parte 1) .29figura 18. Mapeo de funcionalidad de componentes, arquitectura anterior (parte 2) .30figura 19. Nuevo diseño lpa (vista de componentes y conectores) .31figura 20. Diseño product line, vista deployment (despliegue) .32figura 21. Enfoque de licitación de requerimientos y reconstrucción de arquitectura.343/41
Attribute Driven Design y Software Product LineReporte Técnico1 Introducción1.1Definición del problema y alcance del Reporte TécnicoAunque el diseño de la arquitectura de software depende en gran medida de laexperiencia e incluso la intuición del arquitecto, en años recientes se estándesarrollando métodos enfocados en sistematizar este proceso de diseño.La etapa de requerimientos se enfoca más en la funcionalidad deseada, ladescripción operacional, el diseño de la arquitectura, el diseño detallado y laimplementación, pero los atributos de calidad, por general, no son claramenteidentificados en dicha etapa, por lo que no son debidamente especificados, locual trae como consecuencia que no sean bien entendidos y por lo tanto sondébilmente implementados.Attribute Driven Design (ADD) es un método que mediante el análisis de losatributos de calidad definidos en la fase de requerimientos, obtiene unaarquitectura inicial del sistema, identificando módulos, componentes yconectores.Por otro lado, el paradigma de Software Product Line (SPL) se centra endesarrollar una familia de sistemas que tienen como base una funcionalidadcomún y que al aplicar variaciones se obtienen productos diferentes.En el presente reporte se realizará un análisis del método ADD y su aplicaciónen Software Product Line, con el objetivo de buscar si se pueden obtenerdesde la fase de diseño arquitecturas reutilizables y modificables que dencomo resultado productos de software diferentes a partir de una arquitecturabase.1.2Contenido del Reporte TécnicoEn este reporte se describe el resultado del análisis realizado a un conjunto deartículos con la finalidad de conocer a detalle los pasos que conforman elmétodo Attribute Driven Design, ilustrar su implementación y los casosregistrados recientemente sobre la implementación del método bajo el enfoquede Software Product Line.4/41
Attribute Driven Design y Software Product Line1.3Reporte TécnicoCriterios de selección de fuentes de consultaLa estrategia para la búsqueda de información fue a través de la exploraciónen Internet utilizando motores de búsqueda para localizar artículos sobre eltema ADD y su aplicación en SPL. En el sitio de Internet del SoftwareEnginnering Institute (SEI), creador del método Attribute Driven Design, fuedonde se localizaron la mayoría de artículos analizados.Se seleccionaron todos los artículos que abordaban ambos temas porseparado o en el mismo artículo o documento; posteriormente se hizo unadepuración de documentos conforme se consultaban de acuerdo al nivel dedetalle del manejo de información que presentaron.5/41
Attribute Driven Design y Software Product LineReporte Técnico2 El Método Attribute Driven Design (ver. 2.0)2.1Qué es el método ADDAttribute Driven Design (ADD) es un método creado por el SoftwareEngineering Institute para sistematizar la definición de la arquitectura desoftware. Utiliza como elementos de entrada los atributos de calidad, losrequerimientos funcionales y las decisiones de diseño definidos en la etapa derequerimientos de un proyecto y priorizados por los stakeholders.La estrategia utilizada por ADD es descomponer a un sistema en varioselementos y aplicar tácticas arquitectónicas en busca de satisfacer elcumplimiento de los atributos de calidad. En cada nivel de descomposición sonvalidados los requerimientos de calidad y los requerimientos funcionales.Una vez aplicado el método se obtiene un diseño o arquitectura inicial desoftware la cual contiene módulos, componentes y conectores que ilustran larelación entre elementos.Los resultados que se obtienen al aplicar el método son: Conjunto de decisiones de diseño estructuradas.Interconexión y coordinación de mecanismos.Aplicación de patrones y tácticas arquitectónicas para especificar partes dela arquitectura.Requerimientos de atributos de calidad cubiertos.No se obtienen interfaces detalladas.El método se compone de los siguientes 8 pasos, como se muestra en laFigura 1.1. Confirmar que existe suficiente información de requerimientos.2. Elegir un elemento del sistema para descomponerlo.3. Identificar drivers arquitectónicos desde el conjunto de escenarios decalidad y requerimientos funcionales.4. Elegir atributos primitivos que satisfagan las características arquitectónicas.5. Instanciar los elementos arquitectónicos y asignar responsabilidades.6. Definir interfaces para elementos instanciados.7. Verificar y refinar los requerimientos (casos de uso y escenarios de calidad)y aplicar las restricciones a los elementos instanciados.8. Repetir del paso 2 al 7 para los siguientes elementos del sistema que sedesee descomponer.6/41
Attribute Driven Design y Software Product LineReporte TécnicoAntes de iniciar la implementación del método es importante que los atributosde calidad hayan sido priorizados por los stakeholders de acuerdo a las metasde negocio y la misión del cliente. Los requerimientos de calidad deben estarexpresados en escenarios de calidad específicos.Figura 1. Pasos del método ADDFuente: Reporte Técnico Attribute Driven Design (ADD)Versión 2.0, SEI / Carnegie Mellon7/41
Attribute Driven Dessign y Software Product Liine2.2Reporte TécniccoPasos del método ADD1. Confirmaar que exisste suficiennte informaación de reequerimienntos.En este paaso se veriffica que se cuenta conn: s requerimiientos priorrizados de acuerdoaa las metas ded negocio.LosAtrributos de calidadcexpresados enn escenarioos de calidaad (ver Figuura2. EjemploEdee escenario de calidad).Dee todos loss requerimientos que se tienen registradoss para el sistema,ssóólopoocos son siignificativoss para la arquitectura. El processo puede inniciar cuanddosee tiene segguridad dee que se conocencloos drivers arquitectónnicos de loosreqquerimientoos.2 Ejemploo de escenario de callidadFigura 2.Fuente: A Practical Exaample of Apppliying Attributte-Driven Dessign (ADD) Veer. 2.0SEEI – Carnegie Mellon. Williaam G. wood2. Elegir unn elemento del sistemma para descomponeerlo.uando inicia el proceeso el elemmento a deescomponeer es por lol general elCusisstema entero.El elemento a descomponer debe satisfacer los drivers arquitectónicos. En essteaprooceso influyyen factorees tales commo:8/441
Attribute Driven Dessign y Software Product Liine Reporte TécniccoEl número de dependenccias que tendrátconn otros eleementos deldsistemma.Los rieesgos o dificultades paara asociarr los requerimientos al elemento.Criterioos de negoocio (por ejeemplo el immpacto en el mercado).Criterioos organizzacionales (por ejempplo impactoo del uso de recursoshumannos y cómpputo).3. Identificaar drivers arquitectónanicos1 desde el conjunto de esscenarios dedcalidad y requerimiientos funccionales.See clasifican los requerimientos previamentepe priorizadoos por los stakeholdeersenn alto, meddiano o bajjo, mediannte grupos pares (H,HH), en donnde el primmereleemento representa lal importanncia que tiene el requerimienrnto para loosstaakeholders y el segunndo elemennto indica lal dificultadd (impacto potencial deldrequerimientoo en la arquuitectura). LaL Figura 3 muestra unau tabla dee priorizacióóne drivers arqquitectónicoos.deFigura 3. Priorizanddo drivers arquitectóónicosFuente: A Practical Exaample of Apppliying Attributte-Driven Dessign (ADD) Veer. 2.0SEEI – Carnegie Mellon. Williaam G. wood1Elementos de entrrada al processo de ADD quue tienen un grangimpacto en la estructura de laarquiteectura.9/441
Attribute Driven Design y Software Product LineReporte TécnicoSe eligen requerimientos de los que los pares resultantes son de alta prioridad(drivers arquitectónicos) los cuales serán utilizados en el resto de los pasos delproceso.4. Elegir los atributos primitivos que satisfagan las característicasarquitectónicas.En esta parte se elige el mayor número de elementos que formarán parte de laarquitectura y se identifican las relaciones que habrá entre ellos.Al inicio de toda arquitectura, se toman en cuenta los llamados estilos opatrones arquitectónicos. Son soluciones a problemas que se han probadopreviamente que constituyen un conjunto de decisiones de diseño y quedescriben una clase de arquitectura en un enfoque general. En la Figura 4. Selistan los principales patrones arquitectónicos conocidos.Las tácticas (decisiones de diseño con un enfoque más detallado) y losatributos de calidad son utilizados en el método ADD para determinar los tiposde elementos, las relaciones y sus interacciones para satisfacer losrequerimientos de calidad.Figura 4. Tipos de patrones arquitectónicosFuente: Current Best Practices in Software ArchitecturePaul Clements, Software Engineering InstituteCarnegie Mellon University10/41
Attribute Driven Design y Software Product LineReporte TécnicoEn esta etapa, el arquitecto debe seguir los siguientes 6 subpasos:4.1 Identificar tácticas arquitectónicas que son asociadas con losdrivers de diseño arquitectónico.Por ejemplo, para el atributo de calidad availability, algunas de las tácticasarquitectónicas definidas son: prevención a fallos, detección de fallos yrecuperación de fallos como se muestra en la Figura 5.Figura 5. Tácticas del atributo de calidad AvailabilityFuente: Current Best Practices in Software ArchitecturePaul Clements, Software Engineering InstituteCarnegie Mellon University4.2 Para cada táctica arquitectónica identificar una lista de patronessubordinados.Para identificar los patrones subordinados se debe tomar en cuenta: El conocimiento, habilidades y experiencia a cerca de los patronesarquitectónicos previamente descritos.El conocimiento previo de tácticas arquitectónicas para lograr losatributos de calidad.Si un driver arquitectónico es de mayor dificultad que un atributo decalidad, quizá se le deban aplicar múltiples tácticas.Otras fuentes tal como libros, artículos, material de conferencias omotores de búsqueda.11/41
Attribute Driven Design y Software Product LineReporte TécnicoLos patrones subordinados son aquellas opciones conocidas que puedenconseguir que una táctica arquitectónica sea satisfecha, en la Figura 6 semuestran patrones subordinados para la táctica de recuperación a fallos.Por ejemplo, para la táctica de prevención a fallos, uno de los patronessubordinados identificados es process monitor (monitoreo de componentescríticos: remover el componente de un servicio y reinstanciar un nuevo procesoen su lugar).Para cada patrón subordinado de la lista, se debe:a. Identificar cada parámetro diferenciador del patrón que ayude a elegirentre el patrón y la táctica en la lista.Por ejemplo, en cualquier patrón de reinicio, la cantidad de tiempo que setoma para reiniciar es un parámetro diferenciador. Para patrones usadospara lograr modificability (por ejemplo layering) un parámetro diferenciadores el número de dependencias que existen entre los elementos en el patrón.b. Estimar los valores de los parámetros diferenciadores.Figura 6. Identificando tácticas, patrones subordinados y alternativosTácticasarquitectónicasPrevención a fallosDetección de fallosPatronesSubordinadosRecuperación a fallosReinicioDespliegueIntegridad dedatosPatronesAlternativosCold RestartWarm StandbyMaster/MasterLoad Sharing4.3 Seleccionar patrones alternativos que sean más apropiados parasatisfacer los drivers arquitectónicos.Realizar esta selección de manera razonable. Decidir cuáles patrones sonapropiados.12/41
Attribute Driven Design y Software Product LineReporte Técnicoa. Crear una matriz (Figura 7) con los nombres de los patrones en los títulosde las columnas y los drivers arquitectónicos listados en el lado izquierdo.Usar la matriz para analizar las ventajas y desventajas (pros y contras) deaplicar cada patrón para cada driver arquitectónico.Ejemplo de matriz de selección de patrones alternativos, en este caso, para elpatrón subordinado de Reinicio que pertenece a la táctica Prevención a fallos.Figura 7. Matriz de selección de patrones recuperación afallosLaactualizaciónde peticionesde servicio sepuede ignorarmáximo 2 seg.Cold restartpros contrasPérdidadelservicioTiempomuerto 2minutosPatrones alternativosWarm standbyMaster/MasterproscontrasproscontrasTiempo No esTiempo Difícilmuerto probable muertode 0.03 que se 50 ms aplicarseg.pierda elservicio No seFácilpierdedeelaplicarservicio.Load sharingproscontrasTiempoDifícilmuerto de50 msaplicarNo sepierde elservicioLas peticionesde servicios deconsulta debenserrespondidas en3 segundosmásConsiderar lo siguiente al hacer la selección: ¿Qué beneficios se esperan cuando se usa cada patrón?¿Cómo hacer la mejor combinación de patrones entre sí?¿Son mutuamente exclusivos todos los patrones?b. Elegir los patrones que logren satisfacer juntos los drivers arquitectónicos.De acuerdo al ejemplo de la matriz de selección de patrones alternativos, eldriver arquitectónico requiere un tiempo de reinicio para recuperarse a unfallo máximo de 2 segundos, se puede apreciar que cold restart no esapropiado. Por otro lado master/master y load sharing, se desecharon13/41
Attribute Driven Design y Software Product LineReporte Técnicodebido a que su aplicación es más compleja. Asimismo warm standbycumple fácilmente con el requerimiento, por lo que es el patrón elegido.Lo anterior implica que se tendrá un componente primario que recibirá laspeticiones y efectuará las respuestas. Adicionalmente, se contará con uncomponente secundario que será cargado en otro procesador y realizará lasmismas acciones.4.4 Considerar la identificación de patrones que se tenga hasta elmomento y decidir cómo se relacionan con los otros.La combinación de patrones seleccionados dará como resultado un nuevopatrón.a. Decidir cómo son relacionados los tipos de elementos desde variospatrones.b. Decidir qué tipos de elementos desde varios patrones son relacionados.c. Tomar en cuenta la funcionalidad y uso como un indicador para cadacombinación de patrones.d. Identificar nuevos tipos de elementos que resultan de la combinación depatrones.e. Revisar la lista de decisiones de diseño y confirmar que se han hechotodas las decisiones relevantes.4.5 Describir los patrones seleccionados para iniciar la documentaciónde las diferentes vistas arquitectónicas.No se necesita crear completamente las vistas arquitectónicas documentadashasta este punto. Documentar cualquier información que de seguro senecesitará sobre la arquitectura (incluyendo lo que se sabe sobre laspropiedades de los diferentes tipos de elementos). Idealmente se deben usarformatos de vistas para capturar esta información.Una de las vistas que se puede crear es la vista funcional (ver Figura 8) delos elementos y las relaciones entre ellos, que hasta el momento se tienenidentificados. Otra vista que en este punto se puede capturar es un diagramade secuencia.14/41
Attribute Driven Design y Software Product LineReporte TécnicoFigura 8. Vista funcional de elementos de software en la arquitectura y surelación, de acuerdo a los elementos identificadosFuente: A Practical Example of Appliying Attribute-Driven Design (ADD) Ver. 2.0SEI – Carnegie Mellon. William G. wood4.6 Evaluar y resolver inconsistencias en el diseño conceptual.En esta parte el arquitecto puede construir modelos para describir elcomportamiento del sistema.Las tareas iniciales de la evaluación de inconsistencias son:a. Evaluar el diseño contra los drivers arquitectónicos. Si es necesario,usar patrones, experimentos, simulaciones, análisis formal y métodos deevaluación de arquitecturas.b. Determinar si hay algún driver arquitectónico que no fue considerado.c. Evaluar patrones alternativos o aplicar tácticas adicionales, si el diseñono satisface los drivers arquitectónicos.d. Evaluar el diseño del elemento actual contra el diseño de otroselementos en la arquitectura y resolver cualquier inconsistencia. Porejemplo, mientras se diseña cualquier elemento, quizá se descubranciertas propiedades que deberían ser difundidas para otros elementosen la arquitectura.15/41
Attribute Driven Design y Software Product LineReporte TécnicoLas decisiones de diseño tomadas durante el paso 4 son:a. Decidir sobre un conjunto de conceptos que incluyan el mayor tipo deelementos que aparecerán en la arquitectura y el tipo de relacionesentre ellos.b. Tener identificada alguna de la funcionalidad asociada con los diferentestipos de elementos.c. Conocer cómo y cuándo los tipos de elementos de software se mapeanel uno al otro (estática o dinámicamente).d. Pensar en la comunicación entre los diferentes tipos de elementos(elementos internos de software y entidades externas).Considerar además: Qué tipo de elementos necesitan comunicarse con otroQué clase de mecanismos y protocolos serán usados por lacomunicación entre los elementos de software y entidades externas(síncrona, asíncrona, híbrida acoplada, o llamada remota contra llamadalocal)Las propiedades de los mecanismos que serán usadas para lacomunicación entre los elementos de software y las entidades externas(síncrona, asíncrona, híbrida acoplada, capacidad de cola yconfiabilidad)Atributos de calidad de requerimientos asociados con los mecanismosde comunicaciónLos patrones de datos sobre las dependencias de comunicaciónLos tipos de elementos computacionales que soportan las diferentescategorías de uso del sistemaCómo los componentes heredados y componentes que están fuera(COTS) serán integrados en el diseño.Hasta aquí se tiene razonado sobre los elementos de software y recursos delsistema, pero quizás se tienen decisiones diferidas a cerca de ellos. Para esose debe considerar: Qué recursos son requeridos por los elementos de software.Qué recursos necesitan ser administrados.Los límites de los recursos.Cómo serán administradas los recursos.Qué estrategias de calendarización serán empleadas.Qué elementos son de estado.Los mejores modos de operación.16/41
Attribute Driven Design y Software Product LineReporte TécnicoHasta aquí se tienen pensadas las dependencias entre los diferentes tipos deelementos internos de software pero quizás se tienen también decisionesdiferidas a cerca de éstas. Para ello se debe considerar: Qué dependencias de ejecución existen entre elementos.Cómo y dónde son resueltas las dependencias de ejecución entreelementos.La activación y desactivación de dependencias entre elementos desoftware.Se debería incluso considerar lo siguiente: Los mecanismos de abstracción utilizados.Qué elementos del sistema se conocen a la fecha.Qué modelos proceso/hilos será empleados.Cómo serán dirigidos los requerimientos de atributos de calidad.5. Instanciar los elementos arquitectónicos y asignar responsabilidades.En esta etapa se muestra como los elementos de diseño serán instanciadospara usar los drivers arquitectónicos funcionales. Los requerimientosfuncionales ayudan a determinar grupos o instancias de elementos específicosde diseño.Los drivers funcionales son derivados de los requerimientos funcionalesabstractos (por ejemplo las características) o de requerimientos funcionalesconcretos (casos de uso o lista de responsabilidades).Actividades a seguir en este paso: Asignar los requerimientos funcionales del elemento padre a loselementos hijo.Definir responsabilidades de los elementos hijo (ver Figura 9, ejemplode responsabilidades del proxy con health monitor).Descubrir el intercambio necesario de información entre elementos,creando una relación productor/consumidor.Especificar interacciones entre elementos (llamadas, suscripciones ay notificaciones).Representar la arquitectura con vistas.17/41
Attribute Driven Design y Software Product LineReporte TécnicoFigura 9. Ejemplo de responsabilidades del proxy con health monitorDescripción de Health MonitorEl Health Monitor utiliza un temporizador paracomprobar si ha recibido o no una señal de la A, B,A’, y B’. Si no recibe una señal antes de que eltemporizador expire, lo notificará al proxyFuente: A Practical Example of Appliying Attribute-Driven Design (ADD) Ver. 2.0SEI – Carnegie Mellon. William G. woodEn este paso se le asignan responsabilidades2 a los elementosinstanciados. Al finalizar este paso, cada elemento funcional asociado a unelemento padre debe ser representado por medio de responsabilidadesdentro de los elementos hijo.Se puede considerar realizar casos de uso que ayuden a identificar nuevasresponsabilidades o nuevos tipos de elementos.Otra tarea que se realiza en este paso es crear instancias de elementospara cubrir responsabilidades de atributos de calidad asignadas a unelemento o para lograr otro atributo de calidad de requerimientos.Para analizar y documentar las decisiones de diseño que se toman en estepaso se elaboran las siguientes vistas: 2Vistas de módulosVistas de deploymentVistas de componentes y conectores.La responsabilidad de un elemento es la funcionalidad, dato o información que debe proporcionar.18/41
Attribute Driven Design y Software Product LineReporte TécnicoLas vistas de módulo son usadas para documentar las propiedades que noson de tiempo de ejecución de un sistema; por ejemplo, modificability.Las vistas de asignación son usadas para analizar las relaciones entre loselementos de software y los que no lo son. Por ejemplo, cómo loselementos de software serán asignados a los elementos de hardware.Las vistas de componentes y conectores son usadas para documentarcomportamientos de tiempo de ejecución y propiedades de un sistema. Porejemplo, cómo interactuarán los elementos con otros en tiempo deejecución para encontrarse con varios requerimientos y qué característicasde desempeño deberían mostrar esos elementos.Las decisiones de diseño que se analizan en general para elaborar lasvistas mencionadas anteriormente son las siguientes: Cómo serán instanciados cada tipo de elementos y qué propiedadesindividuales y relaciones estructurales tendrán.Qué elementos computacionales serán usados para soportar lasdiferentes categorías que usa el sistema.Qué elementos soportarán los mayores modos de operación.Cómo han sido satisfechos los atributos de calidad de los requerimientosdentro de la infraestructura y aplicaciones.Cómo es dividida y asignada la funcionalidad a elementos de software,incluyendo cómo es asignada la funcionalidad cruzando lainfraestructura y aplicaciones.Cómo son mapeados los elementos de software con otros.Comunicación entre los diferentes elementos (elementos internos desoftware y entidades externas).Elementos internos de software y recursos del sistema.Dependencias entre los elementos internos de software.Cómo son usados los mecanismos de abstracción.Cuántos elementos del sistema se conocen a la fecha.Qué modelo será empleado (proceso / hilos).Cómo serán direccionados los atributos de calidad de losrequerimientos.6. Definir interfaces para elementos instanciados.En este paso se definen los servicios y propiedades requeridas y otorgadas porlos elementos de software en el diseño.Una interfaz incluye alguno de los siguientes elementos:19/41
Attribute Driven Design y Software Product Line Reporte TécnicoSintaxis de operaciónSemántica de operación (describe pre y post condiciones,restricciones)Información intercambiada (eventos señalados, datos globales)Atributos de calidad de los requerimientos de elementos individualesu operacionesManejo de erroresEn este paso se realizan los siguientes tres subpasos: Utilizar los requerimientos funcionales que involucran a los elementosinstanciados en el paso 5. Observar cualquier operación que es producida por algún elemento yconsumida por otro. Considerar las interfaces desde la perspectivade diferentes vistas. Por ejemplo, una vista de módulo permitiráanalizar el flujo de información. Registrar lo encontrado en la documentación de interfaz para cadaelemento.Algunas de las decisiones de diseño que se hacen en este pasoinvolucrarán varios puntos como los siguientes: Las interfaces externas para el sistema.Las interfaces entre particiones de alto nivel del sistema.Las interfaces entre aplicaciones dentro de particiones de alto niveldel sistema.Las interfaces para la infraestructura.7. Verificar y refinar los requerimientos y aplicar las restricciones a loselementos instanciados.En este paso se realizan los siguiente subpasos: Verificar que todos los requerimientos funcionales, requerimientos deatributos de calidad y decisiones de diseño asignadas al elementopadre se han asignado a uno o más elementos hijo en ladescomposición. Trasladar cualquier responsabilidad que fue asignada al elementohijo dentro de los requerimientos funcionales para los elementosindividuales.20/41
Attribute Driven Design y Software Product LineReporte Técnico Refinar los requerimientos de atributos de calidad para un elementoindividual hijo tanto como sea necesario. Los escenarios de calidadson refinados. Si un escenario de calidad no es satisfecho con la actualdescomposición, se debe valorar la importancia de dicho escenariopara reconsiderar su descomposición.En este
En el presente reporte se realizará un análisis del método ADD y su aplicación en Software Product Line, con el objetivo de buscar si se pueden obtener desde la fase de diseño arquitecturas reutilizables y modificables que den como resultado productos de software diferentes a partir de una arquitectura base. 1.2 Contenido del Reporte Técnico
