пропозиції роботи
Wypowiedzi
-
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. ;-) -
Stanisław Jerzy N.:
Andrzej S.:
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".
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.
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_. -
Większą radość kolego sprawia dzielenie się wiedzą :)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ść.
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' "... :-( -
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ć :-) -
Stanisław Jerzy N.:
Andrzej S.:
Przeczytaj no drogi kolego pierwsze strony standardu UML ...
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 :-)
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ść. -
Jakub W.:
Trudno mi wyobrazić sobie _czynną_ znajomość UML (czyli umiejętność tworzenia modeli w UML, a nie tylko ich czytania) bez umiejętności analizy tego, co model ma przedstawiać. Domyślam się, że
ten egzamin ma sprawdzać właśnie taką czynną znajomość (bo bierna nie jest aż takim wyzwaniem :-) ).
"The OCUP Fundamental Examination covers the most commonly encountered UML elements. Familiarity with these elements allows a user to read, interpret, construct and work with simple UML models."
Wydaje mi się że chodzi po prostu o znajomość, czyli umiejętność tworzenia (tak złych tzn. 'głupich' jak i dobrych) / odczytywania diagramów.
Analiza i tworzenie modeli to inna działka.
To ta sama działka. Diagram to graficzna prezentacja fragmentu modelu. Pomaga znacząco w jego odczytywaniu (i tworzeniu też), ale zasadniczo nie jest do tego niezbędny (można zastosować inne rodzaje prezentacji - formatki właściwości elementów, listy powiązań między nimi, itp.).
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*" ) -
Stanisław Jerzy N.:
No to chłopcy gratuluję wiedzy na temat UML-a ;)
Mamy osobę o imieniu Z.
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.
Nie wiem jak żeście wpadli na to, że aby system funkcjonował to uprawnienia czytelnika powinne być dziedziczone przez bibliotekarza, bądź na odwrót.
[...]
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 :-) -
Jakub Wojt:
Z tego co się orientuję OCUP-100 ma przede wszystkim sprawdzać znajomość UML, natomiast w tym pytaniu jest sprawdzana znajomość UML jak i pewne umiejętności analityczne.
[...]
I tu pozwolę sobie uznać, że trafiamy w sendo problemu przemysłu IT.
Zilustruję to stwierdzeniem: Weryfikacja znajomości UML polega na przeprowadzeniu testów (przez osoby pozbawione zdolności analitycznych) z umiejętności analizy ;)
Trudno mi wyobrazić sobie _czynną_ znajomość UML (czyli umiejętność tworzenia modeli w UML, a nie tylko ich czytania) bez umiejętności analizy tego, co model ma przedstawiać. Domyślam się, że
ten egzamin ma sprawdzać właśnie taką czynną znajomość (bo bierna nie jest aż takim wyzwaniem :-) ).
Natomiast do zdawania tego typu testów jest jeszcze potrzebna umiejętność analizy samych tekstów pytań, co bywa trudne ze względu na niejasne i zawiłe sformułowania, nawet w ojczystym języku (np. nasze akty prawne :-) ). -
Kamil Grzybek:
Moim zdaniem to, że bibliotekarz może wypożyczać książki tak samo jak zwykły bywalec biblioteki nie oznacza, że bibliotekarz jest szczególnym przypadkiem bywalca biblioteki (i odwrotnie). Tutaj mamy sytuację, gdzie dwóch aktorów jest połączonych z jednym przypadkiem użycia "Wypożycz książkę". Z treści pytania nie wynika, że między tymi aktorami zachodzi jakakolwiek relacja, jedynie jest napisane, że oboje mogą wypożyczać książki.
Zgadzam się, że między tymi dwoma aktorami - "Czytelnik" (library patron) i "Bibliotekarz" (librarian) nie ma żadnej relacji generalizacji.
Natomiast nie zgadzam się, że oboje mogą wypożyczać książki (w sensie: wziąć książkę dla siebie). Ani *nie jest* to napisane, ani też nie jest zgodne z logiką UC. Tylko "Czytelnik" wypożycza książkę - "Bibliotekarz" nie (co najwyżej 'wypożycza' w sensie wydawania książki dla czytelnika, ale nie o takie znaczenie tego słowa tu chodzi).
Jeśli Zev wypożycza książkę (dla siebie), to występuje w tym momencie w roli "Czytelnika". Co prawda, Zev akurat pracuje też jako bibliotekarz, więc może pełnić również tą drugą rolę w odniesieniu _do tej samej instancji_ przypadku użycia "Wypożycz książkę" (czyli może wypożyczyć książkę sam sobie), ale to nie oznacza żadnego trwałego powiązania między tymi rolami w ogólności.
Zwracam uwagę, że Aktorzy na diagramach UC są klasyfikatorami, a nie wystąpieniami. Nie modelujemy więc konkretnie Zev-a, tylko zbiory ludzi podobnych do Zev-a (co zresztą jest wprost napisane w ostatnim zdaniu testowego pytania), czyli będących bibliotekarzami i czytelnikami. Zev jest tylko szczególnym (przykładowym) przypadkiem osoby będącej takim lub innym Aktorem. -
Jarek Żeliński:
Praktyka to potwierdza: posiadanie jakiegokolwiek certyfikatu niczego nie gwarantuje u jego posiadacza... więc skoro maja być formą "referencji" to nie spełniają tej funkcji...
Dlaczego o tym piszę? Daleki jestem od psucia rynku ośrodkom szkoleniowym i firmom licencjonującym te testy (:)))), ale jak ktoś myśli, że przyjęcie człowieka z certyfikatem cokolwiek gwarantuje, to stawia się w takiej samej sytuacji, jak uznanie, że przyjęcie człowieka z prawem jazdy gwarantuje, że on potrafi jeździć.
Sprawa jest prosta. Gwarancji 100% nie ma, ale jest większe prawdopodobieństwo. Tym większe im bardziej "renomowany" certyfikat (czyt. trudniejszy do przejścia egzamin). A "przyjmujący człowieka" często musi podjąć decyzję dysponując ograniczoną informacją o kandydacie, więc jeśli nie jest to ktoś "polecony" przez znajomego-zaufanego lub sprawdzony w boju, to pozostaje opierać się na certyfikatach (i innych papierkach). To też forma referencji (od organizacji certyfikującej). Niedoskonała, ale lepsze to niż nic. -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy IT – Praca dla osób z charakterem
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy IT – Praca dla osób z charakterem
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy IT – Praca dla osób z charakterem
-
A tu z kolei ja popełniłem skrót myślowy :-) więc wyjaśniam:
Asocjacją byłoby powiązanie rodzinne między różnymi osobami - a więc klasa Osoba z asocjacją zwrotną (do siebie samej).
Związek między Krzysztofem a jego ojcem (dwa obiekty - wystąpienia klasy Osoba) byłby _wystąpieniem_ tej asocjacji (bo asocjacja też jest klasyfikatorem!).
Natomiast jeśli chodzi o nawiązanie do ERD, to jednak uważam tę uwagę za nietrafioną. ERD jako metoda modelowania także jest oparta na koncepcji klasyfikatorów i powiązań między nimi. Zarówno w przypadku UML jak i ERD można mówić o poziomie M0 oraz M1 - tu i tu są byty z określonej dziedziny i reprezentujące je pojęciowo klasyfikatory, które przedstawiamy w modelu.
PS. W kwestię tego, kto ma wiedzę o rodzinie, i co w ogóle znaczy "rodzina" oraz relacja "rodzic"-"dziecko", wolałbym się już w obecnych okolicznościach nie zagłębiać... ;-) -
Krzysztof Sorocki:
[...] Jeśli nie to czy ktoś mógłby dać przykłada związku który jest asocjacją a nie jest agregacją/kompozycją ?
Asocjacją jest np. związek między Tobą a Twoim ojcem - nie jesteś "częścią" swojego ojca.
Ale za to jesteś częścią (composition) "Rodziny", rozumianej jako najmniejsza komórka społeczna - składającej się z Ciebie, Twoich rodziców i rodzeństwa.
Wybacz "osobisty" charakter tego przykładu, ale ten wydał mi się najbardziej czytelny i oczywisty :-) -
Wg mojego rozumienia zacytowanego fragmentu standardu UML, niektóre stwierdzenia dot. kompozycji stoją z nim w sprzeczności.
Jarek Żeliński:
[...] kompozycja to 'silniejsza" forma agregacji, tu "część" musi wystąpić i tyle...
To nieprawda, że w kompozycji "część" zawsze musi występować. W kompozycji może być dopuszczalna liczność 0 po stronie "części".
Natomiast to co standard mówi o kompozycji (i co odróżnia kompozycję od zwykłej agregacji), to to, że w kompozycji:
- część może być przyporządkowana (w określonym momencie czasu) do najwyżej jednej (!) całości (maksymalna liczność po stronie całości = 1), i że
- zwykle (!) cykl życia części jest związany z całością (czyli część przestaje istnieć wraz ze 'zniszczeniem' całości).
I z wcześniejszego postu:- jeżeli ten związek dopuszcza odłączenie B od A to będzie to agregacja
Wg cytowanego fragmentu standardu, odłączenie jest możliwe także dla kompozycji.
wiąże się to także z rygorem na tożsamość klasy (klasa agregowana nie musi mieć tożsamości bo występuje zawsze jako część, np. moje buty nie mają numeru seryjnego ale one są zawsze czyjeś i "buty Żelińskiego" identyfikują je jednoznacznie.
Klasa agregowana [w kompozycji] nie zawsze występuje jako część (bo może być odłączona od całości). W takim przypadku obiekty klasy "część" muszą posiadać także 'samodzielną' tożsamość (muszą być identyfikowalne także bez "całości").
A "buty Żelińskiego" nie zawsze są czyjeś - po wystawieniu na ulicę (śmietnik) stają się niczyje (być może tylko tymczasowo - mamy trochę bezdomnych w Polsce), a jednak istnieją nadal i są identyfikowalne - może po numerze seryjnym jeśli go mają (bo np. była to seria limitowana dla koneserów ;-) ) -
Co do wzoru wniosku o przekazanie raportu z udostępniania danych:
Wzór jest 'skonstruowany' na zasadzie wyglądu papierowego formularza, a składany ma być tylko w postaci elektronicznej - trochę razi mnie ta 'rozbieżność'. Ale najważniejsze, że zakres informacyjny takiego wniosku jest jasny (przynajmniej tak mi się wydaje).
Natomiast dużo ciekawszy mógłby być wzór samego raportu z udostępniania danych. Przede wszystkim jego zakres informacji (ale może też ogólny układ graficzny). -
Projekt w/s minimalnej funkcjonalnosci systemów *telefonicznych* - to zabrzmiało intrygująco. Na szczęście chodzi o znane nam wszystkim systemy *teleinformatyczne* :-)
-
Konkluzja reportażu jest taki, że do usunięcia obecnego bałaganu z receptami jest _potrzebny_ centralny system CSIOZ realizujący m.in. obieg e-recept. Hmm... moim zdaniem nie. Prawdą jest, że gdyby taki system już był, to bałaganu z receptami byśmy uniknęli.
Ale można było go uniknąć również dużo prostszymi metodami.
Podstawową przyczyną obecnych zawirowań jest brak możliwości weryfikacji (przez lekarza, ew. aptekarza) czy dana osoba jest ubezpieczona ('zdrowotnie'), czyli uprawniona do zakupu refundowanego.
Informacje o fakcie ubezpieczenia pacjenta posiada ZUS. ZUS jest skomputeryzowany. Dlaczego nie może udostępnić takiej informacji lekarzom (w formie usługi elektroniczna - kanałem internetowym albo SMS-em)?
Tą informację posiada także NFZ (refundator recept). NFZ jest skomputeryzowany. Dlaczego nie może udostępnić takiej informacji lekarzom (jw.)?
Do tego nie trzeba budować następnego wielkiego systemu.
(Nie wyklucza to jego przydatności w szerszym zastosowaniu - chociażby tak jak pokazano, do całościowej 'elektronizacji' procesu obiegu recept.)
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
Zaloguj się za pomocą
