Projektowanie serwisu cz.1 - ogólny zarys
Pierwszy wpis z tej serii będzie nieco ogólny i teoretyczny. Co należy sobie przygotować zanim w ogóle zacznie się pracę z pisaniem kodu? Przede wszystkim należy mieć pomysł. Trzeba wcześniej już sobie wyobrazić jak serwis ma funkcjonować, jakie ma spełniać zadania itp. - oczywiście dość ogólnie.
Następnie najlepiej jest rozpisać na kartce poszczególne moduły/funkcjonalności. Według mnie najważniejszy jest system uprawnień, dlatego planowanie powinno się zacząć od niego. To jak będzie wyglądał zależy od rodzaju serwisu jaki planujemy, ale też od jego wielkości i tego, kto nim będzie zarządzał. Zazwyczaj wystarczają 3 lub 4 poziomy uprawnień - admin, moderator, użytkownik i gość. Jeśli chcemy możemy pokusić się o dynamiczne uprawnienia, czyli oddzielne przyznawane dla każdego zarejestrowanego. Jeżeli mamy na przykład serwis podzielony na kilka działów możemy poszczególnym moderatorom/redaktorom przyznać uprawnienia dodawania/edycji tylko w dziale, którym się zajmują. Takie rozwiązanie ma swoje wady i zalety. Główną zaletą jest to, że przestrzegamy tzw. zasady minimalnych uprawnień. Wadą, dość poważną jeśli admin nie ma doświadczenia w prowadzeniu serwisu, może okazać się skomplikowany interface nadawania uprawnień. Wszystko zależy jednak od sposobu w jaki go zaimplementujemy. Poza tym dość uciążliwe może okazać się nadawanie oddzielnych uprawnień kilkunastu moderatorom. Dobrym rozwiązaniem jest równoległe zastosowanie kilku predefiniowanych modeli uprawnień. W innym wypadku administracja serwisem mogłaby okazać się na prawdę uciążliwa.
Dobrą sprawą jest podzielenie całego serwisu na oddzielne moduły. Dzięki rozdzieleniu niektórych elementów strony będzie można w większym stopniu później nimi manipulować i nadawać specyficzne uprawnienia. Jako moduł w tym wypadku rozumiem na przykład: menu, artykuły, newsy, czat/shoutbox, każdy element panelu administratora. Takie rozwiązanie w połączeniu z odpowiednio rozplanowanym systemem uprawnień pozwoli na zaawansowaną obsługę dostępu do modułów. Jeśli zastosujemy zaawansowany system uprawnień z poprzedniego akapitu będziemy w stanie w bardzo prosty sposób zablokować użytkownikowi dostęp(pełny lub częściowy)do dowolnego modułu. Wystarczy, że każdy moduł będzie sprawdzał uprawnienia użytkownika odnośnie tej części witryny. Dużym ułatwieniem w takim rozwiązaniu jest programowanie obiektowe, ponieważ można stworzyć klasę rodzica - wzór modułu. Każdy nowy moduł dziedziczący z niej nie będzie już musiał martwić się np. o sprawdzanie uprawnień itp. Dodatkowym plusem jest fakt, że zmiana sposobu zapisywania uprawnień nie zmusza nas do edycji kilkudziesięciu(albo i nawet kilkuset)linijek kodu w kilku(nastu)różnych plikach.
Wracając do rozpisywania funkcjonalności. Ja zawsze każdą część strony zapisuję w mniej więcej takiej postaci:
- NAZWA MODUŁU
- co - czyli krótki opis tego, do czego ma nam się przydać
- jak - można sobie ew. pod spodem narysować jakiś niewielki rysunek
- kto - dokładne opisanie uprawnień dla poszczególnych grup
W ten sposób uzyskamy klarowny zapis funkcjonalności serwisu. Będziemy w stanie w przystępny sposób przekazać naszą wizję komuś innemu. Po określeniu tego podstawowego planu dobrze jest schować go do szuflady na 4-5 dni. Po tym okresie jeszcze raz go przejrzeć i przemyśleć. W ten sposób będziemy pewni, iż umieściliśmy takie elementy, które pozwolą nam osiągnąć maksimum funkcjonalności.
Ostatnim etapem jest dokładne zaplanowanie każdego modułu serwisu. W szkicu powinno uwzględnić się każdy możliwy do przewidzenia scenariusz zachowania użytkownika skryptu i wypracować odpowiednią odpowiedź. Należy starać się przewidzieć nietypowe zachowania odbiorcy. W końcu nie każdy musi myśleć tak jak my. Dobrze jest pokazać taki plan innej osobie znającej zagadnienie, aby w razie braków dodać nową akcję i reakcję. Podobnie jak opis całego projektu dobrze jest zostawić szkice modułów na kilka dni, żeby się "przegryzły". Po pewnym czasie zaczynamy patrzeć na pewne sprawy z innej strony, dzięki czemu zredukujemy prawdopodobieństwo pomyłki do minimum.
Jak już wspomniałem wpis ten jest nieco teoretyczny, jednak faza projektowania funkcjonalności jest bardzo ważna. Pozwala uniknąć nagłych zmian koncepcji podczas, gdy część kodu jest już gotowa. Jednym słowem - oszczędzamy czas i energię. Mam nadzieję, że całość nie jest napisana zbyt chaotycznie i niezrozumiale. Proszę także o wyrozumiałość, ponieważ jest to mój pierwszy wpis tego typu.
8 komentarzy
ja zamiast kartki stosuje freemind - dobrze sprawdza się na tym etapie projektowania. Wydaje mi się, że sensowniej jest na początku rozpisać co chcesz osiągnąć, a dopiero później zastanawiać się czy to jest do zrobienia - po co ograniczać wyobraźnię już na początku ?
Ja nie napisałem, żeby ktoś się zastanawiał, czy coś co wymyślił jest do zrobienia :) Wręcz przeciwnie - jeśli coś wydaje się niemożliwe powinno się spróbować to zrobić. Dlatego właśnie powstaje ta seria - aby ludzie, którzy chcą mieć własną stronę, a brak im doświadczenia mieli jakieś podstawy, od których mogą zacząć.
ups - przez przypadek wpisałem złe id wpisu i komentarz poleciał nie tam gdzie trzeba >.<
Moim zdaniem podchodzisz trochę od pupy strony, albo zaczynasz nie od początku.
W Twoim opisie zupełnie pominięte są etapy takie jak określenie grup odbiorców, celów witryny etc - od których zaczynać powinno się szeroko pojęte projektowanie witryny.
Następnym krokiem powinno być stworzenie modułów - ale nie w ten sposób, który opisałeś. Musisz najpierw określić "co" ma robić moduł dla odwiedzającego - jakie opcje, funkcjonalności, reprezentacje a dopiero później przechodzisz do projektowania technicznych rozwiązań po stronie administracyjnej.
IMO, i przynajmniej u nas tak to wygląda ;-)
@BTM
1. "Trzeba wcześniej już sobie wyobrazić jak serwis ma funkcjonować, jakie ma spełniać zadania itp." według mnie to jest mniej więcej to o czym mówisz.
2. Nie wiem jaką różnicę widzisz w tym, co ja wypunktowałem w artykule, a tym co sam napisałeś. W moim opisie nie ma nawet mowy o żadnym technicznym podejściu do prawy. Chodziło mi tylko o dokładne określenie co użytkownik może zrobić z danym modułem i jak moduł powinien się w takiej sytuacji zachować. Czysty schemat: pytanie - odpowiedź.
Ja jestem właśnie w trakcie zaliczenia przedmiotu "Projektowanie systemów informatycznych" i według tego co się uczę, to projektowanie systemu składa się przynajmniej z kilku faz. Przeważnie zaczyna sie zawsze od opisu funkcjonalności systemu, jest to kilka zdań dot. tego co system ma robić, kto będzie go używał, etc. Następnie tworzy się różne diagramy: diagram hierarchii funkcji, diagramy przepływu danych, diagramy związków encji, itp, itd :P I dopiero po przejściu tych etapów, które mogą trwać miesiącami zaczyna się kodować ;)
Tyż mam z tego zaliczenie, jutro idę oddać projekt z UML'a ;-)
@snipe: wszystko racja, ale wyobrażasz sobie, że żądny rezultatów swojej pracy młody programista poświęci na to kilka(naście) tygodni? Według mnie kilka dni to dla niektórych i tak za dużo :P