FORS
Separating Configuration From Formal
Specification
Chiel Peters
chiel.peters@student.uva.nl August 20, 2014
Supervised by:
Centrum Wiskunde & Informatica
Software Analysis and TransformationTijs van der Storm
Internationale Nederlanden Groep (ING)
IT BankingHerbert van der Wetering & Joost Bosman
Universiteit van Amsterdam
Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering
specifically designed to allow domain experts to specify the behavior of a (new) product in an un-ambiguous manner. FORS uses a library design. The allowed generic behavior of the product line is formally specified in libraries. Building a specification then consists of combining and configuring generic behavior from these libraries. This separation of configuration and specification allows for division of labor. Domain engineers can create the libraries by domain modeling and domain experts can configure/create products without any intimate knowledge of formal specification.
The language uses Alloy, a lightweight model checker, to test the specifications. FORS requires as input a formal specification which describes the product, the pre- and postconditions of each event (operation) on the product and its invariants. The output consists of an Alloy model. In Alloy all combinations of possible events in a bounded scope are executed in order to test the product’s invari-ants. A benefit of FORS over Alloy directly is that it is also able to construct test cases (traces of operations) from the specification which can be used to test the implementation.
FORS was tested in a real world scenario, in the domain of savings accounts. In collaboration with ING the accounts were modeled and formally specified in FORS. FORS was able to find a scenario in which the positive balance invariant was violated. It showed how a series of events allowed by the specification led to a negative balance. The language however does not scale very well due to a lack of primitives within Alloy, more specifically in SAT. Satisfiable Modulo Theories (SMT), an extension to SAT, does include a larger set of primitives and could be used in further research to verify formal specifications.
Contents
1 Introduction 1 1.1 Contributions . . . 2 1.2 Organization . . . 2 2 Problem Analysis 3 2.1 Motivation . . . 3 2.2 Goals . . . 3 2.3 Terminology. . . 4 3 Formal Specification 5 3.1 Definition . . . 5 3.2 Necessity of Specification . . . 5 3.3 Criteria . . . 63.4 Advantages & Challenges . . . 6
4 Formal Specification Languages 8 4.1 Introduction. . . 8
4.2 Success Stories . . . 8
4.3 Languages . . . 9
5 FORS: Design 10 5.1 Introduction to FORS Specifications . . . 10
5.2 Library Design . . . 10 5.3 Configuration Parameters . . . 11 6 FORS: Specifications 12 6.1 Introduction. . . 12 6.2 Fields . . . 12 6.3 Functions . . . 12 6.4 Events . . . 12 6.5 Invariants . . . 14 6.6 A simple example. . . 14 7 FORS: Implementation 19 7.1 Architecture. . . 19 7.2 Mapping. . . 19 7.3 Primitives . . . 20 7.4 IDE Features . . . 21 7.5 Code Overview . . . 21 8 Savings Accounts 23 8.1 Domain Analysis . . . 23 8.2 Specification. . . 27 8.3 Results. . . 33
9.3 Interactivity. . . 37 9.4 Usability. . . 38 10 Discussion 39 10.1 Primitive Scope . . . 39 10.2 Prototyping . . . 39 11 Related Work 40 12 Conclusion 41 A Introduction to Alloy 42 A.1 Signatures . . . 42
A.2 Functions, Predicates, Facts and Asserts . . . 42
A.3 Traces . . . 43 A.4 Commands . . . 44 B Grammar of FORS 45 B.1 Specification. . . 45 B.2 Functions . . . 46 B.3 Events . . . 46 B.4 Invariants . . . 46
B.5 Expressions, Statements and Literals . . . 47
C Alloy Meta-models for primitives 50 C.1 Percentages . . . 50
C.2 Date . . . 50
C.3 Frequency . . . 51
C.4 Period . . . 51
D Alloy Specification Model 52 E Test Case Generation Algorithm 54 F FORS Specifications of ING savings accounts 55 F.1 Savings Accounts . . . 55
F.2 Models. . . 55
Chapter 1
Introduction
Within organizations there are typically two conceptual views on a single product even though there exists only one product specification. This is also the case for ING, a large dutch bank, which is the driver behind this research. The first view is from a business perspective which are the domain experts who communicate and think in domain terminology. The second view is from a developers perspective which are usually not familiar with the domain and have a more technical view. These two different views can lead to costly misunderstandings and incorrect implementations. This paper researches the communication problem and tries to answer the following question:
How to construct a specification language that allows domain experts to unambiguously specify the behavior of a product within a product line and formally test this behavior against predefined con-straints?
Specification defines the operations to be performed by the system. These operations are usually defined in a natural-language document. Natural-language is however not suitable for precise defi-nitions as it contains ambiguities and is subject to a number of other deficiencies ([Mey85]). These problems might become apparent to the programmers who will have to interpret them. Software developers have therefore resorted to formal specification in order to precisely define the operations of a system.
Formal specification expresses the operations of a system in a language whose vocabulary, syntax and semantics are formally defined ([Som06]). This way the system is expressed in an unambiguous manner and potential specification errors are discovered early. Another advantage is the possibility of automated tool support. Tools are able to formally test if certain properties of the system hold, generate possible counterexamples and generate test cases in order to find possible bugs in the actual implementation.
Even though formal specification seems to offer huge benefits and was seen as a necessity for soft-ware quality in the 1980s by many softsoft-ware developers ([Som06]) its use in practice is still limited. Currently its mostly used in the field of critical systems such as railway systems ([BBFmM99]), air traffic control ([Hal96]) and space craft systems ([ELC+98]). This is due to two reasons which are
discussed in the next paragraph.
In order to satisfy the formal definition of vocabulary, syntax and semantics formal languages most commonly resort to mathematical concepts such as set theory, logic and algebra. The mathematical notations of these concepts although unambiguous are not known to most software designers and can be quiet intimidating. The second reason is related to agile methodologies. Popular agile method-ologies such as Extreme Programming ([Bec00]) let design evolve with the code instead of defining it upfront. Time-to-market is also frequently favored above software quality.
To answer the research question FORS was created, a Domain Specific Language (DSL) for formal
specification of product lines. FORS has a library design pattern which allows the division of labor between the domain experts and developers. Generic behavior of products within the product lines are specified formally by the domain engineers in libraries. Domain experts can then configure and combine behavior (events) from these libraries to create new products. FORS uses the concepts described in Design by Contract ([Mey92]) in order to formally define the behavior of a product. In FORS each product specification consists of three elements:
• Fields. The fields express the properties or information contained within a product.
• Events. Events describe the possible operations that can be performed on the product. These operations are described formally using pre- and postconditions.
• Invariants. Properties of the system that should hold true for all possible states of the product. Using these three elements FORS is able to construct traces of events. These traces can either be used to find a counterexample for the provided invariants or as possible test cases for the actual im-plementation. FORS is based on Alloy, ([Jac02]) an automated model checker. The Alloy Analyzer finds traces of events that satisfy the constraints (pre- and postconditions). FORS parses these Alloy traces back into a more common format (JSON) to form test cases for the actual implementation of the system. Alloy can also be setup to look for counterexamples in order to find traces that lead to an invalid product state, a state in which a product invariant is false.
In this paper FORS is applied to a real world scenario. In collaboration with ING the domain of savings accounts is analyzed in FORS. After domain analysis and formal specification of the savings accounts FORS was able to find a scenario in which the invariant of positive balance does not hold. Although this scenario shows the potential of formal specification, the methodology does not seem to scale well. Especially the SAT Solvers which are used by Alloy seem incapable of handling primitives and larger numerical problems. A future possibility might be to be FORS on a more generalized SAT solver, SMT, which is capable of handling primitives and larger numerical problems.
1.1
Contributions
• A library based DSL which separates configuration of products from specification of its behavior within product lines.
• The use of formal specification in order to find errors in a real world case study of savings accounts.
• A feasibility study of using SAT solvers for formal testing of product specifications.
1.2
Organization
The remainder of this paper is organized as follows. The second chapter describes the problem and motivates why this topic was researched. Chapter three describes the necessity and challenges of product specification. Existing formal specification languages and their theorems are discussed in chapter four. Chapter five describes the key design decisions of FORS. In chapter six a FORS specification is discussed along with a simple example. The inner workings of FORS along with the basic metrics are stated in chapter seven. Chapter eight states the case study done in collaboration with ING, a major dutch bank, to formally describe their savings account products. Evaluation of the language is performed in chapter nine. A discussion of the limitations of FORS is presented in chapter ten along with possible solutions. Related work done in the domain of formal specification is described in chapter eleven. The final chapter twelve contains the conclusion of this paper.
Chapter 2
Problem Analysis
This paper was commissioned by ING. In this chapter the motivation and rationale behind the research and some of the early design decisions are discussed. The first section describes the motivation from ING’s perspective. In the second section the goals of the research are stated. The final section explains the terminology used throughout this paper.
2.1
Motivation
The current trend in banking is ’Personalized Banking’. Products are tailored towards the needs of the client and the client has a lot of options to choose from. However the development of new products or configurations of existing products is often plagued by the different perceptions between business and IT.
Within ING there are typically two conceptual views on a single product, one from a business perspective and one from an IT perspective. The business has dedicated personnel, so called product owners, which are responsible for their portfolio of products. They are the domain experts and often the source of change requests. However these conceptual differences in the two ways of thinking can lead to problems when altering product specifications or introducing new ones. For instance, the prod-uct owner is misunderstood and finds out at a much later stage that the prodprod-uct does not behave as expected or a product owner might want a feature that is not available in the current implementation. These misunderstandings can be costly and lead to an increased time-to-market which are both not desirable. Therefore ING is actively seeking towards a solution to solve this problem and create a better synergy between its departments.
2.2
Goals
The goal of this research is to find a way to increase the quality of communication between the domain experts and developers. The domain experts should be able to express the behavior of new products unambiguously. This avoids future misunderstandings and creates a medium through which both sides can confidently communicate.
In this paper a particular solution to solve the communication gap is presented, a domain specific language (DSL) called FORS. FORS allows domain experts to create new (or alter existing) product specifications from existing behavior in an unambiguous manner. To achieve unambiguously the DSL is based upon the concepts of formal specification. Formal specification is unambiguous and has the added benefit of being subject-able to analysis. One of the main focuses of this paper is also testing the product specifications. These concepts are explained in the next chapter.
2.3
Terminology
In this paper the terms products, product lines, specification, application engineer and domain engi-neer are used frequently. In this section the definitions of these terms are given
A product is often referred to a physical good or service sold to a client. However the product specifications of this paper will mainly serve as internal communication. Therefore products in the context of this paper relates more to business entities. These entities are abstractions of an element that is in the current business landscape. This does not necessarily have to be sold to the client, but can also refer to internal business entities such as user accounts. The product line is a higher level ab-straction which describes a family of products that share a common, managed set of features ([Wit96]). The specifications in this paper form descriptive models of the functional product requirements. These models can be seen as information models. They contain a representation of concepts, relation-ships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse which are used to communicate between the domain experts and developers ([Lee99]).
The term domain experts has so far been used to describe the business who is in charge of configuring or altering products. In the remainder of this paper the more technical term application engineer is used. When referring to the person who formalizes the behavior of the products into reusable components the term domain engineer is used in this paper. Developers in the context of this paper are the persons creating the actual source code implementation of the products.
Chapter 3
Formal Specification
In this chapter the necessity and challenges of formal specification are discussed. In the first section a definition of formal specification is given. The second section describes the necessity of specification and why requirements documents do not suffice. The criteria for a good specification are given in section three and finally section four explains the advantages and challenges of formal specification.
3.1
Definition
The word specification is overloaded as its both refers to the product and the process. Therefore the definition of formal specification is of a very generic form to allow for each of the possibilities [Lam00]: Formal specification is the expression, in some formal language and at some level of abstraction, of a collection of properties some system should satisfy.
The term system can here refer to numerous things, most notably: a descriptive model of the domain of interest and a prescriptive model of the software and its environment. The properties mentioned may relate to high level goals, functional requirements and non functional requirements.
In this paper the focus is put on functional requirements of descriptive models of the domain of interest. These types of specifications have received the most attention to this date. The purpose of these specifications is to communicate between business and the developers. The business, described by the title domain experts in this paper, are the ones with the domain knowledge. While the developers are the ones that have to implement the software products. The specification takes place between requirements and design and clarifies the requirements to enhance the value of the information being communicated.
3.2
Necessity of Specification
Specification is a phase often skipped in software development cycles. A common argument is that the natural-language descriptions from the requirements engineering phase are good enough as spec-ifications. However a study by Meyer ([Mey85]) showed that these descriptions are often filled with deficiencies. The deficiencies can be categorized into seven distinct cases which are given in table3.1. Meyer argues that even well-written requirements documents do not solve these problems and makes a strong point by showing an example of the requirements of a well-known text processing problem ([Mey85]).
Type Description
Noise The presence in the text of an element that does not carry informa-tion relevant to any feature of the problem. Variants: redundancy: remorse.
Silence The existence of a feature of the problem that is not covered by any element of the text.
Overspecification The presence in the text of an element that corresponds not to a feature of the problem but to features of a possible solution. Contradiction The presence in the text of two or more elements that define a
feature of the system in an incompatible way.
Ambiguity The presence in the text of an element that makes it possible to interpret a feature of the problem in at least two different ways. Forward Reference The presence in the text of an element that uses features of the
problem not defined until later in the text.
Wishful thinking The presence in the text of an element that defines a feature of the problem in such a way that a candidate solution cannot real-istically be validated with respect to this feature.
Table 3.1: The seven sins of a specification ([Mey85])
3.3
Criteria
There are certain properties a good specification must have. These properties coincide with the coun-terpart of the earlier stated deficiencies ([Lam00]). Each specified property of the system must have a meaningful semantic interpretation and be internally consistent (Contradiction, Forward Reference, Wishful Thinking) The specification should leave no room for multiple interpretations and therefore should be unambiguous (Ambiguity ). The specification should be minimal and not state irrelevant properties or properties of a possible solution for the problem (Noise, Silence, Overspecification).
3.4
Advantages & Challenges
Making a specification is essential for communicating, designing and validating domain models. Using formality the domain engineer can avoid the possible problems described in the section 3.2. It also has the added benefit of being subject-able to testing by automated tools. Although tools have been used for a wide variety of purposes ([Lam00]) in this paper the focus is put on the following purposes: • Derive premises or logical consequences of the specification, for user confirmation, through
deductive theorem proving techniques.
• Generate counterexamples against derived properties of the system. • Generate test cases from the specification.
Up till now it may seem like formal specification solves all problems related to domain models and their design. However formal specification has certain pitfalls of which the most important two are noted next.
CHAPTER 3. FORMAL SPECIFICATION
speaking to all involved parties in a language everyone understands, natural-language. Second, formal specification must contain an informal definition of how to interpret them in the domain of interest to be useful. This problem was presented by Zave et al. ([ZJ97]). A formalization contains terms and predicates. In order to state the meaning of these terms/predicates precisely one must map the term/predicate name back to functions/relations on domain objects. This mapping must be precise but can only be done informally to avoid infinite recurrence ([ZJ97, Lam00]).
Two other operational reasons why formal specification is not used more widely in practice are the formal language itself and the development process. Most formal specification languages are based upon mathematical concepts such as set theory, logic and algebra. These concepts have a steep learn-ing curve and are usually not not well known to either domain engineers or developers. The other operational reason is due to the current trend in software processes to agile methodologies. Agile methodologies let design evolve from the code. The idea of big design upfront in practice is perceived as ineffective and too costly. The focus of new software has been been put on time-to-market with the possible consequence of more bugs. Advocates state these bugs can be fixed quickly in new releases and design up front is wasteful as not all of the needed properties of the system can be known upfront. These operational pitfalls are however becoming less troublesome. New lightweight formal spec-ification languages do not require expertise of heavy mathematical concepts. These languages also allow for incremental design through modularity. The specification can, as with the requirements in agile methodologies, change incrementally over time. The next chapter will introduce these formal specification languages along with their theorems.
Formal Specification Languages
In this chapter multiple formal specification languages are discussed. For this paper several languages were considered. Some successful examples of formal specification are given in section4.2after a short introduction. The existing languages are described in the final section.
4.1
Introduction
Formal specification languages are typically divided into two categories: model-based and algebraic specification. The model-based approach is state-based and provides a model of a system’s state in terms of a collection of state variables ([Den96]). Operations describe how the system transfers from one state into the other. Preconditions of the operations state valid input, postconditions define out-puts after invocation and invariants are properties/constraints of the system which should hold true for all states. Popular model-based specification languages are Alloy ([Jac02]), Z ([Spi89]), B ([LH96] and OCL ([WK03]). Algebraic specification models the state of a system in sequences of operations required to be invocated to reach that state. Operations are defined in terms of other operations. The most common algebraic specification languages are Larch ([GH93]), Lotus ([ED89]) and OBJ ([JKKM88]).
In this paper focus is put on the model-based specification languages. These tools have received more interest in the past and are more mature. Also they better fit the purposes for the goals of this paper, modeling functional requirements of products in product lines. One major benefit is that model-based languages lead to a model of the product which is a valuable artifact for communication purposes.
4.2
Success Stories
Formal specification has existed since the late 1960s when Floyd, Hoare and Naur started the term specification as techniques to prove consistency for sequential programs at specific program states ([Flo67, Nau66, Hoa69]). Dijkstra showed how formal calculus can be used to construct programs that meet those specifications ([Dij75]). Since then formal specification has had numerous success stories, especially in safety critical systems. In this section a few of the most notable examples are given.
Matra Transport International has successfully developed an operating system called METEOR for railway systems using the formal B method [BBFmM99]. METEOR runs the first driver-less metro in the city of Paris. It is based on approximately 100 thousand lines of B code which are automatically translated to ADA for operational purposes. It covers software for all elements of the train system: on-board, control-center and on the tracks. METEOR was on time and within budget and automat-ically proved 92 % of the provided lemmas.
CHAPTER 4. FORMAL SPECIFICATION LANGUAGES
IBM and Oxford University have successfully used Z to restructure a complex transaction process-ing system CICS ([Kin93]). CICS is widely used in the world with applications in bankprocess-ing, airline reservations and insurance. The evolution of CICS had led to a complicated internal structure. Z was used to provide formal specifications for the parts that had to be rewritten or for new elements of the system. This amounted to several tens of thousands of lines of code. At that time (late 1980s) tools on Z were not mature enough to perform automatic analysis. A recent study by Fretias et al. ([FMW07]) used Z/Eves a tool to automatically analyze the code and found no major errors in the system when revising the specification.
4.3
Languages
In this section a few of the most popular model-based formal specification languages are described: 1. Z. The Z language is a formal notation for specifying and designing software. The language is
grounded in mathematics and all expressions are typed. Z uses a schema calculus, a language for schemas to define signatures and constraints. Although it is originally a non-executable language for proving system properties, many tools have been build for automatically processing Z specifications such as Z/Eves. Object oriented extensions such as Object-Z ([CDD+89]) and Z++ ([Lan91]) have been proposed to allow for inheritance and polymorphism which Z does not support.
2. B. B comprises of a language, Abstract Machine Notation (AMN), and a method for obtaining implementations from abstract models. It is mainly aimed at formal specification of large safety critical systems. In B preconditions are explicit and postconditions are viewed as substitutions. These substitutions change the state variables. It also makes the specification close to imperative languages and can therefore more easily be converted to general purpose languages ([Jac06]). 3. OCL. Object Constraint Language (OCL) is the constraint language of UML. A model is a
de-scription of state space, invariants and operations. The state space consists of classes, attributes and associations. Operations explicitly state pre- and postconditions and invariants implicitly. 4. Alloy. Alloy is a relatively new language that is based upon the three preceding formal
specifi-cation languages, especially Z. It is a lightweight formal language that relies on a small simple toolkit of mathematical concepts. The analysis of Alloy models relies on SAT technology. All models are converted to CNF format which are analyzed through an SAT-based constraint solver, KodKod.
FORS: Design
In the previous chapter existing formal languages were discussed. Some are very mature and have large user base, however none of them are suitable for the goals of this paper. The language is likely to hard for application engineers to use or understand. Although these languages are capable of describing product line behavior through inheritance the resulting specifications will be of low communicational value. This is because the source code will not be a valuable artifact for communication as it cannot be understood by the application engineers. Hence the decision was made to create a DSL called FORS. FORS is specifically designed for product lines. It has a library design that allows application engineers to configure new products from existing features. It uses two key design patterns that will be explained in this chapter.
5.1
Introduction to FORS Specifications
In FORS a formal specification of a product has to be build by the application engineer. A FORS specification consists of three elements: fields, events and invariants. Each specification corresponds with one product. These specifications can inherit from and encapsulate other specifications . The information contained within the product can be modeled by fields. The operations that can be performed on the product are called events. Invariants of a product capture properties which must be true in all states. A more detailed explanation of these elements is given in the next chapter.
5.2
Library Design
The domain of FORS is product lines. The products are often very similar and only have minor changes in behavior or configuration. Therefore in FORS a library design was chosen. Events, in-variants and functions are all stated in separate libraries. The library design creates a division of labor between the application engineers and the domain engineers. The domain engineers capture the generic allowed behavior of the products within the product lines by domain modeling and write these in the corresponding libraries. The application engineers can then create products by configuring and combining the components within the libraries.
This design still requires the initial translation of domain knowledge to fill the libraries. However after this initial phase application engineers can generate new products themselves from the existing behavior in the libraries. This step requires combining and configuring the elements inside the libraries and does not require any intimate knowledge of formal specification.A graphical overview of the library design in FORS is given in figure5.1.
CHAPTER 5. FORS: DESIGN
Figure 5.1: Library design of FORS. The relation in the figure shows the ’consists of’ relation between the components.
5.3
Configuration Parameters
Each product within the product line is different in one of the variation points. This can be expressed in FORS using the configuration parameters. Each FORS event consists of two different parameters that differ in binding time. The configuration parameters express the parameterization/configuration of the generic event for a specific product. The second type of parameters are the run time parameters. These parameters express external variables at runtime on which the event depends. The configura-tion parameters allow the applicaconfigura-tion engineers to configure/parametrize the variaconfigura-tion points in the generic behavior of the event. This allows different products within a product line to be made from a fixed set of events.
In example 5.1 a FORS event is given. This event simulates withdrawing money from a savings account. The configuration parameter in this event is penalty which is a penalty function. It measures the percentage penalty a user has to pay when he withdraws money from his account. This configuration parameter must be specified by the domain expert (or left to default) and is bounded when the specification is made. The second type of parameter is the run time parameter amount. It expresses how much the user wants to withdraw. This parameter is different for each user and situation and can only be bound at run time.
withdraw(Integer -> Integer penalty = noPenalty)
parameters : Integer amount
preconditions : this.balance[now] >= amount, amount > 0
postconditions : this.balance[now] == old this.balance[now]
-penalty[amount]
FORS Example 5.1: A simplified example of the withdraw event on savings accounts.
FORS: Specifications
6.1
Introduction
This chapter explains how to write a specification in FORS. It describes the elements of a FORS specification and explains the rationale behind them. Each specification models exactly one product. In order to describe this product there are three necessary elements: fields, events and invariants. Fields are used to describe the information contained within the product. The operations that are possible are expressed in events. Finally, derived properties which should hold are described in the invariants. Each of these subsequent section explains one of these three elements. The final section of this chapter contains a small example to illustrate how multiple specifications can be combined.
6.2
Fields
Fields are used to describe the information contained within the product. Fields can be compared to fields inside objects or classes in most general purpose languages. Out of these fields an Alloy signature (see AppendixA.1) is generated which acts as a data model for the product. The grammar of Fields is given in grammar6.1. The grammars of the individual components not explicitly stated, hField i and hTypei, are given in AppendixB.
hFieldDecl i ::= hField i : hTypei Grammar 6.1: Grammar for field declarations
6.3
Functions
In order to write more complex reoccurring statements FORS supports functions. Functions can receive arguments. Semantically, functions can be seen as placeholders for complex statements. They are directly translated into Alloy functions which have the same semantic meaning. Every function must specify its non-void return type. The grammar of Functions is given in grammar6.2. In the declaration of the hArgumentsi one of Rascal’s grammar features is used. This feature indicates that hArgumentsi is comma separated list of hArgument i.
6.4
Events
Events express the behavior of a product or more technically transitions on the product’s state. Events formally are equivalent to transitions from one state to another. Events consists of four parts:
CHAPTER 6. FORS: SPECIFICATIONS
hFunctioni ::= hFunctionNamei [ hArgumentsi ] : hTypei = hStatement i hArgumentsi ::= {hArgument i , }*
hArgument i ::= hTypei hVar i
Grammar 6.2: Grammar for function declarations
all products within the product line, however its parametrization is not. Therefore the specifier can give the parametrization of an event through the configuration parameters and leave the generic behavior in one event which can be reused.
2. Runtime Parameters. Most operations change from one state to another with respect to some external variables. An example is withdrawing money from a bank account. It changes the state by subtracting an amount from the balance. Here the amount can be seen as a runtime parameter.
3. Preconditions The conditions that need to hold before this event can be called. 4. Postconditions The conditions that hold after the event is called.
The grammar of events is given in grammar6.3.
hEvent i ::= hSignaturei hParametersi? hPreConditionsi? hPost i? hSignaturei ::= hLifeCyclePropertyi? hEventNamei ( {hEventArgument i, }* )
hEventArgument i ::= hTypei hVar i (= hExpr i)? hLifeCyclePropertyi ::= initial | ’final’ hParametersi ::= parameters : hArgumentsi hPreConditionsi ::= preconditions : hExprList i hPostConditionsi ::= postconditions : hExprList i
Grammar 6.3: Grammar for event declarations
The grammar describes the four parts explicitly. The grammar of hArgumentsi in hParametersi is given earlier in grammar6.2, hExprList i denotes a comma separated list of expressions. The grammar of the individual components not explicitly stated is given in AppendixB.
6.4.1
Product life cycle
Events can be of different types with regards to the product life cycle. Events can denote three types of operations: initial (open), modifying and final (close). These three types denote the life cycle of a product. This explicit modeling of initial and final allows for multiple ways of opening and closing which is usually the case for most products. In order to specify the type of an event, the user can write initial to denote that the event is an opening type or final to denote that the event is of a closing type. If nothing is specified FORS will assume the event of is of a modifying type. The current state of the product can be accessed through the opened field which is automatically generated by FORS. A initial (open) state is represented by a one and a final (close) state is represented by a zero.
6.4.2
Interactivity
In FORS it is allowed for domain objects to interact with each other. This can be achieved by encapsulation or extension. The life cycle state of another product can be accessed through the gen-erated opened field. A value of one indicates an open state and a value of zero indicates a closed state. A transition can be performed on a product by calling a special function called next. This tran-sitions the product to a new state using one of its events. Additional pre- or postconditions can be added inside the event of top level product to further restrict the transitions the encapsulated product can make.
6.4.3
Frame Problem
A common problem for formal specification languages is the frame problem ([MH69]). In postcondi-tions of events one wants to indicate the properties of the product that change and simply assume that all other properties in the product remain the same, hence the word frame. However the formal language interprets the not mentioned properties as unconstrained. In FORS any property not men-tioned in the postcondition of an event will stay equal. FORS first collects all different properties of the product and analyzes which properties are mentioned in the postconditions. For any property not mentioned a frame condition is generated in Alloy that states that the property must remain unchanged.
6.5
Invariants
Invariants state certain conditions of the system that should always be true. Invariants are useful for testing conditions which should hold from the constraints of the system. Alloy will in limited scope check if these constraints do imply the conditions in invariants. The grammar of invariants is given by:
hInvariant i ::= hInvariantNamei hInvariantDecl i hInvariantDecl i ::= hScopei* hExpr i
hScopei ::= hQuant i hDecl i | hQuant i ::= all | some | one | lone | no
hDecl i ::= hVar i : hExpr i
Grammar 6.4: Grammar for invariant declarations
An invariant consists of two parts: a scope which constrain the state space to certain domain objects with certain conditions and a condition (expression) which indicates the condition that should hold true for this scope.
6.6
A simple example
In this section a simple example is given to introduce the concepts of FORS to the reader. The example consists of a simple traffic junction with two traffic lights. The traffic lights can either be red or green. In this example there are thus two domain objects (traffic light and junction) which will be specified in the following subsections.
CHAPTER 6. FORS: SPECIFICATIONS
6.6.1
Traffic Light
The traffic light consists of one internal property, the color of the light. So using the fields the traffic light model can be expressed with one field variable color. For this example an integer will be used to represent red (0) and green (1). Note that another domain object color could be created however for the simplicity of this example an integer is used. The corresponding code is given in Example6.1.
Specification TrafficLight
Fields{
color : Integer
}
FORS Example 6.1: Modeling of Traffic Light
The life cycle of a traffic light is a very simple state diagram with three states and three state transitions. A graphical illustration of the state diagram is given in figure 6.1. Note that the open states in this case form a sink together and no final (close) transition is defined. In FORS the three transitions have to be modeled. In order to simplify the pre- and postconditions a function changeColoris defined. The function receives the integer representing the current color and flips the value to the other color.
Figure 6.1: State Diagram of a Traffic Light
changeColor[Integer color] : Integer = color == 1 ? 0; : 1; FORS Example 6.2: Function which returns the integer representing the new color
The three transitions can be declared as events. A traffic light does not need configuration of generic events and hence the configuration parameters are not needed. The source code for the events is given in Example6.3
# Initial event sets traffic light to red
initial initTrafficLight()
postconditions : this.color == 0
toggle()
postconditions : this.color == changeColor[old this.color]
unchanged()
FORS Example 6.3: Three events (state transitions) for a simple traffic light
For the initial event the keyword initial is used to indicate FORS that this event transitions from a closed state to an open state. A domain object starts in the closing state. In the closed state for the traffic light there is only possible opening transition initTrafficLight. Then there are two possible transitions either the traffic light stays red (unchanged) or it changes from red to green (toggle).
The event unchanged is not a real transition as it does not alter the internal state of the traffic light. It consists of no explicit pre- or postconditions and only contains one implicit precondition (through the default life cycle type) that the product must be in open state. Its a peculiar event that is necessary to indicate to Alloy that not each time step should result in a state transition. This is important when generating traces of events as it may occur that a state transition per time step is required/preferred for a product.
In events fields can be accessed and changed using the keyword this. this in the preconditions refers to the old state and this in the postconditions refers to the new state. If a reference in the postcondition must be made to the old state the user can write old this. In the event toggle the function declared in Example6.2is used. FORS declares these events and functions separately in libraries. These libraries can be used in the full specification. The specification of a traffic light is given in Example6.4. Specification TrafficLight Fields{ color : Integer } Events{ initTrafficLight() toggle() unchanged() }
CHAPTER 6. FORS: SPECIFICATIONS
6.6.2
Junction
The junction is a simple junction with two traffic lights. The constraint is that only one of the traffic lights can be green at any time. The junction is modeled by two events: an initial event that opens the state of the junction and a transition state that changes the color of the traffic lights. The model of the junction is given in Example6.5. Note that FORS supports importing other modules in the same folder by means of the keyword import.
import TrafficLight Specification Junction Fields{ left : TrafficLight right : TrafficLight }
FORS Example 6.5: Specification of the fields of a simple junction
There are two different events on a Junction which are given in Example 6.6. The initial state receives two traffic lights as Runtime Parameters. The precondition is that these traffic lights must be in an open state. The field opened is generated by FORS and can be accessed just as a field. This condition is necessary to insure that the traffic light are not in an unconstrained final (closed) state. Another precondition is that both lights must be red. The postconditions assign the traffic lights to the junction.
The changeJunctionState change the state of each of the traffic lights by the reserved function next. next uses the transitions found in the specification of the domain object and transitions (if possible) to a new state. In this example this means that next calls either of the two transitions toggleor unchanged. The postcondition of the junction constrain the two possible transitions of the two traffic lights, because only one of the traffic lights can be green at any time. The function amountOfGreensis given in Example6.7
initial init()
parameters : TrafficLight l, TrafficLight r
preconditions : l.opened == 1, r.opened == 1 ,
amountOfGreens[this.left,this.right] == 0
postconditions : this.left == l, this.right == r
changeJunctionState()
postconditions : this.left == next[old this.left], this.right == next[old this.right],
amountOfGreens[this.left,this.right] <= 1
FORS Example 6.6: Two events of a simple junction
amountOfGreens[TrafficLight t1, TrafficLight t2] : Integer = t1.color + t2.color;
FORS Example 6.7: Function which returns the number of greens for the two Traffic Lights In the invariants the extra constraint, only one green at the time, can be checked. Although for this example it follows trivially from the postconditions of the two events, the constraint will be checked any way for explanatory purposes. The invariant is given in Example6.8.
No2GreenLights{
all j : Junction | {amountOfGreens[j.left,j.right] <= 1} }
FORS Example 6.8: Invariant no two green lights at the same time
The full specification is then given by combining and configuring the events and invariants. Because both events on a junction do not have any Configuration parameters there are no variation points and no further configuration is needed. The specification is given in Example6.9.
import TrafficLight Specification Junction Fields{ left : TrafficLight right : TrafficLight } Events{ init() changeJunctionState() } Invariants{ No2GreenLights }
FORS Example 6.9: Full specification
Using this specification the user can formally test if the specification contains any contradictions or generate traces of events for testing purposes. The Alloy model that is generated by FORS from this specification is given in AppendixD.
Chapter 7
FORS: Implementation
In this section the implementation of FORS is discussed. FORS uses the meta-programming language Rascal ([SWA14]) as a host language for the DSL implementation. In section 7.1the architecture of the DSL is discussed. Section7.2contains the a high-level overview of the mapping from a FORS specification to an Alloy model. The third section discusses the primitives. FORS includes IDE features such as syntax highlighting and error checking which are further explained in section 7.4. The fifth and final section contains an overview of the source code.
7.1
Architecture
FORS translates its specification into Alloy, a mature formal specification language, using the meta-programming language Rascal ([SWA14]) as a host language. A short introduction of Alloy’s con-cepts is given in AppendixA. Rascal is build for source code analysis and transformation. Rascal programs typically take another language as input and are able to output source code in another language through the use of the Extract-Analyze-Synthesize (EASY) paradigm ([vdS11]). DSL im-plementation fits this paradigm very well. Rascal also support IDE features for DSLs such as syntax highlighting, outlining and a read-eval-print loop (REPL) through the Eclipse IMP meta-tooling framework ([CFJ07]).
The first step is the formal specification in FORS. The user has to build the specification which is explained in detail in the next chapter. The FORS specification is parsed in Rascal (Extract). This generates a parse tree which can be traversed (Analyze). The parse tree is transformed and Alloy code is generated (Synthesize). The user is redirected to the Alloy tool with the generated Alloy model from the FORS specification. Another possibility is the generation of test cases. FORS calls the Alloy API in order to generate solutions to the given specification. These solutions are traversed in order to obtain which trace of events has taken place. These traces are written in a common data format (JSON) and can be used as test cases for the actual implementation. A graphical overview of the architecture is given in figure7.1.
7.2
Mapping
FORS transforms a specification in its own language into an Alloy model. This section describes the mapping between the two models. Alloy , with the modeled primitives, supports all operations that are available within FORS. There is no semantic difference between the operations in the languages, only syntactically they are different. Therefore only the high-level language constructs are discussed in this section.
FORS specifications contain three elements: fields, events and invariants. The fields express the properties of a product and are mapped to an Alloy signature (see sectionA.1). An event which de-scribe certain behavior of a product in FORS is mapped to an Alloy predicate. Finally the invariants
Figure 7.1: An overview of the high level Architecture of FORS FORS Construct Alloy Construct
Fields Signature Attributes Functions Functions1
Events Predicates Invariants Asserts
Table 7.1: A mapping table between constructs in FORS and Alloy.
are mapped to asserts which is an Alloy command. An overview of the high level mapping is given in table7.1.
In the next chapter (section6.6.2) a complete example of a FORS specification is given. The Alloy model that is generated from this specification is given in appendixD.
7.3
Primitives
Alloy only has support for one primitive type, integers. Although it uses booleans internally it does not allow the user to explicitly use them. All other types are modeled through (abstract) signatures. For FORS this limited support for primitives is a problem as it would require the user to model primitives as domain objects. Therefore some primitives are embedded in FORS. These primitives are modeled in Alloy and support all the normal operations like addition, subtraction, multiplication when it makes sense:
• Dates. Dates are modeled as a triplet of integers representing day of month, month and year. 1Boolean functions form an exception. Since Alloy handles booleans internally and does not allow returning them
CHAPTER 7. FORS: IMPLEMENTATION
• Periods. Periods represent a certain period of time. Currently supported periods are : day, month, quarter and year.
• Frequencies. In order to indicate that some event occurs at a certain frequency the primitive frequency is used. Frequency supports the same time frames as Period, namely daily, monthly, quarterly and yearly.
• Percentages. In order to allow for real numbers the Percentage primitive is used. It consists out of a single integer representing a certain percentage.
• Booleans. A limited support is available for booleans. In FORS it is allowed to return booleans by functions2.
The meta-models of these primitives are given in appendixC.
7.3.1
Generation Axiom
Alloy is a declarative language and does not allow imperative constructs such as new to create new objects. It construct a set of atoms corresponding to the given constraints. Currently only Integer constants can be defined, however in our case constants from the modeled primitives must be available as well. To solve this problem the Generation Axiom is used.
In the Generation Axiom all the possible combinations of the modeled primitives within a given scope are generated. If the atom is generated first it can be accessed in Alloy through the use of functions. This has however the disadvantage that the scope tends to grow really fast and solutions take considerably longer. An example of the generation axiom for percentage is given in listing7.1. The fact indicates that for all integers available within the current scope the same percentage should be in scope as well. sig Percentage{ percent : Int } . . . fact Percentages{
∀ i : Int • one p : Percentage • i = p.percent }
Listing 7.1: Generator Axiom for the modeled primitive Percentage.
7.4
IDE Features
FORS is implemented in the meta-programming language Rascal ([SWA14]). It runs within the Rascal Eclipse IDE and includes basic IDE features such as syntax highlighting, folding and error checking. A screen shot of the IDE is given in figure 7.2. In the screen-shot an error is marked by the IDE. Event close2 could not be found in the event library and is marked as undefined. The IDE also contains a context menu for execution purposes. This menu allows the user to export the specification to an Alloy model or to generate a number of test cases from the specification.
7.5
Code Overview
This section contains an overview of the source code of FORS. FORS consists of just over a thousands lines of source code. It is mainly written in Rascal, but also contains components in Alloy and Java. Table 7.2 gives a detailed view of each of the components and their sizes. The largest component is the code generator which transforms FORS specifications into Alloy models. The miscellaneous component in Rascal consists of setting up the IDE and connecting the functionalities together.
2Any other use of booleans is however disallowed as it creates issues with the primitive booleans already present in
Alloy
Figure 7.2: Screen-shot of the IDE for FORS.
Component Implementation Size (SLOC)
Grammar Rascal 163
Error Checking Rascal 57 Code Generator Rascal 419 Miscellaneous (e.g. IDE) Rascal 134
Primitives Alloy 218
Test Case Generation Java 194
Total - 1185
Chapter 8
Case Study: Savings Accounts
In chapter6a simple traffic junction example was specified in FORS. The purpose of this chapter is to test FORS in a real world scenario. ING is currently rationalizing its software production process. Their software is a critical financial system and potential bugs or mis-specifications can be very costly. In consultation with ING the scope was determined to be savings accounts.
The goals of the case study are to formalize the specifications, find possible errors through in-variants and generate test cases which can be used by the actual implementation. The goal is not to replace the current implementation as it is, although this could technically be achieved in the future. In the first section of this chapter the results of a domain analysis on savings accounts are stated. The second section contains the specification in FORS. The third section expresses the results of formalizing and checking the specifications.
8.1
Domain Analysis
In this section the domain of savings accounts is analyzed. A good understanding of the domain is key when developing the specification. This allows for the right abstractions and ultimately leads to well designed specification. In order to properly analyze the domain the methodology of Feature Oriented Domain Analysis (FODA) is used as a guideline. This methodology is further explained in the next section. Thereafter each subsection contains the results of a phase in FODA.
8.1.1
Feature-Oriented Domain-Analysis (FODA)
FODA is a method for describing and representing commonalities among related products or systems within a certain domain [KCH+90
]. The primary focus of FODA is to identify features of the products within the domain. It consists out of three phases:
• Context Analysis. In the context analysis the scope of the domain is defined. This scope consists of products that have a common set of features. Another purpose of the Context Analysis is that the variation points of the products within the scope are evaluated. This results in a context model which defines the boundaries of the domain.
• Domain Modeling. The commonalities and differences from the context analysis are used to form different models representing different aspects of the domain.
• Architecture Modeling. In the architecture modeling phase a solution is made in the form of a architecture model which detailed design and component construction can be done.
The formal process of each phase is not performed step by step as not every step is relevant to the goals of this case study. Therefore FODA will be used more as a guideline. The Architecture Modeling phase is not applied, because at the end of the Domain Modeling phase already enough
information was available to describe the specification. Also the Architecture Modeling phase is more concerned with the software implementation which is out of our scope.
8.1.2
Context Analysis
The context analysis is the first part of FODA and establishes the scope of the domain. Another goal of context analysis is to analyze the differences and commonalities between the products in the domain. The domain consists of all savings accounts however for modeling purposes only the ING savings accounts will be inspected. The assumption is made that ING savings accounts are representative for the full domain of savings accounts.
Scope
The scope consists of all savings accounts within ING. This consists out of 17 products that are currently available at ING. These products are placed into three categories: private, preferred banking and business. The products are shown in Figure8.1
CHAPTER 8. SAVINGS ACCOUNTS
Commonalities
The domain consists of savings accounts which share a number of commonalities. In this section these commonalities are discussed:
1. Positive balance. A savings account is purely meant for savings and cannot be using for lending purposes. Therefore each of the savings account cannot be overdrawn and get a negative balance. 2. Interest rate. The bank pays interest over the balance you have on your account. That is each time frame you have a positive balance the bank pays a percentage of this balance as interest. 3. Direct payments. A savings account is meant for saving purposes and not for regular spending.
Hence a savings account can not be used for direct payment in for example stores or on-line. The savings accounts are coupled with a regular bank account and the money can only be transferred from and to this regular account.
Differences
The savings accounts also contain some distinct differences which are covered in this section: 1. Interest rate payments A key difference between the savings accounts is the amount and behavior
of the interest rate payments. These differences are:
(a) Disks. The interest rate percentage is dependent on the balance of the savings account. Specifications contain one or multiple ’disks’ that assign different percentage depending on the balance. There are however exceptions to this disk rule which are discussed next. (b) Bonus rente. Some savings account contain additional behavior on interest rate payments
for instance the ’bonus rente’. If the balance is higher than the balance of last year on the reference date then an additional percentage is paid.
(c) Payout dates. Although the standard is that interest is paid once a year certain savings account alter this rule to quarterly.
(d) Maximum. To avoid huge interest payments banks put a maximum on the amount on which interest is received. The business and preferred banking savings accounts have a considerably higher maximum compared to the private savings accounts.
2. Withdrawal and deposits. Some savings account have restrictions on withdrawals and deposits. In the most extreme case no withdrawals and deposits can occur unless for exceptional reasons (e.g. death). Another possibility is that of a penalty in the form of fixed or variable fee depending on the amount that is withdrawn. This penalty can be 0 in which case the holder of the savings accounts is free to withdraw and deposit.
8.1.3
Domain Modeling
In the domain modeling the emphasis is put on understanding the capabilities of the products in the domain. This is done by building models that capture these capabilities such as services, performance, hardware platforms and cost. In this section the focus is put on the services provided by the products or more commonly described as features of the products. FODA advocates the use of a feature models which are discussed in the next section.
Feature Model
A feature model describes the set of standard features of the products in the domain and the re-lationships among these features. The model describes the consists of relationship and identifies a logical grouping. The differences between the products within the domain can be specified by optional features that are present in some products but not all. The feature diagram of savings accounts is shown in Figure8.2. The feature diagram besides the internal components shows the major events.
Each of the elements in the feature diagram are discussed next:
Figure 8.2: The feature diagram of a saving account
1. Frequency. The frequency of interest rate payments (e.g. yearly, quarterly)
2. Interest rates. The multiple interest rates that are applicable to a particular savings account. 3. Balance. The amount on the savings account.
4. StartDate. The start date of the savings account. This is the date on which a client opens the account.
5. Term. The pre-specified term for the savings account. This is only for the savings account with fixed interest rate as the contract usually involves a fixed term.
The feature diagram also contains the behavior of the two most important features of a savings account:
1. Calculate interest rate. One major feature of every savings account is the behavior of interest rate payment. This behavior can be split into two categories: fixed and variable interest rate.
(a) Fixed In fixed interest rate as the name implies the interest rate is fixed and known upfront for the whole period 1.
(b) Variable The variable interest rate is the most common case among savings account. The interest the holder receives can be based on a multiple factors or rules as they are described next.
i. Rules The interest rate depends on several factors these can be described using expres-sions and rules. The use of rules in feature diagram to describe behavior was presented by [VV11].
2. Deposits & Withdrawals. The ability to deposit and withdraw can be restrained depending on the type of account. Especially with fixed savings accounts withdrawals and deposits are usually penalized.
(a) Rules. The rules governing the ability to withdraw and deposit money from the savings account. These rules use the same elements as the variable interest rate calculation rules.
CHAPTER 8. SAVINGS ACCOUNTS
The feature diagram and the specified behavior can be used to create a specification. This is the topic of the next section.
8.2
Specification
In this section the implementation of ING savings accounts in FORS is discussed. In this example only savings accounts are taken into account. There is no notion of a current account or user. There-fore some constraints can not be stated2
. FORS does allow domain objects interactivity however a separate domain analysis would need to be performed on these objects. Although this scope is limited, the example is still big enough to find errors in the ING specification.
The first subsection contains the modeling of the savings accounts using fields. The second sub-section defines functions which express common complex formulas. The events are specified in the third subsection. The fourth section contain the invariants and finally a full example of one savings account Top Rekening is given in section five.
8.2.1
Fields
Using the feature diagram defined in section8.1.3the model of a savings account can be made. The diagram displays five different elements of which one is optional. Although two different models can be made to account for this optionality the choice was made to make one. The optional field term can be set to infinity without losing its semantic meaning. The interest rates are currently not modeled as a field but stated explicitly as a configuration parameter for the associated event interest. The model of savings account in FORS is given in Example8.1.
Specification SavingsAccount
Fields{
balance : Date -> Integer
term : Integer
startDate : Date
interestFreq : Freq
now : Date
}
FORS Example 8.1: Modeling of a savings account using fields
An extra field was added to the savings account model to keep track of the current date. Although nowis not really a element of savings accounts it is needed later on to describe the global state. now describes a part of the global external state and could have been modeled in a separate domain object. However for simplicity reasons this is added to the state of the savings accounts.
8.2.2
Functions
There are three different categories of functions needed to describe savings accounts: date, interest rate and penalty functions. The functions are shown in Example8.2. In order to determine if a date is an interest payment date the function isPayOutDate is declared. This function receives the current date, the payout date3and the payout frequency.
Interest within ING is always paid using the same formula given in equation8.1. 2An example of such a constraint is that a business account can only be opened by a business user
3Depending on the frequency only parts of this date will be relevant. For instance for yearly frequency, the year of
the payout date is irrelevant only the day and month are required.
interest = now X d=now−f balance(d) · r daysinyear(d) (8.1)
In the equation f denotes the frequency, r the interest rate and daysinyear(d) the number of days in the year (365 or 366). The implementation of this formula is given in the function interest. There is one slight alternation to this formula for the account Bonus Rente Rekening here the user receives a bonus rate if his balance is higher or equal compared to the balance on the previous payout date. The implementation of this conditional is given in the function interestBonus.
The final category for functions is penalty functions. In some accounts it is penalized if the owner withdraws or deposits money. ING uses a penalty on its fixed savings accounts depending on the remaining years left. The function noPenalty is given to describe that their is no penalty (0 %) and the function penalty implements the penalty scheme implemented by ING for fixed savings accounts.
################################################################ # Date Functions
################################################################
isPayOutDate[Date date, Date payoutdate, Freq freq] : Boolean =
case freq {
Daily => True;
Monthly => date.days == payoutdate.days;
Quarterly => date.days == payoutdate.days && (payoutdate.month
-date.month) % 3 == 0;
Yearly => date.days == payoutdate.days && date.month == payoutdate.month;
};
################################################################## # Interest Rate Functions
##################################################################
interest[Integer maximum, map[Integer : Percentage] interestRates,
map[Date : Integer] balance, Date start, Date end] : Integer =
sum(min[balance[date],maximum]*interestRates.get[balance[date]]/
daysInYear[date] | date <- {start ... end});
interestBonus[Integer maximum, map[Integer : Percentage] interestRates,
Percentage bonusrate, map[Date : Integer] balance, Date start, Date end] : Integer =
balance[start] <= balance[end] ?
sum((min[balance[date],maximum]* (interestRates.get[balance[date]]+
bonusrate))/daysInYear[date] | date <- {start ... end}); : interest[maximum,interestRates,balance,start,end];
################################################################## # Penalty Functions for Withdrawal and Deposits
##################################################################
noPenalty[Integer yearsLeft] : Percentage = 0%;
CHAPTER 8. SAVINGS ACCOUNTS
8.2.3
Events
Within ING over a number of clusters 119 events are described on savings accounts. These events describe what a user is allowed to do with his savings account. Most of these events fall under one of the following categories:
1. Open. There are multiple ways to open a savings account, for example on the web, telephone or through a physical office. Some accounts have constraints on the medium as they require preprocessing of information in order to determine if the client is eligible for the account. 2. Withdraw/Deposit. Accounts with fixed interest and terms usually define constraints on
with-drawals and deposits. Either it is completely disallowed or a penalty function is applied. These penalty functions are specified in Example8.2.
3. Inquire. Accounts contain a lot of information and also derived information. In order for the client to access this information he has to initiate an inquire event. An example of this is accrued interest or transaction information.
4. Maintenance. This can be seen as maintenance from the client’s and business perspective. From a client’s perspective this includes events such as changing home address and nickname. From a business perspective this includes events such as blocking/unblocking and capital/interest corrections.
5. Close. Accounts with fixed interest and terms usually include a contract period. Closing before the contract has ended is either disallowed or penalized the same way as with withdrawals and deposits. However in certain circumstances this penalty is waived (e.g. death or unemployment). Also closure of some accounts may lead to tax related issues leading to other behavior than a normal close.
In this case study the Inquire and Maintenance events are left out of scope as they do not change the state of a savings account in the case of the former or alter a portion outside of the scope in the case of the latter. As mentioned earlier some constraints can not be expressed fully as they rely on objects out of the scope of savings accounts, therefore the number events is reduced. In the following subsections these categories are discussed.
Open & Close
This section contains the events related to open and close transitions. In these events a division of two kinds of savings accounts can be observed: variable and fixed interest. These two types are also indicated in the feature diagram defined in section8.1.3. A fixed account has two extra specification parameters: term and payout frequency. At runtime the client can choose which payout frequency he wants4. Besides the regular close event there are also three specific other close events: cancelopen
allows the client to cancel a recently opened fixed savings accounts, closeAfterDuration closes a fixed account if the contract term has expired and forcedClose allows ING to close an account which has a balance below the required minimum. The events are given in Example8.3. Most closing events do not contain postconditions as the postcondition that the account is closed is generated by FORS because of the final keyword.
4The higher the payout frequency the lower the interest. This penalty is not implemented because the penalty is
expressed in percentage points which are to small to be expressed in FORS.
