Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Jarek Żeliński:

Stanisław Niepostyn:
Rozdzielenie podmiotu projektującego od podmiotu implementującego spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

dlaczego?

Czy uczestniczyłeś w projekcie, w którym jeden podmiot projektował, a jeszcze inny implementował system IT ?

Hehe - uczestniczył:P
Jarek projektował, mój zespół implementował. Projekt został zrealizowany zgodnie z harmonogramem i w założonym budżecie, jako wykonawcy systemu otrzymaliśmy znakomite referencje i do dzisiaj utrzymujemy doskonałe kontakty biznesowe z Zamawiającym.
Dodam jeszcze, że nasza oferta była ponad 2 krotnie tańsza od ofert konkurencji, czas wykonania znacząco krótszy.
Fakty te wynikały z prostych powodów:
- jednoznaczna dokumentacja wymagań, jasno definiująca cele projektu, oparta o model biznesowy (BPMN), model dziedziny (UML) oraz model przypadków użycia (UML) wraz ze scenariuszami testów opartych o przypadki użycia pozwoliły nam na dokładną wycenę projektu
- testowanie koncepcji na modelach i makietach pozwoliło doprecyzować szczegóły wykonawcze tanio i efektywnie, sprawiając, że implementacja jest jednoznaczna
- efektem tego już pierwsza dostarczona wersja pozwalała na realizację postawionych celów
Dodam jeszcze, że Projekt realizowany był we Wrocławiu. Jarek jest z Warszawy, ja i mój zespół z Gdańska. Zamawiający świetnie koordynował projekt i rozproszenie geograficzne zespołu nie miało negatywnego skutku na jakość, ani czas trwania projektu.Mateusz Kurleto edytował(a) ten post dnia 11.03.11 o godzinie 23:18

Temat: Zrozumiałość diagramów

Mateusz Kurleto:

Stanisław Niepostyn:

Jarek Żeliński:

Stanisław Niepostyn:
Rozdzielenie podmiotu projektującego od podmiotu implementującego spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

dlaczego?

Czy uczestniczyłeś w projekcie, w którym jeden podmiot projektował, a jeszcze inny implementował system IT ?

Hehe - uczestniczył:P
Jarek projektował, mój zespół implementował. Projekt został zrealizowany zgodnie z harmonogramem i w założonym budżecie, jako wykonawcy systemu otrzymaliśmy znakomite referencje i do dzisiaj utrzymujemy doskonałe kontakty biznesowe z Zamawiającym.
Dodam jeszcze, że nasza oferta była ponad 2 krotnie tańsza od ofert konkurencji, czas wykonania znacząco krótszy.
Fakty te wynikały z prostych powodów:
- jednoznaczna dokumentacja wymagań, jasno definiująca cele projektu, oparta o model biznesowy (BPMN), model dziedziny (UML) oraz model przypadków użycia (UML) wraz ze scenariuszami testów opartych o przypadki użycia pozwoliły nam na dokładną wycenę projektu
- testowanie koncepcji na modelach i makietach pozwoliło doprecyzować szczegóły wykonawcze tanio i efektywnie, sprawiając, że implementacja jest jednoznaczna
- efektem tego już pierwsza dostarczona wersja pozwalała na realizację postawionych celów
Dodam jeszcze, że Projekt realizowany był we Wrocławiu. Jarek jest z Warszawy, ja i mój zespół z Gdańska. Zamawiający świetnie koordynował projekt i rozproszenie geograficzne zespołu nie miało negatywnego skutku na jakość, ani czas trwania projektu.Mateusz Kurleto edytował(a) ten post dnia 11.03.11 o godzinie 23:18

Gratulacje :)
A co ten system miał robić ?

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:
A co ten system miał robić ?

Obawiam się, że szczegóły kontraktu stanowią tajemnicę handlową, natomiast realizowany był w ramach: Projekt SZOK - „System Zarządzania Obiegiem Korespondencji dla MMSP” realizowany w ramach Programu Operacyjnego Innowacyjna Gospodarka POIG 2007 - 2013, działanie. 5.2 Wspieranie instytucji otoczenia biznesu świadczących usługi proinnowacyjne oraz ich sieci o znaczeniu ponadregionalnym.

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Jarek Żeliński:

Stanisław Niepostyn:
Rozdzielenie podmiotu projektującego od podmiotu implementującego spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

