UML - Apostila

Prof.
Ricardo Terra
O que UML?
UML (Unified Modeling Language) uma famlia de notaes grficas, apoiada por um metamodelo nico, que ajuda na descrio e no projeto de sistemas de software, particularmente daqueles construdos utilizando o estilo orientado a objetos (OO) Esta definio um tanto simplificada. Na verdade, para diferentes pessoas a UML tem significados diferentes As linguagens grficas de modelagem existem h muito tempo na indstria do software. O propulsor fundamental por trs de todas elas o fato das linguagens de programao no estarem em um nvel de abstrao suficiente alto para facilitar discusses sobre projeto
Tpicos Especiais em Informtica II - Prof. R. Terra
O que UML?
A UML um padro relativamente aberto, controlado pelo OMG (Object Management Group), um consrcio aberto de empresas. O OMG foi formado para estabelecer padres que suportassem interoperabilidade, especificamente de sistemas orientados a objetos. Talvez, o OMG seja mais conhecido pelo padres CORBA (Commom Object Request Broker Architecture) A UML nasceu da unificao das muitas linguagens grficas de modelagem orientadas a objetos
Diagramas UML
A UML 2.0 descreve 13 (treze) tipos de diagramas oficiais, indicando que 3 novos diagramas foram inseridos desde sua ltima verso Nosso foco na disciplina no exatamente ver todos, mas sim, aqueles mais comuns, so os diagramas mais utilizados: Atividades Classes Interao
Sequncia Colaborao
Caso de Uso (CDU)

Tpicos Especiais em Informtica II - Prof. R. Terra 4
Diagramas UML
Significado da UML
Um dos problemas difceis da UML que, embora a especificao descreva com bastante detalhe o que UML bemformada, ela no tem muito a dizer a respeito do que significa UML fora do mundo refinado dos metamodelos UML No existe nenhuma definio formal sobre como a UML mapeada para qualquer linguagem de programao especfica, isto , voc no v um diagrama UML e dizer exatamente qual seria o cdigo equivalente Na prtica, isto suficiente para ser til
Onde comear com UML?

Ningum, nem mesmo seus criadores, entende ou utiliza tudo que h na UML. A maioria das pessoas utiliza um pequeno subconjunto da UML e trabalha com isto. (FOWLER, 2005) Podemos pensar em UML como o processo de engenharia de software RUP. Ambos so muito grandes, todavia ningum o usa como um todo. As pessoas/empresas separam o que realmente acreditam que seja til e o utilizam
Referncia Bibliogrfica
FOWLER, Martin. UML Essencial. 3 ed. Porto Alegre: Bookman, 2005. PENDER, Tom. UML, a bblia. 2 reimp. Rio de Janeiro: Campus, 2004.
Prof. Ricardo Terra
Diagrama de Atividades
Os diagramas de atividades so uma tcnica para descrever lgica de procedimento, processo de negcio e fluxo de trabalho Se assemelha aos fluxogramas, mas a principal diferena o fato dos diagramas de atividades suportarem comportamento paralelo
Diagrama de Atividades
Um diagrama de atividades normalmente composto pelos seguintes elementos:
Atividade Transio Condio de guarda Deciso Ponto de merge Ponto de Incio Ponto de Fim Concorrncia
Bifurcao Sincronizao
Veremos um pouco de cada um desses

Atividades e transies
Uma atividade uma etapa em um processo, onde algum trabalho est sendo realizado A atividade representada por um retngulo arredondado, contendo texto em forma livre
Um diagrama de atividades uma srie de atividades ligadas por transies, que so setas conectando cada atividade Normalmente uma transio ocorre quando uma atividade concluda
Atividades e transies
Condio de Guarda
Em algumas situaes, a transio s deve ocorrer se determinada condio ocorra Uma condio de guarda pode ser atribuda com a inteno de restringir o uso daquela transio A condio de guarda uma condio dentro de conchetes em proximidade a seta de transio
Decises
Assim como no fluxograma, o losango do diagrama de atividades tambm representa um cone de deciso. Uma seta sai do losango para cada valor possvel da condio testada A condio pode ser simples (como um booleano) ou mais abrangente Cada opo identificada por meio de uma condio de guarda. Cada condio de guarda precisa ser mutuamente exclusiva, de modo que somente uma opo possa ser selecionada a partir da deciso
Decises
Ponto de merge
O cone de losando tambm usado para modelar um ponto de merge O ponto de merge um local onde dois caminhos alternativos se juntam e continuam como apenas 1 caminho
Ponto de Incio e de Fim

