Paper Menu >>
Journal Menu >>
![]() J. Software Engineering & Applications, 2009, 2:13-19 Published Online April 2009 in SciRes (www.SciRP.org/journal/jsea) Copyright © 2009 SciRes JSEA An Approach to Generation of Process-Oriented Requirements Specification Jingbai Tian1, Keqing He1, Chong Wang1, Huafeng Chen1 1State Key Lab of Software Engineering, Wuhan University, China Email: Tianjingbai@live.cn Received January 10th, 2009; revised February 21st, 2009; accepted March 19th, 2009. ABSTRACT In service-oriented computing, process model may serve as a link to connect users’ requirements with Web Services. In this paper, we propose an approach and related key techniques to generate process-oriented requirements specification from user’s goal. For this purpose, a requirements description language named SORL will be provided to capture us- ers’ requirements. Then, a unified requirements meta-modeling frame RPGS will be used to construct reusable domain assets, which is the basis of generating requirements specifications. Finally, a set of rules are defined to extract process control structures from users’ requirements described with SORL, so that we can convert requirements description into process-oriented requirements specification smoothly. Keywords: Requirements Specification, Process Modeling, Process Control Stucture, Networked Software 1. Introduction Service-oriented computing (SOC) [1] paradigm is deemed as an active topic in recent years, because it pro- vides a loosely coupled, highly interoperability and high levels of reuse application architecture. As a typical kind of SOC applications, networked software (NS) [2,3] is born as a software system whose structure and behavior can evolve dynamically. Following the idea of user-cen- tric development, NS can satisfy users’ demands dy- namically by composing web services distributed among the network hosts. When customizing personalized requirements of NS, one of the key problems is to elicit users’ requirements precisely. In the network environment, it is difficult for users to describe their requirements correctly and com- pletely. What’s more, users’ requirements are always with preference and rapid change. Traditional requirements elicitation methods collect initial requirements by memo of interview transcripts, which is hard to capture rapid changes of requirements in the network environment. Moreover, Users usually describe requirements with im- precise natural languages, and it’s difficult for them to grasp formal or logical requirements description lan- guages. Accordingly, a requirements description language called Service-Oriented Requirements Language (SORL) [4] was proposed in our previous works. It defined set of natural language patterns to describe requirements and supported online requirements elicitation. In order to develop software rapidly, many previous researches emphasize on using domain acknowledge to support requirement assets reuse. In order to analyze and satisfy users’ requirements in networked environment, we proposed a domain requirements metamodelling frame- work called RGPS (Goal-Role-Process-Service) [5]. It is tended to model common requirements assets in a do- main, including domain ontology and four types of do- main models. Domain ontology consists of entity ontol- ogy and operation ontology, which represents noun terms and verb terms respectively. Domain models can resides in role layer, goal layer, process layer and service layer. Role layer describes organizations, roles, participants and the relationships between them. Goal layer addresses users’ requirements based on SORL and provides a goal based hierarchy for requirements refinement. Process layer and service layer present the processes and web services that can fulfill users’ requirements. Based on RGPS framework, users’ requirements in SORL can be translated into customized goal model and process chain step by step. Finally, these models ex- pressed with OWL can be saved as the corresponding Web service-based requirements specifications. During the process of translating, process model plays a very important role. Because process can not only give a de- tailed perspective on how a service operates, but serve as a bridge between users’ requirements and service compo- sition. According to the refining process in RPGS, goals can be refined as operational goals, which can be mapped to some certain processes. Compared with goal model, process model contains control structures. In order to generate complete process chain from initial require- ments, a control structure extraction method is expected. In this paper, an approach to generate process-oriented requirements specification is proposed to extract control structure from language patterns and business rules. This approach can be used to generate a process-based re- ![]() 14 An Approach to Generation of Process-Oriented Requirements Specification Copyright © 2009 SciRes JSEA quirements specification from users’ requirements and support web services composition in NS. The rest of this paper is organized as follows: Section 2 introduces the theoretical foundation of our approach. Section 3 gives the overview of the requirements specifi- cation generation approach. Section 4 states the process control structure extraction method with a case study. Section 5 discusses related works, followed by the con- clusions and future work in Section 6. 2. Theoretical Foundation 2.1 SORL: A Requirements Description Language Natural language pattern is the key to information extrac- tion. Based on natural language patterns, SORL is de- signed for online requirements elicitation. Figure 1 illus- trates the requirements description metamodel in SORL. There are four layers in the syntactic structure of SORL, which are sentence, pattern, phrase and word. More spe- cifically, Word includes concepts in the domain ontology and key words defined in sentence and pattern (e.g. preposition and adverb). There are 10 types of patterns in SORL, covering the description of functional goals, qualitative nonfunctional goals, quantitative non-functional goals, and precondition and post condition of a goal, etc. The SORL sentence, which can be simple sentence or compound sentence, is composed of patterns. Simple sentence can be used to describe an activity, a constraint, or a state. Compound sentence is composed of natural language pattern, which can be Loop Sentence, Choose Sentence and Trigger Sentence. In this paper, we will pay more attention to compound sentences. More details of SORL are provided in [6]. 2.2 RGPS: A Domain Metamodeling Frame In order to develop software rapidly, reuse of both code and components should be taken into account. Common requirements resources are also important asserts in software development, which should be given to recovery and reuse. Many researches recognized the potential benefit of requirements reuse [7,8], and provided corre- sponding methods. In [9], for example, ontology was used to represent common requirements in certain do- mains. In order to sort and reuse requirements assets in the networked environment, a unified requirements meta-modeling frame named RPGS is proposed. The frame is consisted of domain ontology and domain model. Domain ontology includes entities and operations, which can be imported by domain models. There are four meta-models in RGPS: Role metamodel describes the user roles of networked softwares, the actors who play roles, the contexts where actors are, intercourse between different roles, and the business rules to be complied with. Goal metamodel describes the requirements goals of users, including functional, non-functional goal, and se- mantic relationships between them (e.g. depend, conflict, etc.). The goals can be refined to operational goal further, which can be realized by business processes. The process of goal refinement will not halt until all the goal leaves are operational goals. Process metamodel defines information of business processes, including functional description such as IOPE (input, output, precondition and effect), and non-func- tional description such as Qos expectation and individu- alized business context expectation. A process can realize at least one functional goal and promote realization of non-functional goals. A process can be either an atomic process or a composite process, and a composite process has its own control structures. Service metamodel provides the solution based on ser- vice resources, with functional and non-functional attrib- utes. A service-based solution can be used to realize the specified business process. Figure 1. Requirements description metamodel ![]() An Approach to Generation of Process-Oriented Requirements Specification 15 Copyright © 2009 SciRes JSEA 1.Parsing 2.Goal Refinement 3.Process Matching NS Requirements Specification Requirements In SORL Initial Customized Goal Model Refined Goal Model Process Chain Domain Ontology Domain Role Model Domain Goal Model Domain Process Model Figure 2. Overview of the NS requirements specification generation process The domain model is provided by domain experts un- der the guidance of these four metamodels. Some domain requirements assets are stored as domain knowledge in each layer of RGPS, which corresponds to the respective requirements of different users group. Requirements of the user are elicited, analyzed, and finally matched to the common domain requirements specifications described with Web services. 3. Overview of the Approach Figure 2 illustrates the overview of the requirements specification generation process. The three shadowed parts are key steps to convert requirements into NS re- quirements specifications. ·The first step is to parse users’ requirements described in SORL to initial customized goal models by a finite automaton. SORL and domain ontology share a com- mon vocabulary to ensure that the requirements can be parsed to goal model in a consistent manner. All the functional goals and non-functional goals are matched against domain goal model. All the unmatched goals will be marked, and stored into the specification repository for further analysis by domain engineers to check whether common requirements assets are enough. ·Secondly, each goal in the first step will be linked to a role. The goals can be decomposed into more concrete sub-goals according to the hierarchical structure in domain goal model. While the sub-goals are all opera- tional goals, the refinement process is ended. The goal refinement process is shown in Figure 3. An opera- tional goal means a goal which can be matched to a simple process or a composite process consistently. In this step, the goals depended by existing goals from users’ requirements will also be added to improve us- ers’ demands. For example, if user needs the goal “book airline ticket by credit card”. To achieve this goal, the goal “validate credit card” must be carried out previously. Figure 3. Goal refinement process ![]() 16 An Approach to Generation of Process-Oriented Requirements Specification Copyright © 2009 SciRes JSEA Figure 4. Process metamodel in RPGS ·In the third step, a set of processes are gained based on the refined goal model composing operational goals. Since process model has its own control structure (e.g. sequence, choice, join, etc), a set of extraction rules is needed to extract control struc- tures from above two steps and composite these processes into process chains. With the control structures, the discontinuous processes can be inte- grated as process chains and saved as requirements specification finally. In this section, the overview of our approach is illus- trated, in next section, the process control structure ex- traction rules will be discussed in detail. 4. Extraction Rules for Process Control Structure This section discusses some rules of extracting process control structures. Figure 4 illustrates the process meta- model in RPGS frame. The shadowed parts are primitive control structures defined in RPGS, i.e. Sequence, Loop, Choice, Join, and Split. In order to obtain control struc- tures in process chains, each control structure should be mapped in metamodel layer. In our approach, process control structures are gener- ated from two sources: one is sentences based on SORL. The other is Depend relationships between related goals of the specific process. 4.1 Extraction Rules Based on SORL Sentence As Section 2 describes, two kinds of compound sentence in SORL can be used for process control structure extrac- tion, i.e. Loop sentence and Choose sentence. Loop Sentence The loop control structure can be extracted from loop sentence. Loop sentence describes system cyclic behavior under a certain condition. As Figure 5 shows, loop sen- tence is represented as “loop <function requirement pat- tern> until <condition pattern>”. To extract loop control construct from the corresponding loop sentences, we de- fine extraction rules as follows: Def.1 In a Loop sentence, FP is the Function Require- ment Pattern and CP is the Condition Pattern. So the Loop sentence “loop FP until CP is true” denoted as LoopSentence (FP, CP). Def.2 In a process chain, P is a process and C is a condi- tion. “Loop a Process P until condition C is true” will be denoted as LoopControlStructure (P, C). Def.3 If FP is a Function Pattern, the process related to the corresponding goal of this Function Pattern is denoted by P. If CP is a Condition Pattern, the related Condition in process chain is denoted by C. Extraction Rule.1: LoopSentence (FP,CP)⇒LoopControlStructure (P,C) Figure 5. Loop sentence Figure 6. Choose sentence ![]() An Approach to Generation of Process-Oriented Requirements Specification 17 Copyright © 2009 SciRes JSEA Choose Sentence The extraction of Choice control structure is similar to the one of Loop control structure. In SORL, choose sen- tence describes a selection of different system behaviors. Choose sentence is represented as “if <Condition Pat- tern>, then <Function Pattern>, else <Function Pattern>”, as Figure 6 depicts. The extraction rules of choice control structure are the followings: Def.4 FPA and FPB are two alternative Function Re- quirement Patterns in a Choose Sentence, and CP is the Condition Pattern. The Choose sentence “if CP, then FPA, else FPB” is denoted by ChooseSentence (CP, FPA, FPB). When FP is a Function Requirement Pattern in a Choose Sentence, the Choose sentence “if CP, then FP” is de- noted by ChooseSentence (CP, FP). Def.5 C is a condition in process chain, and PA and PB are two processes. The Choice control structure in process chain is denoted by ChoiceControlSturcture (C,PA,PB), which means “if C is true, then execute PA; if not, exe- cute PB”. When P is a process, if C is true, then executes P, else skip P, this is denoted by ChoiceControlSturcture (C,P) Extraction Rule.2: ChooseSentence (CP, FPA, FPB)⇒ChoiceControlStruc- ture (C, PA, PB) ChooseSentence (CP,FP)⇒ChoiceControlStructure(C,P) 4.2 Extraction Rules based on Goal Model In RGPS, Goal metamodel defines Depend relationships between goals. A Depend relationship can be either an Object Depend or a Conditional Depend. Object Depend used to indicate the Input/Output relationship between two goals, which is related to dataflow in system. Condi- tional Depend describes the Precondition/Postcondition between two goals, which is related to business rules. Object Depend In Object Depend relationship, realization of a goal de- pends on output data of the other goals. We assume that such dataflow in real time systems would never get fail- ure. Correspondingly, the realization of related process also depends on the others. Therefore, we can extract process control structure from Object Depend relation- ship this section defines three extraction rules for Se- quence, Split and Join control structure respectively. Def.6 GA and GB are two goals in refined goal model. If GA Object Depend on GB, the relationship is denoted by ObjectDepend (GA, GB). GAi (i=1, 2,…,n) and GB are goals in refined goal model, GAi (i=1, 2,…,n) Object Depend on GB, it is denoted by ),( ...2,1 BAi niGGndobjectDepeAnd = . GA and GBi(i=1,2,…,n) are goals in refined goal model, GA Object Depend on GBi(i=1, 2,…,n), it is denoted by ),( ...2,1AiB niGGndobjectDepeAnd =. Def.7 PA and PB are two processes in process chain. If there is a sequence control structure between PA and PB and PA executes after PB, denoted by Sequence (PA, PB). Extraction Rule.3: ),(),( ABBA PPSequenceGGndObjectDepe ⇒ Def.8 PAi(i=1, 2… n) and PB are Process in process chain, if PAi(i=1, 2… n) is split from P B, the control structure is de- noted by Split (PB, PAi). Extraction Rule.4: ),(),( ...2,1...2,1 AiB ni BAi ni PPSplitAndGGndObjectDepeAnd == ⇒ Def.9 PAi(i=1, 2… n) and PB are Process in process chain, if PAi(i=1, 2… n) is join to PB, the control structure is denoted by Join (PAi, PB). Extraction Rule.5: ),(),( ...2,1...2,1 BAi ni AiB ni PPJoinAndGGndObjectDepeAnd== ⇒ Conditional Depend Conditional Depend describes the business rules between goals. “Goal A is Conditional Depend on Goal B” means “if Goal B cannot be achieved, then Goal A cannot be achieved; if not, it should be skipped”. For example, a traveler want to travel to Wuhan, he want to “book an airline ticket to Wuhan”, and to “book a standard room in Wuhan”. If the first goal can’t be achieved, which means he can’t arrive in Wuhan in time, the second goal will be canceled. From this point of view, we defined the fol- lowing rules: Def. 10 GA and GB are two goals in refined goal model, If GA Conditional Depend GB, denoted by ConditionalDe- pend (GA, GB). Def. 11 PA is a process, if PA is successful execution, the condition CA in A P’s Effect would be True, else be False. Extraction rule.6 ),( ),( AB BA PC rerolStructuChoiceContGGlDependConditiona ⇒ 4.3 Case Study In this section, a case in travel and transportation domain will be demonstrated. Firstly, we constructed the domain ontology and domain model in [5]. And the following ones are requirements examples. A customer is planning a trip to Wuhan. His SORL- ased requirements are as followings:“Query travel ex- pense in Wuhan”, “Book an airline ticket to Wuhan by credit card”, “if the price is no more than 500 RMB, then, book a room, the standard of the hotel is no less than 4-Star, else, book a standard room, the standard of the hotel is equal to 3-Star.” Figure 7 Refined goal model of the case. ·Based on extraction rule 2, we can find that there is a choice control structure in the corresponding processes of “book room”. ·Based on extraction rule 3, the related process of “Validate Credit Card” must be executed before the re- lated process of “Book Airline Ticket by Credit Card”. ·Based on extraction rule 6, if “book airline ticket” cannot be achieved, “book room” should be skipped. The generated process chain is shown in Figure 8. ![]() 18 An Approach to Generation of Process-Oriented Requirements Specification Copyright © 2009 SciRes JSEA Figure 7. An example of refined goal model Figure 8. An example of process chain A trial system based on this approach is build up pre- liminarily. With the graphical process tool, users can see their requirements directly, so that users can understand the work flow intuitively and modify the work flow with ease. 5. Related Works Process-oriented technology has many potential advan- tages in software development, and many SOC tech- nologies have adopted process in their methods to im- prove the service composition. For example, OWL-S [10] models services as processes to give services a more detailed perspective. In WS-BPEL [11], processes use Web Service interfaces to export and import func- tionality. In [12], W. M. P. van der Aalst proposes an algorithm based on petri net to extract process model from “work- flow log”, which contains information about the work- flow processes in real-time systems. Moreover, many systems (e.g. ERP, CRM) provide a set of pre-defined process models. In our work, we use RGPS to manage not only process model but also related goal, role and service model. A solution for process model generation from user’s requirements is given. In [13] and [14], authors established relationships be- tween process model and high-level requirements models (e.g. KAOS and i*), presented methods to generate, vali- date and improve process model. In [15], authors present a framework and associated techniques to synthesis ser- vice composition from temporal business rules through process models. Compared with these approaches, our approach is more suitable for end-users and caters for the “user-centric” trend. 6. Conclusions and Future Work In this paper, we proposed an approach to generation of process-oriented requirements specifications. It estab- lishes mappings from SORL metamodel and Goal meta- model in RGPS to the control structures defined in Proc- ess metamodel. So it can be used to generate an NS re- quirements specification including goal models and process chains through these control structures. In the future, the control structure extraction rules will be improved, the influences from goal refinement types (e.g. mandatory, optional) to the control structure will be supplemented. Moreover, the corresponding validation and verification methods will be provided later, followed by the relevant tools and platforms. 7. Acknowledgements This research project was supported by the National Ba- sic 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 Na- tional Natural Science Foundation of China under Grant No. 60803083, 60873009, 60803025 and 60703018, the Provincial Natural Science Foundation of Hubei Province under Grant No.2006ABA228,and the Research Fund for the Doctoral Program of Higher Education of China un- der Grant No. 60803025. REFERENCES [1] M. N. Huhns and M. P. Singh, “Service-oriented comput- ing: Key concepts and principles,” IEEE Internet Com- putting, pp. 2-8, 2005. ![]() An Approach to Generation of Process-Oriented Requirements Specification 19 Copyright © 2009 SciRes JSEA [2] K. He, R. Peng, J. Liu, F. He, et al., “Design methodology of Networked Software Evolution Growth based on Soft- ware Patterns,” Journal of System Science and Complex- ity, Vol. 19, pp. 157-181, 2006. [3] K. He, P. Liang, R. Peng, et al., “Requirement emergence computation of networked software,” Frontiers of Com- puter Science in China, 1(3), pp. 322-328, 2007. [4] W. Liu, K. He, J. Wang, et al., “Heavyweight semantic inducement for requirement elicitation and analysis,” In Proceedings of the 3rd International Conference on Se- mantics, Knowledge and Grid (SKG 2007), Xi’an, China, pp. 206-211, 2007. [5] J. Wang, K. He, P. Gong, C. Wang, R. Peng, and B. Li, “RGPS: A unified requirements meta-modeling frame for networked software,” in Proceedings of Third Interna- tional Workshop on Advances and Applications of Prob- lem Frames (IWAAPF’08) at 30th International Confer- ence on Software Engineering (ICSE’08), Leipzig, Ger- many, pp. 29-35, 2008. [6] L. Wei, “Research on services-oriented software require- ments elicitation and analysis,” Ph. D thesis, Wuhan Uni- versity, 2008. [7] P. Massonet and A. van Lamsweerde, “Analogical reuse of requirements frameworks,” Third IEEE International Symposium on Requirements Engineering, pp. 26, 1997. [8] W. Lam, “A case-study of requirements reuse through product families,” Springer Netherlands, pp. 253-277, 1998. [9] Y. Q. Lee and W. Y. Zhao, “Domain requirements elicita- tion and analysis-An ontology-based approach,” In: Pro- ceedings of Workshop on Computational Science in Soft- ware Engineering (CSSE), pp. 805-813, 2006. [10] M. Smith, C. Welty, and D. McGuinness, “OWL web ontology language guide,” W3C Candidate Recommen- dation, 2004. Available: http://www.w3.org/TR/owl- guide/. [11] OASIS: Web services business process execution lan- guage version 2.0, 2006. Available: http://docs.oasis- open.org/ wsbpel/2.0/wsbpel-specification-draft.html. [12] W. van der Aalst, T. Weijters, and L. Maruster, “Work- flow mining: Discovering process models from event logs,” IEEE Transactions on Knowledge and Data Engi- neering, Volume 16, Issue 9, 2004. [13] G. Koliadis and A. Ghose, “Relating business process models to goal-oriented requirements models in KAOS,” PKAW 2006, pp. 25-39, 2006. [14] A. Ghose and G. Koliadis, “Actor eco-systems: From high-level agent models to executable processes via se- mantic annotations,” COMPSAC 2007, pp. 177-184, 2007. [15] J. Yu, Y. B. Han, J. Han et al., “Synthesizing service composition models on the basis of temporal business rules,” Journal of computer science and technology 23(6) pp. 885-894, 2008. |