Você está na página 1de 28

Usando UML para Especificação de Sistemas Orientados a Objetos

Prof. Rodrigo Quites Reis

Fevereiro, 2003

quites@computer.org

http://www.inf.ufrgs.br/~quites

Usando UML para Especificação de Sistemas Orientados a Objetos

Modelagem de Objetos com UML

Autoria: Rodrigo Quites Reis

Última atualização: fevereiro/2000

Nenhuma parte desta apostila pode ser utilizada ou reproduzida, em qualquer meio ou forma, seja mecânico ou eletrônico, fotocópia, gravação, ou outros, sem autorização, prévia, expressa e específica do Autor.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

SUMÁRIO

1 INTRODUÇÃO

4

2 DIAGRAMAS DE CASOS DE USO (USE CASES)

5

2.1 Caso de Uso

5

2.2 Interação em caso de uso

6

2.3 Exemplos de casos de uso

8

2.3.1 Caixa eletrônico

8

2.3.2 Telefone celular

8

2.3.3 Sistema de Vendas [TOG00]

9

3 DIAGRAMA DE CLASSES EM UML

10

3.1 Classes e seus relacionamentos 10

3.2 Associações Simples 11

3.3 Multiplicidade (Cardinalidade) 13

3.4 Classes Associativas

14

3.5 Qualificador

15

3.6 Agregação

16

3.7 Navegabilidade

18

3.8 Generalização/Especialização 18

19

3.10 Estudo de Caso 20

3.9

Restrições

4 DIAGRAMAS DE INTERAÇÃO

21

4.1 Diagrama de Seqüência

22

4.2 Diagrama de Colaboração

24

5 ESTUDOS DE CASO E EXERCÍCIOS

27

5.1 Estudo de Caso 1: Locadora de Veículos

27

5.2 Estudo de Caso 2: Hospital

27

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

1

INTRODUÇÃO

O presente texto tem como objetivo apresentar uma visão geral das técnicas de modelagem de sistemas orientados a objetos chamada UML – Unified Modelling Language. Atualmente, UML consiste na principal linguagem para descrição de sistemas O.O., tendo sido definida como padrão do OMG 1 em 1997.

Apesar deste não se propor a substituir qualquer um dos livros clássicos escritos nesta área, o objetivo deste texto é o de complementar as atividades realizadas em sala de aula, proporcionado uma visão geral dos conceitos de modelagem com UML. Além disso, somente os modelos UML mais importantes são apresentados, deixando de lado aqueles que possuem sua aplicação condicionada a sistemas com características específicas.

1 OMG = Object Management Group. Organismo internacional para definição de padrões da orientação a objetos.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

2 DIAGRAMAS DE CASOS DE USO (USE CASES)

Os diagramas de caso de uso fornecem um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição de usuário.

A modelagem de caso de uso é uma técnica utilizada para descrever a funcionalidade

de um sistema através de atores externos interagindo em casos de uso. Atores representam um papel e iniciam o caso de uso que, por sua vez, deve entregar um valor tangível de retorno ao ator. Atores e casos de uso estão conectados através de associações e podem ter relacionamentos de generalização que descreva o comportamento comum em superclasses herdadas por uma ou mais subclasses especializadas.

A modelagem de casos de uso é utilizada para capturar necessidades de um novo

sistema ou acrescentar novas necessidades para criar uma nova versão. Neste sentido, a nova funcionalidade é adicionada ao contexto do modelo de caso de uso através da inserção de novos atores e casos.

Os objetivos principais de um diagrama de caso de uso são:

Descrever os requisitos funcionais do sistema de maneira uniforme para usuários e desenvolvedores;

Descrever de forma clara e consistente as responsabilidades a serem cumpridas pelo sistema, formando a base para a fase de projeto;

Oferecer as possíveis situações do mundo real para a fase de testes do sistema.

Um diagrama de caso de uso é um gráfico de atores, um conjunto de casos incluído por um limite de domínio, comunicação, participação e associações entre atores, assim como generalizações entre casos de uso. Os elementos básicos de um diagrama de caso de uso são:

ator, caso de uso, interação e sistema, todos ilustrados na figura a seguir.

Sistema Caso de uso 1 AtorAtor
Sistema
Caso de uso 1
AtorAtor

Figura 1. Componentes de um diagrama de caso de uso.

2.1 Caso de Uso

Cada caso de uso é uma seqüência completa de cenários de interação mostrando

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