A UML tambm oferece cone para iniciar e terminar um diagrama de atividade
Um ponto slido indica o incio do fluxo de atividades Um olho de boi indica o ponto final
Somente deve existir um ponto de incio por diagrama de atividade Podem existir vrios pontos de fim. Se quiser pode apontar todas suas transies apontando para o mesmo ponto de fim, mas todos estes pontos de fim significam a mesma coisa: Parar todas as atividades do diagrama
10
Ponto de Incio e de Fim
11
Concorrncia
A notao admite concorrncia, que permite modelar os recursos das linguagens que foram criados aps a inveno do fluxograma. Estes recursos so conhecidos como threads ou processos concorrentes Para demostrar que um processo simples inicia vrios outros processos concorrentemente, o diagrama de atividades utiliza uma barra simples, chamada bifurcao
Cada transio de sada desta bifurcao uma nova thread
12
Concorrncia
Para a sincronizao de diversos processos paralelos utilizada a mesma barra, todavia agora conhecida como barra de sincronizao Nesta barra de sincronizao, chega diversos processos e sa apenas uma transio, que indica que o processamento concorrente acabou e o diagrama de atividades continua como uma nica thread ou processo
13
Concorrncia
14
Exemplo Completo
Ver pgina 119 do livro UML Essencial - 3 edio.
15
16
FOWLER, Martin. UML Essencial. 3 ed. Porto Alegre: Bookman, 2005. PENDER, Tom. UML, a bblia. 2 reimp. Rio de Janeiro: Campus, 2004.
17
Prof. Ricardo Terra
Casos de Uso
Os casos de uso so uma tcnica para captar os requisitos funcionais de um sistema. Eles servem para descrever as interaes tpicas entre os usurios de um sistema e o prprio sistema, fornecendo uma narrativa de como o sistema utilizado
Abordagem
Nossa abordagem neste estudo ser: Diagramas de casos de uso Narrativas de caso de uso
Narrativa de um caso de uso

No existe nenhuma maneira padronizada para escrever o contedo de um caso de uso e diferentes formatos funcionam bem em diferentes casos O slide a seguir mostra um estilo comum de uso. Voc comea escolhendo um dos cenrios como sendo o cenrio principal de sucesso (CPS). Da incio ao corpo do caso de uso escrevendo o CPS como uma seqncia de passos numerados. Ento, pega os outros cenrios e os escreve como extenses, descrevendoos em termos de variaes em relao ao cenrio principal de sucesso. As extenses podem ser bem-sucedidas o usurio atinge o objetivo, como em 3a ou falhas como em 6a
Narrativa de um caso de uso

Nome: Comprar produto. Pr-condies: Cliente com acesso a internet na pgina inicial do comrcio eletrnico. Cenrio Principal de Sucesso:
1. 2. 3. 4. 5. 6. 7. O cliente navega pelo catlogo e seleciona itens para comprar. O cliente vai para o caixa, isto , fecha o carrinho de compra. O cliente preenche formulrio de remessa (forma de pagamento; endereo da entrega; opo de entrega imediata ou em trs dias). O sistema apresenta a informao completa do faturamento, incluindo a remessa. O cliente autoriza a compra. O sistema confirma imediatamente a venda. O sistema envia uma confirmao para o cliente por e-mail.
Extenses: 3a. Cliente regular:

.1: .2: O sistema mostra a informao atual da remessa, a informao do preo e a informao de cobrana. O cliente pode aceitar ou escrever por cima desses padres, retornando ao CPS no passo 6.
6a. O sistema falha na autorizao de compra a crdito

.1: O cliente pode inserir novamente a informao do carto de crdito ou cancelar.
Ps-condies: Cliente finaliza sua compra.
Ver figura 9.1 da pgina 105 do livro UML Essencial 3 edio
Diagrama de Caso de Uso

Um diagrama de caso de uso normalmente composto pelos seguintes elementos:
Ator:
Um papel desempenhado por uma pessoa, sistema, dispositivo ou mesmo uma empresa, que possui interesse na operao bem-sucedida do sistema

