Forum PHP.pl

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

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"

Możecie coś zaproponować?

http://www.phppatterns.com/docs/design/php..._class_diagrams

Cieżko coś znaleśćm gdyż to jest tak "praktyka czyni mistrzem"
Ja osobiscie wole zaczac od rozrysowania na kartce dopiero potem moge takie rzeczy robic.

Patrzyłeś co WNT ma w ofercie? Z tego co pamiętam to w serii Inżyniera Oprogramowania książek o UMLu i powiązanych zagadnieniach jest sporo.

Hej.

Taki sam problem miałem ja, ale powoli all poukładało się w głowie i przygotowywany przeze mnie projekt wygląda mniej więcej tak... (mam na myśli projekt systemu IT - niezależnie od technologii implementacyjnej - chociaż ta czasem wymusza pewne elemenetu w projekcie)

Zaczynam od opisu obszaru problemowego - stan istniejący, nadaje nazwę systemowi, określam cel powstania systemu.

Następnie określam podtawowe problemy i obaszary krytyczne które ma realizować system.

Następnie staram się wyłonić użytkowników systemu i ich rolę.

Kolejny etap to wymagania funkcjonalne - wypisuje całą funkcjonalność. Później szczegółowy opis każdej funkcji(Nazwa, Opis, Dane wejściowe, Dane zwracane, Wartości oczekiwane, Kto może korzystać etc).

Następnie rysuję diagramy przypadków użycia, wyłaniam w nich części wspólne i staram się zgeneralizować pewne czynności. Do diagramów przypadku użycia robię spis aktorów systemu i ich rolę oraz spis przypadków użycia i ich funkcję.

Następnie dla każdego przypadku użycia rysuję diagramy: współpracy, sekwencji oraz tworzę scenariusz realizacji(warunki początkowe, scenariusz główny, scenariusz alternatywny, warunki końcowe, punkty rozszerzenia).

Na podstawie powyższych działan staram się stworzyć diagram klas konceptulanych oraz "rzeczywistych" a do tego powstaje diagram obiektów.

Później dochodzą diagramy czynności i stanów.

Określam też specyfikację wymagań niefunkcjonalnych (jaki sprzęt, wymagania dotyczące bazy itd)...

Na koniec powstaje diagram komponentów i diagram wdrożenia.

Do tego w między czasie, po diagramie klas i obiektów rysuje zawsze diagramy ERD i projektuje strukturę danych.

------------------------

Co do literatury:

Jacek Płodzień, Ewa Stemposz - wydawnictow PJWSTK - Analiza i projektowanie systemów informatycznych
Andrzej Jaszkiewicz - Inżynieria oprogramowania

Często gęsto najlepiej podpatrzyć gotowe(dobre) projekty - rozjaśnia umysł - nie mówię tutaj o kradzieży pomysłów, a nauce na bazie doświadczenia bardziej doświadczonych

pozdrawiam

anas

Ten post edytował anas 8.01.2006, 10:25:46

@anas, piękne, ale ma się do rzeczywistości baaardzo średnio.

Tak poważnie, Deyv, trzeba pamiętać o tym, że:
- projekt zawsze się zmienia w trakcie realizacji,
- przy oprogramowaniu często nasz projekt może mieć potrzebę synchronizacji z 10-cioma już istniejącymi rozwiązaniami (np. Xls-y Pani Hani z księgowości ),
- piękne książki trzeba przekładać na rzeczywistość i często okazuje się, że 50% materiału w nich zawartego jest do odłożenia na inną okazję,
- im mniej dokumentów a więcej stabilnego i bezbłędnego kodu tym szybciej Klient zobaczy efekty.

Kilka linków:
http://www.agiledata.org/essays/tdd.html
http://www.featuredrivendevelopment.com/
http://www-306.ibm.com/software/awdtools/rup/

Dodatkowo kilka uwag:
- zamiast rysować diagramy UML w początkowej fazie lepiej jest zrobić "ekrany" czyli poglądowe widoki w aplikacji (np. grid pokazujący listing faktur bla bla .... z dostępnymi opcjami) , jeżeli Klient zaakceptuje ekrany -> przypadki użycia i następne,
- pamiętaj, że w/w ekrany mogą posłużyć jako załączniki do umów itp - mocno Cię zabezpieczają -> dokładnie ukazując wyglad i działanie aplikacji,
- z każdej metodologi wyciągaj coś dla siebie - bądź elastyczny - dobry management to ten który wypracowuje w swoim środowisku własny styl adoptując najlepsze wzorce.

