Component and Aspect Oriented Software Development Group

Home Page
Software Agents
Virtual Office
Sw Product Lines
xADL Extensions
Involved Projects
Contact Info.

CAM/DAOP is a component and aspect based model and platform that applies the principle of separation of concerns to separate both components and aspects as first class entities. These entities are then dynamically weaved at runtime.

CAM/DAOP is the PhD Thesis of Mónica Pinto, supervised by Lidia Fuentes and Jose Maria Troya.

This is an introduction of the main features of CAM/DAOP. More information about CAM/DAOP can be found here.

Contact Person: Mónica Pinto

The CAM/DAOP approach is defined in terms of:

1.     CAM [1] (Component-Aspect Model), a new model to design component and aspect based application specified in UML. The CAM model defines the main entities of a CAM application and the relationships among them. Therefore, aspects are identified at the design level contrary to other aspect proposals, where the separation of aspects is delayed until the implementation level.

2.     DAOP-ADL [2], an XML-based Architecture Description Language (ADL) that is used to describe the structure of CAM applications in terms of a set of components, aspects and composition constraints. One of the most relevant issues of our approach is that the description of the application architecture in DAOP-ADL can be automatically generated from the UML-based CAM diagrams generated during design.

3.     DAOP [1]  (Dynamic Aspect-Oriented Platform), which is our distributed component and aspect based platform. DAOP implements the CAM model and provides a dynamic composition mechanism that plugs software aspects into components at runtime, contrary to other approaches that perform it statically during compilation or at load-time. Another relevant feature of our approach is how the information provided with the DAOP-ADL language is used at runtime by the DAOP platform: (1) the information about the application architecture is loaded in the internal structures of the DAOP platform when the application is initiated, and (2) the DAOP platform consults this information to obtain the composition rules that indicate how to perform the dynamic composition of components and aspects.

4.     An integrated development process that we have defined to help software developers to understand how to use aspect-oriented technologies, specifically CAM/DAOP. This process establishes the relationship among CAM, DAOP-ADL and DAOP and guides software developers through the construction of CAM/DAOP applications from the design to the execution phases. As part of our ongoing work we are applying the Model Driven Architecture approach to automate part of this process [3].

5.    An integrated development environment (IDE) [2] that supports our development process with tools that helps to design, implement and deploy component-aspect applications. This IDE for CAM/DAOP will automatically produce the information generated in each phase of the process; in case the automation was possible.

Due both to the use of the DAOP-ADL language and to the dynamic composition mechanism offered by the DAOP platform, our approach is especially suitable to develop applications with high requirements of dynamic adaptability. In this sense, up to now we have developed several collaborative applications using CAM/DAOP; from simple applications such as chat applications or the PictionaryTM game, to more complex ones such as a virtual office application [4]. These applications are dynamic and distributed applications that are characterized by high runtime interaction among the users connected in the same session, and high requirements of dynamic adaptability, so they are good candidates to test our approach. In this demo our goal is to show our experience of several years developing our virtual office application using component-aspect techniques; thus we will use this application to illustrate our approach.

One extension of xADL 2.0 to adapt it to DAOP-ADL, called DAOPxADL, has been made. More information about DAOPxADL can be found here.


The main problems addressed by our approach are:

1.     Current component platforms only separate a limited set of common services required in distributed systems. Using CAM/DAOP it is possible to separate any common services, modelling them as aspects.

2.     In many approaches aspects are not reusable entities, mainly because they mixed the behaviour of aspects (aspect advice) and the definition of aspect point cuts in the same entities. In CAM/DAOP the behaviour of aspects and the point cuts are described in different and independent entities. Therefore, aspects become context-independent and reusable parts.

3.   When the definition of aspect pointcuts is distributed among the different aspects, as is usual in some aspect proposals, it is very difficult to trace which aspects are applied to each object/component and when they are applied – specially before the application execution (at design and architectural level). CAM/DAOP addresses this problem centralizing the description of the point cuts for all the aspects in an application as part of the composition rules in the DAOP-ADL language.

