UML - co do nauki

Odpowiedz Nowy wątek
2018-10-29 22:29
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

Pozostało 580 znaków

2018-10-30 00:48
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.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 2x, ostatnio: Shalom, 2018-10-30 00:50

Pozostało 580 znaków

2018-10-30 07:01
Nieposkromiony Kura
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?

Pozostało 580 znaków

2018-10-30 07:17
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?

Pozostało 580 znaków

2018-10-30 09:16
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

Pozostało 580 znaków

2018-10-30 09:19
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.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2018-10-30 09:21

Pozostało 580 znaków

2018-10-30 09:28
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


"Chodzenie po wodzie i tworzenie oprogramowania wg specyfikacji są łatwe, o ile woda i specyfikacja są zamrożone" - Edward V. Berard

Pozostało 580 znaków

2018-10-30 09:31
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 :)

Pozostało 580 znaków

2018-10-30 09:36
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?

Pozostało 580 znaków

2018-10-30 09:43
._.
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.

edytowany 1x, ostatnio: ._., 2018-10-30 11:06

Pozostało 580 znaków

2018-10-30 09:43
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.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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