Temat: Czy Use Case...

przenoszę pewne pytanie :)

Jarku, moglbys nieco rozwinac punkt nt. use case'ow? Czy jest to standardowe podejscie? (chodzi mi o: Przypadki użycia jako lista wymagań funkcjonalnych + Scenariusze)

kwestia metodyki bo sam UML daje "całe spektrum narzędzi" dla Use Case, ja osobiście jestem zwolennikiem metod bazujących na kilku prostych diagramach zamiast "jednego wypasionego" dlatego na diagramach Use Case nie zalecam używania bez specjalnego uzasadnienia takich elementów jak Extend, Include czy w szczególności dziedziczenia bo to prowadzi do modelowania struktury programu z pomocą tego diagramu a do tego służy diagram klasa lub pakietów.

Osobiście uważam próby modelowania całego systemu tylko z pomocą diagramów Use Case są złą drogę, ten diagram służy wyłącznie do uporządkowanie wiedzy o zakresie systemu - funkcjonalności.

Osobiście bliższa mi jest metodyka ICONIX jednak ja nie używam diagramów Robustnes, zastępuje to kontekstem biznesowym robiąc modele procesów biznesowych na których oznaczam czynności wchodzące w zakres projektu, mapowane właśnie na Use Caase.

Można by powiedzieć, że z perspektywy użytkownika mamy Use Case + scenariusze (opisowe lub tabela), z perspektywy projektowania mamy rozszerzenie:
- model dziedziny systemu (diagram klas)
- sekwencje dla każdego Use Case (które klasy co robią)
- stany klas stanowych
-jeżeli jest taka potrzeba, diagram czynności do zobrazowania algorytmów metod
- podział na podsystemy - diagram pakietów

jednak są różne metodyki, jakich i kiedy używacie?Jarek Żeliński edytował(a) ten post dnia 14.10.10 o godzinie 07:04

Temat: Czy Use Case...

W kwestii przypadków użycia dyskutowaliśmy już niejednokrotnie.

Myślę, że najlepsze wskazówki w tym zakresie znaleźć można u Alistair'a Cockburn'a. Zacytuję fragment mojego artykułu:

Rozróżnienia pięć poziomów przypadków użycia szeregując od najwyższego do najniższego poziomu:
• wysokie podsumowanie (very high summary)
• podsumowanie (summary)
• cel użytkownika (user goal)
• podfunkcja (subfunction)
• zbyt niskie (too low)
Pierwsze dwa – zwykle używane są do pokazania kontekstu systemu lub podzielenia go na pomniejsze grupy funkcjonalne. Dwa najniższego poziomu służą do uszczegóławiania przepływów w obszarze danej funkcjonalności dlatego dla potrzeb szacowania oraz dokumentacji wymagań przypadki użycia powinny zostać określane jako cele użytkownika (user goal) wg klasyfikacji Cocburna.
Dla zweryfikowania czy przypadek użycia jest na odpowiednim poziomie klasyfikacji Cockburna –
poziomie celu użytkownika należy odpowiedzieć na dwa pytania:
• czy przypadek użytkownika realizuje cel biznesowy? - przypadki użycia powinny
dostarczać wartości biznesowe – im więcej razy scenariusz przypadku użycia przebiega
zgodnie ze schematem sukcesu tym większą wartość system tworzy
• Czy przypadek użytkownika opisuje kompletną interakcję w obrębie sesji? - dobrą weryfikacją jest określenie czy po wykonaniu scenariusza użytkownik systemu może realizować inne funkcje systemowe

Diagram przypadków służy do kilku rzeczy:
• określenie wymagań funkcjonalnych
• określenie punktów startowych dla poszczególnych wymagań funkcjonalnych
• określenie aktorów
• określenie dostępu do funkcjonalności systemu przez aktorów
Diagram taki oczywiście nie jest kompletny. Uzupełniamy go zawsze tabelką z podstawowymi informacjami o danym przypadku użycia. Na przykład taką:

