Deriving design aspects from canonical models

Transcription

1 Deriving design aspects from canonical models Bedir Tekinerdogan & Mehmet Aksit University of Twente Department of Computer Science P.O. Box AE Enschede, The Netherlands {bedir Abstract: Two fundamental issues in aspect orientation are the identification and the composition of aspects. We argue that aspects must be identified at the requirement and the domain analysis phases. We also propose a mechanism for gradually composing aspects throughout the software development process. We illustrate our ideas by using an example transaction system. keywords: aspect oriented design, aspect oriented programming, component composition 1. Introduction Software components can be defined as programming language abstractions. Examples of software components are procedures, data structures and objects. Programming languages are vehicles to express abstract executable mechanisms. Components can be identified by the use of heuristic rules in conventional methods. For example in OMT [Rumbaugh 91] tentative classes are identified by looking for nouns in a problem statement. The identified components are composed by means of the object-oriented composition mechanisms, such as inheritance, aggregation and association. Object-oriented methods define a number of heuristic rules to identify relations among components. In [Kiczales et al. 97], aspects are defined as properties that affect the performance or semantics of the components in systemic ways. Systemic characteristic of aspects implies that they can be considered as concepts. The term performance is a special case of the general term quality. Other quality examples are adaptability and reusability. From this point of view, aspects are concepts, which affect the quality and/or semantics of software components [Aksit & Tekinerdogan 98]. An aspect language is a language whose abstractions can directly represent one or more aspects. A trivial aspect is an aspect, which can be directly represented by a software component. This means that an aspect can show up as a software component (or can become trivial) if a suitable programming language can be designed for that aspect. Similar to object-oriented design, in aspect-oriented design, two issues appear to be important: identification of the abstraction models, that is, aspects and the composition of these aspects, or aspect weaving [Kiczales 97]. We will focus on these two issues in this paper. Regarding the aspect identification we argue that like objects, aspects should be identified during the requirement and the domain analysis phases. We will also discuss an approach in which aspects are gradually composed along the software development process. The outline of this paper is as follows: In the next section for illustration purposes we will give an example of a pilot project on atomic transaction systems for a car dealer management system. This example will be used throughout the paper. Section 3 will elaborate on our approach for aspect identification and aspect composition. Section 4 will give our conclusions. 2. Example: Systems for a Car Dealer System In order to illustrate our ideas we will shortly describe a pilot project which aims at designing an object-oriented atomic transaction framework to be used in a distributed car dealer management system 1. Data and processing in 1 This project is carried out together with Siemens-Nixdorf Software Center and supported by The Dutch Ministry of Economical Affairs under the SENTER program. 1

2 a car dealer management system are largely distributed and therefore serializability and recoverability of executions are required. Using atomic transactions [Bernstein 87], serializability and recoverability for a group of statements can be ensured. Serializability means that the concurrent execution of a group of transactions is equivalent to some serial execution of the same set of transactions. Recoverability means that each execution either completes successfully, or has no effect on data shared with other transactions. A car dealer management system is a data-intensive system that involves several applications with varying characteristics, operates in heterogeneous environments, and may incorporate different data formats. To achieve optimal behavior, each of these aspects may require transactions with dedicated serialization and recovery techniques. This requires transactions with dynamic adaptation of transaction behavior, optimized with respect to the application and environmental conditions, and data formats. The adaptation policy, therefore, must be determined by the programmers, the operating system or the data objects. Further, reusability of the software is considered as an important requirement to reduce development and maintenance costs. 3. Aspect abstraction and aspect composition Software development can be seen as a problem solving process in which the requirements represent the problem for which a programming solution is required. A software development process involves a number of steps, which produce various kinds of software artifacts. These steps can be considered as transitions between artifacts. No doubt, the early phases of the software development process includes concerns, which have a major impact on the final structure and quality of the software [Aksit 97]. We therefore, believe that aspects appear beyond the programming level and as such the identification of aspects should start at the levels of requirements engineering. Here the fundamental question is, given a problem domain like the transaction system, how should we abstract and identify the aspects? To address this issue, we propose the method described in Figure 1, which defines the basic steps needed to identify aspects in the earlier phases of the software development process. This method will be described in more detail in subsequent sections. CLIENT S WISH PROBLEM DOMAIN ASPECT- ORIENTED DESIGN 1. Requirements Analysis 2. Domain Analysis 6. Identify Rules for Aspect composition 3a. Conceptual Modeling 5. Aspect Composition Specification 3b. Aspect abstraction 4. Define design space Figure 1. The aspect modeling method 3.1 Requirements Analysis The first step in software development is the requirements analysis phase. The goal of the requirements analysis phase is to understand and capture the exact needs of the clients of a software system [Wieringa 96]. Requirements analysis deals with eliciting, analyzing and capturing the requirements of the client for which the software system is developed. systems From the requirements analysis of the distributed car dealer system [Tekinerdogan 96] it followed that because of the heterogeneity of the car dealer system adaptability was an important quality aspect. In addition, it was required that the transaction system should have an acceptable performance. We could extract four basic groups of aspects from the requirements analysis phase: Aspects related to the transaction models, aspects related to quality factors such as adaptability and performance and aspects related to the object model. 3.2 Domain Analysis Domain analysis aims at systematically identifying, formalizing and classifying the knowledge in problem domain in a reusable way. The basic steps of domain analysis are the identification of the knowledge sources, the data collection from the knowledge sources, data analysis of the extracted knowledge and knowledge modeling. Domain models are mainly derived by considering commonalities and variations between the 2

3 retrieved data. The basic difference between requirements analysis and domain analysis is that requirements analysis focuses on the requirements of one application whereas domain analysis attempts to model the knowledge of a wide range of related applications. The deliverables of domain analysis are a set of domain models, relations and rules that are common in a problem domain for the corresponding applications. Domain models can be represented in many ways, e.g. ER diagrams, object-oriented class diagrams, or just ordered text. In [Aksit et. al. 98] we applied domain analysis techniques to support the development of stable frameworks. 3.3 Conceptual modeling Requirements analysis extracts the potential aspects. Domain analysis collects knowledge about these aspects. The conceptual modeling process elaborates on the domain model to define canonical models. Canonical models are similar to concepts of the classical view [Smith & Medin 81]. Concepts are not chosen arbitrarily but are formed by abstracting the knowledge about instances. An identified concept is useful if it has meaningful differences with the existing concepts. The meaningfulness on its turn is defined by the context. In the following section we will illustrate the process of forming conceptual models for the example transaction system Conceptual Models for Adaptable System Domain Model A considerable number of textbooks and articles have been written on atomic transactions [Bernstein 87] [Elmagarmid 92]. After analyzing and comparing the literature, we noticed that most publications adopt a similar structure. This helped us to define the conceptual model of transaction systems, which is shown by Figure 2. The node represents a transaction block as defined by the programmer. The node Manager provides mechanisms for initiating, starting and terminating the transaction. It maintains the data objects that are affected by the transaction. If a transaction reaches its final state successfully, then the node Manager sends a commit message to the corresponding data objects to terminate the transaction. Otherwise, an abort message is sent to all the data objects to undo the effects of the transaction. PolicyManager adapts adapts manages Manager DataManager controls DataObject coordinates Scheduler coordinates RecoveryManager Figure 2. Conceptual model for transaction systems The node PolicyManager determines the strategy for optimizing the transaction behavior. In most publications, PolicyManager is included in Manager. We considered, however, transaction policies as a different concern, and therefore defined it as a separate node. The node DataManager controls the access to its DataObject, and includes the nodes Scheduler and RecoveryManager. The node Scheduler orders the incoming messages to achieve serializability. Scheduler may include deadlock avoidance and/or detection mechanisms. The node RecoveryManager keeps track of changes to the data object to recover from failures. A succinct representation of the conceptual model for transaction systems is as follows: = (TM, PM, DM, SC, RM) Hereby, the subconcepts TM, PM, DM, SC and RM represent Manager, PolicyManager, DataManager, Scheduler, and RecoveryManager respectively. Domain Coupling Aspect Potentially, all the domain elements may be coupled together. This coupling has also a great impact on the structure and the quality of the final software system. As such we consider the domain coupling also as an aspect. The coupling aspect can be defined as the Cartesian product of the domain elements: Domain Coupling = x 3

4 Adaptability As it was also stated in the adaptability workshop [Adaptability 96], we define adaptability as follows: Adaptability = (FX, AD) where FX represents the fixed concerns, and AD represents the adaptable concerns. Performance The performance of an implementation can be improved by using the following 3 criteria: implementing the efficient alternative, by run-time dispatching or by prioritization. In case most efficient alternative is selected, then all the aspects of the transaction system must be fixed and in lined. This will of course reduce the adaptability of the transaction system. In the criterion run-time dispatching, the performance affecting alternatives must be made adaptable, and a decision-maker must select the most efficient one. The prioritization approach requires a real-time language and operating system to control the executions based on priorities. Obviously, many of the alternatives conflict with each other. During the mapping process, the most appropriate alternatives must be selected based on the requirements and the design context. The performance model can now be defined as: Performance = (EA, DD, EP) Where the elements EA, DD and EP represent efficient alternative, dynamic dispatch and explicit prioritization respectively. Object Model The object model is defined as: ObjectModel = (CL, OP, AT) Hereby, the elements CL, OP and AT represent the concepts class, operation and attribute respectively. We define the object coupling aspects as follows: Object Coupling = (IN, AS, AG) where the elements IN, AS, and AG represent inheritance, association and aggregation respectively. 3.4 Define design space Jacobson defines information space as a space where information can be expressed [Jacobson 1992]. One may define models within an information space by using the concepts relevant to this information space. Objectoriented analysis and design methods and patterns are the instruments to define various kinds of models suitable for different stages of software development. The more powerful the instruments are, the larger the information space that software engineers can express. Our concept of design space is similar to the concept of information space. In our method the information space is defined as a Cartesian product of the identified aspects in the aspect identification process in step 3. Each of these aspects is derived from the concepts, which represent the abstraction of a wide range of domain instances. As such, the Cartesian product of these concepts represents the total design space. In [Aksit & Tekinerdogan 1998] we elaborate on the concept of design space and more specific on the concept of design algebra. For the adaptable transaction domain the design space is as follows: Design Space = ( x ) x ObjectModel x Object Coupling x Adaptability x Performance) = (TM, PM, SC, DM, RM) (TM, PM, SC, DM, RM) (CL, OP, AT) (IN, AS, AG) (FX, AD) (EA, DD, EP) The design space for the transaction problem domain has 6 dimensions, consisting of 5x5x3x3x2x3 = 1350 elements. Each element in this design space represents a design solution for the given problem domain. 4

