Projektowanie /Dokumentacja aplikacji desktopowej w c++

Cześć , dostałem zadanie zaprojektowania aplikacji dekstopowej/konsolowej whatever -nie było wyszczególnione w treści zadania :D. No i siedzę teraz z długopisem, i kartką ,ale nie wiem z której strony zacząć "smarować" .

Problem leży w tym,że słowo dokumentacja i projektowanie jest dla mnie na tyle ogólne, że nic mi to nie mówi xD ....Więc idąc w myśl pierwszej zasady dynamiki Newtona może wy coś podpowiecie/ruszycie - i hope -
Co dla was jest projektem ? W tym przypadku wyobrażam sobie to tak :

Mam w głowie zarys programu np.program od bankowości ,no i rysuje okienko , zaraz dodaje jakiś button , input , nie wiem logo, później dodaje możliwość wyboru czy zalogować czy zamknąć ..po zalogowaniu pokazuje aktualne saldo , książkę adresowa ,blablabla , i tak co chwilę mogę dodawać jakąś funkcjonalność , ale co mi da rysowanie tego ? ew. dodanie jakichś opisów .. mam wrażenie że to nie o to do końca chodzi .

Dokumentacja ? - no okej , wyobrażam sobie zapiski gdzie jest jakis kod źródłowy z którego potencjalnie mogę skorzystać , w którym miejscu może zaistnieć zagrożenie błędem , czego oczekuje dany formularz ,ale przecież równie dobrze mogę to napisać w komentarzach w kodzie .

to co chcesz zrobic to waterfall. Nie rob tego

Jak masz opis tego projektu, podziel sobie go na mniejsze czesci.
Np masz napisac Kalkulator.

• Mozliwosc dodawania
• Mozliwosc odejmowania
• Mozliwosc mnozenia
• Mozliwosc zapamietywania liczby i pozniejsze je wczytanie

itd.

Robisz tak by Twoje zdanie bedzie najmniejsza jednostka jaka mozesz skonczyc i ma jakis impakt na Twoj projekt

Dokumentacja niech bedzie Twoj kod. Jezeli chcesz to mozesz jeszcze globalny zarys architektury jak co dziala (watpie by byl wymagany)

fasadin napisał(a):

to co chcesz zrobic to waterfall. Nie rob tego

Jak masz opis tego projektu, podziel sobie go na mniejsze czesci.

Nie nie mam , wszystko od zera .

to najpierw zdefiniuj od gory co to ma byc za projekt i jakie "biznesowe" wartosci ma w sobie

Jak to zrobisz, nie jest to wazne (w sensie w jakim jezyku i czy dodasz dwie klasy czy jedna) to szczegol implementacyjny ktory na tym etapie nie powinien Cie obchodzic

pain368 napisał(a):

fasadin napisał(a):

to co chcesz zrobic to waterfall. Nie rob tego

Jak masz opis tego projektu, podziel sobie go na mniejsze czesci.

Nie nie mam , wszystko od zera .

No okej , nie żebym się uparł ,ale jakiś krótki treściwy rysunek w postaci drzewa w którym mógł bym zaznaczyć jakieś zachodzące relacje miedzy funkcjami, np . chce zrobić wpłatę do kolegi i mam jego adres w książce telefonicznej ,relacją w tym przypadku była bo ściągniecie adresu,numeru konta itd ,no i wypełnienie nim formularzy, może coś takiego być ?

ale co Ci da taka informacja?

Kazdy programista jezeli bedzie chcial zobaczyc jak cos dziala to spojrzy w kod.

Jezeli nie moze spojrzec w kod wtedy bedzie czytal dokumentacje. Jezeli nie robisz jakies bibloteki / frameworka / nie wystawiasz RESTa nie potrzebujesz opisywac funkcji co robia

fasadin napisał(a):

ale co Ci da taka informacja?

No nie wiem , powiedzmy że dokumentacja tez ma służyć i mi ,żebym czegoś nie zapomniał :p ,to mój pierwszy projekt podkreślam ! :D proszę o wyrozumiałość.

Zrobiłem krótki ogólny opis, jakie zadania ma realizować , do kogo jest skierowana , w których miejscach może wystąpić potencjalny błąd czyli takie ogólne tezy.. coś bardzie w tym kierunku ?

poczytaj sobie o:

• uml
• diagramach wymagań systemowych
• diagramach przypadków użycia
• doxygen

Dziękuje :). Jak tylko skończę to zaraz zbadam,póki co googlowalem i coś znalazłem. Zacząłem od rysunku, a potem takie ogólne rzeczy, opisy, autor-dla zachowania formy- do kogo program ma być skierowany ,na jaka platformę ,jaką funkcjonalność będzie zawierał i jakie mechanizmy chce w tym zaimplementować , aktualnie rysuje graf klas, wygląda to trochę jak kwerenda w Microsoft Access , tylko że przedstawiam na tym potencjalne relacje zachodzące miedzy innymi klasami , dobry kierunek obrałem ?

dobry kierunek obrałem?

Nie można odpowiedzieć na to pytanie w sytuacji, w której nie masz żadnego twardego produktu. Jeśli Twoja metodologia doprowadzi to działającego, niepsującego się programu nikt nie będzie Ci wytykał w jaki sposób do niego doszedłeś.

Z mojego doświadczenia, większość rzeczy którymi chcesz się teraz zajmować to marnowanie czasu, który można by przeznaczyć na ewaluację technologii czy rozwiązań, tymbardziej że, jak twierdzisz, to Twój pierwszy projekt. Takie rzeczy jak użyte technologie, dostępność na platformy, funkcjonalność to po prostu się pamięta nawet po latach, a jeśli robisz to bo myślisz, że ktoś tego będzie używał to nie oszukuj się - nie będzie.

W większych projektach takie rzeczy jak relacje między klasamia/modułami, argumenty metod czy nawet API są kwestiami dynamicznymi dlatego do udokumentowania tychże wykorzystuje się automaty puszczane na gotowym produkcie. Nie masz doświadczenia, nie wiesz jeszcze, że Twój model rozrysowany przed napisaniem pierwszej linijki wyjdzie Ci bardzo sterylny i założę się, że nie przewidujesz w nim efektów ubocznych takich jak thread-safety, I/O, blokowanie GUI, migotanie konsoli, error handling etc. "Papier przyjmie wszystko" i diagram, który łądnie wygląda w Access może być mega niepraktyczny w implementacji.

No ale jak napisałem, to Twój wybór czym chcesz zajmować, jeśli zamiast oswajania się z debugerem wolisz rysować diagramy to nikt Ci w tym nie przeszkodzi.