Nazwa przypadku użycia: Add patient
Krótki opis: Dodawanie nowych pacjentów do systemu
Warunki początkowe: Spełnienie przypadku Browse patients, użytkownik posiada prawo do wykonywania operacji na danych pacjentów.
Zdarzenie inicjujące: Wybranie opcji dodaj pacjenta.
Przebieg:
1. Wybranie opcji dodania pacjenta
2. Rozszerzenie: getPatientData
3. Wpisanie danych pacjenta
4. Zatwierdzenie danych.
Przebieg alternatywny: Wpisanie nie poprawnych danych, powtórzenie
akcji, Wylogowanie, zamkniecie aplikacji.
Warunki końcowe: Powiększona lista pacjentów.
Extends: Browse patients

Warto zauważyć, że projektując wiele systemów znamy zakres technologii, który wykorzystywany będzie przy tworzeniu oprogramowania. Nie ma w związku z tym żadnego sensu projektowanie tak szczegółowych przypadków użycia jak dodawanie poszczególnych obiektów dla systemów webowych. Ze względu na rozwój frameworków tworzenie kodu potrzebnego do standardowej manipulacji danymi jest znacznie uproszczone. Dlatego w takim przypadku operacje CRUD (Create Retrieve, Update Delete) modelujemy jako jeden przypadek użycia dla danego obiektu. W zależności od skomplikowania i ilości obiektów zależnych kwalifikuje się poziom skomplikowania danego przypadku użycia lub interfejsy CRUD dla niektórych podobiektów modeluje osobno - szczególnie jeśli można nimi zarządzać niezależnie.

Oczywiście często konieczne jest uzupełnienie powyższych o macierze uprawnień - czasem wielowymiarowe, szczególnie jeśli modelujemy uprawnienia z dokładnością do instancji.

Temat: Czy Use Case...

no ja niestety jakoś nie kupuje Pana Cockbourna... dociera do mnie jedynie:
• cel użytkownika (user goal)

jak chce pokazać pod funkcje to wolę opisać sekwencją scenariusz dla danego UC co pokaże jakie klasy i co zrobią, tu od razu także wyjdzie (traktuje diagram sekwencji jako pierwszy proof-of-concept) czy dla UC wystarczy biblioteka widoku (np. a frameworka) czy trzeba zaprojektować klasę wykonawczą w modelu dziedziny dla tego UC (bo jego scenariusz np. stanowi specyfikę dziedziny).

Aczkolwiek wiem, że podejście Cockbourna jest dość popularne... dla mnie jest "pracochłonne" w sferze kontroli spójności i niesprzeczności....

Temat: Czy Use Case...

Osobiście preferuję takie podejście:
1. BPMN - jako sposób na poznanie i utrwalenie, dla przyszłych pokoleń ;), wiedzy o sposobie działania organizacji.
2. Na podstawie nr.1 wskazanie wymagań (punktów wsparcia użytkownika) przy użyciu UC.
3. Na podstawie nr.2 prowadzenie analizy systemowej preferuję sekwencje ponieważ w prosty sposób dostarczają bardzo wielu informacji.

Ad.2 Przy modelowaniu UC należy korzystać z relacji a to dlatego, że są one nie wymagające (mówią tylko co MUSI a co MOŻE być wykorzystane) pozwalają się zapoznać z działaniem systemu na wysokim poziomie abstrakcji. Opisy scenariuszy powinny być jak najbardziej biznesowe tak by klient mógł je zrozumieć i "przyklepać" jako poprawne wymagania.

Temat: Czy Use Case...

Wojciech Kłujszo:
Ad.2 Przy modelowaniu UC należy korzystać z relacji a to

jakich "relacji"? czy chodzi o relacje [aktor] <-> [przypadek użycia]?

Temat: Czy Use Case...

Jarek Żeliński:

Wojciech Kłujszo:
Ad.2 Przy modelowaniu UC należy korzystać z relacji a to

jakich "relacji"? czy chodzi o relacje [aktor] <-> [przypadek użycia]?

