A Tale of Two Case Studies: Using Integrated Methods to Support Rigorous Requirements Specification

Integrated formal and informal speci cation techniques (FISTs) have been the focus of a number of research projects since the mid-eighties. Research in this area aim at producing speci cation techniques that integrate concepts and notations used in mature formal speci cation techniques (FSTs) and popular graphical modeling methods such as Structured Analysis (SA) and Object-Oriented Analysis (OOA). In this paper we illustrate, using the results of two case studies, two roles FSTs can play in the context of less formal graphical requirements modeling and analysis techniques. In the rst case study discussed an extended Petri Net model is used to prototype a textbook SART (SA/Real-Time) model. In this case, the formal model acts as a prototype, and is used to dynamically validate the requirements expressed in the SART model. In the second case study an integrated OOA method (Fusion) and FST (Z) is used to create requirements models that are graphical and analyzable. In this case, the formal models act as more precise representations of the requirements captured by the graphical models.


Introduction
Software requirements engineering is concerned with the systematic analysis and specication of software requirements. One can view requirements engineering as a systematic approach to problem analysis and specication, where the goal is to obtain a precise statement of the problem in terms of goals that must be met by the implemented system.
The graphical model-based techniques of Structured A nalysis (SA) and Object-Oriented A nalysis (OOA) (henceforth referred to as informal specication techniques (ISTs)) can provide the exibility (in terms of ease of change) and modeling constructs needed to explore appropriate abstractions for problem concepts. On the other hand, the lack of rm semantic bases for these methods limits their eectiveness in validation and subsequent v erication activities.
The need for precision suggests the use of formal specication techniques (FSTs). FSTs utilize mathematical concepts and notation to precisely dene theories and models of application behavior. Precise specications facilitate eective communication among persons with a stake in the development of the software. The ability to reason about properties captured in formal specications allows developers to rigorously assess the adequacy of their models.
FSTs and ISTs can complement each other in a software development project. For example, variants of the SA method [6] are among the most widely used requirements specication and analysis methods in industry. Their simple, intuitively-appealing specication concepts and notation are major factors behind This work was partially funded by NSF grant CCR-9410396. their popularity. On the other hand, the lack of a rm semantic basis for SA models severely inhibits their use as bases for further development, in particular, their use as major references against which the quality and applicability of implementations can be assessed. The lack of a rm semantic basis also means there is little support for rigorously reasoning about specied properties, thus limiting the use of the models in analyses of desired behaviors. These problems can be alleviated by replacing informally specied parts of SA models (e.g., data descriptions and process specications) with formal specications. The inclusion of formal specications in SA models facilitates a level of rigorous analysis not attainable in the less formal expressions of SA models.
A signicant amount of research on the technical aspects of integrating FSTs and ISTs has taken place. We refer to such i n tegrated techniques as FISTs. Surveys of some these research eorts can be found in [11,15]. In this paper we illustrate, via the results of two case studies, two w a ys in which FSTs can complement and enhance the application of ISTs in the requirement engineering phase of development. In Section 2 we describe the major results of a case study in which a formal model was used to prototype the required behavior captured by informal, graphical models. We developed a formal operational model, in the form of an extended Petri Net, for a textbook SART (SA/Real Time) [14] model of a vending machine. Using the insights gained from building and exercising the operational model we w ere able to improve the SART models (i.e., make them more accurate and informative). The development of the formal model was done in a generative s t yle, that is, a rigorously dened relationship between modeling concepts was used to guide the transformation of the SART model to the extended Petri Net model [19].
In Section 3 we describe a case study in which a n i n tegrated Fusion [5] and Z [17] FIST was used to develop a rigorous OOA model of a student advising system. The Z models we produced supplemented the OOA models, that is, both the OOA models and the Z models are needed to get a complete picture of the modeled behavior. The FST in this case was used to make more precise the concepts captured by the OOA model. Section 4 contains our conclusions.

