Assignment指导： Software Architecture（软件架构）

Assignment指导：  Software Architecture（软件架构）

澳洲 Software Achitecture Assignment

专业指导澳洲assignment1455780998,qq ukassignment@qq.com
Tutor name:  Ian Rose

Due: Friday 22nd   Sep 2006, 5.00pm

Tutorial Class: Friday, 3 –4 pm

1 Introduction 4
1.1 Objective 4
1.2 Scope 4
2 Overview 4
2.1 Goals 4
2.2 Conditions 5
2.2.1 Direct Trust 5
2.2.2 Referred Trust 5
2.2.3 Default Trust 6
2.3 Resource Estimation 6
2.3.1 Budget 6
2.3.2 Size Estimate 7
2.3.3 Delivery Time 8
2.3.4 Functionality 8
3 SUBSYSTEM DECOMPOSITION 9
3.1 Subsystem1 (UI) 10
3.1.1 Interface and technology 10
3.1.2 Users 10
3.2 Subsystem2 (Login system) 10
3.2.1 Interface 10
3.3 Subsystem3 (user request system) 11
3.3.1 Interface and technology 12
3.4 Subsystem5 (assessment) 12
3.4.1 Interface and technology 12
Trust updating 13
Trust updating interface and technology 13
3.5 Subsystem5 (Charge system) 14
3.6 Subsystem6 (main data store) 14
3.6.1 Interface and technology 14
3.6.2 Users 14
3.7 External Interface 15
4 HORIZONTAL ARCHITECTURE 15
4.1 Data Storage 15
4.2 Hardware and Operating System 16
4.2.1 User Hardware and Software Requirements 16
4.2.2 Skeptical Hardware and Software Requirements 16
4.3 Language 17
4.4 Performance 17
4.5 User Statement 18
5 ARCHITECTURAL Response 18
5.1 Architecting for Skeptical server 18
5.2 Architecting for database performance optimization 20
6 VERIFICATION 20
6.1 Verify functions are met 20
6.2 Verify architecture for low budget 20
6.3 Verify short delivery time 20
6.4 Verify the risks are identified and mitigated 20
6.5 Verify the flexibility requirements are addressed 20
7 DETAILED DESIGN 20
7.1 Interface 20
7.2 Function 21
7.3 Verification 22
8 REFERENCES 23
9 APPENDIX 23

 
1 Introduction
This document represents the high level architectural design for….

#p#分页标题#e#

1.1 Objective

1.2 Scope

2 Overview
2.1  Goals

This section identifies the goals of the project, justifies three different types of trust, and estimates the resources of the project.

 Business Goals
The following table shows the goals of the project. The importance of those goals is ranked into three priorities: low, medium and high. The business goals are relate to software quality standard (ISO/IEC 9126-1, 13-14) and organizational life cycle processes (ISO/IEC 12207 AMD1, 25).

PRIORITY GOAL DESCRIPTION
High Functionality The system is a web based system.
The system can be used after the customer installs the software.
The system can update relationship of two parties when the referred trust is searched.
The database of the system can be updated by staff in Skeptical.
High Reliability The system gives the correct data which the user requests.
High Usability The system can be login fast.
The trust information can be searched by the customer fast and correctly.
High Performance The performance of the data searching is fast.
High Time The software finishes in one year within the testing time.
High Data integrity The data stored in the database is integrated.
High Security The system can not be login by anyone do not have a user ID and password.
Medium Efficiency The login time of the system is short.
The data can be searched by the customer fast.
Medium Maintainability The system uses the common variable name.
The codes of the system have briefly comments.
The Skeptical have a copy of the database.
Medium Portability The size of the software is small, so it can be store in a USB, and customer can take it anywhere. http://www.ukassignment.org/daixieAssignment/aozhoudaixieassignment/
Medium Availability The system is runs 24 hours a day, 365 days a year.
Medium Space The web space of the system is big, so the system can be used by many customers at the same time at a high speed.
Medium Cost The cost of the project is no more than $1M.
Low Equipment The system can be used on different operating systems and databases.

2.2  Conditions
Trust is a kind of relationship between two parties. In Skeptical system, the trust relationship between two parties is recorded as {dimension, intensity}. The dimension is characteristics of each trust; http://www.ukassignment.org/daixieAssignment/aozhoudaixieassignment/ and the intensity is a number from 0(no trust) to 1(fully trust). Each path of trust relationship built on one party’s own experience, that means party A’s trust of party B is different from party B’s trust of party A. Also, party A’s trust of party B is different from party C’s trust of party B. There are three types of trust: direct trust, referred trust and default trust.#p#分页标题#e#

