Archief - Software-Analyse & Ontwerp in een one-man-project?

Hallo iedereen!

Ik studeer toegepaste informatica, waar we naast programmeren de analyse en het ontwerp van software uitgebreid zien.
Meer concreet gaat het over zogenaamde UML diagrammen op basis van een use case diagram, waaronder bij analyse het Activity Diagram, Domain Model en System Sequence Diagram, en bij ontwerpen over het Design Class Diagram en Sequence Diagram. We doen dit allemaal in Visual Paradigm. Ik begrijp min of meer waarom we ze opstellen, en ik zie het nut binnen grote bedrijven, maar...

Wat ik mij nu afvroeg, is het volgende:

Hebben al deze diagrammen nut voor een project waar één persoon aan werkt, of worden ze in de praktijk opgesteld en gebruikt in zo'n situatie?

Ik maak bijvoorbeeld de bedenking dat ik bij Chris Sawyer of Marcus Persson, of meer recent aan mensen op youtube die een vlog maken over hun one-man software (game) project, nooit echt zulke diagrammen zie. Zouden deze mensen dat beter wel doen, of verliest het zijn nut als je alleen bent?

Alvast bedankt!

Voor éénmansprojecten is dit afhankelijk wat en hoe groot het project is. Zo klein toolke of dat je schrijft is nu ook niet echt nuttig om uml ontwerpen en dergelijke te maken.

Use case designs worden wel gebruikt om een beetje een gemakkelijk overzicht te hebben over bepaalde functionaliteiten. Andere diagrammen zoals context diagram of een overzicht van je modules/dependencies zijn wel handig. Zeker bij overdracht van project naar een ander team. Zo kan het nieuw team snel een overzicht hebben van het project.

Bij code-reviews kan een sequentie diagram handig zijn als het over moeilijke stukken code/flow van bepaalde functionaliteit gaat.

Niet echte directe wetenschap van wat en wanneer je uml moet maken. Ik vind dit eerder een tool die je kan helpen om problemen aan te pakken. Bv. is iets snel uittekenen (uml model) voor je programmeert is zeer handig dan direct beginnen te coderen.

Zelf doe ik het in ieder geval niet. Hooguit wat simpele schetsen, maar voornamelijk gewoon doen en geleidelijk aan verbeteren waar nodig.

NoGo zei:

Zelf doe ik het in ieder geval niet. Hooguit wat simpele schetsen, maar voornamelijk gewoon doen en geleidelijk aan verbeteren waar nodig.

Klik om te vergroten...

En welke software projecten maak jij zoal, of hoe groot zijn die als ik vragen mag?

@totec bedankt, als ik het dus goed begrijp kan je even goed met pen en papier snel iets uittekenen indien nodig, maar is het geen vereiste om degelijke software in je eentje tot stand te brengen?
Wat bedoel je juist met een overzicht van je modules / dependencies? Kan je een voorbeeld geven?

Vooral ontleden van je programma in kleinere stukken. Vanuit java kan dit met gradle modules/maven modules. Zoveel mogelijk proberen low coupling te behouden. Bv. de application (base) heeft dependency op api, domain, infrastructure, etc.. en die op zich hebben dan ook weer dependencies naar ander modules. Zo kan je snel circular dependencies terugvinden en die proberen te refactoren.

t0tec zei:

Vooral ontleden van je programma in kleinere stukken. Vanuit java kan dit met gradle modules/maven modules. Zoveel mogelijk proberen low coupling te behouden. Bv. de application (base) heeft dependency op api, domain, infrastructure, etc.. en die op zich hebben dan ook weer dependencies naar ander modules. Zo kan je snel circular dependencies terugvinden en die proberen te refactoren.

Klik om te vergroten...

Ik denk dat ik begrijp wat je bedoelt, om het in de termen vanuit mijn lessen te zeggen: Zoveel mogelijk de verantwoordelijkheden van elk object afbakenen, en problemen/programma's onderverdelen in meerdere lagen of delen, met als doel zo weinig mogelijk afhankelijkheid te hebben?

Oh ik studeer ook toegepaste informatica, ik heb enkel ervaring met Data Flow Diagrammen.

Natuurlijk hebben deze diagrammen nut. Waarom? Ze geven je een overzicht en besparen je een hoop werk. Bijvoorbeeld bij een data flow diagram is het doel om zo goed mogelijk te normaliseren en fouten te voorkomen die ervoor zorgen dat heel je structuur onbruikbaar is. En voor zover ik weet is het bij zowat alle diagrammen het geval. Je maakt ze om achteraf werk te besparen.

En ze zetten je ook aan het denken. Je schrijft iets uit en dan pas realiseer je: hoe ik dat doe is toch niet de beste methode? Misschien kan ik daar iets beters voor bedenken.