UML - co do nauki

0

cześć,
Może ktoś z Was może polecić mi dobrą literaturę (najlepiej polskojęzyczną) do nauki UML?
Dodatkowo chciałbym (być może będą to te same źródła) dowiedzieć się co nie co na temat nie samej notacji a nazwijmy to filozofii wykorzystania modelowania w kontekście pracy analityka itp?

z góry dzięki

1

filozofii wykorzystania modelowania w kontekście pracy analityka itp?

Poza bardzo wyjątkowymi sytuacjami (jak http://wwwis.win.tue.nl/2R690/doc/ECSS-E-ST-40C(6March2009).pdf i Model Driven Development) w ogóle nie są wykorzystywane. A w pracy analityka to już w ogóle, bo analityk ma rozumieć potrzeby klienta i umieć je przekazać programistom, podczas gdy UML generalnie w dużej mierze dotyczy projektowania roziązania. Analityk ma wyjaśnić czego klient potrzebuje, a projektowaniem i pisaniem zajmą się programiści. Jeśli gdzieś spotkasz UML to raczej w dokumentacji projektu i to tylko jak ktoś będzie miał jakąś wielką potrzebę coś takiego zrobić.
No chyba ze żyjesz w latach 70, zanim ludzie odkryli ze Waterfall się nie sprawdza.

0

Ale czy jednak umiejetność np tworzenia użytecznych diagramów przypadków użycia nie pomaga w realizacji zadań oktorych mówisz? Trzeba przyjąć jakaś efektywna technikę która uporządkuje wymagania i zbierze je w jakiejś bardziej uporządkowanej formie. Dodatkowo może złe się wyraziłem ale często łączone są role analityka biznesowo i systemowego i jakw tym kontekście rozumieć wykorzystanie UMLa?

0

Być może wiec są jakieś odpowiednie wzorce które należy poznać by lepiej po pierwsze umieć pozyskiwać te wymagania od klientów a po drugie przekształcać je w coś co można przekazać programistom? Właśnie tu mam problem ze zidentyfikowaniem za pomocą jakich metod analityk ma przekazać programiście te wymagania? Czy nie właśnie np za pomocą diagramów UML?

0

Dla analityków/projektantów systemowych, np.

Dla analityka biznesowego masz inny zestaw narzędzi:

  • BABOK Guide v3 - taki elementarz
  • BPMN (notacja do modelowanie procesów) + soft do symulacji procesów (np. możesz robić sobie symulacje typu "jaka będzie stopa zwrotu" / "okres zwrotu do inwestycji za wagon $" / "dorzucenie zasobów w tym miejscu nie poprawi sytuacji" i ubijać głupie pomysły w zarodku, albo argumentować, że może i kosztuje $, ale po X czasu się zwróci, a po X+N będą oszczędności rzędy Y)

Pamiętaj, że UML (język do modelowania) != waterfall (podejście do realizacji projektów). W małych zespołach, to overkill, bo łatwiej podejść i pogadać, aniżeli stworzyć model i wysłać go ziomkowi do skomentowania, ale jak dostajesz duży system do ogarnięcia, to od czego chciałbyś zacząć jak nie od zrozumienia podstawowych konceptów, funkcjonalności, budowy, interfejsów, itd.? Diagramy UML pozwalają szybko się zorientować o co chodzi, bo adresują określone potrzeby i wymuszają pewien stopień precyzji (co nie znaczy, że nie można stworzyć jakiejś qpy). W przypadku diagramów "custom", jest ten problem, że często autorzy mieszają na nich różne aspekty, np. statyczne (wszystkie klocki systemu) z dynamicznymi (kto komu coś wysyła i kiedy) + etykietki i pod diagramem długa lista opisująca co się dzieje (=instrukcja jak odczytać myśl przewodnią diagramu, który przedstawia "wszystko" - interfejsy/sekwencje, a nas interesuje tylko określony aspekt).

Finalnie i tak projekt musisz udokumentować, no chyba, że klient nie chce dokumentacji, albo pracodawca zakłada, że nie będzie rotacji załogi i co wtedy, "nasz firma ma autorską notację" ? :-D

2

Nie, bo to nie ma najmniejszego sensu. Chyba ze firma zatrudniła analityka na chwilę i liczy ze on im wyprodukuje specyfikacje wymagań na papierze z potem programisci to zaklepią :D Tak sie nie da, bo specyfikacja odpowiednio szczegółowa to byłby zwyczajnie kod tylko w innej postaci.
W praktyce analitycy cały czas pracują z zespołem i są dostępni pod ręką, zeby rozwiać wątpliwości kiedy się pojawią w trakcie implementacji. Nie ma tu żadnych szczególnych "metod", po prostu ludzie ida ze sobą pogadać.

Takie formalne podejście to lata 70, kiedy ludzie wierzyli ze da się zrobić to o czym mówisz i klepali Waterfallem. Dzis wiemy że generalnie ciężko tak robić soft, bo wszystko za często się zmienia. Wyjątkiem są przytoczone przeze mnie wyżej systemy kosmiczne i systemy krytyczne, bo te buduje sie trochę jak "mosty", tzn jak ktoś przyklepie zestaw wymagań i funkcjonalności to jest to zamrożone i buduje się taki system do samego końca, tak jak jest napisane, choćby nie miało to żadnego sensu.

Tak jak wspomniał @yarel (i ja też, wcześniej) ma to pewien sens przy dokumentowaniu projektu, ale wtedy nijak nie jest to praca żadnego analityka.

0

Zwykle w trakcie analizowania problemu stosuje się uproszczonego schematu, by móc co najwyżej rozrysować problem i jest to na tyle prosty schemat, że do UMLa to im daleko. :p

0

Yarel dzięki,
właśnie potrzebuję zorientować się jak efektywnie zacząć analizować wymagania biznesowe (na razie w teorii).
Inaczej mówiąc jak (i jakie) zadawać istotne pytania tak aby wycisnąć od klienta jak najwięcej informacji która później pomoze mi w tworzeniu dokumentacji która będzie przynajmniej w części podstawą dla programisty.
Oczywiście tak jak mówisz zależy wszystko od konkretnego zadania i inaczej będzie wyglądało dokumentowanie stworzenia cyklicznego comiesięcznego raportu wysylanego do jednej osoby a inaczej np stworzenie interfejsu (i bebechów) zeby klient mógł kupić polisę ubezpieczeniową do konta bankowego

Rozumiem ze wszystko wychodzi w praktyce i praktyka czyni mistrza ale zawsze mogą być jakies pomoce teoretyczne które pomogą w przygotowaniu się do takiej roli :)

