Information Hiding and Aspect-Oriented Modeling

Information Hiding and Aspect-Oriented Modeling Wisam Al Abed and Jörg Kienzle School of Computer Science, McGill University Montreal, QC H3A2A7, Canada Wisam.Alabed@mail.mcgill.ca, Joerg.Kienzle@mcgill.ca ABSTRACT Aspect-orientation adds a new dimension to encapsulation, allowing a modeler to group model elements related to the structure and/or behavior of a given concern together. As a result, information hiding becomes tricky. We propose that in addition to a public interface that exposes the state and behavior that the aspect is designed to provide to the outside world, model elements within an aspect need to define an intra-aspect interface that exposes state and behavior to the model elements within the same aspect. In addition, in order to support aspect hierarchies, an aspect weaver should automatically remove the public interface of an aspect during the weaving process by moving the operations from the public interface to the intra-aspect interface. As a result, aspects give the developer the power to hide design decisions, even those that require the interaction of instances of multiple classes. 1. INTRODUCTION Encapsulation or modularization allow an application developer to physically group together a set of related structural elements and behavior definitions within a module. For instance, in object-orientation, the class construct encapsulates state and behavior. In UML [6], a standard visual object-oriented modeling language, the state of a class is depicted using attributes, and behavior is defined by operations. The encapsulation or grouping of state and behavior is shown visually by placing the attributes and operations in a rectangular box. The same idea is used in object-oriented programming, where the attributes of a class are usually called fields, and where the operations are called methods. Good object-oriented design favors to strive for high cohesion when designing classes, i.e., a class should encapsulate all state that is related together with the all operations that can be used to modify the state of an object in a semantically meaningful way. UML also defines the package construct which can be used to group model elements and provide a namespace for them. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 200X ACM X-XXXXX-XX-X/XX/XX...$10.00. Again, the grouping is shown visually by drawing a rectangular box around all model elements that are within the package. Similar constructs are provided by object-oriented programming languages. Information hiding [8] is the activity of consciously deciding what parts of a software module should be exposed to the outside, i.e. the rest of the application, and what parts should be hidden from external use. To allow a developer to state what is internal and what is external to a module, modeling or programming languages typically provide constructs to define a module s interface. The interface exposes state and behavior that is visible to the outside; everything else remains hidden inside the module. Defining interfaces for classes is well understood; UML introduces visibility/access modifiers such as public, protected and private to do so. Information hiding, if employed well, gives the developer the ability to hide the internal workings of a software module behind a well defined interface. As a result, any one who wishes to interact with this component only needs to know what the module does and is not dependent on the details of how it does it. This is a critical property, because it allows a developer to modify the internal state and behavior of the module, for example improve an algorithm or use a different data structure, without affecting how the outside world interacts with the module. A developer can even go to the extent of replacing the module with a completely different one that supports the same public interface. Finally, if information hiding is used to hide the state of a module entirely, then the only way to modify the state of the module is to invoke the operations provided by the object s interface. If the operations are carefully designed to only perform semantically correct state updates, then it is impossible for the outside world to put the state of the module into an inconsistent state. Aspect-oriented modeling adds a new dimension to modularization. Aspect models encapsulate or group model elements related to the structure and/or behavior of a particular concern. The crosscutting nature of the concern dictates that the different model elements within an aspect need to interact closely with each other. To this aim, interfaces between the model elements need to be defined. Later, a model weaver combines multiple source aspect models (or source aspects and a base model) to form a woven model. This woven model includes the model elements of the concerns of all the source models. The model elements of the different source aspects (and the base) may also need to interact, but good aspect-oriented design strives for loose coupling between aspects (and between the base). This prompts a

