Anda di halaman 1dari 9

UML - Diagrama de Classes

terça-feira, 14 de setembro de 2010


23:16

• É o diagrama mais usado.


• Representa o conjunto de classes que o sistema vai possuir.
• Define o relacionamento entre classes.
• Pode ser usado para definir a modelagem de um Banco de Dados.

Exemplo de um diagrama de classe


Nome da classe No diagrama de classes o nome do elemento vem antes e posteriormente a definição do seu tipo.
Nem sempre são divididos em três partes. Podem somente ter uma parte (para somente descrição da
classe) ou duas (para definição somente dos atributos ou de seus métodos para não poluir o diagrama).
Atributos da classe

Métodos da classe

Visibilidade
Informa qual nível de acesso o elemento terá. Podendo ser:
- : Private
+: Public
#: Protect

Relacionamento
Serve para o compartilhamento de informações entre classes.
Colaboração entre elas para execução de diversos processos no sistema.
Associações, Agregações, Composição, Especialização/Generalização, Dependência e Realização são os tipos de relacionamento de classes.

Associação:
• Representa um vínculo entre uma ou mais classes.
• Pode ocorrer troca de informações, compartilhamento de métodos ou mesmo que uma instância de uma classe origine uma ou mais instâncias de outra classe.
• Podem possuir titulo para determinar o tipo de vinculo. Melhor compreensão na leitura deste diagrama.

Associação Unária:
uma classe se associa consigo mesma.

Na associação NÃO é obrigatório existir o vínculo no


relacionamento.

Na figura acima mostra-se que um Funcionário pode ser chefe e pode chefiar nenhum ou muitos funcionários na empresa.

Associação Binária: Associação Ternária ou N-ária:


Há um relacionamento entre duas classes. É o tipo de associação Há um relacionamento que contem mais de duas classes.
mais comum encontrado no diagrama de classes. Deve-se evitá-la se possível, pois sua compreensão as vezes se torna difícil.
Isto indica que para cada Pedido deve existir um ou mais
ItenPedido. E para cada ItenPedido deve existir um Pedido
associado.

Agregação:
-Utiliza

• Tipo especial de associação.


1..*

• Mostra um objeto-todo que se relaciona com objetos-parte.


• É obrigatória existir a relação quando o objeto-todo é criado.
• O objeto-todo precisa de um agregado para existir, um complemento.
• O objeto-parte pode existir sem o objeto-todo.

Composição:
• Um relacionamento com um vínculo mais forte que a agregação.
• É obrigatório existir o relacionamento quando o objeto todo é criado.
• O objeto-parte não existe sem o objeto todo.

Exemplo de Associação Binária, Agregação e Composição

Análise de Projetos Orientados a Objetos Page 1


Pedido
ItemPedido
-NroPedido: long 1..1 1..*
+DataPedido: date -QtdItem: double
+DataEntregaPedido: date Possui -ValUniItem: decimal

0..* 1..*

Desconto Compõe
0..1 1..1

Vale_Compra Produto
-Codigo: double -DsProd: string
-Valor: decimal -QtdProduto: double
-ValProduto: double

Descrição do diagrama acima:


1. Associação (Pedido - Vale_Compra):
a. No momento da criação do Pedido é possível vincular um Vale_Compra ao mesmo, podendo assim obter um desconto. Está relação não é obrigatória, e mesmo
quando existir, se o Pedido for cancelado o Vale_Compra vinculado terá seu valor restituído no total debitado. (no caso do cliente não precisar usar o valor integral do
Vale_Compra no Pedido). Podendo vincular este vale a outros pedidos.
2. Agregação(Produto - ItemPedido):
a. Quando é formado um item do pedido o mesmo tem que ser agregado por um produto. Está relação é obrigatória. Mas se caso o ItemPedido for excluído o produto
vinculado não será também.
3. Composição (Pedido - ItemPedido):
a. É uma relação mais forte. É obrigatória e se caso o objeto-todo (Pedido) for excluído, os objeto-parte serão também. Neste caso não pode ser agregado porque um
ItemPedido sempre estará amarrado com um Pedido e se seu Pedido é excluído não há motivo para ele existir também.

Especialização/Generalização: Dependência
É a herança entre classes. • É pouco usado no diagrama de classes.
• Mostra a dependência entre classes, ou seja, caso uma classe sofre modificações seus
dependentes também sofrerão modificações para se adequar ao novo formato.
Pessoa

