A Systematic Approach for Structuring Exception Handling in Robust Component-Based Software
This article addresses the systematic incorporation of exception handling into component-based systems. By "component-based", one can infer "object-oriented" since the use of libraries of classes, such ast STL and JCL, can be seen as the use of components, building blocks, while constructing large-scale software systems. Read this article in its entirety to get a sense of how to put exception handling to good use.
3. Background
3.3 A Typical Component-based Development Process
There are few CBD processes that have achieved some acceptance in the industry, compared to the large number of processes available for object-oriented development. This is not something to be surprised by. Although the first work proposing the use of "mass produced software components" dates back to more than 30 years ago, most research on the subject has appeared in the last ten years.
Figure 2 presents a typical component-based development process divided into six workflows: requirements, specification, provisioning, assembly (or integration), test, and deployment. The requirements workflow aims to identify the system requirements. The specification workflow structures the software architecture of the system as a set of abstract components that have specific responsibilities and interact to fulfil the system requirements.
The implementation of a component-based system is achieved by provisioning and assembly workflows. This is a consequence of the component development/system integration dichotomy described in Section 1. Components are instantiated during the provisioning workflow. In this workflow, the system integrator decides if an abstract component can be instantiated by an existing OTS component, or if it will require an implementation effort, in which case it is called a newly developed component. The selection of an OTS component often requires its adaptation and, possibly, the refinement of the system's software architecture to fit the available OTS component. This adaptation may include the development of wrappers to adapt the external interface of the OTS component to that specified for the abstract component being instantiated.
In the assembly workflow, the system integrator assembles OTS and newly developed components to build the whole system. This integration effort includes the development of glue code necessary to connect the various components, and comprises the specification and implementation of connectors and wrappers.
During the test workflow, the integrated system is tested and corrections may be made to ascertain that it fulfils its requirements and conforms to its specification. During the deployment workflow, the final system is installed in the environment of the user.