unified modeling language uml

Prof. Msc. Emerson Silas Dória 1

Unified Modeling LanguageUML

Notações BásicasReferência: UML Resource Center


Introdução

A UML é uma linguagem gráfica para visualização, especificação, construção e documentação de artefatos que façam uso de sistemas complexos de software.

Adequada para modelar: sistemas de informação corporativos distribuídos; aplicações baseadas em WEB; e até sistemas complexos embutidos de tempo real.


Modelo Conceitual da UML

Para compreender a UML é preciso formar um modelo conceitual da linguagem e isso pressupõe aprender três elementos principais:

Blocos de construção básicos Regras que determinam como esses

blocos poderão ser combinados Mecanismos comuns aplicados na UML


Blocos de Construção

O vocabulário da UML abrange 3 tipos de blocos de construção: Itens; Relacionamentos; e Diagramas

Os itens são abstrações, os relacionamentos reúnem esses itens; os diagramas agrupam coleções interessantes de itens.


Itens

Existem 4 tipos de itens na UML: Itens Estruturais: partes mais estática do

modelo (substantivos)

Itens Comportamentais: partes dinâmica (verbos)

Itens de Agrupamento: partes organizacionais dos modelos da UML (pacotes)

Itens de Anotações: partes explicativas dos modelos da UML (notas)


Itens

Itens Estruturais: partes mais estática do modelo (substantivos)

+origin#sizeopen()close()move()display()

Window

ISpelling

DigitalizarRetina

Cadeia deResponsabilidade

originsize

Window

orderform.java

Servidor


Itens

Itens Comportamentais: partes dinâmica (verbos)

IdlekeepAlive/Check

ConnectingConnected

onHook

Working

Off

offHook / reclaimConnection()

ready(3) [signalOK]

t:Thread :Tookit

a1:run(3)

run()<<create>

> p:Peer

handleExpose

<<destroy>>


Itens

Itens de Agrupamento: partes organizacionais dos modelos da UML (pacotes)

Itens de Anotações: partes explicativas dos modelos da UML (notas)

Business rules

Consider the use of the broker design

pattern here


Relacionamentos

Existem 4 tipos de relacionamentos na UML: Dependência

Associação

Generalização

Realização


Relacionamentos

Dependência: é um relacionamento semântico entre dois itens, em que uma modificação em um item poderá afetar a semântica de outro item

AgendaDeCursos

remover(c:Curso)adicionar(c:Curso)

Curso

Dependência (Agenda de Cursos depende de Curso)

Quando excluir um

Curso, retirar da

agenda.


Relacionamentos

Associação: é um relacionamento estrutural que especifica que os objetos de um item estão conectados a objetos de um outro item. Existem quatro tipos básicos de adornos a serem aplicados às associações (nome, papel, multiplicidade, agregação).

fornece

associação

nomedireção do nome

ProdutoFornecedor 1 1..*

multiplicidade


Relacionamentos

Associação

EmpresaPessoafuncionário

associação

nome do papel

empregador


Relacionamentos

Associação

DepartamentoEmpresa1 *

agregação (relacionamento tipo fraco)

partetodo

composição

DepartamentoEmpresa1 *

Composição: relacionamento forte do tipo “é parte de “. A composição entre um elemento (o “todo”) e outros elementos (“as partes”) indica que as partes só podem pertencer ao “todo” e são criadas e destruídas com ele.


Relacionamentos

PessoaEmpresa * 1..*

descriçãodtadmissãosalário

Serviço

Associação: Existem outros tipos de adornos a serem aplicados às associações (ex: classe de associação).


Relacionamentos

Outro exemplo de classe de associação

Estudante Prova0..*1..*

data

faz

nota


Relacionamentos

Generalização: é um relacionamento de especialização/generalização, nos quais os objetos dos elementos especializados (filhos) são substituíveis por objetos do elemento generalizado (pais).Ativos

adicionar(...)remover(...) generalização

Conta Corrente Imóveis Seguridade


Relacionamentos

Realização: É um relacionamento semântico entre classificadores, em que um classificador especifica um contrato que outro classificador garante executar. É utilizado: no contexto de interfaces e no contexto de colaborações em casos de usos.

Enviar PedidoCrédito

Cliente

Detectar Fraude Cartão

