Temat: Pytanie z egzaminu OCUP-100

Stanisław Jerzy N.:

Andrzej S.:

Stanisław Jerzy N.:
[...]
Zatem nic dziwnego, że informacja o osobie Zev wprowadza tyle kłopotu początkującym UML-owcom ;) Niezła zmyła, nieprawdaż :)
Ale z drugiej strony niezły ubaw z "fachowców" :)

W dyskutowanym pytaniu OCUP nie było w nim ani słowa o tym, że chodzi o model systemu _informatycznego_. Skąd się więc wzięły formatki i dziedziczenie uprawnień użytkowników?
Niezła nadinterpretacja prostej w sumie informacji zawartej w pytaniu :-)

Przeczytaj no drogi kolego pierwsze strony standardu UML ...
Ponadto chyba nie za bardzo się orientujesz skąd się wzięły przypadki użycia ???
Fakt, w Polsce zawitały w sumie dopiero około 2000 roku, ale chyba
nie trzeba było zagłębiać się w literaturę "wczesno-UML'ową",
by wiedzieć co to scenariusz, a co to przypadek użycia.

Skąd się wzięły dawno temu przypadki użycia (dalej : PU), a do czego mogą być i są obecnie wykorzystywane, to niezupełnie to samo. Modele PU są z powodzeniem stosowane nie tylko w 'domenie' informatycznej, ale i w biznesowej. Systemem jest wtedy np. firma (organizacja) oferująca różne usługi, a aktorami zewnętrzne podmioty (osoby i inne organizacje) wchodzące z nią w interakcje. I scenariusze PU też mają wtedy swoje zastosowanie.
Pewnie, że takie zastosowanie PU jest dużo rzadsze i najczęściej spotyka się PU w kontekście systemu _informatycznego_. Ale nawet wtedy żadne "nadbudowy", domniemania i dywagacje dot. formatek i uprawnień nie są potrzebne, żeby poprawnie odpowiedzieć na dyskutowane pytanie OCUP.

Co do czytania standardu UML: Przeczytałem pierwsze, drugie i wiele kolejnych stron - może jakieś przeglądnąłem tylko pobieżnie, bo dość dużo tego. Pewnie daleko mi jeszcze do prawdziwego Fachowca, ale odrobiłem zadanie domowe i zacytuję drugie zdanie z pierwszego rozdziału specyfikacji Superstructure (1. Scope), zwracając uwagę na jego koniec (od słów "as well as"):
The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes.

Poruszone wątki wspominkowe (Sygnity, oracle, metodyki strukturalne, IACS itd.) pomijam, bo mają charakter personalny (zresztą w moim przypadku są chybione), a takie pojawiają się zwykle wtedy, gdy brakuje merytorycznych argumentów, i prowadzą dyskusję na manowce.

Zatem Twoje zdziwienie bardzo mnie zdziwiło, toteż życzę zwiększenia wysiłków w kierunku poznawania standardu UML ... :)

Odwzajemniam życzenia :-). Zdobywania wiedzy nigdy dość.

Temat: Pytanie z egzaminu OCUP-100

Jakub W.:

[...] Każdy diagram prezentuje pewien model.
Należy jednak rozgraniczyć model i formę jego zapisu. Jeden model można zapisać na wiele sposobów co sugerowałoby, że sam model jest niezależny od języka zapisu.

Tego nie do końca rozumiem. Co oznacza "forma zapisu"?

"Tworzenie modeli w UML" jest po prostu za dużym uproszczeniem. Model tworzy się w głowie (czasem proces tworzenia użytecznego nazywa się analizą ;), a w UML co najwyżej się go zapisuje (modeluje).

