integrating aspects in software architectures: prisma applied to robotic tele-operated systems

Available online at www.sciencedirect.com

www.elsevier.com/locate/infsof

Information and Software Technology 50 (2008) 969–990

Integrating aspects in software architectures: PRISMA appliedto robotic tele-operated systems

Jennifer Perez a,*, Nour Ali b,1, Jose A. Carsı b,1, Isidro Ramos b,1, Barbara Alvarez c,2,Pedro Sanchez c,2, Juan A. Pastor c,2

a Technical University of Madrid (UPM), E. U. Informatica, Carretera de Valencia km.7, E-28031 Madrid, Spainb Department of Information Systems and Computation Polytechnic, University of Valencia, Camino de Vera s/n, E-46022 Valencia, Spain

c Division of System and Electronic Engineering Polytechnic, University of Cartagena, Campus Muralla del Mar s/n, E-30202 Cartagena, Spain

Received 6 November 2006; received in revised form 31 July 2007; accepted 27 August 2007Available online 15 September 2007

Abstract

Aspect-Oriented Software Development (AOSD) has emerged as a new approach to develop software systems by improving theirstructure, reuse, maintenance and evolution properties. It is being applied to all stages of the software life cycle. In this paper, we presentthe PRISMA approach, which introduces AOSD in software architectures. PRISMA is characterized by integrating aspects as first-ordercitizens of software architectures. This paper shows how the PRISMA methodology is applied to develop a case study of the tele-oper-ation system domain. We illustrate how the PRISMA approach can improve the development and maintenance processes of these kindsof industrial systems.� 2007 Elsevier B.V. All rights reserved.

Keywords: Methodology; Aspect-Oriented Software Development (AOSD); Component-based software development (CBSD); Aspect-oriented softwarearchitectures; Tele-operation domain; Software architecture design

1. Introduction

Aspect-Oriented Programming (AOP) [23] proposes theseparation of the crosscutting-concerns of software systemsinto separate entities called aspects. This separation avoidsthe tangled code of software and allows the reuse of thesame aspect in different entities of the software system(objects, components, modules, etc.). Despite the fact thatthe aspect-oriented paradigm emerged from the implemen-tation level, its use is being extended to all stages of thesoftware life cycle. As a result, Aspect-Oriented SoftwareDevelopment (AOSD) has emerged in order to extend the

0950-5849/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2007.08.007

* Corresponding author. Tel.: +34 91 336 78 82.E-mail addresses: [email protected] (J. Perez), nourali@dsi-

c.upv.es (N. Ali), [email protected] (J.A. Carsı), [email protected](I. Ramos), [email protected] (B. Alvarez), [email protected](P. Sanchez), [email protected] (J.A. Pastor).

1 Tel.: +34 96 387 73 50.2 Tel.: +34 96 832 54 80.

advantages that aspects provide to every stage. Oneinteresting stage where AOSD is being introduced is thesoftware architecture stage. This interconnects the require-ments and the implementation stages [16] in order toanalyze the software structure of complex, distributed,heterogeneous and reusable software systems [17].

Software architectures allow us to describe the structureof software systems by hiding low-level details andabstracting the high-level important features [40]. Thisstructure is usually represented in terms of computationalelements and the interactions among them. As a result,software architectures make software systems simpler andmore understandable. Their main advantages are: thehigh-level of abstraction, the reuse of software, and themechanisms to analyze properties, validate softwarerequirements and estimate the cost of the developmentand maintenance processes. In addition, software architec-tures establish the bases and guidelines for designingcomplex and large software systems.

mailto:[email protected]








970 J. Perez et al. / Information and Software Technology 50 (2008) 969–990

Some proposals for the integration of software architec-ture and AOSD have emerged to take advantage of bothapproaches [9,7]. Each one introduces aspects in theirArchitecture Description Languages (ADLs) in a differentway: as a component [31], as a connector among compo-nents [41], as a view of the architecture [21], etc.

PRISMA is an approach that integrates the softwarearchitecture and the AOSD approaches in order to takeadvantage of both approaches. The PRISMA approach isbased on its model [37] and its formal Aspect-OrientedArchitecture Description Language (AOADL) [39]. ThePRISMA model is a symmetrical model because it doesnot consider functionality as a kernel entity different toaspects and it does not constrain aspects to specify non-functional requirements [19]; functionality is also specifiedas an aspect. As a result, PRISMA provides a homoge-neous treatment to functional and non-functional require-ments. The PRISMA model can be classified as amultidimensional model [33,34]. Aspects have been intro-duced in the PRISMA AOADL as a new concept ratherthan simulating the aspect using other architectural terms(components, connectors, views, etc.). In PRISMA, aspectsare first-order citizens of software architectures and repre-sent a specific behaviour of a concern (safety, coordination,etc.) that crosscuts the software architecture. The sameaspect can be imported by each one of the architectural ele-ments (components and connectors) that need to take intoaccount this concern behaviour. As a result, an architec-tural element is defined by a set of aspects that describe itfrom different concerns of the architecture. The PRISMAapproach takes advantage of the notion of aspect fromthe beginning of the system definition. The change of aproperty only requires the change of the aspect that definesit, and as a result, each architectural element that importsthe changed aspect is also updated. In addition, it is impor-tant to emphasize that the PRISMA AOADL is a formaltechnology independent language that facilitates the auto-matic code generation and the validation of architecturaland aspect features of the system.

This paper presents the methodology defined for devel-oping software systems based on PRISMA aspect-orientedsoftware architectures. This methodology follows theModel-Driven Development (MDD) paradigm. This para-digm is based on models that use automatic generationtechniques in order to obtain the software product. Themethodology is divided into three stages: detection ofarchitectural elements and aspects, architecture modelling,and code generation and execution. These three stages areapplied by the analyst of the software system in an iterativeand an incremental way depending on his/her needs. In thispaper, we focus on the architecture modelling stage as it isexplained in detail in order to illustrate how the PRISMAcombination of AOSD and software architectures canimprove the development and maintenance processes ofsoftware.

The methodology is explained using a specific domain inorder to illustrate its application to a real complex system.

This domain is the robotic tele-operation systems. Tele-operated robots are software intensive systems that areused to perform tasks that human operators cannot carryout because of the dangerous nature of the tasks or the hos-tile nature of the working environment. The industrial casestudy where PRISMA is currently being put into practice isthe EFTCoR system. The EFTCoR [13] is a tele-operatedsystem that develops a family of robots whose purpose isto clean the hulls of ships. However, it is too broad andcomplex to present in a paper, so we illustrate the mainideas by showing the small-scale TeachMover tele-operatedteaching robot to illustrate the PRISMA methodology. Asa result, this paper presents the application of a softwareengineering approach to develop a robotic system. In thisway, robotic systems have taken advantage of the benefitsprovided by the PRISMA software engineering approach,specifically, the reuse of components and aspects, as wellas their maintainability, evolution, etc.

The structure of the paper is the following: Section 2introduces the purpose of this work. Section 3 presentsan overview of the PRISMA model in order to describehow PRISMA combines software architectures andaspects. Section 4 presents a brief summary of relatedwork. Section 5 presents the PRISMA approach by focus-ing on the methodology to develop PRISMA aspect-ori-ented software architectures, putting PRISMA intopractice by specifying the TeachMover robot softwarearchitecture. Section 6 details the advantages of thePRISMA framework. Finally, conclusions and furtherwork are presented in Section 7.

2. Motivation

Software architectures allow us to describe the structureof software systems. This structuring improves softwaresystem understanding, development, and maintenance[40,15]. Software architectures are usually crosscut by com-mon concerns of the system domain. These crosscutting-concerns are spread throughout the architectural elementsof software architectures. As a result, the crosscutting-con-cerns are repeated in the architectural elements that theyaffect, and they are tangled with the other concerns ofarchitectural elements [50]. The repetition of crosscutting-concerns throughout software architectures increases thevolume of code and the difficulty of preserving the consis-tency of the software system when changes are introduced.In addition, tangled concerns make the maintenance of aspecific concern more difficult because it is very difficultto locate the correct place where changes should be intro-duced. As a result, the best solution for dealing with thecrosscutting-concerns is by modelling them in a separateentity. This solution is called Separation of Concerns(SoC) [35]. The Aspect-Oriented Programming (AOP) hasemerged as an innovative way of applying SoC in softwaredevelopment [22,23,12].

AOP introduces a higher level of modularity of softwareand simplifies applications. These two properties generate

J. Perez et al. / Information and Software Technology 50 (2008) 969–990 971

advantages such as: simpler code; easier development,maintenance and evolution; and a higher level of reusabil-ity. A demonstration of these advantages is presented in[23] by comparing the source code of a non-aspect-orientedapplication and an aspect-oriented application that weredeveloped for the same software system. In this compari-son, the aspect-oriented application had a clear advantageto the non-aspect-oriented one in the reduction of code.The results were the following:

– Size of the non-aspect-oriented application: 35.213lines of code,

