Service-based Domain Requirements Completeness ... - IEEE Xplore

1 downloads 0 Views 1MB Size Report
2009 Second Asia-Pacific Conference on Computational Intelligence and Industrial Applications. Service-based Domain Requirements Completeness. Analysis.
2009 Second Asia-Pacific Conference on Computational Intelligence and Industrial Applications

Service-based Domain Requirements Completeness Analysis Wei Liu School of Computer Science and Engineering, Wuhan Institute of Technology Hubei Key Laboratory of Intelligence Robot Wuhan, China [email protected]

Chengwan He School of Computer Science and Engineering, Wuhan Institute of Technology Wuhan, China [email protected]

system on networked environment; on the other hand also bring new bafflements of requirement engineering on network environment, which demands a more thorough and systematic approach to eliciting and analyzing requirements. Service requestor and service provider could be regarded as two kinds of stakeholders in service-oriented software engineering (SaSE) [3]. The two kinds of requirement from service requestors and service providers are named as service requirements [4][5]. Service requirements are required condition and capability of solved problems or achieve goals by stakeholders. The characteristics of service requirements are as follows. First, the communication between service requestors and service providers is "back-to-back" mode, which is a loosely coupled communication model. Second, evolvement is one of significant characteristics existed in service-oriented software requirements [6] [7]. Third, business process executed model is referred to service-oriented requirement specification. The business process model could describe the executing sequence of a group of service resources and the sharing data between these resources [8]. The three characteristics mentioned above illuminate incomplete problem of service requirements from three aspects. (1) The early model could not completely cover the service requirements of them. (2) Due to the evolvement characteristics of service requirements, the one of major objects of requirement analysis is not absolute completeness but relative completeness. (3) Control structure information of business processes is difficult to be provided by service requesters or service providers, so lacking for the control structure information brings on the not complete characteristics of service requirements. Goal oriented requirement engineering(GORE) have proposed some approaches of traditional requirement completeness analysis. Darimont and van Lamsweerde define a number of such patters for goal refinement in [9]. The GBRAM method provides strategies and heuristics for goal refinement [10]. It does not provide an algorithm for formal or semi-formal analysis of goal models or goal refmements. In i*

Abstract-Service-oriented computing (SOC) is a kind of computing paradigm that utilizes services as fundamental elements for developing applications. In study domain of SOC, modeling and analysis of services-oriented software requirements is an important research direction. Because of frequent changes of individual or collective requirements and continuous evolution of system function & structure, the study object of services-oriented requirement completeness analysis is relative completeness of services requirements but not absolute completeness. This paper focuses emphases on key problem of servicesoriented software engineering. First, domain knowledge and software reuse technology are combined to present a framework of services-oriented requirement components modeling; second, constructing and optimizing the requirement components directed graph to automatically realize completeness analysis for service requirements; lastly, the concepts of expected requirements and excited requirements are introduced into our research for quantitatively evaluating the results of completeness analysis. The research platform automatically provide theoretical foundation and tool support for modeling in semantic level and analyzing of services-oriented software requirements, simultaneity it will adapt to the new challenges of software on network environments development mode and improve the agreement degree of stakeholder requirements by a large margin. Keywords-requirement completeness; requirement component; domain ontology; requirement component directed graph

I.

Kui Zhang Huawei Technologies, Co., Ltd Wuhan, China zk [email protected]

INTRODUCTION

Service-oriented computing (SOC) [1] is the computing paradigm that utilizes services as fundamental elements for developing applications. Networked software is a complex software system deployed on network environment, which works a kind of typical application in SOC [2]. Development of networked software technology on one hand could reduce the time, expense and risk of developing a new software

PACIIA 2009

978-1-4244-4607-0/09/$25.00 ©2009 IEEE 110

and Tropos goals and tasks are refined through means-ends and task decompositions [11]. The NFR framework provides a catalogue of methods for systematic refinement of softgoals [12]. Goal refinement is the core activity in GORE and thus these approaches provide a variety of notations, refinement patterns, as well as formal and semi-formal analysis methods to support it [13]. These approaches only discuss the completeness analysis from abstract to concrete, but goal dependency is ignored in requirement completeness analysis. The completeness analysis of service requirements is the important study content in services-oriented software development. Our study focuses this key problem of servicesoriented software engineering. First of all, domain knowledge and software reuse technology are combined to present a framework of services-oriented requirement components modeling; then, constructing and optimizing the requirement components directed graph to automatically realize completeness analysis of requirements; lastly, the concepts of expected requirements and excited requirements are introduced into our study for quantitatively evaluating the completeness results. The study productions provide theoretical foundation and tool support for modeling in semantic level and analyzing of services-oriented software requirements automatically, simultaneity it will adapt to the new challenges of software on network environments development mode and improve the agreement degree of stakeholders by a large margin.

II.

Process Level

ljatatoleInteract Ion

Figure!. Domain oriented requirement asset metamodel