need to define interfaces for aspects and as a result, for the same reasons as mentioned above for objects, effective use of information hiding is essential in the aspect-oriented world. This paper investigates the issues around interfaces and information hiding in aspect-oriented models as follows. Section 2 presents the need for two kinds of interfaces in aspectoriented models. Section 3 highlights the problems that arise with aspect interfaces in the context of weaving of aspect hierarchies. Section 4 presents a possible solution to this problem in our Reusable Aspect Models approach. Section 5 mentions related work, and the last section draws some conclusions. 2. INTERFACES FOR ASPECTS An aspect model typically encapsulates all model elements related to the structure and/or behavior of a concern. Aspectoriented modeling approaches such as Theme/UML[1] or our own Reusable Aspect Models (RAM) approach [4, 3] support aspect models that use different modeling notations to represent the aspect s state and behavior. Figure 1 presents an example RAM aspect model that shows the design of a concern that occurs very frequently in applications: an object needs to be associated with many other objects. While in UML this situation can be shown with a standard association that has the multiplicity 0..*, it is usually implemented during the detailed design phase using an intermediate set, list or array object. The class diagram representing the structure of this detailed design is presented in the compartment of Figure 1. It defines three classes:, Associated and the template class Set. The Set class implements a set abstraction: it provides a constructor and destructor, as well as operations to insert elements into and remove elements from the set. It is parametrized with the Associated class, thus creating a Set of Associated. Many object-oriented programming language libraries provide such classes, e.g. the generic Set class in Java, or the set class in the C++ standard template library. To provide the functionality related to a concern, the model elements within an aspect model must collaborate at run-time. In RAM, collaboration between objects is shown using sequence diagrams. The message view initializeassociation, shown in the second compartment of the aspect in Figure 1, shows that whenever a constructor is invoked on an object of the class (see pointcut sequence diagram), then the constructor also creates an instance of the class Set and stores a reference to it in myset (see advice sequence diagram). The message view add describes that adding an object of the class Associated is done by inserting a reference to it into the set referenced by myset. The message views for remove and cleanup are omitted for space reasons. RAM also allows the modeler to show how the state of an object dictates the messages it accepts in state views. The state views have also been omitted for space reasons. The interested reader is referred to [3] for a complete overview of RAM. In order to use the ZeroToManyAssociation aspect in a target model, it has to be instantiated by mapping the mandatory instantiation parameters of the aspect to model elements in a target model. In our example, the mandatory instantiation parameters, shown as UML template parameters on the top right corner of the aspect package, are the classes and Associated. For instance, to associate a user with zero to many bank accounts, a modeler would write the following instantiation: User, Associated BankAccount. At run-time, an account a can now be associated with a user u by calling u.add(a). As we can see from the simple example above, the operations defined by a class within an aspect can be called: 1. by instances of the same class (or of a subclass), 2. by instances of a different class defined in the same aspect (for example, the instance calls insert on the object myset), or 3. by instances of a different class defined in another model (for example, the User instance calling add). For 1., the interaction stays within the encapsulation provided by the class. For 2., the interaction crosses the class boundary, but stays within the encapsulation provided by the aspect. Finally for 3., the interaction crosses the boundaries provided by the aspect. In order to allow a modeler to use information hiding appropriately, we therefore need to be able to describe two kinds of interfaces for classes: an interface for model elements within the same aspect from now on called an intra-aspect interface and an interface for model elements outside of the aspect from now on called the public interface. Given these interfaces, the modeler has complete control over who is allowed to access what. UML introduces four access/visibility modifiers that allow the modeler to tag properties of a classifier with: public, private, protected and package. Elements with public visibility are visible to all elements that can access the contents of the namespace that owns it. A class, for instance, defines a namespace, and hence public attributes of a class can be accessed by any element that can access the class. Elements with private visibility are only visible inside the namespace that owns it. Elements with protected visibility are visible to elements that have a generalization relationship to the namespace that owns it. For instance, attributes of a class that are tagged as protected are only visible to subclasses. Elements with package visibility are visible to elements that are in the same package as its owning namespace. For example, an attribute of a class tagged with the package modifier is accessible to all other elements within the package that contains the class [6]. In order to define the public interface of an aspect, it is sufficient to use the public visibility modifier provided by UML to tag all the operations of classes inside the aspect that should be accessible from the outside. The public interface of the aspect is therefore comprised of the collection of all public operations of the classes it contains. To define the intra-aspect interface of the classes within an aspect, we can use the package visibility modifier provided that the UML package construct is used to encapsulate all model elements of an aspect. In this case, the namespace created by the package encompasses all model elements in the aspect, and therefore any property of a class tagged with package is visible to all other model elements within the aspect. Finally, just like it is practiced in standard object-oriented design, the private or protected modifiers can be used to to hide attributes and operations within a class or class hierarchy, respectively.

