Lightweight Behavior-based Language for Requirements Modeling

Whether or not a software system satisfies the anticipated user requirements is ultimately determined by the behaviors of the software. So it is necessary and valuable to research requirements modeling language and technique from the perspective of behavior. This paper presents a lightweight behavior based requirements modeling language BDL with formal syntax and semantics, and a general-purpose requirements description model BRM synthesizing the concepts of viewpoint and scenario. BRM is good for modeling large and complex system due to its structure is very clear. In addition, the modeling process is demonstrated through the case study On-Line Campus Management System. By lightweight formal style, BDL & BRM can effectively bridge the gap between practicability and rigorousness of formal requirements modeling language and technique.


Introduction
Software requirements modeling is an important phase of software development process.To obtain high quality requirements model, an effective and well-defined requirements modeling language and technique, which both has formal semantic and can be easily understood and used by all kinds of stakeholders, is needed.
The existing requirements modeling languages and techniques can be roughly divided into two categories.One is the semi-formal style based on graph symbol, the most famous representative of which is UML [1].The other is the formal style based on mathematics symbol, such as Automata [2], Z [3], E-LOTOS [4], Petri net [5], Pi-calculus [6], etc.The former has the advantage of strong intuition, of being easy to be understood and used, but it usually lacks rigorous semantics and easily leads to an inconsistent and incomplete requirements model.On the contrary, the latter has rigorous semantics basis and is convenient to deduce and verify some properties, but it has poor practicability, and requires the user and analyzer with advanced skills.
How to deal with the gap between practicability and rigorousness of formal requirements modeling language and technique is a big challenge [7].Some researches suggest to designating formal semantic for semi-formal language [8], and others believe the combination of graph symbol and formal language are more positiveness [9].Although all of those approaches have some effect to bridge the gap, there are still inconvenient to put them into practice.At the same time, whether or not a software system satisfies the anticipated user requirements is ultimately determined by the behaviors of the software.That is to say, the requirements modeling language and technique need to support the description and validation of behavior.So it is necessary and valuable to research software requirements modeling language and technique both has practicability and rigorousness from the perspective of software behavior.
Due to lightweight formal style can help to bridge the gap between practicability and rigorousness [10], we established a lightweight formal language BDL (Behavior Description Language) to modeling user's requirements, which is based on the identifiable behaviors of software system.What should be emphasized is that the behaviors not only include the observable behaviors from the system external interface but also consist of the behaviors resided in the internal of the system.In addition, in order to support the requirements modeling of large and complex software, a general-purpose requirements description model BRM (Behavior Requirements Model) is proposed, which partly synthesizes some ideas of viewpoint-oriented requirements engineering [11] and scenario-oriented requirements engineering [12].
The structure of this paper is organized as follows: Section 2 introduces the formal syntax of BDL and its structural operational semantics.Section 3 introduces the requirements description model BRM and Section 4 demonstrates the modeling process through the case study On-line Campus Management System.Finally, the related works are discussed in Section 5 and the conclusions and future works are discussed in Section 6.

Behavior Based Requirements Modeling Language
A behavior is a certain interaction among two or more entities.For easy discussion, this paper presumes a behavior is an interaction only between two entities.We define a software behavior as a process during which a subject implements an operation, service, or action to an object.The subject and the object which may be physical or logistic, can be a person, a software or hardware component of system, or certain element of environment.The structure of each behavior consists of a subject, an object, some properties, some inputs, some outputs, and an operation, service, or action.If a behavior can't be divided into two or more sub-behaviors, it is an atomic behavior.An atomic behavior is a simple behavior.Two or more simple behaviors form a composite behavior.In addition, according with the interact mode of software behaviors, the combine pattern of simple behaviors can be divided into five categories: sequence, certainty choice, uncertainty choice, parallel and shielding.
Based on the above consideration about software behavior, the followings are the syntax and structural operational semantics of behavior based requirements modeling language BDL.

Syntax of BDL
2) Certainty choice behavior:  denotes the Boolean value of b at .Suppose , ( ) i i N    are atomic behavior, , B B i ( ) N i are behavior expression.The structural operational semantics of BDL can be defined in this way: 1) Semantic of atomic behavior expression: 3) Semantic of End action of composite behavior: Suppose  is the first atomic behavior of B.

