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 :-)

[Nightstalker]

Crozin, napisaliśmy post w tym samym momencie, więc robie edycje :-) Najpierw odpowiedź i pytanie do bastard13:

Czyli jestem na dobrym tropie :-) Jeśli dobrze zrozumiałem to robiąc diagram klas mam skupić się na faktycznych czynnościach jakie wykonują kluczowe obiekty, a to w jaki sposób coś robią i za pośrednictwem czego mogę ukryć lub pominąć, tak?
System był projektowany w miarę poprawnie - najpierw była analiza i określenie wymagań, później ogólne przypadki użycia i diagramy stanów ilustrujące bardziej złożone procesy.
Na ich podstawie powstał projekt bazy danych, który dla zwiększenia wydajności został później poddany denormalizacji (czyli w rezultacie mam dwa: ERD i schemat fizyczny docelowej bazy).
Do tego doszły makiety GUI i z tego miejsca zabrałem się za implementacje.
Kiedy jednak przyszło do składania dokumentacji zorientowałem się, że realizuje projekt wg lekko "wybrakowanej" metodyki obiektowej, bo brak w nim diagramów klas (o diagramch sekwencji już nie wspominając)...
Zapomniałem wspomnieć, że jest to praca na zaliczenie kursu projektowania systemów, na który raczej rzadko uczęszczałem (i teraz to się mści...) :-) Mogę liczyć jeszcze na jakieś porady?

A teraz Crozin:

Sorry za te tekst - późno w nocy było jak pisałem, a enter daleko...

Bardzo dużo mi rozjaśniłeś. Wygląda na to, że jednak powinienem uwzględnić pewne klasy, którymi posługuje się np. przy zapisie lub odczycie z bazy danych.
Dobrym przykładem będzie zarządzanie kolekcją faktur, bo mam tam kilka klas managerów, maperów, "składaczy" i oczywiście obiekt "faktura" :-) Wieczorem poskładam diagram i zaprezentuje Wam tutaj - mam nadzieję, że mogę liczyć na Waszą ocenę ;-)



Oj chyba jednak nie tędy droga - wydaje mi się że za bardzo wchodzę w kwestię architektury systemu i szczegóły implementacji... No ale zobaczymy... Poniżej uproszczony diagram klas. W skrócie działa to tak:
1. aplikacja tworzy i używa managera finansów
2. manager finansów tworzy i używa managera listy faktur oraz managera pojedynczej faktury
3. managery listy i pojedynczej faktury dziedziczą po uniwersalnych managerach i tylko ustawiają im odpowiednie dao
4. managery korzystają z dao do utrwalania i odczytywania danych
5. dao listy i dao obiektu dziedziczą po uniwersalnych dao i tylko ustawiają im parametry wskazujące na mapper i model
6. na samym końcu mamy model, który jest wynikiem działania mappera, który z kolei jest używany przez dao

(IMG:http://img836.imageshack.us/img836/2245/classdx.jpg)

(http://imageshack.us/f/836/classdx.jpg/ - daje link bezpośredni, bo nie wiem czy hotlink zaskoczy)

To jest na prawdę fajna architektura i sprawdza się "w boju", ale nie wiem czy dobrze przedstawiam ją na projekcie.

PS. To co napisał bastard13 wydaje mi się jednak być w sprzeczności ze słowami Crozin (albo odwrotnie), bo jeśli mam ukrywać szczegóły implementacji to powinienem pozbyć się z diagramu tych wszystkich managerów. Co o tym myślicie?

Ten post edytował Nightstalker 10.08.2011, 15:21:23