GoldenLine
Zaloguj się
Jarosław Żeliński

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Marcin Gościniak:
Jeśli warunki wstępne to np. "użytkownik jest zalogowany", to jak rozumieć "Warunki końcowe"?

hm... bez kontekstu to trudne ale...

warunek (stan) początkowy: użytkownik zalogowany
czynność: wywołanie menu
stan końcowy: menu wywołane

przykład trywialny, żeby nie powiedzieć głupi ale mam nadzieję, że coś Ci pomoże: w UC opisujemy w nagłówku: stan (warunki) początkowe, cel i uzasadnienie, stan końcowy. do tego jak trzeba to scenariusz (event flow), UC to czynności służące do osiągnięcia jednego nazwanego efektu, czyli nie jest przypadkiem użycia "obsługa wizyty klienta" a jest nim, przyjęcie zamówienia, wystawienie faktury, itp...

np.tu:
stan początkowy: znany dane kontrahenta produkty do zafakturowania
cel: wystawienie faktury VAT zgodnej z przepisami
stan końcowy: faktura wystawiona, zarejestrowana, opcjonalnie wydrukowana.Jarek Żeliński edytował(a) ten post dnia 19.10.09 o godzinie 21:03
Link do wypowiedziLink
Bartosz Borowiec

Bartosz Borowiec Salesforce and Java
backend/integration
developer at Inde...

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Moja aplikacja składa się z dwóch modułów webowego i EJB. Moduł webowy wykorzystuje BuissnesDelagate i ServiceLocatora do cashowania i wyszukiwania elementów webowych. Jak to pokazać na diagramie komponetów? Czy te dwie dependencje (w czerwonym kółeczku:) ) do portu w komponencie webowym są właściwe?

Obrazek
Link do wypowiedziLink
Olga Makushenko

Olga Makushenko Student, Wyższa
Szkoła Informatyki i
Zarządzania w
Rzeszowie

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Witam!
Mam takie zadańko z Inżynierii Oprogramowania:
"Przedstaw przy pomocy diagramu przypadków użycia model systemu informatycznego sterującego sygnalizacją świetlną skrzyżowania drogowego z ruchem okrężnym. W projektowanym systemie należy uwzględnić możliwość uruchamiania odpowiednich detektorów ruchu, określania czasu przejazdów uczestników ruchu, informowania o zapełnieniu buforów ronda, kolejkach samochodów, itp. uwarunkowania zgodnie z rzeczywistym planowaniem ruchu na skrzyżowaniu okrężnym."
Próbowałam coś robić, jednak nie bardzo mi wychodzi... Czy mógłby ktoś z tym pomóc, w ogóle powiedzieć co mam źle (obawiam się że wszystko =P, chociaż mam uproszczony model ) ? Dzięki!


Obrazek
Olga Makushenko edytował(a) ten post dnia 02.07.10 o godzinie 19:42
Link do wypowiedziLink
Jarosław Żeliński

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Olga Makushenko:
Witam!
Mam takie zadańko z Inżynierii Oprogramowania:
"Przedstaw przy pomocy diagramu przypadków użycia model systemu informatycznego sterującego sygnalizacją świetlną skrzyżowania drogowego z ruchem okrężnym. W projektowanym systemie należy uwzględnić możliwość uruchamiania odpowiednich detektorów ruchu, określania czasu przejazdów uczestników ruchu, informowania o zapełnieniu buforów ronda, kolejkach samochodów, itp. uwarunkowania zgodnie z rzeczywistym planowaniem ruchu na skrzyżowaniu okrężnym."

hm.. na początek ważne jest okreslenie granicy systemu: np. detektor ruchu jest "dany" czy wymaga zaprojektowania i jest częścią nowego systemu? Jeśli jest dany to samochody dla nas nie istnieją, samochód będzie aktorem jeśli detektor ruchu jest funkcjonalnościa systemu....

najpierw pokresl zakres systemu...
Link do wypowiedziLink
Artur Kęska

Artur Kęska Senior Software
Developer, XNet
Communications

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Olga Makushenko:
"Przedstaw przy pomocy diagramu przypadków użycia model systemu informatycznego sterującego sygnalizacją świetlną skrzyżowania drogowego z ruchem okrężnym. W projektowanym systemie należy uwzględnić możliwość uruchamiania odpowiednich detektorów ruchu, określania czasu przejazdów uczestników ruchu, informowania o zapełnieniu buforów ronda, kolejkach samochodów, itp. uwarunkowania zgodnie z rzeczywistym planowaniem ruchu na skrzyżowaniu okrężnym."