2.2.1 Direct Trust

Direct trust is the trust between two parties who know each other. The direct trust relationship is built by one company’s own experience. So the intensities could be changed after each business, and the intensities will be increased slowly and decreased quickly. The direct trust can be searched directly for one party. As showing below, A’ trust of B is direct trust.

A→B

2.2.2 Referred Trust
Referred trust is the trust relationship among more than two parties. One party uses other party’s trust relationship for their own business. For example, party A have no direct trust of party B, but have direct trust of party C; and party C have direct trust of party B. So the system can search the relationship between party A and party B by using the relationship paths between A and C; C and B. The following paths show the referred trust between party A and party B:

A→C
C→B
  ↓
A→B

2.2.3 Default Trust

The default trust is used when two parties have neither direct trust nor referred trust. When this happened, the system gives a default trust as result. But the intensity of the default trust is very low. And one party can change the default data after its business with the other party. For example, the relationship between party A and party B is showing as blew:

A  B
  ↓
A→B

2.3 Resource Estimation
This section shows the estimation of the resources of this project. It includes the size, the delivery time and the budget of the product. It also describes the functionality of the project.

2.3.1 Budget
The total budget showed by Skeptical is $1M.

The list is the salary for one year of the employees (Classification and salary scales, 2006):
Experienced project manager   $150,000
Experienced designer     $120,000
Experienced programmer    $120,000
Graduate designer      $60,000
Graduate programmer    $60,000

The budget of the project is calculated as following:
1 experienced project manager during the whole process
1 * $150,000 * 1 year = $150,000

1 experienced designer and 2 graduate designer work for the design part for 1month
1 * $120,000 * 1 month + 2 * $60,000 * 1 month = $20,000

2 experienced programmers and 2 graduate programmers work for both system decomposition and subsystem integration for 3 months
2 * $120,000 * 3 months + 2 * $60,000 * 3 months = $90,000

8 experienced programmers build the subsystems for 6 months
8 * $120,000 * 6 months = $480,000

2 experienced programmers and 4 graduate programmers work for the testing part for 2 months
2 * $120,000 * 2 months + 4 * $60,000 * 2 months = $80,000

The expected overheads are $180,000#p#分页标题#e#

So, the total budget is
$150,000 + $20,000 + $90,000 + $480,000 + $80,000 + $180,000 = $1M

2.3.2 Size Estimate
The Programming Productivity is showing below:
Graduate programmer – 2k LOC/year
Experienced programmer – 5k LOC/year

Codes produced in the duration of building subsystem:
8 * 5k LOC/year * 6 months = 20k LOC

Codes produced in the subsystem integration time:
2 * 5k LOC/year * 2 months + 2 * 2k LOC/year * 2 months = 2.3k LOC

Codes produced in the testing time:
2 * 5k LOC/year * 2 months + 4 * 2k LOC/year * 2 months = 3k LOC

The total codes is 20k LOC + 2.3k LOC + 3k LOC = 25.3k LOC, so the size of the software is between 20k LOC and 25.3k LOC.

 
2.3.3 Delivery Time

The soft ware is required for live field trial within one year. The following table shows the duration and delivery times of each milestone.

Milestone Duration Delivery Time
Design 1 month The first month
System decomposition 1 month The second month
Build the subsystems 6 months The eighth month
Subsystem integration 2 months The tenth month
Testing 2 months The end of the year

2.3.4 Functionality

In order to keep the existing customers and get more potential customers, the system should have high functionalities.
The system can update relationship of two parties when the referred trust is searched. The database of the system can be updated by staff in Skeptical in time. The results searched from the system are correct and can help the customers reducing the risks in their businesses. The system can send each party an email for updating trust relationships automatically. The system can change each party’s account after each query. The space of the server system needs to be large in order to increase the speed of each search.

3 SUBSYSTEM DECOMPOSITION
The entire Trust system is divided into 6 subsystems: User Interface, Login System, User Request System, charge system, Assessment and Main Data Store. For each subsystem, the interface and related technical strategies are specified to model a successful subsystem.
 
Class diagram

