Documenting Software Architectures Research Articles

Operation‐based approach for documenting software architecture knowledge

AbstractDocumenting architectural knowledge is a tedious and time‐consuming task from the knowledge producer's point of view. As a consequence, design decisions, the underlying rationale, and the resulting designs are poorly documented. We propose to alleviate this problem by introducing an operation‐based model for documenting software architecture design processes, which makes possible to capture architectural knowledge in a non‐intrusive way as the design process takes place. By means of a flexible model that makes possible the definition and execution of different level's operations, such as operations that enclose patterns and tactics semantics, we ensure codification of general architectural knowledge and enable its recovering to use it in several design projects. From the knowledge consumers' point of view, the model provides tracing capabilities and useful mechanisms for architectural knowledge recovering.

Two controlled experiments on model-based architectural decision making

ContextIn recent years, architectural design decisions are becoming more and more common for documenting software architectures. Rather than describing the structure of software systems, architectural decisions capture the design rationale and – often reusable – architectural knowledge. Many approaches and tools have been proposed in the literature to support architectural decision making and documentation (for instance, based on models, ontologies, or templates). In this context, the capturing, organization, and effective reuse of architectural knowledge has gained a lot of attention. ObjectiveHowever, there is little empirical evidence about the supportive effect of reusable architectural knowledge on the effectiveness and efficiency of architectural decision making. MethodTo investigate these aspects, we conducted two separate controlled experiments with software architecture students in which we tested the supportive effect of reusable decision models in decision making and documentation. ResultsOur results show that the use of reusable decision models can significantly increase both the efficiency and the effectiveness of novice architects. ConclusionWe can report, that our findings are in line with similar studies and support the claims regarding reusable architectural design decisions in principle.

Documenting Software Architectural Component and Connector with UML 2

Earlierversions of the UML have been an out of depth for documenting software architectures like component, port, connector and system. Users have adopted conventions for representing architectural concepts using different grouping of UML modeling element. They can also create profiles to focus the UML. Changes incorporated in UML 2 have improved UML’s suitability for software architectural documentation, but UML is still an out of your depth for documenting some types of architectural information. In this paper, there is description of documenting component and connector using UML but in particular case, documenting architectural connectors and components remains problematic.

Reverse Engineering for Documenting Software Architectures, a Literature Review

Recently, much research in software engineering focused on reverse engineering of software systems which has become one of the major engineering trends for software evolution. The objective of this survey paper is to provide a literature review on the existing reverse engineering methodologies and approaches for documenting the architecture of software systems. The survey process was based on selecting the most common approaches that form the current state of the art in documenting software architectures. We discuss the limitations of these approaches and highlight the main directions for future research and describe specific open issues for research.

Bridging the gap between software architecture rationale formalisms and actual architecture documents: An ontology-driven approach

Documenting software architecture rationale is essential to reuse and evaluate architectures, and several modeling and documentation guidelines have been proposed in the literature. However, in practice creating and updating these documents rarely is a primary activity in most software projects, and rationale remains hidden in casual and semi-structured records, such as e-mails, meeting notes, wikis, and specialized documents. This paper describes the TREx (Toeska Rationale Extraction) approach to recover, represent and explore rationale information from text documents, combining: (1) pattern-based information extraction to recover rationale; (2) ontology-based representation of rationale and architectural concepts; and (3) facet-based interactive exploration of rationale. Initial results from TREx’s application suggest that some kinds of architecture rationale can be semi-automatically extracted from a project’s unstructured text documents, namely decisions, alternatives and requirements. The approach and some tools are illustrated with a case study of rationale recovery for a financial securities settlement system.

Architectural description languages (ADLs) vs UML

The field of software architecture which is considered as a subfield of software engineering is now about two decades old. During this period a number of software Architecture Description Languages (ADLs) emerged and vanished. But none of the ADLs became much popular amongst the practitioners except a few, that too only in a specific domain. On the other hand Unified Modeling Language (UML) which some times is not even accepted as an ADL or accepted with a some hesitation has become an industry de facto standard notation for documenting software architectures. This paper makes an attempt to find an answer to this question as to what went wrong with the ADLs that they did not become much popular beyond their place of origin. Is UML really an Architecture Description Language.

On Designing Software Architectures.

As the size and complexity of software has rapidly grown during the past two decades, it has become a big challenge to assure quality of software and to curb the cost of developing software. Many ways have to be brought to bear in order to meet this challenge. One of them is the design and documentation of software architecture. In this article, I discuss various aspects of designing and documenting software architecture in order to provide some practical guides to software engineers.