Abstrahując od tego co mówi pan Jarek. Niech by i granice projektowanego systemu były wyznaczone między sensorami a obiektami na drodze (to sugeruje diagram). To kiedy go czytam, odnoszę wrażenie, że jest to raczej model zachowania pieszego/kierowcy niż systemu sterowania.
Tworząc taki diagram musi Pani patrzeć z punktu widzenia systemu. Przecież system sterowania nie będzie "skręcał" co najwyżej "Pozwoli na skręcanie", albo "Ustawi sygnał zezwolenia na skręt".

Poza tym, osobiście uważam, że akurat przypadki użycia średnio się nadają do modelowania tego rodzaju systemów.
Dla czego? Bo tak na prawdę prawidłowy diagram powinien mieć jeden przypadek użycia "Sterowanie ruchem" podłączony do aktorów: "Dane pomiarowe", "Efektory-czegoś-tam" i "Czas" (klasyka w automatyce). No i co ma się niby znaleźć w opisie takiego przypadku? Może - użyj metody Xsińskiego i na podstawie danych pomiarowych i czasu zmieniaj stan efektorów? Po co więc w ogóle robić taki diagram.
Mogą być też inne przypadki, jak "Diagnozuj system" z relacją do "Serwisanta", "Archiwizuj dane statystyczne" podłączony do "Bazy danych" i.t.d. tyko, że w treści zadania (SRS) nie ma na ten temat ani słowa.
W każdym razie, nie modelował bym logiki systemu sterowania przy pomocy UC.
Link do wypowiedziLink
Jarosław Żeliński

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:
W każdym razie, nie modelował bym logiki systemu sterowania przy pomocy UC.

sakramentalne stwierdzenie: diagram UC to TYLKO funckjonalności a nie specyfikacja logiki programu.

Jeśli mowa o modelu systemu i jego logice to raczej diagram klas uzupełniony diagramami sekwencji i maszyny stanów dla obiektów stanowych. Nie wiem dlaczego nawet na studiach wykładowcy życzą sobie opis logiki systemu, wręcz cały jego projekt w postaci diagramu UC, który akurat najmniej sie do tego nadaje...

jednak skoro zadanie brzmi "Przedstaw za pomoca diagramu UC..." to należy wykonac dobry diagram UC niezależnie od tego że pokaże on wyłącznie funkcjonalności...Jarek Żeliński edytował(a) ten post dnia 03.07.10 o godzinie 00:35
Link do wypowiedziLink
Olga Makushenko

Olga Makushenko Student, Wyższa
Szkoła Informatyki i
Zarządzania w
Rzeszowie

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Żeliński:

hm.. na początek ważne jest okreslenie granicy systemu: np. detektor ruchu jest "dany" czy wymaga zaprojektowania i jest częścią nowego systemu? Jeśli jest dany to samochody dla nas nie istnieją, samochód będzie aktorem jeśli detektor ruchu jest funkcjonalnościa systemu....

najpierw pokresl zakres systemu...
Dziękuję! Uwzgłędniłam to.
Artur Kęska:

Abstrahując od tego co mówi pan Jarek. Niech by i granice projektowanego systemu były wyznaczone między sensorami a obiektami na drodze (to sugeruje diagram). To kiedy go czytam, odnoszę wrażenie, że jest to raczej model zachowania pieszego/kierowcy niż systemu sterowania.
Tworząc taki diagram musi Pani patrzeć z punktu widzenia systemu. Przecież system sterowania nie będzie "skręcał" co najwyżej "Pozwoli na skręcanie", albo "Ustawi sygnał zezwolenia na skręt".

Rozumiem, o co Panu chodzi, ale w tym przypadku jest mi trudno tak wszystko pozamieniać, bo i tak nie jest to zwykły diagram przypadków, tylko diagram, który pokazuje jeszcze specyfikację działania.

Odnośnie logiki systemu - była to dla mnie bardo ciekawa informacja i teraz zastanawiam się nad sensem tego wszystkiego...

