0

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.

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:

enter image description here

My question: Is there a better way to illustrate the connection between the activators and the systems they're supposed to pass data to? Also the system works in isolation, meaning that external factors such as crashes or mechanical failures are not in the scope of the system.

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
Lee Merlas
  • 430
  • 9
  • 24
  • You have a funny bike that comes to wheels only in the 3rd level. Note that the shared composition has no defined meaning. – qwerty_so Nov 24 '19 at 12:34
  • Cross posted here: https://softwareengineering.stackexchange.com/questions/401528/how-to-improve-this-class-diagram – qwerty_so Nov 24 '19 at 12:36
  • @qwerty_so yes that's still me, I wasn't sure which SO would get more attention. But regarding your previous comment, could you expound more on 'shared composition has no defined meaning'? – Lee Merlas Nov 24 '19 at 12:57
  • Pls. see p. 110 of UML 2.5 (the table in the middle) – qwerty_so Nov 24 '19 at 16:28
  • Questions like yours are a better fit for SE and definitely a bad one here. This place is for specific UML questions, not for design improvements. So cross-posting is regarded a bad habit. You need to decide where to go. – qwerty_so Nov 24 '19 at 16:30

1 Answers1

0

Yes, there is "a better way to illustrate the connection between the activators and the systems they're supposed to" activate. These "activators" are, in fact, part of these subsystems. Consequently, you should not use plain UML associations on the first two levels of your composition break-down hierarchy, but rather UML composition relationships (with "black diamonds"), which are special associations representing part-whole relationships where parts are exclusive (= non-shareable).

Bicycle would be composed of BreakSystem, DriveSystem and SteerSystem. Then, for instance, BreakSystem would be composed of the "activator" BreakLever and Brake. Likewise, for the other subsystems.

Since you don't model a digital bike, better say that an activator (like break lever) causes a subsystem (like the break system) to react, instead of "activators are supposed to pass data to" these subsystems. In a mechanical system, it's about physical causation, and not about passing data.

See also https://www.uml-diagrams.org/composition.html for an explanation of the UML concept of composition, which often comes with, but does not imply, a life cycle dependency.

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
  • Yes I got the part where I should use composition. I'm just trying to emulate the real-life experience of using a bicycle, wherein you pull the brake lever and the 'data' that gets passed is on how hard you pull it, and the brake pads react accordingly. – Lee Merlas Nov 24 '19 at 09:03
  • Do I really have to use composition in connecting `BrakeLever` and `Brake` to the `BrakeSystem`? Why not aggregation, since these parts can exist outside the system? – Lee Merlas Nov 24 '19 at 09:05
  • @LeeMerlas: It's a wide-spread misunderstnding that composition would impy a lifecycle dependency. There are cases where it does (e.g., `Brain` as a component of `Person`), and there are also cases where it does not (e.g., `Heart` as a component of `Person`). These are not aggregation relationships because they are exclusive. See also https://stackoverflow.com/questions/734891/aggregation-versus-composition/27889087#27889087 – Gerd Wagner Nov 24 '19 at 09:10