The SART/Petri Net Case study
The goal of the SART/Petri Net case study was to rigorously analyze an SART model of the vending machine problem taken from the book by Hatley and Pirbhai [14]. The analysis was done by building and exercising a formal operational model of required behavior as modeled by the SART model. The operational model can be viewed as a prototype, or an executable formal model of behavior, and as such, it contains implementation details not present in the SART model. For this reason, the formal and the informal models are at dierent levels of abstraction. The operational model was created using an extended form of Petri Nets [19].
This case study illustrates how executable formal models can be used to enhance the application of informal requirements modeling techniques. The experience outlined in the following subsections indicate that building and exercising the prototype can yield insights that can be used to make the informal models more accurate and informative.
For this approach to be eective there must be some assurance that the formal model captures the behavior abstractly described in the informal model. We provide a basis for such assurance by imposing an operational semantics on the SART model and dening a relationship, based on the semantics, between the modeling concepts used in the SART and the Petri Net techniques. The dynamic semantics we impose on SART models is based on our experiences with the use of such models in student projects and a particular industrial application. We are not claiming that our semantices reects the most common interpretation (if one exists!). We suspect that industrial applications of SART techniques are based on a variety of (often implicitly dened) interpretations that may suit the particular domain in which the SART techniques are applied. In this paper, our intent is to illustrate the benets of explicitly dening a formal semantics for SARTs.
In the subsections that follow w e dene the relationships and show h o w it can be used to transform a SART model to an executable extended Petri Net model.

Modeling requirements with SART
The SART requirements modeling techniques extend the applicability of traditional SA techniques to realtime, reactive systems. An SART requirements model consists of the following major components: Data ow diagrams (DFDs) model systems in terms of data ow dependencies between processes (also called data transforms). A DFD can be viewed as a structural model of the functional aspects of a system. Process specications are informal processes descriptions depicted in DFDs. Control ow diagrams (CFDs) model control dependencies between processes. CFDs depict the control signals that aect the state of a system and the behavior of DFD processes.
Control specications describe how control ows aect the state and hence the behavior of the system.
In this paper, the specications are expressed in terms of state transition diagrams. The vending machine is constrained to behave as follows [14]: 1. Only nickels, dimes, and quarters are to be accepted as valid contributions to a payment. All other objects are rejected (rejected objects are called slugs). 2. Payment computation and product selection can only be activated after a valid coin is detected. 3. Coins must be returned and the customer notied if a selection is not available. 4. Product prices must be changeable. 5. Return the customer's payment on request if he or she decides not to make a selection. 6. A product can only be dispensed if it is available and the payment is sucient. 7. Disable product selection after the product is dispensed and until the next validated coin is detected.  Figure 1: SART model of the vending machine problem A combined at DFD and CFD model of the vending machine system, derived from the hierarchical DFD and CFD models given in [14] i s s h o wn in Fig. 1(a). The round-edged boxes represent processes, the solid arrows represent data ows, the dashed arrows represent control ows, and the parallel bars represent data stores. Fig. 1(b) shows the state transition diagram describing how the control ows aect system states.
In the state transition diagram, states are represented by rectangular boxes, and a state transition from state Si to state Sk (i 6 = k), resulting from the occurrence of an event represented by the control ow c, i s described by a labeled, directed arrow going from Si to Sk. The label on the arrow consists of the control ow's name above a horizontal bar and a list of processes that are activated and/or deactivated as a result of the transition below the bar. For example, the generation of the sucient payment signal causes the system to change state from S2 ( Waiting For Selection) t o S 3 ( Dispense Product), and also causes the activation of the processes Dispense Change, Clear Payment and Dispense Product, and the deactivation of the process Get Valid Selection (the process specications are not given here because of page constraints). The SART model for the vending machine is typical of the type of description produced by the SA techniques. It utilizes simple graphical constructs to build an intuitively-appealing structure, and is supported by informal descriptions of processing and data details that are not depicted in the diagrams. While the techniques may be appropriate problem structuring aids, the lack o f a w ell-dened semantics for the models produced makes it dicult to analyze specied behavior rigorously.
Development of the formal operational model from the SART model proceeded as follow: 1. With the help of formal transformation rules, an Extended Petri Net (EPN) structure was obtained from the SART model. 2. Algebraic type specications for data elements described in the SART model were dened. 3. Denition of the EPN was completed by dening behavior of processes in terms of transition ring and data transformation rules. 4. The EPN was then converted to a machine executable form called Cabernets [16] and exercised.

