Temat: Scenariusze w diagramach UML

Jakub Płachecki:

Jarek Żeliński:
@Stanisław
Jeżeli zadałeś te wszystkie pytania dla jaj z okazji weekendu to rozumiem, jeżeli zaś pytania są jednak poważnie zadane to ich ilość i treść sugeruje mi, że powinienem Ci polecić jakieś szkolenie lub książki, ale nie moje żeby było Ci łatwiej..

Szczerze powiedziawszy nie wiem, które z pytań zadanych przez Stanisława uważasz za "niegodne"...

nie użyłem słowa "niegodne"

W moim odczuciu większość uwag i pytań jest jak najbardziej sensowna.

ale czytałeś moje odpowiedź na te pytania?
http://www.goldenline.pl/forum/2252034/scenariusze-w-d...

Moje modele dziedzinowe służą jasnemu określeniu pojęć z dziedziny i zależności między nimi. Natomiast na diagramie klas mogą znaleźć się klasy nie odpowiadające żadnemu pojęciu z dziedziny, a wynikające bardziej z kwestii implementacyjnych (różnego rodzaju klasy pomocnicze, interfejsy - oczywiście nie w rozumieniu GUI, itp), zaś w modelu bazy danych mogą pojawić się choćby np. struktury pośrednie służące utworzeniu relacji wiele do wielu (których również w modelu dziedzinowym nie umieszczę).

to akurat kwestia stylu projektowania i nie ma tu zakazów ani nakazów.. ja np. lubie DDD/MVC, tu model dziedziny to klasy odwzorowujące "modelowaną dziedzinę", określenie pojęć i ich zależności to odrębny model pojęciowy lub tak zwana taksonomia, jeden i drugi model tworzy się z użyciem diagramów klas ale każdy z nich co innego opisuje. Możesz podać przykład klasy na modelu dziedziny nie mającej odpowiednika w opisywanej dziedzinie?

Model dziedziny będzie raczej zbiorem klas komunikujących się w celu wykonania zadnia, model pojęciowy to nafaszerowany asocjacjami diagram klas opisujący pojęcia słownikowe i zależności między nimi, chyba że ktoś przenosi na diagram klas i model dziedziny nawyki z diagramów ERD dla relacyjnych baz danych ale tu pakuje się raczej w antywzorce obiektowe...
http://pl.wikipedia.org/wiki/Antywzorzec_projektowy

w szczególności w anemiczny model dziedziny...

Co do "przerywanej strzałki" - nie masz racji Jarku. Tak jak napisał Stanisław jest to związek zależności (dependency), natomiast dopiero jedną z predefiniowanych zależności (via odpowiedni stereotyp) jest użycie.

na diagramie klas domyślną zależnością jest użycie, i można nie stereotypowac tej strzałki. Łatwo to sprawdzić, jeżeli masz jakąkolwiek książkę z wzorcami projektowymi zobaczysz dużo strzałek bez stereotypów i nie za wiele asocjacji na diagramie klas, z diagramów sekwencji jasno widać że to wywołania metod (komunikaty)

Zgodzę się też ze Stanisławem, że wykorzystanie go jako głównego typu związku na diagramie dziedzinowym lub klas, to lekkie nieporozumienie.

jakie pojęcie reprezentuje "zależność" na diagramie klas? Semantycznie klasy (obiekty) od siebie zależą? Komunikują się chyba raczej...

co rozumiesz pod pojęciem "główny typ związku"? Bo chyba nie "najczęściej narysowany".... odsyłam nieco wyżej do antywzorców...

jeżeli celem zamawiającego jest wsparcie danego procesu prze projektowane
oprogramowanie to tak (np. program ma wspierać proces wystawiania faktur,
należy opisać ten proces, najlepiej w postaci modelu).

Odnoszę wrażenie, że pobożnym życzeniem pozostaje taka wiara Klienta w czyjeś kompetencje i pozostawienie przez niego takiej swobody wykonawcy (czy to analizy, czy projektu), by wymagania ograniczyły się do "wsparcia procesu biznesowego" jako takiego, bez żadnych dodatkowych wymagań, uwag i sugestii.

???? a jak inaczej Prezes producenta pampersów ma nazwać to zadanie dla analityka wymagań? Ma mu wylistować od razu przypadki użycia?Jarek Żeliński edytował(a) ten post dnia 26.02.11 o godzinie 21:18

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Jakub Płachecki:

Jarek Żeliński:
@Stanisław
Jeżeli zadałeś te wszystkie pytania dla jaj z okazji weekendu to rozumiem, jeżeli zaś pytania są jednak poważnie zadane to ich ilość i treść sugeruje mi, że powinienem Ci polecić jakieś szkolenie lub książki, ale nie moje żeby było Ci łatwiej..

Szczerze powiedziawszy nie wiem, które z pytań zadanych przez Stanisława uważasz za "niegodne"...

nie użyłem słowa "niegodne"

Nie twierdzę, że użyłeś - cudzysłów pojawił się, bo czasem po prostu go używam, szczególnie jeśli jakieś słowo jest swego rodzaju przenośnią, albo celowo wyolbrzymione :-) W każdym razie nie było moim celem wskazanie, że odwołuję się do jakiegoś Twojego komentarza.

W moim odczuciu większość uwag i pytań jest jak najbardziej sensowna.

ale czytałeś moje odpowiedź na te pytania?
http://www.goldenline.pl/forum/2252034/scenariusze-w-d...

Czytałem. Nie na wszystkie pytania decydujesz się odpowiedzieć, nie do wszystkich uwag się odnosisz. Twój wybór ;-)

Moje modele dziedzinowe służą jasnemu określeniu pojęć z dziedziny i zależności między nimi. Natomiast na diagramie klas mogą znaleźć się klasy nie odpowiadające żadnemu pojęciu z dziedziny, a wynikające bardziej z kwestii implementacyjnych (różnego rodzaju klasy pomocnicze, interfejsy - oczywiście nie w rozumieniu GUI, itp), zaś w modelu bazy danych mogą pojawić się choćby np. struktury pośrednie służące utworzeniu relacji wiele do wielu (których również w modelu dziedzinowym nie umieszczę).