– Size of the aspect-oriented application: 4.628 lines ofcode,
– Component program: 756 lines of code,– Three aspects programs: 352 lines of code,– Aspect weaver: 3.520 lines of code.
This example shows how code is reduced in aspect-ori-ented applications taking also into account the aspect wea-ver code. In addition, the aspect weaver code can be reusedin other applications. However, different kinds of projects,with different requirements, sizes and programmers shouldbe measured to make a real study about the time and spaceefficiency of aspect-oriented applications. The demonstra-tion of [23] has been the starting point for studying theimprovement of aspect-oriented programming. Otherworks have also confirmed this improvement such as theworks of Garcia et al. [15] or Munelly et al. [28]. Garciaet al. compares the aspect-oriented implementation of theGang-of-Four (GoF) design patterns [14] to their object-oriented implementation, and they demonstrate that mostaspect-oriented implementations improve the separationof concerns to a great extent. On the other hand, Munellyet al. have implemented the same case study of a context-aware system using an aspect-oriented design, using anobject-oriented design, and using a popular context-awareframework. After, they have evaluated the different imple-mentations achieved using several characteristics and indi-cators, and they have illustrated that the aspect-orientedimplementation improves the separation of concerns.

Crosscutting-concerns arise throughout the software lifecycle. For this reason, despite the fact that AOP emergedfrom the implementation level, its use is being extendedto all the stages of the software life cycle. As a result,Aspect-Oriented Software Development (AOSD) hasemerged to gain the advantages that aspects provide inevery stage of the software life cycle.

The combination of software architectures and AOSDfor structuring software is a step forward in improvingthe development, maintenance and evolution processes ofsoftware, as well as in reducing their costs. The PRISMAapproach combines AOSD and software architectures toprovide the advantages that this combination offers.

There is a wide variety of domains that can take advan-tage of the PRISMA approach. We have focused on thetele-operation domain in order to cope with the problemsof these real industrial systems using software engineering

techniques. The importance of considering the softwarearchitecture in robotic tele-operated systems is well known[8]. However, despite the fact that tele-operated systemsusually have many common requirements in their defini-tion and many common components in their implementa-tion, it is impossible for a single architecture to beflexible enough to cope with all of the variability of thedomain. Therefore, a further step is needed to provide aflexible and extensible architectural framework to developsystems with different requirements and commonalities.In this sense, there have been numerous efforts to providedevelopers with frameworks such as [6,52] and [43]. Allof them make very valuable contributions that simplifythe development of systems. However, the way that thecomponent-oriented approach has been applied mayreduce part of its benefits. They are object-oriented or com-ponent-oriented frameworks that rely on object-orientedtechnologies and that highly depend on a given infrastruc-ture (Linux O.S. and the C++ language). They are depen-dent on the technology and infrastructure and they usespecific programming languages. As a result, a technol-ogy-independent language that provides mechanisms todefine abstract software architectures that can be mappedinto specific software architectures is needed.

At the same time, tele-operated systems have a widerange of common concerns in their domain. These concernscan be modelled as aspects in order to take advantage ofAOSD. Some of these candidate aspects of the tele-opera-tion domain are distribution, safety, mobility, security,coordination, etc.

The EFTCoR [13] is a tele-operated system that devel-ops a family of robots whose purpose is to clean the hullsof ships. These robots are specifically designed for ship hullmaintenance and the performance of different require-ments. For example, in the EFTCoR system, its safety

requirements are extremely important. This is due to thefact robot movements are very dangerous for the operatorsand the environment that surrounds them. Most of EFT-CoR architectural elements must take these safety require-ments into account. As a result, safety is presented as acrosscutting-concern in this system, and this concernshould be developed by providing its separation from therest of concerns in order to avoid tangled code inside archi-tectural elements.

Therefore, an approach that integrates the definition oftechnology-independent software architectures and the sep-aration of concerns can be a great contribution to the tele-operated domain. As a result, in this paper we present howthe PRISMA approach copes with the tele-operationdomain needs.

3. An overview of the PRISMA model

The PRISMA approach is based on the PRISMA model[37], its Aspect-Oriented Architecture Description Lan-guage (AOADL) [39], its methodology, and its tool [38].The PRISMA model is described by its metamodel, which


allows the definition of the PRISMA properties in a preciseway.

The PRISMA model allows the description of softwarearchitectures of complex and large systems. From theaspect-oriented point of view, PRISMA is a symmetricalmodel that does not distinguish a kernel or core entity toencapsulate functionality; functionality is also defined asan aspect [19]. One concern can be specified by severalaspects of a software architecture, whereas a PRISMAaspect represents a concern that crosscuts the softwarearchitecture. This crosscutting is due to the fact that thesame aspect can be imported by more than one architec-tural element of a software architecture. In this sense,aspects crosscut those elements of the architecture thatimport their behaviour (see Fig. 1). However, the concernis not tangled through the architecture, it is encapsulatedinside one or more aspects.

A PRISMA architectural element can be seen from twodifferent views: internal and external. In the external view(black box view), architectural elements encapsulate theirfunctionality as black boxes and publish a set of servicesthat they offer to other architectural elements (seeFig. 2b). These services are grouped into interfaces to bepublished through the ports of architectural elements. Eachport has an associated interface that contains the servicesthat are provided and requested through the port. As aresult, ports are the interaction points of architecturalelements.

The internal view shows an architectural element as aprism (white box view). Each side of the prism is an aspectthat the architectural element imports. In this way, archi-tectural elements are represented as a set of aspects (seeFig. 2a ) and the weaving relationships among aspects.

Since PRISMA is a symmetrical aspect-oriented modelthat is applied at the architectural level, the weaving

Fig. 1. Crosscutting-concerns

process indicates that the execution of an aspect servicecan trigger the execution of services in other aspects. InPRISMA, in order to preserve the independence of theaspect specification from other aspects and weavings,weavings are specified outside aspects and inside architec-tural elements. As a result, aspects are reusable and inde-pendent of the context of application and weavingscoordinate the different aspects that form an architecturalelement. This way of specifying weavings achieves not onlythe reusability of the aspects in different architectural ele-ments, but also the flexibility of specifying different behav-iours of an architectural element by importing the sameaspects and defining different weavings.

PRISMA has two kinds of architectural elements: com-ponents and connectors. A component is an architecturalelement that captures the functionality of software systemsand does not act as a coordinator among other architec-tural elements; whereas, a connector is an architectural ele-ment that acts as a coordinator among other architecturalelements. Connectors do not have the references of thecomponents that they connect and vice versa. Thus, archi-tectural elements are reusable and unaware of each other.This is possible due to the fact that the channels definedbetween components and connectors have their references(attachments) instead of architectural elements. Attach-ments are the channels that enable the communicationbetween components and connectors. Each attachment isdefined by attaching a component port with a connectorport (see Fig. 3).

PRISMA components can be simple or complex. Thecomplex ones are called systems. A PRISMA system is acomponent that includes a set of architectural elements(connectors, components and other systems) that are cor-rectly attached. In addition, a system can have its ownaspects and weavings as components and connectors. Since

in PRISMA architectures.

Fig. 2. Views of an architectural element.

Fig. 3. Attachments.


a system is composed by other architectural elements, thecomposition relationships among them must be defined.These composition relationships are called bindings. Bind-ings establish the connection among the ports of the com-plex component (the system) and the ports of thearchitectural elements that a system contains.

4. Related works

AOP introduces a set of new concepts that allow us toapply the AOP paradigm at the different levels of the soft-ware life cycle. The most import concepts are the basecode, join point, pointcut, advice, aspect and weaving [11].

– Base code: The base code is composed of the softwareunits (modules, objects, components) of an application,which have been obtained as a result of a functionaldecomposition.– Join point: Join points are situated in the base code ofan application. A join point is a semantic concept thatdefines a well-defined point of the execution of a basecode. This point can extend the base code with theaspect code, thereby altering the execution flow of theoriginal application.– Pointcut: A pointcut is a set of join points, which arecandidates for injecting aspect code into base code atrun-time, and their multiple instantiations. Pointcutsperform the weaving between the base code and theaspect code by capturing joinpoints.– Advice: An advice defines the code that should be exe-cuted at the join points of a specific pointcut. Advicesare executed after, before or instead of the selected joinpoints.– Aspect: An aspect is composed of pointcuts and anadvice.

– Weaving: The Weaving is the process that consists ofcoordinating the base code and the aspect code. Thiscan be seen as the composition process of an aspect-ori-ented application.

In PRISMA, these concepts have been introduced at thearchitectural level in order to take advantage of AOP prop-erties. The functional decomposition of PRISMA is per-formed by architectural elements, which allow us tostructure the code by functional blocks. However, thesefunctional blocks do not have a base code associated tothem that implements their functionality (kernel, class,object, etc.). In PRISMA, functionality is also an aspectdue to the fact that PRISMA follows a symmetricalaspect-oriented model. PRISMA architectural elementsare composed by aspects and weavings. Since we do notmake any difference between base and aspect code, ourweaving process consists of coordinating the differentaspects that an architectural element imports. In PRISMA,every aspect service is a joinpoint and those services thatneed to execute other services after, before or instead ofthem are pointcuts, and these other services that are exe-cuted as a consequence of pointcut services are the advice.As a result, the weaving is composed of a pointcut service,a temporal operator (after, before, instead) and one ormore advice services.

PRISMA architectural elements provide the functionalview of a software architecture, publishing through theirports, the services of the aspects that are necessary to inter-act with the rest of architectural elements. They madetransparent to the user the fact that there is a clear separa-tion of concern inside them and there is a weaving processthat coordinates these concerns.

With regard to software architectures, a wide variety ofADLs have been proposed in the literature, and an interest-ing comparison among these languages has been made inthe work by Medvidovic and Taylor [25]. Some proposalsfor the integration of software architecture and AOSDhave emerged to take advantage of the two approaches.A comparison of these is presented in [9]. Each of theseapproaches, that are presented in [9], introduces aspectsin their Architecture Description Languages (ADLs) in adifferent way: as a component AspectLEDA [31], JAC


