GoldenLine
Zaloguj się
Krzysztof Sorocki

Krzysztof Sorocki Tester

Temat: Diagram przypadków użycia - kierunek asocjacji

Mam pytanie dotyczące diagramów przypadków użycia i znaczenia kierunku asocjacji. W różnych źródłach znajduję, różne, czasem sprzeczne informacje na ten temat.

Jedne źródła podają, że kierunek asocjacji pomiędzy aktorem a PU oznacza kierunek przepływu danych. Inne źródła podają, że kierunek asocjacji wskazuje kto jest inicjatorem danej akcji i nie oznacza kierunku przepływu informacji.

Jak wygląda sytuacja z kierunkiem asocjacji na diagramie kontekstowym ? Czy na tym diagramie kierunek asocjacji oznacza zawsze kierunek przepływu informacji ?

Będę wdzięczny za pomoc w uporządkowaniu powyższych informacji.
Link do wypowiedziLink
Jacek Sałacki

Jacek Sałacki analityk
biznesowy/project
manager

Temat: Diagram przypadków użycia - kierunek asocjacji

Jeżeli UC jest prawidłowo zaprojektowany i nie jest trywialny to "przepływ informacji" odbywa się w obie strony: aktor wprowadza dane, system je przetwarza i odpowiada aktorowi, aktor robi coś z odpowiedzią systemu itd.
Asocjacje pokazują przede wszystkim jakie UC są wykorzystywane przez danego aktora.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Asocjacja Aktor-UC oznacza jedynie skojarzenie aktora z usługa systemu. Ten diagram to nie "przepływ danych".

Diagram przypadków użycia to model Systemu jako czarnej skrzynki i zewnętrznych bytów mających z nim interakcje. I tylko tyle. Nie znalazłem w specyfikacji UML opisu "kierunkowych asocjacji w UC".

W kwestii inicjacji to skojarzenie aktora z przypadkiem użycia z pomocą asocjacji oznacza, że korzysta on z tego System, a korzystać oznacza "chcieć coś" od niego czyli aktor inicjuje interakcje z systemem.

Co masz na myśli pisząc diagram kontekstowy?

P.S.
należy pamiętać, że UML jest notacją nadmiarową dlatego bardzo ważne jest uznanie (lub stworzenie) jakiejś pragmatyki dla modeli. Najczęściej jest nią przyjęta metodyka (RUP, ICONIX, CATALYST, inne).

Niestety niektóre "źródła" (książki, internet) to miej lub bardziej wymysły ich autorów (np. symbole kluczy głównych na diagramach klas, fuj), osobiście stoję na stanowisku by tam gdzie pada nazwa notacji jaką języka stosować ją bez własnych udziwnień bo wtedy przestaje być "ta notacją". Dotychczasowe projekty nauczyły mnie, że nie ma potrzeby udziwniania notacji (np. UML) a "potrzeba" wprowadzania własnych "znaków" to raczej efekt niezrozumienia notacji lub modelowanego problemu a nie "braki notacji"...Jarek Żeliński edytował(a) ten post dnia 04.11.12 o godzinie 12:59
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Może to Ci pomoże:

http://it-consulting.pl/autoinstalator/wordpress/2011/...

i to:

http://it-consulting.pl/autoinstalator/wordpress/2012/...

i to:

http://it-consulting.pl/autoinstalator/wordpress/2011/...Jarek Żeliński edytował(a) ten post dnia 04.11.12 o godzinie 15:09
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Przypomniałem sobie jedną rzecz: pojęcie "information flow" na diagramie przypadków użycia jest w notacji SysML... ale tam i tak nie jest to "kierunek asocjacji" tylko znacznik kierunku (duży pełny grot w środku asocjacji aktor system) czy o to Ci chodziło?
Link do wypowiedziLink
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Diagram przypadków użycia - kierunek asocjacji