0

dzięki za opinie. Zastanawia mnie tylko jedno - jak grzebę po internecie to moja obserwacja jest taka ze jak już znajdę coś o UMLu i modelowaniu to zazwyczaj w opinii twórców tekstów/książek jest to uniwersalne narzedzie komunikacji i must have każdego projektowania nowego rozwiązania bez względu na kaskadowa czy zwinną metodykę prowadzenia projektów (jak wspomnieliście w aktualnych realiach w dużej większości przeważa ta druga). Natomiast z tego co pisze Shalom wynika ze do podejścia zwinnego (z iteracjami i zmieniającymi się wymaganiami klienta) modelowanie UML nie nadaje się praktycznie wgl. I pytanie kto w takim razie odpowiada za dokumentowanie projektu jak nie analityk?

0

Przede wszystkim musisz myśleć kontestkowo. Najlepsza technika/wzorzec do tego to mapa kontekstów, o której już kilka razy pisałem. Po drugie musisz znać domenę. Większość dziedzin biznesowych to nic odkrywczego i można te informacje znaleźć w książce. Zadajesz pytania "czym to jest, co to robi, co się stanie jeśli to wykona tą operację, do czego należy ta operacja" i na podstawie tego modelujesz dziedzinę. Jeśli nie programujesz kilka lat to i tak nie będziesz umieć modelować w sensowny sposób. W większości przypadków dla programistów wystarczyły by tylko te historyjki. Praca analityka jest zbędna, bo analityk jako taki nie potrafi zrozumieć architektury aplikacji/systemu.

0

i jeszcze jedno. W jaki sposób (poza modelowaniem formalnym) przekazac programiście to co powinien zacząc programować? Rozumiem ze nie może być to zlepek dokumentacji ze słownymi opisami procesów biznesowych, jakąs ewentualną nieformalną notacją wymyśloną przez analityka oraz tabelami.
Chciałbym zrozumieć wartość analityka który nie przekazuje programiście jasnych wytycznych w jezyku "półtechnicznym" na podstawie których ma on działać typu jakies obiekty, diagram/model erd bazy danych, diagram klas na podstawie których programista będzie budował kod. Oczywiście pomijam w zamysle projekty krótkie i mało skomplikowane gdzie nawet chociażby się chciało ciężko budować formalne modele itd.