aspect ZeroToManyAssociation + add( Associated a) + remove( Associated a) + Set< Associated> getassociated() 1 myset Associated Set ~ create() ~ insert( Associated ) ~ remove( Associated) ~ delete() 0..* Associated Associated message view initializeassociation new := create(..) new: caller * Caller * new * new := create(..) new: myset := create() myset: Set< Associated> message view add add( Associated a) target: caller * Caller * target * add( Associated a) target: insert(a) myset: Set< Associated> message view remove and cleanup and state views and Set not shown for space reasons Figure 1: The ZeroToManyAssociation Aspect 3. INFORMATION HIDING AND ASPECT HIERARCHIES Models of complex applications tend to grow in size to the point where the diagrams become difficult to understand. Aspect-oriented modeling can help reduce the size of individual models by modularizing model elements that relate to a concern. But this approach in itself does not help if the design of a concern is complex. What is needed is the support for aspect hierarchies. Aspect hierarchies allow us to split the model into pieces of manageable size by allowing aspects that provide complex or high-level functionality to be able to reuse simpler or lower-level functionality provided by other aspects. In addition to making reuse possible, hierarchies also allow the developer to modularize crosscutting at different levels of abstraction; at a high level of abstraction, a complex application can be split into multiple high-level aspects. Crosscutting concerns within the internal designs of the higher-level aspects can be modularized in lower-level aspects. In theory, aspect hierarchies can be very deep but in our experience they rarely exceed 5 levels. A crisis management system (CMS), i.e. a system that helps identifying, assessing, and handling a crisis situation, is a real-world example of a large and complex software. One of the tasks of a CMS is to allocate and manages resources, i.e. humans, vehicles and other goods involved in handling the crisis. As mentioned above, the philosophy behind aspect hierarchies is to decompose aspects that provide high-level functionality into aspects that provide lower-level functionality. At a high level of abstraction, the resource management functionality of the CMS can be split into several high-level aspects, e.g. resource search and resource allocation. The high-level aspects depend on lower-level aspects, such as for example the simple low-level aspect Allocatable shown in Figure 2. aspect Allocatable Allocatable - bool allocated + bool isallocated() + allocate() + deallocate() state view Allocatable not shown for space reasons Allocatable Figure 2: The Allocatable Aspect Notice how Allocatable provides the functionality of being able to tag an Allocatable object as being allocated by calling allocate, free it again by calling deallocate, and query its state using isallocated. The Allocatable aspect is really simple, in the sense that it contains only one class Allocatable. The three public operations of Allocatable form the interface of the aspect. None of the public operations of Allocatable involve object interactions, and therefore this aspect does not contain any message views, nor do its classes need to worry about declaring an intraaspect interface. ResourceAllocation, shown in Figure 3, is an example of a higher-level aspect that depends on the low-level functionality of both Allocatable and ZeroToManyAssociation. ResourceAllocation is in charge of allocating resources to a task, and tagging the resources as being allocated. To this aim, ResourceAllocation defines the two classes and. provides the public operations allocateresources and deallocateresources. The instantiation directive that maps to and Associated to reuses the functionality provided by ZeroToManyAssociation to configure each object with a set of s. ResourceAllocation also reuses Allocatable to be able to mark a resource as being allocated.

