I'm modeling a system while improving my knowledge of software engineering. I am building a class diagram and a component diagram, but notice that when I tweak one, I have to alter the other. Also, I feel like I can represent the classes in a component diagram. How do you do this? Do you make them both or only one? If one, which is the best or when to use one or the other?

Thank you!

  • Design using code then generate the two diagrams from that code with some UML-generating tool. That way, they are both an accurate representation of your solution and you don't have to waste time manually creating them. Job done. Onto the next project...
    – David Arno
    Jul 2 '19 at 12:43
  • And if you want to really improve your knowledge of software engineering, skip straight to the end and just learn why UML is a stinking pile of horse manure and never touch it again. It'll save you a lot of wasted effort trying to learn to use the thing. You can then start learning useful SE principles like test first, CI/CD, clean coding etc.
    – David Arno
    Jul 2 '19 at 12:48
  • You don't need any diagrams at all. Jul 2 '19 at 14:47
  • @DavidArno, perhaps my mindset is not the correct one, but I think of a diagram as a tool to guide my implementation (coding task). If I get to code without one, then I will end up not building one. I'm really on the path to learning SE principles and most sources include UML diagrams as a way to model a system. Now, I read the article you linked to and it makes sense. Maybe I'll try finishing this project without focussing much on UML diagrams and them take time later to learn better. Thank you! Jul 2 '19 at 16:16
  • 1
    Diagrams are primarily a tool to communicate ideas to other people, or to help organize your own thoughts; they are ephemeral, and as a system changes they will go out of date. You'll often throw them away. You may use them to document some of the more stable high-level structures; if you document implementation details, you have the same problem with any kind of external documentation, not just UML, so you have to find a balance there; also, writing self-documenting code helps (meaningful names, comments where appropriate, consistency, readability, simplicity, etc.) Jul 2 '19 at 16:52

Do you need to build both? Maybe. It depends. I'd say that if there is a 1:1 mapping between classes in a UML Class Diagram and components in a UML Component Diagram, you probably don't need both diagrams.

The intention of both diagrams is different, though. Class diagrams specifically show classes (and modules or packages), along with their attributes, methods, and relationships. You can get into the details of interfaces and abstract classes and visibility (public, private, protected) of attributes and methods, aggregation and composition, and so on. Of course, the level of detail in a class diagram depends on the audience. Component diagrams are a higher level of abstraction. A component could be something more like a module, an API, a service, an application, a database. If you are building in an object-oriented language, I would suspect that a component would be a set of classes, perhaps a deployable unit.

If you find yourself changing a Component Diagram every time you make a change to a Class Diagram, your Component Diagram is probably at too low of a level of abstraction. I'd think harder about what a "component" is and if it makes sense to use the Component Diagram for your system.

  • "your Component Diagram is probably at too low of a level of abstraction". This might be the problem. Thank you very much! Jul 2 '19 at 12:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.