Panie Arturze, spodobał mi się Pana "prawidłowy diagram". Nawet go narysowałam (Obrazek №1).
Swój diagram przerobiłam, chociaż nie wygląda tak, jak powinien, ale mam nadzieje że lepiej od poprzedniego (Obrazek №2). Martwi mnie jednak jego złożoność =(


Obrazek


Obrazek
Link do wypowiedziLink
Olga Makushenko

Olga Makushenko Student, Wyższa
Szkoła Informatyki i
Zarządzania w
Rzeszowie

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jeszcze trocha przerobiłam diagram. Oto wersja końcowa że tak powiem =)


Obrazek
Link do wypowiedziLink
Mateusz Kurleto

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Droga koleżanko. Obawiam się, że nie tędy droga. Chyba bardzo próbujesz opisać co robią uczestnicy ruchu na rondzie - a to nie jest Twoje zadanie. Ty masz wykonać diagram przypadków użycia systemu sterującego światłami.
Proponuję zamiast siadać na rondzie i patrzeć co się na nim dzieje usiąść w dyspozytorni i zastanowić się co ma robić system sterujący światłami.
Po pierwsze przyjmij poziom szczegółowości - proponuję klasyczny one goal-one usecase-one scenario. A więc jakie będą te przypadki użycia?
Czy "zaświeć czerwony na światłach 1,2,3,4,5 dla pieszych" to przypadek użycia? Nie to krok algorytmu zarządzania stanami! To nie tutaj.
Przypadki użycia to:
- analiza danych statystycznych
- włączenie sygnalizacji
- wyłączenie sygnalizacji
System nie może zmniejszyć prędkości.
System nie może wjechać na rondo.
Ani skręcić w prawo.
System siedzi w serwerowni i służy do zarządzania sygnalizacją. Diagram przypadków użycia nie służy do opisu zachowania aktorów. Ani do przedstawienia zasad działania algorytmu przełączania świateł!
Cały Twój diagram jest kompletnie nie na temat!Mateusz Kurleto edytował(a) ten post dnia 03.07.10 o godzinie 16:30
Link do wypowiedziLink
Artur Kęska

Artur Kęska Senior Software
Developer, XNet
Communications

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Olga Makushenko:
Rozumiem, o co Panu chodzi, ale w tym przypadku jest mi trudno tak wszystko pozamieniać, bo i tak nie jest to zwykły diagram przypadków, tylko diagram, który pokazuje jeszcze specyfikację działania.

Obawiam się, że aby diagram był prawidłowy, MUSI Pani go zmienić.
Z resztą jak Pani widzi wszyscy zgadzamy się ze sobą. Na diagramie nie mogą występować przypadki takie jak "Przejdź przed światłami" (i inne łączące się z Pieszym i Pojazdem).
Niezależnie od tego co się może wydawać, system sterowania ruchem, wcale nie steruje pojazdami czy pieszymi - to dzieje się już poza systemem. No chyba, że chce Pani modelować socjo-mechaniczno-kognitywiztyczne aspekty działania układu "sygnalizator drogowy-człowiek-(pojazd)". Nie widziałem nic takiego w treści zadania, więc myślę, że nie o to chodzi.
Niech Pani więc po prostu usunie te przypadki - bez obaw, model na tym nie ucierpi.

Model też nadal nie pokazuje nic co by się wiązało z akwizycją danych pomiarowych. Niech już by i był ten pieszy i pojazd (sic) to trzeba by jeszcze stworzyć przypadek "Analizuj ruch" czy jakoś tak (podobnie jak proponuje Pan Mateusz).

Dla czego nie do końca podoba mi się ten pieszy i pojazd? Ano dla tego, że z punktu widzenia systemu automatyki nie ma pojazdu ani pieszego, za to są dane pomiarowe. Jeżeli mi pani nie wierzy, to proszę się przyjrzeć dość prymitywnej definicji takiego układu: http://pl.wikipedia.org/wiki/Uk%C5%82ad_sterowania

Jeszcze odnoście diagramu No1 i No2 - proszę zwrócić uwagę, że diagram No1 wykracza poza sferę sterowania. Pokazuje on, jakie funkcję będzie posiadał system (poza oczywiście funkcją sterowania sygnalizacją) i kto lub co będzie wchodziło z nimi w interakcję. I tyle i tylko tyle powinien pokazywać diagram UC.
A diagram No2. Słusznie martwi Panią jego złożonośćą :-). Potwierdza tylko moje przypuszczenia - UC nie nadają się do modelowania układów sterowania.

Obawiam się, że nie specjalnie Pani pomagamy. Myślę, że z tym zadaniem jest po prostu coś nie tak.

Odnośnie logiki systemu - była to dla mnie bardo ciekawa informacja i teraz zastanawiam się nad sensem tego wszystkiego...