2

A co maja twierdzić autorzy ksiażek o UMLu, przeciez nie powidzą ci że jest bezużyczny, bo nie kupisz książki ;)
Nie nadaje się głównie dlatego że to masa dodatkowej roboty, której wartość jest zerowa. Po co ktoś ma 2 godziny malować diagramy, jak można w tym czasie naklepać szkielet takiego ficzera i przy okazji zweryfikować czy w ogóle sie da i czy nie ma po drodze jakiegoś pola minowego?
Taką dokumentacje techniczną, jeśli w ogóle, robi się na bardzo wysokim poziomie - rys architektury, komunikacja między serwisami, schemat deploymentu. Robienie czegoś bardziej szczegółowego mija sie z celem bo trzeba by to non stop poprawiać, dodając sobie pracy. Bo praktycznie każda zmiana w kodzie triggerowałaby zmianę jakiegoś diagramu. Już prędzej można by te diagramy generować z kodu, ale czy w ogóle warto? Dla kogo? Wielu programistów szybciej ogarnie czytając kod / odpalając sobie testy.

Analityk ma rozumieć biznes i potrzeby klienta. Ma umieć odpowiedzieć na pytania "co się ma stać kiedy XYZ", "jeśli użytkownik zrobi X to jaki powinien być tego efekt", "ile...", "gdzie...", "czy...".

0

Wymagania to inna bajka jeszcze :-) Jak chcesz zrozumieć skąd się biorą, to trzeba spojrzeć od góry (i to z wysoka) na organizację, jej strategię, cele, ograniczenia i motywację dla wymagań.
Słowa klucze: "Business Motivation Model OMG" albo "Archimate motivation modeling" (np. http://www.silverbulletinc.com/dm2/File_Browser_2/data/files/References%20and%20Research/TOGAF/Whitepaper_MotivationPrinciplesReqs_BiZZ%20(1).pdf)

Jeśli jesteś na początku swojej drogi w IT, to raczej ciężko będzie Ci przebrnąć przez to, bo nie chodzi tu o wiedzę, a o ubranie doświadczenia w notację i uporządkowanie sobie różnych rzeczy.

Proponowałbym zacząć od BABOKa.

1

Shalom, Yarel zgodzę się z Wami (nie mam wyjścia :) ) ale wlasnie nadal muszę wrócić do jednej kwestii. Oczywiście rozumiem, to programista jest od kwestii technicznych, kodu, definiowania architektury systemu (w uproszczeniu) ale według mnie analityk poza niewątpliwą koniecznością zapoznania się z dziedziną problemu (abstrahując w tym momencie od kwestii IT) i umiejętnością wyciągnięcia informacji od klienta i rozumienia biznesu musi znać też ogólnie kwestie systemowe (np to ze w programowianiu obiektowym jakies byty to klasy, ze wymieniają komunikaty, ze mają jakieś ograniczenia). Według mnie błędem byłoby jedynie słuchać i analizować wymagania (mimo ze osoba to robiąca mogla by być ekspertem od tego) jeżeli ta sama osoba nie widzi ograniczen lub możliwości "technicznych". Inaczej mówiąc analityk może naobiecywać klientowi ze system spełni jego wymagania bo nie zna się na systemach a okaze się później ze większość z tych wymagan nie może być zrealizowana lub może być zrealizowana ale inaczej ponieważ analityk nie zna możliwości systemu a poznanie go możliwe jest np dzięki diagramom, modelowaniu itd. Nie wiem czy nie popłynąłem za bardzo ale licze ze jeżeli mowie zle to mnie poprawicie :)

1
  1. Po co? Paradygmatów programowania jest wiele. Może dana funkcjonalność będzie napisana jako osobny serwis w jakiejś Scali, czysto funkcyjnie? Zresztą nie róbmy sobie żartów, nikt sie nie bawi w projektowanie na poziomie klas, bo to by zajeło milion lat. Jesli w ogóle to projektuje się na poziomie serwisów i komunikacji między nimi. Nijak informacja o tym że w paradygmacie obiektowym są jakieś klasy w niczym tu nie pomoże. Analityk powinien za to rozumieć co system potrafi i mniej więcej ogarniać co jest możliwe a co nie jest, ale to nijak sie ma do jakichś niskopoziomowych szczegółow systemu.
  2. Analityk ma niczego nie obiecywać! Ma słuchać potrzeb i tyle! O tym co się finalnie da albo nie da zrobić zadecydują osoby techniczne na jakimś planningu. Analitycy mogą co najwyżej przedstawić priorytety z punktu widzenia klienta.
