Julie Pickett

CS Senior Seminar

Fall 2003



CommonForm: An Application of Software Engineering Methodology.



Introduction to Software Engineering: Waterfall Method



I. Introduction.


The waterfall method is an ideal way of describing the development and 'life cycle' of software. This method involves five main stages: requirements, specification, design, coding, and testing, as well as a determination for continuing support for the software system after the initial implementation. The main characteristic of this method is that the stages do not intersect and are addressed linearly. In other words, specification does not begin until the requirements stage is complete and laid out in appropriate documentation. At the same time, each stage contributes to the test plan, which is implemented at the test stage (refer to figure 1).

II. Requirements.


The requirements stage is the time to interact with the user. The exchange between user and developer is documented, and the needs of the user are laid out in precise terms that are decisive to the user and clear to the developer. At the same time, the intentions of the developer are described in terms that the user can understand and agree with. The result should be a concise document agreed upon by both parties, called the 'requirements document'. It is common for the developer to draft the document and propose it to the user after adequate interaction has been made. This ensures that the developer is clear on what the needs of the user are, where a document drafted by the user can be unclear to the developer and may need redefinition late in the development process. It is very important that the needs of the software system be clear before the specification and design stages of development, though it is important that the developer stay in contact with the user so that sudden changed can be accommodated quickly and efficiently. After the intentions for the system are laid out, the beginnings of the test plan are formed. At this point, the developer is clear on the forms of input and output of the system, and other user interaction, and can plan to test for these accordingly.

III. Specification.


The specification stage does not require explicit exchange with the user, though interaction should be a continuing process. The main objective of this stage is to document a complete problem description. At this point, the developer describes exhaustively and in his own terms exactly what the software system will do. One important qualification for terms of the resulting document is that it describes 'what' the software will do, and avoids describing 'how' this will be achieved. Also, at this stage, any issues left undefined by the user can be identified and addressed. If the user remains indecisive about the issue, it is laid out well enough for the developer to propose options to the user. After the problem is better defined, so are the terms of testing, and the test plan can be revised. This part of the test plan can comprise the needs of the system testing.

IV. Design.


The design stage is the 'how' stage of development. The system is broken down into manageable pieces that can be individually programmed. This break-down is usually handled in steps where similar components can be grouped together and designed more generally to allow more flexibility and less physical code. In this example, the groupings are laid out in terms of classes and common class methods. The specifications laid out in the previous stage are very important, as every component needs a functional description and these can be directly defined in the specification documentation. Here, the test plan can be updated to include the beginnings of the component testing.

V. Coding.


The coding stage presents the programming of the components as laid out in the design sage. The components and their groupings have been defined in the specification documentation, and their interactions and relationships have been laid out in the design representations. This is the most specific and complex stage of development, where decisions are plenty and have consequences large and small. Some amount of forward thinking is involved to allow for additional components to be added later on, or for adjustments to be made more immediately during the testing phase. Since our system is laid in terms of common class-associated methods, the same functions will apply to many functions, streamlining the code and allowing for easy additions and changes. As always, documentation is required. The documentation produced here should explain each component's actions reasonably so that the user can understand how to use the system. This documentation can be collected to make a user manual once the system's components have been compiled and the testing has proved the system useful and accurate. Now the test plan can be updated to specify parameters for component testing, and later, the system testing plan can be defined in terms of appropriate user interaction.

VI. Testing.


If the developer has vigilantly updated the test plan and defined it in terms of system code, then the testing stage comprises component and system runs of the code to ensure proper interaction between components, and between the user and system. At the point a problem is encountered that is not immediately remedied with proper code syntax, it is necessary to refer to documentation from previous stages to ensure that the specifications and design have been carried out properly in the code implementation. Coding decisions could be to blame, and interactions between components are always tricky. Once code has been corrected and rectified with documentation from previous stages, the final bit of documentation to be produced is the compilation of a user manual. Now the system is ready to be used by the end user.

Problem Description: CommonForm



I. Form input.


The problem to which this system will applied is one of form information redundancy. Commonwealth Land Title Assoc. requires all of it's agents to complete a set of forms in order to issue title insurance or a commitment for title insurance. These forms are very redundant and very time-consuming for Abstractors, and this system will be a step in reducing an agent's time commitment to a single instance of title insurance. These forms (figure 2) consist of a combination of required information and a subset of document information. Any land owner can have multiple forms pertaining to the same parcel of land and any document can apply to any number of forms. Currently, an agent must enter all of this information by hand multiple times (figure 3). Part of the data redundancy problem is due to improper data storage. It would be nice if an agent could enter form or document information once, and then access it or change it as many times as necessary without starting over. These are the issues that this system will address.

