csps software architecture document 1
TRANSCRIPT
13/01/12 CSPS Software Architecture Document 1.0
1/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Collegiate Sports Paging System
Software Architecture Document
Version 1.0
Revision History
Date Version Description Author
November 30, 1999 1.0 Initial Version
Table of Contents
IntroductionArchitectural RepresentationArchitectural Goals and ConstraintsUse-Case ViewLogical ViewProcess ViewDeployment ViewImplementation ViewSize and PerformanceQuality
Introduction
Purpose
This document provides a comprehensive architectural overview of the system, using a number of differentarchitectural views to depict different aspects of the system. It is intended to capture and convey thesignificant architectural decisions which have been made on the system.
Scope
This Software Architecture Document applies to the Collegiate Sports Paging System which will bedeveloped by Context Integration.
Definitions, Acronyms and Abbreviations
See Glossary.
References
1. CSPS Vision 1.02. CSPS Requirements Management Plan 1.03. CSPS Iteration Plan 1.0
13/01/12 CSPS Software Architecture Document 1.0
2/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
4. CSPS Supplementary Specification 1.05. CSPS Use Case - Approve Story 1.06. CSPS Use Case - Edit Profile 1.07. CSPS Use Case - Pay Fee With Credit Card 1.08. CSPS Use Case - Print Advertiser Reports 1.09. CSPS Use Case - Provide Advertising Content 1.0
10. CSPS Use Case - Provide Feedback 1.011. CSPS Use Case - Read Content on Website 1.012. CSPS Use Case - Send Content 1.013. CSPS Use Case - Send Page 1.014. CSPS Use Case - Subscribe 1.0
Architectural Representation
This document presents the architectural as a series of views; use case view, process view, deploymentview, and implementation view. These views are presented as Rational Rose Models and use the UnifiedModeling 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 web site provides most of the content for display. An interface to thissystem 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 besent 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 theSupplementary Specification [7], must be taken into consideration as the architecture is beingdeveloped.
Use-Case View
A description of the use-case view of the software architecture. The Use Case View is important input to theselection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set ofscenarios and/or use cases that represent some significant, central functionality. It also describes the set ofscenarios and/or use cases that have a substantial architectural coverage (that exercise many architecturalelements) 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. Adescription of these use cases can be found later in this section.
Approve StoryClick on Banner AdEdit ProfileModify StoryPay Fee With Credit CardPrint Advertiser ReportsProvide FeedbackRead Content on Web SiteRead Public ContentReject StoryPost ContentSend PageSubscribe
The following diagrams depict the use cases in the system.
13/01/12 CSPS Software Architecture Document 1.0
3/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Figure 1 - Potential Subscriber Use Cases
Figure 2 - Subscriber Use Cases
13/01/12 CSPS Software Architecture Document 1.0
4/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
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
13/01/12 CSPS Software Architecture Document 1.0
5/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
This Use Case takes place when an editor approves a story for inclusion in the Collegiate SportsPaging System. Some stories will automatically propagate from the existing WebNewsOnLinesystem, but some stories will require editor intervention (either because their subject is not clearor the categories to which the story belongs are not clear). This flow is also used to approveadvertising content being posted.
2. Edit Profile
This Use Case occurs when a subscriber wishes to change their profile information or when anew 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 byspecifying a credit card number and PIN. This may also occur when an existing subscriber wantsto renew.
4. Print Advertiser Reports
This use case occurs when an advertiser accesses the Collegiate Sports Paging System toobtain reports of how their advertising content has been viewed. Advertiser selects format(Microsoft(R) Word(R), Microsoft(R) Excel(R), or HTML) for the report.
5. Provide Feedback
This use case occurs when a system user (advertiser, subscriber, or potential subscriber) wishesto 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 theweb 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 targetedinformation. Pages are dynamically built to show the user headlines for which they have beenpaged, 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 web site. Somestories will be tagged for transmission to the Collegiate Sports Paging System, and will be sentfor possible paging and display.
9. Send Page
This use case occurs when new content is posted to the Collegiate Sports Paging System. Thisincludes finding subscribers to be notified, formatting the page message, and sending the pagevia email.
10. Subscribe
This use case occurs when a potential subscriber wants to subscribe to the service. It notifiesthe user of contract terms and, if accepted, invokes the use case to edit a profile (specifyingcategories 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 organizationin service packages and subsystems, and the organization of these subsystems into layers. Also describesthe most important use-case realizations, for example, the dynamic aspects of the architecture. Class
13/01/12 CSPS Software Architecture Document 1.0
6/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
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:
Presentationcontains 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 ofadvertising reports, approving stories, providing feedback, subscribing, and paying fees with creditcards
Applicationcontains classes for major processing functionality within the system. Control classes exist tosupport advertising administration, content management, profile management, subscriptionprocessing, paying fees with credit cards, and providing feedback.
Domaincontains packages containing classes to support Content, Profile, Subscription, and Support.
Persistencecontains classes to persist specific objects within the system. At this point in the design, onlyProfiles are persisted, though Content objects may be persisted at some future point (a selectionof a packaged content management system may obviate the need for this).
Servicescontains classes to provide system-level classes for maintenance purposes - at this time, allmaintenance is manual.
Logical View
13/01/12 CSPS Software Architecture Document 1.0
7/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Presentation Package
13/01/12 CSPS Software Architecture Document 1.0
8/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Application Package
13/01/12 CSPS Software Architecture Document 1.0
9/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Domain Package
13/01/12 CSPS Software Architecture Document 1.0
10/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Content Package
13/01/12 CSPS Software Architecture Document 1.0
11/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Profile Package
13/01/12 CSPS Software Architecture Document 1.0
12/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Subscribe Package
Support Package
13/01/12 CSPS Software Architecture Document 1.0
13/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
Persistence Package
Process View
This section describes the system's decomposition into lightweight processes (single threads of control) andheavyweight processes (groupings of lightweight processes). Organize the section by groups of processesthat communicate or interact. Describe the main modes of communication between processes, such asmessage passing, interrupts, and rendezvous.
At this point in the design, a single process is envisioned to provide server-level functions for the CollegiateSports Paging System. Threads for application functions will be part of this process (application functionsare listed in the previous section). The process diagram of the system can be viewed as follows:
Deployment View
13/01/12 CSPS Software Architecture Document 1.0
14/14www.baufest.com/rup/LargeProjects/informal_resources/guidances/examples/resources/ex_sad.htm
This section describes one or more physical network (hardware) configurations on which the software isdeployed 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.) Alsoinclude 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 Gatewayis 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 achievedby providing multiple levels of Pager Gateway, or by simply providing additional Pager Gateway systemswithin the same tier.
Quality
The software as described above supports the existing WebNewsOnLine graphical standards, interfaces withthe existing WebNewsOnLine server, and provides a self-describing user interface.
Copyright 1987 - 2003 Rational Software Corporation