Software Design Model in the Simulation System - Project | COP 4331, Study Guides, Projects, Research of Computer Science

Download Software Design Model in the Simulation System - Project | COP 4331 and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

Software

Design Model

for the

Grocery Checkout

Simulation System

(GCKSS)

Submitted by

Dr. David A. Workman

Instructor

COP 4331 and EEL

November 20, 2007

Fall 2007

Table of Contents

• 1.0 Introduction
• 1.1 Document Purpose..........................................................................................
• 1.2 Document Scope.............................................................................................
• 1.3 Definitions, Acronyms, and Abbreviations....................................................
• 1.4 References.......................................................................................................
• 1.5 Document Overview.......................................................................................
• 2.0 Overview and Summary of the Simulation System
• 2.1 Project Motivation and Business Analysis.....................................................
• 2.2 The Virtual World Model...............................................................................
• 2.3 Operational View of the Simulator.................................................................
• 2.4 Assumptions and Dependencies.....................................................................
• 3.0 External Interface Specifications
• 3.1 Input Specifications........................................................................................
• 3.2 Output Specifications......................................................................................
• 3.3 Interactive User Interface Specification.........................................................
• 4.0 Internal Software Specification
• 4.1 Architectural Overview................................................................................
• 4.2 Package Specifications.................................................................................
• 4.3 Class Specifications (SimModels only)........................................................
• 5.0 Implementation Summary

1.0 Introduction

1.1 Document Purpose..........................................................................................

This section should delineate the purpose (what kind of information does it contain?) of this document and identify the intended audience (who should be reading this spec?).

1.2 Document Scope.............................................................................................

This subsection should: (a) Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.); (b) Explain what the software product(s) will, and, if necessary, will not do; (c) Describe the application of the software being specified, including relevant benefits, objectives, and goals; (d) Be consistent with similar statements in higher-level specifications (e.g., the system requirements specification – Use Case Model), if they exist.

1.3 Definitions, Acronyms, and Abbreviations....................................................

This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret this document. This information may be provided by reference to one or more appendixes in this document.

1.4 References.......................................................................................................

This subsection should (a) Provide a complete list of all documents referenced elsewhere in the SRS or used as a source of material for this SRS (example class notes); (b) Identify each document by title, report number (if applicable), date, and publishing organization; (c) Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix.

1.5 Document Overview.......................................................................................

This subsection should a) Describe what the rest of this document contains; b) Explain how this document is organized.

2.0 Overview and Summary of the Simulation System

This subsection should put the product into perspective with other related products. If the product is independent and totally self-contained, it should be so stated here. If this document defines a product that is a component of a larger system, as frequently occurs, then this subsection should relate the requirements of that larger system to functionality of the subject software and should identify interfaces between that system and the subject software. A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful. This subsection should also describe how the software operates inside various constraints. For example, these constraints could include (a) System interfaces; (b) User interfaces; (c) Hardware interfaces; (d) Software interfaces; (e) Communications interfaces; (f) Memory; (g) Operations; (h) Site adaptation requirements.

2.1 Project Motivation and Business Analysis.....................................................

This subsection shall include a discussion of the need for the subject system. What problem motivated the development of this system? This subsection shall also discuss the cost/benefit tradeoffs that justify the economics of building the system. This can be taken directly from the Project Requirements Specification and/or your Use Case Model. During the second fiscal quarter 2007, Crazy Foods, Inc., has noticed a significant drop in customer patronage. Anecdotal feedback from frustrated customers suggests that the reason for this decline is extremely slow checkout lines. When management began doing some spot checking, observations tended to confirm customers complaints – it did seem that some of the checkout clerks appeared to deliberate in slowing down the checkout process. The sluggish checkout clerks were interviewed (and in some cases fired) and management discovered that these clerks felt their pay rate did not warrant busting their new nail jobs just to please irritating customers and crabby bosses – they needed some incentive to improve their performance. The Grocery ChecKout System Simulator (GCKSS) described in this document is a software tool Crazy Foods plans to develop and use to help arrive at an appropriate resolution to their checkout clerk’s performance issues. Crazy Foods has decided to pay checkout clerks a base salary (hourly wage rate) plus a bonus based on the number of items checked out per hour. The GCKSS will allow management to estimate the %increase in revenues resulting from a given %increase in checkout clerk performance. Knowing this relationship will permit management to quantify the bonus Crazy Foods can afford to give their clerks and still maintain a profitable business. In searching for an appropriate software vendor to develop this tool, Crazy Foods called the University of Central Florida Computer Science Program. Dr. Workman, who teaches the software engineering courses in CS, said that developing such a system was a “piece of cake” –