UML jak każdy "język" służy do wyrażania (komunikowania na zewnątrz) modeli "tworzonych w głowie", ale już ich konstruowanie w głowie też wymaga użycia jakiegoś "języka".
Zauważyłeś może, że nawet kiedy myślisz o czymś _sam_ (tylko analizujesz coś w swojej głowie, nie artykułujesz tego w mowie lub piśmie), to konstruujesz swoje myśli z użyciem jakiegoś języka naturalnego - najczęściej Twojego ojczystego, czyli tego którego używasz na co dzień. Twoje myśli "składają się" z konceptów występujących w tym języku.
UML oczywiście nie jest na tyle zaawansowanym językiem, żeby można z jego pomocą formułować w głowie wszelakie myśli. Dlatego bogaty model powstający w głowie w trakcie analizy jakiegoś tematu z użyciem rodzimego języka naturalnego trzeba przekonwertować/przetłumaczyć na bardzo uproszczony model wyrażony jedynie koncepcjami występującymi w UML (i zapisać w tej formie).
Jest to coś podobnego do tłumaczenia z języka polskiego na angielski - trzeba swoje polskie myśli przełożyć na inne koncepty językowe, np. stwierdzenie sytuacji wyrażone zdaniem w czasie teraźniejszym dokonanym przełożyć na zdanie present perfect :-)
BTW Ci, którym jest dana znakomita znajomość języka angielskiego nie muszą robić tego tłumaczenia - oni w razie potrzeby od razu "myślą po angielsku". I moim zdaniem jest w tym potocznym powiedzeniu głęboki i dosłowny sens.

A czy możemy też w razie potrzeby od razu "myśleć po UML-owemu"? ...

Poza tym w przytoczonym opisie egzaminu jest wyraźnie napisane, że chodzi o tworzenie modeli - nie diagramów. ( "[...] construct and work with simple UML *models*" )

To ja czegoś nie rozumiem - żeby opisywać modele w UML trzeba najpierw ten język (UML) znać ...

Zakładając, że przez "opisywanie modeli w UML" rozumiesz "wyrażanie modeli w UML", to
jest dokładnie tak jak napisałeś. Żeby wyrazić jakąś wiedzę/myśl w języku polskim też trzeba ten język najpierw znać :-)

Temat: Pytanie z egzaminu OCUP-100

nie polemizując z powyższym dodam ważną rzecz; porównywanie UML z językiem mówionym (angielski czy polski) ma ograniczone zastosowanie, bp notacje takie jak UML mają za cele miedzy innymi wyeliminowanie wieloznaczności "języków mówionych, nieformalnych". Każdy język naturalny ma ogrom wyjątków od reguł (semantyki i syntaktyki) bo na tym polega jego moc ekspresji i kontekstów. Modelowanie np. w UML ma sens, jeżeli jeżeli tych niejednoznaczności nie ma bo taki jest cel komunikacyjny modeli. Tu ujawnia się błąd w postaci "użyje wszystkich symboli jakich się nauczyłem" oraz drugi w postaci "symbole wystarczą, kontekst nie potrzebny". te wątek - to jest treść pytania egzaminacyjnego - jest moim zdaniem dobitnym przykładem tego drugiego błędu, dla mnie co gorsza: to egzamin! międzynarodowy a tu spodziewał bym się czegoś więcej niż systemu testów znanych z naszych rodzimych egzaminów na prawo jazdy, no chyba, że te egzaminy to skok na kasę egzaminowanych ;)

Temat: Pytanie z egzaminu OCUP-100

"Zev works as the librarian at the local library. He can also borrow books as an ordinary library
patron. How many actors are needed when modeling people like Zev in a use case diagram?"

A. 1 actor
B. 2 unconnected actors
C. 1 actor and 1 external system
D. 2 actors connected by a generalization

napisałem że sugeruje 1 aktora to może wyjaśnię dlaczego:

Treść opisu zawiera explicite tylko jeden przypadek użycia (pogrubienie) "wypożyczenie książki", jeżeli podejdziemy do takiej analizy uznając, że aktor to rola a nie osoba czy stanowisko, to powyższy opis zawiera role/aktora "wypożyczający książki" lub po protu "czytelnik". Bibliotekarza, jako rolę/aktora, ignoruję gdyż w treści nie ma przypadku użycia w rodzaju "wypożyczenie książki czytelnikowi", owszem można się domyślać, że taka rola - bibliotekarz - istnieje, ale to domysły, których analityk powinien się wystrzegać. Być może intencją autora testu było domyślenie się, że biblioteka to aktor "czytelnik", aktor "bibliotekarz", nie łączymy niczym tych aktorów, i mamy dwa przypadki użycia: "wypożyczenie (wydanie) książki z biblioteki" i "wypożyczenie książki przez czytelnika".

