Engraved In Stone

Yüklə 84.55 Kb.
ölçüsü84.55 Kb.
Engraved In Stone
Researching MIS: Electronic Commerce Business Startup
Software Design Description
Release 1.0


Casey Chesnut

Aaron Wardrum

-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


5. CSCI Detailed Design …………………………… 25

5.1 XXX Software Unit …………………………… 26


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 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
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 <> 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.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.
Presentation Image Files - These are image files that will be displayed through the Presentation HTML files. These will support the main web site, and not individual invitations.
Uploaded Image Files - These are the image files that a user will upload to display along with the invitation that has been created. The image files will have to be in either GIF or JPG format, which are internet standard image file formats.
Binary Data Storage Text - The textual information concerning individual invitations will be saved in a binary format. It will be saved as binary so that hackers cannot modify the information. Only the Servlets on the web server will have the capability to manipulate the information in a meaningful way. An example of this type of file will be the reservation list associated with an invitation.
Invitation Package - All of the files needed to support the invitation as a stand-alone entity will be compressed into a single binary file. This file can then be downloaded by Invitee’s and Inviter’s to be kept as a keepsake, which they can keep forever and view on their local machines. Possible formats are ZIP or PDF.
Servlets - Servlets are the components with the business logic to automatically run the EIS web site. Servlets will accept the information that the Invitee’s submit to the web site, generate the invitation and save it on the server as a file. Also, servlets will be used to dynamically generate HTML and email messages.

D. Safety/Security/Privacy
The online wedding invitation has to take into account security and privacy concerns. Inviters will not want everyone to receive the wedding invitation, so they will only notify a limited number of Invitees to receive the invitation. Their will not be a link from the presentation HTML of the site to take browsing users to the invitation. Invitees will be able to view the site by going directly to the URL or by logging into the online wedding invitation system from a presentation HTML page. Either way, the Invitee will have to enter their username and password to access the invitation. Inviters will have the capability to choose not to use this security restriction for Invitees. Inviters will have to login to the system with a password to update their invitation, and to manage RSVPs. This will keep Invitees from maliciously changing the content of the invitation or modifying the reservation list. Security will also have to be handled during the transaction. A secure connection will be established using SSL so that the integrity of the users credit card number will not be violated. Owners will have super privileges to the web site which will allow them to monitor all information being passed through the system, to verify that the site is working correctly and to support the Inviters properly. EIS will choose an appropriate ISP to support the online wedding invitation system and handle all of its low level web service issues.
E. Other CSCI-Wide Design Decisions

  • Scalability – because of limited resources, EIS will start out using a virtual web hosting service, running a Java web server, and storing data to files. This configuration should be adequate to support the business plan of EIS. If scalability becomes an issue, the system would be moved to its own server, running an application server, connected to a DBMS.

  • Availability – the system has to be available 24 hours a day. The largest possible number of clients will be supported because users will only require a standard web browser. All modifications to the web site will be handled on the server and will not effect client access.

  • Maintainability – the system is automated and will be tuned to maintain itself, but it will be maintained at a number of different levels. The Inviters will use the system to maintain their own invitations. The Owners will maintain the site through the use of the system and by interacting directly with the Java web server. The web hosting administrators will also maintain the site by directly interacting with the server.

  • Performance – the system does not have any performance requirements. If performance becomes an issue, it can be improved through the same means which would be used to improve scalability. Performance should not be an issue, because the site is neither data, processing, not bandwidth intensive.

  • Transferability – the system complies with many standards so that it is portable. From a clients perspective it complies with HTML, HTTP, and MIME standards. From the owners perspective, the system will be implemented using Java on the server so that EIS will not be tied down to a single platform or web hosting service provider. This is also supported through the purchase of the engravedinstone.com domain name, which abstracts the virtual company from having to reside on the same web server.

4. CSCI Architectural Design
4.1 CSCI Components
A. Software Units
The software units are represented by the following component diagrams. The primary components are a Web server, Inviter, Invitee, and Owner components. The Web Server components can be further decomposed, and will consist of a Java Web Server, File Server, Email Server, Servlet Engine, and a Standard Web Server. A Java Web Server is comprised of a Servlet Engine along with a Standard Web Server. The Standard Web Server handles the static interfaces to external clients through HTML, HTTP, and MIME. It also directs this information to the Servlet Engine. The Servlet Engine hosts the servlets that will be developed by the Owners of EIS. The servlets are components that will incorporate the business logic to automate the online wedding invitation system and support all of its dynamic functions. The servlets will use the Email Server to pass the email messages that they dynamically generate. The servlets will also use the File Server to store and retrieve information. Finally, the servlets will pass information to the web server which will display the information as dynamically generated web pages. At a higher level, and in a more traditional sense, the Web Server will also interact with the Email server to receive questions and comments from clients, as well as interact with the File Server to retrieve the presentation HTML pages and the associated image files.

