🚀 go-pugleaf

On 2007-03-20, Peri <email@server.net> wrote:

> > To są rzeczy niezależne od siebie. Refaktoryzację przeprowadza się w
> > istniejącym kodzie, specyfikacja jest dla kodu, który dopiero
> > powstanie.
>
>  Ok. To oczywiste. Czyli co z takim OCL'em dalej robimy? Programiści mają  
>  pisać "pod niego"? A jak podczas implementacji okaże się że specyfikacja  
>  jest niedobra (inne nazwy metod, inne klasy - pewnie tak jest w 90%  
>  przypadków) to trzeba wracać do tego OCL'a i poprawiać, aby był zgodny z  
>  kodem?

W mojej firmie OCL jest tworzony wraz z rozwojem systemu dla
poszczególnych zadań. W pliku specyfikacji zawieram opis fragmentu
istniejącego systemu ważnego dla tworzonej funkcjonalności (np. trzy
tabele z niektórymi atrybutami i kluczowe klasy) wraz z projektem
nowych struktur / metod. OCL po implementacji jest "wyrzucany".
Dzięki temu osoba pracująca na danycm use casem ma nieduży fragment
systemu do poznania za każdym razem (nie musi obejmować całości). To
jest typowy proces przyrostowy.

Nie ma jednego głównego projektu OCL, wygodniej jest nam się
posługiwać UML/OCL jako szkicownikiem na wysokim poziomie abstrakcji.

> > Nie, to jest metoda na naszkicowanie funkcjonalności. Można opisać
> > decyzje projektowe i założenia systemu w bardzo kompaktowy sposób
> > nieosiągalny dla zwykłego zapisu np. w Javie czy SQL-u. Dzięki
> > temu specyfikacje są zwięzłe.
>
> Zastanawiam się tylko co z tym się dalej robi w trakcie tworzenia
> aplikacji. Zgadzam się, że to może kompaktowe, ale co gdy kod, który
> powstanie, wygląda inaczej niż początkowa specyfikacja? Skaczemy
> cały czas między kodem, a OCL'em, aby były zgodne i ten OCL mógł
> cokolwiek zwalidować?

Aktualnie OCL nie jest używany przez nas bezpośrednio do automatycznej
walidacji tworzonej funkcjonalności. Istnieją jednak metody, które
pozwalają sprawdzać poprawność działania systemu w trakcie wykonania
względem OCL-a, ale jakość takiego sprawdzenia zależy od jakości
pokrycia kodu testami:

  http://www.db.informatik.uni-bremen.de/publications/Richters_2003_UMLWS_AOD.ps

Ponieważ nie walidujemy OCL-a względem kodu (jak nadmieniłem powyżej)
cząstkowe specyfikacje poszczególnych przyrostów idą na "śmietnik" po
utworzeniu zadanej funkcjonalności.

-- 
Dariusz Cieslak
http://aplikacja.info - systemy informatyczne na zamówienie