From Contracts in Structured English to CL Specifications
EE. Pimentel, V. Valero (Eds.): Workshop on Formal Languagesand Analysis of Contract-Oriented Software 2011 (FLACOS’11)EPTCS 68, 2011, pp. 55–69, doi:10.4204/EPTCS.68.6 c (cid:13)
Montazeri, Roy & SchneiderThis work is licensed under theCreative Commons Attribution License.
From Contracts in Structured English to
C L
Specifications
Seyed Morteza Montazeri, Nivir Kanti Singha Roy
Department of Computer Science and EngineeringUniversity of Gothenburg, Sweden [email protected], [email protected]
Gerardo Schneider
Department of Computer Science and EngineeringChalmers | University of Gothenburg, SwedenDepartment of InformaticsUniversity of Oslo, Norway [email protected]
In this paper we present a framework to analyze conflicts of contracts written in structured English.A contract that has manually been rewritten in a structured English is automatically translated into aformal language using the Grammatical Framework (GF). In particular we use the contract language
C L as a target formal language for this translation. In our framework
C L specifications couldthen be input into the tool CLAN to detect the presence of conflicts (whether there are contradictoryobligations, permissions, and prohibitions. We also use GF to get a version in (restricted) English of
C L formulae. We discuss the implementation of such a framework.
Natural language (e.g., English) descriptions and prescriptions abound on documents used in differentphases of the software development process, including informal specifications, requirements, and con-tracts at different levels (methods/functions, objects, components, services, etc.). There is no doubt ofthe usefulness of having such descriptions and prescriptions in natural language (NL), as most of theintended users of the corresponding documents would not have problems to understand them. However,it is well known that NL is ambiguous and imprecise in many cases due to context sensitivity, underspec-ified terminology, or simply bad use of the language.At the other extreme, we have formal methods with a myriad of different formal languages (logics)with complex syntax and semantics. Those languages are indeed extremely useful as they are precise,unambiguous, and in many cases tools are available as to provide the possibility of (semi-) automaticanalysis. However, in many cases they require high expertise not only at the syntactic level in order touse the language to specify system properties or requirements, but also to interpret the results of the tools.For instance, though the use of model checkers has been advertised as a “push-button technology” notrequiring user expertise, the reality is that one still needs to write the properties on a logic and interpretthe counter-examples which are also usually given as a big formula representing the trace leading to theproblematic case.On an ideal world, software engineers (and the mortal non-technical users) would only need to dealwith natural language descriptions, push a button and get a result telling them whether for instance thegiven contract (specifications, set of requirements) is consistent and conflict-free. The current state-of-practice however is far from that ideal world. Though the state of the art on NL processing has advanced In the rest of the paper we will use the term “contract” to refer to contracts at different levels (including legal contracts),software specifications, requirements, etc. From Contracts in Structured English to
C L
Specifications C : = C O | C P | C F | C ∧ C | [ β ] C | (cid:62) | ⊥ C O : = O C ( α ) | C O ⊕ C O C P : = P ( α ) | C P ⊕ C P C F : = F C ( α ) α : = | | a | α & α | α . α | α + αβ : = | | a | β & β | β . β | β + β | β ∗ Figure 1:
C L syntax.quite a lot in recent years, we still have to depend on the use of formal languages and techniques to ana-lyze such contracts. A relatively new trend is then to restrict the use of NL in order to get something that“looks like a NL” but it has a better structure, and if possible avoid ambiguity. We call such constrainedlanguages restricted or controlled NL.Our aim in this paper is to advance towards finding a suitable solution to the problems and challengesjust mentioned, in particular the possibility of writing contracts in NL, but being able to analyze themwith tools, automating the process as much of possible. In particular, we show that it is possible to relatethe formal language for contracts
C L [10] and a restricted NL by using the Grammatical Framework(GF) [11]. In this way we are able to take contracts written in NL, manually obtain a restricted NL versionof such contract, use GF to automatically obtain a
C L formula that could then be analyzed using CLAN[3]. Note that the above process should be in both directions, as we might need the translation from
C L into NL since the result of CLAN in case a conflict is detected is given as a (eventually huge)
C L formula representing the counter-example.The paper is organized as follows. In next section we recall the necessary technical background therest of the paper is based on, including
C L and GF. In section 3 we present our framework in generalterms, and we provide some details on the implementation. Before concluding in the last section wepresent a case study in section 4.
C L
C L is a logic based on combination of deontic, dynamic and temporal logics, designed to specify andreason about legal and electronic (software) contracts [9, 10]. With the help of
C L it is possible torepresent the deontic notions of obligation, permission and prohibition, as well as the penalties appliedin case of not respecting the obligations and prohibitions. In what follows we recall the syntax of
C L ,and we give a brief intuitive explanation of its notations and terminology, following [10]. A contract in
C L may be obtained by using the syntax shown in Fig. 1.A contract clause in
C L is usually defined by a formula C , which can be either an obligation ( C O ),a permission ( C P ) or a prohibition ( C F ) clause, a conjunction of two clauses or a clause preceded by thedynamic logic square brackets. O , P and F are deontic modalities, the obligation to perform an action α is written as O C ( α ) , illustrating the primary obligation to perform α , and if α is not performed then thereparation contract C is enacted. The above represents in fact a CTD ( Contrary-to-Duty ) as it specifieswhat is to be done if the primary obligation is not fulfilled. The prohibition to perform α is representedby the formula F C ( α ) , which not only specifies what is forbidden but also what is to be done in casethe prohibition is violated (the contract C ); this is called CTP ( Contrary-to-Prohibition ). Both CTDsand CTPs are then useful to represent normal (expected) behavior as well as the alternative (exceptional)behavior. P ( α ) represents the permission of performing a given action α . In the description of the ontazeri, Roy & Schneider α and β in Fig. 1). It should be noticedthat the usage of the Kleene star (the * operator) which is used to model repetition of actions, is notallowed inside the above described deontic modalities, though they can be used in dynamic logic style-conditions. Indeed, actions β may be used inside the dynamic logic modality (the bracket [ · ] ) representinga condition in which the contract C must be executed if action β is performed. The binary constructors&, ., and + represent concurrency, sequence and choice in basic actions (e.g. “buy”, “sell”) respectively.Compound actions are formed from basic actions by using the above operators. Conjunction of clausescan be expressed using the ∧ operator; the exclusive choice operator ( ⊕ ) can only be used in a restrictedmanner. (cid:62) and ⊥ are the trivially satisfied and violating contract respectively. 0 and 1 are two specialactions that represent the impossible action and the skip action (matching any action) respectively. The following example is an excerpt from part of a contract between an Internet provider and aclient, where the provider gives access to the Internet to the client: “The Client shall not supply falseinformation to the Clients Relations Department of the provider”, and “if the client does provide falseinformation, the provider may suspend the service” [8]. If we consider the action fi (representing that“client supplies false information to Client Relations Department”), and s (representing that “providersuspends service”), in C L the above would be written as F P ( s ) ( f i ) .One of the usefulness of C L is that there are tools available to detect whether a given
C L formulacontains conflicts . There are four main kinds of conflicts in normative systems, and contracts in particular.The first one is when there is an obligation and the prohibition of performing the same action, in whichcase, independently of what the performed action is, will lead to a violation of the contract. The secondconflict type happens when there is a permission and a prohibition to do the same action, which mightlead to a contradicting situation. The other two cases are when there is an obligation to perform mutuallyexclusive actions, and the permission and the obligation to perform mutually exclusive actions. CLANis a tool that automatically determines whether there are conflicts on
C L formulae, giving a counter-example in case a conflict is detected [3].
The Grammatical Framework (GF) is a framework to define and manipulate grammars [11]. Historically,GF was first implemented in the project “Multilingual Document Authoring” at Xerox Research CenterEurope in Grenoble in 1998 [11]. As explained in [4] the main idea of this project was to build an editorwhich helps a user to write a document in a language which is unfamiliar, as Italian, while at the sametime seeing how it develops in a familiar language such as English. The development of GF continuedover time and evolved into a functional programming language, with multiple application domains [11].GF has a central data structure called abstract syntax , based on type theory where it is possible to definespecial purpose grammars. It also has a concrete syntax part where it is possible to specify how theformulas defined in the abstract syntax can be translated into NL or a formal notation. One notable useof GF useful for our purposes, is the possibility to relate NL and formal languages in both directions:it is possible to go from a sentence written in NL to a term in the formal language, and vice-versa. GFhas a module system consisting basically of two main modules, one to define the abstract syntax and theother the concrete syntax.
Abstract syntax.
Abstract syntax is a type-theoretical part of GF where logical calculi as well as mathe-matical theories may be defined simply by using type signatures [4]. Let us consider the simple “Hello Some of the reasons behind the
C L syntax have been motivated by a desire to avoid deontic paradoxes [6]. See [9] for amore detailed explanation of the design decisions behind
C L . From Contracts in Structured English to
C L
Specifications world” example. We start by defining the types of meaning (categories)
Greeting and
Recipient : cat Greeting ; Recipient .We then define Hello as a function for building syntactic trees. The type of
Hello has
Greeting as itsvalue type and
Recipient as its argument type: fun Hello: Recipient -> Greeting; . Concrete syntax.
Once an abstract syntax is constructed, we can build a concrete syntax by using lin-earization rules, which basically allow us to generate the language. For instance, the English linearizationrules for the function
Hello is: lin Hello recip = {s = ‘‘hello’’ ++ recip.s}; .The above defines the linearization of
Hello in terms of the linearization of its argument, representedby the variable recip . The terminal ‘‘hello’’ is concatenated with recip.s using the concatenationoperator ++, which combines terminals. The most important thing to consider in a linearization rule isto define a string as a function of the variable it depends on.The example above shows that the fun rules should be defined in the abstract syntax modules and lin rules in concrete syntax modules. In the abstract syntax is where we need to define powerful type theoryto express dependencies among parts of texts, and in the concrete syntax we need to define language-dependent parameter systems and the grammatical structures.From the practical point of view, the concrete syntax description above could be saved on a file (letsay example.gf ), which could be uploaded by making import example.gf . By executing the com-mand line
Parse "hello world" we generate the abstract syntax
Hello World . It should be noticedthat
Hello is the function defined in the abstract syntax above (prefixed with fun ), and
Recipient is theargument type of the function (i.e.,
World is of type
Recipient ). In the concrete syntax,
Recipient isa record recip containing a string s which in this case will take the value "world" .To summarize, the two main functionalities in GF useful for our purpose are linearization (translationfrom abstract to concrete syntax) and parsing (translation from concrete to abstract syntax). In this section we present our framework,
AnaCon , in general terms, and we present a summary of thelinearization and parsing process of
C L into GF.
AnaCon takes as input a text file containing the description of a contract consisting of 3 parts: 1) A
Dictionary listing the actions being used in the contract together with a textual description; 2) The con-tract itself written in restricted English; 3) A list of contradictory actions. (Fig. 2 shows the input filecontaining a simple contract.)Our framework is summarized in Fig. 3 where arrows represent the flow of information highlightinghow it works. Essentially, it consists of a parser, the Grammatical Framework, the conflict analysis toolCLAN, and some scripts used to connect these different parts. Overall, the typical workflow of
AnaCon is as follows:1. The user writes a contract (specification, set of requirements, etc) in NL (“plain” English), whichis then manually translated into restricted English. This is a modeling task and it is done manually.It does not require any technical skill from the user, only to get access to the list of “allowed”English words to be used in the restricted version of the language. For instance, a sentence origi-nally written as “The ground crew is obliged to open the check-in desk” would be translated into ontazeri, Roy & Schneider
AnaCon script as anargument so the analysis starts (in what follows we call the input file containing the given contract,
Contract.txt ).3.
Cont_ParserScriptGen (a Java program) generates a script file based on the content of
Con-tract.txt . The script file
Cont_Parser then projects the content of the file to testGrammarCl parser.4. At this stage testGrammarCl conducts syntax analysis based on the structure defined for thesystem. This parser is based on Labelled BNF grammar and generated from BNF Converter [5].5. The Java program
Comparison connects with testGrammarCl in order to obtain actions definedin the contract and then compare these actions against the ones defined in the
Dictionary part of
Contract.txt . Other analysis such as comparison between actions defined in
Contradiction and theones in
Dictionary , duplication of actions in
Dictionary and empty string assertion, are conductedat this level.6. After successful parsing, the
Cont_GF_Cl script file is generated with the contract and necessaryinformation to start the translation process in GF from Restricted English to
C L .7. The version of the contract written in restricted English is then represented in the abstract syntaxpart of GF.8. The abstract syntax obtained above is translated into concrete syntax (
C L ) which is then storedin the text file
Result Cl.txt .9. The concrete syntax (
C L formula) in textual form is transformed into XML by using
Cl2XML (implemented but not integrated).10. The XML version of the
C L output of GF is fed into CLAN for analyzing whether the contracthas a conflict.11. If the output of CLAN is ‘NO’, then the answer is immediately given to the user. If the answeris ’YES’ then the counter-example will be given by CLAN (a big
C L formula containing theconflicting subclauses as well as the trace leading to such a state).12. The formula obtained from CLAN is then linearized into a restricted English using GF. The
Cl_GF From Contracts in Structured English to
C L
Specifications
Figure 3:
AnaCon
Frameworkscript will take the content of
Result Cl.txt and pass it to
Cl_GF_ContScript (a Java program),which generates the
Cl_GF_Cont script to start the translation. The result in restricted English isgiven in a file named
Result Eng.txt .13. The user must then find in the original contract where the counter-example arises. This last stepis currently done manually, by simply searching in the text the keywords given in the counter-example in restricted English. (We discuss in the last section our future work on how to automatepart of this process.)Except for the steps above where we explicitly mention that it is manual, the rest of the process iscompletely automatic. So far, we have only fully implemented steps 2–8, and the translation back from
C L to restricted English (as used in step 12).Besides the above, we provide the possibility of generating a restricted English version of a
C L formula, by executing
AnaCon with a special flag (
AnaCon -cl
In what follows we present the abstract and concrete syntax of
C L and NL, in GF. At first, we present allthe categories and functions for handling different
C L clauses and actions in the abstract syntax part, ontazeri, Roy & Schneider
C L syntax. The linearization of the different used functions and structures into
C L symbolicsyntax and natural language is done by using two concrete syntax modules. In the first one we write theexact
C L syntax, and in the latter we express the corresponding restricted natural language.We define the following categories, based on the BNF of
C L . -- Abstract module(Cl.gf module)cat Act ;KleeneStarAct;KleeneCompAct;ClSO;ClSF;ClSP;Clause;Clauses;ClauseP;ClauseO; ClauseF;And;Or;Dot;Cross;CompAct;Star;Not;[Clause]{2};[CompAct]{2};[ClauseO]{2}; [ClauseP]{2}; We define similar categories in the concrete modules
ClEng.gf and
ClSym.gf , using lincat in-stead of cat prefixing them. The main difference is that in the linearization type definitions we need tostate that for instance
Clause and
Act are records containing a field of type string s . Obligations, Permissions and Prohibitions.
Obligations, permissions and prohibitions have the samestructure in the
Cl.gf module. In the rest of this section we will only show the abstract and concretesyntax for obligations, those for permissions and prohibitions being similar. -- Abstract module(Cl.gf module)fun Obl : ClSO -> CompAct -> Clauses;OClause : ClauseO -> Clause;;Clo : ClSO -> CompAct -> ClauseO;
There are some differences among these clauses (or rather group of clauses, as there are similarones for permissions and prohibitions) which is worth mentioning. As it is clearly shown
CompAct is the argument type used among the four groups which represent both basic and compound actionsrespectively. This will provide the possibility to be able to express
Obligation over both basic andcompound actions (actions will be explained later on in this section).
ClauseO follows the BNF ofthe syntactic definition of
C L obligations and allows to express the obligation that together with theaction (verb) form the actual clause. The other difference is that generally a
Clause itself can consistof different structures and thus it can be either constructed from
ClauseO , ClauseP and
ClauseF frombasic or compound actions. They are defined in this way to avoid mixing certain operators only permittedfor some of the deontic notions. It facilitates to make the conjunction and choice of certain kind ofclauses, but not the direct linearization and parsing of each structure. For that we specify
Clauses as astart category for parsing and linearization so that each structure can be linearized and parsed directly.The linearization of the above in concrete syntax is as follows: -- Concrete module(ClEng.gf module)lin Clo clo compact = {s = "(" ++ clo.s ++ "(" ++ compact.s ++ ")" ++ ")"};OClause clo = {s = clo.s};Obl clo compact = {s = "(" ++ clo.s ++ "(" ++ compact.s ++ ")" ++ ")"};
Basically,
Clo and
Obl clauses are expressed in NL using restricted words as “It is mandatory to”( clo.s ) as terminals (quoted words in GF are terminals ) so that together with actions they formulate theclauses in NL.As explained before, we provide another concrete syntax module called
ClSym.gf to provide theuser with the possibility of writing with specific
C L syntax, such as operators, parentheses, brackets,2
From Contracts in Structured English to
C L
Specifications etc. The converse is also true, when writing any specific clause in NL, the framework (with the help ofthis module) would be able to provide
C L formulas in the intended format. -- Concrete module(ClSym.gf module)lin Clo clo compact = {s = "(" ++ clo.s ++ "(" ++ compact.s ++ ")" ++ ")"};OClause clo = {s = clo.s};Obl clo compact = {s = "(" ++ clo.s ++ "(" ++ compact.s ++ ")" ++ ")"};
The structure of the above module is very similar to the
ClEng.gf module, the only difference beingthat clo.s represent specific characters such as "O" instead of words or sentences. -- Concrete module(ClSym.gf module)lin O = {s = "O"};
Contrary-to-Duties (CTDs) and Contrary-to-Prohibitions (CTPs).
CTDs and CTPs are both relatedto obligation and prohibition clauses respectively, and are expressed as the following functions: -- Abstract module(Cl.gf module)fun CTDc : CompAct -> Clause -> Clauses;CTDcc: CompAct -> Clause -> Clause;
CTD and CTP clauses are functions taking an action (which is to be obliged, or prohibited) and aclause representing what is to be done in case the obligation or the prohibition is not fulfilled. We specifyagain these operators over simple and compound actions. We only present now the concrete modules forCTDs, the ones for CTPs being similar. -- Concrete module(ClEng.gf module)lin CTDc compact clause = {s = "(" ++ "It is mandatory to" ++ "(" ++ compact.s ++ ")"++"if not" ++ "(" ++ compact.s ++ ")"++ "then" ++ clause.s ++ ")"};CTDcc compact clause = {s = "(" ++ "It is mandatory to" ++ "(" ++ compact.s ++ ")"++ "if not" ++ "(" ++ compact.s ++ ")" ++ "then" ++ clause.s ++ ")"};
Now, we show how to express the logical syntax in the other concrete module: -- Concrete module(ClSym.gf module)lin CTDc compact clause = {s = "(" ++ "O" ++ "(" ++ compact.s ++ ")" ++ "_"++ clause.s ++ ")"};CTDcc compact clause = {s = "(" ++ "O" ++ "(" ++ compact.s ++ ")" ++ "_"++ clause.s ++ ")"};
The only important thing to notice here is the ‘‘_’’ character to express the reparation, meaningthat the clause after this symbol is the reparation clause which has to be considered in case of a violationof the primary obligation.
Conjunction of clauses ( C ∧ C ) Other operators, like conjunction and exclusive or, need also to berepresented in the abstract and concrete syntax. We only show here how to represent the conjunction. -- Abstract module(Cl.gf module)fun Conj_np : [Clause] -> Clauses;Conj_np2 : [Clause] -> Clause; ontazeri, Roy & Schneider -- Concrete module(ClEng.gf module)lin Conj_np xs = {s = "(" ++ xs.s ! Conjunction_np ++ ")"};Conj_np2 xs = {s = "(" ++ xs.s ! Conjunction_np ++ ")"};-- Concrete module(ClSym.gf module)lin Conj_np xs = {s = "(" ++ xs.s ! Conjunction_np ++ ")"};Conj_np2 xs = {s = "(" ++ xs.s ! Conjunction_np ++ ")"};
The structure used in above to show iteration conjunction of clauses, corresponds to the way it wasdefined in
C L . Test Operator.
The test operator where in
C L is used to express conditional obligations, permissionsand prohibitions. The test operator may be applied to simple or compound actions including the Kleenestar. We should thus add a function to each different application of the test operator; we will only presentthe abstract and concrete syntax of the application of the Kleene star to simple and compound actions. -- abstract module(Cl.gf module)fun TestOpc,TestOpcStar : KleeneCompAct -> Clause -> Clauses;TestOpcc,TestOpccStar : KleeneCompAct -> Clause -> Clause;
The concrete modules are as follows: -- concrete module(ClEng.gf module)fun TestOpc kleenecompact clause = {s = "(" ++ "If" ++ "(" ++ kleenecompact.s ++")"++ "then"++ clause.s ++ ")"} ;TestOpcStar kleenecompact clause = {s ="("++"((" ++ "Always" ++ ")"|"(" ++ "After"++ ")"|"(" ++ "When" ++ ")"|"(" ++ "Before" ++ ")") ++ "(" ++ "If" ++ "(" ++kleenecompact.s ++ ")" ++ "then"++ clause.s ++ ")" ++ ")"} ;TestOpcc kleenecompact clause = {s = "(" ++ "If" ++ "(" ++ kleenecompact.s ++ ")"++ "then"++ clause.s ++ ")"};TestOpccStar kleenecompact clause = {s = "(" ++ ( "(" ++ "Always" ++ ")"|"(" ++"After" ++ ")"|"(" ++ "When" ++ ")"| "(" ++ "Before" ++ ")") ++ "(" ++ "If" ++"(" ++ kleenecompact.s ++ ")" ++ "then"++ clause.s ++ ")" ++ ")"};-- concrete module(ClSym.gf module)fun TestOpc kleenecompact clause = {s = "(" ++ "[" ++ "(" ++ kleenecompact.s ++")"++ "]" ++ clause.s ++ ")"} ;TestOpcStar kleenecompact clause = {s = "(" ++ "[" ++ "1" ++ "*" ++ "]" ++"(" ++ "[" ++ "(" ++ kleenecompact.s ++ ")" ++ "]" ++ clause.s ++ ")" ++ ")"} ;TestOpcc kleenecompact clause = {s = "(" ++ "[" ++ "(" ++ kleenecompact.s++ ")" ++ "]" ++ clause.s ++ ")"};TestOpccStar kleenecompact clause = {s = "(" ++ "[" ++ "1" ++ "*" ++ "]"++ "(" ++ "[" ++ "(" ++ kleenecompact.s ++ ")" ++ "]" ++ clause.s ++ ")"++ ")"}; From Contracts in Structured English to
C L
Specifications
Actions.
Defining basic, compound and Kleene star actions in GF is not difficult, however it should benoted that since actions in our case are generally verbs that could be considered as a specific vocabularypart (domain lexicon), it is more efficient to use module extension [11]. This in effect separates thegrammar part (
Cl.gf module) from a more specific vocabulary part (
Action module). In other words,the developer will be provided with a modular system giving more flexibility to modify the modules, andthus increasing maintainability. The
Action module extends the Cl module. In such a module we willdefine all the involved simple actions (e.g., “Pay), other actions only affected by the Kleene star (e.g.,“CloseCheckIn”), as well as those operators over actions. In what follows we only show the conjunction(sequence of actions, choice, etc are defined similarly). -- Action module(abstract syntax)fun Pay,Buy : Act;-- Cl module (abstract syntax)fun CompActSI : Act -> CompAct;CompActa : CompAct -> And -> CompAct -> CompAct; The linearization of the functions specified in the
Action module above described is easy to specify: -- ActionEng module (concrete syntax)lin Pay = {s = "pay a fine"};Buy = {s = "buy a car"};CloseCheckIn = {s = "closeTheCheckIn"};CorrectDetail = {s = "checkThatThePassportDetailMatch"};
The structure of compound actions shows how the operators’ name has been used as an argumenttypes to build the functions. However, what we need to focus on in the translation of compound actionsinto NL is to know how each operator should be interpreted. As a consequence we end up with thefollowing concrete syntax where it is possible to express all the operators: -- Cl module (abstract syntax)fun CompActSI : Act -> CompAct;CompActa : CompAct -> And -> CompAct -> CompAct;-- ClEng module (concrete syntax)lin CompActSI acti = {s = acti.s};CompActa compact and compact1 = {s = compact.s ++ and.s ++ compact1.s};
User defined operations such as the above fall under specific logical symbols which are definedbelow: -- ClSym module (concrete syntax)lin CompActa CompAct and CompAct1 = {s = CompAct.s ++ and.s ++ CompAct1.s};CompActSI acti = {s = acti.s};
In this manner, the representation of and.s (similarly for or.s , dot.s , and not.s ) are reduced to "&" , "+" , "." and "!" which are logical operators as used in CLAN to manipulate C L formulae.The Kleene star is actually a compound action as shown below with the difference that it can only beused between test operator: -- Cl module (abstract syntax)fun KleeneActSI : Act -> KleeneCompAct;KleeneActa : KleeneCompAct -> And -> KleeneCompAct -> KleeneCompAct; ontazeri, Roy & Schneider The ground crew is obliged to open the check-in desk and request the passenger manifest two hours beforethe flight leaves. The airline is obliged to reply to the passenger manifest request made by the ground crew when opening thedesk with the passenger manifest. After the check-in desk is opened the check-in crew is obliged to initiate the check-in process with anycustomer present by checking that the passport details match what is written on the ticket and that theluggage is within the weight limits. Then they are obliged to issue the boarding pass. If the luggage weighs more than the limit, the crew is obliged to collect payment for the extra weight andissue the boarding pass. The ground crew is prohibited from issuing any boarding cards without inspecting that the details are correctbeforehand. The ground crew is prohibited from issuing any boarding cards before opening the check-in desk. The ground crew is obliged to close the check-in desk 20 minutes before the flight is due to leave and notbefore. After closing check-in, the crew must send the luggage information to the airline. Once the check-in desk is closed, the ground crew is prohibited from issuing any boarding pass or fromreopening the check-in desk.
If any of the above obligations and prohibitions are violated a fine is to be paid.
Figure 4: Case studyIn what follows we show the corresponding concrete syntax enabling the translation to natural andsymbolic languages: -- ClEng module (concrete syntax)lin KleeneActSI acti = {s = acti.s};KleeneActa kleenecompact and kleenecompact1 = {s = kleenecompact.s ++and.s ++ kleenecompact1.s};-- ClSym module (concrete syntax)lin KleeneActSI acti = {s = acti.s};KleeneActa kleenecompact and kleenecompact1 = {s = kleenecompact.s++ and.s ++ kleenecompact1.s};
In this section we apply our framework to a case study taken from [2] of a contract concerning thecheck-in process of an airline company. The full description is given in Fig. 4. We provide the detailedtranslation into restricted English, and the corresponding
C L formula for all the clauses. Note thatclause 10 is “distributed” among the others as it represent a penalty in case the other clauses are notsatisfied.1. The ground crew is obliged to open the check-in desk and request the passenger manifest twohours before the flight leaves (Fig. 4 first clause).6
From Contracts in Structured English to
C L
Specifications [Restricted English]: ( If (two hours before the flight leaves) then (It is mandatory to (open thecheck in desk and request the passenger manifest) if not (open the check in desk and requestthe passenger manifest) then (It is mandatory to (pay a fine)) ) ) [Program output]: ( [ ( two hours before the flight leaves ) ] ( O ( open the check in desk &request the passenger manifest ) ( O ( pay a fine ) ) ) )2. The airline is obliged to reply to the passenger manifest request made by the ground crew whenopening the desk with the passenger manifest [Restricted English]: ( (When) ( If (opening the desk with the passenger manifest) then (It ismandat ory to (reply to the passenger manifest request) if not (reply to the passenger manifestrequest) then (It is mandatory to (pay a fine))) )) [Program output]: ( [ 1 * ] ( [ ( opening the desk with the passenger manifest ) ] ( O ( re-ply to the pass enger manifest request ) ( O ( pay a fine ) ) ) ) )3. After the check-in desk is opened the check-in crew is obliged to initiate the check-in process withany customer present by checking that the passport details match what is written on the ticket andthat the luggage is within the weight limits. Then they are obliged to issue the boarding pass (Fig. 4third clause). [Restricted English]: (((After) (If (open the check in desk) then (It is mandatory to (check that thepassport details match what is written on the ticket and check the luggage is within theweight limits) if not (check that the passport details match what is written on the ticket andcheck the luggage is within the weight limits) then (It is mandatory to (pay))))) and (If (checkthat the passport details match what is written on the ticket and check the luggage is withinthe weight limits) then (It is mandatory to (issue the boarding pass) if not (issue the boardingpass) then (It is mandatory to (pay a fine)) ) ) ) [Program output]: (( [ 1 * ] ([(open the check in desk ) ] (O (check that the passport detailsmatch what is written on the ticket & check the luggage is within the weight limits) (O (paya fine ))))) ∧ ([( check that the passport details match what is written on the ticket & checkthe luggage is within the weight limits) ] (O (issue the boarding pass) (O (pay a fine )))))4. If the luggage weighs more than the limit, the crew is obliged to collect payment for the extraweight and issue the boarding pass (Fig. 4 seventh clause). [Restricted English]: ( If (the luggage weighs more than the limit) then (It is mandatory to (collect payment for the extra weight and issue the boarding pass ) if not (collect payment for theextra weight and issue the boarding pass ) then (It is mandatory to (pay a fine))) ) [Program output]:( [ ( the luggage weighs more than the limit ) ] ( O ( collect payment for theextra weight & issue the boarding pass ) ( O ( pay a fine ) ) ) ) ontazeri, Roy & Schneider [Restricted English]: (It is mandatory to (inspect that the details are correct beforehand) if not(inspect that the details are correct beforehand) then (It is prohibited to (issue any boardingcards) if (issue any boarding cards) then (It is mandatory to (pay a fine))) ) [Program output]:( O ( inspect that the details are correct beforehand ) ( F ( issue the boardingpass ) ( O ( pay a fine ) ) ) )6. The ground crew is prohibited from issuing any boarding cards before opening the check-in desk(Fig. 4 tenth clause). [Restricted English]: ( (Before) (If (open the check in desk) then (It is prohibited to (issue anyboarding cards) if (issue any boarding cards) then (It is mandatory to (pay a fine)) ) ) ) [Program output]: ( [ 1 * ] ( [ ( open the check in desk ) ] ( F ( issue the boarding pass ) (O ( pay a fine ) ) ) ) )7. The ground crew is obliged to close the check-in desk 20 minutes before the flight is due to leaveand not before [Restricted English]:( (Before) (If (20 minutes the flight is due to leave and not before) then (Itis mandatory to (close the check in desk) if not (close the check in desk) then (It is mandatoryto (pay a fine)) ) ) ) [Program output]:( [ 1 * ] ( [ ( 20 minutes the flight is due to leave and not before ) ] ( O (close the check in desk ) ( O ( pay a fine ) ) ) ) )8. After closing check-in, the crew must send the luggage information to the airline [Restricted English]:( (After) (If (close the check in desk) then (It is mandatory to (send theluggage information to airline) if not (send the luggage information to airline) then (It ismandatory to (pay a fine)) ) ) ) [Program output]:( [ 1 * ] ( [ ( close the check in desk ) ] ( O ( send the luggage information toairline ) ( O ( pay a fine ) ) ) ) )9. Once the check-in desk is closed, the ground crew is prohibited from issuing any boarding pass orfrom reopening the check-in desk [Restricted English]:( (Always) (If (close the check in desk) then (It is prohibited to (issue anyboarding pass or open the check in desk) if (issue any boarding pass or open the check indesk) then (It is mandatory to (pay a fine)) ) ) ) From Contracts in Structured English to
C L
Specifications [Program output]:( [ 1 * ] ( [ ( close the check in desk ) ] ( F ( issue the boarding pass + open thecheck in desk ) ( O ( pay a fine ) ) ) ) )The case above has already been analyzed using CLAN before and a conflict has been detected asreported in [3]. So, in this sense we do not report any new result here. We have used the same exampleas our intention is to validate our approach on a familiar case study when all the steps in our frameworkbe implemented (we are currently working on a full implementation of the framework).
GF has been used on a variety of application domains. We will only focus here on the one reported in [4]since it is closely related to our research. In such paper H¨ahnle et al. describes how to get a NL versionof a specifications written in OCL (Object Constraint Language). The paper focused on helping to solveproblems related to authoring well-formed formal specifications, maintaining them, mapping differentlevels of formality and synchronizing them. The solution outlined in the paper illustrates the feasibilityof connecting specification languages at different levels, in particular OCL and NL. The authors haveimplemented different concepts of OCL such as classes, objects, attributes, operations and queries in GF.Our work is similar to [4] with the difference that
C L is a more abstract and general logic allowing tospecify contracts in a general sense (as mentioned in the introduction
C L may formalize legal contracts,software specifications, contracts in SOA, or even be used to represent requirements). Besides we are notinterested only on “language translation” but rather in the use of the formal language to further performverification (in our case conflict analysis) which is then integrated within our framework by connectingGF’s output into CLAN. In what concerns the technical difficulties related to the implementation in GFwe do not have enough knowledge of the work done in [4] as to make a more careful comparison.From the perspective of relating a contract language and natural language, it is worth mentioning thework by Pace and Rosner [7], where it is presented an end-user system which is specifically designedto process the domain of computer oriented contracts. The translation is not based on GF but on acompletely different technology. They use controlled natural language (CNL) to specify contracts, anddefine a similar logic to
C L , which is embedded into Haskel in order to manipulate the contracts. So,the comparison is not straightforward as the aim of their work and ours diverges.
We have presented in this paper an encoding of the contract language
C L into GF, and back. We haveintegrated the above into a framework that allows to analyze
C L formulae for conflicts, and eventuallygive a counter-example in restricted English helping the user to find it in the original specification innatural language. As a proof-of-concept we have applied it to a case study which has already been usedfor conflict detection. The framework as presented here does not automate the whole process, though weare working on those parts as described below.We would like to emphasize what was said in the introduction concerning the scope of our approach.
C L is a formal language to specify contracts in a broad sense, and as such one should not think thatour work limits to the analysis of contracts in that language. As an abstract logic,
C L can be usedto describe and prescribe “contracts” (including specifications) in SOA, component-based developmentsystems, e-business, requirement engineering, etc. We believe the approach is useful in practice, the ontazeri, Roy & Schneider
References [1] D. Buscaldi, P. Rosso, J.M. G´omez-Soriano & E. Sanchis (2009):
Answering Questions with an n-gram based Passage Retrieval Engine . Journal of Intelligent Information Systems
Automatic Conflict Detection on Contracts . In:
ICTAC’09 , LNCS
CLAN: A Tool for Contract Analysis and Conflict Discovery . In:
ATVA’09 , LNCS
An Authoring Tool for Informal and Formal RequirementsSpecifications . In:
FASE , LNCS http://link.springer.de/link/service/series/0558/bibs/2306/23060233.htm . doi:10.1007/3-540-45923-5 16.[5] M. Forsberg A. Ranta. M. Pellauer (2004-09):
BNF Converter: Multilingual Front-End Generation from La-belled BNF Grammars . Technical Report, Technical Report 348, Computing Science at Chalmers Universityof Technology and Gothenburg University.[6] P. McNamara (2006):
Deontic Logic . In:
Gabbay, D.M., Woods, J., eds.: Handbook of the History of Logic ,7, North-Holland Publishing, pp. 197–289.[7] G.J. Pace & M. Rosner (2010):
A Controlled Language for the Specification of Contracts
Model Checking Contracts –A Case Study . In:
ATVA’07 , LNCS
A Formal Language for Electronic Contracts . In:
FMOODS , LNCS
CL: An Action-based Logic for Reasoning about Contracts . In:
WOL-LIC’09 , LNCS
Grammatical Framework: A Programming Language for Multilingual Grammars and TheirApplications .