#PLANT UML FLOW DIAGRAM CODE#
I am sorry I haven't provided an answer, but it depends on what code you are writing. Trying to map functional programming code into an object is a nightmare. These I have discovered don't fall into either category of programming (OO or procedural). Recently there have been shifts in Java and c# to provide functional programming techniques. This will decide which diagramming tools that should be used, and how you are going to analyze the system. If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This is a form of coding hell which I have stayed clear of for many years. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. A good book on this is "Object Thinking-David West".it helps to think about objects first. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. Once you're in the zone with thinking about objects then the OOD methods work fine. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. They map better, and do help in the thinking about a system.
My advice, is that if you're doing OO code, then use OOD. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on. In Go structs are used intensively which are basic data types. I too am looking for a diagram that could do this sort of work. I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. This is most helpful when dealing in a procedural way. The emphasis on DFD's is data separated from the function.
0 kommentar(er)
