royerlab / aydin

Aydin — User-friendly, Fast, Self-Supervised Image Denoising for All.
https://royerlab.github.io/aydin/
BSD 3-Clause "New" or "Revised" License
149 stars 14 forks source link

Dataflow and class hierarchy diagrams #198

Open xiyuyi opened 2 years ago

xiyuyi commented 2 years ago

Is your feature request related to a problem? Please describe. The feature is to help new developers: It would be nice to have a data flow diagram and a class hierarchy diagram to provide a quick and concise overview of the Aydin architecture. It would be helpful for a new developer to keep track of the many layers of parent/child classes when attempting to decipher the package structure by tracing the code in an execution).

Describe the solution you'd like Two pictures describing the data flow and class hierarchy diagrams might be enough.

Describe alternatives you've considered If it gets too complicated to capture the architecture using static diagrams, it would be nice to have a website like VTK's documentation page. VTK is quite complicated, I'm only using it as an example to explain the idea, but please don't perceive it as an expectation :D.

Additional context N.A.

AhmetCanSolak commented 2 years ago

Thank you for the feature request @xiyuyi !

We can definitely have such diagrams. But to set the expectations right, I should mention that data typically doesn't flow on Aydin Studio(GUI). We have a data model and data is requested when run command is called. We are doing something like Model/View(which is sort of recommended way for Qt applications, please see https://doc.qt.io/qt-6/model-view-programming.html) paradigm on GUI. For the non-GUI modules, dataflow is as simple as it gets. Data is passed down the composed classes where needed (like passing image to feature generator to be able to generate features).

We have a simple class hierarchy also, which we can easily document. All the submodules in the codebase are standalone modular units. Only a couple of them composing the others (like restoration implementations compose image translators). I will make a diagram to show total relationships. Previously in an internal presentation I actually showed this for GUI classes and we improved over time. You can see below. I can do something similar for all submodules in the codebase to give sense of what depends on what. I will share that with you.

image

Coming to the VTK example, I think it is quite bad. This Class Hierarchy page shows class summaries but list is way too long and summaries are not even complete as far as we can see on the page. Personally, I would never use such reference list, takes a lot of time to find what you are looking for. Instead of this sort of long list we decided to group the classes in submodules in our documentation, see as an example: https://royerlab.github.io/aydin/api/regressors.html

I like to discuss further if we can do better than the example Class Hierarchy. Please let me know if have any other suggestions or any pain points with the existing API reference on our documentation.

xiyuyi commented 2 years ago

Hi @AhmetCanSolak AhmetCan, The class hierarchy diagram you proposed sounds good! Each node would be the name of the class (instead of a descriptive name of the class). It would also be helpful to list out the method names inside each method if that makes sense.

I trust you as the expert here and I do not have more examples.