analise-orientada-a-objetos

Prévia do material em texto

ANÁLISE ORIENTADA 
A OBJETO
Prof. Me. CRISTÓVAM EMÍLIO HERCULIANI
Reitor
Márcio Mesquita Serva
Vice-reitora
Profª. Regina Lúcia Ottaiano Losasso Serva
Pró-Reitor Acadêmico
Prof. José Roberto Marques de Castro
Pró-reitora de Pesquisa, Pós-graduação e Ação Comunitária
Profª. Drª. Fernanda Mesquita Serva
Pró-reitor Administrativo
Marco Antonio Teixeira
Direção do Núcleo de Educação a Distância
Paulo Pardo
Edição de Arte, Diagramação, Design Gráfico
B42 Design
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência. Informamos
que é de inteira responsabilidade da autoria a emissão de conceitos.
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A 
violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
Universidade de Marília 
Avenida Hygino Muzzy Filho, 1001 
CEP 17.525–902- Marília-SP
Imagens, ícones e capa: ©envato, ©pexels, ©pixabay, ©Twenty20 e ©wikimedia
G915b Sobrenome, Nome autor
Titulo Disciplina [livro eletrônico] / Nome completo autor. - 
Marília: Unimar, 2020.
PDF (XXX p.) : il. color.
ISBN XXX-XX-XXXXX-XX-X
1. palavra 2. palavra 3. palavra 4. palavra 5. palavra 6.
palavra 7. palavra 8. palavra I. Título.
CDD – 610.6952017
Introdução
O desenvolvimento de softwares vem, há muito tempo, tentando encontrar meios que
sejam eficientes e eficazes aos desenvolvedores e usuários.
Elaborar um sistema é muito mais amplo do que elaborar alguns softwares, envolvem
fatores extremamente complexos, como análise de requisitos, levantamento de prazos
e custos, elaboração dos modelos lógicos e físicos do sistema, além de documentação,
testes e manutenção.
Bons estudos! 
3
005 Aula 01:
016 Aula 02:
025 Aula 03:
037 Aula 04:
045 Aula 05:
053 Aula 06:
061 Aula 07:
068 Aula 08:
076 Aula 09:
087 Aula 10:
094 Aula 11:
101 Aula 12:
109 Aula 13:
117 Aula 14:
126 Aula 15:
134 Aula 16:
Orientação a Objetos: Conceitos Fundamentais 
Análise Orientada a Objetos: Princípios de Orientação 
do Paradigma
Diagrama de Casos de Uso: Conceitos 
Diagrama de Casos de Uso: Exercícios com Inclusão e 
Extensão
Diagrama de Casos de Uso: Exercícios Com 
Especialização / Generalização
Diagrama de Classes: Definições e Conceitos 
Diagrama de Classes: Agregação, Composição, 
Especialização/ Generalização e Classe Associativa
Diagrama de Classes: Exercícios 
Diagrama de Sequência: Conceitos 
Diagrama de Sequência: Exercícios 
Diagrama de Sequência: Exercícios com Repetições e 
Autochamadas
Diagrama de Comunicação (Colaboração) 
Diagrama de Estados: Conceitos Iniciais 
Diagrama de Estados: Conceitos Avançados 
Diagrama de Atividades: Conceitos Iniciais 
Diagrama de Atividades: Conceitos Avaçados
01
Orientação a Objetos: 
Conceitos Fundamentais
5
Introdução à Análise
Orientada a Objetos (AOO)
Antes dos anos de 1980, grande parte das empresas de software concebia seus
sistemas sem nenhuma metodologia de desenvolvimento, utilizava suas técnicas
próprias, cada uma de seu próprio modo. Desta forma, o conjunto de problemas
encontrados era constante, como: as estimativas de prazos e custos eram imprecisas,
a qualidade do software, muitas vezes, era inadequada, a manutenção do software
era muito difícil, entre outros. Nessa época, surgiu a análise estrutura de sistema ou o
paradigma clássico de desenvolvimento.
Durante muito tempo, os ciclos de vidas de sistemas foram utilizados e, na medida
em que o tempo foi passando, notou-se que estavam �cando aquém do esperado,
tanto pelos desenvolvedores, quanto pelos usuários, principalmente, com a
manutenção dos mesmos. Apesar de sucessos alcançados, houve uma grande
quantidade de softwares entregues com atraso, acima do orçamento, com recursos a
menos e até mesmo cancelados (Figura 1).
6
Figura 1:  Resultados de mais de 9 mil projetos de desenvolvimento de software
concluídos em 2004
Fonte: HAYES, 2004.
Os paradigmas tradicional e de orientação a objetos mostram suas diferenças
enquanto que, o maior fator ao sucesso limitado da análise estruturada de sistemas
se deve ao fato de que as técnicas são orientadas ao processo (procedure), os
atributos �cam em segundo plano, o processo (operações) é a parte central, enquanto
na análise orientada a objeto, o componente fundamental é o OBJETO que combina
estrutura e comportamento em uma única entidade.
7
Figura 2: Paradigma Tradicional x Paradigma Orientado ao Objeto
Fonte: Booch, Rumbaugh e Jacobson, 2005.
Os objetos, do ponto de vista do ser humano, são algo tangíveis e/ou visíveis, algo que
possam ser intelectualmente entendidos e/ou aprendidos e são modelados como
objetos da vida real, com estados e comportamentos. Todo objeto tem atributos e
pode prestar algum tipo de serviço e, esses atributos e serviços são conhecidos como
membros de dados e métodos, respectivamente. (Figura 3).
8
Figura 3: Representação de um objeto de software
Fonte: Engholm Jr., 2010.
Fonte: Engenharia de Software na Prática, Engholm Jr., 2010.
Tudo que um objeto de software sabe (estado) e pode fazer
(comportamento) é representado pelas variáveis e métodos do próprio
objeto. Um objeto é representado por duas propriedades: atributos e
métodos, desta forma, um objeto é uma coleção de atributos e métodos
válidos para manipular os atributos.
Em contraste com a análise estruturada de sistemas, a análise orientada a objeto
considera importantes tanto os atributos quanto às operações.
9
Figura 4: Comparação da implementação de uma conta bancária usando (a) o
paradigma clássico e (b) o paradigma de orientação a objetos
Fonte: Schachs, S., 2010.
10
Uma conta bancária é um exemplo de objeto, conforme a Figura 5. Com relação ao
paradigma clássico, um produto que lida com bancos teria de incorporar um atributo,
o saldo da conta, e três operações, depósito, saque e determinar saldo. Já no paradigma
de orientação a objetos, o componente de atributo do objeto é saldoDaConta. Existem
as operações depositar dinheiro na conta, retirar dinheiro da conta e determinarSaldo,
que podem ser realizadas sobre esse saldo bancário. O objeto conta bancária
combina um atributo com as três operações realizadas sobre esse atributo em um
único artefato. E, como um método é uma implementação de uma operação, na
�gura 3 (b), se o cliente �zer um depósito de 100 reais, uma mensagem será enviada
para o método depósito para incrementar 100 reais no atributo saldoDaConta. Tanto o
método saque como depósito sabem como o saldoDaConta é implementado, sem a
necessidade de nenhuma entidade externa ao objeto ter esse conhecimento, assim
sendo, o paradigma de orientação a objetos demonstra esse ponto forte, que os
detalhes da implementação são locais para um objeto.
A Análise de Orientação a Objetos representa uma mudança radical na maneira de se
desenvolver sistemas em relação ao Paradigma Tradicional ou Estrutural, permitindo
um melhor gerenciamento da complexidade destes sistemas.
Um grande fator da orientação a objetos é a REUSABILIDADE. Estamos reutilizando
códigos de programas desde o início da computação. As técnicas de orientação a
objetos nos permitem muito mais que a reutilização de códigos, podemos reutilizar
requisitos, análise, projeto, planejamento de testes, interfaces de usuário e
arquiteturas, ou seja, todos os componentes de engenharia de software podem ser
encapsulados como reutilizáveis.
Segundo Booch (2005), a orientação a objetos possui as seguintes vantagens:
desenvolvimento mais rápido;
maior facilidade de manutenção;
maior facilidade de extensão e evolução do sistema;
melhor aproveitamento do potencial das linguagens O.O.;
possibilidade de reúso (não só o código fonte, mas também os modelos de
análise e projeto);
diminuição dos riscos inerentes à construção de sistemas complexos;
envolvimento de conceitos que são naturais aos seres humanos (apelativos à
cognição do ser humano).
11
Fonte: Aprenda Programação Orientada a Objetos em 21 Dias.
AnáliseOrientada a Objetos é um processo que usa uma estratégia
orientada a objetos para ajudá-lo a entender o problema que está tentando
resolver. No �nal da análise, você deverá entender o domínio do problema e
seus requisitos em termos de classes e interações de objetos.
O Processo de
Desenvol�mento do So�ware
A forma de construção de um software depende de diversos fatores, como:
do conhecimento do negócio a ser modelado;
do conhecimento da tecnologia que será utilizada, por parte de quem fará a
construção;
da capacidade de abstração do principal interessado no software;
da capacidade de abstração de quem construirá o software;
e do volume de dinheiro dedicado à aquisição de softwares de autoria, banco de
dados, ferramentas de desenvolvimento, hardware e terceiros, como provedores
de acesso e data centers.
Seguindo esse raciocínio, foram criadas diversas formas de desenvolvimento, mas na
verdade, uma equipe de desenvolvimento de software precisa de uma estratégia
uni�cada para desenvolver. Assim, as metodologias de desenvolvimento de
software de�nem uma maneira comum de realizar. Uma metodologia de
desenvolvimento é um fator-chave para um projeto de desenvolvimento. Ela é um
conjunto de regras e padrões que orientam a abordagem utilizada em todas as
tarefas associadas com o ciclo de vida do desenvolvimento de sistemas.
12
Introdução à U.M.L. (Unified
Modeling Language)
Existem diversos processos de desenvolvimento de software, a UML não é um
processo, e sim, a forma de comunicação que um processo pode utilizar. A UML
(Uni�ed Modeling Language ou Linguagem para Modelagem Uni�cada) é uma
linguagem visual utilizada para modelar sistemas computacionais por meio de
paradigma de Orientação a Objetos. Esta linguagem tornou-se, nos últimos anos, a
linguagem padrão de modelagem de software adotada internacionalmente pela
indústria de Engenharia de Software.
A UML não nos indica como devemos fazer um software. Indica apenas as formas que
podem ser utilizadas para representar um software em diversos estágios de
desenvolvimento. Utilizando a UML, conseguimos “pensar” um software em um local e
codi�cá-lo em outro. É uma forma de comunicar ideia. O “L” de Language refere-se a
uma linguagem de comunicação entre duas partes e não a uma linguagem de
computador.
A UML resultou de um esforço conjunto de três autores e da aceitação da OMG
(Object Management Group): Grady Booch, Jim Rumbaugh e Ivar Jacobson, nos anos
1990.
13
Figura 5: Como iniciou a criação da UML
Fonte: Booch, Rumbaugh e Jacobson, 2005.
A UML é uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros de
software a de�nirem as características do software, tais como:
seus requisitos;
seu comportamento;
sua estrutura lógica;
a dinâmica dos processos e
suas necessidades físicas em relação ao equipamento sobre qual sistema deverá
ser implantado.
Tais características devem ser de�nidas antes de o software começar a ser realmente
desenvolvido.
14
Um desenvolvedor de sistemas busca uma modelagem orientada a objetos,
porque tem uma diminuição do tempo e do custo de desenvolvimento, um
aumento do atendimento da demanda gerada pela evolução tecnológica
como celular, palm, eletrodomésticos, etc., e a reutilização de código e
facilidade de manutenção.
15
02
Análise Orientada a 
Objetos: Princípios de 
Orientação do Paradigma
16
Como vimos no capítulo anterior, a UML (Uni�ed Modeling Language) é uma
linguagem visual utilizada para modelagem de sistemas por meio do paradigma de
orientação a objetos. Para isso, antes, devemos conhecer alguns conceitos
importantes de Orientação a Objetos e o Ciclo de Vida do Software no Modelo
Uni�cado.
Abstração
A abstração caracteriza as propriedades essenciais de um objeto que vai fazer a
diferença dos outros objetos. Ela permite agrupar entidades associadas por
propriedades comuns, representando as propriedades dos objetos sem referenciar
detalhes de implementação. Podemos dizer também que são as características
essenciais resultantes de alguma coisa.
As abordagens de desenvolvimentos tradicionais materializam esta ideia pelas
abstrações funcionais (processos), enquanto que os métodos orientados a objetos
utilizam os próprios objetos.
Fonte: Disponível aqui
A abstração é a habilidade e a capacidade de se modelar conceitos,
entidades, elementos, problemas e características do mundo real, de um
domínio do problema em questão, levando-se em conta apenas os detalhes
importantes para a resolução do problema e desprezando coisas que não
têm importância no contexto.
17
http://leandromtr.com/pilares-da-orientacao-a-objetos/
Figura 6: Encapsulamento
Fonte: o autor.
Encapsulamento
Nesse paradigma de orientação a objeto, o acesso aos dados dos objetos só pode
acontecer pelos métodos dos próprios objetos (membros de dados privados), dando a
garantia da manipulação adequada dos mesmos e utilização das regras
implementadas, de�nindo o primeiro princípio do paradigma, o encapsulamento, que
também é conhecido como ocultação de informações. Podemos dizer também que é
um mecanismo usado para ocultar os dados, a estrutura interna e os detalhes da
implementação de algum elemento, como um objeto ou subsistema.
Na verdade, o encapsulamento é o mecanismo utilizado que disponibiliza métodos
que trabalham sobre os dados e que protegem o acesso direto indevido aos atributos
de uma instância, que estão fora da classe onde estes foram declarados.
18
Fonte: Disponível aqui
Encapsulamento é a técnica que faz com que detalhes internos do
funcionamento dos métodos de uma classe permaneçam ocultos para os
objetos. Por conta dessa técnica, o conhecimento a respeito da
implementação interna da classe é desnecessário do ponto de vista do
objeto, uma vez que isso passa a ser responsabilidade dos métodos internos
da classe. Neste artigo, vocês verão o conceito de Encapsulamento em
Programação Orientada a Objetos.
Herança
Em se tratando de Orientação a Objetos, a função da Herança é permitir criar novas
classes a partir de classes já existentes, aproveitando-se das características da classe a
ser estendida. Desta forma, é possível criar classes derivadas (subclasses) a partir de
classes bases (superclasses). Enquanto que as superclasses são mais genéricas, as
subclasses são mais especializadas. As subclasses vão herdar todas as características
de suas superclasses, como seus atributos e métodos.
Vamos imaginar que dentro de uma faculdade temos muitos funcionários, sendo que
estes são divididos em pessoal administrativo e docente. Todos são funcionários da
faculdade, porém, cada um com um cargo diferente. Tanto a secretária, o auxiliar
administrativo, o professor possuem um número de identi�cação, um nome, um
endereço, além de salário e diversas outras características em comum. Essas
características em comum podem ser reunidas em um tipo de classe em comum
(Funcionário), e cada nível da hierarquia ser tratado como um novo tipo (Docente e
19
https://www.devmedia.com.br/conceitos-encapsulamento-programacao-orientada-a-objetos/18702
Figura 7: Herança
Fonte: O autor.
Administrativo), mas aproveitando-se dos tipos já criados, através da herança. Este
mecanismo é muito interessante, pois promove um grande reúso e reaproveitamento
de código existente.
As subclasses, além de herdarem todas as características da superclasse, também
podem adicionar mais atributos e/ou métodos, bem como reescrever métodos já
existentes na superclasse (polimor�smo).
20
Fonte: Disponível aqui
Na Orientação a Objetos, as palavras: classe base, supertipo, superclasse,
classe pai e classe mãe são sinônimos, bem como, as palavras classe
derivada, subtipo, subclasse e classe �lha também são sinônimos.
Polimorfismo
O termo Polimor�smo signi�ca várias formas, em Orientação a Objetos, ele
caracteriza uma situação na qual um objeto pode se comportar de diversas maneiras
diferentes ao receber uma mensagem, dependendo do seu tipo de criação.
Polimor�smo é possível na presença de herança, quando são implementados
métodos de mesma identi�caçãona superclasse e subclasses e, necessariamente,
realizando alterações (reescrevendo) nos métodos das subclasses para atender às
suas particularidades. Duas subclasses de uma mesma classe podem ter
implementações totalmente diferentes de um mesmo método, fazendo com que os
objetos se comportem de maneira diferente, dependendo do seu tipo (classe).
Vamos imaginar um programa que faça a ligação por meio de uma classe chamada
Telefone, que é uma interface de acesso às funcionalidades do telefone utilizado. Um
telefone �xo tem um mecanismo de ligação diferente de um telefone celular. Ele
manda uma mensagem simples para ligar para o Telefone, assim, o modo como o
Telefone liga vai variar de acordo com o tipo de telefone utilizado, isto é, são formas
diferentes para a mesma mensagem de ligar.
21
http://leandromtr.com/pilares-da-orientacao-a-objetos/
Figura 8: Polimor�smo
Fonte: o autor.
Fonte: Disponível aqui
Uma observação importante é dizer que as únicas partes de um programa
que requerem modi�cações são aquelas partes que exigem conhecimento
direto da classe particular que é adicionada à hierarquia.
22
https://wiki.sj.ifsc.edu.br/images/e/e2/Heran%C3%A7a20151.pdf
Figura 9: Ciclo de Vida do Software no Modelo Uni�cado
Fonte: Ko�man, Wolfgang, 2008.
Ciclo de Vida do So�ware no
Modelo Unificado
Como já é sabido, o Ciclo de Vida Clássico não é muito funcional na prática devido a
diversos fatores. Desta forma, surgiu o Modelo Uni�cado que tem como ideia
desenvolver o software em ciclos, onde cada ciclo é uma miniversão do modelo em
cascata, com intensidade variada na ênfase das diferentes etapas de um dado ciclo.
 No �nal de cada ciclo, há uma revisão com os usuários para conseguir um feedback,
