15 Years of Reuse Experience in Evolutionary Prototyping for the Defense Industry

Abstract

At Thales Defense Mission Systems, software products first go through an industrial prototyping phase. We elaborate evolutionary prototypes which implement complete business behavior and fulfill functional requirements. We elaborate and evolve our solutions directly with end-users who act as stake-holders in the products' design. Prototypes also serve as models for the final products development. Because software products in the defense industry are developed over many years, this prototyping phase is crucial. Therefore, reusing software is a high-stakes issue in our activities. Component-oriented development helps us to foster reuse throughout the life cycle of our products. The work presented in this paper stems from 15 years of experience in developing prototypes for the defense industry. We directly reuse component implementations to build new prototypes from existing ones. We reuse component interfaces transparently in multiple prototypes, whatever the underlying implementation solutions. This kind of reuse spans prototypes and final products which are deployed on different execution platforms. We reuse non-component legacy software that we integrate in our component architectures. In this case, we seamlessly augment standard classes with component behavior, while preserving legacy code. In this paper, we present our component programming framework with a focus on component reuse in the context of evolutionary prototyping. We report three scenarios of reuse that we encounter regularly in our prototyping activity.

Reuse in component-based prototyping: an industrial experience report from 15 years of reuse

“…Exploring design ideas through Concept prototyping [4,14] is one of the main activities at Thales DMS. We develop prototypes to communicate concepts to users, demonstrate the HMI usability and exhibit potential problems [10]. Moreover, we develop and maintain prototypes until they meet users expectations regarding not only the HMI, but also the main business functionalities.…”

“…Since 2005, Thales DMS use Smalltalk for prototyping. Our main motivations behind the choice of Smalltalk is the ability to quickly design and program complex prototypes, and the capabilities to lively change a design in the front of customers [9,10,17]. Since 2016, we use Pharo [7] with the Molecule component-oriented programming framework.…”

“…The integration of the Traits implementing the component contract with the original class may require some code adaptation. Typically, when we reuse classes from legacy software as components (e.g., a radar class), we have to adapt how the component's Type (i.e., it's business behavior) interacts with the class API (e.g., by converting the radar's accuracy from feet to meters [10]). This code adaptation ensures that the augmented class provides the correct level of information in regards with the requirements of the connected components.…”

“…We extend our previous work based on one industrial prototype [10] with the study of 23 additional prototypes resulting from 15 years of prototyping. We complete our analysis and discussions with these new data.…”