witam
Interesuje mnie jakie sa ogólne zasady projektowania systemów internetowych opartych o php,szblony itd.. tzn jak to sie robi , czy uzywa np UML'a czy może indywidyalnych(własnych ) sposobów i własnych diagramów nie stosujac sie do żadnych notacji(a może jakis mix).To samo pytanie dotyczy dokumentacji samego programu jestem ciekaw jak to u was wyglada no i jak to sie powinno robić??


Jesli nie pasuje na pro to sorry ale do innych też jakos nie

Z uwagi na to, żę nie mam teraz czasu pisać więcej - podam tylko fantastyczny link http://www.phppatterns.com/index.php/artic...icle/archive/1/
z szczególnym uwzględnieniem http://www.phppatterns.com/index.php/artic...cleview/15/1/1/


ps. usunąłem pewnego niepotrzebnego posta...

Tak linki są dobra, ale pod warunkiem że piszemy obiektowo

Ja tam póki jeszcze nie ma stabilnej 5, koduje strukturalnie i nie krzystam z UML'a.

A jeśli chodzi o sposoby projektowania: pirewsza rzecz, to gromadzenie informacji o wymaganiach jakie stawiamy przed danym systemem, dalej dobrze jest wypisać sobie wszystkie potrzebne nam informacje związane z poszczególnymi cześciami serwisu, czy nawet z poszczególnymi skryptami, modułami - można to sobie pogrupować w tabelach. Jak już wiemy, co mamy uzyskać i jakie dane będą nam potrzebne, możemy zacząć planować strukturkę bazy danych - tutaj dobrze jest poświęcić dużżo czasu, bo dobrze zaplanowana baza będzie miała spory wpływ na szybkość działania oprogramowania. Baze projektujemy w oparciu o informacje jakie sobie wypisalismy, a których system będzie wymagał, a projektujemy na początek może zgodnie z 3 pierwszymi formami normalnymi.

Jak już mamy gotową strukturę do bazy, można zacząć przygotowywać szablony do poszczególnych sekcji serwisu (na razie chodzi nam i strone wizualną serwisu, a konkretniej o informacje, które będą wyświetlane na poszczególnych podstronach etc.), w razie gdyby okazało się że zapomnieliśmy np. że chcemy wiedzieć o userach z jakiej miejscowości pochodzą - modyfikujemy strukturę bazy.

aaa... wracając do bazy - projektujemy na karkach papieru - można posłużyć się diagramami obiektowo-związkowymi. Projekty muszą być dla nas czytelne na tyle, że patrząc na szkic od razu wiemy jak ma wyglądać np. dana tabela, jakie zapytania po niej najczęściej będą szły itd.

Jak już mamy gotowe szablony (na razie w forumie HTML), możemy przystąpić do kodowania. A tutaj najprościej można po kolei: np. skrypt rejstrujący userów - stopdniowo uzupełniamy go o poszczególne moduły i testujemy czy działają poprawnie. Interesujące jest, że czasem dodanie kolejnego modułu wpływa na inny moduł - w trakcie kodowania dochodzi do "eureka" - tak TEN pomysł jest świetny i trzeba go zaimplementować.

Generalnie: to co i jak będziesz projektował a później implementował, zależy tylko i wyłącznie od Ciebie. Im więcej czasu poświecisz na dopracowywanie projektu tym mniej czasu później stracisz na implementacje. Patrząc na projekt powinnieneś widzieć jeśli nie cały już kod, to chociaż jego część - wystarczy że patrząc na projekt struktury bazy danych (który uległ modyfikacji podczas tworzenia szablonów) wiesz: "aha, będę potrzebował modułu do||od...".

Owszem, przy większych projektach nie ma mowy o takim rozgardniaszu jaki tutaj przedstawiłem (bardzo ogólnie zresztą), ale to głwównie dlatego że prawdopodobnie nie będziesz pracował sam. A co z tego wynika, ini członkowie zespołu mogą mieć problemy z rozszyforwaniem Twoich hieroglifów (projektu). I właśnie dlatego powstały takie standardy jak UML, czy diagramy Z-O dla baz danych etc.

Na koniec: jeżeli pracujesz sam, to ołowek w dłoń, duuży zeszyt na biurko i szkicuj - na tyle abyś później z takich szkiców był w stanie wyciągnąć jak najwięcej informacji potrzebnych do napisania oprogramowania etc. (generalnie to wpierw lepiej przygotować szablony i z nich "czytać" informacje, które będziemy przechowywać w bazie danych).

Projektowanie to proces ewolucyjny i nigdy nie zdaża się że projekt od razu jest idealny i nie trzeba go poprawiać

Skleciłem krótki artykulik o projektowaniu. Co prawda cudem bedzie jeśli ktoś się w nim połapie, ale cóż...

Można go znaleźć pod adresem: http://www.pwsz.nysa.pl/%7Eportalis/index....d=showArt&id=15

Przeczytałem i bardzo wiele mi ten artykuł wyjaśnił. Napisałeś go prostym i przejrzystym (w miarę) językiem. Mam propozycję abyś zgłosił go do odpowiedniego redaktora na php.pl celem zamieszczenia go na wortalu

hmmm... ok, ale wpierw go poprawię (jak znajdę chwilkę czasu), bo można tam jeszcze wiele rzeczy dokładniej objasnić, przedstawić przykłady itd.

P.S Dziwne, że coś z niego zrozumiałeś - sam nie kapuje co tam napisałem