[36], Jiazzi [24], as a connector among components CAM/DAOP [41], as a view of the architecture AVA [21], etc. Onthe other hand there are approaches such as FuseJ [48,49]that promote the idea that there are no aspects, there areonly components. This assertion is well-based on the factthat aspects can be modelled using components as FuseJ,AspectLEDA, JAC, Jiazzi and others. However, it doesnot mean that components and aspects are the same thing.The semantics of these concepts is different as Kizcalesexplains in his work [23]. In addition, if aspects and compo-nents were the same, not only aspects could be modelled ascomponents, but components could be also modelled asaspects. However, a component cannot be modelled as anaspect because a component usually implements propertiesof more than one concern. As a result, in order to be con-sistent with the meanings of both concepts, in PRISMAsoftware architectures, an aspect is introduced as an aspect,i.e, the aspect is a new primitive in software architecturesand it is not simulated by using an architectural term (com-ponents, connectors, views, etc.). PRISMA aspects arefirst-order citizens of the PRISMA AOADL.

The first tasks for developing software architectures areto identify which architectural elements make up the archi-tecture and to detect the aspects that crosscut the softwarearchitecture. Several works have been proposed for theidentification of components, they are usually based on awidely extended criterion that consists of the functionaldecomposition of software. One of these works applies thiscriterion to multi-agent systems [32] and another workapplies this criterion to software architectures (the Archi-tecture Based Design Method (ABD)) [3,1]. A detailed sur-vey of criteria to identify software components can befound in [20]. Other works have been developed for theidentification of aspects in requirements specification suchas [4,27,29,45,47] and [53]. An extended survey of thesecan be found in [7]. The identification of aspects is one ofthe new challenges that have emerged as a consequenceof introducing aspects in software architectures. However,there is not a unique standard guided process that is usedto identify architectural elements and the aspects thatcrosscut them. In PRISMA, the detection of those architec-tural elements and aspects is performed from the require-ments document in an intuitive way.

PRISMA takes advantage of the notion of aspect fromthe beginning of the system definition by specifying theaspects that are found in the requirements specification.These aspects are reusable and can be used during the restof the development process as well as in the maintenanceprocess. However, other approaches such as AspectLEDArequire having an initial architectural specification of thesystem in order to introduce aspects. In this way, aspectscan only emerge as new requirements of the system thatare hooked to the base architecture, i.e., aspects are onlyused for evolution during the maintenance process.

In the PRISMA approach, the complete view of the soft-ware architecture is not lost because of the use of aspects,that is, the use of the view notion is not required to define

aspects in software architectures as in AVA. We considerthat the use of architectural views from an aspect-orientedpoint of view is an additional mechanism for analyzing soft-ware architectural features. PRISMA can obtain differentarchitectural views by means of the import relationships thataspects have from architectural elements (see Fig. 6). As aresult, a view of an aspect consists of the set of architecturalelements that import it. For example, we can have an aspect-oriented view of the software architecture by considering allthe architectural elements that import a specific aspect. Inaddition, we can have another view by considering all thearchitectural elements that import a kind of aspect concern;for example, analyze the view of all the architectural ele-ments that import a safety concern.

At the configuration level, when the architectural ele-ments are instantiated and a specific configuration isdefined by connecting instances, the structural and archi-tectural view of the system is not lost due to the fact thatour components are connected by means of connectorsinstead of aspects as in CAM/DAOP. CAM/DAOP intro-duces aspects as connectors and the approaches ofAspectLEDA and Jiazzi implement weavings as connectorsin order to coordinate their ‘‘component aspects’’. Thisway of introducing AO concepts in software architectureis influenced by the fact that these approaches are basedon ADLs that do not originally provide the notion of con-nector and simulate it by aspects. Another approach thatdoes not provides the notion of connector is JAC, but fur-thermore it does not try to simulate the concept, it intro-duces the weaving process inside its ‘‘component aspects’’losing the reusability of aspects.

However, as Shaw presents in her work [44], the specifi-cation of software systems with complex coordination pro-tocols is too difficult without the connector architecturalelement. This is because the connector provides the separa-tion of component interactions thereby achieving a higherlevel of abstraction, modularity, and a greater architecturalview of the system. For this reason, PRISMA connectorsare first-class citizens of the ADL. In addition, the notionof connectors provides PRISMA with a mechanism tofocus on all the aspects that are needed to coordinate aset of components on an entity. For example, in the Teach-

Mover case study, the connector needs a coordinationaspect to synchronize the components as well as a safetyaspect to check whether the movements are correct. Here,the connector uses the safety aspect as a means to coordi-nate components. As a result, connectors are preserved inour ADL and so, our approach can follow the notion ofcontract of Andrade and Fiadeiro [2]. This notion specifiesthe dynamic business rules of the system in connectors inorder to obtain more maintainable architectures.

It is also important to preserve the fact that ADLsshould be formal because it is the only way to analyzeand reason about the obtained software architectures.For this reason, PRISMA AOADL is a formal languagethat allows us to validate properties and generate code.However, we lose the advantages of using an extended lan-

Fig. 4. The TeachMover Robot.


guage such as XML or Java, as in the CAM/DAOP andFuseJ proposals, respectively. This disadvantage is over-come thanks to the fact that XML specifications or Javacan be generated from our ADL. In this way, our ADLcan be interoperable with other frameworks since theADL XML specifications can be used.

Finally, another approach that should be mentionedbesides the ones presented in [9] is TranSAT [5]. Transat isan approach for managing the evolution of software archi-tecture specifications using aspect-oriented programmingprinciples. The approach starts from a core architecturalmodel that either needs to be extended during its develop-ment process or needs to be evolved during its maintenanceprocess. The mechanisms of extension and evolution are pro-vided using AOP techniques. As a result, this approach incre-mentally obtains a complete software architecture withbusiness and technical concerns from a business softwarearchitecture. Their models are hierarchical component mod-els that define software architecture by means of composi-tion relationships. The new technical concerns aremodelled as components that refine the original componentspecification. As a result, the composition relationshipsallow the generation of other components that include theseaspects without losing the black box view of components.The main advantages of this approach is that it is based onADL for defining the core architectural model, the way thatevolution is supported, the reusability preservation and theindependence from a technological. However, a great limita-tion of this approach is the constraint of starting the develop-ment from a core architectural model without consideringconcerns from the beginning. Also, the fact that concernsare only technical and not more generic is another drawback.As a result, aspects in this approach are not introduced as anew concept for modelling software architectures. Softwarearchitectures are defined using a pure compositional ADL,and aspects only appear as an extension or evolution mech-anism of software architectures.

In summary, PRISMA is a new contribution in the areawhich offers some advantages and which is novel in the waythat it integrates aspects in software architectures.PRISMA combines AOSD and software architecture in away that preserves the concepts of both approaches. Inaddition, its methodology is also a new contribution dueto the fact that it applies the MDSD approach to aspect-oriented software architecture in order to automaticallygenerate code from models.

5. The PRISMA software development methodology

The contribution of this paper is the methodology thatPRISMA proposes in order to develop complex systems.The PRISMA methodology can be divided into threestages: detection of architectural elements and aspects,architecture modelling, and code generation and execution.These stages are applied by the analyst of the softwaresystem in an iterative and an incremental way dependingon his/her needs.

5.1. 1st Stage: detection of architectural elements and

aspects

The first tasks for developing software architectures areto identify which architectural elements make up the archi-tecture and to detect the aspects that crosscut the softwarearchitecture. In PRISMA, the detection of those architec-tural elements and aspects is performed from the require-ments document in an intuitive way.

The running example that we are going to use to illus-trate our methodology is the TeachMover tele-operationsystem [51] (see Fig. 4). The TeachMover robot is a roboticarm that is frequently used to teach the fundamentals ofrobotics. This robot was specially designed for the purposeof simulating the behaviour of large and heavy industrialrobots. The computational units (components) and thecoordination units (connectors), which allow the architec-ture to synchronize components and permit the communi-cation among them, can be identified from the manual ofthe TeachMover robot. In addition, the concerns thatcrosscut the software architecture can be detected. Themechanisms and criteria to detect concerns, componentsand connectors are out of the scope of this paper, so we willassume that these elements have already been detected.

5.1.1. Identification of architectural elements

The manual of the TeachMover shows that the robot iscomposed of a set of components that represent a set ofjoints, a set of connectors that coordinate the joints, anda set of complex components that allows the compositionof joints to form a robot. These joints permit the robot’smovements. They are the following: Base, Shoulder, Elbow

and Wrist. In addition, it has a Tool to perform differenttasks. In this case study, the tool is a gripper, whose openand close actions allow the robot to pick up and depositobjects (see Fig. 4). These joints are complex componenttypes called SUCs (Simple Unit Controllers) in the tele-operation domain. They are complex because they arecomposed of simple components that allow the movementsof the SUC: the Actuator, the Sensor, and the Connector


that coordinates them (see Fig. 5). Actuators and Sensors

are basic components, which communicated with the hard-ware joints of the robot. The functionality of the Actuatorsand Sensors are the following:

• Actuator: An actuator sends commands to a joint of therobot. These commands are performed by the joint orthe tool.

• Sensor: A sensor reads the results of the commands inorder to know whether or not they have been performedsuccessfully.

