1.
1

2.
2
1. Sistema de Controle Bibliotecário (SisBiblio)
Para possibilitar a aplicação prática da UML na fase de análise, foi
definido o domínio de problema de uma Biblioteca para modelagem do Sistema de
Controle Bibliotecário (SISBIBLIO). Esse domínio de problema permitiu
exemplificar todos os diagramas da UML necessários. A seguir serão descritos
os requisitos e regras de negócio do sistema.
Considere a Biblioteca de uma Universidade que necessita controlar o seu
acervo de livro e atender aos professores e alunos no que se refere a serviços de
reservas, empréstimos e devoluções.
Os professores e os alunos podem acessar o Sisbiblio para consulta de
livros, exemplares e para reservar livros.
Para emprestar e devolver livros, o aluno ou professor deve dirigir-se à
Biblioteca para solicitar o serviço diretamente à bibliotecária.
Durante o empréstimo de livros, o sistema deverá verificar se o aluno ou
professor está em situação regular que permita a realização do empréstimo,
bem como se o livro a ser emprestado está disponível na Biblioteca. Em caso
afirmativo, o sistema deve permitir que o aluno empreste até 3 (três) livros
enquanto o professor poderá emprestar até 5 (cinco) livros. No ato do
empréstimo, o sistema deverá calcular a data de devolução prevista, sendo que o
aluno deverá devolver o livro em até 2 (dois) dias enquanto o professor deverá
devolver o livro em até 3 (três) dias.
O sistema também deverá permitir que a bibliotecária realize o registro
das devoluções de livros. Caso o livro seja devolvido com atraso, ou seja, após a
data prevista pelo sistema, o sistema deverá gerar um débito de R$ 3,00 por dia

3.
3
para cada livro em atraso, que deverá ser pago pelo aluno. Já o professor será
suspenso e não poderá realizar outros empréstimos durante 2 dias úteis para
cada livro em atraso.
Para os casos de pagamento de débitos de atraso, o sistema deverá
permitir que o valor pago seja registrado e a situação do aluno seja atualizada
automaticamente.

4.
4
Capitulo 2
Diagrama de Caso de Uso
2.1 Conceito
Um diagrama de caso de uso é um diagrama usado para representar tanto as
interações entre o(s) usuário(s) e o sistema quanto as funcionalidades do mesmo.
Por interação entendemos como o ato de alguém ou alguma coisa poder se
“comunicar” com o sistema. Ressaltando-se que quando essa comunicação é feita
por uma pessoa, ela geralmente é feita por meio de uma interface (tela).
Uma pergunta que pode surgir, principalmente, aos iniciantes na área de
desenvolvimento de sistemas é: “o que é uma funcionalidade?”
De forma simples, uma funcionalidade representa qualquer tarefa que o
sistema pode realizar. Por exemplo: Emprestar Livro, Calcular juros por atraso,
cancelar um item de venda, emitir um relatório, cadastrar um cliente, etc.
Em outras palavras, funcionalidade é tudo aquilo que contribui para o
“funcionamento” do sistema. Por exemplo, um sistema desenvolvido para
controlar aluguéis de DVD, não pode “funcionar” se não tiver implementado as
funções alugar, devolver, cadastrar clientes, dentre outras.
Portanto, o diagrama de casos de uso representa tanto as funcionalidades
que o sistema possui quanto as comunicações feitas entre o sistemas e todos que
precisarem utilizá-lo.

5.
5
2.2 Componentes
O diagrama de Caso de uso possui três componentes (Figura 2.1): o ator, o caso
de uso e a associação, sendo que:
o Ator - corresponde a representação de qualquer coisa que possa
interagir (se comunicar) com o sistema, podendo ser um usuário, um
equipamento (por exemplo, impressora) ou um outro sistema.
o Caso de uso – refere-se às funcionalidades (tarefas) do sistema.
o Associação – diz respeito à ligação que pode existir entre os dois
elementos anteriores.
Figura 2.1: Componentes de um Diagrama de Caso de Uso.
A seguir descreveremos, mais detalhadamente, cada componente do Diagrama de
Casos de Uso.
2.2.1 ATOR
Conforme já dito anteriormente os atores representam entidades que interagem
com o sistema. Tais entidades podem ser:
pessoas e/ou seus papéis (usuário, gerente, vendedor...);
sistemas (sistema de banco, de fornecedores, que importam dados para o
sistema que está sendo desenvolvido ou exporta dele para os primeiros);
Calcular
desconto
Ator Caso de uso
Associação

6.
6
locais físicos, tais como departamentos ou setores de uma empresa
(almoxarifado, recursos humanos, setor de vendas, entre outros.);
quaisquer hardware que se relacione com o sistema, seja pelo teclado,
dando cliques com o mouse, ou seja, que se comunique por meio da
absorção de dados ou fonte de dados ou recebendo dados do sistema.
A representação do ator pode ser feita por meio da figura de um stickman
(Figura 2.2a), quando se trata de usuário (pessoa). Quando se trata de sistemas,
empresas etc, pode-se utilizar retângulos estereotipados como ator (<<actor>>) e
com o nome do ator (Figura 2.2b), ou qualquer figura especial que retrate tal
entidade (Figura 2.2c).
Figura 2.2a – usuário (stickman) Figura 2.2b – ator como um sistema
Figura 2.2c – Banco do Brasil
Portanto, ator é um papel que uma entidade, externa ao sistema, desempenha em
relação ao sistema. Sendo assim, usuários que não interagem com o sistema não
devem ser considerados.
2.2.2 CASO DE USO
<<actor>>
Sistema de RH
esteriótipo
Nome do ator

7.
7
Um Caso de Uso, conforme já dito anteriormente, representa uma funcionalidade
do sistema e é representado por uma elipse, com linha simples e sem cor (Figura
2.3).
Figura 2.3: Notação para um Caso de Uso
O nome do caso de uso pode ser colocado no interior da elipse (Figura
2.3a) ou imediatamente abaixo (Figura 3b).
Calcular desconto
2.2.3 ASSOCIAÇÃO
Uma associação representa a ligação que pode ser feita entre os elementos do
diagrama de caso de uso.
As associações podem ser feitas entre:
1. Um ator e um caso de uso;
2. Uma ator e outro ator;
3. Um caso de uso e outro caso de uso.
1. Associação entre ator e casos de uso – faz a ligação entre o ator e o
respectivo caso de uso com o qual ele interage. Sendo assim, toda vez que um
caso de uso necessitar de uma intervenção externa para ser executado, este
Figura 2.3a: Nome do Caso de Uso no
interior da elipse
Figura 2.3b: Nome do Caso de Uso abaixo da elipse
Calcular
desconto

8.
8
deverá possuir a ligação com o ator que fará a intervenção. Por exemplo, a Figura
2.4 apresenta a interação do ator usuário com o caso de uso Efetuar Login.
2. Associação entre casos de uso – faz a ligação entre dois casos de uso, pode
ser de 3 tipos: include, extend e generalização/especialização. A seguir
descreveremos cada um deles.
Include
Com o intuito de facilitar o entendimento do conceito e funcionalidade de um
include, façamos uma analogia com o conceito de procedimento (procedure) em
Linguagem de Programação, em que pode-se criar rotinas a parte para simplificar
um processamento e permitir que a mesma possa ser utilizada por outros
programas (reutilização).
O include é representado por uma seta tracejada originada no caso de uso
principal, em direção ao caso de uso secundário, conforme pode ser visualizado na
Figura 2, em que o caso de uso Efetuar Login corresponde ao caso de uso
principal (inclusor) e o caso de uso Validar Senha o secundário (incluído).
Figura 2.4: Exemplo do uso do include

9.
9
O Include pode ser utilizado em dois momentos importantes: na
complementação obrigatória e na reutilização.
Ao tratar de uma complementação o include é utilizado para representar
funcionalidades obrigatórias, mas que possuem uma quantidade de ações que
viabilizem a criação de um novo caso de uso. Por exemplo: Um caso de uso que
represente a funcionalidade EFETUAR VENDA para qual existe outra
funcionalidade que é VALIDAR FORMA DE PAGAMENTO. Toda vez que for
efetuada uma venda, é obrigatória a validação da forma de pagamento, uma vez
que, dependendo da forma, o sistema terá um tratamento diferente.
O segundo caso é quando temos a mesma porção de ações sendo utilizada
em mais de um caso de uso. Neste caso, deve-se retirar as linhas de ações
repetidas de todos os casos de uso e criar um novo caso de uso, o qual poderá ser
usado pelos casos de uso que precisarem (tal mecanismo é chamado de
reutilização).
Por exemplo, no SisBiblio tanto a funcionalidade Emprestar Livros quanto a
de Reservar Clientes necessitam da funcionalidade Consultar Cliente, haja vista
que para executar tais tarefas é preciso sempre saber qual a situação do cliente
(aluno ou professor), ou seja, checar se o cliente está OK, se está devendo,
verificar os dados cadastrais dos mesmos, entre outras coisas. Sendo assim, o
caso de uso de uso Consultar Cliente foi modelo como forma de atender essa
necessidade de reutilização, ao invés de repetir essas ações nos casos de uso
Emprestar Livros e Reservar Livros.
Com isso, há uma vantagem também para se fazer manutenções no sistema.
Pois caso mude a regra de negócio em relação à pesquisa do cliente, as alterações
necessárias serão feitas somente em um caso de uso (Pesquisar) e não em dois
(Emprestar e Reservar). A Figura 2.5 apresenta uma parte do Diagrama de Caso
de Uso geral que retrata este cenário.

10.
10
Figura 2.5: Exemplo de Include para Casos de Usos distintos
Extend
O extend também é representado por uma seta tracejada, porém na
direção contrária a do include, ou seja, o extend tem sua origem no caso de uso
secundário e finaliza no caso de uso principal.
Tal como um include, o extend também pode ser utilizado por questões de
reutilização (complemento) ou visto como uma sub-rotina. Entretanto, a
diferença entre eles é que o include possui a característica de obrigatoriedade, e
o extend, por sua vez, é caracterizado por sua opcionalidade.
Por exemplo, a Figura 2.6 apresenta o caso de uso Efetuar Login com uma
associação do tipo extend para o caso de uso Validar Senha. Isso significa que ao
se executar a função Efetuar Login o sistema poderá ou não validar a senha. Em
comparação com o exemplo de include visto no exemplo da Figura 2.4 em que toda
vez que o caso de uso Efetuar login fosse executado o caso de uso Validar Senha
também seria.

11.
11
Note que a decisão de se usar o extend ou o include é tomada de acordo
com a regra de negócio.
Figura 2.6: Exemplo do uso de extend
Generalização de caso de uso
Uma generalização de caso de uso é feita quando existir um caso de uso
(principal) que possa ser “desmembrado” em outros casos de uso, os quais
possuem características específicas mas que dependem das características do
caso de uso principal, ou seja, primeiramente é executado o caso de uso principal
e em seguida um dos casos de uso especializados também é executado.
Na Figura 2.7 podemos visualizar o caso de uso Devolver Livro, o qual pode
ser especializado em Devolver livro Professor e Devolver Livro Aluno. Tais
especializações possuem regras próprias, tais como: para o aluno que atrasa a
devolução é cobrado um valor de juros e multa, já para o professor é dada uma
suspensão de 1 semana para fazer novos empréstimos. Portanto, embora esses
casos de usos possuam características próprias, ainda assim necessitam da
realização do caso de uso Devolver Livro para serem executados.

