Usando Uml

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

Prof. Rodrigo Quites Reis Fevereiro, 2003 [email protected]

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 3.9 Restrições .................................................................................................................... 19 3.10 Estudo de Caso.......................................................................................................... 20

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 OMG1 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

Ator 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; Telefone Celular

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 <>. 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

Telefone Celular <>

Fazer ligação

Usuário

Identifica destinatário

A comunicação é representada através de um arco pontilhado com o rótulo <>

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. Telefone Celular

Receber ligação

<<extends>>

Receber ligação adicional

Opcional

Usuário

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. Efetua pagamento

Usuário

Pagto com Cartão de crédito

Super tipo

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 Solicitação de extrato

Cliente

Saque

Abastecer dinheiro Recolher envelopes de depósitos

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”. Telefone Celular

Rede Celular

Fazer ligação

<>

Identifica destinatário

<<extends>>

Fazer ligação em conferência

Receber ligação <<extends>>

Uso programado

Usuário

Receber ligação adicional

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.

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.

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.

Multiplicidade da associação Pessoa Livro autoria Título: Str ISBN: Int Editora: Str

0..*

Nome: Str Endereço: {

1..* Logradouro: Str, Bairro: Str, Cidade: Str. }

Telefones: Array of Int

Rótulo da associaçã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

número saldo dataAbertura

*

1 titular

criar() bloquear() desbloquear() creditar() debitar()

Nome: Str Endereço: { Logradouro: Str, Bairro: Str, Cidade: Str. }

Telefones: Array of Int

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

João

Funcionário

0..*

trabalha 4 1

Departamento

Financeiro

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

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

financia 0..1

código nome

realizada por

Venda

*

Vendedor

*

número nenha nívelAutorização

data hora

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. casamento

Data Regime

esposa 0..1 Pessoa Nome Endereço: { 0..1 marido

Logradouro; Bairro; Cidade. }

Sexo

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

financia 0..1

Venda

*

código nome

realizada por *

Vendedor número nenha nívelAutorização

data hora 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

trabalha 4 0..1

1

Departamento

salário dataContratação

Funcionário

*

Emprego salário dataContratação

*

0..1

Departamento

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 entidaderelacionamento. Prof. Rodrigo Quites Reis - Fevereiro/2003

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

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

Nome do arquivo

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 Regular Figura 22. Agregação regular ou relacionamento por referência.

Todo

Parte

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.

Documento

Documento

0..* composto-por

0..*

Parágrafo

0..* composto-por

Parágrafo

0..*

Sentença

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

0..*

<- afiliada

0..*

Equipe

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.

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

composição Pessoa

Pessoa

nome endereço: { logradouro; bairro; cidade. } cpf sexo

Endereço logradouro bairro cidade

nome sexo

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 alvo 1 Cliente Pedido *

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 *

nome

PessoaFísica CPF RG Sexo DataNascimento

realiza

*

Compra

PessoaJurídica CGC RazãoSocial

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 Idosos

{pessoa.idade>60} 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.

Conta corrente

0..1

0..*

Indivíduo

{ou} 0..* 0..1

Organização

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.

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

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

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.

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

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.

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.

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

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

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 with Applications. Benjamim-Cummings Publishing Co., 1994. [BOO00] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. São Paulo: Campus, 2000. [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. PrenticeHall, 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