O que é a UML

A UML (Unified Modeling Language, ou linguagem de modelagem unificada) é uma linguagem gráfica para descrever sistemas de software: que partes existem, como elas se relacionam e como se comportam ao longo do tempo. É uma norma mantida pela OMG (Object Management Group). A versão atual é a 2.5.1, publicada em dezembro de 2017. ^{[2] [3]}

Ela nasceu da união de três métodos de orientação a objetos. Grady Booch e James Rumbaugh juntaram as suas notações na Rational Software, e Ivar Jacobson entrou na equipe em 1995. A OMG adotou a UML como padrão em 1997, e a ISO a publicou como norma ISO/IEC 19501 em 2005. ^{[3] [4]}

Uma comparação ajuda: a UML é para o software o que a planta baixa é para uma casa. A planta não levanta paredes, mas deixa arquiteto, engenheiro e cliente conversarem sobre a mesma coisa antes de gastar tijolo.

Este tutorial explica a teoria com o UML Studio, um app em um único arquivo HTML que desenha os 14 diagramas da UML 2.5.1, verifica erros comuns, simula os diagramas de comportamento e gera a documentação em PDF. ^[1]

Abrir o UML Studio →

Palavras que você vai ver o tempo todo

Modelo

A descrição do sistema. Um modelo pode ter muitos diagramas.

Diagrama

Uma vista do modelo, que mostra só uma parte dele, com um propósito.

Classe

Um tipo de coisa: Cliente, Pedido, Livro. Tem atributos (dados) e operações (comportamento).

Objeto

Uma instância concreta de uma classe: a cliente Ana, o pedido 1001.

Relacionamento

Uma ligação entre elementos: associação, generalização, dependência e outras.

Multiplicidade

Quantos objetos participam de uma ligação: 1, 0..1, 0..*, 1..*.

Estereótipo

Uma palavra entre « » que dá um significado extra a um elemento, como «interface» ou «entity».

Para que modelar

Modelar é pensar no papel antes de pensar no código. Um diagrama mostra em uma página o que levaria horas para descobrir lendo programas, e é barato de mudar: apagar uma caixa custa um segundo, refazer um módulo custa dias.

Martin Fowler descreve três jeitos de usar a UML: como esboço, para discutir uma ideia; como planta, um projeto detalhado para outra pessoa construir; e como linguagem de programação, quando o modelo vira código. ^[5] Para quem está começando, o esboço é o melhor ponto de partida: poucos elementos, só o que ajuda a conversa.

• “Preciso usar os 14 diagramas”

  Não. Escolha o diagrama pela pergunta que você quer responder. Muitos projetos vivem bem com classes, casos de uso e sequência.

• “Quanto mais detalhe, melhor”

  Detalhe demais esconde a ideia. Mostre o que importa para quem vai ler; o resto fica no código ou em outro diagrama.

• “UML é só para sistemas enormes”

  Um esboço de cinco caixas também é UML, e muitas vezes é o que mais ajuda.

• “O diagrama substitui a conversa”

  O diagrama apoia a conversa. Se ninguém o entende sem você explicar, simplifique.

Os 14 diagramas

A especificação organiza os diagramas em dois grandes grupos. ^[2] Os de estrutura mostram o que o sistema é: as peças e como elas se ligam, sem tempo. Os de comportamento mostram o que o sistema faz: ações, estados e mensagens. Dentro do comportamento há um subgrupo, os diagramas de interação, focados nas mensagens trocadas entre participantes.

Conheça o UML Studio

Abra o UML Studio. Na primeira vez, ele traz um exemplo de cada um dos 14 diagramas, prontos para explorar.

Criar um diagrama

Clique no + ao lado das abas. O diálogo mostra os 14 tipos nos três grupos, com uma frase sobre cada um. Marque Começar com um exemplo se quiser partir de um modelo pronto.

Onde ficam os seus dados

• Dentro do próprio arquivo. Como no TiddlyWiki, Salvar grava o arquivo HTML com os diagramas dentro. No Chrome e no Edge você escolhe o arquivo uma vez e as próximas gravações o substituem; nos outros navegadores é baixada uma cópia nova, que substitui a antiga.
• Rascunho no navegador. Até você salvar, as mudanças ficam guardadas no navegador e são oferecidas de volta se a página fechar.
• Nada sai do seu computador. O arquivo bloqueia conexões de rede.

Seu primeiro diagrama: uma biblioteca

Vamos modelar uma biblioteca pequena: livros, os exemplares físicos de cada livro, os leitores e os empréstimos. Siga os passos no app.

1. Clique no + das abas, escolha Diagrama de classes, digite o nome Biblioteca e clique em Criar.
2. Na paleta, clique em Classe e depois no quadro. A caixa de nome abre sozinha: digite Livro e tecle Enter.
3. No painel de propriedades, em Atributos, escreva um por linha: - titulo: String e - isbn: String.
4. Repita para mais três classes: Exemplar (abaixo de Livro, com - codigo: String), Leitor (à direita, com - nome: String) e Empréstimo (abaixo de Leitor, com - data: Date e - devolucao: Date).
5. Na paleta, escolha Composição e arraste de Livro até Exemplar. Nas propriedades, ponha 1 na multiplicidade da origem e 1..* na do destino.
6. Escolha Associação e arraste de Leitor até Empréstimo, com multiplicidades 1 e 0..*.
7. Escolha Associação navegável e arraste de Empréstimo até Exemplar, com 1 no destino.
8. Clique em Livro, segure Shift e clique em Leitor. Abra Organizar e escolha Alinhar ao topo.
9. Clique em Verificar. O app deve dizer que não encontrou problemas.
10. Tecle Ctrl+S para gravar o diagrama dentro do arquivo.

Como ler o que você desenhou

• Livro ◆— Exemplar, 1 e 1..*: cada livro tem um ou mais exemplares, e cada exemplar pertence a exatamente um livro. O losango cheio é composição: se o livro sai do acervo, os seus exemplares saem junto. ^[2]
• Leitor — Empréstimo, 1 e 0..*: um leitor pode ter nenhum ou muitos empréstimos; cada empréstimo é de um leitor.
• Empréstimo → Exemplar, 1: cada empréstimo é de um exemplar, e a seta diz que, a partir do empréstimo, se chega ao exemplar.

Repare que o empréstimo liga o leitor ao exemplar, não ao livro: quem sai da estante é uma cópia física. Esse tipo de pergunta, “é o livro ou o exemplar?”, é exatamente o que a modelagem obriga a responder cedo.

Diagrama de classes

É o diagrama mais usado. Cada classe é um retângulo com até três compartimentos: o nome, os atributos e as operações.

Atributos e operações

Um atributo se escreve visibilidade nome: Tipo [multiplicidade] = valor inicial, e uma operação, visibilidade nome(parâmetros): TipoDeRetorno. Só o nome é obrigatório. A visibilidade usa quatro símbolos: ^[2]

No app, escreva um item por linha. Comece a linha com _ para sublinhar (membro estático) e termine uma operação com {abstract} para itálico. Uma classe abstrata tem o nome em itálico: marque Abstrata.

Além da classe comum, a paleta tem interface (um contrato de operações), enumeração (uma lista fechada de valores), tipo de dado, tipo primitivo e sinal.

Os relacionamentos

Multiplicidades

Leia sempre a multiplicidade do lado oposto: em Cliente 1 —— 0..* Pedido, o 0..* perto de Pedido diz quantos pedidos um cliente faz.

Diagrama de objetos

Se o diagrama de classes é a regra, o de objetos é um exemplo: uma fotografia do sistema em um instante. Cada caixa é uma instância, com o nome sublinhado no formato nome : Classe, e mostra valores (slots) em vez de tipos. As linhas são vínculos (links), instâncias das associações.