to akurat kwestia stylu projektowania i nie ma tu zakazów ani nakazów.. ja np. lubie DDD/MVC, tu model dziedziny to klasy odwzorowujące "modelowaną dziedzinę", określenie pojęć i ich zależności to odrębny model pojęciowy lub tak zwana taksonomia, jeden i drugi model tworzy się z użyciem diagramów klas ale każdy z nich co innego opisuje.

Mógłbym prosić o przedstawienie różnic między modelem pojęciowym a dziedzinowym w takim razie?

Możesz podać przykład klasy na modelu dziedziny nie mającej odpowiednika w
opisywanej dziedzinie?

Nie mogę, bo w związku z tym co pisałem odnośnie moich modeli dziedzinowych, każda klasa z modelu dziedzinowego (ale niekoniecznie już z projektowego modelu klas) reprezentuje jakiś element / pojęcie z opisywanej dziedziny.

Model dziedziny będzie raczej zbiorem klas komunikujących się w celu wykonania zadnia, model pojęciowy to nafaszerowany asocjacjami diagram klas opisujący pojęcia słownikowe i zależności między nimi

Z tym drugim się zgodzę, a co do modelu dziedziny, to uważam, że masz na myśli projektowy model klas, który wywodzi się z modelu dziedzinowego / pojęciowego.

chyba że ktoś przenosi na diagram klas i model dziedziny nawyki z diagramów ERD dla relacyjnych baz danych ale tu pakuje się raczej w antywzorce obiektowe...
http://pl.wikipedia.org/wiki/Antywzorzec_projektowy

Nie bardzo wiem a propos czego wspominasz przenoszenie na projektowy model klas i model dziedziny (przedstawiane notabene na diagramie klas) nawyki z diagramów ERD. Poza tym uważam, że określanie liczności w modelu dziedzinowym / pojęciowym nie jest nawykiem złym.

Co do "przerywanej strzałki" - nie masz racji Jarku. Tak jak napisał Stanisław jest to związek zależności (dependency), natomiast dopiero jedną z predefiniowanych zależności (via odpowiedni stereotyp) jest użycie.

na diagramie klas domyślną zależnością jest użycie, i można nie stereotypowac tej strzałki. Łatwo to sprawdzić, jeżeli masz jakąkolwiek książkę z wzorcami projektowymi zobaczysz dużo strzałek bez stereotypów i nie za wiele asocjacji na diagramie klas, z diagramów sekwencji jasno widać że to wywołania metod (komunikaty)

Nie spotkałem się z diagramem klas wykorzystanym jako model dziedzinowy lub projektowy model klas, na którym dominowałyby zależności (jako użycia), a asocjacji byłoby "nie za wiele". Takie twierdzenia odbieram w kategoriach herezji :-)

Zgodzę się też ze Stanisławem, że wykorzystanie go jako głównego typu związku na diagramie dziedzinowym lub klas, to lekkie nieporozumienie.

jakie pojęcie reprezentuje "zależność" na diagramie klas? Semantycznie klasy (obiekty) od siebie zależą? Komunikują się chyba raczej...

Nie reprezentuje żadnego sensownego właśnie. Jej użycie w takim kontekście, w celu pokazania komunikacji między klasami, najczęściej jest błędem. Odsyłam np. do diagramu modelu dziedzinowego w specyfikacji superstruktury UML 2.3, np. str. 435 lub 604.

co rozumiesz pod pojęciem "główny typ związku"? Bo chyba nie "najczęściej narysowany".... odsyłam nieco wyżej do antywzorców...

Odsyłasz do antywzorców chyba tylko dlatego, że sam uważasz zagadnienia, do których się odnosisz, takimi właśnie antywzorcami. Ja pozwolę sobie odesłać do antywzorców Ciebie :-)

jeżeli celem zamawiającego jest wsparcie danego procesu prze projektowane
oprogramowanie to tak (np. program ma wspierać proces wystawiania faktur,
należy opisać ten proces, najlepiej w postaci modelu).

Odnoszę wrażenie, że pobożnym życzeniem pozostaje taka wiara Klienta w czyjeś kompetencje i pozostawienie przez niego takiej swobody wykonawcy (czy to analizy, czy projektu), by wymagania ograniczyły się do "wsparcia procesu biznesowego" jako takiego, bez żadnych dodatkowych wymagań, uwag i sugestii.

???? a jak inaczej Prezes producenta pampersów ma nazwać to zadanie dla analityka wymagań? Ma mu wylistować od razu przypadki użycia?

Wymagania mogą wynikać także, a może przede wszystkim, z procesu. Proces jako taki nie jest wymaganiem. Nie wspominam już tu o wymaganiach pozafunkcjonalnych, które z procesem mogą mieć bardzo niewiele wspólnego.Jakub Płachecki edytował(a) ten post dnia 26.02.11 o godzinie 22:37

Temat: Scenariusze w diagramach UML

Jakub Płachecki:

ale czytałeś moje odpowiedź na te pytania?
http://www.goldenline.pl/forum/2252034/scenariusze-w-d...

Czytałem. Nie na wszystkie pytania decydujesz się odpowiedzieć, nie do wszystkich uwag się odnosisz. Twój wybór ;-)

odniosłem się do wszystkich, pytania o narzędzia CASE odpuściłem wskazując opis dostawcy pakietu VP

Mógłbym prosić o przedstawienie różnic między modelem pojęciowym a dziedzinowym w takim razie?

link do mojego artykuły powyżej, ogólnie model pojęciowy to taksonomia zaś model dziedziny wzorca MVC to model realizacyjny, co nieco także tu:
http://www.ipipan.eu/staff/k.subieta/artykuly/Obiektow...

i w moim blogu w linkowanym artykule..

Możesz podać przykład klasy na modelu dziedziny nie mającej odpowiednika w
opisywanej dziedzinie?