ValidarTransação

GerenciarPedido

GerarConta

<<interface>>

IAgentedaRegra

AdicionarRegra()

AlterarRegra()

ExplicarRegra()

RegrasDeContabilidade


Extensibilidade

A UML oferece três mecanismos para a extensão da sintaxe e da semântica da linguagem, são eles: Estereótipos

Valores atribuídos

Restrições


Extensibilidade

<<container>>

ActionQueue

{version=3.2}

add(a:Action)

remove(n: Integer)

<<query>>

length():Integer

<<helper functions>>

reorder()

estereótipo

valor atribuído

restrição

{add runs in O(1) time}


ExtensibilidadeEstereótipos

Um estereótipo é um mecanismo de extensão introduzido pela UML, que permite que o usuário estenda o meta-modelo para suprir necessidades que não encontram-se definidas entre os elementos dos diagramas.A apresentação geral de um estereótipo é o nome do estereótipo colocado entre os símbolos << >>.Um estereótipo geralmente é aplicado a classes, relacionamentos de dependência, atributos e operações.Exemplo: <<abstract>> aplicado a uma classe indica que a classe não pode ter objetos, é uma classe que nunca deve ser instanciada.


ExtensibilidadeEstereótipos - Exemplos

Cliente

Clientes

adicionar(...)remover(...)

<<ator>>Clientes

adicionar(...)remove(...)


ExtensibilidadeEstereótipos - Exemplos

{versão=3.2 autor= tec}

Overflow

<<exceção>>Fila

adicionar( )remover( )

{ordenado}

Veículo

<<abstrato>>


Valor atribuído: permite atribuir um tipo particular de propriedade a um ou vários blocos de construção. {valor atribuído = valor}

Exemplo {valor > 100} = exemplo de uma pré-condição para a execução de um método

ExtensibilidadeValores atribuídos


ExtensibilidadeValores atribuídos - Exemplos

{versão=3.2 autor= tec}

Fila


Servidor{processadores =

3}


Restrição: é uma relação semântica entre elementos do modelo. Especifica condições ou proposições que devem ser mantidas verdadeirasUma restrição é mostrada como uma cadeia entre chaves {}

ExtensibilidadeRestrições

Fila


{ordenado}


ExtensibilidadeRestrições - Exemplos

Contrato de Seguros

Pessoa Empresa

{or}0..*

1..* 1..*


Diagramas

Um diagrama é uma apresentação gráfica de um conjunto de elementos com objetivo de visualizar um sistema sob diferentes perspectivas. Diagrama de Classes

Diagrama de Objetos

Diagrama de Casos de Uso

Diagrama de Seqüência

Diagrama de Colaboração

Diagrama de Estados

Diagrama de Atividades

Diagrama de Componentes

Diagrama de Implantação


Diagrama de ClassesPedido

IncluirPedido(...)AtenderPedido(...)

Cliente+CódigoCliente-LimiteCredito

ItensPedido#quantidade

IncluirItemPedido(...)CalcularTotal(...)

*

1

Produto

Produto Automotivo Produto Agrícola Produto Híbrido

Pessoa

Empresa{ou}

EmpresaCliente


A sintaxe padrão de um atributo é:

visibilidade nome : tipo = valor_inicial

{string de propriedade}

onde visibilidade é:

+ visibilidade pública# visibilidade protegida- visibilidade privada

+ valor: Real+ data: Date = data atual+ cliente: String- num_faturas: Integer = 0+ status: String = nãopago {nãopago, pago}

Fatura

Diagrama de Classes


A sintaxe da operação é:

visibilidade nome (lista_parâmetros):tipo_do_retorno {string de propriedade} na qual lista_parâmetros é um lista de

parâmetros formais separados por vírgula, cada um especificado segundo sintaxe: nome : tipo = valor_padrão

Diagrama de Classes

+ desenhar ( )+ escala (percentual:integer=25)- pos_retorno( ):position

Figura


Exemplos


Diagramas

Um diagrama é uma apresentação gráfica de um conjunto de elementos com objetivo de visualizar um sistema sob diferentes perspectivas.

Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados

Diagrama de Atividade




Diagrama de ObjetosAutor

nome: String idade: Integer

Computador

nome: Stringmemória:Integer

Usa

