~~ODT~~ ====== HQEd audit ====== autor: Damian Dudziński, email: Test the new version of HQEd. Check quality, test, update manual, code and funcionality audit, in wiki description and s5 presentation. ====== Projekt ====== ===== Prezentacja ===== Prezentacja wyników pracy: [[pl:miw:2009:miw09_hqed_audit_1:slideshow|prezentacja]] ===== Sprawozdanie ===== ==== Statyczne linkowanie ==== Jednym z ważnych celów projektu było statyczne zbudowanie aplikacji z Qt4. Powody: * Zlikwidowanie potrzeby instalowania Qt4 dla użytkownika końcowego, czyli duże ułatwienie dla niego; * Uniknięcie problemów ze zgodnością nowych wersji Qt; W tej kwestii udało mi się skompilować statycznie zarówno Qt4 (w wersjach: 4.2.3, 4.3.0, 4.5.2), jak i program (rozmiar wzrósł do 5.9 MB z 3.8 MB). Niestety po jego uruchomieniu otrzymałem w konsoli błąd: 'segmetion fault'. Kompilacja Qt4 jest bardzo czasochłonna, na moim komputerze zajmowała nawet do 13h (dla wersji 4.5.2, pełna kompilacja z przykładami). ==== Audyt kodu ==== === Dostęp do CVS-a === Dużym utrudnieniem dla projektu był problem z dostępem do CVS-a. Quota na koncie na Charonie była mniejsza niż zajmował cały kod źródłowy na CVS-ie. Dodatkowo w pewnym momencie dostęp ten został zablokowany. Brak pełnego dostępu do CVS-a spowodował, że z pewnych rzeczy - takich jak bezpośrednie poprawianie ostrzeżeń kompilacji czy jakiekolwiek zajmowanie się komentarzami - trzeba było zrezygnować. === Analiza ostrzeżeń kompilacji === == nieużywany parametr == Tych ostrzeżeń kompilator wykrył aż 82, poprawa kodu sprowadza się do zmiany: było: void fun(..., int param, ...) jest: void fun(..., int, ...) Należy nie zapomnieć o pozostawieniu samego parametru, gdyż mogą istnieć wywołania funkcji z tym parametrem, które spowodują błędy kompilacji. == niebezpieczna konwersja == Kompilator wskazał 12 linijek z tym błędem, jednak sprowadzało się do zmiany w 2 linijkach kodu: było: char* cFormats[] = {"...", "...", "...", "..."} jest: const char *cFormats[], Wcześniejszy zapis umożliwiał zmianę czegoś zadeklarowanego jako stałe (niejawna konwersja z 'const char *' do 'char *'). == niezainicjowana zmienna == 11 wystąpień. Tu trzeba było zainicjować zmienną, ustawić na 0, NULL lub jakąś inną początkową wartość. == Błędne nawiasowanie == 3 ostrzeżenia. Chodziło o to, żeby iloraz logiczny wziąć w nawiasowanie, co zapewnia czytelność: było: ((s && r)) || q && p jest: (s && r) || (q && p) i było: t && (s && r) || (q && p) jest: (t && s && r) || (q && p) Tu dokładność kompilatora okazała się bardzo potrzebna, bo okazało się, że jedno z nawiasowań było logicznie błędnym rozumowaniem. == Brak klamr == To dwa najważniejsze ostrzeżenia, które także okazały się błędami logicznymi w programie. * Umiejscowienie średnika w tym miejscu powodowało, że wszystko w klamrach wykona się niezależnie od spełnienia warunków if-a. było: if(...); { ... } jest: if(..) { ... } * Brak klamr w tym miejscu powodował, że else z poziomu niższego odnosił się do if-a o poziom wyżej. było: if(...) if(...) { ... } else { ... } jest: if(...) { if(...) { ... } else { ... } } === Błąd kompilacji === Jedyny błąd kompilacji okazał się zależny od wersji qt. Skompilowanie programu w wersji qt 4.3.0 i niższej: 4.2.3 błędu nie pokazuje, natomiast pojawia się on przy wersjach 4.4.3 i wyższych. Błąd pojawiał się w pliku generowanym automatycznie z plików QTDesignera. Po edycji tych plików, problem zgodności został rozwiązany. ==== Testowanie Aplikacji ==== === Konfiguracja na której testowana była aplikacja === * Ubuntu 8.10, Qt ver. 4.4.3, Gnome ver. 2.24.1 * Ubuntu 9.04, Qt ver. 4.5.0, Gnome ver. 2.26.1 Potem były także zmiany wersji qt na wersje: 4.3.0 i 4.2.3 (dla Ubuntu 8.10) - na nich większych testów nie przeprowadzałem. === Stworzone modele === == Thermostat == Zbudowałem model termostatu na podstawie już dobrze opisanego sytemu: [[hekate:hekate_case_thermostat]]. Ponieważ problem ten został już tam dość dobrze opisany, dodam tylko, że zmieniłem miesiące tak, by odpowiadały porom roku na półkuli północnej. Wykonanie w HQEd (screen): {{:pl:miw:2009:miw09_hqed_audit_1:thermostat.png?600|}} Wykonanie w HQEd (plik o ściągnięcia): {{:pl:miw:2009:miw09_xtt_drools:thermostat.zip}} == ATM == Zbudowałem model bankomatu zarówno na podstawie już stworzonego modelu (dostępnego w aplikacji) jak i na podstawie własnych pomysłów. Jako dane wejściowe przyjąłem: pin wprowadzony przez użytkownika, prawidłowy pin z bazy danych, deklarowaną kwotę do wypłacenia, dostępne środki na koncie oraz w bankomacie. Na podstawie tych danych program daje jedną z odpowiedzi: wypłacenie kwoty, nieprawidłowy pin, brak środków na koncie, brak środków w bankomacie. Wykonanie w HQEd (screen): {{:pl:miw:2009:miw09_hqed_audit_1:atm.png?600|}} Wykonanie w HQEd (plik o ściągnięcia): {{:pl:miw:2009:miw09_xtt_drools:atm.zip}} === Uwagi === * Jeśli Podczas zapisywania pliku nie podamy rozszerzenia ('.hml') w nazwie (chcąc by edytor sam ją automatycznie dodał), zostanie utworzony plik o nazwie wydłużonej o 'hml' i bez roszerzenia. Dodatkowo z każdym zapisaniem program będzie tworzył kolejny plik konkatenując nazwę o 'hml', zamiast zapisywać w starym. Jeżeli wpisze się ręcznie nazwę wraz z rozszerzeniem '.hml', nie ma tego problemu. Jest to zależne od sytemu na którym używa się aplikacji. * Nieintuicyjne ustawianie granic przedziału - należy najpierw zdefiniować dolny próg i dopiero wtedy zaznaczyć range (radio button cały czas aktywny) i podać górny próg, w przeciwnym razie wyskakuje błąd; * Program zawsze pyta, czy zapisać zmiany - niezależnie od tego czy nastąpiły; * Mało ergonomiczny interfejs – trzeba wykonać dużą ilość kliknięć aby cokolwiek wykonać; * Wartość 'row' w 'cell editor' powinna zostać ograniczona - zbyt duża powoduje zakończenie programu wyjątkiem; * Zakończenie pracy aplikacji wyjątkiem podczas konstruowania skomplikowanego wyrażenia. * Część przeznaczona do rysowania modelu zmienia swój rozmiar dopiero po ponownym wczytaniu modelu; * Tips na początku przyczepiony do nie wiadomo czego, poza oknem (może być to kwestia systemu na którym jest użytkowany); Program jest cały czas w trakcie tworzenia, więc tego typu uwagi często dotyczą rzeczy, których jeszcze nie zrobiono, a nie błędów. Część błędów zależy bezpośrednio od platformy i zainstalowanej na niej wersji qt4. ===== Do wykonania ===== ==== Audyt kodu ==== * Przetłumaczenie komentarzy w j. polskim na j. angielski. * Dostosowanie formatu komentarzy do formatu obsługiwanego przez doxygen. * komentowanie parametrów funkcji: ''\param nawa_parametru - opis'' (nazwa parametru bez typu!) * Uzupełnienie nazw argumentów w plikach nagłówkowych * Usunięcie wszystkich **możliwych** ostrzeżeń podczas kompilacji. * ''unused variable'' * conversion warnings * inne * Tutaj należy uważać gdyż w niektórych momentach kod jest bardzo czuły na wszelkie zmiany. * Sprawdzenie informacji zawartych w nagłówkach plików (nazwa pliku, klasy, daty). ==== Testowanie HQed ==== * Zadanie polega na dprawdzeniu poprawności działania narzędzia. * Testowanie powinno zostać zrealizowane na dwa sposoby: * Testowanie modelowania systemów od podstaw: * Zamodelować od początku system Thermostat. * Zamodelować od początku system ATM. * Oraz inne dostępne. * Nowe pliki wrzucamy na wiki z wyraźnym zanzaczeniem że są **nowe**. * Należy zwrócić uwagę na: * Ograniczenia narzędzia - czego nie da się zrobić co jest przewidziane w specyfikacji XTT. * Czy proces modelowania przebiega poprawnie: * Czy i ewentualnie w jakich sytuacjach narzędzie **umożliwia** wprowadzenie **niepoprawnych** danych. * Czy i ewentualnie w jakich sytuacjach narzędzie **uniemozliwia** wprowadzenie **poprawnych** danych. * Testowanie na gotowych modelach: * Należy wykorzystać modele z poprzedniego punktu, oraz inne dostępne. * Testowanie powinno polegać na: * Próbie edycji poszczególnych elementów modelu: * Należy sprawdzić czy po edycji poszczególnych parametrów, właściwości danego obiektu narzędzie odpowiednio sygnalizuje, bądź przestaje sygnalizować anomalie. Przykładowo: * Dla atrybutu możemy zmienić: typ, nazwę, klasę, relację, itp. * Dla typu możemy zmienić: dziedzinę, rodzaj ograniczeń. Dodatkowo dla typów symbolicznych uporządkowanych kolejność elementów. * W tabelach należy manipulować kolumnami i wierszami (dodawać, usuwać, zamieniać, zmieniać konteksty, itp), zmieniać typ tabeli. * W komórce należy zmienić działanie, zmieniać typy zwracane na poszczególnych poziomach. * Przykładowo: * Po zmianie typu atrybutu (np. z symbliczonego na liczbowy) narzędzie powinno wyświetlić informacje o niezgodności typów zwracanego i oczekiwanego. * Po zmianie relacji atrybutu z ''internal'' na ''output'', narzędzie powinno wyświetlić informacje o nieprawidłowym użyciu atrybutu w kolumnach kontekstu warunkowego w których ten atrybut się znajduje. * Testowaniu zapisu i odczytu z pliku: * Prostych i złożonych modeli. * Złożonych (zagnieżdżonych) wyrażeń w komórkach. * Testowaniu generowania kodu PROLOGU: * Czy kod jest poprawny składniowo, czy jest uruchamialny przez HeaRT. * Czy kod jest poprawny pod względem semantycznym z modelem XTT. ====== Spotkania ====== ===== 20090225 ==== ===== 20090528 ==== Uwagi: http://student.agh.edu.pl/~dudad/miw/ ====== Materiały ====== ===== Dostęp do CVS HQeD ====== ==== CVS Access ==== Aby mieć możliwość korzystania z CVS to oprócz konta na charonie potrzebne jest skonfigurowanie systemu na wsłasnym komputerze: * Aby nie powtarzać operacji za każdym razem najlepiej jest umieścić poniższe instrukcje w pliku inicjalizacyjnym powłoki: export CVSROOT=:ext:kinio@charon.ia.agh.edu.pl/mnt/cvs/cvs-hades export CVS_RSH=ssh * Powyższe instrukcje są kompatybilne z powłoką //sh// i pochodnymi, należy je odpowiednio zmodyfikować dla innych powłok (o ile konieczne). * Ciąg ''kinio'' zastąpić własną nazwą użytkownika. * Dla osób pracujących w systemi Windows dobrym rozwiązaniem może być pakiet Cygwin (podczas inastalacji należy zaznaczyć moduł obsługujący CVS, SSH). W celu uniknięcia powstawania **bardzo** niechcianych konfliktów w systemie kontroli wersji należy zastosować się do poniższych uwag: * Tuż przed rozpoczęciem pracy zsynchronizować swoję wersję kodu z tą która aktualnie znajduje się w repozytorium wpisując komendę: cvs update * **Nie pobieramy i nie edytujemy wersji tagowanych**. * Podobnie: nie tagujemy żadnych wprowadzanych do repozytorium wersji :!: * Często wprowadzamy zmiany do repozytroium wykonując tzw. ''commit'' komendą: cvs ci * **Zakładamy że wykonujemy jeden ''commit'' po zakończeniu pracy z pojedynczym plikiem** :!::!: * Zawsze po zakończeniu pracy upewniamy się że wprowadziliśmy zmiany do CVS. * Nie usuwamy żadnych plików. * Można dodawać pliki (tylko niezbędne) poleceniem: cvs add filename * Staramy się umieszczać w CVS wersję możliwą do skompilowania. * Podczas kompilacji mogą powstawać różne dodatkowe pliki np. moc_*.cpp, ui_*.h, *.o, Makefile* - **nie dodajemy ich do repozytorium** :!::!: ==== CVS OnLine ==== See [[https://hekate.ia.agh.edu.pl/webcvs/cvs-hades/view.vc/hades/hqed|On line HaDeS CVS]] Log in with the same user/password as in wiki, you need to be in the appropriate cvs group at charon for this to work! ==== Doxy OnLine ==== The [[https://hekate.ia.agh.edu.pl/webdoxy/hqed/doc/|DoxyGen doc]] for Hqed, automagically regenereted while you sleep :-) Log in with the same user/password as in wiki, you need to be in the appropriate cvs group at charon for this to work!