|
|
pl:miw:2009:miw09_hqed_audit_1 [2009/10/14 12:26] jsi08 |
pl:miw:2009:miw09_hqed_audit_1 [2019/06/27 15:50] |
~~ODT~~ | |
| |
====== HQEd audit ====== | |
| |
autor: Damian Dudziński, email: <damian.dudzinski(at)gmail.com> | |
| |
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 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 problemem dla projektu były problemy z dostępem do CVS-a. Quota na koncie na Charonie była mniejsza niż zajmował pełny kod źródłowy na CVS-ie. Dodatkowo w pewnym momencie ten dostęp został zablokowany. Brak pełnego dostępu do CVS-a spowodował, że z pewnych rzeczy trzeba było zrezygnować jak: bezpośrednie poprawianie warningów, czy jakiekolwiek zajmowanie się komentarzami. | |
| |
=== 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, ...) | |
zamiast: void fun(..., int, ...) | |
| |
Należy nie zapomnieć o pozostawieniu samego parametru, gdyż mogą istnieć wywołania funkcji z tym parametrem, które spowodują błąd kompilacji. | |
| |
== niebezpieczna konwersja == | |
Kompilator wskazał 12 linijek z tym błędem, jednak sprowadzało się do zmiany w 2 linijkach: | |
| |
było: char* cFormats[] = {"...", "...", "...", "..."} | |
zamiast: 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 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ść: | |
dla: | |
było: ((s && r)) || q && p | |
zamiast: (s && r) || (q && p) | |
i | |
było: t && (s && r) || (q && p) | |
zamiast: (t && s && r) || (q && p) | |
| |
Tu dokładność kompilatora okazała się bardzo potrzebna, bo okazało się, że jedno z nawiasowań jest logicznie błędnym rozumowaniem. | |
| |
== Brak klamr == | |
To dwa najważniejsze ostrzeżenia, które 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(...); | |
{ | |
... | |
} | |
zamiast: | |
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 | |
{ | |
... | |
} | |
zamiast: | |
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 plikach generowanych 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 juz dobrze opisanego sytemu:[[hekate:hekate_case_thermostat]]. Ponieważ został juz ten problem tam dość dobrze opisany dodam tylko, że zmieniłem miesiące aby 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 trochę na podstawie już stworzonego modelu (dostępnego w aplikacji) i trochę na podstawie własnych pomysłów. Jak dane wejściowe otrzymuje pin wprowadzony przez użytkownika, prawidłowy z bazy danych, deklarowana kwota, dostępne środki na koncie jak i w bankomacie. Na podstawie tych danych daje jedną z odpowiedzi: ok, 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}} | |
| |
== Consonance vs Dissonance == | |
| |
=== Uwagi === | |
* Jeśli damy save i zapiszemy plik bez rozszerzenia, żeby ją edytor sam automatycznie dodał, zapisze bez kropki i dodatkowo z każdym naciśnięciem save będzie tworzył kolejny plik konkatenując nazwę o rozszerzenie bez kropki, zamiast zapisywać w starym. Jeżeli się ręcznie wpisze nazwę z rozszerzeniem '.hml', nie ma tego problemu. | |
* Kiedy chce się sprawdzić czy wielkość zawiera się w przedziale poprzez funkcję in, 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 zawieszenie programu | |
* 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) | |
| |
| |
| |
===== 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! | |