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 speciﬁed interfaces and explicit context dependencies. They may be deployed independently and are subject to third-party composition (component deﬁnition by Clemens Szyperski ).
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
ﬁnal implementations, we assign a unique role name (in class Role of
Figure 1) to identify both component and aspect classes. A role name identiﬁes a
speciﬁc 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.
CAM aspects do not have any information about the other
aspects applied at the same time to a component. Even if there is
Properties are identiﬁed 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 deﬁne 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 speciﬁc 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 ﬁgure 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 ﬁnalization 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
In CAM, we consider that aspects are applied to black-box components. Therefore, in our model we intentionally avoid the deﬁnition 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.