(artykuł uzupełniony w 2019 r.)

Kolejna godna polecenia książka na rynku. Nie miałem czasu by wcześniej ją opisać ale w końcu udało się. Ale od początku, wrócimy do niej.

To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania „na papierze”. Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa  dyskusja z jednym z nich…). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: „czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da”.  W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: „ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów”. W zasadzie taki proces analizy i projektowania jest znany od lat jako Model Driven Architecture (MDA):

W czym problem? Nauczyć się pracować na modelach (abstrakcje systemu) a nie od razu na kodzie (a raczej poprzedzić kodowanie analizą i projektowaniem), nauczyć się wzorców projektowych i przede wszystkim obiektowego myślenia (paradygmatu) czyli analizy i projektowania. Wykonanie – implementacja na końcu a nie na początku (podobnie jak baza danych: w metodach obiektowych projektujemy utrwalanie na końcu!). Po drugie, niestety, nie raz słyszałem o dostawców: „nie mamy interesu w tym by projekt trwał krótko”, to jednak tylko argument za tym by nie zlecać im projektowania a tylko realizację.

MDA to trzy kluczowe etapy: CIM, PIM i PSM (szczegółowo opisałem w artykule o analizie). Interesuje mnie tu etap CIM (Computation Independent Model) i PIM (Platform Independent Model). Pierwszy to analiza biznesowa, nie ma ona nic wspólnego z oprogramowaniem, jej celem jest zrozumienie i udokumentowanie tego co robią przyszli użytkownicy systemu oraz wskazanie zakresu projektu dostarczenia oprogramowania. Drugi to PIM czyli opracowanie modelu logiki systemu bez względu na to w jakiej technologii powstanie, tu milczącym założeniem jest, że będzie to technologia obiektowa jednak język programowania może być dowolny.

Dużą zaletą tego podejścia jest to, że opracowanie modelu PIM jako Opisu Przedmiotu Zamówienia (OPZ) jest zgodne z PZP (Prawo Zamówień Publicznych) bo nie determinuje implementacji ale dokładnie opisuje oczekiwania. Uważam, że jest to najlepszy sposób tworzenia OPZ, bo nie pozostawia dowolności w kwestii funkcjonalności rozwiązania. Jaki mamy tu problem? Należy oddzielić projektowanie od realizacji  czyli mamy dwa etapy projektu zamiast jednego, dwóch wykonawców  (analiza i projektowanie oraz realizacja). Wady? Nie, korzyści bo wykonawca i tak musi jakiś projekt opracować, po drugie wycena na bazie projektu jest daleko mniej ryzykowna niż „wycena na bazie koncepcji”, zresztą skutki wszyscy obserwujemy  na rynku. Ale wracamy do tematu :).

Proces od analizy do projektu

Dwa pierwsze (CIM i PIM) to pierwsze etapy procesu powstawania oprogramowania: Analiza Biznesowa i jej produkt oraz projektowanie rozwiązania i jego produkt. Między nimi ma miejsce określenie zakresu, którego produktem jest model przypadków użycia (od 2015 roku w UML 2.5.x ten diagram jest modelem uzupełniającym)

Analiza biznesowa

Zgodnie z zaleceniami opracowujemy model CIM czyli tworzymy model tego „jak działa biznes”. Produktem tego etapu są modele procesów biznesowych (raczej [[BPMN]] niż [[UML]]). Muszą się one jednak cechować ustalonym poziomem abstrakcji (nie powinny być zbyt szczegółowe) i muszą uwzględniać rozdział kompetencji pracowników (ich nie komputeryzujemy) od ich specyficznych dla danej organizacji i procesu (te będą wspierane przez nowe oprogramowanie). Dobrą praktyką jest poprzedzanie tego etapu (uzupełnienie go) o analizę i model architektury korporacyjnej. To jest ostatni gwizdek na wprowadzanie ewentualnych ulepszeń zarządzania (reinżynieria procesów) w organizacji. Kolejny etap to

Opracowanie modelu przypadków użycia