Problem? Domysły.

Idąc dalej, odpowiedź C. sugeruje, że jednak chodzi o System Dla Biblioteki więc wersja prawdopodobna: oprogramowanie powstaje dla biblioteki więc czytelnik nie jest w ogóle aktorem tego Systemu a jedynie Bibliotekarz, podobnie jak klient sklepu spożywczego nie jest aktorem oprogramowania kasy komputerowej. Co tylko powoduje, że to pytanie jest bez sensu, jeżeli nie mamy kontekstu.

Na mój rozum i domysły: jeden aktor oprogramowanie wspomagającego wypożyczanie książek z biblioteki, i jest nim bibliotekarz a nie czytelnik.

Moje domysły mogły iść dalej, np. w kierunku samoobsługi czytelnika, ale tu także byłby jeden aktor: samoobsługujący się czytelnik :).

Temat: Pytanie z egzaminu OCUP-100

[...] Kazdy diagram prezentuje pewien model.
Nalezy jednak rozgraniczyc model i forme jego zapisu. Jeden model mozna zapisac na wiele sposobów co sugerowaloby, ze sam model jest niezalezny od jezyka zapisu.

Tego nie do konca rozumiem. Co oznacza "forma zapisu"?

Jezyk / notacja. ;)

"Tworzenie modeli w UML" jest po prostu za duzym uproszczeniem. Model tworzy sie w glowie (czasem proces tworzenia uzytecznego nazywa sie analiza ;), a w UML co najwyzej sie go zapisuje (modeluje).

UML jak kazdy "jezyk" sluzy do wyrazania (komunikowania na zewnatrz) modeli "tworzonych w glowie", ale juz ich konstruowanie w glowie tez wymaga uzycia jakiegos "jezyka".
Zauwazyles moze, ze nawet kiedy myslisz o czyms _sam_ (tylko analizujesz cos w swojej glowie, nie artykulujesz tego w mowie lub pismie), to konstruujesz swoje mysli z uzyciem jakiegos jezyka naturalnego - najczesciej Twojego ojczystego,
czyli tego którego uzywasz na co dzien.

Zgoda, ale te mysli z czegos sie biora, i to cos jest poza swiadomoscia (a wiec i konkretnym jezykiem).
To, ze ktos potrafi pisac nie oznacza, ze dana osoba wie jak pisac dobre ksiazki.
Analogicznie z "modelami UML", to ze ktos potrafi je tworzyć nie swiadczy o tym, ze te modele sa cos warte.

Podsumowujac - umiejetnosc analizy i znajomosc UML to dwie rózne rzeczy i nie powinno sie ich mylic.

Twórcy testu chyba tego nie zrozumieli

BTW: Czy to jeszcze IT czy juz nie IT ;)Jakub Wojt edytował(a) ten post dnia 08.04.13 o godzinie 15:51

Temat: Pytanie z egzaminu OCUP-100

Podsumowujac - umiejetnosc analizy i znajomosc UML to dwie rózne rzeczy i nie powinno sie ich mylic.

Twórcy testu chyba tego nie zrozumieli

tez mam takie odczucie

BTW: Czy to jeszcze IT czy juz nie IT ;)

w sumie UML to na pewno nie tylko IT :), żeby zamącić SysML to w 3/4 UML...;)

Temat: Pytanie z egzaminu OCUP-100

Andrzej S.:

Stanisław Jerzy N.:

Andrzej S.:

Stanisław Jerzy N.:
[...]
Zatem nic dziwnego, że informacja o osobie Zev wprowadza tyle kłopotu początkującym UML-owcom ;) Niezła zmyła, nieprawdaż :)
Ale z drugiej strony niezły ubaw z "fachowców" :)

W dyskutowanym pytaniu OCUP nie było w nim ani słowa o tym, że chodzi o model systemu _informatycznego_. Skąd się więc wzięły formatki i dziedziczenie uprawnień użytkowników?
Niezła nadinterpretacja prostej w sumie informacji zawartej w pytaniu :-)

Przeczytaj no drogi kolego pierwsze strony standardu UML ...
Ponadto chyba nie za bardzo się orientujesz skąd się wzięły przypadki użycia ???
Fakt, w Polsce zawitały w sumie dopiero około 2000 roku, ale chyba
nie trzeba było zagłębiać się w literaturę "wczesno-UML'ową",
by wiedzieć co to scenariusz, a co to przypadek użycia.

Skąd się wzięły dawno temu przypadki użycia (dalej : PU), a do czego mogą być i są obecnie wykorzystywane, to niezupełnie to samo. Modele PU są z powodzeniem stosowane nie tylko w

To samo, ale kolego mylisz dwie rzeczy, jak kazdy nowicjusz. Model przypadków, a przypadek uzycia to zupełnie różne rzeczy i staraj się odróżniać model przypadków uzycia od przypadku użycia.

'domenie' informatycznej, ale i w biznesowej. Systemem jest wtedy np. firma (organizacja) oferująca różne usługi, a aktorami zewnętrzne podmioty (osoby i inne organizacje) wchodzące z nią w interakcje. I scenariusze PU też mają wtedy swoje zastosowanie.

Scenariusze zawsze mają zastosowanie, natomiast brak opisu scenariusza to raczej niedbalstwo, a nie "swoje zastosowanie"

Pewnie, że takie zastosowanie PU jest dużo rzadsze i

Jakie zastosowanie PU ???
Wydaje mi się, że kolega ma na mysli tzw. biznesowy przypadek użycia, ale z powyżej kolega nie opisuje biznesowego przypadku uzycia.

najczęściej spotyka się PU w kontekście systemu _informatycznego_. Ale nawet wtedy żadne "nadbudowy", domniemania

W jakich innych "nieinformatycznych" kontekstach kolega "spotykał" UML-owe przypadki użycia ?

i dywagacje dot. formatek i uprawnień nie są potrzebne, żeby poprawnie odpowiedzieć na dyskutowane pytanie OCUP.

I musiał kolega używać tak wielu pokrętnych zdań, by spróbowac to dowieść ???
przeciez powyzszy wywód kupy się nie trzyna, bo logiki tam żadnej.
Wywód kolegi:
Przesłanki kolegi:
1. PU nie sa wykorzystywane obecnie do tego co kilka lat temu - fałsz
2. Modele PU sa stosowane w domenie informatycznej i biznesowej - co ma model do PU ?
3. Scenariusze PU maja swoje zastosowania - nie ma scenariuszy PU, sa albo scenariusze albo PU
4. Najczęściej spotyka się PU w kontekście systemu informatycznego
Konkluzja:
dywagacje dot. formatek i uprawnień nie są potrzebne

Gdzie tu logika ?

Co do czytania standardu UML: Przeczytałem pierwsze, drugie i wiele kolejnych stron - może jakieś przeglądnąłem tylko pobieżnie, bo dość dużo tego. Pewnie daleko mi jeszcze do prawdziwego Fachowca, ale odrobiłem zadanie domowe i zacytuję drugie zdanie z pierwszego rozdziału specyfikacji Superstructure (1. Scope), zwracając uwagę na jego koniec (od słów "as well as"):
The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes.

To dam plusa koledze za odnalezienie elementów w standardzie UML, które zostały wprowadzone razem z fragmentem następującym po "as well as".

Poruszone wątki wspominkowe (Sygnity, oracle, metodyki strukturalne, IACS itd.) pomijam, bo mają charakter personalny (zresztą w moim przypadku są chybione), a takie pojawiają się

Należy znać metodykę firmy, z którą się wspólpracuje (czy pracuje).

zwykle wtedy, gdy brakuje merytorycznych argumentów, i prowadzą dyskusję na manowce.

To się kolego zdecyduj, bo wcześniej próbowałeś podważać moje argumenty, a w tym fragmencie twierdzisz, iż brakuje z mojej strony argumentów.
To miałem jakieś argumenty, czy nie miałem ?

Zatem Twoje zdziwienie bardzo mnie zdziwiło, toteż życzę zwiększenia wysiłków w kierunku poznawania standardu UML ... :)

Odwzajemniam życzenia :-). Zdobywania wiedzy nigdy dość.

Większą radość kolego sprawia dzielenie się wiedzą :)

