A Taxonomy for Design Decisions in Software Architecture Documentation

A software system is the result of all design decisions that were made during development and maintenance. Documentation, such as software architecture documentation, captures a variety of different design decisions. Classifying the kinds of design decisions facilitates various downstream tasks by enabling more targeted analyses. In this paper, we propose a taxonomy for design decisions in software architecture documentation to primarily support consistency checking. Existing taxonomies about design decisions have different purposes and do not fit well because they are too coarse. We take an iterative approach, starting with an initial taxonomy based on literature and considerations regarding consistency checking. Then, we mine open-source repositories to extract 17 software architecture documentations that we use to refine the taxonomy. We evaluate the resulting taxonomy with regard to purpose, structure, and application. Additionally, we explore the automatic identification and classification of design decisions in software architecture documentation according to the taxonomy. We apply different machine learning techniques, such as Logistic Regression, Decision Trees, Random Forests, and BERT to the 17 software architecture documentations. The evaluation yields a F1-score of up to 92.1% for identifying design decisions and a F1-score of up to 55.2% for the classification of the kind of design decision

Detecting Inconsistencies in Software Architecture Documentation Using Traceability Link Recovery

Documenting software architecture is important for a system’s success. Software architecture documentation (SAD) makes information about the system available and eases comprehensibility. There are different forms of SADs like natural language texts and formal models with different benefits and different purposes. However, there can be inconsistent information in different SADs for the same system. Inconsistent documentation then can cause flaws in development and maintenance. To tackle this, we present an approach for inconsistency detection in natural language SAD and formal architecture models. We make use of traceability link recovery (TLR) and extend an existing approach. We utilize the results from TLR to detect unmentioned (i.e., model elements without natural language documentation) and missing model elements (i.e., described but not modeled elements). In our evaluation, we measure how the adaptations on TLR affected its performance. Moreover, we evaluate the inconsistency detection. We use a benchmark with multiple open source projects and compare the results with existing and baseline approaches. For TLR, we achieve an excellent F1-score of 0.81, significantly outperforming the other approaches by at least 0.24. Our approach also achieves excellent results (accuracy: 0.93) for detecting unmentioned model elements and good results for detecting missing model elements (accuracy: 0.75). These results also significantly outperform competing baselines. Although we see room for improvements, the results show that detecting inconsistencies using TLR is promising

Design as exploring constraints

Thesis (Ph. D.)--Massachusetts Institute of Technology, Dept. of Architecture, 1986.MICROFICHE COPY AVAILABLE IN ARCHIVES AND ROTCHBibliography: leaves 139-143.by Mark Donald Gross.Ph.D

Exploring Blockchain Adoption Supply Chains: Opportunities and Challenges

Excerpt from the Proceedings of the Nineteenth Annual Acquisition Research SymposiumThe 2018 release of the DoD’s Digital Engineering (DE) strategy and the success of applying DE methods in the mechanical and electrical engineering domains motivate application of DE methods in other product development workflows, such as systems and/or software engineer-ing. The expected benefits of this are improved communication and traceability with reduced rework and risk. Organizations have demonstrated advantages of DE methods many times over by using model-based design and analysis methods, such as Finite Element Analysis (FEA) or SPICE (Simulation Program with Integrated Circuit Emphasis), to conduct detailed evaluations earlier in the process (i.e., shifting left). However, other domains such as embedded computing resources for cyber physical systems (CPS) have not yet effectively demonstrated how to in-corporate relevant DE methods into their development workflows. Although there is broad sup-port for SysML and there has been significant advancement in specific tools, e.g., MathWorks®, ANSYS®, and Dassault tool offerings, and standards like Modelica and AADL, the DE benefits to CPS engineering have not been broadly realized. In this paper, we will explore why CPS devel-opers have been slow to embrace DE, how DE methods should be tailored to achieve their stakeholders’ goals, and how to measure the effectiveness of DE-enabled workflows.Approved for public release; distribution is unlimited

Digital Engineering Effectiveness

