Table of Contents Software Architectural Design & Evaluation1 1 Introduction3 2 Design part6 2. 1 Object-Oriented Architectural Style: Alaa Alqallaf (10079858)7 2. 2 WWW Client-Server: Brazilo Gonsalves (10071310)11 2. 3 Main program and subroutine: Nadine Robb (10026063)16 2. 4 Pipe-and-filter: Naveed Sabir (08075782):19 3 Evaluation part20 3. 1 Object-Oriented Architectural Style:21 3. 2 WWW Client-Server:23 3. 3 Main program and subroutine:25 3. Pipe-and-filter: Evaluated by ( Naveed Sabir)27 4 Overall Evaluation28 1 Introduction Design problem definition: – The problem which is needed to be designed in this project is all about design software for a petrol filling station. There will be two software needed to be designed; software system running on the computers of the pumps and the cashier’s consoles to process the transactions. However, we can optionally add third software the server computer. – Functional requirements: • Requirements for pumps: 1.
The pumps should provide a facility to display the type of the fuel, which is used by customer (Diesel/Unleaded). (high quality) 2. The pumps should provide the volume of the specific used fuel. (high quality) 3. The pumps should calculate the amount to be paid. (high quality) 4. The pumps should display the amount to be paid. (high quality) 5. The pumps should send a record to the cashiers’ console, which contains details (pump identity, fuels’ type, fuels’ volume, amount of money to be paid). (high quality) 6.
The pump must be initialised after paying the amount. (low quality) • Requirements for console: 1. The console should contain a display screen, keyboard, credit card reader and receipt printer. (high quality) 2. More than one cashiers’ console may be provided. (medium quality) 3. If there is more than one cashier, then the customer can pay the amount from any cashiers’ consoles. (high quality) 4. The console may provide a facility to select one of the records sent from the pumps to display the details. (medium quality) 5.
The console must save the paid record in the system (the server). (high quality) • Requirement for the server: 1. The server must save the paid records. (high quality) 2. The server should have enough space to store the records – large enough RAM. (high quality) 3. The server should have a backup system. (high quality) 4. Updates can be easily made (medium quality) – Non-Functional requirements: 1. The system should allow for the mutuality and alternatives of the hardware components (including the pumps, server and cashier terminals). . The system should allow adding/removing pumps or cashier consoles to/from the system. 3. The system should be strongly performed without errors, the calculation and processing of payment must be absolutely accurate. 4. The system shouldn’t allow any crash to happen. And if in some point it happens to occur, a large amount of productivity would be lost. 5. The system should have fast and immediate response time, which will make the calculation and processing for the payment much easier. 6.
The system should allow a big reasonable amount of storage to save the paid record in server (which will hold the record). 7. The system should allow paying easily by a cashier, integrating card and cash payments. 8. The system should allow one or more cashiers to be available or working in shifts. 9. The system should be user-friendly (Console) 10. The system must update regularly to give correct information. 11. The system should allow numerous amounts of customers to pay at the same time without any delays. 12. The system must save all records. 3. Each cashier must contain all transactions (records) so the customer doesn’t get confused and have to go to each console to find their transaction. 14. The console mustn’t print a receipt until the customer has fully paid. 15. The consoles should only show the transactions (records that have occurred within the last 5 minutes) so there isn’t a long list for the customers to choose from. 16. In order to access all the customer’s records the system should have a password that only certain members of staff have- should be changed regularly. 7. Records in the system should be backed up regularly in case of a fire/flood/ hardware failure etc. 18. System should abide by the Data Protection Act. – Quality requirements: 1. Sending, accepting and saving records must be immediate (very fast). 2. Each fuel type has its special price, which may be saved on the pumps system. Also it could be uploaded regularly. – Constraints: 1. The amount records must be sent from the pumps to the other systems, when the customer returns the pump nozzle to its socket. 2.
The paid records must be conserved after the payment of the customer. 2 Design part Each member has chosen architecture style; which is different than the others in the group members. This design part contains of four different style separated in four section for each of them. Each member has done the style, implements their rationales, structure, components and connectors for their designs presented in points. The table below show each section with the member who done it and was responsible of all the details on it. Note: Each section done was checked by all other members. | | | |Group member |Student Number |Architecture Style | | | | | |Alaa Alqallaf |10079858 |Object Oriented Design | | | | | |Brazilo Gonsalves |10071310 |WWW Client-Server | | | |Main program and subroutine | |Nadine Robb |10026063 | | | | |Pipe and Filter | |Naveed Sabir |08075782 | | 2. 1 Object-Oriented Architectural Style: Alaa Alqallaf (10079858) The ideas of the design and the rationales in the architectural style: The idea of choosing this design “Object Oriented Architecture Design” is all about separating a responsibilities for system to a useful individual objects. Each object will contain the data and the specific behavior to that object. Objects are discrete, independent, and loosely coupled; they communicate through interfaces, by calling methods or accessing properties in other objects, and by sending and receiving messages (Microsoft, 2009).
This useful information have helped me to decide to use Object Oriented style to solve the petrol station problem and it fits and solve the problem very well. Looking from both management and technical perspective, OO offers numerous inherent benefits like high-quality programming and ease maintenance due to decoupled nature of the structure. Object technologies are easier to adopt and are easily scalable. But the most important benefit is the reuse facility and hence faster development process. Functions of the components: Display_Type_Fuel (pump): – checks the type of the fuel is selected. – The pump will display the type of the fuel that the customer has chosen. – The type of the fuel will be saved to send through the Send_Record. Display_Volume_fuel (pump): increase the volume of the spent fuel, if the nozzle’s pomp isn’t returned to its place. – Display the volume of the fuel with the increasing volume until the nozzle is placed back. – If the nozzle returned, then the volume will stop increasing and saved to be send with other details through the Send_Record. Calculate_Total_Amount (pump): – This component will calculate the amount of money that the customer has to pay. – The total will take the saved Display_Volume_Fuel and the saved Display_Type_Fuel and calculate the amount which is (pump): Calculate_Total_Amount = value of Display_Type_Fuel * Display_Volume_Fuel. – The Calculate_Total_Amount will be increasing until the nozzle is return back.
But it’s already returned. Display_Total_Amount (pump): – will take the Calculate_Total_Amount and display; it that will help the customer to know the total payment before he goes to the cashiers. – will be changing increasingly with the Calculate_Total_Amount until the other one stop increasing. – The Final value of Display_Total_Amount will saved and added to other details and will send through Send_Record. Send_Record (pump): – Save all details from other components: Display_Type_Fuel, Display_Volume_Fuel, Display_Total_Amount and finally the special number of the relevant pump. – Send the details to the cashier’s consoles. Initialise_Pump_Details (Pump): This component will initialise the details of the pump; Display_Type_Fuel to ‘NULL’, Display_Volume_Fuel and Dispaly_Total_Amount, Calculate_Total_Amount to zeros. (Immediately after a customer pick up the pump) Receive_Record (cashiers consoles): – will accept the Send_Record from the pump system. Select_One_record (cashiers consoles): – This component will help the cashiers to choose one pump through a specific number. – This component will help specially if the station has more than one cashier console. Display_Details (cashiers consoles): – Will allow the cashier to see the details of the payment and the total amount which must be paid by the customer. – Takes the details from the Receive_Record using the Select_One_Record. Receive_Payment (cashiers consoles): will allow the cashier to accept the specific amount of the payment or greater value… If the value is greater than the cashier must return the change to the customer. – And will allow the customer to pay in cash or by credit card. – Will print the receipt for the customer. Save_Paid_Record_In_Server (cashiers consoles): – This component will save the cashier Id/name, record for this payment (Receive_Record) and some other details like how its paid (cash / credit card), the time of paying bill, the amount received from customer and the returned change if there any. Save_Paid_Record (Server): – The server will save the sent record from the Cashiers consoles of the paid ones containing all details. Features of connectors: There are just two connectors that I reached in my design: 1. Send_Record (Pump) to Receive_Record (Cashiers consoles): This connector will help the Cashiers console to accept and receive several records from the Pump system after the pump nozzle is returned back. 2. Save_Paid_Record_In_Server (Cashiers consoles) to Save_Paid_Record (Server): Basically the connector will make it easier to save the paid records from a Cashiers console system to in a save place which is the Server. Microsoft. 2009. Architectural Patterns and Styles, Object-Oriented Architectural Style. In: Application Architecture Guide, 2nd Edition. Ch. 3. 2. 2 WWW Client-Server: Brazilo Gonsalves (10071310) [pic]
The ideas of the design and the rationales in the architectural style: The idea of choosing this design “WWW Client-Server Architecture Design” is that the client/server architectural style distributes the systems that involve a separate client and server system to a connecting network. The simplest form of client/server system involves a server application that is accessed directly by multiple clients. The client/server architecture indicated a pump system and the checkout console clients communicated with a server, which stores/contains the information about the fuel details and customer’s payment details. The client/server architectural style has many benefits that will improve the system for petrol system: • Higher security – which will stored all data on the server, which generally offers a greater control of security than client machines. Centralized data access – will help you to access and updates to the data are far easier to administer than in other architectural styles. • Ease of maintenance – Roles and responsibilities of a computing system are distributed among several servers that are known to each other through a network. This ensures that a client remains unaware and unaffected by a server repair, upgrade or relocation. Functions of the components: Type of Fuel (pump system): – Checks the type of the fuel is selected by the customer. – The type of the fuel will be saved to send through the Send the Fuel Record. Volume of Fuel (pump system): – Checks how much the customer took fuel after returning the pump nozzle. When the Nozzle is returned the details will be saved and sent through the Send the Fuel Record. Total Cost of Fuel (pump system): – This component will calculate the total amount of money that the customer has to pay, according to how much fuel the customer used. – The final total details will be saved and sent through the Send the Fuel Record. Send the Fuel Record (pump system): – This will save all details from other components Type of Fuel, Volume of Fuel and Total cost of the Fuel. – This will send the details to the server to process the details. Receive Fuel Record (Server): – Get fuel record from the pump system, the details of the Type of Fuel, Fuel volume and Total cost of Fuel. Process Record (Server): This is where the details of fuel get processed, before it sent to the checkout console client. Process Credit Card Details (Server): – This is where the credit card details get checked if the credit card is in date/have money on it, when the customer tries to pay the amount for the fuel. Process the Payment (Server): – This is where the credit card details get processed, before it gets saved. Save the Payments Details (Server): – This is where all the payment details get saved, once it is processed. File System/Data Storage (Server): – This is where all the payments and customer details are stored, so you don’t lose the payments details. Receive Fuel Record (cashiers consoles client): Get fuel record from the Server, the details of the Type of Fuel, Fuel volume and Total cost of Fuel. – Checkout person has to accept the Process record from the Server. Select one record (cashiers consoles client): – This component will help the cashiers to choose one of the pumps through a specific pump number. Display Amount Due (cashiers consoles client): – This will allow the cashier to see the details of the final total amount, which needs to be paid by the customer. Collect Payment (cashiers consoles client): – This will allow the cashier to accept the exact amount of the payment from the customer. – This will let the customer to pay in cash or credit card. Then it will print the receipt for the customer. Features of connectors: There are just three connectors in my design: 1. Send The Fuel Record (Pump System) to Receive Fuel Record (Server): This connector will process the fuel taken by the customer and save the details into the server, so the checkout console client can get the details. 2. Process Records (Server) to Receive Fuel Record (Cashiers Console Client): This connector will process the data into the server and then send it to the checkout console, when the checkout person wants the details of the pump used by the customer. 3. Collect The Payment (Cashiers Consoles Client) to Process Credit Card Details(Server):
This connector will process the credit card detail into the Server and the server will save the details of the payments. 2. 3 Main program and subroutine: Nadine Robb (10026063) [pic] The ideas of the design and the rationales in the architectural style: The idea of “Main Program and Subroutine” design is that the main tasks of the system are all allocated to different components, which are identified in a specific order from a control component, which may be the master control. Its main task is to call upon the other modules in the correct order. A group of subroutines that share a common data store can be grouped together to form a Module.
A Main Program and Subroutine design has a call and return architecture with a hierarchical structure. This design supports system modifiability, scalability and performance, which are the main reasons I chose this design. It’s easy to modify this design, which is useful when new pumps or consoles are to be added into the system or removed and replaced. Performance is important, given that on a daily basis there is a significant amount of people refueling their car and therefore having a fast system will make things more efficient. Functions of the components: New record: – When the customer picks up the nozzle a new record is created in the system. This new record is a place where all the details of the customer’s choices are found. Display type of fuel taken: – Checks the type of the fuel which has been selected. – The pump will display the type of the fuel that the customer has chosen. – The type of the fuel will be saved onto the record details. Display volume of fuel taken: – The volume of fuel increases as the customer pumps it into their vehicle. – When the customer stops pumping fuel into their car the final volume of fuel used will be displayed. – The volume will be saved onto the record details. Calculate/ Display amount to pay: – This component will calculate and display the total amount the customer will have to pay. In order to calculate the total amount it will take into account the type of fuel used, the price per liter and the amount of fuel used. – The total amount to be paid will be saved onto the record details. Record Saved: – All details from other components such as display type of fuel, display volume of fuel used and display/calculate amount to pay are all saved. – Record is sent to cashiers console. Type of fuel: – Details of fuel types that can be chosen by customers to use. Amount of fuel used: – The amount of fuel used is dictated by how much fuel the customer puts in their car. – This is used to calculate the amount the customer has to pay. – The amount of fuel used is temporary stored in the new record (record details). Price per liter: Details of how much each fuel is per liter. – This is used to calculate how much the customer has to pay. Record details: – Details of the new record that will be saved into the system. – Details include: pump identity, type of fuel taken, volume of fuel taken and amount to pay. Features of the connectors: There are a number of different connectors within the system; each which represents data flow. The connectors from the master control to the major components (New record, Display type of fuel taken, Display volume of fuel taken, Calculate/Display amount to pay and Record saved) process the order in which the components must be carried out.
The reason these connectors have arrows at both sides is because once the major component is carried out the process continues by going back to the master control and then onto the next subroutine. The connectors from the major components to the passive data components are either taking data from the components to use in order to carry out their specific task (In order to display the type of fuel taken, it uses the list of fuel types available) or it stores important data in a temporary record (Record details) that will be saved and sent to the console. These connectors go straight from the major components to the Record Details components as the data produced by these components are needed to be stored for later usage. 2. 4 Pipe-and-filter: Naveed Sabir (08075782): 3 Evaluation part
The Non-Functional requirements, Quality requirements and Constraints in our system, we found many good scenarios… We have choosed the best for our system and more associated ones; they are mentioned below assigned with appropriate weights to represent their importance (total from 100): | | | | |Scenario No |Scenario Description |weight | |Scenario 1 |Add/Remove pump to/from system; |5 | |Scenario 2 |Adding new petrol type; |10 | Scenario 3 |Change the values of the fuel type; |10 | |Scenario 4 |No space to save the paid record; |20 | |Scenario 5 |Add/Remove console to/from system; |5 | |Scenario 6 |Errors have occurred OR system failed; |20 | |Scenario 7 |Delay in responding time in sending record position from pump to console; |10 | |Scenario 8 |Customer pay the fuel using cash/card; |5 | |Scenario 9 |Customer couldn’t pay the fuel/ left without paying; |5 | |Scenario 10 |Cashier not available; |10 | 3. 1 Object-Oriented Architectural Style: |Scenario |Modification | |No. Description |Type |Component |Change | |1 |Add/Remove pump to/from system. |Indirect |Display_Type_Fuel, Display_Volum_Fuel, |Reduce or add new pump. | | | | |Calculate_Total_Amount, | | | | | |Display_Total_Amount, Send_Record, | | | | | |Initialise_Pump_Details. | | |2 |Adding new petrol type. |Indirect |Display_Volume_Fuel, |Add new fuel type. | | | |Calculate_Total_Amount, | | | | | |Display_Total_Amount. | | |3 |Change the values of the fuel type. |Indirect |Calculate_Total_Amount, |Update vat. | | | | |Display_Total_Amount. | | |4 |No space to save the paid record. |Indirect |Save_Paid_Record_In_Server. |Add new hardware/RAM | |5 |Add/Remove console to/from system. |Indirect |Receive_Record, Select_One_Record, |Reduce or add new console. | | | |Display_Detail, receive_Payment, | | | | | |Save_Paid_Record_In_Server. | | |6 |Errors have occurred within the system. |Indirect |All the components will be affected |Fix the errors. | |7 |Delay in responding time in sending |Indirect |Send_Record, receive_Record. |Diagnose the problem. | | |record position from pump to console. | | | | |8 |Customer pays the fuel using cash/card. Direct |NA |NA | |9 |Customer couldn’t pay the fuel/ left |Direct |NA |NA | | |without paying. | | | | |10 |Cashier not available. |Direct |NA |NA | 3. 2 WWW Client-Server: [pic] |Scenario |Modification | |No. Description |Type | Component |Change | |1 |Add/Remove pump to/from system. |Indirect |Type Of Fuel, Fuel |You will have to be update the system in | | | | |Volume, Total Cost |order to run on the new environment | | | | |For Fuel, Send The Fuel Record. | | |2 |Adding new petrol type. |Indirect |Fuel Volume, Total |You will have to be add new fuel type and | | | | |Cost For Fuel. update the system in order to run on the new | | | | | |environment | |3 |Change the values of the fuel |Indirect |Total Cost For Fuel. |Change the fuel cost and update the system in| | |type. | | |order to run on the new environment | |4 |No space to save the paid |Indirect |File System/Data Storage. |Install new hardware in the file system to | | |record. | | |store the records | |5 |Add/Remove console to/from |Indirect |Receive Fuel Record (checkout console |You will have to be update the system in | | |system. |client), Select One |order to run on the new environment | | | | |Record, Display Amount Due, | | | | | |Collect The Payment. | | |6 |Errors have occurred OR system |Indirect |All the components will be affected |Diagnose the problem and fix it or try an | | |failed. | | |update the system if need to. | |7 |Delay in responding time in |Indirect |Send The Fuel Record, Receive Fuel Record |Identify the problem and fix it | | |sending record position from | |(Server), Process | | | |pump to console. |Records, Receive Fuel Record | | | | | |(checkout console client). | | |8 |Customer pays the fuel using |Direct |Collect The Payment, Process Credit Card|N/A – Wait for the Credit card details to | | |cash/card. | |Details, Process The Payment. |process | |9 |Customer couldn’t pay the fuel/|Direct |Collect The Payment. |N/A – Wait for the customer to pay | | |left without paying. | | | | |10 |Cashier not available. Direct |Receive Fuel Record (checkout console |N/A – Wait for the cashier to come back | | | | |client). | | 3. 3 Main program and subroutine: |Scenario |Modification | |No. |Description |Type | Component |Change | |1 |Add/Remove pump to/from system. |Indirect |Master Control |Add or remove a pump | |2 |Adding new petrol type. Indirect |Type of fuel |Add a new petrol type to the | | | | |Display type of fuel taken |existing list | | | | |Calculate/Display amount to | | | | | |pay Price per litre | | |3 |Change the values of the fuel type. |Indirect |Price per litre |Update VAT | |4 |No space to save the paid record. Indirect |Record saved |Install new hardware/ get more | | | | | |RAM | |5 |Add/Remove console to/from system. |Indirect |Master Control |Add or remove console and make | | | | | |sure records appear on new | | | | | |console | |6 |Errors have occurred OR system failed. Indirect |Master Control |Diagnose problem Make | | | | |New record |improvements to make sure errors | | | | |Display type of fuel taken |don’t occur again | | | | |Display volume of fuel taken | | | | | |Calculate/Display amount to | | | | | |pay Record saved | | |7 |Delay in responding time in sending record position |Indirect |Record details |Diagnose problem Make sure | | |from pump to console. |Record saved |records are updated in case | | | | | |system crashes | |8 |Customer pays the fuel using cash/card. |Direct |NA | | |9 |Customer couldn’t pay the fuel/ left without paying. |Direct |NA | | |10 |Cashier not available. |Direct |NA | | 3. 4 Pipe-and-filter: Evaluated by ( Naveed Sabir) |Scenario |Modification | |No. Description |Type | Component |Change | |1 |Add/Remove pump to/from system. |Indirect | | | |2 |Adding new petrol type. |Indirect | | | |3 |Change the values of the fuel type. |Indirect | | | |4 |No space to save the paid record. |Indirect | | | |5 |Add/Remove console to/from system. Indirect | | | |6 |Errors have occurred OR system failed. |Indirect | | | |7 |Delay in responding time in sending record position from |Indirect | | | | |pump to console. | | | | |8 |Customer pays the fuel using cash/card. |Direct | | | |9 |Customer couldn’t pay the fuel/ left without paying. Direct | | | |10 |Cashier not available. |Direct | | | 4 Overall Evaluation The final step of this document is; Each Architecture style of our document was evaluated and assessed against the selected set of scenarios by applying the SAAM method. The metric we used to compare them was the number of interactions with the components. Each scenario was weighted and a final conclusion can be drawn. As a group we decided on four designs to overcome the problem which included Object-Oriented, WWW Client-Server, Main program and subroutine and Pipe-and-filter.
As a group we think that the Main Program and Subroutine design is the best out of the three designs evaluated. As seen from the table below it has the lowest percentage of 22 so therefore fewer components will be affected when any changes or updates are made throughout the system. |Scenarios |Architectures | |No |Weight |Object-Oriented |WWW Client-Server |Main program and | | | | | |subroutine | ———————– | |Coursework: | |Software Architectural Design & Evaluation | | | | | | | | | | | |Group 4 | | | |Alaa Alqallaf (10079858) | |Brazilo Gonsalves (10071310) | |Nadine Robb (10026063) | |Naveed Sabir (08075782) | [16. March. 2012] Authored by: Alaa Alqallaf