Jarek Żeliński:
W kwestii inicjacji to skojarzenie aktora z przypadkiem użycia z pomocą asocjacji oznacza, że korzysta on z tego System, a korzystać oznacza "chcieć coś" od niego czyli aktor inicjuje interakcje z systemem.
Czy aktor musi koniecznie inicjować interakcję z systemem? Wydaje mi się, że zgodnie z definicją języka musi uczestniczyć w realizacji usługi. Inicjować może także:
- inny aktor
- system
Czy się mylę?
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

To konsekwencja definicji:
- przypadek użycia to usługa systemu
- usługi systemu są wywoływane (żądane, inicjowane) przez aktora
- usługi oczywiście może żądać inny system, wtedy jest aktorem

Jeżeli system ma funkcjonalność "generowanie raportu sprzedaży" to raport ten nie pojawi się na ekranie czy papierze "samorodnie" a jedynie na żądanie użytkownika, może również zostać wygenerowany automatycznie rano o 8:00 co nie zmienia faktu, że ktoś to "zaprogramował" (zażądał tego - przypomnę czas nie jest aktorem, czas to parametr "czegoś").

Ale jeżeli np. "nasz" system (system projektowany, dokumentowany) wywołuje inny by np. pobrać z niego dane pracownika, to "nasz" system jest aktorem "tamtego", ale "tamten" system implementuje "naszemu" jakaś usługę, aktor 'naszego" systemu nie wie gdzie są żądane dane, wie że może ich zażądać.

To dlatego mamy pojęcie interfejsu oferowanego z którego korzystają aktorzy systemu, oraz pojęcie interfejsu wymaganego, który w naszym systemie reprezentuje zewnętrzną implementacje jakiejś usługi.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

przypominam, że asocjacje na diagramach przypadków użycia nie są kierunkowe. SysML ma takie rozszerzenie, obrazuje ono na modelach kontekstowych kierunek przypływu danych, jednak przepływ danych nijak się ma to tego kto go zainicjował: aktor systemu "fajne pliki w sieci" będzie inicjował dostęp do swojego folderu ale to czy w konsekwencji będzie to download czy upload nie zmienia faktu, ze Aktor wywoła usługę systemu Zarządzanie własnym folderem plików.Jarek Żeliński edytował(a) ten post dnia 25.11.12 o godzinie 11:29
Link do wypowiedziLink
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Diagram przypadków użycia - kierunek asocjacji

Mateusz Kurleto:
Jarek Żeliński:
W kwestii inicjacji to skojarzenie aktora z przypadkiem użycia z pomocą asocjacji oznacza, że korzysta on z tego System, a korzystać oznacza "chcieć coś" od niego czyli aktor inicjuje interakcje z systemem.
Czy aktor musi koniecznie inicjować interakcję z systemem? Wydaje mi się, że zgodnie z definicją języka musi uczestniczyć w realizacji usługi. Inicjować może także:
- inny aktor
- system
Czy się mylę?
No to sprawdziłem i się nie mylę:)
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

nie bardzo rozumiem co :),

aktorem "systemu modelowanego" na diagramie PU jest "coś z zewnątrz" co używa usługi systemu, to coś z zewnątrz to aktor, pamiętamy, że diagram przypadków użycia ma jeden System, inne mogą być właśnie aktorami (albo są pomijane), jak można skorzystać z usługi systemu nie wywołując (żądając) jej? Jeżeli usługą wywołał "ktoś inny" to ten ktoś je aktorem...
Link do wypowiedziLink
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Diagram przypadków użycia - kierunek asocjacji

Jarek Żeliński:
nie bardzo rozumiem co :),

