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

[Crozin]

Na przyszłość dodawaj proszę jakieś akapity - strasznie ciężko się czyta taki blok tekstu. (IMG:style_emoticons/default/wink.gif)

Na takim diagramie powinieneś przedstawić jedynie interfejs aplikacji, czyli de facto nie wiele tutaj powinno z Zenda pozostać.

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

Oczywiście, bardzo dobrze że to osobne obiekty odpowiedzialne za druk czy zapis, jednakże to nie obiekt Faktura się do nich odwołuje. To one powinny najpierw otrzymać jakiś obiekt po czym to na nich wywołujesz operację zapisu czy druku. Tak mogłoby wyglądać ostateczne użycie:

[JAVA] pobierz, plaintext 
Invoice invoice = new Invoice();
invoice.set...(...);
invoice.set...(...);
invoice.set...(...);
 
InvoicePrinter printer = ...; // tworzy / pobiera skądś obiekt drukarki faktur
printer.setInvoice(invoice);
printer.print();
// lub jeżeli zajdzie taka potrzeba inny interfejs:
// printer.print(invoice);
 
InvoiceManager manager = ...;
manager.persist(invoice);
 
invoice.set...(...);
 
manager.update(invoice);
[JAVA] pobierz, plaintext 

Jak mogłyby te obiekty wyglądać?

[JAVA] pobierz, plaintext 
public interface Manager<T> {
	public void persist(T object);
	public void update(T object);
	public void remove(T object);
}
 
public class InvoiceManager implements Manager<Invoice> {
	@Override
	public void persist(Invoice object) {
		...
	}
 
	@Override
	public void update(Invoice object) {
		...
	}
 
	@Override
	public void remove(Invoice object) {
		...
	}
}
 
public interface Printer {
	public void print();
}
 
public class InvoicePrinter implements Printer {
	@Override
	public void print() {
		...
	}
}
 
public class Invoice {
	...
}
[JAVA] pobierz, plaintext 

Przeniesienie tego na diagram nie powinno być trudne.

Pozwoliłem sobie na przykład w Javie bo lepiej w niej widać co jest czym i do czego się odnosi