DoRA model instructed according to DoRA metamodel could be described with an ontology description language, such as OWL [19]. This model has two characteristics. First, the DoRA model is multi-granularities and multi-aspects. RoleAsset. The granularities of assets (RoleAsset, GoalAsset and ProcessAsset) are from small to big, and the aspects of assets are from static to dynamic . Secondly, the DoRA model is described by domain ontologies. The semantic interoperability between DoRA models could provide theory and practice basic for semi-automatic or automatic realization of requirement analysis and service resources aggregation.

S ERVICE-ORIENTED DOMAIN REQUIREMENTS MODEL

A. Domain oriented Requirement Assets Model Domain oriented requirement modeling technology considers that stakeholder participation in requirement process is effective for requirement elicitation and analysis. Domain knowledge works as bridge between domain experts and common customers. At present, domain concept and domain requirement are two kinds of main granularity elements for knowledge reuse. Domain concepts applied in requirement elicitation and analysis are proposed in ontology-oriented requirements analysis (OORA)[14][I5]. Domain ontologies [16] are viewed as basic thread to lead domain customers to describe systems. In [17], a domain requirement is defined as one common requirement that can be reused as a core asset of developing system in a product line. Ontology is used to represent domain requirements so that domain users can take part in requirements elicitation easily [18]. A domain oriented requirement asset (DoRA) metamodel is proposed for service requirements model could represent dynamic knowledge and describe more relationship of requirements. There are three kernel metaclasses in DoRA metamodel: role asset, goal asset and process asset. RoleAsset is play by actor, and associate goal asset with perform relation. GoalAsset could generalize the static attributes of requirements. ProcessAsset could describe the dynamic attributes of requirements. In Figure l, there are three kernel metaclasses in DoRA metamodel: role asset, goal asset and process asset.

B. Services Requirement Component The core asset is one of reuse objects in software product line, which is a process of developing a set of products that share a majority of features [20]. The products in every phase of software engineering, such as requirement, architecture, service and test, could work as the core asset. The kernel element of service oriented requirement modeling is requirement component (Re), which is a modularized and domain reused unit for requirements. Service oriented requirement component is defined from management view and technology view. In technology view, requirement component has to represent not only abstract requirement of stakeholders, but also concrete requirement being provided with service character. Technology view aims at different granularities and effects to define requirement component technology view includes RoleAsset, GoalAsset and ProcessAsset, which come from DoRA model. In management view, management of requirement components could construct requirement model quickly and improve the reuse degree of requirement component. Technology view aims at RC registry, RC inquiry and RC track to define requirement component. Management view includes Profile, Content and Context.

111

Semantic web [22] provides a feasible solution for understanding in semantic level and disposing automatically of service requirements elicitation and analysis. For adapting to semantic web environment and making the best of knowledge in domain ontology, description logic [21] is adopted as description language for requirement component model. Definition 2.1 (Concept Set Semantic Contain) Two concept . V a,I E A,I :3 bjEan I B I d a,I == b' j, th en concept sets A and B, If set A is semantic contained by concept set B, denoted as A!:B. Semantic equivalence relation between concepts in domain ontology has defined in [26]. Two domain concepts a and b, in domain ontology, if a is defined as the equivalentClass of b, then concept a and concept b have semantic equivalence relation, denoted as "a==b". Semantic equivalence relation between domain concept set is defined for judging that two concept sets are whether or not have semantic contain relation. Definition2.2 (Condition) Precondition and Postcondition are presented as Condtion = < Argument1, Predicate, Argument2>. Argument set Argument1I, Argumentz'c; ~ I. Predicate set Predicate'czx I. Definition2.3 (Condition Semantic Equivalence) Two condition Ci= and Cj= , If Predicate/==Predicatejl, Arg1/==Arg1 jl and Arg2/ == Arg2/, then C, and C, have semantic equivalence relation, denoted as Ci==Cj. Definition2.4 (Condition Set Semantic Contain) Two condition sets CS i and CSj. If V C, E CS i, :3 C, E CSj and C/ == C/, then condition C, is semantic contained by condition c, denoted as c, !:Cj. Requirement component (RC) ontology is constructed according to DoRA metamodel. The RC ontology is presented as a triple RCO= : • Profile=. DomainCatalogue is the domain information; Operation and Object are elements that compose Goal, these elements are used here to denote the basic function meaning of requirement component. • Content= . Role, Goal and Process are the requirement core assets; RofA=RhasGuGhasPuRefmementuInteraction is the set of relation between requirement core assets. l)Role =, RName is the name of Role; 2)Goal = , Operation' E ~I, Object I E ~I , and Manner' E ~I; 3)Process= , Input is the input parameter set and Input' ~ ~ I, Output is the output parameter set and Output'c; ~ I, Precondition is the precondition set and Precondition'c.Condition', Postcondition is the precondition set and Postcondition'c.Condition' • Context = . RCS is the set of requirement components; RofRC =Decomposi-tion u Dependency is the set of relation between requirement components. The set of relation between requirement core assets includes the relation between role asset and goal asset, the relation