Tyle

pzdr patS

Hej.

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

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.

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 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ę

Twierdzę jedynie, że z wiedzy podawanej w książkach trzeba umiejętnie adoptować wybrane elementy do otaczającej projekt rzeczywistości

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

Zejde troche z tematu, ale

Patrycjusz, anas:
Czytałem jakiś czas temu artykuł na temat tworzenia dokumentacji w jednym z pism poświęconemu programoaniu, bodajże SDJ, ale numeru nie pamiemtam. Artykuł opisywał metody tworzenia dokumentacji. Opisywał zalety tworzenia dokumentacji. Jednak również podkreślał, żeby nie tworzyć na ślepo niepotrzebnej dokumentacji. Trzeba znaleźć złoty środek między tworzeniem dokumentacji, a tworzeniem samego oprogramowania. Niektórych elementów nie warto dokumentować. Ale tak jak już napisałem to tylko OT, o którym przeczytałem w jednym z pism.

Sam ostatnio dochodze do wniosku, że szefostwo cisnie nas, o dokumentacjie, jednak po co robimy tak szczegółową dokumentację? Nie mam pojęcia. Niektóre elementy są tworzone niepotrzebnie, bądź nie są wykorzystywane. Z uml'em też dopiero zaczynam przygodę.

Pozdrawiam.

Hej ponownie.

Zapewne czytałeś SDJ Extra poświecno Projektowaniu SI - przyznam szczerze że wyjątkowo dobre teksty w tym numerze były. Co do Twojej opinii jest jak najbardziej słuszna, bo nie trzeba dokumentować wszystkiego jak leci - głównym czynnkiem jest czas - czas jak wszyscy wiemy to pieniądz - dlatego należy znaleźć ten przysłowowiowy złoty środek pomiędzy dokumentacją a samą implementacją. Jednak tkwi w tym wszystkim duże i ważne ale, mianowicie:

- dobra dokumentacja już na etapie projektowania systemu (bo do tego służy właśnie UML - a nie jak można mniemać: wytwarzamy coś, a później do tego powstają diagramy, projekt i opis) może spowodować że zanim wyjdzie z pod naszego palca jakakolwiek linia kodu znajdziemy wiele błędów i usuniemy je - a co dla mnie jeszcze ważniejsze, przecież z UML'a możemy generować kod - możemy oddając projekt do implementacji wręczyć programistom szkielet klas, interfejsy z jakich mają korzystać i inne ważne elementy - po to powstają narzędzia typu CASE, żeby ominąć pewne etapy wytwarzania. Podobnie ma się to do struktury danych, nie wyobrażam sobie dzisiaj przy dużym złożonym systemie pisać dla każdej tabeli Create... i zastanawiać się gdzie postawiłem nie tak przecinek... - tu się właśnie traci czas i pieniądze, jak (błędnie w mojej opinii) uważa się że dokumentacja nie jest potrzebna - jej nadmiarowość owszem, ale nie ona sama.

Idąc dalej należy pamiętać (przynajmniej w moim przypadku), że w małych firmach bywa tak, że na jedną osobę spada rola zarówno analityka, projektanta oraz osoby implementującej dany system - często gęsto stajemy się również testerami oraz konserwujemy to co stworzyliśmy. W dużych firmach programista dostaje projekt oraz wytyczne którą część ma implementować i mimo faktu że znajdzie (jego zdaniem) błąd ma zakichany obowiązek zaimplementować to w/g wytycznych - zgłaszając ów błąd do weryfikacji dla wyższego szczebla(projektanta) - ten jeśli problem dotyczy założeń, przekazuje go grupie analityków - gdyby w dużych zespołach nie dokumentowano wszystkiego z nadmiarowością dziś zamiast dużych wydajnych systemów mielibyśmy dziwaczne twory, mutanty nie nadające się do rozwoju.

To tyle mojej opinii na ten temat.

pozdrawiam

anas

Anas - dokładnie o kroki które podałeś na wstępie i ich rozwiniecie - pytałem w tym temacie.
Jednak Twoja odpowiedź nie wyczerpuje jeszcze moich rozważań na ten temat, stąd wrócę do tego tematu za parę dni, jak tylko troszkę się uspokoji zamieszanie związane z uruchomieniem php.pl vol. 2
A narazie cieszy mnie tak żywiołowa dyskusja

Polecam dobry wyklad z inz. oprogramowania, tez zawarty uml.
Aragorn

Ostatnio pojawiła się książka http://helion.pl/ksiazki/juml2.htm