Temat: Procesy i ich zależności w UML.

Witam,
Nie jestem specem od UML bo miałem go tyle co na uczelni.
Proszę o małą sugestię i słowo wsparcia, w którym z diagramów najwygodniej przedstawić opis działania procesów systemowych.

Nie chodzi tu o procesy organizacyjne a stricte systemowe.
Procesy takie mają jakieś dane na wejściu, te dane są przekazywane do innego procesu w celu przeprowadzenia analiz i operacji, w tamtym procesie znowu to samo, potem to wraca do procesu wstępnego a potem dane na wyjściu idą do procesu końcowego.
Niektóre procesy są odpalane przez CRON'a w systemie a niektóre przez system zewnętrzny.

Wiem, że to dość chaotyczne przedstawienie problemu, ale zwyczajnie nie do końca jestem pewien czy diagram, którym chcę to przedstawić podoła wszystkim zależnościom itd.

Myślałem nad diagramem klas lub/i sekwencji.

Proszę o radę...

Jeszcze raz przepraszam jeśli zasypuję banialukami.

Pozdrawiam
Ł.

Temat: Procesy i ich zależności w UML.

Łukasz W.:
Witam,
Nie jestem specem od UML bo miałem go tyle co na uczelni.
Proszę o małą sugestię i słowo wsparcia, w którym z diagramów najwygodniej przedstawić opis działania procesów systemowych.

Myślę, że da się to zrobić na diagramie aktywności i / lub sekwencji.Jakub Wojt edytował(a) ten post dnia 26.07.12 o godzinie 12:08

Temat: Procesy i ich zależności w UML.

Diagram klas jest statyczny, więc raczej się nie sprawdzi.

Decyzja zależy od tego, jaki stopień szczegółowości. Samo przedstawienie przepływu i ewentualnych decyzji (aktywności), czy może dokładniejsze przedstawienie poszczególnych kroków (sekwencji)Sebastian Malaca edytował(a) ten post dnia 26.07.12 o godzinie 13:32

Temat: Procesy i ich zależności w UML.

A ktoś jest może w stanie polecić insteresujący tutorial do EA? Generalnie jak oglądam te zamieszczone filmiki to walczę by nie zasnąć przy nich. Tak wolno wyjaśniają cokolwiek ;P

Temat: Procesy i ich zależności w UML.

Łukasz W.:
Witam,
Nie jestem specem od UML bo miałem go tyle co na uczelni.
Proszę o małą sugestię i słowo wsparcia, w którym z diagramów najwygodniej przedstawić opis działania procesów systemowych.

podaj definicje pojęcia "proces systemowy".... (mówię poważnie)

Nie chodzi tu o procesy organizacyjne a stricte systemowe.

tym bardziej jak wyżej....

Procesy takie mają jakieś dane na wejściu, te dane są przekazywane do innego procesu w celu przeprowadzenia analiz i operacji, w tamtym procesie znowu to samo, potem to wraca do procesu wstępnego a potem dane na wyjściu idą do procesu końcowego.

to robi "komputer" czy człowiek, jeżeli komputer to nie proces a sekwencja i diagram sekwencji

Niektóre procesy są odpalane przez CRON'a w systemie a niektóre przez system zewnętrzny.

jak wyżej

Wiem, że to dość chaotyczne przedstawienie problemu, ale zwyczajnie nie do końca jestem pewien czy diagram, którym chcę to przedstawić podoła wszystkim zależnościom itd.

co chcesz pokazać?

Myślałem nad diagramem klas lub/i sekwencji.

diagram klas (a konkretnie to jaki model tym diagramem pokażesz), a konkretnie model dziedziny tego systemu i diagram sekwencji, który pokaże dialog obiektów.

Temat: Procesy i ich zależności w UML.

Jarek Żeliński:

Łukasz W.:
Witam,
Nie jestem specem od UML bo miałem go tyle co na uczelni.
Proszę o małą sugestię i słowo wsparcia, w którym z diagramów najwygodniej przedstawić opis działania procesów systemowych.