como eventos externos iniciais são respondidos no caso. Um cenário é uma narrativa de uma parte do comportamento global do sistema e uma coleção completa de cenários é usada para especificar completamente um sistema. Um caso de uso está para um cenário assim como uma classe está para um objeto. Ou seja, um caso de uso representa uma declaração de um aspecto de comportamento que é caracterizado por um lote de cenários concretos.

Um ator é uma entidade externa ao sistema que de alguma forma participa de um caso de uso. Um ator estimula o sistema com eventos externos e tipicamente recebe algo do sistema. Um ator pode ser um ser humano, máquinas, dispositivos, ou outros sistemas. Atores típicos incluem, por exemplo, clientes, usuários, gerentes, computadores e impressoras.

2.2 Interação em caso de uso

O ator comunica-se com o sistema através do envio e recebimento de mensagens, sendo que um caso de uso é sempre iniciado a partir do momento em que o ator envia sua mensagem (estímulo). As seguintes interações são importantes dentro de um diagrama de caso de uso:

Comunicação: Um ator comunica-se com o caso de uso, tal como no exemplo da Figura 2;

TelefoneTelefone CelularCelular Fazer ligação Usuário A comunicação é representada através de um arco simples
TelefoneTelefone CelularCelular
Fazer ligação
Usuário
A comunicação é representada através
de um arco simples

Figura 2. Exemplo de Comunicação

Inclusão: Quando um número de casos de uso tem comportamento comum, esse comportamento pode ser modelado em um simples caso de uso que é utilizado por outros casos. Assim, quando um caso de uso faz uso de outro, o relacionamento de inclusão se aplica. É desenhado como uma seta pontilhada do caso de uso que faz o uso ao caso de uso que é usado (da parte para o todo), etiquetada com <<includes>>. A Figura 3 apresenta um exemplo do relacionamento de inclusão.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

TelefoneTelefone CelularCelular <<includes>> Identifica Fazer ligação destinatário Usuário A
TelefoneTelefone CelularCelular
<<includes>>
Identifica
Fazer ligação
destinatário
Usuário
A comunicação é representada através
de um arco pontilhado com o rótulo <<includes>>

Figura 3 Exemplo de Inclusão

Extensão. É usada para descrever casos de uso que são ativados opcionalmente em um sistema. O relacionamento de extensão é representado graficamente através de uma seta pontilhada com o rótulo <<extends>> que tem origem no caso de uso opcional e atinge o caso de uso obrigatório associado. A Figura 4 mostra um exemplo do uso de Extensão na modelagem de casos de uso.

TelefoneTelefone CelularCelular Receber <<extends>> ligação Receber ligação adicional Usuário
TelefoneTelefone CelularCelular
Receber
<<extends>>
ligação
Receber
ligação
adicional
Usuário
Opcional

Figura 4 Exemplo de Extensão

Generalização. Expressa um relacionamento do tipo herança entre casos de uso. Assim, um super-tipo de caso de uso indica um caso geral, enquanto que suas especializações indicam casos particulares. A Figura 5 apresenta um exemplo do relacionamento de generalização, onde Efetua pagamento é um super-tipo o qual é especializado em Pagto com Cartão de Crédito e Pagto com Débito em Conta.

Super tipo Efetua pagamento Usuário Pagto com Cartão de crédito Pagto com Débito em Conta
Super tipo
Efetua
pagamento
Usuário
Pagto com
Cartão de crédito
Pagto com
Débito em Conta
Sub tipos

Figura 5 Exemplo de Generalização

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

2.3 Exemplos de casos de uso

2.3.1 Caixa eletrônico

O exemplo da Figura 6 mostra um diagrama de caso de uso que ilustra os serviços

tipicamente fornecidos por um Caixa eletrônico bancário. O diagrama distingue explicitamente dois grupos de serviços: aqueles casos de uso para o Cliente, enquanto que “Abastecer dinheiro” e “Recolher envelopes de depósitos” são de uso exclusivo do ator Funcionário.

Caixa eletrônico Consulta de saldo Abastecer dinheiro Solicitação de extrato Recolher envelopes de depósitos
Caixa eletrônico
Consulta
de saldo
Abastecer
dinheiro
Solicitação
de extrato
Recolher
envelopes de
depósitos
Saque
Cliente
extrato Recolher envelopes de depósitos Saque Cliente Funcionário Figura 6 Exemplo de diagrama de caso de

Funcionário

Figura 6 Exemplo de diagrama de caso de uso (extraído de [FUR98])

2.3.2 Telefone celular

A Figura 7 apresenta um diagrama de caso de uso para um telefone celular. Deve-se