Temat: Pytanie z egzaminu OCUP-100

Jarek �.:

"Zev works as the librarian at the local library. He can also borrow books as an ordinary library
patron. How many actors are needed when modeling people like Zev in a use case diagram?"

A. 1 actor
B. 2 unconnected actors
C. 1 actor and 1 external system
D. 2 actors connected by a generalization

napisałem że sugeruje 1 aktora to może wyjaśnię dlaczego:

Treść opisu zawiera explicite tylko jeden przypadek użycia (pogrubienie) "wypożyczenie książki", jeżeli podejdziemy do takiej analizy uznając, że aktor to rola a nie osoba czy stanowisko, to powyższy opis zawiera role/aktora "wypożyczający książki" lub po protu "czytelnik". Bibliotekarza, jako rolę/aktora, ignoruję gdyż w treści nie ma przypadku użycia w rodzaju "wypożyczenie książki czytelnikowi", owszem można się domyślać, że taka rola - bibliotekarz - istnieje, ale to domysły, których analityk powinien się wystrzegać. Być może

Zwyczajny analityk od razu dostrzeże pierwsze zdanie "Zev works as the librarian at the local library" i raczje nie bedzie miał problemów z interpretacją tego zdania.
Dla kolegi Jarka zdanie to nie ma znaczenia i olewa je twierdząc, że to nie do niego.
No, nic dziwnego kolego, że nie cierpisz testów.

Temat: Pytanie z egzaminu OCUP-100

Treść opisu zawiera explicite tylko jeden przypadek użycia (pogrubienie) "wypożyczenie książki", jeżeli podejdziemy do takiej analizy uznając, że aktor to rola a nie osoba czy stanowisko, to powyższy opis zawiera role/aktora "wypożyczający książki" lub po protu "czytelnik". Bibliotekarza, jako rolę/aktora, ignoruję gdyż w treści nie ma przypadku użycia w rodzaju "wypożyczenie książki czytelnikowi", owszem można się domyślać, że taka rola - bibliotekarz - istnieje, ale to domysły, których analityk powinien się wystrzegać. Być może

Zwyczajny analityk od razu dostrzeże pierwsze zdanie "Zev works as the librarian at the local library" i raczje nie bedzie miał problemów z interpretacją tego zdania.

Nom... Zev był zatrudniony na czarno i podpierdzielał z biblioteki książki.
Kiedy spece z OMG pytali "co robi" - on stwierdzał, że "tylko pożycza książki" - a w myślach "na czas nieokreślony"... Pewnie dlatego nie było wzmianki "zwracaniu książek" ;)

I tak - aktor nazywa się "Zev".
I kto właściwie zna się na bibliotekoznawstwie spośród niedoszłych posiadaczy "certyfikatów" ? (ciekawe, dlaczego spece z OCUP wybrali właśnie tą działkę)

Dla kolegi Jarka zdanie to nie ma znaczenia i olewa je twierdząc, że to nie do niego.
No, nic dziwnego kolego, że nie cierpisz testów.

A macie testy testów ...
Wiesz, ile warte są testy bez testów ?Jakub Wojt edytował(a) ten post dnia 08.04.13 o godzinie 20:50

Temat: Pytanie z egzaminu OCUP-100

Jakub W.:

Treść opisu zawiera explicite tylko jeden przypadek użycia (pogrubienie) "wypożyczenie książki", jeżeli podejdziemy do takiej analizy uznając, że aktor to rola a nie osoba czy stanowisko, to powyższy opis zawiera role/aktora "wypożyczający książki" lub po protu "czytelnik". Bibliotekarza, jako rolę/aktora, ignoruję gdyż w treści nie ma przypadku użycia w rodzaju "wypożyczenie książki czytelnikowi", owszem można się domyślać, że taka rola - bibliotekarz - istnieje, ale to domysły, których analityk powinien się wystrzegać. Być może

Zwyczajny analityk od razu dostrzeże pierwsze zdanie "Zev works as the librarian at the local library" i raczje nie bedzie miał problemów z interpretacją tego zdania.