0

rozumiem,
W takim razie po co ten cały UML? Próbowałem w tych pytaniach i Waszych odpowiedziach uzyskać na to odpowiedź i okazuje się, że nie wiele z niego wartości a jednak mnóstwo szkoleń, mnóstwo książek, w prawie każdym ogłoszneiu o prace dla analityka wymagana znajomość UML/BPMN. Po co to wszystko skoro w praktyce jest to praktycznie nie używane? Oczywiście pomijam to o czym wspominaliście czyli jakieś wąskie zastosowania lub stare modele kaskadowe. Patrząc na to z perspektywny osoby niedoświadczonej nigdzie nie znajduje info że UML jest tylko do tak wąskich zastosowań

0

UML to taka próba standaryzacji opisu tego jak dokumentować projekty systemu (istniejącego, bądź planowanego). W praktyce masz tak, że w dokumencie nie walisz kwadratu, a w nim napisu, tylko masz sekcję, która tłumaczy notację, której używasz w dokumentacji. Tak, by czytelnik mógł zrozumieć co masz na myśli rysując kwadrat. UML definiuje znaczenie poszczególnych symboli, ale i tak w praktyce ładujesz skrót użytej notacji, bo pewnie czytelnik nie zna UMLa :) W zamyśle miał ułatwiać komunikację, czy ułatwia jak ktoś nie zna języka?

Można przekornie zapytać, po co bootcampowcom znajomość architektury komputerów skoro w praktyce tego nie używają. Czy szeroko pojęta "kultura informatyczna" (czy brzydko pisząc, etos informatyczny) tego wymaga?

W praktyce masz też tak, że przychodzi RFP i trzeba opisać koncepcję rozwiązania i co wtedy? Jakiej notacji użyjesz do opisania proponowanego rozwiązania? Czy może do przetargu stajesz bez projektu i zapewniasz, że będzie uszyte na miarę? :D Stąd też zamawiający często ma życzenia odnośnie sposobu dokumentowania, np. diagramy UML/BPMN lub równoważna notacja.

0

Yarel czyli sugerujesz ze to bardziej wymaganie klienta lub konieczność "ładnej" dokumentacji wymysza stosowanie UML?
W takim razie co zamiast UML? Jakiś przykład jakimi metodami opisane są wszystkie aspekty systemu w dokumentacji projektu? Mam na myśli oczywiście większy projekt w którym do zrobienia dla Banku jest funkcjonalność kupna ubezpieczenia po zalogowaniu się do bankowości osobistej?

0

To wymagania wymuszają stosowanie określonych narzędzi, a nie pomysły "od dziś będziemy jeszcze robić diagramy w UML i na pewno będzie lepiej". Nie produkujesz diagramów UML, czy BPMN jeśli nie masz odbiorców tychże produktów (inaczej marnujesz swój czas :P).

W przypadku zapytań ofertowych, to klient opisuje przedmiot zamówienia, np. http://przetargi.bip.uml.lodz.pl/pokaz/plik.htm;jsessionid=302BBF330DE24F772DA401CBD09317B9?idPlik=5226 Tam sobie poszukaj po słowach BPMN/UML. Ogólnie możesz spodziewać się tego w administracji publicznej (i innych wynalazków, np. punkty funkcyjne opisane
i stosowane przez ARMIR http://www.arimr.gov.pl/uploads/media/Zalacznik_nr_1_do_Zalacznika_nr_4C_do_wzoru_Umowy.pdf), dodatkowo pojawiają się wymagania, że np. dostawca posiada N osób z certyfikacją OCUP/OCUP2 albo alternatywną, TOGAF itd. To jest jednak inna skala projektów, budżety po kilkadziesiąt/kilkaset baniek PLN.

0

Ok ale to są wymagania co do systemu ale może powstać jakas dodatkowa dokumentacja wewnętrzna na podstawie której system musi powstać. Pytanie co taka dokumentacja będzie zawierać? To co wspomniałeś to tak jak mówisz projekty na kilkaset baniek i miesiące albo lata pracy dziesiątek ludzi. miałem na myśli cos bardziej ludzkiego :).