Przypadki użycia, usługi systemu dla użytkowników, to celowe interakcje użytkownika z systemem. Ich cechą powinna być kompletność, bo przypadek użycia to realizacja  konkretnego celu biznesowego przez użytkownika. Poprawnie opracowany taki model pozwala mapować czynności z modelu procesów wprost na przypadki użycia (ale nie koniecznie jeden do jednego, przypadków użycia może być mniej, bo ta sama usługa systemu może posłużyć do realizacji kilku celów biznesowych, np. utworzenia danych jak i ich podglądu czy korekty, przykładem mogą być tak zwane [[CRUD]]’y) (kliknij tu by zobaczyć to na przykładzie narzędzia jakiego używam).

Każda czynność kandydująca na przypadek użycia powinna być opisana scenariuszem jej realizacji opisującym jak planujemy tę usługę zrealizować. Jest to tak zwany dialog użytkownik-system. Model przypadków użycia to także definicja zakresu projektu programistycznego (robimy to i  tylko to).

Opracowanie modelu dziedziny

Specyfikacja usług systemu (przypadki użycia)  to tak zwane wymagania funkcjonalne. Jest to stanowczo za mało by cokolwiek (w szczególności oprogramowanie) mogło powstać. Problem w tym, że samo stwierdzenie „system ma wciągać śmieci” nijak się nie ma do konstrukcji urządzenia jakim jest odkurzacz. Wymaganie pozafunkcjonalne, że „ma ich wciągać co najmniej 90%” także nic nie mówi o tym co na prawdę ma zostać wytworzone. Brakuje PROJEKTU.

Takim projektem jest model dziedziny, jednak nie jest to diagram klas na którym pokażemy, że np. istnieje związek logiczny brudnego dywanu z odkurzaczem! bo to jest tylko model pojęciowy (słownik pojęć). Model dziedziny systemu to model dziedzinowej logiki jaką należy odwzorować w oprogramowaniu. Owszem, jest to także Diagram klas UML, ale zupełnie inny niż tak zwany model konceptualny, który po prostu jest tylko słownikiem (i często jest mylony z modelem danych!).

Model dziedziny systemu to sedno analizy obiektowej.  To model całej logiki biznesowej aplikacji: klasy, ich operacje i atrybuty. Nie powinien to być na pewno tak zwany [[anemiczny model dziedziny]] a niestety takie właśnie są one w większości projektów jakie widuję.

Na tym etapie, modelowanie dziedziny systemu, powstają „suche” klasy, bez metod i atrybutów (tak, bez atrybutów!). W projektach złożonych systemów, powstanie modelu dziedzinowego powinno być poprzedzone powstaniem modelu komponentów (także stosowny diagram UML), który jest pośrednią warstwą abstrakcji w takich projektach. W takim przypadku początkowo operujemy praktycznie tylko na klasach abstrakcyjnych i ich interfejsach (są to interfejsy tych komponentów).

Projektowanie realizacji czyli testowanie modelu dziedziny

Mając model dziedziny, czyli listę specjalizowanych „wykonawców” konkretnych prac, możemy przystąpić do testów scenariuszy przypadków użycia. Takim testem jest próba zrealizowania scenariusza przypadku użycia z pomocą obiektów modelu dziedziny. Na tym etapie powstaje diagram sekwencji (lub sterowania interakcją, przepływu interakcji) dla każdego przypadku użycia. Dobrą praktyką jest stosowanie tu diagramów przepływu interakcji. Służą one do modelowanie nietrywialnych przypadków użycia, przepływu scenariuszy alternatywnych, ekranów itp.

W trakcie tworzenia diagramu sekwencji projektowane są operacje klas (metody to ich realizacje). Diagram sekwencji opisuje dialog pomiędzy obiektami prowadzący do zrealizowania zadania, jakim jest cel przypadku użycia (jego stan końcowy). Dialog taki to nic innego jak wywołania operacji obiektów przez inne obiekty (lub własnych). Po opracowaniu diagramu sekwencji obiekty, które brały w niej udział „wzbogacą” się w projekcie o swoje operacje. Na tym etapie może się okazać, że pewne obiekty zmieniają swoje stany. Dla ich klas projektujemy diagramy maszyny stanowej. Jeżeli okaże się, że jakiś obiekt wykonuje nietrywialne zadania (obliczeniowe, złożony proces itp.), jego operację, która za to odpowiada, dokumentujemy z pomocą np. diagramu czynności – taki algorytm to Metoda danej Operacji.  Za każdym razem sprawdzamy zgodność z oczekiwaniami użytkownika i uzupełniamy klasy o niezbędne atrybuty, w szczególności, jeżeli reprezentują one dokumenty czy formularze.