Nom... Zev był zatrudniony na czarno i podpierdzielał z biblioteki książki.
Kiedy spece z OMG pytali "co robi" - on stwierdzał, że "tylko pożycza książki" - a w myślach "na czas nieokreślony"... Pewnie dlatego nie było wzmianki "zwracaniu książek" ;)

I tak - aktor nazywa się "Zev".
I kto właściwie zna się na bibliotekoznawstwie spośród niedoszłych posiadaczy "certyfikatów" ? (ciekawe, dlaczego spece z OCUP wybrali właśnie tą działkę)

Wzór przystosowania standardów do "kultury korporacyjnej" ?

Dla kolegi Jarka zdanie to nie ma znaczenia i olewa je twierdząc, że to nie do niego.
No, nic dziwnego kolego, że nie cierpisz testów.

A macie testy testów ...
Wiesz, ile warte są testy bez testów ?

Scenariusz służy do zbudowania systemu (kontroli jego budowy w 4+1).
Główną jego zaletą jest to, że na koniec budowy systemu realizuje się ten scenariusz, by zweryfikować, czy system rzeczywiście działa tak jak został zaprojektowany poprzez ułożenie scenariuszy.
W projektach, gdzie nie wykorzystuje się scenariuszy pojawia się bardzo duży problem z testowaniem systemu. Wtedy rozpoczyna się układanie testów, by przetestowac zbudowany system. Niektóre metody budowy oprogramowania rozpoczynają się wprost od układania testów (XP i wydzielona z niej TDD). Niestety pojawiają się przeróżne problemy związane z testami jak dostateczne pokrycie kodu, czy przepływu danych, testowanie wyjątków, ustalenie klas równoważności, testowanie obiektów itd. itp. I wtedy faktycznie trzeba sprawdzić, czy zaplanowany test faktycznie prawidłowo weryfikuje ustaloną właściwość systemu.
Inna sprawa, że testy jednostkowe, systemowe, integracyjne itd., za wyjątkiem testów akceptacyjnych (opartych na scenariuszach), również powinne być realizowane w trakcie budowy oprogramowania opartego na scenariuszach, ale ....

Temat: Pytanie z egzaminu OCUP-100

Stanisław Jerzy N.:

Napisz kolego swoją wersję jako i ja napisałem...

Temat: Pytanie z egzaminu OCUP-100

Jarek �.:

Stanisław Jerzy N.:

Napisz kolego swoją wersję jako i ja napisałem...

Mojej wersji, kolego, też jeszcze nie zauważyłeś ?

Temat: Pytanie z egzaminu OCUP-100

Stanisław Jerzy N.:

Jarek �.:

Stanisław Jerzy N.:

Napisz kolego swoją wersję jako i ja napisałem...

Mojej wersji, kolego, też jeszcze nie zauważyłeś ?

gdzie ona?

Temat: Pytanie z egzaminu OCUP-100

Jarek �.:

Stanisław Jerzy N.:

Jarek �.:

Stanisław Jerzy N.:

Napisz kolego swoją wersję jako i ja napisałem...

Mojej wersji, kolego, też jeszcze nie zauważyłeś ?

gdzie ona?

Wcześniej w tym wątku

Temat: Pytanie z egzaminu OCUP-100

Stanisław Jerzy N.:
Jeden scenariusz to wypożyczanie książek czytelnikom = 1 formatka do wypożyczania książek czytelnikom.
Drugi scenariusz to wypożyczanie książek z biblioteki = 1 formatka do wypozyczania książek z biblioteki.

czym się różnią te formatki od siebie w treści?

Chyba jasne, że nie powinno być jakiegokolwiek związku między formatką do wypożyczania książek czytelnikom a formatką do wypozyczania książek przez czytelników i na odwrót.

Przecież to te same książki z tej biblioteki... po co dwie różne formatki? Dlaczego formatka wypożyczenia książki ma byc inna tylko dlatego, że kto inny ją wypisuje?

Zatem jak modelujemy system to namalujemy 1 aktora o nazwie Bibliotekarz i drugiego Aktora, którego ochrzcimy Czytelnik.

czy to oznacza, że z programem ma interakcje i czytelnik i bibliotekarz każdy w inny sposób mimo tego, e obaj wypożyczają książkę?

