Feature-Oriented Reflexion Modelling

Herold, Sebastian; Buckley, Jim

doi:10.1145/2797433.2797494

Cited by 5 publications

(4 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Browser proposed by Liu et al [25] and its Feature Modelling origins in the proposal for a tool called FORM, by Herold and Buckley [22]. The Dependency Browser is an Eclipse plugin that supports dependency searches on Java applications.…”

Section: Flints Has Its Feature Location Origins In the Dependencymentioning

confidence: 99%

“…FLINTS allows viewing of dependencies for a set of source code entities. The FORM tool suggested by Herold and Buckley, proposed the application of Reflexion Modelling [22] to the task of Feature modelling, leveraging the dependency insights that Reflexion Modelling provides to refine the feature's source code location and to help define the feature's interface. This aligns with the graphical representation provided by FLINTS.…”

Section: Flints Has Its Feature Location Origins In the Dependencymentioning

confidence: 99%

See 1 more Smart Citation

Flints

Buckley

Rosik

Herold

et al. 2016

Proccedings of the 10th European Conference on Software Architecture Workshops

Self Cite

View full text Add to dashboard Cite

Reflexion Modeling has been proposed as a means of creating and refining a functional model of software systems at the architectural level. Such a model allows developers to maintain a consistent understanding of the relationships between different functionalities of their system as it evolves, and allows them to analyze the system at a functional-chunk level rather than at the traditional, structural levels more typically presented by IDEs. This paper describes a prototype tool built to enable this approach. The tool assists developers in moving to this functional perspective by supporting them as they first attempt to locate specific functionalities in the code. This support is based on design principles identified by observing experienced software developers in-vivo, as they performed this task manually. After the code associated with several such functionalities is located in the code-base, a graphical view allows the developer to assess the source code dependencies between these features and between these features and the rest of the system. This helps the developer understand the inter-functional interfaces, and the representation can be reviewed over time, as features are added and removed, to ensure on-going consistency between the architect's perspective of the features in the system and the code-base.

show abstract

Section: Flints Has Its Feature Location Origins In the Dependencymentioning

confidence: 99%

Section: Flints Has Its Feature Location Origins In the Dependencymentioning

confidence: 99%

Flints

Buckley

Rosik

Herold

et al. 2016

Proccedings of the 10th European Conference on Software Architecture Workshops

Self Cite

View full text Add to dashboard Cite

show abstract

“…To facilitate the transition, automated unit tests that analyze the source code were introduced to ensure that the intended structure of packages in the architecture was not violated. These unit tests is one of many possible ways to perform Static Architectural Conformance Checking (SACC) [4,16,18,23,24,29,30,34].…”

Section: Introductionmentioning

confidence: 99%

“…They often rely on dependencies embedded in source code statements, and compare these with the desired and allowed dependencies in the software architecture. Methods such as Reflexion Models [4,16,23,24], Dependency Rules [29,30,34], and Dependency Structure Matrices [18] have been used to find and visualize architectural violations.…”

Section: Introductionmentioning

confidence: 99%

The relationship of code churn and architectural violations in the open source software JabRef

Olsson

Ericsson

Wingkvist

2017

Proceedings of the 11th European Conference on Software Architecture: Companion Proceedings

View full text Add to dashboard Cite

The open source application JabRef has been developed since 2003. In 2015, the developers decided to make an architectural refactoring as continued development was deemed too demanding. The developers also introduced Static Architecture Conformance Checking (SACC) to prevent violations to the intended architecture. Measurements mined from source code repositories such as code churn and code ownership has been linked to several problems, for example fault proneness, security vulnerabilities, code smells, and degraded maintainability. The root cause of such problems can be architectural. To determine the impact of the refactoring of JabRef, we measure the code churn and code ownership before and after the refactoring and find that large files with violations had a significantly higher code churn than large files without violations before the refactoring. After the refactoring, the files that had violations show a more normal code churn. We find no such effect on code ownership. We conclude that files that contain violations detectable by SACC methods are connected to higher than normal code churn. CCS CONCEPTS• Software and its engineering → Software architectures; Software verification and validation;

show abstract

Architecture consistency: State of the practice, challenges and requirements

Alí

Baker

O’Crowley³

et al. 2017

Empir Software Eng

Self Cite

View full text Add to dashboard Cite

Architecture Consistency (AC) aims to align implemented systems with their intended architectures. Several AC approaches and tools have been proposed and empirically evaluated, suggesting favourable results. In this paper, we empirically examine the state of practice with respect to Architecture Consistency, through interviews with nineteen experienced software engineers. Our goal is to identify 1) any practises that the companies these architects work for, currently undertake to achieve AC; 2) any barriers to undertaking explicit AC approaches in these companies; 3) software development situations where practitioners perceive AC approaches would be useful, and 4) AC tool needs, as perceived by practitioners. We also assess current commercial AC tool offerings in terms of these perceived needs. The study reveals that many practitioners apply informal AC approaches as there are barriers for adopting more formal and Empir Software Eng (2018) 23:224-258 DOI 10.1007 The original version of this article was revised due to a retrospective Open Access order. Karlstad University, Karlstad, Sweden explicit approaches. These barriers are: 1) Difficulty in quantifying architectural inconsistency effects, and thus justifying the allocation of resources to fix them to senior management, 2) The near invisibility of architectural inconsistency to customers, 3) Practitioners' reluctance towards fixing architectural inconsistencies, and 4) Practitioners perception that huge effort is required to map the system to the architecture when using more formal AC approaches and tools. Practitioners still believe that AC would be useful in supporting several of the software development activities such as auditing, evolution and ensuring quality attributes. After reviewing several commercial tools, we posit that AC tool vendors need to work on their ability to support analysis of systems made up of different technologies, that AC tools need to enhance their capabilities with respect to artefacts such as services and meta-data, and to focus more on non-maintainability architectural concerns.

show abstract

Feature-Oriented Reflexion Modelling

Cited by 5 publications

References 35 publications

Flints

Flints

The relationship of code churn and architectural violations in the open source software JabRef

Architecture consistency: State of the practice, challenges and requirements

Contact Info

Product

Resources

About