que será levado em consideração no próximo ciclo.
23
Um exemplo de um modelo desse tipo é o Modelo Unificado,
ilustrado na Figura 9. Os ciclos, denominados  fases  e  iterações,
aparecem no eixo horizontal; e as atividades, denominadas fluxos de
trabalho, aparecem no eixo vertical. As quatro fases são: concepção,
elaboração, construção e transição (mudança para o novo sistema).
O tempo transcorre no eixo horizontal da iteração 1 à iteração n, e
cada iteração é uma minicascata. As cinco atividades são as mesmas
do modelo em cascata simples. As áreas sombreadas sob as curvas
próximas a cada atividade têm por objetivo mostrar a quantidade de
esforço despendido em cada atividade durante cada iteração. Por
exemplo, durante a fase de concepção (iterações 1 e 2), a maior parte
dos esforços é dedicada à especificação de requisitos. Na verdade,
especificação de requisitos é a única atividade realizada durante a
iteração 1. Durante a iteração 2, alguns esforços são igualmente
dedicados à análise, com uma pequena quantidade ao projeto e à
implementação. À medida que se encaminham para a fase de
elaboração, os desenvolvedores do software continuam a trabalhar
nos requisitos e na análise, mas começam igualmente a dedicar mais
tempo ao projeto e à implementação, particularmente mais próximo
ao final da fase de elaboração. Na fase de construção, a
especificação de requisitos e a análise das atividades são
completadas, e a maior parte dos esforços é dedicada ao projeto e
implementação. O diagrama mostra igualmente que algum tempo é
dedicado ao teste durante todas as fases após a concepção, mas a
maior parte do tempo dedicado ao teste é durante as fases de
construção e transição (KOFFMAN, 2008, cap.1).
Até a próxima aula!
24
03
Diagrama de Casos 
de Uso: Conceitos
25
O Diagrama de Casos de Uso (D.C.U.) tem o objetivo de ilustrar em um nível alto de
abstração, quais elementos externos interagem com que funcionalidades do sistema.
Dentre todos os diagramas, o U.M.L. é o mais abstrato, desta forma, o mais �exível e
informal. Ele é utilizado na fase inicial de modelagem, durante o levantamento dos
requisitos do sistema. Importante destacar, que serve de base para a modelagem de
outros diagramas U.M.L.
Este diagrama apresenta uma visão externa geral das funções e serviços que o
sistema irá oferecer aos usuários, sem se preocupar como essas funções serão
implementadas. Ele ajuda na especi�cação, visualização e documentação das
características, funções e serviços do sistema que os usuários desejam. O D.C.U.
identi�ca todos os usuários que irão interagir com o sistema, quais seus papéis e
funções especí�cas.
É recomendado e muito útil a apresentação do Diagrama de Casos de Uso aos
usuários nas reuniões iniciais, como uma forma de demonstrar o comportamento de
todo o sistema, facilitando o entendimento por parte dos mesmos e enxergar
possíveis falhas na especi�cação do sistema pelo analista, pois trata-se de um
diagrama bem informal e de fácil compreensão.
Nesse sentido, a �nalidade de um D.C.U. é apresentar um tipo de “diagrama de
contexto” que apresenta os elementos externos de um sistema e as maneiras,
segundo as quais eles as utilizam.
Fonte: Disponível aqui
Os Diagramas de Casos de Uso são compostos basicamente por quatro
partes: Cenário, que é a sequência de eventos que acontecem quando um
usuário interage com o sistema; Ator, que é o Usuário do sistema, ou
melhor, um tipo de usuário; Use Case, que é uma tarefa ou uma
funcionalidade realizada pelo ator (usuário) e Comunicação, que é o que liga
um ator com um caso de uso.
26
https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
Figura 10: Atores do Diagrama de Casos de Uso
Fonte: o autor.
Atores
Os atores são os usuários do sistema, representam os papéis desempenhados pelos
mesmos, a forma como irão interagir e utilizar seus serviços e funções. Um Ator pode
ser representado por uma pessoa, outro sistema que forneça e/ou receba informação
desse sistema, ou até mesmo um hardware especial, isto é, tudo que interage com o
sistema fornecendo e/ou recebendo informações é um ator (Figura 10). Ele é
representado por um boneco com sua descrição abaixo, que dependendo do
software utilizado, tem seu formato.
27
Figura 11: Casos de Uso
Fonte: o autor.
Casos de Uso
Os Casos de Uso são as funções, tarefas e serviços que os usuários podem utilizar
para desempenhar seus trabalhos. Eles são usados para expressar e documentar os
comportamentos pretendidos para as funções do sistema. Basicamente, os casos de
uso estão associados aos requisitos funcionais do sistema. Eles são representados
por uma elipse e em seu interior um texto que descreve a função exercida.
Os Casos de Uso devem ser documentados para fornecer informações de como será
seu funcionamento, as ações (atividades) que serão executadas, que Atores
participarão, que possíveis restrições, condições, entre outros.
28
Documentação de Casos de
Uso
A documentação de Casos de Uso tem como objetivo principal fornecer ao usuário
um relatório que explique o comportamento pretendido para determinado Casos de
Uso, demonstrando quais funções ele executará quando for solicitado (Quadro 1). Ele
também auxilia na construção de outros diagramas U.M.L. que são construídos a
partir do Diagrama de Casos de Uso.
Não tem um formato o�cial/especí�co para a documentação de Casos de Uso, a
documentação deve conter a função do Casos de Uso, quais Atores estão envolvidos,
as etapas que devem ser executadas pelo ator e pelo sistema, quais
restrições/validações deve possuir, se possui pré-condições ou pós-condições, isto é,
deve ser um documento �exível que esclareça da melhor forma possível o Caso de
Uso.
29
Quadro 1: Documentação do Caso de Uso de Pedido de Compra
Nome do Caso de Uso Pedido de Compra
Ator Principal Cliente
Ator(es)
Secundário(s)
Vendedor
Resumo
Este caso de uso descreve as etapas de um Cliente
realizando um pedido de compra para um Vendedor.
Pré-condições O Cliente precisa ser cadastrado.
Pós-condições O pedido será encaminhado no e-mail do cliente.
Ações do Ator Ações do Sistema
1. Fazer o pedido  
  2. Consultar se o cliente é cadastrado.
