How to represent the relationship between class ResMulti and class Do_work when drawing a class diagram for this demo code snippet (see on godbolt):

#include <thread>
#include <future>
#include <functional>

class Res4ClassA{};
class Res4ClassB{};

Res4ClassA Calculate_A(){return Res4ClassA{};}
Res4ClassB Calculate_B(){return Res4ClassB{};}

class ResMulti
{
public:
    void SetRes4ClassA (const Res4ClassA& res_a)
    {
        res_a_ = res_a;
    }

    void SetRes4ClassB (const Res4ClassB& res_b)
    {
        res_b_ = res_b;
    }

    const Res4ClassA& GetRes4ClassA ()
    {
        return res_a_;
    }

    const Res4ClassB& GetRes4ClassB ()
    {
        return res_b_;
    }
private:
    Res4ClassA res_a_;
    Res4ClassB res_b_;
};

class Do_work
{
public:
    void Run(const Res4ClassA* res){}
};

int main()
{
    Res4ClassA res_a = Calculate_A();

    ResMulti res_multi;
    res_multi.SetRes4ClassA(res_a);

    Do_work work;
    work.Run(&res_multi.GetRes4ClassA());
}

Question: How to represent the relationship between class ResMulti and class Do_work when drawing a class diagram for this demo code snippet?

CodePudding user response：

There is no direct relationship between ResMulti and Do_work:

• Do_work may be dependent on Res4ClassA because it may need to know about that type (not formally in C , because the pointer is used without ever being dereferenced, but if possibly in the design, if we’d expect the operation to to anything maningful with the referred object);
• ResMulti could have a composite aggregation with a Res4ClassA component since it has a C member of that type and in view of the language semantics.
• main() happens to make the glue. But it is not a structural relationship: it’s a dynamic one that emerges from the behaviors of main() implementation.