Systems Analysis Modeling: Fatimas Pizzeria - Case Study Example

Systems Analysis Modeling 1. Use Case Diagram The Pizza Shop is a Case Study of Fatima’s Pizzeria. The major stake holders and participants in the Pizza shop case study are the clients, The Waitress and the delivery person. Even though there are two categories of clients, the take-out and the in-house clients, they are consolidated into a single group as clients. Since the bank has an interest in providing credit card services, it becomes another stakeholder, but stays inactive until the credit card payment begins. The neighborhood has some pizza shops giving competition to Fatima’s Pizza shop; hence they fall under the category of stakeholders (Ashrafi & Ashrafi, 2008, p37). The need for a simple accounting system arises due to the predicted future expansion, to compute the income earned from in-house clients. This The summarized details for the use case are as presented below. Teller Actions System Response 1 Teller resets the system and verifies the requests of the client None 2 Confirms whether the client is in-house or take-away clients. No Action 3 Receives money and inputs in the system Generates and prints payment receipt 4 Gives back payment balance and the receipt to the client. Presents the main menu The system accepts input of product codes, accepts payment and does calculation of the balance, then prints cash sale receipt. Here is the use case diagram The table below shows the list of all actors and their roles in the use case diagram. Actors Role Cashier Receives client, receives payment and prints receipts Waiter Serves Clients Cook Prepares food Client Gives payment and receives service Hotel Owner Receives all payments and does reconciliations 2. Activity diagram a.    Draw an activity diagram based on the scenario of withdrawing money from an ATM. b.    Explain the activity diagram, including the start state, end(s), and any decision points. Activity Diagram for ATM Withdrawal Activity diagram shows a sequence of technical steps that are followed in the use of a certain system. It explains the order of all activities from the start to the end and conditions under which they take place. The activity diagram in this study uses a scenario of a Bank ATM Cash Withdrawal. The beginning of this sequence is where the customer inserts the card into the slot in the machine. The Machine reads details and enables the client to input secret pin. This is the first decision point where the machine can either proceed or decline the transaction. If the Pin is correct, the machine presents the menu to the customer, who then selects the withdrawal option. If the pin is incorrect, the machine gives the customer another chance to input the correct pin. He then selects the amount or keys in the amount manually. The Machine confirms the availability of funds. This is the second decision point. If the funds are sufficient, the machine proceeds to return the card, dispense the cash and present a receipt. In the event of insufficient funds, the machine notifies the customer, and provides alternative options. This marks the end of the sequence of activities. In all the activities, there are activities initiated by the user and others mainly machine responses. The idea of activity diagram as applied in a cash dispensing machine scenario actually simulates the real ATM withdrawal transaction process. The chain of activities simulates the real automated machine and its users. Just like an automated Teller Machine, users begin by inserting the ATM card into its slot. In the case of withdrawal, an ATM verifies he validity of the user by confirming if the personal identification number (PIN) is correct or wrong. The ATM communicates with the user as if it was a human employee of the Bank. The user then chooses his or her option of the transaction and inputs the amount to withdraw. The ATM responds by dispensing the cash after which it prints the user cash withdrawal receipt. It then returns the card to the owner and terminates the withdrawal session. In order to do a test on the system, the set of activities generate test cases from the withdrawal menu of the ATM and the ATM transaction report. The ATM withdrawal simulation was based on an advanced relationship diagram by integrating the low-level information from the entire code. The communicative responses such as “Wrong ATM Pins” and a physical link with the bank are left out. The activity diagram has the following sessions; the Card validation session and the balance verification session. The ATM dispenses money only as a response to the validity of all the parameters otherwise the flow of activities assumes a back-ward movement (Gilbert, 2002, p36). The distinct sessions are represented by the problem areas where the details are confirmed. The activities can keep repeating for as long as the details are not valid, before finally the sequence of activities proceeds to the subsequent steps. Each session begins with the insertion of the card and ends whenever the ATM ejects it. The ATM model is a representative to a physical cash dispensing terminal. The menu in this sequence of events represents any form of transaction which then menu presents and out of which the user selects an option (Withdrawal). Class Diagram Class Diagram for Tenderfoot Payroll System Class Diagram for Tenderfoot Payroll System Cass Diagram The Tenderfoot use case diagram generates a class diagram whose stakeholders are the employee, the payroll clerk and the head of department and the payroll system itself. The activities and responses do not follow a straight line but a cluster of randomly scattered activities. At the beginning, the Departmental head initiates the request to the system for Payroll computation. The system then creates the time sheet entry. The system notifies the payroll clerk about the request details. The clerk then initiates the computations of the payroll depending on the timesheet details. Once the system is through with the dynamic execution of the request, it sends notification to the employees, with attachments of printable pay slip. The class diagram shows the payroll system as the central point of contact between the employees, the payroll clerk and the heads of the department. There is a possibility that if the details of the paycheck are inconsistent with the employee's expectation, the process can run all over again. The system also sends result to Tenderfoot’s departmental head for approval. The tenderfoot class diagram shows a pattern of interaction between different entities through a common channel, in a generic model (Wasson, 2006, p15). The same routine takes place weekly, as initiated by the departmental head. The result of the processing reaches all the actors in the network. Sequence Diagram A sequence diagram refers to the graphical or pectoral outlook of a situation. It exhibits interactions between different activities or objects in an orderly sequence. This means there are activities that must precede others in a sequence. Sequence diagram, also referred to as event diagrams sets the function of each event in a sequence and provides vital details to define the responsibility of each as well as an each interface. Sequence diagram applies in the preliminary stages of system analysis and design. Many system designers prefer them because they are less complicated. They have very close relationship to use case diagrams. Here is an example of a sequence diagram for Tenderfoot. The sequence diagram for Tenderfoot shows a pattern of interaction and relationship between processes. It shows how processes interact with each other and their sequential order of occurrence. It produces a chain of events starting from the point where the departmental head issues the initiates the request for the payroll process. The diagram shows a simulation of a real payroll system by providing room for user actions and system responses. The processes are generic in the sense that they can be run iteratively for as many employees as exists in the system. After the initiation by the head of the payroll department, the payroll clerk prompts the system to create a time sheet entry. The system notifies the clerk when it is ready to run the payroll module and present a batch of results for the employees. Once the results are ready, the system sends notification to the employees and the head of department. It also stores the batches for the clerk to refer to whenever there is need. The sequence (or event) diagram has a number of test cases such as the initiation of the process by the head of department, initiation of time sheet, payroll execution; generation of pay slips batches, and print out of pays lip. The finer details such as validation of the staff numbers and examination of employee bio data for all the employees in the Tenderfoot Human resources portal were omitted. This is because they have already been implemented in the relational database architecture. The payroll system hence assumes that the prevailing employee details are true and accurate. It thus uses the exact predefined formula to perform computation, deductions and the reporting of the end results. Every transaction or process as it appears in the sequence diagram can move both forward and backward. It means that when the processes reach the end and generates any result, the feedback takes the opposite direction to the originator of the process (Jiang & Klein, 2002, p20). Every time in the week when the Payroll department needs to do payment to the employees; there are 3 compulsory steps in the beginning. Two of them are human actions while one is a System action. All the three steps serve the purpose of preparing the payroll system to perform its expected task. The problem space goes into the depth of the real purpose that the sequence of activities or processes seeks to fulfill. Like in the case of the Tenderfoot payroll system, the problem or the purpose of the system is the generation of pay slips for employees. The problem system seeks to provide records of employee remuneration and the actual payments awarded to the employees. The system also serves the task of informing employees of any irregularity or inconsistency in the payment or deduction details. The sequence of events in the sequence diagram connects the problem space to the solution space by providing the mechanisms or the activities involved in providing the solution. For the solution to be achieved, it means the end users of the Tenderfoot payroll system must provide positive feedbacks. References Ashrafi, N. & Ashrafi, H. 2008. Object Oriented Systems Analysis and Design. Houston, TX, United States: Prentice Hall Publishing, 36-37. Gilbert, J. 2002. Use Technology to you Advantage, Sales and Marketing Management. US: NYU Anesthesia Associates, 23-26. Jiang, J. and Klein, G. 2002. Project Risk Impact on Software Development, Project Management Journal, 19-26 Wasson, C. 2006. System Analysis, Design, and Development: Concepts, Principles, and Practices. NJ, United States: John Wiley & Sons Inc, 15. Read More