Entries by 'Julien Delange'

Managing Model Complexity

Architecture , Model-Based Engineering No Comments »

By Julien Delange
Member of the Technical Staff
Software Solutions Division

Julien Delange Over the years, software architects and developers have designed many methods and metrics to evaluate software complexity and its impact on quality attributes, such as maintainability, quality, and performance. Existing studies and experiences have shown that highly complex systems are harder to understand, maintain, and upgrade. Managing software complexity is therefore useful, especially for software that must be maintained for many years. To generate the complexity metrics, tools extract applicable data—such as source lines of code, cohesion, coupling, and more—from binary or source code to analyze the software and report its complexity and quality. Several tools support these techniques and help stakeholders manage the evolution of system development, provide quality improvements, prevent lack of cohesion, and perform other tasks. To date, such approaches have been successfully used in many projects, but as system development moves toward model-based engineering, these methods, metrics, and tools might not be sufficient to manage model complexity. This blog post details the state of the art for reporting model complexity and introduces research underway at the SEI in this area.

Read more...

Code Generation with AADL: A State-of-the-Art Report

Architecture , Architecture Analysis & Design Language (AADL) No Comments »

By Julien Delange 
Member of the Technical Staff
Software Solutions Division

Dr. Julien DelangeGiven that up to 70 percent of system errors are introduced during the design phase, stakeholders need a modeling language that will ensure both requirements enforcement during the development process and the correct implementation of these requirements. Previous work demonstrates that using the Architecture Analysis & Design Language (AADL) early in the development process not only helps detect design errors before implementation, but also supports implementation efforts and produces high-quality code. Our latest blog posts anda recent webinar have shown how AADL can identify potential design errors and avoid propagating them through the development process. Verified specifications, however, are still implemented manually. This manual process is labor intensive and error prone, and it introduces errors that might break previously verified assumptions and requirements. For these reasons, code production should be automated to preserve system specifications throughout the development process. This blog post summarizes different perspectives on research related to code generation from architecture models. 

Read more...

Architecture Analysis Using AADL: A Beginner’s Perspective

Architecture , Architecture Analysis & Design Language (AADL) No Comments »

By Julien Delange
Member of the Technical Staff
Software Solutions Division

Julien Delang

Introducing new software languages, tools, and methods in industrial and production environments incurs a number of challenges. Among other necessary changes, practices must be updated, and engineers must learn new methods and tools. These updates incur additional costs, so transitioning to a new technology must be carefully evaluated and discussed. Also, the impact and associated costs for introducing a new technology vary significantly by type of project, team size, engineers’ backgrounds, and other factors, so that it is hard to estimate the real acquisition costs. A previous post in our ongoing series on the Architecture Analysis and Design Language (AADL) described the use of AADL in research projects (such as System Architectural Virtual Integration (SAVI)) in which experienced researchers explored the language capabilities to capture and analyze safety-critical systems from different perspectives. These successful projects have demonstrated the accuracy of AADL as a modeling notation. This blog post presents research conducted independently of the SEI that aims to evaluate the safety concerns of several unmanned aerial vehicle (UAV) systems using AADL and the SEI safety analysis tools implemented in OSATE.

Read more...

Specifying Behavior with AADL

Architecture , Architecture Analysis & Design Language (AADL) 5 Comments »

By Julien Delange
Member of the Technical Staff
Software Solutions Division

Julien Delange The Architecture Analysis and Design Language (AADL) is a modeling language that, at its core, allows designers to specify the structure of a system (components and connections) and analyze its architecture. From a security point of view, for example, we can use AADL to verify that a high-security component does not communicate with a low-security component and, thus, ensure that one type of security leak is prevented by the architecture. The ability to capture the behavior of a component allows for even better use of the model. This blog post describes a tool developed to support the AADL Behavior Annex and allow architects to import behavior from Simulink (or potentially any other notation) into an architecture model.

Read more...

Detecting Architecture Traps and Pitfalls in Safety-Critical Software

Architecture , Architecture Analysis & Design Language (AADL) No Comments »

By Julien Delange
Member of the Technical Staff   
Software Solutions Division

Julien Delange Safety-critical avionics, aerospace, medical, and automotive systems are becoming increasingly reliant on software. Malfunctions in these systems can have significant consequences including mission failure and loss of life. So, they must be designed, verified, and validated carefully to ensure that they comply with system specifications and requirements and are error free. In the automotive domain, for example, cars contain many electronic control units (ECU)—today’s standard vehicle can contain up to 30 ECUs—that communicate to control systems such as airbag deployment, anti-lock brakes, and power steering. The design of tightly-coupled software components distributed across so many nodes may introduce problems, such as early or late data delivery, loss of operation, or concurrent control of the same resource. In addition, errors introduced during the software design phase, such as mismatched timing requirements and values beyond boundaries, are propagated in the implementation and may not be caught by testing efforts. If these problems escape detection during testing, they can lead to serious errors and injuries, as evidenced by recent news reports about problems with automotive firmware. Such issues are not specific to a particular domain and are very common in safety-critical systems. In fact, such problems are often found when reviewing code from legacy systems designed and built more than 20 years ago and still operating, as in the avionics and aerospace domains. This blog post describes an effort at the SEI that aims to help engineers use time-proven architecture patterns (such as the publish-subscribe pattern or correct use of shared resources) and validate their correct application.

Read more...