Nie ma jakiegokolwioek powodu, by ich ze sobą łączyć. A nawet nie powinniśmy ich ze sobą łączyć, gdyż dalibyśmy ograniczenie na Bibliotekarza , bądź Czytelnika w takiej bibliotece.

Innymi słowy zrobilibyśmy system, w którym warunkiem wypożyczenia książki byłaby więź Bibliotekarza z Czytelnikiem.
Czyli Czytelnik nie wypożyczyłby książki z biblioteki, ani bibliotekarz nie wypożyczy żadnemu Czytelnikowi książki jeśli nie byłoby między tymi aktorami związku.

dziedziczenie nie oznacza żadnej więzi a jedynie to, że dziedziczący potrafi tyle samo co przodek i coś jeszcze... (lub coś inaczej). Po drugie w dobrym projekcie obiektowym instancje mają tylko "lliście" struktury dziedziczenia, przodkowie są wyłącznie abstrakcją, to drugi powód dla którego stosowanie dziedziczenia dla aktorów i łączenie przodka z przypadkiem użycia nie ma sensu...

Zatem nic dziwnego, że informacja o osobie Zev wprowadza tyle kłopotu początkującym UML-owcom ;) Niezła zmyła, nieprawdaż :)

tak

Ale z drugiej strony niezły ubaw z "fachowców" :)

tak

Temat: Pytanie z egzaminu OCUP-100

Zatem Twoje zdziwienie bardzo mnie zdziwiło, toteż życzę zwiększenia wysiłków w kierunku poznawania standardu UML ... :)

Odwzajemniam życzenia :-). Zdobywania wiedzy nigdy dość.

Większą radość kolego sprawia dzielenie się wiedzą :)

Kolega ma specyficzny sposób dzielenia się wiedzą - wokół "nowicjusze", "początkujący UML-owcy", ... nie dostrzegam w tym radości u kolegi. No chyba, że chodzi o ten "niezły ubaw z 'fachowców' "... :-(

Temat: Pytanie z egzaminu OCUP-100

Stanisław Jerzy N.:

Andrzej S.:

drugie zdanie z pierwszego rozdziału specyfikacji Superstructure (1. Scope), zwracając uwagę na jego koniec (od słów "as well as"):
The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes.

To dam plusa koledze za odnalezienie elementów w standardzie UML, które zostały wprowadzone razem z fragmentem następującym po "as well as".

Kolega sugeruje, że ta deklaracja OMG jest bez pokrycia?
Jest napisane, że celem UML-a (jako całości) jest dostarczenie narzędzi
1) do analizy, projektowania i implementacji systemów informatycznych,
jak również
2) do modelowania biznesowych i podobnych procesów

Z tego wynika, że cały UML (_wszystkie_ elementy) mogą potencjalnie być zastosowane zarówno do modelowania domeny Systemów Informatycznych (*SI*) jak i do modelowania domeny biznesowej.
Elementy Class mogą opisywać logiczne i fizyczne struktury danych, jak i mogą opisywać byty i pojęcia z określonej dziedziny (tzw. model dziedziny).
Elementy Activity mogą być użyte do specyfikowania przebiegu przetwarzania danych w SI, jak i do opisu przebiegu procesu biznesowego. (I proszę nie argumentować, że do tego lepszy jest BPMN - bo to nie zmienia faktu, że można w tym celu wykorzystać także UML-a - czystego lub profilowanego).
O systemowych i biznesowych Przypadkach Użycia już było.

Może teraz to kolega poszuka i powie nam jakie elementy UML-a wg standardu są przeznaczone _tylko do modelowania SI_.

Temat: Pytanie z egzaminu OCUP-100

Jarek �.:

dziedziczenie nie oznacza żadnej więzi a jedynie to, że dziedziczący potrafi tyle samo co przodek i coś jeszcze... (lub coś inaczej).

Nie ma więzi na poziomie instancji - ona występuje tylko na poziomie klasyfikatorów.

Po drugie w dobrym projekcie obiektowym instancje mają tylko "lliście" struktury dziedziczenia, przodkowie są wyłącznie abstrakcją,

