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.

Jednym z ważnych celów projektu było statyczne zbudowanie aplikacji z Qt4. Powody są dwa:

• 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ć Qt4 statycznie (w wersjach: 4.2.3, 4.3.0, 4.5.2), także program dał się skompilować (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ł nawet do 13h (dla wersji 4.5.2, pełna kompilacja z przykładami).

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.

Tych ostrzeżeń kompilator wykrył aż 82, poprawa kodu sprowadza się do zmiany:

z: void fun(..., int param, ...)
do: 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.

Kompilator wskazał 12 linijek z tym błędem, jednak sprowadzało się do zmiany w 2 linijkach:

było: char* cFormats[] = {"...", "...", "...", "..."} 
teraz 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 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ść: dla:

było: ((s && r)) || q && p 
powinno być: (s && r) || (q && p) 

i

jest: t && (s && r) || (q && p) 
powinno: (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.

To dwa najważniejsze ostrzeżenia, które okazały się błędami logicznymi w programie.

1. Niepotrzebny średnik

Pierwsze dotyczyło niepotrzebnego średnika

  
było:
if(...);
{
  ...
}
zamiast:
if(..)
{
  ...
}

1. brak klamr

if(…)

if(...)
{
  ...
}
else
{
  ...
}

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 plikach generowanych automatycznie z plików QTDesignera. Po edycji tych plików, problem zgodności został rozwiązany.

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