dlaczego?

Czy uczestniczyłeś w projekcie, w którym jeden podmiot projektował, a jeszcze inny implementował system IT ?

robię od od lat... tu np. zapytaj Mateusza o efekty.

Nie odpowiedziałeś na pytanie DLACZEGO...Jarek Żeliński edytował(a) ten post dnia 12.03.11 o godzinie 10:23

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:
Gratulacje :)
A co ten system miał robić ?

Ta część projektu jest jawna i ogólnie dostępna:
http://www.kigeit.org.pl/informacje/szok/iSZOK_ogolne.htm

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Mateusz Kurleto:

Stanisław Niepostyn:
Często znają poprzednika diagramu stanów:
http://pl.wikipedia.org/wiki/Automat_sko%C5%84czony
Czasem DFD:
http://pl.wikipedia.org/wiki/DFD
A najczęściej schemat blokowy:
http://pl.wikipedia.org/wiki/Schemat_blokowy

Ale mówiliśmy o projektach systemów, a nie o algorytmice. Jak chcesz korzystając ze schematów blokowych projektować cokolwiek bardziej złożonego niż implementacja algorytmu?

Mowa była o programistach, którzy pracują nad różnymi fragmentami systemu.
Czasami jest tak, że po "przeczytaniu" dokumentacji programiści potakują z głebokim zrozumieniem, po czym .... muszę im wyjasniać za pomocą o wiele prostszych notacji sposób pracy fragmentu systemu, który mieli oprogramować ...

Trudno mi sobie wyobrazić jak zaprezentować w ten psosób mapowanie bazy danych na obiekty. Tudziez przepływ sterowania dla kilku watków ;)

Temat: Zrozumiałość diagramów

Grzegorz Gwoźdź:

Stanisław Niepostyn:

Mateusz Kurleto:

Stanisław Niepostyn:
Często znają poprzednika diagramu stanów:
http://pl.wikipedia.org/wiki/Automat_sko%C5%84czony
Czasem DFD:
http://pl.wikipedia.org/wiki/DFD
A najczęściej schemat blokowy:
http://pl.wikipedia.org/wiki/Schemat_blokowy

Ale mówiliśmy o projektach systemów, a nie o algorytmice. Jak chcesz korzystając ze schematów blokowych projektować cokolwiek bardziej złożonego niż implementacja algorytmu?

Mowa była o programistach, którzy pracują nad różnymi fragmentami systemu.
Czasami jest tak, że po "przeczytaniu" dokumentacji programiści potakują z głebokim zrozumieniem, po czym .... muszę im wyjasniać za pomocą o wiele prostszych notacji sposób pracy fragmentu systemu, który mieli oprogramować ...

Trudno mi sobie wyobrazić jak zaprezentować w ten psosób mapowanie bazy danych na obiekty. Tudziez przepływ sterowania dla kilku watków ;)

Raczej chodzi o mapowanie obiektów na bazę danych, ale w coraz wiekszej części frameworków można nie przejmować się tym mapowaniem z powodu ich coraz większej automatyzacji. no, ale "na piechotę" też zawsze można to robić, jak się człowiek uprze ;)
Z kolei przy rozważaniu równoległości przetwarzania wielu wątków znakomicie od kilkunastu lat radzimy sobie za pomocą automatów, tym bardziej, że nawet istnieje bardzo mocna podbudowa teoretyczna. A notacja naprawdę jest prosta ...

Temat: Zrozumiałość diagramów

Napisano:

>Stanisław Niepostyn:

Rozdzielenie podmiotu projektującego od podmiotu implementującego
spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

czy dowiemy się dlaczego bo to ważne...

Temat: Zrozumiałość diagramów

Jarek Żeliński:
Napisano:

>Stanisław Niepostyn:

Rozdzielenie podmiotu projektującego od podmiotu implementującego
spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

czy dowiemy się dlaczego bo to ważne...

A czy znajdzie się jeszcze choć jedna osoba nazywająca siebie Analityk, badź Projektant, która też nie wie dlaczego ?

Temat: Zrozumiałość diagramów

jeżeli nie potrafisz uzasadnić postawionej tezy to powiedz "nie wiem", to także będzie odpowiedź na pytanie "dlaczego".Jarek Żeliński edytował(a) ten post dnia 15.03.11 o godzinie 18:39

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Jarek Żeliński:
Napisano:

