Diagramas UML

A arena conhece o herói, mas essa ligação não diz em que ordem um pedido move o herói e atualiza a vista. UML tem diagramas para perguntas diferentes: classes mostram estrutura; sequências e comunicação mostram mensagens; estados mostram reações permitidas.

Diagrama de classes

Uma classe pode ter três compartimentos: nome, atributos e operações. + significa público, - privado, # protegido e ~ visível no pacote. Atributos e operações estáticos aparecem sublinhados; elementos abstratos podem aparecer em itálico ou com indicação de abstrato.

Uma operação pode mostrar parâmetros e retorno, como + mover(x: int): boolean. Uma interface pode usar o estereótipo «interface». Os nomes são tipos; num diagrama de objetos, heroi:Heroi identificaria uma instância.

Começa por um exemplo concreto. Uma Arena guarda um Heroi e Paredes; o Heroi conhece a sua Posicao. A arena compõe paredes e herói porque o seu ciclo de vida manda neles; a ligação a Posicao é uma associação navegável simples, sem afirmar posse exclusiva. Cada relação da tabela seguinte afirma uma coisa diferente sobre estas ligações.

Relação	Notação	O que afirma
Associação	Linha contínua	Objetos mantêm uma relação estrutural. Uma seta aberta pode indicar navegação.
Dependência	Seta tracejada	Um elemento usa outro, por exemplo como parâmetro ou variável temporária.
Generalização	Linha e triângulo vazio para a base	Um tipo especializa outro e deve respeitar o contrato da base.
Realização	Linha tracejada e triângulo vazio para a interface	Uma classe implementa o contrato.
Agregação partilhada	Losango vazio do lado do todo	Relação todo/parte fraca; a semântica de posse precisa de ser definida no modelo.
Composição	Losango cheio do lado do todo	Posse forte: uma parte pertence no máximo a um todo composto de cada vez.

Na composição, o modelo associa o ciclo de vida da parte ao todo: eliminar o todo elimina as partes que ainda lhe pertencem. Uma parte pode ser retirada ou transferida antes disso. Não interpretes esta regra conceptual como uma chamada automática ao garbage collector de Java.

Uma referência num campo Java não prova composição. Usa associação quando não estás a afirmar posse forte. Também não assumes navegação nas duas direções apenas porque a linha não mostra uma seta; o desenho pode deixar essa informação por especificar.

Traduzir relações para Java

Uma classe Equipa pode especializar Grupo e realizar a interface Participante. Em Java, a base vem depois de extends e as interfaces depois de implements:

class Equipa extends Grupo implements Participante {
    private final java.util.Set<Membro> membros =
        new java.util.HashSet<Membro>();
}

O excerto pressupõe que Grupo, Participante e Membro existem e que os métodos exigidos já são herdados ou implementados. Uma classe só estende uma classe, mas pode implementar várias interfaces, separadas por vírgulas. Escrever implements Participante extends Grupo troca a ordem da gramática e não compila.

O campo membros pode representar uma associação navegável para zero ou mais membros, sem duplicados lógicos. O conjunto precisa da igualdade adequada de Membro. Uma multiplicidade mínima de um também precisaria de validação na construção e nas remoções; Java não a impõe por declarar um campo. O campo e o final na referência também não provam composição UML ou imutabilidade do conjunto.

Multiplicidades

A multiplicidade num extremo diz quantos objetos desse extremo podem relacionar-se com um objeto do outro extremo. 1 é exatamente um; 0..1, opcional; 0..* ou *, zero ou mais; 1..*, pelo menos um.

Neste modelo escolhemos que uma arena possui um herói e zero ou mais paredes. O losango fica na arena, o todo. O herói conhece uma posição. A associação à posição não afirma que a posição só possa ser usada por esse herói.

Se cada herói só pertence a uma arena, a multiplicidade no extremo da arena também seria 1. O desenho reduzido mostra apenas as multiplicidades necessárias à pergunta sobre o conteúdo da arena; num modelo completo, explicita os dois extremos e os nomes dos papéis.

Uma associação pode ter dados próprios. Por exemplo, a relação entre aluno e projeto pode guardar papel e data de entrada. Uma classe de associação representa esses dados da relação, em vez de os duplicar em cada aluno ou projeto.

Diagrama de sequência

Os participantes têm linhas de vida. O tempo avança de cima para baixo e representa ordem, não duração proporcional à distância vertical. Uma mensagem de chamada tem como destino o objeto que oferece a operação.

Uma seta de chamada síncrona usa uma ponta preenchida; uma mensagem assíncrona usa uma ponta aberta. Um retorno, quando o mostramos, é tracejado. Uma ativação é um retângulo fino sobre a linha de vida que indica execução. O esquema abaixo mostra chamadas síncronas e omite as ativações para destacar o percurso.

