How to improve this class diagram of a system with its components

Question

So I was given a task of making a class diagram for a bicycle. I know what a class diagram is and the concepts behind one.

The requirement is that the bike can brake, turn or speed up. Now to me, a bike has three major components: the brake system, drive system and steering system. And each system has each own activators for actions: a brake handle, a pedal and a handlebar.

For my bike to actually brake, I need to go through the brake lever to trigger my brake system (pass data on how hard the lever is squeezed from the lever to the brake system). Same for the other two systems as well. This is what I've come up with so far:

My question: Is there a better way to illustrate the connection between the activators and the systems they're supposed to pass data to?

Answer 1

When it comes to class design, always bear in mind that it is less about mirroring the real world objects and more about organizing your thoughts and reducing complexity behind a use-case like brake(). This is generally achieved by reducing levels into a more flat organization. Also, special components like BrakeLever should not know about general components like BrakeSystem.

I would use more composition. Bike should have-a BrakeSystem. BrakeSystem should have-a Brakes and BrakeLever. BrakeLever should be a public property of BrakeSystem. BrakeLever should have a onPull event that BrakeSystem listens to with its private handleBrakeLeverPull() method. handleBrakeLeverPull() can call the private reduceRPM() method. reduceRPM() then uses Wheels setWheelSpeed(). DriveSystem and SteerSystem in an analogous manner.

Answer 2

There's already a nice answer but I think some more thoughts deserver to be considered:

• I agree with Ozan: your model should have relevant level of details. If for example you'd create an application for selling bikes, you'd probably have a very flat structure of an article with a price.

• But if you need a digital twin for example to simulate a bike, to enhance the bike with sensors and actuators, or to create a bike configurator, it's completely ok to have a model that is close to the real-world.

Not knowing your modeling intent:

• The guiding principle for the model should be the abstraction of components. The result will be a bike and its three specific subsystems. This leaves more freedom: there are for example bikes whose brake is activated by pulling the pedal backwards without the lever.

• Subsystems could be decomposed further, either specifically as you did, or using a more general composite pattern, where the number and type of components could vary at runtime.

Finally, the UML class diagram is only there to show the structure of the object. How the "connections will be used" is already behavior and would be modelled with behevioral diagrams such as sequence or communication diagrams.