-Nome: String
<PENDENTE>
-Nascimento: DateTime
-AntecedentesCriminais: Bool

+Comprar(produto: Produto): Bool


+toString(): String

Funcionario Cliente

-CPF: double +CNPJ: double


-Desconto: float

+Comprar(produto: Produto): Bool

Tanto funcionário como Cliente possuem os mesmos atributos e métodos de Pessoa. Realização
Entretanto, Funcionário possui um CPF enquanto que Cliente possui um CNPJ e o • É um relacionamento que mistura a Generalização e a dependência.
Funcionário pode comprar produtos da empresa com um desconto sendo um método • Representam dependências de classes para com interfaces.
com processos diferentes do que o Cliente.

No caso se houver alguma alteração em Animal (interface) haverá


alteração em Cachorro.

Referência

Análise de Projetos Orientados a Objetos Page 2


Análise de Projetos Orientados a Objetos Page 3
UML - Diagrama de Sequência
quinta-feira, 7 de outubro de 2010
22:53

Um Diagrama de sequência representa um Caso de Uso. Mas no


• Mostra a seqüência de eventos de determinado processo. entanto não existe, em absoluto, um Diagrama de Sequência para cada
Caso de Uso. Existe vários diagramas de Sequência num projeto, cada
• Mostra quais objetos se relacionam.
um representando um processo específico do sistema.
• Mostra quais métodos de determinado objeto são chamados.
• Mostra em que momento instanciamos um objeto e por quanto tempo ele fica disponível no processo.
• Determina restrições para que o processo não siga em frente.

Diagrama de Sequência

Elementos envolvidos:
1. Atores:
a. Podem ser pessoas ou sistemas que vão utilizar o software. São quem iniciam as chamadas a métodos(mensagens) para iniciar um processo.
2. Objetos:
a. São as variáveis instanciadas no processo.
b. São identificados por um retângulo com o nome do objeto em minúsculo e posteriormente o nome da classe com as iniciais em maiúsculo. Essas duas informações
são separadas por dois pontos(:).

Mensagens
Demonstram a ocorrência de um evento no processo.
Em geral o diagrama de seqüência é iniciado por um evento externo (ator) e assim é chamado um método do processo.
As mensagens podem ser:
1. Ator com Ator (menos comum)
2. Ator com objetos (mais comum)
3. Objeto com objeto
4. Objeto com ator - acontecendo muitas vezes pelo retorno da chamada.

Especificações:
• As mensagem são representadas retas horizontais por dois componentes envolvidos. São setas de linha contínua.
• A ordem seqüencial é mostrada de cima para baixo.
• São realizadas entre as linhas de vida dos objetos.
• O componente atrás da seta é o componente emissor da mensagem enquanto o componente onde a seta aponta o receptor da mensagem.
• A mensagem possuí uma pequena descrição do evento e o método chamado para realizar tal evento. Essas informações são separadas por dois pontos (:).

Exemplo de mensagem disparando um evento

Mensagens de retorno
O mesmo que as mensagens
É a resposta de um evento disparado por uma mensagem.
São representadas por uma reta (seta) com linha pontilhada.
Sua descrição pode conter somente o retorno do método ou uma pequena descrição do que foi realizado

Exemplo de mensagem de retorno

Análise de Projetos Orientados a Objetos Page 4


Linha de Vida
Representam o tempo que determinado objeto existiu no processo.
São representadas por linhas verticais tracejadas.
Quando o objeto é destruído há uma representação de um X no final da linha de vida.
Os objetos não precisam existir quando o processo é iniciado. Podem ser criados durante o processo.

Foco no controle ou Ativação


É o período do processo em que o objeto está ativo, ou seja, executando um ou
mais métodos. São representados na linha de vida do objeto com um retângulo .

Exemplo de Linha de Vida e Ativação

Referência

Análise de Projetos Orientados a Objetos Page 5


UML - Multiplicidade
segunda-feira, 11 de outubro de 2010
12:15

0..1 No mínimo zero(nenhum) e no máximo um. Indica que os objetos das classes associadas não precisam obrigatoriamente estar relacionados, mas se houver relacionamento indica
que apenas uma instância da classe relaciona-se com as instâncias da outra classe.
Ex: Um carro pode ter nenhum ou um rádio.
1..1 Um e somente um. Indica que apenas um objeto da classe relaciona-se com os objetos da outra classe.
Ex: Uma filho possuí um Pai. Uma Pessoa possuí um CPF.
* Muitos. Indica que muitos objetos da classe estão envolvidos no relacionamento.
1..* No mínimo um e no máximo muitos. Indica que há pelo menos um objeto envolvido no relacionamento, podendo haver muitos envolvidos.
Ex: Um Pedido tem que ter um ou mais produtos envolvidos.
Quando não há multiplicidade explícita entende-se por ser uma multiplicidade de um para um (1..1)
3..5 No mínimo três e no máximo cinco. Indica que existem pelo menos três instâncias envolvidas no relacionamento e que podem ser quatro ou cinco as instâncias envolvidas, mas não
mais do que isso.

