Przyjrzyjmy się teraz diagramowi sekwencji na rysunku 10 i zastanówmy się co można z niego odczytać. Jeżeli chodzi o sposób działania to mamy jak na dłoni pokazany cały przebieg zmiany stanu problemu. Użyteczność tego diagramu polega również na tym że widać na nim jak na dłoni błędy architektoniczne rozwiązania. Jeżeli przyjrzycie się sekwencji działań wychodzących z obiektu Model::ProblemWorkflow to zauważycie dwa problemy. Pierwszy polega na bardzo dużej ilości działań wychodzących z tego obiektu do obiektów z którymi współpracuje. Wyraźnie widać tu brak przekazywania odpowiedzialności za działania do obiektów współpracujących. Konsekwencją tego jest mało czytelny diagram i trudno modyfikowalny kod. Wprowadzanie poprawek to już działanie do zrobienia w środowisku programistycznym. W tym przypadku usunąłem w VisualStudio twór ProblemWorkflow i przeniosłem odpowiedzialność za wykonanie działania na klasę Problem. Ponadto rozdzieliłem rozbudowaną metodę ExecuteActions na mniejsze funkcje, którymi łatwiej będzie zarządzać w kodzie później. Po zmianach wygenerowałem ponownie diagram, tym razem uzyskując efekt z rysunku 11.

Rysunek 11. Wygenerowany diagram sekwencji po poprawkach (delikatnie ściśnięty przez autora)

Jest trochę lepiej i czytelniej. Dalej możecie działać sami. Powodzenia.