Praca z UML, Znać - nie znaczy umieć korzystać... Opcje

[DeyV]

Witam

Od pewnego czasu staram się lepej zorganizować swoje projekty, i w lepszy sposób projektować zarówno strukturę OOP, jak i sam przebieg działania aplikacji.
I nagle okazalo się, że moja wiedza i umiejętności związane z UML są stanowczo niewystarczające. Stąd stwierdziłem, że muszę poszukać dodatkowych materiałów lub książek, które pomogą mi nauczyć się pracy z UML.

Ale zanim - może wspomnę, co mnie zmartwiło.
Znam podstawy UML, znaczenie poszczególnych diagramów, rozrysowywanie poszczególnych związków itp. A przynajmniej podstawy tego.
Mam również i znam podstawowe zasady obsługi paru programów do tworzenia diagramów, a nawet sprawiłem sobie tablice do rysowania (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Niestety - okazuje się, że bardzo trudno przychodzi mi z tym pracować.
Nie wiem, od których diagramów należałoby rozpocząć, jak je z sobą łączyć, jak rozpocząć i w którym momencie skończyć prace z projektem.

No i potrzebuję pomocy.
Potrzebuję materiałów i publikacji, które nie tylko przekażą podstawowe zasady UMLa ale również pokażą jak z nim żyć, tak by było to udane "współżycie" (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Możecie coś zaproponować?

[anas]

Hej ponownie.

Zapewne czytałeś SDJ Extra poświecno Projektowaniu SI - przyznam szczerze że wyjątkowo dobre teksty w tym numerze były. Co do Twojej opinii jest jak najbardziej słuszna, bo nie trzeba dokumentować wszystkiego jak leci - głównym czynnkiem jest czas - czas jak wszyscy wiemy to pieniądz - dlatego należy znaleźć ten przysłowowiowy złoty środek pomiędzy dokumentacją a samą implementacją. Jednak tkwi w tym wszystkim duże i ważne ale, mianowicie:

- dobra dokumentacja już na etapie projektowania systemu (bo do tego służy właśnie UML - a nie jak można mniemać: wytwarzamy coś, a później do tego powstają diagramy, projekt i opis) może spowodować że zanim wyjdzie z pod naszego palca jakakolwiek linia kodu znajdziemy wiele błędów i usuniemy je - a co dla mnie jeszcze ważniejsze, przecież z UML'a możemy generować kod - możemy oddając projekt do implementacji wręczyć programistom szkielet klas, interfejsy z jakich mają korzystać i inne ważne elementy - po to powstają narzędzia typu CASE, żeby ominąć pewne etapy wytwarzania. Podobnie ma się to do struktury danych, nie wyobrażam sobie dzisiaj przy dużym złożonym systemie pisać dla każdej tabeli Create... i zastanawiać się gdzie postawiłem nie tak przecinek... - tu się właśnie traci czas i pieniądze, jak (błędnie w mojej opinii) uważa się że dokumentacja nie jest potrzebna - jej nadmiarowość owszem, ale nie ona sama.

Idąc dalej należy pamiętać (przynajmniej w moim przypadku), że w małych firmach bywa tak, że na jedną osobę spada rola zarówno analityka, projektanta oraz osoby implementującej dany system - często gęsto stajemy się również testerami oraz konserwujemy to co stworzyliśmy. W dużych firmach programista dostaje projekt oraz wytyczne którą część ma implementować i mimo faktu że znajdzie (jego zdaniem) błąd ma zakichany obowiązek zaimplementować to w/g wytycznych - zgłaszając ów błąd do weryfikacji dla wyższego szczebla(projektanta) - ten jeśli problem dotyczy założeń, przekazuje go grupie analityków - gdyby w dużych zespołach nie dokumentowano wszystkiego z nadmiarowością dziś zamiast dużych wydajnych systemów mielibyśmy dziwaczne twory, mutanty nie nadające się do rozwoju.

To tyle mojej opinii na ten temat.

pozdrawiam

anas