Este último pertence ao infinito e foi colocado aqui somente para mostrar as várias possibilidades de formações de multiplicidade. O que poderia ser 4..5, 1..20 etc.
Em modelagem objeto relacional para construção de banco de dados o mesmo quer dizer cardinalidade.

Análise de Projetos Orientados a Objetos Page 6


UML - Diagrama de Caso de Uso
sábado, 16 de outubro de 2010
13:08

• Serve para descrever as ações necessárias para determinado evento. Essa descrição é formada para o usuário
(para seu entendimento), ou seja, precisa ser escrito de uma forma simples (linguagem informal).
• Pode-se usar pseudocódigo, ou mesmo, código de uma determinada linguagem de programação, mas isso
fugiria da simplicidade do diagrama.
• Usado na parte inicial do desenvolvimento. Criado na fase de análise de requisitos.
• Pode ser usado para demonstrar para o cliente o que o software irá fazer (cliente vai analisar se o sistema
possuí todas as funções que ele quer) e como o mesmo se comportará.
• Para demonstrações de software numa reunião com o cliente.
• Em reuniões ficará melhor com um protótipo do sistema para melhor entendimento. Um completará o outro.

Representação de Atores
Atores
• Elementos que interagem com o sistema.
• Pode ser: Pessoa, Hardware, outro sistema, etc.

Funcionário Módulo Oficina Servidor ABC

Casos de Uso Representação de Casos de Uso


• São tarefas, funções ou serviço do sistema.
• É um conjunto de eventos para realizar determinado objeto.
• Ex:
○ Pagar conta Pagar Conta Montar relatório vendas mês Cadastrar Produto
○ Cadastrar Produto
○ Montar relatório de vendas mês

Sempre usar uma breve descrição do caso de uso

– Associado a uma tela do sistema


– Associado a várias telas do sistema
– Associado a um evento de um botão do sistema por exemplo.

Associações
São os relacionamentos de: Existe vários tipos de associações, são elas:
 Ator -> Caso de Uso. 1. Associação Simples.
 Caso de Uso -> Ator. 2. Inclusão.
 Ator -> Ator (pouco utilizado). 3. Extensão.
 Caso de Uso -> Caso de Uso. 4. Especialização/Generalização.

Se há uma associação de um ator com um caso de uso quer dizer que o ator de alguma maneira, usa o
serviço ou tarefa específica do sistema.
As associações também podem informar se algum elemento herda características de um elemento
comum.

Associação Simples
> É o relacionamento de um Ator com caso de uso
> A representação é uma reta contínua entre estes elementos.
> Pode haver uma seta que informa a navegabilidade da informação, ou seja, para onde a informação
trafega neste relacionamento.
> Se não haver seta de navegabilidade quer dizer que a informação trafega para ambos os lados.

Exemplos

Usando protocolo UDP


Enviar Email Enviar vídeo streaming
Cadastrar Produto
Usuário Emissor Usuário Receptor Filmadora
Funcionário

Neste caso temos dois exemplos de navegação. O usuário emissor monta Neste caso o ator é um hardware está enviando sua filmagem via
Um funcionário faz o cadastro do produto (ele é o gatilho um email e o envia para o usuário receptor. Neste caso haverá mensagem streaming. Com o protocolo UDP não retorna se os pacotes
para iniciar o processo). de retorno para o usuário emissor caso a mensagem não seja entrega. chegaram ou não então a navegabilidade é somente uma.
Posteriormente aguarda o retorno de alguma informação Para o receptor só terá o recebimento da mensagem. • Aqui também vimos uma breve descrição desta associação.
para informar se o cadastro foi realizado com sucesso ou Neste caso é uma descrição mas também pode ser o tipo de
não. retorno de um caso de uso por exemplo.

