《自動(dòng)售貨機(jī) 需求報(bào)告》由會(huì)員分享，可在線閱讀，更多相關(guān)《自動(dòng)售貨機(jī) 需求報(bào)告（15頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、 Vending Machine 1 - Objectives The objectives of this exercise are to: · Based on TOOD design approach, propose 2 solutions for the design architecture of the Vending Machine presented in specification module: · First solution: sequential - without process. Using a sequential solution, it

2、is interesting to show than one mode of the State Transition Diagram (STD) cannot be reached: “Dispensing Product”. · Second solution: concurrent - with process(es). Hypothesis must be made on the hardware. 2 - Problem Overview This example is an extension of the problem presented at the Forum

3、”Structured Development” in San Francisco, in February 1986. The problem statement and the resulting models were interactively developed and described as a dialogue between the customer and the analyst. The customer started by outlining to the analyst that he is faced with crooks as customers who

4、try putting junk into the coin slots of his vending machines hoping to get something for nothing. Some even try to enter coin-like slugs to fool the machines. They also try to vandalize the selection register to get products free. These are major problems for the vending machine operators because th

5、ey do business on a narrow margin, which disappears very quickly. The machine is to do the following: - Accept objects from the customer in payment for his/her purchase. - Check each object to make sure that it is not a slug. This is to be done by validating the size, weight and thickness. - Acce

6、pt nickels, dimes and quarters. Any other coins are to be treated as slugs and returned to the customer. - Only initiate payment computation or product selection process after a validated coin is detected. - Accept product selection from the customer. - Check to see whether the selected product i

7、s available, if not available, return coins automatically and notify customer. - Accept a variety of products, which will change from time to time. Hence, the product prices should be changeable. - Return the customer’s payment on request if he or she decides not to make a selection. - Dispense t

8、he product to the customer if it is available and the amount is sufficient. - Return the correct change to the customer if the amount deposit is greater than the product price (initial conditions ?). - Disable the product selection after the product is dispensed and until the next validated coin i

9、s received. Several extra requirements could be added to the first list of user’s requirements, since we identified silences: - Reject coins as slug during the product is dispensed. - Have available coins to be able to give back the change (initial conditions). For that, the coins introduced by t