0..1 1..*

Diagrama deClasses

Bob: Autor

nome: “Bob J.” idade: 32

PC Profissional deBob: Computador

nome: “Pent. III” memória: 64 Diagrama de

ObjetosPC Doméstico deBob: Computador

nome: “CompaqPentium MMX”

memória: 32


Diagrama de Objetos

objeto

c: Companhia

d2: Departamento

nome = "RH"

d1: Departamento

nome = "Vendas"

p:Pessoa

nome = "Eric"cod = "4362"cargo = "Chefe de

: Informações Adicionais

endereço = "Rua St. Inacio, 1472"

valor do atributo

objeto anônimogerente

vinculo


Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados






Ator 1

Caso de Uso

A

Ator 2

Nome do Sistema

Fronteira doSistema

Caso de Uso

C

Caso de Uso

B

Associação



Casos de Uso podem ser organizados pela especificação de relacionamentos de: Generalização Inclusão <<include>> Extensão <<extend>>


Diagrama de Casos de UsoGeneralização entre Atores

Grupos gerais de atores especializados, utilizando o relacionamento de generalização.

Cliente

Cliente Comercial

Cliente Industrial

Cliente PessoaFísica


Outra forma de representar a generalização.

Cliente

ClienteComercial

ClienteIndustrial

Cliente PessoaFísica

Diagrama de Casos de UsoGeneralização entre Atores


O caso de uso filho herda o comportamento e o significado do caso de uso pai.

Diagrama de Casos de UsoGeneralização entre Casos de Uso

ValidarUsuário

DigitalizarRetina

ChecarSenha


Um relacionamento include de um caso de uso A para um caso de uso B indica que uma instância de A inclui o comportamento especificado por B. Esse tipo de associação é útil para evitar a repetição de um fluxo de eventos várias vezes. Essa associação é mostrada com um relacionamento de dependência e acrescentando o estereótipo << include>>.

Diagrama de Casos de UsoInclusão


<<include>>

Diagrama de Casos de UsoExemplo de Inclusão

ValidarUsuário

DigitalizarRetina

ChecarSenha

SacarDinheiro


Um relacionamento extends de um caso de uso A para um caso de uso B indica que uma instância de B pode usar o comportamento especificado por A.É um tipo de associação usada para a modelagem da parte de um caso de uso que é opcional (não é obrigatório) para o sistema ou uma parte do caso de uso que só é executada sob determinadas condições.Essa associação é mostrada com um relacionamento de dependência e acrescentando o estereótipo << extend>>.

Diagrama de Casos de UsoExtensão


Cliente

Diagrama de Casos de UsoExemplos de Extensão

<<include>>

ValidarUsuário

DigitalizarDigital

ChecarSenha

Sacar Dinheiroponto de extensão

Informar Saldo Insuficiente<<extend>>

CadastrarVenda

CadastrarCliente

<<extend>>


Cliente Individual Cliente Juridico

Reconciliar as transações

Cliente

Realizar transação com cartão

Instituição de venda a varejo

Gerenciar a conta do cliente

Instituição financeira patrocinadora

Processa a conta do cliente

Sistema de Validação de Cartão de Crédito

Exemplos


Rede Celular

Uso programadoUsuário

Fazer ligação de conferenciaFazer ligação

Receber ligação adicionalReceber ligação

<<extend>>

<<extend>>

Telefone Celular

Exemplos

Prof. Msc. Emerson Silas Dória 48Negócio com Limites Excedidos

Avaliar Negócio

Vendedor

Analisar Riscos

<<include>>

Fechar Preço

<<include>>

Analista Comercial

Registrar Negócio

Gerente Comercial

Estabelecer LimitesSistema de

Contabilidade

Atualizar ContasExemplos


Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados





Diagramas de Interação

Um DI mostra uma interação formada por um conjunto de objetos e seus relacionamentos, incluindo mensagens que podem ser trocadas entre eles;Um Diagrama de Seqüência é um DI que dá ênfase à ordenação temporal das mensagens;Um Diagrama de Colaboração é um DI que dá ênfase à organização estrutural dos objetos que enviam e recebem mensagens;


Diagramas de Interação

Os Diagramas de Seqüências têm duas características que os diferenciam dos diagramas de colaboração: Existe linha de vida do objeto Existe o foco de controle

