2 Position

We are interested in component-based system architecture, architecture description environments and supporting tools.

Architecture level design considerations become significant when software systems grow larger and more complex [GaSh93,ShGa96]. Important issues include descriptions of components which constitute the system architecture and relations among these components, i.e. the way these components are connected to build the system. It has been recognized that designers follow some idiomatic patterns [ShGa96,Shaw95a,Shaw95b], e.g. pipes-filters [Bach86], client-server [Bers92], etc., during system design. These patterns are usually accompanied by box-and-line diagrams that depict the intended system architecture. However, the interpretation of box-and-line diagrams is highly informal and highly specific to the design team, and to the described system. In addition, it is hard to decompose an element, particularly a line, in a box-and-line diagram. As a result, the architecture is poorly understood by developers when the system grows larger and more complex. It also hampers attempts at making system design knowledge explicit and easy to reuse [GAO95,CoLu95,DeCo95].

The jigsaw patterns technique, as illustrated in Figure 1, can overcome these problems of box-and-line diagrams. In Figure 1, the component C1 could be a source or a sink process. It has room for one inward stub corresponding to one interface interacting with one connector. The connector $Con\_C1\_C2$ is a pipe (or channel ). $Con\_C1\_C2$ is able to connect with two components via the two interfaces, i.e. outward stubs, which are implemented in the connector. Finally, the component C2 is a filter . It has room for two inward stubs corresponding to two interfaces interacting with two connectors. The picture could be completed to a producer/consumer system by adding a pipe connector to C2 and a component similar to C1.

Figure 1. Jigsaw patterns

The notation allows hierarchical decomposition because each component or connector of the system can be treated as a new system to be given an architecture using a finer grained jigsaw .

The general discipline is: An inward stub uses services and an outward stub provides services. Thus, Components do not implement interfaces, i.e. they do not have outward stubs graphically. Connectors do not use interfaces, i.e. they do not use access functions. The rationale for this discipline is to reduce the agenda in the design activity and provide syntactic criteria for classifying a module as a connector or a component.

In some cases, a connector uses the standard linkage convention to glue an object (e.g. in C++ and Java programs), see Figure 2. We call this connector an Application module. This, in fact, reflects the ability of composition, decomposition and evolution of jigsaw patterns .

Figure 2. Illustration of an Application module

In the following, we shall give the semantics of jigsaw patterns in terms of ML. An interface is expressed by a signature. A connector or a component is expressed by a structure, or a structure generator functor if it is generic.