observar que o serviço “Faz ligação” faz uso de “Identifica destinatário” e opcionalmente

utiliza “Fazer ligação em conferência”. O caso de uso “Receber ligação”, por sua vez, opcionalmente utiliza o “Receber ligação adicional”.

TelefoneTelefone CelularCelular Fazer <<includes>> Identifica Rede ligação destinatário Celular
TelefoneTelefone CelularCelular
Fazer
<<includes>>
Identifica
Rede
ligação
destinatário
Celular
<<extends>>
Fazer
Receber
ligação em
ligação
conferência
<<extends>>
Uso
Receber
programado
ligação
adicional
Usuário
Figura 7 Exemplo de caso para telefone celular (adaptado de [BOO00])

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

2.3.3 Sistema de Vendas [TOG00]

A Figura 8 mostra um diagrama de caso de uso fornecido como exemplo na ferramenta Together Control Center. São fornecidos dois sistemas inter-relacionados (“Point of Sale” e “Product System”) com casos de uso particulares. O ator Cashier representa o usuário do sistema que assume o papel de Caixa (atendente), enquanto que Inventory System é um sistema externo.

enquanto que Inventory System é um sistema externo. Figura 8. Caso de uso de Sistema de

Figura 8. Caso de uso de Sistema de vendas.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

3 DIAGRAMA DE CLASSES EM UML

O modelo de objetos em UML é representado através de um diagrama de classes. Um diagrama de classes denota a estrutura estática de um sistema e as classes representam coisas que são manipuladas por esse sistema. A notação utilizada para representar o diagrama de classes em UML é fortemente baseada na notação de Diagramas Entidade-Relacionamento [CHE90] e no Modelo de Objetos de OMT [RUM94]. As seções a seguir apresentam resumidamente a notação utilizada nesta linguagem.

3.1 Classes e seus relacionamentos

Uma classe é representada por um retângulo sólido com três partes: uma para o nome da classe; outra para os atributos da classe; e a terceira para a declaração das operações definidas para a classe. A Figura 9 mostra a notação UML para classes.

a classe. A Figura 9 mostra a notação UML para classes. Figura 9. Notação para classe

Figura 9. Notação para classe em UML

Os tipos principais de relacionamentos entre classes são:

Generalização/Especialização (Herança): Indica relacionamento entre um elemento mais geral e um elemento mais específico (superclasse e subclasse, respectivamente). A subclasse pode conter somente informação adicional acerca da superclasse. Por exemplo um médico é um funcionário;

Agregação: Usada para denotar relacionamentos todo/parte. Por exemplo, um item de compra é parte de um pedido;

Associação (simples): Usada para representar relacionamentos entre as classes (por exemplo, um cliente pode alugar várias fitas de vídeo);

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

Dependência: Um relacionamento entre um elemento independente e outro dependente, onde uma mudança no elemento independente afetará o elemento dependente.

3.2 Associações Simples

Uma associação descreve um conjunto de vínculos entre objetos das classes relacionadas. A associação entre duas ou mais classes permite um conjunto de ligações entre os objetos das classes. Os tipos de associação são:

Associação Unária: Relacionamento entre uma classe e ela mesma. Também conhecida como associação recursiva, cujo relacionamento pode conectar dois diferentes objetos de uma mesma classe. A Figura 10 mostra um exemplo de associação unária:

Funcionário

1

*

supervisiona

Figura 10. Exemplo de associação unária.

Associação Binária: Expressa o relacionamento entre duas classes distintas. A Figura 11 ilustra o exemplo de associação binária.

MultiplicidadeMultiplicidade dada associaçãoassociação Pessoa Pessoa Livro Livro Nome: Str Nome: Str autoria
MultiplicidadeMultiplicidade dada associaçãoassociação
Pessoa
Pessoa
Livro
Livro
Nome: Str
Nome: Str
autoria
Endereço: {
Endereço: {
0
*
1
*
Título: Str
Título: Str
Logradouro: Str,
Logradouro: Str,
ISBN: Int
ISBN: Int
Bairro: Str,
Bairro: Str,
Editora: Str
Editora: Str
Cidade: Str. }
Cidade: Str.
}
Telefones: Array of Int
Telefones: Array of Int

RótuloRótulo dada associaçãoassociação

Figura 11 Exemplo de associação binária

Em geral, toda associação deve ser rotulada, tal como na associação de ‘autoria’ na Figura 11. Alternativamente, pode ser expresso o papel de uma classe na associação, tal como Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

titular na Figura 12.

Conta Bancária

 

Pessoa