>Stanisław Niepostyn:

Rozdzielenie podmiotu projektującego od podmiotu implementującego
spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

czy dowiemy się dlaczego bo to ważne...

A czy znajdzie się jeszcze choć jedna osoba nazywająca siebie Analityk, badź Projektant, która też nie wie dlaczego ?

Ja. Co więcej uważam, że tak jak mówisz dzieje się wtedy i tylko wtedy, gdy projektem zarządza kiepski Project Manager.
Rozdzielenie tych funkcji jest dość naturalne. Jakoś nikt się nie dziwi, że murarz nie projektuje wieżowców...Mateusz Kurleto edytował(a) ten post dnia 15.03.11 o godzinie 18:50

Temat: Zrozumiałość diagramów

Mateusz Kurleto:

Stanisław Niepostyn:

Jarek Żeliński:
Napisano:

>Stanisław Niepostyn:

Rozdzielenie podmiotu projektującego od podmiotu implementującego
spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

czy dowiemy się dlaczego bo to ważne...

A czy znajdzie się jeszcze choć jedna osoba nazywająca siebie Analityk, badź Projektant, która też nie wie dlaczego ?

Ja. Co więcej uważam, że tak jak mówisz dzieje się wtedy i tylko wtedy, gdy projektem zarządza kiepski Project Manager.
Rozdzielenie tych funkcji jest dość naturalne. Jakoś nikt się nie dziwi, że murarz nie projektuje wieżowców...Mateusz Kurleto edytował(a) ten post dnia 15.03.11 o godzinie 18:50

Jako, że wcześniej tu określiłeś, że Twoje stanowisko i Jarka jest w zasadzie identyczne (wszak wspólnie robiliście projekty), więc pozwolisz, że zaczekam jednak na głos innych osób ...

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:
Jako, że wcześniej tu określiłeś, że Twoje stanowisko i Jarka jest w zasadzie identyczne (wszak wspólnie robiliście projekty), więc pozwolisz, że zaczekam jednak na głos innych osób ...

Ale to tylko jeden z wielu projektów jakie ja robiłem, dodam że jedyny w którym uczestniczył też Jarek.
Więc odnieśmy to do tych pozostałych, bo pozostaje aktualne. Nie tylko w IT, ale także w reklamie i budownictwie - takimi projektami też zarządzałem mając osobno projektantów i wykonawców.

Temat: Zrozumiałość diagramów

sugeruję zakończyć ten off-top chyba autor tezy:

Rozdzielenie podmiotu projektującego od podmiotu implementującego
spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

ją rozwinie, moje i nie tylko doświadczenie wskazuje, że ewentualne rozmycie odpowiedzialności jest prawie zawsze efektem złej jakości dokumentacji projektu to jest przypadku gdy wykonawca nie jest w stanie "dociec" co autor projektu (dokumentacji) miał na myśli.

ciekawszy wydaje mi się wątek jaki urodził sie gdzie indziej ale "wszedł" w temat zrozumiałości.

Jarek Żeliński:
jednak czasami problem w tym, że jeden diagram klas będzie zawierał klasę SamochódSłużbowy połączoną asocjacją z klasą Pracownik, a na innym diagramie te dwie klasy będą połączone zależnością <<use>> (Pracownik używa samochodu), w pierwszym przypadku mamy relacje biznesowe ale nie implementowane a w drugim implementowane współdziałanie (pokazane później na diagramie sekwencji).

Czy nie wystarczającym rozwiązaniem byłoby nadać znaczenie asocjacji poprzez nadanie jej nazwy używa?

nie, bo asocjacja jest atrybutem klasy a relacja <<use>> wywołaniem metody, to skrajnie różne pojęcia semantyczne

Jeżeli powiązanie to ma jakieś właściwości to zawsze można użyć klasy asocjacyjnej, której wielu programistów nienawidzi, a która jest tak użyteczna w analizie.

ja także jej nie lubię :) dlaczego? Bo nie lubią jej programiści :), po co rysować coś co jest trudne lub nie możliwe do implementacji w projekcie koncepcji rozwiązania?