As a result, it is possible to identify that a SUC is a com-plex architectural element type that models the genericbehaviour of a joint. However, two special SUCs have beenidentified in order to take into account the peculiarities ofthe wrist joint and the tool (see Fig. 5). The SUC, the Wrist

and the Tool SUCs must be composed and coordinated inorder to form the complete structure and functionality of atele-operated robot. This composition has generated differ-ent levels of granularity. The architectural elements thatparticipate in each level are types, and the number ofinstances of each one will be determined at configuration-time (Section 3.2.5 Step 5) depending on the tele-operatedrobot. They are the following:

– Mechanism Unit Controllers (MUCs): This architec-tural element type represents the arm of the robot,which is composed of the SUCs and Wrist SUCs coordi-nated by means of a connector (see Fig. 5).

TeachMover Architecture

RUC

OPERATOR

OperatorConnector

MUC

RUCConn

Tool

Fig. 5. Identification of a

– Robot Unit Controllers (RUCs): This architectural ele-ment represents the robot, which is composed of theMUCs and Tools coordinated by means of a connector(see Fig. 5).– The Architectural Model: This level represents theinteractions between operators and robots throughouta connector (see Fig. 5).

From the manual of the robot the components of therobot and the different level of composition have been iden-tified. These component types are illustrated in their corre-sponding level of granularity using a tree view in Fig. 5. Inaddition, the connectors needed to coordinate these com-ponents as well as to provide a suitable behaviour of thearchitecture have been identified. Connectors are necessarybecause PRISMA introduces connectors as first order citi-zens of architectural models. As a result, PRISMA avoidsthe dependencies among components that ADLs withoutconnectors encounter by specifying coordination rulesinside components [44].

Both architectural elements and the services that mustbe interchanged among them can be identified during thisstage. These services are requested and/or provided bythe architectural elements. Since a PRISMA interface is aset of services that is provided and/or requested by meansof the ports of architectural elements, the identification ofthese services implies the identification of the interfaces.The ports of architectural elements and the interconnec-tions among these ports can also be detected taking intoaccount the identified interfaces.

ector

SUC

MUCConnector

Wrist

Actuator

SUCConnector

Sensor

Actuator

WristConnector

Sensor

Actuator

ToolConnector

Sensor

rchitectural elements.


5.1.2. Identification of crosscutting-concerns

The concerns that crosscut the software system must beidentified from the requirements specification in order tomodularize them into reusable entities called aspects. Inthe case of the TeachMover, the crosscutting-concerns thatwe have identified in the case study are the following:

• Functional: The purpose of the TeachMover softwaresystem is to move the robot. The robot has a motor toaccurately perform movements by half-steps. A half-stepis an angular advance that is produced by a stimulatingimpulse. In the case of the TeachMover, the movementscan be requested using half-steps or inverse cinematics(moving to a specific point in space). This functionality,together with the gripper functionalities allows the robotto move objects from an initial position to a final one.The movements of the robot are ordered by an operatorfrom a computer.

• Safety: Safety directives are necessary for monitoringthe TeachMover movements in order to make sure thatthe movements are safe for the robot, the operator,and the environment that surrounds them.

• Coordination: The inner behaviour of joints (SUCs) andthe movements in which more than one joint has to bemoved must be coordinated. In addition, the requestsof the operator and the performance of the movementsmust be synchronized.

5.2. 2nd Stage: architecture modelling

Once the interfaces, aspects, architectural elements andtheir ports have been identified, the skeleton of the architec-tural elements and the aspects can be defined. The analyst is

Fig. 6. The methodology of

then ready to start the modelling process of the softwarearchitecture. The modelling stage of our methodology isthe main contribution of this paper; that is, how can anaspect-oriented software architecture be modelled. Thisstage can be divided into five modelling steps: Interfaces,Aspects, Simple Architectural Elements, Complex Architec-tural Elements, and Configuration (see Fig. 6).

It is important to keep in mind that the enumeration ofthese steps is not a restrictive order. The enumeration sim-ply indicates the dependencies between the different con-cepts that arise when the architectural model is beingmodelled. These dependencies are the following:

– To configure an architectural model, the concepts thatare instantiated during the configuration process musthave been previously defined.– To completely define a complex architectural element,the architectural elements that it consists of must havebeen previously defined.– To completely define an architectural element, theaspects that it imports and the interfaces that their portsuse must have been previously defined.– To completely define an aspect that uses interfaces, theinterfaces must have been previously defined.

Even though the order of these steps can be different, itshould be followed in order to completely define an archi-tectural model. In other words, it does not mean that par-tial descriptions of the architectural elements, aspects orarchitectural models cannot be performed during the devel-opment process. The analyst can start the modelling pro-cess from either steps 1, 2, 3, or 4, obtaining partialsolutions of the model, and can go backward or forwarddepending on his/her needs.

the PRISMA approach.


5.2.1. Step 1: Interfaces

Interfaces are specified in step 1 of the PRISMA archi-tecture modelling stage. This is due to the fact that it isnot necessary to previously define other elements of themodel. Interfaces are stored in a PRISMA repository forreuse (see step 1, Fig. 6).

The specification of the interfaces identified in the stagepresented in 3.1.1. consists of describing the interface ser-vices and their signatures. The signature of a service spec-ifies its name and parameters. The data type and the kind(input/output) of parameters are also declared. An exampleof an interface is shown in Fig. 7.

5.2.2. Step 2: Aspects

As it has been previously mentioned, a PRISMA aspectencapsulates a concern that crosscuts the architectural ele-ments of software architectures. This aspect semantics isdifferent from any of the architectural terms in the softwarearchitecture discipline that currently exist. The notion ofaspect has an entity of its own, and aspects are first-ordercitizens of the PRISMA AOADL.

Aspects are defined in step 2 of the PRISMA architec-ture modelling stage using the combination of two formal-isms: a modal logic of actions [46] and a dialect of thepolyadic p-calculus [26]. p-calculus is used to specify andformalize the processes of the PRISMA model, and themodal logic of actions is used to formalize how the execu-tion of these processes affects the state of aspects. The kindof aspects and the number of each one depends on the soft-ware system. Aspects are reusable entities that define a spe-cific behaviour of a crosscutting-concern and are, therefore,stored in a PRISMA repository (see step 2, Fig. 6). As aresult, not only can aspects be used more than once in asoftware architecture description, they can also be reusedin different software architectures.

There are aspects that specify the semantics of the ser-vices that are published by an interface (public services),there are aspects that specify the semantics of services thatare not published by any interface (private services), andthere are aspects that specify the semantics of both, publicservices and private services. The aspects that specify thesemantics of public services must be defined after the inter-face of their services has been defined. This is why inter-faces are defined in step 1 and aspects are defined in thestep 2 of the methodology. However, this does not con-strain the specification order. Either the interface is definedbefore the aspect, or the services are initially defined as pri-vate services of the aspect and are then changed to publish

Fig. 7. The ISU

services by means of an interface. Furthermore, when theneeded interfaces are reused from the repository, step 1 isnot necessary.

The aspects are defined by taking into account the cross-cutting-concerns identified in stage 3.1.1. The number ofaspects for the same concern is decided by the analyst, tak-ing into account criteria such as reusability and under-standing. Depending on the analyst’s criteria, he/she willdefine one aspect for a concern or several aspects for thesame concern. For example, for the safety concern thatcrosscuts the software system, two safety aspects can bedefined. Each of these aspects has a different safety behav-iour. In this paper, due to space limitations, we are going tofocus on the specification of a safety and a coordinationaspect of the case study.

5.2.2.1. The safety aspect. The concerns (safety, coordina-tion, functionality, distribution, etc.) that an aspect canspecify in PRISMA is not constrained because the concernsvary depending on the system and the domain that is beingmodelled. A keyword is used to establish the concern of theaspect that is being specified. For example, in this case, theSafety word establishes that every property, service, orbehaviour that is specified in the aspect is related to thesafety concern (see Fig. 8). This keyword is a property ofa PRISMA aspect called concern, whose value is providedwhen a specific aspect is defined. There is no predefined listof keywords; the value is introduced by the analyst whenhe/she starts the aspect modelling task.

The concern of an aspect and its name are detailed at thehead of the aspect. Several constant attributes are declaredin the body in order to store the information of the mini-mum and maximum values that have to be taken intoaccount to preserve the safety of the TeachMover (see Sec-tion 1, Fig. 8). Begin and end services start and end the exe-cution of an aspect, respectively (see Sections 2 and 5,Fig. 8). Also, several services to preserve the safety of thesystem are defined in the SMotion aspect using dynamiclogic. Some of them are specified in Section 3 of Fig. 8.Due to space limitations, only the complete specificationof the service check is presented. This service ensures thatthe requested movement is safe by determining whether itis between the minimum and maximum degree (see Section4, Fig. 8). In addition, transactional operations are definedto execute a set of services atomically (see Section 6, Fig. 8).Finally, the protocol defines the process of execution of theaspect services using a dialect of p-calculus (see Section 7,Fig. 8).

C interface.

Fig. 8. The safety aspect SMotion.


5.2.2.2. The coordination aspect. The coordination aspectdefines the interactions needed to coordinate the sendingof movements to the robot and the robot’s answers. Theseanswers notify whether or not the movements have beensatisfactorily performed. In this case, the aspect uses theservices of several interfaces. This is detailed at the headof the aspect (see Fig. 9), that means, that these servicesare public. As a result, these interfaces have been previ-ously defined.