12.
12
Figura 2.7: Exemplo de generalização de caso de uso
Associação entre atores – pode ser somente do tipo generalização. É usada
para diminuir a complexidade do diagrama evitando, na maioria das vezes, um
grande número de associações no diagrama.
A Figura 2.8 apresenta um exemplo de associação entre os atores Usuário,
Vendedor e Gerente. Ressaltando-se que, o caso de uso associado ao ator de
nível mais alto (principal) pode ser executado pelos atores de nível mais baixo
(especializados), mas a recíproca não é verdadeira, ou seja, tanto vendedor
quanto gerente podem efetuar login, porém somente o vendedor pode efetuar
veda e somente o gerente pode efetuar trocas.
Figura 7: Exemplo de associação entre atores

13.
13
3.5 Dicas
Não é aconselhável identificar um ator pelo nome da pessoa que
executa o papel. Por exemplo, supondo-se que no sistema de
biblioteca o balconista chama-se Pedro, A Figura X mostra que ao
invés de identificar o ator como Balconista o analista o identificou
pelo nome. Acontece que Pedro pode ser demitido da empresa e a
documentação do sistema referenciará uma pessoa que ninguém
conheça, podendo causar uma dificuldade de entendimento do
diagrama;
Ao identificar uma funcionalidade que complementa outra, pergunte
se a mesma sempre será executada, se resposta for sim modele um
relacionamento do tipo include caso contrário modele um extend.

14.
14
Capítulo 3
Descrição de Caso de Uso
3.1 Conceitos
A descrição de um diagrama de caso de uso tem como finalidade apresentar, de
forma detalhada, como deve ser executada uma funcionalidade, ou seja,
representa a execução da funcionalidade passo-a-passo.
Os diversos autores, que tratam, atualmente, deste assunto, apresentam
diferentes padrões e notação para descrição de caso de uso. Adotaremos um
modelo originado a partir da fusão do que de bom foi encontrado nesses autores,
e acrescentamos, é claro, nossa contribuição.
Após a construção do diagrama de caso de uso é necessário que todos os
casos de uso, sem exceção, sejam descritos. Tal descrição servirá tanto para
validar a existência ou não do caso de uso, como permitirá a consolidação do
conhecimento do analista em relação ao funcionamento do mesmo.
A seguir, a Figura 8 apresenta o modelo principal que será utilizado neste
caderno.

15.
15
3.2 Componentes
Embora represente a “parte textual” do diagrama de Caso de uso a descrição do
diagrama de caso de uso também é formada por componentes. São eles:
Nome do Caso de Uso – descrição do Nome do caso de uso correspondente
ao nome do diagrama.
Sigla – é uma forma de denominar o caso de uso, tornando mais fácil sua
referência. Por exemplo: UC001
Objetivo – é seção na qual deverá ser descrita qual o objetivo do caso de
uso;
Ator(es) – identifica qual ator(es) irão interagir com o caso de uso que
está sendo descrito.
Pré condição – descreve as restrições que devem ser obedecidas para a
execução do caso de uso.
Pós Condição – descreve o que deverá ocorrer no sistema após a execução
do caso de uso. É importante tomar o cuidado para descrever
somente aquilo que de fato irá impactar no sistema e, de
preferência, aquilo que tem influência direta nas regras de
negócio.
Fluxo – é o principal componente de uma descrição de caso de caso de uso.
Representa a seqüência de passos a serem seguidos e está
classificado em: Fluxo Principal (ou Básico), Sub Fluxo, Fluxo
Alternativo e Fluxo de Exceção (ou de erro);

16.
16
A seguir detalharemos os fluxos e suas aplicabilidades.
3.2.1 Fluxo Principal ou Básico
Descreve o “caminho ótimo” do caso de uso, ou seja, descreve a principal ação
do caso de uso sem se preocupar com exceções ou quaisquer outros detalhes que
possam interferir no resultado do mesmo. Por exemplo, se um usuário do sistema
aciona a função “Emprestar Livros”, devemos descrever o fluxo principal supondo
que tudo ocorreu de forma perfeita para que o empréstimo pudesse ser
efetivado, ou seja o cliente sempre estará com situação OK, o livro sempre
estará disponível, etc.
3.2.2 Sub-fluxo (SF)
Descreve uma parte do fluxo principal. Representa uma seqüência de passos
que serão SEMPRE executados, porém são tratados de forma separada para
tornar a descrição do fluxo principal mais simples. Por exemplo, veja a descrição
do caso de uso Emprestar Livros temos o sub-fluxo Calcular data da devolução, o
qual é sempre executado, ou seja, toda vez que um empréstimo for realizado o
prazo para devolução deverá ser feito. Considerando que esse prazo é diferente
para alunos e professores, fica mais apresentável e mais fácil de entender se
colocarmos a descrição do cálculo do prazo à parte, conforme podemos ver nos
exemplos 1 e 2, em que é apresentado o cálculo do prazo no fluxo principal e fora
do fluxo principal respectivamente.
Exemplo 2: Usando sub-fluxo
Fluxo Principal
2. Este caso de uso se inicia quando o ator selecionar a opção Empréstimos.
3. O SisBiblio exibe a Tela Empréstimos.
4. O ator aciona o comando Buscar CLIENTE.
5. O SisBiblio realiza o Caso de Uso CONSULTAR CLIENTE(UC04)
6. O sistema valida o status do cliente como OK
7. O SisBiblio preenche o campo CLIENTE de acordo com a pesquisa realizada

17.
17
8. O SisBiblio habilita a opção Adicionar Livros.
9. O ator aciona o comando Adicionar Livro.
10. O SisBiblio realiza o Caso de Uso CONSULTAR LIVRO(UC05)
11. O sistema valida o status do exemplar como ‘D’ (disponível)
12. O SisBiblio apresenta os dados (nome do livro e autor) a serem emprestados
13. Se o cliente desejar emprestar mais de um livro O SisBiblio repete os passos de 8 a
11 atendendo a regra de 3 livros para alunos e 5 para professores.
14. O SisBiblio realiza o subfluxo CALCULAR DATA DEVOLUÇÃO (SF01)
15. O ator confirma a operação.
16. O SisBiblio salva os dados do empréstimo.
17. O SisBiblio atualiza a situação do exemplar para 'E' (emprestado).
18. O SisBiblio realizar o subfluxo ATUALIZAR STATUS CLIENTE (SF02)
19. O SisBiblio realiza o caso de uso EMITIR COMPROVANTE DE EMPRÉSTIMO
(UC06)
20. Este caso de uso se encerra.
SubFluxo ATUALIZAR STATUS CLIENTE (SF02) ref UC02(17)
Precondição:
Passos:
1. SE Cliente for um aluno
SE quantidade de livros emprestados < 3
sistema atualiza o status do cliente para EI (empréstimo Incompleto)
SENÃO
sistema atualiza o status do cliente para EC (empréstimo Completo)
SENÃO (se cliente for professor)
SE quantidade de livros emprestados < 3
sistema atualiza status do cliente para EI (empréstimo Incompleto)
SENÃO
o sistema atualiza o status do cliente para EC (empréstimo Completo)
2. Este subfluxo se encerra
SubFluxo CALCULAR DATA DEVOLUÇÃO (SF01) ref UC02(13)
Precondição: Deve haver pelo menos um livro para empréstimo.
Passos:
1. SE o cliente for PROFESSOR
O SisBiblio calcula 3 dias para a devolução a partir da data do empréstimo
SE o Cliente for do tipo ALUNO
O SisBiblio calcula 2 dias para a devolução a partir da data do empréstimo
2. O SisBiclio preenche o campo Prazo para Devolução com a data calculada;
3. Este subfluxo se encerra.
Exemplo 2: Sem sub-fluxo
Fluxo Principal
1. Este caso de uso se inicia quando o ator selecionar a opção Empréstimos.
2. O SisBiblio exibe a Tela Empréstimos.
3. O ator aciona o comando Buscar CLIENTE.
4. O SisBiblio realiza o Caso de Uso CONSULTAR CLIENTE(UC04)
5. O sistema valida o status do cliente como OK
6. O SisBiblio preenche o campo CLIENTE de acordo com a pesquisa realizada
7. O SisBiblio habilita a opção Adicionar Livros.
8. O ator aciona o comando Adicionar Livro.
9. O SisBiblio realiza o Caso de Uso CONSULTAR LIVRO(UC05)
10. O sistema valida o status do exemplar como ‘D’ (disponível)
11. O SisBiblio apresenta os dados (nome do livro e autor) a serem emprestados
12. Se o cliente desejar emprestar mais de um livro O SisBiblio repete os passos de 8 a 11 atendendo
a regra de 3 livros para alunos e 5 para professores.
13. SE o cliente for PROFESSOR
O SisBiblio calcula 3 dias para a devolução a partir da data do empréstimo
SE o Cliente for do tipo ALUNO

18.
18
O SisBiblio calcula 2 dias para a devolução a partir da data do empréstimo
14. O SisBiclio preenche o campo Prazo para Devolução com a data calculada;O ator confirma a
operação.
15. O SisBiblio salva os dados do empréstimo.
16. O SisBiblio atualiza a situação do exemplar para 'E' (emprestado).
17. SE Cliente for um aluno
SE quantidade de livros emprestados < 3
sistema atualiza o status do cliente para EI (empréstimo Incompleto)
SENÃO
sistema atualiza o status do cliente para EC (empréstimo Completo)
SENÃO (se cliente for professor)
SE quantidade de livros emprestados < 3
sistema atualiza status do cliente para EI (empréstimo Incompleto)
SENÃO
o sistema atualiza o status do cliente para EC (empréstimo Completo)
18. O SisBiblio lê os dados do exemplar para qual foi o empréstimo foi registrado
19. O SisBiblio lê os dados do usuário que fez o empréstimo.
20. O SisBiblio monta o comprovante de empréstimo.
21. O SisBiblio envia comprovante montado para dispositivo de impressão.
22. Este caso de uso se encerra.
Conforme pode ser observado no Exemplo 2 a descrição do fluxo principal
se torna maior e mais complexa, uma vez que trata de todos os casos de uma
única vez, enquanto que a leitura do fluxo principal do Exemplo 1 fica mais fácil
de enteder.
3.2.3 Fluxo Alternativo (FA)
O Fluxo alternativo representa um caminho opcional para o usuário que
está interagindo, ou seja, caso ele não queira seguir o caminho principal (básico)
ele tem a alternativa de seguir outro caminho. Por exemplo, no caso de uso
Manter Livros do Sistema de Biblioteca (ver capítulo 2), o Fluxo Alternativo
Remover Livro propõe uma alternativa ao usuário, caso queira, de retirar um dos
livros de sua lista.
Outro exemplo complementar pode ser visto em um sistema de vendas, em
que se pode ter o fluxo principal como pagamento à vista, dando opções
(alternativas) para que se possa efetuar pagamentos a prazo, no cartão de
crédito ou débito.
Exemplo Prático:
Fluxo alternativo REMOVER LIVRO (FA01) ref UC02(10)
Precondição: O usuário acionou o comando Remover Livro.
Passos:
1. O SisBiblio exibe pergunta se o ator deseja confirmar a remoção do livro da lista de
empréstimo.
2. O usuário confirma a remoção
3. O SisBiblio retira o livro da lista de livros emprestados.
4. Este fluxo se encerra