II. Requirements Document.


There are two types of allowable input for this system. The first will be user input with the following requirements. The user must be able to delete and adjust any of the information in the form. This is very important to allow the user to ensure the correctness and appropriateness of the information included in the form, and correctness of the form as a collection of information. The primary objective is to allow the user to enter form information one time, at which point the information will be populated into the form in every necessary field using the proper format. This is the most basic and important user interaction for CommonForm, and will be retained with the addition of database interaction. Associated with forms are documents. The user must be able to choose the type of document to associate with a form and enter the required data, which will be entered into the form in the proper fields with proper syntax.
The second type of input for CommonForm is database input with the following requirements. A user can search a database for a form or document by using a document identification number, and this information can be defaulted into the form or document values by CommonForm. The user can then change any of the information and submit the changes to the database. All new documents and forms will be populated in the database for easy access via CommonForm so that the user may freely use form and document information without consistently entering the same information.
The required output for this system is a set of forms that is demonstrated to contain correct information embedded in the proper format, as entered into the database by the user. The forms must comply with Commonwealth's standard forms concerning title insurance. The information in a form is required to be checked by an agent of Commonwealth and any corrections made before the issuance of any commitments or policies of insurance. An example of each form is included in figures 2, 3, including the proper format for included information and documents.
There are three types of forms that CommonForm can replicate, Commitment for Title Insurance, Owner's Policy, and Lender's Policy. Each form is made up of a particular set of information and a set of associated documents. The required information for a commitment includes: commitment number, effective date, owner, description, taxes, and any liens against the property. There are additional optional fields depending on whether the commitment is for owner's insurance, lender's insurance, or both. The required information for an owner's policy includes: policy number, purchase amount, new deed information, address of buyer, description, and any liens against the property. Similarly, the required information for a lender's policy includes: policy number, new mortgage information, address of lenders, owners, description, and any liens against the property.
There are five types of documents that can be defined as liens against a property, a deed, a mortgage, an easement, a judgment, and tax information. Each document type has a set of inherent variables and a specific format for the insertion of document information into a form. A deed requires the following information: date and time recorded, owner, seller, description, document number, and number of pages. A mortgage requires: date recorded, owner, lender, amount, document number, number of pages, and description. An easement includes: granted by, granted to, record information, date signed, and date recorded. An oil and gas lease requires the same information as an easement, as it is a specific type of easement that we like to denote separately. Required judgment information includes: plaintiff, defendant, cause number, date of filing, book and page numbers, and amount owed. Outstanding taxes are not laid out in a document, unless there is a tax warrant, which is defined as a judgment, so there is no recording information. To denote outstanding taxes we need the total taxes and the additional penalty for each installment, and the computer number, which identifies a parcel of land. The format for each document type is demonstrated in the form examples.

III. Specifications Document.


Now that the form classes and document classes have been defined in terms of the necessary information or each, we will refer to these as the information classes. In addition to these classes, we need a few additional classes to complete our system interface. The classes FormTypes and DocTypes are defined as the set of appropriate types. FormTypes includes the information types Commitment, Owner's Policy, and Lender's Policy, and DocTypes includes the five document types. These additional classes will expand to form the entry points of our system's user interaction, in terms of the interface. The last class we require is DisplayForm, representing the interface of the system that compiles all of the stored and entered information into a particular format and displays the form.
For each information class, we have defined the appropriate variables, but now we need to define the methods, or additional functions of the classes. Each of the form types need the added functionality to associate a document, to edit a document that is currently associated with the form, and to display the form. Each document type must be have an included interface for editing the information contained therein, and generally an interface for searching for a particular document of that type. These additional functions will be served by interaction with the three additional classes. Now all the classes are defined by their relations to each other as well as inherent variables to the class. These definitions will serve as internal, Java class definitions. Now that we have a set of classes, and have laid out the methods that connect our classes, we are ready to design the system in terms of how the system will achieve the input and output requirements.

IV. Design: UML.


The system is designed using a method of object-oriented design called the Unified Modeling Language (UML). This is a very useful form of system description that lays out a system design using a set of several different types of diagrams. This is a very powerful design method that defines a system from the top down, and is so descriptive that it can be translated directly into code using UML interpreters. Code developed using this method can be easily verified to accomplish desired results.The following set of UML diagrams was derived into a Java system that interacts with classes, objects, and methods to create the desired interface.