Since the request of a movement to the robot does notguarantee that it will be satisfactorily performed, the coor-dination aspect must coordinate the position of the jointthat is synchronizing the movement request (see Sections2 and 3, Fig. 9) with the movement notification of the robot(moveOk service, see Section 4, Fig. 9). At this point, theaspect changes the value of the robot position, i.e., thehalf-step attribute (see Section 1, Fig. 9).

The protocol of the CProccessSUC aspect coordinatesthe requested movements and the notification movementsof the robot. It is composed of three processes CProcess-

SUC, MOTION, and ANSWER (see Section 5, Fig. 9).The CProcessSUC process starts the execution of theaspect (begin), initializes the attributes that need a value(Not Null), and starts the MOTION process (see Section6, Fig. 9). This process either receives a movement request

or ends the aspect execution (see Section 7, Fig. 9). Finally,this MOTION process continues with the ANSWER pro-cess, in which the coordination process waits for the sen-sor’s answer and notifies of the failure or success of themovement (see Section 8, Fig. 9).

5.2.3. Step 3: Simple architectural elementsThe definition of simple architectural elements is per-

formed in step 3 of the PRISMA architecture modellingstage. The aspects that are defined in step 2 are used tocompletely define these architectural elements. An architec-tural element imports the aspects that define the concernsthat it requires. For this reason, aspects must be definedbefore architectural elements.

The same aspect is imported by each architectural ele-ment that needs to take into account the same behaviourof this concern (crosscutting-concerns). As a result, anaspect can be imported by one or more architectural ele-ments (see steps 2 and 3 of Fig. 6). It is important to notethat the changes performed in an aspect also affect everyarchitectural element that imports this aspect.

From the architectural element point of view, eacharchitectural element is formed by a set of aspects. Forexample, the connector in Fig. 6 is made up of a safetyaspect and a coordination aspect.

Fig. 9. The coordination aspect CProcessSUC.


In PRISMA, weavings weave the different aspects thatform an architectural element and they are encapsulatedinside the architectural element. The temporal order ofthe weaving process is described by temporal operationscalled weaving operators. These operators can be extendedin future work. Initially, we have the after, before, around,afterif, beforeif and insteadif operators whose semantics aredefined in the following:

A weaving that relates service s1 of aspect A1 and services2 of aspect A2 can be specified using the following operators:

• A2.s2 after A1.s1: A2.s2 is executed after A1.s1.• A2.s2 before A1.s1: A2.s2 is executed before A1.s1.• A2.s2 instead A1.s1: A2.s2 is executed in place of A1.s1.• A2.s2 afterif (Boolean condition) A1.s1: A2.s2 is exe-

cuted after A1.s1 if the condition is satisfied.• A2.s2 beforeif (Boolean condition) A1.s1: if the condition

is satisfied, first A2.s2 is executed and then A1.s1is exe-cuted; otherwise, only A2.s2 is executed.

• A2.s2 insteadif (Boolean condition) A1.s1: A2.s2 is exe-cuted in place of A1.s1 if the condition is satisfied.

As a conclusion, a PRISMA simple architectural ele-ment is specified by a set of aspects, the weavings ofaspects, and a set of ports that have an associated inter-face. Ports represent the points of interaction of architec-tural elements. The architectural elements that are definedin this step are types that are reusable by different soft-ware architectures because they are stored in the PRISMArepository. The storage of PRISMA architectural elementsimplies the storage of the aspects that they import. Inaddition, the reusability of the aspect can be due to thefact that it is reused in many architectural elements andalso when the architectural element that imports theaspect is reused.

The simplest components that are found in the Teach-

Mover system are actuators and sensors:

• Actuator: An actuator has two ports. To describe itsfunctional behaviour, it imports the FActuator aspectthat has been previously stored in the repository (seeFig. 10).

Fig. 10. The Component Actuator.


• Sensor: A sensor has two ports. To describe its func-tional behaviour, it imports the FSensor aspect thathas been previously stored in the repository (seeFig. 11).

In addition, the actuators and sensors for the tool andthe wrist joints are defined as new architectural elements.They have the same functionality as the ones presented inFigs. 10 and 11. However, the signature of the services thatthey offer is different, that is, the number of parameters andtheir types is different.

Weavings are only specified when they are necessary toweave the execution of two services from different aspects.An example of weavings appears in the SUCConnector

architectural element where the joint is moved only afterthe connector is sure that the movement is safe (see theweavings section of the SUCConnector in Fig. 12).

The invocation of the movejoint service (the second ser-vice of the weaving) of the CProcessSUC aspect triggers theexecution of a weaving. When a weaving is specified, theweaving operator is chosen from the point of view ofthe service that triggers the weaving; that is, dependingon whether the service needs the execution of a servicebefore, after, or instead of it. As a result, the weaving ofthe SUCConnector (see Fig. 12) means that the check

Fig. 11. The Comp

Fig. 12. The Connecto

service of the SMotion safety aspect will be executed beforethe movejoint service of the CProcessSUC coordinationaspect. The condition also establishes that the executionof the movejoint service must only be performed if theSecure parameter of the check service returns true.

The connectors that coordinate the actuators and thesensors of the tool and the wrist joints are also defined asnew architectural elements. SUCconnector, WristSUCcon-

nector, and ToolSUCConnector are architectural elementsstored in the PRISMA repository. These three architecturalelements import the same coordination (CProcessSUC)and safety (SMotion) aspects (crosscutting-concerns); how-ever their behaviour is different because they have differentweavings. This is a clear example of the reuse of aspectsinside the same architectural model thanks to the fact thatthe definition of weavings outside aspects and inside archi-tectural elements, and an example of how these aspectscrosscut the behaviour of several architectural elements.

The Actuator, Sensor, and their connector SUCConnec-

tor are reusable architectural elements that can be used sev-eral times in the TeachMover architectural model or inanother architecture specification such as the EFTCoRrobot. In the case of the TeachMover, they have been spec-ified in the simplest way. However, in the EFTCoR, theyalso have a distribution aspect in order to provide distrib-

onent Sensor.

r SUCConnector.


uted behaviour to these components. As a result, we havereused the Actuator, Sensor and SUCConnector architec-tural elements of the TeachMover in the architecture ofthe EFTCoR. We have modified them by adding a distribu-tion aspect, a pair of weavings between the functional anddistribution aspects of the Actuator and Sensor, andanother pair of weavings between the coordination and dis-tribution aspects of the SUCConnector. This is an exampleof reusability of defined components in other architecturalmodels using the PRISMA repository. This reusabilityavoids having to start from scratch to build a new architec-tural model. The analyst can reuse the architectural ele-ments in their original way or can reuse them and thenintroduce the changes that the new software systemrequires, just as we did with the actuator and sensor com-ponents of the EFTCoR.

An actuator and a sensor must be coordinated through aconnector in order to separate their computations fromtheir interactions [44]. The SUCConnector imports a coor-dination and a safety aspect in order to define its behaviour(see Fig. 12).

5.2.4. Step 4: Complex architectural elements

PRISMA complex components are called systems. Sys-tems are defined in the 4 step of the PRISMA architecturemodelling stage.

A PRISMA system is a complex component thatimports a set of connectors, components, and other sys-tems that must be correctly attached. A system is definedby using two kinds of communication channels: attach-ments and bindings.

To completely specify a system, the architectural ele-ments that the system is composed of should be previouslydefined. In addition, the communication channels that per-mit the communication among them are defined. It isimportant to emphasize that the attachments are onlydefined if the system includes components and connectorsthat must be coordinated.

Systems are defined as patterns or architectural styles[18] that can be reused in any software architecture when-ever they are needed. For this reason they are stored in thePRISMA repository.

Fig. 13. The System SUC (

It is important to note that any changes that occur inaspects affect the architectural elements that import themand, consequently, affect the systems that import thesearchitectural elements. Moreover, the changes that occurin architectural elements that are imported by a system alsoaffect the system (see step 3, Fig. 6).

In the case of the TeachMover, there are several systems,at different levels of granularity. These systems are guidedby the skeleton identified in the stage 3.1.1 (see Fig. 5).The SUC (Simple Unit Controller) system is composed ofan actuator, a sensor, and the connector that synchronizesthem. The system specifies the architectural elements that itis composed of and the communication channels amongthem (see Fig. 13).

The SUC system delegates the commands that it receivesto the connector in order to perform the movementsbetween the actuator and sensor in a synchronized way.For this reason, the SUC system and the SUCConnector

have a binding between their portMUC and portSUC ports,respectively. In addition, two attachments haven beendefined in order to establish the communication channelsbetween the Actuator and the SUCconnector, and the Sen-sor and the SUCconnector, respectively. A ToolSUC and aWristSUC are also defined with their corresponding actua-tors, sensors, connectors and their relationships. The SUCsystem is stored in the PRISMA repository so that it can bereused as an architectural pattern.

The MUC (Mechanism Unit Controller) system is thethird layer of granularity of the decomposition of theTeachMover system. It integrates a set of SUCs and a con-nector. The connector coordinates the SUCs in order toachieve a common goal. Specifically, the MUC of theTeachMover is composed of the generic SUC, the SUC ofa wrist, and a connector that synchronizes them (seeFig. 14). As a result, the MUC of the TeachMover ismatched with the arm of the robot and specifies the behav-iour required to accurately perform its movements. TheMUC is also stored in the PRISMA repository.

The RUC (Robot Unit Controller) system coordinatesevery part of the robot and is composed of the MUC ofthe arm and the SUC of the tool, which are synchronizedthrough a connector (see Fig. 15). The SUC of the tool is

Simple Unit Controller).

