UML - Diagrama de classes

Sem dúvida alguma o mais importante diagrama da UML, o seu objetivo principal é permitir a visualização das classes que comporão o sistema com seus respectivos métodos e atributos bem como em demonstrar como as classes do diagrama se relacionam, complementam e transmitem informações entre si.

O diagrama de classes serve como base para construir a maioria dos diagramas da UML pois ele é uma “visão” das estruturas das classes de forma simples.
Veja um exemplo da classe pessoa

E ai ? Entendeu? Sinceramente isso é intuitivo não acha? Para vc é que do contra vou explicar melhor; O nome “Pesso” é o nome da classe, os ‘Nome’ e ‘Sexo’ são os atributos da classe e o o ‘Falar(),Pensar()’ e etc são métodos, ou seja, funções dessa classe.
Ainda criamos a classe ‘Engenheiro’ que herda tudo que a classe Pessoa tem com um método a mais que é o ‘ganharDinheiro’ rsrs... tudo bem que se fosse a classe ‘Político brasileiro’ iriam existir mais método como ‘corrompimento’ e o valor recebido do ganharDinheiro seria um long double max plus alfa int mas não vamos entrar nesse mérito ok?

Persistência
O diagrama de classe foi interncionalmente projetado para ser uma evolução do MER (modelo entidade relacionamento) e pode ser utilizado para modelar a estrutura lógica das tabelas que comporão um banco de dados

Relacionamentos
As classes costumam possuir relacionamentos entre si, com o intuito de compartilhar informações e colaborarem afim de permitir a execução de seus processos.

Associações
Vínculo que ocorre entre duas classes, uma classe pode estar associada a si mesma, chamado de associação unária, ou uma mesma associação para várias classes que é chamada de ternária seu uso é muito raro e complexo.
A associação determina que uma instância de uma classe esteja de alguma forma ligadas a instâncias das outras classes envolvidas podendo haver troca de informações.

As associação são o mair próximo dos relacionamento utilizados no MER, ou seja, seu objetivo é definir como as classes estão unidas.





Veja um exemplo de associação;

Associação unária ou Reflexiva
Este tipo de associação ocorre quando existe um relacionamento de uma classe para consigo mesma. Um exemplo de associação unária pode ser observado abaixo;

Note que na classe acima temos o nome “Funcionário” com os atributos Codigo, Nome e Codigo do chefe. O chefe do funcionário também é, por sua vez, um funcionário da empresa e, portanto também se constitui em uma instância da classe Funcionário. Logo a associação chamada “Chefia” indica uma possível relação entre uma ou mais instâncias da classe Funcionário com outras instâncias da própria classe Funcionário, ou seja, esta associação determina que um funcionario pode ou não chefia outros funcionários.

Assim, é preciso existir uma associação da classe funcionário com ela mesma, o que força que a classe possua o atributo Codigo_Chefe para armazenar o código do funcionário que é responsável pela instância do funcionário em questão.

Percebam que existe outra informação na associação, além de seu próprio nome, representada pelo valor “0...*”, esta informação é conhecida como multiplicidade. A multiplicidade, ela é extremamente igual o conceito de cardinalidade no MER, pois procura determinar qual das classes envolvidas em uma associaçção fornece informações para as outras, além de permitir especificar o nível de dependência de uma classe para com as outras envolvidas na associação.

No classo da figura acuna a multiplicidade 0...* indica que um determinado funcionário pode chefiar nenhum (0) ou muitos (*) funcionários, ou seja, um funcipnário pode não chefiar ninguém ou pode chefiar um o mais funcionários. Pode-se perceber que só existe multiplicidade em uma das extremidades, po default, quando não existe multiplicidade explícita entende-se que a multiplicidade é “1...1” .

A tabela abaixo demonstra laguns dos diversos valores de multiplicidade que podem ser utilizados em uma associação :

Associação Binária
A mais utilizada ocorre quando são indentificados relacionamentos entre duas classes, veja um exemplo;

 

Simples n é? um Objeto da classe sócio pode possuir 0 ou vários dependentes.

O diagrama de classe ainda tem outros tipos de relação como Agregação e composição mas já que a idéia é explicar a UML de maneira mais rápida se eu continuar vou ficar até o mês que vem escrevendo. O importante é entender essa estrutura e depois(se achar interessante ir a fundo).

Obrigado e até a próxima.

UML - Diagrama de Caso de Uso

Agora chegou a hora de avaliar melhor, explicar a fundo e PRATICAR, afinal, só conseguimos aprender direito se treinarmos certo?

Hoje vamos falar a fundo sobre o Diagrama de Casos de Uso para alguns desenvolvedores, "engenheiros" e funções o caso de uso é tão genérico que fazer caso de uso é perda de tempo mas não é verdade o caso de uso apesar de genérico é uma "bússola" para entender o sistema.

O diagrama de Casos de Uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os diagramas da UML o mais abstrato e, portanto o mais fléxivel e informal. Ele costuma ser utilizado principalmente no início da modelagem do sistema, principalmente nas etapas de levantamento e Análise de Requisitos, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas.
Por mais abstrato que seja ele é de grande ajuda para auxiliar o engenheiro de software a dar um ‘rumo’ ao sistema.

Veja o nosso pequeno exemplo que mostra um caso de uso da funcionalidade de administrar novidades de um sistema:


Este diagrama tem por objetivo apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuários, sem se preocupar com como essas funções serão implementadas. O Diagrama de Casos de Uso é de grande auxílio na etapa de Análise de Requisitos, ajudando a especificar, visualizar e documentar as características, funções e serviços do sistema desejados pelo usuário. O Diagrama de Casos de Uso tenta identificar os tipos de usuários que irão interagir com o sistema, quais papéis esses usuários irão assumir e quais funções serão requisitadas por cada usuário específico.

Por utilizar uma linguagem informal e apresentar uma visão geral do comportamento do sistema a ser desenvolvido, o Diagrama de Casos de Uso pode e deve ser apresentado durante as reuniões iniciais com os clientes como uma forma de ilustrar o comportamento do sistema, facilitar a compreensão dos usuários e auxiliar na identificação de possíveis falhas de especificação é recomendado que junto com o caso de uso o cliente tenha acesso a um protótipo para que assim um complemente o outro.

Atores
O Diagrama de Casos de Uso concentra-se em dois itens principais: Atores e Casos de Uso. Os atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma maneira os serviços e funções do sistema; eventualmente um Ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Resumindo tudo isso que falei um Ator pode ser qualquer elemento externo que interaja com o sistema.
Os atores são representado por símbolos de bonecos que eu sei desenhar, é eu sei desenhar apenas aqueles bonequinhos de pauzinho sabe? Então, esses são os atores, em alguns livros e artigos os chamam de “bonecos magros” mas da na mesma pois pra mim são uns alienígenas veto rizados, rsrs.

E os casos de uso que refere-se aos serviços, tarefas ou funções que podem ser utilizados de alguma maneira pelos usuários do sistema, como emitir um relatório, cadastrar a venda de um produto qualquer, administrar usuários, emitir boleto bancário e etc... Os casos de uso são utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema.
Não existe regra para definir ao que se refere exatamente um caso de uso por exemplo, posso fazer um caso de uso que represente uma tela do sistema, ou uma ação especifica do usuário ou ainda várias ações, o indicado é criar algo que fique claro as funções do sistema por exemplo, veja esse diagrama de caso de uso para um modulo de novidades

Um usuário com uma ação “administra novidades” e nessa função existem várias ações. Para reforçar melhor a idéia do caso de uso ele basicamente oferece instruções gerais de como será seu funcionamento, quais atividades deverão ser executadas, qual eventos forçará sua execução, quais Atores os poderão utilizar, quais suas possíveis restrições entre outras.



Documentação de Casos de Uso
A documentação de um Caso de Uso costuma descrever por meio de uma linguagem bastante simples, a função em linhas gerais do Caso de Uso, quais Atores interagem com o mesmo, quais etapas devem ser executadas pelo Ator e pelo sistema para que o Caso de Uso execute sua função, quais parâmetros devem ser fornecidos e quais restrições e validações o Caso de Uso deve possuir.

No entanto, não existe um formato específico de documentação para Casos de Uso definido pela UML, o que está de acordo com a característica do próprio diagrama, ou seja, o formato de documentação de um Caso de Uso é bastante flexível, permitindo que se documente o caso de Uso da forma que se considerar melhor, até mesmo através do uso de pseudo-código ou da utilização do código de alguma linguagem de programação propriamente dita, embora isto fuja bastante do objetivo principal do Diagrama de Casos de Uso, que é utilizar uma linguagem simples que até mesmo usuários leigos possam entendê-la.

