UML i php Opcje

[DeyV]

godzinę? To nie wystarczy nawet na omówienie podstawowych elementów z ktorych buduje się schematy.

Książki które uczą UML'a mają naprwdę niezłą wagę, a i nawet przerobienie takiego konkretnego tomu może nie wystarczyć.

Nie zmiania to jednak faktu, że warto, a same podstawy można załapać w miarę szybko, co juz wtedy może okazać się bardzo przydatne.

[nazihipi]

oczywiście ale nie tłumaczą w takiej książce tylko kiedy i gdzie jaką kreską pociągnąć, jaką komórkę etc...

czytałem podręczniki do uml'a, wiem jak sprawa wygląda..

[Jarod]

oczywiście ale nie tłumaczą w takiej książce tylko kiedy i gdzie jaką kreską pociągnąć, jaką komórkę etc...

czytałem podręczniki do uml'a, wiem jak sprawa wygląda..

Zajrzyj do tego http://helion.pl/ksiazki/juml2.htm

[nazihipi]

Zajrzyj do tego http://helion.pl/ksiazki/juml2.htm

~Cena: 59.00 zł, chwilowo mnie nie stać...

[sf]

DIA jest strasznie niewygodne. Zdecydowanie polecam ArgoUML badz Enterprice Architect.

[macbirdie]

digramy uml mają graficznie obrazować (a nie odwzorować) aplikacje i w najprostrzy i najbardziej czytelny spsób opisywać spsób jej działania, a nie być kopią kodu powkładaną w prostokąty

Na najniższym poziomie diagramy mogą opisywać klasy i zależności między nimi i dawać możliwość wygenerowania z nich gotowych interfejsów. I tworzy się je na podstawie diagramów z wyższych warstw.
Nie wyobrażam sobie, żeby po otrzymaniu bardziej ogólnikowego projektu w UMLu, programiści zaczęli wymyślać swoje interfejsy i próbować współpracować w tym samym projekcie. Dla jednego do kilku blisko współpracujących może to zadziała, ale nie dla większego zespołu.

[dogmat]

hm ciekawie sie to zapowiada ale cos nie chce mi zadzialac poprawnie, moze wystawil by gdzies ktos przykladowy projekt php na bazie diagramu dla paradigm lub innego programu obslugujacego zapis odczyt php

[php programmer]

jak dla mnie lekka przesada narysować sobie schemat - "klik: generate php" dry.gif , bez sensu,
digramy uml mają graficznie obrazować (a nie odwzorować) aplikacje i w najprostrzy i najbardziej czytelny spsób opisywać spsób jej działania, a nie być kopią kodu powkładaną w prostokąty

no i w końcu ktoś napisze właśnie coś takiego i zbije na tym kupe kasy,
bo nit wcześniej na to nie wpadł, bo wszyscy uważali to za bez sensu,
a potem reszta będzie sie zastanawiać: Czemu ja na to nie wpadłem

Ten post edytował php programmer 13.09.2006, 08:41:15

[SongoQ]

@php programmer tu nie chodzi o postawieine glupiej kreski, czy narysowanie prostokata. Jesli dla Ciebie UML do tego sie sprowadza to radze ten temat omijac z daleka.

[php programmer]

mi też o to nie chodzi,
miałem na myśli generowanie kodu php (a właściwie szkieletu)
na podstawie narysowanego diagramu

Ten post edytował php programmer 13.09.2006, 08:49:49

[Jarod]

Mam pytanie z innej beczki. Piszecie mniejsze, większe aplikacje. Czy zawsze używacie UML do projektowania? Tworzycie wszystkie diagramy czy tylko diagram przypadków użycia, klas i ewentualnie czynności? Są ta diagramy ogólne czy szczegółowe?

Może ktoś z Was orientuje się jak to robią firmy zajmujące się pisaniem aplikacji (nie myślę tu tylko o php)?

[060156]

Czesc,

