MIL-STD-498 Software Design Description Outline · Web viewThis document conforms to the...

Engraved In Stone

Researching MIS: Electronic Commerce Business Startup

Software Design Description

Release 1.07/27/99

Casey ChesnutAaron 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 …………………………… 51.1 Identification1.2 System Overview1.3 Document Overview

2. Referenced Documents …………………………… 53. CSCI-Wide Design Decisions …………………………… 6

A. Inputs/Outputs …………………………… 6B. Behavior …………………………… 7C. Database/Files …………………………… 15D. Safety/Security/Privacy …………………………… 17E. Other CSCI-Wide Design Decisions…………………………… 17

1. Scalability2. Availability3. Maintainability4. Performance5. Transferability

4. CSCI Architectural Design …………………………… 184.1 CSCI Components

A. Software Units …………………………… 18B. Static Relationship …………………………… 20C. Purpose …………………………… 21D. Development Status …………………………… 21E. Hardware Utilization …………………………… 21

4.2 Concept Of Execution …………………………… 224.3 Interface Design …………………………… 23

4.3.1 Interface Identification Diagrams …………………………… 234.3.1 XXX Interface Details …………………………… 24…4.3.X

5. CSCI Detailed Design …………………………… 255.1 XXX Software Unit …………………………… 26…5.X

6. Requirements Traceability …………………………… 27A. Software Unit/Package – RequirementB. Requirement – Software Unit/Package

7. Notes …………………………… 27A. AcronymsB. Glossary

A. Appendixes …………………………… 28

List Of Figures

Analysis

Analysis Use Case Diagram …………………………… 6

Make Invitation Sequence Diagram …………………………… 7,8Distribute Invitation Sequence Diagram …………………………… 9Transaction Sequence Diagram …………………………… 10Update Invitation Sequence Diagram …………………………… 11RSVP Sequence Diagram …………………………… 12Manage RSVP Sequence Diagram …………………………… 13Monitor Site Sequence Diagram …………………………… 14

Package Diagram …………………………… 15

Architecture

Server Component Diagram …………………………… 18Invitee Component Diagram …………………………… 19Inviter Component Diagram …………………………… 19Owner Component Diagram …………………………… 19

Analysis Class Diagram …………………………… 20

Hardware Deployment Diagram …………………………… 21

System Statechart Diagram …………………………… 22

Invitee User Interface Activity Diagram …………………………… 23

Inviter User Interface Screen Capture …………………………… 24

Detailed Design

Design Class Diagram …………………………… 25

Inheritance Diagrams …………………………… 26

Collaboration Diagram(s) …………………………… X

Object Diagrams …………………………… X

1. Scope

1.1 Identification

This document is the Software Design Description (SDD) for the Engraved In Stone (EIS) online wedding invitation system. It details the design effort being performed by the developers of Engraved In Stone. This design effort should reflect the intentions of Engraved In Stone’s Software Requirements Specification (SRS), as well as provide the basis for prototyping efforts and implementation of the online wedding invitation system. Finally, this document will also be referenced during testing of the final system.

1.2 System Overview

The system provides for online wedding invitations. The wedding invitation is a dynamically generated HTML page hosted at EngravedInStone.com. It consists of the information traditionally dealing with the wedding and its associated events (showers, rehearsal dinner, parties). The invitees of the individual events will be notified by email, supplied by the purchaser of the invitation. The invitee will be able to RSVP to the invitation(s) and will be provided with other communication services. The purchaser will be provided with an online interface to manage the acceptance and rejection of invitations and other information services.

1.3 Document Overview

The remainder of this document is organized as follows: Section 2 lists the documents referenced to support the SDD. Section 3 presents the CSCI-Wide Design Decisions. These design decisions were discovered through the analysis effort of generating the SRS. Section 4 consists of the Architectural (high level) view of the system. Section 5 consists of the Detailed Design of the system. Section 6 presents the traceability of the design to requirements and vice versa. Section 7 presents supplementary material to support the SDD. Throughout the document, the appropriate UML design diagrams are shown to display functional, static, and dynamic views of the system.

2. Referenced Documents

This document conforms to the MIL-STD-498 for Software Design Descriptions.

This document references Release 2.0 of the Software Requirements Specification for Engraved In Stone.

The UML artifacts are compliant with UML Version 1.1.

3. CSCI-Wide Design Decisions

A. Inputs/Outputs

The inputs and outputs to the system are represented by the following use case diagram. The stick figures represent the actors, which are external to the system and interact with the system through interfaces. The actors of the online wedding invitation system are the Inviter, Invitee, and the Owner. The Inviter will invite a number of Invitees to his wedding. The Owner will receive payment and maintain the site for the Invitee’s. The ovals are individual use cases that represent the functions the system performs to provide the services that the actors desire. The use cases of the online wedding invitation are: Make Invitation, Distribute Invitation, Transaction, Update Invitation, RSVP, Manage RSVP, and Monitor Site. The Transaction use case is unique in that it is not acted on directly by an external actor. It represents a function that can only be performed indirectly through the use of the Distribute Invitation use case. This is represented by the <<uses>> relationship between Distribute Invitation and the Transaction use cases. The Inviter actor interacts with the following use cases: Make Invitation, Distribute Invitation (Transaction), Update Invitation, and Manage RSVP. The Invitee actor interacts with the following use cases: Distribute Invitation and RSVP. The Invitee does not initiate the Distribute Invitation use case, but is a data sink for the output of the Distribute Invitation use case, initiated by the Inviter. The Owner actor interacts with the following use cases: Transaction and Monitor Site. The Owner does not provide any inputs for the Transaction use case.

RSVP

Update Invitation

Manage RSVP

Make Invitation

InviteeInviter

nameaddressphone

emailAddresstransactionNumber