Fig. 15. The System RUC (Robot Unit Controller).

Fig. 14. The System MUC (Mechanism Unit Controller).


not inside the MUC system in order to easily allow changesin the tool. For example, the tool of the TeachMover is agripper, but it can be changed for a paintbrush, a hosepipe,etc., in order to perform other tasks. The RUC is matchedwith the TeachMover. As a result, we obtain a softwarearchitecture that is easy to evolve.

Finally, the last layer of decomposition is composed of theoperator, the robot (RUC), and the connector that coordi-nates them (see Fig. 16). This last level provides us the mostabstract view of the software architecture, which is called theArchitectural Model. It is important to emphasize that sincethe architectural model does not define a system that encap-sulates it, bindings are do not need to be defined.

5.2.5. Step 5: Configuration of software architectures

architectural elements

Finally, the architectural elements that have beendefined in the previous steps and have been stored in thePRISMA repository are instantiated in step 5. In orderto understand the step trace of the approach, it is impor-tant to take into account that instances have all theproperties and behaviours of their architectural elements,and as a consequence, instances have the properties and

Fig. 16. The architectural m

behaviours of the aspects that their architectural elementsimport. As a result, when an architectural element isinstantiated, the aspects that it imports are also instanti-ated in order to have their specific state and behaviour.

A specific software architecture is defined by connectinga set of instances of components, systems, and connectorswith each other (see Fig. 6). For this reason, the instantia-tion of the architectural elements of a model and the defi-nition of attachment and binding relationships amonginstances is necessary to obtain an executable architecturalmodel.

To obtain the software architecture of the TeachMover,the SUC has been instantiated three times in order toobtain the base, shoulder, and elbow joints of the robot(see Fig. 13). The gripper and the wrist are instances ofthe ToolSUC and WristSUC, respectively. As a result ofthese instantiations, the instantiation of the MUC gener-ates the configuration that appears in Fig. 17.

The RUC and the architectural model of the TeachMov-

er are instantiated generating one instance for each one ofthem. This instantiation constitutes the last step of themodelling stage. As a result of this step, the software archi-tecture of the TeachMover is completely defined.

odel of the TeachMover.

Fig. 17. The configuration MUC for the TeachMover.


5.2.6. Summary

The TeachMover example illustrates that the PRISMAapproach allows the development of aspect-oriented soft-ware architectures as if aspects and architectural elementswere building blocks. You can work with them in differentways to obtain different results. This flexibility and facilityfor working is achieved thanks to the fact that aspects andcomponents are independent entities that can be importedin different entities of the same software architecture or indifferent ones.

The introduction of aspects in a separate entity allowsfor the TeachMover software architecture to separate thesafety concern in the SMotion aspect. This aspect is onlydefined once and it is imported by the SUCconnector,WristSUCconnector, ToolSUCconnector, MUCconnector

and RUCconnector connectors by referencing this aspect.As a consequence, the aspect is used by the instances ofthese connectors. For example, the TeachMover instancesof the SUCconnector are the BaseSUCconnector, Shoulder-

SUCConnector and ElbowSUCConnector. As a result ofconsidering aspects to model the TeachMover, tangled codeis avoided by separating coordination properties fromsafety properties. In addition, this separation of concernscan improve the maintenance process of the system dueto the fact that the introduction of a change in the safetyproperties of the TeachMover only requires modifying theSMotion Aspect and, consequently, all the changes arepropagated to the connectors and their instances.

The PRISMA repository also promotes the reuse ofarchitectural elements and aspects in different softwarearchitectures. They can be used as they are stored in therepository or can be adapted to the features of the newarchitecture that is being modelled. For example, most ofthe architectural elements of the TeachMover were reusedin the EFTCoR software architecture. The specific proper-ties of the EFTCoR were easily adapted; for example, someof the robot pieces of the EFTCoR are distributed. Thisproperty was introduced by defining a distribution aspect

and importing it from the reused architectural elementsof the TeachMover that represent these pieces. It must benoted that reuse is limited for software architectures of dif-ferent domains, but the PRISMA repository could be agreat contribution for reuse in product families such asthe tele-operation family. In addition, a large repositorywith good searching mechanisms could provide excellentsupport for the development and maintenance of software.

5.3. 3rd Stage: code generation and execution

Most ADLs are not expressive enough to define thecomplete behaviour of a software system, since they onlydescribe the structure of systems. In PRISMA, aspects pro-vide the mechanism to completely define not only the func-tional behaviour of the system, but also its non-functionalrequirements. The PRISMA AOADL is a formal languagebased on Modal Logic of Actions and Polyadic p-calculusthat allows us: (1) not to worry about implementationdetails, (2) to verify aspect-oriented architectural models,(3) to generate code from architectural specifications and(4) to maintain the traceability from the software architec-ture to its implementation. Even though these are defini-tively advantageous characteristics, the use of a formallanguage is really difficult. For this reason, we provide aframework to model PRISMA software architectures usingan intuitive and friendly graphical AOADL (see Fig. 18).In addition, the framework gives the analyst support to fol-low the PRISMA methodology in order to take maximumadvantage of the PRISMA approach.

The framework has been developed using DSL tools[10], which has provided us a simple way of following theMDD paradigm by developing the model compiler andthe modelling tools of the PRISMA framework. The modelcompiler has been developed using the template files thatDSL tools provides for the code generation. We have pro-grammed our PRISMA templates to be able to generateC# code and the textual AOADL from software architec-

Fig. 18. The PRISMA modelling tool.


tures that have been modelled graphically using thePRISMA modelling tools. Fig. 19 shows the equivalencesbetween the graphical representation of an interface, andthe AOADL and C# code that have been generated by exe-cuting the code generation templates of the PRISMAcompiler.

In addition, Fig. 20 shows the complete support fordeveloping executable PRISMA architectural models fol-lowing the MDD paradigm and using the DSL tools. Thecomplete PRISMA framework is called PRISMA CASE.The Figure shows the architecture of the framework andhow the parts that compose the PRISMA framework allowus to automatically generate executable C# code fromarchitectural models that have been modelled using themodelling tool. This generation is possible thanks to thecode generation templates (model compiler), which isolatethe specification from the source code preserving their inde-pendence. Until now, PRISMA CASE generates PRISMAaspect-oriented C# code that is executable in .NET frame-work thanks to our PRISMANET middleware, whichgives support to aspect execution over .NET technology[38].

The PRISMA methodology is put into practice usingthe PRISMA CASE, except for the 1st Stage that the iden-tification of architectural elements and aspects is made byhand. The 2nd Stage is developed using the PRISMA TypeModelling Tool and the PRISMA Configuration Model-ling Tool. The STEPS 1–4 are developed using thePRISMA Type Modelling Tool, where all the reusable

types (interfaces, aspects, simple architectural elementsand complex architectural elements) and the architecturalmodel of the software system are modelled in a graphicalway by drawing and dropping the PRISMA modellingprimitives. The STEP 5 is developed using the PRISMAConfiguration Modelling Tool, where the configurationof the initial architecture of a specific system is modelledby instantiating the types and the architectural model thathas been defined in previous STEPS. Finally, the 3rd Stageis developed using the PRISMA Model Compiler, to gener-ate the code of the types and its instances. The code of thetypes is generated by executing the PRISMA Model Com-piler from the PRISMA Type Modelling Tool, and thecode of the instances is generated by executing thePRISMA Model Compiler from the PRISMA Configura-tion Modelling Tool. Next, the execution of the generatedcode joint the PRISMANET middleware can be launchedfrom the PRISMA Configuration Modelling Tool. Oncethe aspect-oriented software architecture is executed theuser can interact with it using the PRISMA GenericGUI, which allows the user to execute services, query thevalue of attributes and validate the correct behaviour ofeach of the architectural elements that compose thearchitecture.

6. Discussion

Although this paper has placed emphasis on the archi-tecture modelling stage of the methodology, the PRISMA

Fig. 19. The PRISMA code generation.


approach includes a model, an AOADL that is textuallyand graphically supported, a technological middleware(PRISMANET), and a tool (see Fig. 20). The PRISMAmethodology is supported by a framework for the con-struction of aspect-oriented software architectures thatare independent of specific technologies.

The first stage of the PRISMA methodology is the iden-tification of the aspects and the architectural elements of asoftware architecture. Currently, this identification is per-formed in an intuitive way from the requirements docu-ment of the system. However, we are working in thisstage in order to propose guidance for the user in this iden-tification task [29,30].

The modelling stage of the PRISMA methodology isbased on the PRISMA metamodel. It has been definedby integrating aspects and software architectures. In thisway, software architectures can be constructed gainingthe advantages of two different paradigms: the aspect-ori-ented paradigm (AOP) and the component-based para-digm. One of these advantages is the reusability ofsoftware at different levels of granularity. As an example,the reusability level of the SUC system (see Fig. 13) is illus-trated in the following:

6.1. Analysis of the reusability of the SUC system

The reusability of the SUC is analyzed by taking intoaccount the system, its architectural elements and theaspects that these architectural elements import. In

