Tym razem o modelu, a konkretnie komponencie Model, w architekturze systemu. W poprzednim artykule pod koniec napisałem: Czy musimy znać opis wszelkich zachowań systemu? Nie, i z reguły nie jesteśmy w stanie ich wszystkich opisać, zresztą nie ma takiej potrzeby. Jednak mechanizm (wiedza jak coś działa) pozwala nam wyjaśnić zaobserwowane zachowania oraz przewidzieć przyszłe (dokładnie tak jak teoria naukowa). Niewątpliwie młotek został stworzony do wbijania gwoździ i ten jego ?przypadek użycia? był przyczyną (wymaganie) jego skonstruowania, jednak wiedząc jak jest skonstruowany i znając prawa fizyki, jesteśmy w stanie przewidzieć praktycznie wszelkie…
zły model to złe oprogramowanie....
Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią.
Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".
