HANDLINGCROSSCUTTING CONSTRAINTSIN DOMAIN-SPECIFIC MODELINGCOMMUNICATIONS OF THE ACM October 2001/Vol. 44, No. 10 87AAn aspect-oriented approach can be beneficial at different stages ofthe software life cycle and at various levels of abstraction. Wheneverthe description of a software artifact exhibits crosscutting structure,the principles of modularity espoused by AOP offer a powerful tech-nology for supporting separation of concerns. We have found this tobe true especially in the area of domain-specific modeling [3].In domain-specific modeling, a design engineer describes a systemby constructing a model using the terminology and concepts from aspecific domain. Analysis can then be performed on the model, orthe model can be synthesized into an implementation. At the Insti-tute for Software Integrated Systems (ISIS) at Vanderbilt University(see www.isis.vanderbilt.edu/) we implement this approach using acore tool—the Generic Model Editor (GME). The GME is a Jeff Gray, Ted Bapty, Sandeep Neema,and James TuckUniting AOP with model-integrated computing.88 October 2001/Vol. 44, No. 10 COMMUNICATIONS OF THE ACMmodeling environment that can be configured andadapted from metalevel paradigm specifications [8].In using the GME, a modeler loads a domain,implemented with a metalevel paradigm, into thetool. This provides an environment containing all ofthe modeling elements and valid relationships thatcan be constructed in a model. This specificapproach to domain-specific modeling has been suc-cessfully applied in several different domains,including automotive manufacturing [7], digital sig-nal processing [11], and electrical utilities.In one particular domain-specific paradigm wecreated for reconfigurable systems, a modeler maydeploy constraints (we use a variant of the ObjectConstraint Language to specify system properties[12]) to capture application specific rules. In thesemodels, constraints are used to specify propertiessuch as bit precision, timing, and power concerns.Due to the large number of conflicting design crite-ria in reconfigurable systems, constraints aid in thereduction of the number of design states that mustbe examined. However, the utility of specifying con-straints within the model is often diminished due tothe scattering of constraints throughout the modelhierarchy. Consequently, constraints represent a typeof crosscutting concern.This article describes the difficulties caused bycrosscutting constraints and provides a descriptionof the AO techniques that are being used to amelio-rate the problem. Our goal is to encode importantissues about the system being modeled in a clean andlocalized manner. A key feature of this approach is itprovides a framework that uses software code gener-ators to create new domain-specific weavers.Constraints as Aspects“The crucial choice is, of course, what aspects to study ‘in isolation,’ how to disentangle the originalamorphous knot of obligations, constraints and goalsinto a set of ‘concerns’ that admit a reasonably effective separation.” [2]The same problems that result from tangledcode in programming languages [5] alsooccur in the tangled constraints of ourmodels [3]. Often, the same constraint isrepeatedly applied in many different places in amodel, usually with slight node-specific variations.It would be beneficial to describe a common con-straint in a modular manner and designate the placesand conditions where it is to be applied. Withrespect to code, a large amount of redundancy canFigure 1. Illustration of the difficulty in managing constraints.4AFBBcdecdecdeB3Context SensitiveConstraints21’ 2’1”2”13’3”ReplicatedStructures-Figure 2. A tangled resource constraint.constraint K2MULT_RESOURCE() { ((self.children("Forwarder").implementedBy() = self.children("Forwarder").children("forward")) implies ((self.children("K2_Multiplier").children("K2_Shift_Multiplier").assignedTo() = project().resources("Xilinx_FPGA_1")) and (self.children("K2_Multiplier").children("K2_Full_Multiply").children("K2_Multiplier").assignedTo() = project().resources("Xilinx_FPGA_1")) and (self.children("K2_Multiplier").children("K2_Full_Multiply").children("K2_Retrieval_00").assignedTo() = project().resources("Xilinx_FPGA_1")) )) and ((self.children("Forwarder").implementedBy() = self.children("Forwarder").children("resource_boundary")) implies ((self.children("K2_Multiplier").children("K2_Shift_Multiplier").assignedTo() = project().resources("Xilinx_FPGA_2")) and (self.children("K2_Multiplier").children("K2_Full_Multiply").children("K2_Multiplier").assignedTo() = project().resources("Xilinx_FPGA_2")) and (self.children("K2_Multiplier").children("K2_Full_Multiply").children("K2_Retrieval_00").assignedTo() = project().resources("Xilinx_FPGA_2")) ))}be removed using AO techniques[6]. We are finding the sameapplies to our models and constraints.There are several differentkinds of constraints a modeler canapply. Operational constraintsexpress relations between designspace alternatives and modes ofoperation of the system. Compos-ability constraints express com-patibility between differentalternatives. They can be used torestrict alternatives not compati-ble with each other. Resourceconstraints are used to indicatespecific hardware resourcesneeded by software modules. Per-formance constraints are widelyused in our models. These con-straint expressions indicate theend-to-end latency, throughput,power consumption, and bit pre-cision.As illustrated in Figure 1, threereplicated structures are acted onby context-sensitive constraints.The dominant form of decomposition shown in thisfigure is concentrated on the functional hierarchy ofthe system being modeled. Notice that each con-straint cuts across this hierarchy. The manner inwhich a constraint is applied also depends upon thecontext of the sub-model (for example, constraint“1” may be applied in different ways depending onthe context of each model element). However, if itwere essential to change the intention of these con-straints, it would be necessary to visit each oneuniquely and modify it for each context. The dependent nature of each constraint makes changemaintenance a daunting task for anything but a sim-ple model.An example of the complexity that can resultfrom a tangled constraint is evident in Figure 2. Thisresource constraint describes the effects of two dif-ferent design alternatives. Our former approach toconstraint specification,
View Full Document
Unlocking...