Use-o para testar um diagrama de classes com um caso real. Se o exemplo não cabe nas regras (um pedido sem cliente, por exemplo), a multiplicidade ou a própria classe estão erradas.

Pacotes e perfis

Um pacote é uma pasta: agrupa elementos e dá um espaço de nomes a eles. O diagrama de pacotes mostra como o modelo se divide e quem depende de quem. As dependências mais comuns são «import» (o pacote passa a enxergar os nomes públicos do outro), «access» (o mesmo, só para uso interno) e «merge» (junta o conteúdo de dois pacotes). ^[2]

Um perfil adapta a UML a um domínio. Ele define estereótipos que estendem metaclasses da própria UML. A extensão é uma linha com triângulo cheio, do estereótipo para a metaclasse; a aplicação do perfil a um pacote é uma dependência «apply». ^[2]

Componentes, estrutura composta e implantação

Componentes

Um componente é uma peça substituível do sistema, que se conhece pelas interfaces: as que ele fornece (o pirulito, um círculo) e as que ele requer (o soquete, um meio círculo). Quando um soquete encaixa num pirulito, temos um conector de montagem. Uma porta é um ponto de interação na borda do componente, e um artefato (um arquivo) pode manifestar o componente.

Estrutura composta

Mostra o interior de uma classe: as partes (papéis que outros objetos ocupam lá dentro), as portas e os conectores entre elas. Um conector de delegação leva o que chega pela porta até a parte que trata.

Implantação

Mostra onde o software roda. Nós são caixas em 3D: um «device» é hardware, um «executionEnvironment» é um ambiente de software, como um servidor de aplicação. Artefatos ficam dentro dos nós em que estão implantados, e os caminhos de comunicação ligam os nós.

Casos de uso

Um caso de uso é um objetivo que alguém atinge com o sistema: “Comprar produto”, “Emprestar livro”. Quem tem o objetivo é o ator, o boneco: uma pessoa, um papel ou outro sistema. O retângulo é o sujeito, o sistema em estudo.

Atividades

O diagrama de atividades é o fluxograma da UML: mostra os passos de um processo, as decisões e o que acontece em paralelo. As partições (raias) mostram quem faz cada passo.

A especificação define o comportamento das atividades com tokens, fichas que percorrem as setas: uma ação começa quando recebe fichas em todas as entradas e, ao terminar, oferece fichas nas saídas. ^[2] É isso que o botão Simular mostra.

1. Abra o exemplo de atividades e clique em Simular.
2. Clique em Passo (ou tecle N) e acompanhe a ficha laranja.
3. Na decisão, escolha [em estoque]. Veja a bifurcação dividir a ficha e a união esperar as duas ações.
4. Clique em Reiniciar e escolha [sem estoque]: o final de fluxo encerra só aquele caminho.

No modo Sortear com a semente, o app escolhe por você. A mesma semente repete a mesma simulação, o que permite mostrar um caso a outra pessoa. As guardas não são avaliadas: quem decide é você ou a semente.

Máquina de estados

Alguns objetos mudam de comportamento conforme a sua situação: um pedido aberto pode ser pago ou cancelado, mas um pedido enviado não. A máquina de estados mostra essas situações (estados) e o que faz o objeto passar de uma para outra (transições).

O rótulo de uma transição segue o formato evento [guarda] / efeito: quando o evento chega e a guarda é verdadeira, o efeito executa e o objeto muda de estado. Dentro do estado, entry / roda ao entrar, do / enquanto está nele e exit / ao sair. A especificação diz que cada evento é tratado até o fim antes do próximo (run-to-completion). ^[2]

Na simulação, o app lista os eventos possíveis a partir do estado atual. Escolha um e veja o registro: sai do estado, executa o efeito e entra no novo. Transições sem evento disparam sozinhas quando o estado termina. O app também trata estados compostos, escolha, histórico raso (H) e profundo (H*), bifurcação e união.

Sequência e comunicação

O diagrama de sequência conta uma história no tempo, de cima para baixo. Cada participante tem uma linha de vida tracejada; as setas entre elas são mensagens. Os retângulos estreitos sobre a linha mostram quando o participante está trabalhando (especificação de execução).

Os fragmentos combinados são molduras com um operador no canto: alt (um entre vários caminhos), opt (opcional), loop (repetição), par (em paralelo), break (interrompe o restante) e neg (um caminho que não deve acontecer), entre outros. ^[2]

O diagrama de comunicação mostra as mesmas mensagens, mas organizadas pelos vínculos entre os participantes. A ordem vem da numeração: 1, depois 1.1 e 1.2, que acontecem dentro da mensagem 1.

Tempo e visão geral de interação

O diagrama de tempo põe o tempo no eixo horizontal e os estados no vertical. É útil quando o momento importa: sistemas embarcados, protocolos, prazos. No app, escreva os estados de cima para baixo e as mudanças no formato tempo estado, uma por linha.

A visão geral de interação parece um diagrama de atividades, mas cada passo é uma interação inteira: uma referência (ref) a outro diagrama ou uma interação desenhada ali mesmo (sd).

Organizar, verificar, documentar e salvar

Organizar

Verificar

O botão Verificar procura erros comuns: «include» ou «extend» fora de casos de uso, comentário ligado sem comentário, nó inicial com entradas, final com saídas, decisão que não decide nada, bifurcação mal formada, generalização entre tipos diferentes ou em ciclo, elementos sem nome e ações soltas. Clique num aviso para selecionar o elemento.

Documentar

O botão Documentar gera um PDF com capa, sumário com links, cada diagrama em desenho vetorial e, se quiser, as tabelas de elementos, de relacionamentos e o resultado da verificação. Escolha os diagramas, a orientação e o papel (A4 ou Carta).

Salvar, exportar e importar

O app não exporta XMI, o formato de troca de modelos da OMG; para levar o modelo a outra ferramenta, use as imagens ou redesenhe.

Erros comuns de principiante

• Generalização no lugar de associação

  Pedido não “é um” Cliente; pedido “pertence a” um cliente. Herança só quando a frase “X é um Y” faz sentido.

• Composição em tudo

  O losango cheio diz que a parte morre com o todo. Um leitor não morre com a biblioteca: ali cabe uma associação.

• Seta do «extend» invertida

  O «include» sai do caso base; o «extend» sai do caso opcional e aponta para o base.

• Caso de uso como tela ou passo

  “Clicar em salvar” não é caso de uso. Um caso de uso é um objetivo completo do ator.

• Sequência com tudo

  Uma sequência com dezenas de mensagens não se lê. Conte um cenário por diagrama e use ref para os detalhes.

• Esquecer as multiplicidades

  Sem elas, ninguém sabe se o pedido pode ficar sem itens. Pergunte sempre “quantos, no mínimo e no máximo?”.

• Diagrama sem pergunta

  Antes de desenhar, escreva a pergunta que o diagrama responde. Se não há pergunta, talvez não precise do diagrama.

• Atividade e estado misturados

  Ação é algo que se faz (“Enviar pacote”); estado é uma situação (“Enviado”). Os nomes já mostram a diferença.

