Jak określić, co należy dodać do diagramów przypadków użycia? 1 dla każdego przycisku/formularza? Czy należy uwzględnić rzeczy takie jak sortowanie i wyszukiwanie? Czy są na przykład pod "pozycjami listy"? Chociaż wydaje się, że lista przedmiotów wydaje się zrozumiała?Szczegółowość przypadków użycia. Czy należy włączyć sortowanie/wyszukiwanie?
Diagram przypadków użycia ma pomóc zdefiniować ważne zadania biznesowe na wysokim poziomie, a nie listę funkcji systemu. Na przykład system do użytku w obsłudze klienta może obejmować zadanie badawcze polegające na wyszukiwaniu informacji, aby pomóc komuś w wezwaniu pomocy technicznej.
Większość literatury opisuje Przypadki użycia jako punkt wyjścia do określenia, co system musi osiągnąć. Pokusa zawsze była tak pełna, jak to tylko możliwe; dodając coraz więcej szczegółów, aby zdefiniować przypadek użycia na poziom funkcjonalny (w sensie kodowym). Chociaż przydatne jest pełne zrozumienie wymagań, diagram przypadków użycia nie ma na celu zapewnienia takiego poziomu dokumentacji.
Jedną z rzeczy, która sprawia, że problem jest gorszy, jest składnia, której nigdy nie widziałem w projekcie roboczym. Nie jest tak, że warunki nie są użyteczne, wynika to z braku konsensusu co do tego, kiedy używać terminu dla danego przypadku użycia. Artefakty UML oczekują procesu, który jest bardziej skoncentrowany na języku biznesowym zamiast na języku implementacji - i przez to nie mam na myśli języka komputerowego. Tendencją niektórych było podejście do diagramów z legalistycznym podejściem i martwienie się o to, kiedy używać w powiązanych przypadkach użycia lub jak wyrazić obsługę błędów jako wyjątki od zdefiniowanej listy zadań procesowych.
Jeśli kiedykolwiek próbowałeś pracować na przykładzie Automated Teller Machine (ATM), będziesz wiedział co mam na myśli. W układzie słonecznym nauki UML, przykładem ATM jest czarna dziura, która wsysa cię w szczegóły. Unikaj używania go do zrozumienia UML lub analizy i projektowania zorientowanego obiektowo. Ma wiele problemów, typowych dla domen rzeczywistych, które odwracają uwagę od ogólnego zrozumienia, nawet jeśli byłoby to dobre, zaawansowane badanie.
Tak, kod zostanie ostatecznie wyprodukowany z artefaktów UML, ale to nie znaczy, że muszą być dyskutowane jak traktat w Senacie.
The OMG UML spec mówi:
Przypadki użycia są środkiem do określania wymaganych zwyczaje systemu. Zwykle są one używane do przechwytywania wymagań systemu, czyli tego, co system ma robić. Kluczowymi koncepcjami związanymi z przypadkami użycia są aktorzy, przypadki użycia i temat. Przedmiotem jest rozważany system, do którego mają zastosowanie przypadki użycia. Użytkownicy i wszelkie inne systemy, które mogą wchodzić w interakcję z podmiotem, są reprezentowani jako aktorzy. Aktorzy zawsze modelują jednostki, które są poza systemem.
Wymagane zachowanie obiektu jest określone przez jeden lub więcej przypadków użycia, które są zdefiniowane zgodnie z potrzebami aktorów. Ściśle mówiąc, termin "przypadek użycia" odnosi się do typu przypadku użycia. Wystąpienie przypadku użycia odnosi się do pojawienia się nowego zachowania, które jest zgodne z odpowiednim typem przypadku użycia. Takie przypadki są często opisywane przez specyfikacje interakcji.
Aktor określa rolę odgrywaną przez użytkownika lub inny system, który współdziała z tematem. (Termin „rola” jest używany nieformalnie tutaj i niekoniecznie implikuje techniczną definicję tego pojęcia można znaleźć gdzie indziej w niniejszej specyfikacji.)
Teraz większość ludzi zgodzi się, że interakcje poziomie biznesowym i użytkownik są sweet spot , ale nie ma ograniczeń.Pomyśl o aktorach/rolach znajdujących się poza głównym systemem/systemami, na których się skupiasz. Ale w jednym widoku system może być aktorem, ale w innym implementatorze innych przypadków użycia.
Normalna ziarnistość użycia to cel scenariusza, a nie krok. –