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]

OK, dzięki za pomoc, ale mam taki mętlik w głowie, że poczytałem trochę mądrych książek i zaczynam projekt od początku...

Plan jest taki:

1. Wstęp - będzie napisany na końcu (IMG:style_emoticons/default/wink.gif)
2. Przegląd:
----2.1. Analiza biznesowa - wybrałem metodę BABOK, bo była najbliższa temu co faktycznie robiłem:
--------2.1.1. Analiza przedsiębiorstwa - co robi firma, z czym ma problemy i gdzie jest miejsce dla nowego systemu, tutaj będzie też branżowy słownik danych - dobre miejsce?
--------2.1.2. Pozyskiwanie wymagań - analiza dokumentu, który klient zaprezentował jako spis wymagań funkcjonalnych i niefunkcjonalnych, jego transformacja na formalną postać tekstową oraz aktualizacje tych wymagań na podstawie cyklu spotkań z klientem i dodatkowych materiałów jakie przedstawił,
--------2.1.3. Planowanie i zarządzanie wymaganiami - tu mam zamiar napisać tylko w jakiej formie będą dalej dokumentowane wymagania funkcjonalne (przypadki użycia) i kto odpowiada za ewentualne zmiany oraz w jaki sposób będą numerowane kolejne wersje dokumentów (czysta formalność),
--------2.1.4. Dokumentowanie wymagań - chciałbym tu wstawić przypadki użycia utworzone na podstawie wymagań funkcjonalnych - co o tym myślicie? Dobre miejsce?
--------2.1.5. Komunikowanie wymagań - tutaj chcę napisać tylko, że klient zaakceptował przypadki użycia powstałe na bazie wymagań i jak bardzo był zadowolony, bo tak faktycznie było i warto w pracy o tym wspomnieć,
--------2.1.6. Ocena rozwiązania - tutaj będzie podsumowanie stwierdzające, że analiza wyczerpała temat w stopniu wystarczającym do rozpoczęcia projektowania systemu zgodnie z wymaganiami opracowanymi wspólnie z klientem - to chyba trzyma się kupy i co najważniejsze, trzyma się książki (IMG:style_emoticons/default/wink.gif)
----2.2. Obiektowy model dziedziny - na podstawie analizy biznesowej mogę przedstawić już obiekty, które powinny istnieć w systemie aby zrealizować przypadki użycia (wraz z atrybutami, ale bez metod - zamiast metod podam opis słowny)
----2.3. Narzędzia i technologie - opis narzędzi (w tym PHP, JS, HTML, Zend Framework) i wyjaśnienie dlaczego właśnie te narzędzia, a nie inne
3. Projekt:
----3.1. Określenie celów - chcę tutaj wyznaczyć kilka celów opracowanych na podstawie przedstawionych wcześniej wymagań - dobry pomysł?
----3.2. Przegląd istniejących rozwiązań - solidne uzasadnienie potrzeby stworzenia nowego systemu
----3.3. Opis aktorów i przypadki użycia razem ze scenariuszami (także alternatywnymi),
----3.4. Model danych - diagram relacji encji (no i teraz pytanie - czy powinienem? to przecież metodyka strukturalna, ale jakiś podkład dla schematu bazy danych muszę mieć)
----3.5. Schemat bazy danych - nic dodać nic ująć...
----3.6. Projekt GUI - makiety,
----3.7. Architektura systemu - diagram klas służących do zarządzania obiektami z modelu dziedziny,
----3.8. Opis implementacji - jakieś ciekawostki na temat budowy systemu, zastosowanych algorytmów, itp...
----3.9. Testy jednostkowe, wydajnościowe i funkcjonalne potwierdzające, że projekt spełnia postawione na początku wymagania
4. Podsumowanie:
----4.1. Konfrontacja rezultatu z celami,
----4.2. Sugestie na temat dalszej rozbudowy systemu

Co o tym myślicie?

PS. Tak poza tym to zdecydowałem, że jak tylko skończę studia to idę na kolejne - tym razem z naciskiem na analizę i projektowanie systemów :-)

Ten post edytował Nightstalker 14.08.2011, 02:26:56