Nie mogę, bo w związku z tym co pisałem odnośnie moich modeli dziedzinowych, każda klasa z modelu dziedzinowego (ale niekoniecznie już z projektowego modelu klas) reprezentuje jakiś element / pojęcie z opisywanej dziedziny.

bez powołania się na jakieś wzorce nie dogadamy się chyba, dlatego proponuję za bazę przyjąć MVC, bazę chyba większości obecnych frameworków... jeśli się zgodzisz..

Model dziedziny będzie raczej zbiorem klas komunikujących się w celu wykonania zadnia, model pojęciowy to nafaszerowany asocjacjami diagram klas opisujący pojęcia słownikowe i zależności między nimi

Z tym drugim się zgodzę, a co do modelu dziedziny, to uważam, że masz na myśli projektowy model klas, który wywodzi się z modelu dziedzinowego / pojęciowego.

kwestia przyjętej metody i nazewnictwa, powyższe o MVC chyba wyjaśnia to...

chyba że ktoś przenosi na diagram klas i model dziedziny nawyki z diagramów ERD dla relacyjnych baz danych ale tu pakuje się raczej w antywzorce obiektowe...
http://pl.wikipedia.org/wiki/Antywzorzec_projektowy

Nie bardzo wiem a propos czego wspominasz przenoszenie na projektowy model klas i model dziedziny (przedstawiane notabene na diagramie klas) nawyki z diagramów ERD. Poza tym uważam, że określanie liczności w modelu dziedzinowym / pojęciowym nie jest nawykiem złym.

nie chodzi o liczności a o nadużywanie łączenia klas asocjacjami tak jak na diagramach ERD, diagram klas to nie model danych.

Nie spotkałem się z diagramem klas wykorzystanym jako model dziedzinowy lub projektowy model klas, na którym dominowałyby zależności (jako użycia), a asocjacji byłoby "nie za wiele". Takie twierdzenia odbieram w kategoriach herezji :-)

no to mamy różne sposoby projektowania, a wzorce projektowe polecam bardzo poważnie... i absolutnie bez złośliwości

Nie reprezentuje żadnego sensownego właśnie. Jej użycie w takim kontekście, w celu pokazania komunikacji między klasami, najczęściej jest błędem. Odsyłam np. do diagramu modelu dziedzinowego w specyfikacji superstruktury UML 2.3, np. str. 435 lub 604.

nie wiem jak rozumieć "najczęściej" bo do tego ta strzałka służy, inna sprawa, ze używa się jej do pokazania kontekstu a nie "wszystkich" odwołań bo diagram byłby nieczytelny.. specyfikacje znam i nie dopatrzyłem się sprzeczności z tym co napisałem... podaj link do pliku bo w moim pdf'ie nic takiego nie znalazłem

co rozumiesz pod pojęciem "główny typ związku"? Bo chyba nie "najczęściej narysowany".... odsyłam nieco wyżej do antywzorców...

Odsyłasz do antywzorców chyba tylko dlatego, że sam uważasz zagadnienia, do których się odnosisz, takimi właśnie antywzorcami. Ja pozwolę sobie odesłać do antywzorców Ciebie :-)

a konkretnie o co chodzi? polecam antywzorzec anemicznego modelu dziedziny by poprzeć tezę, że model dziedziny nafaszerowany prostymi klasami i dużą ilością asocjacji jest bliski diagramom ERD co jest postrzegane (i zgadzam się z tym) jako zły sposób modelowania dziedziny systemu, a Ty co masz na myśli?

Wymagania mogą wynikać także, a może przede wszystkim, z procesu. Proces jako taki nie jest wymaganiem. Nie wspominam już tu o wymaganiach pozafunkcjonalnych, które z procesem mogą mieć bardzo niewiele wspólnego.

w kwestii wymagań, metod ich definiowania jest wiele i chyba nie rozstrzygniemy tu jak je pisać,

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Nie reprezentuje żadnego sensownego właśnie. Jej użycie w takim kontekście, w celu pokazania komunikacji między klasami, najczęściej jest błędem. Odsyłam np. do diagramu modelu dziedzinowego w specyfikacji superstruktury UML 2.3, np. str. 435 lub 604.

nie wiem jak rozumieć "najczęściej" bo do tego ta strzałka służy, inna sprawa, ze używa się jej do pokazania kontekstu a nie "wszystkich" odwołań bo diagram byłby nieczytelny.. specyfikacje znam i nie dopatrzyłem się sprzeczności z tym co napisałem... podaj link do pliku bo w moim pdf'ie nic takiego nie znalazłem

http://www.omg.org/spec/UML/2.3/Superstructure/PDF/

Chyba jednak na innych falach nadajemy :-)

Temat: Scenariusze w diagramach UML

Jakub Płachecki:

Jarek Żeliński:

Nie reprezentuje żadnego sensownego właśnie. Jej użycie w takim kontekście, w celu pokazania komunikacji między klasami, najczęściej jest błędem. Odsyłam np. do diagramu modelu dziedzinowego w specyfikacji superstruktury UML 2.3, np. str. 435 lub 604.

nie wiem jak rozumieć "najczęściej" bo do tego ta strzałka służy, inna sprawa, ze używa się jej do pokazania kontekstu a nie "wszystkich" odwołań bo diagram byłby nieczytelny.. specyfikacje znam i nie dopatrzyłem się sprzeczności z tym co napisałem... podaj link do pliku bo w moim pdf'ie nic takiego nie znalazłem

http://www.omg.org/spec/UML/2.3/Superstructure/PDF/

Chyba jednak na innych falach nadajemy :-)

wygląda na to, że tak, wskazane przez Ciebie strony opisują metamodel i elementy semantyki, np. zależność jest jawnie opisana jako relacja client/suplayer czyli na diagramie klas wywołanie usług (metod). Relacje na diagramach klas na które wskazałeś definiują związki semantyczne (co jest tam explicite napisane w podpisie) a nie elementy oprogramowania, jeżeli z pomocą UML modelujemy kod oprogramowania narzuca to pewną pragmatykę na stosowana notację. ten sam diagram klas może obrazować:
- związki pomiędzy słowami języka polskiego np. obiekty żona i mąż są powiązane asocjacją jeden do jednego, semantyka asocjacji tu to wskazanie, że relacja jest trwała i dopuszcza w tej parze pojedyncze egzemplarze żony i męża
- systematykę w biologii np. pies jest typem (specjalizacją) ssaka (z biologii wyrósł zresztą termin taksonomia)
- wreszcie związki pomiędzy obiektami w obiektowym projekcie systemu: pozycja zamówienia jest zagregowana ze swoim zamówieniem.

