Macierz CRUD w EA

Dla lepszego zrozumienia artykułu najpierw przypomnijmy sobie czym jest CRUD? Według Wikipedii są to cztery podstawowe funkcje w aplikacjach korzystających z pamięci trwałej, które umożliwiają zarządzanie nią. Skrót CRUD pochodzi od angielskich terminów: Create, Read, Update oraz Delete (Utwórz, Odczytaj, Aktualizuj oraz Usuń). Skrót ten może być stosowany w odniesieniu do interfejsu użytkownika większości aplikacji, które zazwyczaj pozwalają użytkownikowi na:

• utworzenie lub dodanie nowych informacji (create),
• odczytanie lub wyświetlenie istniejących informacji (read),
• modyfikowanie lub edycję istniejących informacji (udpate),
• usuwanie istniejących informacji (delete).

Mapowanie przypadku użycia

Opracowanie modelu użycia ma na celu udokumentowanie w fazie analizy szczegółowych wymagań dotyczących funkcjonalności budowanego rozwiązania. W tym celu definiowani są aktorzy, którzy wchodzą w interakcję z systemem oraz przypadki użycia, które opisują wykorzystywaną przez nich funkcjonalność.

Jednakże analiza systemów informatycznych oprócz modelu funkcjonalnego obejmuje również inne obszary, takie jak:

• zarządzanie wymaganiami,
• modelowanie procesów biznesowych,
• modelowanie danych (logiczny model danych / model domeny),
• modelowanie interfejsu użytkownika. 

Ponadto analiza nie może istnieć w oderwaniu od innych zadań projektowych, takich jak:

• zarządzanie zakresem projektu,
• zarządzanie ryzykiem,
• zarządzanie problemami,
• zarządzanie zmianą,
• projektowanie,
• implementacja,
• testy.

Częstą praktyką jest chociażby opracowywanie scenariuszy i przypadków testowych przez analityków, które są wykorzystywane przez testerów. Dzieje się tak, gdyż przypadki testowe bazują w głównej mierze na przypadkach użycia, a analityk zna je najlepiej.

Zatem, wskazane jest stworzenie i utrzymywanie określonych powiązań elementów modelu użycia z elementami innych obszarów.

Jak przenieść scenariusz do innego przypadku użycia?

W trakcie pracy nad modelem użycia często dochodzi do sytuacji, w której analityk dochodzi do wniosku, że określony scenariusz należy przenieść z jednego przypadku użycia do innego. Może tak się zdarzyć, gdy okazuje się, że scenariusz alternatywny powinien rozwidlać się jeszcze bardziej, czyli mieć jeszcze dodatkowe alternatywy.
Czasem istnieje również potrzeba stworzenia nowego przypadku użycia podobnego do już istniejącego, na przykład, gdy tworzymy kolejną specjalizację przypadku generalizującego.
Gdyby scenariusze pisane były w zwykłym dokumencie MS Word, wówczas przeniesienie czy skopiowanie kroków scenariusza byłoby banalne. Jednak jeśli zdecydowaliśmy się na zastosowanie ustrukturalizowanych scenariuszy (Structured scenario), wówczas staje się to problematyczne.
Na szczęście istnieje rozwiązanie...

Raport dla przypadków użycia

Z modelem przypadków użycia tworzonym przez analityków w programie Enterprise Architect powinno się zapoznać wielu interesariuszy projektu. Spośród nich można wymienić projektantów, programistów, ale przede wszystkim przedstawicieli klienta, takich jak kluczowi użytkownicy, eksperci dziedzinowi i inni. W związku z tym, jeśli decydujemy się na opisywanie scenariuszy przypadków użycia w formie Structured Scenario w EA - powinniśmy również zadbać o ich stronę dokumentacyjną.
Profesjonalnie przygotowany raport poprawia czytelność i odbiór wyników pracy fazy analizy.

Scenariusze przypadków użycia w EA

W Sparx Enterprise Architect od wersji 8.0 wprowadzono możliwość opisywania scenariuszy przypadków użycia w formie ustrukturalizowanej (Structured Scenario). Wcześniej scenariusz można było tworzyć tylko w postaci sformatowanego tekstu zawierającego ewentualnie listy numerowane. Od dawna możliwe było również opracowanie scenariusza w formie Linked Document dołączonego do elementu typu Use Case.
W tym artykule chciałbym przybliżyć możliwości wykorzystania mechanizmu Structured Scenario. Ten sposób posiada wiele zalet i warto się z nimi zapoznać.

Logowanie - w kontekście przypadków użycia

Niedawno spotkałem się z pytaniem dotyczącym modelowania przypadków użycia i diagramów aktywności. Jeden z użytkowników zastanawiał się nad kwestią umieszczenia na diagramach aktywności wielokrotnie występujących czynności, takich jak logowanie. Jego problem dotyczył tego, czy operacja logowania użytkownika może być zdefiniowana w jednym miejscu w modelu i wstawiana wielokrotnie na różnych diagramach.

Kompletność modelu użycia

Model użycia (use case model) w wielkim skrócie służy do przedstawienia funkcjonalności rozwiązania poprzez zastosowanie przypadków użycia, aktorów oraz relacji pomiędzy nimi.
Z reguły początkujący analitycy dysponują przynajmniej teoretyczną wiedzą o regułach tworzenia modelu użycia. Wraz z każdym zrealizowanym projektem umiejętności te rosną, ale mimo to dostarczany model użycia często nie jest idealny. Warto zatem pokusić się o stworzenie krótkiego podsumowania w tym zakresie.

Warunki początkowe i końcowe przypadku użycia

W ostatnim czasie w biurze miała miejsce krótka dyskusja dotycząca warunków początkowych (pre-condition) i końcowych (post-condition) przypadku użycia. W wielu projektach w ciągu ostatnich lat opisywaliśmy przypadki użycia i w każdym przypadku wszyscy wiedzieli w jaki sposób formułować warunki początkowe i końcowe. Niespodziewanie dyskusja została wywołana przez analityków z jednej z firm z którą współpracujemy. Dyskusja ta świadczy o tym, że warto dokładnie opisać wszelkie zasady, które na pierwszy rzut oka wydają się oczywiste.