|Engraved In Stone
Researching MIS: Electronic Commerce Business Startup
Software Design Description
-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.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
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. 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
Design Class Diagram …………………………… 25
Inheritance Diagrams …………………………… 26
Collaboration Diagram(s) …………………………… X
Object Diagrams …………………………… X
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
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.
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
The Inviter uses a web browser client to access the Engraved In Stone web server to create the wedding invitation online.
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.
The web server manages the collection of the data from the html forms and uses the information to generate the online wedding invitation.
The online wedding invitation is presented to the Inviter, so that he/she may preview it.
B.2 Distribute Invitation
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.
The Inviter inputs the appropriate textual data into the html forms, concerning the Invitees, and submits the information to the web server.
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.
The email messages are sent to the appropriate Invitees to notify them of their online wedding invitation.
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.
The Inviter inputs the appropriate textual data into the html form, concerning the monetary transaction, and submits the information to the web server.
The web server accepts the information and passes it an external system which solely provides the means to process online transactions.
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
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.
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.
The web server manages the collection of the data from the html forms and uses the updated information to regenerate the online wedding invitation.
The Inviter is presented with an html page confirming the invitation has been successfully updated.
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.
The Invitee inputs textual information into the html form aspect of the online wedding invitation and submits the information to the web server.
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.
The Invitee is presented with an html page confirming the reservation has been successful.
B.6 Manage RSVP
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.
The Inviter inputs the appropriate textual data into the html form, concerning the reservation list, and submits the additional information to the web server.
The web server manages the collection of the data from the html forms and uses the additional information to update the reservation list.
The Inviter is presented with an html page confirming the reservation list has been successfully updated.
B.7 Monitor Site
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.
The Owner selects the online wedding invitation to monitor from a list of the most recently created/modified invitations.
The web server updates the list of most recently created wedding invitations the links to its associated data store information stored as files.
The Owner views the chosen online wedding invitation to monitor that the online wedding invitation system is working correctly.
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.
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.
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.
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
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
C. Programming Language Rationale
D. Procedural Commands
E. Inputs/Outputs/Data Elements
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.
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
Tailored out of this document.
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