systems. A typical software engineering process groups the related activities into stages of requirements acquisition and analysis, design, implementation, testing and verification, deployment, and maintenance. The type of activities involved may vary from one system to another depending on the type of system and the development methodology used. For example, the activities involved in designing a safety critical system differs from those used to design a library classification system. Rigor must be applied in the former. Also, the design of a system using the object-oriented methodology differs from the design of the same system using procedural programming.
In order to achieve the benefits of component-based development (CBD), a component- based process must be used. The design of a component-based system differs than the de- sign of other types of systems. CBD is a reuse oriented process. Therefore, the development of reusable components and the integration of components to create systems are the main concerns in a CBD process. A major difference between conventional software engineer- ing process and a CBD process is that the former results in a software system, whereas the
later results in a software system as well as a system with reusable components [TGG07]. A typical component-based development process comprises two parallel activities: software component development and component-based system development [CCL06, Pre05]. The former addresses the issues of component’s specification, development, qualification, doc- umentation, cataloguing, and adaptation and selection for reuse. The later addresses the is- sues of assembling components to develop component-based systems. Several component- based process models exist in the literature [Chr95, DT03, TGG07, CCL06]. The follow- ing presents an overview of these process models highlighting their main features. The overview is arranged in a chronological order based on their presentation time.
In [Chr95], a reuse-based software development process model was presented. This process is based on the hypothesis that domain engineering is the foundation for a reuse- based software system development. A domain is a set of applications that share similar requirements, capabilities, and data. Domain engineering is the set of activities that create and support a model, architectures, components, and applications specific to the domain. The domain analysis defines the requirements that are common for all products in the do- main and the requirements that vary for each product. These requirements are used to de- velop a domain model that includes requirements of all products. From the domain model, a domain architecture is developed to form the basis for all domain products. The architec- ture is further refined to define the constituent reusable components. Domain applications are designed based on the domain architecture and developed by reusing existing domain components.
In [DT03], a component-oriented development process was presented. The process focusses on system development by integrating existing components. It is based on the
abstract design paradigm which suggests decomposing a system structure hierarchically
into components and associating data, functions, and controls to each component. A design modeler starts with system requirements and uses a recursive structural decomposition to arrive to the definition of composite or simple components. Then, activities of component specification, search, modification, or creation starts. After that, the system is built by integrating components.
In [CCL06] a process of three parallel tracks was presented: component development, component assessment, and system development. The activities in component assess- ment include finding and evaluating existing components. It yields a repository of com- ponents that includes the components’ specifications, descriptions, documented tests, and
executable components. In [TGG07] two independent processes are defined for component and system development.
Tables 3 and 4 provides a summary of the activities suggested in [Chr95, DT03, CCL06, TGG07] for both component and system development. Reviewing these models helps us to extrapolate the main activities involved in a general component-based development pro- cess, which can be extended with rigorous methods to define a component-based process for developing trustworthy systems.
2.5.1 Discussion
From the above summary and Tables 3 and 4, we find that there are four major activities involved in component-based development. These are domain engineering, component de-
velopment, component assessment, and system development. These activities are important,
however might not all be required at the same time. For example, it is possible to have a company which focuses only on developing and selling components. Therefore, there is neither domain engineering nor system development. On the other hand, there could be a company which has a domain engineering and system development but no component development because it buys the required components from others using the component as- sessment activities. Also, it is possible to have a single project which uses CBD; therefore, it requires component development and system development only. It is quite possible, how- ever, to have an enterprise which uses all the four types of activities for developing complex systems. Such examples may be found in avionics, automotive, and product-line develop- ment industries. Therefore, a component-based development process should address all
four types of activities.
Component assessment through testing and verification is an important factor for the success of reuse. The assessment should be done at a component level, in which the func- tional and nonfunctional requirements are tested and verified, and at a system level, in which composability tests are used to test the successful integration of reusable compo- nents. Integration testing should assess not only structural assembling but more impor- tantly nonfunctional requirements, specially unwanted properties that may emerge at sys- tem level but remain invisible at component level. In safety/security critical systems, the issue of emergent properties is critical. Integration may violate safety or security proper- ties. Verification of such properties is challenging [CCL06]. Therefore, a component-based
Table 3: A summary of the component and system development activities - Part 1
Phase Component Development System Development
Requirements Domain analysis is used to identify required com- ponents [Chr95]. The defined requirements should address ranges of require- ments and the possibility of reuse [TGG07].
In addition to require- ments acquisition, existing components’ information and documentation are reused [CCL06]. System requirements are captured and component requirements are defined to help in search- ing and selecting existing components [TGG07].
Analysis and De- sign
Assumptions are made about the environment in which the component will operate. A component technology is se- lected for components, such as .NET, J2EE, COM+, etc. The design should be gen- eral to enable reuse. Design adaptations to existing com- ponents to fit into the sys- tem [CCL06]. Detail com- ponent specification are de- signed including functional, structural, and nonfunctional specifications [TGG07].
The overall system architec- ture is designed. Then, the architecture is refined and the constituent components are identified and specified in de- tails [DT03, CCL06]. A component-oriented architec- ture is selected and compo- nents are identified. Detail design of new components is performed. Verification and validation of functionalities are conducted [TGG07].
Implementation The selected component technology determines the implementation de- tails [CCL06]. The methods and events of components are implemented [TGG07]. Reuse is encouraged when- ever possible.
The emphasis in implementa- tion is put on component selection and adapta- tion [DT03, CCL06]. Components must be as- sessed before reuse [CCL06]. New components are de- veloped and glue code is written [TGG07].
Table 4: A summary of the component and system development activities - Part 2
Phase Component Development System Development
Integration Integration considerations must be continuously in focus through all phases [CCL06].
Architectural matches should be tested, and functional and nonfunctional behavior should be verified thoroughly to insure successful integra- tion [CCL06]. Connectors are used to integrate compo- nents [DT03].
Testing Extensive tests such as unit and integration testing should be done to verify functional and nonfunctional require- ments. Test results should be delivered with the com- ponent to system develop- ers [CCL06].
Tests must be performed during component selection and integration [CCL06]. Integration, system, and acceptance testings are required [TGG07].
Maintenance Strategies should be defined for component mainte- nance [CCL06].
Replace old components by new ones or add new compo- nents into the system when- ever necessary [CCL06].
verification and testing techniques, in component development, assessment, and system integration to ensure a correct and trustworthy system behavior.
Since software requirements form the foundation from which the development process starts and quality attributes can be assessed, there is a need for a formal specification lan- guage that collectively and precisely define the software requirements related to functional, nonfunctional (such as trustworthiness), and structural parts of the software. The com- bination of rich formal specification language and a rigorous development process pro- vide a high assurance level of trustworthiness. Trustworthiness must be a central concern
throughout the different activities in the component and system life-cycle as depicted in
Figure 8. In every stage, established methods for the verification of trustworthiness are to be used. Iterative cycles exist between sequential phases to ensure that the trustworthi- ness requirements are satisfied. Although formal methods may seem complex and costly, they are inherently supported by automation tools. Therefore, a rich specification language
and tools support are essential for the success of the development process of trustworthy systems. Requirements Testing Design Verification of Trustworthiness Implementation Maintenance Deployment
Figure 8: Trustworthy development life-cycle