Pessoa

 

número

saldo

dataAbertura

*

1

Nome: Str

Nome: Str

Endereço: {

Endereço: {

 

Logradouro: Str,

Logradouro: Str,

criar()

bloquear()

desbloquear()

 

titular

titular

Bairro: Str,

Bairro: Str,

Cidade: Str. }

Cidade: Str.

}

Telefones: Array of Int

Telefones: Array of Int

creditar()

 

debitar()

Papel da classe na associação

Figura 12 Segundo exemplo de associação binária

As associações têm sua semântica definida como relações entre conjuntos. O exemplo da Figura 13 ilustra como que as classes Funcionário e Departamento representam conjuntos, enquanto que a associação ‘trabalha’ define uma relação bidirecional entre os conjuntos, indicando que o Funcionário João ‘trabalha’ no Departamento Financeiro e vice versa.

Funcionário Departamento * 0 trabalha 4 1 Financeiro João João Funcionário Funcionário Departamento Figura
Funcionário
Departamento
* 0
trabalha 4
1
Financeiro
João
João
Funcionário
Funcionário
Departamento
Figura 13 Mapeamento da semântica estrutural de uma associação

Associação n-ária: Associação entre três ou mais classes. Neste caso a notação inclui um losango para representar a associação, como mostra a figura a seguir:

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

UML para Especificação de Sistemas Orientados a Objetos Figura 14. Representação de associação ternária. 3.3

Figura 14. Representação de associação ternária.

3.3 Multiplicidade (Cardinalidade)

A cardinalidade das associações em um diagrama de classes é denominada de multiplicidade e especifica quantas instâncias de uma classe podem participar da associação (semelhante à abordagem ER). A tabela 1 a seguir apresenta as multiplicidades. Tabela 1 – Multiplicidades de associações entre classes.

Multiplicidade

Significado

 

0

1

Zero ou um

 

1

Somente 1

 

0

*

Maior ou igual a zero

 

*

Maior ou igual a zero

 

1

*

Maior ou igual a 1

1

15

(m

n)

De 1 a 15 (m a n), inclusive

A Figura 15 mostra um exemplo de uso de multiplicidade onde a classe financeira está associada a 0 ou mais instâncias classe venda através da associação financia. A classe venda está associada a um objeto da classe vendedor através da associação venda (notar que o nome da associação pode ser um substantivo).

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

Financeira

Financeira

 

financia

Venda

Venda

realizada por

Vendedor

Vendedor

0

1

*

*

código

código

nome

nome

 

data

data

hora

hora

número

número

nenha

nenha

 

nívelAutorização

nívelAutorização

Figura 15. Financeira: exemplo de uso de multiplicidade (adaptado de [HEU 99])

3.4 Classes Associativas

São classes que representam a associação entre outras classes. Somente ocorrem instâncias da classe associativa quando ocorre a associação entre classes. Comparando com a abordagem Entidades-Relacionamentos (ER), uma classe associativa equivale a uma entidade associativa ou agregação de entidades. Da mesma forma, quando em um diagrama ER existe a necessidade de representar atributos de relacionamentos, em um diagrama de classes cria-se uma classe associativa.

A Figura 16 mostra um exemplo de classe associativa onde quando ocorre um

casamento entre duas pessoas, então uma classe associativa armazena a data do casamento e o regime.

Data Data Data Regime Regime Regime

Data

Data

Data

Regime

Regime

Regime

casamento

esposa

0

1

Pessoa

Pessoa

 

Nome

Nome

Endereço: {

Endereço: {

Logradouro;

Logradouro;

0

1

Bairro;

Bairro;

marido

}

Cidade.

Cidade. }

Sexo

Sexo

marido } Cidade. Cidade. } Sexo Sexo Figura 16. Exemplo de classe associativa em uma

Figura 16. Exemplo de classe associativa em uma associação unária.

A Figura 17 mostra um exemplo de associação onde é representado que quando

ocorre a matrícula de um Aluno em uma Disciplina. A classe associativa armazena as

informações de matrícula, isto é, o conceito e semestre correspondentes.

Aluno

*

matriculado

*

Disciplina

   
 

conceito

 

semestre

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

Figura 17. Exemplo de classe associativa com associação binária.

A Figura 18 ilustra um exemplo de classe associativa entre Financeira e Venda, complementando o diagrama apresentado anteriormente na Figura 15

Financeira

Financeira

 

financia

 

Venda

Venda

realizada por

Vendedor

Vendedor

0

1

*

*

código

código

nome

nome

 

data

data

hora