Excerpt from the Proceedings of the Nineteenth Annual Acquisition Research SymposiumThe 2018 release of the DoD’s Digital Engineering (DE) strategy and the success of applying DE methods in the mechanical and electrical engineering domains motivate application of DE methods in other product development workflows, such as systems and/or software engineer-ing. The expected benefits of this are improved communication and traceability with reduced rework and risk. Organizations have demonstrated advantages of DE methods many times over by using model-based design and analysis methods, such as Finite Element Analysis (FEA) or SPICE (Simulation Program with Integrated Circuit Emphasis), to conduct detailed evaluations earlier in the process (i.e., shifting left). However, other domains such as embedded computing resources for cyber physical systems (CPS) have not yet effectively demonstrated how to in-corporate relevant DE methods into their development workflows. Although there is broad sup-port for SysML and there has been significant advancement in specific tools, e.g., MathWorks®, ANSYS®, and Dassault tool offerings, and standards like Modelica and AADL, the DE benefits to CPS engineering have not been broadly realized. In this paper, we will explore why CPS devel-opers have been slow to embrace DE, how DE methods should be tailored to achieve their stakeholders’ goals, and how to measure the effectiveness of DE-enabled workflows.Approved for public release; distribution is unlimited

Supporting the grow-and-prune model for evolving software product lines

207 p.Software Product Lines (SPLs) aim at supporting the development of a whole family of software products through a systematic reuse of shared assets. To this end, SPL development is separated into two interrelated processes: (1) domain engineering (DE), where the scope and variability of the system is defined and reusable core-assets are developed; and (2) application engineering (AE), where products are derived by selecting core assets and resolving variability. Evolution in SPLs is considered to be more challenging than in traditional systems, as both core-assets and products need to co-evolve. The so-called grow-and-prune model has proven great flexibility to incrementally evolve an SPL by letting the products grow, and later prune the product functionalities deemed useful by refactoring and merging them back to the reusable SPL core-asset base. This Thesis aims at supporting the grow-and-prune model as for initiating and enacting the pruning. Initiating the pruning requires SPL engineers to conduct customization analysis, i.e. analyzing how products have changed the core-assets. Customization analysis aims at identifying interesting product customizations to be ported to the core-asset base. However, existing tools do not fulfill engineers needs to conduct this practice. To address this issue, this Thesis elaborates on the SPL engineers' needs when conducting customization analysis, and proposes a data-warehouse approach to help SPL engineers on the analysis. Once the interesting customizations have been identified, the pruning needs to be enacted. This means that product code needs to be ported to the core-asset realm, while products are upgraded with newer functionalities and bug-fixes available in newer core-asset releases. Herein, synchronizing both parties through sync paths is required. However, the state of-the-art tools are not tailored to SPL sync paths, and this hinders synchronizing core-assets and products. To address this issue, this Thesis proposes to leverage existing Version Control Systems (i.e. git/Github) to provide sync operations as first-class construct

Exploring Blockchain Adoption Supply Chains: Opportunities and Challenges

Excerpt from the Proceedings of the Nineteenth Annual Acquisition Research SymposiumThe 2018 release of the DoD’s Digital Engineering (DE) strategy and the success of applying DE methods in the mechanical and electrical engineering domains motivate application of DE methods in other product development workflows, such as systems and/or software engineer-ing. The expected benefits of this are improved communication and traceability with reduced rework and risk. Organizations have demonstrated advantages of DE methods many times over by using model-based design and analysis methods, such as Finite Element Analysis (FEA) or SPICE (Simulation Program with Integrated Circuit Emphasis), to conduct detailed evaluations earlier in the process (i.e., shifting left). However, other domains such as embedded computing resources for cyber physical systems (CPS) have not yet effectively demonstrated how to in-corporate relevant DE methods into their development workflows. Although there is broad sup-port for SysML and there has been significant advancement in specific tools, e.g., MathWorks®, ANSYS®, and Dassault tool offerings, and standards like Modelica and AADL, the DE benefits to CPS engineering have not been broadly realized. In this paper, we will explore why CPS devel-opers have been slow to embrace DE, how DE methods should be tailored to achieve their stakeholders’ goals, and how to measure the effectiveness of DE-enabled workflows.Approved for public release; distribution is unlimited

M2: An architectural system for computer design

The number of embedded computer systems has been growing rapidly as system costs have declined and capabilities have increased. The rationale behind design decisions for embedded systems is often informal and based on estimates of key values rather than actual measurements. Because of the small number of programs typically executed by an embedded processor, significant opportunities for optimization exist;M2 is an architectural system for computer design. It consists of language tools, architectural tools, and implementation tools. The language tools gather information about programs at compile time and at execution time. This information is used by the implementation tools to generate candidate processor implementations which are evaluated with the architectural tools. The evaluation involves comparing the size, speed, power, cost, and reliability of candidates to constraints set by the M2 user;An M2 design is based on actual program measurements and is documented so its derivation can be publicly considered. It is generated in less time and with fewer errors than manual methods;The M2 project is an extension of work being performed at Stanford University on a workbench for computer architects and of work being performed at the University of Southwestern Louisiana on plausibility-driven design