podaj definicje pojęcia "proces systemowy".... (mówię poważnie)

a ja mam lepsze zadanie ;)

UML - Unified Modeling Language

Co to jest "zunifikowany język", i jaki sensowny (marketing i propaganda odpadają) język nie służy do modelowania ? ;)

Eh... "Unified Modeling Language (UML) is a standardized (btw: interedasting) general-purpose modeling language"
(http://en.wikipedia.org/wiki/Unified_Modeling_Language)

Nie ma języków "ogólnego użytku" :)

UML to w najlepszym wypadku ilustracje rzeczy jakichkolwiek (general purpose).

Masz trudne zadanie Łukaszu i nie ma ono nic wspólnego z inżynierią ... Jakub Wojt edytował(a) ten post dnia 26.07.12 o godzinie 22:03

Temat: Procesy i ich zależności w UML.

a ja mam lepsze zadanie ;)

UML - Unified Modeling Language

Co to jest "zunifikowany język", i jaki sensowny (marketing i propaganda odpadają) język nie służy do modelowania ? ;)

to coś jak język np. polski (tez uniwersalny), do wszystkiego, ale jak ktoś potrafi to wiersz napisze, dobrą książkę, listę zakupów albo np. wymagania na oprogramowanie, zaletą UML jest to, że nie ma wyrazów bliskoznacznych ani synonimów dzięki czemu unikamy nieporozumień i bełkotu :)

UML jak każde narzędzie, wymaga nie tylko wzięcia do ręki ale i sztuki użycia, jak instrument w rękach wirtuoza, język u poety czy toporek i mistrza cieśli....

Temat: Procesy i ich zależności w UML.

Jarek Żeliński:

a ja mam lepsze zadanie ;)

UML - Unified Modeling Language

Co to jest "zunifikowany język", i jaki sensowny (marketing i propaganda odpadają) język nie służy do modelowania ? ;)

to coś jak język np. polski (tez uniwersalny), do wszystkiego

języki programowania powinny być po polsku ...

UML jak każde narzędzie, wymaga nie tylko wzięcia do ręki ale i sztuki użycia, jak instrument w rękach wirtuoza, język u poety czy toporek i mistrza cieśli....

eh... myślę, że tu chodzi głównie o odbiorcę... a nie o, sztukę użycia (?) :|

Temat: Procesy i ich zależności w UML.

Jakub Wojt:

Jarek Żeliński:

a ja mam lepsze zadanie ;)

UML - Unified Modeling Language

Co to jest "zunifikowany język", i jaki sensowny (marketing i propaganda odpadają) język nie służy do modelowania ? ;)

to coś jak język np. polski (tez uniwersalny), do wszystkiego

języki programowania powinny być po polsku ...

UML jak każde narzędzie, wymaga nie tylko wzięcia do ręki ale i sztuki użycia, jak instrument w rękach wirtuoza, język u poety czy toporek i mistrza cieśli....

eh... myślę, że tu chodzi głównie o odbiorcę... a nie o, sztukę użycia (?) :|

a kim jest czytelnik wiersza jak nie jego odbiorcą?

Temat: Procesy i ich zależności w UML.

W skrócie sprawa wygląda tak...
Jest sobie user który wgrywa coś do katalogu. Do katalogu co 10 minut zagląda proces odpalany przez cron'a który te dane przekazuje dalej do innych katalogów. Po przeniesieniu tych plików operują na nich inne procesy i joby a na koniec leci to do bazy danych lub systemów raportowych za pośrednictwem job'ów. :)

Tak więc pomijając to że user dogrywa pliki do przetworzenia i załadunku to dalej operują na nich procesy systemowe, skrypty i joby czyli mechanizmy komputera a nie usera. Są automatyczne :P

Temat: Procesy i ich zależności w UML.