hora

número

número

nenha

nenha

   

nívelAutorização

nívelAutorização

 

Financiamento

   

registroAprovação

dataAprovação

 

Figura 18 Evolução do modelo de Financeira com classe associativa

Uma classe associativa pode ser transformada em uma classe regular conforme

mostra a Figura 19 a seguir. A parte superior da figura mostra o modelo duas classes regulares

e uma associativa, enquanto que a parte inferior apresenta um modelo análogo que é composto por três classes regulares.

Funcionário

1

Departamento

1 trabalha 4 0

regulares. Funcionário 1 Departamento 1 trabalha 4 0 salário dataContratação Funcionário * Emprego *

salário

dataContratação

Funcionário

*

Emprego

*

0 1

Departamento

 

salário

 

dataContratação

Figura 19. Transformação de uma classe associativa em classe regular.

3.5 Qualificador

Qualificadores ou Associações Qualificadas são usadas com associações 1:N ou N:N.

O qualificador distingue (divide) o conjunto de objetos do outro lado da associação. A figura

a seguir ilustra um exemplo de qualificador. O modelo informa que um prédio possui vários números de andar. Um número de andar de um prédio está associado a exatamente um andar. Como conseqüência um andar é identificado pelo seu número e pelo prédio. Este conceito é análogo ao conceito de entidade fraca ou relacionamento identificador em modelos entidade- relacionamento.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

UML para Especificação de Sistemas Orientados a Objetos Figura 20. Exemplo de uso de qualificador. Outro

Figura 20. Exemplo de uso de qualificador.

Outro exemplo de qualificador é apresentado na figura a seguir, onde um diretório está associado a vários nomes de arquivo, e cada nome de arquivo é associado a um arquivo. Cada arquivo está associado a um nome de arquivo e a um diretório.

Diretório Arquivo Nome do arquivo
Diretório
Arquivo
Nome do arquivo

Figura 21. Exemplo de qualificador.

3.6 Agregação

É um caso especial de associação usado para representar a relação todo/parte entre

classes. Quando o todo é criado, as partes também o são (e quando é eliminado também). As

partes não têm existência própria, somente associadas ao todo.

A notação de agregação é apresentada nas figuras a seguir:

Todo

Parte

agregação é apresentada nas figuras a seguir: Todo Parte Agregação Regular Figura 22. Agregação regular ou
agregação é apresentada nas figuras a seguir: Todo Parte Agregação Regular Figura 22. Agregação regular ou

Agregação Regular

Figura 22. Agregação regular ou relacionamento por referência.

Todo

Parte

regular ou relacionamento por referência. Todo Parte Agregação de composição Figura 23. Agregação de
regular ou relacionamento por referência. Todo Parte Agregação de composição Figura 23. Agregação de

Agregação de composição

Figura 23. Agregação de composição ou relacionamento por valor. Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

A rigor, a agregação deve ser utilizada prioritariamente para explicitar relações de todo-parte: portanto, a Figura 24 mostra dois diagramas de classe que possuem exatamente o mesmo significado.

0 * 0 * Documento Parágrafo Sentença composto-por composto-por 0 * 0 * Documento Parágrafo
0
*
0
*
Documento
Parágrafo
Sentença
composto-por
composto-por
0
*
0
*
Documento
Parágrafo
Sentença

Figura 24 Documento, parágrafo e sentença: duas alternativas para modelagem de agregação

Um segundo exemplo de uso de agregação em que uma Associação Esportiva é composta por várias Equipes afiliadas que, por sua vez, são compostas por objetos da classe Jogador.

Associação

Esportiva

Equipe

0 * 0 * <- afiliada
0
*
0
*
<- afiliada

Jogador

Figura 25. Exemplo de agregação.

Outro exemplo de agregação com notação compacta é apresentado na Figura 26, mostrando que ao invés de ligar várias linhas a um agregado, basta usar o símbolo de agregação uma única vez.

basta usar o símbolo de agregação uma única vez. Figura 26. Agregação de várias classes com

Figura 26. Agregação de várias classes com notação compacta [HEU 99].

Por fim, é apresentado um exemplo de composição na Figura 27. No caso, a classe CPF é especialmente útil para ser descrito separadamente por fornecer o método validaCPF.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

Pessoa

Pessoa

nome

nome

endereço: {

endereço: {

logradouro;

logradouro;

bairro;

bairro;

cidade. }

cidade. }

cpf

cpf

sexo

sexo

