Parę pytań o USE CASE

0

Piszę USE CASE w którym klient operuje cały czas na aplikacji, na stronie. A to sobie coś dodaje,a to zmienia taka radosna działalność usera :D. Jako primary actor piszę Klienta bo tak nazwałam swojego usera. Czy nie powinnam gdzieś umieścić tej aplikacji jako aktora? Bo w sumie to aplikacja odpowiada tak jakby naszemu Userowi.

To są raczej USE CASY biznesowe niż systemowe.

Mam taki pomysł aby dać taki podpunkt: scieżka alternatywna dla wszystkich usecasów i tu rozważyć przypadek gdy jest problem z palikacją, nie ma połączenia z internetem etc.

Gdzie by go najlepiej umieścić?

Bardziej niecodzienne ścieżki alternatywne normalnie egzystują po ścieżce głównej każdego use casu.

Może by zrobić taki akapit "Własności wspólne dla wszystkich use casów i tu dać warunki początkowe i tą ścieżką alternatywną?

0
  1. Use Case to przypadek użycia systemu. System sam NIE MOŻE siebie używać, bo nie miałoby to sensu. Jak klient klika guzik a system odpowiada mu listą zakupów to przypadkiem użycia jest "Wyświetlenie listy zakupów", a mam wrażenie że u ciebie jest "Kliknięcie guzika" i nie wiesz gdzie dać tą "drugą stronę"...
  2. Generalnie ścieżki alternatywne, tak jak i zwykłe, umieszcza się w scenariuszach przypadków użycia.
0

A nie za mocno kombinujesz z tymi UC? To nie miejsce na "programowanie" i uogólnianie kodu. W kontekście danego UC masz osiąganie celu biznesowego i budowanie wartości biznesowej. Stąd błąd i brak możliwości osiągnięcia tego celu obsługujesz (generalnie) w ramach tego przypadku użycia.
W przypadkach użycia nie oczekuj obsługi "if'ów i switch/case'ów". Tam ma być scenariusz główny napisany "na hipisa" (świat jest piękny, wszystko działa, user czyta komunikaty i wie co robi) oraz ścieżki alternatywne jako wersje danego kroku jak coś pójdzie inaczej.
Stanowczo za nisko schodzisz w szczegóły techniczne z tym przypadkiem.
Nie, stanowczo nie należy rysować jako aktora samego systemu.

0

@Shalom Jeśli mam USE CASE, który coś usuwa na przykład zdjęcie to jeden z kroków może tak brzmieć? "Zdjęcie zostaje usunięte" ? Wcześniej, że klient wybiera klika, potwierdza etc....

Rok temu na jednym z przedmiotów wraz z kolegą napisaliśmy że system jest aktorem... Prowadzący zwrócił uwagę na kwestie które były subiektywne (nie wyglądało tak jak on sobie zażyczył, ale obiektywnie rzecz ujmując to była kwestia punktu widzenia) ale nie zwrócił uwagi na rzeczy istotne. Pomijając literówki bo mimo że wtedy myślałam że jak na 14 czy 15 stron jest pare literówek bo to nie komercyjne to nic się nie dzieje. To tak z tym miał rację dokumentacja nawet nie komercyjna nie powinna mieć literówek czy błędów ortograficznych - na to zwrócił uwagę i tu mu przyznaje racje.

Jeszcze jeden błąd który ja teraz widzę a nie został wymieniony (przez prowadzącego) to że mieliśmy tam śmietnik, biznesowe z systemowymi.

@Mokrowski Masz rację z tym porównaniem. Właśnie tak to widziałam jako coś co się powtarza i niepotrzebnie to pisać n razy no to co? no to funkcja... Teraz to widzę że to by źle wyglądało i wbrew pozorom NIE BYŁO SPÓJNE I CZYTELNE, a o to chodzi.

Ps Mam na początku listę USE CASE i odnośniki do nich. Słownictwo najlepiej dać między stroną tytułową a tymi Spisem? Tak sądzę...

0

@lightinside czyli masz przypadek użycia "Usuń zdjęcie" gdzie aktorem jest Użytkownik? Tak, mozesz mieć wtedy w scenariuszu punkt "zdjęcie zostaje usunięte".
System jako taki nie może być aktorem bo system sam siebie nie może użyć! Niemniej są sytuacje kiedy system "niby-sam" podejmuje jakąś akcję, ale zawsze istnieje zewnętrzy trigger. Na przykład czas. Może tak być że system co 24h cośtam wykonuje. Ale wtedy aktorem jest "Czas" a nie system. Może też być tak że jakiś zewnętrzny system powoduje wykonanie jakiejs akcji i wtedy znów aktorem jest "Zewnętrzny system".

1 użytkowników online, w tym zalogowanych: 0, gości: 1