Towards Individualized Requirements ... - Semantic Scholar

Towards Individualized Requirements Specification Evolution for Networked Software Based on Aspect Zaiwen Feng, Keqing He, Yutao Ma, Jian Wang, and Ping Gong State Key Lab of Software Engineering, Wuhan University 430072 Wuhan City, Hubei Province, China [email protected]

Abstract. Networked software is a kind of Internet-based online complex software system produced through interaction and cooperation between networks and users who act as both consumer and producer of the system composed of web services. To meet a mass of individualized requirements, specifications for common requirements of the domain need to modify and evolve. Aiming at the concern, we propose a 3-step process of requirements evolution modeling of networked software. Focusing on the first step, the paper analyzes inducements for individualized requirements evolution, proposes a meta-model to describe the evolutionary requirements specification of networked software based on aspects, and presents a case study to demonstrate the usage of our approach. Finally a process for implementing the individualized requirements evolution is proposed. So it is helpful to guide the modeling for evolutionary requirements specifications and implement individualized requirements from common specifications. Keywords: requirements specification, evolution, OWL-S, aspect.

1 Introduction Before developing a software production, we should make sure what users want to do. The purpose of software requirements engineering is to define problems which the software will solve [4]. The final artifact of requirements engineering is software requirements specification that explicitly defines users’ requirements. The general process of software requirements engineering is composed of requirements eliciting, analyzing, modeling, checking and evolution. Requirements evolution concerns how to reflect user’s evolutionary requirements into primitive requirements specification. Software paradigm has changed with the born of Service-Oriented Architecture after 2000. For the new paradigm, software artifacts can be aggregated by software resources on Internet. Based on the background, we propose Networked Software (NS below) that is a complex system of which topology structure and activity can be evolutionary dynamically [1] [13]. To solve the problem of modeling for requirements of the NS, some researchers have been done on meta-model for requirements, language for acquiring requirements, requirements analysis of complex system, dynamic composition of requirements and methodology for modeling requirements evolution [4]. To describe the individualized and diversiform requirements for user of the NS, the Q. Wang, D. Pfahl, and D.M. Raffo (Eds.): ICSP 2008, LNCS 5007, pp. 88 – 99, 2008. © Springer-Verlag Berlin Heidelberg 2008

Towards Individualized Requirements Specification Evolution for NS Based on Aspect

89

meta-models of domain requirements modeling framework which support contextawareness named RGPS is proposed [5]. In addition, to capture the individualized and diversiform requirements in the mode of intercommunication between users and network which is specific for the NS, a service-oriented requirements language named SORL is proposed [12]. In the requirements engineering of NS, common domain requirements specifications are stored in domain knowledge repository. Under the support of RGPS, SORL and domain requirements specification, the individualized requirements of the user of the NS can be elicited dynamically, and matched by domain requirements specification which is represented in the form of domain process model described by OWL-S in domain knowledge repository finally. But sometimes the domain requirements specification stored in domain knowledge repository probably cannot fulfill the individualized requirements for the user of the NS completely. For example, the common domain requirements specification for arrange trip for traveler only provides the user three traffic patterns: by train, by air or by car. If someone plans to travel by ship, his requirements cannot be fulfilled by common domain requirements specification. In the scenario similar to the example, we should design a method to make the common domain requirements specification evolved to fulfill the user’s individualized requirements. To address this problem, we import aspect to support modeling for the evolutionary requirements, and design the corresponding process that implements the evolution of common domain requirements specifications. One of our contributions is proposing OWL-SA and its meta-model that can describes the evolutionary requirements, the other is designing the process supports individualized requirements evolution. The outline of the paper is arranged as follows: In Section 2, we introduce RGPS and the requirements evolution stages based on it. The catalogue of inducements for individualized requirements evolution is analyzed in Section 3. In Section 4 we propose the meta-model and corresponding definitions of OWL-SA. In Section 5 the process for implementing the individualized requirements evolution is proposed. In Section 6, related work is reported. Finally, in section7, we conclude the paper and outline our future work.

2 Requirements Evolution Modeling of NS 2.1 RGPS: Meta-models of Domain Modeling Framework for NS In traditional software engineering, requirements specification is the normal document which is used to describe the requirements for the user of the software. Several requirements modeling methodology have been proposed in traditional software requirements engineering, such as: Role-oriented requirements modeling methodology, as well as Goal-oriented, Process-oriented and Service-oriented requirements modeling methodology [14-16]. The requirements modeling methodologies and the corresponding established requirements specifications are different from one another. It is necessary to propose universal requirements modeling language and methodology to instruct somebody to edit requirements specification. After studying various requirements modeling methodology, meta-models which describe the requirements specification models from each viewpoints have been proposed. That is RGPS: meta-models of domain modeling framework for NS [4][5]. RGPS is composed of four meta-models:

