Julie Pickett

CS Senior Seminar

Fall 2003



Survey


Introduction: Software Engineering


The development of software is the design and implementation of some program that performs a specific task or solves a specific problem. This is a relatively new idea that is not yet well-defined in a way in which the programming community can agree. Often, software does not perform adequately or solve the intended problem. Software engineering is the emerging solution to a poorly-defined and sometimes untrustworthy occupation (Hamlet xxv). Two important issues facing software engineering are universal methodologies and design representations. The idea of a widely accepted methodology is a leap toward the goal of better software system design and more reliable software. The software system resulting from this project will be designed with the waterfall methodology in mind. The issue of design representation is one of organization to the developer, to assist in the design and layout of the system, as well as an issue of readability to others involved in the development process. Unified Modeling Language (UML) is a widely accepted design representation and was derived from commonly used diagrams and ideas (Bruegge 30). This will be the method of design representation for this project.

General Methodology: Waterfall Method


I. Introduction. The waterfall method is an ideal way of describing the development and 'life cycle' of software. Implementing this particular stage-wise method is difficult and rarely fully accomplished (Hamlet 8). 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' (Hamlet 10). 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 (Hamlet 10). 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 says "...exactly what the software is supposed to do, but to avoid as much as possible saying how that functionality will be attained" (Hamlet 10). 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. The specifications laid out in the previous stage are very important, as every component and group thereof needs a functional description and these can be directly defined in the specification documentation (Hamlet 11). Hopefully, the design of the system will be laid out in some hierarchical form, and graphically represented in a readable way. This is especially important when many people are involved in the programming stage; however, in this case the developer will do the programming. 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 (Hamlet 11). 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. 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.

Design Representation: UML


I. Introduction. The specification and design stages of development are complex and best handled in steps of abstraction. Also, because of the nature of the development of a system, graphical charts are an ideal way to represent these layers of objects and relationships as they are defined. This is why UML is commonly used as a software development notation. UML also provides notations to represent both general and very specific ideas. Use case and class diagrams are more general, and apply to software systems in general, while there are many forms of interaction diagrams to represent different types of interaction. The example of UML used here will be for a system called SimpleWatch, which represents a normal-function wristwatch and it's components.

II. 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 (Bruegge 31). 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. Figure 2 depicts two actors and three use cases of SimpleWatch, and the lines indicate which actors interact with the use cases. In this example, each use case is outwardly visible to one actor, and there are only three types of user interaction.

III. 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 (Bruegge 32). In a way, the class diagram defines what is or is not a SimpleWatch, as it's purpose is to lay out all of the classes, objects, relationships, and attributes of SimpleWatch and it's components. Figure 3 is a diagram of the classes involved in SimpleWatch and the relationships of the objects. The numbers associated with the links between classes represent the number of objects in that class related to the number of objects in the relating class. For example, each object :SimpleWatch has two :PushButtons and one :Time, where :Name is an object, or instance, of the class Name. Also, each :PushButton is associated with only one :SimpleWatch. This diagram defines five classes for our example system, which will affect how we organize and design the lower levels of the system.

IV. Interaction diagram. An interaction diagram represents communication among participating objects, or objects involved in a use case. This diagram identifies all of the participating objects in one particular use case, so that the developer can lay out the necessary involvement for each use case (Bruegge 32). Figure 4 is an example of an interaction diagram called a sequence diagram, which represents the sequence of object interaction in a use case. If :WatchUser uses the pressbutton1() function of :SimpleWatch, the blinkhours() function will cause :Display to blink, until both buttons are pressed. This example relies on :WatchUser pushing the buttons in this particular order, but more diagrams can be created to represent other possible combinations.

V. 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 (Bruegge33). The sequence diagram (figure 4) represented the interaction between objects, while a statechart diagram defines the dynamic state of a single object. Each state of figure 5 has an associated set of values for the object :Display. In this case, the beginning and ending states have the same values, where :Display displays some value of :Time. If :Display is in this normal state, and a button 1 is pressed, it will move to the state BlinkHours, and adopt the values associated with the change to that state. At this point, any action that is taken will change the values of :Display and associate the object with another state. This continues for any possible change of state until :Display is returned to it's normal state.

VI. Activity diagram. The last notation of system behavior to discuss is the statechart diagram, which describes the system and i'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 (Bruegge 33). Figure 6 is an activity diagram for the ChangeBattery use case of SimpleWatch. 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 watch must open and the batteries accessible before any instructions of any other activity can begin; however, new batteries can be found before or after the old batteries have been removed, and a new battery can be put in place as soon as there is room. Only after the batteries have been replaced can the watch be closed. Presumably, the user will now reset the time of the watch.

Application


The system developed as an example of this methodology and notation will be a set of applications designed to solve the following problem: Any agent for Commonwealth Land Title Assoc. must fill out a set of forms in order to issue a commitment for title insurance, a title insurance policy, or a lender's insurance policy. These forms contain a very specific set of data consisting of the following types of records: parcel of land, owner of parcel, owner's address, optional buyer of parcel and address, optional lender of purchase price of parcel, outstanding mortgages, mortgage releases, mortgage assignments, easements of record, leases of property, and any applicable court judgments or documents. This set of data can be uniquely identified by the legal description of the land. The entry of this information into set forms by hand is redundant and inefficient. The system proposed is one to search through an existing subset of this information and populate the form variables automatically, but to also allow the user to enter the pertinent information by hand, at which point the application will apply the correct syntax to the base information and populate the appropriate form variable.

The first stage of development for this system will involve requirements analysis with a local abstracting company, Jay County Abstract Company, Inc., with which I am personally associated. This business has made an ongoing effort to retain the information needed to test this system, and the company itself is an agent of Commonwealth Land Title Assoc. The resulting documentation from this problem analysis will be recorded, along with proposed problem descriptions by me as the developer.