3.1 Subsystem1 (UI)
The user interface is built as a model to allow user to access the trust system. In the user interface, there are two elements involved to serve the user: user identification and relevant user password. The user identification is set up to provide valid and unique name for the user registration. And the password is built up to ensure the entrance of system is only opened for the registered users. The password is consisting of several codes to ensure the security and reliability.

3.1.1 Interface and technology
Information Source Information Information Transfer Model Technology#p#分页标题#e#
User name Identification
Characters and numbers Request response model LPC
Password A series of numbers, notation and characters Request response model LPC

In the user interface, Linear Predictive Coding (LPC) is planning to be used. It is simple to build and easy to use. In additional, LPC is fast to transfer information. Because the process is located on the same computer, therefore it makes progress on efficiency, and transferring speed gets faster.

When the user interface is being designed, it is necessary to set a length limitation for the user name and valid password to avoid an insecure registration. It also needs to provide adequate registration space for users. When the user name and password are entered, the user interface is connecting with login data store system to operate next function.

3.1.2 Users
The user interface is built for the customers (involves the individual person and organizations) who want to view the page or do the advanced operations.

3.2 Subsystem2 (Login system)
The purpose of the login system is to verify the typed user name and password when the registered user applies for entering the system. The main functions of the login system are checking length of user name and password, applying for a new user registration, modifying user password, verifying and validating user name and password. When the user login in the Skeptical server, it will check user ID and password. If the ID or password is wrong, the user can not login the system.

3.2.1 Interface
In the login system, we are going to use Java RMI as an information transfer technology. It works on a java-to-java operation and support request-response transfer model. It is simple to build, and suits to all operating systems.

Login Authentication Interface and technology
Information Source Information Information Transfer Model Technology
setUserPassword The acceptable password identified Request response model Java RMI
modifyPassword Change password Request response model Java RMI

Java RMI is planning to be identified in the user request system as an information transfer technology. It works on a java-to-java operation and support request-response transfer model. It is simple to build, and suits to all operating systems.

When a new user applies for the registration, the system will give a new user name and a password automatically. The user name can not be changed once created. The user can change the password themselves. When the user sends a query to change the password, the system will check the length of the password. If it is in the correct size, the password will be changed.

Login data store
In the login data store part of the login system, the registered user name, relevant password and user information are stored to ensure that the user has permission to log in the system next time. Login data store is a main function in the login system. The capabilities of the login data store system are storing the user name, storing the password, store other user information, and verifying with a new registered user name.#p#分页标题#e#

Login data store Interface and technology http://www.ukassignment.org/daixieAssignment/aozhoudaixieassignment/

Information Source Information Information Transfer Model Technology
getUserName Registered user name Request response model Java RMI
getPassword Reliable password Request response model Java RMI
getUserInfo User information Request response model Java RMI

In the login data store system, each registered user information will be stored in an independent package. It ensures a successful storing ability for user to enter system any time. When the user information is validly covered over the login data store system, the users are able to provide their requests and enter next subsystem (user request system) to do operations.

3.3 Subsystem3 (user request system)
In the user request system, user can look for the trust relationship and trust requires about other parties, which is registered in the TRUST system. The main functions of user request system is to searching trust relationship, providing justification for trust of any party, submitting direct trust experiences about other parties, enquiring direct trust experiences, applying for changing trust relationship with other parties and asking for charge services.

3.3.1 Interface and technology
Information Source Information Information Transfer Model Functional requirement Technology
enquiryTrust The party user is looking for
Trust relationship Request response model FR1 Java RMI
justifyTrustResult Justification of provided trust relationship Request response model FR3 Java RMI
enquiryTrustUpdate Enquiry of trust relationship update Request response model FR5 Java RMI
writeTrustExp Trust experience for any other party Request response model FR7 Java RMI
editTrustExp Improve the trust experience record last time Request response model FR8 Java RMI
EnqireTrustExp Existing trust experience Request response model FR10 Java RMI
chargeRequest Payment for the services Request response model FR11, FR12 Java RMI

When user is asking for the request for trust relationship of any other party, the user request system connects with assessment system, main data store system and trust update system to work on the relevant operations based on the rule of trust develops. Both trust experience and trust relationship modifications are services for charge. Each time they use these two services, the users need to add money to their account to pay for the services.

3.4 Subsystem5 (assessment)
Assessment system is another subsystem, which is doing some operations on processing requires, which are associated with trust relationships. The functions of the assessment are selecting trust relationships, checking user request, calculating trust relationships, matching user request with relevant data in the database, storing trust experience, providing the justification of trust relationships and supplying enquired trust experience.#p#分页标题#e#