Atalhos de teclado

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “UML Studio”, aplicativo em um único arquivo HTML, giovanipm.github.io/uml-studio.html.
2. Object Management Group, OMG Unified Modeling Language (OMG UML), Version 2.5.1, especificação formal/17-12-05, dezembro de 2017, omg.org/spec/UML/2.5.1.
3. Object Management Group, “Unified Modeling Language”, página da especificação com o histórico de versões (1.1 em dezembro de 1997, 2.0 em julho de 2005, 2.5.1 em dezembro de 2017), acesso em 05/11/2026, omg.org/spec/UML.
4. Wikipedia (em inglês), “Unified Modeling Language”, acesso em 05/11/2026, en.wikipedia.org/wiki/Unified_Modeling_Language. Divergência: a Wikipedia diz que a OMG adotou a UML 1.1 em novembro de 1997; a tabela da própria OMG [3] registra dezembro de 1997.
5. Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3ª edição, livro, Addison-Wesley, 2003, ISBN 978-0-321-19368-1.
6. Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, 2ª edição, livro, Addison-Wesley, 2005, ISBN 978-0-321-26797-9.

What UML is

UML (Unified Modeling Language) is a graphical language for describing software systems: which parts exist, how they relate and how they behave over time. It is a standard maintained by the OMG (Object Management Group). The current version is 2.5.1, published in December 2017. ^{[2] [3]}

It grew out of three object-oriented methods. Grady Booch and James Rumbaugh merged their notations at Rational Software, and Ivar Jacobson joined the team in 1995. The OMG adopted UML as a standard in 1997, and ISO published it as standard ISO/IEC 19501 in 2005. ^{[3] [4]}

A comparison helps: UML is to software what a floor plan is to a house. The plan does not build walls, but it lets the architect, the engineer and the client talk about the same thing before spending any bricks.

This tutorial explains the theory with UML Studio, a single-file HTML app that draws the 14 diagrams of UML 2.5.1, checks common mistakes, simulates the behavior diagrams and creates PDF documentation. ^[1]

Open UML Studio →

Words you will see all the time

Model

The description of the system. A model can have many diagrams.

Diagram

A view of the model that shows only part of it, for a purpose.

Class

A kind of thing: Customer, Order, Book. It has attributes (data) and operations (behavior).

Object

A concrete instance of a class: the customer Ana, order 1001.

Relationship

A link between elements: association, generalization, dependency and others.

Multiplicity

How many objects take part in a link: 1, 0..1, 0..*, 1..*.

Stereotype

A word between « » that gives an element extra meaning, such as «interface» or «entity».

Why model

Modeling is thinking on paper before thinking in code. A diagram shows on one page what would take hours to find out by reading programs, and it is cheap to change: deleting a box takes a second, rewriting a module takes days.

Martin Fowler describes three ways to use UML: as a sketch, to discuss an idea; as a blueprint, a detailed design for someone else to build; and as a programming language, when the model becomes code. ^[5] For beginners, the sketch is the best starting point: few elements, only what helps the conversation.

• “I need all 14 diagrams”

  No. Choose the diagram by the question you want to answer. Many projects do fine with classes, use cases and sequences.

• “More detail is better”

  Too much detail hides the idea. Show what matters to the reader; the rest belongs in the code or in another diagram.

• “UML is only for huge systems”

  A sketch with five boxes is UML too, and it is often what helps most.

• “The diagram replaces the conversation”

  The diagram supports the conversation. If nobody understands it without you explaining, simplify it.

The 14 diagrams

The specification organizes the diagrams into two large groups. ^[2] Structure diagrams show what the system is: the parts and how they connect, without time. Behavior diagrams show what the system does: actions, states and messages. Inside behavior there is a subgroup, the interaction diagrams, focused on the messages exchanged between participants.

Meet UML Studio

Open UML Studio. The first time, it comes with an example of each of the 14 diagrams, ready to explore.

Creating a diagram

Click + next to the tabs. The dialog shows the 14 types in the three groups, with a sentence about each one. Tick Start with an example if you want a ready-made model.

Where your data lives

• Inside the file itself. As in TiddlyWiki, Save writes the HTML file with the diagrams inside. In Chrome and Edge you choose the file once and later saves replace it; in other browsers a new copy is downloaded, which replaces the old one.
• Draft in the browser. Until you save, changes are kept in the browser and offered back if the page closes.
• Nothing leaves your computer. The file blocks network connections.

Your first diagram: a library

Let's model a small library: books, the physical copies of each book, the members and the loans. Follow the steps in the app.

1. Click + next to the tabs, choose Class diagram, type the name Library and click Create.
2. In the palette, click Class and then the canvas. The name box opens by itself: type Book and press Enter.
3. In the properties panel, under Attributes, write one per line: - title: String and - isbn: String.
4. Repeat for three more classes: Copy (below Book, with - code: String), Member (to the right, with - name: String) and Loan (below Member, with - date: Date and - dueDate: Date).
5. In the palette, choose Composition and drag from Book to Copy. In the properties, put 1 as the source multiplicity and 1..* as the target multiplicity.
6. Choose Association and drag from Member to Loan, with multiplicities 1 and 0..*.
7. Choose Directed association and drag from Loan to Copy, with 1 at the target.
8. Click Book, hold Shift and click Member. Open Arrange and choose Align top.
9. Click Check. The app should say it found no problems.
10. Press Ctrl+S to save the diagram inside the file.

How to read what you drew

• Book ◆— Copy, 1 and 1..*: each book has one or more copies, and each copy belongs to exactly one book. The filled diamond is composition: if the book leaves the collection, its copies go with it. ^[2]
• Member — Loan, 1 and 0..*: a member can have no loans or many; each loan belongs to one member.
• Loan → Copy, 1: each loan is for one copy, and the arrow says that from the loan you can reach the copy.

Note that the loan links the member to the copy, not to the book: what leaves the shelf is a physical copy. That kind of question, “is it the book or the copy?”, is exactly what modeling forces you to answer early.

Class diagram

This is the most used diagram. Each class is a rectangle with up to three compartments: the name, the attributes and the operations.

Attributes and operations

An attribute is written visibility name: Type [multiplicity] = initial value, and an operation, visibility name(parameters): ReturnType. Only the name is required. Visibility uses four symbols: ^[2]

In the app, write one item per line. Start the line with _ to underline it (static member) and end an operation with {abstract} for italics. An abstract class has its name in italics: tick Abstract.

Besides the ordinary class, the palette has interface (a contract of operations), enumeration (a closed list of values), data type, primitive type and signal.

Relationships

Multiplicities

Always read the multiplicity on the opposite end: in Customer 1 —— 0..* Order, the 0..* next to Order says how many orders one customer places.

Object diagram

If the class diagram is the rule, the object diagram is an example: a snapshot of the system at one instant. Each box is an instance, with an underlined name in the form name : Class, and shows values (slots) instead of types. The lines are links, instances of the associations.

Use it to test a class diagram with a real case. If the example does not fit the rules (an order without a customer, for instance), the multiplicity or the class itself is wrong.

Packages and profiles

