Witam wszystkich serdecznie.
Mój projekt to aplikacja w javie do wystawiania faktur, robienia raportów, zamówień itp. Na początku zrobiłem kolejno diagram przypadków użycia, aktywności, sekwencji i klas - to przedstawiłem mojemu wykładowcy który zaakceptował. Następnie zacząłem kodować - wykładowca to także zaakceptował(oczywiście działanie aplikacji bo kodu nie widział). Teraz podczas pisania dokumentacji doszedłem do wniosku, że mój wcześniejszy diagram klas nie za bardzo zgadza się z tymi klasami co mam w kodzie tzn w kodzie mam ich więcej oraz są trochę inne metody i też jest ich więcej. Wiem, że teraz z tych klas co mam w diagramie raczej ciężko by było utworzyć taki program jak mam teraz. Myślę, że po prostu nie da się przewidzieć wszystkiego. Czy mam teraz poprawić mój diagram klas na taki aby wszystkie klasy były takie same jak w kodzie. Czy może oba diagramy będą poprawne. Nie wiem co mam powiedzieć wykładowcy. Doradzicie coś co mam z tym zrobić.
Jestem zwolennikiem Agile, więc podpowiem Ci jak to wygląda w tej metodyce.
- Założenia projektowe i architektura zmieniają się co jest oczywistą oczywistością - niektóre powstają tylko na chwilę na kawałku kartki i potem przepadają
- Diagramy nie powinny pożerać za dużo czasu, poziom szczegółowości nie może być za duży (umieszczanie wszystkich metod klasy na diagramie mija się z celem). Ma być ogólny, w przeciwnym wypadku zmiany musiałbyś wprowadzać co kilka chwil. Diagram ma przedstawiać model a nie implementację.
Czyli poprawnie będzie jeżeli w dokumentacji odwołam się do jakiejś klasy z "kodu" a której nie ma na diagramie? (oczywiście diagram też będzie wcześniej w dokumentacji)
Jeśli zmiany były istotne to nanieś je na diagram, ale tak aby zawierał jedynie podstawowe dane o modelu. Klasy mniej istotne możesz umieścić na diagramie jako klasa bez metod, jedynie aby była informacja o jej istnieniu.
A najprościej chyba byłoby wygenerować sobie diagram klas z kodu i tyle.
somekind napisał(a)
A najprościej chyba byłoby wygenerować sobie diagram klas z kodu i tyle.
Dla uproszczenia tak, jednak specyfikacja powinna poprzedzac implementacje, wiec generowanie specyfikacji z implementacji jest troche nie tego. Jednakze, w rzeczywistosci nigdy nie widzialem UML'a w 100% zgodnego z kodem. ;]
To tyle z mojej strony, jezeli chodzi o to "jak jest". ;]
Ja zrozumiałem, że trzeba napisać dokumentację (a nie specyfikację) programu, więc opisać istniejące w nim klasy. Może nie zrozumiałem autora.
somekind napisał(a)
A najprościej chyba byłoby wygenerować sobie diagram klas z kodu i tyle.
Nie jestem jakimś zaawansowanym specjalista ale żeby diagram generować z kodu - pierwsze słyszę. Chyba na odwrót ;)
@aglasek a widzisz wielką różnicę między generowaniem w tą czy w drugą stronę? Są narzędzia które potrafią i jedno i drugie ;)
A wiecie może jakimi narzędziami można wygenerować diagram klas (z asocjacjami) z kodu.
Np. Enterprise Architect.
Zastanawiam się tylko czy mogę użyć w mojej pracy dyplomowej EA, bo on przecież płatny jest. Sprawdziłem Netbeans'em i też można, tylko coś relacji nie pokazuje, trzeba już ręcznie tworzyć :-/
Ja używałem, dlaczegóż by nie? Nigdy nie było mowy, że nie można używać wersji trial w pracach dyplomowych.