An extended Petri Net model
The Extended Petri Net (EPN) model is based on the Modied Petri Net model proposed by Y au and Caglayan [19]. The EPN consists of a set of places, a set of data objects, and a set of transitions. T ransitions are connected to each other through places and data objects. The EPN incorporates data ow in regular Petri Nets; therefore, it can be used to specify both functional and control aspects of a system.
The function M takes a place and returns its marking (i.e., the numb e r o f t o k ens in the place). A place p is said to be enabled if M (p) > 0 and disabled if M (p) = 0. If there is a place, p, in an EPN for which M (p) > 1 then the EPN is said to be in an unsafe state; normal (or safe) behaviors must be modeled in terms of markings of 0 and 1.
Formally, an EPN transition T is represented by the 5-tuple T = ( I ; O ; D ; F ; G ) where I and O are the set of input and output places, respectively, D is the set of data objects, and F and G are the control transfer specication (CTS) and the date transfer specication (DTS) of the transition, respectively. There are two t ypes of data objects (i.e., elements of D): data variables and stores. An input (data) variable has its contents removed during transition ring, and an output variable has its contents replaced during transition ring. A variable whose data item has been removed is associated with the value empty. A store contains data that persists over the executions of transitions. Execution of transitions may i n v olve reads and/or updates of associated stores. F consists of an input place specication and an output place specication. An input place specication denes precisely the input place states that initiate the execution (ring) of T. An output place specication denes the change of output places after execution of T. Predicates associated with output places have the same function as those used in Predicate/Transition Nets [12], that is, an output place receives a token (as a result of transition ring) only when the predicate associated with the corresponding link is true. An output place associated with a link that is associated with a predicate true receives a token as a result of each transition ring.
Data transfer specications (DTSs) are expressed in terms of operations dened in algebraic specications [13] of the data types associated with the system being modeled. The specications abstractly dene data types in terms of operations that can create and manipulate instances of the types. Some types are considered primitive, that is, their denition is provided by the modeling language. Examples of such t ypes are the integer type (denoted by Z), natural numbers (denoted by N), and character.
For convenience, an EPN can be partitioned into two subnets: one for data ow (referred to as the D-EPN) and the other for control ow (referred to as the C-EPN). See Fig. 3 for an example of an EPN.
Execution of an EPN is based on the following transition ring rules: If the input place condition specied in a transition's control transfer input specication holds, then the transition is said to be enabled. A transition res immediately when enabled, and the output result is observable instantaneously. On ring, tokens in the input places of the transition are removed. The eect of the transition's execution on the output places of the transition is determined by the output specication given in the transition's CTS.
When a transition is executed the eects on the data variables and stores associated with the object are determined by the Data Transfer Specication (DTS).