Przepraszam skróciłem...
Chodzi o relacje include i extend a czasami i dziedziczenie. Pozwalają one ZAPLANOWAĆ interakcję pomiędzy częściami systemu bez określania szczegółów. Mi osobiście daje to możliwość określenia złożoności systemu oraz określenia "pola rażenia" ewentualnych zmian w wymaganiach.
Natomiast powiązania użytkownik UC są zbędne, ale tylko dlatego, że role wynikają z BPMN. Tak jak wcześniej pisałem 1. BPMN -> 2. UC.

Jeżeli brakuje BPMNa to bardzo użyteczne jest modelowanie powiązań użytkownik UC w formie użytkownik1 -> UC -> użytkownik2 gdzie:
użytkownik1 - jest osobą odpowiedzialną za wykonanie pewnego zadania
UC - jest funkcjonalnością systemy umożliwiająca wykonanie tego "pewnego zadania"
użytkownik2 -> jest konsumentem wyników :)

Temat: Czy Use Case...

Wojciech Kłujszo:

Jarek Żeliński:

Wojciech Kłujszo:
Ad.2 Przy modelowaniu UC należy korzystać z relacji a to

jakich "relacji"? czy chodzi o relacje [aktor] <-> [przypadek użycia]?

Przepraszam skróciłem...
Chodzi o relacje include i extend a czasami i dziedziczenie. Pozwalają one ZAPLANOWAĆ interakcję pomiędzy częściami systemu bez określania szczegółów.

tu się rozchodzą nasze podejścia :), moim zdaniem wydzielanie poprzez include i include pewnych wspólnych (współdzielonych) części UC fałszuje obraz systemu bo to tylko fragmenty scenariuszy, jest to moim zdaniem jak by próba normalizacji (w sensie bazodanowym) powodująca utratę kontaktu. Nie ma nic złego w tym, że kawałek scenariusza powtarza się w kilku UC, jest to kandydat na osobną klasę z metodą obsługująca tę specjalizowaną.

Mi osobiście daje to możliwość określenia złożoności systemu oraz określenia "pola rażenia" ewentualnych zmian w wymaganiach.

moim zdaniem UC to nie jest dobre miejsce na opis architektury oprogramowania.

Natomiast powiązania użytkownik UC są zbędne, ale tylko dlatego, że role wynikają z BPMN. Tak jak wcześniej pisałem 1. BPMN -> 2. UC.

pamiętajmy, że diagram UC powinien być samowystarczalny wiec bez aktorów jak by jest "goły" troszkę :)

Jednak zapewne oba nasze, jednak nieco odmienne, podejścia zachowują w całości jakąś logikę :)

Temat: Czy Use Case...

Jarek Żeliński:

tu się rozchodzą nasze podejścia :), moim zdaniem wydzielanie poprzez include i include pewnych wspólnych (współdzielonych) części UC fałszuje obraz systemu bo to tylko fragmenty scenariuszy, jest to moim zdaniem jak by próba normalizacji (w sensie bazodanowym) powodująca utratę kontaktu. Nie ma nic złego w tym, że kawałek scenariusza powtarza się w kilku UC, jest to kandydat na osobną klasę z metodą obsługująca tę specjalizowaną.

:) zleży co rozumiemy pod pojęciem "wspólnych części" i dla kogo jest realizowany produkt. Załóżmy, że mamy do czynie z systemem, który bazuje do dokumentach a w treści tych dokumentów pojawiają się ludzie w różnych kontekstach (wnioskujący, wystawca faktury, zamawiający itp...) moim zdaniem warto wydzielić UC np. "Dodawanie nowego kontrahenta", który mógłby być wykorzystany w np. przy tworzeniu każdego dokumentu a dodatkowo w różnych innych miejscach gdzie istniej potrzeba powiązania kogoś z czymś.
Oczywiście nie należy wydzielać i pokazywać UC (typu funkcji systemowe) "Wyszukaj kontrahenta po NIP'ie" bo na to jest dużo miejsca w niższych warstwach analizy :).
Ale poważnie bym się zastanawiał nad wydzieleniem UC, który umożliwiał wyszukanie kontrahenta po wielu parametrach a następnie wybrania go do realizacji innych UC. Wówczas zamiast postępowania wybierz kontrahenta -> wskaż co chcesz z nim zrobić -> zrób to, byłoby wskaż co chcesz zrobić -> wybierz kontrahenta. Może z opisu różnica jest kosmetyczna natomiast funkcjonalnie to przepaść :)