pay()

Distribute Invitation

Transaction

<<uses>>

Monitor Site

Owner

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 IntroductionThe 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.

: Inviter

: Invitation

initiate order

display available packages

choose package

display invitation template

choose template

display contact information form

contact information

: Inviter

: Invitation

generates invitation

invitation preview

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

DISTRIBUTE INVITATION USE CASE

B.2 Distribute Invitation


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.

: Inviter : Mail : Invitee

initiate distribution

sends email messages

display guest list form

attendants

display personal message form

personal message text

generate guest/event matrix

display guest/event matrix form

designate attendants for specific events

generate email message

TRANSACTION USE CASE

B.3 Transaction


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.

: InviterActor : Inviter

initiate financial transaction

display transaction form

credit card info

process transaction

transaction tracking info

DISTRIBUTE INVITATION USE CASE

: Owner

provide notice of invitation creation

payment

B.4 Update Invitation


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.

Actor : Inviter

: Invitation

initiate update

display information form with current info

modified information

regenerate invitation

update confirmation

B.5 RSVP

B.5.1 IntroductionThe 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.

: Mail

: Invitee

: Reservation : Invitation

receives email message

views invitation

RSVPs

update reservation list

RSVP confirmation

B.6 Manage RSVP


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

updates reservations

generate RSVP page

display reservations

update confirmation

update reservation list

B.7 Monitor Site

B.7.1 IntroductionThe 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.

: Owner : Invitation : 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.

Presentation HTML

HTML Forms

Dynamically Generated HTML

Presentation Image Files

ASCII Data Storage Text

ASCII Data Storage Text

Invitation Package

Servlets

ASCII Binary

Uploaded Image Files

Generated Mail Messages

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.

File Server

Web Server

Servlet Engine

Email Server

Java Web Server

Invitee Components

Inviter Components Owner

Components

Web Server 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.

Invitee Components

Web Browser

Mail Browser

Web Browser

Inviter Components

Owner Components

Web Browser

Telnet Client

FTP Client

B. Static RelationshipThe 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.

Invitee

MailinviteeNameemailAddressemailTextemailSubjectinvitationURL

sendMail()

receives

ReservationreservedListdeclinations

updateList()generateList()

Invitationwhowhatwhenwherewhyhow

makeReservation()generateInvitation()updateInvitation()

views

handles notifies invitees of

Inviter

nameaddressphone

emailAddresstransactionNumber

pay()

views1

1..*

1

1..*

creates

Owner

monitors

supports

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

Java Web Hosting ServerInvitee PC

Client

Inviter PC Client

Owner PC Client

ISP 'A' Server

Connections through internet backbone

ISP 'B' ServerInvitee

PC Client

Dial-up modem connections

Personal Computer

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.

Idle Monitored by Owner

Generating Invitation

Distributing Invitation

Processing Transaction

Updating Invitation

Accepting RSVP

Managing RSVP

Inviter

Inviter

Inviter

Invitee

Inviter

Owner

Return To Idle

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

Send Email for HelpDecision

View Invitation

RSVP

Receive Confirmation Email

Login Accepted?

Yes

NoNo

Sign Guestbook 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.

Mail

inviteeNameemailAddressemailTextemailSubjectinvitationURL

sendMail()

(from Use Case View)

Reservation

reservedListdeclinationsproductuser

getReservation()setReservation()


Imageproduct

getImage()setImage()

UserusernamepasswordnameemailAddress

getUser()setUser()login()

0..*0..*

sends

0..*0..*

updates

Productmailinviterwhowhatwhenwherewhyhow

getProduct()setProduct()

11

notifies users of 0..*0..*

creates

0..*

1

0..*

1

0..*1 0..*1

PasswordListuserproductprivilege

getPrivilege()setPrivilege()

is part of

5.1 Individual Software Unit

OBJECT DIAGRAMS

A. Unit Design DecisionsB. Constraints/LimitationsC. Programming Language RationaleD. Procedural CommandsE. Inputs/Outputs/Data ElementsF. Logic

…

5.X…

UserusernamepasswordnameemailAddress

getUser()setUser()login()

Invitee

reservation

RSVP()


Inviter

addressphone

transactionNumber

pay()update()create()

(from Use Case View)Owner

monitor()


Announcementsexweight

AlbumimageList

Invitation

reservationpasswordList


Productmailinviterwhowhatwhenwherewhyhow

getProduct()setProduct()

Silver GoldgenericImage

TitaniumuploadedImage

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 – RequirementTailored out of this document.

B. Requirement – Software Unit/PackageTailored out of this document.

7. Notes

A. Acronyms

API Application Programming InterfaceASCII American Standard Code for Information InterchangeCASE Computer Aided Software EngineeringCOTS Commercial Off The ShelfCSCI Computer Software Configuration ItemDBMS DataBase Management SystemDID Data Item DescriptionDoD Department of DefenseEIS Engraved In StoneFTP File Transfer ProtocolGIF Graphics Interchange FormatHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolIEEE Institute of Electrical and Electronics EngineersISP Internet Service ProviderJPG Joint Photographic (E)xperts Group formatMIL-STD Military StandardMIME Multipurpose Internet Mail ExtensionsMIS Management Information SystemsOO Object OrientedOS Operating SystemPC Personal ComputerPDF Portable Document FormatRSVP Repondez Sil Vous PlaitSDD Software Design DescriptionSRS Software Requirements SpecificationSSL Secure Socket LayerTBD To Be DeterminedTBR To Be ResolvedUML Unified Modeling LanguageURL Universal Resource Locator

B. GlossaryTailored 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

MIL-STD-498 Software Design Description Outline · Web viewThis document conforms to the...

Documents

Transcript of MIL-STD-498 Software Design Description Outline · Web viewThis document conforms to the...