3. Se cliente não
cadastrado, fazer
cadastro.
 
  4. Consultar estoque do produto.
  5. Se produtosem estoque, emitir aviso.
5. Se produto com
estoque, cadastrar
pedido.
 
  6. Atualizar estoque do produto.
30
Fonte: o autor.
  7. Con�rmar pedido.
  8. Emitir pedido ao Cliente.
Restrições/Validações
O pedido somente será con�rmado se o produto
existir no estoque.
O valor mínimo de um pedido é de R$100,00.
Relacionamentos nos Casos de
Uso
As alternativas possíveis entre relacionamentos entre atores e casos de uso em um
diagrama de casos de uso podem ser descritas assim:
Quadro 2: Relacionamentos dos Componentes dos Casos de Uso
Fonte: o autor.
 
Entre
atores
Entre casos
de uso
Entre ator e caso
de uso
Comunicação     X
Inclusão   X  
Extensão   X  
Especialização/Generalização X X  
31
Figura 12: Associação entre Ator e Caso de Uso
Fonte: o autor.
Associações
As Associações podem acontecer de diversas formas nos diagramas de casos de uso,
elas representam os relacionamentos entre Atores, entre Atores e Casos de Uso, e
entre Casos de Uso. Cada um tem um tipo especial de relacionamento como é
demonstrado no quadro.
Uma associação (comunicação) entre um Ator e um Caso de Uso demonstra que o
ator se utiliza da função especí�ca do sistema representado pelo caso de uso, seja
requisitando a execução, seja recebendo o resultado produzido. Ela é representada
por uma reta fazendo a ligação entre ambos, como é demonstrado na Figura 12.
Inclusão
O Relacionamento de Inclusão indica uma obrigatoriedade, isto é, quando o caso de
uso é executado, outro caso de uso precisará ser também, como se fosse a chamada
de uma sub-rotina ou função de uma linguagem de programação (Figura 13). Ela é
representada por uma seta tracejada com um nome (<<include>> ou <<incluir>> ou
<<use>>, depende do software que está utilizando) e com um ponteiro indicando o
caso de uso que será também realizado.
32
Figura 13: Relacionamento de Inclusão
Fonte: o autor.
A Figura 9 demonstra que sempre que uma venda é realizada, deve-se emitir uma
nota �scal. O Caso de Uso Emitir Nota Fiscal será sempre realizado quando o Caso de
Uso Realizar Venda for executado.
Extensão
O Relacionamento de Extensão descreve cenários opcionais de um Caso de Uso, isto
é, somente ocorrerá em uma situação especí�ca, “se” uma determinada condição for
satisfeita. Esse tipo de relacionamento representa eventos (ações) que não ocorrem
sempre, desta forma, vão depender sempre de uma condição ser satisfeita. Ela é
representada por uma seta tracejada com um nome (<<extend>> ou <<extender>>) e
com um ponteiro indicando para o caso de uso que utiliza o caso de uso estendido
(contrário ao de inclusão).
33
Figura 14: Relacionamento de Extensão
Fonte: o autor.
A Figura 14 demonstra que quando uma venda for realizada, poderá ser chamada de
Caso de Uso Cadastrar Cliente, se o cliente não for cadastrado.
Especialização/Generalização
Este tipo de relacionamento acontece quando temos dois ou mais Casos de Uso com
características semelhantes, com apenas algumas diferenças entre si. Quando isso
ocorre, deve-se criar um Caso de Uso Geral que de�ne as características em comum
que serão herdadas por todos os casos de uso envolvidos com o mesmo e estes casos
de uso especializados/generalizados, além dos requisitos herdados possuem também
seus próprios requisitos particulares. Ela é representada por uma reta inteira mais
grossa com a seta apontada para o Caso de Uso Geral.
34
Figura 15: Relacionamento de Especialização/Generalização
Fonte: o autor.
O Caso de Uso receber pagamento tem suas especi�cidades que os casos de usos
especializados herdam, mas alguns requisitos próprios de cada um deles pertencem
somente a eles, o que justi�ca colocá-los em casos de uso especializados, detalhando
suas particularidades.
Este tipo de relacionamento também pode ser aplicado nos Atores dos Casos de Uso.
Tudo que o Ator Geral faz, os atores especializados podem também fazer, já quando
quisermos que apenas Ator Especializado faça determinada ação, a associação terá
que sair dele.
35
Figura 16: Relacionamento de Especialização/Generalização
Fonte: o autor.
Ficamos por aqui, até a aula que vem!
36
04
Diagrama de Casos de 
Uso: Exercícios com 
Inclusão e Extensão
37
Neste capítulo, vamos nos dedicar somente a exercícios de Casos de Uso, envolvendo
os relacionamentos de Inclusão e Extensão. Os exercícios podem ser realizados por
qualquer software de sua preferência ou até mesmo em uma folha de papel. Os
diagramas expostos aqui utilizarão o software Visio Professional da Microsoft 2019.
Nesta seção, apresentaremos três exemplos de Diagrama de Casos de Uso, sendo o
primeiro um Controle de um Negócio Comercial, o segundo de uma Clínica
Veterinária, e o terceiro de um Sistema de Saúde Municipal.
 
