Engraved In Stone
Researching MIS: Electronic Commerce Business Startup
Software Design Description
Release 1.0
7/27/99
Casey Chesnut
Aaron Wardrum
TBD/TBR
-diagram entire scope of system in section 4, not just examples of some diagrams
-complete section 5 of detailed design
Table Of Contents
1. Scope …………………………… 5
1.1 Identification
1.2 System Overview
1.3 Document Overview
2. Referenced Documents …………………………… 5
3. CSCI-Wide Design Decisions …………………………… 6
A. Inputs/Outputs …………………………… 6
B. Behavior …………………………… 7
C. Database/Files …………………………… 15
D. Safety/Security/Privacy …………………………… 17
E. Other CSCI-Wide Design Decisions …………………………… 17
1. Scalability
2. Availability
3. Maintainability
4. Performance
5. Transferability
4. CSCI Architectural Design …………………………… 18
4.1 CSCI Components
A. Software Units …………………………… 18
B. Static Relationship …………………………… 20
C. Purpose …………………………… 21
D. Development Status …………………………… 21
E. Hardware Utilization …………………………… 21
4.2 Concept Of Execution …………………………… 22
4.3 Interface Design …………………………… 23
4.3.1 Interface Identification Diagrams …………………………… 23
4.3.1 XXX Interface Details …………………………… 24
…
4.3.X
5. CSCI Detailed Design …………………………… 25
5.1 XXX Software Unit …………………………… 26
…
5.X
6. Requirements Traceability …………………………… 27
A. Software Unit/Package – Requirement
B. Requirement – Software Unit/Package
7. Notes …………………………… 27
A. Acronyms
B. Glossary
A. Appendixes …………………………… 28
List Of Figures
Analysis
Analysis Use Case Diagram …………………………… 6
Make Invitation Sequence Diagram …………………………… 7,8
Distribute Invitation Sequence Diagram …………………………… 9
Transaction Sequence Diagram …………………………… 10
Update Invitation Sequence Diagram …………………………… 11
RSVP Sequence Diagram …………………………… 12
Manage RSVP Sequence Diagram …………………………… 13
Monitor Site Sequence Diagram …………………………… 14
Package Diagram …………………………… 15
Architecture
Server Component Diagram …………………………… 18
Invitee Component Diagram …………………………… 19
Inviter Component Diagram …………………………… 19
Owner Component Diagram …………………………… 19
Analysis Class Diagram …………………………… 20
Hardware Deployment Diagram …………………………… 21
System Statechart Diagram …………………………… 22
Invitee User Interface Activity Diagram …………………………… 23
Inviter User Interface Screen Capture …………………………… 24
Detailed Design
Design Class Diagram …………………………… 25
Inheritance Diagrams …………………………… 26
Collaboration Diagram(s) …………………………… X
Object Diagrams …………………………… X
1. Scope
1.1 Identification
This document is the Software Design Description (SDD) for the Engraved In Stone (EIS) online wedding invitation system. It details the design effort being performed by the developers of Engraved In Stone. This design effort should reflect the intentions of Engraved In Stone’s Software Requirements Specification (SRS), as well as provide the basis for prototyping efforts and implementation of the online wedding invitation system. Finally, this document will also be referenced during testing of the final system.
1.2 System Overview
The system provides for online wedding invitations. The wedding invitation is a dynamically generated HTML page hosted at EngravedInStone.com. It consists of the information traditionally dealing with the wedding and its associated events (showers, rehearsal dinner, parties). The invitees of the individual events will be notified by email, supplied by the purchaser of the invitation. The invitee will be able to RSVP to the invitation(s) and will be provided with other communication services. The purchaser will be provided with an online interface to manage the acceptance and rejection of invitations and other information services.
1.3 Document Overview
The remainder of this document is organized as follows: Section 2 lists the documents referenced to support the SDD. Section 3 presents the CSCI-Wide Design Decisions. These design decisions were discovered through the analysis effort of generating the SRS. Section 4 consists of the Architectural (high level) view of the system. Section 5 consists of the Detailed Design of the system. Section 6 presents the traceability of the design to requirements and vice versa. Section 7 presents supplementary material to support the SDD. Throughout the document, the appropriate UML design diagrams are shown to display functional, static, and dynamic views of the system.
2. Referenced Documents
· This document conforms to the MIL-STD-498 for Software Design Descriptions.
· This document references Release 2.0 of the Software Requirements Specification for Engraved In Stone.
· The UML artifacts are compliant with UML Version 1.1.
3. CSCI-Wide Design Decisions
A. Inputs/Outputs
The inputs and outputs to the system are represented by the following use case diagram. The stick figures represent the actors, which are external to the system and interact with the system through interfaces. The actors of the online wedding invitation system are the Inviter, Invitee, and the Owner. The Inviter will invite a number of Invitees to his wedding. The Owner will receive payment and maintain the site for the Invitee’s. The ovals are individual use cases that represent the functions the system performs to provide the services that the actors desire. The use cases of the online wedding invitation are: Make Invitation, Distribute Invitation, Transaction, Update Invitation, RSVP, Manage RSVP, and Monitor Site. The Transaction use case is unique in that it is not acted on directly by an external actor. It represents a function that can only be performed indirectly through the use of the Distribute Invitation use case. This is represented by the <uses> relationship between Distribute Invitation and the Transaction use cases. The Inviter actor interacts with the following use cases: Make Invitation, Distribute Invitation (Transaction), Update Invitation, and Manage RSVP. The Invitee actor interacts with the following use cases: Distribute Invitation and RSVP. The Invitee does not initiate the Distribute Invitation use case, but is a data sink for the output of the Distribute Invitation use case, initiated by the Inviter. The Owner actor interacts with the following use cases: Transaction and Monitor Site. The Owner does not provide any inputs for the Transaction use case.
B. Behavior
The behavior of the system is modeled as sequence diagrams. Each use case has its own corresponding sequence diagram. The sequence diagram shows the flow of data between the system and external actors through interfaces, as well as for the flow of data and message calls between objects internal to the system. Data cannot flow between actors and objects unless they have the appropriate association represented in the class diagram. Only some of the objects of the class diagram are required to support the function of each individual use case. The scenarios represented are the most common path through the system and do not detail alternate scenarios. The scenarios are also time dependent and happen in sequence. The transitions internal and external to scenarios might be either synchronous or asynchronous.
B.1 Make Invitation
B.1.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to create the wedding invitation online.
B.1.2 Inputs
The Inviter inputs the appropriate textual and graphical data into the html forms, concerning the wedding ceremony itself, and submits the information to the web server.
B.1.3 Processing
The web server manages the collection of the data from the html forms and uses the information to generate the online wedding invitation.
B.1.4 Outputs
The online wedding invitation is presented to the Inviter, so that he/she may preview it.
B.2 Distribute Invitation
B.2.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to specify who should be notified of the online wedding invitation.
B.2.2 Inputs
The Inviter inputs the appropriate textual data into the html forms, concerning the Invitees, and submits the information to the web server.
B.2.3 Processing
The web server manages the collection of the data from the html forms and uses the information to dynamically generate email messages. The Transaction use case occurs within the context of this sequence.
B.2.4 Outputs
The email messages are sent to the appropriate Invitees to notify them of their online wedding invitation.
B.3 Transaction
B.3.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to offer the monetary transaction information to purchase the online wedding invitation. This entire sequence is performed over a secure connection.
B.3.2 Inputs
The Inviter inputs the appropriate textual data into the html form, concerning the monetary transaction, and submits the information to the web server.
B.3.3 Processing
The web server accepts the information and passes it an external system which solely provides the means to process online transactions.
B.3.4 Outputs
A dynamic html page is generated and displayed to the Inviter, so that the Inviter can monitor and track the state of the transaction.
B.4 Update Invitation
B.4.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to update and modify the information presented on the online wedding invitation.
B.4.2 Inputs
The Inviter inputs the appropriate textual data into the html form, concerning the previously generated invitation, and submits the updated information to the web server.
B.4.3 Processing
The web server manages the collection of the data from the html forms and uses the updated information to regenerate the online wedding invitation.
B.4.4 Outputs
The Inviter is presented with an html page confirming the invitation has been successfully updated.
B.5 RSVP
B.5.1 Introduction
The Invitee receives notification of the online wedding invitation through email and uses a web browser client to access the Engraved In Stone web server to RSVP for the event.
B.5.2 Inputs
The Invitee inputs textual information into the html form aspect of the online wedding invitation and submits the information to the web server.
B.5.3 Processing
The web server manages the collection of the data from the html form and uses the information to update the reservation list hosted on the server.
B.5.4 Outputs
The Invitee is presented with an html page confirming the reservation has been successful.
B.6 Manage RSVP
B.6.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to view and update the reservation list for the associated online wedding invitation.
B.6.2 Inputs
The Inviter inputs the appropriate textual data into the html form, concerning the reservation list, and submits the additional information to the web server.
B.6.3 Processing
The web server manages the collection of the data from the html forms and uses the additional information to update the reservation list.
B.6.4 Outputs
The Inviter is presented with an html page confirming the reservation list has been successfully updated.
B.7 Monitor Site
B.7.1 Introduction
The Owner uses a web browser client to access the Engraved In Stone web server to monitor the online wedding invitations and email messages that have been produced.
B.7.2 Inputs
The Owner selects the online wedding invitation to monitor from a list of the most recently created/modified invitations.
B.7.3 Processing
The web server updates the list of most recently created wedding invitations the links to its associated data store information stored as files.
B.7.4 Outputs
The Owner views the chosen online wedding invitation to monitor that the online wedding invitation system is working correctly.
C. Database/Files
Initially, the system will not incorporate a DBMS because of limited resources. Instead, persistence of data will be accomplished through file manipulation on the server. The following package diagram displays all of the file types that will be necessary to complete the online wedding invitation system. The files will fall into either two categories: ASCII or Binary. ASCII files are human-readable, Binary files are only machine-readable. Each of these packages would ultimately contain all of the files, or examples of the files, necessary to make EIS operational. These packages could also be abstracted to the use case level, in which their would be a package for each use case and each use case would contain all of the files necessary to support it. Descriptions of each package follow the package diagram.
Presentation HTML - These are the static HTML pages that compose the EIS web site. They will all have the same ‘look and feel’. An example will be the home page when the Inviter firsts enters the site at www.engravedinstone.com. The invitation itself will be saved on the server as a static HTML file, which may have some parts that are dynamically generated.
HTML Forms - These are also static HTML pages. Instead of being used for presentation, these forms are used to collect information from the user when they are specifying what they want their invitation to display. These forms will also contain JavaScript which can be used to verify that the proper information will be submitted to the web server. An example is a webpage in which the Inviter types in their ‘Contact Information’ and submits the information to the web server.
Dynamically Generated HTML - These are dynamically generated HTML pages that will not be saved to the server. These will be used to display confirmation information, such as confirming the information the user specified when creating the invitation. The invitation itself will be generated on the server, but it will also be saved to the server as a static HTML file, so that it does not have to be dynamically generated each time an Invitee wants to view the invitation.
ASCII Data Storage Text - Some of the information will be stored in a human readable form on the server. This information will only be accessible by the Owners. It will remain in human readable form so that the Owners may use scripting languages to parse the information and generate reports to help them manage the web site. An example is a list of Inviter’s contact information which the Owners can use to market new products to these individuals.
Generated Mail Messages - The dynamically generated email messages are also generated in ASCII format. These messages will not be saved on the server. An example is a copy of the email message that was sent out to a group of Invitee’s, notifying them of a new invitation, this will also be sent to the Owners so that they can monitor the site. This message will be saved in the Owner’s mail browser.