aktorem "systemu modelowanego" na diagramie PU jest "coś z zewnątrz" co używa usługi systemu, to coś z zewnątrz to aktor, pamiętamy, że diagram przypadków użycia ma jeden System, inne mogą być właśnie aktorami (albo są pomijane), jak można skorzystać z usługi systemu nie wywołując (żądając) jej? Jeżeli usługą wywołał "ktoś inny" to ten ktoś je aktorem...
Są np. usługi świadczone w sposób ciągły, które mogą same inicjować interakcje z aktorem. Np. jakaś usługa implementuje wzorzec obserwatora i jeżeli zostaną spełnione jakieś tam warunki żąda od aktora współpracy przy jej realizacji.
Np. kiedy inny aktor jest systemem, który obsługuje dla mnie płatności, albo jest to przełożony, który podejmuje decyzję co zrobić gdy system wzbudza alert.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Mateusz Kurleto:
Są np. usługi świadczone w sposób ciągły, które mogą same inicjować interakcje z aktorem. Np. jakaś usługa implementuje wzorzec obserwatora i jeżeli zostaną spełnione jakieś tam warunki żąda od aktora współpracy przy jej realizacji.
Np. kiedy inny aktor jest systemem, który obsługuje dla mnie płatności, albo jest to przełożony, który podejmuje decyzję co zrobić gdy system wzbudza alert.

ja to nazywam "System Bomba Zegarowa", kto jest aktorem co sie dziej samo?

Bomba ma programator, aktorem jest Użytkownik Bomby, wybuch o określonym czasie to reakcja wywołana przez aktora bo ten zaprogramował (GUI) moment wybuchu, tyle że z opóźnieniem. Takie "rozumowanie" nazywam zmuszaniem się do zrozumienia istoty rzeczy. Pojęcie System i Aktor są bardzo precyzyjnie zdefiniowane w UML, problemem może być wyłuskanie tych pojęć w analizowanej rzeczywistości.

"Samoczynna interakcja z aktorem" została wcześniej "zaprogramowana", tu nie ma dylematu co było wcześniej jajko czy kura, tu ZAWSZE pierwszy jest Aktor, w skrajnym wypadku jest nim programista (jeżeli system jest konfigurowany pisanym kodem). Poszerzanie (uważam zbędne bo psuje) znaczenia Aktor prowadzi np. do błędnego wniosku, że Czas może być Aktorem.
Link do wypowiedziLink
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Diagram przypadków użycia - kierunek asocjacji

Jarek Żeliński:
"Samoczynna interakcja z aktorem" została wcześniej "zaprogramowana", tu nie ma dylematu co było wcześniej jajko czy kura, tu ZAWSZE pierwszy jest Aktor, w skrajnym wypadku jest nim programista (jeżeli system jest konfigurowany pisanym kodem). Poszerzanie (uważam zbędne bo psuje) znaczenia Aktor prowadzi np. do błędnego wniosku, że Czas może być Aktorem.
Nie ma to nic wspólnego z czasem - jeszcze nie widziałem pracy o kwantach wchodzących w interakcje z systemem informatycznym.
Specyfikacja UML nie wskazuje kto inicjuje interakcje - system, czy aktor - asocjacja systemu i aktora stwierdza jedynie, że aktor bierze udział w realizacji przypadku użycia. Inicjację usługi może prowadzić zgodnie z semantyką i syntaktyką UML zarówno aktor, inny aktor jak i system.Mateusz Kurleto edytował(a) ten post dnia 27.12.12 o godzinie 15:28
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Mateusz Kurleto:
Specyfikacja UML nie wskazuje kto inicjuje interakcje - system, czy aktor - asocjacja systemu i aktora stwierdza jedynie, że aktor bierze udział w realizacji przypadku użycia.

specyfikuje "nie wprost", w opisie diagramow sekswencji, Aktoor inicjuje....

Inicjację usługi może prowadzić zgodnie z semantyką i syntaktyką UML zarówno aktor, inny aktor jak i system.
Link do wypowiedziLink
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Diagram przypadków użycia - kierunek asocjacji

Jarek Żeliński:
Mateusz Kurleto:
Specyfikacja UML nie wskazuje kto inicjuje interakcje - system, czy aktor - asocjacja systemu i aktora stwierdza jedynie, że aktor bierze udział w realizacji przypadku użycia.