Por esse motivo não é recomendado utilizar pseudo-código na documentação de Casos de Uso, isto é mais adequado em outros diagramas como o Diagrama de Atividades, por exemplo.

Vamos mostrar um breve exemplo de Documentação de Caso de Uso do administrar novidades OK? Apenas para inserir novidade.

Documentação do Caso de Uso Inserir novidade

Nome do Caso de Uso	Inserir novidade
Caso de Uso Geral	Administar novidades
Ator principal	Usuario
Resumo	Este caso de uso descreve as etapas percorridas por um usuario para inserir uma novidade
Pré-condições	Ser um usuario do sistema com permissão para utilizar esse modulo
Ações do Ator	Ações do sistema
1. Preencher campos
	2. Receber dados de novidade
	3. Validar campos
	4. tratar imagem
6. definir tempo de transição dos slides
	7. Verificar se tempo é valido e registrar
Restrições/Validações	1. A imagem inserida deve ter extensão jpg, gif ou png. 2. Titulo e descrição são obrigatórios 3.  Titulo deve ter no máximo 90 caracteres 4. Descrição deve ter no máximo 160 caracteres 5. Não permitir tags html

A documentação em si parece ser bem simples mas devemos prestar atenção na parte que mostra Caso de Uso Geral e colocamos como valor Administrar novidades, isso acontece pq esse caso de uso é o Insere novidades que fica abaixo do Administrar novidades (veja na imagem), esse é chamado de caso de uso especializado que herda as características do Caso de uso geral.

O campo ator principal identifica o ator que mais interage com o Caso de Uso ou que está mais interessado nos resultados produzidos pelo mesmo. Ainda existe o Ator secundário que são aqueles que interagem em um nível menor com o Caso de Uso ou que não tem tanto interesse em seus resultados.Existe também o Resumo que apresenta um breve resumo explicando seu objetivo. Em seguida são descritas as possíveis pré-condições para que o Caso de Uso seja executado ou concluído, existe tambem as pós-condições, ou seja, tarefas que devem ser realizar depois que as etapas do Caso de Uso tiverem sido concluídas. Na documentação deste Caso de Uso as ações tomadas pelo Ator Usuario aparecem no lado esquerdo e as do sistema no lado direito. Em seguida, a documentação apresenta as ações realizadas quando o serviço representado pelo Caso de Uso for solicitado. As ações são divididas em ações realizadas pelo Ator que interage com o sistema e em ações realizadas pelo próprio sistema, numeradas em ordem sequencial. Finalmente é apresentada uam lista de possíveis restrições e validações do Caso de Uso, com o objetivo de tornar o processo mais consistente.

Alguns autores sugerem ainda o acréscimo de FLuxos Alternativos ou Cenários Alternativos, como uma maneira de prever ações que devem ser realizadas quando da ocorrência de possíveis exceções. Nestes casos deve-se determinar o FLuxo ou Cenário Principal que será normalmente executado e cada um dos possíveis fluxos ou cenários alternativos, dependendo do número de exceções que possam vir a ocorrer no Caso de Uso em questão.


Associações
As associações representam as interações ou relacionamentos entre os Atores que fazem parte do diagrama, entre os Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Os relacionamentos entre casos de uso recebem nomes especiais, como Inclusão, Extensão e Generalização. Todos esses relacionamento serão examinados aqui.

A associação entre um Ator e um Caso de Uso é representada por uma reta ligando o Ator ao Caso de Uso, podendo ocorrer que as extremidades da reta contenham setas, indicando a navegabilidade de Associação, o que demonstra o sentido em que as informações trafegam, ou seja, se estas são fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator ou ambos (neste ultimo caso a reta não possue setas demonstrando que as informações são transmitidas nas duas direções). Além disso uma associação pode possuir uma descrição própria, quando há necessidade de esclarecer a natureza da informação que está sendo transmitida, ou para das um nome à Associação, se isto for considerado necessário.

A imagem abaixo representa uma Associação entre um Ator e um Caso de Uso;


Examinando essa associação percebemos que o Ator Cliente utiliza, de alguma forma, o serviço Abertura de Conta, representado pelo Caso de Uso e que a informação referente a este processo trafega nas duas direções.


Especialização/Generalização

O relacionamento de Especialização/Generalização é uma forma de Associação entre Casos de Uso no qual existem dois o mais Casos de Uso com características semelhantes, apresentando pequenas diferenças entre si. Quando isso acontece definimos um Caso de Uso Geral que descreve as características compartilhadas por todos os Casos de Uso em questão e então relacioná-lo com os outros casos de uso envolvidos.
A associação de Generalização/Especialização é representada por uma reta com uma seta mais grossa, que indica qual o Caso de Uso Feral (para o qual a seta aponta) e quais os Casos de Uso Especializados(os que estão na outra extremidade da seta) veja um exemplo abaixo;

Embora não seja comum a especialização pode ser aplicada a atores tambem e funciona da mesma forma.

Inclusão
A Associação de Inclusão costuma ser utilizada quando existe um serviço, situação ou torina comum a mais de um Caso de Uso. Quando isso acontece, a documentação dessa rotina é mcolocada em um Caso de Uso específico para que outros Casos de Uso utilizem-se desse serviço, evitando-se descrever uma mesma sequência de passos em vários Casos de Uso.  Uma inclusão em um caso de uso comporta-se da mesma forma que uma chamada de função na programação. Uma associação de inmclusão é representada por uma reta tracejada contendo uma seta em uma de suas extremidades que aponta para o Caso de Uso incluído no caso de uso posicionado na outra extremidade da reta. As associações de inclusão costumam apresentar também um EStereótopo contendo o texto “include”, entre dois sinais de menor (<) e dois de maior (>). Os Estereotipos serão melhor detalhados em breve. Veja um exemplo de inclusão abaixo;



Nessa imagem percebemos que feito qualquer ação (Saque ou depósito) é necessário registrar o movimento.

Extensão
Associação de Extensão são utilizadas para descrever cenários opcionais de um Caso de Uso. Os Casos de uso estendidos descrevem cenários que somente ocorrerão em uma situação específica, se uma determinada condição for satisfeita.
As associações de Extensão indicam a necessidade de um teste para determinar se é necessário executar também o Caso de Uso estendido ou não. Relacionamentos de Extensão representam eventos que não ocorrem sempre, o que não significa que eles sejam incomuns. As associações de Extensão possuem uma representação semelhante a de inclusão, utilizando também a reta tracejada diferenciando-se pelo fato da seta apontar para o Caso de Uso que utiliza o Caso de Uso estendido e por possuir um Estereótipo contendo o texto “extend” ao invés de “include” a imagem abaixo representa muito bem uma extensão:

O certo no banco é que quando vc va cancelar a conta fique com saldo igual a zero ou seja, não esteja nem devendo para o banco e também não tenha dinheiro, então para encerrar a conta é necessário se o saldo positivo sacar o dinheiro e se negativo “pagar” depositar dinheiro.

 

UFÁ! Pensei que seria menor o caso de uso mas finalmente terminamos essa parte.

Bem no próximo post vamos falar de diagrama de classes, até la!

UML - Hierarquia dos diagramas

Agora que entendemos basicamente a utilidade de cada diagrama precisamos “ver por cima” o pq eles existem, precisamos de uma síntese geral para entender o pq de cada diagrama.

Os digramas da UML 2.0 dividem-se em DIagramas Estruturais e DIagramas Comportamenteis, sendo que estes últimos possuem ainda uma sub-divisão representada pelos DIagramas de Interação, conforme pode ser verificado abaixo:

 

É importante que vc clique da imagem e leia esse texto a seguir assim consegue ter uma visão melhor de tudo.

Conforme aparece na imagem os Diagramas Estruturais(Structure Diagram) abragem os Diagramas de Classes, Estrutura Composta, de objetos, de Componentes, de Implantação e de Pacotes, enquanto os Diagramas Comportamentais(Behavior Diagram) englobam os Diagramas de Casos de Uso, Atividade, Máquina de Estados, Sequência, Comunicação, de Interação Geral e de Tempo, sendo que estes últimos 4 correspondem aos diagramas da sub-divisão de Diagramas de Interação. Isso não significa que um é mais importante que o outro ou que é necessário fazer todos mas sim, significa entender que os diagramas em si são divididos em dois tipos que são os de estrutura e os de comportamento destinados claramente a atender esses objetivos que são entender a estrutura do sistema e como funcionam os comportamentos dele baseado em cada ação.

