UML, Data Flow diagram i inne metody planowania kodu

0

Często, przed przystąpieniem do implementowania funkcjonalności, rozrysowujecie je sobie w postaci diagramów? Albo chociaż rozpisujecie na kartce, lub w pseudokodzie, jak mają z grubsza wyglądać? Chodzi mi tutaj zarówno o podejście makro, do tworzenia całych aplikacji, jak i do tworzenia pojedynczych klas.

Często spotykam się z opinią, że to strata czasu i diagramy to rysowało się w gimnazjum. Z drugiej strony, ciężko mi sobie wyobrazić taką biegłość programowania, żeby kolejne klasy i moduły pisane z pod palca, składały się w logiczną i spójną całość.

0

Kiedyś więcej pisałem diagramów, ale teraz już nie muszę, bo zwykle jestem w stanie sobie wyobrazić jak to będzie wyglądać. Więc po co rysować (no chyba, że dla dokumentacji).

Chociaż nie zawsze wszystko ogarniam umysłem, to wtedy owszem, mogę coś narysować, albo np. opisać rozwiązanie w pliku tekstowym - taki dialog ze sobą-wewnętrzna burza myśli, i np. opisuję w takim pliku jakbym to rozwiązał (normalne zdania po polsku albo po angielsku) i piszę przykłady użycia modułów, itp. (tzn. piszę wtedy kawałki kodu, ale takie, które w żaden sposób się nie uruchomią, tylko spełniają rolę pseudokodu).

Czasem też prototypuję rozwiązanie, robię coś działającego, ale bardzo szybko i byle jak, po to, żeby jak najszybciej zobaczyć jakie konkretne problemy techniczne trzeba będzie rozwiązać (i w jaki sposób), jak to będzie mniej więcej wyglądać w praktyce itp. Bo jednak planować można sobie wiele rzeczy, a się okaże, że w praktyce problem jest zupełnie inny.

A potem albo refaktoruję kod na ładniejszy, albo piszę od nowa na czysto.

UML, Data Flow diagram

UML czy inne konkretne formalne techniki dobre są dla inspiracji, ale nie musisz się przejmować konkretnym sposobem zapisu. Dzisiaj i tak każdy pisze jak chce, a UML i tak wcale nie jest zbyt czytelny.

1

Diagramy to część dokumentacji.
Obecnie preferuję żywe diagramy (jeśli już mam je stosować - BPMN).
Idealnie byłoby gdyby analityk je rysował w BPMN, a ja doszczegóławiam. Niestety moi analitycy używają Painta / Worda...

Jak chcesz zaoszczędzić czas to jest kilka narzędzi które umożliwiają rysowanie przy pomocy "skryptów":

  • yUML - diagrams from text, online (image) & offline generation
  • Mscgen - automatic generation from text input
  • js-sequence-diagrams - JavaScript tool (OSS)
2

Treść i narzędzia dostosowuję do odbiorców.
Ja w trybie one-man-army nie robię daigramów, bo wszystko mam w głowie ;)

Jeśli trzeba wiedzę udokumentować, to w zależności od tego dla kogo jest ta wiedza i co trzeba pokazać, to używam:

UML:

  • diagram komponentów,
  • przypadków użycia,
  • sekwencji,
  • klas,
  • stanów

BPMN - co tu dużo pisać, procesy

PowerPoint - "rysunki" - szkice rozwiązań na bardzo wysokim poziomie (opcja1..opcja3) + zalety/wady + koszty
Chyba, że narysowanie w czystym power poincie wymaga zbyt dużego klikania, to przepinam się na BPMN/UML.

Ostatnio spodobał mi się Archimate, ale to inny poziom modelowania niż te wspomniany w inicjalnym poście.
Przykładowy tool

0

U nas poglądowie diagramy zawsze tworzone są przez osobę zlecającą, która w ten sposób mniej więcej przedstawia funkcjonalne zależności oraz związki przyczynowo-skutkowe zadania.
Później używamy Gherkina i w ten sposób opisujemy zadanie, dzięki czemu od razu jest gotowiec pod automatyczne testy. Co prawda wymaga to trochę pracy w przygotowanie całości, jednak później są mniejsze wątpliwości, kto co miał na myśli i jak to własciwie miało działać.
Ogólnie diagramy są bardzo przydatne, gdy nad projektem pracuje większa liczba osób, gdyż łatwiej jest tłumaczyć i trzymać się pewnych wytycznych oraz zmniejsza to szumy informacyjne. W przypadku, gdy sam coś robię od razu używam Gherkina i praktycznie nie stosuję żadnych diagramów.

0

Zamiast planować, wymyślać, rozrysowywać całą wielką architekturę, którą i tak trafi szlag i zmieni się conajmniej trzy razy jak już zaczniesz klepać, proponuję powrócić do starych dobrych zasad jak SRP, OCP, DRY, czy KISS i po prostu pisać moduły, które są generyczne, skalowane, utrzymywalne, autonomiczne i składają się z mniejszych modułów w równym stopniu generycznych, skalowanych, utrzymywalnych, autonomicznych. Nigdy nie wiesz jak potem coś co naklepiesz będzie używane

1
vpiotr napisał(a):

Idealnie byłoby gdyby analityk je rysował w BPMN, a ja doszczegóławiam. Niestety moi analitycy używają Painta / Worda...

Ło panie. Moi analitycy używali BPMN, co więcej dzieki activiti my te diagramy odpalamy.
Dużo kluczowych procesów przez nie przechodzi, i już się nie da od nich odspawać. Jakkolwiek, analitycy dawno stracili nad tym kontrole i już nie grzebią tylko mówią co trzeba zmienić.
Wiec, jak chcesz to mamy w zasadzie wieczne dostępne stanowisko grzebacza w tych diagramach, trzeba być dość biegłym w javie, niezłym w BPMN, droolsach i nie mieć do siebie szacunku.
Sądze, że kolega który obecnie się tym zajmuje wypali się w ciągu 2-3 miesiecy, albo umrze na raka. Będzie miejsce.
Dla zachęty:
Jeden z kluczowych procesów mamy wydrukowany - na połączonych arkuszach A2 - rozwieszony wzdłuż korytarza, fizyczne przejsćie od początku do końca jest zalecane w ramach dziennej dawki ruchu dla programisty. Acha, i to jest widok wysokopoziomowy bez podprocesów :-)

0

A jak budowalibyście dom, robilibyście to bez projektu? Ja jednak wolę najpierw coś zaprojektować, to mi daje możliwość zweryfikowania poprawności mojej koncepcji i strzeże mnie przed grubymi pomyłkami. Oczywiście wszędzie jest potrzebny zdrowy rozsądek. Ta czy inna metoda modelowania to tylko narzędzia w rękach inteligentnych ludzi. I tak, do budowy szopy wystarczą szkice (moja ulubiona forma przy małych systemach).

0

Mapy kontekstów razem z modułami, czasem agregatami. Rysowanie prostych procesów to strata czasu. Jeśli chodzi o dokumentacje to bardziej stawiam na textowe Use Case 3C i testy oparte o BDD, diagramy to dodatek, który obrazuje konteksty, dziedziny, moduły i w szczególnych wypadkach skomplikowane procesy.

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