Dlaczego uważasz, że tylko takie projekty są dobre, gdzie wszystkie elementy generalizujące są abstrakcyjne?
Trzymając się tego ograniczenia czasem musielibyśmy wprowadzać sztuczny element specjalizujący, który nie wnosiłby żadnych nowych cech (fetures) w stosunku do elementu generalizującego.
BTW Twórcy UML-a nie "potępiają" wykorzystania takich nieabstrakcyjnych elementów generalizujących i dla metaklasy GeneralizationSet zdefiniowali atrybut isCovering. ;-)

Temat: Pytanie z egzaminu OCUP-100

dziedziczenie nie oznacza żadnej więzi a jedynie to, że dziedziczący potrafi tyle samo co przodek i coś jeszcze... (lub coś inaczej).

Nie ma więzi na poziomie instancji - ona występuje tylko na poziomie klasyfikatorów.

jeżeli uznamy, że fakt iż [owczarek niemiecki] to rodzaj [psa] a ten to [ssak], wiąże z sobą te pojęcia to pozostaje zdefiniować pojęcie [więzy] w tym kontekście. Pojęciowo ta więź klasyfikatorów istnieje niewątpliwie...ale mój Fred (pies) jeżeli był z czym lub kim kolwiek związany to ze mną i np. swoją miską ;)

Po drugie w dobrym projekcie obiektowym instancje mają tylko "lliście" struktury dziedziczenia, przodkowie są wyłącznie abstrakcją,

Dlaczego uważasz, że tylko takie projekty są dobre, gdzie wszystkie elementy generalizujące są abstrakcyjne?

"dobry projekt" to faktycznie pojęcie względne, za takie uważam, te projekty obiektowe, które spełniają zasadę SOLID i parę innych w tym wzorców projektowych i dobrych praktyk,

dalej: bo pies, którego miałem w domu był konkretnym psem konkretnej rasy i trudno inaczej, po drugie po co odwoływać się do przodka (superklasy) skoro to samo potrafi klasa konkretna (musi bo dziedziczy)? W modelu pojęciowym generalizacje są metodą uogólniania, w kodzie jest to metoda np. na współdzielenie kodu. Zapytam inaczej: co potrafi klasa nadrzędna a czego nie potrafi jej specjalizacja, że byłby powód wołania przodka?

zresztą jest to dość ładnie opisane w książkach i w wiki chyba jako antywzorzec projektowy: "wołanie przodka".

Trzymając się tego ograniczenia czasem musielibyśmy wprowadzać sztuczny element specjalizujący, który nie wnosiłby żadnych nowych cech (fetures) w stosunku do elementu generalizującego.

nie rozumiem, skoro jakaś klasa jest najniżej w hierarchii to jest liściem a nie abstrakcją...

BTW Twórcy UML-a nie "potępiają" wykorzystania takich nieabstrakcyjnych elementów generalizujących i dla metaklasy GeneralizationSet zdefiniowali atrybut isCovering. ;-)

podobnie jak językoznawcy nie potępiają słabych ale bezbłędnie napisanych tekstów, ale są one oceniane jako słabe w stosunku do tych lepszych publikowanych drukiem lub nagradzanych. To że słownik j.polskiego zawiera kilkadziesiąt tysięcy słów nie znaczy, że należy za wszelką cenę użyć wszystkich w swoich wypowiedziach... Podobnie jako to, że sam fakt, ze kompilator nie wykaże błędów kompilacji nie czyni z kompilowanego programu arcydzieła sztuki programowania ;)

Temat: Pytanie z egzaminu OCUP-100

Andrzej S.:

Stanisław Jerzy N.:

Andrzej S.:

drugie zdanie z pierwszego rozdziału specyfikacji Superstructure (1. Scope), zwracając uwagę na jego koniec (od słów "as well as"):
The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes.

To dam plusa koledze za odnalezienie elementów w standardzie UML, które zostały wprowadzone razem z fragmentem następującym po "as well as".

Kolega sugeruje, że ta deklaracja OMG jest bez pokrycia?

Nie, kolega sugeruje co by porównać UML 1.4 i np. UML 2.2 w aspekcie wyrażenia "business" użytym we fragmencie nastepującym po "as well as". Co oznaczało business w 1.4, a co w wersji 2.2. i czym te biznesy się różnią.
Nadal powiadam, że plus czeka ;)