Improving system dependability by enforcing architectural intent (original) (raw)
Related papers
ArchJava: Connecting Software Architecture to Implementation
Software architecture describes the structure of a system, enabling more effective design, program understanding, and formal analysis. However, existing approaches decouple implementation code from architecture, allowing inconsistencies, causing confusion, violating architectural properties, and inhibiting software evolution. ArchJava is an extension to Java that seamlessly unifies software architecture with implementation, ensuring that the implementation conforms to architectural constraints. A case study applying ArchJava to a circuit-design application suggests that ArchJava can express architectural structure effectively within an implementation, and that it can aid in program understanding and software evolution.
JITTAC: A Just-in-Time tool for architectural consistency
2013 35th International Conference on Software Engineering (ICSE), 2013
Architectural drift is a widely cited problem in software engineering, where the implementation of a software system diverges from the designed architecture over time causing architecture inconsistencies. Previous work suggests that this architectural drift is, in part, due to programmers' lack of architecture awareness as they develop code. JITTAC is a tool that uses a real-time Reflexion Modeling approach to inform programmers of the architectural consequences of their programming actions as, and often just before, they perform them. Thus, it provides developers with Just-In-Time architectural awareness towards promoting consistency between the as-designed architecture and the as-implemented system. JITTAC also allows programmers to give real-time feedback on introduced inconsistencies to the architect. This facilitates programmer-driven architectural change, when validated by the architect, and allows for more timely team-awareness of the actual architectural consistency of the system. Thus, it is anticipated that the tool will decrease architectural inconsistency over time and improve both developers' and architect's knowledge of their software's architecture. The JITTAC demo is
Connecting Architecture and Implementation
Lecture Notes in Computer Science, 2009
Software architectures are still typically defined and described independently from implementation. To avoid architectural erosion and drift, architectural representation needs to be continuously updated and synchronized with system implementation. Existing approaches for architecture representation like informal architecture documentation, UML diagrams, and Architecture Description Languages (ADLs) provide only limited support for connecting architecture descriptions and implementations. Architecture management tools like Lattix, SonarJ, and Sotoarc and UML-tools tackle this problem by extracting architecture information directly from code. This approach works for low-level architectural abstractions like classes and interfaces in object-oriented systems but fails to support architectural abstractions not found in programming languages. In this paper we present an approach for linking and continuously synchronizing a formalized architecture representation to an implementation. The approach is a synthesis of functionality provided by code-centric architecture management and UML tools and higher-level architecture analysis approaches like ADLs.
A Language-based Approach to Specification and Enforcement of Architectural Protocols
2010
Software architecture research has proposed using protocols for specifying the interactions between components through ports. Enforcing these protocols in an implementation is difficult. This paper proposes an approach to statically reason about protocol conformance of an implementation. It leverages the architectural guarantees of the ArchJava programming language. The approach allows modular reasoning about implementations with callbacks, recursive calls, and multiple instances of component types. It uses a dataflow analysis to check method implementations and uses model checking techniques to reason modularly about component composition. The approach is limited to static architectures but can handle multiple instances for component types and arbitrary nesting of components.
Towards an Approach for Building Reliable Architectures
2007
Composing an application out of independent, reusable pieces has been a key challenge since the early days of software engineering. In this paper we examine some aspects of software architecture. We introduce our COSA+ model built in order to provide some enhancement in the COSA 1 one. Our main contributions are the new structure given to an explicit connector, and the conceptual view of the different abstract levels used to define the applications architectures. Profits expected from these improvements are numerous; mainly we can quote the reduction of the production costs and the time to market, simplify the maintenance operations, and foresee supports for the evolution of the software architecture.
2010
The ArchMapper approach allows performing two activities in the software development process efficiently: checking the conformance of the code to the intended architecture as specified by an architectural description, and generating code skeletons and architecture-related configuration files from the architectural description. Both directions exploit information based on the architectural style of the software system. An architectural style may be as simple as the style of layered architectures, or it may correspond to a specific middleware platform, which allows more specific analyses and generation. We have applied the approach to the style of the Spring MVC framework, where several architectural properties can be checked, and the Spring configuration file for the application may be automatically generated from the architectural description.
A Case Study on Improving Maintainability and Evolvability using Architectural Constraints
Developers usually rely on patterns and best practices to increase the quality of their projects. However, as projects evolve, it is usual to observe deviations in the use of the patterns and best practices defined during the initial design of a system. This article aims to illustrate the application of a static, domain-specific, and declarative dependency constraint language, called DCL, to express architectural patterns and design principles that contribute to the maintainability and evolvability – and therefore to the internal quality – of a software system. We present in the paper several architectural constraints that demonstrate the benefits achieved by DCL in one motivating system and in five real-world, open-source object-oriented applications.
JavaCompExt: Extracting Architectural Elements from Java Source Code
2009 16th Working Conference on Reverse Engineering, 2009
Software architecture erosion is a general problem in legacy software. Because they don't know or don't understand the original architectural intent, maintainers introduce changes that violate the intended architecture and properties. To fight this trend, component models and languages are designed to try to make explicit, and automatically enforceable, the architectural decisions in terms of components, interfaces, and allowed communication channels between component interfaces. But, what about existing systems written in traditional (e.g. object-oriented) languages? To help maintainers work on such systems, we explore the possibility of extracting architectural elements (components, communications, services, . . . ) from the source code. Some extraction heuristics are proposed and experimented on several implementations of a nontrivial system.
Component-based specification of software architecture constraints
Proceedings of the 14th international ACM Sigsoft symposium on Component based software engineering - CBSE '11, 2011
Component-based software engineering provides for developers the ability to easily reuse and assemble software entities to build complex software. Component-based specification of software functionality has been and is largely addressed, however this is not yet the case for what concerns software non-functionality. In this paper, we propose a new way to express component-based software non-functional documentation, and we will focus more specifically on architecture constraints which formalize parts of architecture decisions, as executable, customizable, reusable and composable building blocks represented by components. Checking of architecture constraints is provided via service invocation through ports of a special kind of components, called constraint-components. The signatures of these checking services can be defined in required interfaces of business components, to document decisions taken while designing their architecture. They can also be part of other required interfaces of constraint components, making it possible to build higher-level or more complex constraints while reusing existing ones. We present an example of implementation of constraint components using, an ADL which is introduced in this paper. Architecture constraints can then be checked on the architecture of business components at design-time using the CLACS tool support, which has been implemented as an Eclipse plugin.