O modelo começa na posição 2; o controlador pede mover(1), onde o argumento é um deslocamento. O modelo aceita, passa para a posição 3 e devolve true; depois o controlador lê a posição e pede à vista mostrar(3), que mostra o resultado aceite pelo modelo, não apenas a posição pedida pelo utilizador.

Uma mensagem para o próprio objeto representa uma chamada interna. Uma criação inicia a linha de vida do novo participante; uma destruição termina-a com uma cruz.

Condições e repetição

Um fragmento alt separa percursos alternativos por guardas, como [livre] e [ocupada]. opt representa um percurso opcional. loop contém mensagens repetidas enquanto uma condição ou contagem o determina.

O modelo começa em 2 e a tentativa pretende chegar a 3. Aqui acrescentamos uma regra de ocupação: só entra na célula se estiver livre. Esta regra não existe no modelo reduzido de MVC, que verifica apenas os limites. O fragmento alt representa os dois resultados da tentativa:

A leitura getX() e a chamada mostrar(x) ficam depois do fragmento porque ocorrem nos dois casos. No ramo livre, x vale 3; no ocupado, vale 2. Escrever mostrar(3) nos dois percursos esconderia a recusa. Uma chamada a Mapa.livre() dentro de mover seria numerada 1.1 no diagrama de comunicação.

Uma guarda é uma condição entre parênteses retos. Não é um método novo do objeto nem uma garantia de que os outros ramos são impossíveis. As guardas devem descrever as condições reais do cenário.

Diagrama de comunicação

Representa os participantes e as ligações por onde enviam mensagens. Como não há eixo vertical de tempo, a numeração fixa a ordem.

Aqui 1, 2 e 3 são chamadas consecutivas do controlador. Se mover chamasse uma operação interna noutro participante, essa chamada poderia ser 1.1; uma segunda chamada dentro da mesma ativação seria 1.2. A numeração hierárquica mostra o aninhamento, não apenas uma lista global.

Uma repetição pode ser indicada por *[condição]. Sequência e comunicação podem descrever a mesma interação, mas a sequência torna a ordem mais visível e a comunicação destaca as ligações.

Diagrama de estados

Um estado representa uma situação em que o objeto responde a eventos de determinada maneira. A mesma ação pausar só faz sentido durante o jogo, não no menu.

O círculo preenchido indica o início; o círculo com outro dentro indica o fim. O jogo começa em Menu, começar leva a Jogar, pausar leva a Pausa e retomar regressa a Jogar. perder termina este percurso.

Uma transição pode ter a forma evento [guarda] / efeito. Em mover [célula livre] / atualizar posição, o evento desencadeia a tentativa, a guarda decide se é permitida e o efeito descreve o que acontece.

entry é uma ação ao entrar num estado e exit ao sair. Uma transição externa para o mesmo estado volta a executar saída e entrada; uma reação interna pode tratar o evento sem sair do estado. Esta diferença importa se a entrada reinicia um temporizador.

Estados compostos agrupam uma máquina interna. Por exemplo, Jogar pode conter Normal e Invencível. Não confundas esse agrupamento com uma subclasse Java: o diagrama descreve comportamento permitido, não exige uma implementação específica.

Regiões ortogonais

Um estado composto pode conter regiões ortogonais, cada uma com o seu estado ativo. Podemos separar o estado da partida, Ativo ou Pausa, do áudio, Audível ou Mudo. Se as duas dimensões forem independentes, as quatro configurações são permitidas:

Partida	Áudio
Ativo	Audível
Ativo	Mudo
Pausa	Audível
Pausa	Mudo

Representar duas regiões evita criar quatro nomes de estado que repitam as mesmas regras. Com n dimensões binárias independentes, um modelo plano pode precisar de $2^n$ combinações. As regiões reduzem a repetição do desenho; não fazem desaparecer as combinações nem implicam criar uma thread Java por região.

Também podem existir várias transições com o mesmo evento e a mesma origem, distinguidas por guardas. Em Menu, começar [dados válidos] pode levar a Jogar e começar [dados inválidos] pode apresentar um erro e manter Menu. Define condições que se excluem quando precisas de uma escolha determinada; não assumes que duas transições concorrentes serão escolhidas pela ordem em que as desenhaste.

Conferir o desenho com o contrato

Percorre uma situação concreta, como mover de 2 para 3 com a célula livre. Confirma que cada operação chamada existe no recetor, que há uma ligação para o conhecer e que o estado permite a ação. Repete com a célula bloqueada.

Se o código guarda apenas Modelo, o desenho não deve mostrar uma dependência direta do controlador para todas as suas peças internas. Se o desenho e o código diferem, decide qual está correto para o contrato e corrige o outro. Um diagrama serve antes da implementação para discutir escolhas e depois para explicar o que ficou.