Bylem glownym architektem systemow call center w sredniej firmie amerykanskiej i
przez kilka lat udalo mi sie wprowadzic profesjonalne metody
definiowania (IDEF0) i projektowania (UML) systemow komputerowych ..

Mam kilka obserwacji:
1) zbyt dokladne dokladne projektowanie to strata czasu bowiem
kazdy projekt na etapie implementacji wymaga zmiany i modifikacji a
to z kolei propaguje sie na aktualizacje diagramow UML i szybko
rozjezdza sie design i implementacja ...

2) wazne jest zaprojektowanie koncepcji systemu
*) Use Case - aktorzy, gui ( koncept, styl, nawigacja)
*) Entity Objects i relecje miedzy nimi (ERD)

3) state transition diagrams dla zlozonych stanow systemu

4) tworzenie prototypu i zgodnie z extreme programing
"lightweight software development methodologies"
jego inkrementacja oraz weryfikowanie z uzytkownikiem systemu

pozdrawiam ...

[Jarod]

2) wazne jest zaprojektowanie koncepcji systemu
*) Use Case - aktorzy, gui ( koncept, styl, nawigacja)
*) Entity Objects i relecje miedzy nimi (ERD)
3) state transition diagrams dla zlozonych stanow systemu

Czyli diagram przypadków użycia, diagram klas, stanów.. A to czwarte to co to jest?

[060156]

Czwarte ..
to istota extreme programing,
czyli nie buduje sie calego systemu w izolacji, tylko
dzieli sie go na etapy, ktore sa
weryfikowane z uzytkownikiem i uwzgledniane
sie jego uwagi ...

Ps. obserwacje o ktorych napisalem wczesniej miedzy innymi
przyczynily sie do opracowaniea SOWA (Services Oriented Web Architecture),
ktora jest wpasowana w takie wlasnie podejscie do projektowania
i pisania systemu ..

Ten post edytował 60156 16.11.2006, 19:41:14

[Jarod]

Dzięki za odpowiedź. Mógłbyś coś więcej opisać o projekcie SOWA- oczywiście jak znajdziesz czas. Tak luźno bez diagramów. Ile nad tym pracowałeś, jak to się sprawdza (i po polsku).

Czy wogóle spotkał się ktoś z wykorzystaniem pozostałych diagramó? Bo trochę ich jest i zastanawiam się czy się znich korzysta..

[nasty]

Czesc,
Mam kilka obserwacji:
1) zbyt dokladne dokladne projektowanie to strata czasu bowiem
kazdy projekt na etapie implementacji wymaga zmiany i modifikacji a
to z kolei propaguje sie na aktualizacje diagramow UML i szybko
rozjezdza sie design i implementacja ...

Tak zgadzam sie z Toba w tej kwestji, male duperele tu juz trzeba pozostawic do momentu implementacji

2) wazne jest zaprojektowanie koncepcji systemu
*) Use Case - aktorzy, gui ( koncept, styl, nawigacja)
*) Entity Objects i relecje miedzy nimi (ERD)

3) state transition diagrams dla zlozonych stanow systemu

4) tworzenie prototypu i zgodnie z extreme programing
"lightweight software development methodologies"
jego inkrementacja oraz weryfikowanie z uzytkownikiem systemu

Ale tu juz zapomniales chyba kilka rzeczy po drodze jak np. Risk analisys, czy Stakeholder Analisys... ktore sa nie mniej waznie niz te ktore napisales

Ten post edytował nasty_psycho 10.11.2006, 23:24:29

[060156]

Czesc,
Nie zapomnialem o elementach o ktorych wspomniales ...
Ale trudno jest umiescic wszystko na jednym diagramie.
Dlatego poracowalem rozne Process Template,
ktory opisuja jakie anlaityczne i projektowe kroki
maja byc wykonane w poszczegolnym etapie.
To o czym wspomniales miesci sie w dokumencie
Product Strategy i zawiera nastepujace elmenty:
Executive Summary
Introduction
Strategic Alignment Audit
High Level Business Requirements
Deployment Technology Assumptions
Market Segment Analysis
Product Target Market Segment Analysis
Target Market Sub-Segment – YYYYYY
Target Market Sub-Segment - YYYYYY
Revenue Projection Summary
Revenue Projection Model
Cost Projection Model
pozdrawiam ...

