Projekt aplikacji

Cześć!
Mam problem z zaprojektowaniem sobie np. na kartce całej aplikacji, wiem tylko że pierwsze o muszę zrobić to napisać samemu GUI a potem przy użyciu tego GUI zrobić aplikacje. Jakie macie sposoby na zaprojektowanie takich rzeczy?, ja próbowałem coś na kartce sobie rozrysować, ale zazwyczaj kończy się na narysowaniu komponentów do GUI i napisaniu czego robią i narysowaniu mniej wiecęj wyglądu aplikacji.

Moze UML: przypadki uzycia i diagram czynnosci? Zaprojektowanie GUI jest moim zdaniem najmniejszym problemem. W UML masz wiecej diagramow, ale czy ich uzyjesz, to zalezy tylko od tego, jak szczegolowa ma byc dokumentacja. W wiekszych projektach dochodzi na bank model bazy danych i diagram klas / obiektow.

piotrek89 napisał(a)

[...] wiem tylko że pierwsze o muszę zrobić to napisać samemu GUI a potem przy użyciu tego GUI zrobić aplikacje.

Hmm, a nie na odwrót?? Najpierw "silnik", a później oprawa graficzna?

0x666 napisał(a)

Hmm, a nie na odwrót?? Najpierw "silnik", a później oprawa graficzna?

Dokładnie. Interface usera to ostatnia rzecz jaką powinieneś się zająć. Uwież mi, że źle się pisze silnik pod gotowy interface. Najpierw określ co i jak program ma robić. jak to wyświetlisz to zostaw na koniec.

nie zgodze sie. pisanie silnika na podstawie GUI daje mase bledow logicznych, dajacych sie poprawic zazwyczaj, ale jest wzglednie szybki sposob na proste programy. pisanie GUI na podstawie silnika daje program i UI zrozumiale i oczywiste dla tworcy programu, ale zazwyczaj totalnie nieintuicyjne dla przecietnego usera. ogolnie to powinno sie zrobic silnik i GUI, oba w dowolnej kolejnosci, calkowicie od siebie niezaleznie i w takiej formie jak sobie wymarzysz, a potem dopiero to powiazac.

edit:
a mowie tak, poniewaz 95% procent uzytkownikow bedzie oceniac Twoj program po wizualiach i intuicyjnosci obslugi. pozostale 5% to informatycy albo specjalisci. Ci pierwsi patrza na bezblednosc programu, Ci drudzy na wyniki..

quetzalcoatl napisał(a)

pisanie GUI na podstawie silnika daje program i UI zrozumiale i oczywiste dla tworcy programu, ale zazwyczaj totalnie nieintuicyjne dla przecietnego usera.

Przecież ten sposób nie wyklucza możliwości stworzenia intuicyjnego UI.

ogolnie to powinno sie zrobic silnik i GUI

...a poważniejsze zmiany w silniku implikują poważne zmiany w GUI... nieefektywne podejście ;) Najpierw silnik, który z grubsza będzie spełniał założenia programu i da się uruchomić, a później można dorabiać poszczególne elementy UI - tak to widzę.

oba w dowolnej kolejnosci

:|

calkowicie od siebie niezaleznie

Jak najbardziej tak. Choć nie zawsze się da.

ogolne zalozenia ktorymi kierowalem sie piszac poprzedni post to:

• dobrze przemyslany silnik jest calkowicie niezalezny od GUI
• struktura i uklad GUI zalezy nie od silnika, ale od celu jakiemu aplikacja ma sluzyc
• cel ten osiaga sie nie silnikiem, ale poprzez wykorzystanie funkcjonalnosci oferowanych przez silnik

na przyklad:

chcemy zrobic baze danych obrazkow. obrazek to {unikatowa nazwa, opis, slowa kluczowe, blob z grafika}

silnik:

• pozwala dodawac nowe obrazki, dolaczajac przy tym podane metadane (nazwa, opis, slowa kluczowe)
• pozwala usuwac obrazki po nazwie obrazka
• pozwala pobrac metadane obrazka po nazwie obrazka
• pozwala pobrac bloba obrazka po nazwie obrazka
• pozwala wyszukac nazwy obrazkow zawierajacych podane slowa kluczowe
• pozwala wyszukac nazwy obrazkow ew. ktorych opis zawiera podana fraze
• pozwala pobrac nazwy wszystkich obrazkow