3.4.1 Interface and technology
Information Source Information Information Transfer Model Functional Requirements Technology
calTrustRls Trust relationships associated with parties Request response model FR2 Java RMI
provideDbRls Relationships in the database provided Request response model FR4 Java RMI
provideCharge Payment for the justification service Request response model FR9, FR11 Java RMI
updateTrustRls Changes of trust relationships provided Request response model FR5, FR6 Java RMI
updateCharge Charges for trust update service Request response model FR9, FR11 Java RMI
setTrustRls Submit trust experience Request response model FR7 Java RMI
setTrustCharge Charges for trust experience submission Request response model FR9, FR11 Java RMI
enteredTrustExp Trust experience in the database Request response model FR8 Java RMI
enteredCharge Charges for entered trust experience Request response model FR9, FR11 Java RMI
trustExpEnquiry Get response of trust experience Request response model FR10 Java RMI
enquiryCharge Charges for trust experience enquiry Request response model FR9, FR11 Java RMI

Trust updating
The trust updating is focusing on updating the trust relationships between any two parties. It is one main function in the assessment subsystem. Basically, the function for it is getting changed request, identifying current trust relationships, modifying current relationships, updating the relationships and restoring updated relationships.

Trust updating interface and technology
Information Source Information Information Transfer Model Technology
getTrustRls Request from the user Request response model Java RMI
getOldTrustRls Data stored in the database Request response model Java RMI
setOldTrustRls Trust relationships and rules Request response model Java RMI
getUpdateTrustRls Update trust relationships and rules Request response model Java RMI
addUpdateTrustRls Add new trust relationships and rules to database Request response model Java RMI

Overall the entire system, trust updating is one of the most difficult operating subsystems to be built up. It needs to get trust request of a party from user request system, and then select all the trust relationships about that party in the main data store system, changing all the trust relationships based on the user trust update requests. Finally, the updated trust relationships are sent back and restored in the main data store system.

3.5 Subsystem5 (Charge system)
The charge system is used for parties to pay the money for the charged services. The function of the charge system is to identify the amount of charged payment for the services and add the charges to pay for the services.#p#分页标题#e#

3.5.1 Interface and technology
Information Source Information Information Transfer Model Technology
identityCharge amount of payment for different services Request response model Java RMI
addCharge Payment for the services Request response model Java RMI

In the charge system, there are different charge items provided to pay for the charged services. The amount of charges for different services is dissimilar; it is identified when the user selects different services. Then the system will automatically display the amount of charges which is consistent with the services user applies for.

3.6 Subsystem6 (main data store)
The main data store system is a capable database to store the information associated with central usage of the system. In the main data store system, trust relationships of parties, trust experience, and charged payment are stored in the database to provide assistance when the users enquire the information. The functions of the main data store system are to store user information, delete user registration, add the trust relationships, delete the trust relationships, add trust experience, store the charges for the services payment and delete the charges.

3.6.1 Interface and technology
Information Source Information Information Transfer Model Technology
addUserName User name Request response model Java RMI
addUserPassword Secure password Request response model Java RMI
addTrustRls Trust relationships associated with parties Request response model Java RMI
removeTrustRls Trust relationships prepared to be deleted Request response model Java RMI
addTrustExp Trust experience of user request Request response model Java RMI
storeCharge Payment for the charged services Request response model Java RMI
deleteCharge Charges prepared to be removed Request response model Java RMI

3.6.2 Users
Administrator is allow to enter the database to manage the main data store system such as deleting some user registrations which are out of date, maintaining the system by cleaning rubbish files and documents, and then updating the system.

3.7 External Interface

Email Services
The email service is used for the system to send email to notify the trust updates from users. The main functions of it are to identify the registered trust updates and send email to user.

Interface
Information source Information Information transfer model Technology
trustUpdateRequest User trust update information Request response Model Java RMI
sendEmail Email associated with trust updates Request response Model Java RMI

4 HORIZONTAL ARCHITECTURE

4.1 Data Storage
The system work with 1 billion registered parties and each server can handle 1 million registered parties. In that case, the maximum expected registered party base of the system is expected to be 1000 Skeptical servers. Each Skeptical server requires Maximum 1million parties account storage in order to handle them. Every party needs a detailed account with registered information. The registered information includes the account name and password. The account details require a maximum of 200K for user name and password. The amount of money requires a maximum of 2M for the balance of each account, the previous transfer record. The registered information was recorded into the Skeptical servers, and it amount of money was refreshed when parties add money to their account to pay for services.#p#分页标题#e#