cidade. } cidade. } cpf cpf sexo sexo composição Pessoa Pessoa Endereço Endereço
composição Pessoa Pessoa Endereço Endereço logradouro logradouro nome nome bairro bairro sexo sexo cidade
composição
Pessoa
Pessoa
Endereço
Endereço
logradouro
logradouro
nome
nome
bairro
bairro
sexo
sexo
cidade
cidade
CPF
número
validaCPF: bool

Figura 27 Uso de composição para descrever os detalhes de Pessoa

3.7 Navegabilidade

Uma instância de uma classe pode navegar a instâncias de outra classe e vice-versa. Navegabilidade é percebida freqüentemente por objetos que mantêm referências de algum tipo entre objetos associados. Uma seta é ligada entre duas classes para indicar o caminho de navegação entre elas. Em termos de implementação isso representaria que o objeto de uma classe conteria um apontador para o objeto da outra classe.

A figura a seguir mostra um exemplo onde as classes Pedido e Cliente possuem uma associação onde o sentido da navegação ocorre de Pedido para Cliente. Isto indica que um pedido tem a responsabilidade de informar a qual cliente pertence, mas um cliente em particular não precisa indicar quais pedidos possui.

fonte

Pedido

alvo

Cliente

1 *
1
*
indicar quais pedidos possui. fonte Pedido alvo Cliente 1 * navegabilidade Figura 28. Exemplo de Navegabilidade

navegabilidade

Figura 28. Exemplo de Navegabilidade

3.8 Generalização/Especialização

Generalização/Especialização é um conceito também conhecido pelo nome de Herança. Trata-se de um relacionamento de classificação entre um elemento mais geral e outro mais específico. O elemento mais específico é completamente consistente com o mais geral somando-se informação adicional especializada.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

As subclasses herdam atributos, operações e associações da superclasse e agregam atributos e operações particulares ao elemento de especialização a que se referem.

A Figura 29 mostra um exemplo do uso de herança onde Pessoa física e Pessoa jurídica são especializações de Cliente. As sub-classes herdam todas as propriedades (atributos, métodos, relacionamentos, generalizações) da classe genérica e, desta forma, em virtude do polimorfismo de dados não é necessário repetir a associação entre Cliente e Compra para todas as especializações de Cliente.

Cliente realiza * * nome Compra PessoaFísica PessoaJurídica CPF CGC RG RazãoSocial Sexo DataNascimento
Cliente
realiza
*
*
nome
Compra
PessoaFísica
PessoaJurídica
CPF
CGC
RG
RazãoSocial
Sexo
DataNascimento

Figura 29. Exemplo de generalização/especialização.

3.9 Restrições

Uma restrição é um relacionamento semântico entre elementos de modelo que especifica condições e proposições que devem ser mantidas como verdadeiras.

Certos tipos de restrições são predefinidas em UML, mas há a possibilidade de definição de restrições por parte do usuário. Por exemplo, a Figura 30 mostra uma associação onde a restrição é definida para limitar a possibilidade de associação entre Pessoa e Cidadãos idosos.

Cidadãos

{pessoa.idade>60}

 

Idosos

0

1

0

*

Pessoa

Figura 30. Exemplo de uso de restrição.

Um exemplo de restrição bastante utilizada é a restrição {ou}. Ela indica que em uma associação, uma instância da classe só pode participar uma vez no máximo de uma das associações possíveis (cortadas pela linha tracejada). A figura a seguir ilustra um exemplo

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

onde uma conta corrente pertence a um indivíduo ou a uma organização.

Indivíduo 0 1 0 * Conta corrente {ou} 0 * Organização 0 1
Indivíduo
0
1
0
*
Conta
corrente
{ou}
0
*
Organização
0
1

Figura 31. Uso de restrição {ou}

3.10 Estudo de Caso

A figura a seguir mostra um exemplo inicial do modelo de classes para uma universidade. Sugere-se como exercício a complementação do modelo.

Sugere-se como exercício a complementação do modelo. Figura 32. Estudo de caso de Controle Acadêmico de

Figura 32. Estudo de caso de Controle Acadêmico de Universidade

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

4 DIAGRAMAS DE INTERAÇÃO

Diagrama de Interação é um termo genérico que se aplica a vários tipos de diagramas que enfatizam interações de objetos. Uma interação é uma especificação comportamental que inclui uma seqüência de trocas de mensagens entre um conjunto de objetos dentro de um contexto para realizar um propósito específico, tal como a realização de um caso de uso. As mensagens podem incluir sinais e chamadas implícitas decorrentes de condições e eventos de tempo.