90

Z. Feng et al.

z z

z

z

Role Meta-Model: describes the roles of the users of NS, actors and the contexts which actors are in, intercourse between different roles, and the business rules which intercourse must abide by. Goal Meta-Model: describes the requirements goals of the user, including functional and non-functional goal, which can be decomposed to operational goal further. An operational goal can be realized by business process. The decomposition of goal is not completed until the lowest goals are all operational goals. Process Meta-Model: describes the business process, including functional description such as IOPE (input, output, precondition and effect), and nonfunctional description such as Qos expectation and individualized business context expectation. A process can realize functional goal and promote the realization of non-functional goal. Service Meta-Model: describes the solution based on service resource, including functional and non-functional attributes. A service solution realizes the business process.

The domain expert defines a number of domain requirements specifications stored in domain knowledge repository in each lay of RGPS, which correspond to the requirements of different users group of the NS. In fact, it is the application of masscustomization. In Process layer, a great deal of domain requirements specifications represented as domain process model are defined. Requirements of the user are elicited, analyzed, which is finally matched to common domain requirements specifications described by process model. 2.2 Requirements Evolution Modeling Based on RGPS As described above, the domain requirements specification represented as domain process model is custom-made for a user group. But actually the user requirements is always individualized, which is not fulfilled by common solution. In traditional software engineering, the software capability may grow as the user of software claims more requirements. As a new software paradigm, NS can make the user feel that he is producing a software system himself through intercommunication between user and network. In fact, the important feather of NS is self-evolution capability. That is to say, NS can continually absorb new common user’s requirements from the network, extend or integrate the old domain requirements specifications to the greater ones, and form the universal domain requirements specification which can fulfill almost all the users of the domain finally. Generally speaking, the requirements evolution modeling based on RGPS is divided to the following three stages [4]: (1) Weaving the individualized requirements specification into the domain requirements specification, the requirements specification fulfilling the individualized requirements case is set up. (2) Aggregation. The requirements specification from different roles and different goals are aggregated to several classes. The specifications in each class are integrated. The universal domain requirements specification is set up. (3) Optimization. The universal domain requirements specification is optimized according to complex network environment and the current context. The corresponding content in stage one of requirements evolution modeling is proposed in the paper below.


91

3 Inducement for Individualized Requirements Evolution The inducement leading to the evolution of domain process model includes three points: (1) Additional functional requirements: Common domain process model cannot fulfill the individualized user’s functional requirements. For example, the domain process model: constructing does not comprise atomic process: supervising. If the user claims that the whole constructing process can be supervised by the third party, the process model should be evolved. (2)Additional business context requirements: one or some processes in process model are put different business context expectation. For example, there is a process model named plan the travel abroad which comprises an atomic process: arrange the travelling routine. Now the traveler hopes specially that the arranged travelling routine consumes no more than 7 days. Thus the process model needs evolving. (3) Additional non-functional requirements. For example, there is another atomic process named pay for the travel in the process model plan the travel abroad. The traveler hopes higher security in the process of paying for the travel. Thus the process model needs to be evolved.

4 Description Model for Evolutionary Requirements Specification If the common domain requirements specification is not enough to fulfill the user’s individualized requirements, the requirements specification is driven to evolve. The requirements specification is represented by process model in the process layer of RGPS framework, and process model is represented by the extension of OWL-S. But process meta-model has not enough capability to model the individualized evolutionary requirements specification because the OWL-S does not support modeling where the evolution happens, when the evolution happens and how the evolution happens. After studying some features of AOP, we defined OWL-SA based on OWL-S that has capability to describe the attributes of the evolutionary requirements specification. 4.1 Brief Introduction of OWL-S and Aspect-Oriented Programming OWL-S [2] is proposed by W3C which describes services. OWL-S makes the computer understand the semantics of services. It describes the service through a normal ontology based on OWL. Described by semantic markup language, services can be automatic discovered, invoked and composited. OWL-S release 1.1 defines three ontologies to describe services: service profile, service model and service grounding. Service profile gives the basic capability of service such as IOPE. Service model describes the constitution of service from the viewpoint of process flow. And service grounding describes how a concrete instance of service can be accessed. In traditional software development, scattered and tangled code always exists in many modules of the software. The scattered and tangled sections lead verbose software code and make it difficult to debug, modify and maintain the program. The goal of Aspect-Oriented Programming (AOP) is to solve this issue [7]. AOP insists on aggregating the scattered and tangled code to a whole modularity, named as aspect. An aspect comprises pointcut, join point, and advice. Join point is a well-defined

