Narzędzia oceny i utrzymywania jakości kodu
Ostatnia modyfikacja: 2005.11.03
opis
w USOSWebie
JML HomePage
Rozkład jazdy:
27.10 Zadanie wstępne (pierwsza analiza)
03.11 Napisać/zrozumieć/przerobić parser/pretty-printer dla Javy i JMLa
24.11 Raport - I wersja (analiza, postawienie problemu, bibliografia)
05.01 Raport - II wersja (j.w + opis narzędzia/rozwiązania)
02.02 Raport - III wersja (całość)
Raport można pisać po polsku, ale lepiej po angielsku, ma mieć do 10
stron.
Skala ocen oczywista: jest 5 rzeczy do zrobienia, za sensowne zrobienie
kazdej rzeczy 1 punkt. Suma punktow, to ocena koncowa :)
Kierownik zespołu ma uprawnienia jak na ZPP (może dowolnie dzielić
łączna ocenę pomiędzy członków zespołu).
Zaczątki bibliografii
1. Funkcyjność struktur danych.
Mark Zander, Functional
Programming in Java
Abhijit Belapurkar, Functional
programming in the Java language
Martin Odersky and Philip Wadler, Pizza
into Java: Translating theory into practice
2. Propagacja adnotacji dotyczących null-i.
Jif: Java + information flow
3. Odwołania między pakietami.
Corwin, Bacon, Grove, Murthy MJ: A
Rational Module System for Java and its Applications
Zadanie wstępne
Zadanie wstępne polega na ręcznym zrealizowaniu zadania całościowego na
przykładzie Passwords, przykładowego
programiku na ok. 2000 wierszy kodu. Przy tej okazji należy zastanowić
się nad automatyzacją tego procesu.
1. Funkcyjność struktur danych.
Sprawdzić, które str. danych w Passwords sa funkcyjne i/lub rozpatrzeć
kilka używanych klas z biblioteki Javy i sprawdzić, które są funkcyjne.
Co to właściwie znaczy, że str. danych jest funkcyjna i jak tę własność
można by sprawdać automatycznie ?
Co dokładnie oznacza istniejąca w JMLu anotacja /*@ pure @*/. Czy ona
jest wystarczająco dobra, czy trzeba wymyśleć własną?
2. Propagacja adnotacji dotyczących null-i.
Obadnotować ręcznie Passwords anotacjami /*@ not-null @*/ żeby ESC/Java2
http://secure.ucd.ie/products/opensource/ESCJava2/
nie wykazywało żadnych warningów związanych z nullami.
Jak można propagować tę informację po kodzie ?
3. Odwołania między pakietami.
Wstepnie zróbmy to na metodach, a nie na pakietach:
Na poziomie specyfikacji JML stworzyc "wirtualny" licznik (zmienna
"ghost") odwiedzin metod w jakiejs klasie z Passwords lub biblioteki
standartowej, ktory bedzie sie aktualizowal po kazdym wywolaniu metody.
Dzieki temu bedzie mozna mowic "w metodzie A licznik metody B nie
zmienil sie", czyli z kodu A nie da się (nawet pośrednio) wywolac
metody B.
Pomyslec o wbudowaniu tego licznika w JMLa.