Exemplos de Diagramas de
Casos de Uso com Inclusão e
Extensão
1. Desenvolva o Diagrama Caso de Uso para um Controle de um Negócio Comercial,
levando em conta os requisitos já identi�cados para os atores envolvidos:
Requisitos do Gerente Comercial
Estabelecer limites.
Requisitos do Sistema de Contabilidade
Atualizar contas.
Requisitos do Analista Comercial
Analisar riscos com a necessidade de avaliar negócio.
Fechar preço juntamente com a participação do Vendedor e a necessidade
também de avaliar negócio.
Registrar negócio juntamente com a participação do Vendedor e com a opção de
realizar negócio com limites excedidos.
38
Figura 17: Caso de Uso Controle de Negócios
Fonte: o autor.
2. Desenvolva o Diagrama Caso de Uso para uma Clínica Veterinária levando em conta
os requisitos já identi�cados para os atores envolvidos:
Requisitos da Secretária
Cadastrar cliente.
Cadastrar animal.
Cadastrar veterinário.
Requisitos do Cliente
Marcar consulta com a Secretária. Se o Cliente e/ou o animal não forem
cadastrados, os cadastros devem ser realizados.
39
Figura 18: Caso de Uso de Clínica Veterinária
Fonte: o autor.
Requisitos do Veterinário
Realizar consulta com a participação do Cliente. É necessário registrar a
consulta. Na consulta, pode haver a necessidade de realizar exames.
Ao analisar o exercício 2, percebemos que quando um Cliente marca uma consulta
com a secretária, pode haver a necessidade de “cadastrar o cliente” e/ou “o animal” se
os mesmos não forem cadastrados (extensão), desta forma, são casos de uso que
somente acontecerão se a condição for satisfeita. O mesmo ocorre com o caso de uso
40
“marcar exames”, ele só será executado se for necessário na “realização da consulta”.
Toda vez que o caso de uso “realizar consulta” acontecer, será necessário “registrar a
consulta”, pois é uma obrigação a ser feita (inclusão).
3. Desenvolva o Diagrama Caso de Uso para uma Secretaria Municipal de Saúde
levando em conta a descrição a seguir:
Uma Prefeitura Municipal, através do Secretário Municipal de Saúde, cadastra todos
os médicos que se dispõem a trabalhar no serviço público de saúde do município com
a participação do Médico. A prefeitura possui diversas unidades de atendimento
(hospitais, postos de saúde, ambulatórios médicos, etc.) e o Secretário Municipal de
Saúde também mantém o cadastro destas unidades. Os cidadãos que desejam ter
acesso ao atendimento do sistema público do município são cadastrados pelos
funcionários das unidades de atendimento previamente com sua participação. O
Cidadão pode agendar consultas médicas em qualquer unidade de atendimento com
o Funcionário da unidade de atendimento. Mensalmente, o Secretário Municipal de
Saúde estabelece uma escala de médicos para cada unidade de atendimento e envia
a eles. A qualquer momento, o Secretário Municipal de Saúde pode extrair relatórios
com indicadores do funcionamento do sistema. Diariamente, os funcionários das
unidades de atendimento listam as consultas médicas agendadas para cada médico e
envia a eles. Em todas as ações do Funcionário da unidade de atendimento terá que
ser feito o login.
41
Figura 19: Caso de Uso de Saúde Municipal
Fonte: o autor.
Ao analisar o exercício 3, percebemos que sempre que o Funcionário for realizar uma
ação, ele teráque fazer seu login obrigatoriamente (inclusão).
42
Lembre-se de que o relacionamento de inclusão é um caso de uso
obrigatório de ser executado quando outro caso de uso foi acionado, e um
caso de uso extensivo depende de uma condição para ser executado.
Exercícios de Diagramas de
Casos de Uso com Inclusão e
Extensão
4. Desenvolva um Diagrama de Caso de Uso para um Sistema de Matrícula em um
Curso, a partir dos requisitos já identi�cados para cada ator envolvido:
Requisitos do Atendente
Cadastrar curso.
Realizar matrícula no curso com a participação do aluno. Com a realização da
matrícula será obrigado a fazer o cadastro do aluno, o registro da matrícula e a
geração do boleto que será entregue ao aluno. O Atendente que fará o cadastro
do aluno.
Gerar certi�cado, que será entregue ao aluno.
Requisitos do Aluno
Além das já citadas com o Atendente, terá que pagar a mensalidade, que será
obrigatório ser registrada.
5. Desenvolva um Diagrama de Caso de Uso para um Sistema de Hospedagem em um
Hotel a partir dos requisitos já identi�cados para cada ator envolvido:
43
Requisitos do Atendente
Manter quartos.
Manter serviços.
Fazer a reserva com a participação do Hóspede. Na reserva, se necessário, será
feito o cadastro do hóspede se o mesmo não for cadastrado.
Requisitos do Hóspede
Além da reserva com o atendente, terá que solicitar serviço, que será obrigatório
o registro do movimento.
Pagar conta, também tem que registrar o movimento.
6. Desenvolva um Diagrama de Caso de Uso para um Sistema de Estacionamento a
partir dos requisitos já identi�cados para cada ator envolvido:
Requisitos do Atendente
Registrar entrada. Toda vez que acontecer a entrada será obrigado cadastrar o
veículo e gerar um ticket impresso que será entregue ao Cliente.
Registrar saída. Toda vez que houver a saída será obrigatório gerar a fatura ao
Cliente. A geração da fatura implicará obrigatoriamente a consulta de preços.
Manter promoções.
Requisitos do Gerente
Cadastrar parcerias.
Manter tabela de preços.
Gerar relatório de faturamento. Desta forma, será obrigado a calcular o
faturamento.
Requisitos do Cliente
Pagar fatura com a participação do Atendente.
7. Desenvolva o Diagrama Caso de Uso para uma empresa de Organização de Eventos
levando em conta a descrição a seguir:
Uma empresa de organização de eventos gerencia seus compromissos da forma
descrita a seguir. Os Clientes são cadastrados pelo Representante da Empresa, que
também cadastra o evento que deseja que seja organizado. Na hora de cadastrar um
evento, se necessário, deve atualizar os dados do cliente. Desta forma, inicia-se um
processo de divulgação do evento pelo Representante da Empresa, assim, terá que
emitir uma mala direta aos clientes. O Representante emite relatórios de providências
a serem tomadas, à medida que se aproxima o evento. Após a realização do evento, o
Representante, se desejar, faz o balanço, para sua apuração de custos e lucro.
44
05
Diagrama de Casos 
de Uso: Exercícios 
Com Especialização / 
Generalização
45
Neste capítulo, vamos nos dedicar a exercícios de Casos de Uso completos,
envolvendo além dos relacionamentos de Inclusão e Extensão, também de
Especialização/Generalização.
Nesta seção, apresentaremos, novamente, dois dos exemplos do capítulo anterior de
Diagrama de Casos de Uso, o de Controle de um Negócio Comercial e o de Clínica
Veterinária com os acréscimos de especialização/generalização.
Exemplos de Diagramas de
Casos de Uso com
Especialização /
Generalização
1. Desenvolva o Diagrama Caso de Uso para um Controle de um Negócio Comercial
levando em conta os requisitos já identificados para os atores envolvidos:
Requisitos do Gerente Comercial
Estabelecer limites.
Requisitos do Sistema de Contabilidade
Atualizar contas.
Requisitos do Analista Comercial
Analisar riscos com a necessidade de avaliar negócio.
Fechar preço juntamente com a participação do Vendedor e a necessidade
também de avaliar negócio. O fechamento do preço poderá ser à vista ou a
prazo.
Registrar negócio juntamente com a participação do Vendedor e com a opção de
realizar negócio com limites excedidos.
Obs.: O Gerente pode realizar todas as ações do Analista Comercial.
46
Figura 20: Caso de Uso de Controle de Negócio Comercial
Fonte: o autor.
Ao analisar o exercício 1, no que se refere à especialização/generalização, o “fechar
preço à vista” e o “fechar preço a prazo” possuem todas as características do “fechar
preço”, mas possuem algumas características e requisitos próprios, o que justifica
colocá-las como especializações do caso e uso “fechar preço”. A mesma coisa
acontece com a especialização/generalização entre Atores, em que o “Gerente” herda
todas as ações do Analista Comercial, isto é, ele poderá realizar todas as operações
que o Analista Comercial executa.
47
2. Desenvolva o Diagrama Caso de Uso para uma Clínica Veterinária levando em conta
os requisitos já identificados para os atores envolvidos:
Requisitos da Secretária
Cadastrar cliente.
Cadastrar animal.
Cadastrar veterinário.
Receber pagamento com a participação do Cliente. O pagamento poderá ser em
dinheiro ou cartão.
Requisitos do Cliente
Marcar consulta com a Secretária. Se o Cliente e/ou o animal não forem
cadastrados, os cadastros devem ser realizados.
Requisitos do Veterinário
Realizar consulta com a participação do Cliente. É necessário registrar a
consulta. Pode na consulta haver a necessidade de realizar exames.
O Veterinário pode realizar todas as operações da Secretária.
48
Figura 21: Controle de uma Clínica Veterinária
Fonte: adaptado de Guedes, 2008.
Analisando o exercício 2, no que se refere à especialização/generalização, o “receber
pagamento em dinheiro” e o “receber pagamento no cartão” possuem todas as
características do “receber pagamento”, mas possuem algumas características e
requisitos próprios, o que justifica colocá-las como especializações do caso de uso
“receber pagamento”. A mesma coisa acontece com a especialização/generalização
entre Atores, em que o “Veterinário” herda todas as ações da “Secretária”, isto é, ele
poderá realizar todas as operações que a Secretária executa.
49
Lembre-se de que a estrutura de um Caso de Uso generalizado é herdada
pelo Caso de Uso especializado.
Exercícios de Diagramas de
Casos de Uso com
Especialização /
Generalização
3. Desenvolva o Diagrama Caso de Uso para um Clube Social, levando em conta os
requisitos já identificados para os atores envolvidos:
Requisitos do Candidato
Apresentar pedido.
Requisitos do Clube
Associar o sócio com a participação do Sócio. Se o sócio tiver dependentes, deve-
se associar os dependentes.
Gerar mensalidade.
Requisitos do Sócio
Fazer matrícula em atividades.
Quitar mensalidade com a participação do Clube.
É derivado a partir do Candidato.
50
4. Desenvolva o Diagrama Caso de Uso para um Restaurante levando em conta os
requisitos já identificados para os atores envolvidos:
Requisitos do Gerente
Cadastrar mesas.
Cadastrar menu.
Cadastrar garçons com a participação do Garçom.
Gerar histórico de movimento diário.
Requisitos do Garçom
Abrir conta com a obrigação de registrar movimento.
Solicitar pedido com a participação do Cliente e com a obrigação de registrar
movimento.
Emitir conta ao Cliente.
Fazer pagamento da conta com o Registro do movimento e com a participação
do Cliente. O pagamento poderá ser em dinheiro, em cheque ou no cartão.
Emitir nota fiscal ao Cliente.
Requisitos do Cliente
Todos feitos com o Garçom citados anteriormente.
Obs.: O Gerente pode fazer todas as funções do Garçom.
5. Desenvolva o Diagrama Caso de Uso para um Consultório Dentário levando em
conta os requisitos já identificados para os atores envolvidos:
Requisitos da Secretária
Marcar consulta com o Paciente. Se o paciente não for cadastrado será feito seu
cadastro.
Cadastrar paciente.
Cadastrar dentista.
Receber pagamento com a participação do Paciente. O pagamento pode ser
feito em dinheiro ou cartão e o cartão pode ser no débito ou no crédito. No
pagamentoserá emitido um recibo ao Paciente.
Requisitos do Dentista
Realizar consulta, com a obrigação de registrar histórico. Pode na consulta haver
a necessidade de marcar exames.
Registrar histórico.
Cadastrar orçamento e emitir ao Paciente.
51
Requisitos do Paciente
Todos os casos já citados com a Secretária.
52
06
Diagrama de Classes: 
Definições e Conceitos
53
Dentro da UML, o Diagrama de Classes é o mais importante e utilizado, possui muitas
semelhanças com o antigo Modelo Entidade-Relacionamento (MER) utilizado para
definir as estruturas das tabelas em bancos de dados relacionais. Ele foi criado para
ser uma evolução do Modelo Entidade-Relacionamento e para modelar a estrutura
lógica das tabelas de um banco de dados.
Em um MER, além dos relacionamentos, eram definidos apenas os dados, que no
Diagrama de Classes são representados pelos atributos e, ainda, possibilita definir as
operações que irão executar nas tabelas pelos métodos.
O Diagrama e Classes permite a visualização das classes que vão
compor o sistema com seus respectivos atributos e métodos, bem
como demonstrar como as classes do diagrama se relacionam,
complementam e transmitem informações entre si (GUEDES, 2008 p.
75).
O Diagrama de Classes serve como base para a construção de outros diagramas UML.
Basicamente, o Diagrama de Classes é formado por suas classes e pelas associações
existentes entre elas, isto é, os relacionamentos entre as classes. Em Programação
Orientada a Objeto os problemas de programação são pensados em termos de
objetos, nada de funções e rotinas, o assunto são os objetos, propriedades e
métodos.
Objetos - Classes - Atributos -
Métodos
Um Objeto representa uma abstração de alguma coisa do nosso domínio do
problema que retém e interage informações do sistema. Todo objeto possui atributos
e pode prestar algum tipo de serviço. Uma classe possui atributos, isto é, armazena os
dados dos objetos e, também os métodos, que são as instâncias que uma classe pode
executar.
54
Figura 22: Objetos, Classes e Atributos
Fonte: o autor.
Uma classe descreve como certos tipos de objetos se parecem do ponto de vista da
programação, pois quando definimos uma classe, precisamos definir duas coisas:
Atributos, que são Informações específicas relacionadas a uma classe de objeto. São
as características dos objetos que as classes representam, por exemplo: CPF, nome,
fone, sexo, data de nascimento etc.; e Métodos: que são ações que os objetos de uma
classe podem realizar, como, por exemplo: falar, andar, ouvir, etc.       
A representação de uma classe tem a descrição ou o nome dela na primeira parte, na
segunda, possui os atributos e seus tipos, e na terceira parte, contém seus
métodos.    
55
Figura 23: Representação de Classe
Fonte: o autor.
Você pode pensar em uma classe com um modelo para criar quantos
objetos você desejar de um tipo particular. Pense em um carimbo com a
imagem de uma pessoa, quando você carimba e obtém um desenho dela,
você acabou de criar uma instância da classe e obteve um objeto daquela
classe. O novo objeto possuirá todas as características e comportamentos
definidos pela classe.
Os símbolos (+ e -) representam a visibilidade dos atributos e operações em uma
classe com os seguintes significados:
+ público: visível em qualquer classe, isto é, pode ser utilizado por qualquer
objeto de qualquer classe.
# protegido: qualquer descendente pode usar, isto é, somente objetos da classe
possuidora do atributo ou método ou suas subclasses podem ter acesso ao
mesmo.
- privado: visível somente dentro da classe, isto é, somente objetos da classe
possuidora do atributo poderão utilizá-los.
56
É possível percebermos que os atributos CPF, nome, endereço e nascimento
têm visibilidade privada, pois apresentam o símbolo (-) e, portanto, somente
as instâncias da classe Funcionário podem enxergar esses atributos. Já o
método Consultar (  ) possui visibilidade pública, como indica o símbolo (+), o
que permite que objetos de outras classes visualizem o método.
Como o intuito deste capítulo e dos capítulos 7 e 8 são definir e demonstrar os
relacionamentos entre as classes, não serão apresentados os atributos e métodos nos
relacionamentos, senão, pode tornar o diagrama muito poluído. Eles devem ser
apresentados no momento de fazer a programação e a implementação de um
sistema.
Relacionamentos entre Classes
As classes possuem relacionamentos entre si, para poderem compartilhar
informações e permitir a execução dos diversos processos executados pelo sistema.
Desta maneira, veremos, nas seções seguintes, as associações utilizadas pelos
analistas de sistemas.
Associação Binária
A Associação Binária é o relacionamento entre duas classes. É a associação mais
comum encontrada nos diagramas de classes. É um relacionamento estrutural que
especifica que objetos de uma classe estão conectados a objetos de outra classe. A
Figura 24 mostra esta associação:
57
Figura 24: Associação Binária
Fonte: o autor.
De acordo com a Figura 24, um pedido é efetuado por exatamente um cliente. Um
cliente pode efetuar vários ou nenhum pedido. Os limites inferiores/superiores
devem ser indicados numericamente (cardinalidade) e a associação pode ser rotulada
(nomeada), não há obrigação de rotular.
A cardinalidade é parecida com o Modelo Entidade-Relacionamento, com a diferença
de “muitos” é representado pelo asterisco (*) e, também podemos colocar números
inteiros quaisquer para representar corretamente a relação.
Figura 25: Exemplos de Multiplicidades
Fonte: o autor.
Multiplicidade Significado
0..1 No mínimo zero (nenhum) e no máximo um.
1..1 Um e somente um.
0..* No mínimo zero e no máximo muitos.
1..* No mínimo um e no máximo muitos.
2..8
No mínimo 2 e no máximo 8. Existem pelo menos 2 e no
máximo 8.
58
Figura 26:  Associação Unária
Fonte: o autor.
Quando não existir cardinalidade demonstrada, entende-se que a
cardinalidade é “1..1”, que significa que no mínimo e no máximo um objeto
dessa extremidade relaciona-se com objeto(s) da outra extremidade.
Associação Unária
A Associação Unária é o relacionamento de uma classe com ela mesma, como é
demonstrado na Figura 26.
De acordo com a Figura 26, temos a classe Professor com os atributos de código,
nome e possível código de coordenador. O coordenador também é um professor,
assim sendo, a associação “coordena” indica uma possível relação entre uma ou mais
instâncias da classe Professor com outras instâncias da própria classe. Essa
associação determina que um Professor pode ou não coordenar outros professores.
59
Figura 27: Associação Ternária
Fonte: o autor.
Associação Ternária
A Associação Ternária ou N-árias é o relacionamento com mais de duas classes,
conforme a Figura 27.
Um professor de uma disciplina tem no mínimo um e no máximo muitos alunos; uma
disciplina de um aluno é no mínimo e no máximo um professor; e um aluno de um
professor é de uma disciplina ou mais disciplinas.
60
07
Diagrama de Classes: Agregação, 
Composição, Especialização/ 
Generalização e Classe Associativa
61
Figura 28: Agregação
Fonte: o autor.
Agregação
É uma relação Todo/Parte entre os objetos associados, isto é, um tipo especial de
associação na qual se tenta demonstrar que as informações do objeto (chamado
objeto-todo) precisam ser complementadas pelas informações contidas em um ou
mais objetos de outra classe (chamados objetos-parte). É uma associação com o
significado contém (é constituído por)/faz parte de.
O símbolo da Agregação tem um losango vazio na extremidade da classe que contém
os objetos-todo, conforme é mostrado na Figura 28.
Na Figura 28, temos uma classe Nota Fiscal que contém os objetos-todo e uma classe
Itens Nota que possui os objetos-parte. Uma Nota Fiscal pode tanto possuir um ou
vários itens, mas quantos? Pode ser um, dois, três etc., assim, os itens que se repetem
devem ser armazenados em uma classe dependente da classe Nota Fiscal. Temos
também uma associação binária entre a classe Produto e a classe Itens Nota, sendo
que um objeto daclasse Produto pode se referir a muitos objetos da classe Itens
Nota, já um objeto da classe Itens Nota refere-se a apenas uma instância da classe
Produto.
62
A função principal de uma agregação é identificar a obrigatoriedade de uma
complementação das informações de um objeto-todo por seus objetos-parte quando
este for consultado; já em uma associação binária esta obrigatoriedade não está
explícita.
Os Objetos-parte não podem ser excluídos por um objeto diferente do
Objeto-todo.
Figura 29: Composição
Fonte: o autor.
Composição
A Associação de Composição é uma Agregação mais forte. Implica que o Objeto-todo
é responsável pela criação do Objeto-parte e que esta não vive sem o Objeto-todo. A
composição é mais física, uma parte não pode pertencer a dois objetos ao mesmo
tempo, como, por exemplo, um coração não pode pertencer a dois corpos ao mesmo
tempo. Quando um Objeto-todo for excluído, os Objetos-parte também serão.
63
Figura 30: Composição Revista Científica
Fonte: Guedes, 2008.
Conforme a Figura 29, podemos observar que, um objeto da classe Sócio refere-se a
nenhum ou vários objetos da classe dependente, isto é, um sócio pode ter muitos ou
nenhum dependente. E que cada instância da classe Dependente se relaciona única e
exclusivamente a uma instância específica da classe Sócio, não podendo relacionar-se
com nenhuma outra (quando não for especificado é determinado 1..1).
Vejamos outro exemplo, conforme a Figura 30.
Podemos observar que um objeto da classe Revista Científica refere-se a, no mínimo,
um objeto da classe Edição e, no máximo, a vários objetos dessa classe. Cada
instância da classe Edição relaciona-se única e exclusivamente a uma instância da
classe revista Científica, sendo assim, ela não pode relacionar-se com nenhuma outra.
Um objeto da classe Edição deve-se relacionar no mínimo 6 e no máximo 10 a objetos
da classe Artigo (isso é uma forma de “validação”). Um objeto da classe Artigo refere-
se unicamente a um objeto da classe Edição.
64
Figura 31: Especialização / Generalização do Diagrama de Classes
Fonte: o autor.
Especialização /
Generalização
É um relacionamento bem parecido utilizado no Diagrama de Caso de Uso. Ocorre
quando existem duas ou mais classes com características semelhantes. Deste modo,
para evitar declarar atributos e métodos idênticos, produz-se uma classe geral com os
atributos e métodos comuns a todas as classes envolvidas no processo e criam-se
classes especializadas ligadas à classe geral, que herdam todas as suas características,
podendo ter atributos e métodos próprios.
A Classe mais geral pode ser chamada de Super-Classe ou Classe-Mãe e as classes
especializadas de Sub-Classes ou Classes-Filhas.
65
Ao observarmos a Figura 31, existe uma classe geral chamada Pessoa que possui os
atributos nome e endereço e duas classes especializadas (Pessoa Física e Jurídica) que
herdam os atributos da classe Pessoa, além de possuir seus atributos próprios.
Figura 32: Classe Associativa
Fonte: o autor.
Classe Associativa
Classe Associativa é criada quando existir uma associação entre duas classes com
cardinalidade muitos (*) nas duas extremidades, isto é, uma relação de muitos para
muitos. Esta classe associativa é criada porque nenhuma classe do relacionamento
pode receber o atributo-chave da outra, desta forma, a classe associativa receberá
esses atributos, o que não impede de ela ter seus próprios atributos criados desta
relação.
Um Aluno cursa no mínimo uma Disciplina, mas pode cursar muitas e uma Disciplina
é cursada por muitos alunos. Como não há lugar para armazenar essas informações
em nenhuma das duas classes, pois um aluno pode fazer uma, duas,... dez disciplinas
e uma disciplina pode ser cursada por dezenas de alunos, desta forma, não dá para
66
deixar reservado certo números de atributos em cada uma das classes, porque
diversos deles poderiam ficar em branco ou até, em alguns casos não serem
suficientes.
Nesse exemplo (Figura 32), foi criada a classe Período que terá os atributos-chave das
classes Aluno e Disciplina, além dos atributos próprios criados desta relação, o ano e
semestre que está sendo cursada a disciplina pelo aluno.
67
08
Diagrama de Classes: 
Exercícios
68
Neste capítulo, iremos dedicar aos exercícios de Diagramas de Classes completos,
envolvendo todos os conceitos aprendidos nos capítulos 6 e 7.
Nesta seção, apresentaremos, primeiramente, dois exemplos de exercícios de
Diagrama de Classes, um de Controle de Negócio Comercial e um de Clínica
Veterinária com os acréscimos de especialização/generalização.
Exemplos de Diagramas de
Classes
1. Diagrama de Classes de uma Faculdade
Um curso possui diversas turmas, no entanto, uma turma relaciona-se
exclusivamente a um único curso.
Um curso pode ser de exatas, humanas ou da saúde, cada um com suas
características próprias.
Uma disciplina pode pertencer a diversos cursos e um curso possui diversas
disciplinas.
Um professor leciona em pelo menos uma disciplina, mas pode lecionar em várias, e a
disciplina é lecionada por no mínimo um e no máximo 3 professores.
Um aluno de uma turma precisa estar matriculado ao menos em uma disciplina, uma
disciplina de uma turma tem ao menos um aluno, e um aluno de uma disciplina só
pode estar matriculado em uma turma.
69
Figura 33: Diagrama de Classes de uma Faculdade
Fonte: o autor.
No Diagrama de Classes da Figura 33, podemos observar que temos um
relacionamento binário entre Professor e Aluno, um pode existir sem o outro; uma
associação de composição entre Curso e Turma, isto é, uma turma só existe se houver
o curso; temos especialização/generalização da classe Curso (superclasse) com as
subclasses Exatas, Humanas e Saúde; temos também uma relação ternária entre
Aluno, Turma e Disciplina; e, ainda, uma classe associativa (Curso-Disciplina) entre as
classes Curso e Disciplina.
2. Diagrama de Classe de um Disk-Pizza
Um cliente precisa ser cadastrado para fazer um pedido, e este faz no mínimo um
pedido.
Um pedido é de somente um cliente, desta forma, o pedido só vai existir se houver o
cliente.
Um pedido pode tanto possuir um como vários itens de pedido. Os itens de pedido
complementam o pedido, e este item é somente de um pedido.
Uma pizza pode compor muitos itens de pedido, no mínimo 1, porém, um objeto da
classe Itens de pedido refere-se a apenas uma instância da classe de pizza.
70
Figura 34: Diagrama de Classe de um Disk-Pizza
Fonte: o autor.
Uma pizza pode ser pequena, média ou grande, sendo que cada uma delas tem suas
características próprias.
No pagamento da conta o cliente, obrigatoriamente, faz um pagamento, que pode ser
em dinheiro ou cartão, e o pagamento é de apenas um único hóspede, sendo que ele
só existirá se houver hóspede.
Neste Diagrama (Figura 34), temos uma associação de agregação entre o Pedido e o
ItemPedido, pois esta classe de itens de pedido complementa a classe de pedido com
as informações contidas nela, pois seria impossível estas informações estarem na
classe de pedido onde poderia conter um item como dezenas de itens. Há também
três associações de composição entre Cliente e Pedido, Cliente e Pagamento, Pizza e
ItemPedido (os objetos-parte precisam ser exclusivos do objeto-todo). E, por fim,
temos duas associações de especialização/generalização, uma na Pizza com suas
especializadas Pequena, Média e Grande e outra no Pagamento com as subclasses
Dinheiro ou Cartão.
71
Exercícios de Diagramas de
Classes
1. Desenvolva o Diagrama de Classe para um Hotel levando em consideração os
requisitos já identificados:
Um hotel possui um cadastro de seus quartos, sendo que, o quarto pode ser de luxo
ou standard. Um hóspede reserva pelo menos um quarto, e um quarto só pode ser
reservado por um hóspede por vez.
Um serviço de hotel pode ser de cozinha, lavanderia ou telefonia, e o hóspede não é
obrigado a solicitar um serviço, mas pode solicitar vários. Um serviço pode ou não ser
solicitado por vários hóspedes.
No pagamento da conta, o hóspede só pode fazer um pagamento em dinheiroou
cartão, e o pagamento é de apenas um único hóspede, sendo que ele só existirá se
houver hóspede.
 