4.    The information about the software architecture of an application is usually lost at implementation level. In our approach we close the 'gap' between design and implementation using the DAOP-ADL language that describes exactly the same information that is provided with the CAM model during the design phase. The execution of the application is driven by this information, which establishes at runtime the composition logic between components and aspects.


The most unique feature of our approach is the use of the DAOP-ADL language to explicitly describe the architecture of a CAM/DAOP application in XML and the fact that the use of the DAOP-ADL language establishes a clear “relationship” among the different phases of the software development (from design to execution). In fact, the DAOP-ADL language is the back-end of the complete development process as described below:

q       First, software developers will use a UML editor to draw the UML diagrams of the CAM/DAOP application. These diagrams will be used by our IDE to automatically generate part of the software architecture of the application in DAOP-ADL.

q       Once the software architect completes the description of the application architecture in DAOP-ADL the XML document containing the description of the application architecture is stored in an architecture repository.

q       Then, during the implementation phase software developers will register their components and aspects in a component and aspect repository tool. The relevant issue is that this tool automatically generates the description of these entities in DAOP-ADL. These XML descriptions are then automatically incorporated as part of the architecture description when components and aspects are selected.

q       Finally, as mentioned before, the information in DAOP-ADL is loaded along with components and aspects and it is consulted by the DAOP platform at runtime to perform the late-binding between living components and aspects. Furthermore, this information can be modified at runtime to dynamically adapt the behaviour of applications developed on top of CAM/DAOP.


The current implementation of CAM/DAOP uses Java to take advantage of characteristics such as reflective programming, code mobility and RMI. In this implementation of CAM/DAOP, a CAM/DAOP application is a web application that is deployed by making accessible through a Web server both the implementation of components and aspects and the description of the software architecture. This information will be then downloaded at runtime using an applet or the Java WebStart technology.

The DAOP platform has two sides: the kernel side, which stores shared information among all users; and the client side, where a light-weight middleware layer, previously downloaded with a browser, manages the participation of a user inside a distributed application. We want to point out that this architecture is almost completely distributed. This is not a traditional client-server approach, so we have implemented the client side with an applet. Thus, a running application consists of several client applets and at least one kernel, which is considered the home of the application. 


[1] M. Pinto, L. Fuentes, J.M. Troya, "A Component and Aspect Dynamic Platform", The Computer Journal 2005 48(4):401-420 (copy available under request).

[2] M. Pinto, L. Fuentes, J.M. Troya, "Supporting the Development of CAM/DAOP Applications: An Integrated Development Process", next publication in Software Practice and Experience (copy available under request).

[3] M. Pinto, L. Fuentes, J.M. Troya, “DAOP-ADL: An architecture description language for dynamic component and aspect-based development “, GPCE 2003, LNCS 2830, pp. 118-137, sep 2003, Erfurt, Germany.

[4] L. Fuentes, M. Pinto, A. Vallecillo, “How MDA can help designing component- and aspect-based applications, EDOC 2003, sep 2003, pp. 124-135, Brisbane, Australia.

[5] M. Pinto, L. Fuentes, M. E. Fayad, J.M. Troya, "Separation of Coordination in a Dynamic Aspect Oriented Framework", Proc. of AOSD'02, April 2002, Enschede, Holland

[6] M. Pinto, M. Amor, L. Fuentes, J.M. Troya, ”Supporting heterogeneous users in collaborative virtual environments”, CoopIS 2001, LNCS 2172, pp. 226-238, sep 2001, Trento, Italy.


Home Page | AO-ADL | CAM/DAOP | Software Agents | MultiTEL | Virtual Office | Pópulo | Sw Product Lines | xADL Extensions | Involved Projects | Publications | Members | Contact Info.

© UMA CBSD & AOSD Group, 2005.
Last Update: 13 feb 2009