aspect ResourceAllocation depends on Allocatable, ZeroToManyAssociation + allocateresources(set<> r) + Set<> getresources() + ZeroToManyAssocation instantiation Associated Allocatable instantiation Allocatable message view allocateresources instantiates add, allocate target: allocateresources(set<> r) target: allocateresources(set<> r) caller * Caller * target * allocate() add(res) res: message view deallocateresources instantiates getassociated, remove target: target: r := getassociated() caller * Caller * target * res: deallocate() remove(res) message view getresources is ZeroToManyAssociation.getAssociated state view not shown for space reasons Figure 3: The ResourceAllocation Aspect The allocateresources message view shows how behavior of lower-level aspects is reused. The sequence diagrams describe that when requested to allocate a set of resources to a task, the task object loops through the set of resources, calling allocate (provided by Allocatable) for each of them and subsequently adding it (provided by ZeroToManyAssociation) to the set of resources associated with the task. When creating a target model, the aspect weaver merges the structure view of the involved aspects according to the instantiation directives, and weaves the message views of the low-level instantiated aspect into the advice of the higherlevel aspect s message view. If no special treatment is applied to the visibility modifiers, then the resulting structural view of ResourceAllocation looks like what is shown in Figure 4.. The aspect interface of the resulting aspect contains 9 () public operations. The public operations of the lower-level aspects were simply copied into the woven model. As a result, model elements in higher-level aspect models that instantiate the ResourceAllocation aspect can directly use the functionality provided by Allocatable and ZeroToManyAssociation, thus violating the information hiding principles. The design decision of how to implement allocation is exposed to the outside world. This is not only bad practice, it can even lead to inconsistencies. To properly allocate resources, higher-level aspects should use the behavior described in the message view allocateresources: it makes sure that every resource that is added to the set of resources belonging to a task is also tagged as allocated. Incorrect behavior would be to tag a resource as allocated, but to not actually add it to a task, or, conversely, add a resource to a task, but to not tag it as allocated. This is exactly what can happen if aspects above ResourceAllocation are allowed to execute the functionality provided by Allocatable or ZeroToManyAssociation directly. 4. AUTOMATIC INFORMATION HIDING DURING WEAVING In order to make information hiding possible in aspect hierarchies, we propose that an aspect weaver should automatically remove the public interface of the model elements of an aspect when it is woven into a target model by changing the visibility of the model elements from public to package. This effectively moves the operations from the public interface of the aspect to the intra-aspect interface. The weaver in our Reusable Aspect Models approach supports aspect hierarchies of arbitrary depth. Given an aspect A that depends on lower-level aspects B and C, we must first create an independent model of A before A can be woven into a base application model or be reused in a higher-level aspect. The independent model of A is an aspect model that contains all the structural entities, states and message exchanges defined in the aspects A depends on, i.e., in B and C. Since B and C can themselves can depend on other aspects, our weaving algorithm is recursive in nature, processing the dependency graph in depth-first order. Weaving is always performed in pairs. For example, in order to create an independent aspect model of ResourceAllocation (Figure 3) that depends on Allocatable (Figure 2) and ZeroToManyAssociation (Figure 1), we first weave the aspect Allocatable into ResourceAllocation in order to get a model of ResourceAllocation that is independent of Allocat-

aspect ResourceAllocation + allocateresources(set<> r) + Set<> getresources() + + add( Associated a) + remove( Associated a) + Set< Associated> getassociated() 1 myset Set ~ create() ~ insert( Associated ) ~ remove( Associated) ~ delete() 0..* - bool allocated + bool isallocated() + allocate() + deallocate() message views and state views not shown for space reasons Figure 4: The Woven ResourceAllocation Aspect able. Second, that model is woven with ZeroToManyAssociation to finally get a model of ResourceAllocation that is independent of both Allocatable and ZeroToManyAssociation. We have modified the class diagram weaving algorithm that our weaver uses to implement our proposed solution, i.e. to automatically change the visibility of every public method of lower-level aspects to package during weaving. Figure 5 shows how ResourceAllocation looks like after weaving and having automatically treated the visibility modifiers. The aspect interface of the resulting aspect contains 3 public operations. The public operations of the lower-level aspects had their visibility changed from public to package as they were copied into the woven model. As a result, model elements in higher-level aspects that instantiate ResourceAllocation can no longer directly use the functionality provided by Allocatable and ZeroToManyAssociation. This implies that we have effectively maintained the information hiding principles and prevented exposure of internal design decisions of ResourceAllocation. Some times, however, a modeler may want to re-expose lower-level operations at the higher level. This situation occurs when an operation of the lower-level aspect directly implements a functionality that the higher-level aspect needs to provide. In the ResourceAllocation aspect, for example, it should be possible to query all the resources that are allocated to a task. This functionality is already provided by the operation getassociated in ZeroToManyAssociation. In RAM, the modeler can explicitly re-expose lower-level operations by first declaring the re-exposed operation in the appropriate class. The same operation name can be chosen, but a different name can also be used if it better reflects the semantics of the operation in the context of the highlevel aspect. Second, the message view of the operation in the high-level aspect just refers to the message view in the lower-level aspect. Concretely, if a modeler wishes to reexpose getassociated in ResourceAllocation, he can add a public operation getresources in the class and specify that the message view getresources is ZeroToManyAssociation.getAssociated. This tells the weaver to rename the getassociated operation during the weaving process and to not change its visibility modifier. 5. RELATED WORK Clarke and Baniassad [1] define an approach called Theme /UML. It introduces a theme module that can be used to represent a concern at the modeling level. Themes are declaratively complete units of modularization, in which any of the diagrams available in the UML can be used to model one view of the structure and behavior the concern requires to execute. In Theme/UML class diagrams and sequence diagrams are typically used to describe the structure and behavior of the concern being modeled. Just like in our approach, the binding to a base model is done by template parameter instantiation. In contrast to our approach, Theme/UML does not support model weaving, and therefore does not need to worry about performing automatic information hiding during weaving. Loughran Rashid [5] propose framed aspects, an approach that uses AOP to modularize crosscutting and tangled concerns and frame technology to allow aspect parametrization, configuration, and customization. In framed aspects, identification of aspect features is performed following the highlevel feature interaction approach promoted by FODA [2]. Once this is done, the features are modularized within framed aspects. Framed aspects are made up of three distinct modules: the framed aspect code (normal and parametrized aspect code), composition rules (aspect dependencies, acceptable and incompatible aspect configurations), and specifications (user-specific customization). These modules are composed to generate customized aspect code using a frame processor. The RAM approach performs weaving at the modeling level, whereas framed aspects work at the programming language level. Although it is not explicitly mentioned, we believe that their code generator does not address the information hiding issues mentioned in this paper. 6. CONCLUSION Aspect-orientation adds a new dimension to encapsulation, allowing a modeler to group model elements related to the structure and/or behavior of a given concern together. In this paper we show by example that as a result, information hiding principles found in object-orientation hiding the implementation of an object behind an interface have to be adapted. Just like an object, an aspect needs a public interface that exposes the state and behavior that the aspect is designed to provide to the outside world. However, since the crosscutting nature of the concern modularized in an aspect dictates that the different model elements within an aspect model must be able to interact closely with each other, the model elements within an aspect also need to define an intra-aspect interface. In an aspect-oriented modeling approach that supports aspect hierarchies, high-level aspects can reuse state and behavior provided by low-level aspects. We suggest that an

