OCeeL, teoretyczna teoria, czy praktyczna praktyka?

Zupełnie niespodziewanie przeprowadziłem dzisiaj ponad godzinną rozmowę ze studentem podejmującym decyzję o temacie pracy magisterskiej. Pytanie, z jakim zadzwonił, można streścić jednym zdaniem Czy OCL to już odległa historia, czy coś, czym warto się jeszcze zająć? Ponieważ dziś sobota, więc nie spodziewałem się telefonu w takiej sprawie, ale doszedłszy do siebie, już chciałem odpowiedzieć, że jak to historia? , ale powstrzymałem się i zapytałem a skąd pytanie? Odpowiedź była do przewidzenia – wszyscy mówią, że to czysta teoria i tak nikt nie pracuje.

To jak się pracuje?

Takim pytaniem postanowiłem podrążyć temat. I usłyszałem, że po pierwsze, OCL to już programowanie, po drugie, bez sensu jest dokumentować każdą linijkę kodu, i po trzecie, dlaczego analityk ma narzucać programiście, co ma robić.

OCL to już programowanie

Tak może powiedzieć tylko ktoś, kto nie ma pojęcia, czym jest OCL. Wytłumaczywszy studentowi, że OCL ma się tak do programowania, jak wzór w Wordzie do zapisów w silniku reguł biznesowych, usłyszałem – o dziwo – odpowiedź tak mi się wydawało.

Dokumentowanie a analiza

Na temat tego typu sformułowań można byłoby książkę napisać. Analiza to nie dokumentowanie! Analiza to proces tworzenia koncepcji rozwiązania. To co pozostaje po wykonanej analizie, można nazwać dokumentacją, ale jest to poniekąd efekt uboczny a nie cel. Tutaj student poprosił o wyjaśnienia, ale na koniec stwierdził, że rozumie (a dokładniej, zakminił).

Wpływ na programistę

Dlaczego analityk ma narzucać programiście, co ma robić? Hmmm…dlatego, że taka jego rola. Odpowiedzialnością analityka jest doprowadzenie do powstania koncepcji rozwiązania. W tym celu musi komunikować się z szeroko pojętym zestawem interesariuszy. W ich skład wchodzi zarówno tak zwana strona biznesowa jak i technologiczna, z programistami włącznie. Nie zmienia to faktu, że to analityk jest odpowiedzialny za stworzenie koncepcji. Ta koncepcja jest następnie przekazywana do zaprogramowania. Bez narzucania metod, ale z narzuceniem celu.

Ale przecież programista może stwierdzić, że można to zrobić lepiej! Oczywiście, że może. Ale to analityk powinien finalnie potwierdzić koncepcję. Zdanie programisty, to zdanie jednego z interesariuszy. Analityk musi uwzględnić zdanie wszystkich, którzy mają wpływ. I dokonywać korekt każdoroazowo, gdy taka konieczność nastąpi. Czyli do samego końca procesu produkcyjnego.

Ten temat zajął nam najwięcej czasu. Mam jednakże wrażenie, że rozmówca ostatecznie zrozumiał znaczenie OCL w całym procesie wytwórczym. Zresztą, nie tylko OCL. 

Ale dlaczego warto pisać o takiej rozmowie?

Kto poddał w wątpliwość?

To jest powód powstania niniejszego wpisu. Wątpliwość bowiem podniósł opiekun przyszłej pracy. Pracownik naukowy. Osoba, która powinna rozumieć. Poszerzać horyzonty studentów. Inspirować. Nie poddawać się modom. 

To był jakiś dzban (tak się chyba teraz mówi o osobach, które nie w pełni rozumieją, co mówią), pomyślałem. Zaproponowałem, aby student jeszcze raz porozmawiał z opiekunem i wyjaśnił powody dla których chciałby się zająć OCeeLem.

Niesmak pozostał. A wraz z nim pytanie dokąd zmierza świat naukowy?


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.