Panie Arturze, spodobał mi się Pana "prawidłowy diagram". Nawet go narysowałam (Obrazek №1).
Swój diagram przerobiłam, chociaż nie wygląda tak, jak powinien, ale mam nadzieje że lepiej od poprzedniego (Obrazek №2). Martwi mnie jednak jego złożoność =(


Obrazek


Obrazek
Link do wypowiedziLink
Olga Makushenko

Olga Makushenko Student, Wyższa
Szkoła Informatyki i
Zarządzania w
Rzeszowie

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Dzięki za wartościową odpowiedź!

Te diagramy również wysłałam nauczycielu. Powiedział, że "diagram powinien uwzględniać tylko aktorów takich jak: Pojazd, Detektor i Sygnalizator". Oraz że "diagram ma opisywać model funkcjonalności systemu, a nie stanów".
Ale jak mam zmodelować system, sterujący sygnalizacją świetlną skrzyżowania drogowego z ruchem okrężnym posługując się tylko tymy tzema aktorami i nie wchodząc w szczegóły ???
Link do wypowiedziLink
Olga Makushenko

Olga Makushenko Student, Wyższa
Szkoła Informatyki i
Zarządzania w
Rzeszowie

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Narysowałam diagram do drugiego zadania:
"Wykorzystując metodologię projektu diagramu przypadków użycia wykonaj model systemu informatycznego, którego zadaniem powinno być programowalne sterowanie wszystkimi urządzeniami budynku mieszkalnego. Minimalna funkcjonalność systemu powinna umożliwiać sterowanie:
- oświetleniem poszczególnych pomieszczeń
- alarmem przeciwwłamaniowym
- alarmem przeciwpożarowym
- instalacją centralnego ogrzewania
- instalacją gniazd elektrycznych
- klimatyzacją i wentylacją pomieszczeń
- urządzeniami AV

System powinien mieć również możliwość wysyłania w trybie interakcyjnym informacji związanych z uruchomieniem procedur awaryjnych zarówno do odpowiednich służb jak i osób uwzględnionych w rejestrze listy kontaktowej wraz z zapisaniem aktualnego stanu w dzienniku zdarzeń."

Mam nadzieję, że skorzystałam z Państwa wskazówek w mniej-więcej poprawny sposób =)


Obrazek
Link do wypowiedziLink
Olga Makushenko

Olga Makushenko Student, Wyższa
Szkoła Informatyki i
Zarządzania w
Rzeszowie

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Narysowałam po raz kolejny diagram do Zadania 1.


Obrazek
Link do wypowiedziLink
Mateusz Kurleto

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Olga Makushenko:
Narysowałam po raz kolejny diagram do Zadania 1.


Obrazek
Niewiele lepiej, ale lepiej. Nadal nie na temat.
Diagram Przypadków uzycia opisuje w jaki sopsób aktorzy korzystają z systemu. Pojazd nie korzysta z systemu. Powiedz mi jak system realizuje przypadek użycia Jedź???? Co to za przypadki użycia z włączaniem świateł hamowania i kierunkowskazami?
Diagram przypadków użycia opisuje przypadki użycia SYSTEMU. Ponawiam więc swój apel. Wyrzuc to do kosza i zamiast wyobrażac sobie skrzyżowanie wyobraź sobie DYSPOZYTORA RUCHU
Link do wypowiedziLink
Joanna U.

Joanna U. Inżynier
oprogramowania,
Analityk
systemowy/biznesowy

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
Diagram Przypadków uzycia opisuje w jaki sopsób aktorzy korzystają z systemu. Pojazd nie korzysta z systemu.

Chyba musimy to przełknąć i wyobrazić sobie na potrzeby tego zadania (w końcu to szkoła, przykłady są często naciągane, a nauczyciel wyznaczył trzech aktorów), że POJAZD jest "biernym" użytkownikiem systemu (obserwatorem). Jeżeli już musi być, to może mieć aktywności JEDŹ i STÓJ.

DETEKTOR mierzy aktywność POJAZDU: czas przejazdu, w jakim stopniu POJAZD zapełnia bufor ronda, tworzy kolejkę samochodów i w zależności od tego - zarządza zmianą świateł, wykonywaną przez SYGNALIZATOR.

SYGNALIZATOR - świeci (jednak to, jak długo trwa czerwone/zielone światło powinno być zależne od DETEKTORA, który jest tutaj nie od parady) :)
Link do wypowiedziLink
Joanna U.