92

Z. Feng et al.

point in a program’s execution, Pointcut predicates on join points. It is a collection of selected join points. And advice is a piece of code that is executed whenever a join point in the set indentified by a pointcut is reached [8]. There are some AOP languages now such as: AspectJ, AspectC++, and AspectWerkz. 4.2 OWL-SA: Describing the Evolutionary Requirements In process layer of RGPS, the OWL-S is used to describe the domain process model. It is the proposal of the new individualized user’s requirements that drives the domain process model to evolve. Only the domain process model is tailored can the requirements evolution be realized. Aspect is a good solution to realize the customization of the process model. Several evolution points within one process or several evolution points within several processes can be described easily by aspect, as well as the evolutionary content that happens near evolution point. So it is convenient to add, modify or remove evolutionary elements from several evolution points of one or several process model with aspect and the evolution of process model is realized. Furthermore, the modularity of evolutionary element at the requirements stage will be brought to the design and implementation stages smoothly. Thus the runtime evolution of NS can be realized. Since aspect is introduced to realize the requirements evolution, first we need to describe how the evolution happens. Besides, we also need to describe the point where the evolution happens and what something of evolution is. In fact, it is necessary to set up a unified modeling language to describe the requirements evolution. OWL-SA is proposed to describe the evolutionary requirements. OWL-SA is based on OWL-S, ‘A’ of OWL-SA refers to aspect, and pointcut-advice model in AspectJ is exerted in it. In OWL-SA, an aspect describes an evolutionary requirements specification, which comprises one or several pointcut-advice pairs. One pointcut and one or several advices constitute a pointcut-advice pairs. In a requirements specification described by OWL-SA, pointcut describes the position where the evolution takes place. Advice describes the content of requirements evolution. Advice also has an attribute: evolutionOrder, which illuminates the order between the evolutionary requirements specification and evolutionary position. The meta-model of OWL-SA is presented in Fig.1.

Fig. 1. Meta-Model for OWL-SA


93

(1) Describing the position of evolution When we describe the evolutionary requirements specification, the position of evolution should be described firstly. Xpath [11] is always used to address a certain node in an XML document tree. Since domain process model is mainly described in OWL-S, which adopts XML syntax, it is appropriate to use Xpath to locate some certain position of OWL-SA. There are two types of pointcut in OWL-SA. One is the performance to the certain process in the process model. The inserting, substituting, or removing action takes place on or near the certain process when we perform the certain process in the process model, so the process model evolves. This type of pointcut is demonstrated as following: //process:CompositeProcess[@rdf:ID=”CP1”]//process:perform[@rdf:ID=”Step1”]

When we insert or substitute new process to the process model, the input or output parameter of the process model would be added or modified. So the other type of pointcut is the declaration of input or output parameter of the process model. The type of pointcut is demonstrated as following: //process:CompositeProcess[@rdf:ID=”CP1”]//process:hasInput[@rdf:ID=”I1”]

(2) Description of evolutionary content Advice describes the content of requirements evolution. The evolutionary content is either the performance of new process that is inserted or substituted near pointcut, or the added input (or output) parameter to the process model. The inserted or substituted new process may be either atomic process or composite process described by OWL-S. The inserted or substituted evolutionary process is usually invoked by a control construct Perform, in which there are some data binding relationships. Data binding of performance is composed of two sections. One is the input data binding represented by InputBinding, the other is the output data binding represented by ProducedBinding. InputBinding describes the data source of evolutionary process. ProducedBinding describes the destination of output data of evolutionary process. It is not always that the evolutionary process has data bindings with conjoint processes in the process model, which is due to the order type of the process model. There exist two types of order in process model: business logic order and data flow order. The business logic order is defined by business flow. There is not always data binding In this case. For example, the business flow prescribes that the process “send mobile phone message to somebody” takes place before “send Email to somebody”. There could be no data binding between the two processes. Another data flow order is defined by the order of data binding in process model, and there exist data bindings between the two nearby processes. For example, the process “select cargo” must precede the process “pay for the cargo” in the process model “e-business shopping”, since the output of “select cargo”, such as “cargo list”, is one of inputs of the process “pay for the cargo”. In summary, three patterns of the data binding exist between evolutionary process and other processes when the evolutionary process is imported into the process model. (1) Complete data binding. The new process receives all the outputs of preceding process as the inputs of its, and pushes all the outputs of its to the inputs of the succeeding process. (2)Complete non data binding. It is the business logic order between

