🚀 go-pugleaf

> może ja uściślę sformułowane zagadnienie, że:
>> model dynamiki powinien być on punktem wyjścia
>
> otóż zacytuję może fragment z książki "Język UML 2.0" autorów 
> Wrycza/Marcinkowski/Wyrzykowski:
> etapy tworzenia diagramów czynnosci:
> 1. zidentyfikowanie podstawowych czynności i sygnałów 
> na_podstawie_scenariusza_przypadków_użycia
> 2. połączniu ich za pomocą przepływów sterowania
> 3. identyfikacji decyzyjnych i współbieznych przepływów sterowania
>
> wobec powyższego zapisu niełatwo mi uzmysłowić współpracownikom potrzebę 
> zamodelowania diagramu jako punktyu wyjścia (a dopiero poźniejszego zapisu 
> scenariuszy), mimo, iż powstające scenariusze uginają się od niespójności!

Wydaje mi się że z UMLem nie należy przesadzać ze spójnością diagramu 
przypadków użycia także :) (jeśli w ogóle coś takiego istnieje). Diagram 
przypadków użycia razem ze scenariuszem jest istotnym elementem dla 
zrozumienia tego co ma umożliwać system jego użtkownikom. Diagram czynności 
służy już czemuś innemu i wskazuje na to w jaki sposób przebiegają dane 
procesy. Jeśli nie rozumie się danego przypadku użycia to można rozrysować 
jego diagram czynności (tak aby rozwiać swoje wątpliwości). Jak chcesz takie 
diagramy robić dla całego systemu to czeka cię dużo pracy :) no ale kto wie 
jak wasz klient będzie miał czas aby się nad tym zastanowić to może się to 
do czegoś przyda. Ja trochę nie lubie tego diagramu bo jest on za bardzo 
algorytmiczny i trochę przypomina mi programowanie proceduralne :) trochę 
cieżko przechodzi się od niego do programowania obiektowego. Osobiście 
zamiast tego diagramu wole zrobić ogólny diagram stanów dla poszczególbych 
obiektów w stystemie. Oczywiście na stapie analizy powinien być on ogólny a 
poszczególne obiekty powinny mieć może trzy góra cztery możliwe stany (na 
tym etapie nie warto wchodzić w szczeógły).

Jeśli chodzi o pisanie scenariuszy to jak najbardziej tak przypadki użycia 
bez scenariusza raczej mało mówią. No i dobrze by było aby klient sobie 
przeczytał co dla niego robicie ;)

A tak na marginesie to według mnie najprzydatniejsze w UMLu są diagramy 
przypadków użycia, stanów oraz klas i to w fazie analizy. Programiści 
powinni już tylko robić szczegółowy diagram klas (jeśli odpowiednio 
zaprojektuje się aplikacje to w diagramie klas można zawrzeć diagram 
stanów).

Stosując te trzy diagramy już masz aż za dużo. Pozwalają się one zorientować 
w tym co trzeba napisać i pozwalają testerą na przetestowanie aplikacji. 
Oczywiście inne diagramy też się czasem mogą przydać wszystko zależy od tego 
jaki masz probelm ale jeśli chodzi o moje zdanie to w 95% powinny 
wystarczyć.