自动售货机需求报告.docx

1、自动售货机需求报告Vending Machine1 - ObjectivesThe 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 is inter

2、esting 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 OverviewThis example is an extension of the problem presented at the Forum ”Structured Develo

3、pment” 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 try putting junk into

4、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 they do business on a na

5、rrow 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.- Accept nickels, dimes and quarte

6、rs. 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 is available, if not available, ret

7、urn 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 customers payment on request if he or she decides not to make a selection.- Dispense the product to the customer if it is avail

8、able 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 is received.Several extra requirements could b

9、e added to the first list of users 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 the customer are accumulated in the coins storage (An

10、yway we dont know if the inserted coins are used for giving back the change or not).- Tolerance for validating the thickness, size & weight (doesnt have effect on the architecture nor on the algorithms.- Reject coins as slug if there is not enough change and of course doesnt deliver the product (do

11、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 diagramSince no information on the hardware is available, the following context diagram is proposed (as functional di

12、agram; 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 customers actions and notifications,- PRODUCT DISPENSER: the box containing the products.Since there is no i

13、ndication 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 compilation (#define of C).- Each valid object is sent directly to the change

14、 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 for every storage.- The number of type of product is defined by MaxTypeOfProducts a

15、nd 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 data flow called slug is in fact a control flow because an even to the terminator COIN

16、S SYSTEM.Recall of the State Transition Diagram4 - Identification of objects and classes4.1 ClassesFrom the text before and the global SART model presented in specification, the following objects, classes and functions can be proposed.Entity NameAttributesTypeObjectThickness (integer)Size (integer)W

17、eight (integer)T_ObjectCoinObjectValueTypeT_CoinPaymentPaymentIntegerProductIdentifierPrice (integer)T_ProductModeModeT_Mode4.2 InstantiationThe instantiation of a class becomes an object. In the case of the vending machine there are:Coins storage = multiple instantiation of the class Coin,Products

18、storage = multiple instantiation of the class Product,CurrentPayment = single instantiation of the class Payment,CurrentMode = single instantiation of the class Mode.4.3 External interfaces1 terminator is translated in 1 TOOD entity such as machine, sub-application or process. In the case of the SAR

19、T diagram above, 3 machines are identified.5 - FunctionalityEntitiesFunction (methods)ParametersCoins- Validate- Input = object- output = Value, status (coin or slug)- Accumulate- Input : Coin- Output : status (full)- ReturnCoins- input : Change- Output : Status (enough, not enough)Payment- Accumula

20、te- Input : CoinValue- Output : none- Get- Input : none- Output : Payment- Clear- 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

21、 (OK/NOK)Mode(Contained in the main controller)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, -

22、Output:6 - First Proposed solution : sequential caseNote: 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 research

23、 of the most elementary objects before grouping them.The process is bottom-up.6.1 ArchitectureFigure 1: Application Architecture2 sub-applications appear: Coins & Products.The sub-application “Coins” is very big compared to “Products” and to the machines SELECTOR & Payment. But the grouping of relat

24、ed 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 “Products” contains

25、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 definition of the clas

26、s 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 (“GetPrice”) to get this

27、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 & EnvironmentIt is not necessary to draw again the diagram because it would be very close to Figu

28、re1.6.3 Sub-application “Coins”6.3.1 Interfaces & Environment6.3.2 Body of the sub-applicationThe 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 “IsEqual”) and COINS SYSTEM (via “Initialise”

29、). 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 dont know the interfaces of the SELECTOR.The questions that can be asked are: Is it possible to read without wait the selection? What is the hardware for t

30、he users lamp (not available), time out , on/off?6.6 Main Algorithm/* Proposal of Algorithm for the main() */Mode = Wait_For_CoinPayment.Clear()while (true) do wait 1 second Not really necessary in that case because the CPU is dedicated to thevending machineif (GetValue(Out Value) = OK)| Payment.Acc

31、umulate (In Value)| Mode = Wait_For_Selectionendif if (SELECTOR.AcceptSelection(Out Selection) = true) | 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 | | Product.Dispense (In ValidSelection) /* Returned status not used */ | | else | | Payment.Get (Out CurrentPayment) | | Coins.ReturnCoins (In CurrentPayment) | | endif | | Payment.Clear() | | Mode =