specyfikuje "nie wprost", w opisie diagramow sekswencji, Aktoor inicjuje....
To ciekawostka - bo zgodnie z moją wiedzą nic nie stoi na przeszkodzie ze względów językowych aby pierwszy komunikat był klasa->aktor.
Ponadto nie można mówić o specyfikowaniu nie wprost - nie wprost to jest interpretacja.
Interpretacja diagramu przypadków użycia na podstawie diagramu sekwencji jest słabe.
Inicjację usługi może prowadzić zgodnie z semantyką i syntaktyką UML zarówno aktor, inny aktor jak i system.Mateusz Kurleto edytował(a) ten post dnia 27.12.12 o godzinie 21:23
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Mateusz Kurleto:
Interpretacja diagramu przypadków użycia na podstawie diagramu sekwencji jest słabe.

nie :), jak zitepretujesz "system świadczy usługi aktorowi"?
Link do wypowiedziLink
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Diagram przypadków użycia - kierunek asocjacji

Jarek Żeliński:
Mateusz Kurleto:
Interpretacja diagramu przypadków użycia na podstawie diagramu sekwencji jest słabe.

nie :), jak zitepretujesz "system świadczy usługi aktorowi"?
Nie jest tu napisane kto jest inicjatorem tej usługi. Usługi mogą być świadczone w sposób ciągły.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Mateusz Kurleto:
Usługi mogą być świadczone w sposób ciągły.

OK, ale kiedyś trzeba zacząć :)
Link do wypowiedziLink
Mateusz Kurleto

Mateusz Kurleto Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku

Temat: Diagram przypadków użycia - kierunek asocjacji

Jarek Żeliński:
Mateusz Kurleto:
Usługi mogą być świadczone w sposób ciągły.

OK, ale kiedyś trzeba zacząć :)
Ale konfiguracja usługi automatycznej to nie koniecznie ten sam przypadek użycia co jej świadczenie - to raz - a dwa tu nie chodzi o proste sytuacje pod tytułem wyzwalanie akcji CRON-em.
Specyfikacja UML ani logika nie wskazuje że aktor musi PU inicjować.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Diagram przypadków użycia - kierunek asocjacji

Mateusz Kurleto:
Jarek Żeliński:
Mateusz Kurleto:
Usługi mogą być świadczone w sposób ciągły.

OK, ale kiedyś trzeba zacząć :)
Ale konfiguracja usługi automatycznej to nie koniecznie ten sam przypadek użycia co jej świadczenie - to raz - a dwa tu nie chodzi o proste sytuacje pod tytułem wyzwalanie akcji CRON-em.
Specyfikacja UML ani logika nie wskazuje że aktor musi PU inicjować.

Ogólnie:
- Aktor to coś co ma interakcję z systemem
- Przypadek Użycia to usługa świadczona przez system, której można od niego zażądać

w związku z tym interakcja z system polega na żądaniu od niego usług (sam nic nie robi) więc Aktor, nie ma zmiłuj, żąda czyli inicjuje działania systemu.

Nawet System o nazwie "Kalendarz, który do końca świata sam mówi każdemu o jego imieninach" ktoś musi raz skonfigurować, i mamy Aktora, który wprowadza dni i nazwy imienin. Taki Przypadek użycia zapewne zostanie użyty raz, i System "sam" będzie coś robił ale ... to dozgonne samoczynne powiadamianie zostało zainicjowane przez Aktora, który wprowadził pierwotne dane.

w najgorszym przypadku ktoś musi po protu to cudo włączyć i być może podać jakieś plik konfiguracyjny jako parametr...

Tak restrykcyjne, wręcz purystyczne, podejście bardzo skutecznie chroni moje projekty przed odkrywaniem wymagań w trakcie implementacji... i przez tak zwanymi wymaganiami sierotami, czyli ktoś se wymyślił coś fajnego a potem się okazuje, że nikomu to nie jest potrzebne (nikt nie używa) a koszty implementacji poniesiono.

ten UML na prawdę ma sens :)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj