Kilkanaście dni temu opublikowałem 5 wskazówek dla analizy w ujęciu AGILE Scotta Amblera. Chciałbym je teraz uzupełnić o kolejne spostrzeżenia. Tym razem dotyczące przede wszystkim modeli.
1. Modele z czasem ewoluują
Możesz zacząć od podstawowego przypadku, ale szybko postanowisz przekształcić go w kilka systemowych przypadków użycia. Możesz również postanowić opracować zbiór diagramów Object-Role Model (ORM) umieszczone na białej tablicy jako wkład w diagram klas UML, który z kolei przekształci się w kod źródłowy.
2. Modele analiz muszą być jedynie wystarczająco dobre
Staraj się, aby twoje modele były jak najbardziej proste i o lekkiej konstrukcji. Skup się na zrozumieniu, nie na dokumentacji. Użyj najprostszych i najbardziej ogólnych z dostępnych narzędzi. Zdaj sobie sprawę z tego, że Twoje modele nie muszą być doskonałe.
3. Każdy model może zostać użyty dla wielu celów
Diagramy przepływu danych można użyć zarówno jako techniki analizowania w celu zbadania istniejących procesów biznesowych jaki i jako techniki projektowania, aby je zdefiniować na nowo. Podobnie, modele Klasa Zobowiązanie Współpraca (CRC) mogą być użyte zarówno dla celów analizy i projektowania jak i dla przypadków użycia dla wymagań, analiz, a czasem nawet projektowania.
4. Linie modelowania są często niewyraźne
Tradycyjna koncepcja faz tworzenia oprogramowania – wymagania, analiza, projekty, kodowanie, testowanie i wdrażanie – pozostawiło u wielu osób przekonanie, że musimy dokonać rozróżnienia pomiędzy różnymi rodzajami modelowania. Ale jeśli osoba zainteresowana poda opisze nam jakiś wymóg, jak na przykład potrzebę zdobycia adresu domowego studenta, to często przejdziemy przez te fazy w odstępach kilku sekund. Zaczniemy myśleć o tym, jak powinien wyglądać interfejs użytkownika, o różnych elementach danych, jakie mają zostać zdobyte, o potrzebie klasy Adresy, możliwości zastosowania wzoru Contact Point, potrzebie stworzenia tabeli Adresowej w bazie danych, i jak napisać kod dla tego wszystkiego w javie, tym samym odchodząc od wymogu poprzez analizę i projektowanie do pisania kodu bez zatrzymywania się aby stworzyć kompletny model wymagań, czy też kompletny model analiz, itd. Jako że istotnym jest zadawać pytania takie jak czego potrzebujesz (wymogi), co to oznacza (analiza) i jak zamierzamy to zbudować (projekt), często będziemy to robić w sposób iteracyjny, nie seryjny.
5. Używaj tej samej terminologii co udziałowcy
Nie zmuszaj udziałowców Twojego projektu do używania sztucznego, technicznego żargonu. To dla nich system jest tworzony; dlatego też w modelu systemu powinieneś użyć ich terminologii.