ogólnie:

działający program do "dialogi" pomiędzy obiektami, wymiana komunikatów (zależność użycia) a nie kłębek powiązanych niteczkami (asocjacje) martwych przedmiotów (patrz antywzorzec anemiczny model dziedziny)

polecam np.
http://en.wikipedia.org/wiki/Design_pattern_(computer_...

nie ma sensu ciągnąć tego wątku bo wkraczamy w kwestie gustu: stylu projektowania.

W kwestii scenariuszy temat chyba wyczerpałem, jeżeli uznać, że scenariusz to opis jakiejś sekwencji działań (z ewentualnymi wariantami) to w modelowaniu oprogramowania w zasadzie mamy scenariusze realizacji obsługi zdarzeń inicjowanych przez aktora lub inny system (przypadki użycia) ale nie koniecznie (np. demon czasu itp.).

Faktycznie zignorowałem jedno pytanie kolegi Niepostyna: co to jest testowanie diagramów/modeli. Cóż, tu za mało miejsca, polecam książki a klasycznej analizie systemowej (np. Findeisen)
http://archiwumallegro.pl/analiza_systemowa_podstawy_i...

albo tu:
http://mfiles.pl/pl/index.php/Analiza_systemowa

otóż tworzenie modeli i nietestowanie ich to jakiś dziwny zwyczaj tworzenia nikomu nieprzydatnych obrazków... a analiza systemowa to PRZEDE WSZYSTKIM tworzenie i testowanie modeli w celu oceny skutków i wariantów.

to dlatego odesłałem na jakiś kurs lub do książek, forum to miejsce na wymianę poglądów a nie na darmowe szkolenia e-learningowe, jakoś nie czuje potrzeby pisania książki czy cytowania tu dziesiątek stron literatury, podaję czasem tytuł i autora bo do tego mi służy forum dyskusyjne...

osobiście nie widzę nic złego w tym, że różne osoby tworzą różne produkty analiz i projektów, różnie interpretując i używając tej czy innej notacji, notacja (tu UML) to słownik i gramatyka, powołujesz, wybacz ale powoływanie się na tylko specyfikacje języka podczas dyskusji o stylu pisania wierszy nic nie wnosi (poza błędami gramatycznymi), należy poznać wielkich poetów i wyrobić sobie własne poglądy. Dlatego na mojej półce są książki Erica Evansa, Martina Fowlera, E.Yourdona, i podobnych. Mam także podręczniki o RUP, w tym także pozycje Pana Kruchtena ale to rzemiosło, warte poznania.

Osobiście nie jestem zwolennikiem maskowania braku kompetencji deklarowaną pracochłonnością (ilością zadrukowanego papieru) dlatego mnie osobiście wręcz oburza jak ktoś pisze, że wygenerował setki stron tylko w celu wystawienia faktury czy powiększenia jej wartości. To skrajny brak szacunku dla klienta, który płaci w dobrej wierze za umiejętności eksperta a nie za generator raportów. To także psucie opinii branży doradztwa.

Co do jakości modeli to dla mnie miernikiem jakości mojej pracy (każdego projektanta) jest różnica pomiędzy projektem a ostatecznym produktem (ale już to chyba napisałem tu gdzieś).Jarek Żeliński edytował(a) ten post dnia 27.02.11 o godzinie 10:12

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Jakub Płachecki:

Jarek Żeliński:

Nie reprezentuje żadnego sensownego właśnie. Jej użycie w takim kontekście, w celu pokazania komunikacji między klasami, najczęściej jest błędem. Odsyłam np. do diagramu modelu dziedzinowego w specyfikacji superstruktury UML 2.3, np. str. 435 lub 604.

nie wiem jak rozumieć "najczęściej" bo do tego ta strzałka służy, inna sprawa, ze używa się jej do pokazania kontekstu a nie "wszystkich" odwołań bo diagram byłby nieczytelny.. specyfikacje znam i nie dopatrzyłem się sprzeczności z tym co napisałem... podaj link do pliku bo w moim pdf'ie nic takiego nie znalazłem

http://www.omg.org/spec/UML/2.3/Superstructure/PDF/

Chyba jednak na innych falach nadajemy :-)

wygląda na to, że tak, wskazane przez Ciebie strony opisują metamodel i elementy semantyki, np. zależność jest jawnie opisana jako relacja client/suplayer czyli na diagramie klas wywołanie usług (metod). Relacje na diagramach klas na które wskazałeś definiują związki semantyczne (co jest tam explicite napisane w podpisie) a nie elementy oprogramowania, jeżeli z pomocą UML modelujemy kod oprogramowania narzuca to pewną pragmatykę na stosowana notację. ten sam diagram klas może obrazować:
- związki pomiędzy słowami języka polskiego np. obiekty żona i mąż są powiązane asocjacją jeden do jednego, semantyka asocjacji tu to wskazanie, że relacja jest trwała i dopuszcza w tej parze pojedyncze egzemplarze żony i męża
- systematykę w biologii np. pies jest typem (specjalizacją) ssaka (z biologii wyrósł zresztą termin taksonomia)
- wreszcie związki pomiędzy obiektami w obiektowym projekcie systemu: pozycja zamówienia jest zagregowana ze swoim zamówieniem.

Wskazałem Ci diagramy klas przedstawiające model dziedzinowy, opisane jako model dziedzinowy, zawierające asocjacje jako związki między klasami (a nie zależności). Bez różnicy, co one opisują, chodzi o sposób zastosowania. A Twoja odpowiedź jest niekonkretna, zbyt ogólna i rozwlekła, chyba tylko po to, by coś zamaskować ;-)

