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.