Caso de Uso
Identifica um comportamento-chave do sistema. Sem esse comportamento, o sistema no preencher os requisitos do ator. Cada caso de uso expressa um objetivo que o sistema precisa alcanar e/ou um resultado que ele precisa produzir

Associao
Identifica uma relao entre atores e casos de usos. Cada associao torna-se um dilogo que deve ser explicado em uma narrativa de caso de uso. Cada narrativa oferece um conjunto de cenrios como j foi visto anteriormente
Ver figura 12.12 e 12.13 das pginas 320-321 do livro UML, a Bblia.

Relacionamento include (incluso)
Identifica um caso de uso reutilizvel, que incorporado incondicionalmente na execuo de outro caso de uso. A responsabilidade pela deciso sobre quando e por que usar o caso de uso includo encontra-se no caso de uso que o chama
Ver figura 12.14 da pgina 322 do livro UML, a Bblia.

Relacionamento extend (extenso)
Identifica um caso de uso reutilizvel, que interrompe condicionalmente a execuo de outro caso de uso para aumentar sua funcionalidade. A responsabilidade por decidir quando o caso de uso estendendo deve ser usado encontra-se com o caso de uso estendendo
10

extend X include
Include Aumentam o comportamento do caso de uso bsico. O caso de uso includo sempre utilizado. A seta do relacionamento desenhado do caso de uso em execuo para o caso de uso includo. A seta do relacionamento indica que o caso de uso bsico direciona o caso de uso includo para a execuo. O caso de uso de extenso pode ser usado. A seta do relacionamento desenhada do caso de uso de extenso para o caso de uso em execuo. A seta indica que o caso de uso de extenso est tomando a deciso se dever interromper o caso de uso em execuo. Extend
11

Generalizao
Identifica um relacionamento de herana entre atores.
12
Diagrama de Caso de Uso Exemplo
13

Como construir um diagrama de Caso de Uso (PENDER): 1. Definir o contexto do sistema: 1. Identificar atores e suas responsabilidades. 2. Identificar os casos de uso, os comportamentos do sistema, em termos de objetivos especficos e/ou resultados que precisam ser produzidos. 2. Avaliar os atores e casos de uso para encontrar oportunidades de refinamento, como diviso ou merge de definies. 3. Avaliar os casos de uso para encontrar relacionamentos do tipo include. 4. Avaliar os casos de uso para encontrar relacionamentos do tipo extend. 5. Avaliar os atores para oportunidades de generalizao (propriedades compartilhadas)

Como construir um diagrama de Caso de Uso (FOWLER): Embora o diagrama de Caso de Uso s vezes seja til, ele no obrigatrio. Em seu trabalho com casos de uso, no se esmere muito no diagrama. Em vez disto, concentre-se na narrativa (contedo textual) do caso de uso. A melhor maneira de pensar em um diagrama de caso de uso como um sumrio grfico do conjunto de casos de uso. O diagrama de casos de uso mostra os atores, os casos de uso e os relacionamentos entre eles.
Quais atores realizam quais casos de uso? Quais casos de uso incluem outros casos de uso?
A UML inclui outros relacionamentos entre os casos de uso, alm da incluso e da extenso, mas no necessrio nos aprofundarmos a este ponto.
15
FOWLER, Martin. UML Essencial. 3 ed. Porto Alegre: Bookman, 2005. PENDER, Tom. UML, a Bblia. 2 reimp. Rio de Janeiro: Campus, 2004.
16
Prof. Ricardo Terra
Diferenciao entre classe e objeto