A package is a folder: it groups elements and gives them a namespace. The package diagram shows how the model is split and who depends on whom. The most common dependencies are «import» (the package can see the other one's public names), «access» (the same, for internal use only) and «merge» (joins the contents of two packages). ^[2]

A profile adapts UML to a domain. It defines stereotypes that extend UML's own metaclasses. The extension is a line with a filled triangle, from the stereotype to the metaclass; applying the profile to a package is an «apply» dependency. ^[2]

Components, composite structure and deployment

Components

A component is a replaceable piece of the system, known by its interfaces: the ones it provides (the lollipop, a circle) and the ones it requires (the socket, a half circle). When a socket fits a lollipop, you have an assembly connector. A port is an interaction point on the component's border, and an artifact (a file) can manifest the component.

Composite structure

Shows the inside of a class: the parts (roles that other objects fill inside it), the ports and the connectors between them. A delegation connector passes whatever arrives at the port to the part that handles it.

Deployment

Shows where the software runs. Nodes are 3D boxes: a «device» is hardware, an «executionEnvironment» is a software environment, such as an application server. Artifacts sit inside the nodes they are deployed on, and communication paths link the nodes.

Use cases

A use case is a goal someone reaches with the system: “Buy product”, “Lend a book”. Whoever has the goal is the actor, the stick figure: a person, a role or another system. The rectangle is the subject, the system being studied.

Activities

The activity diagram is UML's flowchart: it shows the steps of a process, the decisions and what happens in parallel. Partitions (swimlanes) show who does each step.

The specification defines how activities behave with tokens that travel along the arrows: an action starts when it receives tokens on all its inputs and, when it finishes, offers tokens on its outputs. ^[2] That is what the Simulate button shows.

1. Open the activity example and click Simulate.
2. Click Step (or press N) and follow the orange token.
3. At the decision, choose [in stock]. Watch the fork split the token and the join wait for both actions.
4. Click Restart and choose [out of stock]: the flow final ends only that path.

In Draw with the seed mode, the app chooses for you. The same seed repeats the same simulation, which lets you show a case to someone else. Guards are not evaluated: you or the seed decide.

State machine

Some objects behave differently depending on their situation: an open order can be paid or cancelled, but a shipped order cannot. The state machine shows these situations (states) and what makes the object move from one to another (transitions).

A transition label has the form event [guard] / effect: when the event arrives and the guard is true, the effect runs and the object changes state. Inside a state, entry / runs on entering, do / while in it and exit / on leaving. The specification says each event is handled to the end before the next one (run-to-completion). ^[2]

In the simulation, the app lists the possible events from the current state. Pick one and read the log: it leaves the state, runs the effect and enters the new one. Transitions without an event fire by themselves when the state completes. The app also handles composite states, choice, shallow (H) and deep (H*) history, fork and join.

Sequence and communication

The sequence diagram tells a story in time, from top to bottom. Each participant has a dashed lifeline; the arrows between them are messages. The narrow rectangles on the line show when the participant is working (execution specification).

Combined fragments are frames with an operator in the corner: alt (one of several paths), opt (optional), loop (repetition), par (in parallel), break (skips the rest) and neg (a path that must not happen), among others. ^[2]

The communication diagram shows the same messages, but arranged by the links between participants. The order comes from the numbering: 1, then 1.1 and 1.2, which happen inside message 1.

Timing and interaction overview

The timing diagram puts time on the horizontal axis and states on the vertical one. It helps when the moment matters: embedded systems, protocols, deadlines. In the app, write the states from top to bottom and the changes as time state, one per line.

The interaction overview looks like an activity diagram, but each step is a whole interaction: a reference (ref) to another diagram or an interaction drawn right there (sd).

Arrange, check, document and save

Arrange

Check

The Check button looks for common mistakes: «include» or «extend» outside use cases, a comment link without a comment, an initial node with incoming edges, a final with outgoing ones, a decision that decides nothing, a malformed fork, generalization between different kinds or in a cycle, unnamed elements and loose actions. Click a warning to select the element.

Document

The Document button creates a PDF with a cover, contents with links, each diagram as a vector drawing and, if you want, the tables of elements, of relationships and the check results. Choose the diagrams, the orientation and the paper (A4 or Letter).

Save, export and import

The app does not export XMI, the OMG model interchange format; to take the model to another tool, use the images or redraw it.

Common beginner mistakes

• Generalization instead of association

  An order is not “a” customer; an order “belongs to” a customer. Use inheritance only when the sentence “X is a Y” makes sense.

• Composition everywhere

  The filled diamond says the part dies with the whole. A member does not die with the library: that is an association.

• «extend» arrow reversed

  «include» leaves the base case; «extend» leaves the optional case and points to the base.

• Use case as a screen or a step

  “Click save” is not a use case. A use case is a complete goal of the actor.

• A sequence with everything

  A sequence with dozens of messages cannot be read. Tell one scenario per diagram and use ref for the details.

• Forgetting multiplicities

  Without them, nobody knows whether an order can have no items. Always ask “how many, at least and at most?”.

• A diagram without a question

  Before drawing, write the question the diagram answers. If there is no question, you may not need the diagram.

• Activities and states mixed up

  An action is something you do (“Ship parcel”); a state is a situation (“Shipped”). The names already show the difference.

Keyboard shortcuts

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “UML Studio”, single-file HTML app, giovanipm.github.io/uml-studio.html.
2. Object Management Group, OMG Unified Modeling Language (OMG UML), Version 2.5.1, specification formal/17-12-05, December 2017, omg.org/spec/UML/2.5.1.
3. Object Management Group, “Unified Modeling Language”, specification page with the version history (1.1 in December 1997, 2.0 in July 2005, 2.5.1 in December 2017), accessed on 5 November 2026, omg.org/spec/UML.
4. Wikipedia, “Unified Modeling Language”, accessed on 5 November 2026, en.wikipedia.org/wiki/Unified_Modeling_Language. Discrepancy: Wikipedia says the OMG adopted UML 1.1 in November 1997; the OMG's own table [3] records December 1997.
5. Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd edition, book, Addison-Wesley, 2003, ISBN 978-0-321-19368-1.
6. Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, 2nd edition, book, Addison-Wesley, 2005, ISBN 978-0-321-26797-9.

Che cos'è UML

UML (Unified Modeling Language, linguaggio di modellazione unificato) è un linguaggio grafico per descrivere sistemi software: quali parti esistono, come sono collegate e come si comportano nel tempo. È uno standard gestito dall'OMG (Object Management Group). La versione attuale è la 2.5.1, pubblicata nel dicembre 2017. ^{[2] [3]}

È nato dall'unione di tre metodi orientati agli oggetti. Grady Booch e James Rumbaugh hanno unito le loro notazioni alla Rational Software, e Ivar Jacobson è entrato nel gruppo nel 1995. L'OMG ha adottato UML come standard nel 1997, e l'ISO lo ha pubblicato come norma ISO/IEC 19501 nel 2005. ^{[3] [4]}

Un paragone aiuta: UML sta al software come la pianta sta a una casa. La pianta non costruisce i muri, ma permette ad architetto, ingegnere e cliente di parlare della stessa cosa prima di spendere mattoni.

Questo tutorial spiega la teoria con UML Studio, un'app in un unico file HTML che disegna i 14 diagrammi di UML 2.5.1, verifica gli errori comuni, simula i diagrammi di comportamento e genera la documentazione in PDF. ^[1]

Apri UML Studio →

Parole che vedrai di continuo

Modello

La descrizione del sistema. Un modello può avere molti diagrammi.

Diagramma

Una vista del modello, che ne mostra solo una parte, con uno scopo.

Classe

Un tipo di cosa: Cliente, Ordine, Libro. Ha attributi (dati) e operazioni (comportamento).

Oggetto

Un'istanza concreta di una classe: la cliente Ana, l'ordine 1001.

Relazione

Un collegamento tra elementi: associazione, generalizzazione, dipendenza e altre.

Molteplicità

Quanti oggetti partecipano a un collegamento: 1, 0..1, 0..*, 1..*.

Stereotipo

Una parola tra « » che dà un significato in più a un elemento, come «interface» o «entity».

Perché modellare

Modellare è pensare sulla carta prima di pensare nel codice. Un diagramma mostra in una pagina ciò che richiederebbe ore leggendo i programmi, ed è economico da cambiare: cancellare una scatola costa un secondo, rifare un modulo costa giorni.

Martin Fowler descrive tre modi di usare UML: come schizzo, per discutere un'idea; come progetto, un disegno dettagliato che altri costruiranno; e come linguaggio di programmazione, quando il modello diventa codice. ^[5] Per chi comincia, lo schizzo è il punto di partenza migliore: pochi elementi, solo ciò che aiuta la conversazione.

• “Devo usare tutti i 14 diagrammi”

  No. Scegli il diagramma in base alla domanda a cui vuoi rispondere. Molti progetti vivono bene con classi, casi d'uso e sequenze.

• “Più dettagli, meglio è”

  Troppi dettagli nascondono l'idea. Mostra ciò che conta per chi legge; il resto sta nel codice o in un altro diagramma.

• “UML è solo per sistemi enormi”

  Anche uno schizzo con cinque scatole è UML, e spesso è ciò che aiuta di più.

• “Il diagramma sostituisce la conversazione”

  Il diagramma sostiene la conversazione. Se nessuno lo capisce senza le tue spiegazioni, semplificalo.

I 14 diagrammi

La specifica organizza i diagrammi in due grandi gruppi. ^[2] Quelli di struttura mostrano che cosa il sistema è: i pezzi e come si collegano, senza il tempo. Quelli di comportamento mostrano che cosa il sistema fa: azioni, stati e messaggi. Dentro il comportamento c'è un sottogruppo, i diagrammi di interazione, centrati sui messaggi scambiati tra i partecipanti.

Conosci UML Studio

Apri UML Studio. La prima volta contiene un esempio per ciascuno dei 14 diagrammi, pronti da esplorare.

Creare un diagramma

Fai clic sul + accanto alle schede. Il dialogo mostra i 14 tipi nei tre gruppi, con una frase su ciascuno. Spunta Inizia con un esempio se vuoi partire da un modello pronto.

Dove stanno i tuoi dati

• Dentro il file stesso. Come in TiddlyWiki, Salva scrive il file HTML con i diagrammi dentro. In Chrome ed Edge scegli il file una volta e i salvataggi successivi lo sostituiscono; negli altri browser viene scaricata una nuova copia, che sostituisce quella vecchia.
• Bozza nel browser. Finché non salvi, le modifiche restano nel browser e vengono riproposte se la pagina si chiude.
• Nulla esce dal tuo computer. Il file blocca le connessioni di rete.

Il tuo primo diagramma: una biblioteca

Modelliamo una piccola biblioteca: i libri, le copie fisiche di ogni libro, i lettori e i prestiti. Segui i passi nell'app.

1. Fai clic sul + delle schede, scegli Diagramma delle classi, scrivi il nome Biblioteca e fai clic su Crea.
2. Nella tavolozza, fai clic su Classe e poi sulla tela. La casella del nome si apre da sola: scrivi Libro e premi Invio.
3. Nel pannello delle proprietà, in Attributi, scrivi uno per riga: - titolo: String e - isbn: String.
4. Ripeti per altre tre classi: Copia (sotto Libro, con - codice: String), Lettore (a destra, con - nome: String) e Prestito (sotto Lettore, con - data: Date e - scadenza: Date).
5. Nella tavolozza, scegli Composizione e trascina da Libro a Copia. Nelle proprietà, metti 1 come molteplicità all'origine e 1..* alla destinazione.
6. Scegli Associazione e trascina da Lettore a Prestito, con molteplicità 1 e 0..*.
7. Scegli Associazione navigabile e trascina da Prestito a Copia, con 1 alla destinazione.
8. Fai clic su Libro, tieni premuto Shift e fai clic su Lettore. Apri Disponi e scegli Allinea in alto.
9. Fai clic su Verifica. L'app dovrebbe dire che non ha trovato problemi.
10. Premi Ctrl+S per salvare il diagramma dentro il file.

Come leggere ciò che hai disegnato

• Libro ◆— Copia, 1 e 1..*: ogni libro ha una o più copie, e ogni copia appartiene a esattamente un libro. Il rombo pieno è composizione: se il libro esce dal catalogo, le sue copie escono con lui. ^[2]
• Lettore — Prestito, 1 e 0..*: un lettore può avere nessun prestito o molti; ogni prestito è di un lettore.
• Prestito → Copia, 1: ogni prestito riguarda una copia, e la freccia dice che dal prestito si arriva alla copia.

Nota che il prestito collega il lettore alla copia, non al libro: dallo scaffale esce una copia fisica. Questo tipo di domanda, “è il libro o la copia?”, è proprio ciò a cui la modellazione obbliga a rispondere presto.

Diagramma delle classi

È il diagramma più usato. Ogni classe è un rettangolo con fino a tre compartimenti: il nome, gli attributi e le operazioni.

Attributi e operazioni

Un attributo si scrive visibilità nome: Tipo [molteplicità] = valore iniziale, e un'operazione, visibilità nome(parametri): TipoDiRitorno. Solo il nome è obbligatorio. La visibilità usa quattro simboli: ^[2]

Nell'app, scrivi un elemento per riga. Inizia la riga con _ per sottolinearla (membro statico) e termina un'operazione con {abstract} per il corsivo. Una classe astratta ha il nome in corsivo: spunta Astratta.

Oltre alla classe normale, la tavolozza ha interfaccia (un contratto di operazioni), enumerazione (un elenco chiuso di valori), tipo di dato, tipo primitivo e segnale.

Le relazioni

Molteplicità

Leggi sempre la molteplicità dal lato opposto: in Cliente 1 —— 0..* Ordine, lo 0..* vicino a Ordine dice quanti ordini fa un cliente.

Diagramma degli oggetti

Se il diagramma delle classi è la regola, quello degli oggetti è un esempio: una fotografia del sistema in un istante. Ogni scatola è un'istanza, con il nome sottolineato nella forma nome : Classe, e mostra valori (slot) invece di tipi. Le linee sono collegamenti (link), istanze delle associazioni.

Usalo per mettere alla prova un diagramma delle classi con un caso reale. Se l'esempio non rispetta le regole (un ordine senza cliente, per esempio), sono sbagliate la molteplicità o la classe stessa.

Package e profili

Un package è una cartella: raggruppa elementi e dà loro uno spazio dei nomi. Il diagramma dei package mostra come si divide il modello e chi dipende da chi. Le dipendenze più comuni sono «import» (il package vede i nomi pubblici dell'altro), «access» (lo stesso, solo per uso interno) e «merge» (unisce il contenuto di due package). ^[2]

Un profilo adatta UML a un dominio. Definisce stereotipi che estendono le metaclassi di UML stesso. L'estensione è una linea con triangolo pieno, dallo stereotipo alla metaclasse; l'applicazione del profilo a un package è una dipendenza «apply». ^[2]

Componenti, struttura composita e deployment

Componenti

Un componente è un pezzo sostituibile del sistema, che si conosce dalle interfacce: quelle che fornisce (il lecca-lecca, un cerchio) e quelle che richiede (la presa, un semicerchio). Quando una presa si incastra in un lecca-lecca abbiamo un connettore di assemblaggio. Una porta è un punto di interazione sul bordo del componente, e un artefatto (un file) può manifestare il componente.

Struttura composita

Mostra l'interno di una classe: le parti (ruoli che altri oggetti occupano lì dentro), le porte e i connettori tra di esse. Un connettore di delega porta ciò che arriva alla porta fino alla parte che lo gestisce.

Deployment

Mostra dove gira il software. I nodi sono scatole in 3D: un «device» è hardware, un «executionEnvironment» è un ambiente software, come un server applicativo. Gli artefatti stanno dentro i nodi su cui sono distribuiti, e i percorsi di comunicazione collegano i nodi.

Casi d'uso

Un caso d'uso è un obiettivo che qualcuno raggiunge con il sistema: “Acquistare prodotto”, “Prestare un libro”. Chi ha l'obiettivo è l'attore, l'omino: una persona, un ruolo o un altro sistema. Il rettangolo è il soggetto, il sistema studiato.

Attività

Il diagramma di attività è il diagramma di flusso di UML: mostra i passi di un processo, le decisioni e ciò che avviene in parallelo. Le partizioni (corsie) mostrano chi fa ogni passo.

La specifica definisce il comportamento delle attività con i token, gettoni che percorrono le frecce: un'azione inizia quando riceve token su tutti gli ingressi e, quando finisce, offre token sulle uscite. ^[2] È ciò che mostra il pulsante Simula.

1. Apri l'esempio di attività e fai clic su Simula.
2. Fai clic su Passo (o premi N) e segui il token arancione.
3. Alla decisione, scegli [disponibile]. Guarda il fork dividere il token e il join attendere entrambe le azioni.
4. Fai clic su Riavvia e scegli [esaurito]: il finale di flusso chiude solo quel percorso.

Nella modalità Estrai con il seme, l'app sceglie per te. Lo stesso seme ripete la stessa simulazione, così puoi mostrare un caso a qualcun altro. Le guardie non vengono valutate: decidi tu o il seme.

Macchina a stati

Alcuni oggetti cambiano comportamento secondo la loro situazione: un ordine aperto può essere pagato o annullato, ma un ordine spedito no. La macchina a stati mostra queste situazioni (stati) e ciò che fa passare l'oggetto dall'una all'altra (transizioni).

L'etichetta di una transizione segue la forma evento [guardia] / effetto: quando arriva l'evento e la guardia è vera, l'effetto viene eseguito e l'oggetto cambia stato. Dentro lo stato, entry / si esegue all'ingresso, do / mentre si è nello stato e exit / all'uscita. La specifica dice che ogni evento viene gestito fino in fondo prima del successivo (run-to-completion). ^[2]

Nella simulazione, l'app elenca gli eventi possibili dallo stato attuale. Scegline uno e leggi il registro: esce dallo stato, esegue l'effetto ed entra nel nuovo. Le transizioni senza evento scattano da sole quando lo stato termina. L'app gestisce anche stati compositi, scelta, storia superficiale (H) e profonda (H*), fork e join.

Sequenza e comunicazione

Il diagramma di sequenza racconta una storia nel tempo, dall'alto in basso. Ogni partecipante ha una linea di vita tratteggiata; le frecce tra di esse sono messaggi. I rettangoli stretti sulla linea mostrano quando il partecipante sta lavorando (specifica di esecuzione).

I frammenti combinati sono cornici con un operatore nell'angolo: alt (uno tra più percorsi), opt (facoltativo), loop (ripetizione), par (in parallelo), break (salta il resto) e neg (un percorso che non deve accadere), tra gli altri. ^[2]

Il diagramma di comunicazione mostra gli stessi messaggi, ma disposti sui collegamenti tra i partecipanti. L'ordine viene dalla numerazione: 1, poi 1.1 e 1.2, che avvengono dentro il messaggio 1.

Temporizzazione e panoramica delle interazioni

Il diagramma di temporizzazione mette il tempo sull'asse orizzontale e gli stati su quello verticale. È utile quando il momento conta: sistemi embedded, protocolli, scadenze. Nell'app, scrivi gli stati dall'alto in basso e i cambi nella forma tempo stato, uno per riga.

La panoramica delle interazioni somiglia a un diagramma di attività, ma ogni passo è un'intera interazione: un riferimento (ref) a un altro diagramma o un'interazione disegnata lì (sd).

Disporre, verificare, documentare e salvare

Disponi

Verifica

Il pulsante Verifica cerca errori comuni: «include» o «extend» fuori dai casi d'uso, collegamento di commento senza commento, nodo iniziale con ingressi, finale con uscite, decisione che non decide nulla, fork malformato, generalizzazione tra tipi diversi o in ciclo, elementi senza nome e azioni isolate. Fai clic su un avviso per selezionare l'elemento.

Documenta

Il pulsante Documenta genera un PDF con copertina, indice con collegamenti, ogni diagramma come disegno vettoriale e, se vuoi, le tabelle degli elementi, delle relazioni e il risultato della verifica. Scegli i diagrammi, l'orientamento e la carta (A4 o Letter).

Salvare, esportare e importare

L'app non esporta XMI, il formato di scambio di modelli dell'OMG; per portare il modello in un altro strumento, usa le immagini o ridisegnalo.

Errori comuni dei principianti

• Generalizzazione al posto dell'associazione

  Un ordine non “è un” cliente; un ordine “appartiene a” un cliente. Usa l'ereditarietà solo quando la frase “X è un Y” ha senso.

• Composizione ovunque

  Il rombo pieno dice che la parte muore con il tutto. Un lettore non muore con la biblioteca: lì serve un'associazione.

• Freccia dell'«extend» invertita

  L'«include» parte dal caso base; l'«extend» parte dal caso facoltativo e punta al base.

• Caso d'uso come schermata o passo

  “Cliccare su salva” non è un caso d'uso. Un caso d'uso è un obiettivo completo dell'attore.

• Una sequenza con tutto

  Una sequenza con decine di messaggi non si legge. Racconta uno scenario per diagramma e usa ref per i dettagli.

• Dimenticare le molteplicità

  Senza di esse, nessuno sa se un ordine può restare senza righe. Chiediti sempre “quanti, come minimo e come massimo?”.

• Un diagramma senza domanda

  Prima di disegnare, scrivi la domanda a cui il diagramma risponde. Se non c'è una domanda, forse il diagramma non serve.

• Attività e stati mescolati

  Un'azione è qualcosa che si fa (“Spedire pacco”); uno stato è una situazione (“Spedito”). I nomi mostrano già la differenza.

Scorciatoie da tastiera

Ripasso veloce

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “UML Studio”, app in un unico file HTML, giovanipm.github.io/uml-studio.html.
2. Object Management Group, OMG Unified Modeling Language (OMG UML), Version 2.5.1, specifica formal/17-12-05, dicembre 2017, omg.org/spec/UML/2.5.1.
3. Object Management Group, “Unified Modeling Language”, pagina della specifica con la cronologia delle versioni (1.1 nel dicembre 1997, 2.0 nel luglio 2005, 2.5.1 nel dicembre 2017), consultata il 05/11/2026, omg.org/spec/UML.
4. Wikipedia (in inglese), “Unified Modeling Language”, consultata il 05/11/2026, en.wikipedia.org/wiki/Unified_Modeling_Language. Divergenza: Wikipedia dice che l'OMG ha adottato UML 1.1 nel novembre 1997; la tabella dell'OMG stessa [3] riporta dicembre 1997.
5. Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3ª edizione, libro, Addison-Wesley, 2003, ISBN 978-0-321-19368-1.
6. Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, 2ª edizione, libro, Addison-Wesley, 2005, ISBN 978-0-321-26797-9.

Qué es UML

UML (Unified Modeling Language, lenguaje unificado de modelado) es un lenguaje gráfico para describir sistemas de software: qué partes existen, cómo se relacionan y cómo se comportan a lo largo del tiempo. Es una norma mantenida por la OMG (Object Management Group). La versión actual es la 2.5.1, publicada en diciembre de 2017. ^{[2] [3]}

Nació de la unión de tres métodos orientados a objetos. Grady Booch y James Rumbaugh juntaron sus notaciones en Rational Software, e Ivar Jacobson se sumó al equipo en 1995. La OMG adoptó UML como estándar en 1997, y la ISO la publicó como norma ISO/IEC 19501 en 2005. ^{[3] [4]}

Una comparación ayuda: UML es al software lo que el plano es a una casa. El plano no levanta paredes, pero permite que arquitecto, ingeniero y cliente hablen de lo mismo antes de gastar ladrillos.

Este tutorial explica la teoría con UML Studio, una app en un único archivo HTML que dibuja los 14 diagramas de UML 2.5.1, verifica errores comunes, simula los diagramas de comportamiento y genera la documentación en PDF. ^[1]

Abrir UML Studio →

Palabras que verás todo el tiempo

Modelo

La descripción del sistema. Un modelo puede tener muchos diagramas.

Diagrama

Una vista del modelo, que muestra solo una parte, con un propósito.

Clase

Un tipo de cosa: Cliente, Pedido, Libro. Tiene atributos (datos) y operaciones (comportamiento).

Objeto

Una instancia concreta de una clase: la clienta Ana, el pedido 1001.

Relación

Un vínculo entre elementos: asociación, generalización, dependencia y otras.

Multiplicidad

Cuántos objetos participan en un vínculo: 1, 0..1, 0..*, 1..*.

Estereotipo

Una palabra entre « » que da un significado extra a un elemento, como «interface» o «entity».

Para qué modelar

Modelar es pensar en papel antes de pensar en código. Un diagrama muestra en una página lo que llevaría horas descubrir leyendo programas, y es barato de cambiar: borrar una caja cuesta un segundo, rehacer un módulo cuesta días.

Martin Fowler describe tres maneras de usar UML: como boceto, para discutir una idea; como plano, un diseño detallado para que otra persona lo construya; y como lenguaje de programación, cuando el modelo se convierte en código. ^[5] Para quien empieza, el boceto es el mejor punto de partida: pocos elementos, solo lo que ayuda a la conversación.

• “Necesito usar los 14 diagramas”

  No. Elige el diagrama por la pregunta que quieres responder. Muchos proyectos viven bien con clases, casos de uso y secuencia.

• “Cuanto más detalle, mejor”

  El exceso de detalle esconde la idea. Muestra lo que importa a quien lee; el resto queda en el código o en otro diagrama.

• “UML es solo para sistemas enormes”

  Un boceto de cinco cajas también es UML, y muchas veces es lo que más ayuda.

• “El diagrama sustituye la conversación”

  El diagrama apoya la conversación. Si nadie lo entiende sin que lo expliques, simplifícalo.

Los 14 diagramas

La especificación organiza los diagramas en dos grandes grupos. ^[2] Los de estructura muestran lo que el sistema es: las piezas y cómo se conectan, sin tiempo. Los de comportamiento muestran lo que el sistema hace: acciones, estados y mensajes. Dentro del comportamiento hay un subgrupo, los diagramas de interacción, centrados en los mensajes que intercambian los participantes.

Conoce UML Studio

Abre UML Studio. La primera vez trae un ejemplo de cada uno de los 14 diagramas, listos para explorar.

Crear un diagrama

Haz clic en el + junto a las pestañas. El diálogo muestra los 14 tipos en los tres grupos, con una frase sobre cada uno. Marca Empezar con un ejemplo si quieres partir de un modelo listo.

Dónde quedan tus datos

• Dentro del propio archivo. Como en TiddlyWiki, Guardar escribe el archivo HTML con los diagramas dentro. En Chrome y Edge eliges el archivo una vez y los siguientes guardados lo sustituyen; en otros navegadores se descarga una copia nueva, que sustituye a la antigua.
• Borrador en el navegador. Hasta que guardes, los cambios quedan en el navegador y se ofrecen de nuevo si la página se cierra.
• Nada sale de tu ordenador. El archivo bloquea las conexiones de red.

Tu primer diagrama: una biblioteca

Vamos a modelar una biblioteca pequeña: los libros, los ejemplares físicos de cada libro, los socios y los préstamos. Sigue los pasos en la app.

1. Haz clic en el + de las pestañas, elige Diagrama de clases, escribe el nombre Biblioteca y haz clic en Crear.
2. En la paleta, haz clic en Clase y luego en el lienzo. La caja del nombre se abre sola: escribe Libro y pulsa Intro.
3. En el panel de propiedades, en Atributos, escribe uno por línea: - titulo: String y - isbn: String.
4. Repite con tres clases más: Ejemplar (debajo de Libro, con - codigo: String), Socio (a la derecha, con - nombre: String) y Préstamo (debajo de Socio, con - fecha: Date y - devolucion: Date).
5. En la paleta, elige Composición y arrastra de Libro a Ejemplar. En las propiedades, pon 1 en la multiplicidad del origen y 1..* en la del destino.
6. Elige Asociación y arrastra de Socio a Préstamo, con multiplicidades 1 y 0..*.
7. Elige Asociación navegable y arrastra de Préstamo a Ejemplar, con 1 en el destino.
8. Haz clic en Libro, mantén Shift y haz clic en Socio. Abre Organizar y elige Alinear arriba.
9. Haz clic en Verificar. La app debe decir que no encontró problemas.
10. Pulsa Ctrl+S para guardar el diagrama dentro del archivo.

Cómo leer lo que dibujaste

• Libro ◆— Ejemplar, 1 y 1..*: cada libro tiene uno o más ejemplares, y cada ejemplar pertenece a exactamente un libro. El rombo relleno es composición: si el libro sale del catálogo, sus ejemplares salen con él. ^[2]
• Socio — Préstamo, 1 y 0..*: un socio puede no tener préstamos o tener muchos; cada préstamo es de un socio.
• Préstamo → Ejemplar, 1: cada préstamo es de un ejemplar, y la flecha dice que, desde el préstamo, se llega al ejemplar.

Fíjate en que el préstamo une al socio con el ejemplar, no con el libro: lo que sale de la estantería es una copia física. Ese tipo de pregunta, “¿es el libro o el ejemplar?”, es justo lo que el modelado obliga a responder pronto.

Diagrama de clases

Es el diagrama más usado. Cada clase es un rectángulo con hasta tres compartimentos: el nombre, los atributos y las operaciones.

Atributos y operaciones

Un atributo se escribe visibilidad nombre: Tipo [multiplicidad] = valor inicial, y una operación, visibilidad nombre(parámetros): TipoDeRetorno. Solo el nombre es obligatorio. La visibilidad usa cuatro símbolos: ^[2]

En la app, escribe un elemento por línea. Empieza la línea con _ para subrayarla (miembro estático) y termina una operación con {abstract} para la cursiva. Una clase abstracta tiene el nombre en cursiva: marca Abstracta.

Además de la clase común, la paleta tiene interfaz (un contrato de operaciones), enumeración (una lista cerrada de valores), tipo de dato, tipo primitivo y señal.

Las relaciones

Multiplicidades

Lee siempre la multiplicidad del lado opuesto: en Cliente 1 —— 0..* Pedido, el 0..* junto a Pedido dice cuántos pedidos hace un cliente.

Diagrama de objetos

Si el diagrama de clases es la regla, el de objetos es un ejemplo: una fotografía del sistema en un instante. Cada caja es una instancia, con el nombre subrayado en el formato nombre : Clase, y muestra valores (slots) en lugar de tipos. Las líneas son enlaces (links), instancias de las asociaciones.

Úsalo para probar un diagrama de clases con un caso real. Si el ejemplo no cabe en las reglas (un pedido sin cliente, por ejemplo), la multiplicidad o la propia clase están mal.

Paquetes y perfiles

Un paquete es una carpeta: agrupa elementos y les da un espacio de nombres. El diagrama de paquetes muestra cómo se divide el modelo y quién depende de quién. Las dependencias más comunes son «import» (el paquete ve los nombres públicos del otro), «access» (lo mismo, solo para uso interno) y «merge» (une el contenido de dos paquetes). ^[2]

Un perfil adapta UML a un dominio. Define estereotipos que extienden metaclases de la propia UML. La extensión es una línea con triángulo relleno, del estereotipo a la metaclase; la aplicación del perfil a un paquete es una dependencia «apply». ^[2]

Componentes, estructura compuesta y despliegue

Componentes

Un componente es una pieza reemplazable del sistema, que se conoce por sus interfaces: las que proporciona (la piruleta, un círculo) y las que requiere (el enchufe, un semicírculo). Cuando un enchufe encaja en una piruleta, tenemos un conector de ensamblaje. Un puerto es un punto de interacción en el borde del componente, y un artefacto (un archivo) puede manifestar el componente.

Estructura compuesta

Muestra el interior de una clase: las partes (papeles que otros objetos ocupan dentro), los puertos y los conectores entre ellos. Un conector de delegación lleva lo que llega al puerto hasta la parte que lo trata.

Despliegue

Muestra dónde se ejecuta el software. Los nodos son cajas en 3D: un «device» es hardware, un «executionEnvironment» es un entorno de software, como un servidor de aplicaciones. Los artefactos van dentro de los nodos en que están desplegados, y las rutas de comunicación unen los nodos.

Casos de uso

Un caso de uso es un objetivo que alguien alcanza con el sistema: “Comprar producto”, “Prestar un libro”. Quien tiene el objetivo es el actor, el muñeco: una persona, un papel u otro sistema. El rectángulo es el sujeto, el sistema en estudio.

Actividades

El diagrama de actividades es el diagrama de flujo de UML: muestra los pasos de un proceso, las decisiones y lo que ocurre en paralelo. Las particiones (calles) muestran quién hace cada paso.

La especificación define el comportamiento de las actividades con tokens, fichas que recorren las flechas: una acción empieza cuando recibe fichas en todas sus entradas y, al terminar, ofrece fichas en sus salidas. ^[2] Es lo que muestra el botón Simular.

1. Abre el ejemplo de actividades y haz clic en Simular.
2. Haz clic en Paso (o pulsa N) y sigue la ficha naranja.
3. En la decisión, elige [en stock]. Mira cómo la bifurcación divide la ficha y la unión espera a las dos acciones.
4. Haz clic en Reiniciar y elige [sin stock]: el final de flujo termina solo ese camino.

En el modo Sortear con la semilla, la app elige por ti. La misma semilla repite la misma simulación, lo que permite mostrar un caso a otra persona. Las guardas no se evalúan: decides tú o la semilla.

Máquina de estados

Algunos objetos cambian de comportamiento según su situación: un pedido abierto se puede pagar o cancelar, pero un pedido enviado no. La máquina de estados muestra esas situaciones (estados) y lo que hace pasar el objeto de una a otra (transiciones).

La etiqueta de una transición sigue el formato evento [guarda] / efecto: cuando llega el evento y la guarda es verdadera, se ejecuta el efecto y el objeto cambia de estado. Dentro del estado, entry / se ejecuta al entrar, do / mientras está en él y exit / al salir. La especificación dice que cada evento se trata hasta el final antes del siguiente (run-to-completion). ^[2]

En la simulación, la app lista los eventos posibles desde el estado actual. Elige uno y lee el registro: sale del estado, ejecuta el efecto y entra en el nuevo. Las transiciones sin evento se disparan solas cuando el estado termina. La app también trata estados compuestos, elección, historial superficial (H) y profundo (H*), bifurcación y unión.

Secuencia y comunicación

El diagrama de secuencia cuenta una historia en el tiempo, de arriba abajo. Cada participante tiene una línea de vida discontinua; las flechas entre ellas son mensajes. Los rectángulos estrechos sobre la línea muestran cuándo el participante está trabajando (especificación de ejecución).

Los fragmentos combinados son marcos con un operador en la esquina: alt (uno entre varios caminos), opt (opcional), loop (repetición), par (en paralelo), break (interrumpe el resto) y neg (un camino que no debe ocurrir), entre otros. ^[2]

El diagrama de comunicación muestra los mismos mensajes, pero organizados por los enlaces entre los participantes. El orden viene de la numeración: 1, luego 1.1 y 1.2, que ocurren dentro del mensaje 1.

Tiempos y visión general de interacción

El diagrama de tiempos pone el tiempo en el eje horizontal y los estados en el vertical. Es útil cuando el momento importa: sistemas embebidos, protocolos, plazos. En la app, escribe los estados de arriba abajo y los cambios en el formato tiempo estado, uno por línea.

La visión general de interacción parece un diagrama de actividades, pero cada paso es una interacción entera: una referencia (ref) a otro diagrama o una interacción dibujada ahí mismo (sd).

Organizar, verificar, documentar y guardar

Organizar

Verificar

El botón Verificar busca errores comunes: «include» o «extend» fuera de casos de uso, enlace de comentario sin comentario, nodo inicial con entradas, final con salidas, decisión que no decide nada, bifurcación mal formada, generalización entre tipos distintos o en ciclo, elementos sin nombre y acciones sueltas. Haz clic en un aviso para seleccionar el elemento.

Documentar

El botón Documentar genera un PDF con portada, índice con enlaces, cada diagrama como dibujo vectorial y, si quieres, las tablas de elementos, de relaciones y el resultado de la verificación. Elige los diagramas, la orientación y el papel (A4 o Carta).

Guardar, exportar e importar

La app no exporta XMI, el formato de intercambio de modelos de la OMG; para llevar el modelo a otra herramienta, usa las imágenes o vuelve a dibujarlo.

Errores comunes de principiante

• Generalización en lugar de asociación

  Un pedido no “es un” cliente; un pedido “pertenece a” un cliente. Usa herencia solo cuando la frase “X es un Y” tiene sentido.

• Composición en todo

  El rombo relleno dice que la parte muere con el todo. Un socio no muere con la biblioteca: ahí va una asociación.

• Flecha del «extend» al revés

  El «include» sale del caso base; el «extend» sale del caso opcional y apunta al base.

• Caso de uso como pantalla o paso

  “Hacer clic en guardar” no es un caso de uso. Un caso de uso es un objetivo completo del actor.

• Una secuencia con todo

  Una secuencia con decenas de mensajes no se lee. Cuenta un escenario por diagrama y usa ref para los detalles.

• Olvidar las multiplicidades

  Sin ellas, nadie sabe si un pedido puede quedarse sin líneas. Pregunta siempre “¿cuántos, como mínimo y como máximo?”.

• Un diagrama sin pregunta

  Antes de dibujar, escribe la pregunta que responde el diagrama. Si no hay pregunta, quizá no necesites el diagrama.

• Actividades y estados mezclados

  Una acción es algo que se hace (“Enviar paquete”); un estado es una situación (“Enviado”). Los nombres ya muestran la diferencia.

Atajos de teclado

Repaso rápido

Intenta responder antes de abrir cada pregunta.

Referencias

1. Giovani Perotto Mesquita, “UML Studio”, app en un único archivo HTML, giovanipm.github.io/uml-studio.html.
2. Object Management Group, OMG Unified Modeling Language (OMG UML), Version 2.5.1, especificación formal/17-12-05, diciembre de 2017, omg.org/spec/UML/2.5.1.
3. Object Management Group, “Unified Modeling Language”, página de la especificación con el historial de versiones (1.1 en diciembre de 1997, 2.0 en julio de 2005, 2.5.1 en diciembre de 2017), consultado el 05/11/2026, omg.org/spec/UML.
4. Wikipedia (en inglés), “Unified Modeling Language”, consultado el 05/11/2026, en.wikipedia.org/wiki/Unified_Modeling_Language. Divergencia: Wikipedia dice que la OMG adoptó UML 1.1 en noviembre de 1997; la tabla de la propia OMG [3] registra diciembre de 1997.
5. Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3.ª edición, libro, Addison-Wesley, 2003, ISBN 978-0-321-19368-1.
6. Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, 2.ª edición, libro, Addison-Wesley, 2005, ISBN 978-0-321-26797-9.