Home Page
Contact Info

The Component and Aspect Model

Figure 1 shows an UML diagram with the basic entities of the CAM model and the relationships that can be established among them. The entity names in this diagram are UML stereotypes for modelling applications in terms of CAM.





















Figure 1. CAM Metamodel

Figure 2 shows part of the CAM diagram of a chat application using these stereotypes.

Figure 2. Example of the CAM model of a Chat Application

In this application a chat component is instantiated to represent a user that has joined to the chat application. When this occurs and before creating the chat component, the authentication aspect is evaluated to make sure that the user only joins the application if he or she has the right permissions. Then, when users are chatting (e.g. chat components send/receive the sendText message) the persistence and the filter aspects are evaluated. The persistence aspect stores the persistent state of the component into a store, for example a LDAP directory server or a database server. This is useful for latecomer users that join the application once there are other users working on it. The filter aspect is evaluated before the sendText message is received in a chat component and allows filtering messages according to user preferences.

Components and Aspects

CAM components and aspects are coarse-grained encapsulated entities that can only act as units of composition with contractually specified interfaces and explicit context dependencies. They may be deployed independently and are subject to third-party composition (component definition by Clemens Szyperski [1]).

CAM aspects are treated as a “special” kind of component, so both components and aspects share some common features. For instance, they may have a set of StateAttributes that represent their public state.

In order to detach component and aspect interfaces from their final implementations, we assign a unique role name (in class Role of Figure 1) to identify both component and aspect classes. A role name identifies a specific functionality and will be play by a component that implements this functionality. These role names are architectural names that will be used for component-aspect composition and interaction, allowing loosely coupled communication among them – i.e. no hard-coded references need to be used for exchanging information, but just a role name identifying the target of a message.

It is possible that several components play the same role inside a distributed application. In this case the model distinguishes between different instances of a role by the RoleInstance. Figure 2 shows that the component chat fulfills the “chat” role, but if the same user initiates, for example, two chats, each one will have different role instances. 


CAM aspects do not have any information about the other aspects applied at the same time to a component. Even if there is
some kind of dependency, the aspects should not be aware of this. We cope with this problem of composition of non-orthogonal aspects by using the class Property in Figure 1.

Properties are identified by a unique name, their type, and current value. Thus, in the CAM model, non-orthogonal aspects indirectly interact to resolve their dependencies by sharing properties with the same name and type. Then, aspects that are evaluated concurrently should not have any dependence among themselves, and their effect on components should not interfere. Otherwise, aspects should be evaluated in sequence. Likewise, properties also help to define truly independent components, putting any kind of data dependency as a shared property.

Messages and Events

An important feature of the CAM model is the way in which the entities of the model communicate among themselves.

Following the standard practices of CBSD, components interact by exchanging Messages and by throwing Events. We understand the meaning of messages and events in the CBSD sense: messages are sent to a specific target entity and events are messages with no information about the target component.

The handling of events is resolved at runtime by a coordination aspect (class CoordinationAspect in figure 1) that encapsulates a component interaction protocol that will decide which are the target components of a given event, at runtime.

Component and Aspect Interfaces

Similarly to other component models, we describe the interfaces of components and aspects using an interface description language (IDL). A component’s IDL describes not only the services the component provides to the environment, as is usual in component platforms (the provided interface), but also those services it requires in its interaction with other components (the required interface).

How to evaluate aspects is described in an evaluated interface, instead of a provided interface as for components, that includes the join points (messages, events, creation and finalization of components) that an aspect is able to intercept and evaluate. By aspect evaluation we mean the execution of the corresponding aspect advice. If an aspect is general enough to be able to evaluate any intercepted join point, this interface can be omitted.

In addition, when an coordination aspect is being evaluated, it can also interact with the components it coordinates. This means that coordination aspects also have a required interface describing the output messages. Context dependencies are also
specified as part of the component and aspect IDLs. In CAM these IDLs are part of an XML-based architectural description language named DAOP-ADL.

Joinpoint Model

In CAM, we consider that aspects are applied to black-box components. Therefore, in our model we intentionally avoid the definition of join points that intercept the internal behaviour of a component, as we only have access to a component through its public interface.

Thus, CAM aspects can be applied before and after (incoming and outgoing) messages and events, and also before and after the creation and destruction of component instances, as showed in the different “applies to” relationships for aspects and the AspectJoinPoint Enumeration class in Figure 1.


Home Page | CAM | DAOP-ADL | DAOP | Implementations | Applications | Tools | Publications | Members | Contact Info

© UMA CBSD & AOSD Group, 2005.
Last Update: 05 jun 2006.