The IMI Process

In Step 1 of the approach, the major architectural elements, i.e. component, connector, ports and constraints in CCA, are assumed to be composed of objects and their relationships. Mapping a CCA architecture to implementation elements is a key activity in this step. In this activity, how to realize these elements is considered based on the architectural elements identified. For connector, many implementation approaches can be applied. For example, to transfer a simple string from a class to another class, a string buffer can be used and to transfer complex data types from a process to another process, socket communication or middleware can be used. Depending on the implementation choices of connectors and components, implementation of the ports may become different. For instance, the use of middleware requires the ports to be the message sender instance or the message receiver instance of the middleware.
In Step 2, once the implementation elements per each architectural element have been decided, the functional and non-function requirements are distributed among architectural elements. Distributing non-functional requirements to architectural elements is not as simple as with functional requirements because quality attributes that represent non-functional requirements can be supported both implicitly and explicitly by the architectural elements. When an architectural element is used in order to support a specific quality attribute, the attribute can be assigned to the element.
Step 3 consists of three sub-steps. In Step 3A, for each functional requirement, objects that are needed to satisfy the requirement has to be identified. Of course, it is sufficient to identify the objects within the component boundary according to the baseline assumption of this approach. At the same time, the simple relationship between the objects can be considered briefly.
And in Step 3B, OO design patterns are considered. A design pattern gives us a generic solution that solves a family of recurring problems in a certain context [11]. The design patterns listed in Table 2 are the candidates that can provide a proven way to realize the architectural elements.
This step is required because OO design can be difficult without applying design patterns. Also, by considering proven design patterns before starting design developers can make better designs than by considering them later. Considering the quality attributes and requirements, the patterns that can be applied to the components for the Metadirectory system can be listed up as in Table 2.
Lastly, in Step 3C, the objects identified and the relationships between them are rearranged based on the selected design patterns. The basic method invocation sequence of an object can be determined from the design patterns and also the base-line of object relationships are rearranged based on the patterns.