Łukasz W.:
W skrócie sprawa wygląda tak...
Jest sobie user który wgrywa coś do katalogu. Do katalogu co 10 minut zagląda proces odpalany przez cron'a który te dane przekazuje dalej do innych katalogów. Po przeniesieniu tych plików operują na nich inne procesy i joby a na koniec leci to do bazy danych lub systemów raportowych za pośrednictwem job'ów. :)

Jeśli zamieścisz ten opis w ramce, to będziesz mógł nazywać to diagramem UML.

Tak więc pomijając to że user dogrywa pliki do przetworzenia i załadunku to dalej operują na nich procesy systemowe, skrypty i joby czyli mechanizmy komputera a nie usera. Są automatyczne :P

Po prostu pokaż coś ładnego swojemu przełożonemu...

Temat: Procesy i ich zależności w UML.

Łukasz W.:
Witam,
Nie jestem specem od UML bo miałem go tyle co na uczelni.
Proszę o małą sugestię i słowo wsparcia, w którym z diagramów najwygodniej przedstawić opis działania procesów systemowych.

Zależy komu chcesz przedstawić i po co ...

Nie chodzi tu o procesy organizacyjne a stricte systemowe.
Procesy takie mają jakieś dane na wejściu, te dane są przekazywane do innego procesu w celu przeprowadzenia analiz i operacji, w tamtym procesie znowu to samo, potem to wraca do procesu wstępnego a potem dane na wyjściu idą do procesu końcowego.
Niektóre procesy są odpalane przez CRON'a w systemie a niektóre przez system zewnętrzny.

Wiem, że to dość chaotyczne przedstawienie problemu, ale zwyczajnie nie do końca jestem pewien czy diagram, którym chcę to przedstawić podoła wszystkim zależnościom itd.

Dlatego w UML-u używa sie kilku diagramów.
Przy czym jedne pokazuja strukture systemu: diagram klas, obiektów,
a inne zachowanie: diagram aktywności, sekwencji, stanów,
a jeszcze inne funkcje systemu: diagram przypadków uzycia.
nawet we wczesnym UML-u był taki podział diagramów, po czym postanowiono diagram przypadków uzycia wprowadzić do grupy diagramów zachowania systemu.

Myślałem nad diagramem klas lub/i sekwencji.

Proszę o radę...

Jeszcze raz przepraszam jeśli zasypuję banialukami.

Pozdrawiam
Ł.

Tutaj Twoja intuicja dobrze Cię prowadzi :)
By w miarę kompletnie opisac system należałoby opisac jego strukturę, zachowanie i funkcjonalność.
Zakładam, że robisz to dla siebie, bo chcesz sobie poukładac swoją wizję systemu.
I bardzo dobrze :)
Zatem zacznij od przypadków uzycia. Określisz na nim jakie funkcje spełnia Twój system. Co on tak naprawdę robi. Byc może, że po zamodelowaniu funkcjonalności odkryjesz, że przydałoby sie dorobić jakieś funkcjonalności, a inne będą zupełnie niepotrzebne.
Polecam przed i w trakcie rysowania bąbelków okreslić scenariusze (opis co robi aktor, co robi system) dla wszystkich przypadków użycia. Wtedy bedziesz mógł je sensownie zamodelować.
A jeszcze lepiej jak scenariusze zwizualizujesz np. diagramami aktywności, bądź sekwencji.
Na diagramie sekwencji będziesz musiał określić obiekty, a na diagramach aktywności tez przydałoby się je namalować.
I właśnie w oparciu o te obiekty będziesz mógł zamodelowac strukturę systemu, a więc np. diagramy klas.
Dla ważnych klas możesz określić ich diagramy stanów i zweryfikować z wcześniej zamodelowanymi diagramami aktywności/sekwencji, czy ich zachowania sa spójne.
Z diagramu klas skorzysta przede wszystkim człowiek od tworzenia/modyfikacji baz danych, a z diagramów aktywności/sekwencji programiści, natomiast tester zainteresuje sie diagramami przypadków użycia.
Mógłbys jeszcze pare innych diagramów utworzyć jak diagram komponentów, czy wdrożenia, którymi z kolei chłopaki od systemów, czy wdrożeniowcy chetnie by sie zapoznali.
Zatem na upartego mógłbys spokojnie spróbować uzyć niemal wszystkich.
Ale jak napisałem na poczatku zależy dla kogo i po co ....
Miłej zabawy ....

