Projektowanie oprogramowania przez pseudokodowanie?

Czy znasz dobry sposób na zaprojektowanie (tj. Spisanie) oprogramowania za pomocą metody opartej na pseudokodzie?

Jestem nowy w projektowaniu oprogramowania i czytam informacje o UML. Moje skromne hierarchie klas są jak dotąd dobre, jednak po złożeniu się zauważam, że przy „oglądaniu całego” obrazu mogłem zastosować inną strukturę dla większej przyszłej rozszerzalności. Ponieważ Python jest dobry w tworzeniu prototypów, prawie dobrze mi się zaczyna pisać, ale nie całkiem.

Wypróbowałem więc diagramy klas UML, ale wydaje mi się, że niewiele mi to pomagają. Problemy, które tam rozwiązuję, mogę trywialnie rozwiązać w mojej głowie. Ale zauważam dodatkowe wymagania projektowe, kiedy zaczynam pseudokodować rzeczywiste metody.

Więc jeśli chcesz zaprojektować za pomocą pseudokodu, jak byś to zrobił? Uważam, że metoda, która jest w przybliżeniu 1 do 1 z kodem, działa najlepiej. Ale większość oprogramowania UML nawet nie pokazuje kodu metody (w przeciwieństwie do zdjęć np. W GoF).

Ktoś twierdził, że UML służy wyłącznie do dokumentacji i prezentacji, a nie jest świetny do projektowania? Mam też to uczucie. Myślałem, że czysty UML i kilka uproszczonych szkiców tablicy były sposobem na zaprojektowanie oprogramowania, dopóki google nie znalazłem Envision APDT.

Czy więc zwinne programowanie jest czymś, na co powinienem zwrócić uwagę, czy też przypadkowo nazywają to zwinnym - myślałem, że zwinny dotyczy wyłącznie harmonogramu? Czy też projektuję niepoprawnie (za pomocą UML) - czy ktoś projektuje za pomocą pseudokodu? Jak mogę znaleźć do tego dobre narzędzie?

 I thought agile is about schedule only?

To nie tylko planowanie. Zwinne opracowywanie oprogramowania polega raczej na rozwoju ewolucyjnym i dostarczaniu iteratywnych ram czasowych z adaptacyjnym planowaniem, które zachęca do elastycznej reakcji na zmiany wymagane przez właściciela produktu.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Z mojego doświadczenia wynika, że ​​wykresy są znacznie łatwiejsze do zrozumienia z perspektywy klienta. Są atrakcyjne wizualnie i wielokrotnie bardzo kolorowe i łatwe do naśladowania. Jednak bardzo trudno jest obsługiwać wykresy ze względu na charakter rozłączenia z rzeczywistym kodem aplikacji. Za każdym razem, gdy wprowadzana jest zmiana w aplikacji, programista musi poświęcić czas na aktualizację całej dokumentacji, w tym wykresów. Problem ten można jednak łatwo wyeliminować, gdy w zespole lub firmie pojawi się licencjat, który dobrze rozumie proces biznesowy klienta i może zarządzać diagramami UML.

Narzędzia takie jak UML mogą ułatwić ten proces, ale działają dobrze tylko z programowaniem obiektowym. Pseudo-kod jest znacznie łatwiejszy dla zespołów technicznych. Proces tworzenia tego kodu znacznie przyspiesza rzeczywistą fazę rozwoju języka programowania.

Istnieją również inne alternatywy, które możesz szukać:

• Diagramy przepływu danych
• Diagramy stanów
• Wykresy przebiegu procesu

Dobre referencje: samouczki dotyczące projektowania oprogramowania . Ponadto osobiście radziłbym przeczytać dobry blog na pseudokodzie lub kodzie? opublikowane przez Coding Horror - mój ulubiony blog do przeczytania :)

Podsumowując, należy wziąć pod uwagę pewne kompromisy.

Podczas programowania w asemblerze pisanie pseudokodu ma sens. Algorytm można zweryfikować przed wysiłkiem ręcznego przetłumaczenia go na język asemblera, a następnie debugowania tłumaczenia. Nadal miało to sens dla skompilowanych języków pierwszej generacji, takich jak FORTRAN IV, gdzie jedynym konstruktem kontrolnym był GOTO, wszystkie zmienne (z wyjątkiem argumentów formalnych) były globalne, a nazwy zmiennych były ograniczone do sześciu znaków.

