Czy da się wyspecyfikować wymagania na duże miasto? Poproście kilkanaście osób o wypisanie tego jakich funkcji oczekują od swojego miasta. Dostaniecie długą listę wyobrażeń zawierających przemieszane możliwości, ich jakość i wydajność. Otóż złożonego systemu nie da “sensownie” opisać z pomocą zwykłej listy oczekiwań. Będzie bardzo duża i zdezaktualizuje się toku trwania projektu, który planuje się raczej na lata niż niż tygodnie.
Książka zawiera opis szkieletu (framework) modelowania systemu informacyjnego opartego na czterech podstawowych obszarach: interfejs użytkownika, wejście i wyjście, kluczowej oraz wspomagającej logiki. Główny trzon szkieletu to wejście, przetwarzanie i wyjście, czyli “proces”. Autorzy budują system pojęciowy oparty na analizie od ogółu do szczegółu, abstrakcji, także obiektowym paradygmacie (autorzy operują związkami całość cześć, dziedziczeniem, związkiem usługobiorca – usługodawca). Złożony system dzielony jest na komponenty, całość jednak utrzymana w duchu biznesowych schematów blokowych.
W części opisującej wymagania, pojawia się bardzo ważne i przydatne założenie: wymagania są definiowane niezależnie od technologii. Druga ważna rzecz: wymagania to słownik (zestawienie) cech: możliwości systemu oraz – tych możliwości (funkcje) – cechy jakościowe i wydajnościowe. Szkielet (abstrakcja) systemu to trzy typy elementów (w książce trzy perspektywy): pamięć (entity model) czyli miejsca przechowywania informacji (repozytoria). Dalej procesy – tu, funkcje przetwarzające dane przechowywane w pamięci oraz sterownie (sprawowanie kontroli) nad całością.
Całość stanowi pewne przemieszanie analizy obiektowej (model abstrakcji od ogółu do szczegółu z dziedziczeniem, komponenty) i strukturalnej (modele danych i przepływu danych). Całość jest “opakowana” wymaganiami w rozumieniu słownika cech systemu.
Z opisu można wysnuć wniosek, że autorzy nie wprost (nie powołują się na ten model) nawiązują do obiektowego modelu BCE (opisałem go w artykule Wzorzec analityczny BCE). Korzystają z diagramu klas UML (jawnie o nim pisze) jako modelu pojęciowego. Jednak model procesów to już model DFD znany z analizy strukturalnej (De Marco). W obszarze definiowania procesów (w tej książce funkcje przetwarzające) przywołują także tablice decyzyjne (tablice decyzyjne).
Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną, zorientowaną na modele, koncepcję analizy i modelowania systemów biznesowych. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że nadal kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny. Autorzy przywołują metody obiektowe jako “szeroko obecnie reklamowane”, jednak mam wrażenie, że nie mają przekonania do tego modelu, uznającego ścisły związek danych i procesów przetwarzania w postaci obiektów. Co ciekawe jednak widzą zalety tego na “wyższych poziomach abstrakcji”, a tak się składa, że obiektowy paradygmat zakłada implementację właśnie tej abstrakcji – obiektowego modelu – w takiej postaci jaka powstaje na etapie analizy i projektowania (modelowania) systemu (przeczytaj artykuł o DDD).
Dalsza część książki to opis procesu wytwarzania aplikacji co tu pominę, także dlatego, że nie jest moim celem streszczanie tu tej książki. Opisałem ją bo (pomijając strukturalnie zorientowaną metodę analizy i projektowania) bardzo dobrze opisuje wartość dodaną samego procesu analizy opartej na modelowaniu. Porządkuje to wiedzą o systemie, modele stanowią też dokumentację systemu, są “mapowane” na wymagania.
Na koniec warto podkreślić jedną rzecz: analiza i specyfikowanie wymagań, zakładając abstrahowanie wymagań od technologii, doskonale nadaje się do projektów zakładających zakup gotowego oprogramowania. Autor nadmienia na początku, iż zakładanie że będzie to od razu jeden monolityczny system, że taki jest lepszy, jest mocno naciągane. Nawiązując do metafory z budowaniem miasta: powstaje ono w czasie, będzie ono raczej złożeniem komponentów ([[COTS]]) niż monolitem.
Trzeba tę mieć jednak świadomość tego, że książkę pierwszy raz wydano w 2000 roku, jej napisanie mogło trwać ok. roku, może dwóch, a to znaczy, że opisuje ona doświadczenia autorów z lat 80 i 90 tych (czego autorzy nie ukrywają). To były czasy, gdy metody obiektowe raczkowały a strukturalne przeżywały jeszcze szczyty popularności.
Co ciekawe autorzy, w dodatku na końcu książki, przyznają, że model zorientowany obiektowo jest bardzo dobrą abstrakcją systemu, jednak uznają, że na potrzeby implementacji ważny jest model strukturalny. Myślę, że to efekt przyzwyczajenia autorów do traktowania wymagań jako przepisu na pisanie kodu programu, pisanie metodami i narzędziami strukturalnymi…
Tak więc czytając takie książki, nadal popularne, nie zapominajmy o tym z jakiej epoki się wywodzą. Nie zapominajmy, że metody strukturalne to droga do monolitycznych systemów, których “zwinność” jest porównywalna raczej do wielkiego trawlera przetwórni na Bałtyku, a dzisiaj są potrzebne małe, szybkie, dedykowane kutry rybackie, które w można bardzo w ilości i specjalizacji, łatwo dobrać do panujących warunków na rynku i zmieniać w razie potrzeby.
Tytuł: Process for System Architecture and Requirements Engineering
Autor: Derek Hatley, Peter Hruschka, Imtiaz Pirbhai0
Wyd.: Published August 2nd 2013 by Addison-Wesley Professional (Goodreads | Process for System Architecture and Requirements Engineering Dorset House eBooks by Derek Hatley ? Reviews, Discussion, Bookclubs, Lists).