P.S II: ja zawsze staram się używać prostego języka, bo po co pisać artykuł, który de facto pisze się dla ludzi, skoro i tak nic z niego nie zrozumieją? Taki nawyk to mają tylko doktorowie i profesorowie - Boże chroń przed takimi tytułami :wink:

heh, nie miałem za wiele czasu, aby coś tam popawić... a i mieć go nie będę, bo wpadłem na pomysł, że nie chcę się uczyć C++, a JAVA i poszedłem z tym do mojego wykładowcy. Teraz do końca maja muszę na tyle pobawić się w JAVA, aby napisać aplikację klijent-serwer, konkretnie gierkę podobną do tych na portalach jak wp.pl - z tym, że nia jakieś tam warcaby czy grę w statki, ale coś "ciekawego" z wykorzystaniem OpenGL'a. No to teraz siedzę i morduje "Thinking in Java", bo od tego zależy mój byt na uczelni.

A co do umieszczania artu na woratalu: nie wiem czy to dorby pomysł: dziś przedstawiałem projekt (diagram O-Z) z baz danych. Temat: "Stadnina koni" - kumpela wybrała... Dyskutowałem z "szefem" mojego wydziału przez jakieś 45 min., bo ciągle miał do czegoś jakieś obiekcje. W międzyczasie padło: "proszę zmienić ton...". heh. A na koniec facet stwierdził, że to jest sprowadzone do 3 NF... wogóle jazda na maksa, bo chłop miał taki pomysł na projekt bazy, że nadmiarowość pojawiała się praktycznie w każdym możliwym miejscu. Więc sobie podyskytowaliśmy - także nie jestem pewien, czy artykuł kogoś kto "krzyczy" się z prof. dok. i w dodatku szefem całego wydziału jest coś wart

Z drugiej strony, to były zajęcia projektowe, więc mozna zgadywać, że facet na siłę "czepia" się wszystkeigo, bo prawdopodobnie chce przygotować ludzi do obrony prac inzynierskich za roczek A i zepsułem mu całą zabawę, bo bazy normalizwoać mamy dopiero za 3-4 zajęcia

P.S Jakby przez przypadek zajrzał tutaj ktoś z prowadzących wortal, to jakby miał chwilkę to art jes pod wcześniej podanym linkiem - nie wiem, czy będę miał czas, aby go wysłać komu trzeba...

Zgadzam sie z PMadejem. Krotko, zwiezle, przejzyscie, konkretnie i na temat. Idzie zrozumie i sie zastanowic, oraz moze i cos zmienic w swoim dotychczasowym mysleniu o projektowaniu.

Thx za ten text, przydal mi sie bardzo

<pressed pomogl>

Robudowałem arta o kilka szczegółów na temat BD i więcej jak na razie nie planuje, bo i tak tekst majuż 11 stron, a jak tak dalej pójdxie to z tego jakiś kurs projektowania wyjdzie (nie daj Boże). Na razie czekam, aż pojawi się na woratalu specyfikacja co do tego w jakiej formie powinne być te arty.

Specyfikacja jest "In Production".
Na chwile obecną, w skrócie:
XML/DocBooK (full, nie simplified) jesli artykuł składa sie z części użyć struktury Book, jeśli zęśc jest jedna - wystarczy "Article".
Edytor: XML Mind - polecam.

Sorki, ze bez linków, ale padam na pysk...

Wiem, ale dzięki zainfo


hmm... poczekam na pełnego DocBooka, bo zapewne to coś więcej niż 2 tagi


Kurde, tyle mega na modemie No nic, zobaczymy jak się ściągnie


Ok. A link to jakby co tutaj: http://www.xmlmind.com/xmleditor/download.shtml

?
Jako fanatyk DocBooka zapewniam, że nia ma na co czekać. DocBook jest standardem tak pełnym że i tak 90% nie użyjesz. Tu nie ma co robić jakiś tutoriali, o DocBooku są książki (i to za darmo w sieci), a praca z XXE w ogóle nie wymaga znajomości XMLa.

Racja. Ściagnąłem progra i odpaliłem, wygląda przyzwoicie i nawet w JAVA go napisali Ale i tak musze znaleźć chwilkę na przeczytanie dokumentacji do tego.

Tylko ci kiepscy, na szczęście

Eeee... Mieliście jakiś pad zdaje się i tego artykułu już nie ma pod tym adresem, a nawet żadnego artykułu nie ma na tej stronie. Mógłbyś go wrzucić :? Lubię inżynierię oprogramowanie, to bym sobie poczytał 8)

Nie pad, tylko musialem od nowa napisac oprogramowanie (głupie pomysły upierdliwych ludzi...) i w ciagu 2 tyg. gdy studia jeszcze na plecach więcej nie dałem rady. A arta podesłałem komus z php.pl (nie pamietam komu, ale to bym TEN czlowiek) i jakos nie zostal opublikowany, a tyle mordowalem sie z docbookiem na moim C400 z 64 RAMu.

Na jutro postaram sie podeslac arta na serwer mojej PWSZtki i zapodam linkiem.

Oki mialem chwilke: http://www.pwsz.nysa.pl/%7Eportalis/testy/projekt.zip

Format pliczku: ms-word. znalazlem tylko ta wersje "brudnpisowa", ale wydaje sie byc kompletna.

NIe wiem komu go podesłałeś, ale to na pewno nie byłem ja. A ja jestem Tym człowiekiem. Ewentualnie wassago.

Sprawdziłem PW. Adres do ZIP z artem wysłałem wówczas do wassago. Ale mniejsza o to, art i tak jest kicha.