SAZ Invoicing Case Study : Questions Raised in Development 1. INTRODUCTION Dr Fiona Polack fiona@cs.york.ac.uk Department of Computer Science University of York, YORK YO1 5DD, UK tel : +1904 432798 fax : +1904 432767 In May 1997, H. Habrias proposed an exercise in a message to the B User Group. The proposition is to specify the case study, recording the questions which one would ask. The researchers at IRIN, Nantes, are accumulating responses, in an attempt to determine what sorts of questions the developers should prompt the clients to ask. This paper explores the specification using SSADM version 4 techniques, and then using SAZ-style Z. 2. SSADM version 4 SSADM version 4[1, 2, 3] is not designed for a small case study such as this. It is best suited to very large, multi-analyst projects. However, a number of its techniques can be applied to assist with the specification. The SSADM method is the UK de facto standard for public sector information systems (although version 4 is now being superceded by more adaptable and open versions). It is widely used in the private sector, and in a range of European and Eastern countries. The structure of SSADM version 4 defines 5 modules, two of which are broken into two stages. Within the modules, there are steps and tasks, which achieve the goals of the module. However, despite this well-defined structure, the philosophy of the method is adaptation. One of the first tasks of the analysts is to determine which parts of the method are appropriate for their project. In this case study, the second and third modules are used. These are known as Requirements Analysis (RA) and Requirements Specification (RS). RA explores the system, extracting requirements. RS specifies a abstract system to meet the functional requirements which have been determined, using data, dynamic and functional models. The techniques are briefly introduced as each is used in the case study. Because of the small size and restricted scope of the case study, only a cursory analysis and specification was prepared. This took approximately half an hour. The diagrams and text presented here are sometimes incomplete, because of the nature of the study. The questions, noted in situ, are those which arose during the original work. Any which arose afterwards are listed separately. A major criticism of the SSADM method is its mixed paradigms. The approach to data modelling, for instance, is explicitly oriented to the development of a relational database.
Thus, attributes (data items) are selected as unique identifiers (primary keys) of entities very early in specification. Normalisation is performed on the entities, on the assumption that these will form relations in a relational database. However, the approach to dynamic modelling, using entity life histories (and, later, Jackson programming structures derived from these), is implicitly aimed at the development of a procedural program. There is, for instance, no acknowledgement of the problems of implementing dynamic constraints (as specified in the entity life histories) in a relational DBMS. 3. SAZ SAZ[4, 5, 6, 7] is a method, developed at the University of York, UK, with EPSRC funding, which takes the products of a structured specification and informally derives a formal specification for the system function. The style of Z is fairly primitive, but is used to minimise the formal-specification insight required of the specifier. SAZ has been shown to raise issues which are not traditionally apparent in systems analysis and design [8]. However, in this case study, the SSADM version 4 was prepared by the author, who is accustomed to the formal approach, and may thus have identified some issues which a structured methods analyst would not have spotted. 4. The SSADM Analysis and Specification 4.1. Analysis The RA module uses a logical data model (SSADM s name for entity-relationship diagrams with supporting documentation) and sketched data flow diagrams to explore the current system (in this case, the given scenario). The module initiates the Requirements Catalogue, although the method does not give clear guidance on the form and content of this product. In the case study, the main requirements are clear. However, the modelling to explore the scenario did raise several issues. Figure 1 shows a SSADM-style logical data model for the scenario. CUSTOMER ORDER ITEM Figure 1. SSADM-style logical data model for the case study. In the diagram, boxes represent entity types; lines represent relationships between the entities; the presence or absence of the crow s foot, triangular notation at the end of a line indicates the degree of the relationship. If any of the lines was dashed, it would indicate optionality. Thus, figure 1 represents the following information. Each instance of customer must be related to one or more instances of order, whilst each The SAZ project, which was carried out at the Department of Computer Science, University of York, 1991-95, was supported by the UK Science and Engineering Research Council under grants GR/F98529 and GR/J81655.
instance of order must be related to exactly one customer. Each instance of item must be related to one or more instances of order, whilst each instance of order must be related to exactly one item. QUESTION : do customers exist in the system independently of orders? It is assumed that the details of customers are linked to the orders, but that each customer can place many orders. QUESTION : what information does the system hold on these entities? It is stated that orders record quantities of items, and that items have a stock level. It might be taken to be implicit that there are customer details (eg for sending invoices), and that there is some price information for items (so that invoices can be calculated). A case might be made for adding a date attribute to the orders. However, these would be outside the scope of the case study. The data dictionary which accompanies the data model would, in SSADM, comprise dozens of forms, at too low a level of abstraction. Here, a simple, abstract, format is used: ENTITY: CUSTOMER ORDER ITEM Attributes: details quantity stock_level There is one derived attribute, which is not shown on the logical data model, namely the invoiced? indicator. The case study states that orders are invoiced if the quantity ordered is less than or equal to the stock level of the item ordered. The second technique of RA is the data flow model. Unlike most other methods, data flow diagrams are not used to specify system processing, but merely to help the analysts understand the workings of the system they are about to develop. In SSADM version 4, three versions of the DFDs can be used. The first captures the current physical system in detail. The other two versions remove non-logical features (processes which don t change data, processes relating to geography, history etc). This is started for the current system, and modified to reflect the requirements of the new system. This may change the scope of the diagrams, and may add or remove processes. In this case study, one logical DFD phase is used for each of the two cases, to illustrate what the case study appears to be requesting. X invoice 2 D1 ORDER FILE Invoice Order quantity stock level D2 STOCK FILE Figure 2. DFD for case study Case 1, using SSADM logical DFD notations. In figure 2, boxes represent processes; ellipses are external entities (these are NOT entities in the sense used in the data model, but simply the origins and destinations of data flows crossing the system boundary). The open-ended boxes are data stores. In SSADM RA, the data stores on the DFDs are correspond to one or more entities from
the data model. This is a non-rigorous matching, which allows some entities, or attributes of some entities, to be present in more than one data store. In this case, the ORDER FILE comprises the data items from the Order and Customer entities; the STOCK FILE equates to the instances of the Item entity. SSADM again has copious text documentation, using a variety of standard forms. The documentation of the processes and data flows is not included here, since this is considered to be obvious from the case study text. The DFD for Case 2 of the case study is rather more elaborate, being required to handle cancelled orders, as well as new orders, and to accept new stock. The notations are as for Case 1 (figure 2), except that, to avoid data flow lines crossing, the ORDER FILE data store is represented twice. The duplication is indicated by the addition of a vertical bar on the front of the open-box notation. 1 new order Handle new order order details W 2 D1 ORDER FILE X invoice Invoice Order quantity stock level stock delivery 3 Receive Stock D2 STOCK FILE Y stock quantity Z cancellation notice 4 Cancel Order returned stock D1 ORDER FILE stock level Figure 3. DFD for case study Case 2, using SSADM logical DFD notations. In figures 2 and 3, the external entities are not named, since there is no information in the case study about the external communication of the system. QUESTION : Are the source of orders and the destination of invoices the same? QUESTION : What are the external entity labels? QUESTION : Are orders cancelled by customers, or by the company, both or neither? QUESTION : What happens to unmet orders? The model for Case 2 (figure 3) implies that orders remain in the ORDER FILE until they are invoiced or cancelled; these are the only data flows out of the ORDER FILE. It is not possible to define (and the case studies do not require that we define) any sequencing, such
that the first order placed is invoiced first. The full RA module includes scoping exercises, in which the developers and clients determine the extent of the system to be specified. This is not relevant here. 4.2. Specification The SSADM RS is intended to give a logical (abstract, or implementation independent) definition of the system, based on the requirements identified in RA. In order to specify the system, the data model is validated against the scope of the system to be built, and the data in the data model may be normalised. In SSADM version 4, the implicit aim is to have a data structure which can be directly implemented as relational tables, for a relational database. In the case study, normalisation was not necessary; the data is in third normal form, coincidentally. The data model for the system is as produced by the RA, but the data dictionary is modified with the addition of primary and foreign keys, to uniquely identify each entity (surrogate primary keys), and to model, in relational terms, the relationships shown in the data model diagram. (Strictly this is at too low a level of abstraction, but it would be included at this level in SSADM.) QUESTION : are there any unique identifiers inherent in the system? ASSUMPTION : surrogate attributes are added as primary keys; relationships are represented as foreign keys. In the simple dictionary, below, primary keys are all named with the entity name followed by Id, and foreign keys are asterisked. ENTITY: CUSTOMER ORDER ITEM Attributes: Customer Id Order Id Item Id details quantity stock_level Item Id* Customer Id* In RS, the data flow diagrams are reworked into function definitions. These are the gross processing specifications for the system, and are derived by a two-part technique. First, all events are identified and traced through the DFDs. Second, the event traces are referred to users, who may combine or divide the contents, to give user-approved system function definitions. The technique is text-based, although there are diagrams representing the entities updated by each function and the input and output of data (these are not included here). In addition to function definition, SSADM requirements specification requires that a life history is composed for every entity. To facilitate the construction of entity life histories, and also other techniques for documenting functions (not included here), an entity event matrix may be constructed. This may be used to ensure that the system can create and delete instances of all entities and that the system provides all required data update An event is a flow of data into the system, or a system triggered event, such as a monthly archive session. In Case 1, there is one event, an internally generated (and unspecified) prompt to invoice an order. In case 2, the events include, in addition, the receipt of a new order, the receipt of new stock, and the instruction to cancel an order.
facilities. For the case study, function definitions and an entity event matrix were prepared, and the data model was extended with primary and foreign key information. For the case study, three functions are defined. Of these, only the first is relevant to Case 1; all three are required for Case 2. QUESTION : are all orders invoiced as soon as they are received? ANSWER : There is nothing in the specification presented that indicates how the invoicing of an order is triggered. The function definitions (below) merely state that there must be enough stock for an order to be processed. Function 1 : Receive Order Order is received by the system. Processing involves checking the stock level of the ordered item, and preparation of an invoice if the order can be met from stock (quantity <= stock). QUESTION : are orders validated in any way? QUESTION : what happens to the orders which cannot be met? Function 2 : Cancel Order An order is cancelled and any stock allocated to it is reinstated to the total stock for that item. QUESTION : when can an order be cancelled? ASSUMPTION : an order can be cancelled after invoice, but, perhaps, before some unspecified non-functional cut-off (eg before it s posted). QUESTION : How is an order cancelled (by customer, company, or what)? QUESTION : is there any form of acknowledgement of the cancellation? Function 3 : Receive Stock Stock is received at the warehouse, and the stock level for the item is updated. QUESTION : When stock is received, is there any interaction with un-invoiced orders? The entities from the data model and the events which trigger the above functions can be used to initiate an entity event matrix. (This is relevant only to Case 2 of the case study, since there is only one process, and thus no dynamics as such, in Case 1.)
EVENTS ENTITIES Customer 1 2 3 C Order C D Item U U KEY C = creation of entity instance(s) D = deletion of entity instance(s) U = update of some or all attribute values EVENTS KEY: 1. Receipt of Order 2. Receipt of Stock 3. Cancellation of Order The entity event matrix shows that the system as specified cannot create (C) or delete (D) items from the stock record, nor can it update (U) and delete (D) customers. The orders cannot be modified (U). Because of the scope of the case study, these are not pursued, but would be questions to a client in a real study. QUESTION : How are items created and deleted from the stock record? QUESTION : How are customers updated and deleted? QUESTION : Are orders ever modified? Because of the incompleteness of the event record (SSADM expects instances of every entity to be at least capable of being created and deleted), it is not worth while to draw up entity life histories. Again this would have to be addressed in a real development. 5. SAZ-STYLE Z SPECIFICATION SAZ is a method for taking a specification in the style of SSADM version 4 and producing, by informal translation, a Z specification of the functional parts of the system. SAZ does not aim to produce concise or elegant Z, preferring a templatable approach. It is aimed at novice formalists, and assumes that more advanced Z users will develop their own preferred approaches to the formal specification. There is no formal attempt to verify that the Z and the SSADM are specifying identical systems, although it is noted in SAZ work that it is necessary to reflect any modifications made in the light of the Z specification in the SSADM specification documents and vice versa. The SAZ specification has only been attempted for the full, Case 2, situation. 5.1. Defining the State SAZ follows a conventional approach in defining the Z state. Given sets, enumerated types and schemas are used to define the base types at appropriate levels of details. Schemas are then used to define entity types, and relations or functions map relationships. The SAZ state would typically extend the information available about the state, since it is SAZ Z style has varied over the years. This case study uses the original SAZ approach, which is less rigorous than later work in determining and enforcing abstraction levels[7].
easier to detect and express constraints in the Z than in the diagram-and-text format of the SSADM data model. In the case study, there is no substantive information about the domains of the attributes of the entities in the specification, so the most appropriate (though not necessarily most efficient) option is to use given sets for these. ][]QUANTITY_, ]STOCK_LEVEL_]_ QUESTION : what customer information is stored? There is a question as to what to do about the customers who place the orders. These appear to be strictly outside the scope of the case study, even in Case 2. It has been decided to represent these simply as identifiers in the Z specification. QUESTION : are quantities and stock levels integers? QUESTION : what are the constraints on these domains? The identifiers, in SAZ, are conventionally defined also as given sets: ][]CUSTOMER_ID_, ]ORDER_ID_, ]ITEM_ID_]_ The entity type and entity set schemas are simple, since there is no extra information on constraints. ]CUSTOMER_SET ]]Customers_ : ]F ]CUSTOMER_ID_]_]_ ]ORDER ]]Quantity_ : ]QUANTITY_]_]_ ]ORDER_SET ]]Orders_ : ]ORDER_ID_ I ]ORDER_]_]_ ]ITEM ]]Stock_level_ : ]STOCK_LEVEL_]_]_ ]ITEM_SET ]]Items_ : ]ITEM_ID_ I ]ITEM_]_]_ QUESTION : can a customer place more than one order for the same item? ASSUMPTION : the case study, and the SSADM specification, are not clear on this question. The Z has not been constrained to prevent such duplicate orders. Although SAZ often defines the relationships as separate schemas, in this small case it is more efficient to define them in a general state schema. The case study is not clear about the optionality of the relationships (as noted with the data model). SAZ models many-toone relationships, of which the two in the data models are both examples, as partial
functions, and constrains the optionality with reference to the entity sets. In this case, the relationships are defined to hold between the unique identifier instances of the entities in the entity sets. There are other ways of doing this : one is shown in the schema, ALT_STATE, below, in which the relationships are modelled as relations, constrained to total functions between the sets of known instances of the entities. ]STATE ]]CUSTOMER_SET ]]ORDER_SET ]]ITEM_SET ]]Order_Customer_Rel_ : ]ORDER_ID_ I ]CUSTOMER_ID ]]Order_Item_Rel_ : ]ORDER_ID_ I ]ITEM_ID_] ]_]]dom ]_]_]_]_]_]Order_Customer_Rel_] = _]_]_]_]_]dom ]_]_]_]_]_]Orders_] ]_]]ran ]_]_]_]_]_]Order_Customer_Rel_] = _]_]_]_]_]Customers_] ]_]]dom ]_]_]_]_]_]Order_Item_Rel_] = _]_]_]_]_]dom ]_]_]_]_]_]Orders_] ]_]]ran ]_]_]_]_]_]Order_Item_Rel_] = _]_]_]_]_]dom ]_]_]_]_]_]Items_]_ ]ALT_STATE ]]CUSTOMER_SET ]]ORDER_SET ]]ITEM_SET ]]Order_Customer_Rel_ : ]ORDER_ID_? ]CUSTOMER_ID ]]Order_Item_Rel_ : ]ORDER_ID_? ]ITEM_ID_]_ ]Order_Customer_Rel_ / ]dom ]_]_]_]_]_]Orders_ J ]Customers_ ]Order_Item_Rel_ / ]dom ]_]_]_]_]_]Orders_ J ]dom ]_]_]_]_]_]Items_ 5.2. SAZ PROCESSING SPECIFICATION SAZ specifies processing in accordance with the SSADM version 4 emphasis on eventtriggered functions. Processing is not fully defined in the case study, but the details derived for the SSADM specification of Case 2 gave rise to three such functions. Receive Order This comprised two processes, Handle New Order and Invoice Order. We do not have information about any checking etc of the new order; we simply infer that the order is entered in the set of orders. Note that SAZ distinguishes entity instances by a function from identifiers to the set of known orders. This means that a new order will require a new identifier, but other information may already exist in the instance set. For instance, if all instances of the entity which is the domain of the function must take part in the relationship, as here, the domain of the relationships is equal to the set of instances of the entity; if some instances need not take part in the relationship, then the domain of the relationships is a subset (9) of the set of instances of the entity. The range constraints are defined in the same way.
It is usually most efficient to declare substates for update (after Barden, Stepney and Cooper[9] ). This is not done here, because of the small and intimately linked state structure. Because the relationships are assumed to be mandatory, it is necessary to link the order to a customer and an item. The Z specification requires that the item and customer already exist. QUESTION : must customers and items exist for an order to be accepted? ASSUMPTION : for simplicity, the Z specification assumes that both customers and items exist for an order to be accepted. The specification could be extended to include the need to add a customer placing an order to the set of known customers. It is clearly nonsense to accept orders for non-existent items. There are a number of options for the entry of the new order. Here, the addition of the new order is defined first, and a separate schema defines the invoicing of the orders. The addition of the new order involves adding the order to the set of orders, with a new identifier (surrogate primary key value). The customer placing the order and the item ordered are specified by their identifiers. The Z functions representing the relationships with the order entity are updated by the addition of the identifier tuples. ]HANDLE_NEW_ORDER ]] STATE ]]Order?_ : ]ORDER ]]Customer_Id?_ : ]CUSTOMER_ID ]]Item_Id?_ : ]ITEM_ID ]]New_Order_Id?_ : ]ORDER_ID_] ]_]]New_Order_Id?_] 7 _]_]_]_]_]dom ]_]_]_]_]_]Orders_] ]_]]Orders _] = _]_]_]_]_]_]_]_]Orders_] ; _]_]_]_]_]_]_]_]_]{]_]_]_]New_Order_Id?_] @ _]_]_]_]_]_]_]Order?_]_]_}_]_] ]_]]Customers _] = _]_]_]_]_]Customers_] ]_]]Items _] = _]_]_]_]_]_]Items_] ]_]]Order_Customer_Rel _] = _]_]_]_] ]_]_]]Order_Customer_Rel_] ; _]_]_]_]_]_]_]_]_]{]_]_]_]New_Order_Id?_] @ _]_]_]_]_]_]_]Customer_Id?_]_]_}_]_] ]_]]Order_Item_Rel _] = _]_]_]_]_]_]_]_]Order_Item_Rel_] ; _]_]_]_]_]_]_]_]_]{]_]_]_]New_Order_Id?_] @ _]_]_]_]_]_]_]Item_Id?_]_]_}_]_]_ In terms of the invoicing of the entered orders, it is not clear whether orders are invoiced immediately or at a later date. The Z is left open on this issue; it simply requires that the order can be met in order to invoice it. At this stage in the SAZ specification, it becomes apparent that the derived attribute, invoiced?, noted in the data model development (section 4.1, above) is needed, since there is no obvious way of determining whether an order has been invoiced. An additional modification is required to the state, so that STOCK_LEVEL is comparable with QUANTITY. This resolves, arbitrarily, the question raised in section 5.1, as to the units of these two attributes. The revised elements of the state specification are as follows. All other elements are unchanged.
_]]NUMBER_ == ]N_]_] ]]STOCK_LEVEL_2_ == ]NUMBER_]_] ]]QUANTITY_2_ == ]NUMBER_]_]_ ]ORDER_STATE_ ::= ]Order_Entered_ ]Order_Invoiced_ ]ORDER_2 ]]Quantity_ : ]QUANTITY_2 ]]Order_State_ : ]ORDER_STATE_]_]_ ]ORDER_SET_2 ]]Orders_ : ]ORDER_ID_ I ]ORDER_2_]_]_ ]ITEM_2 ]]Stock_level_ : ]STOCK_LEVEL_2_]_]_ ]ITEM_SET_2 ]]Items_ : ]ITEM_ID_ I ]ITEM_2_]_]_ ]STATE_2 ]]CUSTOMER_SET ]]ORDER_SET_2 ]]ITEM_SET_2 ]]Order_Customer_Rel_ : ]ORDER_ID_ I ]CUSTOMER_ID ]]Order_Item_Rel_ : ]ORDER_ID_ I ]ITEM_ID_] ]_]]dom ]_]_]_]_]_]Order_Customer_Rel_] = _]_]_]_]_]dom ]_]_]_]_]_]Orders_] ]_]]ran ]_]_]_]_]_]Order_Customer_Rel_] = _]_]_]_]_]Customers_] ]_]]dom ]_]_]_]_]_]Order_Item_Rel_] = _]_]_]_]_]dom ]_]_]_]_]_]Orders_] ]_]]ran ]_]_]_]_]_]Order_Item_Rel_] = _]_]_]_]_]dom ]_]_]_]_]_]Items_]_ The order-handling specification is modified to require the new order to be in the state, Order_Entered. This could imply that a default value is used for new orders.
]HANDLE_NEW_ORDER_2 ]] STATE_2 ]]Order?_ : ]ORDER_2 ]]Customer_Id?_ : ]CUSTOMER_ID ]]Item_Id?_ : ]ITEM_ID ]]New_Order_Id?_ : ]ORDER_ID_] ]_]]Order?_. ]Order_State_] = _]_]_]_]_]Order_Entered_] ]_]]Orders _] = _]_]_]_]_]_]_]_]Orders_] ; _]_]_]_]_]_]_]_]_]{]_]_]_]New_Order_Id?_] @ _]_]_]_]_]_]_]Order?_]_]_}_]_] ]_]]Customers _] = _]_]_]_]_]Customers_] ]_]]Items _] = _]_]_]_]_]_]Items_] ]_]]Order_Customer_Rel _] = _]_]_]_] ]_]_]]Order_Customer_Rel_] ; _]_]_]_]_]_]_]_]_]{]_]_]_]New_Order_Id?_] @ _]_]_]_]_]_]_]Customer_Id?_]_]_}_]_] ]_]]Order_Item_Rel _] = _]_]_]_]_]_]_]_]Order_Item_Rel_] ; _]_]_]_]_]_]_]_]_]{]_]_]_]New_Order_Id?_] @ _]_]_]_]_]_]_]Item_Id?_]_]_}_]_]_ The invoicing of orders is now explicitly specified as changing the state of the order from Order_Entered to Order_Invoiced ASSUMPTION : A precondition of the invoicing operation is that there is sufficient stock of the ordered item. This is not stated in Case 2, but is implicit in the action of invoicing. ASSUMPTION : It is assumed that companies do not invoice for goods that cannot be supplied. ASSUMPTION : The specification further assumes that the act of invoicing an order includes the reduction of the level of stock by the amount ordered. This is again not explicit in the case study, but is necessary to ensure that successive orders are not notionally assigned the same stock items. ]INVOICE_ORDER ]] STATE_2 ]]Order_Id?_ : ]ORDER_ID_]_ ]Order_Id?_ / ]dom ]_]_]_]_]_]Orders ]_]](]Orders_ ]Order_Id?_). ]Order_State_] = _]_]_]_]_]Order_Entered_] ]_]](]Orders _ ]Order_Id?_). ]Order_State_] = _]_]_]_]_]Order_Invoiced_] ]_]](]Items_ (]Order_Item_Rel_ ]Order_Id?_)_). ]Stock_level_] Q _]_](]Orders_ ]Order_Id?_). ]Quantity_] ]_]](]Items_ (]Order_Item_Rel _ ]Order_Id?_)_). ]Stock_level_] = _]_]_] ]_]_]](]Items_ (]Order_Item_Rel_ ]Order_Id?_)_). ]Stock_level_] - _]_](]Orders _ ]Order_Id?_). ]Quantity_]_] ]_]]dom ]_]_]_]_]_]Items _] = _]_]_]_]_]dom ]_]_]_]_]_]Items_] ]_]]Order_Item_Rel _] = _]_]_]_]_]_]Order_Item_Rel_] ]_]]Order_Customer_Rel _] = _]_]_]_]_]_]Order_Customer_Rel_] ]_]]Customers _] = _]_]_]_]_]Customers_]_ Following common Z practice, SAZ then defines the corresponding error schemas. These do not update the state, but output error messages (success messages could be output by the previous schemas, if necessary). QUESTION : does the client have error messages, or other actions for these situations? ]NEW_ORDER_MESSAGE_ ::= ]Order_Already_Invoiced_ ]Order_Not_Entered_
]INVOICE_MESSAGE_ ::= ]Stock_Low_No_Invoice_ ]Other_No_Invoice_ ]HANDLE_NEW_ORDER_2_ERR ]]ΞSTATE_2 ]]Order?_ : ]ORDER_2 ]]Message!_ : ]NEW_ORDER_MESSAGE_] ]_]]Order?_. ]Order_State_] 6 _]_]_]_]_]Order_Entered_]_ & ]_]_]Message!_] = _]_]_]_]_]Order_Not_Entered_]_ ]INVOICE_ORDER_ERR ]]ΞSTATE_2 ]]Order_Id?_ : ]ORDER_ID ]]Order_Message!_ : ]NEW_ORDER_MESSAGE ]]Invoice_Message!_ : ]INVOICE_MESSAGE_] ]_]]Order_Id?_] 7 _]_]_]_]_]dom ]_]_]_]_]_]Orders_]_ & _]_]]Order_Message!_] = _]_]_]_]_]Order_Not_Entered_]_ ( (]_]_](]Orders_ ]Order_Id?_). ]Order_State_] = _]_]_]_]_]Order_Invoiced_]_ & _]_]]Order_Message!_] = _]_]_]_]_]Order_Already_Invoiced_]_) ]_]](]Items_ (]Order_Item_Rel_ ]Order_Id?_)_). ]Stock_level_] < ]](]Orders_ ]Order_Id?_). ]Quantity_]_ & ]_]_]Invoice_Message!_] = _]_]_]_]_]Stock_Low_No_Invoice_]_ Cancel Order ASSUMPTION : The cancellation function in the SSADM assumes that an order can be cancelled before or after invoice, but before some unspecified non-functional cut-off (eg before it s posted). An order is cancelled and any stock allocated to it is reinstated to the total stock for that item. The Z describes the removal of all record of the order, and makes the requisite adjustment to the stock level. The Z specification given applies a cascade delete on the customer, such that, if the order is the last or only order placed by the customer, then the record for the customer is removed. This is in keeping with the mandatory relationship assumed between customers and orders. However, a cascade delete is not applied to items, giving rise to the following question and assumption. QUESTION : can items exist in the system, for which there is no order? ASSUMPTION : It would seem logical to assume that this is possible, although this requires a modification to the relationship, and to the Z function modelling it, between orders and items. Rather than rework the entire specification thus far, it is simply noted that in the STATE_2 schema, the statement, ran Order_Customer_Rel = Customers
should be replaced by, ran Order_Customer_Rel 9 Customers This allows the operation, defined in the following schema, to maintain a consistent state. ]CANCEL_ORDER ]] STATE_2 ]]Order_Id?_ : ]ORDER_ID_] ]_]]Orders _] = _]_]_]_]_]_]_]_]{]_]Order_Id?_]_}_] D _]_]_]_]_]_]_]Orders_]_] ]_]_]_]]{]_]Order_Id?_]_}_] B _]_]_]_]_]_]_]Order_Customer_Rel_]_] = _]_]_]_]_]_]_]_]_]{]_}_]_ & _]_]]Customers _] = _]_]_]_]_]_]_]Customers_] \ _]_]_]_]_]{]_]Order_Customer_Rel_ ]Order_Id?_]_}_]_]_ * _]_]]Order_Customer_Rel _] = _]_]_]_]_]_]_]_]{]_]Order_Id?_]_}_] D _]_]_]_]_]_]_]Order_Customer_Rel_]_] ]_]_]_]]{]_]Order_Id?_]_}_] B _]_]_]_]_]_]_]Order_Customer_Rel_]_] 6 _]_]_]_]_]_]_]_]_]{]_}_]_ & _]_]]Customers _] = _]_]_]_]_]Customers_]_ * _]_]]Order_Customer_Rel _] = _]_]_]_]_]_]_]_]{]_]Order_Id?_]_}_] D _]_]_]_]_]_]_]Order_Customer_Rel_]_] ]_]](]Items _ (]Order_Item_Rel_ ]Order_Id?_)_). ]Stock_level_] = _]_]_] ]_]_]](]Items_ (]Order_Item_Rel_ ]Order_Id?_)_). ]Stock_level_] + _]_](]Orders_ ]Order_Id?_). ]Quantity_]_] ]_]]Order_Customer_Rel _] = _]_]_]_]_]_]_]_]{]_]Order_Id?_]_}_] D _]_]_]_]_]_]_]Order_Customer_Rel_]_] ]_]]Order_Item_Rel _] = _]_]_]_]_]_]_]_]{]_]Order_Id?_]_}_] D _]_]_]_]_]_]_]Order_Item_Rel_]_]_ Since there is no information about the state in which it is possible to cancel orders, there are no preconditions on this operation, and thus no error states. Receive Stock The SSADM function definition states that stock is received at the warehouse, and the stock level for the item is updated. QUESTION : What happens to any unfulfilled orders for this stock? ]RECEIVE_STOCK ]] STATE_2 ]]Item_Id?_ : ]ITEM_ID ]]Amount?_ : ]N 1 _]_ ]Item_Id?_ / ]dom ]_]_]_]_]_]Items ]_]](]Items _ ]Item_Id?_). ]Stock_level_] = _]_]_]_]_]_]_](]Items_ ]Item_Id?_). ]Stock_level_] + _]_]Amount?_]_] ]_]]Customers _] = _]_]_]_]_]Customers_] ]_]]Orders _] = _]_]_]_]_]_]Orders_] ]_]]Order_Customer_Rel _] = _]_]_]_]_]_]Order_Customer_Rel_] ]_]]Order_Item_Rel _] = _]_]_]_]_]_]Order_Item_Rel_]_ ASSUMPTION : The Z specification assumes that the stock received is for a known item. QUESTION : what happens if a delivery arrives for which there is no entry in the Items catalogue? One error option is simply to return an error message:
]STOCK_MESSAGE_ ::= ]Item_not_on_catalogue_ ]Items_Delivered_ ]RECEIVE_STOCK_ERR ]]ΞSTATE_2 ]]Item_Id?_ : ]ITEM_ID ]]Stock_Message!_ : ]STOCK_MESSAGE_] ]_]]Item_Id?_] 7 _]_]_]_]_]dom ]_]_]_]_]_]Items_] ]_]]Stock_Message!_] = _]_]_]_]_]Item_not_on_catalogue_]_ Another option, not specified here, is to initiate the extension of the catalogue to include the item for which there is now stock. This seemed to be outside the remit of the case study Case 2, which refers only to entries of quantities in the stock. 6. CONCLUDING REMARKS The SSADM diagrams and text, like most structured method specifications, are not easy to validate. Important links, such as those between the state and the operations, are not rigorously explored, and constraints (dynamic and static) are not routinely included. The SAZ specification, working from the SSADM specification, corrects the stateprocessing mismatches (such as the mis-specification of the relationship between items and orders), and has the potential for elaborating the system constraints. Most of the information required to exploit this capability is not included in the case study, but some of the questions raised indicate where a formal approach generates questions about constraints etc. It is believed that, with the alteration to the state noted in section 5.2, the Z specification is consistent. The Z tool support currently available to the author makes formal proofs of specifications such as this time consuming (indeed the author has crashed the relevant proof tool many times attempting to prove apparently simple conjectures). However, informal proofs, of the style presented by Barden et al[9] or Potter et al[10], could be undertaken if time allowed.
REFERENCES 1. CCTA, SSADM Version 4 Reference Manual, NCC Blackwell Ltd (1990). 2. Weaver, P. L., Practical SSADM Version 4 : A Complete Tutorial Guide, Pitman Publishing (1993). 3. Goodland, M. and Slater, C., SSADM version 4 : A Practical Approach, McGraw- Hill (1995). 4. Mander, K.C. and Polack, F., Rigorous specification using structured systems analysis and Z, Information and Software Technology 37(5) (May 1995). 5. Polack, F. A. C. and Mander, K. C., Software Quality Assurance Using the SAZ Method, in Proceedings of Eighth Annual Z User Meeting, Cambridge, June 1994, Springer Verlag (1994). 6. Polack, F., Whiston, M. and Mander, K.C., The SAZ Project : Integrating SSADM and Z, LNCS 670 Proceedings, FME 93 : Industrial Strength Formal Methods, Odense, Denmark, April 1993, Springer Verlag (1993). 7. Polack, F., Whiston, M. and Mander, K. C., The SAZ Method Version 1.1, YCS 207, York (Jan 94). 8. Parker, H.E.D., Polack, F. and Mander, K.C., The Industrial Trial of SAZ : Reflections on the Use of an Integrated Specification Method, Z Twenty Years On: What Is Its Future?, Nantes, France, October 1995 (1995). 9. Barden, R, Stepney, S. and Cooper, D., Z In Practice, Prentice-Hall Practitioner Series (1994). 10. Potter, B., Sinclair, J. and Till, D., An Introduction to Formal Specification and Z, Prentice Hall (1991).