Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:miw:miw08_ardcase_cs:biletomat [2008/05/24 13:27] miw |
pl:miw:miw08_ardcase_cs:biletomat [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 1: | Linia 1: | ||
| ====== Analiza biletomatu i design ====== | ====== Analiza biletomatu i design ====== | ||
| + | |||
| + | |||
| ==== Wybrany przykład: ==== | ==== Wybrany przykład: ==== | ||
| - | [[:pl:miw:miw08_ardcase_cs:tpa_b3osz_mmazur_-_automat.pdf|Well documented Vending Machine Model by T. Pałosz, M. Mazur (AiR IV) <localcopy> ]] | + | {{:pl:miw:miw08_ardcase_cs:tpa_b3osz_mmazur_-_automat.pdf|Well documented Vending Machine Model by T. Pałosz, M. Mazur (AiR IV) <localcopy> }} |
| == Pozostałe przykłady == | == Pozostałe przykłady == | ||
| Linia 242: | Linia 244: | ||
| - fizyczna możliwość wypłaty (czy jest tusz do drukowania/pieniądze do wydania reszty) | - fizyczna możliwość wypłaty (czy jest tusz do drukowania/pieniądze do wydania reszty) | ||
| + | |||
| ===== Ostatnie zmiany ===== | ===== Ostatnie zmiany ===== | ||
| + | 24.05.2008 - usunięcie linków zewnętrznych, dodane kopii lokalnych, drobne zmiany | ||
| + | |||
| 28.04.2008 - od poprzedniej wersji ARD/XTT (v1) przy użyciu nowej wersji VARDA wygenerowano poprawione ARD, a za pomocą HQed XTT (v2). Ważne - w wersji v1 w tabelach reguł występowały działania, które należało wyeliminować. W tym celu wprowadzono nowy atrybut - reszta. Po zmianach okazało się, iż aby wyliczyć, w jakiej kwocie należy wydać resztę należy odjąć atrybut - cena produktu (priceList[chosenProduct]), od atrybutu wpłacona przez klienta kwota (remittance). Reszta=wpłata-cena. Tak powstały atrybut należy dalej wykorzystać do sprawdzenia, czy biletomat posiada środki do wydania reszty. Powoduje to porównanie atribute2atribute, które może zostać zapisane niejednoznacznie tj. gdy fundsInMachine<change lub change>fundsInMachine atrybut enoughCashToChange jest prawdą, aby nie powodować reguł redundantnych koniecznym wydaje się przyjęcie jednolitej konwencji np w postaci ustalania jednego (np. skrajnie prawego w tabeli) jako dowolnego/stałego i dopasowywanie prawego jako większego/mniejszego niż prawy. Pytanie co stanie się przy większej ilości atrybutów | 28.04.2008 - od poprzedniej wersji ARD/XTT (v1) przy użyciu nowej wersji VARDA wygenerowano poprawione ARD, a za pomocą HQed XTT (v2). Ważne - w wersji v1 w tabelach reguł występowały działania, które należało wyeliminować. W tym celu wprowadzono nowy atrybut - reszta. Po zmianach okazało się, iż aby wyliczyć, w jakiej kwocie należy wydać resztę należy odjąć atrybut - cena produktu (priceList[chosenProduct]), od atrybutu wpłacona przez klienta kwota (remittance). Reszta=wpłata-cena. Tak powstały atrybut należy dalej wykorzystać do sprawdzenia, czy biletomat posiada środki do wydania reszty. Powoduje to porównanie atribute2atribute, które może zostać zapisane niejednoznacznie tj. gdy fundsInMachine<change lub change>fundsInMachine atrybut enoughCashToChange jest prawdą, aby nie powodować reguł redundantnych koniecznym wydaje się przyjęcie jednolitej konwencji np w postaci ustalania jednego (np. skrajnie prawego w tabeli) jako dowolnego/stałego i dopasowywanie prawego jako większego/mniejszego niż prawy. Pytanie co stanie się przy większej ilości atrybutów | ||