The system also provides the storage for the trust relations. Each party has a trust relation to another one, and the party can register for trust updates for another party. A single trust relation should have a maximum of 3M allocated for the details.

Minimum Storage Requirements on each server:

1 Million Registered parties’ http://www.ukassignment.org/daixieAssignment/aozhoudaixieassignment/ account details at 200k per account ~ 200G
1 Million Registered parties’ balance at 2M per account ~ 20000G
          1 Million Registered parties’ trust relations at 3M per listing ~ 30000G
          Estimated physical size of the web pages and subsystems ~ 1G
         
          Total Required Storage for each server ~ 50201G
          
          Total Required Storage for the whole system ~50201000G

         Storage Technologies:
        
 Priority MYSQL Oracle MSSQL DB2
Performance High High High Medium Medium
Budget High High Low High Low
Functionality High High High High High
Maintainability Medium High High Medium Medium
Usability High Low High High High
Reliability Medium High High High High
Security Medium Medium High Low Medium

        Compare with the above technologies, the Oracle database technology is suitable. The advantage of using Oracle for the database technology is not only for the reliability, but also for building the huge data system. There are 1 million register users in each server. And Oracle can be used in many operation system like Windows NT, and UNIX, it is suit for almost corporation to use.

4.2 Hardware and Operating System

4.2.1 User Hardware and Software Requirements
The Skeptical product will be developing as an Internet based for selling trust assessments.

Operating System
Windows 98 and above version OS or compatible OS platform would be able to run the product.

Browser Support
The IE 5.0 and above version or compatible browser would be designing for support the product.

Hardware Requirements
With at least 56K dial-up modem, any computer system that able to access Internet without any difficulties should be able to run the product without too long response time.

4.2.2 Skeptical Hardware and Software Requirements#p#分页标题#e#
Since Skeptical has no predisposition toward any particular hardware or software for this system. However, the system would design for 1 billion parties share, to handle concurrent usage and produce fast response times to search, ideally the servers’ specification would contain the following qualities:

Operating System
The chosen operating system for the Skeptical server is Windows 2000 Advance Server as it easy to handle for every level of operators and the OS is easy to get, simplifies IT infrastructure and reduce IT operating costs. A Windows 2000 Advance Server system allows for better maintainability of server side applications and is more flexible for expansion with the enterprise growth than other Windows version.

Hardware Specifications
• Processor (CPU) – Five Power5™ processors at 3.2 GHz each server.
• Memory (RAM) – 60Gb with 1Gb L3 Cache
• Storage – Total 3000Gb HDD read/write at 10K rpm
• Internet Connection is preferably a T3 line with 256Mbps of bandwidth.

Software Specification
o Oracle: Oracle 9.0.1.1.2 9
o PHP: php-4.3.4-Win32.
o Java: Java 3.015

4.3 Language
Skeptical will be developed in PHP due to its speed advantage over JAVA in development and execution time.  PHP is easy for web page to pass the user’s request to database.

Goal Priority PHP ASP Java C
Delivery Time High High High Medium  High
Functionality High - - - -
Performance High High Medium Medium High
Reliability High High Medium High Medium
Usability High High Medium Medium Medium
Security High Medium Medium High Low
Maintainability Medium High High High High
Budget Medium High High Medium High
Portability Medium High High High High
Flexibility Medium Medium High High High
Reusability Medium High High High High

PHP
The Skeptical website chooses PHP to develop is due to the language speed advantage over JAVA in development and execution time.  PHP is easy for web page to get through to database, and it is easy to update the webpage, easy to create, and access database and query database.
Java

User/Party and server are chooses Java to develop because java is a full function language, we are using java to achieve the test requirement.

4.4 Performance
The response speed is a key factor for system performance. And the performance is result in the business.

Skeptical system should work with 1 billion registered parties. The Skeptical System is supposed to have 1000 server that use same infrastructure software such as operating system, data base and the like. And each sever should be handle one million registered parties.#p#分页标题#e#

Each Skeptical system must have the capacity to handle:
 One thousand registered parties
 One thousand parties registered for changes
 One enquiry per second