0

Dokumentacja wewnętrzna może powstać, ale... kto będzie jej odbiorcą i jakie ma potrzeby? Nie produkuje się kwitów, żeby produkować. Musi być ku temu potrzeba :-)

Na pewno (chociaż nie wszystko widziałem ;) ) nie jest tak, że developer dostaje zadanie "weź zaimplementuj system X", tylko powinien dostać materiały wejściowe na podstawie, których ma pracować, do których będzie miał pytania/wątpliwości. Te materiały wejściowe powstają na wcześniejszych etapach prac różnych grup osób. Mogą być uszczegóławiane w dokumencie, na daily meetingach, rozmowie itd. Zależy od tego jak firma pracuje.

Ja często spotykam się z takimi grupami:

  1. Odpowiedź na RFP - koncepcja systemu
  2. High Level Design - rozwinięcie koncepcji opisanej w RFP (kamień milowy projektu) i urealnienie tego co się da, albo wypracowanie rozwiązań alternatywnych
  3. Low Level Design - doszczegółowienie JAK to zostanie zrobione - dla klienta
  4. internal LLD - dla zespołu, rozwianie wątpliwości

W strukturze takiego dokumentu odnosisz się do:

  1. Scenariuszy (procesów) biznesowych
  2. Wymagań funkcjonalnych
  3. Wymagań niefunkcjonalnych
  4. Integracji
  5. Konfiguracji
  6. Migracji

Osobiście nigdy nie widziałem RFP, w którym klient życzyłby sobie by prace prowadzone były w trybie "zwinnym". Zazwyczaj kontrakty przewidują płatności po osiągnięciu określonych kamieni milowych projektu i jak pracować zwinnie wobec waterfallowego harmonogramu? :)

Zdarza się też tak, że prace prowadzone są w trybie rozwojowo-utrzymaniowym, tzn. klient coś zleca w oparciu o umowę ramową i wówczas ścieżka jest krótsza, więc dokumentuje się tylko "delty".
Nie ma tak, że "zobacz kliencie jaki diagram klas zrobiłem, prawda że fajny?" (a klient, "po wuja mi ten diagram klas?"), tylko robi się minimum i poprawia na życzenie "weź drogi dostawco dodaj diagram sekwencji ilustrujący komunikację między systemami biorącymi udział w realizacji tego scenariusza, tylko bez zbytniej dbałości o szczegóły implementacyjne", albo kolega z zespołu "weź mi to rozrysuj zamiast opowiadać i pisać maile".

0

Yarel jasne z tym, że powiedz proszę jak sformalizować te wymaania itd w dokumentacji o ktorej mówisz? Odnoszę się do integracji, konfiguracji itd ale pod tymi pojęciami kryją się szczegóły stricte techniczne. Zeby przedstawawić zagadnienia integracji nie będę przeciez klepał rozprawek. Według mnie w takiej sytuacji potrzeba wlasnie jakiegos formalizmu. Być moze nie musi to być UML ale nie sądzę tez aby taka dokumentacja była od dechy do dechy opisem słownym, tabelkami czy jakimiś rysunkami. Czy ja jako analityk nie powinienem uzyc jakiejś formalnej notacji do przedstawienia takich kwestii? Np nie pisze w wordzie ze moduł X odwoluje sie do modulu Y poprzez jakies API itd.
Raczej wyobrazalbym sobie stworzenie diagramu (lub kilku diagramów) np w UML gdzie formalnie za pomocą np diagramu pakietów lub jakimś innym "narysuje to" - oczywiscie z opatrzeniem tego jakims opisem. Tak samo np przeplywy. Tak samo jakas logika systemu, typu diagram aktywności. Czy nie lepiej jezeli programista dostanie diagram na ktorym widzi ze jakis obiekt np faktura tworzona jest w ramach okreslonej czynnosci, ze np klient moze żadać 5 kopi faktur do jednego zamówienia (za pomocą liczności) niż pisać to po prostu ciągiem zdan?

0
donkosiorro napisał(a):

...

Według mnie w takiej sytuacji potrzeba wlasnie jakiegos formalizmu. Być moze nie musi to być UML ale nie sądzę tez aby taka dokumentacja była od dechy do dechy opisem słownym, tabelkami czy jakimiś rysunkami.
...

