I have just first heard of Unified Modelling Language, or UML (Note I am only an amateur software engineer), which wikipedia states is a "general-purpose modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system."

The UML website seems to claim that UML is quite general, stating:

You can model just about any type of application, running on any type and combination of hardware, operating system, programming language, and network, in UML

You can use UML for business modeling and modeling of other non-software systems too

However, when I look at the 14 types of diagrams in UML, I am not sure but it seems to me that this modelling language was primarily designed for specifying particular aspects of what I would call the "specification". Clearly, UML is not suited for specifying literally all aspects of what we need from a system, and it shouldn't be: As an extreme example, a specification language like UML cannot fully capture the specification that the user interface should be "easily understandable", and we obviously shouldn't expect this of UML.

However, given that (of course) UML can't be used to model/make precise all aspects of what we want from our system, I am wondering what are and are not the benefits of using UML: After reading some introductions, I am still unsure about what these diagrams can and cannot be usefully used for.

  • Is UML really as useful for non-object-oriented as it is for object-oriented projects?

  • What (in practive) aspects of a specification can UML fruitfully capture and what is it less useful for (in practice)?


UML is general in the sense, that it can be used for a very broad range of modelling topics and since it is extendable in a certain way, you can adapt it to fit other niches as well. However, it is also a child of its time with a focus on object-oriented modelling overall and there are models that you'd definitely have a hard time diagramming in UML (Bayesian nets for example, surely you could reuse a few diagram elements and annotate them appropriately but that would result in an awkward diagram).

The word "any" in the sentence you posted surely is not used in a mathematical way where you claim that really anything possibly can be modelled using UML, rather, it phrases the expectation that an experienced UML user may be able to model about anything in UML that they could come across in an enterprise /business context.

A few facts about UMLs "Generality"

  • Activity Diagrams are a superset of Petri nets if you read the spec closely. Petri nets are well understood models for concurrency modelling and can model a lot in concurrency research.
  • Entity-Relationship diagrams were left out of UML for idiological reasons. (Class diagrams can substitute and be used in a similar ways as ER, but you can see that the diagrams are not streamlined for that).

What's kind of lacking in UML are architectural block diagrams that you see on any Powerpoint slide.

  • 2
    You have class diagrams, component diagrams, package diagrams and deployment diagrams. At least one of them should be suitable for your architecture level.
    – Simon B
    Apr 9 '20 at 9:27
  • If you want the Powerpoint level, use Visio :-/
    – user188153
    Apr 9 '20 at 16:52
  • @SimonB whats not really there is a block diagram like this one fmc-modeling.org/images/quick-intro/TravelAgency.BD.gif showing information flow with regards to components. Of course you can model it in UML using diagrams and relations. Its just not on the trodden path.
    – wirrbel
    Apr 28 '20 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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