Tópicos

• Visão Geral
• Diagrama de Atividades
• Diagrama de Comunicação
• Componente
• Diagrama de Estrutura Composta
• Diagrama de Seqüência

Visão Geral

Esta página descreve algumas diferenças entre UML 1.x e UML 2.0 que são relevantes para o contexto do RUP. A intenção não é abranger todas as especificações de infra-estrutura e superestrutura da UML ([UML04]), mas dar uma visão geral dos recursos relevantes da UML. Além disso, consulte [RUM05] e [ERI04] para obter informações adicionais.

Observe que "UML 1.x" refere-se às versões UML 1.0 até UML 1.5.

As alterações diagramáticas mais importantes no conjunto de recursos da UML 2.0 estão nos diagramas comportamentais, especificamente no diagrama de atividades e no conjunto de diagramas de interação (consulte Diagrama de Atividade, Diagrama de Seqüência e Diagrama de Comunicação a seguir).

Diagrama de Estrutura Composta e Classe Estruturada também são recursos novos da UML 2.0 (consulte Diagrama de Estrutura Composta a seguir).

Diagrama de Atividades

Introdução

A modelagem de atividades passou por uma revisão completa na UML 2.0. É oportuno dizer que, pelo menos para uso ocasional, o efeito e a aparência podem ser muito semelhantes e, embora dependam da formalidade da modelagem na UML 1.5 (e versões anteriores), é possível que a interpretação e a execução exatas resultantes de um modelo construído de acordo com as regras da UML 1.x não sejam as mesmas na UML 2.0. Por isso, cuidado com o modelador que, mesmo quando um modelo de atividade da UML 1.x pareça aceitável para a UML 2.0 sem alteração, pode não ser executado da mesma maneira, particularmente no caso de modelos mais complexos que envolvem coincidência. Consulte [UML04] para obter informações adicionais.

Conforme [UML04] a define, uma atividade (que será mostrada em um diagrama de atividades) é a especificação do comportamento conforme a seqüência coordenada de unidades subordinadas cujos elementos individuais são ações. Pode ser que tenhamos nos referido informalmente às etapas executáveis individuais em um diagrama de atividades da UML 1.x como atividades ou estados de atividade ou, corretamente, como estados de ação; agora essas etapas em uma atividade da UML 2.0 são chamadas ações, sendo que tais ações não são decompostas posteriormente na atividade. A conotação de estado desapareceu na UML 2.0 porque uma atividade não é mais um tipo de máquina de estado, como era na UML 1.x. Na UML 2.0, as atividades são compostas de nós, dos quais as ações são de um tipo; outras, descritas posteriormente a seguir, são nós de controle e nós de objeto.

Semântica de Fluxo

As atividades agora contam com a semântica semelhante à Petri Net, com base no fluxo de símbolo, onde a execução de um nó afeta a execução de outro, através de conexões diretas chamadas fluxos. Símbolos, contendo objetos ou um local de controle, fluem entre nós através dessas conexões. Um nó tem permissão para iniciar a execução quando as condições especificadas em seus símbolos de entrada são atendidas e, quando ele conclui a execução, oferece símbolos em seus fluxos de entrada, para que nós de recebimento de dados possam iniciar a execução. Os fluxos que conectam nós são posteriormente refinados em fluxos de controle e de dados ou objetos e, você poderá esperar, controlam os símbolos que se movem pelos fluxos de controle e os símbolos de objetos e dados são transmitidos pelos fluxos de objetos.

Isso difere da UML 1.x, na qual os nós eram estados (ou pseudo-estados) com transições entre eles, o que limitava a modelagem de fluxos.

Modelagem Simultânea

