Software Architecture Document
Table of Contents
This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.
This Software Architecture Document applies to the Collegiate Sports Paging System which will be developed by Context Integration.
Definitions, Acronyms and Abbreviations
This document presents the architectural as a series of views; use case view, process view, deployment view, and implementation view. These views are presented as Rational Rose Models and use the Unified Modeling Language (UML).
There are some key requirements and system constraints that have a significant bearing on the architecture. They are:
A description of the use-case view of the software architecture. The Use Case View is important input to the selection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set of scenarios and/or use cases that represent some significant, central functionality. It also describes the set of scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture.
The use cases in this system are listed below. Use cases in bold are significant to the architecture. A description of these use cases can be found later in this section.
The following diagrams depict the use cases in the system.
Figure 1 - Potential Subscriber Use Cases
Figure 2 - Subscriber Use Cases
Figure 3 - Advertiser Use Cases
Figure 4 - Current System Use Cases
Figure 5 - Pager Gateway Use Cases
Figure 6 - Editor Use Cases
Significant Use Case Descriptions
This Use Case takes place when an editor approves a story for inclusion in the Collegiate Sports Paging System. Some stories will automatically propogate from the existing WebNewsOnLine system, but some stories will require editor intervention (either because their subject is not clear or the categories to which the story belongs are not clear). This flow is also used to approve advertising content being posted.
This Use Case occurs when a subscriber wishes to change their profile information or when a new subscriber wishes to enroll.
This use case occurs when a new subscriber wants to pay their annual subscription fee by specifying a credit card number and PIN. This may also occur when an existing subscriber wants to renew.
This use case occurs when an advertiser accesses the Collegiate Sports Paging System to obtain reports of how their advertising content has been viewed. Advertiser selects format (Word, Excel, or HTML) for the report.
This use case occurs when a system user (advertiser, subscriber, or potential subscriber) wishes to comment on the service or the web site.
This use case occurs when an advertiser wants to post advertising content (banner ads) on the web site and specify which subscriber profiles should be used for display.
This use case occurs when an active subscriber connects to the system to view targeted information. Pages are dynamically built to show the user headlines for which they have been paged, as well as general sports categories to which they subscribe.
This use case occurs when content is posted to the existing WebNewsOnLine website. Some stories will be tagged for transmission to the Collegiate Sports Paging System, and will be sent for possible paging and display.
This use case occurs when new content is posted to the Collegiate Sports Paging System. This includes finding subscribers to be notified, formatting the page message, and sending the page via email.
This use case occurs when a potential subscriber wants to subscribe to the service. It notifies the user of contract terms and, if accepted, invokes the use case to edit a profile (specifying categories to which the user wants to subscribe, pager information, credit card info, etc.).
A description of the logical view of the architecture. Describes the most important classes, their organization in service packages and subsystems, and the organization of these subsystems into layers. Also describes the most important use-case realizations, for example, the dynamic aspects of the architecture. Class diagrams may be included to illustrate the relationships between architecturally significant classes, subsystems, packages and layers.
The logical view of the Collegiate Sports Paging System is comprised of 5 main packages:
This section describes the system's decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). Organize the section by groups of processes that communicate or interact. Describe the main modes of communication between processes, such as message passing, interrupts, and rendezvous.
At this point in the design, a single process is envisioned to provide server-level functions for the Collegiate Sports Paging System. Threads for application functions will be part of this process (application functions are listed in the previous section). The process diagram of the system can be viewed as follows:
This section describes one or more physical network (hardware) configurations on which the software is deployed and run. At a minimum for each configuration it should indicate the physical nodes (computers, CPUs) that execute the software, and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping of the processes of the Process View onto the physical nodes.
The CSPS Server is a UNIX server. The Client machine is any device capable of running a Web browser (most likely a PC, but not necessarily) and of connecting to the CSPS via the Internet. The Pager Gateway is an externally-maintained device provided by paging services.
All server software resides within a single layer. The browser client provides a secondary access layer.
The software as designed will support 200,000 concurrent users. Scaling beyond this level may be achieved by providing multiple levels of Pager Gateway, or by simply providing additional Pager Gateway systems within the same tier.
The software as described above supports the existing WebNewsOnLine graphical standards, interfaces with the existing WebNewsOnLine server, and provides a self-describing user interface.