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
……………………………
1.1 Identification
1.2 System Overview
1.3 Document Overview
2. Referenced Documents
……………………………
3. CSCI-Wide Design Decisions
……………………………
A. Inputs/Outputs
……………………………
B. Behavior
……………………………
C. Database/Files
……………………………
D. Safety/Security/Privacy
……………………………
E. Other CSCI-Wide Design Decisions ……………………………
17
1. Scalability
2. Availability
3. Maintainability
4. Performance
5. Transferability
4. CSCI Architectural Design
……………………………
4.1 CSCI Components
A. Software Units
……………………………
B. Static Relationship
……………………………
C. Purpose
……………………………
D. Development Status
……………………………
E. Hardware Utilization
……………………………
4.2 Concept Of Execution
……………………………
4.3 Interface Design
……………………………
4.3.1 Interface Identification Diagrams
……………………………
4.3.1 XXX Interface Details
……………………………
…
4.3.X
5. CSCI Detailed Design
……………………………
25
5.1 XXX Software Unit
……………………………
…
5.X
6. Requirements Traceability
……………………………
A. Software Unit/Package – Requirement
B. Requirement – Software Unit/Package
7. Notes
……………………………
A. Acronyms
B. Glossary
A. Appendixes
……………………………
5
5
6
6
7
15
17
18
18
20
21
21
21
22
23
23
24
26
27
27
28
List Of Figures
Analysis
Analysis Use Case Diagram
……………………………
6
Make Invitation Sequence Diagram
Distribute Invitation Sequence Diagram
Transaction Sequence Diagram
Update Invitation Sequence Diagram
RSVP Sequence Diagram
Manage RSVP Sequence Diagram
Monitor Site Sequence Diagram
……………………………
……………………………
……………………………
……………………………
……………………………
……………………………
……………………………
7,8
9
10
11
12
13
14
Package Diagram
……………………………
15
Server Component Diagram
Invitee Component Diagram
Inviter Component Diagram
Owner Component Diagram
……………………………
……………………………
……………………………
……………………………
18
19
19
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
Design Class Diagram
……………………………
25
Inheritance Diagrams
……………………………
26
Collaboration Diagram(s)
……………………………
X
Object Diagrams
……………………………
X
Architecture
Detailed Design
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.
: Invitation
: Inviter
initiate order
display available packages
choose package
display invitation template
choose template
display contact information form
contact information
: Invitation
: Inviter
display wedding service info form
wedding service info
display associated event info form
info
guest and registry info form
info
ceremony details form
info
display information for confirmation
confirm
display image file upload form
image files
generates invitation
invitation preview
DISTRIBUTE INVITATION USE CASE
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.
: Mail
: Inviter
: Invitee
initiate distribution
display guest list form
attendants
generate guest/event matrix
display guest/event matrix form
designate attendants for specific events
display personal message form
personal message text
TRANSACTION USE CASE
generate email message
sends email messages
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.
Actor : Inviter
: Owner
: Inviter
initiate financial transaction
display transaction form
credit card info
process transaction
transaction tracking info
payment
provide notice of invitation creation
DISTRIBUTE INVITATION USE CASE
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.
: Invitation
Actor : Inviter
initiate update
display information form with current info
modified information
regenerate invitation
update confirmation
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.
: Reservation
: Invitation
: Mail
: Invitee
receives email message
views invitation
RSVPs
update reservation list
RSVP confirmation
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.
: Reservation
: Inviter
initiate reservation review
generate RSVP page
display reservations
updates reservations
update reservation list
update confirmation
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.
: Invitation
: Owner
: Inviter
request list changed/modified invitations
display most recent invitations
select invitation to audit
display selected invitation and associated information
audit invitation and transaction for errors
notify inviter of any errors
fix error
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.
ASCII
Binary
Presentation
HTML
Presentation
Image Files
HTML Forms
Uploaded Image
Files
Dynamically
Generated HTML
ASCII Data
Storage Text
ASCII Data
Storage Text
Invitation
Package
Generated Mail
Messages
Servlets
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.
Web Server
Components
Email
Server
Java Web
Server
Invitee
Components
Servlet
Engine
Web
Server
Inviter
Components
File
Server
Owner
Components
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.
Web
Browser
Invitee
Components
Mail
Browser
Inviter
Components
Web
Browser
Web
Browser
Owner
Components
Telnet
Client
FTP
Client
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.
Java Web Hosting Server
Invitee PC
Client
Personal
Computer
Owner
PC Client
ISP 'A' Server
Connections
through
internet
backbone
Dial-up
modem
connections
Inviter PC
Client
4.2 Concept Of Execution
ISP 'B' Server
Invitee
PC Client
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.
Owner
Idle
Monitored by Owner
Inviter
Invitee
Managing RSVP
Inviter
Inviter
Accepting RSVP
Inviter
Updating Invitation
Distributing Invitation
Generating Invitation
Return To Idle
Processing Transaction
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.
Receive Notification Email
Click Link
Enter Login Information
Login Accepted?
No
Decision
No
Send Email for Help
Yes
Sign Guestbook
View Invitation
RSVP
Receive Confirmation Email
Leave Personal Message
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
OBJECT DIAGRAMS
A. Unit Design Decisions
B. Constraints/Limitations
C. Programming Language Rationale
D. Procedural Commands
E. Inputs/Outputs/Data Elements
F. Logic
…
5.X
…
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