2.2 The Virtual World Model...............................................................................

This subsection shall present a description of the virtual world scenario to be simulated. Material included can come from the Use Case Model and/or Project Requirements Specification and/or some other source.  Include a Physical Model and Scenarios  Include Modeling (Fidelity) Requirements Figure 2 illustrates a model of the virtual world encompassed by the GCKS. A typical checkout scenario begins when a shopper begins unloading the shopping cart onto the grocery conveyor. The numbered boxes on the diagram indicate the relative sequence in which actions and events occur. Of course, the activities of the shopper, clerk and bagger become concurrent in a steady- state operation of the checkout system. Figure 2. Virtual Model of the Grocery ChecKout System The simulator shall provide realistic modeling parameters for varying the rate at which the shopper can remove grocery items from the shopping cart, the rate at which the conveyor transports items to the checkout point as well as the capacity of the conveyor surface. The rate at which the clerk can checkout grocery items of different types (e.g. items that need weighing vs. those that are bar coded) shall be one of the most important sets of simulation parameters. Of equal importance will be model parameters that define the performance of the bagger. Clearly the throughput of the checkout station is not strictly a function of the clerk’s performance, but of the clerk and bagger working together as a team. (Note: we may learn that baggers need to be incentivized as well as the clerk.)

The simulation scenario ends when the shopper receives the shopping cart loaded with bagged groceries from the bagger. Simulation output (elaborated in more detail in Section 3.2) shall include, as a minimum, the total time of the scenario measured starting when the shopper begins unloading until the bagger delivers the shopping cart loaded with bagged groceries. The simulation output shall also include the clerk’s rate of checkout (items per minute) for each type of grocery item modeled in the system. In addition, the simulator shall report the rate at which the bagger can bag grocery items (average items per bag)(bags per minute) and the time delay between the time when the last items is deposited in the bagging bin to when the last item is bagged. The simulator shall also separately report the amount of time required to make payment for both cash transactions and credit transactions. Finally, the simulator shall output the total price and profit of the items processed during checkout. The time fidelity (length of a clock tick in simulation time) shall be no longer than 1 second of real time.

2.3 Operational View of the Simulator.................................................................

This subsection should provide a summary of the major functions (use cases) that the software will perform. For example, this spec for an accounting program may address customer account maintenance, customer statement, and invoice preparation without mentioning the vast amount of detail that each of those functions requires. Sometimes the function summary that is necessary for this part can be taken directly from the section of higher-level specifications (e.g. Use Case Model) that allocates particular functions to the software product. Note that for the sake of clarity: (a) The functions should be organized in a way that makes them understandable to the customer or to anyone else reading the document for the first time. (b) Textual or graphical methods can be used to show the different functions and their relationships (e.g. Use Case Diagram). Such a diagram is not intended to show a design of a product, but simply shows the logical relationships among actors and use cases. This subsection shall include a list of all simulation functional requirements. That is, the specific questions the simulation system is designed to answer. This can be taken directly from the Project Specification.  Use Case Diagram and User Scenarios  Actors and their Roles  Simulator Functional Requirements (what questions does the simulator answer)  External Interface Requirements and Views The GCKSS is a discrete-event simulator. This initial version is a prototype restricted to input and output through ASCII file streams. Users interact with GCKSS via a simple command line interface. All external interfaces, input and output file formats are detailed in Section 3.0. Functionality and operational flow the simulator are documented in this section. Figure 3 illustrates a conceptual model or Use Case Diagram of the GCKS Simulator and the actors that it interacts with. Actors are external agents that directly interface with the system. Use cases are bubbles defining system actions or functions, some of which require inputs from, or produce outputs to, one or more actors. Lines or connectors in the diagram indicate a control or data dependency between an actor and a use case, or between two use cases.

