You should put in the class diagram all the classes and association you need, regardless how many. But not more.
So let me challenge your diagram:
- Will you really have a class
PerformanceFile with properties and methods ? Or is the file just an artefact created by a
Calculator upon invocation of one of its methods (e.g.
- What are the differences between inlet and outlet conditions ? Are these the same kind of conditions (e.g.temperature, humidity, pression, ...) but with a different source (e.g. input and output) ?
- Is there a structural relation between the
Calculator and the conditions it uses for the calculation ? Or does it just access conditions that are measured by the AirConditionner ?
With the assumptions 1)No, 2)Different, 3)No, 1 calulator for 1 unit, I'd see a diagram with much less relations:
I've detailed some properties and methods, just to clarify the responsibility of the classes. But if you just keep the classes you'll have a much simpler diagram.
Important remark: if the calculator measures the conditions, the conditions would be linked to the calculator instead of the air conditioning unit. In this case, if the calculator could control several airco units, it would be necessary to link the conditions to both the calculator and the unit: