Case Study: NextPOS System

Case Study: NextPOS System

       The case study is the NextGen point-of-sale (POS) system. In this apparently straightforward problem domain, we shall see that there are very interesting requirement and design problems to solve. In addition, it is a realistic problem; organizations really do write POS systems using object technologies.

       A POS system is a computerized application used (in part) to record sales and handle payments; it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. It interfaces to various service applications, such as a third-party tax calculator and inventory control. These systems must be relatively fault-tolerant; that is, even if

       remote services are temporarily unavailable (such as the inventory system), they must still be capable of capturing sales and handling at least cash payments (so that the business is not crippled).

       A POS system increasingly must support multiple and varied client-side terminals and interfaces. These include a thin-client Web browser terminal, a regular personal computer with something like a Java Swing graphical user interface, touch screen input, wireless PDAs, and so forth.

       Furthermore, we are creating a commercial POS system that we will sell to different clients with disparate needs in terms of business rule processing. Each client will desire a unique set of logic to execute at certain predictable points in scenarios of using the system, such as when a new sale is initiated or when a new line item is added. Therefore, we will need a mechanism to provide this flexibility and customization.

       Using an iterative development strategy, we are going to proceed through requirements, object-oriented analysis, design, and implementation.

Architectural Layers and Case Study Emphasis

       A typical object-oriented information system is designed in terms of several architectural layers or subsystems (see Figure 3.1). The following is not a complete list, but provides an example:

•        User Interface—graphical interface; windows.

•        Application Logic and Domain Objects—software objects representing domain concepts (for example, a software class named Sale) that fulfill application requirements.

•        Technical Services—general purpose objects and subsystems that provide supporting technical services, such as interfacing with a database or error logging. These services are usually application-independent and reusable across several systems

       OOA/D is generally most relevant for modeling the application logic and technical service layers.

       The NextGen case study primarily emphasizes the problem domain objects, allocating responsibilities to them to fulfill the requirements of the application.

       Object-oriented design is also applied to create a technical service subsystem for interfacing with a database.

       In this design approach, the UI layer has very little responsibility; it is said to be thin. Windows do not contain code that performs application logic or processing. Rather, task requests are forwarded on to other layers.