19.
19
5. O sistema retorna para o passo 6 ou para o passo 10 do fluxo principal, de acordo com a
opção do ator.
Fluxo de Exceção ou Erro (FE)
O Fluxo de Exceção ou Erro tem como finalidade descrever como o
sistema deverá tratar erros que poderão ocorrer no fluxo principal ou em nos
fluxos alternativos e sub-fluxos, ou seja, o fluxo de exceção descreve algo que
interferiu no caminho ótimo mas que foi tratado pelo sistema. Por exemplo, a
situação do cliente não está OK e este não poderá efetuar um empréstimo ou
ainda, o livro desejado não está disponível.
Exemplo Prático:
Fluxo de Exceção CLIENTE COM TOTAL DE LIVROS COMPLETO (FE01) ref UC02(5)
Pré-condição: O cliente selecionado já está com a quantidade máxima de livros emprestados.
Passos:
23. O SisBiblio exibe um aviso dizendo que o cliente selecionado não pode efetuar empréstimos
porque já alcançou a quantidade total permitida.
24. Este fluxo se encerra
25. O SisBiblio encerra o Caso de Uso.
Regras de Negócio (RE)
As regras de negócio referem-se às principais regras que regem o caso de uso. A
seguir serão apresentados alguns exemplos de regras de negócio para o caso de
uso Emprestar Exemplar:
RE01 – Só poderão ser emprestados os exemplares que estivem com o status ‘D’
(disponível);
RE02 - Só poderão fazer empréstimos os clientes que estiverem com o status
‘OK’ ou ‘EI’ (empréstimo incompleto);
RE03 – A data para devolução do empréstimo deverá ser calculada como 3 dias
após a data corrente para cliente aluno e 4 dias para cliente professor.
3.3 Notação para descrição de casos de uso
A Figura 3.1 apresenta um exemplo completo da descrição de um caso
de uso, no qual, além das seções já comentadas tais como sub-fluxo, fluxo
alternativo etc, podemos verificar uma codificação do tipo FA01 ref UC01

20.
20
(2,5), cuja leitura é Fluxo Alternativo 01 referente ao Caso de Uso 01, passos
2 e 5.
Caso os passos referenciados representem um intervalo os mesmo
podem ser representados como n..m, em que n significa a ordem do menor
passo e m a ordem do maior passo. Por exemplo, SF01 ref UC02(3..7), lê-se
Sub-Fluxo 01 referente ao Caso de Uso 02 passos de 3 a 7. Vale ressaltar
que a referência pode ser tanto só do fluxo principal, quanto de um subfluxo,
fluxo alternativo, de exceção ou de todos ao mesmo tempo.
Importante ressaltar que a seqüência numérica para identificar sub-
fluxos, fluxos alternativos e fluxos de exceção é específica para cada grupo
desses fluxos. Dessa forma, podemos ter, por exemplo,FA01, FA02, SF01,
SF02, FE01 e FE02 na descrição de um caso uso.
3.4 Relacionamento com diagramas
A descrição dos casos de uso é um importante recurso, pois permite
que tenhamos uma visão detalhada da funcionalidade. Sendo assim, enquanto
o diagrama de caso de uso só permite a visão de QUAIS funcionalidades
existem no sistema, a descrição de caso de uso permite a visão de COMO as
mesmas funcionam.
Considerando o nível de detalhe das funcionalidades na descrição de
casos de uso, este recurso dá suporte para validação dos seguintes
diagramas:
• Seqüência – permitirá que a seqüência de passos definida na
descrição do caso de uso seja feita de forma gráfica no referido
diagrama, mostrando, inclusive, quais as classes do Diagrama de
Classes contemplarão os dados tratados pelo caso de uso.

21.
21
• Atividade – também permitirá que os passos definidos na
descrição do caso de uso sejam representados graficamente no
referido diagrama.
• Classes – pela descrição dos casos de usos será possível
identificar tanto os dados a serem armazenados (persistidos),
através do que foi inserido ou recuperado pelos atores, ou ainda
através dos dados necessários para efetuar alguma operação,
quanto os métodos das classes, mediante algumas
funcionalidades que deverão ser executadas pelo sistema. Por
exemplo, na Figura poderemos mapear a classe Vdf e os
atributos fffh com os métodos jdjd.
3.5 Dicas
Um sub-fluxo pode ser comparado a um procedimento/função
(procedure/function), representando um desvio para se executar
algo a parte e depois voltar para o programa principal (fluxo
principal no nosso caso);
Uma diferença entre um sub-fluxo e um fluxo alternativo é que o
fluxo alternativo representa, na maioria das vezes, uma opção de
escolha do usuário, isto é, uma escolha manual, e um sub-fluxo
representa uma escolha do sistema, ou seja, uma escolha
automática.

22.
22
Figura 3.1 – Modelo para descrição de casos de uso
Objetivo:
Caso de Uso: Sigla:
Fluxo Básico:
1. Descrição do passo 1
2. Descrição do passo 2
3. …
4. Descrição do passo n
Sub Fuxo (SFXX) ref YYY-N:
1. Descrição do passo 1
2. Descrição do passo 2
3. …
4. Descrição do passo n
Fluxo Alternativo (FAXX) ref YYY-N:
1. Descrição do passo 1
2. Descrição do passo 2
3. …
4. Descrição do passo n
Fluxo de Exceção (FEXX) ref YYY-N, FAXX-2,5:
1. Descrição do passo 1
2. Descrição do passo 2
3. …
4. Descrição do passo n
Pré Condição:
Pós Condição:
Regras de Negócio: Opcional
Texto livre

23.
23
Capítulo 4
Diagrama de Classes
4.1 Conceito
O diagrama de classes é um dos diagramas estáticos da UML e tem por
objetivo apresentar as classes do domínio do problema e os relacionamentos
entre as mesmas.
Mas o que são classes? As classes agrupam um conjunto de entidades do
mundo real que possuem as mesmas características. Essas entidades são
conhecidas como objetos. Além disso, as classes servem como um molde para
a criação de novos objetos do mesmo tipo.
Para exemplificar estes conceitos, suponha fabricação de um determinado
tipo de peça X. Todas as peças deste mesmo tipo devem ter as mesmas
características. Portanto, precisam de um molde para serem construídas.
Desta forma, fazendo uma analogia ao conceito de classes e objetos, o
molde usado para fabricar a peça X corresponde ao que chamamos de classe e
cada peça fabricada (X1, X2, X3, etc.) corresponde a um objeto produzido a
partir deste molde.
Para um exemplo mais prático dos conceitos vistos nos parágrafos
anteriores, vamos analisar o domínio de problema do Sistema de Biblioteca
apresentado nesse caderno universitário.
Nesse domínio de problema, observamos que uma biblioteca dispõe de
diversos livros, cujos dados devem ser armazenados na base de dados do
sistema. Portanto, Livro é uma classe do sistema com as seguintes
características: título, ano de publicação, editora, edição, etc.
Comentado [c1]: Glossário

24.
24
Cada livro existente na biblioteca (com seu próprio título, ano de
publicação, editora, etc.) é um objeto da classe Livro. Além disso, supondo que
um novo livro seja comprado e precise ser cadastrado no sistema, deverá ter
as mesmas características que os demais. Assim, o molde para a sua criação
será a classe Livro.
Dando continuidade ao conceito de diagrama de classes, como vemos nas
disciplinas de banco de dados, os dados só têm sentido em uma base de dados
quando estão interligados. Portanto, um diagrama de classes deve representar
além das classes do sistema, os relacionamentos entre as mesmas.
É importante ressaltar que este diagrama pode ser elaborado em duas
fases do desenvolvimento de um software: na fase de análise e na fase de
projeto.
Na fase de análise, este diagrama é usado para representar as classes do
domínio do problema, cujos dados devem ser armazenados na base de dados
do sistema.
Em relação à fase de projeto, pode-se dizer que o mesmo é usado
representar não apenas as classes que contêm os dados a serem armazenados,
mas também outros tipos de classe necessários à implementação software, as
quais são conceituadas na seção 4.3.4.
A seguir, são detalhados os componentes deste diagrama, bem como
apresentadas algumas noções de como construir o diagrama de classes a
partir do diagrama de casos de uso.
4.2 Componentes
Os componentes do diagrama de classes são apenas dois: classes e
relacionamentos. Esses componentes são detalhados a seguir.

25.
25
4.3 Classes
De um modo geral, as classes são compostas por seus atributos e seus
métodos, sendo representadas por uma “caixa” com três compartimentos,
como mostra a (Figura 4.1).
O primeiro compartimento, de cima para baixo, é utilizado para apresentar
o nome da classe. Por padrão, os nomes das classes devem ser formados por
substantivos, começando com letra maiúscula. Ex.: Livro,
MovimentaçãoExemplar, Usuário, etc.
Nesse compartimento também identificamos o esteriótipo da classe, ou
seja, o tipo da mesma, o qual pode ser: entidade (entity), fronteira (boundary)
e controle (control). Estes tipos serão detalhados na seção 4.3.4. Vale
ressaltar que o esteriótipo da classe pode ser omitido.
O compartimento central é reservado para a declaração dos atributos da
classe. Os nomes dos atributos, por padrão, devem iniciar com letra minúscula.
Caso seja formado por mais de uma palavra, as palavras subseqüentes devem
iniciar com letra maiúscula. Além disso, siglas devem permanecer inalteradas.
Ex.: nome, situação, dataValidade, ISBN, etc.
Finalmente, o terceiro compartimento destina-se à declaração dos
métodos da classe. A nomenclatura para métodos segue o mesmo padrão
adotado para nomes de atributos. A diferença é que nomes de atributos são
compostos por substantivos, enquanto que nomes de métodos, normalmente,
contêm verbos.
Esteriótipo e nome da classe
Atributos
Métodos
Figura 4.1 - Notação de classe e seus compartimentos.