5 3.5 Aspect composition specification Basically there are two ways for aspect composition. Composition at-once or gradual composition. In the composition at-once approach which is shown in Figure 3, one aspect composer composes all the identified aspects into to the final realization model. Model Adaptability Performance Aspect Realization Model Object Model Figure 3. Composition at-once of aspects The problem with this approach is that the aspect composer needs to deal with all the aspects at once which may be a difficult, error-prone and time-consuming process. In addition, not all the combinations of the design space may be possible or useful. It is therefore, not necessary to elaborate on all the elements of the design space. Accordingly, we need some mechanisms to restrict this large design space and exploit only the useful combinations. In order to meet this requirement we will gradually explore the useful combinations in this design space. Figure 4 shows this process of gradually refining the domain model with the appropriate aspects until the realization model is acquired. DM 1 DM 2 DM n select X S 1 X S 2 X RM CM 1 CM 2 CM m Figure 4. Gradual composition of aspects In Figure 4 we start with a Domain Model (DM) and define a design space by taking the Cartesian product with a Cross Model (CM). A cross-model may be a domain model, a quality model or a component model. From the resulted space a new model is selected which includes the useful and desired combinations. The selection is based on some design rules. This process is iterated until we have included all the aspects and domain models. The final result of this process is a realization model (RM). The realization model includes all the elements, which define the final implementation for the design problem. Figure 4 implies that we have several specific aspect composers during the software development process. The basic issue here is how to order the gradual aspect composition. Since we have 6 aspects we can apply the gradual aspect composition in 6!= 720 ways. This is a difficult task. We therefore apply some general rules to manage this situation. The most intuitive ordering is to start with the domain models and end with the component models. A possible ordering of aspect composition for the given example problem is as follows: (((((( x Adaptability) x Performance) x Object Model) x Coupling) x Object Relations) Figure 5 shows the ordering of the aspect composition process for this ordering. In this figure we see that for obtaining the final realization 6 specific aspect composers are used. Each aspect composer composes two aspects into one model. For example Adaptable composes transaction model M Trans and adaptability model M Adapt into a adaptable transaction model called M AdaptTrans. M AdaptTrans is further composed with the Performance model by the AdaptablePerformance. 5

6 M Trans Adaptable M Adapt M AdaptTrans M Perform Adaptable Performance Aspect M AdaptPerformTrans M Object Object Aspect or Component Legend M ObjectAdapt PerformTrans M ObjectAdapt PerformTrans DomainCoupling M CouplingObject AdaptPerformTrans M ObjectRel ObjectCoupling M RelatedCouplingObject AdaptPerformTrans ObjectRealization RealizationModel Figure 5. Gradual composition of aspects in transaction domain 3.6 Define aspect composition rules After we have determined the ordering of the aspect composers we must define the rules which will be applied in each specific aspect composer. In [Aksit & Tekinerdogan 98] we have described this process in more detail. For illustration purposes we only explain Adaptable of Figure 5. This aspect composer first takes the Cartesian product of with Adaptability: AdaptableSpace = x Adaptability = (TM PM DM SC RM) X (AD FX) = ( (TM, AD) (TM, FX) (PM, AD) (PM, FX) (DM, AD) (DM, FX) (SC, AD) (SC, FX) (RC, AD) (RC, FX) ) This defines the space of the adaptable transaction domain, whereby the elements of the product represent all the possible concepts of an adaptable transaction domain. We are not interested in all these combinations. The aspect composer Adaptable selects all the useful combinations from this design space and defines a new model called M Adapt. adapt: AS M Adapt This function can be implemented, by using a dialog interface. In the following dialog example, the software engineer is asked to determine whether the concept algorithm type should be made adaptable: DO YOU THINK THAT Manager SHOULD BE MADE ADAPTABLE? 6

7 In a similar way the adaptability type for the other transaction concepts range may be determined by such dialogs. Adaptable may for example come up with the following model. M Adapt = ((TM, AD), (PM, AD), (DM, AD), (SC, AD), (RM, FX)). This model will be further used/refined by the other aspect composers. The final aspect composer ObjectRealization will provide the implementation for the selected and woven aspects. 4. Conclusion In this paper we have proposed an approach for identification of proper aspects from the domain analysis and requirements analysis phases. The aspect composition can be done centrally by one composer or gradually by multiple composers along the software development process. We illustrated the practical applicability of gradually composing aspects. 5. References [Adaptability 96] M. Aksit, B. Tekinerdogan, L. Bergmans, K. Lieberherr, P. Steyaert, C. Lucas, & K. Mens, ECOOP 96 Adaptability in Object-Oriented Software Development Workshop, url: [Aksit 97] M. Aksit. Issues in Aspect-Oriented Programming, Position paper, AOP workshop, ECOOP 97. [Aksit & Tekinerdogan 98] M. Aksit & B. Tekinerdogan, Models for Composition of Design Aspects, University of Twente, Department of Computer Science, [Arrango 94] G. Arrango. Domain Analysis Methods. In Software Reusability, Schäfer, R. Prieto-Díaz, and M. Matsumoto (Eds.), Ellis Horwood, New York, New York, 1994, pp [Bernstein 87] P.A. Bernstein, V. Hadzilacos, & N. Goodman. Concurrency control and recovery in Database Systems. Addison-Wesley, [Elmagarmid 92] A. Elmagarmid (ed), Database Models for advanced applications, San Mateo, CA, Morgen Kaufmann, [Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson & G. Overgaard, Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley/ACM Press, [Kiczales et al. 97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J-M. Loingtier and J. Irwin, Aspect-Oriented Programming, ECOOP 97 Conference proceedings, LNCS 1241, June 1997, pp [Smith & Medin 81] E.E. Smith & D.L. Medin. Categories and Concepts, Harvard University Press, [Tekinerdogan 96] B. Tekinerdogan. Requirements analysis of transaction processing in a distributed car dealer system. Technical report. University of Twente, [Wieringa 96] R.J. Wieringa. Requirements Engineering: Frameworks for understanding, Wiley,