Para especificar uma interação, é necessário definir um contexto de caso de uso e estabelecer os objetos que interagem e seus relacionamentos. Portanto, diagramas de interação são aplicados para mostrar a realização de casos de uso e as possíveis seqüências de interação entre objetos.

O diagrama de interação deve ser usado quando se deseja visualizar o comportamento de vários objetos dentro de um único caso de uso, a partir de mensagens passadas entre eles. Para se compreender o comportamento de um único objeto para muitos casos de uso, é melhor empregar um diagrama de estado; para se analisar o comportamento de muitos casos de uso é recomendado o diagrama de atividade. Os diagramas de interação são apresentados de duas formas (equivalentes) em UML:

Diagrama de Seqüência: Enfatiza o comportamento dos objetos em um sistema incluindo suas operações, interações, colaborações e histórias de estado em seqüência temporal de mensagem e representação explícita de ativação de operações. Os objetos são desenhados como linhas verticais, as mensagens como linhas horizontais e a seqüência de mensagens é lida de cima para baixo;

Diagrama de Colaboração: Mostra o contexto completo de uma interação, inclusive os objetos e seus relacionamentos pertinentes a uma interação particular, sendo freqüentemente melhores para propósitos de projeto.

A figura a seguir mostra um exemplo de um diagrama de seqüência (enfatizando a ordem de chamamento) e um diagrama de colaboração (enfatizando a interação entre os objetos).

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

UML para Especificação de Sistemas Orientados a Objetos Figura 33 Diagramas de Seqüência e Colaboração. 4.1

Figura 33 Diagramas de Seqüência e Colaboração.

4.1 Diagrama de Seqüência

Um diagrama de seqüência mostra interações de objetos organizadas em uma seqüência de tempo e de mensagens trocadas, mas não trata associações entre os objetos como os diagramas de colaboração.

A Figura 34 apresenta a notação utilizada para diagrama de seqüência onde são mostrados os seus elementos básicos.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

UML para Especificação de Sistemas Orientados a Objetos Figura 34 Elementos de um diagrama de seqüência

Figura 34 Elementos de um diagrama de seqüência UML [FUR98]

Um exemplo de diagrama de seqüência para o empréstimo de um livro em um sistema de bibliotecas é apresentado na figura a seguir. Neste exemplo, o bibliotecário acessa a janela de empréstimo que enviará mensagem para encontrar o título. Encontrado o título, busca-se a disponibilidade do item, identifica-se o usuário e faz-se o empréstimo. Outro exemplo de diagrama de seqüência é mostrado na Figura 36, retratando o processo de venda.

é mostrado na Figura 36, retratando o processo de venda. Figura 35 . Exemplo de diagrama

Figura 35. Exemplo de diagrama de seqüência para biblioteca [FUR 98]. Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

UML para Especificação de Sistemas Orientados a Objetos Figura 36. Exemplo de diagrama de seqüência para

Figura 36. Exemplo de diagrama de seqüência para um sistema de vendas.

4.2 Diagrama de Colaboração

Um diagrama de colaboração mostra uma interação organizada em torno de objetos e seus vínculos formando uma base de padrões.

O diagrama de seqüência e diagrama de colaboração expressam a mesma informação mas a apresentam de forma diferente. O primeiro exibe uma seqüência explícita de mensagens

e é melhor para especificações de tempo real (dimensão tempo) e para cenários complexos,

enquanto o segundo mostra os vínculos entre objetos e é melhor para entender os efeitos em um determinado objeto (dimensão espaço). Para decidir qual diagrama deve ser utilizado para

estudar uma interação, uma regra geral é escolher o diagrama de colaboração quando o objeto

e seus vínculos facilitam a compreensão da interação, e escolher o diagrama de seqüência somente se a seqüência necessita ser evidenciada.

Ao contrário de um diagrama de seqüência, um diagrama de colaboração mostra os relacionamentos entre os objetos, mas não trata o tempo como uma dimensão separada. A seqüência de tempo é indicada numerando-se as mensagens. Em um diagrama de colaboração as classes e objetos são representados como na Figura 37.

de colaboração as classes e objetos são representados como na Figura 37. Prof. Rodrigo Quites Reis

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

Figura 37. Elementos de um diagrama de colaboração.

A Figura 38 mostra a chamada de métodos em um diagrama de colaboração e a Figura 39 mostra algumas convenções utilizadas quando um método é chamado. A Figura 40 mostra o uso de parâmetros de métodos no diagrama de colaboração, onde é possível chamar um método com argumentos declarando a variável e o tipo de retorno.