10、he customer are accumulated in the coins storage (Anyway we don’t know if the inserted coins are used for giving back the change or not). - Tolerance for validating the thickness, size & weight (doesn’t have effect on the architecture nor on the algorithms. - Reject coins as slug if there is not e

11、nough change and of course doesn’t deliver the product (do we have the information from the hardware). - Reject coins as slug if there is no space enough in the receiving box (do we have the information from the hardware). 3 - Proposed context diagram Since no information on the hardware is avai

12、lable, the following context diagram is proposed (as functional diagram; no low level exchanges). 3 different terminators are proposed: - COINS SYSTEM: the system for processing the objects and containing the coins container, - SELECTOR: the interface for the customer’s actions and notifications,

13、 - PRODUCT DISPENSER: the box containing the products. Since there is no indication of the initial number of products from the PRODUCT DISPENSER and the initial number of coins from the COINS SYSTEM, assumptions must be made regarding the limit and initial conditions. These values are defined by

14、compilation (#define of C). - Each valid object is sent directly to the change coins storage (if space available) and will be used as change coin. - One change storage is available for each type of coin and full as soon as the vending machine is turned on. The maximum value is MaxNbOfCoin, same fo

15、r every storage. - The number of type of product is defined by MaxTypeOfProducts and the maximum number of product for one type is defined by MaxNbOfProducts. - As soon as the Vending Machine is turned on, the product storage is considered full for all products (type and number for 1 type). - The

16、 data flow called slug is in fact a control flow because an even to the terminator COINS SYSTEM. Recall of the State Transition Diagram 4 - Identification of objects and classes 4.1 Classes From the text before and the global SART model presented in specification, the following objects, cla

17、sses and functions can be proposed. Entity Name Attributes Type Object Thickness (integer) Size (integer) Weight (integer) T_Object Coin Object Value Type T_Coin Payment Payment Integer Product Identifier Price (integer) T_Product Mode Mode T_Mode 4.2 Instantiation The ins

18、tantiation of a class becomes an object. In the case of the vending machine there are: Coins storage = multiple instantiation of the class Coin, Products storage = multiple instantiation of the class Product, CurrentPayment = single instantiation of the class Payment, CurrentMode = single instan

19、tiation of the class Mode. 4.3 External interfaces 1 terminator is translated in 1 TOOD entity such as machine, sub-application or process. In the case of the SART diagram above, 3 machines are identified. 5 - Functionality Entities Function (methods) Parameters Coins - Validate - Inpu

20、t = object - output = Value, status (coin or slug) - Accumulate - Input : Coin - Output : status (full) - ReturnCoins - input : Change - Output : Status (enough, not enough) Payment - Accumulate - Input : CoinValue - Output : none - Get - Input : none - Output : Payment - Cl

21、ear - Input : none - Output : none - Validate - Input : ProductPrice - Output : Status (enough) Products - Dispense - Input : Valid Selection - Output : Status (OK/NOK) - GetPrice (Validation) - Input: Selection - Output: Price, Status (OK/NOK) Mode (Contained in the main controlle

22、r) ADT_Object - Initialize (Question for the students – why ?) - Input : Thickness, Size, Weight - Output : Object - IsEqual - Input : Object 1, Object 2 - Ouput : Status (Equal/Not Equal) ADT_Coin - GetValue - Input : Coin - Output : Value - Validate - Input: Object, - Outpu

23、t: 6 - First Proposed solution : sequential case Note: The proposed solution here after is not the only one possible. Several solutions exist, and the designer has to choose the best one regarding the encapsulation, abstraction, … Especially, the process of thinking makes us begin with the resear

24、ch of the most elementary objects before grouping them. The process is bottom-up. 6.1 Architecture Figure 1: Application Architecture 2 sub-applications appear: Coins & Products. The sub-application “Coins” is very big compared to “Products” and to the machines SELECTOR & Payment. But the gro

25、uping of related entities such as object, coins, terminator coins system obliges the designer to choose this solution. Of course the balance of the design must also be studied and other solutions can be proposed. Justifications must then be given (work sharing for example). The sub-application “Pro

26、ducts” contains only 2 entities that are a machine for the storage and an ADT for the type product. With TOOD, we could have only one machine for “Products” defining both the storage and the type (see the GDL TOOD). But, if we take the case of the C++ language, it requires absolutely first the defin

27、ition of the class and second the instantiation(s) of this class. And anyway the translation from SART to TOOD proposes to translate data flows into Abstract Data Types. Note: For the entity “Products”, the function “Validate” returns the price of the selected product. A function could exist (“GetP

28、rice”) to get this value. It can be easier to understand. Note: Another solution is to group all the external interfaces within 1 entity to make easier the maintenance and better the portability. 6.2 Machine MODE – Interfaces & Environment It is not necessary to draw again the diagram because it

29、would be very close to Figure1. 6.3 Sub-application “Coins” 6.3.1 Interfaces & Environment 6.3.2 Body of the sub-application The body of this sub-application is related to detailed design, every entity composing the sub-application being a basic one. ADT_Object is used by ADT_Coin (via “IsE

30、qual”) and COINS SYSTEM (via “Initialise”). The question “Why do we need this function?” can be asked to the students. 6.4 Sub-Application “Products” 6.5 Machines “Payment” & “SELECTOR” We don’t know the interfaces of the SELECTOR. The questions that can be asked are: · Is it possible to

31、read without wait the selection? · What is the hardware for the user’s lamp (not available), time out , on/off? 6.6 Main Algorithm /* Proposal of Algorithm for the main() */ Mode = Wait_For_Coin Payment.Clear() while (true) do wait 1 second Not really necessary in that case because t

32、he CPU is dedicated to the vending machine if (GetValue(Out Value) == OK) | Payment.Accumulate (In Value) | Mode = Wait_For_Selection endif if (SELECTOR.AcceptSelection(Out Selection) == true) | if (Mode != Wait_For_Selection) do nothing | else | | if (Products.GetPrice (In Selectio

33、n, Out Price) == AVAILABLE) | | if (Payment.Validate (In Price, Out Change) == OK) | | if (Coins.ReturnCoins (In Change) == OK) | | Mode = Dispensing_Product | | Product.Dispense (In ValidSelection) /* Returned status not used */ | | else | | Payment.Get (Out CurrentPayment

34、) | | Coins.ReturnCoins (In CurrentPayment) | | endif | | Payment.Clear() | | Mode = Wait_For_Coin | | endif | | else | | SELECTOR.NotAvailable() /* Assumption: TimeOut in the H/W */ | | Payment.Get (Out CurrentPayment) | | Coins.ReturnCoins (In CurrentPayment)

35、| | Payment.Clear() | | Mode = Wait_For_Coin | | endif | endif endif if (SELECTOR.ReturnRequest () == true) | Payment.Get (Out CurrentPayment) | Coins.ReturnCoins (In CurrentPayment) | Payment.Clear() | Mode = Wait_For_Coin endif enddo We can easily notice in the algo

36、rithm above that the mode Dispensing_Product has no utility because we never get out of the loop with this mode. And yet, it takes probably several seconds between the selection and the receiving of the product. Question 1: How long does take the function Product.Dispense which call the hardware ?

37、Is it only an impulse to the hardware and return (event Deliver) or 2 functions open & close of a gate ? Question 2: What happens if the customer insert coins during the product is dispensed ? Any way, in term of terminators we don’t have any returned information from the dispenser. Of course, al

38、l the readings of hardware interfaces must be not blocking. 7 - Second proposed solution – Interrupts & processes In the case of the concurrent solution, once again we must do assumptions on the hardware that are: every request of the client can be read by interrupt. These actions are coin insert

39、ion, return request, product selection. The problem is then that the interfaces should be different, and the context diagram should be different. Every action of the client is supposed to generate an hardware interrupt (assumption on the hardware). To each hardware interrupt is associated one pr

40、ocess, activated by the interrupt. What is different in the architecture: · First point: Mode becomes a process, the main controller. Receives messages into its FIFO that contain the type of the user’s action and the corresponding parameters. A message is usually made of an Identifier and a Body.

41、It is a ADT (T_MESSAGE), not represented here. · Second point: New process “Actions” activated by an interrupt both for return request and product selection. Why not because the same terminator. · Third point: New process “Object” for receiving the events produced by object insertion. That process

42、 changes the level of decomposition, for a reason of simplification of the design. Consequence, ADT_Object needed by the process “Object” changes the level too. Note: Case of using the C language, a new object appears, the FIFO, class T_FIFO. This FIFO is here unique (only for MODE) but could be a

43、machine with methods such as read, write, reset, create, delete … or send_message, receive_message, … (see RealTime Operating Systems). Usually specific from the OS. 7.1 Sub-application “Coins” This solution for the sub-application “Coins” is consistent with the global architecture proposed befo

44、re. It is of course possible to make a better grouping and eventually keep the process “Object” in the sub-application. There is no change in the case of the others entities. 7.2 Main Algorithm /* How is the main algorithm changed */ Mode = Wait_For_Coin Payment.Clear() WHILE (true) DO

45、 -- Infinite loop Read the message from the FIFO /* Blocked Reading of the FIFO */ If Type of message is “OBJECT” do If Object is valid then -- If not valid, return slug is called in the SubApp Coins Accumulate Payment Set Mode to Wait_For_Selection Endif Else if T

46、ype of message is Selection | if (Mode != Wait_For_Selection) do nothing | else | | if (Products.GetPrice (In Selection, Out Price) == AVAILABLE) | | if (Payment.Validate (In Price, Out Change) == OK) | | if (Coins.ReturnCoins (In Change) == OK) | | Mode = Dispensing_Product |

47、| Product.Dispense (In ValidSelection) /* Returned status not used */ | | else | | Payment.Get (Out CurrentPayment) | | Coins.ReturnCoins (In CurrentPayment) | | endif | | Payment.Clear() | | Mode = Wait_For_Coin | | endif | | else | | SELECTOR.NotAvailable()

48、 /* Assumption: TimeOut in the H/W */ | | Payment.Get (Out CurrentPayment) | | Coins.ReturnCoins (In CurrentPayment) | | Payment.Clear() | | Mode = Wait_For_Coin | | endif | endif endif Else if Type of message is Return Request | Payment.Get (Out CurrentPayment) | Coins.R

49、eturnCoins (In CurrentPayment) | Payment.Clear() | Mode = Wait_For_Coin End If END DO This algorithm is not really different from this of the sequential solution. What is changed is the blocked reading of a FIFO and reception of a message. The message type is then analysed and the contain

50、ed information processed. More especially it is very easy to see, once again, that the Mode “Dispensing Product” is not more useful. 8 - Third proposed solution – Mode Dispensing product To make this specific mode useful, it is necessary to make “parallel” the dispensing of the product, that is

51、to introduce another process to pilot the PRODUCT DISPENSOR. The following architecture is then proposed, as first approach. Another process : PRODUCT DISPENSER that receives the order of dispensing in a FIFO (solution asynchronous absolutely), controls the dispensing, and returns a message to th

52、e boss MODE for indication of the end (new message). Needed function for MODE in that case, ReturnSlug used when a coin is inserted and the product not yet delivered. This solution is the easiest to think of. It is of course possible to make another grouping more intelligent but with a more comple

53、x solution considering the processes and synchronisation. GOOD LUCK 8.1 Main Algorithm /* How is the main algorithm changed */ Mode = Wait_For_Coin Payment.Clear() WHILE (true) DO -- Infinite loop Read the message from the FIFO /* Blocked Reading of the FIFO */ If Type of me

54、ssage is “OBJECT” do If Mode is Dispensing_Product Return slug Else If Object is valid then -- If not valid, return slug is called in the SubApp Coins Accumulate Payment Set Mode to Wait_For_Selection Endif Else if Type of message is Selection | if (Mode != Wait_For

55、_Selection) do nothing | else | | if (Products.GetPrice (In Selection, Out Price) == AVAILABLE) | | if (Payment.Validate (In Price, Out Change) == OK) | | if (Coins.ReturnCoins (In Change) == OK) | | Mode = Dispensing_Product | | Product.Dispense (In ValidSelection) /* Returned

56、status not used */ | | else | | Payment.Get (Out CurrentPayment) | | Coins.ReturnCoins (In CurrentPayment) | | Payment.Clear() | | Mode = Wait_For_Coin | | endif | | endif | | else | | SELECTOR.NotAvailable() /* Assumption: TimeOut in the H/W */ | | Paymen

57、t.Get (Out CurrentPayment) | | Coins.ReturnCoins (In CurrentPayment) | | Payment.Clear() | | Mode = Wait_For_Coin | | endif | endif endif Else if Type of message is End of Dispensing Set Mode to Wait_For_Coin Clear Payment Else if Type of message is Return Request | Payment.Get (Out CurrentPayment) | Coins.ReturnCoins (In CurrentPayment) | Payment.Clear() | Mode = Wait_For_Coin End If END DO REAL-TIME SOFTWARE ENGINEERING – C006