The Invitee components consist of a Web Browser and a Mail Browser. The Mail Browser will be used to retrieve notification of the invitation and provide the link to the invitation. The Web Browser will display the invitation and allow the Invitee to RSVP. The Invitee will only interact with the Email Server and the Web Server components of the Java Web Server.

The Inviter components primarily consist of a Web Browser. A standard browser such as Netscape Navigator or Internet Explorer is all that an Inviter will need to create, update, and manage their invitation. The Inviter will only interact with the Web Browser of the Java Web Server.
The Owner components consist of a Web Browser, FTP Client, and a Telnet Client. The Web Browser allows the Owners to monitor the site through master servlets that only the Owners have access privileges to. The FTP and Telnet Clients connect directly to the Java web server to allow the Owners to modify any aspect of the site.

B. Static Relationship

The online invitation system was also modeled as a class diagram. Class diagrams represent the static associations between objects in the system. The classes derived from the analysis are: Inviter, Reservation, Invitation, and Mail. Inviter was an external actor in the use case view, but it was determined that a class would also have to be developed to maintain state for individual actor objects. Invitee remains as an actor in the system in the static view because it was not deemed necessary at this point in time to collect their state information. The information needed to contact Invitee’s is currently handled by the Mail class. The associations between the classes, show which objects can interact directly and indirectly with other objects. Attributes and methods were only defined in so much as to help describe the primary purpose of the class. UML design artifacts, such as collaboration diagrams, would provide the exercise to flesh out the complete set of attributes and methods necessary to support the system. The system is decomposed in these low level objects to that Engraved In Stone can experience reuse. An example might be that the Mail class could be reused in a baby announcement system.

C. Purpose

Tailored out of this document.
The purpose of the software components has already been covered in previous sections of this document.
D. Development Status
All of the components displayed in the component diagrams can be purchased as COTS products. Each of the actors will have purchased their own components to support the system. The Web Server components will have been purchased from a web hosting service and the use of the components will be purchased as a service by the Owners.
The EIS online wedding invitation system will be newly developed. The presentation content using static HTML pages, forms, and images will be developed by the Owners. The dynamic server side servlet components will also be developed by the Owners.
A working prototype of the technology needed to support the site has been completed and is detailed in Appendix A of this document.
E. Hardware Utilization
The following deployment diagram shows the hardware architecture that will support the EIS online wedding invitation system. The Inviter, Invitee, and Owner components will execute on their respective PC Clients. The Inviter and Invitee will connect to the Java Web Server indirectly through their own ISPs, over the internet. The Owner will connect to the Java Web Server directly, because the Java Web Server is also their ISP. The Owners can also connect to the Java Web Server through third party ISPs, although some access privileges will be reduced.

4.2 Concept Of Execution
The following statechart diagram represents the following modes that the system can be in, as well as the roles of the external actors which will be operating in those modes. Each of the modes is directly related to a functional use case. The system can concurrently operate in a number of these modes at once, supporting multiple clients simultaneously. An example is that one or more Inviters can be creating invitations and/or distributing invitations at the same time Invitees are RSVP’ing to different invitations while the Owners are monitoring various activities of the site. The only restriction is that a single client can only be in one mode of operation at a time. An example is that an Inviter cannot be creating an invitation and distributing the invitation at the same time.

4.3 Interface Design
4.3.1 Interface Identification Diagrams
The following activity diagram describes the interface the Invitee used to RSVP an invitation. It includes the use of both of the components that comprise the Invitee components. This type of diagram would be generated for the interfaces to accomplish each of the use cases.

4.3.1 XXX Interface Details
The following screen capture is of what a typical HTML form page will look like. This specific HTML form is to collect the Inviters contact information. Mandatory form fields are designated in a bold typeface. The transaction cannot be processed without content being supplied in these field. JavaScript will run on the client side component to ensure that the fields are filled in correctly with the appropriate information. The only form components being used in this example are text fields and pull down menus. Other forms components might include check boxes, text areas, etc… This prototype does not include a submit button, which will be necessary on a finished product to submit the information to the Java web server through the HTTP protocol, so that a servlet can process the information on the server. Also, this prototype form does not include any presentation items to make the form less imposing or any links to associated pages to help the Inviter interact with the system.