Um complementa o outro
O sentido de um complementa o outro é algo muito lógico mas atenção, não estou me referindo a minha namorada por exemplo que me completa (apesar de ela me completar infinitamente =]) mas sim ao fato de que conseguimos eliminar uma dúvida de comportamento ou de estrutura com o outro diagrama.

HEINN?? Eu sei eu sei que esse papo de diagramas e diagramas de UML é um saco mas vamos a um exemplo prático:

Estou fazendo um modulo no meu sistema que administra novidades que ficam em destaque no site, vamos imaginar em  o que o usuario pode fazer nesse módulo... para isso montamos inicialmente o Diagrama de caso de uso olha um exemplo:

Um exemplo simples com um Ator(Usuario) que administra novidades, dentro dessa administração existem um CRUD (Inserir,Excluir,Deletar) simples não é? Sim esse é o intuito do caso de uso enteder por cima o que acontece... mas e ai? COmo exatamente aconteceria esse processo? Será que estamos esquecendo de algo? Vamos fazer então um Diagrama de Atividade para o método que futuramente vai inserir a novidade e ficaria mais o menos assim:

Veja que aquele diagrama de caso de uso nos deu parametro para entendermos o que queremos e assim montar a sequencia de como será feito (utilizando o Diagrama de atividade). Meu intuito não é explicar aqui como fazer o caso de uso e mt menos o diagrama de atividade por isso não se preocupe em entender de fato os diagramas mas se preocupe  sim em saber que no final das contas um ajuda o outro. Futuramente vou explicar melhor como se faz cada um ok?


Programas para UML

Chegou uma hora interessante afinal, não vamos ficar desenhando os diagramas no caderno né? Ou ainda no paint,gimp photoshop isso iria dar muito trabalho... Vamos criar esses diagramas com programas próprios para isso, vou apresentar alguns aqui mas não vou entrar no mérito de explicar um a um pois são ferramentas visuais e seu uso é intuitivo.

Umbrello (para linux)
Esse é o programa que estou usando para criar os diagramas para esses artigos, particularmente acho ele muito simples e fácil de trabalhar alem de ser open-source e free, pode ser baixado facilmente nos repositórios do ubuntu basta fazer um sudo apt-get install umbrello e pronto, instalado. Acho que é importante deixar claro também que ele é muito limitado ok? Assim ninguém me xinga depois rsrs.
BOUML (para linux)
Esse é um mais completo que o Umbrello e de fácil utilização tambem, utilizei muito pouco mas achei ele muito bom para fazer engenharia reversa.
Para instalar esse carinha entre no seu central de programas e procure por ele, em um clique já estara em sua máquina.

Visual Paragigm (windows e linux)
Esse ja deixa a apresentação de lado pois é uma ferramenta case UML muito poderosa alem de ter versões para varios SOs... o problema é que é codigo fechado e pago mas é possível utilizar ele de graça com a sua veroa community basta baixar no site e fazer seu registro http://www.visual-paradigm.com/

Bem existem outros como Poseidon, Jude mas vou deixar que vcs procurem essa não é uma tarefa dificil e vc utiliza aquele que vc se identifica e pode ter.

Por hoje é só, no próximo post vou começar explicando o caso de uso onde vamos começar a modelar um pequeno sistema de noticias.

Obrigado e até a próxima.

UML - Diagramas

Bom dia! E como eu prometi hoje estou iniciando o segundo post sobre UML onde vou falar por cima um pouco sobre cada diagrama e nos outros posts explicar um a um com exemplos na prática...

Aliás, um feliz 2012 a todos, muita paz, saúde, sucesso e acima de tudo! CONHECIMENTO :]

Diagrama de casos de uso
Ele é o diagrama mais geral e informal da UML, sendo utilizado normalmente nas fases de Levantamento e Análise de Requisitos do sistema, e normalmente é sempre consultado duranto o processe de modelagem e serve como base para outros diagramas. Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma idéia geral de como o sistema irá se comportar.
Procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware especial), que utilizarão de alguma forma o software, bem como os serviços, ou seja, as opções, que o sistema disponibilizará aos atores, conhecidas neste diagrama como Casos de uso.

Um exemplo:

Diagrama de classes
O mais utilizado e o mais importante da UML, servindo de apoio para a maioria dos moutros diagramas. Como o próprio nome diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos possuídos por cada classe, além de estabelecer como as classes se relacionam e trocam informações entre si.

Diagrama de Objetos
Esta associado ao diagrama de classes. Na verdade, o Diagrama de Objetos é praticamente um complemento do Diagrama de Classes, sendo bastante dependente deste. O Diagrama de Objetos fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classes em um determinado momento da execução de um processo do software. Este foi um dos diagramas tornados independentes pela UML 2, apesar de já existir anteriormente, era considerado apenas uma extensão do Diagrama de Classes.

Diagrama de estrutura composta
Descreve a estrutura interna de um classificador, como uma classe ou component, detalhando as partes internas que o compõem, como estas se comunicam e colaboram entre si. Também é utilizado para descrever uma Colaboração onde um conjunto de instâncias coopéram entre si para realizar uma tarefa. Este é um dos três novos diagramas propostos pela UML 2.

Diagrama de sequencia
Preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo. Em geral, baseia-se em um Caso de Uso definido pelo diagrama de mesmo nome e apóia-se no Diagrama de Classes para determinar os objetos das classes envolvidas em um processo. Um Diagrama de Sequência costuma identificar o evento e determina como o processo deve se desenrolar e ser concluído por meio da chamada de métodos disparados por mensagens enviadas entre os objetos.

Diagrama de colaboração
Chamado de Diagrama de Comunicação na UML 2 esse diagrama está amplamente associado ao Diagrama de Sequencia, na verdade, um complementa o outro. As informações mostradas no Diagrama de Sequencia, porém com um enfoque diferente, visto que este diagrama não se preocupa com a temporalidade do processo, concentrando-se em como os objetos estão vinculados e quais as mensagens trocam entre si durante o processo.

Diagrama de Gráfico de Estados
Chamado de Diagrama de Máquina de Estados na UML 2 procura acompanhar as mudanças sofridas por um objeto dentro de um determinado processo. Como o Diagrama de Sequencia, o Diagrama de Máquina de estados muitas vezes baseia-se em um Caso de Uso descrito em um Diagrama de casos de uso e apoia=se no diagrama de classes. O diagrama de maquina de estados é utilizado normalmente para acompanhar os estados por que passa uma instancia de uma classe, no entanto pode ser utilizado para representar os estados de um caso de uso ou mesmo os estados gerais de um sub-sistema ou de um sistema completo.

Diagrama de atividades
O diagrama de atividades era considerado um caso especial do antigo Diagrama de Gráfico de EStados, atualmente conhecido como DIagrama de Máquina de Estados, conforme foi descrito na seção anterior. A partir da UML 2.0 o DIagrama de Atividades foi considerado independente do DIagrama de Máquina de EStados. Esse diagrama preocupa-se em descrever os passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes representada por um método com um cetro grau de complexidade e não de um processo completo como é o caso dos DIagramas de Sequencia ou Colaboração, embora também possa ser utilizado para este fim. O diagrama de Atividades concentra-se na representação do fluxo dle controle de uma atividade.

Diagrama de componentes
Esta amplamente associado à linguagem de programação que será utilizada para desenvolver o sistema modelado. Esse diagrama representa os componentes do sistema quando este for ser implementado em termos de módilos de código-fonte, bibliotecas, formulários, arquivos de ajuda, etc. e determina como esses componentes estarão estruturados e interagirão para que o sistema funcione de maneira adequada.

Diagrama de implantação
Determina as necessidades de hardware do sistema, as características físicas como servidores, estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado.

Diagrama de pacotes
Tem como objetivo representar os sub-sistemas englobados por um sistema de forma a determinar as partes que o compõem. Pode ser utilizado de maneira independente ou associado com outros diagramas.

Diagrama de interação geral
Uma variação do Diagrama de Atividades que fornece uma visão geral dentro de um sistema ou processo de negócio. Esse diagrama passou a existir somente a partir da UML 2

Diagrama de tempo
Descreve a mudança no estado ou condição de uma instância de uma classe ou seu papel durante um tempo. Tipicamente utilizada para demonstrar a mudança no estado de um objeto no tempo em resposta a eventos externos. Esse é o terceiro diagrama criado a partir da nove versão da linguagem.

continua...