As classes formam o alicerce do diagrama de classes. Assim, para trabalhar com diagrama de classes, voc precisa ter uma noo clara da diferena entre classes e objetos. Portanto:
Classe a definio para um recurso. Ela inclui informaes que descrevem os recursos de uma entidade e como ela pode ser utilizada. Objetos, ao contrrio, so instncias de uma classe. Pode-se dizer que um objeto uma entidade identificvel de forma exclusiva de acordo com as regras definidas pela classe.
Diagrama de Classes
Se algum chegar perto de voc em um beco escuro e disser: Psiu, quer ver um diagrama UML:, esse provavelmente seria um diagrama de classes. A maioria dos diagramas UML que vejo composta por diagrama de classes. (FOWLER, 2005) O diagrama de classes provavelmente o diagrama mais utilizado da UML. Na verdade, o diagrama de classes a ferramenta de modelagem principal para descrever a prpria UML. (PENDER, 2004)
Diagrama de Classes
Um diagrama de classes descreve os tipos de objetos presentes no sistema e os vrios tipos de relacionamento estticos existentes entre eles. Os diagramas de classe tambm mostram as propriedades e operaes de uma classe e as restries que se aplicam maneira como os objetos esto conectados.
Classe
Uma classe uma descrio de um conjunto de objetos que partilham os mesmos atributos, operaes, relaes e semntica. Por exemplo, na classe Cliente, "Joo da Silva" pode ser considerado um dos objetos num sistema que pretende manipular informao referente aos clientes de uma empresa.
Classe
Uma classe descrita por seus aspectos estruturais atravs de seus atributos e atravs de seus aspectos comportamentais atravs de suas operaes. Uma classe (seus atributos e operaes) pode ser detalhada atravs de sua visibilidade e sua multiplicidade. Uma classe representada como mostrado no desenho abaixo:
Operaes e Atributos de uma Classe

Uma classe definida nos seus aspectos estruturais atravs de seus atributos e nos seus aspectos comportamentais atravs de suas operaes. Uma classe no tem necessariamente que corresponder a uma entidade humana ou, mais genericamente, a uma entidade com representao fsica (por exemplo, uma fatura).
Pode-se representar entidades mais abstratas (por exemplo, venda).
Atributos de uma Classe

Atributo da classe
So propriedades semelhantes que os objetos de uma classe possuem. O "Joo da Silva" alm do nome, tambm caracterizado por outros atributos, como endereo, nmero do contribuinte, cpf, rg, etc. Cada atributo permite definir um intervalo de valores que as instncias dessa propriedade podem apresentar. Meu carro branco, o seu preto.
Essas propriedades de carro so descritas pelo atributo cor.
Atributos de uma Classe

Tanto nos atributos quanto nas operaes de uma classe podem ser especificados detalhes de sua visibilidade e de sua multiplicidade. A sintaxe bsica de um atributo :
[visibilidade] nome-do-atributo : [tipo] { =valor-inicial }
Exemplos:
+ nome : String
- salario : double = 1000.00 # nota : int
Operaes de uma Classe

Operaes da Classe
O Joo da Silva possui uma identidade prpria, isto , para a empresa, ele distinto de todos os outros clientes. Essa identidade no s descrita pelos atributos. Todos os objetos de uma classe podem fazer alguma coisa (um servio) ou pode-se fazer com ele alguma coisa. As operaes so responsveis pela efetivao dos servios prestados pelas classes. Sobre o cliente "Joo da Silva" pode-se efetuar vrias operaes como emitir-lhe faturas, alterar seu endereo, apag-lo da base de dados, entre outras.
10
Operaes de uma Classe

A sintaxe bsica de uma operao :
[visibilidade] nome-da-operao ( [lista-de-parmetros] ) : [tipo-retorno]
Exemplos:
- mostrar() : void
+ calcularTaxa( valorDolar : double ) : double # somar (a : int , b: int) : int
11
Operaes e Atributos Estticos