Joanna U. Inżynier
oprogramowania,
Analityk
systemowy/biznesowy

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Olga Makushenko:
Narysowałam diagram do drugiego zadania:

Obrazek
Olu, chyba nie do końca zrozumiałaś przeznaczenie systemu. Aktor MIESZKANIEC DOMU (albo SERWISANT) powinien mieć tylko aktywność np. ZAPROGRAMUJ STEROWANIE URZĄDZENIAMI.
Potem całą resztę "załatwia" już aktor SYSTEM - czyli steruje wszystkim tym, co wymieniłaś w rządku, a więc:
- włącz, wyłącz oświetlenie poszczególnych pomieszczeń,
- włącz, wyłącz alarm przeciwwłamaniowy, itp.

To wszystko robi SYSTEM w zależności od ustawionych (zaprogramowanych) przez MIESZKAŃCA DOMU parametrów oraz czujników, czyli np. od ustawionego czasu oraz odebranych przez czujniki sygnałów.
Link do wypowiedziLink
Mateusz Kurleto

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Joanna U.:
Mateusz Kurleto:
Diagram Przypadków uzycia opisuje w jaki sopsób aktorzy korzystają z systemu. Pojazd nie korzysta z systemu.

Chyba musimy to przełknąć i wyobrazić sobie na potrzeby tego zadania (w końcu to szkoła, przykłady są często naciągane, a nauczyciel wyznaczył trzech aktorów), że POJAZD jest "biernym" użytkownikiem systemu (obserwatorem). Jeżeli już musi być, to może mieć aktywności JEDŹ i STÓJ.

DETEKTOR mierzy aktywność POJAZDU: czas przejazdu, w jakim stopniu POJAZD zapełnia bufor ronda, tworzy kolejkę samochodów i w zależności od tego - zarządza zmianą świateł, wykonywaną przez SYGNALIZATOR.

SYGNALIZATOR - świeci (jednak to, jak długo trwa czerwone/zielone światło powinno być zależne od DETEKTORA, który jest tutaj nie od parady) :)
Nawet jeśli jest to nie może mieć JEDŹ i STÓJ, chyba, że system steruje pojazdem i wysyła mu jakieś sygnały. Zadanie jest proste, przykład jest OK tylko wykonanie absolutnie nie na temat.
Link do wypowiedziLink
Jarosław Żeliński

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Olga Makushenko:
Ale jak mam zmodelować system, sterujący sygnalizacją świetlną skrzyżowania drogowego z ruchem okrężnym posługując się tylko tymy tzema aktorami i nie wchodząc w szczegóły ??

UML to kilkanascie typow diagramow, to nie jest przypadek ze jest ich tyle....
diagram UC to TYLKO funcjonalnosci a nie PROJEKT. Do projektowania sa inne diagramy.... duzym bledem jest niestety proba projektowania z pomoca UC bo to tak jak by probowac projektowac telewizor z pomoca jego zdjec.. owszem moza - tylko wyglad klawiszy.
Link do wypowiedziLink
Jarosław Żeliński

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Olga Makushenko:
nie jest to zwykły diagram przypadków, tylko diagram, który pokazuje jeszcze specyfikację działania.

to postrzegam jako jego glowna wade wlasnie...
(Obrazek №2). Martwi mnie jednak jego złożoność =(

nadmierna zlozonosc diagramu to pierwszy sygnal, ze cos z nim nie tak... sugeruje podzial dziedzinowy na pakiety i podsystemy ale to nie bedzie diagram UCJarek Żeliński edytował(a) ten post dnia 09.07.10 o godzinie 13:24
Link do wypowiedziLink
Mateusz Kurleto

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

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Żeliński:
Olga Makushenko:
nie jest to zwykły diagram przypadków, tylko diagram, który pokazuje jeszcze specyfikację działania.

to postrzegam jako jego glowna wade wlasnie...
(Obrazek №2). Martwi mnie jednak jego złożoność =(

nadmierna zlozonosc diagramu to pierwszy sygnal, ze cos z nim nie tak... sugeruje podzial dziedzinowy na pakiety i podsystemy ale to nie bedzie diagram UCJarek Żeliński edytował(a) ten post dnia 09.07.10 o godzinie 13:24
Przecież to można zamknąć w 10-15 UC. Zaraz mnie sprowokujecie żebym to zrobił:P
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj