Systems Analysis


During systems analysis, you figure out what you need in terms of a system. For example, you need two machines to properly test your solution, and you need to know what software goes on these systems. You conduct systems analysis and design methods to develop your solution for this certification. Throughout the certification project, you review and modify the downloaded program. You code, test, debug, and install your new application before submitting it. All these activities are defined first in the project management plan. After you have an overall project management plan, you take the next step, which is analysis.

Before writing code, you need a clear understanding of the assignment requirements and design. As outlined in Chapter 1, "Certification Steps and Submission Grading," start by writing a Software Requirements Specifications (SRS) document. It seems like so much documentation, when it is easier to just start coding, and this document and the others mentioned in this book aren't required. However, my goal is to provide you with the best chance to pass the certification. The SRS document is one that definitely helps achieve that goal.

Requirements

Requirements determine what Sun wants you to build, not how to do it. For example, the statement "The application keeps the user informed about what is going on with a reservation" is broad, but it does nail down a single function ”giving users status messages. Obviously, more requirements are needed to design a successful solution, but the point is you now know that the system will have to generate status messages.

Defining the status messages are part of the requirements definition phase. How these messages are generated (such as using exception handling to alert users of incorrect input) is not defined until later, in the Software Design Descriptions document. The requirements specify what the software needs to do precisely, concisely, and unambiguously. This phase is the most crucial, so a mistake here is the most costly. In fact, after poor planning, mistakes in defining requirements are probably the second biggest risk in a software project. A mistake in writing code later is not desirable, but it happens and isn't a big deal. A mistake at the requirements phase, however, is sometimes costly enough to kill a project.

You need the tools and techniques necessary to discover and analyze requirements for your solution. Many candidates submit a solution that is missing a requirement or two, but you can avoid this costly mistake if you learn how to use various fact-finding techniques to gather information about the assignment's instructions and challenges. After you have that information, you can start writing requirements. This step is where errors sneak into the project but don't get discovered until much later. Be careful ”this is the project-killer step.

The requirements document provides information about the application's requirements, both functional and nonfunctional, by addressing the following three areas:

  • Describes the operational environment ” For example, the application operates in local and remote modes. While in local mode, the client communicates with the database as a local file. While in remote mode, the client communicates with the database remotely via RMI.

  • Describes the application's capabilities ” For example, the application is limited to booking seats. Assume that cancellation is not possible after a seat has been reserved.

  • Describes the application's functional and nonfunctional requirements ” For example, the application allows a user to choose a seat by clicking on the JTable grid, which displays the seats and related information.

The requirements are the system's constraints. One of the tools designers use to illustrate these constraints is the use case diagram. Figure 6.1 shows you the use case diagram for the hypothetical assignment this book uses. As you can see, the diagram is simple, but still clearly illustrates the core functionality of the Super Bowl Reservation System.

Figure 6.1. The use case diagram for the Super Bowl Reservation System.

graphics/06fig01.gif

Design

Now it's time to look at the Software Design Descriptions (SDD) document, which describes the software structure, components , interfaces, and data used to build the solution. The design's key value is that each requirement in the SRS document is linked directly to one or more design entities in the design. The question of how the project will be built is answered in detail in the SDD document. Philosophies differ : Some analysts believe this document should be abstract enough to build with different languages, and some think it should be language or technology specific. The latter approach is more practical. Rarely does a company actually intend to build a product from many different languages, even if it does plan to target several platforms (for example, must work on Unix, Windows, and Macintosh).

graphics/caution_icon.gif

Identify opportunities for reuse and apply design patterns. Sun's evaluators want to see patterns in your design. They will frown on custom solutions that do not take advantage of known design patterns. For example, you must use the MVC pattern in the GUI and probably the Factory pattern for the local/remote connection to the database.


Chapter 1 outlined the IEEE standard 1016.1-1993, "Guide to Software Design Descriptions," but I've revised it for brevity. Remember that these standards are helpful tools, but in this assignment you can pick and choose what is useful to you. The following brief example of a system design document describes a project similar to the certification assignment:

