Certification Objective 7.03: Validating the Proposed Logical Design


Once the application and database logical designs have been developed, you can proceed to the final stage of logical design—validation. The validation step is important because it is “one final check” before the application moves into physical design.

The main goal of validation is to ensure that nothing has been overlooked during the logical design process. The task of validating the design need not take a lot of time or effort, and the potential costs of missing out on an important application requirement until late in the development process can be high. For example, imagine not realizing that an application had to have the same user interface look and feel as an existing application until the user acceptance stage of development. The amount of work required in redesign and redevelopment could have been saved had someone just spent a few hours validating the design.

There are two main techniques for validating the logical design, both of which we will discuss in this section:

  • Compare the proposed logical design to the known business requirements.

  • Validate the proposed logical design against usage scenarios.

Reviewing the Effectiveness of the Proposed Logical Design in Meeting Business Requirements

The easiest and best way to validate a logical design is to reexamine carefully the business and user requirement documents. By extracting each requirement from those documents and comparing them with the logical design, you should quickly be able to verify if an application will do all the tasks the user wants it to.

When comparing the logical design and business requirements in this way, there are eight important considerations to keep in mind:

  • What types of performance problems are likely to occur with this architecture?

  • What types of scalability problems are likely to occur with this architecture?

  • Is the application extensible, in that it will be able to easily accommodate new requirements in the future?

  • Will application availability be a factor?

  • How easy will the application be to maintain in the long run?

  • How easy will the application be to deploy into the production environment?

  • What are the major security risks?

  • Have all of the user’s accessibility needs been taken into consideration in the user interface design?

These eight considerations are important, to be sure, as they look beyond the business requirements at the operational requirements of the application. But the most important consideration still remains the comparison against the business requirements. Does the application do what it is supposed to do? If not, either the application or the user requirements have to be corrected so that those two pieces are in alignment at the end of this phase.

Validating the Proposed Logical Design Against Usage Scenarios

Another technique for validating the proposed logical design is to run through the predefined use cases. (If you recall, use cases were discussed in Chapter 3.) Of course, since we do not have a functioning application at this point, “running through” a use case is mainly a matter of comparing the application-related requirements of that case to the logical design.

Start by choosing a use case from the collection of cases developed during the business requirements phase. For instance, assume you will be going through the “Add a New Appointment” use case.

The logical design should be able to support every task requested of it in the case. For instance, if the first step of the “Add a New Appointment” case is for the application to create an empty appointment for the user to work in, the Appointment object should support creating an empty appointment.

Likewise, if the use case mentions certain fields that get updated, the object should support modification of those fields. If the object is called upon to perform a task, such as to save to the database, the logical design should include an appropriate behavior for that object.

Creating a Proof of Concept for the Proposed Logical Design

A proof-of-concept (POC) is perhaps the first actual bit of coding that gets done for an application. The purpose of the POC is to test out some of the most difficult technical requirements in order to prove their viability. The POC is not a sample application or a working prototype. In fact, the POC usually bares no visible resemblance to the final application.

For example, let’s say the design of your application called for the application to save and retrieve all its data from the database in XML format. There is some concern, for good reason, that this might cause some performance problems for a heavily used application. To prove this concept, you develop a sample application that replicates the architecture of your production application and attempts to save and load thousands of records in XML format. This is a reasonable test because if the performance is not good enough, you may have to change your plan.

Another example of a POC would be an application to test the performance gains that could be made by creating a multithreaded (asynchronous) application instead of a single-threaded one. A POC application could have a user interface switch that allowed testing various scenarios under both synchronous and asynchronous conditions.

Not all applications need proof-of-concepts. They are only usually required when you are trying to test something that has never been done before to see how it works. Code developed for POCs can often be reused. For instance, when you have the asynchronous components working as a proof-of-concept, that code can be copied into the production application when the time comes for development.

The main problem with POCs is that they are sometimes used as the foundation for the production application. POCs are designed mainly to be quick tests and do not have many of the important architectural traits of production-quality applications. Try to avoid using the POC as the basis of the production application design. Instead, just incorporate some of the ideas and code from the POC into the final application.

In the next chapter, we will examine the application physical design. Physical design results in the actual technical specifications that can be used to develop the application. Many of the concepts that were introduced during the logical design phase get formalized during the physical design.




MCSD Analyzing Requirements and Defining. NET Solutions Architectures Study Guide (Exam 70-300)
MCSD Analyzing Requirements and Defining .NET Solutions Architectures Study Guide (Exam 70-300 (Certification Press)
ISBN: 0072125861
EAN: 2147483647
Year: 2003
Pages: 94

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