26.
26
Na Figura 4.1, a classe Exemplar tem o esteriótipo entity (primeiro
compartimento, além dos atributos ISBN, situação e tipoConsulta
apresentados no segundo compartimento. Quanto aos métodos da classe
inserir(), excluir(), alterar() e pesquisar() são listados no último
compartimento.
4.3.1 Atributos
Os atributos representam as características que os objetos de uma classe
possuem. Em outras palavras, descrevem os dados a serem armazenados pelos
objetos de uma classe. Ex.: todo objeto da classe Usuário deve ter um login,
uma senha, uma situação, um número de matrícula e um e-mail.
Além de um nome, um atributo deve ter um tipo e sua visibilidade. O tipo de
um atributo pode ser primitivo (ex.: inteiro, real, String, etc.) ou de um tipo
complexo.
Os tipos complexos são tipos baseados em outras classes. No exemplo
apresentado na Figura 4.2, o atributo autores da classe Livro é uma lista de
objetos do tipo Autor. Cada objeto dessa lista possuir um código e um nome.
Figura 4.2 – Classe Livro com um atributo de tipo complexo.

27.
27
4.3.2 Métodos
Os métodos correspondem às ações que os objetos de uma classe podem
realizar. Em outras palavras, são os serviços que uma classe oferece. Ex.: a
classe Usuário sabe como realizar as operações de revogar login, alterar senha,
além de inserir e alterar usuários. Qualquer outra classe que precise de um
desses serviços, deve solicitá-lo à classe Usuário.
Um método é definido por sua assinatura. A assinatura de um método é
composta por seu nome, seus parâmetros de entrada e de saída.
Os parâmetros de entrada (que pode ser mais de um) correspondem aos
valores que devem ser passados quando o método é chamado, para que o mesmo
possa ser executado. Enquanto que o parâmetro de saída (deve ser no máximo
um) refere-se ao resultado retornado pela operação após sua execução.
Existem casos em que o método não necessita de parâmetros de entrada.
Nessa situação, no lugar dos parâmetros devem ser exibidos apenas os
parênteses aberto e fechado (sem nada entre os mesmos). Já a ausência do
parâmetro de saída deve ser expressa por meio da palavra reservada void.
4.3.3 Visibilidade de Atributos e Métodos
A visibilidade indica onde um atributo ou um método pode ser acessado
dentro do sistema. Existem três tipos de visibilidade propostos na UML:
Nome do método Parâmetro de entrada Parâmetro de saída
pesquisarTitulo (titulo: String) : Livro
Sem parâmetro de entrada Sem parâmetro de saída
cancelarMovimentacao ( ): void

28.
28
• Privado (private) – indica que um atributo ou método só pode ser
visualizado e acessado dentro da própria classe. Na UML, a visibilidade
private é representada pelo símbolo “-”.
• Público (public): um atributo ou método definido como público é visível
por qualquer por qualquer classe. É importante comentar que é preciso
ter muito cuidado ao definir um atributo como public, pois você estará
“dizendo” que qualquer outra classe pode alterar o valor do mesmo. Mas
por que isso é um problema? Suponha o atributo valorMulta da classe
Débito, o qual deve ser calculado antes de inserido. Imagine que seja
definido como public e que, portanto, outra classe qualquer, como
Empréstimo pode alterar seu valor. Porém, a única classe que sabe como
calcular este valor é a classe a qual o mesmo pertence. Desta forma, a
classe Empréstimo pode inserir um valor incorreto neste atributo. A
notação para representar essa visibilidade é o símbolo “+”.
• Protegido (protected): um atributo ou método com visibilidade protegido
pode ser acessado pela própria classe ao qual o mesmo pertence e por
suas subclasses. É utilizado em relacionamentos de herança para
permitir que os atributos e métodos da superclasse possam ser
acessados pelas subclasses. É importante destacar que o inverso não é
verdadeiro, ou seja, os atributos e métodos das subclasses com
visibilidade protected não são acessíveis na superclasse. A visibilidade
protected é representada na UML pelo símbolo “#”.
A Figura 4.3 apresenta um exemplo da notação desses três tipos de visibilidade
de atributos e métodos na classe MovimentaçãoExemplar.
Atributo privado
Atributo protegido
Atributo público
Método público
Método protegido
Método privado
Figura 4.3 - Representação de atributos e métodos privados, públicos e protegidos.

29.
29
Para representar a utilização dos atributos e métodos da classe
MovimentaçãoExemplar de acordo com a sua visibilidade, a Figura 4.4 apresenta
um exemplo, escrito em pseudo-código, utilizando as classes Reserva (subclasse
de MovimentaçãoExemplar) e Livro.
Classe Livro{
privado String titulo;
privado ArrayList[Autor] autores;
privado int anoPublicacao;
privado String editora;
privado int nroPagina;
publico inserir() {
<implenentação>
movimentação = new
MovimentacaoExemplar();
movimentacao.dataHora =
‘23/04/08’;
movimentacao.inserir();
}
}
Classe MovimentacaoExemplar {
privado int código;
público Datetime dataHora;
protegido int situacao;
público inserir(){
<implementação>
}
protegido cancelarMovimentacao()
{
<implementação>
}
privado alterar()
{
<implementação>
}
}
Classe Reserva extends
MovimentacaoExemplar {
privado Date dataValidade;
público inserir(){
<implementação>
situacao = 2;
}
público alterar(){
<implementação>
cancelarMovimentacao();
}
}
Figura 4.4 – Pseudo-código com o uso de atributos e métodos privados, públicos e protegidos.
Nos exemplos apresentados nas Figura 4.3 e Figura 4.4, o atributo público
“dataHora” da classe “MovimentaçãoExemplar” pode ter seu valor alterado pela
classe Livro. Além disso, o método inserir() também pode ser chamado a partir da
classe Livro, por ter visibilidade pública.

30.
30
Em relação ao atributo “situacao” e ao método “cancelarMovimentacao()”,
ambos com visibilidade protected só podem ser acessados na própria classe
“MovimentaçãoExemplar” e na sua subclasse “Reserva”. Finalmente, o atributo
“codigo” e o método “alterar()” só podem ser acessados dentro da classe ao qual
pertencem.
4.3.4 Tipos de Classes
Como descrito na introdução deste capítulo, é por meio do diagrama de
classes que o desenvolvedor irá definir os dados que deverão ser armazenado no
banco de dados.
Entretanto, pensar que este diagrama deve ser usado apenas com essa
finalidade é uma maneira de subutilizá-lo, uma vez que um software é composto
não apenas por classes que representam os dados a serem armazenados no banco
de dados, mas também por outras classes que participam do processamento do
software e por aquelas que fazem o papel de intermediárias entre outras classes.
Estas também devem ser representadas, com o intuito de documentar o sistema
integralmente.
Dessa forma, o diagrama de classes pode representar três tipos de classes.
São elas:
a) Classes de entidade (Entity) – são entidades do mundo real relevantes para
o domínio do problema, sendo seu principal papel representar os dados a
serem armazenados pelo sistema. Por exemplo: Livro, Exemplar, Autor,
etc.
b) Classes de controle (Control) – sua principal função é controlar a execução
de processos. Normalmente, os métodos de uma classe dessa natureza
controlam transações que envolvem várias classes de entidade. Ex.:

31.
31
suponha que para realizar um empréstimo na biblioteca, primeiramente,
devem ser inseridos os dados gerais do empréstimo (método
inserirEmprestimo() é chamado) e inserir cada exemplar emprestado
(método inserirItemEmprestimo() é chamado). Como se pode concluir,
nesta única transação, é necessário chamar tanto métodos da classe
Empréstimo quanto métodos da classe ItemEmpréstimo. Assim, o controle
dessa transação, envolvendo mais de uma classe de entidade, ficaria a
cargo de uma classe de controle. O padrão de projeto Facade (Fachada) é
implementa classes de controle.
c) Classes de fronteira (Boundary) – responsáveis pela comunicação entre o
mundo externo (atores) e as classes de controle. Normalmente, são
implementadas na forma de interfaces gráficas (telas). Exemplo: Tela de
Cadastro de Livros, Tela de Empréstimo de Exemplares.
Vale ressaltar que, esses dois últimos tipos de classes são, normalmente,
especificados na fase de projeto do sistema. Assim, como o enfoque desse
caderno universitário é apresentar o uso dos diagramas da UML na fase de
análise, daremos ênfase apenas às classes de entidade.
4.4 Relacionamentos
Os relacionamentos representam a forma como as classes de um sistema
interagem entre si. Duas ou mais classes podem se associar por meio de quatro
tipos de relacionamentos, os quais são: associações, todo-parte, herança e
dependência.
4.4.1 Associações
De um modo geral, as associações descrevem um vínculo existente entre
duas classes, sendo conhecidas como associações binárias. Para exemplificar este
tipo de relacionamento, considere as classes Aluno e Curso. De acordo com o

32.
32
domínio de problema, um aluno deve estar matriculado em um curso, ou seja,
existe um vínculo entre essas classes, como mostrado na Figura 4.5.
Esse tipo de associação também pode ser aplicado entre uma classe e ela
mesma. Neste caso, a associação é chamada reflexiva. Suponha uma classe
Funcionário, a qual não consta no nosso domínio de problema. Sabendo que um
funcionário pode gerenciar outros funcionários, temos uma associação reflexiva,
como mostra a Figura 4.6.
Quando uma associação vincula mais de duas classes, é conhecida como
associação n-ária, onde n é substituído pelo prefixo que indica a quantidade de
classes vinculadas. Assim, caso seja uma associação entre três classes, é
chamada de associação ternária, entre quatro classes, quaternária e assim por
diante.
Figura 4.5 – Associação entre as classes Aluno e Curso.
Figura 4.6 – Exemplo de associação reflexiva.

33.
33
Outro conceito importante é o de classe de associação ou classe
associativa. Se você é familiarizado ao Modelo Entidade-Relacionamento, irá
recordar que é possível que um relacionamento entre conjuntos de entidades
tenha atributos. Entretanto, quando se trata do diagrama de classes, não é
possível que uma associação tenha atributos, uma vez que esta é uma
característica exclusiva das classes.
Mas então como representar que uma associação entre duas classes possui
atributos? Isso é feito no diagrama de classes por meio de classes de
associações. Em outras palavras, cria-se uma classe a partir de um
relacionamento e nesta são incluídos os atributos e métodos da associação, como
exemplificado na Figura 4.7.
Note que os objetos da classe MovimentaçãoExemplar só existem quando
as classes Exemplar e Usuário se relacionam. Em outras palavras, uma
movimentação de exemplar só é criada quando um usuário reserva, empresta ou
devolve um exemplar.
4.4.2 Todo-parte
Figura 4.7 – Exemplo de classe de associação.

34.
34
Um relacionamento do tipo todo-parte indica que os objetos da classe A
(todo) são compostos por objetos da classe B (parte). Para exemplificar este
conceito, suponha um carro, o qual é formado por diversas peças. O carro
representa o todo e suas peças representam as partes que o compõe.
Existem dois tipos de relacionamento todo-parte: agregação e composição.
A agregação representa um relacionamento todo-parte, cuja característica
principal é que as partes podem continuar existindo mesmo que o todo deixe de
existir. Imagine uma agregação entre as classes Livro (todo) e Exemplar (parte).
Este tipo de relacionamento indica que cada objeto de Livro é formado por
exemplares. Entretanto, caso um livro deixe de existir, seus exemplares podem
continuar existindo no sistema.
Como apresentado na Figura 4.8, a agregação é representada por uma linha
com um losango sem preenchimento em uma das pontas. Este losango deve ficar
na extremidade da classe que representa o todo do relacionamento. O
relacionamento ilustrado nessa figura deve ser lido da seguinte forma: um livro é
composto1 por exemplares.
1
Embora seja um relacionamento todo-parte de agregação, utilizamos o verbo “composto” para lê-lo.
Figura 4.8 – Relacionamento de agregação entre as classes Livro e Exemplar.