addition, the reusability is going to be analyzed at thetype level and at the configuration level.Fig. 21 shows the number of times that an aspect isreused by different architectural elements and the namesof the architectural elements that import the aspect. Theaspects are enumerated in the first columns of the twotables. These aspects are the ones that have been usedfor defining the SUC system. The first table details thereusability at the type level, and the second table detailsthe reusability at the configuration level, respectively.From these tables, it is possible to conclude that: theaspect SMotion is defined once and it is reused by fivearchitectural elements at the type level and by sevenarchitectural elements at the configuration level. Theaspects FActuator FSensor and CProcessSUC have beendefined once and they are reused by one architecturalelement at the type level and three architectural elementsat the configuration level.On the other hand, Fig. 22 shows the number of timesthat an architectural element type is reused at the config-uration level of the architecture by means of itsinstantiation.In addition to the SUC rates of reusability inside theTeachMover software architecture, the reusability ofaspects and architectural element types by other soft-ware architectures, such as the EFTCoR software archi-tecture, must be taken into account. For example, in thecase of the EFTCoR we have imported every aspect andarchitectural elements of the TeachMover without hav-

Fig. 20. The PRISMA framework.

Fig. 21. Reusability of aspects.

Fig. 22. Reusability of architectural elements.


ing to start the modelling process from scratch. Some ofthe reused aspects have been modified introducing newproperties and others had not to be modified. Some ofthe reused architectural elements have been modifiedadding new aspects and/or weavings and others havebeen preserved in their original version.

Maintainability and evolution are also gained from inte-grating the aspect-oriented paradigm (AOP) and the com-ponent-based paradigm. This is due to the fact that aspects

and architectural elements facilitate the task of locatingwhere the changes must occur. For example, in the caseof the TeachMover, safety properties are located in onlyone place, in the aspect SMotion. As a result, if a changein the safety properties occurs, the safety aspect is onlymodified instead of changing the five architectural elementsthat import it at the types level. But not only the number ofchanges is reduced, but also the time invested in locatingwhere the change must be introduced is improved. In ourcase, the safety properties of the aspect have to be onlysearched; whereas in a non-aspect-oriented approach, thearchitectural elements with tangled concerns have to besearched and the location of the safety properties is moredifficult. Finally, another important advantage is the reduc-tion of code. As it was demonstrated by Kizcales et al. [23],the lines of code are reduced. Our proposal avoids the rep-lication of code. For example, t the lines of the safetyaspect SMotion were avoided to be repeated five times atthe type level.


The DSL tools development environment has been cho-sen in order to provide a framework for the PRISMAapproach. DSL tools allow us to define PRISMA meta-model, associate a graphical notation to each metamodelconcept and its instantiation, and implement the C# codegeneration templates of PRISMA. The PRISMA frame-work provides mechanisms to optimize the programming,reusability, and modularity of code. Developers use thegraphical notation of the PRISMA AOADL to build theirsoftware architectures using the methodology presented inthis paper. After, the models are verified they can generateautomatically the code. The TeachMover software architec-ture has been modelled, its code has been generated and ithas been executed in the.NET platform. As a result,PRISMA has made it possible to move a robot using anaspect-oriented architecture that is executed in .NET tech-nology (see demonstrations in [42]).

7. Conclusions and future work

In this paper, the PRISMA approach which introducesaspects in software architectures has been presented indetail. It has been designed to integrate aspects as a newconcept and as first-order citizens of software architectures.PRISMA is presented as a symmetrical model because itdoes not distinguish a kernel entity that encapsulates func-tionality; functionality is also specified as an aspect. Inaddition, other concerns related to non-functional require-ments can be weaved with other non-functional concerns.In this way, PRISMA shows that non-functional concernscan have the same relevance as functional ones.

PRISMA offers a clear approach in which both aspectsand software architectures are smoothly integrated with aclear semantics. Aspects are defined independently of archi-tectural elements and the final software architecture of thesystem. Architectural elements are defined by means ofthe importation of aspects. As a result, aspects crosscutthe architectural elements of PRISMA software architec-tures. PRISMA is presented with a methodology, whichis divided into five steps, to allow the development andmaintenance of software systems in a simple and flexibleway.

The precise semantics of the PRISMA language gives usthe chance to verify model properties and to compile mod-els to obtain specific executable systems. A PRISMANETmiddleware [38] has been developed to support PRISMAon .NET platform. We are currently developing compilersfor specific infrastructures such as C#, Web Services,XML, etc.

The case study presented in this work is a suitable wayto illustrate how the PRISMA approach serves to developcomplex software. The example is bounded enough to beeasily understood. It shows how the PRISMA approachenables the deployment of software and provides flexibilityto the development of software systems.

The ideas developed in the case study have been appliedto specific products of the EFTCoR and TeachMover. The

benefits of applying PRISMA to the case study are mainly:(1) the definition of reusable concerns that crosscut thesoftware architecture called aspects and the storage in arepository, (2) the definition of reusable architectural ele-ments by reusing aspects, (3) the definition of complexarchitectural elements reusing other architectural elements,(4) building the formal software architecture of the systemusing a friendly graphical notation independently of tech-nology and (5) the reduction of the development time ascode is automatically generated from the graphical nota-tion to a specific technology.

It is important to emphasize that this paper is a proof ofthe emergent convergence of two areas of engineering thathave historically been separated; software engineering androbotics engineering. In this paper, we have applied a soft-ware engineering approach to the development of a roboticsystem. In this way, this development has taken advantageof the good properties provided by this software engineer-ing approach, especially reuse of components, maintain-ability, evolution, etc.

As future work, we are going to introduce validationtechniques in our modelling tool and to compare aspect-oriented and non-aspect-oriented applications to be ableto measure the advantages that PRISMA provides. Thismeasurement should be made taking into account differentcase studies and domains. In addition, we are going toextend the language to support more mechanisms for spec-ifying architectural patterns. We want to provide supportfor the COTS importation in the PRISMA methodology.Finally, we are going to implement an assistant for thePRISMA repository and the code generation patterns forother technologies and languages.

Acknowledgements

This work has been funded by the Department of Sci-ence and Technology (Spain) under the National Programfor Research, Development and Innovation, META pro-ject TIN2006-15175-C05-01.

References

[1] B. Alvarez, P. Sanchez, J.A. Pastor, F. Ortiz, An ArchitecturalFramework for Modeling Teleoperated Service Robots, InternationalJournal of Information, Education and Research in Robotics andArtificial Intelligence, Cambridge University Press, 2005.

[2] L.F. Andrade, J.L. Fiadeiro, Architecture based evolution of softwaresystems, in: M. Bernardo, P. Inverardi (Eds.), Formal Methods forSoftware Architectures, LNCS 2804, Springer Verlag, Bertinoro,Italy, 2003.

[3] F. Bachman, L. Bass et al., The Architecture Based Design Method,Technical Report CMU/SEI-200-TR-001, Carnegie Mellon Univer-sity, USA, January (2000).

[4] E. Baniassad, S. Clarke, Finding aspects in requirements with Theme/Doc, in: Proceedings of the Workshop on Early Aspects, held with theInternational Conference on Aspect-Oriented Software Development(AOSD), Lancaster, UK, 2004.

[5] O. Barais, E. Cariou, L. Duchien, N. Pessemier, L. Seinturier,Transat: a framework for the specification of software architecture


evolution, in: Proceedings of the First International Workshop onCoordination and Adaptation Techniques for Software Entities(WCAT), held with ECOOP, Oslo, June, 2004. <http://wcat04.u-nex.es/bib>.

[6] H. Bruyninckx, B. Konincks, P. Soetens, A Software Framework forAdvanced Motion Control, Department of Mechanical Engineering,K.U. Leuven, OROCOS project inside EURON, Belgium, 2002.

[7] R. Chitchyan, A. Rashid, P. Sawyer, A. Garcia, M. Pinto, J. Bakker,B. Tekinerdogan, S. Clarke, A. Jackson, Report synthesizing state-of-the-art in aspect-oriented requirements engineering, architectures anddesign, Lancaster University, Lancaster, AOSD-Europe DeliverableD11, AOSD-Europe-ULANC-9, 18 May, 2005, pp. 1–259, <http://www.comp.lancs.ac.uk:8080/c/portal/layout?p_l_id=1.94>.

[8] E. Coste-Maniere, R. Simmons, Architecture, the backbone ofrobotic system, in: Proceedings of the IEEE International Conferenceon Robotics & Automation, IEEE Computer Society, San Francisco,USA, April, 2000, pp. 505–513.

[9] C. Cuesta, M.P. Romay, P. De La Fuente, M. Barrio-Solorzano,Architectural aspects of architectural aspects, in: Proceedings of theSecond European Workshop on Software Architecture, LNCS 3527,Springer Verlag, Pisa, June 2005.

[10] Domain-Specific Language (DSL) Tools, <http://lab.msdn.micro-soft.com/teamsystem/workshop/dsltools/default.aspx>.

[11] R. Douence, D. Le Botlan, Report Towards a Taxonomy of AOPSemantics, AOSD-Europe Deliverable D11, AOSD-Europe-INRIA-1, INRIA, CNRS, 7 July, 2005, pp. 1–13, <http://www.comp.lanc-s.ac.uk:8080/c/portal/layout?p_l_id=1.94>.

[12] T. Elrald, R.E. Filman, A. Bader, Aspect-oriented programming: anintroduction, Communications of the ACM 44 (10) (2001).

[13] C. Fernandez, J.A. Pastor, P. Sanchez, B. Alvarez, A. Iborra, Co-operative robots for hull blasting in European shiprepair industry,IEEE Robotics and Automation Magazine (RAM) (2005).

[14] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, 1995.

[15] A. Garcıa, C. Sant’Anna, E. Figueiredo, U. Kulesza, C. Lucena, A.von Staa, Modularizing design patterns with aspects: a quantitativestudy, in: Proceedings of the 4th international conference on Aspect-oriented software development, ISBN:1-59593-042-6, Chicago, Illi-nois, 2005, pp. 3–14.