Once the initialization has been completed, and without further Analyst input, the GCKSS proceeds to execute the simulation. The simulation process consists of removing the next event from the event queue and dispatching it to the simulation agent that must respond to the event. Each event encapsulates a message, the agent sending the message, the agent that must receive or respond to the message, and the simulation time associated with the message arrival at the receiver. When the message is dispatched, the receiving agent decodes the message to determine what action is necessary and also, in some cases, to extract data required to respond to the message. The result of responding to an event is generally to spawn future interaction events. Future events are inserted into the event queue in their proper time sequence (relative to other events waiting to be dispatched). Because of the granularity of simulation time, a sequence of events may occur at exactly the same simulation time – among these, cause-effect order is always preserved; that is, if the dispatch of event E 1 spawns future event E 2 where both E 1 and E 2 have the same simulation time stamp, then E 2 will always follow E 1 in the event queue. After each event is dispatched it is written to the simulation log. The time, identity of the sending and receiving agents, and the content of the message are output in an easy to read format for post simulation review and analysis. When the event queue becomes empty, the simulation ends. The last use case executed by the GCKSS is the Report Post Simulation Data. This use case computes and outputs the information that fulfills the purpose of the simulation run, specifically, and, more generally, the requirements for building the GCKS Simulator in the first place. Figure 4 summarizes the operational flow of the use cases as we have described in more detail above. Figure 4. Activity Diagram Illustrating Operational Flow of GCKSS Use Cases.

2.4 Assumptions and Dependencies

This subsection shall include all dependencies on and assumptions relating to third-party products, subcontractors, governmental laws and regulations, or finally on emerging industry standards should be discussed in this section. This section is important to help identify sources of project risk.

3.0 External Interface Specifications

3.1 Input Specifications

This subsection shall include a detailed description of all non-interactive input data sources. Specifically it should enable the reader to construct valid instances of all input sources. A complete set of example input sources should be provided to illustrate the specifications given in this subsection. These can be provided as appendices with appropriate descriptive references given in this subsection. (E.g. Input File Specification)

3.2 Output Specifications

This subsection shall include a detailed description of all non-interactive output data sinks. A complete set of example output data records, files, streams, etc., should be provided to illustrate the specifications given in this subsection. These can be provided as appendices with appropriate descriptive references given in this subsection. (E.g. Output File Specification)  Event Log  Post Simulation Report

Figure 6. Specify Output User Screen. Figure 7. Final GCKSS Screen – Successful Completion.

4.0 Internal Software Specification

This subsection includes a specification of the software architecture and design of the GCKS Simulator. This serves as a blue print for implementation.

4.1 Architectural Overview................................................................................

A static view of the GCKSS architecture is shown in Figure 8. This view shows the major reusable packages ( IOMgmt, SimMgmt) that are independent of the virtual world being modeled and how they relate to the one package ( SimModels ) that encapsulates the virtual world specific modular elements. All packages are implemented as C++ namespaces and are represented in the code by a C++ header (.h) file and implementation (.cpp) file bearing the name of the namespace. Further details on the purpose, functional capabilities, and internal organization of each package is documented in Section 4.2. SimControl is implemented as the application main() function in C++. It encapsulates the logic that controls the flow of simulator use cases. Each major use case is defined as a method of the class that denotes the virtual world. This class (the virtual world) is defined in package SimModels. SimControl is completely reusable from one simulation to the next except for one change – the name of the virtual world class must change throughout the body of SimControl. Figure 8. Static Package Architecture of the GCKSS.

Figures 9a and 9b show the sequence of execution flow that creates simInMgr, simOutMgr, theEventMgr, and finally, the execution of methods called by main() to construct and simulate the virtual world (GCKS). Figure 9a. Execution Flow Creating simInMgr and simOutMgr