Behavior Based Requirements Description Model
As to small and simple software system, BDL can be used to describe its requirements model directly due to BDL's syntax is also simple and small.But it is hard to describe requirements model of large and complex software system using BDL directly because on the one side the software scale and structure may be very complicated, and on the other side many kinds of stakeholders who reside in different time zone and space, may be involved.
To deal with large and complex problems, people often employ the strategy of divide-and-rule.Based on this method, we propose a general-purpose requirements description model BRM, which synthesizes the concepts of viewpoint and scenario.The model process of BRM consists of five steps: first, to identify the scope of the whole problem domain of the software system, next, to divide the problem domain into some interrelated sub-domains.After that, to list all potential viewpoints and their sequence or overlap relationships of each sub-domain based on the viewpoint identifying methods of viewpoint-oriented requirements engineering [11].Later on, to look for different scenarios and their sequence or overlap relationships of each viewpoint.Finally, to adopt the scenario describing way of scenario-oriented requirements engineering [12] to establish each scenario model using BDL.
BRM is composed of three kinds of model.One is the scenario behavior model, another is viewpoint behavior model, and the last is system behavior model.The followings are the formal definition of them.
Definition3  is also a 2-tuple operator, which denotes two viewpoints have overlaps in domain, that is, the sub-domains where they belong to have common elements;  is also a 2-tuple operator, which denotes two scenarios have overlaps in content, that is, they have common behaviors;  denotes two or more viewpoints are independent of each other in execution order and in domain. denotes two or more scenarios are independent of each other in execution order and in content.
These relation operators can also be use to assisting analyze and check requirements model's properties from the aspect of syntax and semantic at the phase of requirements analysis.
These relation operators can be use to assisting analyze and check requirements model's properties from the aspect of syntax and semantic at the phase of requirements analysis.
The syntax structure of system behavior model is defined as Figure 3, where, ViewpointOperator is the viewpoint's relation symbol or .

Case Study
On-line Campus Management System (OCMS) consists of several subsystems related each other, which used for the daily management of education administrative unit and schools.Its user requirements have modeled using BDL & BRM.In this section, we demonstrate a partial of function requirements model of OCMS.
The following is part of the functions of Student Information Management Subsystem: 1) Student needs to scan his or her IC card at the door-control reader when he or she enters or leaves schoolyard, at the same time, a correlative short message will be automatically sent to the student's parents' mobile phone; 2

) Teachers can process students' all kinds of information and send student's information to his or her parents by the way short message and E-mail;
3) Administrator distributes IC cards and manages its authorization.Besides, Administrator sets the students attendance rules and the system automatically creates the students attendance reports;

