Studium przypadku diagram przypadki użycia

0

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.

user image</image>

0

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.

0

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??
user image

0

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

0

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.

0

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-kropel[...]/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.

0

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.

0
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.

0
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.
0

Witam,

Zmieniłem nieco swoje wypociny.

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

user image

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

user image</image>

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