Figure 9b. The Execution Flow Creating theEventMgr, the Virtual World and Simulating the Virtual World. Figure 9b abstracts away interactions and emphasizes only the interactions between the virtual world and the external file streams. Detailed flow of the virtual world methods will be presented in Section 4.3.

4.2 Package Specifications.................................................................................

In this section we describe the purpose of each package in the architecture and identify the classes that participate in the design. Figure 10 presents a view inside each package exposing the classes contained within and some of the key associations and relationships among classes belonging to different packages. Package IOMgmt. This package provides several classes for managing file streams. The two primary classes used by the simulator are InMgr and OutMgr. In addition, two exception classes are provided. Class IOError is used exclusively by classes in IOMgmt for throwing exceptions when errors occur while attempting to perform stream operations (e.g. open(), append(), etc. ). Class TokenError is provided to application clients of InMgr when trying to parse data from some input stream.

SimMgmt also holds two pre-defined objects for managing the simulation input and output streams. SimInMgr manages the input file stream and simOutMgr manages the simulation log. These objects are instance of classes IOMgmt::InMgr and IOMgmt::OutMgr, respectively. Package SimModels. Figure 11 gives a detailed view of the members of package SimModels. SimModels contains all classes that model the virtual world and its constituents. It is this package that would have to be changed or replaced to simulate a new virtual world or to enhance an existing simulator. Figure 11. Design Template showing the Layered Architecture of the SimModels Classes Interface and Control Layer Class GCKS defines and represents the “Simulated or Virtual World”. An instance of this class is the object to be simulated. Note the composition relationship between World and the agent classes, and between the World and Cart. These are objects that GCKS constructs from the input file stream. Instances of other classes are created dynamically when agents send messages to one another. One of its methods of GCKS, Simulate(), controls the simulation by removing Events from theEventMgr and dispatching the contained Message instance to the designated receiver Agent. The receiving Agent decodes and acts on the message it receives – this may spawn the creation

of new Events that are posted to theEventMgr. This scenario repeats until all Events have been dispatched and the Event queue becomes empty. Agent Layer This layer consists of all active object classes or agents. Active objects must be instances of some subclass of abstract class Agent. The simulation progresses as a result of events created and serviced by agents. All simulation time must be accounted for in the time delays associated with sending messages from one agent to another. In other words, agents control the progress of the simulation and can only communicate with each other by sending messages through events. There is one exception to this statement – a direct call must be made from a sending agent to a public message constructor provided by the receiving agent. These calls are necessary as part of message passing mechanism and have no meaning in the virtual world. An agent must call methods of passive classes directly, such as Cart, but if such calls have meaning in the virtual world, then the associated simulation time must be accounted for in the time delay defined for the next message sent to another agent. An Event has four components: a sender agent, a receiver agent, an instance of some message class , and an event time. When one Agent wishes to interact with another, it must do so by creating an instance of Event that defines a “future” time at which the interaction will occur. The message component defines an action to the receiver agent and possibly carries data necessary to complete the action. The simulation time associated with the new event is computed by the sender and must include virtual world delays associated with any actions the sender may perform to cause the interaction with the receiver – this includes interactions between the sender and any passive objects. Message Classes Messages contain two important data members, a message handler id or code, and, optionally, a passive data object that is needed by the message handler to execute the requested action. Message instances are created by the receiver agent. For each potential incoming message, the receiver agent class assigns an integer code that identifies the private message handler that will be called to service or act on the message when it is received during simulation. Message handlers are called by the receiver’s Dispatch() method – the Dispatch() method uses the handler code to identify an internal private method that will act on the message and its data (if any). Furthermore, as mentioned above, the receiver agent must provide a public message constructor method, for each message it can expect to receive from some other agent. These message constructors may take passive data as parameters and create an appropriate instance of some message class. The purpose of these message constructors is to allow the receiver to encode the handler id as part of the message so that it will know how to dispatch it when the corresponding interaction event occurs (in the future). Passive Layer The passive layer contains all classes that model problem data and inanimate objects of the simulated world. Agents make direct calls on passive objects, but must account for the simulation time consumed when doing so. Passive objects may make direct calls to each other, if necessary. Passive objects may be passed from one agent to another as part of a instance of some message.