Define the Design

A design is an instruction for building the solution. It provides an understanding for how the solution should fit into the host and defines the tasks required to build the solution. Deliverables of the build process are also itemized in the design. The design describes what code efforts need to be performed and what configurations need to take place on the hosting platforms. In an ideal world, the design would provide enough information for a programmer to write the code necessary to build the software.

A design consists of diagrams, text, pictures, pseudo-code, or any other means necessary to convey technical specifications. The deliverables of the design step process are called a façade, functional test scripts, and a technical specification, as summarized in Table 18-3.

Table 18-3: Summary of Deliverables for the Define Design Step

Execution Order	Deliverable	Responsible Party
1	Façade	Business analyst and development
2	Technical specification	Development
3	Functional test scripts	Quality assurance

What Is a Façade?

A façade in this context is not an object-oriented design pattern. Instead, it could be better described as a limited prototype or a creative mock-up mixed with a little reality. The façade effort is a step that was introduced to help an owner view a solution before the final product is received. It helps to demonstrate the way that a creative mock-up described in the functional specification might appear in action in a web browser.

Designing the solution takes place after the requirements are gathered and summarized in a functional specification. This implies that the owner knows what they want and that these desires have been rendered on paper. Realistically, however, although the owner may describe what they want in the form of a document, they are likely to want something else after they see the solution begin to take shape. After the objectives in the functional specification come to life in the form of a dynamic software application that works, new requirements often come to light.

In many web-based projects, the owner’s primary concern is the way the end user interacts with the software. The functional specification defines what the software should be, and it should be defined by the way it looks to the end user. The façade plays a role in the design and build process by asking the owner or business analyst to verify how they want the software to look and to function. Web portal software projects generally consist of the following deliverables:

• Data source configurations and scripts

• Binary and script code files that obtain data and apply business rules

• Script files used to apply presentation logic

Why not build the presentation logic before building anything else? As long as the solution supports abstraction from the business logic and the presentation logic, the presentation logic may be produced first. The technology that supports this abstraction is the Extensible Markup Language (XML). For the purposes of this chapter, it will be assumed that data is formatted in XML.

The collaborative effort of the business rules code and script and the data sources involved in the process builds the XML that the presentation logic needs to create the desired output. Prior to building the data source or the software that applies business rules, the developer writes a technical specification that establishes the way these items should work, including the XML they will produce. This means that the XML should be produced and be designed prior to building the software. If the XML is established prior to building the supporting software, why not validate the XML design prior to building the data source or the software that applies the business rules? The script files used to apply presentation logic must be written, and they may be written before the supporting software is written—or, they may be written after the supporting software is written. If requirements change, changing a presentation logic script file is less work than changing a compiled code business object. If the presentation logic is embodied in Extensible Stylesheet Language (XSL), XSL Transformations (XSLT), or some other presentation technology such as ASP.NET web forms, static XML documents representing the desired output for every given command to the solution may be produced and used to test the presentation logic script file.

Given the amount of work required to develop a technical specification and build the software, validating the functional specification is a valuable effort toward ensuring that the design and technical specification are valid. The façade part of the design process is performed with that goal in mind. Following are the goals of the façade portion of the design process:

• Establish the XML document for every given solution event to the portal project.

• Build the presentation logic.

• Demonstrate visually to the decision makers how the product will function and verify that it is correct.

Once the façade is completed, the rest of the work of building the business rules code and the data source may be completed. The owner may also be shown the façade. Although the façade is not totally functional, it does demonstrate progress and provides reassurance to the owner. The owner/decision maker feels included in the process and accepts some responsibility for the outcome of the development effort.

The façade presentation logic files that were produced do not need to be changed in the build effort except to support other web browser versions or other client platforms. The business rules software and data source efforts, which generally require the most amount of work to produce or alter, may be built with greater confidence that the final product will meet the owner’s expectations.

Produce the Façade

The effort to build the façade requires the cooperation of the players involved with defining and building the solution. The business analyst, the developer coding the presentation logic, and the developer writing the business logic or data solution will interact with one another until they are satisfied that the product is presentable to the owner. In this discussion, the developer producing the presentation logic will be referred to as the UI developer and the developer producing the business logic and data logic code will be referred to as the object developer.

The façade process begins by examining the screens required, as indicated by the functional specification and producing edge case XML. Each unique screen identified in the functional specification results in an XML document. The UI developer and the object developer work together to develop edge case XML documents for each screen. Edge case XML documents represent the scenarios that are specified in the functional specification. The goal of an edge case is to choose a set of test data that is likely to force the developer to code based on the worst case data and thereby produce code that is likely to be more reliable. As the edge case XML is created, the UI developer will produce functioning presentation logic code based on the edge case XML.

Note 

Many of the objects in .NET stream the state of an object into XML automatically. This functionality shifts the effort of defining XML to defining objects to use in the solution, which is a huge benefit since ultimately the objects producing the XML will need to be built. Specifically, ASP.NET affords many conveniences for producing XML and displaying XML. Please refer to Chapters 14 and 15 for more information about ASP.NET technologies.

The following deliverables will be produced with any façade:

• One or more edge case XML specifications for each screen identified in the functional specification