O recurso de modelagem da UML 2.0 permite um paralelismo irrestrito: enquanto na UML 1.x, a máquina de estado inteira (atividade) executava uma etapa de execução até a conclusão, o recurso na UML 2.0, em sua forma mais completa, permite múltiplas chamadas de uma atividade a ser tratada por uma única execução, com diversos fluxos de símbolos passando pelos nós e conectores de fluxo da atividade. Isso coloca a responsabilidade no modelador, que deve estar ciente das interações e condições do curso. Além disso, consulte a seção Diferenças Semânticas a seguir, para obter outro exemplo do efeito na modelagem de simultaneidade da semântica de fluxo de token.

Notação

Nós de Ação e Controle

O diagrama a seguir ilustra vários dos elementos da UML 2.0 e é apresentado da forma usual na UML 2.0, com um quadro retangular e um nome localizado em uma divisão na parte esquerda superior. Compare esse diagrama com a versão UML 1.x mostrada abaixo dele. Eles têm aparência semelhante (permitindo diferenciar a orientação e as convenções de cores utilizadas - não possuem significado semântico), e esse modelo tem o mesmo resultado de execução na UML 1.x e UML 2.0. Observe que os nós de controle - decisão, mesclagem, bifurcação, junção, inicial e final - são semelhantes a seus equivalentes na UML 1.x e os fluxos de controle são mostrados com uma linha indicadora, um visual comparável ao da seta de transição da UML 1.x.

Exemplo do diagrama de atividades da UML 2.0

Exemplo do diagrama de atividades da UML 1.x

A UML 2.0 possui um modo de controle adicional chamado Final de Fluxo (mostrado a seguir em um diagrama obtido da [UML04]) que é utilizado como uma alternativa ao nó Final de Atividade para finalizar um fluxo. É necessário porque, na UML 2.0, quando o controle alcança alguma instância do nó Final de Atividade, a atividade inteira (incluindo todos os fluxos) é finalizada. O Final de Fluxo simplesmente finaliza o fluxo ao qual está conectado. Isso não chegava a ser um problema na UML 1.5 por causa da semântica de execução até a conclusão mas, com o paralelismo irrestrito da UML 2.0, você pode não desejar a parada de todos os fluxos e a destruição de todos os símbolos.

Nó de controle de final de fluxo

Nós de Objeto

A modelagem de atividades da UML 2.0 suporta também nós de objetos. Um nó de objeto é um nó de atividade que indica que uma instância de determinado classificador, possivelmente em um estado específico, pode estar disponível em um ponto específico na atividade (por exemplo, como saída de ou entrada para uma ação). Nós de objeto agem como contêineres para objetos e a partir dos quais os objetos de um determinado tipo (e possivelmente em um determinado estado) podem fluir. Uma nova notação, denominada pino, foi introduzida para nós de objetos na UML 2.0. Os pinos representam entradas para uma ação ou saídas de uma ação e são desenhados como retângulos pequenos, anexados aos retângulos de ação, conforme mostrado a seguir.

Notação de pino

As setas representam os fluxos de objetos. Estas são linhas sólidas, ao contrário das linhas tracejadas utilizadas para transições de/para os estados de fluxo de objeto na UML 1.x. Quando o pino de saída em uma ação possui o mesmo nome do pino de entrada na ação conectada, os pinos de saída e entrada podem ser mesclados para oferecer um pino independente. Novamente, isso oferece um visual semelhante ao do fluxo de objetos na UML 1.x.

Notação de pino independente

Nós de Atividades Estruturadas

Um nó de atividades estruturadas é um nó de atividades executáveis que pode ser expandido para nós de atividades subordinados. Os nós subordinados pertencem a apenas um nó de atividades estruturadas, mas podem ser aninhados. Pode haver fluxos de controle conectados a ele e também pinos anexados. Um nó de atividades estruturado é desenhado como um retângulo tracejado, com cantos arredondados, envolvendo seus nós e fluxos, com a palavra-chave <<estruturado>> no topo.

Partições de Atividades