35.
35
Entretanto, sabemos que não faz sentindo um exemplar continuar
existindo se o livro ao qual está relacionado for excluído. Assim, a composição,
que é um relacionamento todo-parte um pouco mais rígido, se aplicaria melhor a
esta situação, pois as partes não continuam existindo se o todo for excluído. A
notação da agregação é uma linha com um losango preenchido, o qual deve ficar na
extremidade da classe que representa o todo do relacionamento.
A leitura desse relacionamento é feito da mesma forma que a leitura de uma
agregação, ou seja, um livro é composto por exemplares.
4.4.3 Herança
Antes de iniciar a explicação do conceito de herança empregada no
diagrama de classes, vamos entender o conceito de herança proposto pela
genética.
De acordo com o estudo da genética, quando uma criança nasce, ela traz o
que se chama de carga genética de seus pais. Em outras palavras, a criança herda
as características de seus pais. Entretanto, como a criança não é simplesmente
Figura 4.9 – Relacionamento de composição entre as classes Livro e Exemplar.

36.
36
uma cópia de seus pais, além de herdar as características dos mesmos, ela
também tem suas próprias características.
No diagrama de classes, esse mesmo conceito também pode ser aplicado,
de forma que uma classe (subclasse) pode herdar todas as características de
outra classe (superclasse) e ainda ter suas características próprias. Vale
ressaltar que, quando se trata de uma classe, as características herdadas podem
ser tanto atributos quanto métodos.
No exemplo ilustrado na Figura 4.10, as subclasses Professor e Aluno
herdam todas as características (atributos e métodos) da superclasse Usuário,
além de ter suas características próprias. Em outras palavras, para se cadastrar
um aluno devem ser informados os seguintes dados: login, senha, situação,
matrícula, e-mail e indicar se o aluno é bolsista ou não.
É importante destacar que uma subclasse representa um tipo da
superclasse. Na Figura 4.10, podemos dizer que as subclasses Professor e Aluno
são tipos de Usuário.

37.
37
4.4.4 Dependência
Este tipo de relacionamento é usado para representar, como o próprio
nome sugere, que uma classe, chamada de cliente, depende de outra classe, a
qual é chamada de fornecedora. Desta forma, uma alteração na estrutura da
classe fornecedora pode afetar o funcionamento da classe cliente.
Como dica, um relacionamento de dependência é indicado quando a classe
fornecedora é usada como parâmetro de um método da classe cliente ou quando a
classe fornecedora é usada como o tipo de um atributo da classe cliente,
conforme apresentado na Figura 4.11 e na Figura 4.12.
Autor é usado como
tipo de um atributo na
classe Livro
Classe Fornecedora
Classe Cliente
Figura 4.10 – Relacionamento de herança entre Usuário, Professor e Aluno.
Figura 4.11 – Relacionamento de dependência entre as classes Autor e Livro.

38.
38
Na Figura 4.11, o tipo do atributo “autores” da classe Livro é uma lista de
objetos do tipo Autor. Portanto, podemos dizer que a classe Livro (cliente) é
dependente da classe Autor (fornecedora).
Na Figura 4.12, a classe Devolução é usada como parâmetro de entrada de
um método da classe Débito. Assim, podemos representar que a classe Débito
(cliente) é dependente da classe Devolução (fornecedora).
Como apresentado nas Figuras 4.11 e 4.12, a dependência é representada na
UML por uma linha tracejada com uma seta na extremidade. A seta deve apontar
para a classe fornecedora.
4.5 Multiplicidade e Participação
Quando relacionamos duas ou mais classes, devemos especificar além do tipo do
relacionamento, a multiplicidade e a participação.
4.5.1 Multiplicidade
A multiciplicidade indica quantos objetos de uma classe pode se relacionar
com objetos de outra classe. Existem três tipos de multiplicidade. São elas:
Figura 4.12 – Relacionamento de dependência entre as classes Devolução e Débito.
Devolução é usada
como parâmetro de
um método da classe
Débito
Classe Cliente
Classe Fornecedora

39.
39
• Um-para-um: especifica que cada objeto da classe A só pode estar
relacionado a no máximo um objeto da classe B, conforme ilustrado na
Figura 4.13.
No nosso sistema de biblioteca, um exemplo de relacionamento um-
para-um ocorre entre as classes Reserva e Empréstimo, como mostrado na
Figura 4.14, no qual uma reserva está associada a nenhum (representado
pelo zero) ou no máximo um empréstimo e um empréstimo está associado a
nenhuma ou no máximo uma reserva. Observe que as setas indicam o
sentido da leitura.
A1
A2
A3
B1
B2
Figura 4.13 – Representação de relacionamento um-para-um.
Figura 4.14 – Relacionamento um-para-um entre as classes Reserva e Empréstimo.
Um empréstimo associa-se a nenhuma ou uma reserva
Uma reserva associa-se a nenhum ou um empréstimo

40.
40
• Um-para-muitos: este tipo de multiplicidade indica que cada objeto da
classe A pode estar relacionado a nenhum, a um ou a muitos objetos da
classe B. Porém, cada objeto da classe B só pode estar associado a no
máximo um objeto da classe A (Figura 4.15).
A Figura 4.16 ilustra um exemplo prático de relacionamento um-
para-muitos entre as classes Aluno e Curso, em que temos que um aluno
está associado a um único curso, porém um curso pode estar vinculado a
vários alunos.
• Muitos-para-muitos: este tipo de multiplicidade indica que cada objeto da
classe A pode estar relacionado a nenhum, a um ou a muitos objetos da
classe B e vice-versa, conforme ilustrado na Figura 4.17.
A1
A2
A3
B1
B2
B3
A1
A2
A3
B1
B2
B3
Um aluno associa-se a um curso
Curso associa-se a nenhum, um ou vários alunos
Figura 4.15 – Representação de relacionamento um-para-muitos.
Figura 4.16 – Relacionamento um-para-muitos entre as classes Aluno e Curso
Figura 4.17 – Representação de relacionamento muitos-para-muitos.

41.
41
A Figura 4.18 apresenta um exemplo de relacionamento muitos-para-
muitos ocorre entre as classes Livro e Usuário no nosso domínio de
problema.
4.5.2 Participação
A participação indica se os objetos de uma classe devem ou não se
relacionar obrigatoriamente aos objetos de uma outra classe. Como exemplo,
vamos tomar o relacionamento entre as classes Aluno e Curso.
Aluno deve estar vinculado a um e somente um curso
Curso pode estar vinculado a nenhum, um ou a vários alunos
Um exemplar associa-se a nenhuma, um ou vários usuários
Um usuário associa-se a nenhum, um ou vários exemplares
Figura 4.18 – Relacionamento muitos-para-muitos entre as classes Exemplar e Usuário.
Figura 4.19 – Exemplo de participação total e parcial.

42.
42
Conforme podemos observar na Figura 4.19, temos que um aluno deve
obrigatoriamente estar vinculado a um curso, ou seja, quando um aluno é
cadastrado, deve ser informado o curso ao qual o mesmo pertence.
Por outro lado, um curso, quando cadastrado, não necessariamente precisa
estar associado a um aluno. Desta forma, dizemos que o Curso tem participação
parcial (representada pelo zero) e o Aluno tem participação total (omite-se o
zero) no relacionamento.
4.6 Como elaborar um diagrama de classes?
Dentre as principais dúvidas dos desenvolvedores iniciantes, uma das mais
marcantes é como aplicar os conceitos vistos ao longo desse capítulo para
elaborar o diagrama de classes.
Para elaborar o diagrama de classes de um sistema, um bom ponto de partida
é o diagrama de casos de uso. Mas como utilizar o diagrama de casos de uso para
extrair as informações necessárias para a construção do diagrama de classes?
Existem algumas dicas para realizar esta tarefa, as quais serão descritas nesta
seção.
1. Identifique todos os atores cujos dados realmente precisem ser
armazenados na base de dados do sistema. Mapeie cada ator para
uma classe. Caso exista relacionamento de herança entre os atores,
este relacionamento também deverá existir nas classes criadas. No

43.
43
nosso domínio de problema, temos seis (06) atores. Entretanto,
destes necessitamos armazenar dados apenas a respeito dos
usuários, os quais podem ser professores ou alunos. Assim, teremos
o mapeamento como ilustrado na Figura 4.20.
2. Liste os casos de uso do tipo “manter”, tais como: Manter livro e
Manter exemplar. Estes casos de uso envolvem as quatro operações
básicas de banco de dados (inserir, excluir, alterar e pesquisar),
conseqüentemente, devemos armazenar os dados que os mesmos
manipulam. Assim, iremos mapear as classes correspondentes a
estes UC, que no nosso domínio de problema são Livro e Exemplar,
conforme ilustrado na Figura 4.21.
Figura 4.20 – Exemplo de mapeamento de atores em classes.
Figura 4.21 – Exemplo de mapeamento de casos de uso para classes.

44.
44
3. Liste os casos de uso do tipo “movimentação”, tais como: Emprestar
exemplar, Devolver exemplar, Gerar débito, Reservar exemplar,
Registrar pagamento, Emitir comprovante de empréstimo, Atualizar
situação do exemplar, dentre outros. Esses casos de uso podem ser
mapeados em classes, atributos ou métodos.
Dentre os casos de uso listados, podemos identificar que
empréstimo, reserva e débito devem ser mapeados em classes, uma
vez que possuem características próprias (atributos) que justificam
este mapeamento. Em outras palavas, o sistema de biblioteca
necessita que sejam armazenados os dados de cada empréstimo,
reserva e débito realizados. A Figura 4.22 ilustra as classes
criadas a partir desse mapeamento.
Já casos de uso como Atualizar situação do exemplar, não podem ser
mapeados na forma de uma classe, pois não tem características que
justifiquem isso. Mesmo assim, precisamos armazenar a situação do
exemplar, ou seja, é importante para o sistema saber se um exemplar está
disponível ou não. Desta forma, ao analisarmos um pouco este caso de uso,
como seu próprio nome sugere, situação do exemplar enquadra-se bem
Figura 4.22 – Exemplo de mapeamento de casos de uso de movimentação para classes.
Comentado [Coran2]: A situação é do exemplar e não do Livro.
Verificar quais as situações de um exemplar

45.
45
melhor como um atributo da classe Exemplar do que como uma classe,
como mostrado na Figura 4.23.
Em relação a casos de uso como Emitir comprovante de empréstimo,
devemos nos perguntar: é necessário armazenar dados a respeito do
comprovante ou apenas emiti-lo? Se a resposta for “apenas emiti-lo”, então
este caso de uso deve ser mapeado apenas como um método da classe
Empréstimo, como mostra a Figura 4.24.
Entretanto, quando fazemos uma pergunta semelhante para o caso
de uso Registrar pagamento, a resposta certamente será: precisamos
armazenar dados do pagamento do débito (data do pagamento e valor), mas
também necessitamos representar como este registro será feito. Assim,
devemos mapear este UC como atributos da classe Débito e um método,
como mostrado na Figura 4.25.
Atributo
Atributos
Método
Método
Figura 4.23 – Exemplo de mapeamento de caso deuso para atributo.
Figura 4.24 – Mapeamento de casos de uso para método.