Projekt wykonany

Po wykonaniu powyższego, otrzymamy kompletny model aplikacji w notacji UML. Będzie to właśnie model PIM. Wszelkie niejasności powinny zostać wyjaśnione. Pozostaje realizacja, model PSM, czyli opakowanie projektu  „technikaliami” (w tym realizacja wymagań pozafunkcjonalych) czyli tym co dają nam np. frameworki MVC i podobne. Oczywiście nie jest to „trywialny problem”, ale w takim projekcie developer rozwiązuje problemy jakości systemu a nie logiki biznesowej systemu (podobnie jak inżynier budowlany, który ma postawić mocny i bezpieczny dom, bo jego funkcjonalność to problem mieszkańca i zadanie projektanta architekta).

Poniżej produkty takiej analizy i projektowania w postaci diagramów (modeli), pierwszy to BPMN, pozostałe UML:

 Aby zobaczyć jak to zrobić pakietem Agilian obejrzyj Tutorial pakietu Visual-Paradigm Agilian. 

A teraz lektura Craig’a Larman’a

Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman’a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD ([[Joint Application Development]]), jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.

To jest właśnie problem nazywany „użytkownik nie wie czego chce”. Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman’a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.

Larman’s UML Process

Use Cases	Define user interaction with the system. Underline nouns to identify concepts in the problem domain.
Conceptual Model	Use the underlined nouns from the use cases to create the concepts in the conceptual model. Some of the nouns, if they identify simple data types, are used to create attributes of these concepts. Create associations between the concepts.
System Sequence Diagram	Create system sequence diagrams for each use case scenario. Each sequence event in the diagram corresponds to a user interaction with the system specified by the expanded use case.
System Contracts	Specify post-conditions for each system event in the system sequence diagrams. Use the conceptual model to identify objects created, associations formed, and attributes modified.
Collaboration Diagram	Create a collaboration (or sequence) diagram for each system event in the system sequence diagrams. Assign responsibilities to classes in the conceptual model to fulfill the post-conditions in the contracts. Use associations from the conceptual model in conjunction with patterns (Expert, Creator) to assign responsibilities.
Class Diagram	Add methods and additional attributes which were discovered in the collaboration diagrams to the classes in the conceptual model.
Code	Create classes with their names, attributes and method signatures taken from the class diagram. For each method on a class, use the collaboration diagrams to find the sequence of messages generated when the method is called and create at least one line of code for each message.

(Based on Craig Larman’s Applying UML and Patterns -> Larman’s UML Process).

konwencje bardzo bliska powyższej (Larmana) opisano na stronach MSDN, tu wyciąg:

You can create several different views of the users’ requirements. Each view provides a particular type of information. When you create these views, it is best to move frequently from one to another. You can start from any view.

 

Diagram or document	What it describes in a requirements model	Section
Use case diagram	Who uses the system and what they do with it.	Describing how your system is used
Conceptual class diagram	Glossary of types that are used to describe the requirements; the types visible at the system’s interface.	Defining terms used to describe requirements
Activity diagram	Flow of work and information between activities performed by users and system or its parts.	Showing work flow between users and your system
Sequence diagram	Sequence of interactions between users and system or its parts. An alternative view to the activity diagram.	Showing interactions between users and your system
Additional documents or work items	Performance, security, usability and reliability criteria.	Describing quality of service requirements
Additional documents or work items	Constraints and rules not specific to a particular use case	Showing business rules

Notice that most of the diagram types can be used for other purposes. For an overview of diagram types, see Developing Models for Software Design. For basic information about drawing diagrams, seeHow to: Edit UML Models and Diagrams.

Na zakończenie

Powyżej opisany proces w całości można przećwiczyć wraz z poznaniem wymaganych diagramów UML  na warsztatach, które prowadzę.

Serdecznie zapraszam.