Osobiście staram się unikać takich "powiązań kontekstowych", jak przytoczone <<use>> ponieważ można je mnożyć w "nieskończoność". Takie zależności prezentuje poprzez operacje np. Pracownik .pobierzUżywaneSamochody():SamochódSłużbowy[], w której mówię, że są to obiekty spełniające relacje Pracownik->używa->SamochódSłużbowy ewentualnie dodając potrzebne ograniczenia klasy asocjacyjne.

pojęcie relacji to semantyka ERD a nie diagramu klas (a konkretnie obiektowego projektu)... tu widzę "kłopot"...

owszem nie ma sensu nanoszenie wszystkich <<use>> ale dokumentując jakiś konkretny kontekst pokazuje się je... na poparcie tej tezy polecam książki z opisem wzorców projektowych, diagramy klas są nafaszerowane relacjami <use> z małą ilością asocjacji.

Temat: Zrozumiałość diagramów

Jarek Żeliński:
sugeruję zakończyć ten off-top chyba autor tezy:

Rozdzielenie podmiotu projektującego od podmiotu implementującego
spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

ją rozwinie, moje i nie tylko doświadczenie wskazuje, że ewentualne rozmycie odpowiedzialności jest prawie zawsze efektem złej jakości dokumentacji projektu to jest przypadku gdy wykonawca nie jest w stanie "dociec" co autor projektu (dokumentacji) miał na myśli.

Problem w tym, że tylko dwie osoby nie wiedzą o co tu chodzi.
Dla reszty osób jest to jak na razie zrozumiałe.
Stąd nie mam zamiar wchodzić w dyskusje na tematy oczywiste.

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Jarek Żeliński:
sugeruję zakończyć ten off-top chyba autor tezy:

Rozdzielenie podmiotu projektującego od podmiotu implementującego
spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

ją rozwinie, moje i nie tylko doświadczenie wskazuje, że ewentualne rozmycie odpowiedzialności jest prawie zawsze efektem złej jakości dokumentacji projektu to jest przypadku gdy wykonawca nie jest w stanie "dociec" co autor projektu (dokumentacji) miał na myśli.

Problem w tym, że tylko dwie osoby nie wiedzą o co tu chodzi.
Dla reszty osób jest to jak na razie zrozumiałe.
Stąd nie mam zamiar wchodzić w dyskusje na tematy oczywiste.

dla mnie nie jest to takie oczywiste bo rozdzielenie roli projektanta od wykonawcy jest wymogiem projektów IT dla administracji USA i zaleceniem w UE, widać to choćby po rosnącej także w Polsce liczbie przetargów na analizę i projektowanie bez implementacji, która to jest przedmiotem odrębnego przetargu w którym projekt jest tak zwanym OPZtem...

jak zinterpretujesz następującą pozycję klasyfikację przetargów:
CPV: Usługi opracowywania oprogramowania

po protu myślałem, że potrafisz swoją rewolucyjną tezę czymś poprzeć... choć skoro jako analityk projektant masz inne doświadczenia.... sam już nie wiem co o tym myśleć...Jarek Żeliński edytował(a) ten post dnia 16.03.11 o godzinie 11:29

Temat: Zrozumiałość diagramów

Patrząc na specyfikację UML 2.1.2 na stronie OMG nigdzie jednoznacznie nie ma opisanego elementu <<use>>, jednakże pojawia się pośrednio w momencie opisywania relacji zależności klas.
Jednakże, zarówno asocjacja, kompozycja, zależność są elementem języka odnoszącym się do relacji pomiędzy klasami.
Asocjacja jako związek nie jest bezpośrednio atrybutem klasy, a jedynie powoduje powstanie atrybutów (pamiętajmy, że atrybuty klasy są to jej właściwości, którym możemy nadać oznaczenia publiczny, chroniony, prywatny, statyczny).
Mało tego, mając na myśli diagram klas, <<use>> używane jest jako określenie zależności, np. komputer używa procesora, karty graficznej, pamięci itp, tak więc mowa tu o związku zależności. Nie ma tu bezpośrednio mowy o tym, że jedna klasa używa metody drugiej klasy (bo tego nie ma przedstawionego na diagramie klas). Używanie metod właściwe jest dla diagramów komunikacji, gdzie jednoznacznie można wskazać, która klasa lub aktor używa jakich metod.
Dodatkowo relacja zależności może zostać oznaczona rodzajem poprzez ujęcie nazwy zależności pomiędzy << a >>.
Jeśli jednak posługujemy się inną notacją, myślę że warto wspomnieć na początku o takim fakcie, aby nie powstawały niepotrzebne nieporozumienia, a co trzymanie się określonego zbioru zasad i słownika pojęć, jak najbardziej pozwoli tego uniknąć. :)