W każdym razie na tyle, na ile weń weszliśmy, temat chyba można uznać za rozwinięty w satysfakcjonujący sposób, więc pozwolę sobie go już nie kontynuować :-)

Pozdrawiam,
Jakub

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Wskazałem Ci diagramy klas przedstawiające model dziedzinowy, opisane jako model dziedzinowy, zawierające asocjacje jako związki między klasami (a nie zależności). Bez różnicy, co one opisują, chodzi o sposób zastosowania.

ja własnie chciałem zwrócić uwagę na to, że ta różnica jednak istnieje i jest istotna... literki i kropki w teście są zawsze tymi samymi literkami i kropkami ale teksty z nich złożone są różne

A Twoja odpowiedź jest niekonkretna, zbyt ogólna i rozwlekła, chyba tylko po to, by coś zamaskować ;-)

skoro tak to odbierasz.. to nie ja chwaliłem się, że naciągam ludzi na ilość stron... i ja na razie tylko ja pokazałem swój a nie tylko cudze diagramy... cytować cudze łatwo...

W każdym razie na tyle, na ile weń weszliśmy, temat chyba można uznać za rozwinięty w satysfakcjonujący sposób, więc pozwolę sobie go już nie kontynuować :-)

ja takżeJarek Żeliński edytował(a) ten post dnia 27.02.11 o godzinie 11:19

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Wskazałem Ci diagramy klas przedstawiające model dziedzinowy, opisane
jako model dziedzinowy, zawierające asocjacje jako związki między klasami (a nie zależności). Bez różnicy, co one opisują, chodzi o > > sposób zastosowania.

Jarek Żeliński:
ja własnie chciałem zwrócić uwagę na to, że ta różnica jednak istnieje i
jest istotna... literki i kropki w teście są zawsze tymi samymi literkami > i kropkami ale teksty z nich złożone są różne

Ale używa się tych literek i kropek w określony sposób (mówi o tym np. gramatyka, ortografia, interpunkcja), niezależnie od tego, co się chce powiedzieć. Dlatego piszę, że podałem przykłady diagramów klas reprezentujących model dziedzinowy i nie ma znaczenia (w przeciwieńśtwie do tego, co Ty piszesz), jaki (lub czego) model dziedzinowy reprezentują.

Jarek Żeliński:
skoro tak to odbierasz.. to nie ja chwaliłem się, że naciągam ludzi na ilość stron... i ja na razie tylko ja pokazałem swój a nie tylko cudze diagramy... cytować cudze łatwo...

Jeśli sugerujesz, że to ja się czymś takim chwaliłem, to pomyliłeś osoby :-)Jakub Płachecki edytował(a) ten post dnia 27.02.11 o godzinie 11:37

Temat: Scenariusze w diagramach UML

Jarek Żeliński:
ogólnie:

działający program do "dialogi" pomiędzy obiektami, wymiana komunikatów (zależność użycia) a nie kłębek powiązanych niteczkami (asocjacje) martwych przedmiotów (patrz antywzorzec anemiczny model dziedziny)

Zastanawiałeś się kiedyś Jarek jak uruchomiony obiekt "wysyła" komunikat do konkretnego innego obiektu, bądź wywołuje metodę innego konkretnego działającego obiektu ? Czy może komunikat leci gdzieś w powietrze ? A wywołanie metody tez trafia w "zbiorowisko obiektów" ? A "zbiorowisko obiektów" tylko się rozgląda za komunikatami, czy wywołaniami i łapu-capu takie coś "chwyta" i przetwarza, a potem odsyła odpowiedź .... znów w powietrze ???

Faktycznie zignorowałem jedno pytanie kolegi Niepostyna: co to jest testowanie diagramów/modeli. Cóż, tu za mało miejsca, polecam książki a klasycznej analizie systemowej (np. Findeisen)

Testowanie oprogramowania ma za zadanie weryfikację i walidację oprogramowania. Stąd moje pytanie o testowanie modelu na etapie analizy bez uprzedniego zbudowania oprogramowania. Dlatego też wydaje mi się, że pisząc "testowanie" miałeś na myśli weryfikację, bądź walidację modelu, a nie testowanie modelu. Aczkolwiek model można też i zasymulować co się wiąże niestety ale z uzyciem tych nieszczęsnych scenariuszy ...

Osobiście nie jestem zwolennikiem maskowania braku kompetencji deklarowaną pracochłonnością (ilością zadrukowanego papieru) dlatego mnie osobiście wręcz oburza jak ktoś pisze, że wygenerował setki stron tylko w celu wystawienia faktury czy powiększenia jej wartości. To skrajny brak szacunku dla klienta, który płaci w dobrej wierze za umiejętności eksperta a nie za generator raportów. To także psucie opinii branży doradztwa.

Bardzo złośliwa manipulacja.
Ale jak to mam w zwyczaju nie będę na to reagował złośliwościami tylko spokojnie i rzeczowo odpowiem o co tu chodzi.
Weźmy np. 600 stron, podzielmy na 3 i dostajemy co najmniej 200 diagramów opisujących różne aspekty systemu. Praca z taką ilością diagramów w Wordzie praktycznie jest niemożliwa. I tu przychodzi z pomocą np. Sparx, który umożliwia wygenerowanie takiej dokumentacji złożonego i dużego systemu z zachowaniem spójności i kompletności opisu.
Fakt, że może trwac kilka godzin, ale spójność i kompletność jest zachowana. Dlaczego ? Ano dlatego, że poprawianie takiej dokumentacji w Wordzie wymagałoby sporej pracy i orientacji w jakich miejscach co poprawić, gdy dany zagadnienie się zmienia. W narzedziu natomiast zmiana jednego zagadnienia powoduje odpowiednie zmiany we wszystkich prawie referencjach elementów zależnych. Więc łatwiej generować taki duzy dokument dość sporego i złożonego systemu, aniżeli "recznie" wprowadzać poprawki w wymaganiach zmieniane zazwyczaj na ostatnia chwile przez Klienta.

