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

[patrycjusz]

@patrycjusz - mowisz o swojej rzeczywistosci, czy powaznego dokumentowania projektow? To ze akurat w Twoim przypadku tak nie jest, nie oznacza ze taka jest(winna byc) rzeczywistosc - opini na temat wytwarzana oprogramowania jest tyle ile technologii * ilosc osob sie tym zajmujacych na globie. Twoja nie musi byc sluszna w moim mniemaniu, jak i odwrotnie, dlaczego wiec stwierdzasz i generalizujesz?

nie generalizuje, stwierdzam jedynie na bazie swojego doświadczenia, że od dokumentacji ważniejsze jest samo podejście do projektu,
Co do mojego doświadczenia i mojej rzeczywistości - bez osobistych wycieczek proszę (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

DeyV wyraznie zapytal o UML, dlatego przytoczylem jak powstaja projekty ktore ja dokumentuje - i jest to wlasnie rzeczywistosc. Ksiazki czesto nadmiarowo opisuja problem, ale czy dobra, kompletna dokumentacja jest zlem? Rozumiem ze miales tutaj na mysli wydajnosc przy wytrwarzaniu kodu, a to calkiem inny czynnik i stosuje sie go przy wycenianiu projektów. Wtedy wazy sie czynnik czasu i koniecznosc wykonania niektorych z podanych etapów - lub ich brak.

Twierdzę jedynie, że z wiedzy podawanej w książkach trzeba umiejętnie adoptować wybrane elementy do otaczającej projekt rzeczywistości (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Owszem czym szybciej powstanie kod tym lepiej - opisywane przez Ciebie zagadnienia wkraczaja w obszary programowania ekremalnego gdzie w trakcie produkcji oprogramowania uczestniczy klient - owszem mozna to stosowac i to czesciowo badz w pelni, ale czy trzeba i czy to wyklucza dobra dokumentacje? Co do adoptowania wzorców - to chyba jasne że lepiej bazować na rozwiazaniach sprawdzonych.

pozdrawiam

anas

Nie chodzi o prędkość powstawania kodu. Metodologie typu FDD i TDD kładą nacisk na jakość kodu od samego początku i możliwości jego rozwoju -> nie mają nic wspólnego z dokumentacją, bo dokumentacja sama w sobie jest, była i będzie robiona, ale ważne jest aby sama w sobie nie była meritorium a jedynie czynnikiem wspomagającym prace.

również pozdrawiam,
patS

Ten post edytował patrycjusz 8.01.2006, 18:28:36