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.

Prezentacja wyników pracy: prezentacja

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).

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ć.

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.

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 *').

11 wystąpień. Tu trzeba było zainicjować zmienną, ustawić na 0, NULL lub jakąś inną początkową wartość.

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.

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
  {
    ...
  }
}

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.

• 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.

Zbudowałem model termostatu na podstawie już dobrze opisanego sytemu: 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):

Wykonanie w HQEd (plik o ściągnięcia):

thermostat.zip

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):

Wykonanie w HQEd (plik o ściągnięcia):

atm.zip

• 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.

• 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).

• 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.

Uwagi: http://student.agh.edu.pl/~dudad/miw/

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

See 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!

The 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!