Podsumowując zaś Twój emocjonalny i złośliwy komentarz Jarek wydaje mi się, że nie masz zbytniego doświadczenia w tworzeniu dużych i złożonych systemów. Mam przeczucie jakby Twoja wiedza opierała sie wyłącznie na książkach i to niezbyt aktualnych, co powoduje, że często pod tym samym terminem rozumiemy różne pojęcia. A wszak Informatyka to dość dynamicznie rozwijająca się dziedzina i non-stop trzeba trzymać rękę na pulsie.
Nie będziesz w stanie posuwać się do przodu, jeśli cały czas będziesz trwał w okopach swoich przekonań i twierdził, że masz rację.

Temat: Scenariusze w diagramach UML

Stanisław Niepostyn:
(...) A wszak Informatyka to dość dynamicznie rozwijająca się dziedzina i non-stop trzeba trzymać rękę na pulsie.
Nie będziesz w stanie posuwać się do przodu, jeśli cały czas będziesz trwał w okopach swoich przekonań i twierdził, że masz rację.

Bravissimo, Maestro! :-)
Oddaję pokłon :-)

Temat: Scenariusze w diagramach UML

Stanisław Niepostyn:

Jarek Żeliński:
ogólnie:

działający program do "dialogi" pomiędzy obiektami, wymiana komunikatów (zależność użycia) a nie kłębek powiązanych niteczkami (asocjacje) martwych przedmiotów (patrz antywzorzec anemiczny model dziedziny)

Zastanawiałeś się kiedyś Jarek jak uruchomiony obiekt "wysyła" komunikat do konkretnego innego obiektu, bądź wywołuje metodę innego konkretnego działającego obiektu ? Czy może komunikat leci gdzieś w powietrze ? A wywołanie metody tez trafia w "zbiorowisko obiektów" ? A "zbiorowisko obiektów" tylko się rozgląda za komunikatami, czy wywołaniami i łapu-capu takie coś "chwyta" i przetwarza, a potem odsyła odpowiedź .... znów w powietrze ???

to proste: komunikat to nazwa metody a adresatem jest obiekt mający swoje ID, masz z tym jakiś problem? Jeśli tak to polecam Joshua Bloch "Java Efektywne programowanie". Po drugie jak poznasz kiedyś wzorzec projektowy public/subscribe to się dowiesz, że możliwe jest także "nasłuchiwanie przez zbiorowisko"...

Testowanie oprogramowania ma za zadanie weryfikację i walidację oprogramowania. Stąd moje pytanie o testowanie modelu na etapie analizy bez uprzedniego zbudowania oprogramowania.

widzisz jak ktoś nie potrafi testować modeli to musi dość kosztownie, budując prototyp oprogramowania, testować swoje pomysły na kodzie, jak to się robi? Może jakieś szkolenie z analizy i projektowania? Na początek książki.. wychodzi taniej ale zabiera więcej czasu. Jak masz z tym dla odmiany problem to polecam E.Yourdona Analiza i projektowanie obiektowe.

Dlatego też wydaje mi się, że pisząc "testowanie" miałeś na myśli weryfikację, bądź walidację modelu, a nie testowanie modelu.

miałem na myśli testowanie modelu... do tego służą modele: także do testowania, w przeciwnym wypadku są tylko obrazkami.

Osobiście nie jestem zwolennikiem maskowania braku kompetencji deklarowaną pracochłonnością (ilością zadrukowanego papieru) dlatego mnie osobiście wręcz oburza jak ktoś pisze, że wygenerował setki stron tylko w celu wystawienia faktury czy powiększenia jej wartości. To skrajny brak szacunku dla klienta, który płaci w dobrej wierze za umiejętności eksperta a nie za generator raportów. To także psucie opinii branży doradztwa.

Bardzo złośliwa manipulacja.

jaka manipulacja? podłożyłeś się, to nie ja napisałem, że zarobiłem dodrukowując kilkaset stron z generatora, jeżeli EA tylko do tego Ci służy to cóż...

elementów zależnych. Więc łatwiej generować taki duzy dokument dość sporego i złożonego systemu, aniżeli "recznie" wprowadzać poprawki w wymaganiach zmieniane zazwyczaj na ostatnia chwile przez Klienta.

opisałeś to co potrafi każdy średnio dobry CASE: pilnuje spójności - żadne odkrycie...

wydaje mi się, że nie masz zbytniego doświadczenia w tworzeniu dużych i złożonych systemów. Mam przeczucie jakby Twoja wiedza opierała sie wyłącznie na książkach i to niezbyt aktualnych, co powoduje, że często pod tym samym terminem rozumiemy różne pojęcia.

a ja mam wrażenie, że nie radzisz sobie ze złożonością dużych projektów, który każdy można rozmienić na mniejsze (zaleca to każdy autor książek o analizie i projektowaniu) a różnimy się tym, że ja tu niczego nie udowadniam ani nie demonstruję, także tym, że moje "produkty" są także dla Ciebie dostępne na moim blogu i nie tylko, bo wklejam je nawet tu skoro nie potrafisz nawet kliknąć w mój profil tu na GL.

trudno mi rozmawiać z kimś kto od miesięcy posługuje się jednym autorem kilku książek (Kruchten) i nigdy nie wkleił na forum żadnego kawałka swojej pracy więc wybacz, nie będę się też odnosił do czyjegokolwiek poziomu wiedzy...

A wszak Informatyka to dość dynamicznie rozwijająca się dziedzina i non-stop trzeba trzymać rękę na pulsie.
Nie będziesz w stanie posuwać się do przodu, jeśli cały czas będziesz trwał w okopach swoich przekonań i twierdził, że masz rację.

:) no no no, i mówi to ktoś kto poza Kruchtenem chyba nie ma nic na półce.. nigdzie nie napisałem że mam rację (jakiś cytat???) ja tylko prezentuję fragmenty swojej pracy. Ty zaś stale, np. testowanie modeli, uważasz, że coś czego sam nie potrafisz nie istnieje. Nie zapominaj, że to że ktoś nie widział nigdy czarnego łabędzie nie stanowi żadnego dowodu na jego nieistnienie. W każdym razie ja zawsze testuje swoje modele dzięki czemu ich implementacja wychodzi nie raz za pierwszym razem.