2. Desenvolva o Diagrama de Classe para uma Locada de Veículos levando em
consideração os requisitos já identificados:
Uma Rede de Locadora de veículos possui diversas filiais pelo país, sendo que uma
Filial possui muitos veículos para locação, e um Veículo pode pertencer também a
várias filiais, pelo menos uma.
Um veículo pode ser de passeio, de carga ou van, cada um com suas características
próprias. Um Pessoa que pode ser tanto uma Pessoa Física como Pessoa Jurídica
aluga pelo menos um Veículo, sendo que, se for Pessoa Física, só pode alugar veículos
de passeio, se for Pessoa Jurídica, pode alugar qualquer um.  Um Veículo só pode ser
alugado por uma única Pessoa por vez ou nenhum; estes também são independentes.
Uma Filial pode ou não possuir parcerias com bancos, e um Banco pode também ter
parcerias com várias Filiais ou não.
 
72
3. Desenvolva o Diagrama de Classe para um Consultório Médico levando em
consideração os requisitos já identificados:
Em um consultório médico existe um cadastro de Especialidades. Há também um
cadastro dos Médicos do consultório, sendo que um médico tem pelo menos uma
Especialidade, e uma Especialidade cadastrada tem pelo menos um Médico.
Existem os Agendamentos, sendo que um Agendamento é de apenas um único
Médico, ele só existe se houver o médico, e ele pode ter vários agendamentos ou
nenhum.
O Paciente, por sua vez, para ter um Agendamento, precisa ser cadastrado. Um
Paciente pode ter mais de um Agendamento ou nenhum, já um Agendamento é de
um único Paciente, ele só existe se houver Paciente.
Nem toda Consulta refere-se a um Agendamento, e um Agendamento é de uma
Consulta, estas são independentes.
Um Paciente realiza ao menos uma Consulta e uma Consulta é de apenas um único
Paciente. Ele só existe se houver Paciente.
Um Médico realiza ao menos uma Consulta e uma Consulta é de apenas um único
Médico, ele só existe se houver o Médico.
 