The multi-task and polling situation on held
• A large number of threads usually degrade system performance; in the system, the maximum number of the registered parties for change is one thousand.
• The client would receive information due to slow polling resulted in a significant delay between the response information being ready. The system can handle one enquiry per second.

4.5 User Statement
The system run based on the Internet website. To active the system program, user could open an Internet browser (IE 5.0 or above version).

The first interface will be the login the system, after login, the system would direct to the request system. The request will send to the assessment system for processing user’s request. Then the updated data will flow to the charge system for charge user based on what service they used. And finally the record will update to the data store for backup.

5 ARCHITECTURAL Response

5.1 Architecting for Skeptical server

Bubble Bursts Detection 
        The bubble burst is a big problem in the system. When the server process the trust change request, all of the inquiry related this trust will be blocked, all queries will reflect the new situation within ten minutes, and all parities registered for change will be notified within in one hour. To detect the problem we need a buffer in the server. The server deposits the notification in the buffer and the clients read there from.

Strategies:
        1. Selecting an appropriate buffer size. When the rector overheated, many alarm notifications were sent to the operators, and the buffering was such that they did not discard any. (Ian Rose, 2001) Each server should be allowed to handle 1000 parties registered for changes. If all of the parties registered for changes, the maximum of changes was 1 million. Because that each server handle 1 million parties. It means that the maximum of changes should handle in 1000 times. Each time the server deposits the notification. For each change, the buffer provides 2K for maximum size. The total buffer in each sever could be 2G.
       
        2. Implementing a discarding policy. A policy for when to discard notifications possibly based on age or priority. (Ian Rose, 2001) All of the parties for changes will be notified within one hour. It means that system needs a discarding policy to denote how long the buffer holds the notification. The system will discard notifications in one hour later.

       3. Implementing aggregation. The aggregation replacing many notifications with one summarizing the many. This step will improve the reliability and efficient for the system.#p#分页标题#e#

Trust Path Detection
         The trust path includes the direct trust, referred trust, default trust. Trust Path Detection detects the priority for each path from developing the trust relation.

Priority  Trust Path
High Direct Trust
Medium Referred
Trust
Low Default Trust

In the referred trust path, it is intensified by shorter paths and weakened by longer paths.

Strategies for detecting the trust path:
1. Detect the trust path if it is a direct trust. If the relationship is direct trust, the system will give the response to client and stop querying. If the relationship can not be found in the direct trust way, go to step2.

2. Detect the trust path if it is a referred trust. The referred trust has three ways to need to be detected.
- Detect the referred trust if it has more paths. It will be intensified by having more paths, and weakened by having fewer paths.
- Detect the referred trust if it has longer paths. It will be intensified by shorter paths and weaken by longer paths.
- Detect the referred trust if it is recent direct trust. It will be intensified by recent direct trust and weaken by old direct trust.
                 If the relationship can not be found in the direct trust way, go to step3.

          3. Detect the trust path if it is default trust. This relatively low but not zero.

5.2 Architecting for database performance optimization
The database of the system is huge and complexity. It is necessary to optimize it so that it can improve the performance of the data base. The follow technique can be used in optimizing the database.

Hardware Mapping
It use the memory for caching, such that quires can be answered from memory for caching, such that queries can be answered form memory instead of from disk. (Ian Rose, 2001) This will improve the speed for each server access data. For low budget, 10G memory for caching is suit for our server.

6 VERIFICATION
6.1 Verify functions are met
6.2 Verify architecture for low budget
6.3 Verify short delivery time
6.4 Verify the risks are identified and mitigated
6.5 Verify the flexibility requirements are addressed

7 DETAILED DESIGN
Note:
The sequence diagrams can’t take into account recursive retrieval of site pages.

Please refer to Appendix B for the Sequence Diagrams.

7.1 Interface
There are three interfaces to link between this subsystem and the rest of the system. Since this subsystem will be in a separate process to the subsystems it interacts with, all of them will based on Java RMI technology connections for communication.

User Request Interface
This interface between assessment and the Charge system Interface will be a Java RMI socket technology. In the case process the user’s requests, User Request system will make queries about the query into a text field “request”, in the table “Service Details”. In this step, it will just add the “request” in the text field. It will process the different service and for the entire request for each user. #p#分页标题#e#
Charge system Interface
This interface link between assessment and the Database Interface, the technology socket will be a Java RMI. If any request need to be pay by the user as a result of checking the database, this contact will be made with the Assessment subsystem and to make an email. For the case after get the payment, the subsystem will send request to database to get the result and get back to assessment subsystem.
Database Interface
The interface between Assessment and the Database Interface will be a Java RMI socket. http://www.ukassignment.org/daixieAssignment/aozhoudaixieassignment/In the case of enquire the relationship between two parties; user will make queries about the date recorded in the field called “enquire” from the assessment subsystem. It will list the relation between two parties and transfer back to Charge and Assessment subsystem.

