Projekt systemu w php, "metodyka obiektowa" Opcje

[Nightstalker]

Cześć,
zabieram się właśnie za dokumentacje systemu napisanego w php (wspomaganego przez zend framework)... No i mam z tym mały problem, bo nigdy wcześniej nie robiłem tego zgodnie z teorią serwowaną na uczelniach, a tego właśnie wymaga mój projekt :-) W pracy zawsze zaczynam od analizy, której efektem są przypadki użycia. Przypadki są konsultowane z klientem i na tej podstawie wyodrębnione są główne "obiekty systemu" i dalej schemat bazy. W tym miejscu powinienem jednak zrobić diagram klas, ale niech mi ktoś powie - jak przedstawić na takim diagramie standardowe biblioteki zenda? Przykładowo, mój obiekt "faktura", ma możliwość zapisu i wydruku, ale sam z siebie tego nie robi, tylko odwołuje się do managera, który z kolei przy użyciu dao czyni zapis. To samo z drukowaniem - odpowiedni manager korzysta z innej klasy do wydruku. Obiekt faktury jednak sam w sobie nie ma metody w stylu "drukuj", a tego chyba wymaga projekt systemu w metodyce obiektowej... Bardzo proszę, niech ktoś biegły w tym temacie mi to wytłumaczy... Googluje już od dwóch tygodni i nie spotkałem się z wyjaśnieniem wyczerpującym temat. Mądre książki też np. opisują diagramy sekwencji - orientuje się o co w nich chodzi i potrafię je tworzyć dla głównych obiektów systemu, ale problem pojawia się gdy mam zamiar przedstawić jakiś zendowy proces 9np. sprawdzanie formularza)... Może za bardzo skupiam się na szczegółach? Może powinienem zrobić po prostu diagram klas dla głównych obiektów, wyodrębnić ich atrybuty oraz metody, na tej podstawie zrobić erd i schemat bazy, a szczegóły implementacji przedstawić jakoś inaczej? Jeszcze raz proszę kogoś biegłego o pomoc! Pogubiłem się w tym wszystkim :-)

[bastard13]

Diagramy klas nie powinny zawierać absolutnie żadnej informacji nt. wykorzystywanych w projekcie frameworków, orm itp., nawet język programowania nie powinien być na tym etapie uwzględniony. Tego typu sprawy można ewentualnie dodać do wymagań niefunkcjonalnych aplikacji.
Co do samego modelu, to twój przykładowy obiekt faktura może mniej więcej wyglądać tak:
Faktura
-dataWystawienia:date
-wystawiajacy:Company
-kupujacy:Customer
+drukuj():string
+wystaw(wystawiajacy:Company, kupujacy:Customer)

Do tego dochodzą ci odpowiednie asocjacje z Company i Customer.
Ogólnie zazwyczaj faza projektowa ma miejsce przed wykonaniem projektu:) I na podstawie zebranych wymagań projektujesz to, co ma zostać zrobione. Sposób rozwiązania tego, w jaki sposób faktura ma być drukowana, to już kwestia implementacji.