• Presentation logic code for each screen in the functional specification

The UI developer performs most of the work directly related to this stage of the façade effort by attempting to duplicate the desired UI specified in the functional specification. Because the business analyst has produced the functional specification by the time the façade process begins, the analyst will likely perform the least amount of work at this point. The analyst’s role in the façade is to clarify issues in the specification and to revise the functional specification as needed during the process. The object developer should examine the existing solution, if it exists, for sources of the XML that hosts the objects or data being identified as required content in the edge case XML. As mentioned previously, this search could include .NET Framework classes if the .NET Framework is to be a part of the solution. If the UI developer is intimately familiar with the output XML of the existing solution, the object developer may also start laying groundwork code or performing feasibility analyses on parts of the new solution that reliably will not change after the façade review.

The façade is finished when the screens may be shown in a web browser using the edge case XML documents, although the links and ability to navigate from one façade screen to another is likely not possible. The presentation logic may also need to be tweaked prior to actual deployment.

Presenting the Façade

Presenting the façade to the owner requires the ability to display the screen in a web browser. Microsoft Internet Explorer version 5.5 and higher performs XML to HTML transformation using XSL and XSLT. Because IE is free to use and is widely used, it serves as a great platform for presenting the façade on a computer running any version of Windows. Often, the presentation of the façade would take place at the owner’s established place of business, where Internet connectivity may not be easily accessible. Although the façade could be set up on a server that performs the XML and XSL/XSLT transformation, using the browser to perform the transformation always provides a sure means for allowing the owner to observe the desired output.

To get IE to perform the XML to HTML transformation using XSL or XSLT, add the processing instruction shown in Listing 18-1 at the top of the XML. The XML containing the processing instruction will be transformed using the XSL sheet named MyXSLSheet.xsl. If the XML originates from a web server, the specified XSL sheet must come from the same web server. In the case presented in Listing 18-1, the file MyXSLSheet.xsl could reside in the same file directory as the XML file itself.

Processing Instruction to Transform XML into HTML <<?xml version="1.0"?>> <<?xml-stylesheet type="text/xsl" href="MyXSLSheet.xsl" ?>>

The façade presentation shows the owner how the screens look in a web browser, and the transition from one page to another may be scripted or mocked up to demonstrate flow between screens. After the owner sees the façade for the first time, they usually have some suggestions or demands for change.

The façade generally results in scope change, or scope creep, but the scope creep is performed in a preemptive fashion because you are setting the ground for change. Scope creep is dangerous because it often occurs in the project during a time that causes great difficulty in delivering the project. Scope creep happens because the solution in the web browser looks different from that of the functional specification. Using scope creep to your advantage, the façade may also harness the owner’s creative energy and desire to micromanage the design process by helping them focusing on the requirements. As any owner/decision maker should know, change is not without cost—that is, change usually results in a new and later delivery date. If the owner is against changing delivery dates, the façade may make the case easier to sell. After all, if what the owner requested is presented in the façade, how could the development staff be blamed for delivering what was requested? If change must take place, however, the following may occur:

• Make simple changes on the current solution early on in the process.

• Up-sell more services in the immediate future on the current solution.

• Start gathering requirements for a phase 2 project.

Why Produce a Façade?

A façade is the visible representation of some structure. The façade best represents the part of design that many developers refer to as prototyping. Many infer that prototype efforts require additional work to determine how something should be built. The need for a prototype may also imply that the owner doesn't understand what development is trying to build, or that developers don't understand what the owner needs. The prototype can also be seen as a huge effort that requires a large amount of resources to generate something that cannot be sold. However, a façade, as presented here, differs from the prototype by offering alternative features that a prototype cannot offer.

Some owners can actually interfere with the development process by presuming that developers need to be micromanaged or that they do not understand the scope of the project. Rather than fight the owner's desire to participate in the process at various stages, the façade development strategy attempts to embrace the owner's participation for the positive benefits that can be gained from it.

Owners may doubt the developers' ability to deliver on time or within budget— and sometimes for good reason. Software projects are routinely delivered late or over budget, and many development problems are not revealed until close to the delivery date. Part of the solution for this problem entails notification of risks to delivery and making the owner aware of any problems as soon as possible. Another more predominant reason why developers' ability is questioned is because the requirements may not have been adequately identified, or the functional requirements may have been changed while the software was being built. The software developer leading the effort may erroneously conclude that the owner is aware of the consequences of these changes. The owner can blame developers if the product is seen as “flawed.”

Involving the owner/decision maker throughout the process solves your problem. This does not mean that they are included in technical design; rather, owners must be included in the parts of the process that mean something to them. They want to see implementation of the items they requested. The façade offers a solution that allows the owner to be involved in the process and to have some say regarding issues that arise in the development process.

The façade presentation is generally a positive experience. Developers may demonstrate their talents by offering suggestions for alternative means of providing the desired functionality. The programmers receive validation for their work from individuals outside the development world as well as the confidence gained by knowing that they were trusted to present the façade to an owner/decision maker.

Note 

A developer should exercise caution to make suggestions that fit within the global architectural considerations of the site. In the heat of the moment, an ambitious developer may obligate the delivery of a solution that works in some cases but violates a greater constraint that is not often considered.