[Jarod]

To wkońcy, które diagramy robić?

[060156]

Dobre Pytanie,

Praca nad systemem skalda sie z dwoch czesci:

Analizy, ktora jest bardziej opisowa
Design, ktory ma na celu zaprojektowanie systemu.

Z mojego doswiadczenia najwazniejsze sa diagramy:

*) IFEF0 - Business Process Flow ( jak wystepuje )
*) Use Case ( actors, etc ...
*) ERD (Entiry Relation Diagram)
*) Jak wystepuja to Control i Interface Objects ..
*) Interacja i state transition do bardziej skomplikowanych interakcji i stanow ..
( nie ma sensu tego robic dla trywialnych przypadkow)
*) GUI (styl, zawartosc, navigacja) - mozna uzyc state transition dla stron i
akcji ( buttons, links, etc ...)

pozdrawiam ..

Dzięki za odpowiedź. Mógłbyś coś więcej opisać o projekcie SOWA- oczywiście jak znajdziesz czas. Tak luźno bez diagramów. Ile nad tym pracowałeś, jak to się sprawdza (i po polsku).

Czy wogóle spotkał się ktoś z wykorzystaniem pozostałych diagramó? Bo trochę ich jest i zastanawiam się czy się znich korzysta..

Sowa to resultat wieloletniej analizy i projektowania object oriented enterprise systemow
na bazie CORBA, RPC, RMI, SOAP ...
Ostateczna koncepcja SOWA wyksztaltowala mi sie sie w 2003 roku, czyli przed Web 2.0 (Ajax, etc) ..
W 2004 zaczalem pisac SOWA Kernele do JavaScript, php, Python i Content Adaptery
do e-mail, pdf, flash, odbc, mysql, informix-a, etc...
Praktyczne systemy zaczalem implementowac od roku 2004 po wszechstronnym wytestowaniu
SOWA Kerneli.

Obecnie sa exploatowane systemy napisane w SOWA:

*) Mars - obsluga pacjentow w szpitalach
*) Av - Accident Victims Managemnet
*) Xpp - multi-process managment ( loan, sales, call-center, customer supprot, network)
(ilosc uzytkownikow okolo 500, ilosc dziennych transakcji okolo 200-300 tys.)
*) Rm - Restaurants Online (wersja angielska i polska)
*) Lds - Lead Distribution System
*) Mlm - Multi-Level Marketing
*) Kis - system do kosztorysowania (wersja polska)

Nie sa to rozwiazania oprate na dostarczaniu statycznego content do
uzytkownika a raczej zorientowane na realizacje businesowych processow ktore wymagaja
zawansowanego GUI ( wiekszosc z nich ma GUI w przegladarce tak jak win32 aplikacje).

Jak dotychczas nie wystepuja w ich eskspolatacji powazne problemy czy tez bledy fatalne
w kernelach ..

SOWA po nauczeniu sie okazuje sie okolo 10-20 razy (czas zwlaszcza)
szybsza i efektywniejsza w pisaniu webowych aplikacji. A niektore zwlaszcza o zawansowanym
GUI nie da sie napisac w uzywajac typowego podejscia...


pozdrawiam

Ten post edytował 60156 14.12.2006, 18:48:22

[DEXTER_c]

Opcja której szukasz to reverse engineering - umbrello faktycznie to obsługuje, ale nie dla php

Nieprawda. Umbrello ma domyślnie ustawione generowanie kodu dla php 5 i robi to znakomicie! W ogóle to najlepszy darmowy program do UML jaki widziałem.