Dominion

RTMD
SDS
(Software Design Specification)
Carlos Antunes
Mike Pedersen
Randy Hamburger
Version 2.0:
CS 4500, University of Utah
Spring 200
!. "ntro#$ction
!.! %$rpose of this #oc$&ent
This document describes the detailed software specifications in addition to system
architecture, system components, and software requirements as agreed upon by the
customer and the project team.
!.2 Scope of the #eve'op&ent pro(ect
A software system will be developed that will query real-time commodity and stock price
information from a server and display the information to the user as close to real-time as
possible given the constraints of: network speed, whether the information has to be polled
from a proprietary system and stored in a database, and the available speed of the wireless
services in the desired cities. e will accomplish these tasks using a cellular phone with
!nternet access.
"pon further investigation by #ominion the wireless supplier will be $ingular instead of
%eri&ion and the mobile device will no longer be the Treo '(( alternatively we will be
using the $ingular )*+, -ocket -$, which also runs on the indows ,.( .obile /0.
!.) Definitions, acrony&s, an# a**reviations
$0 - $omputer 0cience
#1.0 - #atabase .anagement 0ystem
#/2 - #epartment of 2nergy
#T3 - #ata Transmission 3etwork
4"! - 4raphical "ser !nterface
!T - !nformation Technology
35.26 - 3ew 5ork .ercantile 27change
/0 - /perating 0ystem
-#A - -ersonal #ata Assistant
-ocket -$ - -ocket -ersonal $omputer
0#0 - 0oftware #esign 0pecification
089 - 0tructured 8uery 9anguage
0:0 - 0oftware :equirements 0pecification
009 - 0ecure 0ocket 9ayer
:T.# - :eal Time .arketing #ata
".9 - "niversal .odeling 9anguage
" of " - "niversity of "tah
%%- - %erification and %alidation -lanning
%%: - %erification and %alidation :esults
!.4 +eferences
.c$onnell, 0teve. 0oftware -roject 0urvival 4uide. .icrosoft -ress, *;;).
<enderson, Thomas. "niversity of "tah 0oftware 2ngineering 9aboratory. =anuary +((>.
"niversity of "tah. +?'?+((> @http:??www.cs.utah.edu?classes?csA,((?B.
-edersen, .ike. Team $ode .onkey ebsite. +?C?+((>. "niversity of "tah. +?'?+((>
@http:??www.cs.utah.edu?Dmpederse?B.
!.5 ,verview of #oc$&ent
This document contains all of the software design specifics. There is a general description
of how the software is going to work, and what technologies we are using to make it work.
This project will be web based and this outline describes how the application will interact
with the user and the different modes of interaction.
Also available in this document is the specifics to different parts of the project.
The project is going to be designed to work on a -#A and is will be geared towards
someone who has little to no e7perience with this type of application.
/ur application will be user friendly, error tolerant, and ready for enhancements or
additional mobile uses.
2. Syste& architect$re #escription
2.! ,verview of &o#$'es - co&ponents
0erver E #ominion will install a server that monitors all connections to the system in addition to
storing the real-time data. The server will interact with either a #1.0 or a third party product to
retrieve the pricing information that has been requested by the user. This will be a multi threaded
application that allows multiple users to log on with no interference. #ominion will handle all
copyright or data reuse issues associated with the -rofit6 software.
$lient E The client will be a !nternet enabled phone where the software can be successfully
installed. This project will only be designed to work with a $igular )*+, -ocket -$ cellular
phone using the indows .obile ,.( /0. /ther phones or versions of indows .obile may
work but will not be investigated or tested.
2.2 Str$ct$re an# re'ationships
2.) User interface iss$es
Marketer Persona - The .arketer -ersona will be the most frequently used persona. /ur
project will be used to check oil and natural gas inde7es as well as #ominion stock prices
from the 35.26 e7change.
The user will interact with the application by inputting what inde7es they would like to
display. This application will have the ability to be customi&ed for each individual
Persona.
0ince this application will be running on the web and the ideal interface would be with a
!nternet enabled phoneF the cost of airtime will be a factor in the final product. -eople with
this level of access to the system will have a limited number of quotes Gwireless airtimeH
they can see. The system will allow us to monitor which users are logged on and how
much the user is using the system.
VIP Persona - -eople %!- access?persona will be able to do everything that the .arketer
-ersona does but will have an unlimited number of quotes they can view. This will mainly
be given to high-level G#irector and aboveH personnel.
Support Persona - !n order to provide a system that is maintainable we are going to provide
#ominion :esources with a support persona. The 0upport -ersona will be responsible for
documentation and resolution of error and defects. -roblem resolution can be assigned to
others support personnel but the 0upport -ersona will be responsible for follow-up and
final resolution of the defect.
Accountant Persona /ne of the goals of the system is to provide #ominion :esources
with a way of reporting system operating costs. This persona would have access to total
number of quotes viewed by -ersonas and the wireless access time used on $ingularIs
network.
Principles for Implementation
The following principles will be used for implementation of the software
https E At the request of the customer, the team will use https for communication with the
pro7y and the -rofit6 server. $ommunication is done via T$-?!- to ensure that a reliable
connection is made to the server in addition to ensuring that data is not lost during the
information transfer.
$J -ortable #evice Application E A %isual 0tudio -ortable #evice application will be built
to allow login and presentation of data to the user. .odular programming will be used to
build the application which will also allow the development of a separate test system that
does not require use of the portable device for testing.
-ro7y 0erver E A pro7y server will be configured to simulate the network system and
security operated by the customer.
-rofit6 0erver E A database server will be configured with .y089 to simulate the real-
time data obtained from -rofit6 by the customer.
$onsole Test Application E As mentioned previously, the team will develop a separate test
program that will be independent of the -#A application. This will allow testing of the
software in addition to affording the team the possibility of running multiple instances of
the software. The ability to run multiple instances of the software will simulate multiple
-#A users
). Detai'e# #escription of co&ponents
).! Co&ponent te&p'ate #escription
0ecurity Gclient-sideH E the application must be secure from outsiders and the data
being transmitted over the !nternet must be encrypted. 0ecurity must conform to
#ominion !T standards and requirements.
4"! configuration G$lient-0ideH E the application will provide different ways of
customi&ing the layout for any given user. At a minimum, font si&e will be
changeable by the user.
$onnect to server Gclient-sideH E the application must provide a secure connection
between the client and the server. !n addition to the connection, the system must be
able to recover from errors or lost connections.
0ecurity Gserver-sideH E the application must be able to send and receive data over a
secure connection. The team will also e7plore the possibility of displaying data in a
graphics format.
3etwork -rotocol E we will look at implementing the necessary network
connections using a T$-?!- connection.
2rror :ecovery E we will retry to make a connection in case of error by retrying the
request a predetermined number of times.
).2 Sec$rity (c'ient.si#e)
All information sent across the !nternet will be considered confidential so 009 will be used.
009 will allow the data to be encrypted and decrypted and unavailable for view by casual
users.
The team will use 009 security whenever a message is passed to or from the server. All
users will have login requirements Guser name and passwordH to use the application. /nce
the user has logged in, additional information will be available. -ermissions will also be
identified based on the persona of the individual using the application.
).) /U" config$ration (c'ient.si#e)
2ach user of this application will be able to customi&e their own profile to fit their needs.
"sers will be able to select color schemes, fonts, font si&e, quote update frequency, and
inde7es to view. The configuration will then be saved with their profile so at the ne7t
login a user can begin at the configuration point where the system was last used. -rofile
configurations can be updated as many times as the user wishes. hen the project reaches
the detailed design stage, the team will consider allowing the user the capability of creating
and storing multiple configurations.
).4 Connect to server (c'ient.si#e)
/nce the application is started, an initial connection needs to be made to the server. The
connection will be done using a T$-K!- connection to ensure reliable connectivity. /nce
the connection has been made the user will be asked to login. After a successful login the
system will wait for the user to decide what they want to do and respond accordingly.
).5 Sec$rity (server.si#e)
The server will be using 009 to create a secure connection between the client and the server.
4.0 +e$se an# re'ationships to other pro#$cts
Lor teams doing enhancement work, reuse is an important issue. .ost enhancement work
should focus on extending, rather than replacing, the design and product development
from earlier releases.
Lor teams doing new development, reuse can also be an important strategy. !n some
cases, there is freeware that could be incorporated. !n other cases, there are e7isting
modules or classes that could be adapted. Another possibility for enhancements is the use
of special tools that produce open source results and thus permissible for use with the
development of the application.
-otential applications or enhancements will be discussed with #ominion but will not be
part of the project.
%ro#$ct #esign an# re$se
/ur project is going to be Mgrass-rootsN implementation. This is not an enhancement
project. indows .obile ,.( will be the operating system used on the -#A. <ence, there
will be room for reuse assuming that indow .obile ,.( is backwards compatible with its
mobile device predecessors.
The server will assemble or have stored information pertaining to charting of stocks and
commodity pricing.
4.! %ro#$ct i&p'e&entation an# re$se
:euse could be used in this project for some of the common implementations that may
already e7ist in class libraries or on the !nternet. e do not want to re invent the wheel we
would much rather use something that has already been written and is open source.
e will revisit projects done in professor OesslerIs team programming class for possible
implementation in the project.
4.) 0otivation for not re$sing
$urrently, there is no motivation to reuse anything because this is not an enhancement
project. e are starting from scratch. <owever, class libraries, professor OesslerIs input,
and open source code on the !nternet will provide us with a good starting point for this
project.
5.0 Design #ecisions an# tra#e offs
The architecture right now is based on the mobile device interfacing the #ominion real-
time server. 1ased on conversations with the customer, a poll period will be used to pull
data from the server. $ontinuous streaming of data will 3/T be used.
The team has had to switch mobile devices in lieu of %eri&onIs inability to provide data
transmission in the 0alt 9ake area.
.0 %se$#oco#e for co&ponents
namespace $lient
P
public partial class .ain.enu : Lorm
P
public .ain.enuGH
P
!nitiali&e$omponentGHF
Q

private void btnRTestR$lickGobject sender, 2ventArgs eH
P
try
P
"ser inputs query for server
$lient application builds appropriate 6.9 string
$lient application generates https request with 6.9 string
$lient application sends https request to server
-ro7y server recieves client request and forwards to the proper data server
#ata server recieves client request
#ata server parses client request
#ata server queries database for requested data
#ata server generates resulting 6.9 string for client request
#ata server sends 6.9 packet to client
$lient recieves 6.9 packet from data server
$lient parses 6.9 packet
$lient displays data to user
$lient ready for user input
Q
catch G27ception H
P
#isplay error to user
Q
Q
Q
Q
namespace 0erver
P
public partial class 9istener : Lorm
P
public 9istenerGH
P
!nitiali&e$omponentGHF
Q

private void 0erver9isten GH
P
try
P
-ro7y server recieves client request and forwards to the proper data server
#ata server recieves client request
#ata server parses client request
#ata server queries database for requested data
#ata server generates resulting 6.9 string for client request
#ata server sends 6.9 packet to client
Q
catch G27ception H
P
9og error to database
Q
Q
Q
Q
1.0 +e2$ire&ents
1.! Doc$&ent %rocess
Lollow the guidelines and requests put forth via $0A,(( management. Lor the most part
the documentation process will follow the 0-04 where:
0pecific deliverables and milestones are given by $0A,(( management.
The team will deliver the requested information, adding specific details that relate
to the project.
As further information or knowledge is gained, the team will update the
documents that add customer value.
!f specific needs or details are not covered in requested $0A,(( management
deliverables, the team will create the necessary documents.
As team priorities change, the project manager will try to limit the amount of
redundant information and request management justification for the effort.
The customer will be asked to determine value added to the project by specific
documents. At key project milestones the documentation will be reviewed and
the customer will be asked whether they would be willing to pay for the time
spent creating the deliverables.
1.2 Specific response to iss$es
4iven that a working prototype has not been developed this section will discuss the key
features of the project. The functionality currently at risk:
9imited screen real estate for the presentation of data.
Response: Meet with the customer to determine what information is essential and what
information is less important. Focus on the condensing the layout to make navigation
simple and intuitive to the casual user.
0peed of the data presentation and display.
Response: Develop testing that determines the time necessary for data turnaround.
Consider time stamping data reuests and transmissions to profile the system.
0ecurity access
Response: Meet with the customer to determine the security encryption reuired to
complete the information transfer.
2rror :esolution
Response: Consider the use of !CP"#P for information transfer. $owever% depending on
timing% multiple transfer attempts with &DP may 'e considered.
"sage time, limits, and controls.
Response: (et up simple tracking within the PD) or the server to store and record user
statistics.
#ata $overage.
Response: *ased on input from the customer% the team will have the a'ility to switch
development to a Cingular +ireless network versus the proposed ,eri-on system. )s
soon as hardware is availa'le% the team will 'egin preliminary testing in the (alt .ake
area.
1.) Defect trac3ing too's an# info
/nce coding begins, the team will maintain a defect tracking list noting the defect, date
found, and person responsible for repair or correction.
1.4. Define &eas$ra*'e 4-5 re'ease criteria
#oes the system allow an authori&ed user to login.
Are unauthori&ed users prevented from using the system.
Are there any points where the system hangsS
$an the system be used without error going through standard functions.
!s the loss of signal adequately handled by the systemS
Are meaningful error messages displayed in the event of a problem.
Are the customer features complete for the given release.
$an system GserverH support multiple usersS
hat milestones and features does the customer feel are important. hat is the
priority of the customer features.
$an the system perform all the features described in the milestone release.
<ave the top ten project risks been addressedS
hich project risks impact the release.
!s there team consensus that the software is ready for release.
Are there any hardware problems or limitations that will impact the release.
!s error recovery an issue for the release.
Are there situations of environments that negatively impact the hardware and
performance of the software.
raceability Matri!
est Case
"ogin #uote
Selection
#uote
$isplay
%ser
Config&
%ser
racking
'rror
Reco(ery
)et*ork
Cn!
%ser Persona
#ata
%erification
* *
3etwork
0peed
* *
.ethod
Tests and
Assertions
* * * * * * * *
2rror
:ecovery
* * * * * * *
3etwork
$n7
* *
8uote
#isplay
* *
#ata 9oss * * * * * *
#ata !mport * * * * * *
#ata 27port * * * * * *
0aving
0oftware
0tate
* * * *
:estore 0tate * * * *