Figure 1. Online Stock Brokerage System Architecture
Submitted by: Gouthami Chintalapani
Instructors: Mark Austin and John Baras
ENSE 623: Systems Validation and Verification, Fall 2003.
TABLE OF CONTENTS
The purpose of this project is to apply the systems engineering principles, the knowledge of UML and the systems validation and verification strategies to design Online Stock Brokerage System. The online stock brokerage system facilitates the users i.e., individual investors to trade (buy, sell, etc) the stocks online through the internet. It allows clients to keep track of, and execute their transactions, shows performance charts of different stocks in their portfolios, provides security for their transactions, and alerts them to pre-defined levels of changes in stocks, with out the use of any middlemen. The main emphasis of the project in this course is on the systems validation and verification strategies.
Online stock brokerage system automates the traditional stock trading using computers and the internet, making the transaction faster and cheaper. This system also gives faster access to stock reports, current market trends and real time stock prices.
The online stock trading system utilizes the three-layer architecture, consisting of a front-end system, middleware and back-end system, as explained in the following figure.
Figure 1. Online Stock Brokerage System Architecture
The system design is accomplished using the three-tier architecture explained above and applying the systems engineering principles. Initially use case analysis is done based on the customer/stake holder requirements. From the use case analysis, high-level system requirements are generated and are further synthesized and broke down into low-level requirements. A system structure model consisting of all system components and the interfaces through which components interact with each other is developed. Then the system behavior model is developed. By mapping the chunks of system behavior onto system structure, a simplified model of the logical system is developed. And then the system tradeoff analysis is carried out to come up with various design alternatives from the system specifications, after allocating requirements to the objects and attributes of system structure. System testing, validation and verification procedures are developed to check the two basic concerns: “are we building the right system?” and “ are we building the system right?” followed by conclusions and references.
The online brokerage system is composed of the aforementioned loosely coupled systems, and an interactive model is depicted in the following schematic.
Figure 2. Component interaction model for the Brokerage System
In this section, various scenarios developed from the stake-holders requirements are recognized through use cases which in case are represented by activity diagrams.
The use cases represent system goals or system functions. A uses case is an abstraction of a system response to external inputs, and accomplishes a task that is important from user’s point of view.
Figure 3. Initial use-case diagram of Online Brokerage System.
In this section, textual use cases are described and activity diagrams are presented to make up the expanded use cases.
Flow of Events:
1. Investor selects the “register” option.
2. Investor fills in the new user registration form.
3. After filling the form, investor submits the form.
4. System checks if the information provided by the investor is correct.
5. A new account is created for the investor.
6. System acknowledges the investor with the login/password.
Abnormal flow
1. If the investor did not provide the required information, system responds with an error message to give that information.Post-condition
2. If the information provided by the investor is wrong (like credit card information), then also system gives the error message.
3. If at the end investor selects the “abort “ option to cancel his registration, investor receives an acknowledgement that his registration was not completed.
Figure 4. Activity diagram for New User Registration.
1. System prompts the user to enter login name and password.Abnormal flow.
2. Investor enters his/her login name and password.
3. System administrator checks for a match in the database.
4. If there exists a match, investor is successfully logged in.
5. Investor’s account is displayed.
1. If the investor’s login and password are not correct, system prompts the investor to reenter the data with a proper message.
2. If the investor has forgot his password, “forgot password” option is provided to the investor
Post-condition. Investor’s account is displayed.
Figure 5. Activity diagram for “Login”
1. Investor can select various available options to view the data.Abnormal flow.
2. The corresponding data is displayed on the screen.
1. The requested data may not be displayed because of the system crash or network problem.Post-condition.
Figure 6. Activity diagram for “View Account”.
1. Investor selects “Logout” option.Abnormal flow.
2. System prompts for saving the information if there is any unsaved information.
3. System asks the investor to confirm his logout.
4. The investor is successfully logged out.
5. The investor cannot do anything without logging again.
1. Investor might have logged out accidentally in which case he/she has to login again.Post-condition.
Figure 7. Activity diagram for “Logout”.
1. Investor views his account.Abnormal flow.
2. Investor decides to change the information (like credit card information, address change, etc.) that is not appropriate or correct by selecting the “Change” or “Update” option.
3. The new information is typed.
4. Investor selects the “Save” option to save the new information.
5. System administrator updates the database to store the new information.
6. New updated account information is displayed.
1. System cannot be able to update the investor’s account in the database because of system crash or network problem.Post-condition.
2. System may prompt the investor an error message if any of the data provided by the investor is not correct.
3. Some of the updates like credit card information may take a little longer time to be activated.
Figure 8. Activity diagram for “Changing account information
1. Investor selects the “view portfolio” option.Abnormal flow.
2. The investor’s portfolio is displayed on the screen.
1. The company’s portfolio requested by the investor may not exist in the exchange service.Post-condition.
Figure 9. Activity diagram for “View portfolio”
1. Investor selects the type of transaction i.e., buy or sell.Abnormal flow.
2. System prompts for stock name and the number of stocks he/she wants to trade.
3. System checks for the deposit, stock availability in order to process the transaction.
4. If everything is satisfied, system prompts for the order confirmation.
5. Once the investor confirms the order, system administrator records the order in the investor’s order history.
6. Investor gets the acknowledgement from the system.
1. If the deposit is less than the money needed to buy stocks, system responds with an error message and cancels the order.Post-condition.
2. If the number of stocks to buy is less than the stock availability, system gives an acknowledgement and cancels the order.
3. If the number of stocks to sell is more than the stocks available with the investor, system responds with an error message.
Figure 10. Activity diagram for “Place an order”.
1. Investor chooses to terminate his/her account.Abnormal flow.
2. System checks for deposit, stocks.
3. If any deposit or stocks exists, system prompts for bank account number etc.
4. Investor provides the necessary information.
5. System makes the necessary transfer of money.
6. System acknowledges the investor about the transfer through e-mail etc.
7. Once all the necessary transfers are made, system administrator deletes the investor’s account from the database.
8. System acknowledges the investor about the termination of the account.
1. Transfer of deposit may take longer time.Post-condition.
2. System may not be able to terminate the account because of incomplete transactions.
Figure 11. Activity diagram for “Close the account”
1. System prompts the user to add, or delete a preference or rule.Abnormal flow.
2. Investor selects either option and enters data.
3. System checks the validity of the data entered.
4. System stores the preferences in the investor’s account.
5. Investor gets the acknowledgement from the system.
1. If the information provided by the investor is not correct, system responds with a error message.Post-condition.
Figure 12. Activity diagram for “Set preferences”
1. Investor requests the system for some information.Abnormal flow.
2. System queries the exchange service for the current information.
3. Exchange service provides the requested information.
4. System displays the information to the investor.
1. The information provided by the exchange service may not arrive at the client end, if the network is broken.Post-condition.
Figure 13. Activity diagram for “Retrieve information”
1. System administrator selects the most recent backup data.Abnormal Flow.
2. System administrator is prompted for the confirmation of the system recovery.
3. The database is recovered with the selected backup data.
1. If there was no recent backup data, information is lost.Post-condition.
Figure 14. Activity diagram for “System recovery”
1. Investor’s deposit is less than the subscription fee.Abnormal flow.
2. Investor deposits money.
3. System checks whether the deposited money is more than the subscription fee.
4. Investor’s account is reactivated.
1. The deposited amount is not sufficient and the account is not reactivated.Post-Condition.
1. Investor reports that the account is frozen.Abnormal flow.
2. System administrator queries the database and gets all the details.
3. System administrator creates a new account for the investor with the details.
4. Investor’s account is recovered.
1. System administrator may not be able to recover the investor’s account from the database, in which case all the account information is lost.Post- condition.
Figure 15. Activity diagram for “Account reactivation” and “Manage account”
1. Investor selects to update portfolio.Abnormal Flow.
2. Investor adds or deletes the stocks that he/she is interested in.
3. Investor submits the new portfolio information.
4. System validates the portfolio selection.
5. System acknowledges the investor.
1. The stock selected by the investor may not exist.Post-condition.
Figure 16. Activity diagram for “Update Portfolio”
Figure 17. Use-case relationship diagram.
| Level 1 Requirements |
|
INITIAL
REQUIREMENTS FROM USE CASES
|
The high level requirements are further synthesized and broke down into low-level requirements as follows.
| High-level ( Level 1) Requirements | Low-Level Requirements (Level 2, 3 and 4) |
|
1
|
1.1 All the
information must be presented in English by default.
1.2 The system can also give users the choice to select a language out of the given set of languages. |
| 2 | 2.1 The system
must provide secure access to its services.
2.1.1 The
system services must be accessible only to the registered users through
a mechanism of secure login.
2.1.2 The
system must enforce the new users to register with the system, in order
to access the system.
2.1.2.1 The
information provided by the user is authenticated.
2.1.2.2 User
has to deposit minimal initial amount in his/her account for carrying out
the transactions, if he/she is a first time user.
2.1.3 The
system can only register specific number of people for using its resources.
2.1.4 The
system must validate the login and password provided by the user.
2.2 The system must support secure transfer
of data over the public networks.
2.3 The users account information must be protected from illegitimate access. 2.4 All user account transactions must be committed through secure interfaces only. 2.5 All the account-specific information provided by the customers should be stored in the brokerage system's data bases. |
| 3 | 3.1 The user
interface provided by the system must be efficient, fast and convenient.
3.2 The system user interfaces must be compatible with popular browsers. 3.3 The system should assist the user with help documentation for various features of the user interfaces. |
| 4 | 4.1 User
transactions must be validated against the user's account previleges and
status.
4.2 Users can cancel their order before the order is executed. 4.3 Users can buy the stocks, depending on the stock availability and the amount deposited. 4.4 Users can execute a sell order depending on the stocks in their possession. 4.5 Users can deposit money in their account. 4.6 Users transaction history must be maintained/logged. 4.7 Users transaction status must be updated regularly. 4.8 Users must receive acknowledgements for their transactions and updates on the status of their transactions. 4.9 The system submits the users transactions to the exchange server for execution. |
| 5 | 5.1 Multiple sessions must be made available to enable multiple users to access the system concurrently. |
| 6 | 6.1 The system should allow the users to set their account preferences, alerts for stocks |
| 7 | 7.1 The system
must provide alternate ways to access the system.
7.2 The system shall notify the users in adavance about the downtimes. 7.3 In case of outages, the system must rectify any potential data integrity issues with the system databases and notify the users of any impact on their accounts. |
| 8 | 8.1 The system
databases are accessible by data administrators
8.2 The system database access must be secured through login/password. |
| 9 | 9.1 The system
should provide regular backup of the data
9.2 Various backup methods/options should be used |
| 10 | 10.1 The
user should be able to use the system services with minimal software requirements
10.2 Users can access the system with a computer and a network connection |
| 11 | 11.1 Latest
stock quotes and information should be provided to the user
11.2 System should let the user browse through information 11.3 System should let the users request the information that they need. |
| 12 | 12.1 System should provide textual/graphical feedback to the users |
The above synthesized requirements are arranged in a tree format based on the level of the requirements as follows. Level 1 requirements represent the system level requirements, sub system level requirements are stored at level 2 and component level requirements are stored at level 3 and level 4.
Figure 18. Layered Requirements in a Tree Format/Structure.
The requirements are traced to the use cases and the scenarios from which they are generated as follows.
| Use Cases | Scenario | Level 2 Requirements | Level 3 Requirements | Level 4 Requirements |
|
|
1.1 | 2.5 | 2.1.2 | 2.1.2.1, 2.1.2.2 |
| Use Case
2
Login |
1.1, 2.3, 4.3 | 2.2 | 2.1.1, 2.1.2, 2.1.4 | |
| Use Case
3
View Account |
4.2, 4.3 | 2.1 | 2.1.1; 2.1.4; | |
| Use Case
4
Logout |
1.1, 2.3, 4.3 | 2.1 | 2.1.1; 2.1.4; | |
| Use Case
5
Change the account information |
1.2, 2,.2, 4.2 | 2.3; 2.4; 2.5; | ||
| Use Case
6
View Portfolios |
4.2, 4.3 | 2.2; 2.3; 2.5; | ||
| Use Case
7
Place an order |
1.2, 2.2, 7.1, 7.2 | 2.4; 4.1; 4.2; 4.3; 4.4; 4.5; 4.6; 4.7; 4.8; 12.1; | ||
| Use Case
8
Closing account |
4.2, 4.3 | 2.1, 2.4, 12.1 | ||
| Use Case
9
Set Preferences and/or alerts |
2.3, 4.2, 4.3 | 6.1, 11.3, 2.4 | ||
| Use Case
10
Get the stock information |
2.1, 1.2 | 11.1, 11.2 | ||
| Use Case
11
System Recovery |
6.1, 1.3, 2.2, 5.1 | 9.1; 9.2 | ||
| Use Case
12
Account reactivation |
7.1 | 2.1; 2.2; 2.4; 2.5; | ||
| Use Case
13
Manage account |
7.1 | 2.4; 4.5; 6.1; 11.3; | ||
| Use Case
14
Update Portfolio |
1.1 | 4.5; 4.3; 4.2; 6.1; 11.3; |
The simplified models of system structure and system behavior are created. The requirements are allocated to the system objects and their attributes and functions.
The online brokerage system is structurally modeled with sub-system hierarchies as shown in the following class diagram (see Figure 19).
Figure 19. Class diagram for the structural model of the online stock brokerage system
Figure 20. System behavior for Client Activities
Figure 21. System behavior for "Buy Order"
Figure 22. System behavior for "Sell Order".
Figure 23. System behavior for "Cancel Order".
Figure 24. System behavior for "Depositing Money".
| Requirement # | System/Sub-system/components | Attribute | Method |
| 1.1 | Manage
Portfolio
Database |
Language
Recorded |
SetPreferences()
UpdateAccount() |
| 1.2 | Other Interfaces | preferences | IsSet() |
| 2.1 | System Administrator | Database key | AuthenticateUserInfo() |
| 2.1.1 | Login/Logout
interface
System administrator |
Username,
password
database key |
IsOk()
IsLoggedin() AuthenticateUserInfor() |
| 2.1.2, 2.1.2.1 & 2.1.2.2 | Deposit
amount
Amount System Administrator |
Amount
TypeOfAmount amountToDeposit database key |
depositAmount()
isValidInfo() CreateAccount() |
| 2.2 | Login/Logout Interface | Username, password, ok, cancel | IsLoggedin()
IsOk() IsCancel() |
| 2.3 | System Administrator | database key | AuthenticateUserInfo() |
| 2.4 | Transaction interface | secureInterface | IsSecure() |
| 2.5 | System administrator | database key | AuthenticateUserInfo() |
| 2.6 | Transaction interface | secureInterface | IsSecure() |
| 3.1 | User interface subsystem | interfaceType
Response, timeforresponse |
Interface()
SendFeedback() IsFast() |
| 3.2 | User interface subsystem | browserCompatible | isBrowserCompatible() |
| 3.3 | User interface subsystem | Help | ProvideHelp()
IsHelp() |
| 4.1 | Transaction subsystem | Transaction | IsValidTransaction()
UpdateTransactionhistory() |
| 4.2 | Cancel
order
Transaction Interface |
Transaction
UserId, orderType, stock |
CancelOrder(),
IsCancel(), is Ok()
DisplayOrderStatus(), UpdateOrderStatus(), isSecure() |
| 4.3 | Buy
Stock
Deposit amount System administrator Database |
UserId, Stock, amount, database key, recorded | IsStockAvailable(),
IsAmountAvailable(), BuyStock()
UpdateOrderStatus(), Depositamount(), AuthenticateUserInfo(), RetrieveuserInfo() |
| 4.4 | Sell
stock
Transaction interface |
userid, stock, ordertype | IsStockAvailable() UpdateOrderStatus() SellStock() IsOk(), isCancel(), displayOrderStaus(), isSecure() |
| 4.5 | Deposit
money
amount account interface |
Amount
Amount type amountToDeposit Update |
Depositamount()
IsValidInfo() AmountDeposited() IsAmountAvailable() PlaceOrder() IsOk() IsCancel() UpdateInfo() |
| 4.6 | Transaction interface | Userid, secureinterface | DisplayHistory() |
| 4.7 | Buy
stock
sell stock cancel order execute order order |
Userid, order | UpdateOrderStatus()
UpdateStatus() |
| 4.8 | Transaction interface | Feedback | sendFeedback()
DisplayOrderStatus() |
| 4.9 |
Execute order |
Order, ordered | ExecuteOrder(), RemoveOrderfrmQueue() |
| 5.1 | database | capacity, number of servers | Isserverdown() |
| 6.1 | portfolio
other interfaces |
Stocks, font, language, preferences, appearance | SetPreferences(), viewGraphs(), setAlerts(), IsOk(), isCancel(), isSet(), updateInfo() |
| 7.1 | System | availability,
number of servers |
IsAvailable()
IsServerDown() |
| 7.2 | System | Userid, Feedback | SendFeedBack() |
| 7.3 | System | Userid, feedback, numberof servers, availability | IsServerDown(), SendFeedBack() |
| 8.1 | database | name, passwd | IsSecureAccess(), IsAdmin() |
| 8.2 | System administrator | database key | AccessDatabase() |
| 9.1 | System administrator | database key | RecoverSystem() |
| 9.2 | System | database key, backup | BackupUsing(Option 0) |
| 10.1 | System, Users | Software | IsExtraSoftwareNeeded() |
| 10.2 | System, Users | User terminal, network connectivity, availability | Isavailable(), isConnectedToNetwork() |
| 11.1 | Users, Userinterface subsystem | Information | DisplayInformation() |
| 11.2 | Users, User interface subsystem | Information, userid | SearchInformation(), DisplayInformation() |
| 11.3 | Users, User interface subsystem | Information, userid | IsLoggedin(), searchInformation(), requestInformation(), displayInformation() |
The architecture-level design (logical design) is created by decomposing
the system into a network of logically connected components and by mapping
models of system behavior onto system alternatives.
Figure 25. Schematic of Logical Design for the System
Figure 26. Functional flow block diagram for client account activities.
Figure 27. Functional Flow Block diagram for Client Trading Activities
Figure 28. Functional Flow Block diagram for Client Order Execution through Brokerage System.
A design structure matrix is a compact, matrix representation of a system or project, consisting of a list of all constituent subsystems/activities and the corresponding information exchange and dependency patterns that are required to start a certain activity and the feedback. Of all the available types of design structure matrices, I am considering the Activity Based Design Matrices, which enables us to observe three different types of interactions, dependent tasks, independent tasks and interdependent or coupled tasks.
| Column sends, Row receives | A | B | C | D | E | F | G | H | I | J | K | L | M | N | |
| Use case (1): New user registration | A | A | |||||||||||||
| Use case (2): Login | B | B | |||||||||||||
| Use case (3): View account | C | X | C | X | |||||||||||
| Use case (4): Logout | D | X | D | ||||||||||||
| Use case (5): Change the account information | E | X | X | E | |||||||||||
| Use case (6): View portfolios | F | X | X | F | X | X | |||||||||
| Use case (7): Place an order | G | X | X | X | G | X | |||||||||
| Use case (8): Closing account | H | X | H | ||||||||||||
| Use case (9): Set preferences and/or alerts | I | X | X | I | X | ||||||||||
| Use case (10): Get the stock information | J | X | J | ||||||||||||
| Use case (11): System recovery | K | K | |||||||||||||
| Use case (12): Account reactivation | L | X | X | L | |||||||||||
| Use case (13): Manage account | M | X | |||||||||||||
| Use case (14): Update portfolio | N | X | X |
The above-specified requirements are realized in quantitative and qualitative terms known as specifications as follows.
1.1. A drop down menu consisting of all the above languages must be implemented.
1.2. The selected language must be shown highlighted and the content is displayed in the selected language.
2.1. System should display the login/logout interface screen, whenever the users try to access the system services without logging in.2.1.1. The system must display the user-preferred settings, once the user has logged in.2.1.2. When a new-user initiates the registration process, a query form consisting of the user name, age, date of birth, current address, permanent address, home telephone number, work number, ssn must be presented to the user.
2.1.2.1. The information provided by the user must be checked against the official records.2.1.2.2. User login ids must be unique. No two users can have the same login name.
2.1.2.2.1. The login name entered by the user is verified with the system database.2.1.2.3. The password must be at least 6 characters long.
2.1.2.2.2. If there is no user with that name, then the user can have that login name.2.1.2.2.3. If there already exists a user with that login name, the system should display the message “Login name already exists. Please enter a different name”.
2.1.2.2.3.1. A new window with the previous login name and a list of suggested login names pops up.2.1.2.3.1. The password characters must be displayed as ‘*’, while typing the password.
2.2. Support for cryptographic algorithms like RSA or MD5 should be implemented for the secure transfer of data over the network.2.1.2.4. The user is required to deposit $1000 as initial deposit to open an account.2.1.3. The system current capacity will allow it to render its services to 100,000 people at the least.2.1.2.4.1. This payment has to be made through a check. A confirmatory message is sent to the user after the check is cashed and the account is created for the user.
2.1.4. The login/password provided by the user is verified against the system’s database.2.1.4.1. If the information is correct, system lets the user login and displays his settings screen.
2.1.4.2. If the information is incorrect, system displays the message “ Invalid login/password” and prompts the user to re-enter his correct login and password.2.2.1. Additional protocol layer may be implemented to ensure secure transfer of data over the network.2.3. The system must be Thawte™ or VeriSign™ compliant.2.3.1. A lock symbol will be displayed at the bottom of the browser window to let the user know his transactions are secure.2.4. The information provided by the user is directed to the middleware systems from the web server.2.4.1. The following are the specifications for a few possible system configurations.
| Option 1 | Option 2 |
| BEA Web Logic/Windows NT servers | Apache 1.3.22/SPARC Solaris |
| Oracle 9i | SQL Server |
| 700 MHz Intel Xeon | SPARC Ultra AXI 440 MHz |
| 2 GB 50 ns ECC Viking RAM | 1 GB RAM |
| Telnet/SSH access | Telnet/SSH access |
| RSA-256/RSA-512, 3DES | RSA-256/RSA-512, 3DES |
| FTP, POP, IMAP, SMTP | FTP, POP, IMAP and SMTP servers |
2.4.2. Network connectivity:Multiple full Gigabit Ethernet or DSL2.4.3. The web servers run dual SCSI and Raid I drive configurations for backup. Also there is a 24-hour accessible user volume backup.
Data centers in the USA, Europe and United Kingdom
Cisco routers and switches
Redundant power backup
24/7 data center monitoring
3.1. Latency: Users must get a response for their actions in at most 45 seconds.
3.2. Users must be provided with a message confirming the action, along with the progress information, and possible future actions.
3.3. The system must be compatible with Microsoft Internet Explorer 5.5, and Netscape 6.0.
3.4. There should be a help option in the user interface, to provide users with help documentation.
Once an order is placed, the system will check whether the order is a valid one or not.
Each order is modeled as an object consisting of orderId, userId, status, orderType, orderDate, stockName, amount, and the number of stocks traded.
orderId must be unique, userId is the user’s login name who placed the order.
status could be “Not Executed”, “Executed”, or “In Process”.
orderType could be “buy”, “sell”, “cancel”.
orderDate is the date when the order is placed.
stockName is the name of the stock being traded.
amount refers to the money.
numStocks is the quantity(number) of the stock being traded.
4.1. If orderStatus = “Not Executed”, only then can that order be cancelled by the user.
4.2. If orderType = “buy”
If (numStocks <= amount of stock available in the market)
If (amount <= amount deposited in the user’s account)
User can buy the stocks.
Else
Prompt the user to deposit money in the account
4.3. if orderType = “Sell”,
Check the number of the stocks to sell <= amount of the stock owned by the user in his/her account.
4.4. Users can deposit the amount in their account either by credit card or by mailing a check. If the credit card is used, the credit card transaction authentication is made through secure interfaces.
4.5. All the transactions made by the user are saved into the account history and are displayed when the user selects “display history”.
4.6. The orderStatus attribute must be updated whenever they are changed by the transaction subsystem.
4.7. A confirmatory message must be sent to the users as an acknowledgment for their transactions.
5.1. The user sessions per server are limited to 1000 at a time.
6.1. Alerts can be implemented as sending an email, or flashing a message window with an alert notice, when the user logs in.
6.2. User can select the stocks from the available list of stocks.
7.1. Customer service must be provided when the system goes down.
7.2. When the system goes down, the transactions must be supported/routed through telephone systems.
7.3. The system must send a message to clients through email about the system outage and how long it is going to take.
8.1. Access to the database systems, must be regulated by the system administrator only.
8.2. The system administrator has to login through his login name and password to access the database. The administrator password must be atleast 8 characters long and must be an alphanumeric string. The password must be changed every week.
9.1. The backup should be taken daily at 12am.
9.2. The system databases should be recoverable from crashes and data corruption through redundant servers and backup systems. 3 redundant database systems are to be used. In case of a crash in a database, all the data can be restored from the redundant database systems, without any loss of data.
10.1. Minimum Windows workstation: Intel Pentium 550MHz, 32 MB RAM, 2 GB hard drive, 3.5" diskette drive, 14” monitor, mouse, Windows 95/98, Windows NT 4, 2000, or XP. Recommended: Same with 128 MB RAM.
10.2. Minimum PDA Configuration: Windows CE, 16MB RAM, Wireless Connectivity (CDMA, GSM or WLAN).
10.3. Minimum Macintosh workstation: G3 300 MHz, 64 MB RAM, one GB hard drive, monitor, mouse, Mac OS X. Recommended: Same with 128 MB RAM. (Remote Desktop Web Connection configuration required.)
11.1. Users can query the system for latest quotes on some specific stocks.
11.2. Users can request for latest news, such as stock upgrades/downgrades, mergers/spin-offs from the stock market or the business world with regard to specific stocks they may be interested in.
12.1. The feedback can be provide using textual messages such as “your transaction is complete” or “ An email is sent” or “ Please verify the login and password” etc. The graphical images like “=>”, ??? etc could be provided to guide the user in carrying out his/her transaction.
13.1. All staff members work 8 hrs a day.
13.2. At least 20 technical and 15 non-technical staff is necessary to run the day-to-day operations.
In the online stock brokerage system, there are many factors that affect the performance of the system. All these factors must be carefully studied and a tradeoff must be done between them prior to the actual design and implementation of the system. The following are the main objectives of the system.
System security
X21: Firewall mechanism
X22: Intrusion detection systems
(IDS)
2. Y: Type of processors
Y1: cluster of 16 pentium Xeon
processors
Y2: cluster of 16 Sparc processors
3. D: Type of database
d1: Microsoft SQL database
d2: Oracle 9i database
4. N: People
n1: number of technical people
n2: number of non-technical
people
As per the requirements and the specifications, the multiple objectives can be expressed as follows.
Max security = S1 X11*
S2 X12 * S3 X21*
S4 X22* S5 n1
Max log(security) = x11
logS1 + x12 logS2 + x21 logS3
+ x22 logS4 + n1log S5
After assigning weights,
Max log(security) = 0.6 x11 + 0.78 x12 + 0.85 x21
+ 0.48 x22 + 0.05 n1
Max throughput = T1 x11 * T2 X12 * T3 y1 * T4 y2 * T5 d1* T6 d2
Max log(throughput) = x11 logT1 + x12 logT2 + y1 logT3 + y2 logT4 + d1logT5+ d2logT6
After calculating the coefficients,
Max log(throughput)
= 2.6 x11 + 2.3 x12 + d1 + 1.22 d2
+ 1.8 y1 + 1.6 y2
Minimize cost = 138 x11 + 552 x12 + 27.4 x21 + 19.2 x22 + 240 n1 + 200 n2 + 250 d1 + 400 d2 + 23.3 y1 + 34.3 y2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|