Projektowanie oprogramowania - metodyka

0

Z reguły bazuję na "własnych rozwiązaniach" i np. tworząc moduł do ERP już po zebraniu wymagań, rozrysowuję na kartce okienka, widoki, konkretne przyciski, mniej więcej planuję metody CRUDowe, serwisowe, następnie zaczynam od tworzenia bazy danych, po niej DAL i w trakcie wychodzą jeszcze różne potrzebne metody. Generalnie - rozwiązanie działa. Z drugiej strony, być może istnieją lepsze i chciałem Was zapytać o opinie. Czy może ktoś korzystał przykładowo z diagramów UML i ułatwiło mu to znacząco życie? Albo jeszcze z innych narzędzi, które pomagają dokładnie zaprojektować konkretne elementy oprogramowania?

1

Ja zawsze zapominam, które strzałki co oznaczają na UMLach. Jak sam rysuję to raczej bardziej freestylowe (i z tego co wiem, mało kto już rysuje diagramy UMLowe, takie podręcznikowe), że kwadraciki, strzałki, ale bez tej całej ścisłości.

Albo jeszcze z innych narzędzi, które pomagają dokładnie zaprojektować konkretne elementy oprogramowania?

stosowałem też aplikacje do map myśli, albo aplikacje do diagramów (np. https://draw.io ). Albo programy do rysowania prototypów GUI, np. open source'owy Pencil:
http://pencil.evolus.vn/Default.html

no i są specjalne języki do pisania diagramów, np. Mermaid. Taka Typora (edytor do Markdowna) pozwala na osadzanie ich w dokumentach Markdown http://support.typora.io/Draw-Diagrams-With-Markdown/ )

a poza tym to kartka papieru i długopis albo pisaki, to jest ponadczasowe narzędzie.

No i oczywiście wyobraźnia, często ona wystarcza.

2

Najbardziej ułatwia życie niezaczynanie od bazy danych.

0

możesz rozwinąć?

8

No ja jestem programistą C#, więc jak mam stworzyć jakąś aplikację, to piszę kod logiki biznesowej w C# (tzn. najpierw oczywiście wymyślam, co napisać, czasem rysuję sobie jakieś klasy i powiązania między nimi długopisem na kartce). Do tej logiki tworzę testy - w zależności od tego jak dobrze ją rozumiem robię to albo przed implementacją, albo po niej. Potem wystawiam tą logikę "na zewnątrz" jako jakieś API albo np. jako webowe MVC bazujące na systemie szablonów (to niestety wymaga dłubania we frontendzie, więc także HTML, CSS, JS), czyli do kodu biznesowego dopisuję kod infrastrukturalny. No i to już mogę testować organoleptycznie uruchamiając aplikację i widząc, czy się wyświetla prawidłowo.

A potem z kodu klas C# modelujących trwałe struktury danych generuję bazę. Wcześniej nie jest potrzebna, bo przecież i tak w trybie debug nie mam nic wartościowego, co byłoby warto do bazy zapisać.

1

Ja z kolei mam tak, że czasem jest mi łatwiej zacząć od bazy danych. Tzn. tworzę model, ale w bazie, a nie w C#. Dopiero później zamieniam to na klasy. Ale u mnie to zależy od problemu. Niektóre rzeczy lepiej mi się tworzy zaczynając od bazy, inne tak jak @somekind od projektu klas.

Ale zawsze posługuję się UMLem. Rzadko rozrysowuję sobie na kartce, bo potem jak się robi zmiany, to jednak łatwiej je zrobić na kompie :) Czasami zaczynam od kartki, ale ostatecznie wszystko ląduje w aplikacji do robienia diagramów.

1 użytkowników online, w tym zalogowanych: 0, gości: 1