gui:

• oferuje mozliwosc przejrzenia jakie obrazki sa w bazie danych, w zaleznosci od trybu pracy, obrazki sa prezentowane najpierw poprzez ich opisy i dopiero po wybraniu konkretnego pokazywany jest wlasciwy obrazek, albo tez od razu pokazywane sa znalezione obrazki
• oferuje mozliwosc wprowadzenia slow kluczowych albo frazy i wyszukanie obrazkow wg tych kryterii, znalezione w zaleznosci od trybu pracy, obrazki sa prezentowane najpierw poprzez ich opisy i dopiero po wybraniu konkretnego pokazywany jest wlasciwy obrazek, albo tez od razu pokazywane sa znalezione obrazki
• podczas wyswietlania obrazkow (zarowno wszystkich jak i wyszukanych) mozliwe jest usuniecie zaznaczonych pozycji
• oferuje mozliwosc dodania do bazy nowego obrazka, bezwzglednie nalezy podac wskazac plik obrazka oraz nazwe obrazka. domyslnie za nazwe obrazka jest przyjmowana nazwa pliku (bez sciezki). mozna takze podac liste slow kluczowych zwiazanych z obrazkiem albo szczegolowy opis jego zawartosci

silnik jak latwo zauwazyc zachowuje sie jak bardzo prosta baza danych. on robi to, co aplikacja musi robic koniecznie, by spelniac podstawowe wymagania funkcjonalne.

jak rowniez widac, funkcjonalnosci GUI wymagaja bardziej skomplikowanych rzeczy od silnika - np. pobieranie zestawu opisow obrazkow wg slow kluczowych. kluczowa rzecza jest, ze mimo rozbieznosci, da sie wykonac przy pomocy silnika rzeczy ktorych GUI potrzebuje - nie bedzie to proste wywolanie jednej metody silnika, ale trzeba bedzie pobawic sie kilkoma. teoretycznie, jak najbardziej daloby sie w handlerach klikniec, wklepan tekstow, drag&dropow etc wykonac wszystkie owe potrzebne czynnosci. jednak jest to 'bad design'.

