🚀 go-pugleaf

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