Temat: Zrozumiałość diagramów

kontynuując poprzednika....

Superstructure UML v.2.3

w kwestii asocjacji

Figure 7.24 shows that the attribute notation can be used for an association end owned by a class, because an association end owned by a class is also an attribute. This notation may be used in conjunction with the line-arrow notation to make it perfectly clear that the attribute is also an association end.

wyjasnienie (ilustracja) asocjacji jako atrybutu, ilustrowane jako klasa z atrybutem, którego wartością jest ID klasy powiązanej z licznoscią powiązania, zapis raczej nie stoswany na diagramach (po to używamy kresek pomiędzy klasami) ale ilustruje semantykę asocjacji. Widać to także w niektórych programach do modelowania, wejscie we "właściwości" klasy i usunięcie WSZYSTKICH jej atrybutów powoduje usunięcie asocjacji z diagramu (np. STAR UML i nie tylko).

rozdz. 7.3.3. Association, sekcja Semantics: An association declares that there can be links between instances of the associated types.

w kwestii <<use>>

Table B.1 - UML Keywords
use Classes Usage dashed-line label (linia bez żadnego stereotypu) i faktycznie nie jest to doprecyzowane.

Czasami można się spotkać z użyciem stereotypu <<call>>:

«call» Classes::
Dependencies
Usage, dependency whose source is an operation and whose
target is an operation.

i chyba to jest "słuszna koncepcja" dla doprecyzowania faktu, że chodzi o wołąnie metody (jeśli tak jest) zamaiast abstrakcyjnego <<use>>... (stereotyp <<call>> pochodzi z jednego ze standardowych profili UML), inna sprawa, że "użycie" klasy (obiektu) może być wyłącznie wołaniem jej metod wiec ...

(cytaty z Superstructure UML v.2.3)

Wydaje mi się, że nie chodzi o to by być purystą (no nie tylko), a o to by użyte pojęcia dały się znaleźć w słowniku (dokumentacja UML) i poprawnie (zgodnie z intencją autora modelu) zinterpretować.... własne konstrukcje, uproszczenia i konwencje powodują utratę komunikacji, dobrym pomysłem jest ewentualne ubranie własnej konwencji w poprawny profil i dodanie go (jego metamodelu) do dokumentacji.

Temat: Zrozumiałość diagramów

W przypadku asocjacji, to że w klasie podrzędnej mogą powstawać atrybuty związane z spełnieniem zależności, to jest oczywiste. Jednakże sama asocjacja - jako połączenie nie stanowi atrybutu w sensie rozumienia atrybutu klasy ( tak jak to w przytoczonym fragmencie zostało ujęte, końcówka może stanowić ).

Na potwierdzenie mojej tezy wesprę się chociażby takim przypadkiem połączenia wielu do wielu, kiedy to asocjacja wcale nie tworzy atrybutu, a powstaje nowa klasa asocjacyjna.
Co do oznaczenia <<use>> czy też <<call>> nie bardzo mogę uchwycić głębszy sens używania tego, gdyż takie oznaczenie określa, że klasa używa lub, co gorsza, wywołuje klasę drugą, bez wskazania dokładnie metod. Mówiąc o klasach bardziej naturalne jest używanie <<use>> niż <<call>>. Relacja zależności uważam w zupełności wystarcza, a uszczegółowienie jej powinno właśnie nastąpić w diagramach komunikacji. Jedynie warte czasem zaznaczenia uważam element określający, że jedna klasa powołuje obiekt klasy drugiej (w przypadku singletonów jest to istotne oraz klas fabryk), czyli <<instantiate>>

Jednakże zgadam się, że jeśli zawrzemy w dokumentacji, opis nowych elementów notacji, czy też sposób modyfikacji, staje się to jak najbardziej poprawne. Sam standard UML nie jest przecież czymś, czego analityk nie może zmieniać, czy też dopasowywać do własnych potrzeb. Przecież najważniejsze jest to, aby w obrębie danej grupy ludzi razem współpracujących i wytwarzających rozwiązanie, używane notacje były jednoznaczne oraz zrozumiałe.