Uma partição de atividades é uma forma de agrupar os nós e fluxos de uma atividade, de acordo com alguma característica compartilhada. Na UML 1.x, a idéia de raias (consideradas partições) foi utilizada em diagramas de atividades para agrupar ações de acordo com alguns critérios, por exemplo, em modelagem de negócios, pela organização executora. A UML 2.0 estende esse recurso de particionamento a várias dimensões dos diagramas de atividades e fornece notação adicional para que, por exemplo, ações individuais possam ser rotuladas com o nome da partição à qual pertencem. O diagrama a seguir mostra um exemplo de raias multidimensionais conforme apareceriam na UML 2.0, onde as ações são agrupadas de acordo com o local e a responsabilidade.

Exemplo de partições de atividades utilizando raias bidimensionais

Diferenças Semânticas

A semântica de fluxo de símbolos e o paralelismo irrestrito dos modelos de atividades da UML 2.0 exigem que o modelador acostumado com a UML 1.x tenha cuidado ao construir novos modelos ou converter modelos existentes, assegurando-se de que o resultado da execução seja o planejado. Por exemplo, no exemplo processPassenger anterior, o passageiro no balcão do check-in poderia ser um passageiro freqüente; nesse caso, o agente precisa conceder a ele o prêmio do programa de milhas, conforme mostrado a seguir em um fragmento de modelo da UML 1.x.

Utilizando a transição simultânea protegida

Colocar a proteção na transição simultânea opcional significa que, na UML 1.x, a transição nunca é iniciada e o comportamento é como se a transição não fosse mostrada no modelo; conseqüentemente, quando as outras duas transições são concluídas, a execução continua após a união. Na UML 2.0, se o passageiro não é alguém que viaja freqüentemente, nenhum símbolo alcançará a junção paralela a esse fluxo e o modelo será paralisado porque a junção aguarda os símbolos em todos os seus fluxos antes de continuar. O modelo deve ser construído conforme mostrado a seguir, com a condição tratada da mesma maneira que no fluxo de tratamento de bagagem. É permitido colocar proteções diretamente nos fluxos simultâneos, desde que você esteja certo de que nenhuma junção de recebimento de dados dependa deles.

Utilizando nós de decisão e de mesclagem em vez do fluxo simultâneo protegido

Diagrama de Comunicação

O diagrama de colaboração da UML 1.x foi renomeado para diagrama de comunicação na UML 2.0. Não há diferenças semânticas das versões anteriores. O diagrama de comunicação tem como base o diagrama de colaboração antigo e ainda é um tipo de diagrama de interação.

Notação

O foco de um diagrama de comunicação está na interação entre as linhas de vida. É mostrado um gráfico cujos nós são retângulos que representam partes de uma classe estruturada ou funções de uma colaboração. Um quadro retangular em volta do diagrama com um nome em uma divisão no canto superior esquerdo é utilizado, o que representa uma alteração notacional das versões anteriores da UML.

• Os nós correspondem às linhas de vida em uma interação.
• Linhas entre as partes representam conectores que formam os caminhos de comunicação.
• Multiplicidades podem ser mostradas em conectores.
• Mensagens entre as partes são mostradas pelas setas rotuladas ao lado das linhas do conector.

Exemplo de um diagrama de comunicação:

Exemplo de Diagrama de Comunicação para um Sistema de Pedidos

Componente

Na UML 2.0, um componente é notado por um símbolo de classe sem os dois retângulos ressaltados, conforme definido na UML 1.4. Em seu lugar, um estereótipo de <<componente>> é utilizado. Como opção, um ícone de componente semelhante ao ícone da UML 1.4 pode ainda ser utilizado no canto superior direito do símbolo de componente.

A UML 2.0 define um componente como sendo uma classe estruturada, o que significa que a colaboração entre os elementos em sua estrutura interna (partes) pode ser modelada para melhor descrever seu comportamento. As partes são conectadas por seus conectores. Portas podem ser utilizadas para aumentar o nível de encapsulamento de um componente por meio de suas interfaces fornecidas e exigidas. Consulte Conceito: Componente e Conceito: Classe Estruturada, para obter informações adicionais.