mamy wiec GUI ktore cos porzebuje zrobic, i silnik ktory dostarcza najbardziej podstawowych rzeczy.. dodajemy warstwe "logiki". ot, dorzucamy pare klas "proxy" ktore beda tlumaczyc punkt widzenia GUI na metody silnika.. dzieki temu GUI bedzie moglo wywolac sobei jedna metode xyz->pobierzMetaInfoObrazkowDlaKeyword("mama") albo xyz->pobierzBitmapyDlaKeyword("reks'), zas silnik zostanie nie tkniety i bedzie caly czas prosty

//pseudokod
bitmap[] xyz::pobierzBitmapyDlaKeyword(string keyw)
{
  string trafienia[] = silnik -> wyszukajNazwyObrazkowDlaKeyword(keyw);
  bitmap obrazy[] = pusto;
  foreach(string kolejny in trafienia)
     dopisz(obrazy, silnik->pobierzBlobaObrazkaONazwie(kolejny);
  return obrazy;
}

dowcip polega na tym, ze zeby miec ladne GUI trzeba dac projektantom GUI wolna reke.. to sa artysci, nie musza trzymac sie logicznych zasad. drugi dowcip siedzi w tym, ze dobry silnik musi dzialac tylko i wylacznie wg logicznych regul i musi miec tez zachowana wlasciwa strukture, inaczej szybko zrobi sie w nim makaron i bedzie "kupa". nie idzie tego powiazac na prosto, tworzac silnik na podstawie GUI, poniewaz GUI jest elementem programu ktory najszybciej i najczesciej ulega zmianom - zmienia sie wraz z coraz to nowszymi pomyslami uzytkownikow/projektantow. wiazaloby sie to z ciaglymi zmianami w silniku, a ze zmiany te by byly "czeste i geste", to silnik w oka mgnieniu stracilby swoja najwazniejsze cechy - logiczna strukture.. silnika sie nie rusza w ogóle, chyba ze wymagania GUI naprawde sa nierealizowalne np. w podanym przykladzie z wyszukiwanie obrazkow po slwoach kluczowych odbywa sie dwustopniowo - najpierw pobeira sie zbior nazw, potem operuje na pojedynczych obrazkach, moze to byc ok, ale GUI moze sobie wymyslic np. masowe usuwanie po slowie kluczowym i jakkolwiek realizowalne - moze to trwac baardzo dlugo - wtedy jest uzasadniona potrzeba modyfikacji silnika i np. dostawia sie overload funkcji usun pobierajacy liste slow kluczowych.. ale zazwyczaj konczy sie to na zmianach drobnych, nie wymagajacych totalnego przebudowania polowy silnika

powiedziawszy to, zeby byc w calosci zgodnie z prawda i realiami --- taka architektura jest fajna, pozwala wymienic GUI nie ruszajac silnika (ale wymaga to zmian w proxy), pozwaja wymienic silnik nie ruszajac GUI (ale wymaga to zmian w proxy), ale jest tu duzo rozdmuchania oraz slepego przekazywania wywolan w przypadku prostego odwzorowania funkcji w gui na funkcje silnika.. totalnie to sie nie oplaca, a wrecz moze szkodzic na przyklad:

• aplikacja jest na prawde malo skomplikowana
• aplikacja wymaga blyskawicznego przetwarzania/mikroskopijnej wielkosci binarek/zajetosci pamieci
• mamy bardzo malo czasu na implementacje..
• mamy malo czasu, wystarczy na implementacje, ale nie na gruntowna analize o co tak w ogóle chodzi

oplaca to sie gdy na przyklad:

• silnik wyglada na czasochlonny, ale chcemy szybko zrobic GUI zeby klientowi zaimponowac graficzka (->artysci leca galopem, engineerzy sobie mysla przy kawie i rozgryzaja silnik)
• wiadomo co aplikacja ma robic, ale klient nie ma zielonego pojecia jakby miala wygladac.. ale ma wygladac tak jak jemu sie to wyobraza a nie Wam (czesty przypadek wbrew pozorom) (->artysci uzeraja sie z klientem czesto wyrzucajac GUI i zaczynajac od nowa, engineerzy sobie spokojnie zdazyli napisac funkcjonalny silnik i lataja juz jakies narafione bugi)
• GUI ma szanse zmieniac w niedalekiej przyszlosci uklad, wyglad etc ALE podstawowe zadania programu nie zmieniaja sie, co najwyzej dojda nowe
• chcemy specjalnie uzyskac 'modularnosc'/'modulowosc' aplikacji, na przyklad by moc teraz szybko napisac silnik przy uzyciu banalnych, wolnych, naiwnych agorytmów, by potem go podmienic na zoptymalizowany i w ogóle wypasiony, ale nieruszajac GUI

W sumie zgodzę się z Tobą, chociaż odnoszę wrażenie, że ten silnik z przykładu to jest po prostu jednym z modułów programu, ot "bardzo prosta baza danych". Ten silnik, według mnie, jest zbyt ogólny. To trochę tak jakby powiedzieć, że GDI (lub coś lepszego) jest silnikiem jakiegoś edytora grafiki wektorowej ;) No, ale to może być kwestia zbyt prostego przykładu.

tak i tak :) raz ze to jest prosty przyklad, dwa, ze w tym przykladzie na warstwe GUI i silnika+proxy skladaja sie pojedyncze moduly :) chcialem powiedziec ze przy dobrym ukladzie poszczegolnych fragmentow programu - czy to beda moduly, warstwy czy biblioteki - bardzo czesto da sie GUI calkowicie odseparowac, a potocznie rozumiany silnik rozszczepic na ten prawdziwy logiczny i sliczny silnik oraz "kociol" w proxy, co pozwoli wiekszosc przyszlych modyfikacji zamknac w "kotle".. proxy nie musi byc jedna wielka gmatwanina - mozna je tez analogicznie rozszepic na warstwy i moduly.. otrzyma sie wtedy co raz lepsze odseparowanie rzeczy pewnych od mniej pewnych i od jeszcze mniej pewnych etc - no ale trzeba sie troche wiecej namyslec i napisac