|
Assignment： Introduction to Software Architecture
Lecturer: Ian Rose
Group Members
Name: Preferred Name: Student Number:
Dossett, James James 2585706
Nick
Chun Ki, Or Jacky 2175829
Due Date: 11 MAY 2007
1 High Level Design 1
1.1 Business Goal - nick 1
1.2 Overview of the subsystems decomposition– nick 1
1.3 Overview of system functions - nick 1
1.4 Omissions - nick 1
1.5 Subsystems 2
1.5.1 GUI - Nick 2
1.5.2 Automatic Criteria Processor – Jacky 3
1.5.2.1 Functions 3
1.5.2.2 Data flows 3
1.5.3 Reject & Reminder - Nick 4
1.6 Inter-Subsystem Interface - James 5
1.6.1 Information repository 5
1.6.2 Event Trace Diagram 5
1.6.2.1 Function 1 5
1.6.2.2 Function 2 5
1.6.2.3 Function 3 5
1.6.2.4 Function 4 5
1.6.2.5 Function 5 5
1.6.2.6 Function 6 6
1.6.2.7 Function 7 6
1.6.2.8 Function 8 6
1.6.2.9 Function 9 6
1.6.2.10 Function 10 6
1.6.3 Validation 6
1.6.4 CRUD analysis 6
1.7 Horizontal Architecture - James 7
1.7.1 Data Storage 7
1.7.1.1 RDBMS? 7
1.7.1.2 ACID transactions? 7
1.7.2 Message Passing 7
1.7.2.1 Message model 7
1.7.3 Hardware 7
1.7.4 Operating System 7
1.7.5 Programming Languages 7
1.7.6 The technologies for presenting information 7
1.8 Verification – Jacky 8
1.8.1 Validation - Information flows 8
1.8.1.1 Event Trace Diagram 8
1.8.2 Function satisfaction 8
1.8.3 Budget of the project 9
1.8.4 Time for the project 9
1.8.5 Risk of the project 9
1.8.6 Flexibility requirements 9
2 Detailed Design for Manual Criteria Processor 10
2.1 Detailed Interface Definitions - James 10
2.2 Detailed Functional Description - James 10
2.3 Detailed requirements - James 10
2.3.1 Manual Criteria Processor 10
2.4 Verification - Jacky 10
2.4.1 Detailed interface verification 10
2.4.2 Function verification 10
2.5 Sample Code - James 10
History Table
Changes By Version
Added person’s name after responsible part Jacky 0.2
Updated content Jacky 0.3
1 High Level Design
1.1 Business Goal - nick
1.2 Overview of the subsystems decomposition– nick#p#分页标题#e#
e.g. the subsystems are independent, internally cohesive and correctly sized
1.3 Overview of system functions – nick
1.3.1 Functional Requirements
1.4 Omissions - nick
1.5 Subsystems
1.5.1 GUI - Nick
1.5.2 Automatic Criteria Processor – Jacky
1.5.2.1 Functions
Check if all Manual Criteria were met
Check if the other authorities completed the prerequisite processing
Check if reached the maximum payout allowed for particular person
Notify a person for validating fraudulent
Send request to authority’s payment processing system if all automatic criteria were met
Call reject & reminder subsystem if not pass
1.5.2.2 Data flows
1.5.3 Reject & Reminder - Nick
1.6 Inter-Subsystem Interface - James
1.6.1 Information repository
Subsystems Information (Authoritative data)
User Interface Postal applications
Help Desk
Manual Criteria Processor Manual criteria
Automatic Criteria Processor Automatic criteria
Reject & Reminder N/A (Information passed from other subsystems)
Database Applications (Complete and incomplete)
Statistics
Application Comments
Username(s)
1.6.2 Event Trace Diagram
For the following diagrams, UI = User Interface subsystem, MCP = Manual Criteria Processor, DB = Database and ACP = Automatic Criteria Processor
1.6.2.1 Function 1
The UI passes application data through the MCP to check whether criteria are met, and is also sent to the database for storage. The application is also sent to the ACP for further checking. Each one of these steps is recorded in the database once the checking is completed.
1.6.2.2 Function 2
The application follows the same steps as in function 1, but is validated by the ACP and MCP, allowing storage of notes where the application failed validation. The ACP also records fraudulent applications.
1.6.2.3 Function 3
Simply checks if all the manual criteria were met for a specific postal application.
1.6.2.4 Function 4
Checks to ensure that all other http://www.ukassignment.org/daixieAssignment/authorities have completed prerequisite processing and requests payment if the application was successful.
1.6.2.5 Function 5
While processing an application, the system checks to ensure that the maximum payout allowed for a particular person has not been reached, and if it has, return the proper notification.
1.6.2.6 Function 6#p#分页标题#e#
Notify a person for validating fraudulent. Simply sends the proper contact information to the Reject & Reminder subsystem if the application was deemed fraudulent. The Reject & Reminder subsystem then sends notification to the applicant, informing them that their application was rejected.
1.6.2.7 Function 7
Once the application has been processed by both the Splosh system and other authorities, payment is requested. Once the transaction is finished, the application is stored and closed until it needs to be accessed again.
1.6.2.8 Function 8
At any stage of the application processing, an application may be deemed invalid due to failure to meet criteria. Information sent to the Reject & Reminder subsystem will enable a notice to be sent out to the applicant, informing them of where the application failed to meet criteria.
1.6.2.9 Function 9
A simple request/response message to check on the status of any requested application, valid or invalid, and send it to the UI.
1.6.2.10 Function 10
A request is made to the database to check a certain statistic, such as how many applications have been processed, etc.
1.6.3 Validation
Coupling between systems?
1.6.4 CRUD analysis
Data Data type Created Updated Read Deleted
Postal application
1.7 Horizontal Architecture - James
1.7.1 Data Storage
Priority Goals MySQL MSSQL Oracle DB2
High Less than $1 million High Low Low Low
High Completed and running within 1 year High High High High
High Run for 2 years High High High High
High Reliability High High High High
Medium Data entry speed must be high High High High High
Low Security Medium High High High
Since Splosh doesn’t require a huge amount of performance (compared to a bank or other large system), MySQL is the best option due to the fact that it is very cheap in comparison to the rest of the examined databases, which automatically makes it a better option in this case, since it is still very powerful and is able to fulfill the requirements.
The downside of MySQL is that it is less secure than the other options, and it is slightly slower in comparison.
1.7.1.1 RDBMS?
We chose a RDBMS as the storage technology for our data. A RDBMS is suitable because it can support any data type and has no size limitations. It also supports searching of the data, which is useful for this scenario for application and account retrieval.
Choosing a RDBMS solves the critical code problem due to its inherent use of the ACID transaction model and its properties, which ensure that no data will be corrupted due to multiple updaters.#p#分页标题#e#
1.7.1.2 ACID transactions?
The strategy we have chosen for implementing transactional behavior is the pessimistic implementation. This is because while one user is accessing data, any subsequent users should be denied access. A RDBMS enforces ACID and ensures that no problems will arise during data updating, since there will be only one user updating the information at one time.
1.7.2 Message Passing
Interface Technology
Due to the fact that Splosh will not be run across multiple machines in the same instance, Java will be used as the interface technology, which means that all of the inter-subsystem interfaces will be Java interface or class definitions.
User Interface Technology
Because Java has been chosen to implement the User Interface subsystems, the interfaces will both be built using Java Swing because this interface package is able to be integrated with the programming language, and the library is readily available to programmers.
1.7.3 Hardware
The hardware used will be relatively standard client/server hardware. Decent speed clients will be required to run the program efficiently, which means low to mid end business machines. Since the finished product requirement specifications are hard to determine until the program is fully developed, specific client and server details will not be listed.
1.7.4 Operating System
Priority Goals Windows Linux Mac
High Less than $1 million High High High
High Completed and running within 1 year High High High
High Run for 2 years High High High
High Reliability High High Medium
High Minimal training required for a novice user to begin using the system High Low Medium
Medium Speed of data entry must be high High High High
Low Security Medium High Medium
Windows will be the Operating System for Splosh to run off. This is because Windows supports Java with the right programs installed, and is also more likely to be used by data entry employees, meaning that training costs are cut down greatly.
Other operating systems aren’t as widely used as Windows, therefore, some training would most likely be required to bring the users up to speed.
The downside to Windows is that it is more expensive for licenses, and that the operating system uses up a large chunk of system resources, potentially being slower than Linux.
1.7.5 Programming Languages
Priority Goals Java C# C++
High Less than $1 million High Medium High
High Completed and running within 1 year High Medium High
High Run for 2 years High High High
High Reliability High High Medium
Medium Speed of data entry must be high High High High#p#分页标题#e#
Low Security of data High High High
Java, scoring high in all categories, is the clear choice for a system of this size and complexity. Also, due to its popularity, there is a large support base for it, meaning technical problems can be solved relatively quickly.
The other examined languages scored medium in one or two requirements, meaning that while they may be suitable, they are slightly less suitable for this situation.
The downside to choosing Java is the program overhead, meaning it may run slower than a C++ program. But due to the speed of data entry, this is only a minor issue.
1.7.6 The technologies for presenting information
XML has been chosen as the interface technology for data flow. XML is readable by humans, has cross-platform support, free to use, and is a good choice for this project. It is a requirement for the system to use Internet technology for data transfer to various subsystems.
XML is suitable for this because when combined with HTTP, it then has the transfer capability needed for this data flow. Having HTTP also allows the request-response, another necessity for this data flow.
1.8 Verification – Jacky
1.8.1 Validation - Information flows
We identify the information flows to assess the impact of the interfaces on the validity of the decomposition
1.8.1.1 Event Trace Diagram
1.8.2 Function satisfaction
Function Satisfaction
FR1 High
FR2
FR3
1.8.3 Budget of the project
Cost less then 1 million
1.8.4 Time for the project
Twelve clerks, two eight hour shifts per day, run for two years
Time to build?
1.8.5 Risk of the project
During peaks of public interest, there may be a delay in processing application. And costing money and let the public down
Coordinating between authorities is complex
1.8.6 Flexibility requirements
2 Detailed Design for Manual Criteria Processor
2.1 Detailed Interface Definitions – James
The following code is used to perform CRUD tasks on the database. The subsystem takes data entered from the User Interface subsystem and passes it through to the database if the application was being altered before being passed to the Automatic Criteria Processor, which has a separate interface.
interface ManualAppProcessing {
// Creates an Application x in the database. Returns a Boolean outcome.
Outcome addApplication(Application x);
// Reads and returns the applications matching the given variable x.
Application[] getApplications(ApplicationData x);
// Updates Application x. Returns a Boolean outcome.
Outcome updateApplication(Application x);#p#分页标题#e#
// Deletes Application x. Returns a Boolean outcome.
Outcome deleteApplication(Application x);
}
2.2 Detailed Functional Description – James
This subsystem is responsible for handling data that is entered by the User Interface subsystem by the user. It allows the user to check (via the User Interface subsystem) to ensure that all fields have valid data in them before passing it on to other subsystems.
It also allows for the user to check off conditions manually according to specific criteria, leave notes if they are not met, and if they are all met, pass it on to the Automatic Criteria Processor.
The subsystem will allow for retrieval of applications http://www.ukassignment.org/daixieAssignment/so that they can be updated as necessary.
If any invalid data is entered or some data is missing, the application is deemed unfinished and is stored in the database, while the applicant is notified by the Reject & Reminder subsystem.
2.3 Detailed requirements - James
2.3.1 Manual Criteria Processor
The requirements for this subsystem are as follows:
- Must be able to perform CRUD actions on database records.
- Must be able to save/load incomplete applications to/from the database.
- Must pass requested information to the User Interface subsystem.
- Must pass completed applications to the Automatic Criteria Processor subsystem.
- Needs to be able to pass comments made by the user to the Reject & Reminder subsystem if necessary.
- When requested, needs to send the needed information to the Reject & Reminder subsystem upon a failed application.
2.4 Verification - Jacky
2.4.1 Detailed interface verification
2.4.2 Function verification
|
