Part III: Case Study
Chapter 13: Conceptual Design
This chapter presents a high-level overview and conceptual design for the case study associated with this book, Within-a-Click. The case study is an end-to-end membership sub-system that should allow users to perform the following basic operations:
- Create a new account by specifying typical account information, such as username, password, e-mail address, and other security-related information.
- Activate their account by specifying a system-generated account Activation Key, which will have been e-mailed to them after they created their new account.
- Log in and log out of the website.
- Update their account details, change their password, and close their account.
Although there are many third-party products and framework components to help you implement some or all of this functionality (for example, the ASP.NET Membership system), this book concentrates on designing a custom solution. This book is not intended to teach you how to implement a good membership system. The book simply uses the case study to promote and discuss some of the production-readiness challenges. This chapter is organized into the following sections:
The Guiding Principles — Reintroduces the guiding principles that were outlined in Chapter 4. The guiding principles will help to shape the design and will underpin the solution.
Online Application Walkthrough — Provides a walkthrough of the user stories and functionality specific to the Within-a-Click online application. The user stories provide the end-to-end view of the overall functionality from the end user's perspective.
Defining the Requirements — Takes the user stories outlined in the application walkthrough section and builds a set of high-level requirements for each area of functionality. It discusses some of the design choices and the comparisons between similar features and functionality that can be found on most modern websites today.
Documenting the Use Cases — Pulls together all the information from the previous sections into a set of detailed use cases that will complete the functional picture and the overall processing.
Chapter 14: Planning the Architecture
This chapter looks at planning and modeling the conceptual architecture for the case study. The storyboards, requirements, and use cases presented in the previous chapter provided a good starting point for this activity. This chapter is organized into the following sections:
The Conceptual Architecture — Discusses the high-level conceptual architecture, including the deployment concept and the transaction flow.
The Presentation Tier — Shows the conceptual web page layout and the high level processing pattern.
The Web Service Façade — Looks at the web services that provide a conduit between the web pages and the business processing components.
The Business-Processing Components — Discusses each of the different component groups in the architecture and their responsibilities.
The Logical Data Model and Data Access — Presents the conceptual data model based on the information in the previous chapter. It looks at the data access layer and the individual data entities that are used for communication between the architectural layers.
The Reporting Components — Takes a look at the reporting requirements outlined previously and the basic components that would need to be in place to support them.
Logical Component Model — Rounds off the chapter by presenting all the high-level components outlined in the previous sections in the first pass conceptual component model.
Chapter 15: Modeling the Application
This chapter examines application-specific processing and the responsibilities of each component. This chapter uses this information, especially the use-case steps, the requirements, and the logical component model, to essentially connect the dots. This chapter is organized into the following sections:
Component Responsibility Modeling — This section presents the responsibility diagram, which maps the steps documented in the use cases to high-level components in the logical component model. The diagram (or process) enables you to visualize the processing steps before formally applying them to classes and methods. It helps to solidify the component responsibilities and their inputs and outputs. It also provides a good basis for further design, review, and agreement prior to heading into full component design. This section walks through the core transactions in the case study and pulls out areas for discussion and interest.
Web Page Processing — This section uses the information (inputs and outputs) gathered in the previous section to capture and highlight the key web page processing areas. These primarily include state management, page transitions, and access control.
Business Processing — The basic responsibility models identify the key methods, inputs, outputs, and processing steps that the components will perform.
Batch Processing — This section looks at the individual batch jobs and batch processing.
Reports — This section looks at the individual reporting components.