Initial Requirements Analysis and Design

For Online Photo Shop, we conduct a high-level analysis to show the various modules and packages of the project, their grouping, and a sequence diagram. In the elaboration phase (Chapter 5), we will show how to do a more detailed analysis and how to derive the architecture from the analysis.

The first step in analyzing the requirements and developing the high-level, overall system design is to identify the underlying structure of the product. From the requirements, we identify three distinct parts: the Online Shop part, a photo-editing part, and an image-processing part. Each of the parts has its own focus on functionality.

Analyzing the requirements further shows that there are very limited dependencies between the three parts, and therefore the system is divided into the three packages. Figure 4.10 shows a UML package diagram, which is fairly simple for the Online Photo Shop project because there are limited dependencies between the packages. Furthermore, the analysis shows that there are no anticipated dependencies between the Online Photo Shop and the image-processing library.

Figure 4.10. Package Diagram for the Online Photo Shop

4.6.1 The Photo Editor

Preparing a digital photo for printing can involve many, sometimes computationally expensive steps. Furthermore, users seldom accomplish the desired result on the first try, and when that happens they start over with a new image from scratch. Driven by the fact that photo postprocessing is typically an offline task, we implement the photo editor as a smart client application that can be downloaded from the business's Web site. The photo editor will provide the customer with a graphical user interface (GUI) to prepare an image for printing. Figure 4.11 shows a UML sequence diagram that illustrates a typical workflow for the Online Photo Shop system.

Figure 4.11. Sequence Diagram for Online Photo Shop

Sequence diagrams are used to visualize interactions among systems or objects, in this case the customer, the photo editor, the image-processing library, the online shop, and the business. These are shown as boxes at the top of a sequence diagram. The vertical lines are called lifelines and represent the life of the object or system that they are connected to during an interaction. Arrows can be connected between lifelines, showing messages or actions. The sequence of occurrence is always top-down.

4.6.2 The Image-Processing Library

All image-processing algorithms are encapsulated in a library. This allows their use in new projects or, if necessary, in the online shop Web application.

4.6.3 The Online Shop

Web Forms

The online shop allows customers to select products on the business's Web site and place them into a shopping cart. At any time a customer can proceed to checkout and complete the order by providing the business with payment and shipping information. Therefore, the main online shop implementation will be implemented in those two Web forms:

• Shopping cart form: This Web form enables customers to add products to a shopping cart. This form will use ASP.NET session management to implement a personal shopping cart for each visiting customer. The Web form accepts multiform encoded HTML-form postings from any calling Web page (*.htm) or Web form (*.aspx). Product identifiers, selected product options, a digital image for customization, and the caller's URL are passed as part of the multiform data posting.
• Checkout form: This Web form collects delivery and payment information from the customer. This module computes the total order cost, including shipping and taxes.

Code Behind

The implementation of Online Photo Shop uses ASP.NET's code behind technology, which means that the logic is separated from the presentation. If you don't separate the logic (code) from the presentation (design), it is very difficult to maintain the software. Each change in the design of a Web page can potentially break the code that is embedded in it. Creating Web forms using the Microsoft Visual Studio template separates code from design using code behind.

State Management

HTTP is a connectionless protocol and therefore is stateless. This means that a request to a Web server cannot rely on any previously made requests and must carry all necessary information to generate a response. To overcome this problem, ASP.NET introduces three methods of state management, which allow the Web server to store information for each client in a session object.

• In process: The session objects are stored within the Web server's process. That allows storing of references to any kind of objects without special handling. Also, the retrieval of those objects is very fast. However, this method does not work in a Web farm approach, in which a Web application is run on a cluster of servers, because the client requests can be directed to any of the Web servers. If a request is directed to a Web server that is different from the preceding one, the session, along with its objects, is lost.
• The State service: When you use the ASP.NET State service, all the session information is stored in a separate process, which can even reside on a different computer. To use ASP.NET, State service objects that need to be stored in a session must implement serialization methods. This entails some additional implementation effort but allows for future expansion and better maintenance. When the State service resides on a dedicated machine, the Web servers in a Web farm can be rebooted without causing downtime for the online shop. Figure 4.12 shows an example of such a configuration.

  Figure 4.12. System Diagram for Online Shop

• SQL Server: State management using SQL Server is very similar to state management using the State service. In addition, SQL Server state management adds even more robustness to the system. The difference between the two methods is that the SQL Server state management method saves the state of a session in a SQL database instead of storing it in memory (as is done by the ASP.NET State service). This means that even if the designated computer that holds the session state goes down or is rebooted, the state is restored from the database after the computer is rebooted, and no state information is lost.

4.6.4 Defining Architectural Requirements

During the process of defining the initial architecture of the product, it is a good practice to describe architectural constraints in the form of new requirements that must be fulfilled in the implementation. The advantage of doing so is that the requirement key tracing takes care of making sure that the implementation was done according to the initial architecture document and that no new measurements must be implemented for this verification. Table 4.6 shows a list of requirements that apply to the online shop.