Mi osobiście daje to możliwość określenia złożoności systemu oraz określenia "pola rażenia" ewentualnych zmian w wymaganiach.

moim zdaniem UC to nie jest dobre miejsce na opis architektury oprogramowania.

Zamiast "opis architektury" ja widzę wskaż powiązania i części wspólne.

Natomiast powiązania użytkownik UC są zbędne, ale tylko dlatego, że role wynikają z BPMN. Tak jak wcześniej pisałem 1. BPMN -> 2. UC.

pamiętajmy, że diagram UC powinien być samowystarczalny wiec bez aktorów jak by jest "goły" troszkę :)

Też mi się tak na początku wydawało :). Jednak proszę zwrócić uwagę, że wykorzystanie "przypadków" w mojej propozycji pozwala przesunąć ich treść bliżej opisu systemu niż opisu biznesu. Pamiętajmy, że biznes jest na BPMN.

Jednak zapewne oba nasze, jednak nieco odmienne, podejścia zachowują w całości jakąś logikę :)

LOGIKA PONAD WSZYSTKO :)

Temat: Czy Use Case...

Wojciech Kłujszo:
:) zleży co rozumiemy pod pojęciem "wspólnych części" i dla kogo jest realizowany produkt. Załóżmy, że mamy do czynie z systemem, który bazuje do dokumentach a w treści tych dokumentów pojawiają się ludzie w różnych kontekstach (wnioskujący, wystawca faktury, zamawiający itp...) moim zdaniem warto wydzielić UC np. "Dodawanie nowego kontrahenta", który mógłby być wykorzystany w np. przy tworzeniu każdego dokumentu a dodatkowo w różnych innych miejscach gdzie istniej potrzeba powiązania kogoś z czymś.

takie sytuacje traktuję jako dwa osobne i niezależne UC: dodawanie kontrahenta. Na diagramie UC nie kojarzę Dodawania kontrahenta i np. Wystawienie Faktury bo ewentualne ich "współwystępowanie" zależy od kontekstu pracy człowieka i nie jest obowiązkowe, i tak są to zresztą dwie osobne pozycje w menu systemu.

Ale poważnie bym się zastanawiał nad wydzieleniem UC, który umożliwiał wyszukanie kontrahenta po wielu parametrach a następnie wybrania go do realizacji innych UC. Wówczas zamiast postępowania wybierz kontrahenta -> wskaż co chcesz z nim zrobić -> zrób to, byłoby wskaż co chcesz zrobić -> wybierz kontrahenta. Może z opisu różnica jest kosmetyczna natomiast funkcjonalnie to przepaść :)

w moich oczach naturalne jest pierwsze, drugie nie wnosi nic nowego... poza zmianą kolejności pracy....:)

moim zdaniem UC to nie jest dobre miejsce na opis architektury oprogramowania.

Zamiast "opis architektury" ja widzę wskaż powiązania i części wspólne.

w moich oczach powiązania te tworzy człowiek w kontekście pracy, nie da się wskazać wszystkich możliwych (a nawet jeśli tak to po co?)

Też mi się tak na początku wydawało :). Jednak proszę zwrócić uwagę, że wykorzystanie "przypadków" w mojej propozycji pozwala przesunąć ich treść bliżej opisu systemu niż opisu biznesu. Pamiętajmy, że biznes jest na BPMN.

ale UC określa jako osobny dokument zakres projektu a to fundamentalny element :)

Jednak zapewne oba nasze, jednak nieco odmienne, podejścia zachowują w całości jakąś logikę :)

LOGIKA PONAD WSZYSTKO :)

ano i tu chyba nadal jest OK :) a są jedynie "dwie szkoły" :)