UCI

The C2 Style Rules

The C2 architectural style is designed to support the particular needs of applications that have a graphical user interface aspect, but it has the potential for supporting other types of applications as well.

Component-based style
Software components may be written in different programming languages. They can more readily be reused and/or substituted with other components in an architecture.
Scalability
Components may be of various granularity. They may be running in a distributed, heterogeneous environment. There is no assumption of shared address space among components and each component may have its own thread(s) of control
Flexibility
Multiple users may be interacting with the system. Multiple dialogs may be active and described in different formalisms. Multiple tool kits and media types may be employed. Architec tures may be changed dynamically. A conceptual architecture is distinct from an implementation architecture; multiple implementation architectures may realize the same conceptual architecture.

An example C2 architecture




C2 composition rules

There are two types of building blocks in C2: components and connectors, i.e., message routing devices. A C2 architecture can informally be described as a network of concurrent components linked together by connectors. Components and connectors both have a defined top and bottom. They may be composed in the follow ing manner:

C2 Communication Rules

All communication between C2 components is achieved solely by exchanging messages. Each component has a top and bottom domain. The top domain specifies the set of notifications to which a component responds, and the set of requests it emits up an architecture. The bottom domain specifies the set of notifications that a component emits down an architecture and the set of requests to which it responds. Central to the architectural style is a principle of limited visibility or substrate independence: a component within the hierarchy can only be aware of components "above" it, and is completely unaware of the components "beneath" it.




Professor Richard N. Taylor
Professor David F. Redmiles
Information and Computer Science
University of California, Irvine CA 92697-3425


E-mail: arch@ics.uci.edu

This material is based upon work sponsored by the Air Force Materiel Command, Rome Laboratory, and the Defense Advanced Research Projects Agency under Contract Number F30602-94-C-0218. The content of the information does not necessarily reflect the position or the policy of the Government and no official endorsement should be inferred.