0

I'd like to write down the design of my program to understand the dependencies and calls better. I know there are class diagrams which show inheritance and attribute variables.

However I'd also like to document the input parameters to method functions and in particular which calls the methods function executes inside (e.g. on the input parameters).

Also sometimes it might be useful to show how actual objects are connected (if there is a standard structure).

This way I can have a better understanding of the modules and design before starting to program. Can you suggest a method to do this software design? It should be one-to-one to programming code structure so that I really notice all quirks beforehand (instead of high-level design where thing are hard to implement without further work). Maybe some special diagram or tool or a combination?

It is static dependency and call design rather than time dependent execution monitoring.

(I use Python if you have any specialized recommendations).

Gere
  • 2,231

2 Answers2

3

I don't think there is any one diagram standard to represent everything.

Typically, I think for going from requirements to design, I would follow these steps:

  1. Use case diagrams
  2. Sequence diagrams
  3. Class Diagrams

You might also want to have a look at Collaboration diagrams.

The use cases give a higher level approach which you can skip in your case.

I have found the sequence diagrams most helpful in drawing out my mind. It helps put on paper the first logical objects and the interactions between them. I have also found these to be most helpful in understanding the behavior of an already built system.

Once those are clear and if you need then you can start making a class diagram with as much detail as you want. Class diagrams are static. If you are using a good IDE, you will hardly miss class diagrams.

Ozair Kafray
  • 840
  • 1
  • 8
  • 15
0

However I'd also like to document the input parameters to method functions and in particular which calls the methods function executes inside (e.g. on the input parameters).

You're either solving the wrong problem or beginning at the wrong level of abstraction.

Consider the following quote:

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

...And ask yourself, "Why do I need to worry about all of the methods and all of the input parameters in an application?"

Community
  • 1
Jim G.
  • 8,035