Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:miw:2009:miw09_hqed_audit_1 [2009/03/11 08:27] kinio |
pl:miw:2009:miw09_hqed_audit_1 [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 1: | Linia 1: | ||
| - | ====== 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 ===== | ||
| ==== Audyt kodu ==== | ==== Audyt kodu ==== | ||
| - | * Przetłumaczenie komentarzy w j. polskim na angielski. | + | * 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 ==== | ==== Testowanie HQed ==== | ||
| - | * Testowanie na gotowych przykładach: | + | * Zadanie polega na dprawdzeniu poprawności działania narzędzia. |
| - | * Termostat | + | * Testowanie powinno zostać zrealizowane na dwa sposoby: |
| - | * ATM | + | * Testowanie modelowania systemów od podstaw: |
| - | * ... | + | * Zamodelować od początku system Thermostat. |
| - | * Wykrycie nieprawidłowości podczas działania aplikacji np: | + | * Zamodelować od początku system ATM. |
| - | * Błędy podczas wykonywania różnych czynności: dodawanie elementów, usuwanie, edycja, ... | + | * Oraz inne dostępne. |
| - | * Wykrycie nieprawidłowości podczas weryfikacji tworzonego diagramu. | + | * 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 ==== | ||