Uma operao ou um atributo que no pertence a uma instncia da classe, mas a classe como um todo chamado de operao e atributo esttico, respectivamente. Operaes e atributos estticos so compartilhados por todas as instncias da classe, mas no pertence a nenhuma instncia.
12
Visibilidade
Os atributos e operaes de uma classe podem ser especificados para mostrar como a mesma pode ser vista e utilizada pelos outros elementos do sistema. Os nveis de visibilidade para o atributo ou a operao: (+) PBLICO:
Todas as classes visualizam.
(-) PRIVADO:
Somente a prpria classe visualiza.
(#) PROTEGIDO:
Todas as classes do mesmo pacote e sub-classes visualizam.
(~) PACOTE:
Todas as classes do mesmo pacote visualizam.
13
Visibilidade
Exemplo:
Somente a prpria classe tem acesso direto aos atributos do veculo. Qualquer classe pode ligar ou desligar o veculo. Somente classes do mesmo pacote ou sub-classes podem acelerar ou frear o veculo. Somente a prpria classe pode ativar o ABS. Somente classes do mesmo pacote podem ver o consumo do veculo.
Associao
Outra maneira de se criar um atributo atravs de uma associao. Associao uma linha cheia entre duas classes, direcionadas da classe de origem para a classe de destino. A direo pode ser nos dois sentidos, o que gera uma Associao Bidirecional.
Exemplo:
Este exemplo indica que um objeto NotaFiscal possui pelo menos um objeto ItemNotaFiscal.
Associao
Ainda no exemplo:
Como pode ser visto no deve-se colocar uma associao como atributo, pois a prpria associao j nos diz isto. O cdigo Java ficaria assim: public class NotaFiscal { private List listaItemNotaFiscal; ... } public class ItemNotaFiscal { private NotaFiscal notaFiscal; ... }
16
Classes Associativas
Algumas associaes de muitos para muitos exige a necessidade da criao de uma classe associativa entre as duas classes associadas. No exemplo abaixo existe a classe Paciente com seus atributos e a classe Exame com seus atributos. Do relacionamento entre Paciente e Exame tm-se a data da realizao e o diagnstico. Observe:
17
Multiplicidade
A multiplicidade de uma classe o nmero de instncias possveis que uma classe pode ter considerando uma nica instncia da outra classe a qual ela associada. Ou seja, o nmero de objetos de uma classe que pode relacionar com um nico objeto de uma outra classe. Multiplicidades so nmeros simples ou intervalos de nmeros. A tabela abaixo exemplifica os tipos comuns de multiplicidades.
0..1 1 0..* 1..* Uma instncia opcional. Exatamente uma instncia. Zero ou mais instncias. Pelo menos uma instncia.
18
Multiplicidade
No exemplo abaixo, um pedido pode estar vinculado a um nico cliente, porm um cliente poder possuir qualquer quantidade de pedidos.
E estes?
19
Dependncia
Uma dependncia entre dois elementos existe se mudanas na definio de um elemento podem causar mudanas ao outro. A simbologia adotada uma linha tracejada ligando um elemento ao outro elemento o qual ele depende.
No exemplo acima, a classe de formulrio do funcionrio depende da classe de funcionrio.

Agregao Tipo de associao

As agregaes so um caso especial das associaes. Uma agregao modela um relacionamento tem um (ou parte de, no jargo da UML) entre pares. Este relacionamento significa que um objeto contm outro. No contexto de uma agregao, os objetos podem existir independentemente uns dos outros. Nenhum objeto mais importante do que o outro no relacionamento. Um losango aberto simboliza a agregao. O losango toca o objeto que considerado o todo do relacionamento. O todo constitudo de partes.
Agregao Tipo de associao

Como o Banco e Cliente so independentes, eles so pares. Voc pode dizer que o objeto Banco e o objeto Cliente so pares, porque os objetos Cliente podem existir independentemente do objeto Banco. Isso significa que se o objeto Banco encerrar suas operaes, os clientes no desaparecero com o banco. Em vez disso, os clientes podem se tornar clientes de outro banco. Do mesmo modo o cliente pode sacar seus fundos e o banco continuar.
22
Composio Tipo de associao

As composies so um caso especial das associaes de agregao. Elas representam a noo de composio e apenas tm sentido em associaes um para muitos e, mais raramente, em associaes muitos para muitos. Enquanto que nas associaes anteriormente referidas no existem classes mais importantes, nas agregaes existe uma classe (supra classe) que representa a agregao dos objetos da outra classe (sub classe).
23

A ttulo de exemplo, considere-se os itens (linhas) de uma fatura. Usualmente uma fatura (ou pode ser) composta por vrios itens, cada um deles diz respeito a um produto faturado. Os itens tm seus prprios atributos (quantidade, preo unitrio, descrio do produto, etc.) e entidade prpria ( possvel distinguir um item de outro na mesma fatura). Uma possvel representao deste domnio o diagrama do prximo slide. Uma fatura possui vrios itens, mas um item apenas diz respeito a uma fatura. Uma composio tem um losango fechado apontando para a parte contendo o todo.
24
importante observar que os itens existem apenas enquanto existir a fatura da qual fazem parte. Dito de outra forma, uma fatura uma composio de itens. Se removermos uma fatura, os itens dessa fatura tambm sero removidos. Neste caso temos um tipo de agregao conhecido como Composio.
Uma composio representa uma relao mais forte entre o objeto agregador e os objetos componentes.
Generalizao
Trata-se da ao de uma classe herdar toda a estrutura de uma outra classe.
Uma sub-classe sempre herda de sua super-classe:
Atributos Operaes Relacionamentos
Uma sub-classe pode:

Adicionar atributos e operaes Adicionar relacionamentos Sobrepr (override) operaes herdadas
Uma sub-classe sempre herda tudo de sua super-classe, isto , no tem como herdar somente alguns atributos ou operaes.
Generalizao
Exemplo:
ContaCorrente um tipo de Conta. ContaPoupanca um tipo de Conta.
27
Interfaces
Uma interface uma coleo de operaes que so usadas para especificar um servio de uma classe. Graficamente, uma interface representada como um crculo (forma icnica). Toda interface deve ter um nome que a distingue de outras interfaces.
Forma Icnica:
28
Interfaces
Uma interface pode tambm ser representada como um esteretipo (forma expandida).
Forma Expandida:
Neste caso, possvel visualizar as operaes permitidas na interface.
29
Interfaces
Uma interface especifica um contrato de servio para uma classe, sem detalhar como ser sua implementao. No exemplo a seguir, IPreco especifica esse contrato e a classe Pedido responsvel pela sua realizao. Podemos definir uma interface a qual nomearemos de IPreco (a letra 'I' foi usada para permitir identificao como sendo uma interface).
30
Interfaces
A interface IPreco prov um contrato de definio de preo para a classe Pedido. A classe Pedido, a qual realiza, isto , prov a implementao concreta da interface IPreco, contm um relacionamento chamado realizao. Neste caso, note que a classe Cliente depende da interface IPreco.
31
Realizao
Uma realizao indica que uma classe comportamento especificado por uma interface.
Uma interface pode ser realizada por vrias classes. Uma classe pode realizar diversas interfaces.
implementa
32
Classes Abstratas
Em alguns momentos deseja criar uma classe sem a implementao de algumas operaes ou, simplesmente, no deseja que exista uma instncia de determinada classe. Para dizer que uma classe abstrata, basta inserir seu nome em itlico.
No exemplo ao lado, no teria como dizer que tem uma instncia de Conta, mas sim, somente uma instncia de uma de suas sub-classes: - ContaCorrente - ContaPoupanca
33
Regras de Restries
Restries agregam condies entre associaes, atributos, operaes e classes. Restries so restries semnticas anotadas como expresses booleanas.
UML oferece vrias restries pr-definidas.
34
Pacotes
Um pacote um mecanismo de agrupamento. Pode ser utilizado para agrupar qualquer elemento UML (como casos de uso, atores, classes, componentes e outros pacotes). Geralmente utizada para especificar uma distribuio lgica.
35
Pacotes
Os pacotes em um diagrama de classes so altamente utilizados, pois, na implementao do sistema, a organizao das classes so sempre feitas utilizando pacotes.
36
Notas e Comentrios
Assim como todo diagrama UML pode ser inseridos notas ou comentrios.
37
Cuidado
Diagrama de Classes no um modelo ER. O maior perigo com os diagramas de classes que voc pode focalizar exclusivamente na estrutura e ignorar o comportamento.
38
39
UML Diagrama de Interao

Prof. Ricardo Terra
Diagramas de Interao
Os diagramas de interao mostram como os objetos interagem uns com os outros. Permitem assim modelar os aspectos dinmicos de um sistema. Existem dois tipos de diagramas de interao: Diagrama de Seqncia Diagrama de Colaborao O diagrama de colaborao pode ser usado para mostrar como os objetos em um sistema interagem sobre mltiplos casos de uso . Por outro lado, um diagrama de seqncia tipicamente usado para mostrar a interao de objetos em um nico caso de uso.
Objeto da Classe
Objeto de Classe uma instncia de uma classe, isto , uma manifestao concreta de algo abstrato.
No exemplo acima, existe a definio da classe Carro e dois objetos desta classe.
Mensagens

Uma mensagem a remessa de um sinal ou a chamada de uma operao de um objeto (o emissor) para um ou mais objetos (receptor). A mensagem o elemento principal do diagrama de interao.
Uma mensagem representada graficamente como uma seta (do emissor ao receptor), acima do qual pode-se colocar um nome (geralmente o nome da operao) e um nmero de sequncia.
No exemplo acima, o objeto emissor (:Motorista) invoca o mtodo ligar do objeto receptor (:Carro).
Mensagens
Existem diversos tipos de mensagens, tais como mensagem sncronas (mais usadas), asscronas, de retorno, auto-referncia e temporizada, observe a diferena entre elas.
Seta
Tipo
Sncrona Assncrona
Descrio
Envio de mensagens sncronas. uma mensagem que no bloqueia o emissor. Isto , o emissor e o receptor executam concorrentemente. Indica o retorno do controle aps uma nova mensagem ter sido enviada Usada quando um objeto necessita enviar uma mensagem para ele mesmo. Indica que a mensagem enviada possui tempo de vida.
Retorno
Autoreferncia Temporizada
Diagrama de Seqncia
O diagrama de seqncia, como um dos dois tipos de diagrama de interao, mostra a interao existente num conjunto de objetos e seus relacionamentos, dando nfase ordenao temporal de mensagens. Nesse diagrama, colocam-se os objetos de classes que participam de interao no topo (eixo X), o objeto que inicia a interao colocado mais esquerda e os demais vo sendo colocados direita. As mensagens trocadas so dispostas ao longo do eixo dos Y, de acordo com os vnculos entre os objetos da classe, e em ordem crescente do tempo. Os diagramas de sequncia diferenciam dos diagramas colaborao por apresentar linhas de vida e barras de ativao. de
Linhas de Vida
Linhas de vida so linhas verticais tracejadas que indicam a existncia do objeto no tempo.
Recomenda-se que todos os objetos a serem utilizados sejam inseridos j no incio do diagrama com sua respectiva linha de vida, observe:
Barras de Ativao
Barras de ativao representam o tempo que um objeto necessita para completar uma tarefa. As barras mostram o tempo em que objeto est ativo.
As barras de ativao so representadas graficamente por um retngulo alto e estreito, colocado no eixo Y, sobre as linhas de vida dos objetos.
Observe exemplo no prximo slide.
Diagrama de Sequncia
Diagrama de Colaborao
O diagrama de colaborao, como um dos dois tipos de diagrama de interao, mostra a interao existente num conjunto de objetos e seus relacionamentos, dando nfase organizao estrutural dos objetos. O diagrama mostra os objetos das classes que participam da interao, mostrando os vnculos entre os mesmos, descrevendo as mensagens que os objetos recebem e enviam. Os diagramas de colaborao diferenciam-se dos diagramas de seqncias nestes aspectos:

Existe um caminho que indica como o objeto est vinculado a outro. Existe um nmero de seqncia para indicar a ordem temporal de uma mensagem.
No diagrama de seqncia altamente recomendado, mas opcional.
10
Diagrama de Colaborao
11
12

UML - Apostila

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UML - Apostila

Încărcat de

Drepturi de autor:

Formate disponibile

Prof.

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Caso de Uso (CDU)

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Onde comear com UML?

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Prof. Ricardo Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Veremos um pouco de cada um desses

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Ponto de Incio e de Fim

Tpicos Especiais em Informtica II - Prof. R. Terra

Ponto de Incio e de Fim

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Prof. Ricardo Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Narrativa de um caso de uso

Tpicos Especiais em Informtica II - Prof. R. Terra

Narrativa de um caso de uso

Extenses: 3a. Cliente regular:

6a. O sistema falha na autorizao de compra a crdito

Ps-condies: Cliente finaliza sua compra.

Ver figura 9.1 da pgina 105 do livro UML Essencial 3 edio

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Ver figura 12.14 da pgina 322 do livro UML, a Bblia.

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Ver figura 12.15 da pgina 323 do livro UML, a Bblia.

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso Exemplo

Ver figura 12.4 da pgina 314 do livro UML, a Bblia.

Tpicos Especiais em Informtica II - Prof. R. Terra

Diagrama de Caso de Uso

Diagrama de Caso de Uso

Tpicos Especiais em Informtica II - Prof. R. Terra

Tpicos Especiais em Informtica II - Prof. R. Terra

Prof. Ricardo Terra

Diferenciao entre classe e objeto