7.2 Function
This section is for describe the detailed architecture of the Assessment subsystem including the subsystem interfaces and the functional description and verification.
The subsystem processes the user’s request, updates the information of user’s trust assessment data; sends the charge bill by through user’s email and record updated data to the database.
There are 6 type user’s requirements (Reference to the assignment scenario) to process the request.
1. Party A can ask the system what trust they should have in B. (Enquiry). In this step, the query will send from the user request subsystem, and get through to the assessment subsystem to database to get the user’s data.
2. Party A can ask why the system provided a particular trust for Party B. In this step, the query will send from the user request subsystem to assessment subsystem to identify the type of the service of the request, based on the referred trust rule, and then submit to the charge subsystem.
3. Party A can register for trust update for party B. In this step, the first process is like user’s requirement 2. But after the charge, and confirmed by the system. The change of data for the trust between A and B will update to the database. And then system will send an email to user.
4. Party A can submit to the system direct trust experience about party B. In this step, the first process is just like user’s requirement 2. After the system confirms get the charge, the subsystem will identify and get the data from database of the credibility of A, and then the service would add amount to A’ account, and send the data to the charge subsystem.
5. Party A can enquire about the direct trust experiences about the system has registered about them. This step is just like the user’s requirement 1.
6. Party A can add money to their account to pay for service. In this step, the query will get through the assessment subsystem, and identify the type service, then send the data to the charge subsystem.#p#分页标题#e#

7.3 Verification

Function Affected Subsystems Responsibility
Enquiry the user’s trust level with another party   User request system
 Assessment
 Main data store The query will send from the user request subsystem, and get through to the assessment subsystem to database to get the user’s data.
Ask why System provide the particular trust for party B  User request system
 Assessment
 Charge system
 Main data store The query will send from the user request subsystem to assessment subsystem to identify the type of the service of the request, based on the referred trust rule, and then submit to the charge subsystem
Registered for trust updates  User request system
 Assessment
 Charge system
 Main data store The first process is to identify the type of the service of the request, based on the referred trust rule, and then submit to the charge subsystem. And after the charge, and confirmed by the system. The change of data for the trust between A and B will update to the database. And then system will send an email to user.
Submit the direct trust experience  User request system
 Assessment
 Charge system
 Main data store The first process is to identify the type of the service of the request, based on the referred trust rule, and then submit to the charge subsystem. After the system confirms get the charge, the subsystem will identify and get the data from database of the credibility of A, and then the service would add amount to A’ account, and send the data to the charge subsystem.
Enquire about the direct trust experience  User request system
 Assessment
 Main data store The query will send from the user request subsystem, and get through to the assessment subsystem to database to get the user’s data.
Add money to pay  User request system
 Assessment
 Charge system The query will get through the assessment subsystem, and identify the type service, then send the data to the charge subsystem.

Notes: all the data flow is start from UI, in this section, there is no specification to define what UI do. The UI function refers to section 6.1, verify functions are met.

8 REFERENCES

9 APPENDIX

Appendix A Functional Requirements
FR1 Party A asks trust relationships in Party B.
FR2 The system calculates the trust relationships between 2 parties.
FR3 They system provides a understandable reason for a particular trust enquiry from A.
FR4 The justification of trust relationship is provided based on the rules for referred trust.
FR5 Party A registers to update trust for party B.
FR6 The system sends email to notify trust relationships change.#p#分页标题#e#
FR7 Party A submits direct trust experiences about party B to system
FR8 Party A edits entered experiences.
FR9 Charge services depend on the credibility of registered parties.
FR10 A party enquires registered direct trust experiences to system.
FR11 Parties pay for services by adding money to their account.

Appendix B Sequence diagram for assessment subsystem

The user login the user request system and make request

The user makes the trust inquiry to assessment system

The user requests the justification of particular trust.

The user register for trust updates.

The user can submit the trust experiences.
The user can edit its previously entered experiences.

The user can enquire about the direct trust the system has registered about them.