Ale tak właśnie jest, rysunki, tabelki, opisy słowne :-) Rysunki bywają diagramami w BPMN czy UMLu. Zbytni formalizm zabije przekaz i trzeba zastanowić się kto będzie odbiorcą dokumentacji i czy ma do niej jakieś wymogi. Tam gdzie mam okazję pytać, to zawsze pytam czy klient ma jakiś szablony dokumentów (HLD, interface agreement itd.), w których chciałby/wymaga zobaczyć opis rozwiązania.

0

W takim razie jakie kompetencje są niezbędne jeżeli znajomość UML/BPMN praktycznie do niczego się nie przyda? :)

0
Koko1 napisał(a):

rozumiem,
W takim razie po co ten cały UML?

Żeby zrozumieć zapisy w książkach o wzorcach projektowych.

A poza tym... myślę, że UML warto poznać dla inspiracji, a niekoniecznie żeby używać ściśle.

Zresztą i tak dzisiaj zwykle się diagramy pisze bardziej freestylowo - niby są jakieś prostokąty, są strzałki, ale mało kto patrzy choćby na rodzaj strzałek. Diagramy się rysuje teraz bardziej kontekstowo/ad hoc niż formalnie. Może to dobrze, może nie? Może potrzebujemy nowej wizualnej specyfikacji? (bo mam wrażenie, że UML jest średnio udanym standardem).

W takim razie jakie kompetencje są niezbędne jeżeli znajomość UML/BPMN praktycznie do niczego się nie przyda? :)

UML jest fajne o tyle, że zachęca do wizualnego myślenia o zależnościach w projekcie. To, żeby myśleć o modułach(np. klasach) jako częściach diagramu. To co należy wynieść z UML to sposób myślenia, a nie to, która strzałka co oznacza.

Z drugiej strony mam wrażenie, że UML jest słabe w opisywaniu "aplikacji w działaniu". Aplikacje to nie do końca są po prostu statyczne prostokąciki, które dziedziczą i się komponują. Jak opisać proces, zmianę czegoś, części działającego mechanizmu? Nie wiem, czy to się da w UML zrobić. Już tradycyjny flowchart byłby lepszy https://en.wikipedia.org/wiki/Flowchart . Chociaż to też jeden z wielu sposobów zapisu i też dość ograniczony.

Wydaje mi się, że designerzy UX mogą mieć jakieś swoje sposoby na zapisywanie takich rzeczy. Ale oni całe aplikacje mają do projektowania.

0

w takim razie jak nie UML to co? Być może jakaś inna notacja a może jekaś metodyka która nie korzysta z takich notacji?

0

Musisz chyba zebrać doświadczenie i wtedy będziesz wiedział.

Ew. możesz podpatrzeć jak działają doświadczeni analitycy, np. poszukać na twitterze po hashtagach, albo zapisać się do jakiejś grupy analityków na FB, albo pooglądać jakiś filmik z konferencji analityków albo vloga prowadzonego przez analityka. Teraz są takie czasy, że o każdym zawodzie można znaleźć w internecie dogłębne informacje, jak działają, jakich narzędzi używają itp. Albo zadać nawet to samo pytanie, które zadałeś, ale w tym miejscu internetu, gdzie są analitycy, a nie programiści.

Swoją drogą kto to jest ten cały analityk? (i jak to będzie po angielsku? Google coś pokazuje jak Programmer Analyst, ale nie wiem, czy to to).

Czy nie lepiej jezeli programista dostanie diagram na ktorym widzi ze jakis obiekt np faktura
tworzona jest w ramach okreslonej czynnosci, ze np klient moze żadać 5 kopi faktur do jednego zamówienia

Czyli to taki UX designer trochę, który projektuje rozwiązania pod kątem użytkownika?

1

Przeginacie z tym spłaszczaniem UML'a. Potem dostajesz diagram i uj wie, czy ta strzałka to realizacja, zależność, czy agregacja, asocjacja i ile do ilu? Niby jaki jest sens rysowania po swojemu, żeby być oryginalnym? Niby w jaki sposób używanie niestandaryzowanej formy ma zabić przekaz? Takie "diagramy" najczęście przypominają zapiski psyhopaty a nie prosty przekaz.

0

._. ja tak właśnie nie myślę, ale inni wskazują, że należy luźno podchodzić do tej kwestii i nie przywiązywać większej wagi do znaczenia diagramów

1 użytkowników online, w tym zalogowanych: 0, gości: 1