Os Diagramas de Colaboração têm duas características que os diferenciam dos diagramas de seqüência: Existe o caminho Existe o número de seqüência


Diagrama de SeqüênciaIlustra a ordenação temporal das mensagens

c:Client p:ODBCProxy

:Transaction<<create>>

X

setActions(a,b,o)setValues(d,3.4)

setValues(a, “CO”)

committed

<<destroy>>

linha de vida

foco de controle

tempo

objetos


Simples = não descreve detalhes da mensagem por não ser importante neste momento ou por não se saber os pormenores da comunicação.Síncrona = mensagem para chamada de operação, a próxima mensagem só é executada quando esta for concluída.Assíncrona = serve para envio de mensagem sem nenhuma espera, ou seja, a próxima mensagem pode ser executada antes que esta termine.

Diagrama de SeqüênciaTipos de Mensagens

Simples Síncrona Assíncrona


c:Cliente

:Agente Viagem

p: Assistente de Planejamento

<<create>>

definir_Itinerário(i)

estabelecer_rota( )

rota

notificar( )

<<destroy>>


X


Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados





Diagrama de ColaboraçãoIlustra organização estrutural dos objetos que enviam e recebem mensagens

:Vendat:obter_total( )

2:st:=obter_subtotal( )

1*:[para cada]iv:next( )

2.1:p:=obter_preço( )

iv:ItemVenda

:EspecificaçãoProduto

iv:ItemVendaordem damensagem


Diagrama de ColaboraçãoSintaxe da Mensagem

número_seqüência{[pré-condição] * [iteração]:valor_retorno:=}assinatura número_seqüência: ordem na qual a

mensagem será executada. pré-condição: pré-condição para a execução

do método. iteração: execução iterativa da mensagem

ex.: 1.1*[x=1..10]:façaAlgo()

valor_retorno: variável que receberá o valor retornado pela mensagem

assinatura: chamada do método com os seus devidos argumentos


Objetos criados durante a execução podem ser designados pelo estereótipo << new >>

Objetos destruídos durante a execução podem ser designados por << destroyed >>

Objetos criados e destruídos durante a execução podem ser designados por << transient >>



Existem algumas ações padrão em UML:Call = Invoca uma operação em um objetos, o objeto poderá enviar uma mensagem a si mesmo, resultando em uma chamada local de uma operaçãoReturn= Retorna um valor para quem o solicitouSend= Envia um sinal para um objetoCreate= Cria um objetoDestroy= Destrói um objeto, o objetos poderá se destruir.



Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados





Diagrama de EstadosUm diagrama de estado representa o ciclo de vida de um objeto. Para isso ele mostra os estados que um objeto pode ter, como os eventos afetam estes estados e como o objeto reage a estes eventos.

Um estado é uma condição ou situação na vida de um objeto durante a qual ele: satisfaz alguma condição, executa alguma atividade ou espera algum evento.

Um evento é uma especificação de uma ocorrência significativa que tem uma localização no tempo e no espaço. No contexto de DE é uma ocorrência de um estímulo capaz de ativar uma transição de estados.


Diagrama de EstadosUma transição é um relacionamento entre dois estados, indicando que um objeto no primeiro estado realizará certas ações e entrará no segundo estado quando um evento especificado ocorrer e as condições especificadas estiverem satisfeitas.

Uma atividade é uma execução não-atômica em andamento em uma máquina de estados.

Uma ação é uma computação atômica executável que resulta e uma alteração do estado do modelo ou no retorno de um valor.


Diagrama de Estados

A sintaxe do rótulo de uma transição é:EventoDeAtivação(Parâmetros)[CondiçãoDeProteção]/Ação

EventoDeAtivação: O evento cuja recepção pelo objeto no estado de origem faz com que a transição possa ser escolhida para ser ativada, desde de que a CondiçãoDeProteção seja satisfeita;

Ação: Uma computação atômica executável que poderá agir diretamente no objeto ao qual a máquina pertence e indiretamente em outros objetos que são visíveis ao objeto.


Um estado pode ser refinado em subestados concorrentes (ortogonais) usando relacionamentos ou em subestados seqüenciais (disjuntos mutuamente exclusivos) usando relacionamentos.

