I'd like to just amplify here what @Dunk has said in the comments. What you described in your "problem statement" is not a problem statement in the object-oriented world.
The "Problem" described a data or relational model, not an object model.
An object model in the context of object-orientation is there to model behavior. Without behavior there is no ...
UML is the Unified Modeling Language it supports a range of paradigms for programming not just OO with its Class diagrams. Use whichever diagrams add value to your documentation or when discussing the implementation at a whiteboard or in review.
Class diagram - You can treat each module as a class for diagramming purposes.
So you want to describe the functional implementation of the application with a diagram
You can use a sequence diagram to depict the functional flow among your modules. This is a bit more at a component level.
If you are talking about specific logic and a bit more detail go for a State diagram
Yes, it is correct, but not optimal.
The dependency just says 'A2Impl' cannot do without 'A', but that is obvious, since A2Impl implements A. In fact, the 'implements' relationship implies the dependency.
If A2Impl has a permanent reference to another instance of A, it would be better to replace the dependency by an association (an arrow with a solid line ...
Stop drawing connections just because you're supposed to draw connections.
In fact, stop drawing diagrams just because you're supposed to draw diagrams.
These things exist to help you communicate your design to other coders. Coders who are working in your domain and in your code base.
So please, even if you put Pose in 1000 classes don't draw a 1000 ...
We model for a reason. If we don't have a reason, then any design fine.
Without knowing how a model is to be used, we could really go off the deep end, modeling to a super level of detail, which could include year of manufacture, manufacturer, model/brand, color, shape, size, image, owner (especially if famous), brand of each string, age of each ...
You can object that the question is silly because it assumes domain knowledge you cannot be expected to bring with you. People have different hobbies.
Anyway, I happen to know a fair bit about guitars and I suspect they wanted to see a class hierarchy something like this:
Instrument -> StringInstrument -> FrettedStringInstrument -> ...
There are several possible class diagrams. In practice, it is good to keep the class diagram as simple as possible, unless there is a good reason to add complexity. If the only task is to show a 6 string guitar and a 4 string bass in a class diagram, I would draw this:
The second task is to add behavior to identify if a note from one is equal to a note from ...
I'm not an expert on electric guitars or basses (I'm a drummer myself) but I can tell you that most of the things that you put in your class diagram are irrelevant.
You can't just design a class structure to represent six string guitars and four string basses, that's nonsense. You need to identify the problem domain: what specific problem is my software ...
It is an association class.
Consider it as a class „C“ that
links between A and B
has properties, such as the Rating score
You could implement it, for example, by referencing from C to both A and B (and vice versa),
Find some more info for example here and here.
The behaviors of a system are usually captured in UML with use case (requirements), sequence diagrams (interaction scenario between several classes), or activity diagrams (logical internal flow).
The activity diagram would best be used to model your narrative.