Apostila UML

Luis Muro

29/10/2019

E aí, curtiu este material?

Ajude a incentivar outros estudantes a melhorar o conteúdo

Gostou desse material? Compartilhe! 🧡

Analise e Modelagem de Sistemas I

1.032 Materiais compartilhados

Baixe o app para aproveitar ainda mais

Leia os materiais offline, sem usar a internet. Além de vários outros recursos!

Prévia do material em texto

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

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.

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

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

� 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

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

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

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

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

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

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

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.

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.

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

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

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

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

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 deExceçã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

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

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

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

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

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.

4.3 Classes
De um modo geral, as classes são compostas por seus atributose 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.

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.

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

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

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.

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

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

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.

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.

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.

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 classesLivro e Exemplar.

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.

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.

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

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

A3
B1

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

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

A3
B1

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.

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.

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

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

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

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.

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.

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.

Figura 4.27 – Diagrama de classes do SisBiblio.

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.

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

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ário Estado inicial Estado final
Nome do estado
Transições Internas
Ações ou atividades

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

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.

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

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.

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]

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

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

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.

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

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.

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.

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.

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