- Email: [email protected]
Using joint application design to develop readable formal specifications
ELSEVIER
Information and Software Technology 38 (1996) 615-631
Using joint application design to develop readable formal specifications Robert B. Jackson*, David W. Embley* Department
of Cornpurer Science, Brigham
Young University,
Provo, UT 84602, USA
Received 8 September 1994; revised 3 May 1995; accepted
12 July 1995
Abstract
A requirements specification is a ‘contract’ between a client and a systems developer. This document is frequently written in some type of ‘computerese’ or formal specification that is unintelligible to most clients. Why can’t we have a precise, formal specification that is understandable? In fact, why can’t we let the client take charge of developing a formal specification? In this paper, we present OSS (Object-oriented Systems Specification), a graphical model with an embedded textual language that has a formal foundation, is suitable for requirements specification, and is understandable to at least technically oriented clients. We also introduce IPOST, a prototyping/specification tool to assist the client. We describe a Joint Application Development (JAD) scenario utilizing OSS and IPOST that involves heavy client participation in the development of formal requirements specifications. Keywords;
Requirements specifications; Joint application design; Rapid prototyping
1. Introduction
In their delightfully refreshing book Expforing Requirements: Quality Before Design [l], Donald Gause and Gerald Weinberg express the essence of the requirements-specification problem: ‘If you tell what you want, you’re quite likely to get it. If you don’t tell what you want, you’re quite unlikely to get it.’ The problem seems to be that either users do not tell developers exactly what they want, or developers do not hear what users say they want. Thus, our first definition: Requirements = What users want. Along with this definition comes a difficult question: How do developers find out what users want, and how do they document it? This leads us to our second definition: Specification = written documentation of what users want, in terms of a solution system. Thus, a specification comes from and extends the requirements into a proposed solution system. In the traditional view of software development, it is the responsibility of the technical team to do systems analysis and to develop the specification documents. The analysts strive to understand the user’s business needs and document those in a precise specification. User involvement is limited to expressing needs, verifying * email:Cjacks@osm., embley@}cs.byu.edu 0950-5849/96/$15.00 0 1996 Elsevier Science B.V. All rights reserved SSDZ 0950-5849(95)01058-O
the suitability of the specification and ‘signing off on the written specification. In many instances user needs can be more accurately identified through a rapid prototype. The technical staff ‘rapidly’ builds a partial model of the system using a CASE tool or some high-level language. Users ‘run’ the prototype and observe whether the form and function of the prototype accurately represent their needs. Where applicable and with the right tools, this approach improves the quality of the resultant specification [2]. The technical staff, however, maintains respdnsibility for creating the prototype and writing the specifications. In recent years, this traditional view has been challenged. In her insightful book A User’s Guide for Dejining Software Requirements [3], for example, Carolyn Shamlin provides a user oriented view of the systems development life cycle. She identifies seven tasks in the analysis phase and insists that all are the responsibility of the user team, not the technical staff: (1) Define external systems needs; (2) Establish systems goals and objectives; (3) Specify basic and optional features; (4) Determine information requirements; (5) Specify interface requirements; (6) Specify data relationships; (7) Specify processing requirements. A compromise approach, being used by some companies, gives users and technical staff equal responsibility for requirements definition. This approach is called Joint
616
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
Application Design (JAD) [4-61. The goal of the JAD approach is to produce higher quality software in an accelerated time by having both users and analysts accept responsibility and become heavily involved in the system development. The JAD approach is conducted through a series of meetings called JAD sessions. In a typical JAD approach a JAD team leader, who may be an analyst, a user or a specially trained facilitator, is selected, and a single team, consisting of users and systems analysts, is formed. This team meets in a single JAD session or in multiple JAD sessions. Each session usually lasts several days. A major benefit of this approach is that the analysis, or discovery, of the business needs is usually thorough and complete. The result of these JAD sessions is a comprehensive statement of system requirements. In support of this JAD approach, we have developed an analysis model, a specification language, and several accompanying computer-based tools. The analysis model, called Object-oriented Systems Analysis (OSA), and the specification language, called Object-oriented Systems Specification Language (OSS-L), are based on the object-oriented paradigm and are used together to provide an integrated analysis model and specification document [7,8]. The main accompanying tools are the OSA Composer, which assists users in creating OSA models instances, and IPOST, which automatically builds working prototypes based on OSA model instances. The focus of this paper is to show how a formal Object-oriented Systems Specification (OSS) can be
developed from an initial set of business requirements. We identify three major types of activities in this process: One activity is the analysis, which is a discovery and model building activity. Another activity is prototype execution, which is a verification and refinement activity. The third activity is specification development, which also includes verification and refinement, and additionally encompasses documentation and ‘contractual’ agreement. One of the major contributions of our approach is the integration of JAD with the development of formal specifications. In typical JAD sessions, these three activities are intermingled. The following hypothetical, but realistic, scenario illustrates the process: For two hours in the morning, the JAD team members review business requirements and begin developing an OSA model instance. Then, after some preliminary model components have been identiJied, the team members sit down at computers and use IPOST to execute the preliminary OSA model instance. Execution of the prototype uncovers several areas that are poorly defined and after about an hour, the team members continue with business requirements review and model building. This continues through most of the day, but by mid-afternoon, a couple of members of the team, a user and a systems analyst, are ready to begin refining portions of the OSA model instance into the SpeciJication. Again they utilize IPOST to execute the OSA model instance, and to add OSS-L statements to make it a formal, executable, precisely defined SpeciJication.
Service First Bank: Description of Operations. The Service First Bank is a locally owned bank that services a small community in the midwest. It provides basic services including savings accounts, checking accounts, credit card accounts and loan accounts. Every customer must have a checking account in order to have a credit or loan account. Accounts may be jointly owned, and a customer may have multiple accounts. Rules for Savings Accounts Anyone may open a savings account with an initial deposit of $10.00. Interest is accrued daily based on the daily balance at a rate which is set from time to time by the bank executive committee. Cash deposits are credited immediately, but check deposits are not credited until the check clears. Withdrawals may be made at any time for any amount. Rules for Checking Accounts Anyone over 16 may open a checking account. No interest is paid on this account. A customer may have automatic monthly withdrawals made for loan payments. An automatic overdraft service is provided for those customers who have a credit card account. Deposits are processed the same as for savings accounts. Rules for Credit Card Accounts Credit card accounts are available to any customer who has a checking account. Each account has a credit limit which may be increased upon request by a customer with good credit history. Interest is accrued on a daily basis. Monthly bills include interest and principal amount. Payment on the principal is 10% of the unpaid balance or $10.00, whichever is greater. Interest is forgiven on accounts that are paid off every month. Rules for Loan Applications and Loan Accounts Loan applications must receive approval by a loan officer based on customer employment and currently outstanding loan liabilities. Loan amortization is based upon a monthly loan payment consisting of both principal and interest. Customers may make advance payments, which decrease the outstanding loan balance. On an annual basis, a new amortization schedule is developed based upon the then current outstanding balance and the time remaining. An automatic loan payment service is available, which automatically deducts the payment from the checking account each month. Fig. 1. Requirements for Service First Bank.
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
This process continues throughout the JAD sessions until all areas of the new system have been identt$ed, analyzed, prototyped, and developed into a spec&ation.
shows these object classes and also shows the relationship sets between these classes. Customer has CheckingAccount and Customer has Loan are two of the five relationship sets. OSA requires each relationship-set name to include the name of each of its associated object classes. Thus, the full name of the completes relationship set in Fig. 2 is Customer completes LoanApplication. Participation constraints (the numbers on the relationship sets) are used to capture business rules about the minimum and maximum number of times objects in one class relate to objects in another class. For example, in the relationship Customer has Loan, we see that a Customer may have (may participate in) zero to many (indicated by *) loans, but that each loan must belong to exactly one customer. In our approach, we draw model instances such as the model instance in Fig. 2 using ‘Composer’, which is a workstation, OSA syntax-directed drawing tool. This is a typical syntax-directed drawing tool that has been used by many people with little or no instruction and can be used by systems analysts and users alike. Further JAD discussions enable us to discover additional objects and relationships which we add to the ORM as shown in Fig. 3. Our process is to simply name ‘things’ and see how they relate to other ‘things’ in the ORM. Also, since this is a discovery process, we are not required to have a perfect model the first time. Obviously, we try to make it correct, but we will have many opportunities to refine and correct it as we proceed. We note some additional types of constructs in Fig. 3. The object classes shown with dotted lines are called lexical object classes. Lexical objects classes contain objects that are strings of alphanumeric characters. Solid boxes represent more abstract objects. The shaded box, named LoanApplication, is called a high-level object class and represents an object class that can contain other object classes and relationship sets. This abstraction
We present this paper as an illustrative report on how a JAD session might proceed using OSA and IPOST. In Section 2, we present a set of business requirements for a bank and illustrate how we begin building an OSA model instance. In Section 3, we illustrate the use of IPOST in prototyping the preliminary model instance and making some improvements to the initial model instance. In Section 4, we introduce OSS-L and develop an OSS for a part of the bank system. In Section 5, we draw our conclusions regarding an OSS (Object-oriented Systems Specification).
2. From business requirements to an OSA model instance Fig. 1 contains a simplified set of business requirements for a bank, which we call Service First Bank. In our sample JAD session we begin by using this information, as well as any available documents from current operations, to begin constructing an OSA model instance. Since OSA is an object-oriented paradigm, normally we first identify several objects and their relationships to other objects. In OSA, we do not try to distinguish between objects and attributes of objects [9]. We do, however, categorize objects into object classes and relationships into relationship sets, and build an ObjectRelationship Model (ORM). An ORM captures structural information about object classes and relationship sets. With some initial JAD team discussion, we easily identify six major classes of objects: Customers, SavingAccounts, CheckingAccounts, CreditCardAccounts, LoanApplications, and LoanAccounts. Fig. 2
CreditCardAccount
I
1
Loan I
LoanApplication I
I
611
I
Fig. 2. Initial ORM for Service First Bank.
618
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
Fig 3. Completed ORM for Service First Bank.
mechanism allows us to consider a loan application as a single entity or as a specific collection of information. We may show the lower-level information as in Fig. 3, or we may hide the internal details and only show the LoanApplication class when that is more convenient. We also see different types of relationship sets in Fig. 3. The diamond shapes have been used to connect multiple object classes together in an n-ary relationship set, with n > 2. Even though we do not show it, the diamond can also be used on a binary relationship set. The open triangle, under LiabilityInformation, represents
generalization/specialization, which is an ISA relationship set. Any object in the specialization class also belongs to the generalization class. The dark triangles are aggregation relationship sets, sometimes referred to as part of relationship sets. This means the primary object class is made up of component parts, or is an aggregate of other classes. As we discover and capture structural information in an ORM, we also begin to discover behavioral information. By behavioral information, we mean what the objects do and how they interact with each other. As
R.B. Jackson, D. W. Embleyjlnformation and Software Technology 38 (1996) 615-631
we look at Fig. 1, we see that we have captured the structural information, but we have not captured the business rules that focus on the dynamics of bank processes. For example, how is an account opened, or how do rules for an automatic loan payment work? We capture this information in OSA submodels called the Object-Behavioral Model (OBM) and the ObjectInteraction Model (OIM). The OBM documents the complete life of an object, such as a checking account, from creation to termination. It includes all the processes (business rules) that occur during the lifetime of the checking account. The OIM documents the interactions between objects, such as deposits and withdrawals. Returning to our JAD session, we may begin this process by identifying all of the states or conditions of a particular object. Taking a loan application object as our example, we begin listing the conditions of a loan application: Completed, Waiting for verification, Waiting for manager approval, Approved, and Rejected. We call these conditions states. Next we identify what has to happen for a loan application to go from state to state. We call these transitions, and they consist of two parts: a
619
trigger, which initiates the move from one state to another, and an action, which is a business process that must be completed before the object can successfully arrive at a new state. Fig. 4 shows the result of some of our brainstorming JAD session about a loan application. States are denoted by rounded boxes and transitions are denoted by rectangular boxes with triggers in the top parts and actions in the bottom parts. Again, is it completely correct? We do not worry much about this here. We will have occasion to review and correct our work later. According to Fig. 4, a LoanApplication object comes into existence in transition (1) upon acceptance of the application. Transition (1) is called an initial transition, since it causes the creation of a new object. It also has no prior states. After creation, a loan application then enters the Completed state. When the loan officer is ready to verify the application, transition (2) fires, and the verification process begins. Verification of a valid checking account is done and requests for employment and liability information are sent to appropriate parties. The loan application then goes into a Waiting for
LoanApplication
Fig. 4. State net for LoanApplication.
620
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
verzjkation state. The solid bar labeled (6) is the final
transition. It causes the removal of the object from the object class and thus has no subsequent states. It is drawn as a solid bar because we have not, at this point, identified any trigger or action for it. We consider states to be semi-permanent conditions that are interrupted by the firing of the trigger of a subsequent transition. Transitions, on the other hand, are normally considered to be non-interruptible processes that cause the object to move to a new state. We finish our JAD session on the LoanApplication by asking what information is needed by a loan application object during the processing of its transitions, and what information is sent to other objects from the transitions. We can identify several pieces of information needed. For example, the action in transition (5) requires a particular loan application object to send a notice to the Customer and a Create Loan interaction to the Loan class upon approval of the loan application. We add these interactions, and others, to Fig. 4 to create Fig. 5. Note that for the JAD activity of adding interactions to the diagram, we identified additional classes, Employee and Manager which, we also now add to our ORM. In Fig. 6, we illustrate another example of an OIM. This OIM contains only object classes and interactions.
During our JAD discussions, we have identified some of these interactions, but are not ready to take them to the same level of detail as in Fig. 4. Rather than lose this information, we simply document it at our current level of knowledge, which only associates interactions with object classes and not transitions or states. We will add more detail, such as state nets and other interaction origin and destination information, as the JAD sessions continue. An interaction occurs between objects, normally an origin object and a destination object. If it is important to identify a particular origin or destination, we use a FROM clause or a TO clause as shown in Fig. 6. The name of the interaction describes the interaction activity. An interaction can also be used to pass objects (data or parameter objects), as seen in the figures. Working in a JAD environment with both technical and user team members enables coaching to go in both directions. The technical team members are better able to understand the business processes and the subtle nuances that are not evident from reading requirements documents such as Fig. 1. The user team members observe and participate in the development of an OSA model instance and understand technical modeling constructs such as object classes, relationship sets, states, transitions
Fig. 5. LoanApplication state net with interactions.
621
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
Employee TO: TO: Cuslomawith SSN equal to inputSSN
1
1
Fig. 6. Employee class with interactions.
and interactions. This bidirectional coaching and information flow develops a knowledgeable, productive and technically competent team.
3. OSA model instance prototyping with IPOST At any time during the discovery process, the JAD team members may decide to observe their work by executing a prototype. Unlike other approaches, which require programmers or the technical members of the team to ‘go off in a corner’ and build a prototype, with IPOST, we simply execute the OSA model instance as built using Composer. Using IPOST, prototype execution is always immediate and automatic. Fig. 7 is a snapshot of Composer, with a view of the bank system OSA model instance. The drop-down menu under the ‘Tools’ option allows us to activate IPOST by selecting the ‘Prototype’ option. Thus as frequently as desired and at any point in the development of the application model we have prototype execution available. Prototype execution consists of firing interactions (the application events) and observing the behavior of the object class objects as described by the state nets. Fig. 8 shows the main IPOST window. The top panel is used to select an interaction to fire. An interaction is selected by origin and destination class. The middle panel is used to enter data objects, origin objects or destination objects as defined by the interaction details. The bottom panel is used to identify and describe the behavior that is activated by the firing of the interaction. It provides detail information on the interaction’s destination, either a class, a state or a transition. Figs. 9a and 9b show how we begin prototype execution. Let’s start by executing the Create interaction in Fig. 6, which will create a new customer. We note that this interaction originates from the Employee class and its destination is the Customer class. IPOST organizes interactions by origin and destination class. In Fig. 9a,
we show the pull-down window which is used to select an origin object class. When we click on the Employee button, it is placed in the Origin Object Class text box as shown in Fig. 9b. The top panel of the IPOST window in Fig. 9b, shows the results of selecting the Employee class for the origin, the Customer class as the destination and finally the Create interaction as a valid interaction with these origin and destination classes. IPOST has pop-up windows for each of these selection items. In our JAD session we decide first to see if our OSA model instance will support the creation of some customers. We recognize that our model instance is rather incomplete, so prototype execution will be limited, but we still want to begin observing some of the behavior of our identified classes. Having selected the interaction we wish to work with in the top panel, if we now click on the OK. Interaction Selected button, the object descriptions in Fig. 6 from the selected interaction appear in the middle panel of Fig. 8 and the destination information, which in this simple case consists only of the destination object-class name, appears in the bottom panel. We now add object values for these object descriptions by entering sample data such as ‘William S. Jones’ for the Name and ‘1222 Fair Street, NYC, NY’ for the Address. To make this interaction fire, we click on the Execute button. Even though we have not defined a state net for the Customer class, IPOST can still execute this interaction. Every object class is assumed to have a default state net consisting of an initial transition to create an object, an Exists state and a final transition to destroy an object. IPOST automatically instantiates these default state nets when they are needed. Since the interaction name we are working with is Create, IPOST executes the interaction by assuming its destination is the initial transition. Initial transitions always cause a new object to come into existence and enter a state following the initial transition. Here, a customer object is created and placed in the Exists state.
622
R.B. Jackson, D. W. Embleyllnformation and Software Technology 38 (1996) 615431
Fig. 7. Composer with Bank Model and Tools Menu.
In Fig. 10 we show two pop-up windows with the main IPOST window as a backdrop. The bottom pop-up window shows the results of executing the Create interaction of Fig. 6. The Result window is obtained by clicking on the Display Data button under the File pull-down menu shown in Fig. 7. Notice that TABLE: Customer, which contains the members of the Customer object class, now has an entry and that TABLE: Customer.Exists, which holds the objects in the Exists state, also contains that same new customer object. Since Customer was identified as a non-lexical object, IPOST generated a value, called a surrogate value, to represent the customer. The top pop-up window in Fig. 10 shows an execution message that automatically appears whenever IPOST detects problems arising from the execution of an interaction. The result of creating a new customer as we did caused conflicts with the integrity constraints in the ORM. Participation constraints specify that every Customer must have a Name, SSN and Address. As a result of these error messages, we note that we must add the SSN to the input objects on the interaction. We must also
add appropriate action statements (which we show in the next section) on the initial transition to create the three identified relationship sets. Any of these changes we make through IPOST will also be saved back to the application model with Composer. This example illustrates the ease with which we initiate prototype execution in the JAD session. The lack of detail for the Customer class constrained us from elaborate prototyping of the behavior and rules associated with bank customers. It did, however, provide immediate feedback concerning the requirements of the Create Customer input interaction, The data content of this interaction applies directly to a ‘New Customer’ screen and thus also assists us in the definition of input screens, Similarly, output interactions define data requirements of report records and output screens. Since we have captured considerably more information about the LoanApplication class, prototype execution of the interactions and state net for that class would provide even more feedback on the quality of our work. However, we wish to do more than to just validate the
R.B. Jackson, D. W. Embleyllnformation and Software Technology 38 (1996) 615-631
623
Fig. 8. Main IPOST Window.
model through prototype execution - we want to develop a specification of the system that supports all of the relevant business rules. We therefore now show how to expand our prototyping experience to include specification development.
4. Developing the specification Most JAD approaches are used to extract and define user requirements. In our previous section, we have shown how we have been able to increase the utility of a JAD session by the addition of prototyping tools which allow us to immediately execute the application model. However, we desire to further increase JAD utility by developing a formal specification as part of the JAD activities. The purpose of a specification is to document the business rules in terms of the functions and data of a solution system and to serve as the ‘contract’ for the development of the automated system. As such, we want it to be as precise as possible. We obtain precision through formal models and languages. Thus the ‘best’ specification is a formal specification because it is the most precise.
However, users are not normally familiar with formal specification languages, so they are seldom able to help develop, or frequently even read, formal specifications. In our approach, the users are integrally involved in the development of the formal specifications. In our approach, an OSA model, which has a formal foundation based on set theory and first-order predicate calculus [IO], with all natural language components written in OSS-L comprises the formal specification. For example, the state net in Fig. 4 for the LoanApplication class has considerable natural language (in this case English) statements embedded in the diagram. Our task, then, for specification development, is to replace natural-language statements with formal, executable statements. We write these formal statements in OS&-L (Objectoriented Systems Specification Language). OSS-L has an English-like syntax so that client members of the JAD team are also able to learn and understand it as they work with and are coached by the more technical members of the team. The natural-language statements we replace with OSS-L statements are transition triggers, actions, interaction TO clauses, and general constraints. In Fig. 5, for example, all TO clauses, triggers, and
624
R.B. Jackson, D. W. Embleyjlnformation and Software Technology 38 (1996) 615-631
Fig. 9. (a) Popup window of possible origin object classes. (b) IPOST for Create customer interaction.
actions are written in natural language and can be replaced with OSS-L statements. We also achieve additional benefits from the introduction of OSS-L. First, the prototype becomes more functional. OSS-L statements can be interpreted and executed by IPOST. With the introduction of OSS-L statements, the OSA model instance can become a fully functional prototype. Thus, the users who are participating in the JAD sessions are able to observe and verify how the system handles business-rule requirements. Second, we have observed that the very process of thinking about and writing OSS-L statements forces all the JAD team members to think more precisely about exactly what is meant by a possibly vague business
rule. Considerable improvement in the definition is achieved even prior to prototype execution. There are two ways to insert OSS-L statements into a model instance: either through Composer or through IPOST. Generally, it works better, especially for JAD members just learning the syntax to use IPOST. The user can write OSS-L statements to replace natural language statements and let IPOST verify the syntax and demonstrate successful execution. This approach lets the user verify both the correctness of the syntax and the execution at the same time. OSS-L statements are based primarily on the constructs already defined in the OSA model instance, i.e. class names, relationship-set names, interaction names,
625
R.B. Jackson, D. W. Embleyllnformation and Software Technology 3X (1996) 615-631
Fig. 10. IPOST showing
and so forth. OSS-L uses these modeling names in conjunction with programming language constructs to describe the functions and procedures of the system. Thus, OSS-L also contains concepts such as variables, expressions, reserved words, and control statements. OSS-L statements consist of (1) OSA Terms; (2) Reserved words and operators; (3) Variable names; and (4) Miscellaneous connectors. In OSS-L statements, object-class names are single words followed by a set of parentheses, such as Customer(). Since class names are part of relationshipset names and relationship-set names are unconstrained sentences, class names are required to be a single word, as is LoanApplication(). This permits OSS-L to be an unambiguous language. As with other programming languages, a variable is bound to different values. A variable must always be associated with a class name by being inside the parentheses appended to the class name. For example. Customer(x) and LoanApplication(loanapp) identify the variables x and loanapp, which, during prototype execution will be bound to particular objects, x to customer objects and loanapp to loan-application objects, Once a variable has been identified as being
error and results windows
associated with a class, it may be used within an expression by itself. Fig. 11 gives a complete list of all OSS-L constructs, including all the keywords. We write the keywords using all capitals for ease of identification. However, OSS-L is not case sensitive. With this brief introduction to OSS-L syntax, let’s return to our JAD session and write some OSS-L statements. We begin with simple statements, and add complexity with later examples. Fig. 12 shows the simple state net that IPOST created when we began prototype execution. In Fig. 10, IPOST identified three participation-constraint errors from the creation of a new customer object. The OSS-L action statement within the initial transition must create name, address and SSN objects. It may also create the relationships between the new customer object and these newly created objects. The following OSS-L statement creates the new objects and places them in their object classes. Create Name(name),
SSN(ssn),
Address(address);
Create is an OSS-L keyword. The identifiers in parentheses are the variables and are associated with specific class names. Variables are either bound to a value prior to execution of an OSS-L statement or they are bound
626
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
OBJECT-CLASS NAMES Class names are always written with parentheses which may optionally contain a variable name: Classname(Variablename). Class names may also use the variable keyword name SELF. Class names may be used with a WHERE clause: class name WHERE relationship-set name (see below). RELATIONSHIP-SET NAMES Relationship set names are the same as in the ORM except that the embedded object-class names have parentheses. Relationship-set names may be used with a WHERE clause. CONDITIONS Conditions are predicates that can be tested for true or false. The following are predicates: Object-Class names Relationship-Set names Class Name INSTATE list of states Class Name INTRANS list of transitions Class Name INPRIOR list of states Expression comparators: =, >, < >=, <=, <> Event Trigger: @Identifier The following boolean connectors are used with conditions: AND, OR, IMPLIES, NOT ACTION CLAUSES The following clauses are used in action statements. CREATE list of classnames or relationship-set names; ADD list of classnames or relationship-set names; REMOVE list of classnames or relationship-set names; DESTROY list of classnames or relationship-set names; REPLACE object-class name or relationship-set name BY object-class name or relationship-set name; SEND interaction description (parameter list) TO clause; IF condition THEN set of clauses ELSE set of clauses ENDIF; WHILE condition DO set of clauses ENDDO; DO set of clauses UNTIL condition ENDDO; FOR loop symbol DO set of clauses ENDDO; TOSTATE list of states FUNCTIONS COUNT (object-class name or relationship-set name) MAX (object-class name) MIN (object-class name) TYPE DECLARATION STATEMENTS DECLARE object-class name (variable name) DATETYPE; similarly for TIMETYPE, INTEGER, REAL, LEXICAL. EXPRESSIONS Assignment: class or variable name : = expression Expressions: include variables, integers, reals and the following operations +, -, *, /. Fig. 11. Summary of the syntax of OSS-L.
during execution. In this instance, name, ssn and address come from the object descriptions on the Create interaction and are bound to the data that is entered through IPOST when the interaction fires. We do not include a Customer() object class in the create statement because IPOST automatically creates this new object when the initial transition fires. The following OSS-L statement creates the required relationships to satisfy the participation constraints. The keyword self is a variable that is always automatically bound to the object whose state net is executing.
Create Customer(self has Name(name), Customer (sew) has SSN(ssn), Customer(self has Address(address);
Fig. 13 shows these two OSS-L statements combined together within the transition action. Next, we desire to formalize the final transition for the Customer state net. Our first step is to formalize the Remove interaction. The Rembve interaction must be sent to a particular object, as noted by the TO clause TO: Customer who has SSN equal to input SSN. We formalize this clause with the following TO: Customer(x)
WHERE Customer(x)
has SSN(ssn).
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
/ Fig. 12. Customer default
with SSN equal IO lnpul SSN
state net.
With these changes, the Customer state net is now formalized, allowing complete execution using IPOST. We select and fire the Create interaction, select and fire other interactions which are related to the customer object, and finally we fire the Remove interaction. However, the Remove interaction produces error messages. We note that a customer object may have other, optional, relationships. A customer object cannot be deleted while it still has relationships to SavingsAccount, CheckingAccount, CreditCardAccount, or Loan objects. Now the JAD team members must determine the business rules which control the removal of accounts and customers. ‘Must accounts be deleted
The WHERE keyword introduces a modifying clause in the OSS-L syntax, which must be satisfied. Firing the interaction requires the IPOST user to provide a specific value for ssn, which then determines a value for x in the relationship Customer(x) has SSN(ssn). The x is then bound to the correct customer object. We next write OSS-L statements for the transition action. As our first cut, we simply replace the Create keyword with a Destroy keyword: Destroy Name(name), Destroy Customer(selfl Customer(self Customer(selJ)
TO:TO:Customer
SSN(ssn), Address(address); has Name(name), has SSN(ssn), has Address(address);
3Jstomer
lgR-e
AND NOT (Cuelomor(sel0 has ChecldnoAarwnlO k
Desl& Cust&(di)
has Nine(Nam~).
’
621
TO: TO: Cudomer(x) WHERE Curtomw(x) has SSN(sH)
.’
Ctstomer(selI) has Addmee(Addmss). CusIomer(selt) has SSN(SSN):
Fig. 13. Customer formal
state net.
628
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
before customers? Can accounts be deleted concurrently with removal of customers, if the balance is zero? Are there tax and legal ramifications that must be considered before customers can be removed? Does the removal of an active customer require archival information to be sent somewhere? These kinds of questions must be answered before the system specification of the final transitions can be completed. Prototype execution with IPOST will force these issues to be addressed during the JAD session while key players are easily accessible. Since our objective in this paper is to demonstrate OSS-L, we keep the problem definition simple and require only that before removing a customer object, all optional relationships must have been removed by prior interactions and actions. In this case, we simply enhance the trigger for the transition to ensure they have been removed before removing a customer and its required relationships. Fig. 13 gives the enhanced trigger with both an event (@Remove) and the conditional test. The conditional test says that if the particular customer associated with selfparticipates in any of the relationship sets in question, then the condition will not hold and the trigger will not fire. Since the LoanApplication class has a more complex state net, we will illustrate a few more aspects of OSS-L by formalizing that state net. We begin with transition (1) from Fig. 5. First we formalize the trigger. An event trigger is formal when its descriptor matches the input interaction. Thus, placing @Submit LoanApplication in the trigger formalizes it. The informal action statement for transition (1) is empty. However, looking at the ORM in Fig. 3, we notice several classes that require objects whenever a loan application is created. These include, for example, EmployerName, LoanCustomer, MonthlyIncome, (if applicable). Amount, and LiabilityInformation Hence, we must create objects and relationships for these objects. Information for all of these objects must also be available from the input interaction Submit LoanApplication. Part of prototype execution will also include any required modifications to the interaction. Generally the order of creating objects and relationships is not important, as long as we ensure that the unbound variables are bound before they are used. Input parameters are bound prior to execution and the variable self is always bound to the destination object. First, we attach the customer to the loan application: Create Customer(x) completes LoanApplication(self Where Customer(x) has SSN(ssn); In this case, x is bound based on the input value ssn, which we notice must also be supplied in the incoming interaction. Next we write statements to create the lexical objects that are passed as input parameters with the Submit LoanApplication interaction.
Create LoanAmount(loanAmount), MonthlyIncome (monthlylncome), EmployerName(employerName); For our next statements, we note in Fig. 3 that the relationship set LoanApplication contains LiabilityInformation has a participation constraint of O:*, meaning that there may be from none to many outstanding loans. In this case, the input interaction identifies the number of car loans and the number of home loans. We use this information to crate a FOR loop so that we create the correct number of sets of loan information. Each set of loan information will contain an abstract object, either CarLoanInfo or HomeLoanInfo, and lexical objects for Institution, MonthlyPayment, Balance, and RemainingPayments. FOR loan# FROM 1 TO NumberOfCarLoans (numberOfCarLoans) DO Create CarLoanInfo(y) f loan#]; Create Institution(institution) [loan#], A4onthlyPayment(monthlyPayment)[loan#], RemainingPayments(remainingPayments)[loan# Balance (balance) [loan#]; Create CarLoanInfo(y)[loan#]‘has Institution(institution)[loan#], CarLoanInfo(y) [loan#] has MonthlyPayment(monthlyPayment)[loan#], CarLoanInfo (y) [loan#] has RemainingPayments(remainingPayments)rloan#], CarLoanInfo(y)[loan#] has Balance (balance) [loan#]; Create LoanApplication(self) contains LiabilityInformation(y)[loan#]; ENDDO;
J,
We would use a similar loop to create the information for home loans. The only difference is that we would need to use a different variable, such as z, with the HomeLoanlnfo class. The FOR statement in OSS-L provides several services. First, it identifies an integer symbol, which is not part of the OSA model instance, but is simply a programming construct. Then, it loops through the statements contained within the DO block varying loan# from one to NumberOfCarLoans. The brackets at the end of each class name do not affect the class or variable bindings. They simply indicate which element in a set of multiple values to use for this iteration through the loop. The FOR loop creates the required objects and relationships in the prototype. IPOST does another service for us here. Since CarLoanZnfo and HomeLoanInfo are specializations of the general class LiabilityInformation, IPOST automatically creates objects in the generalization class. In OSS-L we access these generalization objects with the same variable name as used in the specialization class, i.e. LiabilityInformation(y). Thus we use LiabilityInformation[loan#] in the last Create statement to connect it to
R.B. Jackson, D. W. Embleyllnformation
and Software Technology 38 (1996) 615-631
LoanApplication. Fig. 14 shows how we make these changes using IPOST. We enter them into the bottom panel in the IPOST depiction of transition (1). Upon execution, IPOST validates the syntax and executes the statements. At this point in our analysis, we do not worry about the layout or format of the output interactions. We focus our efforts on the business need of how many different outputs there may be and what information is required on each. Even when we begin prototyping, we want to verify the correctness of the problem definition before we begin to dilute our efforts too much on field layout and format. Fig. 15 shows the entire formalized state net for the LoanApplication object class. Transition (2) illustrates OSS-L constructs. The IF... several more THEN.. . ELSE statement, provides normal decision logic. The SEND statement fires an internal interaction. We have used IPOST to fire some interactions, especially those whose origin is an external object class like Customer or Employee. OSS-L and IPOST will also automatically fire internal interactions when they appear in an action statement with the SEND command. Finally, we note the TOSTATE command is used to
select a particular path out of a transition. In this instance, its use in conjunction with decision logic, indicates an exception condition. Continuing in this fashion, the JAD team can formalize all the state net in Fig. 5. In Fig. 15, we show the formalization of the entire LoanAppkcation state net. The state net, as formalized, is completely executable by IPOST. Input interactions and the appropriate logic are defined to create a new loan application, to send out verification forms, to update the employment and status fields, to approve or reject the loan, and to notify the customer. The process of formalizing this state net by the JAD team members required a combination of ORM analysis (Fig. 3), state net review (Fig. 5) and modifications made through IPOST (Fig. 14). IPOST provides the support to make the changes easily and to verify the changes with prototype execution. Working sessions frequently shift between discussing business rules, enhancing the model instance with Composer, entering OSS-L statements and reviewing the results of prototype execution. This analysis and specification process ends when the JAD team agrees that the specification is complete. This does not necessarily mean that every statement must be
@Submit LoanApplication
Fig. 14. Formalizing
629
transition
(1).
630
R.B. Jackson, D. W. Embleyllnformation and Software Technology 38 (1996) 615-631
Fig. 15. Formalized LoanApplication state net.
in formal OSS-L syntax. It does mean, however, that both the user and the developer members of the JAD team agree that it has sufficient detail to move into design and implementation.
5. Conclusions The JAD approach has grown in popularity over the past ten years. It has proven to be an effective method to do systems development. However, historically, support
for JAD activities has mostly been with ‘low-tech’ tools, such as white boards, hip charts, and projectors. More recently, middle-tech tools such as CASE tools with screen painters and group decision software have helped increase JAD productivity [5]. The inclusion of prototyping requires that JAD sessions be interrupted while prototypes are built and tested. These interruptions, however, diminish the effectiveness of JAD, which relies on a continuous flow of communication and understanding between users and software engineers. Our research is focused toward increasing the effectiveness of JAD
R.B. Juckson.
D. W. Embiey/lnformation
development by improving the level of technical support and by raising the precision and formality of the JAD results. We make two contributions which increase JAD effectiveness. First, since the OSA model is formally defined and executable, we provide analysis model prototyping as an integral part of the analysis discovery process. Execution of the analysis model permits viewing of potential solution system behavior without having to do system design tasks such as file design. In addition, prototyping is done concurrently with analysis and does not require the adjournment of JAD sessions while the prototype is being built and tested. The second contribution is the introduction of a formal analysis model and specification language. One of the stated benefits of the object-oriented approach is that it is a natural and intuitive way to model ‘real-world’ systems. OSA has the additional benefit that it has a formal foundation. The formal foundation provides precise execution semantics and permits prototyping CASE tools such as IPOST to be built. Additionally, we extend the analysis model into the specification model with the inclusion of OSS-L statements. The output of JAD sessions does not normally include formal specifications because formal specification languages are usually too difficult for users to read and write. However, since OSS-L extends the OSA model in a straightforward way, with some cross-training provided in the JAD sessions, users should be able to assist in the development of the formal specifications. Our contribution is to allow more formal and technical results from the JAD sessions. In the introduction, we listed seven analysis-phase tasks [6], which have associated deliverables, that potentially are the responsibility of the user. The first four of these tasks/deliverables should be initiated prior to the JAD sessions. Preliminary requirements on these four items lay the foundation for successful JAD sessions. The deliverables for the last three of these tasks, as well as refinement to the previous four deliverables, are accomplished through the JAD sessions by the development of an Object-oriented Systems Specification (OSS). Beyond these seven analysis-phase tasks, we also have a few additional observations. Our approach to the development of specifications can produce very detailed model instances and can be a lot of work. However, the alternative of building systems with incomplete or vague specifications ultimately may cause more work and be more expensive. Generating detailed specifications requires us to think about the details early and avoid many of the costs of rework and rethink. A JAD approach, with the proper support tools, puts the right players together at the right time in the project. Support tools, such as Composer and IPOST, mitigate the burden of detail work and eliminate the delay of prototype programming. Furthermore, a formal high-level language such as OSS-L helps team members think carefully
und Sqftbvare Technology
38 (1996) 615-631
631
about specification details and document business rules precisely. In our research, we are striving to make the support tools easier to use. For example, we are pursuing methods to make prototyping and specification generation even easier. One area is to include ‘expert system’ logic that can automatically generate OSS-I, statements to create the appropriate Create and Remove statements. We are also pursuing paths to integrate the several CASE tools we are developing into an IntegratedCASE environment. Back end CASE support such as automatic program generation is also under development. Currently we have defined a complete programming language and are in the process of building the tools that will later integrate with IPOST and Composer. We believe that with the proper models and tools a JAD approach is very workable. Even though the primary result of a JAD approach is a higher quality product, of almost equal importance is the level of communication engendered between users and developers. Both kinds of team members can have a good understanding of business requirements. Both can also read and understand technical models and more formal specification languages such as OSA and OSS-L. The result is not only a better product, but also enhanced expertise and confidence of all JAD team members.
References [l] Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House Publishing, 1989. [2] Robert Jackson and David Embley, Rapid prototypes that are truly rapid and truly prototypes, Technical Report, Computer Science Department, Brigham Young University, 1994. [3] Carolyn Shamlin. A User’s Guide for Defining Software Requirements: The Othr Side of Software. QED Information Sciences. Inc., 1989. [4] Judy H. August, Joint Application Design: The Group Session Approach to System Design, Yourdon Press, 1991. [5] Erran Carmel, Randall D. Whitaker and Joey F. George, PD and joint application design: a transatlantic comparison, Comm. ACM, 39 (June 1993) 41-48. [6] Jane Wood and Denise Silver, Joint Application Design: How to Design Quality Systems in 40% Less Time, John Wiley, 1989. [7] David W. Embley, Barry D. Kurtz and Scott N. Woodfield, Object-Oriented Systems Analysis: A Model-Driven Approach, Yourdon Press, 1992. [S] Guido Gryczan and Dar1 Dautz, A comparative case study of prototyping tools ~ experiences and conclusions. IEEE Int. Conf. on Computer Systems and Software, 1’990, pp. 4944501. [9] David W. Embley, Stephen W. Liddle and Scott N. Woodfield. Attributes: should we eliminate them from semantic and objectoriented data models?, Proc. 22nd Ann. Computer Science Conf., March 1994, pp. 340-347. [lo] Stephen W. Clyde, David W. Embley and Scott N. Woodfield, The complete formal definition for the syntax and semantics of OSA. Technical Report BYU-CS-92-2, Department of Computer Science, Brigham Young University, 1992.
Information and Software Technology 38 (1996) 615-631
Using joint application design to develop readable formal specifications Robert B. Jackson*, David W. Embley* Department
of Cornpurer Science, Brigham
Young University,
Provo, UT 84602, USA
Received 8 September 1994; revised 3 May 1995; accepted
12 July 1995
Abstract
A requirements specification is a ‘contract’ between a client and a systems developer. This document is frequently written in some type of ‘computerese’ or formal specification that is unintelligible to most clients. Why can’t we have a precise, formal specification that is understandable? In fact, why can’t we let the client take charge of developing a formal specification? In this paper, we present OSS (Object-oriented Systems Specification), a graphical model with an embedded textual language that has a formal foundation, is suitable for requirements specification, and is understandable to at least technically oriented clients. We also introduce IPOST, a prototyping/specification tool to assist the client. We describe a Joint Application Development (JAD) scenario utilizing OSS and IPOST that involves heavy client participation in the development of formal requirements specifications. Keywords;
Requirements specifications; Joint application design; Rapid prototyping
1. Introduction
In their delightfully refreshing book Expforing Requirements: Quality Before Design [l], Donald Gause and Gerald Weinberg express the essence of the requirements-specification problem: ‘If you tell what you want, you’re quite likely to get it. If you don’t tell what you want, you’re quite unlikely to get it.’ The problem seems to be that either users do not tell developers exactly what they want, or developers do not hear what users say they want. Thus, our first definition: Requirements = What users want. Along with this definition comes a difficult question: How do developers find out what users want, and how do they document it? This leads us to our second definition: Specification = written documentation of what users want, in terms of a solution system. Thus, a specification comes from and extends the requirements into a proposed solution system. In the traditional view of software development, it is the responsibility of the technical team to do systems analysis and to develop the specification documents. The analysts strive to understand the user’s business needs and document those in a precise specification. User involvement is limited to expressing needs, verifying * email:Cjacks@osm., embley@}cs.byu.edu 0950-5849/96/$15.00 0 1996 Elsevier Science B.V. All rights reserved SSDZ 0950-5849(95)01058-O
the suitability of the specification and ‘signing off on the written specification. In many instances user needs can be more accurately identified through a rapid prototype. The technical staff ‘rapidly’ builds a partial model of the system using a CASE tool or some high-level language. Users ‘run’ the prototype and observe whether the form and function of the prototype accurately represent their needs. Where applicable and with the right tools, this approach improves the quality of the resultant specification [2]. The technical staff, however, maintains respdnsibility for creating the prototype and writing the specifications. In recent years, this traditional view has been challenged. In her insightful book A User’s Guide for Dejining Software Requirements [3], for example, Carolyn Shamlin provides a user oriented view of the systems development life cycle. She identifies seven tasks in the analysis phase and insists that all are the responsibility of the user team, not the technical staff: (1) Define external systems needs; (2) Establish systems goals and objectives; (3) Specify basic and optional features; (4) Determine information requirements; (5) Specify interface requirements; (6) Specify data relationships; (7) Specify processing requirements. A compromise approach, being used by some companies, gives users and technical staff equal responsibility for requirements definition. This approach is called Joint
616
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
Application Design (JAD) [4-61. The goal of the JAD approach is to produce higher quality software in an accelerated time by having both users and analysts accept responsibility and become heavily involved in the system development. The JAD approach is conducted through a series of meetings called JAD sessions. In a typical JAD approach a JAD team leader, who may be an analyst, a user or a specially trained facilitator, is selected, and a single team, consisting of users and systems analysts, is formed. This team meets in a single JAD session or in multiple JAD sessions. Each session usually lasts several days. A major benefit of this approach is that the analysis, or discovery, of the business needs is usually thorough and complete. The result of these JAD sessions is a comprehensive statement of system requirements. In support of this JAD approach, we have developed an analysis model, a specification language, and several accompanying computer-based tools. The analysis model, called Object-oriented Systems Analysis (OSA), and the specification language, called Object-oriented Systems Specification Language (OSS-L), are based on the object-oriented paradigm and are used together to provide an integrated analysis model and specification document [7,8]. The main accompanying tools are the OSA Composer, which assists users in creating OSA models instances, and IPOST, which automatically builds working prototypes based on OSA model instances. The focus of this paper is to show how a formal Object-oriented Systems Specification (OSS) can be
developed from an initial set of business requirements. We identify three major types of activities in this process: One activity is the analysis, which is a discovery and model building activity. Another activity is prototype execution, which is a verification and refinement activity. The third activity is specification development, which also includes verification and refinement, and additionally encompasses documentation and ‘contractual’ agreement. One of the major contributions of our approach is the integration of JAD with the development of formal specifications. In typical JAD sessions, these three activities are intermingled. The following hypothetical, but realistic, scenario illustrates the process: For two hours in the morning, the JAD team members review business requirements and begin developing an OSA model instance. Then, after some preliminary model components have been identiJied, the team members sit down at computers and use IPOST to execute the preliminary OSA model instance. Execution of the prototype uncovers several areas that are poorly defined and after about an hour, the team members continue with business requirements review and model building. This continues through most of the day, but by mid-afternoon, a couple of members of the team, a user and a systems analyst, are ready to begin refining portions of the OSA model instance into the SpeciJication. Again they utilize IPOST to execute the OSA model instance, and to add OSS-L statements to make it a formal, executable, precisely defined SpeciJication.
Service First Bank: Description of Operations. The Service First Bank is a locally owned bank that services a small community in the midwest. It provides basic services including savings accounts, checking accounts, credit card accounts and loan accounts. Every customer must have a checking account in order to have a credit or loan account. Accounts may be jointly owned, and a customer may have multiple accounts. Rules for Savings Accounts Anyone may open a savings account with an initial deposit of $10.00. Interest is accrued daily based on the daily balance at a rate which is set from time to time by the bank executive committee. Cash deposits are credited immediately, but check deposits are not credited until the check clears. Withdrawals may be made at any time for any amount. Rules for Checking Accounts Anyone over 16 may open a checking account. No interest is paid on this account. A customer may have automatic monthly withdrawals made for loan payments. An automatic overdraft service is provided for those customers who have a credit card account. Deposits are processed the same as for savings accounts. Rules for Credit Card Accounts Credit card accounts are available to any customer who has a checking account. Each account has a credit limit which may be increased upon request by a customer with good credit history. Interest is accrued on a daily basis. Monthly bills include interest and principal amount. Payment on the principal is 10% of the unpaid balance or $10.00, whichever is greater. Interest is forgiven on accounts that are paid off every month. Rules for Loan Applications and Loan Accounts Loan applications must receive approval by a loan officer based on customer employment and currently outstanding loan liabilities. Loan amortization is based upon a monthly loan payment consisting of both principal and interest. Customers may make advance payments, which decrease the outstanding loan balance. On an annual basis, a new amortization schedule is developed based upon the then current outstanding balance and the time remaining. An automatic loan payment service is available, which automatically deducts the payment from the checking account each month. Fig. 1. Requirements for Service First Bank.
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
This process continues throughout the JAD sessions until all areas of the new system have been identt$ed, analyzed, prototyped, and developed into a spec&ation.
shows these object classes and also shows the relationship sets between these classes. Customer has CheckingAccount and Customer has Loan are two of the five relationship sets. OSA requires each relationship-set name to include the name of each of its associated object classes. Thus, the full name of the completes relationship set in Fig. 2 is Customer completes LoanApplication. Participation constraints (the numbers on the relationship sets) are used to capture business rules about the minimum and maximum number of times objects in one class relate to objects in another class. For example, in the relationship Customer has Loan, we see that a Customer may have (may participate in) zero to many (indicated by *) loans, but that each loan must belong to exactly one customer. In our approach, we draw model instances such as the model instance in Fig. 2 using ‘Composer’, which is a workstation, OSA syntax-directed drawing tool. This is a typical syntax-directed drawing tool that has been used by many people with little or no instruction and can be used by systems analysts and users alike. Further JAD discussions enable us to discover additional objects and relationships which we add to the ORM as shown in Fig. 3. Our process is to simply name ‘things’ and see how they relate to other ‘things’ in the ORM. Also, since this is a discovery process, we are not required to have a perfect model the first time. Obviously, we try to make it correct, but we will have many opportunities to refine and correct it as we proceed. We note some additional types of constructs in Fig. 3. The object classes shown with dotted lines are called lexical object classes. Lexical objects classes contain objects that are strings of alphanumeric characters. Solid boxes represent more abstract objects. The shaded box, named LoanApplication, is called a high-level object class and represents an object class that can contain other object classes and relationship sets. This abstraction
We present this paper as an illustrative report on how a JAD session might proceed using OSA and IPOST. In Section 2, we present a set of business requirements for a bank and illustrate how we begin building an OSA model instance. In Section 3, we illustrate the use of IPOST in prototyping the preliminary model instance and making some improvements to the initial model instance. In Section 4, we introduce OSS-L and develop an OSS for a part of the bank system. In Section 5, we draw our conclusions regarding an OSS (Object-oriented Systems Specification).
2. From business requirements to an OSA model instance Fig. 1 contains a simplified set of business requirements for a bank, which we call Service First Bank. In our sample JAD session we begin by using this information, as well as any available documents from current operations, to begin constructing an OSA model instance. Since OSA is an object-oriented paradigm, normally we first identify several objects and their relationships to other objects. In OSA, we do not try to distinguish between objects and attributes of objects [9]. We do, however, categorize objects into object classes and relationships into relationship sets, and build an ObjectRelationship Model (ORM). An ORM captures structural information about object classes and relationship sets. With some initial JAD team discussion, we easily identify six major classes of objects: Customers, SavingAccounts, CheckingAccounts, CreditCardAccounts, LoanApplications, and LoanAccounts. Fig. 2
CreditCardAccount
I
1
Loan I
LoanApplication I
I
611
I
Fig. 2. Initial ORM for Service First Bank.
618
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
Fig 3. Completed ORM for Service First Bank.
mechanism allows us to consider a loan application as a single entity or as a specific collection of information. We may show the lower-level information as in Fig. 3, or we may hide the internal details and only show the LoanApplication class when that is more convenient. We also see different types of relationship sets in Fig. 3. The diamond shapes have been used to connect multiple object classes together in an n-ary relationship set, with n > 2. Even though we do not show it, the diamond can also be used on a binary relationship set. The open triangle, under LiabilityInformation, represents
generalization/specialization, which is an ISA relationship set. Any object in the specialization class also belongs to the generalization class. The dark triangles are aggregation relationship sets, sometimes referred to as part of relationship sets. This means the primary object class is made up of component parts, or is an aggregate of other classes. As we discover and capture structural information in an ORM, we also begin to discover behavioral information. By behavioral information, we mean what the objects do and how they interact with each other. As
R.B. Jackson, D. W. Embleyjlnformation and Software Technology 38 (1996) 615-631
we look at Fig. 1, we see that we have captured the structural information, but we have not captured the business rules that focus on the dynamics of bank processes. For example, how is an account opened, or how do rules for an automatic loan payment work? We capture this information in OSA submodels called the Object-Behavioral Model (OBM) and the ObjectInteraction Model (OIM). The OBM documents the complete life of an object, such as a checking account, from creation to termination. It includes all the processes (business rules) that occur during the lifetime of the checking account. The OIM documents the interactions between objects, such as deposits and withdrawals. Returning to our JAD session, we may begin this process by identifying all of the states or conditions of a particular object. Taking a loan application object as our example, we begin listing the conditions of a loan application: Completed, Waiting for verification, Waiting for manager approval, Approved, and Rejected. We call these conditions states. Next we identify what has to happen for a loan application to go from state to state. We call these transitions, and they consist of two parts: a
619
trigger, which initiates the move from one state to another, and an action, which is a business process that must be completed before the object can successfully arrive at a new state. Fig. 4 shows the result of some of our brainstorming JAD session about a loan application. States are denoted by rounded boxes and transitions are denoted by rectangular boxes with triggers in the top parts and actions in the bottom parts. Again, is it completely correct? We do not worry much about this here. We will have occasion to review and correct our work later. According to Fig. 4, a LoanApplication object comes into existence in transition (1) upon acceptance of the application. Transition (1) is called an initial transition, since it causes the creation of a new object. It also has no prior states. After creation, a loan application then enters the Completed state. When the loan officer is ready to verify the application, transition (2) fires, and the verification process begins. Verification of a valid checking account is done and requests for employment and liability information are sent to appropriate parties. The loan application then goes into a Waiting for
LoanApplication
Fig. 4. State net for LoanApplication.
620
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
verzjkation state. The solid bar labeled (6) is the final
transition. It causes the removal of the object from the object class and thus has no subsequent states. It is drawn as a solid bar because we have not, at this point, identified any trigger or action for it. We consider states to be semi-permanent conditions that are interrupted by the firing of the trigger of a subsequent transition. Transitions, on the other hand, are normally considered to be non-interruptible processes that cause the object to move to a new state. We finish our JAD session on the LoanApplication by asking what information is needed by a loan application object during the processing of its transitions, and what information is sent to other objects from the transitions. We can identify several pieces of information needed. For example, the action in transition (5) requires a particular loan application object to send a notice to the Customer and a Create Loan interaction to the Loan class upon approval of the loan application. We add these interactions, and others, to Fig. 4 to create Fig. 5. Note that for the JAD activity of adding interactions to the diagram, we identified additional classes, Employee and Manager which, we also now add to our ORM. In Fig. 6, we illustrate another example of an OIM. This OIM contains only object classes and interactions.
During our JAD discussions, we have identified some of these interactions, but are not ready to take them to the same level of detail as in Fig. 4. Rather than lose this information, we simply document it at our current level of knowledge, which only associates interactions with object classes and not transitions or states. We will add more detail, such as state nets and other interaction origin and destination information, as the JAD sessions continue. An interaction occurs between objects, normally an origin object and a destination object. If it is important to identify a particular origin or destination, we use a FROM clause or a TO clause as shown in Fig. 6. The name of the interaction describes the interaction activity. An interaction can also be used to pass objects (data or parameter objects), as seen in the figures. Working in a JAD environment with both technical and user team members enables coaching to go in both directions. The technical team members are better able to understand the business processes and the subtle nuances that are not evident from reading requirements documents such as Fig. 1. The user team members observe and participate in the development of an OSA model instance and understand technical modeling constructs such as object classes, relationship sets, states, transitions
Fig. 5. LoanApplication state net with interactions.
621
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
Employee TO: TO: Cuslomawith SSN equal to inputSSN
1
1
Fig. 6. Employee class with interactions.
and interactions. This bidirectional coaching and information flow develops a knowledgeable, productive and technically competent team.
3. OSA model instance prototyping with IPOST At any time during the discovery process, the JAD team members may decide to observe their work by executing a prototype. Unlike other approaches, which require programmers or the technical members of the team to ‘go off in a corner’ and build a prototype, with IPOST, we simply execute the OSA model instance as built using Composer. Using IPOST, prototype execution is always immediate and automatic. Fig. 7 is a snapshot of Composer, with a view of the bank system OSA model instance. The drop-down menu under the ‘Tools’ option allows us to activate IPOST by selecting the ‘Prototype’ option. Thus as frequently as desired and at any point in the development of the application model we have prototype execution available. Prototype execution consists of firing interactions (the application events) and observing the behavior of the object class objects as described by the state nets. Fig. 8 shows the main IPOST window. The top panel is used to select an interaction to fire. An interaction is selected by origin and destination class. The middle panel is used to enter data objects, origin objects or destination objects as defined by the interaction details. The bottom panel is used to identify and describe the behavior that is activated by the firing of the interaction. It provides detail information on the interaction’s destination, either a class, a state or a transition. Figs. 9a and 9b show how we begin prototype execution. Let’s start by executing the Create interaction in Fig. 6, which will create a new customer. We note that this interaction originates from the Employee class and its destination is the Customer class. IPOST organizes interactions by origin and destination class. In Fig. 9a,
we show the pull-down window which is used to select an origin object class. When we click on the Employee button, it is placed in the Origin Object Class text box as shown in Fig. 9b. The top panel of the IPOST window in Fig. 9b, shows the results of selecting the Employee class for the origin, the Customer class as the destination and finally the Create interaction as a valid interaction with these origin and destination classes. IPOST has pop-up windows for each of these selection items. In our JAD session we decide first to see if our OSA model instance will support the creation of some customers. We recognize that our model instance is rather incomplete, so prototype execution will be limited, but we still want to begin observing some of the behavior of our identified classes. Having selected the interaction we wish to work with in the top panel, if we now click on the OK. Interaction Selected button, the object descriptions in Fig. 6 from the selected interaction appear in the middle panel of Fig. 8 and the destination information, which in this simple case consists only of the destination object-class name, appears in the bottom panel. We now add object values for these object descriptions by entering sample data such as ‘William S. Jones’ for the Name and ‘1222 Fair Street, NYC, NY’ for the Address. To make this interaction fire, we click on the Execute button. Even though we have not defined a state net for the Customer class, IPOST can still execute this interaction. Every object class is assumed to have a default state net consisting of an initial transition to create an object, an Exists state and a final transition to destroy an object. IPOST automatically instantiates these default state nets when they are needed. Since the interaction name we are working with is Create, IPOST executes the interaction by assuming its destination is the initial transition. Initial transitions always cause a new object to come into existence and enter a state following the initial transition. Here, a customer object is created and placed in the Exists state.
622
R.B. Jackson, D. W. Embleyllnformation and Software Technology 38 (1996) 615431
Fig. 7. Composer with Bank Model and Tools Menu.
In Fig. 10 we show two pop-up windows with the main IPOST window as a backdrop. The bottom pop-up window shows the results of executing the Create interaction of Fig. 6. The Result window is obtained by clicking on the Display Data button under the File pull-down menu shown in Fig. 7. Notice that TABLE: Customer, which contains the members of the Customer object class, now has an entry and that TABLE: Customer.Exists, which holds the objects in the Exists state, also contains that same new customer object. Since Customer was identified as a non-lexical object, IPOST generated a value, called a surrogate value, to represent the customer. The top pop-up window in Fig. 10 shows an execution message that automatically appears whenever IPOST detects problems arising from the execution of an interaction. The result of creating a new customer as we did caused conflicts with the integrity constraints in the ORM. Participation constraints specify that every Customer must have a Name, SSN and Address. As a result of these error messages, we note that we must add the SSN to the input objects on the interaction. We must also
add appropriate action statements (which we show in the next section) on the initial transition to create the three identified relationship sets. Any of these changes we make through IPOST will also be saved back to the application model with Composer. This example illustrates the ease with which we initiate prototype execution in the JAD session. The lack of detail for the Customer class constrained us from elaborate prototyping of the behavior and rules associated with bank customers. It did, however, provide immediate feedback concerning the requirements of the Create Customer input interaction, The data content of this interaction applies directly to a ‘New Customer’ screen and thus also assists us in the definition of input screens, Similarly, output interactions define data requirements of report records and output screens. Since we have captured considerably more information about the LoanApplication class, prototype execution of the interactions and state net for that class would provide even more feedback on the quality of our work. However, we wish to do more than to just validate the
R.B. Jackson, D. W. Embleyllnformation and Software Technology 38 (1996) 615-631
623
Fig. 8. Main IPOST Window.
model through prototype execution - we want to develop a specification of the system that supports all of the relevant business rules. We therefore now show how to expand our prototyping experience to include specification development.
4. Developing the specification Most JAD approaches are used to extract and define user requirements. In our previous section, we have shown how we have been able to increase the utility of a JAD session by the addition of prototyping tools which allow us to immediately execute the application model. However, we desire to further increase JAD utility by developing a formal specification as part of the JAD activities. The purpose of a specification is to document the business rules in terms of the functions and data of a solution system and to serve as the ‘contract’ for the development of the automated system. As such, we want it to be as precise as possible. We obtain precision through formal models and languages. Thus the ‘best’ specification is a formal specification because it is the most precise.
However, users are not normally familiar with formal specification languages, so they are seldom able to help develop, or frequently even read, formal specifications. In our approach, the users are integrally involved in the development of the formal specifications. In our approach, an OSA model, which has a formal foundation based on set theory and first-order predicate calculus [IO], with all natural language components written in OSS-L comprises the formal specification. For example, the state net in Fig. 4 for the LoanApplication class has considerable natural language (in this case English) statements embedded in the diagram. Our task, then, for specification development, is to replace natural-language statements with formal, executable statements. We write these formal statements in OS&-L (Objectoriented Systems Specification Language). OSS-L has an English-like syntax so that client members of the JAD team are also able to learn and understand it as they work with and are coached by the more technical members of the team. The natural-language statements we replace with OSS-L statements are transition triggers, actions, interaction TO clauses, and general constraints. In Fig. 5, for example, all TO clauses, triggers, and
624
R.B. Jackson, D. W. Embleyjlnformation and Software Technology 38 (1996) 615-631
Fig. 9. (a) Popup window of possible origin object classes. (b) IPOST for Create customer interaction.
actions are written in natural language and can be replaced with OSS-L statements. We also achieve additional benefits from the introduction of OSS-L. First, the prototype becomes more functional. OSS-L statements can be interpreted and executed by IPOST. With the introduction of OSS-L statements, the OSA model instance can become a fully functional prototype. Thus, the users who are participating in the JAD sessions are able to observe and verify how the system handles business-rule requirements. Second, we have observed that the very process of thinking about and writing OSS-L statements forces all the JAD team members to think more precisely about exactly what is meant by a possibly vague business
rule. Considerable improvement in the definition is achieved even prior to prototype execution. There are two ways to insert OSS-L statements into a model instance: either through Composer or through IPOST. Generally, it works better, especially for JAD members just learning the syntax to use IPOST. The user can write OSS-L statements to replace natural language statements and let IPOST verify the syntax and demonstrate successful execution. This approach lets the user verify both the correctness of the syntax and the execution at the same time. OSS-L statements are based primarily on the constructs already defined in the OSA model instance, i.e. class names, relationship-set names, interaction names,
625
R.B. Jackson, D. W. Embleyllnformation and Software Technology 3X (1996) 615-631
Fig. 10. IPOST showing
and so forth. OSS-L uses these modeling names in conjunction with programming language constructs to describe the functions and procedures of the system. Thus, OSS-L also contains concepts such as variables, expressions, reserved words, and control statements. OSS-L statements consist of (1) OSA Terms; (2) Reserved words and operators; (3) Variable names; and (4) Miscellaneous connectors. In OSS-L statements, object-class names are single words followed by a set of parentheses, such as Customer(). Since class names are part of relationshipset names and relationship-set names are unconstrained sentences, class names are required to be a single word, as is LoanApplication(). This permits OSS-L to be an unambiguous language. As with other programming languages, a variable is bound to different values. A variable must always be associated with a class name by being inside the parentheses appended to the class name. For example. Customer(x) and LoanApplication(loanapp) identify the variables x and loanapp, which, during prototype execution will be bound to particular objects, x to customer objects and loanapp to loan-application objects, Once a variable has been identified as being
error and results windows
associated with a class, it may be used within an expression by itself. Fig. 11 gives a complete list of all OSS-L constructs, including all the keywords. We write the keywords using all capitals for ease of identification. However, OSS-L is not case sensitive. With this brief introduction to OSS-L syntax, let’s return to our JAD session and write some OSS-L statements. We begin with simple statements, and add complexity with later examples. Fig. 12 shows the simple state net that IPOST created when we began prototype execution. In Fig. 10, IPOST identified three participation-constraint errors from the creation of a new customer object. The OSS-L action statement within the initial transition must create name, address and SSN objects. It may also create the relationships between the new customer object and these newly created objects. The following OSS-L statement creates the new objects and places them in their object classes. Create Name(name),
SSN(ssn),
Address(address);
Create is an OSS-L keyword. The identifiers in parentheses are the variables and are associated with specific class names. Variables are either bound to a value prior to execution of an OSS-L statement or they are bound
626
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
OBJECT-CLASS NAMES Class names are always written with parentheses which may optionally contain a variable name: Classname(Variablename). Class names may also use the variable keyword name SELF. Class names may be used with a WHERE clause: class name WHERE relationship-set name (see below). RELATIONSHIP-SET NAMES Relationship set names are the same as in the ORM except that the embedded object-class names have parentheses. Relationship-set names may be used with a WHERE clause. CONDITIONS Conditions are predicates that can be tested for true or false. The following are predicates: Object-Class names Relationship-Set names Class Name INSTATE list of states Class Name INTRANS list of transitions Class Name INPRIOR list of states Expression comparators: =, >, < >=, <=, <> Event Trigger: @Identifier The following boolean connectors are used with conditions: AND, OR, IMPLIES, NOT ACTION CLAUSES The following clauses are used in action statements. CREATE list of classnames or relationship-set names; ADD list of classnames or relationship-set names; REMOVE list of classnames or relationship-set names; DESTROY list of classnames or relationship-set names; REPLACE object-class name or relationship-set name BY object-class name or relationship-set name; SEND interaction description (parameter list) TO clause; IF condition THEN set of clauses ELSE set of clauses ENDIF; WHILE condition DO set of clauses ENDDO; DO set of clauses UNTIL condition ENDDO; FOR loop symbol DO set of clauses ENDDO; TOSTATE list of states FUNCTIONS COUNT (object-class name or relationship-set name) MAX (object-class name) MIN (object-class name) TYPE DECLARATION STATEMENTS DECLARE object-class name (variable name) DATETYPE; similarly for TIMETYPE, INTEGER, REAL, LEXICAL. EXPRESSIONS Assignment: class or variable name : = expression Expressions: include variables, integers, reals and the following operations +, -, *, /. Fig. 11. Summary of the syntax of OSS-L.
during execution. In this instance, name, ssn and address come from the object descriptions on the Create interaction and are bound to the data that is entered through IPOST when the interaction fires. We do not include a Customer() object class in the create statement because IPOST automatically creates this new object when the initial transition fires. The following OSS-L statement creates the required relationships to satisfy the participation constraints. The keyword self is a variable that is always automatically bound to the object whose state net is executing.
Create Customer(self has Name(name), Customer (sew) has SSN(ssn), Customer(self has Address(address);
Fig. 13 shows these two OSS-L statements combined together within the transition action. Next, we desire to formalize the final transition for the Customer state net. Our first step is to formalize the Remove interaction. The Rembve interaction must be sent to a particular object, as noted by the TO clause TO: Customer who has SSN equal to input SSN. We formalize this clause with the following TO: Customer(x)
WHERE Customer(x)
has SSN(ssn).
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
/ Fig. 12. Customer default
with SSN equal IO lnpul SSN
state net.
With these changes, the Customer state net is now formalized, allowing complete execution using IPOST. We select and fire the Create interaction, select and fire other interactions which are related to the customer object, and finally we fire the Remove interaction. However, the Remove interaction produces error messages. We note that a customer object may have other, optional, relationships. A customer object cannot be deleted while it still has relationships to SavingsAccount, CheckingAccount, CreditCardAccount, or Loan objects. Now the JAD team members must determine the business rules which control the removal of accounts and customers. ‘Must accounts be deleted
The WHERE keyword introduces a modifying clause in the OSS-L syntax, which must be satisfied. Firing the interaction requires the IPOST user to provide a specific value for ssn, which then determines a value for x in the relationship Customer(x) has SSN(ssn). The x is then bound to the correct customer object. We next write OSS-L statements for the transition action. As our first cut, we simply replace the Create keyword with a Destroy keyword: Destroy Name(name), Destroy Customer(selfl Customer(self Customer(selJ)
TO:TO:Customer
SSN(ssn), Address(address); has Name(name), has SSN(ssn), has Address(address);
3Jstomer
lgR-e
AND NOT (Cuelomor(sel0 has ChecldnoAarwnlO k
Desl& Cust&(di)
has Nine(Nam~).
’
621
TO: TO: Cudomer(x) WHERE Curtomw(x) has SSN(sH)
.’
Ctstomer(selI) has Addmee(Addmss). CusIomer(selt) has SSN(SSN):
Fig. 13. Customer formal
state net.
628
R.B. Jackson, D. W. Embley/Information and Software Technology 38 (1996) 615-631
before customers? Can accounts be deleted concurrently with removal of customers, if the balance is zero? Are there tax and legal ramifications that must be considered before customers can be removed? Does the removal of an active customer require archival information to be sent somewhere? These kinds of questions must be answered before the system specification of the final transitions can be completed. Prototype execution with IPOST will force these issues to be addressed during the JAD session while key players are easily accessible. Since our objective in this paper is to demonstrate OSS-L, we keep the problem definition simple and require only that before removing a customer object, all optional relationships must have been removed by prior interactions and actions. In this case, we simply enhance the trigger for the transition to ensure they have been removed before removing a customer and its required relationships. Fig. 13 gives the enhanced trigger with both an event (@Remove) and the conditional test. The conditional test says that if the particular customer associated with selfparticipates in any of the relationship sets in question, then the condition will not hold and the trigger will not fire. Since the LoanApplication class has a more complex state net, we will illustrate a few more aspects of OSS-L by formalizing that state net. We begin with transition (1) from Fig. 5. First we formalize the trigger. An event trigger is formal when its descriptor matches the input interaction. Thus, placing @Submit LoanApplication in the trigger formalizes it. The informal action statement for transition (1) is empty. However, looking at the ORM in Fig. 3, we notice several classes that require objects whenever a loan application is created. These include, for example, EmployerName, LoanCustomer, MonthlyIncome, (if applicable). Amount, and LiabilityInformation Hence, we must create objects and relationships for these objects. Information for all of these objects must also be available from the input interaction Submit LoanApplication. Part of prototype execution will also include any required modifications to the interaction. Generally the order of creating objects and relationships is not important, as long as we ensure that the unbound variables are bound before they are used. Input parameters are bound prior to execution and the variable self is always bound to the destination object. First, we attach the customer to the loan application: Create Customer(x) completes LoanApplication(self Where Customer(x) has SSN(ssn); In this case, x is bound based on the input value ssn, which we notice must also be supplied in the incoming interaction. Next we write statements to create the lexical objects that are passed as input parameters with the Submit LoanApplication interaction.
Create LoanAmount(loanAmount), MonthlyIncome (monthlylncome), EmployerName(employerName); For our next statements, we note in Fig. 3 that the relationship set LoanApplication contains LiabilityInformation has a participation constraint of O:*, meaning that there may be from none to many outstanding loans. In this case, the input interaction identifies the number of car loans and the number of home loans. We use this information to crate a FOR loop so that we create the correct number of sets of loan information. Each set of loan information will contain an abstract object, either CarLoanInfo or HomeLoanInfo, and lexical objects for Institution, MonthlyPayment, Balance, and RemainingPayments. FOR loan# FROM 1 TO NumberOfCarLoans (numberOfCarLoans) DO Create CarLoanInfo(y) f loan#]; Create Institution(institution) [loan#], A4onthlyPayment(monthlyPayment)[loan#], RemainingPayments(remainingPayments)[loan# Balance (balance) [loan#]; Create CarLoanInfo(y)[loan#]‘has Institution(institution)[loan#], CarLoanInfo(y) [loan#] has MonthlyPayment(monthlyPayment)[loan#], CarLoanInfo (y) [loan#] has RemainingPayments(remainingPayments)rloan#], CarLoanInfo(y)[loan#] has Balance (balance) [loan#]; Create LoanApplication(self) contains LiabilityInformation(y)[loan#]; ENDDO;
J,
We would use a similar loop to create the information for home loans. The only difference is that we would need to use a different variable, such as z, with the HomeLoanlnfo class. The FOR statement in OSS-L provides several services. First, it identifies an integer symbol, which is not part of the OSA model instance, but is simply a programming construct. Then, it loops through the statements contained within the DO block varying loan# from one to NumberOfCarLoans. The brackets at the end of each class name do not affect the class or variable bindings. They simply indicate which element in a set of multiple values to use for this iteration through the loop. The FOR loop creates the required objects and relationships in the prototype. IPOST does another service for us here. Since CarLoanZnfo and HomeLoanInfo are specializations of the general class LiabilityInformation, IPOST automatically creates objects in the generalization class. In OSS-L we access these generalization objects with the same variable name as used in the specialization class, i.e. LiabilityInformation(y). Thus we use LiabilityInformation[loan#] in the last Create statement to connect it to
R.B. Jackson, D. W. Embleyllnformation
and Software Technology 38 (1996) 615-631
LoanApplication. Fig. 14 shows how we make these changes using IPOST. We enter them into the bottom panel in the IPOST depiction of transition (1). Upon execution, IPOST validates the syntax and executes the statements. At this point in our analysis, we do not worry about the layout or format of the output interactions. We focus our efforts on the business need of how many different outputs there may be and what information is required on each. Even when we begin prototyping, we want to verify the correctness of the problem definition before we begin to dilute our efforts too much on field layout and format. Fig. 15 shows the entire formalized state net for the LoanApplication object class. Transition (2) illustrates OSS-L constructs. The IF... several more THEN.. . ELSE statement, provides normal decision logic. The SEND statement fires an internal interaction. We have used IPOST to fire some interactions, especially those whose origin is an external object class like Customer or Employee. OSS-L and IPOST will also automatically fire internal interactions when they appear in an action statement with the SEND command. Finally, we note the TOSTATE command is used to
select a particular path out of a transition. In this instance, its use in conjunction with decision logic, indicates an exception condition. Continuing in this fashion, the JAD team can formalize all the state net in Fig. 5. In Fig. 15, we show the formalization of the entire LoanAppkcation state net. The state net, as formalized, is completely executable by IPOST. Input interactions and the appropriate logic are defined to create a new loan application, to send out verification forms, to update the employment and status fields, to approve or reject the loan, and to notify the customer. The process of formalizing this state net by the JAD team members required a combination of ORM analysis (Fig. 3), state net review (Fig. 5) and modifications made through IPOST (Fig. 14). IPOST provides the support to make the changes easily and to verify the changes with prototype execution. Working sessions frequently shift between discussing business rules, enhancing the model instance with Composer, entering OSS-L statements and reviewing the results of prototype execution. This analysis and specification process ends when the JAD team agrees that the specification is complete. This does not necessarily mean that every statement must be
@Submit LoanApplication
Fig. 14. Formalizing
629
transition
(1).
630
R.B. Jackson, D. W. Embleyllnformation and Software Technology 38 (1996) 615-631
Fig. 15. Formalized LoanApplication state net.
in formal OSS-L syntax. It does mean, however, that both the user and the developer members of the JAD team agree that it has sufficient detail to move into design and implementation.
5. Conclusions The JAD approach has grown in popularity over the past ten years. It has proven to be an effective method to do systems development. However, historically, support
for JAD activities has mostly been with ‘low-tech’ tools, such as white boards, hip charts, and projectors. More recently, middle-tech tools such as CASE tools with screen painters and group decision software have helped increase JAD productivity [5]. The inclusion of prototyping requires that JAD sessions be interrupted while prototypes are built and tested. These interruptions, however, diminish the effectiveness of JAD, which relies on a continuous flow of communication and understanding between users and software engineers. Our research is focused toward increasing the effectiveness of JAD
R.B. Juckson.
D. W. Embiey/lnformation
development by improving the level of technical support and by raising the precision and formality of the JAD results. We make two contributions which increase JAD effectiveness. First, since the OSA model is formally defined and executable, we provide analysis model prototyping as an integral part of the analysis discovery process. Execution of the analysis model permits viewing of potential solution system behavior without having to do system design tasks such as file design. In addition, prototyping is done concurrently with analysis and does not require the adjournment of JAD sessions while the prototype is being built and tested. The second contribution is the introduction of a formal analysis model and specification language. One of the stated benefits of the object-oriented approach is that it is a natural and intuitive way to model ‘real-world’ systems. OSA has the additional benefit that it has a formal foundation. The formal foundation provides precise execution semantics and permits prototyping CASE tools such as IPOST to be built. Additionally, we extend the analysis model into the specification model with the inclusion of OSS-L statements. The output of JAD sessions does not normally include formal specifications because formal specification languages are usually too difficult for users to read and write. However, since OSS-L extends the OSA model in a straightforward way, with some cross-training provided in the JAD sessions, users should be able to assist in the development of the formal specifications. Our contribution is to allow more formal and technical results from the JAD sessions. In the introduction, we listed seven analysis-phase tasks [6], which have associated deliverables, that potentially are the responsibility of the user. The first four of these tasks/deliverables should be initiated prior to the JAD sessions. Preliminary requirements on these four items lay the foundation for successful JAD sessions. The deliverables for the last three of these tasks, as well as refinement to the previous four deliverables, are accomplished through the JAD sessions by the development of an Object-oriented Systems Specification (OSS). Beyond these seven analysis-phase tasks, we also have a few additional observations. Our approach to the development of specifications can produce very detailed model instances and can be a lot of work. However, the alternative of building systems with incomplete or vague specifications ultimately may cause more work and be more expensive. Generating detailed specifications requires us to think about the details early and avoid many of the costs of rework and rethink. A JAD approach, with the proper support tools, puts the right players together at the right time in the project. Support tools, such as Composer and IPOST, mitigate the burden of detail work and eliminate the delay of prototype programming. Furthermore, a formal high-level language such as OSS-L helps team members think carefully
und Sqftbvare Technology
38 (1996) 615-631
631
about specification details and document business rules precisely. In our research, we are striving to make the support tools easier to use. For example, we are pursuing methods to make prototyping and specification generation even easier. One area is to include ‘expert system’ logic that can automatically generate OSS-I, statements to create the appropriate Create and Remove statements. We are also pursuing paths to integrate the several CASE tools we are developing into an IntegratedCASE environment. Back end CASE support such as automatic program generation is also under development. Currently we have defined a complete programming language and are in the process of building the tools that will later integrate with IPOST and Composer. We believe that with the proper models and tools a JAD approach is very workable. Even though the primary result of a JAD approach is a higher quality product, of almost equal importance is the level of communication engendered between users and developers. Both kinds of team members can have a good understanding of business requirements. Both can also read and understand technical models and more formal specification languages such as OSA and OSS-L. The result is not only a better product, but also enhanced expertise and confidence of all JAD team members.
References [l] Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House Publishing, 1989. [2] Robert Jackson and David Embley, Rapid prototypes that are truly rapid and truly prototypes, Technical Report, Computer Science Department, Brigham Young University, 1994. [3] Carolyn Shamlin. A User’s Guide for Defining Software Requirements: The Othr Side of Software. QED Information Sciences. Inc., 1989. [4] Judy H. August, Joint Application Design: The Group Session Approach to System Design, Yourdon Press, 1991. [5] Erran Carmel, Randall D. Whitaker and Joey F. George, PD and joint application design: a transatlantic comparison, Comm. ACM, 39 (June 1993) 41-48. [6] Jane Wood and Denise Silver, Joint Application Design: How to Design Quality Systems in 40% Less Time, John Wiley, 1989. [7] David W. Embley, Barry D. Kurtz and Scott N. Woodfield, Object-Oriented Systems Analysis: A Model-Driven Approach, Yourdon Press, 1992. [S] Guido Gryczan and Dar1 Dautz, A comparative case study of prototyping tools ~ experiences and conclusions. IEEE Int. Conf. on Computer Systems and Software, 1’990, pp. 4944501. [9] David W. Embley, Stephen W. Liddle and Scott N. Woodfield. Attributes: should we eliminate them from semantic and objectoriented data models?, Proc. 22nd Ann. Computer Science Conf., March 1994, pp. 340-347. [lo] Stephen W. Clyde, David W. Embley and Scott N. Woodfield, The complete formal definition for the syntax and semantics of OSA. Technical Report BYU-CS-92-2, Department of Computer Science, Brigham Young University, 1992.