1. Introduction

1.1 System Objectives

Briefly describe the system, owner, and functions of the system . This system is the Super Bowl Reservation System. It is being built for the Sun Certification Java Developer assignment. It provides seating information for the Super Bowl. The project objective is to extend a skeleton database system into a useable application that provides a convenient way to search for and reserve seats .

1.2 Plan Objectives

Briefly describe the objectives of this design document, especially how this document will transform the requirements into actual design specifications . The purpose of this document is to translate the requirements into actual functional specifications .

1.3 References

Identify your reference and sources of information used to develop this document . IEEE Standard 1016.1-1993, "Guide to Software Design Descriptions," was used to develop this document.

2. System Architecture

2.1 Hardware

Describe the hardware and its architecture that your solution will support including local/distributed modes . The Super Bowl Reservation System will operate in local mode on hardware that supports the operating system, which in turn supports J2SE 1.4. For example, the hardware can be an Intel- or AMD-based workstation running Windows 2000 or a Sun box running Solaris. In remote mode, this system will support a client running on one machine and the remote database server on another machine, as long as the two can communicate over the network via TCP/IP .

2.2 Data Communications

Provide a detailed description of how the system communicates over the network . This system uses Java's built-in RMI feature. Through RMI, the database server and the client can communicate with each other. RMI uses a stub for a remote object, which acts as a client's local proxy. The client invokes a method on the local stub, which in turns invokes a method call on the remote object .

2.3 Software

Describe all software that is needed to support the system . The system uses the J2SE 1.4 SDK. The software application can be considered as two parts : the Sun-provided code and the new code. The system extended the supplied classes instead of modifying them. This way, it didn't modify lock/unlock signatures on the supplied classes, but overrode them in a subclass. The system used Factory, MVC, and Adapter patterns for better architecture and reuse .

2.4 Architecture Diagram

Illustrate the hardware, software, and communications designs to show the structure of your system . For this section, you might provide a diagram illustrating key portions of the system. For example, perhaps you could use a hardware layout to describe the server machines and their relationships. Often, each server shows the IP address, machine type, OS, name , and the major software application running on it.

3 Data Design

3.1 Data Objects and Resultant Data Structures

For each data object, describe how it will be used to store and process the data . The Field object describes a single field in the database. It has several attributes to create a description, including size, data type, value, name, maximum value, and minimum value .

3.2 File and Database Structures

Describe the logical and/or physical data model for your system. This may include file structures and their locations. You might also describe how data is structured in the selected database management system . The system stores and retrieves its data from a binary file “based database. Within the database, data is stored as a sequence of fields that together form a row. Each row is separated by a carriage return. These rows are stored in a single file that acts as a table .

4. Modular Design

4.1 Modules

This is where you describe the software modules used to satisfy the system's operational requirements . When a user selects a seat from the GUI, the request is passed to the application's client functional controller. The controller determines whether that seat is available. If not, the system provides a status message saying so. If it is, the seat is reserved by GUI objects communicating with database objects, which work in the background as systemwide application objects.

4.2 Processing Narrative

Describe the process by which each module interacts with other parts of the system, including the input and output structures to each module. Also, describe the system's key algorithms that transform data . The system allows users to search for seats at the Super Bowl. The algorithm that handles this search is called the searchSeat method. This method is abstracted so that it can return a tableRow object containing all rows that have at least one value matching one criteria value. The column names and values are dynamic, so this method processes any number of criteria for any table, not just the one supplied in the assignment download. The algorithm used is .

4.3 Internal Data Structures

Describe the internal data structures of each module . The seat data is stored in the database. To identify a given seat, users must also know the gate, level, aisle, and row it is in. The database has a table that allows each seat to be unique by associating these other key data items .

4.4 Design Language

Specify the programming language for each module . All modules in this system were written with Java, J2SE 1.4.



JavaT 2 Developer Exam CramT 2 (Exam CX-310-252A and CX-310-027)
JavaT 2 Developer Exam CramT 2 (Exam CX-310-252A and CX-310-027)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 187

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net