Quality-Based Software Reuse

Abstract

Abstract. Work in software reuse focuses on reusing artifacts. In this context, finding a reusable artifact is driven by a desired functionality. This paper proposes a change to this common view. We argue that it is possible and necessary to also look at reuse from a non-functional (quality) perspective. Combining ideas from reuse, from goal-oriented requirements, from aspect-oriented programming and quality management, we obtain a goal-driven process to enable the quality-based reusability.

Método Sistêmico com Suporte em GORE para Análise de Conformidade de Requisitos não Funcionais Implementados em Software

“…O arcabouço do XML é apresentado no APÊNDICE A e nele estão registradas as estruturas para a definição de patterns do RNF decomposto e relacionado a partir das atividades A1 e A2, dessa forma é estabelecido um padrão para tratamento de conformidades e não conformidades entre um software a ser analisado e as regras definidas no catálogo. O uso do arcabouço XML tem como objetivo possibilitar o reuso do conhecimento sobre RNF [45]. As estruturas em XML dos padrões são mantidas, independente do software analisado, e o ponto de variabilidade encontra-se na configuração do arcabouço XML com a customização dos conteúdos das tags dos padrões dependendo do domínio de aplicação do catálogo.…”

Configuring features with stakeholder goals

“…Our system is indeed implemented with 8 major components, namely, the goal model graph editor (OME.jar), the Portable Network Graph JComponent painter (PNG.jar), the Telos parser and knowledge base (jtelos.jar) [21], the Q7 language parser and i* code generator (Q7.jar) [18], the graph layout tool (grappa1 2 .jar) [10], the Ontology query tool (protege query.jar), the Ontology editor (protege.jar) [22], the feature model editor (fmp 0.6.6.jar) and the goal reasoning tool (GR-tool .jar) [11]. Inside the graph editor OME.jar, 3 major sub-components (that correspond to the Model-View-Controller pattern) can be further identified.…”

Aspects across Software Life Cycle: A Goal-Driven Approach

“…The syntax of the language is designed to facilitate the reuse of solutions in the non-functional domains [18]. The semantic domain is formally depicted in GRL [12].…”

“…In Q7, such information is placed inside square brackets as topics of the goals or softgoals. For example, when the system meets the media shop's "Front [page]" goal, it also makes (++) major top-level softgoals ("⇒"), such as "Security [18], and those to the who question attribute a goal to an encapsulating module. In the i * terminology [44], such a module is called an actor that either processes or delegates a goal or a task to other actors via strategic dependencies.…”

“…All matched goals are therefore the join points of the aspect. A weaving algorithm at the requirements level [18] has been implemented in the OpenOME modeling tool [28] to identify the join points and attach the advising tasks as siblings to the join point tasks. Both join point tasks and advising tasks then share the same parent, which is called the weaved goal.…”