[16] D. Garlan, Formal modelling and analysis of software architecture:components, connectors, and events, in: M. Bernardo, P. Inverardi(Eds.), Formal Methods for Software Architectures, LNCS 2804,Springer Verlag, Bertinoro, Italy, 2003.

[17] D. Garlan, in: J. Marciniak (Ed.), Software architecture, WileyEncyclopedia of Software Engineering, John Wiley & Sons, 2001.

[18] D. Garlan, M. Shaw, in: V. Ambriola, G. Tortora (Eds.), Anintroduction to software architecture, Advances in Software Engi-neering and Knowledge Engineering, vol. 1, World Scientific Pub-lishing Company, New Jersey, 1993.

[19] W. Harrison, H.L. Ossher, P.L. Tarr, Asymmetrically vs Symmetri-cally Organized Paradigms for Software Composition, IBM ResearchReport RC22685 (W0212-147) Thomas J. Watson Research Center,IBM, December, 2002.

[20] D. Irastorza, A. Jaime, O. Dı´ az, Component-Based Design: alterna-tives for the partition step, in: Proceedings of the Conference onSoftware Engineering and Databases (JISBD), Spain, 2000. (inSpanish).

[21] M. Katara, S. Katz, Architectural views of aspects, in: Proceedings ofthe International Conference on Aspect-Oriented Software Develop-ment (AOSD), ACM Press, March, 2003.

[22] G. Kiczales, E. Hilsdale, J. Huguin, M. Kersten, J. Palm, W.G.Griswold, An overview of AspectJ, in: Proceedings of the 15thEuropean Conference on Object-Oriented Programming, LNCS 2072,Springer Verlag, Budapest, Hungary, June 18–22, 2001.

[23] G. Kizcales, J. Lamping, A. Mendhekar, C. Maeda, Aspect-orientedprogramming, in: Proceedings of the 11th European Conference onObject-Oriented Programming (ECOOP), LNCS 1241, SpringerVerlag, Jyvaskyla, Finland, June 9–13, 1997.

[24] S. McDirmid, W.C. Hsieh, Aspect-Oriented Programming withJiazzi, in: Proceedings of the 2nd International Conference onAspect-Oriented Software Development (AOSD), Boston, Massachu-setts, USA, March, 2003, pp. 70–79.

[25] N. Medvidovic, R.N. Taylor, A classification and comparisonframework for software architecture description languages, IEEETransactions of Software Engineering 26 (1) (2000).

[26] R. Milner, The Polyadic pi-calculus: a Tutorial, Logic and Algebra ofSpecification, Springer, 1993, pp. 203–246.

[27] A. Moreira, J. Araujo, A. Rashid, A concern-oriented requirementsengineering model, in: Proceedings of the 17th International Confer-ence on Advanced Information Systems Engineering (CAiSE), LNCS3520, Springer-Verlag, Porto, Portugal, June 13–17, 2005.

[28] J. Munnelly, S. Fritsch, S. Clarke, An aspect-oriented approach to themodularisation of context, in: Proceedings of the IEEE InternationalConference on Pervasive Computing and Communications (PerCom),New York, USA, 2007.

[29] E. Navarro, P. Letelier, I. Ramos, Goals and quality characteristics:separating concerns, in: Proceedings of the Early Aspects 2004:Workshop on Aspect-Oriented Requirements Engineering and Archi-tecture Design, collocated to OOPSLA 2004, Vancouver, Canada,Monday, October 25, 2004.

[30] E. Navarro, I. Ramos, J. Perez, Software requirements for architec-tured systems, in: Proceedings of 11th IEEE International Require-ments Engineering Conference, Monterey, California, USA, IEEEComputer Society, ISBN 0-7695-1980-6, September 8–12, 2003, pp.365–366.

[31] A. Navasa, M.A. Perez, J.M. Murillo, Aspect modelling at architec-ture design, in: Proceedings of the Second European Workshop onSoftware Architecture, LNCS 3527, Springer Verlag, Pisa, June 2005.

[32] P. Noriega, C. Sierra, Auctions and multi-agents systems, LatinAmerican Journal of Artificial Intelligence 6 (1998) 68–84.

[33] H. Ossher, P. Tarr, Multi-dimensional separation of concerns and thehyperspace approach, in: Proceedings of the Symposium on SoftwareArchitectures and Component Technology: The State of the Art inSoftware Development, Kluwer, 2000.

[34] H. Ossher, P. Tarr, Multi-Dimensional Separation of Concerns usingHyperspaces, IBM Research Report 21452, April, 1999.

[35] D.L. Parnas, On the criteria to be used in decomposing systems intomodules, Communications of the ACM 15 (12) (1972) 1053–1058.

[36] R. Pawlak, L. Seinturier, L. Duchien, G. Florin, F. Legond-Aubry, L.Martelli, JAC: an aspect-based distributed dynamic framework,Software – Practice and Experience 34 (2004) 1119–1148.

[37] J. Perez, N. Ali, J.A. Carsı, I. Ramos, Dynamic Evolution in Aspect-Oriented Architectural Models, in: Proceedings of the SecondEuropean Workshop on Software Architecture, LNCS 3527, SpringerVerlag, Pisa, June 2005.

[38] J. Perez, N. Ali, C. Costa, J.A. Carsı, I. Ramos, Executing aspect-oriented component-based software architectures on .NET technol-ogy, in: Proceedings of the Conference on .NET Technologies, vol. 3,No.1–3, ISSN 1801-2108, 2005.

[39] J. Perez, N. Ali, J.A. Carsı, I. Ramos, Designing software architec-tures with an aspect-oriented architecture description language, The9th International Symposium on Component-Based Software Engi-neering (CBSE 2006), Malardalen University, Vasteras near Stock-holm, Sweden, June 29th–1st July 2006.

[40] D. Perry, A. Wolf, Foundations for the study of software architec-ture, ACM Software Engineering Notes 17 (4) (1992) 40–52.

[41] M. Pinto, L. Fuentes, J.M. Troya, DAOP-ADL: An architecturedescription language for dynamic component and aspect-baseddevelopment, in: Proceedings of the International Conference onGenerative Programming and Component Engineering (GPCE),LNCS 2830, Springer Verlag, Erfurt, Germany, September 22–25,2003.

[42] PRISMAWeb Page, <http://prisma.dsic.upv.es>.[43] K.U. Scholl, J. Albiez, B. Gassmann, MCA: an expandable modular

controller architecture, in: Proceedings of the 3rd Real-Time LinuxWorkshop, Karlsruhe University, Milano, Italy, 2001.

http://wcat04.unex.es/bib

http://wcat04.unex.es/bib

http://www.comp.lancs.ac.uk:8080/c/portal/layout?p_l_id=1.94


http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx

http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx



http://prisma.dsic.upv.es


[44] M. Shaw, Procedure calls are the assembly language of softwareinterconnection: connectors deserve first-class status, in: Proceedingsof Workshop on Studies of Software Design, January, 1994.

[45] G.M.C. Sousa, J.B. Castro, Towards a Goal-Oriented RequirementsMethodology Based on the Separation of Concerns Principle.Workshop on Requirements Engineering (WER), ISBN8587926071, Piracicaba-SP, Brasil, November, 27–28, 2003.

[46] C. Stirling, in: Modal and temporal logicsHandbook of Logic inComputer Science, vol. 2, Clarendon Press, Oxford, 1992.

[47] S. Sutton, I. Rouvellou, Modeling of software concerns in cosmos, in:G. Kiczales (Ed.), Proceedings of the 1st International Conference onAspect-Oriented Software Development (AOSD), 2002, pp. 127–133.

[48] D. Suvee, B. De Fraine, W. Vanderperren, A symmetric and unifiedapproach towards combining aspect-oriented and component basedsoftware development, in: Proceedings of the 9th InternationalSymposium on Component-Based Software Engineering (CBSE2006), Malardalen University, Vasteras near Stockholm, Sweden,June 29th–1st July 2006.

[49] D. Suvee, W. Vanderperren, D. Wagelaar, V. Jonckers, There Are NoAspects. Electronical Notes in Theoretical Computer Sciences(ENTCS), Special Issue on Software Composition, vol. 114, January,2005, pp. 153–174.

[50] P. Tarr, H. Ossher, W. Harrison Jr., S.M. Sutton, N degrees ofseparation: multidimensional separation of concerns, in: Proceedingsof the 21st International Conference on Software Engineering (ICSE),Communication of the ACM, New York, 1999, pp. 107–119.

[51] The TeachMover Robot, <http://www.questechzone.com/microbot/teachmover.htm>.

[52] R. Volpe, I. Nesnas, T. Estlin, D. Mutz, R. Petras, H. Das, TheCLARAty architecture for robotic autonomy, in: Proceedings ofIEEE Aerospace Conference, vol. 1, Montana, USA, 2001, pp. 121–132.

[53] Y. Yu, J.C. Leite, J. Mylopoulos, From goals to aspects: discoveringaspects from goal models, in: Proceedings of the 12th IEEEInternational Conference on Requirements Engineering (RE), IEEEComputer Society, Kyoto, Japan, September, 2004.

http://www.questechzone.com/microbot/teachmover.htm

http://www.questechzone.com/microbot/teachmover.htm

integrating aspects in software architectures: prisma applied to robotic tele-operated systems

Documents