Temat: Procesy i ich zależności w UML.

Łukasz W.:
W skrócie sprawa wygląda tak...
Jest sobie user który wgrywa coś do katalogu. Do katalogu co 10 minut zagląda proces odpalany przez cron'a który te dane przekazuje dalej do innych katalogów. Po przeniesieniu tych plików operują na nich inne procesy i joby a na koniec leci to do bazy danych lub systemów raportowych za pośrednictwem job'ów. :)

Tak więc pomijając to że user dogrywa pliki do przetworzenia i załadunku to dalej operują na nich procesy systemowe, skrypty i joby czyli mechanizmy komputera a nie usera. Są automatyczne :P

To tak w skrócie, rozumiem, że chcesz po prostu pokazać jak to wygląda, ta aktywność, co tam po kolei się dzieje, gdzie co leci? Proponuję użyć diagramów interakcji (sekwencji i/lub komunikacji) lub diag. czynności. Jak by się uparł to można wszystkie użyć.

W diagramie sekwencji główną uwagę skupia się na osi czasu, ładnie można pokazać na nim komunikację między klasyfikatorami tego fragmentu systemu oraz co każdy z nich robi. Bez wyraźnej osi czasu można to pokazać na diagramie komunikacji.

W diagramie czynności ładnie widać przepływ sterowania i można pokazać przepływ obiektów, zwłaszcza, że tworzysz jakieś pliki i je gdzieś przesyłasz, warto pokazać w którym miejscu to się dzieje, a wykorzystując partycje i subpartycie będziesz mógł pokazać kto, co/jakie czynności wykonuje.

Temat: Procesy i ich zależności w UML.

Jak koledzy zauważyli, zależy co chcesz pokazać.. Ja bym dorzucił jeszcze do rozważenia diagram przepływu danych, który co prawda elementem UMLa nie jest, ale daje Ci możliwość przedstawienia tego co dzieje się z danymi, bez pochylania się nad tym w jaki sposób się to dzieje.

Zestaw "narzędzi" masz zasugerowany, zastanów się co chcesz pokazać i wybierz odpowiednie do Twoich intencji :)

Temat: Procesy i ich zależności w UML.

No więc jest i dla siebie i do dokumentacji technicznej, którą 'dziergam'. Więc fajnie by było jak by to jakieś rączki i nóżki miało. Ale dotychczas usłyszałem chyba dość przydatnych informacji. Chwilowo powstał diagram sekwencji do opisu ogólnego w stylu:

Aktor <-> Quota <-> Proces <-> Proces <-> Quota <-> Proces.
Potem to rozbiję na szczegółowe diagramy wewnątrz każdego z procesów/aktorów i powinno stykać.

Chociaż sprawdzając diagram przepływu danych to może to być lepszym sposobem. :)
Ogarnę i się okaże....

Wstępnie
Procesy w systemie - diagram sekwencji
Ogólny zarys - diagram przepływu danych lub podobny

Wielkie dzięki!

Temat: Procesy i ich zależności w UML.

eh... myślę, że tu chodzi głównie o odbiorcę... a nie o, sztukę użycia (?) :|

a kim jest czytelnik wiersza jak nie jego odbiorcą?

Jeśli czytelnik nie zrozumie "co autor miał na myśli" to nie będzie odbiorcą.
Do zrozumienia przekazu nie wystarczy znajomość "gramatyki". Trzeba również wiedzieć jakich zdań używa się w przekazaniu konkretnych informacji. I to też nie wystarczy; potrzebna jest również "kompatybilność" wiedzy osób które coś sobie próbują zakomunikować.