46.
46
Seguindo os passos acima, chegamos a um esqueleto do diagrama de
classes, como representado na Figura 4.26.
Figura 4.25 – Exemplo de mapeamento de caso de uso para atributo e método.
Figura 4.26 – Esqueleto do diagrama de classes do SisBiblio.

47.
47
Mas sabemos que apenas este esqueleto não é o bastante para representar
os dados a serem armazenados. Portanto, podemos concluir que o diagrama de
casos de uso nos direciona na definição das classes do sistema, porém não é
suficiente. Desta forma, devemos fazer uso de outro recurso, que é a descrição
destes casos de uso, para refinar este diagrama.
Com base na descrição dos casos de uso, podemos capturar informações
refinadas a respeito dos atributos das classes, relacionamentos e outros
métodos não identificados por meio da observação do diagrama de casos de uso.
A Figura 4.27 ilustra o diagrama de classes refinado do sistema. Neste
diagrama, podemos observar que as classes Empréstimo e Reserva foram
convertidas em subclasses de uma classe mais generalizada, chamada
Movimentação. Além disso, por meio deste refinamento também foi possível
modelar a classe Exemplar como uma composição de Livro, uma vez que
exemplares podem ser considerados partes de um livro e não faz sentido um
exemplar existir sem estar associado a um livro.

48.
48
Figura 4.27 – Diagrama de classes do SisBiblio.

49.
49
Capítulo 5
Diagrama de Estados
5.1 Conceito
Estamos, constantemente, em nosso cotidiano em contato com objetos que
variam seus estados. Por exemplo, a água com seus estados de sólido, líquido e
gasoso; uma lâmpada possui os estados ligada e desligada; uma jarra pode estar
cheia ou vazia; enfim são inúmeros os objetos no nosso dia-a-dia que podem
mudar de estados a partir de um evento.
Um evento é uma ação que exige a mudança de estado do objeto como
reação. No exemplo da água o evento (ação) “ferver” faz com que a água mude
(reação) do estado líquido para o gasoso, ou ainda o evento “aquecer” fazê-la
mudar do estado sólido para o líquido.

50.
50
Da mesma forma cada objeto participante de um software orientado a
objetos se encontra em um estado particular, podendo esse estado mudar de
acordo com eventos internos ou externos ao sistema.
A mudança de estado de um objeto é denominada transição de estado. Os
estados e as transições de estado de um objeto constituem seu ciclo de vida.
Dessa forma, o diagrama de estados especifica a seqüência de estados
pelos quais um objeto passa durante o seu tempo de vida em resposta a eventos,
juntamente com suas respostas a esses eventos [BRJ].
É comum vermos diagramas de estados para representar os estados de
uma interação do usuário com o sistema por meio de uma interface. Neste caso,
os estados são: aguardando digitação, confirmando operação, exibindo mensagem,
etc. Em nossa abordagem, utilizaremos o diagrama de transição de estados (DTE)
para descrever somente o ciclo de vida de objetos de uma classe, os eventos que
causam a transição de um estado para outro e a realização de operações
resultantes.
5.2 Componentes
O DTE possui dois elementos básicos: os estados e as transições. Sendo
que estas últimas, por sua vez, estão associadas aos conceitos de evento, ação e
atividade.
A seguir descreveremos, com mais detalhes, cada um desses componentes.
5.1.1 Estados
Um estado é uma situação na vida de um objeto durante a qual ele satisfaz
alguma condição ou realiza alguma atividade, tal estado é denominado de estado
ordinário [Bezerra] também chamado de estado simples ou estado

51.
51
regular(Bíblia). Cada estado de um objeto é normalmente determinado pelos
valores de seus atributos e/ou pelas suas associações com outros objetos. Por
exemplo, o objeto livro pode ter o atributo reservado como verdadeiro, ou o
objeto cliente que pode ter o atributo situação com o valor inadimplente.
Além do estado ordinário existem ainda os estados inicial e final.
O estado inicial mostra a partir de onde o diagrama deve ser lido, e indica
o primeiro estado do objeto, ou seja, o estado que o objeto assume assim que é
criado. Dessa forma, um objeto só pode possuir um único estado inicial.
O estado final indica o fim do ciclo de vida de um objeto, ou seja,
representa o último estado pelo qual o objeto passa no sistema, portanto, do qual
nunca poderá sair. Ao contrário do estado inicial pode existir mais de um estado
final no DTE.
A notação para representar um estado é um retângulo com as pontas
arredondadas, podendo ter duas ou três divisões. Na primeira divisão é descrito
o nome do estado, na segunda as possíveis ações ou atividades que um objeto
pode executar quando está em um determinado estado. Já a terceira divisão é
destinada para definir as possíveis transições internas (ver seção 5.1.2). Tanto as
ações ou atividades quanto as transições internas (segunda e terceira divisão)
são opcionais.
A Figura 5.1 apresenta a notação para a representação do estado inicial,
estado ordinário e estado final.
Figura 5.1: Notação para os estados de um objeto
Estado ordinárioEstado inicial Estado final
Nome do estado
Transições Internas
Ações ou atividades

52.
52
5.1.2 Transições
Uma transição corresponde à passagem para mudar de um estado para outro. É
representada por uma seta originada no estado atual e termina no próximo
estado. A Figura 5.2 apresenta a notação para transição.
Figura 5.1: Notação para Transição
Além da transição normal, existem mais dois tipos de transição: interna e
reflexiva (auto-transição).
• Transições internas - são transições que não mudam o estado de um
objeto. Sendo assim, esse tipo de transição é usado somente para
executar uma ação ou uma atividade. A notação para a transição
interna é a mesma das cláusulas entry, do e exit (ver seção 5.2.1.4),
porém são definidos no último compartimento do estado. Ressalta-
se que alguns autores não usam essa notação de três compartimento
e sim de apenas dois, neste caso tanto as cláusulas entry, do, exit e
as transições internas são todas definidas no segundo
compartimento sem ordem determinada.
• Transições Reflexivas- são transições existentes no próprio
estado, ou seja, sua origem e destino é o estado corrente. A Figura
5.3 apresenta um exemplo de Diagrama de Estados do SisBiblio para
a classe Cliente (atributo status), em que o Cliente (independente
se é aluno ou professor) pode estar no estado “Empréstimo
Transições

53.
53
Incompleto” e após ocorrer um evento (when QtdeEmprestada <
QtdeLimite) ele permanece no mesmo estado. Isto porque pode
ocorrer alguma das seguintes situações na vida real:
1. Quando o cliente empresta apenas um exemplar e antes de
vencer o prazo de entrega, empresta mais um. Nesse caso,
tanto para Cliente Aluno (limite = 3 exemplares) quanto
professor (limite = 5 exemplares) o status permanece
“Empréstimo Incompleto”;
2. Quando o cliente tendo emprestado dois exemplares e
devolver um também continua com o status “Empréstimo
Incompleto”.
Uma transição pode receber uma expressão como rótulo. A forma geral
para se rotular uma transição é dada a seguir:
NomeEvento (lista de parâmetros) [condição de guarda] / ação
Descrevendo cada um dos itens desse rótulo, temos:
5.2.1.1 Eventos
Um evento é qualquer coisa que quando ocorre exige que uma mudança de
estados aconteça, ou seja, o evento é a força geradora da transição de um
estado e por isso, toda transação deve possuir um evento associado a ela.
Conforme já apresentado anteriormente, no exemplo da água temos dentre
os seus estados o líquido, o qual ao passar por um evento ferver será mudado
para estado vapor.
Outro exemplo do nosso cotidiano é apresentado na Figura 5.2, em que
temos os diferentes estados civis que uma pessoa pode assumir ao longo da vida.

54.
54
Figura 5.2: Diagrama de Estados com eventos
Tradicionalmente os eventos são classificados em 4 tipos: evento de sinal,
de chamada, temporal e de mudança [Bezerra e Booch]. Entretanto, devido a
maior aplicabilidade na fase de análise, enfatizaremos apenas dois, conforme a
seguir:
1. Evento Temporal- é um evento que passa um intervalo de tempo
predefinido a partir do qual o objeto receptor pode mudar seu estado. Tal
evento deve vir acompanhado da cláusula after (“depois de”) seguida de um
parâmetro indicando qual o intervalo de tempo. Na Figura 5.3 apresenta um
exemplo de evento temporal usado para cliente professor, em que este
uma vez com o status “Suspenso” deverá ficar com o status “OK” após um
prazo de 5 dias após a data da devolução dos exemplares que estavam em
atraso.
2. Evento de Mudança – é o evento que corresponde a uma condição que
precisa ser satisfeita para gerar a mudança de estados. Ainda na Figura
5.3 podemos ver que o status de um cliente pode passar de “OK” para
“Empréstimo Completo” quando a quantidade de exemplares emprestada
for igual a quantidade limite de empréstimo (3 para alunos e 5 para
professores).

55.
55
Figura 5.3 – Diagrama de estados da classe Cliente
5.2.1.2 Lista de Parâmetros
A lista de parâmetros corresponde aos parâmetros que deverão
necessariamente ser passados, pois contêm informações úteis ao receptor. A
lista de parâmetros é passada entre parênteses e, para os casos em que for mais
de um parâmetro, entre vírgulas dentro dos mesmos parênteses. Vale ressaltar
que cada parâmetro passado poderá estar associado a algum atributo do
diagrama de classes.
5.2.1.3 Condição de Guarda
A condição de guarda refere-se a uma condição que precisa ser satisfeita
para que a transição possa ser disparada e a ação ser realizada.
Quando uma transição possui condição de guarda, ela só é disparada se o
evento ocorrer e a condição for verdadeira, caso ela não tenha condição de
guarda, será disparada somente quando o evento ocorrer.

56.
56
Uma condição de guarda pode ser facilmente confundida com um evento de
mudança. Semanticamente ambos representam uma condição, porém
sintaticamente a condição de guarda é representada por colchetes, enquanto que
o evento de mudança é representado por parênteses pelo fato de representar os
parâmetros da cláusula when. Observe a Figura 5.3 em que a transição para o
estado “Suspenso” deve satisfazer o evento “Data Devolução < Data Corrente” e
a Condição de guarda do Cliente ser do tipo Professor para poder ser realizada.
5.2.1.4 Ações
Uma ação corresponde a uma ou mais tarefas que o objeto pode realizar ao
transitar de um estado para outro, como por exemplo, uma atribuição de um valor
de um atributo ou uma execução de um método. Ressaltando-se que a ação é
executada somente se a transição for disparada.
Existem ações que, independente da transição, são executadas sempre que
um objeto passa para ou sai de um determinado estado. Tais ações são definidas
pelas cláusulas entry, do e exit e são definidas no segundo compartimento da
representação de um estado.
a) Entry – é usada para definir uma ação a ser realizada no momento em que
um objeto entra em um estado e sempre é executada.
b) Exit – ao contrário da entry, é usada para definir uma ação sempre que o
objeto sai de um estado e também é sempre executada, independente do
estado para o qual o objeto vai.
c) Do – define alguma atividade a ser executada quando o objeto passa para
um determinado estado, diferentemente da entry que especifica uma ação.
Conforme já dito, as cláusulas entry, do e exit são definidas no segundo
compartimento do estado obedecendo a seguinte sintaxe:
Evento / [ação|atividade]

