🚀 go-pugleaf

fireball wrote:
> Proszę o opinię analityków oraz projektantów i programistów, odnośnie
> procesu (funkcjonalnej) analizy systemowej w waszych firmach.
> Czy w analizie funkcjonalnej tworzone są (oprócz dokumentów przypadków
> użycia) także diagramy aktywności? U mnie w pracy panuje opór przed modelami
> dynamiki, którego nie rozumiem. Proszę o opinię, jak to się robi w innych
> firmach.
>

Hej,

Być może wszystko zależy od profilu tworzonego
oprogramowania/działalności firmy ale akurat w mojej branży
(telecom) nie wyobrażam sobie analizy bez tego typu diagramów.
Stanowi to jeden z kluczowych elementów analizy.

Michal

Użytkownik "Michal Slocinski" <michal.slocinski@gmail.com> napisał w 
wiadomości

> (telecom) nie wyobrażam sobie analizy bez tego typu diagramów.
> Stanowi to jeden z kluczowych elementów analizy.


Czy do tworzonych diagramów dynamiki są u Was tworzone dokumentacje w 
postaci słownych scenariuszy (use case)?

Zmierzam do potwierdzenia bądź obalenia tezy, że model dynamiki jako byt 
wtórny (wobec słownych scenariuszy przebiegu) nie ma sensu i jeśli ma 
powstać, to powinien być on punktem wyjścia, do czego nie są przekonani moi 
współpracownicy..


dzięki za dalsze komentarze.

Użytkownik "fireball" <fireball@onet.kropka.eu> napisał w wiadomości 
news:eeb0v0

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!


Prosze o opinię osób mających praktyczną styczność z powyższymi elementami 
procesu analizy.

> 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ć.

Użytkownik "Kurciok" <kurciok@poczta.BEZSPAMUonet.pl> napisał w wiadomości 
news:eec203

> 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.
a scenariusz nie?

> 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 :)
wyrysowanie diagramu dużo pracy? jedną ręką czytam scenario, drugą ryruję 
diagram - współbieżnie :) Czas: zero :)

> przypadków użycia, stanów oraz klas pozwalają testerą na przetestowanie 
> aplikacji.
to wystarcza do zbudowania przypadków testowych?

>> 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 :)
> wyrysowanie diagramu dużo pracy? jedną ręką czytam scenario, drugą ryruję 
> diagram - współbieżnie :) Czas: zero :)

Jak się ma szczegółowo napisany scenariusz :) (tylko że scenariusz się chyba 
pisze po to aby tylko przedstaiwć ogólny zarys tego jak ma funkcjonować 
system). Ja w diagramie czynności w fazie analizy widział bym coś bardziej 
wchodzącego w szczegóły niż tylko kopia tego co jest w scenariuszu. A ja te 
szczegóły wole odrazu sobie przedstawić w formie obiektowej na diagramie 
stanów. Bo od tego diagramu mogę odrazu wyjść do programowania obiektowego, 
a do jego stworzenia wcale nie jest potrzebny diagram czynności. A za pomocą 
diagramu stanów można rozwiać tak samo wszystkie wątpliwości co do tego jak 
ma działać system.

>> przypadków użycia, stanów oraz klas pozwalają testerą na przetestowanie 
>> aplikacji.
> to wystarcza do zbudowania przypadków testowych?

Jakie diagramy według ciebie pomagają w budowaniu przypadków testowych? 
Oczywiście oprócz diagramu przypadków użycia i scenariusza.