Collegiate Sports Paging System

Software Architecture Document

Version 1.0

Revision History

Date Version Description Author

November 30, 2019 1.0 Initial Version

Table of Contents

• Introduction
• Architectural Representation
• Architectural Goals and Constraints
• Use-Case View
• Logical View
• Process View
• Deployment View
• Implementation View
• Size and Performance
• Quality

Introduction

Purpose

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.

Scope
This Software Architecture Document applies to the Collegiate Sports Paging System which
will be developed by Context Integration.

Definitions, Acronyms and Abbreviations

Architectural Representation

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).

Architectural Goals and Constraints

There are some key requirements and system constraints that have a significant bearing on
the architecture. They are:

• The existing WebNewsOnLine website provides most of the content for display. An
interface to this system must be capable of handling large traffic volumes.
• The existing WebNewsOnLine legacy Finance System at will eventually be used for
billing advertisers (though this is a later release requirement). As such, advertising
usage information must be able to be sent to the system.
• All functions must be available through either of the two commercially available web
browsers.
• Any and all credit card or other financial transactions must be transmitted in a secured
manner.
• All performance and loading requirements, as stipulated in the Vision Document [1]
and the Supplementary Specification [7], must be taken into consideration as the
architecture is being developed.

Use-Case View

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.

• Approve Story
• Click on Banner Ad
• Edit Profile
• Modify Story
• Pay Fee With Credit Card
• Print Advertiser Reports
• Provide Feedback
• Read Content on Web Site
• Read Public Content
 • Reject Story
• Post Content
• Send Page
• Subscribe

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

1. Approve Story

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.

2. Edit Profile

This Use Case occurs when a subscriber wishes to change their profile information or
when a new subscriber wishes to enroll.

3. Pay Fee With Credit Card

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.

4. Print Advertiser Reports

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.

5. Provide Feedback

This use case occurs when a system user (advertiser, subscriber, or potential
subscriber) wishes to comment on the service or the web site.

6. Post Advertising Content

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.

7. Read Content on Web Site

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.

8. Send Content
 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.

9. Send Page

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.

10. Subscribe

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.).

Logical View

Overview

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:

• Presentation
o contains classes for each of the forms that the actors use to communicate with
the System. Boundary classes exist to support maintaining of profiles, posting
of advertising, printing of advertising reports, approving stories, providing
feedback, subscribing, and paying fees with credit cards
• Application
o contains classes for major processing functionality within the system. Control
classes exist to support advertising administration, content management,
profile management, subscription processing, paying fees with credit cards,
and providing feedback.
• Domain
o contains packages containing classes to support Content, Profile, Subscription,
and Support.
• Persistence
o contains classes to persist specific objects within the system. At this point in
the design, only Profiles are persisted, though Content objects may be
persisted at some future point (a selection of a packaged content management
system may obviate the need for this).
• Services
o contains classes to provide system-level classes for maintenance purposes - at
this time, all maintenance is manual.
Logical View
Presentation Package
Application Package
Domain Package
Content Package

Profile Package
Subscribe Package
Support Package

Persistence Package

Process View

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:
Deployment View

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.
Implementation View

All server software resides within a single layer. The browser client provides a secondary
access layer.

Size and Performance

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.

Quality

The software as described above supports the existing WebNewsOnLine graphical standards,
interfaces with the existing WebNewsOnLine server, and provides a self-describing user
interface.