4. Desenvolva o Diagrama de Classe para uma Clínica Veterinária levando em
consideração os requisitos já identificados:
Um Cliente pode ter muitos animais, mas um Animal pertence exclusivamente a um
único Cliente.
Um Animal pertence a uma única espécie, porém uma Espécie cadastrada na clínica
pode ou não ter animais.
Um Animal pode realizar muitos Tratamentos ou não, mas um Tratamento é realizado
exclusivamente por um Animal.
Um Tratamento, além de suas especificações, é constituído por um ou vários
Medicamentos com suas dosagens diárias, no entanto, cada Medicamento sugerido
faz parte de vários Tratamentos ou nenhum.
73
Cada Tratamento possui ao menos uma Consulta, mas pode possuir muitas consultas.
Uma determinada Consulta refere-se a um determinado Tratamento ou não.
Um Veterinário pode realizar muitas consultas, porém uma Consulta deve ser
realizada por somente um veterinário. Em uma consulta podem ser marcados
diversos exames ou nenhum e um Exame pode ser referência de várias consultas ou
nenhuma.
 
5. Desenvolva o Diagrama de Classe para um Campeonato de Futebol levando
em consideração os requisitos já identificados:
Todo time de futebol pertence a uma cidade, isto é, ele só existe se houver a cidade e
uma Cidade pode possuir vários times ou não.
Um Time de futebol para entrar no campeonato precisa ter um Estádio de referência,
e o Estádio é de apenas um Time, mas ele não é obrigado a ser de um time.
Um Time pode ou não possuir torcidas organizadas, mas uma Torcida é de somente
um Time, ela só existirá se houver um Time.
Um time possui ao menos 16 jogadores inscritos e um Jogador é de somente um Time
ou nenhum.
Um jogador em um jogo pode ter várias ocorrências ou nenhuma, uma ocorrência em
um jogo pode ter muitos jogadores ou nenhum, já um jogador pode sofrer uma
ocorrência em vários jogos ou nenhum. Uma ocorrência pode ter gols, cartões
amarelos ou vermelho, cada uma dessas ocorrências tem suas características
próprias.
 