4) Parents can query his or her child's all kind of information at school by the way of short message, automatic voice and webpage.
The logic structure of above functions as Figure 4.
Although the above function requirements look very simple, there are many complicated and redundant details.For example, how long and how to does the attendance report is created, how to manage the input, modification, processing, storage, transmission, respondence, etc. of all kinds of students' information among different domain elements.Due to space limitations, we directly give the analysis result of above requirements and only demonstrate a partial of requirements model using BDL & BRM.
The problem domain boundary of above user requirements is clear.The followings are the five sub-domains of it: Sub-domain 1: student, IC card, IC reader, mainframe, door and swivel of door; Sub-domain 2: administrator, attendance rules, terminal, mainframe, IC card, IC reader; Sub-domain 3: teacher, all kinds of student's information at school, terminal, mainframe; Sub-domain 4: parents, mobile phone, telephone, terminal, mobile phone networks, telephone networks, Internet, all kinds of student's information at school; Sub-domain 5: mainframe, IC reader, terminal, mobile phone networks, telephone networks, Internet, attendance report, all kinds of student's information at school, list of IC card information.
(  These sub-domains related each other through common elements.For example, Sub-domain 1 and Sub-domain 5 has the common element IC reader, which hints some viewpoints of them may have the relationship "  " defined in Definition 5.
As to Sub-domain 5, we can identify five viewpoints: VP_ICInfo_Manage, VP_AttenRep_Create, VP_Query _Respond, VP_Info_Send, VP_Info_Edit.The relationships of them as Table 1 using the shape of strictly upper triangular matrix.
As to Sub-domain 1, there is only one viewpoint VP_ScanCard, which have the following relationships with the viewpoints belong to Sub-domain 5: <VP_ScanCard VP_ICInfo_Manage>, <VP_Scan Card VP_Info_Send>, etc.
  Now, we give a demonstration of VP_ScanCard's modeling process and its behavior model.The followings are the detailed user requirements of this viewpoint: When a student wants to enter or leave school, she or he needs to scan her or his IC card at the IC reader firstly.If the IC-holder is authorized to enter or leave the school, the door-control system will display the IC-holder's name on the IC reader's screen and open the door.Otherwise, a warning sound will be played in the IC reader's speaker, and the reason why the person is not permitted to enter or leave will be displayed on the screen.
In this viewpoint, there are two scenarios: one is the IC-holder has the right to enter or leave school SC_ValidScanCard, the other is the opposite SC_In-validScanCard.
First, we list all atomic behavior expressions belong to SC_ValidScanCard according to above requirements as Figure 5.
Then, the scenario behavior model of SC_Valid-ScanCard can be established as Figure 6 according to the interrelated relationship of above atomic behavior expressions and Definition 3.
Next, the scenario behavior model of SC_Invalid ScanCard as Figure 7 can be established similarly.
After that, due to SC_ValidScanCard and SC_ In-validScanCard have the common elements in domain, the viewpoint behavior model of VP_ScanCard is established as Figure 8.
Here, the behavior model of VP_ScanCard is established successfully.Behavior model of other user requirements can be established similarly.

Related Works
The semi-formal and formal requirements modeling language and technique both have achieved prominent outcomes in the past twenty years.As to the behavior based requirements modeling, the importance and validity of it has also recognized by many researchers from academia and industry [13][14][15][16][17][18][19][20].
Ayaz et al. propose a behavioral specification language for complex systems-Viewcharts, which extends Statecharts to include behavioral views and their compositions [13].And they define the syntax of viewcharts as attributed graphs and describe dynamic semantics of viewcharts by object mapping automata [14].Viewcharts notation allows views to be specified independent of each other, which is similar to BDL.A difference between this work and ours is that Viewcharts does not consider behav-iors reside in the internal of system, but only observable behaviors from the external system.
Assem proposes an event-oriented requirements definition approach named Behavioral Pattern Analysis Approach (BPA) [15].In BPA, Event is the primary object of the world model.And it use the so-called BPA Behavioral Pattern, which is the template that one uses to model and describe an event, takes the place of the use case in the UML.BPA is a more effective alternative to use cases in modeling and understanding the function requirements.However, BPA is special for real-time systems, multi-agent systems and safety-critical systems.Besides, it lacks clear links among Behavioral Patterns and can't be used for modeling complex system and is not convenient for requirements verification.On the contrary, our approach definitely labels the relationships of scenarios, viewpoints, and sub-domains, can effectively  support the modeling and verification of large and complex system.Khairuddin et al. propose a requirements notation RNSMA and a behavioral approach to specify interactive multimedia applications [16].RNSMA is based on Petri Net, but its semantics are extended to support reactive systems.In RNSMA, transitions due to events are subdivided into automatic, user and clock.The transitions due to tasks to be done are subdivided into animate, image, sound, text and video.RNSMA uses an extremely simple syntax, which can be read even by novices as a form of pseudo-code.Compared with RNSMA, our work can support general-purpose requirements modeling, not special for stand-alone multimedia applications.
UML is a general-purpose and most famous modeling language for software engineering, which is standardized by OMG [1].Requirements modeling manner in UML consists of the use case diagram, sequence diagram, state diagram and activity diagram.UML provides standard notation for modeling software analysis and design.But a common and fair criticism of UML is that it is gratuitously large and complex, imprecise semantics, and a dysfunctional diagram interoperability standard (XMI).As another OMG standard, SysML acts as a general-purpose modeling language for systems engineering applications [17].SysML is based on UML, and it reduces UML's size and software bias while extending its semantic to model requirements and parametric constraints.These capabilities are essential to support requirements engineering and performance analysis.
Besides, there are some researches based on UML and SysML.Luigi et al. propose combining problem frames and UML to describe software requirements in order to improve the linguistic support for problem frames and the UML development practice by introducing the problem frames approach [18].Pietro et al. propose the integration of SysML and problem frames by presenting how a set of well known problem frames can be represented by means of SysML [19].Atle et al. propose to extend UML sequence diagrams to model trust-dependent behavior with the aim to support risk analysis [20].All of these researches are good for the enhancement of behavior modeling.
In addition, there are many kinds of formal languages and techniques for requirements modeling, especially for behavior requirements.Most of them are based on state or event.Some are standardized by different international organization, such as Z [3], E-LOTOS [4].Others may be very famous in industry, such as B [21], VDM [22].Although formal languages and techniques have many advantages, it is difficult to put into practices totally.On the contrary, our approach can be easily used to transform natural language requirements to formal requirements model because the syntax of BDL and the structure of BRM are very simple and clear.

Conclusions and Future Work
Software requirements modeling from the perspective of behavior can not only supports the description and modeling of function requirements but also supports the analysis and deduction of non-function requirements.As a lightweight formal requirements description language and model, BDL & BRM can help to smoothly transfer the user requirements expressed by natural languages to formal requirements model expressed by BDL.And the formal model BRM is also good for subsequent requirements verification and validation.Hence, BDL & BRM can effectively bridge the gap between practicability and rigorousness of formal requirements modeling language and technique.Several completed case studies also testified this kind of feature of BDL & BRM.
Currently, we have realized the prototype requirements modeling tool and experimented some case studies.Future works will mainly focus on to define all kinds of requirements properties based on BDL&BRM, and to design and implement corresponding automatic analyzing and deducing methods.

9 )Figure 5 .
Figure 5. Atomic behavior expressions of the scenario with the right to open the door

Figure 6 .
Figure 6.Scenario behavior model with the right to open the door

(Scenario behavior model):
2-tuple operator, which denotes two viewpoints have the sequence relationship in terms of execution;  is a 2-tuple operator, which denotes two scenarios have the sequence relationship in terms of execution; S is a