Dzisiaj mało programujemy w asemblerze i widzę małą wartość w pisaniu pseudokodu zamiast pisania kodu. W przyzwoitym języku rzeczywisty kod będzie podążał za pseudo-kodem niemal słowo po słowie, a pseudo-kod to tylko strata czasu.

Jednak nie zaczynam kodować od dołu. Śledzę TDD i zaczynam od testu. Następnie zaczynam kodować na górze i stopniowo pracuję na dole, w zależności od potrzeb, aby testy zostały zaliczone.

Alternatywą dla pseudokodu jest nie zapisywanie 1000 linii klas niskiego poziomu. Zamiast tego zacznij od góry, nazywając idealny, ale nieistniejący interfejs API dla Twojej domeny. Następnie zbuduj API.

Uważam, że diagramy klas nie są warte wysiłku, nawet jeśli pominiesz listę wszystkich metod i po prostu pokażesz hierarchię dziedziczenia. Diagramy sekwencji są dobre, ale czuję się niezręcznie, gdy je rysuję (prawdopodobnie tylko ja).

Uważam, że diagramy przepływu danych i wykresy struktur są bardziej użyteczne (chociaż wykresy struktur są zwykle kojarzone z BDUF i dlatego obecnie nie są przychylne). DFD są szczególnie przydatne do funkcjonalnego rozkładu. Każda „bańka” w DFD może zostać rozbita na własną DFD, dopóki nie osiągniesz pożądanego poziomu szczegółowości.

Myślę, że narzędzia graficzne są lepsze niż pseudokodowanie, ale UML jest po prostu tak bardzo skomplikowane, że łączy w sobie złe metody :-)

Mówiąc trochę bardziej jasno: myślę, że programowanie to głównie sposób na analizę pewnego problemu, rozdzielenie go na mniejsze komponenty i ich interakcje. Jest to „podróż, a nie miejsce docelowe”, ciągle doskonalisz swoją wiedzę na temat problemu, więc wykres komponentów się zmienia: warstwy pojawiają się i zanikają, funkcje i elementy danych poruszają się w górę iw dół itp.

Naturalnym narzędziem do śledzenia tego procesu jest szkicownik, tak prosty, jak to możliwe, ale wystarczająco złożony, aby pomóc w szybkim zrozumieniu (te same kolory, kształty, strzałki dla tego samego logicznego znaczenia). Nie znalazłem srebrnej kuli i być może kiedyś napiszę własną, ale teraz używam gliffy ; w połączeniu z funkcją powiększania Prezi byłoby prawie idealne.

Dlaczego nie pseudokodowanie? Pseudokodowanie jest krokiem do implementacji, „serializowaną formą wykresu składowego”, kiedy jeszcze kształtujesz swoje pomysły. Nie dobrze, ogranicza twoją głowę. Z mojego doświadczenia wynika, że ​​im później zacznę kodować, tym mniej kodu muszę wyrzucić ...

Ale może dlatego, że napisałem wszystkie wyrzucone kody, więc nie muszę ich teraz pisać, czy doświadczenie, które z nich czerpałem, jest ze mną przy projektowaniu systemu? Cóż, muszę zmodyfikować oświadczenie.

Jeśli zgubiłeś się na wykresie i widzisz wiele równoważnych możliwych rozwiązań, przejdź do pseudokodu, a nawet napisz ten kod za pomocą fałszywych obiektów - w Javie prawie nie ma różnicy. Zobacz kod, poczuj strukturę i użyteczność tych komponentów, pomoże ci naprawić wykres i podejmować decyzje. Ale działa to TYLKO, jeśli jesteś gotowy wyrzucić ten kod, jeśli uważasz, że jest zły. Myślę, że jest to zaleta pseudokodu: mniejsza pokusa, aby zachować go, gdy działa, ale ma on wadliwą strukturę (i jak zwykle nie masz wystarczająco dużo czasu). :-)