94

Z. Feng et al.

the new process and other processes, no data binding exists. Thus the process model adds some inputs and outputs corresponding to the new process. The new process sets up data binding to the added inputs and outputs of process model. (3) Partial data binding. The new process receives output of preceding process as its partial input, and pushes its partial output to the succeeding process. At the same time, the process model adds some inputs and outputs corresponding to the rest of inputs and outputs of the new process. And the rest of inputs and outputs of the new process sets up data binding to the added inputs and outputs of process model. There is an issue arising if the evolutionary process has data binding to point process. A pointcut is probably composed of several join points which are represented corresponding performed processes. Thus the inserted new process probably has several data bindings to different join points of the pointcut. Here a variable is defined to solve the issue: ThePointcutPerformed, The variable is introduced as the extension to OWL-S, which represents the collection of processes that represent join points. A special-purpose variable, used to refer, at runtime, to the execution instances of the pointcut process definition. (3) Order between evolutionary content and evolutionary position

In a specification describing evolutionary requirements in OWL-SA, the pointcut describes the position where evolution takes place, and advice describes evolutionary content in the pointcut. The sequence between evolutionary content and evolutionary position is represented by evolutionaryOrder. As an attribute of advice, evolutionaryOrder is composed of four values: before, after, around and parallelTo. Before, after or parallelTo represents that the imported new process is performed before, after or parallel to the process designated by pointcut. Around represents the imported new process substitute the process designated by pointcut. 4.3 A Case Study We present an example to illustrate the evolutionary requirements specification described in OWL-SA. There is a domain process model construction, which involves 6 sub-processes: project planning, blueprint designing, builder team recruitment, material purchasing, building and project checking. They are sequent in the process model. The user argues the individualized requirements to domain requirements specification. Req1: He hopes the recruited builder team has no bad record before. Req2: He hopes the third party supervises material purchasing, building and project checking. It means the domain process model needs to be tailored to fulfill the individualized user’s requirements. After requirements analysis based on RGPS framework, we get that the evolutionary requirements are composed of: (1) Substitution of the old process builder team recruitment for the new process with no bad record. (2) Introduction of process supervising after material purchasing, building and project checking. Scenario is the following.


95

Fig. 2. Construction process model evolution scenario

The evolutionary requirements specification about Req2 is demonstrated in the following code list. We add ThePointcutPerform to support data binding between pointcut and imported new process in OWL-SA. //CompositeProcess[@rdf:ID=construction]// Perform[@rdf:ID=”Mateiral Purchasing”] //CompositeProcess[@rdf:ID=construction]// Perform[@rdf:ID=”Building”] //CompositeProcess[@rdf:ID=construction]// Perform[@rdf:ID=”Project Checking”] < Perform rdf:ID = “SupervisingPerformed”> /*I11 is the input of Supervising*/ < ValueOf> < theVar rdf:resource=“#OP”/> /*OP refers to output of the performed pointcut.*/ < fromProcess rdf:resource=“#http://www.daml.org/services/owls/1.1/Process.owl#ThePointcutPerformed”/> /*Setup data binding to the variable of pointcut process.*/ /*O11 is the output of Supervising*/

96

Z. Feng et al.

/*set up data binding to output O1 of Construction*/

