Software Engineering Outline requirements for a Supermarket Checkout System -- The checkout system in a supermarket consists of a store computer to which the cash registers are connected. Each cash register is equipped with its own processor, a keypad with numeric keys and function keys, an electronic barcode scanner, a scale, a customer order receipt printer, a credit/debit card reader, a credit/debit card receipt printer and a display where item and price information is shown. The display is visible to both the customer and the cashier. Each register has a holder for a till containing cash, checks, coupons, etc., which is automatically opened at the end of each customer transaction. As a cashier begins a shift, he or she inserts a till into the cash register, logs onto the register and waits for approval from the system. He or she is then ready to process customer orders. A customer order can only be processed when a till has been locked in the till holder. As a customer checks out an order, the cashier enters the identification number of each item. Scanning the item over the bar-code scanner or manually from the keypad does this also. In the former case, the cashier enters the number followed by the function key ITEM-ID. Based on the number, the cash register obtains product information from the product inventory. The product information contains an item description to be displayed and printed on the receipt, as well as the price. As items are being checked through, prices and item descriptions appear on the display. The system also outputs the item description and price to the customer order receipt printer. If an item is to be credited, the cashier presses CREDIT before scanning the item or manually entering the identification number. After all the items in the order have been processed, the cashier presses the SUBTOTAL function key. The cash register computes and displays the total price including tax. The tax and the total are also printed on the receipt. The SUBTOTAL button may be pressed more than once for each order. Each time, the current subtotal and tax is displayed and printed. The TOTAL button can be pressed only once for each order. Once TOTAL has been pressed, the order cannot be changed. When the total has been computed, the till is automatically opened. After the total has been displayed, the cashier accepts payment. The payment amount is entered followed by a payment type button: CASH, CHECK, and CREDIT/DEBIT. The customer may also pay by credit card or debit card. The credit/debit card reader first scans the card. A message is then sent to the appropriate credit/debit card authorization center. The credit card request is either accepted or rejected. If accepted, an authorization code is returned. The credit card number and authorization code are printed on the receipt. Two copies of a receipt are then printed on the credit/debit card receipt printer: one for the customer; the second is signed by the customer and kept by the supermarket. If a credit / debit card is not accepted and no other payment is offered, the order is canceled. When complete payment has been received, the cash register computes the amount of change displays it and prints it on the receipt. Finally, the receipt is fed out of the printer. At this point the cashier must close the till, which is automatically locked in position until the next customer transaction has been completed. A cashier repeatedly processes customer orders until the end of his or her shift. The cashier then logs off of the cash register. The log off operation unlocks the till, which is removed by the cashier. Each customer order processed is given a transaction id. A transaction log is maintained of all transactions and a daily report is automatically prepared containing the number of items sold for each product and the total revenue for the day. This report is printed on the supermarket printer and also sent to the supermarket headquarters.

1. Produce a detailed use case diagram. Document each use case using the template that I will be sending.

2. Realize the major use cases (refer to the "Use case realization" document that I will be sending) and derive a class diagram for this system.

3. Refine the class diagram where you think it is necessary. Include the major attributes and operations in each class. Distinguish between boundary, control and entity classes. Clearly specify your rationale for the choices of classes what is their responsibility in realizing a use case, and how they cooperate to accomplish a service.

NOTE -- will email use case diagram to you directly...

The term reverse engineering in manufacturing is nothing more than taking apart an object to see how it works and forward engineering is often used in contrast to reverse engineering. The purpose of forward and reverse engineering is usually to see how something works, to duplicate it, to enhance the object or simply to take a part of the object or concept and to then apply what is learned to another thing or process. These unique processes were and still are practiced throughout the corporate and manufacturing environments and from older industries. When Toyota buys a Honda they intend to disassemble it to examine how certain welds, seals, or components work so that they can either improve upon or utilize similar components or processes. From the perspective of software, reverse and forward engineering could be to reverse a computer software program's machine or object code to its original source code format. The reasons do reverse engineering could be to retrieve lost source code, to study how the program performs certain operations, to improve performance, to fix a bug or error in logic, to identify malicious content such as a virus, or to change the program from one programming language into another such as COBOL to C++.
However, in regard to UML, forward engineering is a tool that converts a diagram of a process into code and it should not be limited to pictorial depiction of diagrams. The structure of a system is defined by a diagram that can be translated into actual source code or classes and a forward engineering UML tool should bridge these steps by generating source code of the classes. Developers should be able to take this 'stub' code and fill in with actual code thus speeding up the process of creating source code. Forward engineering support by a UML tool is normally for a specific language or a set of languages. Reverse engineering is exactly the opposite of forward engineering in the sense that the UML tool loads all of the files of the application or system and then identifies the dependencies between classes. In other words, it reconstructs the entire application structure with the relationships between classes.

Some advantages and disadvantages of both reverse and forward engineering are obvious. For example, one obvious disadvantage of reverse and forward is that the interpretation is not accurate. In other words, it could easily constitute an incorrect version of the original diagram or source and thus make additional work for a developer who may assume he is working with a correct interpretation. An obvious advantage in regard to reverse and forward engineering any software, object or product is that whatever the object is, it can be diagnosed to discover better ways of fixing or using the inherent parts or processes.

2.2

This section attempts to illustrate two refactoring examples useful during design. The first is a tool to reduce coupling and the second is to use CASE tools. Because refactoring is a technique for restructuring existing bodies of code by altering internal structure but not external behavior, it is still best to reduce as many internal structural concerns in the design phase. In other words, refactoring may be a series of small transformations that preserve behavior but a series of these small changes amount to a large transformation and a significant restructuring.

The first refactoring example that could be useful during the design stage is the coupling factor with a focus on: aggregation coupling, formal parameter coupling and return-type coupling. Any software with a low coupling ratio is more manageable once in production and also help the code to be more reliable. It is important to use viable strategies to reduce coupling in Object-Oriented Designs because it is a major objective of object-oriented design work to use classes with a high level of cohesion but a low level of coupling.

UML-based class diagrams should be generated early on in the software design process. Programmers today have the luxury to utilize certain tools to help examine class diagrams such as a Coupling Analyzer Tool or CAT where input is a UML class diagram. CAT provides output counts of any aggregation coupling, formal parameter coupling, and return-type coupling evident in the overall design. A software engineer utilizes this output to discover coupling reduction strategies. In other words, CAT output provides information for…