57.
57
Uma dúvida comum é: Qual a diferença entre uma ação e uma atividade?
Uma ação pode ser tanto uma execução de um método quanto uma
atribuição de um valor a um atributo, além disso, uma ação está sempre
associada a uma transição enquanto que a atividade está sempre associada
a um estado e representam apenas execução de métodos.
A notação para ação é uma barra inclina para a direita (“/”).
É importante destacar que não é obrigatório que um diagrama de estados
tenha todas essas ações modeladas para cada estado. Conforme podemos
observar na Figura 5.3 somente o estado de “Pagamento Pendente” possui uma
ação “do” modelada. Estas autoras sugerem que esse tipo de detalhamento seja
mais bem explorado na fase de projeto do sistema. Além disso, na fase de análise
(foco de estudo deste Caderno Universitário) podemos ter diagramas de estados
apresentando somente os estados e as transições com seus respectivos rótulos e
em alto nível.
5.1.3 Outros Elementos
Além dos elementos já mencionados existem outros que merecem um certo
destaque, são eles:’
Ponto de Escolha – é usado para modelar situações em que um ou mais estados
possam ter uma transição para um ou outro estado, dependendo do valor de uma
condição de guarda quando. Sua notação é um pequeno círculo não preenchido. A
Figura 5.3 apresenta um ponto de escolha ao sair do estado OK, pois a partir
desse estado um objeto cliente pode tanto ir para o estado de Empréstimo
Completo quanto de Empréstimo Incompleto, dependendo se ele emprestar ou
não a quantidade limite permitida (condição de guarda). A Figura 5.4 apresenta
uma parte do digrama de estados Cliente que contém o ponto de escolha.

58.
58
Figura 5.4 – Exemplo de Ponto de escolha
Junção – é usada para indicar a união de duas ou mais transições oriundas de
objetos distintos em uma única transição. É representada por uma barra na
horizontal, conforme pode ser visualizado na Figura 5.5, em que a transição para
o “estado 3” pode ser oriunda tanto do “estado 1” quanto do “estado 2”.
Figura 5.5 – Exemplo de Junção
Ponto de Junção – é usado quando se quer modelar situações em que a transição
vinda de dois ou mais estados pode partir também para dois ou mais estados. A
diferença entre o ponto de junção e a junção, é que neste último podemos ter
vários estados que dão origem a um único estado, enquanto que no Ponto de
Junção pode-se ter vários estados originado vários outros estados. A notação
para Ponto de Junção pode ser um losango ou um círculo fechado (idêntico ao
estado inicial). A Figura 5.6 apresenta uma parte da Figura 5.3 em que ocorre um
Ponto de Junção, em que a partir dos estados “Empréstimo Completo” e
“Empréstimo Incompleto” pode-se ter os estados “OK”, “Pendente de Pagamento”
ou ainda “Suspenso”.

59.
59
Figura 5.6 – Exemplo de Ponto de Junção
5.3 Relacionamento com outros Diagramas
O diagrama de estados está relacionado diretamente com o diagrama de Classes,
uma vez que o digrama de estado apresenta os estados de uma classe,
necessitando inclusive em suas transições da definição de alguns métodos
também contidos no diagrama de classes.
5.4 Dicas
Inicie o diagrama de estados somente com as transições e os estados
pelos quais o objeto vai passar. Em seguida, analise cada transição para
identificar qual evento provoca aquela transição e se haverá alguma ação a
ser executada (um método, uma atribuição de valor de um atributo, etc). E
assim por diante para os demais conceitos (do, entry, exit).
Toda ação e atividade executadas no estado representam métodos
definidos no diagrama de classes.

60.
60
Se, a partir de um estado, um objeto puder assumir mais de um estado
diferente, use um ponto de escolha.
Se, a partir de dois ou mais estados, um objeto puder assumir apenas um
estado diferente, use um ponto de escolha.
Se, a partir de dois ou mais estado, um objeto puder assumir mais de um
estado diferente, use um ponto de junção.
Pegue o exemplo da Figura 5.2 e refaça-o usando pontos de escolha.

61.
61
Capitulo dddddd
Diagrama de Atividades
5.1 Conceito
Um diagrama de atividades é uma representação visual do fluxo de eventos do
sistema. Para facilitar o entendimento, podemos comparar o diagrama de
atividades com uma forma gráfica de escrever uma receita de bolo.
É utilizado para:
4. Descrever os passos de um caso de uso.
5. Mostrar o fluxo completo do sistema, representando a ordem de
execução dos casos de uso.
6. Modelar um algoritmo complexo.
5.2 Componentes
O Diagrama de Atividades possui os seguintes componentes básicos (Figura 5.1).
1. Atividade: é um passo simples num processo ou na descrição do caso de
uso.
2. Estados de atividades: são as atividades realizadas pelo sistema ou pelo
ator.
3. Transição: é a mudança que permite a passagem de controle de uma
atividade para outra.

62.
62
4. Desvios: são decisões que precisam ser tomadas para permitir a
continuação do fluxo de atividades.
5. Separação e junção de fluxo de controle: oi primeiro indica o início de
atividades paralelas e o segundo representar a união de fluxos
independentes.
6. Intercalação: é utilizado após um desvio para indicar que o fluxo
seguirá o mesmo caminho independente da condição de guarda
satisfeita.
7. Raias: são compartimentos que permitem a separação das
responsabilidades dos participantes do diagrama de atividades.
8. Estados inicial e final: indicam o início e o fim de um fluxo,
respectivamente.
5.2.1 Atividades
Considera-se que o diagrama de atividades é um caso especial de diagrama de
estados, visto que possuem as mesmas notações. As atividades são chamadas de
estado-ação ou estado-atividade.
Um estado-ação é uma atividade que não pode ser decomposta em
atividades menores. Geralmente, são encontrados quando utilizamos o diagrama
de atividades para modelagem de um único caso de uso.
Já um estado-atividade é uma atividade macro que pode ser decomposta
em atividades menores, podendo ser encontrada quando o diagrama de atividades
é utilizado para modelar o comportamento geral do sistema, mostrando o
relacionamento entre os seus casos de uso. Ambos tipos de estado possuem a
mesma notação no diagrama de estado.

63.
63
5.2.2 Transição
É representada por uma seta e indica o término de uma atividade para que a
próxima possa iniciar. Ou seja, quando uma atividade termina, o fluxo de controle
passa imediatamente para a atividade seguinte.
5.2.3 Desvios
Os desvios indicam caminhos alternativos de controle baseados em condições de
guarda. Ou seja, são considerados como uma decisão que deve ser tomada antes
do fluxo de eventos continuar sua execução. Pode ser entendido como a
estrutura condicional “SE”, em que a condição a ser satisfeita é chamada de
condição de guarda, cuja notação é [expressão booleana].
5.2.4 Separação e junção de fluxo de controle
A separação de fluxo de controle indica execução concorrente de atividades,
devendo ser representada por barras de sincronização.
É importante ressaltar que um fluxo de controle pode se subdividir em
dois ou mais fluxos.
5.2.5 Intercalação
A intercalação é utilizada para representar a união do fluxo após um desvio. O
seja, independente da condição satisfeita no desvio, o fluxo de controle vai para
a mesma atividade. Um exemplo de intercalação pode ser visto na Figura xxxxx,
cuja leitura pode ser feita da seguinte forma: o sistema realizará um empréstimo
após uma consulta de um livro ou após uma reserva.

64.
64
5.2.6 Raias
Raias podem ser usadas para indicar entidades do mundo real responsáveis pela
execução de atividades.
As raias podem ser representadas tanto pelo sistema como por atores que
interagem com o sistema.
5.2.7 Estados inicial e final
Estes estados são considerados estados especiais e permitem identificar o início
e o fim de um fluxo de atividades, respectivamente.
O estado inicial é representado por um círculo preenchido. Já o estado
final é representado por um círculo preenchido menor dentro de um circulo não
preenchido maior conhecido como olho de boi.

65.
65
5.3 Notação para diagrama de atividades
5.4 Relacionamento com outros diagramas
O diagrama de atividades possui relacionamento com os seguintes
diagramas da UML: Diagrama e descrição de casos de uso, Diagrama de Classes e
Diagrama de Estados.
O Diagrama de Atividades pode ser utilizado para representar de forma
gráfica as ações (atividades) descritas na descrição de um caso de uso, bem

66.
66
como permite visualizar a relação temporal entre os casos de uso, possibilitando
um entendimento geral do sistema, conforme Figura xxxxx.
No que se refere ao diagrama de classes, o diagrama de atividades pode
ser utilizado para representar o comportamento de um método complexo.
Já com relação ao diagrama de estados, podemos representar as mudanças
de estados realizadas em uma determinada atividade, também mostrado na
Figura xxxxxxxx.

67.
67
5.5 Dicas

68.
68
21. Capitulo 5
22. Diagrama de Seqüência
Enquanto o diagrama de caso de uso mostra a interação do sistema com as
entidades externas e o diagrama de classes modela o domínio do problema no que
se refere ao comportamento estático do sistema, o diagrama de seqüência
permite a representação do comportamento dinâmico e interno do sistema.
Para entendermos o que é comportamento estático e comportamento
dinâmico de um sistema, podemos dizer analogicamente que comportamento
estático é uma fotografia e o comportamento dinâmico é um filme. Neste
contexto, o diagrama de classes mostra a fotografia do sistema e o diagrama de
seqüência mostra o filme do sistema.
Ainda como um filme, o diagrama de seqüência precisa ter um diálogo entre
os participantes (emissor e receptor), o momento exato em que os diálogos
acontecem (ordem) e os participantes de cada diálogo. Dessa forma, podemos
dizer que os participantes da cena são os objetos das classes e o diálogo entre os
participantes refere-se às mensagens trocadas entre o objeto emissor e o
objeto receptor, solicitando a ativação e execução de um método
respectivamente.

69.
69
Em termos técnicos, segundo a abordagem da orientação a objetos, para
que um objeto execute um método é necessário que este objeto receba uma
mensagem de outro objeto solicitando a execução do método em questão. Ou
seja, para que um método de um objetoA seja executado, é necessário que o
objetoB realize uma chamada explícita para esse método do objetoA, essa
chamada de métodos é chamada de mensagem.
Neste contexto, a UML disponibiliza o Diagrama de Sequência sejam
representadas a ordem de execução dos métodos do sistema referentes à
realização de um caso de uso através da troca de mensagem entre os objetos..
O diagrama de sequência é lido de cima para baixo e da direita para
esquerda, sendo que as mensagens são enviadas na ordem na qual aparecem,
representando dessa forma o sentido temporal do diagrama.
1. 5.1 Conceito
O Diagrama de Seqüência é um diagrama usado para demonstrar interações entre
objetos por meio de troca de mensagens. [A bíblia]
De forma geral, um diagrama de sequência modela a troca de mensagens
entre objetos que participam de um caso de uso.
2. 5.2 Componentes
O Diagrama de Seqüência possui dois componentes básicos (Figura 5.1): o objeto
e a mensagem:
5. Ator: é uma entidade externa ao sistema que geralmente inicia o fluxo
de mensagens de um caso de uso.