6. Desenvolva o Diagrama de Classe para Passagens Aéreas levando em
consideração os requisitos já identificados:
Um Voo é de uma única Companhia Aérea e a companhia possui ao menos um Voo.
Um Passageiro realiza ao menos um Voo, no entanto, um Voo tem no mínimo 10
passageiros. Uma Passagem refere-se a um Passageiro ou nenhum e um Passageiro
só pode ter uma Passagem obrigatoriamente.
74
Cada Passagem refere-se, exclusivamente, a um Voo específico e um Voo tem no
mínimo uma passagem, mas pode ter diversas.
Um Aeroporto está localizado em uma Cidade específica, ele só existe se houver a
cidade, mas uma Cidade pode possuir muitos aeroportos ou nenhum.
Um Voo faz ao menos uma escala em aeroportos, e um Aeroporto pode ser escala de
muitos voos ou nenhum.
75
09
Diagrama de Sequência: 
Conceitos
76
O Diagrama de Sequência é criado a partir do Diagrama de Caso de Uso e também do
Diagrama de Classe, pois o mesmo determina a sequência de eventos que devem ser
realizados, dentro de uma ordem correta, com os objetos declarados do diagrama de
classe, bem como os métodos. São utilizados para apresentar a evolução de uma
funcionalidade em um determinado momento do software.
Este tipo de diagrama determina a sequência de eventos que correm em um
determinado processo, ou seja, quais condições devem ser satisfeitas e quais
métodos devem ser disparados entre os objetos envolvidos e em que ordem durante
um processo específico. (GUEDES, 2008 pág. 113)
Desta forma, podemos dizer que o objetivo do Diagrama de Sequência é:
determinar a ordem em que os eventos ocorrem;
as mensagens que são enviadas;
os métodos que são chamados;
e como os objetos interagem dentro de um determinado processo.
O Diagrama de Sequência se preocupa com a ordem temporal em que as mensagens
são trocadas entre os objetos envolvidos em um determinado processo; ele se baseia
em um Caso de Uso e utiliza o Diagrama de Classes para determinar os objetos
envolvidos em um processo.
O fato de existir um Caso de Uso não significa que deva existir um único Diagrama de
Sequência, e sim, há diversos Diagramas de Sequência em um projeto, uma para cada
processo específico do sistema, como por exemplo, suponhamos um sistema de
controle de um hotel em que temos diversos processos como reserva, entrada,
serviços, saída, desta forma, seria impossível colocar tudo isso dentro de um mesmo
diagrama de sequência, e sim, um diagrama para cada processo específico citado.
É importante destacarmos os componentes que formam um Diagrama de Sequência
para um melhor entendimento. 
Atores
Os Atores são os mesmos utilizados nos casos de usos, sendo assim são os usuários
(entidades externas) que interagem com o sistema. Sua representação é a mesma
(Figura 35) com uma Linha da Vida embaixo que será explicado do capítulo 9.3. 
77
Figura 35: Ator do Diagrama de Sequência.
Fonte: o autor.
Objetos
Os Objetos são todas as instâncias das classes envolvidas no processo. Eles são
representados por um retângulo em que consta o nome do objeto (letras minúsculas)
o sinal de dois pontos (:) e o nome da classe com a letra inicial maiúscula (Figura 36).
Pode ocorrer em certas situações do processo que o mesmo vai consultar ou
selecionar mais de um objeto da classe a qual pertence, neste momento devemos
colocar apenas o sinal de dois pontos (:) e o nome da classe.
78
Figura 36: Objeto e Classe.
Fonte: o autor.
Não é necessário apresentar os atributos dos objetos, apenas terá também uma
Linha da Vida (Capítulo 8.3) representada por uma linha vertical tracejada. Na Figura
26 temos um objeto chamado cliente1que é uma instância da classe Cliente.
Na criação de um Diagrama de Sequência podem existir objetos desde o início do
processo e objetos que são criados durante o processo. Desta forma, (Figura 37) o
mais indicado, no primeiro caso, é colocar os objetos na parte superior do diagrama e
no segundo caso, colocar no mesmo nível em que ele está sendo criado. 
79
Figura 37: Exemplo de Criação de Objetos em um Diagrama de Sequência de Hotel.Fonte: o autor.
Linha de Vida
Representada por linhas verticais tracejadas, a Linha da Vida tem por finalidade
demonstrar o tempo em que um objeto existiu durante um processo. Ela se inicia a
partir do retângulo representado pelo objeto e é interrompida com um “X” quando o
objeto for “destruído” (Figura 37). 
Foco de Controle (Ativação)
O Foco de Controle ou Ativação representa o momento em que o objeto está
participando do processo, isto é, mostra os momentos que o objeto está executando
um ou mais métodos do processo específico. Ele é representado por um traço mais
grosso sobre a linda da vida do objeto (Figura 37). 
80
Acesse o link: Disponível aqui
O tempo de atividades do objeto corresponde ao tempo durante o qual um
objeto exerce sua ação direta ou indiretamente por meio de um objeto que
lhe presta serviço.
Mensagens
As mensagens são utilizadas para indicar a ocorrência de eventos que forçam a
chamada de um método em um dos objetos envolvidos naquele processo. Pode
também ocorrer entre um Ator e a representação pelo meio ao qual o usuário se
comunica com o sistema (Figura 37, Interface da Web), neste caso nenhum método é
disparado. Pode ocorrer também entre dois atores, mas não é muito utilizado, pois
pode deixar o diagrama muito carregado.
As mensagens entre os objetos são as que mais aparecem, é a solicitação de um
objeto a outro para a execução de um método (Figura 37), e ainda, pode disparar um
método para si próprio, conhecido como Autochamada (Capítulo 9.7). Nas mensagens
entre objetos, existe um número, a descrição (não é obrigatório) separado por (:) com
o nome do método, mas é aconselhável colocar a descrição para uma melhor
interpretação do significado do processo que está sendo feito.
81
http://www.deinf.ufma.br/~geraldo/dob/9.Sequencia.pdf
Figura 38: Exemplo de Setas de mensagens.
Fonte: o autor.
É muito importante destacar que as mensagens devem ser numeradas
sequencialmente na posição horizontal e de cima para baixo conforme vão
aparecendo no diagrama. As setas que chamam um método são mais grossas,
enquanto as setas mostram apenas uma ocorrência são um pouco mais finas. 
82
Figura 39: Mensagem de Retorno.
Fonte: o autor.
Mensagens de Retorno
As mensagens de Retorno servem para dar uma resposta a uma mensagem para quem 
o chamou (Ator ou objeto). A mensagem pode ser uma resposta de informações 
específicas do método, um valor ou se o método foi executado com sucesso ou não. Elas 
são representadas uma seta tracejada com uma seta apontada inversamente às 
mensagens dos métodos. 
83
Figura 40: Exemplo de Autochamada.
Fonte: o autor.
Autochamadas 
(Automensagens)
As Autochamadas são as mensagens que um objeto envia para si próprio. 
84
Figura 41: Exemplo de Condição.
Fonte: o autor.
Para uma situação de uma repetição (Figura 42), isto é, um disparo de uma
mensagem para vários objetos, pode-se representar pelo símbolo de asterisco (*) que
representa uma iteração e deve ser colocado antes da condição. 
Condições
As Condições ocorrem quando uma mensagem só será enviada a um objeto se uma 
determinada condição for satisfeita. Elas devem estar entre colchetes ([ ]) na 
mensagem. 
85
Figura 42: Exemplo de Repetição.
Fonte: o autor.
Como podemos observar, uma venda pode conter vários itens de venda, assim,
quando a venda é confirmada, cada um de seus itens precisa ser gerados, desta
forma fica indicado que um laço venha a ser executado e a condição informa que,
para cada item da venda, deve ser chamado um método para gerar uma nova
instância da classe Item Venda. 
86
10
Diagrama de Sequência: 
Exercícios
87
Neste capítulo, nos dedicaremos aos exercícios de Diagrama de Sequências
completos, envolvendo a maioria dos conceitos aprendidos no capítulo 9.
Serão apresentados, primeiramente, três exemplos de exercícios de Diagrama de
Sequência, um de Clínica Veterinária, um de Locação de Veículos e outro de uma
Reserva de Quartos em um Hotel, para em seguida, resolvermos alguns exercícios. 
Exemplos de Diagramas de
Sequência
Desenvolva um Diagrama de Sequência para um sistema de Clínica Veterinária
equivalente ao módulo de tratamento e consulta do animal. Temos um Ator chamado
Veterinário e um objeto abstrato chamado “interface do sistema” por meio da qual o
Veterinário interage com o sistema.
No caso de o Veterinário querer verificar as consultas anteriores de um animal, ele
deverá primeiro consultar o dono do animal em um objeto da classe Cliente. Após
identificá-lo, em seguida será necessário visualizar os animais desse cliente, que
retornará todos os animais do Cliente e assim todas as informações dos animais e do
cliente serão manipuladas pela interface do sistema pelo Veterinário.
Ao visualizar a lista de animais do cliente, o Veterinário selecionará um animal, além,
em seguida, visualizar os tratamentos e depois as consultas desse animal, que
retornarão todas as consultas e os tratamentos já realizados do animal para a
interface do sistema, desta forma o Veterinário pode verificá-los.
Agora, o Veterinário, se desejar, deve gravar este novo tratamento e, em seguida,
registrar a nova consulta feita retornando Verdadeiro na interface do sistema e
consequentemente “Consulta e Tratamento Realizados” ao Veterinário. 
88
Figura 43: Diagrama de Sequência de uma Clínica Veterinária.
Fonte: GUEDES, 2008.
Vejamos o exemplo agora de uma Locadora de Veículos, em que temos um Ator
chamado de Atendente e um objeto abstrato chamado “interface do sistema” por
meio da qual o Atendente interage com o sistema para realizar uma locação de
veículo por um Cliente.
O atendente deve verificar se o sócio está cadastrado, se este não estiver, deve ser
feito seu cadastro, retornando cliente cadastrado à interface do sistema e ao
atendente. Agora, se o sócio estiver cadastrado, deve ser selecionado retornando
verdadeiro à interface do sistema e sócio selecionado.
Em seguida, deve verificar se o sócio possui alguma locação pendente na classe de
locação, caso em que recusará o aluguel, retornando verdadeiro e locação recusada
ao atendente. Se não possuir pendência, após consulta da locação, o atendente
deverá agora selecionar o veículo e, em seguida, a locação deverá ser registrada.
Assim, será retornado ao atendente locação realizada. 
89
Figura 44: Diagrama de Sequência de uma Locadora de Veículos.
Fonte: o autor.
Um dos grandes benefícios do Diagrama de Sequência é observar como os
objetos e componentes interagem uns com os outros objetos para poder
concluir todo um processo a ser realizado.
Em outro exemplo, temos uma Reserva de Quarto feita pelo Hóspede por meio da
interface da web. Primeiro, o hóspede deve selecionar a data de entrada e saída na
classe período, retornando verdadeiro à interface da web. E período selecionado ao
hóspede.  
90
Figura 45: Diagrama de Sequência de uma Reserva de Quarto em um Hotel.
Fonte: o autor.
Em seguida, o hóspede consultará os quartos na classe quarto retornando as
informações a ele.   Se desejar, ele selecionará o quarto que necessita, retornando
verdadeiro à interface da web e quarto selecionado a ele.
Se o hóspede não for cadastrado, ele fará seu cadastro no objeto da classe hóspede,
retornando verdadeiro à interface da web e hóspede cadastrado. Agora, se o
hóspede for cadastrado, será feita a seleção no objeto da classe hóspede, retornando
verdadeiro e hóspede selecionado.
Para finalizar, o hóspede confirmará sua reserva com o cadastro da mesma no objeto
da classe Reserva. Em seguida, será disparado um método para a atualização do
quarto, retornando reserva cadastrada e confirmada ao Hóspede. 
91
Exercícios de Diagramas de
Sequência
1. Elabore um Diagrama de Sequência para a Devolução de um Livro por meio de
uma Interface do Sistema pelo Bibliotecário.
Primeiro, o Bibliotecário terá que achar a locação realizada por meio da consulta na
classe de locação, retornando verdadeiro à interface do sistema e a ele. Em seguida,
será necessário realizar o cadastro da devolução por meio de um métodoem um
objeto da classe de devolução, retornando verdadeiro à interface do sistema e
cadastro realizado ao Bibliotecário.
Agora, o Bibliotecário terá que excluir, por meio de um método, a locação realizada e,
em seguida, com outro método, atualizar a situação do livro no objeto da classe de
livro, retornando atualização realizada e locação excluída à interface do sistema e ao
Bibliotecário.
 