Odrywając się już od kwestii zależności i związków, powiedzcie, czy na swoich diagramach Use Case zaznaczacie System jako aktora ?

Temat: Zrozumiałość diagramów

Konrad E.:
W przypadku asocjacji, to że w klasie podrzędnej mogą powstawać atrybuty związane z spełnieniem zależności, to jest oczywiste. Jednakże sama asocjacja - jako połączenie nie stanowi atrybutu w sensie rozumienia atrybutu klasy ( tak jak to w przytoczonym fragmencie zostało ujęte, końcówka może stanowić ).

tu faktycznie balansujemy wokół kontekstu modelu więc co innego w model pojęciowy a co innego model kodu, ja wskazałem na fakt, że asocjacja - wskaźnik trwałego połączenie z innym obiektem - reprezentuje kontekstowo relację logiczną lub wskaźnik w kodzie.. warto świadomie używać tego elementu notacji i to jest opisane w Superstructure

Na potwierdzenie mojej tezy wesprę się chociażby takim przypadkiem połączenia wielu do wielu, kiedy to asocjacja wcale nie tworzy atrybutu, a powstaje nowa klasa asocjacyjna.

związek logiczny wiele do wielu ma inne znaczenie na diagramie klas a inne na diagramie obiektów (te drugie są instancjami tych pierwszych i mają ograniczenia, których nie mają klasy jako uogólnienia).

mogę napisać, że wielu klientów kupuje wiele produktów, jednak konkretne transakcje to inne obiekty łączące konkretnego klienta z jednym lub wieloma produktami.

Co do oznaczenia <<use>> czy też <<call>> nie bardzo mogę uchwycić głębszy sens używania tego, gdyż takie oznaczenie określa, że klasa używa lub, co gorsza, wywołuje klasę drugą, bez wskazania dokładnie metod.

logikę rozwiązania pokazujemy na diagramie klas wskazując zależnością <<use>> np. że klasa Samochód korzysta z klasy Silnik by ruszyć z miejsca, na diagramie sekwencji (bo on do tego służy) pokażemy scenariusz tego dialogu operując konkretnymi Metodami klasy Silnik.

Diagram klas obrazuje ten problem na wyższym poziomie abstrakcji.

Jednakże zgadam się, że jeśli zawrzemy w dokumentacji, opis nowych elementów notacji, czy też sposób modyfikacji, staje się to jak najbardziej poprawne. Sam standard UML nie jest przecież czymś, czego analityk nie może zmieniać, czy też dopasowywać do własnych potrzeb.

UML definiuje sposób dopasowania: profile

Przecież najważniejsze jest to, aby w obrębie danej grupy ludzi razem współpracujących i wytwarzających rozwiązanie, używane notacje były jednoznaczne oraz zrozumiałe.

tu byłbym ostrożny, UML powstał by komunikacja była możliwa także z nieznajomym (po to są standardy). Niestety często w firmach powstają nieformalne konwencje i uproszczenia i poza tą firmą autorów dokumentacja bywa nawet nieczytelnym bełkotem. Dokładnie to samo ma miejsce w jednej firmie gdy kilku ludzi odeszło a w ich miejsce weszli nowi pracownicy....

przykład, właśnie z tym walczę: pewien lider naszego runku, spółka giełdowa, zatrudnił
podwykonawcę (mojego partnera) i niestety dostaje UMLowy bełkot zrozumiały tylko i "w ich" wąskim gronie... a powstaje OPZ do przetargu wiec nie wiem jak to widzą....

To są właśnie przypadki gdy niemożliwe jest rozdzielenie projektantów od wykonawców: dokumentacja jest hermetyczna! Posuwają się nawet łączenia kompozycją jednego obiektu z dwoma nadrzędnymi... (jeden obiekt jest zawarty na wyłączność do dwóch innych - tragedia, chyba wyłączyli validator w EA bo im przeszkadzał w w produkowaniu tej makulatory)

Odrywając się już od kwestii zależności i związków, powiedzcie, czy na swoich diagramach Use Case zaznaczacie System jako aktora ?

Chodzi o system projektowany czy zewnętrzny? Jeśli to drugie to jak najbardziej.Jarek Żeliński edytował(a) ten post dnia 17.03.11 o godzinie 10:37