5. CSCI Detailed Design
The following diagram shows the preliminary version of the online wedding invitation system detailed design class diagram. Some of the classes from the anlaysis class diagram have been abstracted to more generalized classes to provide for reuse in the future, for such products as Birth Announcements and Baby/Wedding Albums. Following the design class diagram are its associated inheritance diagrams. These diagrams are represented separately to reduce the complexity of the individual diagrams. They could all be represented on the same diagram because they are at the same level of abstraction. The invitation class is further decomposed into possible packages, which might be represented better as a ternary relationship between the user, the product, and a package class.

5.1 Individual Software Unit
A. Unit Design Decisions

B. Constraints/Limitations

C. Programming Language Rationale

D. Procedural Commands

E. Inputs/Outputs/Data Elements

F. Logic


6. Requirements Traceability

The use case driven approach of the Unified Modeling Language ensures traceability of requirements by allowing for a seamless transition from analysis to design. It also allows for a mapping of requirements to test cases, because during integration the use cases become the test cases of the system. The seamless transition from analysis to design is because preliminary design artifacts are discovered during use case analysis. These design objects become the basis for the design of the system which maps back to the functional requirements of the system, represented as use cases.
A. Software Unit/Package – Requirement

Tailored out of this document.

B. Requirement – Software Unit/Package

Tailored out of this document.

7. Notes
A. Acronyms
API Application Programming Interface

ASCII American Standard Code for Information Interchange

CASE Computer Aided Software Engineering

COTS Commercial Off The Shelf

CSCI Computer Software Configuration Item

DBMS DataBase Management System

DID Data Item Description

DoD Department of Defense

EIS Engraved In Stone

FTP File Transfer Protocol

GIF Graphics Interchange Format

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IEEE Institute of Electrical and Electronics Engineers

ISP Internet Service Provider

JPG Joint Photographic (E)xperts Group format

MIL-STD Military Standard

MIME Multipurpose Internet Mail Extensions

MIS Management Information Systems

OO Object Oriented

OS Operating System

PC Personal Computer

PDF Portable Document Format

RSVP Repondez Sil Vous Plait

SDD Software Design Description

SRS Software Requirements Specification

SSL Secure Socket Layer

TBD To Be Determined
TBR To Be Resolved

UML Unified Modeling Language

URL Universal Resource Locator
B. Glossary

Tailored out of this document.

A. Appendixes
Technology Prototype
The prototype is a technology feasibility prototype for developers and is not a proof of concept prototype for end users. It is also not a typical prototype in that it actually works, and is not just made to look like it is working. Specifically, it prototypes all of the main functionality that the online wedding invitation system is going to have to offer. First, it prototypes the client side handling of forms. It accepts ascii textual data, as well as a binary image file from the end user. Next, it prototypes the transfer of both the ascii and binary data to the java web server. The web server generates an ascii text file and saves it to the server, along with uploading the binary image file. Then, it prototypes the Java web server dynamically generating an email message, along with dynamically generating an html message. Finally, it prototypes hosting the created HTML file and uploaded image on the web server. The languages used to develop this prototype include HTML, Java, and Servlets. JavaScript was the only language not prototyped, which will be used in the ultimate system. The prototype uses the standard components of the system, such as the email and web browser. The Java web server is emulated as by an application called the Servletrunner, which is a fully Servlet specification compliant stand-alone utility used for testing servlets. Although both the client and Java web server are operating on the same machine, they are communication to each other through the use of the internet protocols, so that the prototype would operate correctly if it were distributed onto separate machines. Thus, if EIS currently had access to a Java web server, this prototype would work in the exact same manner as the completed system will. It successfully demonstrates the robustness of the development environment chosen for the system and its capabilities to support the entire scope of the online wedding invitation system. The only aspects it is lacking is the presentation aspects of the system along with error handling procedures, which will have to be thorough to provide an entirely automated system.
steps for running the prototype:

  • connect to dial up RNA account, no new messages in mailbox

  • kc.jpg in c:\ and not anywhere else on harddrive

  • startserver from servlets folder

  • open http://localhost:8080/file.html in netscape

  • -file is in C:\jsdk2.1\webpages\file.html

  • submit text name and file

  • it uploads the file and dynamically generates html and email

  • check email for location of new file

  • -new file is at c:\jsdk2.1\examples\fileMade.html

  • go to that directory and double clock on that file

  • -delete the fileMade.html and kc.jpg from that directory

  • run stopserver from servlets directory

  • close internet connection

  • close all open windows

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azrefs.org 2016
rəhbərliyinə müraciət

    Ana səhifə