🚀 go-pugleaf

On Fri, 23 Feb 2007 10:48:44 +0100, Dariusz Cieslak <cieslakd@xyz.invalid>  
wrote:

Ja nie odpowiem, ale chciałbym zapytać Ciebie :)

> Od jakiegoś czasu próbuję zaprząc język OCL (Object Constraint
> Language) do utrwalenia decyzji projektowych i wymagań dla tworzonego
> systemu. Korzystam z USE (UML-based Specification Environment,
> ...
Tzn., że nie ma już miejsca na refaktoring kodu?

> http://www.db.informatik.uni-bremen.de/projects/USE). Dzięki symulacji
> jest teoretycznie możliwa dynamiczna walidacja wyrażeń OCL podczas
> testowania (ale nie udało mi się jeszcze tego mechanizmu zintegrować z
> Pythonem).

Z tego co widzę w przykładach na tej stronie to wygląda jak zwykłe testy  
jednostkowe lub akceptacyjne tylko mniej wygodne. Czy się myle?

-- 
Piotr

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

> Ja nie odpowiem, ale chciałbym zapytać Ciebie :)
>
> > Od jakiegoś czasu próbuję zaprząc język OCL (Object Constraint
> > Language) do utrwalenia decyzji projektowych i wymagań dla
> > tworzonego systemu. Korzystam z USE (UML-based Specification
> > Environment,
>
> Tzn., że nie ma już miejsca na refaktoring kodu?

To są rzeczy niezależne od siebie. Refaktoryzację przeprowadza się w
istniejącym kodzie, specyfikacja jest dla kodu, który dopiero
powstanie.

> > http://www.db.informatik.uni-bremen.de/projects/USE). Dzięki
> > symulacji jest teoretycznie możliwa dynamiczna walidacja wyrażeń
> > OCL podczas testowania (ale nie udało mi się jeszcze tego
> > mechanizmu zintegrować z Pythonem).
> 
> Z tego co widzę w przykładach na tej stronie to wygląda jak zwykłe
> testy  jednostkowe lub akceptacyjne tylko mniej wygodne. Czy się
> myle?

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.

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

Dariusz Cieslak <cieslakd@xyz.invalid> writes:

> On 2007-03-16, Peri <email@server.net> wrote:
>
>> Ja nie odpowiem, ale chciałbym zapytać Ciebie :)
>>
>> > Od jakiegoś czasu próbuję zaprząc język OCL (Object Constraint
>> > Language) do utrwalenia decyzji projektowych i wymagań dla
>> > tworzonego systemu. Korzystam z USE (UML-based Specification
>> > Environment,
>>
>> Tzn., że nie ma już miejsca na refaktoring kodu?
>
> To są rzeczy niezależne od siebie. Refaktoryzację przeprowadza się
> w istniejącym kodzie, specyfikacja jest dla kodu, który dopiero
> powstanie.

Tak, ale zakres istotnych własności programu, które powinny zostać
zachowane, można określić właśnie na podstawie specyfikacji.

Warto zauważyć, że -- tak czy inaczej -- na potrzeby refaktoryzacji
jest zwykle tworzona tymczasowa, zawężona i uszczegółowiona
specyfikacja własności programu i że ta zawężona specyfikacja 
często nie zostaje skodyfikowana.

Co do samej refaktoryzacji, to -- według definicji Fowlera -- ma ona
kluczowy wpływ na strukturę programu, czyli musi mieć wpływ zarówno na
sam kod, jak i na projekt.

-- 
http://www.piotr.dembiński.prv.pl

On Mon, 19 Mar 2007 16:45:15 +0100, Dariusz Cieslak <cieslakd@xyz.invalid>  
wrote:

> On 2007-03-16, Peri <email@server.net> wrote:
>
>> Ja nie odpowiem, ale chciałbym zapytać Ciebie :)
>>
>> > Od jakiegoś czasu próbuję zaprząc język OCL (Object Constraint
>> > Language) do utrwalenia decyzji projektowych i wymagań dla
>> > tworzonego systemu. Korzystam z USE (UML-based Specification
>> > Environment,
>>
>> Tzn., że nie ma już miejsca na refaktoring kodu?
>
> 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?

>> > http://www.db.informatik.uni-bremen.de/projects/USE). Dzięki
>> > symulacji jest teoretycznie możliwa dynamiczna walidacja wyrażeń
>> > OCL podczas testowania (ale nie udało mi się jeszcze tego
>> > mechanizmu zintegrować z Pythonem).
>>
>> Z tego co widzę w przykładach na tej stronie to wygląda jak zwykłe
>> testy  jednostkowe lub akceptacyjne tylko mniej wygodne. Czy się
>> myle?
>
> 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ć?

-- 
Peri

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