Problem Solution: UML



I. Use Case Diagram.


A use case performs a function that is outwardly visible, and an actor is a person who interacts with a use case. The use case diagram represents use cases and actors, as well as their relationships. The use case diagram is one of the more general diagrams, and is used to identify user interaction with the system. This diagram represents a form of requirements interaction, as it defines the input and output in terms of what the user is aware of. figure 4 depicts two actors and four use cases of CommonForm. The user can interact with any use case and the database can interact with the form and document information by loading the information in an interface for the user. The user is able to interact with form and document information in two ways. New forms and documents can be defined by the user, or information can be adjusted.

II. Class Diagram.


Classes are abstractions of the structure and behavior of a set of instances called objects. Objects have attributes and relationships with other objects as instances of other classes. Class diagrams lay out the associations of instances in one class with instances of other classes. In a way, the class diagram defines what is or is not a CommonForm, as it's purpose is to lay out all of the classes, objects, relationships, and attributes of CommonForm and it's components. Figure 5 is a diagram of the classes involved in CommonForm and the relationships of the objects. This diagram defines eleven classes for our example system, which will affect how we organize and design the lower levels of the system. If you notice, this is the same sort of interaction we defined in our specifications stage, and in this case, each class provides a user interface. So this diagram type is associated with the specifications and design stages of the waterfall method.

III. Sequence Diagram.


A sequence diagram represents communication among participating objects, or objects involved in a use case. This diagram identifies all of the participating objects in each particular use case, so that the developer can lay out the necessary involvement for each use case. At this point, the methods for each user interaction are developing, representing the design portion of our software engineering method. Figure 6 is an example of a sequence diagram, which represents the sequence of object interaction in a use case. If the user uses the newform() function of CommonForm, then a choice of form types will be presented to the user. Each form type function will create a new instance of the form type, at which point information can be added and documents can be associated. This diagram does not lay out the information interactions for form and document types, but more specific diagrams can be created to represent every interaction with the user.

IV. Statechart Diagram.


This diagram describes the dynamic behavior of an object, where the states are possible sets of values for the object and the transitions are internalized conditions associated with a change of state. The sequence diagram (figure 6) represented the interaction between objects, while a statechart diagram defines the dynamic state of a single object. Each state of figure 7 has an associated set of values for the object Deed. If Deed is in a normal state, and a new deed form is created, it will move to the state FormBlank, and adopt the values associated with the change to that state. At this point, any information that is added will change the values of Deed and associate the object with another state. This continues for any enumerated change of state until Deed is returned to it's normal state. From this diagram, we can directly infer the structure of the Deed class declaration ( figure 8). This represents parts of the design state of our methodology and the beginning of our coding stage.

V. Activity Diagram.


The last notation of system behavior to discuss is the activity diagram, which describes the system and it's interactions in terms of activities. An activity represents the execution of a specific set of instructions, and the transitions represent the completion of an activity and transfer into a new activity. Activity diagrams are a representation of control or data flow. Figure 9 is an activity diagram for the document searching method of CommonForm. A vertical bar splitting a transition represents a synchronization of activities, and everything before the bar must be completed before another activity can begin. Otherwise, instructions in an activity can execute as soon as the resources are available. In this case, the database interaction must be completed before any instructions of the remaining activities can begin. These diagrams can be enumerated for every action available to the CommonForm system. These are the diagram representations that allow us to form code directly from our UML digression. This represents the final coding methods and allows us to test each method in terms of itself, and it's contributions to the system. Now we have our system design and a representation of our code as well as a way to test for component accuracy and system compatibility.

CommonForm: The Application



I. Reality.


The application resulting from this software engineering methodology is verifiably accurate in it's intentions. The application interacts with a database in all the necessary ways and displays stored information in a form interface. The user can enter different types of form and document information, as well as update already existing information. The user can also associate a document with a form, so that all of the information referred to in the document can be inserted into the form with the right format.

II. Future Work.


There are a few expansions I would like to apply to the system. As it stands, the information is weakly typed, and I would like to impose a very strongly typed definition to many of the information variables to help ensure correctness. I would like to implement some optional parameters for one of the form types that allows for different sets of form variables. The last and most useful thing I need to add to the system is a Java-implemented method for displaying the forms based on their data representations in the database. My current method for display was thrown together and is platform dependent, and I would like to implement the entire system in Java so that it will be compatible with the other software applying to this information.