1

A colleague of mine did this UML component diagram to represent both the required/provided interfaces and the internal structure of the subsystems that compose the system we're working on:

(The subsystems are called "User Management", "Votes Management", "Post Management", etc...)

This diagram is for a System Design Document. This is therefore not an exact representation of the code objects.

The system follows a 3 layer approach:

  • GUI represents the User Interface
  • Control represents the application logic
  • Repository and media access are required interface given by some other components that represent the Data Access.

Each component in the figure above has their own GUI and Control subcomponent. The repository is a monolithic component outside of this diagram so we're just ignoring it.

The question is: does it make sense that "GUI" and "Control" are instances, while "Gestione Utenti", "Gestione Voti", ecc... are not? My colleague states that this is useful to intend that "each GUI subcomponent is different from the GUI subcomponent elsewhere in the diagram". So there is another question: does it make sense that there are multiple "GUI" and "Control" subcomponents with the same name?

Improve this question
6
  • I'm not sure using instances like that is valid or not. What I can tell you is if I had to represent different GUI subcomponents I wouldn't name them the same in the same diagram. Using instances like that makes it look like they are all instances of the same class, which is probably not what you want.
    – Jbm
    Mar 12, 2022 at 14:48
  • 1
    Your colleague might have intended something different from what I'm about to say, but, just for reference - in UML, a full name of any instance is given as instanceName:Component (underlined), where "Component" really plays the role of some kind of an abstract type (components are meant to be substitutable). But you may omit the type instanceName or the name :ComponentType if one or the other is not important for what the diagram is trying to communicate. 1/2
    – Filip Milovanović
    Mar 14, 2022 at 20:02
  • 1
    So, for example, :GUI would, strictly speaking, indicate an unnamed instance that has the abstract type "GUI" (i.e., an instance of GUI component), but the concrete GUI realizations depicted may be different from each other. This would mean that all of the parent components work with their GUI subcomponent in the same way (see and call the same sorts of methods, use the same interface), but that the GUI components themselves differ in what they do internally and/or in how they are wired up with Control "behind the scenes". Your colleague may have intended something less formal, though. 2/2
    – Filip Milovanović
    Mar 14, 2022 at 20:02
  • 1
    I think you are correct there (although, I'm not 100% sure, I think a Component can also act as a namespace). This is (among other things) why I said that your colleague may have intended something less formal - meaning they may have sacrificed syntactical correctness in order to communicate the idea more simply. In the end of the day, being 100% correct with UML is not that important (unless we're talking about tools that can generate code from diagrams), but it can be confusing if the parties involved disagree about the subtle meaning of the symbols. 1/2
    – Filip Milovanović
    Mar 14, 2022 at 20:46
  • 1
    So, what you can do is talk it out with your team, just to make sure that everyone is on the same page, and if you decide it's worth the effort, you may adjust the diagram so that it makes sense to everyone. Remember, you can always include some UML comments (the note box), and add clarifying remarks in an accompanying text. 2/2
    – Filip Milovanović
    Mar 14, 2022 at 20:46

2 Answers 2

Reset to default
2

From an UML point of view, this makes sense:

  • :GUI and :Control represent parts inside a components. To simplify, parts are to components, what properties are to classes.
  • Gestione Utenti, Gestione Voti etc.. are interchangeable components: the diagram represent how they depend on each-other via the offered and consumed interfaces, independently of their future instantiation.

These larger component may later be composed, for example by making them parts of a large component (you could for example have two Gestione Utenti if the larger system would require this component to be redundant for being fail safe), or just by deploying them onto many nodes and ensure the right plumbing.

Improve this answer
0

No, this is not possible.

Either you draw an object diagram with instance specifications, or a component diagramm, with the internal structure of the components. What you have here is a mix.

Text with underline means it is an instance specification. Showing it nested within a component doesn't mean anything. Connecting instance specifications with ports is not possible.

You can correct this, by simply removing the underline. Then they become parts of the component, as described in Christophe's answer.

Some minor hickups:

Parts are shown in a structure compartment. As such there should be a separation line between the name of the component and the compartment.

Connectors cannot connect to interface usages or realizations (lolli and socket). The notation is allowed for connectors connecting simple ports (ports with only one interface). So, you need to add ports to both ends of the connectors.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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