aspect ResourceAllocation + allocateresources(set<> r) + Set<> getresources() + ~ add( Associated a) ~ remove( Associated a) 1 myset Set ~ create() ~ insert( Associated ) ~ remove( Associated) ~ delete() 0..* - bool allocated ~ bool isallocated() ~ allocate() ~ deallocate() message view allocateresources target: allocateresources(set<> r) target: allocateresources(set<> r) allocate() res: caller * Caller * target * add(res) insert(res) myset: Set<> message view deallocateresources target: caller * Caller * target * target: r := getassociated() deallocate() res: remove(res) myset: Set<> remove(res) Figure 5: The Woven ResourceAllocation Aspect With Automatic Hiding aspect weaver should automatically remove the public interface of the model elements of the lower-level aspect during the weaving by changing the visibility of the operations from public to package, i.e., move the operations from the public interface to the intra-aspect interface. In that way, the resulting independent aspect model hides the fact that it reuses lower-level aspects. With public and intra-aspect interfaces and automatic information hiding during weaving, aspects give the developer the power to do proper information hiding according to the ideas of Parnas. In the conclusion of paper [7], in which Parnas talks about the criteria to be used in decomposing systems into modules, he writes: We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. In objectorientation where the class is the unit of encapsulation, only design decisions that do not require interaction between instances of different classes can be hidden. With aspect interfaces, it is possible to hide decisions about the design of a concern involving multiple collaborating classes. 7. REFERENCES [1] S. Clarke and E. Baniassad. Aspect-Oriented Analysis and Design: The Theme Approach. Addison Wesley, 2005. [2] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, November 1990. [3] J. Kienzle, W. AlAbed, and J. Klein. Aspect-oriented multi-view modeling. In ACM, editor, AOSD 09, pages 87 98, Charlotteville, Virginia, USA, March 2009. [4] J. Klein and J. Kienzle. Reusable Aspect Models. In 11th Aspect-Oriented Modeling Workshop, September 2007. [5] N. Loughran and A. Rashid. Framed Aspects: Supporting Variability and Configurability for AOP. In International Conference on Software Reuse (ICSR-8), pages 127 140. Springer, 2004. [6] OMG. Uml infrastructure and superstructure, v2.2. [7] D. L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of the Association of Computing Machinery, 15(12):1053 1058, Dec. 1972. [8] D. L. Parnas. A technique for software module specification with examples. Communications of the Association of Computing Machinery, 15(5):330 336, May 1972.