czy tworząc diagram przypadków użycia mogę stworzyć Aktora który będzie reprezentował system, a przypadkami użycia bedą funkcje tego systemu??

Zamodelować można wszystko i do tego na tysiąc różnych sposobów:)

A tak na poważnie, to myślę, że modelowanie systemu jako aktora oraz przypadków użycia jako funkcji przez niego wykorzystywanych, jak najbardziej jest sensowne. Na dobrą sprawę, to wszystkie zamodelowane przypadki użycia są realizowane przez aktora "system", jednak zwykle nie jest to prezentowane na modelu. Dlatego ważne jest, aby taki zabieg został wykonany zgrabnie i sensownie. Na pewno w taki sposób mogą być przedstawiane są przypadki użycia wykonywane przez system zewnętrzny do modelowanego.

Pozdrawiam,

T.

Forum analityków IT
www.analiza-it.pl

Tak, ale nie zapominajmy o tym że aktorem (nawet jezeli jest stereotypowany do systemu) powinien być podmiot zewnętrzny w stosunku do projektowanego systemu.

utworzyłem taki oto przypadek użycia:



zwrócono mi uwagę że to jest złe, może macie pomysł jak przedstawić następujący system:

Operator na podstawie informacji odczytanej z wyświetlacza odczytuje kod skanerem, 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....

Patki,

Cytat:

A jaka była argumentacja oceniającego?

Pozdrawiam,

T.

Forum analityków IT
www.analiza-it.pl

Argumentacja: DPU jest związany bardziej z analizą dziedziny problemu, nie z projektowaniem wnętrza systemu. |To co przedstawiono ukazuje raczej funkcje i kolejnośc realizacji poszczególnych funkcji.....

Uwagi moim zdaniem słuszne bo:
- aktor to nie system, model UC zawiera granice systemu a wewnątrz przypadki użycia i na zewnątrz aktorzy, którzy są ZAWSZE POZA SYSTEMEM więc aktor System nie ma żadnego sensu
- przypadki użycia to nie model procesów więc kolejność czynności nie jest modelowana na diagramie UC (od tego sa modele procesów)
- przypadki użycia to czynności aktora a nie elementy scenariusza więc Zapis do bazy danych to kawałka scenariusza realizacji przypadku użycia (CRUD)

Od biedy, jeśli wyświetlacz nie jest wewnątrz systemu może być aktorem ale pytanie brzmi czy system odpowiada za to co wyświetla, jeśli tak to wyświetlacz jest w granicy systemu i nie może być jego aktorem, aktorami są Operator i Skaner.

A na koniec utworzyłeś diagram UC a nie przypadek użycia :)

Może wklej tu treść zadania to coś poradzimy...

----------------
--
Jarek Żeliński
"Jeżeli czegoś się nie da się narysować to to nie istnieje"

Cytat:

Przedstawianie na jednym modelu przypadków użycia aktorów zewnętrznych w stosunku do systemu oraz samego systemu jako aktora, z pewnością sensowne nie jest.

Pytanie jednak, czy faktycznie modelowanie systemu jako aktora oraz przypadków użycia jako funkcji przez niego wykonywanych zawsze nie ma żadnego sensu?

W mojej ocenie, wszystko zależy od perspektywy modelowania, jaką sobie założymy. Taki "zabieg" zastosowany w kontekście szczegółowego dokumentowania zachowania systemu może być jak najbardziej sensowny i obrazowy zarówno dla "ludzi biznesu" (klienta) jak i "ludzi informatyki" (zespołu projektowego).

Przyznam szczerze, że nie wiem jak restrykcyjna jest specyfikacja UML i czy wynika z niej, iż niepoprawny jest taki sposób modelowania. Wydaje mi się - jak pisałem wcześniej, iż umiejętne i przemyślane zastosowanie aktora "System" może w pewnych sytuacjach być bardzo pomocne i praktyczne.

Patik,

Argumentacja oceniającego jest dla mnie jak najbardziej zasadna.
Wydaje mi się, że to co zamodelowałeś za pomocą przypadków użycia, powinno być raczej przedstawione np. jako diagramy czynności uszczegóławiające przypadki "Użyj wyświetlacza" i "Użyj skanera".

Poza tym, trudno jest mi odczytać Twoją intencję, co do relacji "extend" pomiędzy przypadkami "Analiza danych" i "Sprawdź proces N-1" (abstrahując od poprawności merytorycznej przypadków) - jaka Twoim zdaniem powinna być interpretacja czytającego?

Pozdrawiam,

T.

Forum analityków IT
www.analiza-it.pl

Cytat:

Chodzi o to że za każdym razem gdy jest wykonywana czynnośc analizy danych, sprawdzany jest wynik procesu N-1 oraz sprawdzana jest poprawność wczytanych kodów.

Cytat:

Celem jest budowa modelu systemu informatycznego do wspomagania procesu produkcyjnego. Zakłada się że system będzie wykożystywał technologię kodów kreskowych do jesdnoznacznej identyfikacji cześci. Na każdym etapie produkcji system będzie rejestorował datęi godzinę, nr operatora, wynik procesu z maszyny, nr częsci skanowanych na danym stanowisku. System ma spełniać również funkcje kontrolne tzn, każdy kod który będzie skanowany przez operatora będzie weryfikowany pod względem długości znaków, i poprawności, ma również sprawdzać czy poprzednie procesy zostały wykonane prawidłowo. Inną funkcją ma być definiowanie łączenia części na etapie montażu chodzi o to aby można było w systemie zdefiniować, że proces montażu może być wykonany tylko dla części A+B orac C+D natomiast A+C, A+D i B+C oraz B+D są niemożliwe do stworzenia - w tych przypadkach system nie zezwoli na start maszyny.

System na każdym etapie komunikuje się z daną maszyną i po zebraniu wszystkich kodów i właściwym przeanalizowaniu odpytuje maszynę czy jest gotowa, jeżeli maszyna wysyła pozytywny sygnał wówczas wysyła pozwolenie na start do sterownika - i tylko w takim przypadku możliwe jest uruchomienie maszyny.

Po pierwsze w kwestii UML: jest to słownik symboli i gramatyka ich stosowania, jeżeli ta metoda ma stanowić narzędzie komunikacji to używajmy jej zgodnie z opisem. Jeżeli każdy będzie sobie używał słów po swojemu i gramatyki po swojemu to tekst nie będzie polski tylko będzie to jakiś zlepek słów w rodzaju poszczególne słowa rozumiem ale tekstu już nie....

W kwestii modelu: opis jest strasznie zagmatwany, moja propozycja ogarnięcia problemu:
- narysuj łańcuch wydarzeń dla każdego celowego działania w UML (diagram czynności) z perspektywy użytkownika (aktora)
- wskaż czynności, kóre będą wykonane przez System (to będą przypadki użycia)
- opracuje na tej podstawie diagram UC
- dla każdego UC napisz scenariusz

jest szansa, że ta metodą będzie OK :)

----------------
--
Jarek Żeliński
"Jeżeli czegoś się nie da się narysować to to nie istnieje"