Graficzne programowanie obiektowo zorientowane

Graficzne programowanie obiektowo zorientowane

Projekt z przedmiotu
Specjalizowane języki programowania
Temat: Zastosowanie programowania
obiektowego w środowisku LabView
Wykonali:
Krzysztof Przybyłek
Piotr Misiuda
IVFDS
Istotę programowania obiektowego w LabView przedstawimy na konkretnym
przykładzie – system sterowania klimatyzacją.
System sterowania klimatyzacją składa się z:
- panelu wejściowego z cyfrowym i analogowym we/wy,
- ekranu VGA 9-calowego,
- heater (podgrzewacz),
- cooler (schładzacz),
- fan (wentylator),
- temp sensor (czujnik temperatury).
Podgrzewacz i schładzacz są włączane i wyłączane sygnałami cyfrowymi. Sygnały
analogowe są użyte w celu powiadomienia schładzacza/podgrzewacza o ile stopni ma być
schłodzone/podgrzane powietrze. Użytkownik ustala żądaną temperaturę pokrętłem.
Rozwiązanie „z góry na dół”, nie używając gotowych obiektów, a zawierając wszystko w
jednym, przedstawia się następująco:
Jak widać z diagramu, w jednym przyrządzie zawarto interfejs użytkownika (GUI) i strukturę
logiczną programu. Cały program to jeden monolit, w którym wszystkie zmienne są globalne.
Utrudnia to ewentualne ich zmiany, dodanie dodatkowych opcji. Niemożliwe jest też
używanie części aplikacji w innych projektach. Kod programu staje się mniej czytelny,
trudniejszy do zrozumienia i ewentualnego modyfikowania. Jeśli GUI i application logic są
umieszczone w jednym przyrządzie, nie jest możliwe dokonywanie oddzielnych zmian na
jednym z nich.
Silne powiązania pomiędzy przyrządami i zmiennymi globalnymi powodują, że jeśli przyrząd
chce zmienić zmienną globalną, to musi ją także zmienić w pozostałych przyrządach.
Lepszym wyjściem jest podzielenie monolitycznego programu na oddzielne składniki, jakby
klocki, które pasują do siebie i tworzą wspólną całość.
Każdy składnik to mini-aplikacja zamykająca w sobie swoje zmienne i funkcje. Realizowane
jest to przez programowanie obiektowe w postaci klas. Każda klasa to zmienne lokalne –
prywatne dla klasy, oraz publiczne, widoczne dla użytkownika tej klasy. Przykładowo klasa
fan:
A to już deklaracja klasy w C++:
a tak wygląda ta klasa w LabView:
Wykorzystujemy tutaj LabView LLB. Przyrządy powyżej linii reprezentują publiczne
funkcje, poniżej – prywatne. Zmienna speed zawarta jest w Fan Data Members.ctl.
Fan Create.vi tworzy obiekt typu fan (konstruktor), Fan Destroy.vi usuwa obiekty Fan.
równoznaczne z :
Realizacja całego systemu sterowania klimatyzacją rozpoczyna się od podziału zadania na
rozdzielne składniki. Będą to:
- GUI-system klimatyzacji,
- system klimatyzacji.
System klimatyzacji GUI odpowiada za wartości wejściowe i przekazuje je dalej do systemu
klimatyzacji. Ponadto prezentuje użytkownikowi wyniki działania składnika system
klimatyzacji.
Na system klimatyzacji składa się 5 klas:
- climate control (kontroler klimatyzacji),
- fan (wentylator),
- heater,
- cooler,
- temp sensor (czujnik temperatury).
Klasa Climate Controler zawiera w sobie 4 funkcje, które składają się na interfejs składnika
Climate system. Są to:
- wanted temp,
- status,
- run,
- stop.
W LabView klasy te odwzorowują przyrządy używając do ich przechowywania LabView
LLB. Vi przechowujące dane publiczne będą pierwsze (top-level). Poniższy rysunek
przedstawia publiczny interfejs klasy Fan:
Fan reference zapobiega nieumyślnemu przesłaniu przez użytkownika obiektu jednej klasy
do innej.
Używając LabView GOOP Wizard do stworzenia klasy LLB, tworzonych jest 5
pomocniczych funkcji do tworzenia obiektów i uzyskania dostępu do ich danych. Są to:
-
create an object (stwórz obiekt) – przydziela miejsce na prywatne dane
obiektu i zwraca wskaźnik do tych danych, jest używana w konstruktorze
klasy,
-
get an object’s data ( weź dane obiektu) - zwraca dane skojarzone przez
wskaźnik obiektu, używana w razie potrzeby odczytania aktualnych danych
obiektu,
-
get an object’s data and lock it for futher modifications – zwraca daną
skojarzoną przez wskaźnik do obiektu i zabiezpiecza przed modyfikacją tej
danej,
- set an object’s data – usuwa zabezpieczenie stworzone przez poprzednią
funkcję,
-
destroy an object – zwalnia pamięć i usuwa obiekt. Używana jako destruktor
klasy.
Konstruktor Fan:
Get speed:
Destruktor Fan destroy
Gotowy panel GUI wygląda nastepująco:
Funkcja w lewym górnym rogu tworzy obiekt Climate Controler. Daje ona wskaźnik
przekazywany dalej do funkcji Run (u góry po środku), a f. Run wykonuje kontroler w pętli,
porównując aktualną temperaturę z temperaturą docelową ( przechowywaną w zmiennej
prywatnej desire temp) i odpowiednio zmienia ustawienia podgrzewacza (heater), schładzacza
(cooler) i wentylatora (fan). Wewnątrz pętli żądana temperatura przekazywana jest dalej do
climate controler, używając przy tym funkcji Wanted temp, a aktualny status kontrolera
określany jest przez funkcję Status. Kiedy użytkownik naciśnie przycisk Stop, wywoływana
jest funkcja Stop, która przerywa wykonywanie funkcji Run, i obiekt climate controler jest
usuwany przez funkcję Destroy (prawy górny róg).
Poniższy rysunek przedstawia diagram funkcji Wanted Temp, która modyfikuje prywatną
zmienną desired temp, która jest odczytywana w funkcji Run:
Podsumowanie:
Można dostrzec następujące zalety rozbicia programu Climate Control na dwie części.
Dzięki rozdzieleniu implementacji składnika Climate Control i interfejsu GUI, możemy
swobodnie zmieniać implementację nie martwiąc się przy tym jak zareaguje GUI. To
„skapsułkowanie” rozwiązuje problem globalnych zmiennych jak w przypadku pierwszej
implementacji problemu. Analogicznie, nie musimy się martwić o reakcję programu w
przypadku zmian na interfejsie GUI. Kod programu Staje się bardziej czytelny i zrozumiały.
Jest skalowalny tj. można dodawać/usuwać nowe elementy, tworząc odwołania do funkcji
Climate Controler Create i Run. Poszczególne składniki dzięki temu że działają na swoich
zmiennych, mogą być wykorzystywane w innych aplikacjach.