Um dado estado pode ser refinado em apenas uma das duas formas. Estes subestados podem ser novamente refinados, de uma forma ou de outra.

Diagrama de Estados


Diagrama de EstadosExemplo – Subestados seqüenciais

Idle

Maintenance

maintain

Validating

Selecting

Printing

Processing

cancel

cardInserted

Active

[not continue]

entry / readCardexit / ejectCard

[continue]

estado composto

subestado seqüencial

transição desubestado

transição para/deestado composto


Diagrama de EstadosExemplo – Subestados concorrentes

subestadosconcorrentesIdle

TestingDevices

cancel

cardInserted

Maintenance

Testing

bifurcação

SelfDiagnosis

Waiting Command

Commanding

[not continue]keyPress

[continue]

união


Diagrama de EstadosModelando uma classe: item bibliográfico

inserir_item_completo

Criado

InseridoExcluído

create

destruir

excluir_IB

alterar_IBprocurar_item

selecionar_IB

inserir_item_incompleto


registrarPagamentocomDinheiro

Esperando por Venda Entrando Itens

Esperando por Pagamento

entrarItem

terminarVenda

entrarItem

Autorizando Pagamento

tratarResposta registrarPagamentocomCartãodeCrédito

registrarPagamentocomCheque

Diagrama de EstadosExemplos


Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados





Diagrama de AtividadeUm DA é um caso especial de uma máquina de estados, em que todos ou a maioria dos estados são estados de atividades e em que todas ou a maioria das transições são ativadas pela conclusão de atividades no estado de origem:

Estado de Atividade: Execução de atividade com evento implícito na sua terminação para ativar a transição de saída;

Estado de Espera/Ação: Computações atômicas executáveis, pode ocorrer evento externo mas o trabalho não é interrompido.

Enquanto um DI observa os objetos que trocam mensagens, um DA observa as operações passadas entre os objetos;


Diagrama de AtividadeUm DA representa o estado de execução do método, ou seja, o estado do objeto que executa o método, em contrapartida aos DI.



fazer trabalho local

fazer trabalho em outros setores

[rejeitado]

[senão]ramificação seqüencial

bifurcação concorrente

união concorrente

estado de ação

contratar arquiteto

selecionar local

desenvolver plano

concluir construção

orçar plano

estado inicial

estado final


solicitar produto

processar pedido

separar materiais

enviar pedido

receber pedido cobrar cliente

pagar cobrança

fechar pedido

Cliente Vendas Estoque

Raia de natação


Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados






Os Diagramas de Componentes são um dos dois tipos de diagramas disponíveis para a modelagem de aspectos físicos de sistemas orientados a objetos (modelagem arquitetural), ele mostra a organização e as dependências existentes entre um conjunto de componentes.

São empregados para a modelagem da visão estática de implementação do sistema, que envolve a modelagem de itens físicos que residem em um nó, como executáveis, bibliotecas, tabelas, arquivos e documentos.



Um componente é uma parte física do sistema. Muitas vezes um componente mostra um arquivo específico do sistema.


Diagrama de ComponentesUsos Comuns - Código-fonte do Sistema


Diagrama de ComponentesUsos Comuns – Versão Executável


Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados






Os Diagramas de Implantação são um dos dois tipos de diagramas disponíveis para a modelagem de aspectos físicos de sistemas orientados a objetos (modelagem arquitetural), ele mostra a configuração dos nós de processamento em tempo de execução e os componentes que nele existem.

Eles são empregados para a modelagem da visão estática da implantação do sistema. Na maior parte, isso envolve a modelagem da topologia do hardware em que o sistema é executado.



2..*

<<processor>>

caching serverDeployshttp.exerting.exe

serversclients

4..*

<<processor>>

serverDeploysdbadimin.exe

logexe.exe

console

kiosk


Diagramas


Diagrama de Classes

Diagrama de Objetos




Diagrama de Estados





Bibliografia

Booch, Grady; Rumbaugh, James. UML – Guia do Usuário; Rio de Janeiro, Campus, 2000.

Furlan, José Davi. Modelagem de Objetos através da UML; São Paulo, Makron Books, 1998.

Larman, Graig; Utilizando UML e Padrões; Porto Alegre, Bookman, 2000.

unified modeling language uml

Documents