between goal asset and process asset, refinement relation and interaction relation. RhasG(RhasGI~RolelxGoall), denoted as RhasG(Rk , • Gk) , Rk l E Role l and Gk l E Goal', • Ghasl'(Ghasl'lc'Goal'xl'rocess'), denoted as Ghasl'(Gj, Pk) , Gk l E Goal l and Pk l E Process'. The relations contained in the RofA set, such as Refinement and Interaction, and the relations contained in the RofRC set, such as Decomposition and Dependency will be defined in the next section. III.

SEMANTIC RELATIONS FOR REQUIREMENT COMPLETENESS ANALYSIS

The strategy of service requirement completeness analysis includes abstract-to-concrete and inexistent-to-existent. These strategies refer to two important relations: decomposition relation and dependency relation between requirement components. The decomposition relation is basic of the abstract-to-concrete strategy, which is a lengthways analysis method. The dependency relation is fundament of the inexistent-to-existent strategy, which could offset the deficiency of abstract-to-concrete strategy and provide a widthways analysis method. The decomposition relation and dependency relation work together with requirement components as shared domain knowledge in process of requirement completeness analysis. On one hand, these domain knowledge could shield the diversity between service requester and service provider; on the other hand, the formal definition of requirement component ontology could realize automatic completeness analysis of service requirement. Decomposition relation is sticking point of the abstract-toconcrete analysis strategy. This strategy confirms the requirement component in higher level and then decomposes it into requirement components in lower lever to complete requirements. Decomposition relations are constructed according to refinement relation between goal assets. Goal refinement [23][24] is a concept or technology of transforming an abstract goal concluding uncertain system functions into a concrete goal concluding less uncertain functions. Based on the research result of goal oriented requirement engineering (GORE) [25] and feature oriented domain model [26], DoRA metamodel defines four type refinement relations. Definition 3.1 (Refinement relation) Refinement'c; Goal'> Goal' is denoted as Refinement (G a, Gb) . Gal, Gbl E Goal' and Gb is the goal asset which is refined. Refinement is classified into four types: • Mandatoryfrfl'Mandatoryfrt'c; Refinement'}. denoted as Mandatorytrfi'G; Gj ) ; • AltemativefrfiAlternativer.rt'c; Refinement'), denoted as AltemativeOf(Gm , Gn ) ; l), denoted as OROf(G , • OROf(OROf~ Refmement p G q) ; • OptionaIOf(OptionaIOf~ Refinement'}, denoted as OptionaIOf(Gx, Gy ) .

0

112

Figure2. Condit ion dependency instance

Definition3.2 (Decomposition relation) Two requirement components RCa and RCb, the goal asset of RCa is G, and the goal asset of RCb is Gb • If Refinement (G., G b) , then RCa and RC b have decomposition relation and RC b is the requirement component which is decomposed, denoted as Decomposition Dec (RCa, RC b) or RCb = RCa. Requirements completeness analysis which is based on decomposition and dependency relation constructs a network structure requirement model to substitute for traditional tree structure requirement model , which is inexistent-to-existent strategy. The strategy could capture the requirement components which are not mentioned by stakeholders and will enhance their satisfaction. Two requirement components have dependency relation indicates that realization of the requirement component as dependency target is the precondition of realization of the requirement component as dependency resource. Dependency relations are constructed according to interaction relation between process assets. Comparing with goal asset describing information in system functions level, process asset could describe dataflow and condition information in system design level. The interaction relation between process assets depicts the dynamic relation of requirements in design and realization phase. In DoRA metamodel, interaction relation includes condition interaction and dataflow interaction, so the dependency relations of requirement components are classified into condition dependency and dataflow dependency. Condition interaction relation is defined by semantic relation between precondition and postcondition of two process assets, which is an employ relation. The employing process asset is named interaction source; the employed process asset is named interaction target. Definition 3.3 (Condition interaction relation) two process assets Pi = and P, = , if condition set Postconditionf.Precondtion., then Pi and Pj have condition interaction relation, Pi is interaction target and P, is interaction source, denoted as Condition_ InteractiontP; Pi) or Pj Cl Pi. Definition 3.4 (Condition dependency relation) two requirement components RC x and RCy , the process asset of RC x is P, and the process asset of RCy is P; If Condition_Interaction (Py , Px), then RC x and RCy have condition dependency relation, RC x is dependency target and RCy is dependency source, denoted as Condition_Dependency

Definition 3.5 (Dataflow interaction relation) two process assets P, = and Pj = , if concept set Input.l.Output i, then Pi and Pj have dataflow interaction relation, P, is interaction target and Pj is interaction source, denoted as DataflowInteraction/Pj, Pi) or Pj Dl Pj. Definition 3.6 (Dataflow dependency relation) two requirement components RC x and RCy , the process asset of RC x is Px and the process asset of RC y is Py • If Dataflow_ Interaction(Py , Px), then RC x and RC y have dataflow dependency relation, RC x is dependency target and RCy is dependency source, denoted as Dataflow Dependency (RC y,

DD

RC x ) or RCy = RCx • Instance 2 is shown in Figure3, the result of semantic inference is Dataflow_Dependency (PrepareTripPlan, GenerateTripPreference) according to definition3.6. <