2. Elabore um Diagrama de Sequência para um Aluno fazer uma Matrícula em
um Curso gratuito na Web.
Pela Interface da Web o Aluno faz uma consulta dos cursos oferecidos em uma classe
de cursos, retornando as informações dos cursos.
Após a visualização dos cursos, se o Aluno desejar, faz uma consulta nas turmas
disponíveis, para isso ele seleciona primeiro o curso desejado e, em seguida consulta
as turmas disponíveis, retornando as informações da turma ao curso,
consequentemente o curso selecionado à interface da web e os dados das turmas e
do curso ao Aluno.
Se o aluno desejar realizar a matrícula, ele fará a seleção da turma desejada na classe
turma, retornando verdadeiro à interface do sistema e turma selecionada ao Aluno.
Se o Aluno não for cadastrado, ele faz seu cadastro no objeto da classe de aluno por
meio de um método, retornando verdadeiro à interface da web e aluno cadastrado ao
Aluno.
92
Se ele for cadastrado, será feito a seleção do aluno no objeto da classe de aluno,
retornando verdadeiro à interface da web e aluno selecionado ao Aluno.
Para finalizar, o aluno tem que fazer o cadastro da matrícula em um objeto de classe
de matrícula, retornando verdadeiro à interface da web e matrícula realizada ao
Aluno.
 
3. Elabore um Diagrama de Sequência para um Cliente fazer um Pagamento de
uma Prestação em uma Loja Comercial por meio de uma Interface do Sistema
feito pelo Funcionário.
O Funcionário deve fornecer o CPF do cliente para que um método selecione o Cliente
na classe de Cliente, para que em seguida seja disparado um método para consultar
as parcelas em aberto do cliente na classe de parcelas, retornando os dados das
parcelas em aberto e do cliente à interface do sistema e ao Funcionário.
Para fazer o recebimento da conta pelo Funcionário, terá que ser disparado um
método na classe de parcelas para selecionar a parcela desejada, em seguida será
disparado um método para cadastrar o pagamento em um objeto da classe
pagamento. Desta forma, será disparado um método para a atualização da parcela na
classe de parcela, retornando os dados do pagamento da parcela à interface do
sistema e pagamento realizado ao Funcionário. 
93
11
Diagrama de Sequência: 
Exercícios com Repetições 
e Autochamadas
94
Agora, neste capítulo, iremos dedicar aos exercícios de Diagrama de Sequências
completos, envolvendo também os conceitos de repetições (iterações) e
autochamadas vistos no capítulo 9.
Serão apresentados primeiramente três exemplos de exercícios de Diagrama de
Sequência, um de Lançamentos de Notas/Faltas de um Professor, um de Pedidos de
Compra e outro de Matrícula de Disciplinas. 
Fonte: Disponível aqui
Um operador de interação (repetição) de loop indica que o fragmento de
interação é executado repetidamente. O número de vezes que ele é
executado será determinado pelos parâmetros de mínimo e máximo.
Exemplos de Diagramas de
Sequência com Repetição
(Iteração) e Autochamadas
Elabore um Diagrama de Sequência para o Lançamento de Notas/Faltas de um
Professor por meio de uma Interface da Web.
O professor fará seu login do sistema no objeto da classe Professor e com sua
validação no mesmo objeto, retornando verdadeiro à interface. Em seguida, o
Professor terá que ver sua disciplina com seus alunos, para isso será selecionado o
curso, a turma, a disciplina e depois os alunos, retornando as informações à interface
do sistema e consequentemente ao professor da disciplina selecionada.
95
https://www.ibm.com/support/knowledgecenter/pt-br/SSRTLW_9.6.1/com.ibm.xtools.sequence.doc/topics/rinteracoperate.html
Figura 46: Diagrama de Sequência de Lançamento de Notas / Faltas.
Fonte: o autor.
Após a confirmação dada ao professor, o professor lançará as notas, uma a uma no
objeto de classe das notas do aluno, retornando no final as notas atualizadas para o
Professor.
Agora, o professor lançará as faltas, desta forma, fará o lançamento uma a uma no
objeto da classe de faltas do aluno, retornando também, no final, as faltas atualizadas
ao Professor.
Para finalizar, o professor informará a chave de segurança para o fechamento da sua
execução no objeto da classe Professor com sua validação no mesmo objeto,
retornando a ele lançamentos atualizados com sucesso. 
96
No exemplo da Figura 46 são ilustradas duas autochamadas, uma para validar o login
do professor e outra para validar a chave de segurança, note que o objeto prof1
dispara em si mesmo a chamada do método de validação do login e da chave de
segurança.
Também são demonstradas duas repetições (iterações), uma no lançamento das
notas e outra no lançamento das faltas, pois podem existir diversas notas e faltas
para serem lançadas. Utilizamos o símbolo da repetição indicando a possibilidade de
que um laço venha a ser executado e inserimos a condição que informa que para
cada nota/falta deve ser chamado um método para gerar uma nova instância da
classe de nota/falta.
Elabore um Diagrama de Sequência para a realização de um Pedido de Compra
feito pelo Gerente de Compras por meio da Interface do Sistema.
Primeiro, o Gerente deverá verificar os produtos que estão abaixo do estoque mínimo
na classe de produtos, que em seguida o método retornará as informações solicitadas
pelo Gerente.
Em seguida, o Gerente precisará identificar o Fornecedor dos produtos, desta forma o
produto primeiro é identificado e em seguida, será disparado o método
SelFornecedor para selecionar o fornecedor dos produtos, que retornará o
fornecedor dos produtos à interface do sistema e ao Gerente.
Será necessário cadastrar o pedido pelo método Cadped e, em seguida, cadastrar os
itens deste pedido um a um, lembrando que podemos ter vários itens no pedido.
Quando acabar, o método retornará ao pedido os itens cadastrados e
consequentemente será retornado à interface do sistema pedido cadastrado com
sucesso. 
97
Figura 47: Diagrama de Sequência de Pedido de Compra.
Fonte: o autor.
Na Figura 47, podemos notar que há uma iteração, pois podem existir vários itens de
pedido em um mesmo pedido.
Elabore um Diagrama de Sequência para a realização de uma Matrícula de um Aluno
em Disciplinas do seu Curso.
Primeiro, o aluno precisa ser “logado” (identificar-se) no objeto da classe aluno, pelo
método login e pela sua validação no mesmo objeto, retornando login efetuado com
sucesso.
Em seguida, ele selecionará seu curso, sua turma e, em seguida, consultará as
disciplinas disponíveis, retornando as informações a ele das disciplinas da turma de
seu curso.
Agora, ele fará sua matrícula com a seleção das disciplinas, desta forma será
disparado o método de seleção da disciplina que será feito uma a uma (lembre-se que
ele pode fazer mais de uma disciplina). Quando acabar, será disparado o método
CadMat para cadastrar a matrícula, assim retornará a mensagem matrícula
cadastrada e matrícula feita com sucesso. 
98
Figura 48: Diagrama de Sequência de Matrícula de Disciplinas.
Fonte: o autor.
Fonte: Disponível aqui
As Autochamadas são mensagens que um objeto envia para si mesmo. A
mensagem parte do objeto e atinge o próprio objeto.
99
https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-diagrama-sequencia-mensagens_v01.pdf
Exercícios de Diagrama de
Sequência com Autochamadas
e Repetições (Iterações)
1. Elabore um Diagrama de Sequência para a Locação de Livros por meio de uma
Interface do Sistema pelo Bibliotecário.
Primeiro, o Bibliotecário terá que entrar com a identificação (RA) do aluno, por meio
de um método de consulta no objeto da classe aluno, retornando verdadeiro à
interface do sistema e a ele. Em seguida, será necessário realizar a consulta do(s)
livro(s)