Guidelines for transforming SART models to EPNs
Below w e give the set of rules we dened to support the systematic transformation of SART models to EPNs (these rules are depicted in A data transform is represented by a transition (called a process transition), a data store by a store, and a data ow is associated with a place and a variable (the place indicates the occurrence of the data ow while the variable gives the content). A data ow a from a process P1 to another process P2 in a DFD is modeled in an EPN by connecting process transition P1 to process transition P2 via a place (used to indicate the occurrence of data on a) a n d a v ariable (holds the contents of a). This relationship is depicted in Fig. 2(a). 2. A data ow from a process P1 to a data store DS is represented by an EPN in which transition P1 is connected to a store data object as input and output (see Fig. 2(b)). The input arc connecting the store to the transition is needed to access the initial state (state before ring) of the store.

3.
A data ow from a data store to a process is represented by an EPN (see Fig. 2(c)) in which the process transition is connected to an input store data object. In this case, the state of the store after execution is the same as the state before execution. 4. A data ow from an external entity to a process is modeled in an EPN as a process transition connected to an input place (used to indicate the occurrence of the ow) and an input variable (see Fig. 2(d)). 5. A data ow from a process to an external entity is modeled as a process transition connected to an output place (used to indicate the occurrence of output on the data ow) and an output variable (see Fig. 2(e)). 6. The EPN model of the eect of control ows on the behavior of a system is obtained using information contained in the CFD and the associated state transition diagram (STD). Each state transition depicted in an STD is represented by an EPN structure. For example, consider a state transition from state S1 t o S 2 resulting from the occurrence of a control ow, c, generated by a process P, that causes the activation of process P1 and the deactivation of process P2 (see Fig. 2(f)). The control ow c is modeled by a place connecting the process transition P (to which it is an output place) to the transition ST representing the state transition (to which it is an input place). The state S1 is represented as an input place to ST and the state S2 is represented as an output place of ST. The transitions associated with P1 and P2 are associated with places e P1 and e P2, respectively, that are connected to ST. A token in these places indicates that P1 and P2 are enabled. The place e P1 is connected to ST as an output place, indicating that P1 is enabled by the transition, and e P2 is an input place to ST, indicating that P2 is disabled by the transition. The input specication (not shown) indicates that ST will re whenever there is token in the place c. The result of the ring depends on whether there is a token in S1 or not. If there is no token in S1 (indicating that the system is not in state S1) then only the token in c is consumed (if there is a token in e P2 it is not consumed) and no output tokens are produced (in other words, signals do not wait for the system to reach a state in which it has an eect; this is an example of an interpretation that may v ary across uses of SART -some situations may require signals to wait for the state to occur, in which case this particular ring of the transition will not occur). If there is a token in c and in S1 then the transition res and puts a token in e P1 and in S2, and, if there is a token in e P2 before ring, it is removed. Using transformation rules 1 to 5, a D-EPN structure is obtained. The D-EPN structure for the SART vending machine model is shown in Fig. 3. The generation of the D-EPN structure can be automated. The DTSs cannot be generated automatically from informal natural language process specications and must be created by the modeler. The modeler can use the informal specications as guides in their development o f more formal specications of data transfer.
The C-EPN is developed using rules 1 to 6. The initial state of the C-EPN obtained for the vending machine problem is shown in Fig. 4.
In the C-EPN, the place label`dn' is an inhibitor place for transition`n'. Place labels starting with`c' in Fig. 4 represent conditions (control ows). Tokens in these places indicate that the associated conditions hold (e.g., a token in c1 means that a coin has been detected). Place labels starting with`s' represent states. A token in the following places indicates that the system is in the associated state: s1: Idle state. s2: Waiting for selection. s3: Dispense product.
The transitions labeled`STn' represent state changes. For example, the state change resulting from the occurrence of the event coin detected in the Idle state is represented by the state transition ST1.

Analyzing the EPN model
An EPN obtained from an SART model can be viewed as a formal operational interpretation of the SART model. The interpretation can be used to`test' the model against the stated requirements by simulating  As pointed out in the previous subsections, a data ow is associated with both a place and a data variable. The place is used to model the occurrence of data on the ow and the variable holds the value. This requires that the following relationship between data ow v ariables and places be maintained in an EPN as it moves from state to state: a token in a data ow place requires that a value be present in the associated variable. One way of ensuring that this relationship is maintained is by associating the output data ow places with predicates that are true exactly when the conditions for data transfer to the corresponding variable are true. In cases where data input to a process is from an external entity then each control transfer rule that removes a token from this place must be predicated on the presence of data in the variable.
Before we can analyze the vending machine SART model, we need to dene its initial EPN state. The initial EPN state is shown in Fig. 4: the state place, s1 has a token in it, indicating that the vending machine is in the Idle state; and the processes Get Valid Selection, Get Change Coin, Dispense Product, Clear Payment and Get Payment Coin are all disabled, that is, a token is present in the inhibitors associated with the corresponding process transitions. In order to execute the EPN on a machine we converted it to an existing machine-executable form called Cabernet [16]. This conversion was done manually. Details of the conversion can be found in a forthcoming technical report.
During development and execution of the EPN, we uncovered a number of problems with the EPN and the SART model. Some of the problems we identied and their resolutions are discussed below: 1. On examining the C-EPN we noted that there was a transition that had an empty set of input and output places (transition 6). This raised a red ag and prompted the question`under what conditions is this transition red?'; a question that had to be resolved before a CTS is associated with the transition.  Figure 4: Initial state for vending machine We l o o k ed at the corresponding process Deposit Coins and noted that the reason for the lack of places is a result of the lack of information related to the conditions under which the process is invoked. The only inputs and outputs of this process are data stores. How does the process know when to read the data store Held Coins? In other words, when do we make the held coins part of the general pool of coins held in the vending machine? An examination of the role of Held Coins raised more questions. It was not clear why i t w as needed in the current problem structure; in another structure Get Payment Coin would need only to recover the coins from Held Coins. Rather than change the structure radically, we c hose the simpler approach; we eliminated the data store Held Coins and the process Deposit Coins and made Accumulate Coins direct its output to the data store Coins. 2. In the EPN the coin value is accumulated when a coin is rejected as a slug because of a full repository of coins. We resolved this problem by h a ving Validate Coins output the valid object (validobj ) t o A c cumulate Coins, which puts the physical coin in Coins and passes the value (value) t o A c cumulate Payment only after it is determined that the coin repository is not full. 3. Payment is not cleared whenever payment e n tered by a customer is returned. We resolved this by activating Clear Payment after payment is returned. This required the addition of a control ow from Get Payment Coin, called payment returned, indicating that payment w as returned. 4. The initial SART model assumed that enough coins for change will always be available. This is an unreasonable assumption. The behavior we specied returns payment (without dispensing product) when there are no coins available for change. The ability to rigorously`test' the SART model increases condence in the structure and properties specied. A w eakness of Petri Nets is the complexity problem, that is, Petri Net models tend to become too large for analysis even for a modest-size system. To solve this problem, a Petri Net model can be organized hierarchically into several levels [18]. The lower level specication can be described by replacing each place in the specication with a more detailed Petri Net through a renement process. The IPTES project [7] has developed a Petri Net formalization of SART that addresses this problem, as well as supports the specication of time constraints.

The Fusion/Z Case Study
In the second case study we used an integrated Fusion/Z FIST to develop requirements models for a student advising system. We did not attempt to formalize all the Fusion analysis models, rather, we used formal notations in place of less formal descriptions, and used formal techniques to specify and analyze the object model. The problem tackled was originally stated for a student project class, but addressed a real-world need.
In formalizing the Fusion analysis models we w ent through the following stages: Stage 1: Object Modeling In this stage the focus was on modeling the static structure, that is, modeling the static relationships among objects. The object model produced in this stage was formalized using some formal translation rules that expressed relationships between Z constructs and constructs in the object model.
Stage 2: Operation Modeling In this stage the externally observable operations of the application were modeled. In the Fusion method the operations are described using natural language. In our approach we dened the eects of operations using Z. Our Z specications can completely replace the Fusion models of operations.
Stage 3: Lifecycle Modeling In this stage the constraints on the order in which operations can be executed were dened. We used the Fusion lifecycle expressions; these representations are rigorous so we did not attempt to formalize them. The following subsections present some of the models we produced in Stages 1 and 2.

Modeling the Advising System Problem
The following is part of the original requirements statement for the advising system (see also [10]): The project is concerned with providing automated support for undergraduate advising in the Department of Computer Science and Engineering. An important component of the department's undergraduate advising system is the student e v aluation worksheet, which is used to keep track of courses students have taken, are currently enrolled in, and plan to take. Your specic task concerns developing a system that supports information retrieval and updating activities associated with student w orksheets.
The system should allow users to do the following: 1. Consistently create and destroy student w orksheets. 2. Consistently update worksheet data. The system should be capable of informing users of updates that violate departmental rules, e.g., the system should disallow the recording of an enrollment when the student does not have the necessary pre-requisites. 3. Retrieve w orksheets.

Stage 1 -Developing the Object Model
In Stage 1 we used an explore, formalize, rene development s t yle (similar to the`explore, elaborate, validate' process model described in [9, 1 0 ]). In the exploratory phase we modeled the structure using Fusion object modeling concepts; no attempt was made to formalize the modeled concepts during this time. In Fig. 5 we show part of the result of the exploratory task. In Fusion, the label + on an association indicates one or more and the symbolindicates zero or more. A black b o x on a relationship indicates that every instance of the adjacent class must participate in the relationship. In the model a student m ust be assigned an advisor, and must have a w orksheet. A worksheet must be associated with one student. An advisor can be assigned to zero or more students (the fact that an advisor is a faculty member is abstracted out of the model). To support the formalization of the object model we dened relationships between Fusion associations and Z concepts. The relationships became part of the Z mathematical toolkit we used to develop a more formal expression of the object model. For more details about the toolkit see [2].
In formalizing the object model we took the following steps: 4. Create the state schema that ties all the above s c hemas together and specify any constraints not covered in the above steps: Constraints that cannot be expressed in terms of Fusion graphical notation are usually stated in natural language in the diagrams. In such cases the constraints should be re-expressed in Z. In the state schema produced at this stage each object is modeled as a set of instances in Z. The specication we obtained at the end of this activity is given below: AdvState Diagram advisors : PAdvisor students : PStudent worksheets : PWorksheet dom assigned to advisors ran assigned to = students dom has = ran assigned to ran has = worksheets 5. Evaluate model: The formal and informal models are examined closely to determine whether they could be improved and/or simplied. In the latter activity w e reexamined our graphical model and decided that a more informative model could be obtained by treating COURSE and TERM as objects. The relationships among these objects were obtained from the Z relations involving these objects. The result of the restructuring is shown in Fig. 6  The results of our case studies are a good indication that the application of FISTs to requirements specication and analysis can bring about the following benets: Support for the analysis and validation of requirements modeling through the use of executable formal models. Support for early problem analysis in the form of exible tools that permit the building of structures that appeal more to intuition than formality, a s w ell as support for more rigorous problem analysis through the formal reexpression of structures and content.
Use could lead to an understanding of required properties that may not be possible with sole use of formal or informal specication techniques.
Benets associated with the use of informal models (for example, ease of use, readability) and benets associated with formal models (for example, less chance of misinterpretation, support for rigorous analysis and verication activities) are not necessarily impaired by their integration. In fact, formal and informal models can complement each other. The denedness of the relationship between the formal and informal concepts and notations determines whether one can partially automate the transformation of informal to formal models. If the relationship is well-dened, and can be codied to some extent, then the set of rules can become the basis for a tool that generates portions of the formal model from information available in the informal models. Lack o f w ell-dened rules, though, does not preclude the integration of techniques, as was shown in the Fusion/Z case study. In such cases, the transformation is more dependent o n h uman skill.
There is some work on developing tools to support FISTs (e.g., see [1,4,7,8]). We are currently working on a tool called FuZE that supports the use of a Fusion/Z FIST for requirements modeling and analysis [3,4]. As the eld develops we expect to see more tools appear. In particular, extensions to CASE tools for traditional techniques that allow for the creation of formal models, or that provide formal interpretations of symbols are envisaged.