70.
70
5. Objeto – refere-se ao(s) objeto(s) que participa do caso de uso que
está sendo modelado. É representado por um retângulo com uma linha
tracejada, conhecida como linha de vida do objeto.
5. Mensagem – refere-se à chamada de método entre dois objetos. É
representada por uma seta que liga dois objetos, possui um nome e
pode apresentar os argumentos (parâmetro) de entrada e de saída.
5. Foco de controle – indica o período de tempo em que uma mensagem
está em execução.
A seguir descreveremos, mais detalhadamente, cada componente do Diagrama de
Seqüência.
5.2.1 ATOR
Os atores que interagem com os casos de uso no diagrama de caso de uso devem
ser representados também na modelagem do diagrama de sequência do caso em
questão.
No diagrama de seqüência, os atores têm a mesma notação do diagrama de
caso de uso.
A única regra que existe para o ator é que ele somente se comunica com a
classe de fronteira (tela) e nunca diretamente com a classe de entidade.
5.2.2 OBJETO
Os objetos do diagrama de seqüência referem-se às instâncias das classes que
participam da realização de um caso de uso. Esses objetos podem pertencer às
classes de entidade, controle ou fronteira.

71.
71
No diagrama de sequência, os objetos são responsáveis por enviar e/ou
receber mensagens.
Os objetos são representados por uma caixa retangular ou por um círculo
junto à uma linha horizontal acompanhado por uma linha tracejada conhecida
como linha de vida do objeto, que indica o período de tempo em que o objeto
participa do fluxo de eventos modelado pelo diagrama de sequência, conforme
apresentado na Figura ZZZZ.. Os objetos de entidade podem também ser
representados com a notação
O nome dos objetos devem obedecer à seguinte sintaxe (forma de
escrever):
nome_objeto : nome_classe ou somente :nome_classe
5.2.3 MENSAGEM
Para que uma mensagem enviada por um objeto emissor seja atendida pelo objeto
receptor, é necessário que haja um entendimento entre as partes. Por exemplo,
se um Japonês quer trocar mensagens com um Americano, eles precisam se
comunicar usando a língua japonesa ou a língua inglesa. Da mesma forma, os
objetos do sistema precisam definir uma língua própria para que as mensagens
enviadas e recebidas sejam corretamente entendidas. Essa “língua” pode ser
entendida como a assinatura dos métodos, composta pelo nome do método, os
parâmetros de entrada e os parâmetros de saída. Na prática, uma mensagem
nada mais é que a chamada de um método.

72.
72
Na representação gráfica, o objeto emissor é o objeto de onde a seta da
mensagem sai, enquanto o objeto receptor é o objeto no qual a seta da mensagem
chega, conforme mostrado na Figura ZZZZ .
Cada mensagem possui uma natureza, que indica o tipo de comunicação que
foi utilizado para definir a mensagem. As naturezas existentes são descritas
abaixo e podem ser vistas na Figura ZZZZ.
3. Síncrona: indica que o objeto emissor espera a resposta do objeto
receptor antes de continuar o seu processamento. A notação da
mensagem síncrona é uma linha contínua com seta preenchida,
conforme mensagem xxx da Figura ZZZZ.
4. Assíncrona: indica que o objeto emissor não espera a resposta do
objeto receptor antes de continuar o seu processamento.
Geralmente representam processamentos concorrentes de um caso
de uso. A notação da mensagem assíncrona pode ser vista na
mensagem xxx da Figura ZZZZ..
5. Retorno: indica a resposta do objeto receptor referente à uma
mensagem síncrona recebida.
6. Reflexiva: é utilizada quando um objeto envia uma mensagem para
ativar um método na sua própria classe. Ou seja, o mesmo objeto é
emissor e receptor ao mesmo tempo.
7. Criação de objetos: indica o momento em que um objeto começa a
existir (nasce) no sistema.
Outra característica das mensagens refere-se ao rótulo de cada
mensagem. Entende-se rótulo como a descrição das informações passadas entre
os objetos durante a troca de mensagem. Esse rótulo pode ser descrito de várias

73.
73
formas, dependendo do nível de detalhamento desejado para o diagrama. Uma
forma é descrever apenas o nome do método que deve ser executado pelo objeto
receptor, como por exemplo nome_metodo(). Outra forma é descrever a
especificação completa da mensagem, conforme o exemplo abaixo:
[[expressão-sequência] controle:] [v:=] nome [(argumentos)]
8. expressão-sequência: é opcional e identifica a ordem de envio da
mensagem. Geralmente, é representada por números sequenciais
simples, como 1, 2, 3 etc. Alternativamente, podem ter numeração
em níveis quando é necessário representar mensagens concorrentes
ativadas por uma única mensagem.
9. Controle: existem dois tipos de controle, a condição de guarda e o
controle cláusula-iteração.
1. Condição de guarda: indica uma condição que precisa ser
satisfeita (ou seja, o valor da expressão lógica deve ser
verdadeiro) para que a mensagem seja enviada ao objeto
receptor. A expressão e o valor verdadeiro devem ser
apresentados dentro de colchetes “ [expressão=valor]”.
2. controle cláusula-iteração: indica que uma mensagem será
envidada várias vezes. É representada somente por um
asterisco seguido por “:” e o nome do método que será
executado, conforme apresentado a seguir:
*: buscarLivro()
Ou pelo asterisco seguido pelo limite inferior e superior de
uma sequência de repetições, “:” e o nome do método que será
executado.
*[i:=1..3]: buscarLivro()

74.
74
Como alternativa, pode descrever a cláusula iteração
utilizando as estruturas de repetição “enquanto” e “repita
até”, descrevendo as condições que permitem que a iteração
tenha um fim.
10. Variável: refere-se ao parâmetro de saída ou de retorno enviado
como resposta à chamada de método. Pode ser entendido como uma
variável temporária que armazena o valor retornado após a execução
do método ao qual a mensagem se refere.
11. Nome: refere-se ao nome do método.
12. Argumentos: referem-se aos parâmetros de entrada necessários
para execução do método que está sendo chamado.
5.2.4 FOCO DE CONTROLE
O Foco de controle indica o momento ou período de tempo em que um
determinada mensagem de um objeto está no comando da execução do sistema.
A notação do foco de controle é uma barra vertical fina sobre a linha de
vida do objeto.
Para as mensagens reflexivas, o foco de controle é representado por por
uma barra vertical sobreposta à barra da linha.

75.
75
3. 5.3 Notação para diagrama de seqüência
A seguir é apresentado o diagrama de seqüência para o caso de uso Emprestar
Livro.

76.
76
Por questões de facilidade de leitura, foi definido que os passos que não
fazem parte do núcleo da descrição de caso de uso e que possuem outro diagrama
de seqüência para representá-las serão diferenciadas das demais e por isso
estão pintadas na cor azul com o rótulo indicando o diagrama de seqüência que
deve ser acessado para sua visualização.
4. 5.4 Outros conceitos envolvidos
5.4.1 CRIAÇÃO DE OBJETOS
A criação de um objeto indica o momento em que o objeto começa a existir
(nasce) no sistema, possuindo um .
De forma prática, pode-se considerar que os eventos que permitem de
inserção de dados no sistema podem ser modeladas com a utilização do conceito
de mensagem de criação de objetos. Nesses casos, o objeto só aparece no
diagrama de sequência no momento do seu nascimento. A Figura CCC apresenta a
modelagem do Fluxo Alternativo Inserir Livro pertencente ao caso de uso
Manter Livro, na qual o objeto livro passa a existir no sistema no momento em
que a mensagem Inserir () é ativada.

77.
77
É importante destacar que caso o diagrama de sequência esteja modelando
uma situação em que o objeto existe desde o início da troca de mensagem, esse
objeto deve ser posicionado no topo do diagrama, conforme Figura DDDD que
apresenta o Fluxo alternativo Alterar Livro pertencente ao caso de uso Manter
Livro.

78.
78
O rótulo da mensagem de criação de objetos pode ser o nome do método
construtor (que é o método nas linguagens de programação que permite a criação
de um novo objeto) ou o método que deve ser chamado no momento da criação do
objeto.
5.4.2 DESTRUIÇÃO DE OBJETOS
Em um diagrama de sequência, é possível representar o momento em que um
objeto deixa de existir no sistema. Geralmente, essa ação ocorre quando um
objeto é excluído.
Para tanto, a UML disponibiliza dois componentes: um tipo especial de
mensagem Destroy e o estereótipo “Termination”. A Figura XXXX apresenta a
modelagem do Fluxo alternativo Excluir Livro, o qual exclui o objeto livro e seus
exemplares do sistema.

79.
79
5. 5.5 Relacionamento com outros diagramas
Para modelagem do diagrama de seqüência, você deve seguir a descrição de caso
de uso e o diagrama de classes já modelados.
Na verdade, um passo da descrição de caso de uso pode se transformar em
uma ou mais mensagens no diagrama de seqüência, dependendo dos objetos
participantes. É aconselhável, por questões de facilidade de leitura e
entendimento, modelar um diagrama de seqüência para o fluxo principal de
eventos com os sub-fluxos e um diagrama de seqüência para cada fluxo
alternativo.
Quanto ao relacionamento com o diagrama de classes, podemos afirmar
que o diagrama de seqüência apenas mostra em que momento os métodos das

80.
80
classes são chamados. Assim, os métodos existentes no diagrama de seqüência
devem existir no diagrama de classes e devem pertencer às classes que
participam do diagrama de seqüência que está sendo modelado.
Devido ao nível de detalhamento apresentado no diagrama de seqüência, é
possível, e totalmente normal, que você encontre novos métodos ou resolva
retirar algum método das classes do diagrama de classes ou ainda verifique a
necessidade de revisar também o diagrama e a descrição de caso de uso.
6. 5.6 Modelando seu primeiro diagrama de sequência
A seguir serão listados os passos necessários para facilitar a modelagem seu
primeiro diagrama de seqüência.
1. Defina um caso de uso e sua descrição.
2. Crie no diagrama de seqüência, o objeto ator que interage com o caso de
uso.
3. Crie no diagrama de seqüência, o objeto da classe de fronteira (tela) que
está definida na descrição de caso de uso.
4. Para cada passo da descrição de caso de uso, crie os objetos que
participam da descrição. Coloque-os posicionados da esquerda para direita
na ordem em que serão utilizados.
5. Leia a descrição de caso de uso novamente para iniciar a definição das
mensagens que serão trocadas entre os objetos. Não esqueça que as
mensagens enviadas para um objeto deve ser um método desse objeto.

81.
81
5.7. Dicas
Nunca permita que um ator comunique-se diretamente com um
objeto de uma classe de entidade.
Deixe seu diagrama de seqüência claro e legível.
Para cada passo da descrição de caso de uso, liste as classes que
possuam os atributos e métodos que possibilitam que a
funcionalidade seja realizada pelo sistema.
Crie um diagrama de seqüência para o fluxo principal juntamente
com os sub-fluxos e um diagrama de seqüência para cada fluxo
alternativo da descrição do caso de uso.