eh...
a jak się okazuje - UML nie definiuje zakresu wymaganej wiedzy; nie definiuje "zdań" (wzorce projektowe są generalnie ignorowane i nie są częścią UML)

Z resztą, według specyfikacji, UML można sobie rozszerzać... to dość zabawne jeśli wziąć pod uwagę fakt, że ludzie którzy sobie "rozszerzają" język polski mają "objawy".

Temat: Procesy i ich zależności w UML.

Pytanie za 100 punktów :)

Czy w diagramie sekwencji.... przydział dyskowy (na którym różne procesy operują danymi) może byc aktorem?

Bo obecnie rozkład aktorów to:

User wrzucający dane // przydział dyskowy a // proces A // proces B // przydział dyskowy b // przydział dyskowy C.

Jako że user wgrywa dane, procesy wyłapują je z katalogu w przydziale dyskowym A i rozrzucają do przydziałów B i C a potem proces B je kompresuje... a inny gdzieś tam proces zasysa je do bazy.

Czy to ma sens? :)

Temat: Procesy i ich zależności w UML.

Łukasz W.:
Pytanie za 100 punktów :)

Czy w diagramie sekwencji.... przydział dyskowy (na którym różne procesy operują danymi) może byc aktorem?

mowa o UML ?
na diagramie sekwencji nie ma aktorów ;)

Bo obecnie rozkład aktorów to:

User wrzucający dane // przydział dyskowy a // proces A // proces B // przydział dyskowy b // przydział dyskowy C.

Jako że user wgrywa dane, procesy wyłapują je z katalogu w przydziale dyskowym A i rozrzucają do przydziałów B i C a potem proces B je kompresuje... a inny gdzieś tam proces zasysa je do bazy.

Czy to ma sens? :)

ymm... nie

ale to
"Jest sobie user który wgrywa coś do katalogu. Do katalogu co 10 minut zagląda proces odpalany przez cron'a który te dane przekazuje dalej do innych katalogów. Po przeniesieniu tych plików operują na nich inne procesy i joby a na koniec leci to do bazy danych lub systemów raportowych za pośrednictwem job'ów. :)"

brzmi całkiem sensownie. :)

Temat: Procesy i ich zależności w UML.

ok, ok :)

Bardziej chodziło o słowne przedstawienie tego co się dzieje (w sensie, że aktorami są procesy, osoba i zasoby(quoty dyskowe)) i info czy zasób dyskowy na którym operują procesy może być aktorem.

Wstępnie chyba przeskoczę na diagram przepływu danych (diagram czynności) a potem pomyślę nad diagramem sekwencji.

Temat: Procesy i ich zależności w UML.

Jakub Wojt:

Łukasz W.:
Pytanie za 100 punktów :)

Czy w diagramie sekwencji.... przydział dyskowy (na którym różne procesy operują danymi) może byc aktorem?

mowa o UML ?
na diagramie sekwencji nie ma aktorów ;)

Od chwili publikacji UML 2.0 w 2005 roku dopuszczono możliwość umieszczania na diagramach, znanych z wersji UML 1.x, dowolnych elementów charakterystycznych dla innych diagramów.
"Charakterystyczne" to takie, dla których w specyfikacji UML 2.x zaproponowano metamodel.
Zatem od 2005 roku mamy metamodel interakcji, w którym brak aktora. Metamodel interakcji pomaga tworzyć m.in. diagramy sekwencji, ale ich nie ogranicza wyłacznie do swojego metamodelu. Diagram sekwencji można więc "upstrzyc" aktorami, use-case'ami, stanami obiektów itd.
Wiem, e ta dualność specyfikacji UML 2.x jest ciężka do ogarnięcia, ale nie bez kozery EA umozliwia własnie taki sposób budowania przeróżnych diagramów UML.