QMH pierwsza próba

Tematy związane z tworzeniem dużych aplikacji. Zaganiednia dotyczące architektury oraz zasad tworzenia optymalnych rozwiązań.
MK_Zuk
Posty: 83
Rejestracja: 01 gru 2009 11:53
Wersja środowiska: LabVIEW 2014

QMH pierwsza próba

Post autor: MK_Zuk »

Witam,
postanowiłem nauczyć się QMH, zacząłem od przykładowego zadania CLD z bankomatem.

Czy ktoś mógłby rzucić okiem i ocenić?

Generalnie założyłem, żeby przy tej próbie nie korzystać z wbudowanego szablonu a zrobić wszystko od zera.
W programie brakuje kilku rzeczy, o których wiem:
- nie ma obsługi błędów,
- nie ma zamknięcia kolejki i zdarzenia dynamicznego,
- operacja dodania/odjęcia pieniędzy na koncie powinna być zabezpieczona np. przez realizację za pomocą zmiennej funkcjonalnej.

W razie czego wrzuciłem też PDFa z treścią zadania.

Dzięki za pomoc
Pozdrawiam
Zuk
Załączniki
ATM in QMH.zip
(449.14 KiB) Pobrany 422 razy
Awatar użytkownika
Pitol
Moderator
Posty: 984
Rejestracja: 19 lip 2007 00:00
Wersja środowiska: LabVIEW 2019
Lokalizacja: Kraków

Re: QMH pierwsza próba

Post autor: Pitol »

Rzuciłem okiem... no i pewnie byś zdał CLD. Tylko dopieścić program trochę.
Dodać to co napisałeś. Poza tym w kilku VI olałeś sprawę z błędami (Chack Pin, Read Accounts).
Referencje do kontrolek zbij w tablicę przed pętlą. Po co ma to się robić za każdym razem.
Staraj się lepiej opisywać nazwy kontrolek i trzymać jednego języka.
A poza tym to :-BD :-BD :-BD
ObrazekObrazekObrazek
Chcesz taki podpis? Zajrzyj tutaj
MK_Zuk
Posty: 83
Rejestracja: 01 gru 2009 11:53
Wersja środowiska: LabVIEW 2014

Re: QMH pierwsza próba

Post autor: MK_Zuk »

Dzięki :-BD
MK_Zuk
Posty: 83
Rejestracja: 01 gru 2009 11:53
Wersja środowiska: LabVIEW 2014

Re: QMH pierwsza próba

Post autor: MK_Zuk »

Zastanawia mnie jeszcze jedno.
Generalnie QMH jest integracją podstawowych struktur:
maszyna stanów i producent konsument, gdzie pętla wykonująca
zadanie jest to pętla konsumenta zbudowana w strukturze maszyny stanów, do której przychodzą także
(albo przede wszystkim) rozkazy wykonania konkretnego stanu z zewnątrz - pętli producenta,
dodatkowo, kiedy jest to potrzebne, przechodzą dowolne dane przez typ variant.

Pisząc kod maszyny stanów stany zapisuje się w definicji typu kontrolki enum, która przechowuje wszystkie stany
a definicja typu ułatwia zarządzanie stanami w kontrolce (dopisywanie/usuwanie).

W strukturze QMH jako element przenoszący rozkaz używa się raczej typu String.

W pierwszym przypadku (enum) rozwiązanie jest wygodniejsze ale każda kolejka musi mieć swoje subVI obsługujące.
W drugim przypadku (string) wszystkie kolejki można tworzyć jednym (powielonym dla każdej kolejki subvi) i liczba plików
obsługujących kolejki jest mniejsza ale kosztem tego, że do selektora struktury case obsługującej stany trzeba podać dokładnie takie same nazwy
zapisane w stringach czyli łatwiej zrobić błąd - najprostsza literówka.

Które rozwiązanie preferujecie i dlaczego?
Kolejka przenosząca dedykowanego enuma i varianta (jak ja to zrobiłem wyżej)
czy kolejka przenosząca stringa i varianta (tak jest chyba we wszystkich filmach na YT jak również w szablonie LabVIEW - Create... --> New Project),
a może jest jeszcze jakieś trzecie rozwiązanie?

Pytam, bo chciałbym od razu nauczyć się dobrego nawyku do pracy w tej strukturze.

Pozdrawiam
Zuk
Awatar użytkownika
Pitol
Moderator
Posty: 984
Rejestracja: 19 lip 2007 00:00
Wersja środowiska: LabVIEW 2019
Lokalizacja: Kraków

Re: QMH pierwsza próba

Post autor: Pitol »

Ja osobiście preferuję Enum, bo trudniej jest popełnić błąd.
Przy stringu jest elastyczność, ale każda literówka może zaboleć (choć jak sobie literówki obsłużysz w odpowiednim case to w sumie nie będzie tak źle).

W każdym razie ja nie korzystam z żadnej z powyższych metod.
Chyba, że robię jakiś super mały programik w "5 minut".

W swoich programach korzystam z wzorca projektowego "Command Pattern" (do poczytania w sieci).
W skrócie - tworzysz klasę "Command", po której dziedziczą Ci konkretne "zadania".
Czyli zamiast klastra z enumem/stringiem + variant masz obiekt konkretnej klasy.
CommandPattern.PNG
Jeśli chcesz, to w załączniku masz mój template.
Nie jest idealny, bo nie mam czasu go dopracować ale do zrozumienia idei Command Pattern się w pełni nadaje.
W moim przykładzie mam dwa "wzorce". Jeden do obsługi komend w maszynie stanów (CommandManager) a drugi do obsługi zdarzeń użytkownika (EventMngr).
W tym szablonie zaimplementowanych jest od razu kilka funkcji:
AppInit - wszystko co ma się wydarzyć przed uruchomieniem FP
ReadConfig - odczyt pliku *.xml z ustawieniami
Save Config - zapis ustawień do pliku *.xml
RefreshFP - metoda do odświeżania elementów na panelu (wyłącza odświeżanie FP, zmienia wartości kontrolek, włącza odświeżanie FP)
ErrorHandler - obsługa błędu
Quit - zamknięcie programu.

Część z nich to tylko szablony, do wypełnienia w zależności od funkcjonalności.
Nowe komendy dodajesz poprzez stworzenie klasy, która będzie dziedziczyć po klasie CommandManager.

Korzystając z tego rozwiązania masz największy "narzut" na przygotowanie, ale jak już masz taki template to można zdecydowanie przyspieszyć prace.

Ja w tym momencie staram się przyzwyczaić do Actor Framework, ale póki to mi się nie uda korzystam z mojego szablonu.

Pobaw się i daj znać czy się spodobało.
Jak coś to pisz.
Załączniki
Template.zip
(310.71 KiB) Pobrany 446 razy
ObrazekObrazekObrazek
Chcesz taki podpis? Zajrzyj tutaj
MK_Zuk
Posty: 83
Rejestracja: 01 gru 2009 11:53
Wersja środowiska: LabVIEW 2014

Re: QMH pierwsza próba

Post autor: MK_Zuk »

Dzięki.
Wzorzec bazuje na programowaniu obiektowym, którego jeszcze nie ogarniam.
Powoli zaczynam dopiero cokolwiek próbować robić w miarę wolnego czasu.
Jest to następny poziom do opanowania ;)
jak widać coraz powszechniejszy jeżeli chodzi o programowanie w LabVIEW.

Ale z tym enumem trafiłem przynajmniej jeżeli chodzi o "aplikacje robione w 5 minut" ;)

Pozdrawiam
Zuk
ODPOWIEDZ