Studium przypadku diagram przypadki użycia

Witam,

Krótki opis systemu:

Operator na podstawie informacji odczytanej ze skanera odczytuje kod, następnie kod jest analizowany przez system, jeżeli jest ok system informuje operatora aby zeskanował kolejny kod, jeżeli wynik analizy jest negatywny system prosi o ponowne zeskanowanie pierwszego kodu. Taka sama jest procedura przy drugim kodzie. Następnie system odpytuje maszynę czy jest gotowa do pracy jeżeli nie jest to ponawia pytanie aż do uzyskania pozytywnej odpowiedzi, następnie system informuje operatora że może włączyć maszynę, operator włącza. Cykl się wykonuje, po zakończeniu cyklu system zapisuje zebrane kody + wynik procesu w bazie danych.... i tak w kółko....

Poniżej utworzyłem diagramy przypadku użycia. Który z rysunków jest bliższy opisanemu systemowi?? a może żaden ?? czekam na propozycje.

</image>

A gdzie Operator? I gdzie przypadki użycia?
Diagramy przypadków użycia służą do opisania funkcjonalności systemu, a nie tego, co i w jakiej kolejności on robi.

to jest właśnie kwestia zastanawiająca. Bo rola operatora wiąże się jedynie z fizycznym użyciem skanera, nie jest to operacja czy też funkcja która podlegać będzie oprogramowaniu. Zaetm jeżeli miałby się tu znaleźć operator to w jaki sposób mógłby być powiązany z diagramem??

Czy poniższy rysunek to właściwy sposób??

Może nie mam racji, ale dla mnie to nie jest diagram przypadków użycia.
Poczytaj może tutaj: http://www.erudis.pl/pl/node/93

Dlaczego dla ciebie nie jest to diagram przypadków użycia? Móglbyś rozwinąć swoje wątpliwości?

Zgodnie z tym co pisze w linku który podałeś nie widze nic co by mogło powyższy przykład dyskwalifikować. przedstawione jest co system robi.

W diagramie przypadków użycia dajesz przypadki użycia :/ czyli akcje wykonywane w systemie z punktu widzenia użytkowników systemu na nim pracującym. Nie opisujesz w nim co się dzieje w bebechach systemu. poza tym w przypadkach użycia sam diagram jest najmniej ważny i służy jedynie jako spis treści. Najważniejsze jest opis poszczególnych przypadków, w kŧórym zawierasz główny scenariusz sukcesu, warunki wstępne, rozszerzania, wyjątki itp.

Dobra rada:

Widzę że to już twój drugi diagram UML, kŧóry z UML'em na wspólnego tylko to że pojawiają się w nim te same strzałki i rysunki. Bo jeżeli chodzi o ich znaczenie to mają mało wspólnego z UML'em.

Dlatego też jeżeli modelujesz ten system tylko do siebie to go sobie rozrysuj tak żeby był on dla ciebie zrozumiały i nie patrz na UML'a. Jeżeli te diagramy będą musieli interpretować inny programiści i na prawdę potrzebujesz jakiś ustandaryzowanych diagramów żeby nie było nieścisłości to weź najpierw przeczytaj jakiś porządniejszy kurs o UML bo robienie takich diagramów co podesłałeś to bezsens.

Polecam:
http://merlin.pl/UML-w-kropelce-wersja-2-0_Martin-Fowler/browse/product/1,424062.html
jako dobry początek. Generalnie ta książka w pełni wystarczy jeżeli UML'em chcesz się posługiwać jako szkicami projektowymi.

Witam, dziękuję wam za cenne uwagi, ale to może ktoś mi pomoże rozwiać moje wątpliwości. Z poziomu użytkownika - operatora to tak naprawdę system ma umożliwyć mu uruchomienie maszyny, a reszt jest wykonywana przez system w taki sposób w jaki został zaprogramowany. Model który próbuje utworzyć nie jest podobny do serwisów www czy obsługi biblioteki gdzie klient jest kluczowy.

Robik napisał(a)

Model który próbuje utworzyć nie jest podobny do serwisów www czy obsługi biblioteki gdzie klient jest kluczowy.

Co ty nie powiesz?

Tak czy owak w przypadkach aktorem może być wyłącznie jakiś podmiot z poza systemu to w przypadkach użycia właśnie opisuje interakcje systemu z jego otoczeniem. Dlatego też aktor "system" jest bezsensowy. Aktor wyświetlacz jest także bezsensowny jeżeli wyświetlacz jest integralną częścią systemu lub jeżeli jest tylko interfejsem użytkownika.

Największym problemem jest tutaj to że nie znasz podstaw projektowania w UML'u. I póki nie poświęcisz czasu na opanowanie tych podstaw nie ma sensu dalej rozmawiać o twoich diagramach.

Robik napisał(a)

przedstawione jest co system robi.

Właśnie, że nie. Przedstawiłeś (a przynajmniej próbowałeś przedstawić) jak system to robi. Narysowałeś elementy systemu, jakieś przepływy danych, warunki pod jakimi one się odbywają, a zupełnie nie o to chodzi w tego typu diagramie. To, że użyłeś elips i ludzików z patyków, nie zrobi z tego rysunku diagramu przypadków użycia.
DPU jest związany bardziej z analizą dziedziny problemu, nie z projektowaniem wnętrza systemu.
Przykładowe przypadki użycia w różnych systemach to mogą być np.:

• zalogowanie do systemu;
• wprowadzenie danych pomiaru;
• sprawdzenie historii operacji bankowych;
• zarezerwowanie biletu, itd., itp.
  Czyli to wszystko, co robi użytkownik, a nie system.