Versões anteriores da UML definiam um elemento de modelagem especial chamado subsistema, que era modelado como um pacote com interface. Além disso, os componentes eram utilizados para estruturar o modelo na arquitetura física. Na UML 2.0, os componentes são utilizados em sentido amplo, em todas as partes do modelo. Assim, não há mais necessidade de um elemento especial para modelar subsistemas. Divisões separadas para realização e especificação de subsistemas na UML 1.x tornaram-se estereótipos separados (<<realização>> e <<especificação>>, respectivamente) aplicados aos componentes da UML 2.0. <<Subsistema>> é um outro estereótipo de componente novo, indicado para modelar componentes em grande escala.

O RUP sugere o uso de componentes para modelar subsistemas (consulte Diretriz: Subsistema de Design, para obter informações adicionais).

Diagrama de Estrutura Composta

As arquiteturas podem ter colaboração específica entre seus elementos, com peças e conectores não necessariamente conhecidos no momento do design. Um diagrama de classe típico (bem como outros diagramas estáticos) não seria suficiente para representar claramente as funções, responsabilidades, relações e regras aplicáveis a esses elementos.

Para tratar essas questões, a UML 2.0 incluiu o diagrama de estruturas compostas. Ele pode representar a estrutura interna de uma classe estruturada (por exemplo, componente ou classe), incluindo os pontos de interação da classe estruturada para outras partes do sistema. Esse diagrama mostra ainda a configuração das partes que conjuntamente executam o comportamento da classe estruturada que o contém.

Diagramas de Estrutura Composta são utilizados para delinear o conteúdo interno das Classes Estruturadas (consulte Conceito: Classe Estruturada, para obter detalhes e exemplos de Diagramas de Estrutura Composta).

Diagrama de Seqüência

A UML 2.0 possui vários novos recursos para diagramas de seqüência:

• Fragmentos fornecem uma semântica mais clara de como ocorre o comportamento em um diagrama de seqüência. Um fragmento combinado encapsula partes de um diagrama de seqüência, onde fluxos separados podem ser modelados, mostrando como as condições levam a caminhos alternativos de execução.
  
  
• As ocorrências de interação permitem a decomposição das interações em amostras reutilizáveis. É uma maneira útil de compartilhar partes de uma interação entre várias outras interações.
  
  
• Na UML 1.x, uma representação possível para loops era utilizar a condição de loop escrita em uma Nota. A Nota era anexada à mensagem ou ao conjunto de mensagens a serem executadas enquanto a condição de loop fosse verdadeira. Na UML 2.0, há uma representação específica para loops.
  
  
• Na UML 2.0, diagramas de seqüência podem mostrar como os objetos são criados e eliminados.
  
  
• Execução de Ocorrência mostra o foco de controle que um objeto executa em um determinado momento, quando recebe uma mensagem.

Com os novos recursos para representar fragmentos, ocorrências de interação e loops, os diagramas de seqüência podem ser utilizados de duas formas:

• Forma de instância: descreve um cenário específico detalhadamente, documentando uma interação possível, sem condições, ramificações ou loops. Essa forma é utilizada para representar um cenário de caso de uso. Cenários diferentes do mesmo caso de uso são representados em diagramas de seqüência diferentes. As ferramentas de modelagem que suportam a semântica da UML 1.x só permitem essa forma de representação.
  
  
• Forma genérica: descreve todas as alternativas possíveis de um cenário, aproveitando as vantagens dos novos recursos da UML 2.0, como condições, ramificações e loops. Essa forma pode ser utilizada para representar diversos cenários do mesmo caso de uso em um diagrama de seqüência exclusivo, no qual faça sentido.

A figura a seguir mostra um exemplo de diagrama de seqüência que modela cenários diferentes. O fragmento alt mostra duas alternativas possíveis de mensagens sendo seqüenciadas, dependendo de uma condição ser ou não satisfeita:

Exemplo: Diagrama de seqüência mostrando ramificações, loops e condições