Both sides previous revision
Poprzednia wersja
Nowa wersja
|
Poprzednia wersja
|
pl:miw:2009:miw09_hqed_audit_1 [2009/03/07 14:28] kinio |
pl:miw:2009:miw09_hqed_audit_1 [2009/10/14 20:18] jsi08 |
====== Opis ====== | ~~ODT~~ |
Damian Dudziński, email: <damian.dudzinski(at)gmail.com> | |
| |
Test the new version of HQEd. | ====== HQEd audit ====== |
| |
Check quality, test, update manual, code and funcionality audit, in wiki description and s5 presentation. | 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. |
| |
====== Spotkania ====== | |
===== 20090225 ==== | |
====== Projekt ====== | ====== 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 ===== | ===== Do wykonania ===== |
* Przetłumaczenie komentarzy w j. polskim na angielski. | ==== Audyt kodu ==== |
| |
| * Przetłumaczenie komentarzy w j. polskim na j. angielski. |
* Dostosowanie formatu komentarzy do formatu obsługiwanego przez doxygen. | * Dostosowanie formatu komentarzy do formatu obsługiwanego przez doxygen. |
* komentowanie parametrów funkcji: ''/// \param - opis'' | * 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. | * Usunięcie wszystkich **możliwych** ostrzeżeń podczas kompilacji. |
* ''unused variable'' | * ''unused variable'' |
* conversion warnings | * conversion warnings |
* inne | * inne |
* Sprawdzenie informacji zawartych w nagłówkach plików (nazwa pliku, klasy itp.). | * 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/ |
| |
====== Sprawozdanie ====== | |
====== Prezentacja ====== | |
====== Materiały ====== | ====== Materiały ====== |
===== Dostęp do CVS HQeD ====== | ===== Dostęp do CVS HQeD ====== |
| |
==== CVS Access ==== | ==== CVS Access ==== |
The code in currently in the CVS at charon. | |
It has a restricted access. | |
One has to be in the //hades// group. | |
This includes the team working on tools and examples. | |
| |
To check out, use: | 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 CVSROOT=:ext:kinio@charon.ia.agh.edu.pl/mnt/cvs/cvs-hades |
export CVS_RSH=ssh | export CVS_RSH=ssh |
cvs co hqed | |
Put your user name instead of ''kinio''. | * 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 ==== | ==== CVS OnLine ==== |