Jeżeli mówić o jakiejkolwiek kompetencji, to jak mówił mój dawny prezes: rynek to zweryfikuje. Zaproś mnie kiedyś na jakąś konferencję lub seminarium gdzie ktoś Ciebie zaprosi w roli prelegenta.

Dla mnie miernikiem tego co potrafię są cudze opinie a nie moje własne, Twoja także, jednak nie zapominaj że wszystkie nasze (Twoje i moje) opinie są czytane i porównywane ze sobą.

pisze to zresztą nie dla Ciebie a dla innych czytających: żeby mieć opinie o potrawach jakiegokolwiek kucharza trzeba często bywać w restauracjach by mieć porównanie, nie wolno jednak zapominać, że o jakości potrawy nie świadczy to w ilu miejscach potrawa jest sprzedawana a to gdzie, chyba ze ktoś jest zwolennikiem fastfoodów...

wyczerpałem wątek....Jarek Żeliński edytował(a) ten post dnia 27.02.11 o godzinie 12:53

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Ale używa się tych literek i kropek w określony sposób (mówi o tym np. gramatyka, ortografia, interpunkcja), niezależnie od tego, co się chce powiedzieć. Dlatego piszę, że podałem przykłady diagramów klas reprezentujących model dziedzinowy i nie ma znaczenia (w przeciwieńśtwie do tego, co Ty piszesz), jaki (lub czego) model dziedzinowy reprezentują.

wybacz ale te modele (na które wskazałeś) opisywały semantyke modeli dziedziny (to był metamodel), a jest to jednak różnica...

Jarek Żeliński:
skoro tak to odbierasz.. to nie ja chwaliłem się, że naciągam ludzi na ilość stron... i ja na razie tylko ja pokazałem swój a nie tylko cudze diagramy... cytować cudze łatwo...

Jeśli sugerujesz, że to ja się czymś takim chwaliłem, to pomyliłeś osoby :-)

tylko jedna osoba się tu tym chwali ;), nie Ty

Temat: Scenariusze w diagramach UML

Jarek Żeliński:

Jakub Płachecki:
Ale używa się tych literek i kropek w określony sposób (mówi o tym np. gramatyka, ortografia, interpunkcja), niezależnie od tego, co się chce powiedzieć. Dlatego piszę, że podałem przykłady diagramów klas reprezentujących model dziedzinowy i nie ma znaczenia (w przeciwieńśtwie do tego, co Ty piszesz), jaki (lub czego) model dziedzinowy reprezentują.

wybacz ale te modele (na które wskazałeś) opisywały semantyke modeli dziedziny (to był metamodel), a jest to jednak różnica...

Różnica w czym? W sposobie wykorzystania notacji do przedstawienia modelu dziedziny? Czy może raczej w tym, jakiej dziedziny model przedstawiamy? Proszę o wskazanie miejsca, z którego dowiem się, że metamodel i związki między jego elementami, przedstawione na diagramie klas, bazują na asocjacjach, a model dziedzinowy / pojęciowy, przedstawiony za pomocą diagramu klas, bazuje na zależnościach stereotypowanych na użycie.

Temat: Scenariusze w diagramach UML

niestety jest różnica pomiędzy modelem a metamodelem

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Różnica w czym? W sposobie wykorzystania notacji do przedstawienia modelu > > dziedziny? Czy może raczej w tym, jakiej dziedziny model przedstawiamy?
Proszę o wskazanie miejsca, z którego dowiem się, że metamodel i związki
między jego elementami, przedstawione na diagramie klas, bazują na
asocjacjach, a model dziedzinowy / pojęciowy, przedstawiony za pomocą
diagramu klas, bazuje na zależnościach stereotypowanych na użycie.

Jarek Żeliński:
niestety jest różnica pomiędzy modelem a metamodelem

To nie jest odpowiedź na moje pytanie. Nie kwestionuję istnienia różnicy. Pytam w czym jest różnica. Czy w sposobie wykorzystania notacji do przedstawienia modelu, czy może raczej w tym, czego model przedstawiamy. Mam też prośbę o wskazanie miejsca, z którego dowiem się, że metamodel i związki między jego elementami, przedstawione na diagramie klas, bazują na asocjacjach, a jakiś inny model dziedzinowy / pojęciowy, przedstawiony za pomocą diagramu klas, bazuje na zależnościach stereotypowanych na użycie (jak twierdzisz). Twoja odpowiedź, którą tu zacytowałem, niestety nic nie mówi o powyższych kwestiach. Liczysz na "zmęczenie materiału"? :-)Jakub Płachecki edytował(a) ten post dnia 27.02.11 o godzinie 16:03

Temat: Scenariusze w diagramach UML

Jakub Płachecki:

Jakub Płachecki:
Różnica w czym? W sposobie wykorzystania notacji do przedstawienia modelu > > dziedziny? Czy może raczej w tym, jakiej dziedziny model przedstawiamy?

Jarek Żeliński:
niestety jest różnica pomiędzy modelem a metamodelem

To nie jest odpowiedź na moje pytanie. Nie kwestionuję istnienia różnicy. Pytam w czym jest różnica. Czy w sposobie wykorzystania notacji do przedstawienia modelu, czy może raczej w tym, czego model przedstawiamy. Mam też prośbę o wskazanie miejsca, z którego dowiem się, że metamodel i związki między jego elementami, przedstawione na diagramie klas, bazują na asocjacjach, a jakiś inny model dziedzinowy / pojęciowy, przedstawiony za pomocą diagramu klas, bazuje na zależnościach stereotypowanych na użycie (jak twierdzisz). Twoja odpowiedź, którą tu zacytowałem, niestety nic nie mówi o powyższych kwestiach. Liczysz na "zmęczenie materiału"? :-)

ja się męczę raczej...;)