Witam,

Zmieniłem nieco swoje wypociny.

Aktor operator, wchodzi w interakcje z systemem po przez skanowanie kodów i uruchamianie maszyny,

Administrator, loguje się do systemu, po zalogowaniu dokonuje zmian konfiguracyjnych lub używa modułu awaryjnego wprowadzania danych.

</image>

mam nadzieje że twoje przypadki użycia nie składają się tylko z diagramów bo jak już wcześniej napisałem przypadki użycia bez opisów słownych są nic nie warte.

oczywiście każdy przypadek jest opisany odrębnym scenariuszem.

Cześć!

Temat po części świeży, bo sprzed paru dni, ale ja bym o coś dopytał, najwyżej moderator wydzieli temat.

Czy możliwe jest rozbijanie diagramu na mniejsze przypadki, wprost, za pomocą zwykłego połączenie elementów diagramu?
Może nie będę wklejał obrazka, ale zapiszę go w postaci małego drzewka. Przykład ze strony wstecz, drugi obrazek.

Aktor: Administrator
Autoryzacja użytkownika
Konfiguracja systemu
Wprowadzenie danych

Z tego co widziałem połączenia są wiele do wielu, ale to można teraz pominąć ;)

Czas na pytnie. Czy można tym samym połączeniem rozpisać:

Aktor: Administrator
Autoryzacja użytkownika
Autoryzacja zwykła
Autoryzacja mobilna
Konfiguracja systemu
Wprowadzenie danych

bez oznaczania ich, jako <<extended>>, jako rozszerzanie? Zwykłe połączenia zwykłą kreską?

Chyba się nie czepiam? Rozszerzanie byłoby używane, w przypadku, gdy? ... Bo agregacja tyczyłaby się tylko komkretnego elementu z przypadku, tak?

Witam,
mam pytanie odnośnie diagramu przypadków użycia. W diagramie przypadków użycia są aktorzy główni: np użytkownik, administrator, a także pomocniczy, np. system powiadomień. System powiadomień to część mojego systemu, który informuje danego użytkownika o np. nowo dodanym pliku. Teraz mam pytanie skoro ten system powiadomień jest częścią całej aplikacji to powinien być na diagramie przypadków użycia- czy właśnie dlatego nie powinien. Na uczelni wykładowca twierdził, że powinien, jednak pewna osoba stwierdziła że to błąd.
Skorzystałem z linku zamieszczonego pare postów wyżej. Jest tam takie zdanie:

Aktorzy (czyli użytkownicy) systemu mogą być ludźmi lub zewnętrznymi systemami. W tym drugim przypadku warto je oznaczać używając notacji prostokątnej.

No ale system obsługi sprzedaży jest zaznaczony ikonką aktora, więc wynikałoby że mój wykładowca ma rację?
Będę wdzięczny za odpowiedź.

To zależy od systemu :)
Aktor to jest "ktoś kto używa systemu". Jeśli system jest podzielony na odseparowane komponenty to można je traktować jako aktorów.

Czyli system powiadomień może być w diagramie jako aktor jeśli istnieje moduł/pakiet lub inny podział, w którym jest ten system powiadomień jako przypadek czy jako co? bo nie rozumiem? Czyli uscisjąc moje pytanie jakby to wyglądało w praktyce? jeśli można to proszę o jakiś przykład, który pozwoli mi to lepiej zrozumieć.
Pozdrawiam

P.S. Mój post w temacie o diagramie aktywności został usunięty, jako powód-odpowiedź w tym wątku, nie rozumiem czemu. Tam prosiłem o ocenę konkretnego diagramu aktywności, tu pytam o aktorów w diagramie przypadków użycia. To różne diagramy jak dla mnie, więc nie wiem jak się wiąże jedno z drugim? Nie zakładałem nowych tematów, czemu post został usunięty? Mogłby mi ktoś na priv lub tu logicznie wytłumaczyć? Będę wdzięczny.

@grzeznik ty chyba w ogóle nie rozumiesz o czym mówisz. Diagram przypadków użycia przedstawia PRZYPADKI UŻYCIA SYSTEMU. Czyli sytuacje w których system jest używany. Zwykle system nie jest aktorem bo "sam siebie nie używa". Ale na przykład mamy taką sytuację:

• mamy moduł Finanse w naszej aplikacji, który na przykład generuje raporty finansowe
• mamy moduł TimerTasks który o określonym czasie nakazuje Finansom generowac raporty
• TimerTasks może być konfigurowany przez użytkownika

W efekcie mozemy tu mieć 2 przypadki użycia:

• Konfiguracja harmonogramu zadań (tutaj aktorem jest Użytkownik)
• Generowanie raportów finansowych (tutaj aktorem może być TimerTasks bo on używa systemu).

Ale takie rzeczy brałbym pod uwagę tylko jeśli to są na prawdę rozdzielne komponenty. Podział na pakiet czy moduł to za mało. Chodzi raczej o taka sytuację kiedy używany jest jakiś "black box". Taka sytuacja kiedy możesz bez problemu podzielić przypadki użycia na "przypadki użycia kompoenentu X" i "przypadki użycia kompoenentu Y".

Wiem co to są przypadki użycia i ich digam :), jednak chciałem wyjaśnić czemu jeda osoba twierdzi że jeśli system powiadomień to część mojego systemu to nie powinien figurować jako aktor, a druga osoba uważa inaczej. W każdym z Twojej wypowiedzi wynika że pierwsza osoba ma rację-w moim przypadku, dzięki za przykład, bo dobrze ilustruje sytuację. Dziękuję za pomoc.