5 Process of Requirements Evolution Modeling Requirements evolution process is driven by the user’s individual requirement. In section3, inducements of requirements evolution are analyzed including functional requirements, some non-functional Quality expectation and business context expectation. After acquiring the user’s individualized requirements, which is then through requirements analyzing and modeling based on RGPS framework, we get the evolutionary position and expected process that supports evolution. Meta-model of OWLSA describing the evolutionary specification is proposed in section 4. In this section we will illustrate the process of requirements evolution modeling. In general, the process of individualized evolution modeling is composed of two basic stages: discovery of process specification in domain knowledge and the modification to the domain process model. It is necessary of stage1 because the evolution of domain process model needs some evolutionary elements represented as atomic process or composite process. If no suitable process provides inserting or substituting operation, the evolution of domain process model maybe pauses. Discovery of process requirements specification comprises semantic matching and Quality/Contextual matching. The semantic matching finds the process that fulfill the user’s requirements by the semantics of input or output based on domain ontology in domain knowledge repository. Based on semantic matching, the Quality/contextual matching finds the process that fulfills the user’s Quality requirement or individualized business context requirement in the domain knowledge repository. It is necessary to refer that the process meta-model, as the extension of meta-model of OWL-S, has the capability to describe user’s quality or contextual requirement. If user argues additional functional requirements, semantic matching will help to find evolutionary element. If user argues additional contextual or quality requirements, the semantic matching and Quality/Contextual matching are both needed. Stage2 is the modification to the domain process model. If user argues more functional requirements, usually some new processes are imported to domain process model. If user argues additional contextual or quality requirements, new process with more suitable Quality or contextual expectation substitutes corresponding one in the domain process model.


97

6 Related Works Aspect technology had been applied in the domain of requirement engineering. Awais Rashid et.al propose a general model for aspect oriented requirements engineering(AORE), which supports separation of crosscutting functional and non-functional properties at requirement level [17]. In [18] Awais Rashid et.al further proposes an approach to modularize and compose aspectual requirements and concrete realization with viewpoints and XML. Ivar Jacobson et.al proposes a method which utilizes use case to modeling for crosscutting in software requirements stage in [19], and use case slice is designed based on use case in software design stage in order to constitute the model for the whole system. [20] shows aspects can be discovered during goaloriented requirement model. [17-20] demonstrates how to apply aspect to several software requirements models in order to modularize the concern in software requirement stage and improve the software quality. The paper combines aspect to requirements specification represented as process model to describe evolutionary requirements. Anis Charfi et.al proposes the application of AOP at the level of the workflow process definition language [8]. They argued that AO4BPEL could be used to modularize the concerns in process-oriented BPEL workflows. AO4BPEL enhances the modularity and flexibility of BPEL, and supports dynamic adaption of composition at runtime. OWL-SA encapsulates the evolutionary requirements specification from a process model in OWL-S. The difference between OWL-SA and AO4BPEL is: (1) OWL-SA is used to describe the evolutionary requirements specification, however, AO4BPEL is used to addresses dynamic adaption at the time of running of service composition as well as BPEL. (2)There are some difference in definition between OWL-SA and AO4BPEL, because the structures of OWL and BPEL are different. Yanbo Han classifies various types of workflow adaption, and discusses potential mechanisms for achieving adaptive workflow management in [3]. Boris Bachmendo proposed the method for workflow adaption using aspect in [9], and Qinyi Wu focused on code for defines the permissible sequences of execution for activities in BPEL and encapsulate code in synchronization-aspect [10]. He also presented tool DSCWeaver to enable extension to BPEL. Bart Verheecke et.al proposed WSML [18] between client and Web Service. Web service composition can evolve by the support of WSML through the selection of services. But their works do not focus on the adaption of requirements specification represented as process.

7 Conclusions In the paper, we demonstrate process and method on the first step of requirements evolution modeling of the NS: individualized requirements evolution modeling. Firstly we analyze the inducements of the individualized requirements evolution. Generally, it is due that the domain common requirements specification can not fulfill the user’s individualized requirements. Then we define OWL-SA which can describe the evolutionary requirements specification. And the meta-model of it is proposed at the same time. Finally, the process of requirements evolution modeling is proposed, which involves discovery of specification and tailoring of domain process model. The paper brings a new method to the requirements evolution modeling of NS.

98

Z. Feng et al.

As a representation of requirements specification, OWL-S is not suitable to construct the Web Service composition at runtime. In fact, BPEL [6] is the most popular language to set up and execute web service composition flow. So the transformation from OWL-S to BPEL is necessary. At the same time, as the representation of evolutionary specification, OWL-SA needs to be mapped to aspect in BPEL, such as AO4BPEL. Thus, with the help of dynamic weaving tool, such as AO4BPEL engine [8], weaving aspect to the executable web service composition flow will be implemented finally. Therefore, we will study on the mapping relation between OWL-SA and aspect in BPEL in the future, and corresponding tool will be developed.