metamodel opisuje możliwość użycia i definiuje pojęcia modelu (elementy notacji). Różnice widać tu (UML 2.3 Infrastructure):
- rys. 9.11 ikonka komentarza, znana karteczka z zagiętym rogiem
- ry. 9.10 - metamodel definiujący ten symbol, jego semantyke i syntaktykę

diagram klas to uniwersalne narzędzie, powszechnie stosowane do definiowania systemów pojęciowych i ich składni, nie każdy diagram klas do model dziedziny czy kodu, to najczęściej modele pojęciowe (taksonomie).

Jeżeli więc pytasz w czym różnica to powiem: ogromna (co mam nadzieję widać na wskazanych dwóch powyższych. Dla wielu ludzi problem polega na tym, ze notacja UML jest specyfikowana przy pomocy niej samej (głownie z użyciem diagramów klas do pokazania systemów pojęciowych oraz diagramów pakietów do modelowania przestrzeni nazw. (UML jest czasem określany jako samodefiniujący się)

Oba dokumenty (UML, Infrastructure i Superstrukture) to specyfikacje semantyki i syntaktyki UML, nie ma tam żadnych modeli (nie licząc kilku trywialnych przykładów stosowania poszczególnych symboli).

Z uwagi na to że UML jest opisywany w dokumentacji nim samym modele i meta-modele są często mylone. Ale inny, bardzo obrazowy przykład:

Notacja BPMN, dobrze znana:
to jakis model:




a tu metamodel notacji BPMN:




nie jest to żaden model dziedziny a jedynie definicja semantyki i syntaktyki BPMN, narzędziem jest UML/diagram klas. Metamodele prawie nigdy (albo mało) nie zawierają zależności za to masę asocjacji i dziedziczenia bo to właśnie modele pojęciowe a nie modele kodu oprogramowania.

można powiedzieć, że "konkretny model to instancja metamodelu" (nie pamiętam, z której to książki cytat).

Temat: Scenariusze w diagramach UML

Zdajesz się uparcie unikać odpowiedzi na zadane pytanie. Pytam cały czas, czy czasem różnica między metamodelem, a jakimś konkretnym modelem pojęciowym / dziedzinowym (nie mówię tu o projektowym modelu klas) nie polega tylko na tym, co jest modelowane, a w samym sposobie modelowania różnicy nie ma. Jako, że nie chcesz odpowiedzieć, to sam odpowiem na to pytanie. Różnica polega tylko na modelowanej dziedzinie, a nie polega na sposobie jej modelowania. Co to oznacza? Ano to, że niezależnie, czy będziemy modelować pojęcia / dziedzinę dla zarządzania nieruchomościami, czy dla branży ubezpieczeniowej, czy dziedzinę języka służącego modelowaniu, to użyjemy klas, atrybutów klas (jako cech modelowanych elementów), liczności, asocjacji (jako wyrażenia związków między elementami), itd - czyli wszystkiego tego, co umożliwia określenie semantyki i syntaktyki modelowanych elementów. Podkreślam: NIEZALEŻNIE.

A więc podsumowując: nie ma znaczenia, czy mamy do czynienia z metamodelem (czyli modelem, który opisuje jakiś inny model), czy z instancją tego opisania, więc już konkretnym modelem opisującym jakiś zbiór pojęć i relacji między nimi - sposób wykonania tego opisu przy użyciu UMLa pozostanie ten sam.

A fakt, że UML jest zdefiniowany przy użyciu samego UMLa, jest w moim odczuciu jedną z największych jego zalet i oznaką wręcz wirtuozostwa jego twórców. To jest po prostu piękne :-)

Dziękuję za rozmowę.Jakub Płachecki edytował(a) ten post dnia 27.02.11 o godzinie 20:42

Temat: Scenariusze w diagramach UML

Jarek Żeliński:
można powiedzieć, że "konkretny model to instancja metamodelu" (nie pamiętam, z której to książki cytat).

Modelowanie w ogóle jest 4-warstwowe. Ja to mam w repozytorium swoich materiałów na starym kompie w tygodniu go podłączę i wrzucę parę "slajdów".

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Proszę o wskazanie miejsca, z którego dowiem się, że metamodel i związki między jego elementami, przedstawione na diagramie klas, bazują na asocjacjach, a model dziedzinowy / pojęciowy, przedstawiony za pomocą diagramu klas, bazuje na zależnościach stereotypowanych na użycie.

Model pojęciowy to model obrazujący pojęcia i związki między nimi czyli przede wszystkim asocjacje i dziedziczenie, modele obiektowe oprogramowania obrazują głównie komunikację pomiędzy obiektami. O jakie "miejsce" Ci chodzi? Ściągawkę? Bo ja czytam, pracuję i myślę, ściągawek nie używam... jak mam wątpliwości jak modelować oprogramowanie to pytam dobrych programistów...

Temat: Scenariusze w diagramach UML

Jakub Płachecki:
Zdajesz się uparcie unikać odpowiedzi na zadane pytanie. Pytam cały czas, czy czasem różnica między metamodelem, a jakimś konkretnym modelem pojęciowym / dziedzinowym (nie mówię tu o projektowym modelu klas) nie polega tylko na tym, co jest modelowane

nie, metamodel to modelu modelu...

Różnica polega tylko na modelowanej dziedzinie, a nie polega na sposobie jej modelowania. Co to oznacza? Ano to, że niezależnie, czy będziemy modelować pojęcia / dziedzinę dla zarządzania nieruchomościami, czy dla branży ubezpieczeniowej, czy dziedzinę języka służącego modelowaniu, to użyjemy klas, atrybutów klas (jako cech modelowanych elementów), liczności, asocjacji (jako wyrażenia związków między elementami), itd - czyli wszystkiego tego, co umożliwia określenie semantyki i syntaktyki modelowanych elementów. Podkreślam: NIEZALEŻNIE.

ok, jaki wg. Ciebie związek istnieje pomiędzy nazwiskiem pracownika a osobą wystawiającą fakturę?

A więc podsumowując: nie ma znaczenia, czy mamy do czynienia z metamodelem (czyli modelem, który opisuje jakiś inny model), czy z instancją tego opisania

ma znaczenie... ja dziękuję... idę do pracy.