com argumentos declarando a variável e o tipo de retorno. Figura 38. Notação UML para diagramas

Figura 38. Notação UML para diagramas de colaboração.

Figura 38. Notação UML para diagramas de colaboração. Figura 39. Convenções do diagrama de colaboração. Prof.

Figura 39. Convenções do diagrama de colaboração.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

UML para Especificação de Sistemas Orientados a Objetos Figura 40. Parâmetros de métodos em diagramas de

Figura 40. Parâmetros de métodos em diagramas de colaboração.

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

5 ESTUDOS DE CASO E EXERCÍCIOS

5.1 Estudo de Caso 1: Locadora de Veículos

Modelar um sistema OO tomando por partida a definição abaixo:

“O cliente é sócio-proprietário de uma rede de locadora de carros que possui várias filiais espalhadas por vários estados brasileiros e países do Mercosul. Cada filial possui diversos carros para alugar. Existem vários tipos de carro: popular, luxo, utilitário, etc. Os carros possuem código (chapa do carro), tipo, modelo, ano, cor, chassis, km e valor do aluguel (diárias e semanais). Os clientes da locadora podem reservar e alugar carros. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguéis. Para cada aluguel é emitida uma nota fiscal com a quilometragem percorrida e o valor do aluguel. A locadora possui funcionários que trabalham nas filiais. As filiais são identificadas por código, nome cidade, endereço e telefones. Os clientes são identificados por código, nome, cpf, telefone, endereço, cidade. E os funcionários são identificados por código, nome, endereço, telefone, cidade.”

5.2 Estudo de Caso 2: Hospital

Modelar um hospital com vários setores e funcionários que presta vários tipos de serviço aos pacientes conforme características abaixo:

Setores são compostos de vários sub-setores. Cada setor está dividido em salas. Existem salas de cirurgia, consultórios, apartamentos, etc.

Os funcionários do hospital trabalham em setores e são médicos, enfermeiros e pessoal administrativo com diversos cargos. Existem equipes de médicos e enfermeiros com um médico como supervisor da equipe;

Os pacientes são submetidos a procedimentos no hospital. Procedimentos são pagos por convênios ou pelo próprio paciente (particular) e podem ser:

- Cirurgias: ocupando salas de cirurgia com equipe médica responsável;

- Internações: ocupando enfermarias ou quartos e com tratamento prescrito (medicação e dieta);

- Consultas: com data, hora, diagnóstico, exames solicitados e receita médica, ocupando consultórios e com médico responsável;

- Exames: solicitados em consultas médicas, registrando os resultados;

- Outros procedimentos de hospital.

Definir novos requisitos para o sistema

Prof. Rodrigo Quites Reis - Fevereiro/2003

Usando UML para Especificação de Sistemas Orientados a Objetos

REFERÊNCIAS BIBLIOGRÁFICAS

[BEZ02] BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. São Paulo:

Campus, 2002.

[BOO94]

BOOCH,

G.

Object-Oriented

Analysis

and

Design

Benjamim-Cummings Publishing Co., 1994.

with

Applications.

[BOO00] BOOCH, G.; RUMBAUGH, J.; Paulo: Campus, 2000.

JACOBSON, I. UML: Guia do Usuário. São

[CHE90] CHEN, P. Modelagem de Dados: A abordagem Entidade-Relacionamento para Projeto Lógico. Makron Books, 1990.

[COA98]

COAD,

P.;

MAYFIELD,

M.

Projeto

de

Sistemas

em

Java:

Construindo

aplicativos e melhores applets. São Paulo: Makron Books, 1998.

[ERI98]

ERIKSSON, H.; PENKER, M. UML Toolkit. Wiley Computer Publishing, 1998.

[FUR98] FURLAN, J.D. Modelagem de Objetos através da UML. São Paulo: Makron Books, 1998.

[GUE91] GUEZZI, C.; JAZAYERI, M. Fundamentals of Software Engineering. Prentice- Hall, 1991.

[HEU 99] HEUSER, C. A. Projeto Orientado a Objetos. Apostila de curso. Obtida em http://heuser.inf.ufrgs.br

[JAC92] JACOBSON, I. et. al. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Publishing Co., 1992.

[JAC99] JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Process. In: IEEE Software. p. 96-102. May/June 1999.

[RUM94] RUMBAUGH, J. et. al. Modelagem e Projetos Baseados em Objetos. São Paulo:

Campus, 1994.

[TOG00] Together Inc. (http://www.togethersoft.com)

Prof. Rodrigo Quites Reis - Fevereiro/2003