Expecialização/Generalização
• É a herança que é paddo. Casos de uso comum são herdados por casos de uso especializados.
• Este tipo de associação também pode ser vista entre atores mas não é comum isto acontecer.
• Este método é útil para reaproveitamento de código.
• Sempre que perceber que há tarefas (Casos de Uso) ou características (Atores) semelhantes atribua um
elemento comum é faça a associação do tipo Generalização.

Exemplos

Análise de Projetos Orientados a Objetos Page 7


*

Usuario maior de idade * Acessar Site

Podemos ver que há funções semelhantes para comprar ingressos. Algumas Usuario

funções de 'Comprar Ingresso' é o mesmo que 'Comprar Ingresso Meia'. Mas *


para este há a criação de algumas restrições especiais, como por exemplo
mostra o documento de matricula da escola. O mesmo acontece com
'Comprar Ingresso Idoso'.
Usuário menor de idade

O site tem dois tipos de acesso. O normal para usuários maiores de


idade e o especial para usuário menores de idade. Por exemplo pode
ser que algumas áreas do site seja restrita para usuários menores de
idade.
Há características iguais para os dois tipos de usuário já que herdam
de 'usuário'. Por exemplo pode ser que para os dois seja necessário
Ter Nome, DataNascimento e CPF cadastrados.

Inclusão Exemplo:
Digamos que o sistema tenha uma regra de negócio que sempre que realizar um Caso de Uso 'Realizar
• Este tipo de associação é usada em Casos de Uso. Venda' seja necessário realizar um Caso de Uso 'Atualizar Estoque'.
• Faz com que a realização de um caso de uso obriga a realização de um outro.
• É representado por um reta pontilhada ou um estereótipo <<include>> com
uma seta apontando o caso de uso que será obrigado a ser realizado.
Vender
<<include>>

Atualizar Estoque
<<include>>
Funcionário

Estocar

Extensão Exemplo:
O Cliente está fazendo uma compra no site e no momento de finalizar a compra o cliente não está
• Tipo de associação usado em casos de uso. logado. O site direciona para o processo de login inicialmente.
• Indica cenários opcionais que caso uma condição verdadeira este possa ser
executado.
• A representação é feita por uma reta pontilhada ou contínua com o estereotipo
<<extend>>.
• Há uma seta que aponta o caso de uso que tem um caso de uso opcional que
pode ser realizado.

Análise de Projetos Orientados a Objetos Page 8


UML - Diagrama de Atividade
sábado, 16 de outubro de 2010
18:31

• É o diagrama que defini o fluxo de funcionamento de métodos.


• Determina o fluxo de controle de métodos.
• É como se fosse o fluxograma antigamente para definição dos sistemas.
• Descreve os passos de um método num sistema.
• Antes era junto com o diagrama de gráfico de estado mais na UML 2.0 passou a ser um diagrama
totalmente independente.

Componentes
São os mesmo do Diagrama Gráfico de Estado tais como: Estados Inicial e Final, Transições e Barras de Sincronização.

Estado de Ação Exemplo

• É uma ação do método.


• É atômico, não pode ser decomposto em subestados. Recebe Número da assinatura
• Não há funções internas no seu evento.
• Considera rápida e não pode ser interrompida.
• Dentro de uma atividade há diversos estado de ação.
• Para sua descrição pode possuir: Passar data para formato MM/dd/yyyy
○ Um texto informativo de sua atividade.
○ Pode estar em pseudocódigo.
○ Pode ser código de uma linguagem de programação.
• Sua representação é formada por um retângulo com suas bordas arredondadas.

Ponto de Decisão
• É o ponto do fluxo que terá uma condição e dependendo do resultado o fluxo irá executar um outro
fluxo com outro conjunto de estado de ação.
• É um decisão boleana, ou seja, há somente dois caminhos a seguir.

Procurar pedidos em aberto do cliente

[Não possui pedidos em aberto]


Emitir mensagem de que cliente não possui Pedidos em aberto

[Possui um ou mais pedidos em aberto]

Mostrar a lista de pedidos em aberto

Estado de SubAtividade
• São estados de atividade que possuem em seu interior mais funções.
• Usado quando não temos acesso a procedimentos internos de uma função ou a função já foi
documentada.

Classe: TelaSoma
Método: Somar

Declare Calculadora

Declare Calculadora

Recebe Nro1, Nro2

Classe Calculadora somar Nro1, Nro2 Estado de SubAtividade

Esta atividade mostra o uso da classe Calculadora. Como ela já foi diagramada não é necessário
refazer o diagrama então usamos um estado de SubAtividade.

Análise de Projetos Orientados a Objetos Page 9