Acknowledgements This research project was supported by the National Basic Research Program of China (973) under Grant No.2006CB708302 and 2007CB310801, the National High Technology Research and Development Program of China (863) under Grant No.2006AA04Z156, the National Natural Science Foundation of China under Grant No.90604005, 60703018 and 60703009, and the Provincial Natural Science Foundation of Hubei Province under Grant No.2005ABA123, 2005ABA240 and 2006ABA228.

Reference 1. He, K., Liang, P., Peng, R.: Requirement emergence computation of networked software. J. Frontier of Computer Science in China 1(3), 322–328 (2007) 2. David, M., Mark, B., et al.: OWL-S: Semantic Makeup for Web Services (November 2004), http://www.w3.org/Submission/OWL-S/ 3. Yanbo, H., Amit, S.: A Taxonomy of Adaptive Workflow Management, http://pbfb5www.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf/0/a7 fac9b815f26c87c1256c8e00669076/$FILE/CSCW98Workshop%20hansheth-bussler.pdf 4. Jin, Z., He, K., Wang, Q.: Software Requirements Engineering: Part of Progress of Studying. J.Communications of CCF (in Chinese) (November 2007) 5. Jian, W., Keqing, H., Bing, L., Wei, L., Rong, P.: Meta-models of Domain Modeling Framework for Networked Software. In: Proceedings of The Sixth International Conference on Grid and Cooperative Computing (GCC 2007), pp. 878–885 (2007) 6. Tony, A., Francisco, C., et al.: BPEL4WS V1.1 specification (May 2003), http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ ws-bpel/ws-bpel.pdf 7. Gregor, K., John, L., Anurag, M., Chris, M., Cristina, L., Jean-Marc, L., John, I.: AspectOriented Programming. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, Springer, Heidelberg (1997) 8. Anis, C., Mira, M.: AO4BPEL: An Aspect-oriented Extension to BPEL. J.World Wide Web, 309–344 (October 2007) 9. Boris, B., Rainer, U.: Aspect-Based Workflow Evolution, http://www.comp. lancs.ac.uk/~marash/aopws2001/papers/bachmendo.pdf


99

10. Qinyi, W., Calton, P., Akhil, S., Roger, B., Gueyoung, J.: DSCWeaver: SynchronizationConstraint Aspect Extension to Procedural Process Specification Languages. In: IEEE International Conference on Web Services (ICWS 2006), Chicago, US, pp. 320–330 (2006) 11. W3C: XML Path Language, Version 1.0 (November 1999), http://www.w3. org/TR/xpath 12. Liu, W., He, K.Q., Wang, J., et al.: Heavyweight Semantic Inducement for Requirement Elicitation and Analysis. In: IEEE Proceedings of 3rd International Conference on Semantics, Knowledge and Grid (SKG 2007), Xi’an, China, October 29–31, 2007, pp. 206–211 (2007) 13. He, K.Q., Peng, R., Liu, J., et al.: Design Methodology of Networked Software Evolution Growth Based on Software Patterns. J. Journal of Systems Science and Complexity 19(3), 157–181 (2006) 14. Lamsweerde, A.: Goal-oriented requirements engineering: a guided tour. In: Proceedings of the 5th IEEE International Symposium on Requirements Engineering, August 2001, pp. 249–263. IEEE Press, Toronto, Canada (2001) 15. Hans-Erik, E., Magnus, P.: Business Modeling with UML: Business Patterns at Work. John Wiley & Sons, Inc., New York (2000) 16. Yu, E.: Modeling strategic relationships for process reengineering. Ph.D thesis, Department of computer science, University of Toronto (1994) 17. Awais, R., Peter, S., Ana, M., Joao, A.: Early Aspect: a Model for Aspect-Oriented Requirements Engineering. In: IEEE Joint International Conference on Requirement Engineering, Essen, Germany, September 2002, pp. 199–202 (2002) 18. Awais, R., Ana, M., Joao, A.: Modularisation and Composition of Aspectual Requirements. In: Proceedings of the 2nd International Conference on Aspect-oriented Software Development (AOSD), Boston, USA, pp. 11–20 (2003) 19. Ivar, J., Pan-Wei, N.: Aspect-Oriented Software Development with Use Cases (Chinese Version). Publishing House of Electronics Industry, Beijing (2005) 20. Yu, Y., Leite, J.C.S.d.P., Mylopoulos, J.: From Goals to Aspects: Discovering Aspects from Requirements Goal Models. In: Proceedings of 12th IEEE International Conference on Requirements Engineering, Kyoto, Japan, September 2004, pp. 38–47 (2004)