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.2 Software Architecture
The architecture of a software system shows how the system is realized by a collection of components and the interactions among them. The building blocks of an architectural description are components, connectors, and architectural configurations. A component is a unit of computation or a data store. Therefore, components are loci of computation and state. Connectors are architectural building blocks used to model interactions among components and rules that govern those interactions. Architectural configurations, or topologies, are connected graphs of components and connectors that describe architectural structures.
The realization of abstract software architectures requires concrete implementations, which raises the question about conformance of an implementation to the intended architecture. To be effective, solutions at the architectural level must be correctly mapped to the implementation level. It is not trivial to guarantee this conformance, since there is a semantic gap between the abstractions defined by software architecture, namely, architectural components and connectors, and the abstractions supported by mainstream object-oriented programming languages, such as packages and classes. In this work, we have used a component implementation model, called COSMOS, to bridge the gap between the software architecture of the system and its implementation.
The COSMOS model integrates a set of design patterns and guidelines into the implementation of a component-based system. These guidelines include: materialization of architectural elements at runtime; separation of nonfunctional concerns; clear separation between component's specification and implementation; explicit declaration of component's specification dependencies; strong encapsulation of implementation; separation of code inheritance from types hierarchy and loose coupling of implementation classes.
When using COSMOS, each architectural component is mapped, at the implementation level, to a package containing two sub packages: (i) the specification package contains the specification of the component's provided and required interfaces; and (ii) the implementation package contains the definition of the concrete classes that implement the component's behaviour. Architectural connectors are mapped to connector packages that implement the connections between required and provided interfaces of interacting components.