Prática Análise Orientada a Objetos I

Prévia do material em texto

2015
AnáLise orientADA A 
oBJetos i
Prof. Jean Carlos Possamai
Copyright © UNIASSELVI 2015
Elaboração:
Prof. Jean Carlos Possamai
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfi ca elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
005.1 
P856ac Possamai, Jean Carlos
Análise orientada a objetos I / Jean Carlos Possamai. Indaial : 
UNIASSELVI, 2015.
189 p. : il.
 ISBN 978-85-7830-874-2
 
1. Programação orientada a objetos. 
I. Centro Universitário Leonardo Da Vinci. 
Impresso por:
III
ApresentAção
Prezado(a) acadêmico(a)!
Seja bem-vindo ao mundo da Programação Orientada a Objetos. 
Neste universo você vai se deparar com termos como atributos, métodos, 
abstração, encapsulamento, classes, hierarquia das classes, processo 
unificado, entre outros, que compõem o material de estudo desta disciplina 
e, por consequência, o dia a dia de um analista, desenvolvedor, programador, 
ou seja, o profissional da programação.
Este caderno pressupõe que você já possua alguma experiência 
anterior em programação, principalmente JAVA, afinal muitos dos objetos, 
classes e diagramas apresentados neste material estão voltados a esta 
linguagem de programação. É essencial você fazer uso dos conhecimentos 
adquiridos em disciplinas anteriores para então conseguir acompanhar 
o desenvolvimento de um sistema e assim auxiliar você na construção do 
entendimento em programação orientada a objetos.
Aproveito a oportunidade para destacar a importância de desenvolver 
as autoatividades, afinal cada exercício deste caderno foi desenvolvido para 
a fixação de conceitos por meio da prática. Em caso de dúvida na realização 
das atividades, sugiro que você entre em contato com seu Tutor Externo ou 
com a tutoria da Uniasselvi, não prosseguindo as atividades sem ter sanado 
todas as dúvidas que irão surgindo.
Vale destacar a necessidade de dedicação e de muita determinação, 
afinal a Programação Orientada a Objetos exige de você bem mais do que 
apenas este caderno para sua total compreensão. Aqui, você recebe somente 
um início, ou seja, os conceitos de determinados pontos importantes na 
programação, porém é somente na prática que você consegue compreender 
o mundo da programação como um todo.
Lembre-se que o mundo da informática é encantador, assim, seu 
entusiasmo por este universo depende somente de você, destacando neste 
momento a compreensão da lógica envolvida no processo de construção de 
programas. Por este motivo, destaco uma frase que considero importante 
no caso da programação, afinal: “Para se ter sucesso, é amar de verdade o 
que se faz. Caso contrário, levando em conta apenas o lado racional, você 
simplesmente desiste. É o que acontece com a maioria das pessoas “ (Steven 
Jobs – criador da Apple).
Bom estudo! Sucesso na sua trajetória acadêmica e profissional!
JEAN CARLOS POSSAMAI
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há 
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova 
diagramação no texto, aproveitando ao máximo o espaço da página, o que também 
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto 
em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
V
VI
VII
UNIDADE 1 - O PARADIGMA DA ORIENTAÇÃO A OBJETOS ............................................. 1
TÓPICO 1 - HISTÓRICO .................................................................................................................... 3
1 INTRODUÇÃO .................................................................................................................................. 3
2 O QUE SÃO OBJETOS? ................................................................................................................... 3
2.1 OBJETOS COMPUTACIONAIS .................................................................................................. 5
2.2 OS DIFERENTES TIPOS DE OBJETOS COMPUTACIONAIS ............................................... 5
2.2.1 Objetos computacionais visuais......................................................................................... 5
2.2.2 Objetos com tarefa relacionada .......................................................................................... 6
2.2.3 Objetos multimídias ............................................................................................................ 7
2.2.4 Objetos de domínio do trabalho ........................................................................................ 8
2.3 ORIENTAÇÃO A OBJETOS ........................................................................................................ 9
2.3.1 Análise orientada a objetos ................................................................................................. 9
2.3.2 Análise orientada a objetos ................................................................................................. 10
2.3.3 Vantagens e benefícios da orientação a objetos ............................................................... 11
RESUMO DO TÓPICO 1..................................................................................................................... 13
AUTOATIVIDADE .............................................................................................................................. 14
TÓPICO 2 - PROCESSO UNIFICADO (UP) ................................................................................... 17
1 INTRODUÇÃO .................................................................................................................................. 17
2 CARACTERIZAÇÃO DO UP .......................................................................................................... 18
2.1 FASES DO UP ................................................................................................................................ 22
2.2 RUP – RATIONAL UNIFIED PROCESS .................................................................................... 25
2.2.1 Blocos de Construção do RUP ........................................................................................... 27
2.2.2 Papéis no RUP ...................................................................................................................... 27
 2.2.2.1 Papel do Analista ..................................................................................................... 27
 2.2.2.2 Papel do Desenvolvedor ......................................................................................... 28
 2.2.2.3 Papel de Testador ..................................................................................................... 29
 2.2.2.4 Papel de Gerente ...................................................................................................... 292.2.2.5 Outros Papéis............................................................................................................ 30
2.2.3 AUP – Agile Unified Process .............................................................................................. 32
2.2.4 Open UP – Open Unified Process ..................................................................................... 34
2.2.5 EUP – Enterprise Unified Process ..................................................................................... 35
2.2.6 RUP-SE – Rational Unified Process – Systems Engineering ......................................... 36
RESUMO DO TÓPICO 2..................................................................................................................... 38
AUTOATIVIDADE .............................................................................................................................. 39
TÓPICO 3 - ESTRUTURAS E RELACIONAMENTOS ................................................................. 41
1 INTRODUÇÃO .................................................................................................................................. 41
2 TIPOS DE ESTRUTURAS E RELACIONAMENTOS ................................................................ 41
2.1 ESTRUTURA GENERALIZAÇÃO – ESPECIALIZAÇÃO (GE) ............................................ 42
2.2 ESTRUTURA TODO – PARTE (TP) ........................................................................................... 43
2.3 CONEXÕES ................................................................................................................................... 44
2.3.1 Conexões de ocorrência ...................................................................................................... 44
sumário
VIII
2.3.2 Cardialidade ......................................................................................................................... 45
2.3.3 Conexão de mensagem ....................................................................................................... 45
2.3.4 Polimorfismo ........................................................................................................................ 47
LEITURA COMPLEMENTAR ............................................................................................................ 48
RESUMO DO TÓPICO 3..................................................................................................................... 54
AUTOATIVIDADE .............................................................................................................................. 55
UNIDADE 2 - UNIFIED MODELING LANGUAGE (UML) ........................................................ 57
TÓPICO 1 - INTRODUÇÃO A UML ................................................................................................ 59
1 INTRODUÇÃO .................................................................................................................................. 59
2 BREVE HISTÓRICO DA UML ....................................................................................................... 59
3 POR QUE MODELAR SOFTWARE? .............................................................................................. 61
3.1 LEVANTAMENTO E ANÁLISE DE REQUISITOS .................................................................. 63
3.2 PROTOTIPAÇÃO ......................................................................................................................... 65
3.3 PRAZOS E CUSTOS ..................................................................................................................... 67
3.4 MANUTENÇÃO ........................................................................................................................... 68
3.5 DOCUMENTAÇÃO HISTÓRICA .............................................................................................. 70
4 EVOLUÇÃO ........................................................................................................................................ 71
RESUMO DO TÓPICO 1..................................................................................................................... 73
AUTOATIVIDADE .............................................................................................................................. 74
FASES DO DESENVOLVIMENTO DE UM SISTEMA UML ...................................................... 77
1 INTRODUÇÃO .................................................................................................................................. 77
2 ANÁLISE DE REQUISITOS ............................................................................................................ 77
3 ANÁLISE ............................................................................................................................................. 79
4 DESIGN (PROJETO) .......................................................................................................................... 81
5 PROGRAMAÇÃO ............................................................................................................................. 82
RESUMO DO TÓPICO 2..................................................................................................................... 84
AUTOATIVIDADE .............................................................................................................................. 85
TÓPICO 3 - MODELOS DE ELEMENTOS ..................................................................................... 87
1 INTRODUÇÃO .................................................................................................................................. 87
2 CLASSES ............................................................................................................................................. 87
3 OBJETOS ............................................................................................................................................. 89
4 ESTADOS ............................................................................................................................................ 90
5 PACOTES............................................................................................................................................. 91
6 COMPONENTES ............................................................................................................................... 92
7 RELACIONAMENTOS .................................................................................................................... 93
8 MECANISMOS GERAIS ................................................................................................................. 98
LEITURA COMPLEMENTAR ............................................................................................................ 101
RESUMO DO TÓPICO 3..................................................................................................................... 103
AUTOATIVIDADE .............................................................................................................................. 104
UNIDADE 3 - DIAGRAMAS ............................................................................................................. 107
TÓPICO 1 - DIAGRAMAS DE CASOS DE USO ........................................................................... 109
1 INTRODUÇÃO .................................................................................................................................. 109
2 ATORES ............................................................................................................................................... 109
3 CASO DE USO ................................................................................................................................... 111
4 DOCUMENTAÇÃO DE CASOS DE USO .................................................................................... 113
5 ASSOCIAÇÕES.................................................................................................................................. 114
IX
6 INCLUSÃO ......................................................................................................................................... 114
7 EXTENSÃO ......................................................................................................................................... 115
8 ESPECIALIZAÇÃO/ GENERALIZAÇÃO .................................................................................... 117
9 EXEMPLOS DE DIAGRAMA DE CASOS DE USO ................................................................... 119
RESUMO DO TÓPICO 1..................................................................................................................... 122
AUTOATIVIDADE .............................................................................................................................. 123
TÓPICO 2 - DIAGRAMA DE CLASSES .......................................................................................... 125
1 INTRODUÇÃO .................................................................................................................................. 125
2 CLASSES, ATRIBUTOS E MÉTODOS ......................................................................................... 125
3 ABSTRAÇÃO...................................................................................................................................... 129
4 ENCAPSULAMENTO....................................................................................................................... 130
4.1 HIERARQUIA DAS CLASSES .................................................................................................... 133
5 HERANÇA .......................................................................................................................................... 133
5.1 HERANÇA MÚLTIPLA ............................................................................................................... 135
6 CLASSE ASSOCIATIVA .................................................................................................................. 137
7 RESTRIÇÃO ....................................................................................................................................... 139
8 PERSISTÊNCIA ................................................................................................................................. 139
9 EXEMPLOS DE DIAGRAMAS DE CLASSES ............................................................................. 140
RESUMO DO TÓPICO 2..................................................................................................................... 148
AUTOATIVIDADE .............................................................................................................................. 149
TÓPICO 3 - DIAGRAMA DE SEQUÊNCIA ................................................................................... 151
1 INTRODUÇÃO .................................................................................................................................. 151
2 ATORES ............................................................................................................................................... 151
3 OBJETOS ............................................................................................................................................. 152
4 LINHA DE VIDA ............................................................................................................................... 152
5 FOCO DE CONTROLE OU ATIVAÇÃO ...................................................................................... 153
6 MENSAGENS OU ESTÍMULOS .................................................................................................... 154
7 MENSAGENS DE RETORNO ........................................................................................................ 156
8 AUTOCHAMADAS OU AUTODELEGAÇÕES ......................................................................... 157
9 CONDIÇÕES OU CONDIÇÕES DE GUARDA ......................................................................... 158
10 EXEMPLOS DE DIAGRAMAS DE SEQUÊNCIA .................................................................... 159
RESUMO DO TÓPICO 3..................................................................................................................... 164
AUTOATIVIDADE .............................................................................................................................. 165
TÓPICO 4 - DEMAIS DIAGRAMAS EXISTENTES ..................................................................... 167
1 INTRODUÇÃO .................................................................................................................................. 167
2 DIAGRAMAS DE SERVIÇOS ........................................................................................................ 167
3 DIAGRAMA DE COLABORAÇÃO .............................................................................................. 169
4 DIAGRAMA DE ATIVIDADES ..................................................................................................... 172
5 DIAGRAMAS DE ESTADOS ......................................................................................................... 174
LEITURA COMPLEMENTAR ............................................................................................................ 176
RESUMO DO TÓPICO 4..................................................................................................................... 183
AUTOATIVIDADE .............................................................................................................................. 184
REFERÊNCIAS ...................................................................................................................................... 187
X
1
UNIDADE 1
O PARADIGMA DA 
ORIENTAÇÃO A OBJETOS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
Esta unidade tem por objetivos:
• conhecer o histórico da programação orientada a objetos;
• identificar e caracterizar os objetos;
• compreender a cerca do Processo Unificado, sua caracterização e suas fases;
• conhecer como se comporta o Processo Unificado na Programação Orien-
tada, quais as suas caracterizações e suas fases;
• compreender como ocorre a interação entre os objetos, ou seja, a estrutura 
e relacionamentos, existentes entre os objetos.
Esta unidade de ensino está dividida em três tópicos, sendo que no final 
de cada um deles, você encontrará atividades que contribuirão para a 
apropriação dos conteúdos.
TÓPICO 1 – HISTÓRICO
 
TÓPICO 2 – PROCESSO UNIFICADO (UP)
 
TÓPICO 3 – ESTRUTURAS E RELACIONAMENTOS
2
3
TÓPICO 1
UNIDADE 1
HISTÓRICO
1 INTRODUÇÃO
Como já é de seu conhecimento, a tecnologia se encontra em constante 
evolução, seja em novos hardwares, gadgets e software.
Especificamente falando de software, também é possível perceber que a 
forma como são desenvolvidos os softwares encontra-se em constante evolução. 
Neste contexto, vale destacar que ao final da década de 60 surgiu a “Engenharia 
de Software”, que veio para tentar solucionar problemas de qualidade e 
produtividade de software. Já nas duas décadas seguintes 70 e 80, vários estudiosos 
desenvolveram técnicas com propostas para solucionar estes problemas.
Uma das técnicas desenvolvidas pela Engenharia de Software foi a 
orientação a objetos, que ocorreu na década de 90, sendo amplamente difunda 
entre a comunidade de desenvolvedores, afinal, apresentava maior fidelidade 
às situações em que são aplicadas no mundo real, como: maior produtividade, 
usabilidade e reusabilidade de funções e códigos.
Nesta unidade serão abordados aspectos sobre o paradigma da orientação 
a objetos, sua origem, seus conceitos, suas aplicações, suas vantagens e como 
utilizá-los no contexto de desenvolvimento de software.
2O QUE SÃO OBJETOS?
Para que possamos iniciar nossos estudos sobre a Orientação a Objetos, 
vamos visualizar algumas definições básicas, como por exemplo, o que é um 
objeto? Correia e Tafner (2001, p. 1) se baseiam no dicionário Aurélio, onde temos 
as seguintes definições para palavra objeto: 
[Do lat. Objectu, part. De objicere, ´por, lançar diante´, ´expor´.] S.m.
1. Tudo que é exterior ao espírito;
2. Tudo que é aprendido pelo conhecimento, que não é o sujeito do 
conhecimento;
3. Tudo que é manipulável e manufaturável;
4. Tudo que é perceptível por qualquer dos sentidos;
5. Coisa, peça, artigo de compra e venda;
6. Matéria, assunto.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
4
Ambler (1998, p. 5) em seu estudo traz uma definição computacional 
de objeto onde “considera que qualquer indivíduo, lugar, coisa, tela, relatório 
ou conceito que seja aplicável ao sistema é um objeto”. Ex.: Em um sistema 
universitário, Arthur Dent é um estudante-objeto; ele atende a diversos 
seminários-objetos e está trabalhando em um mestrado-objeto. Já em um sistema 
bancário Artur é um cliente-objeto e possui uma conta corrente-objeto da qual 
emite cheque-objetos.
FIGURA 1 – EXEMPLOS DE OBJETOS
FONTE: Disponível em: <http://www.dreamstime.com/stock-photo-retro-objects-icons-detailed-
set-image30928100>. Acesso em: 23 dez. 2014.
TÓPICO 1 | HISTÓRICO
5
Objetos são, com frequência, semelhantes a outros tipos de objetos.
Estudantes compartilham de características semelhantes (fazem os 
mesmos tipos de coisas, são descritos da mesma forma), cursos compartilham 
características semelhantes, contas bancárias compartilham características 
semelhantes e assim por diante.
Assim, ao analisar as duas citações descritas acima, podemos concluir que 
objeto é uma coisa física (pedra), ou abstrata (uma equação ou conta corrente).
2.1 OBJETOS COMPUTACIONAIS
Objetos computacionais procuram reproduzir as mesmas características 
e comportamentos dos objetos do mundo real dentro de um sistema. Correia e 
Tafner (2001) reforçam que os programadores podem interagir com estes objetos 
ativando características ou comportamentos, sem necessidade de entender o 
funcionamento interno do objeto computacional. Ou seja, para interagir com 
objetos, precisamos apenas conhecer o que estes objetos fazem e usá-los, nada 
mais.
2.2 OS DIFERENTES TIPOS DE OBJETOS 
COMPUTACIONAIS
Para que você acadêmico possa compreender melhor a relação existente 
entre os objetos computacionais e seu comportamento agregado, seguem alguns 
tipos diferentes de objetos computacionais encontrados, bem como seus exemplos.
2.2.1 Objetos computacionais visuais
A utilização de programação visual proporciona ao usuário uma 
experiência totalmente interativa. Desta forma, o usuário pode interagir 
com sistema computacional através do mouse ou teclado, apertando botões, 
selecionando itens de um calendário, escrevendo em um campo texto ou 
selecionando itens de uma lista, conforme ilustrado na figura 2.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
6
FIGURA 2 – OBJETOS COMPUTACIONAIS VISUAIS COMUNS PARA INTERFACE COM USUÁRIO
FONTE: Sistema ERP Empresa Supero Tecnologia
2.2.2 Objetos com tarefa relacionada
Os desenvolvedores de softwares utilizam os objetos computacionais 
visuais para desenvolver e realizar tarefas relacionadas a dados proporcionando 
aos usuários: janelas, campos ou botões com os quais estes possam interagir. 
Ex.: Um editor de textos qualquer, conforme representado na figura a 
seguir, é um bom exemplo. Neste editor, o documento é apresentado ao usuário 
por meio de uma interface gráfica (também orientada a objetos) que permite 
uma interação direta e praticamente total com o documento em que as barras de 
ferramentas são objetos com os quais o usuário pode interagir com o texto.
TÓPICO 1 | HISTÓRICO
7
FIGURA 3 – OBJETOS COM TAREFA RELACIONADA COMUM PARA INTERFACE COM USUÁRIO
FONTE: O autor
2.2.3 Objetos multimídias
Os objetos multimídia proporcionam uma rica experiência de interação 
com o usuário. Este tipo de objeto computacional possibilita a reprodução de 
sons, imagens, animações ou vídeos da mesma forma que nos editores de texto. 
Como podemos verificar na figura a seguir, no reprodutor de fotos as barras de 
ferramentas são objetos que permitem que o usuário interaja com o conteúdo 
alterando seu comportamento.
FIGURA 4 – OBJETOS MULTIMÍDIAS COMUNS PARA INTERFACE COM USUÁRIO
FONTE: O autor
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
8
2.2.4 Objetos de domínio do trabalho
São características ou compartimentos de um objeto ou sistema 
operacional, criado para ficar, na maioria das vezes, oculto aos usuários. Afinal, 
estes estão diretamente envolvidos com o funcionamento do sistema ou objeto 
computacional. Para exemplificar esta situação observe na figura a seguir o 
gerenciador de tarefas do sistema operacional. Ele está quase sempre oculto, 
garantindo que os milhares de objetos do sistema operacional que fazemos uso 
trabalhem adequadamente.
FIGURA 5 – OBJETOS DE DOMÍNIO DE TRABALHO COMUNS PARA INTERFACE COM USUÁRIO
FONTE: O autor
TÓPICO 1 | HISTÓRICO
9
2.3 ORIENTAÇÃO A OBJETOS
O conceito de Orientação a Objetos surgiu com o intuito de minimizar os 
problemas encontrados até então na criação de softwares complexos, projetados 
por meio de decomposição funcional e sub-rotinas (ARAÚJO, 2009).
A análise e programação orientada a objetos, não se resume apenas 
na utilização de componentes de interface gráfica, mas, sim, na definição e 
programação do sistema computacional, desde que atenda à metodologia.
Metodologia esta, que segundo Correia e Tafner (2001, p. 7) serve tanto 
para a definição lógica do sistema quanto para a sua implementação, sendo esta 
uma das vantagens da Orientação a Objetos.
2.3.1 Análise orientada a objetos
Como já foi visto anteriormente, um objeto é qualquer coisa, real ou 
abstrata, a respeito da qual armazenamos dados e os métodos que os manipulam 
disparam operações que mudam o estado dos objetos, possibilitando que eles 
interagem uns com os outros. 
Segundo Araújo (2009, p. 46), “o foco da análise Orientada a Objetos é no 
mapeamento de uma solução sistêmica para algum processo de negócio”. Assim, 
na análise orientada a objetos, os analistas e desenvolvedores têm como objetivo 
principal identificar os objetos que farão parte do sistema computacional que está 
sendo automatizado, seus atributos e principalmente no comportamento destes 
objetos dentro do sistema computacional.
 
Larman (2004, p. 31) descreve que durante a análise orientada a objetos, 
“o objetivo é encontrar e descrever os objetos – ou conceitos – no domínio do 
problema. No caso do sistema de informação de uma biblioteca, por exemplo, 
alguns dos conceitos incluem Livro, Biblioteca e usuário”, observe a representação 
por meio da figura a seguir, demonstrada na programação orientada a objetos.
Orientação a Objetos consiste em considerar os sistemas computacionais como 
uma coleção de objetos que interagem de maneira organizada (FARINELLI, 2007).
IMPORTANT
E
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
10
2.3.2 Análise orientada a objetos
Segundo Larman (2004, p. 31), “durante o projeto orientado a objetos, há 
uma ênfase na definição dos objetos de software e como eles colaboram para a 
satisfação dos requisitos. No sistema da biblioteca, por exemplo, um objeto de 
software Livro, pode ter um atributo título e um método obterCapítulo”, observe 
a figura a seguir.
Em seu estudo David (2007, p. 1) define que a Programação Orientada a 
Objetos “foi criada para tentar aproximar o mundo real do mundo virtual. Assim, 
a ideia fundamental é tentar simular o mundo real dentro do computador. Para 
isso, nada mais natural do que utilizar Objetos, afinal, nosso mundo é composto 
por objetos”.
Na Programação Orientada a Objetos, o analista ou desenvolvedor é 
responsável por delinear o mundo dos objetos, e assim determinar como devem 
interagir entre si. Desta forma, é possívelperceber que os objetos conversam 
entre si por meio de envio de mensagens, e, assim, a função do analista ou 
desenvolvedor é verificar quais devem ser as mensagens que cada objeto deve 
receber, e consequentemente verificar qual ação deve ser tomada ao receber cada 
mensagem.
Finalmente Larman (2004) escreve que durante a implementação ou 
programação orientada a objetos, os objetos são implementados, como uma classe 
Livro em Java, conforme demonstra a figura seguinte.
“a Análise Orientada a Objetos consiste em definir quais objetos fazem parte de 
um sistema e a maneira como se comportam” (CORREIA e TAFNER, 2001, p. 8).
IMPORTANT
E
TÓPICO 1 | HISTÓRICO
11
FIGURA 6 – A ORIENTAÇÃO A OBJETOS ENFATIZA A REPRESENTAÇÃO DE OBJETOS
FONTE: LARMAN (2004, p. 31)
2.3.3 Vantagens e benefícios da 
orientação a objetos
Ao estudar a Orientação a Objetos, fica fácil perceber que sua principal 
vantagem é a utilização de uma mesma metodologia, tanto para a análise de 
sistemas, quanto para a programação.
Neste contexto, Farinelli (2007) descreve que a Orientação a Objetos 
consiste em conceber um sistema computacional como um todo orgânico 
formado por objetos que se relacionam entre si, trazendo consigo alguns 
benefícios, como por exemplo: unificação entre dados e processos; consistência 
entre análise e desenvolvimento; reutilização e aumento da produtividade; 
multidesenvolvimento e, por último, mas não menos importante, suas facilidades 
de manutenção.
“Programação Orientada a Objetos consiste em utilizar objetos computacionais 
para implementar a funcionalidade de um sistema”. (CORREIA e TAFNER, 2001, p. 8)
IMPORTANT
E
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
12
Assim, para finalizar o pensamento acerca deste tema, pode-se verificar 
que a principal utilização desta ferramenta é a reutilização das informações 
constantes no sistema.
13
Neste tópico, vimos:
• O Paradigma da Orientação a Objetos, que trata da utilização no 
desenvolvimento de softwares, seu histórico; afinal, surgiu há algumas 
décadas e, desde então, vem sendo difundido e adaptado às necessidades do 
mercado.
• Os objetos e seus diferentes tipos: objetos computacionais, objetos visuais, 
objetos multimídias, objetos de domínio do trabalho e objetos com tarefa 
relacionada.
• A análise e programação orientada a objetos, que segundo David (2007), a 
Programação Orientada a Objetos foi criada para tentar aproximar o mundo 
real do mundo virtual. Assim, a ideia fundamental é tentar simular o mundo 
real dentro do computador. 
Neste momento, você está apto a realizar as autoatividades deste tópico 
e iniciar na sequência, o Tópico 2 desta unidade.
Bom estudo!
RESUMO DO TÓPICO 1
14
AUTOATIVIDADE
1 Na área da informática um objeto pode ser considerado qualquer indivíduo, 
lugar, coisa, tela, relatório ou conceito que seja aplicável ao sistema. Com 
base nesta definição, cite os diversos tipos de objetos computacionais.
2 São características ou compartimentos de um objeto ou sistema operacional, 
criados para ficarem, na maioria das vezes, ocultos aos usuários. Esta 
afirmação se refere a:
a) Objetos multimídias.
b) Objeto domínio de trabalho.
c) Objetos computacionais visuais.
d) Objetos com tarefa relacionada.
3 Assinale V para as sentenças verdadeiras e F para as falsas no que diz 
respeito à Orientação a Objetos.
( ) A metodologia utilizada na Orientação a Objetos serve tanto para 
programação quanto para análise.
( ) A Análise Orientada a Objetos é bem definida e consiste em apresentar 
quais os objetos que compõem um sistema e como se comportam.
( ) Com relação à Programação Orientada a Objetos, ela somente utiliza 
a estrutura de dados que pode simular o comportamento dos objetos, 
prejudicando, desta forma, a análise e programação do sistema.
( ) Uma das vantagens da Análise de Orientação a Objetos do analista ou 
desenvolvedor é de dividir com o usuário seu entendimento acerca do 
programa.
Agora, assinale a sequência CORRETA:
a) ( ) V – F – F – V.
b) ( ) F – F – V – F.
c) ( ) V – V – F – V.
d) ( ) F – V – F – F.
15
4 Utilizando-se das informações recebidas durante o estudo deste tópico, 
descreva a diferença em Análise e Programação Orientada a Objetos.
5 Descreva uma das principais vantagens da Orientação a Objetos.
16
17
TÓPICO 2
PROCESSO 
UNIFICADO (UP)
UNIDADE 1
1 INTRODUÇÃO
O Processo Unificado é um dos mais importantes padrões da indústria 
de software atual. Vale destacar que o processo unificado (UP ou Unified Process) 
foi desenvolvido por três importantes pioneiros da orientação a objetos nos anos 
1990 (Jacobson, Booch e Rumbaugh). Este é o resultado de mais de 30 anos de 
experiência acumulada em forma de projetos, notações e processos.
O UP é o primeiro modelo de processo inteiramente adaptado ao uso da 
notação UML (Unified Modeling Language). Sua concepção foi baseada nas práticas 
de maior Retorno do investimento (ROI) de mercado.
Wazlawick (2013, p. 75) descreve ainda que as atividades do UP são bem 
definidas no seguinte sentido:
a)Elas são compostas por uma descrição clara e precisa.
b)Apresentam responsáveis.
c)Nestas atividades apresentam-se os artefatos de entrada e saída.
d)Determinam as dependências entre as atividades.
e)Possuem um modelo de ciclo de vida bem definido.
f)São acompanhadas de procedimentos adequados para o uso das 
ferramentas disponibilizadas. 
g)Indicam o uso da linguagem UML.
Neste tópico será abordado acerca do Processo Unificado, principalmente 
sua caracterização, suas fases e por fim suas derivações.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
18
2 CARACTERIZAÇÃO DO UP
O UP é um framework extensível para a concepção de processos, podendo 
ser adaptada as características de diferentes empresas e projetos (WAZLAWICK, 
2013). Vejamos a seguir as principais características do UP:
a) Dirigido por Caso de Uso
Este é um processo compreendido do ponto de vista do usuário, não 
antecipando decisões de implementações. Para o UP, o conjunto de casos de uso 
deve esgotar toda a funcionalidade possível do sistema. 
Neste momento, vale destacar, a aplicação mais fundamental do caso de 
uno no desenvolvimento de sistemas é a incorporação dos requisitos funcionais 
de forma organizada. Cada passo dos fluxos principais e alternativos de um 
caso corresponde a uma função do sistema. Requisitos não funcionais podem 
ser anotados juntamente com os casos de usos de seus passos, e requisitos 
suplementares são anotados em um documento à parte (WAZLAWICK, 2013).
FIGURA 7 – CASOS DE USO
FONTE: Disponível em: <http://www.devmedia.com.br/artigo-clube-delphi-83-modelagem-uml-
com-together/11031>. Acesso em: 23 dez. 2014.
Cadastrar
Curso
Cadastrar
Professor
Cadastrar
Disciplina
Cadastrar
Aluno
Matricular
Aluno
Secretaria
TÓPICO 2 | PROCESSO UNIFICADO (UP)
19
a) Centrado na arquitetura
O UP sugere desenvolver uma sólida arquitetura de sistema. As 
funcionalidades identificadas nos diversos casos de uso devem ser incrementadas 
a esta arquitetura.
É importante destacar que a arquitetura pode ser compreendida como 
o conjunto de classes, possivelmente agrupadas em componentes que realizam 
operações definidas pelo sistema. Para Wazlawick (2013, p. 76), “a arquitetura 
é basicamente um modelo que define a estrutura da informação, suas possíveis 
operações e sua organização em componentes ou até mesmo em camadas”.
FIGURA 8 – CENTRADO NA ARQUITETURA
FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014.
A arquitetura se desenvolve por meio das visões dos usuários demonstradas 
em casos de uso, sendo esta influenciada por fatores de implementação: arquitetura 
de computador, sistema operacional, dbms, protocolos de redes, linguagem de 
programação, ambiente de interface gráfica, biblioteca de funções disponíveis, 
sistemas legados, necessidade de performance, portabilidade, entre outros.
Application-specific layer
Classes específicas de negócio
Application-general layer
Classes de ServiçosMiddleware layer
Pacotes Genéricos
System-software layer
Sistemas Operacionais
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
20
FIGURA 9 – FATORES QUE INFLUENCIAM A ARQUITETURA
FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014.
a) Interativo e Incremental
“Assim como os desenvolvimentos ágeis, o UP preconiza o 
desenvolvimento baseado em ciclos interativos de duração fixa, onde em cada 
interação a equipe incorpora à arquitetura as funcionalidades necessárias para 
realizar os casos de uso abordados”. (WAZLAWICK, 2013, p. 77).
 
Lembre-se, acadêmico(a), para cada interação os desenvolvedores 
identificam os casos de uso relevante, analisando-os segundo a arquitetura 
selecionada. Ao final, o produto da interação é componente (modelos ou módulos 
executáveis). Desta forma, verifica-se então se os componentes satisfazem os 
casos de uso e a arquitetura. Se a implementação atinge os objetivos, ou seja, 
seus componentes satisfazem os casos de uso e a arquitetura, o desenvolvimento 
passa para a próxima interação, caso contrário, os desenvolvedores devem 
revisar as decisões anteriores e tentar uma nova abordagem (REBOUÇAS, 2007).
System software
Middleware (including frameworks)
Legacy systems
Standards and policies
Nonfunctional requirements
Distribution needs
Constraints and Enablers
Use Cases
Architecture
Experience:
Previous architectures
Architectural patterns
TÓPICO 2 | PROCESSO UNIFICADO (UP)
21
FIGURA 10 – DESENVOLVIMENTO INTERATIVO E INCREMENTAL
FONTE: Disponível em: <http://www.devmedia.com.br/introducao-ao-processo-unificado/3931>. 
Acesso em: 23 dez. 2014.
Como principais benefícios do desenvolvimento interativo, Larman (2004, 
p. 41) destaca: 
a)Mitigação precoce.
b)Progresso visível desde o início.
c)Realimentação, envolvimento do usuário e adaptação imediatos, 
levando a um sistema refinado que atenda, de forma mais adequada, 
às reais necessidades dos interessados no projeto.
d)A complexidade é administrada, desta forma, a equipe não é 
sobrecarregada pela paralisia da análise ou por passos muito longos 
e complexos.
e)O aprendizado obtido em uma interação pode ser metodicamente 
usado para melhorar o próprio processo de desenvolvimento, 
interação por interação.
a) Focado em riscos
Este tipo de abordagem prioriza os casos de uso mais crítico onde são 
tratados primeiro os problemas mais difíceis. Neste caso, os requisitos ou casos 
de uso de maior risco são os mais imprevisíveis, assim, estudá-los primeiramente 
além de garantir maior aprendizado sobre o sistema e decisões arquiteturais, vai 
fazer com que riscos arquiteturais sejam dominados o mais cedo possível.
Realimentação 
da iteração N leva 
ao refinamento 
e adaptação dos 
requisitos e do 
projeto na iteração 
N+1
RequisitosTempo
N
N+1
Quatro semanas por exemplo.
O sistema cresce incrementalmente.
Requisitos
Implementação
Implementação
Testes e 
Integração
Testes e 
Integração
Projeto
Projeto
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
22
2.1 FASES DO UP
Caro(a) acadêmico(a)! Observe, a seguir, quais são as fases que compõem 
a construção de um UP, e ao final das descrições, observe a figura que demonstra 
como essas fases se comportam durante o processo.
a) Concepção (inception)
Busca-se obter uma visão da abrangência do sistema. 
Nesta fase são levantados os requisitos, e um modelo conceitual preliminar 
é construído, bem como ocorre a identificação dos casos de uso de alto nível, que 
implementam as funcionalidades requeridas pelo cliente.
 
Neste momento calcula-se também o esforço de desenvolvimento dos 
casos de uso e é construído o plano de desenvolvimento, sendo este composto 
por um conjunto de ciclos interativos nos quais são acomodados os casos de 
uso. Pode haver, nesta fase, alguma implementação e testes, caso seja necessário 
elaborar protótipos para reduzir riscos, possibilitando assim a verificação dos 
casos de uso que requerem um maior cuidado. 
b) Elaboração (elaboration)
As interações que ocorrem nesta fase têm como objetivo detalhar a análise 
e expandir os casos de uso, para obter assim sua descrição detalhada e verificar 
as situações excepcionais, ou seja, são voltadas para a produção da arquitetura 
básica, e vários casos de uso são demonstrados com detalhes, possuindo uma 
arquitetura projetada a qual utiliza-se de artefatos, os quais podem ser estáticos 
ou dinâmicos.
O modelo conceitual será transformado em definitivo, cada vez mais 
refinado, sobre o qual serão aplicados padrões de análise e uma descrição 
funcional poderá ser feita, bem como o design lógico e físico do sistema.
 
Ao final desta fase, é necessário que os desenvolvedores estejam aptos a 
planejar a fase seguinte a construção.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
23
c) Construção (construction)
A fase de construção possui interações nas quais os casos de uso mais 
complexos já foram tratados e a arquitetura já foi estabilizada, afinal, o produto é 
construído no decorrer desta fase.
Assim, as atividades de suas interações consistem predominantemente na 
geração de código e teste do sistema. 
Com a automação da geração de código e a introdução de modelos de 
desenvolvimento dirigidos a teste, pressupõe-se que um bom design possa dar 
origem rapidamente a um código de alta qualidade, ou seja, o sistema será 
composto por todos os casos de uso que a gerência e os usuários concordaram em 
desenvolver para esta versão do produto.
 
 Vale lembrar que mesmo que ocorram erros, estes podem ser corrigidos, 
estando aptos assim para seguir no processo e iniciar a próxima fase.
d) Transição (deployment)
Esta fase consiste na implementação do sistema no ambiente de produção, 
com a realização de teste e operação, onde a primeira versão do sistema é entregue 
ao usuário.
Também, neste momento, é feita a transferência de dados de possíveis 
sistemas antigos para o novo sistema e o treinamento dos usuários, caso ocorram 
divergências no sistema, os usuários reportam-nas para os desenvolvedores, 
incorporando as melhorias.
Nesta fase ainda pode haver alguma revisão de requisitos e geração de 
código, mas não de forma significativa.
Após todas as definições, conforme mencionado no início deste tópico, 
observe a figura que demonstra as fases, bem como os fluxos de trabalhos no 
decorrer do processo de construção de um UP.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
24
FIGURA 11 – FASES DO UP – FLUXOS DE TRABALHO
FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-o-
processo-unificado-integrado-ao-desenvolvimento-web/803>. Acesso em: 23 dez. 2014.
FIGURA 12 – EXEMPLO DE UM PROCESSO UNIFICADO
FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014.
Concepção Elaboração Construção Transição
Inicial Elab.nº 1
Elab.
nº 2
Const.
nº 1
Const.
nº 2
Const.
nº N
Trans.
nº 1
Trans.
nº 2
Teste
Fluxo de trabalho
Interações
Ambiente
Gerenciamento de Projeto
Geren. de
Configuração e Mudança
Implantação
Implementação
Requisitos
Análise e Design
Modelagem de Negócios
Fases
Use-Case
Model
Analysis
Model
Design
Model Deployment
Model
Implementation
Model
Test
Model
Specified by
realized by
distributed by
implemented by
verified by
X
OK
X
OK
X
OK
TÓPICO 2 | PROCESSO UNIFICADO (UP)
25
Observe como se apresenta o ciclo de desenvolvimento de um UP.
FIGURA 13 – CICLO DE DESENVOLVIMENTO UP
FONTE: Disponível em: <http://open2up.blogspot.com.br/>. Acesso em: 23 dez. 2014.
Agora, acadêmico(a), que você conhece a definição de UP, bem como 
suas fases, chegou o momento de conhecer as derivações desta ferramenta de 
programação, as quais se apresentam a seguir, iniciando-se por: RUP (Rational 
Unified Process), AUP (Agile Unified Process), OpenUp (Open Unified Process), EUP 
(Enterprise Unified Process), e finalizando com RUP-SE (Rational Unified Process – 
Systems Engineering).
2.2 RUP – RATIONAL UNIFIED PROCESS
Micro Incremento
Ciclo de 
Vida deIteração
Ciclo de 
Vida de 
Projeto
Dias
Semanas
Meses
Item de Trabalho
Plano de Interação
Plano de Projeto
Foco no
Indivíduo
Foco na
Equipe
Foco nos
Envolvidos
Iniciação Elaboração Construção Trânsição
Valor
Ríscos
Executável 
Estável
Incremento
Interação
“Este processo de engenharia de software fornece uma abordagem 
para assumir tarefas e responsabilidades dentro de uma organização de 
desenvolvimento, cujo objetivo é assegurar a produção de software de alta 
qualidade dentro de prazos e orçamentos previsíveis”. (KRUCHTEN, 2003, p. 
14). O autor ainda afirma que “Derivado dos trabalhos sobre UML e do Processo 
Unificado de Desenvolvimento de Software, ele captura seis das melhores práticas 
no desenvolvimento de software de forma satisfatória para uma grande faixa de 
projetos e organizações”. 
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
26
Em outras palavras, o autor quer dizer que o RUP é um método que pode 
ser utilizado no desenvolvimento de software, contemplando técnicas que os 
membros da equipe de desenvolvimento devem seguir para atingir o objetivo de 
aumentar sua produtividade.
O RUP representa uma nova geração de processos genéricos, a 
mais importante inovação é a separação de fases e workflows, e sobretudo, o 
reconhecimento de que a implantação de software no ambiente do usuário é parte 
do processo. (SENE, 2015).
FIGURA 14 – QUANDO DEVO UTILIZAR O RUP
FONTE: Disponível em: <http://www.wthreex.com/rup/v711_ptbr/rup/guidances/supportingmaterials/
introduction_to_rup,_uRs44C8CEdqfj_h52-wqcw.html> e <http://www.tiespecialistas.com.br/2011/02/
rup-primeiros-passos/>. Acesso em: 23 dez. 2014.
Maior Complexibilidade Técnica
- Tempo real incorporado, distribuído, tolerância aos defeitos
- Reengenharia de arquitetura sem precedentes, personalizada
- Alto desempenho
Menos Complexibilidade Técnica
- Maioria 4 GL ou baseada em componentes
- Reengenharia de aplicativo
- Desempenho interativo
Menor 
Complexibilidade de 
Gerenciamento
- Pequena escala
- Informal
- Investidor único
Maior 
Complexibilidade de 
Gerenciamento
- Larga escala
- Contratual
- Muitos investidores
Necessidade de alto 
"nível de cerimônia"
TÓPICO 2 | PROCESSO UNIFICADO (UP)
27
2.2.1 Blocos de Construção do RUP
Identificamos o conjunto de elementos básicos (building blocks) da seguinte 
forma:
a) Quem: define o conjunto de habilidades necessário para realizar determinadas 
atividades.
b) O quê: define algo produzido por uma atividade, como diagramas, relatórios 
ou código.
c) Como: descreve uma unidade de trabalho atribuída a um papel que produz 
determinado conjunto de artefatos.
d) Quando: definem as tendências entre as diferentes atividades.
2.2.2 Papéis no RUP
O papel define um conjunto de comportamentos, habilidades e 
responsabilidades de uma pessoa da equipe. Os papéis dentro de um projeto não 
são necessariamente para pessoas específicas nem para cargos dentro da equipe. 
A mesma pessoa pode exercer vários papéis em diferentes momentos do dia, no 
mesmo projeto.
Vejamos a seguir as categorias em que são organizados os papéis:
2.2.2.1 Papel do Analista
O analista é o responsável por realizar o relacionamento ou contato com 
usuário ou cliente do sistema. As pessoas que exercem este papel devem ser 
capazes de entender quais são as necessidades do sistema, e criar descrições que 
sejam compreendidas pelos designers, desenvolvedores e testadores. 
Além de terem a responsabilidade de atentarem para as adequações de 
reais necessidades, bem como verificar a conformidade com normas e padrões 
estabelecidos.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
28
FIGURA 15 – PAPEL DO ANALISTA
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_implm.
htm>. Acesso em: 23 dez. 2014.
2.2.2.2 Papel do Desenvolvedor
Os desenvolvedores transformam os requisitos em produto de software 
e devem ter o conhecimento necessário para desenvolver os códigos-fonte e 
testá-los.
FIGURA 16 – PAPEL DO DESENVOLVEDOR
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_implm.
htm>. Acesso em: 23 dez. 2014.
Implementar
Componente
Componente
Realizar
Teste Unitário
Corrigir
um Defeito
Desenvolver
Artefatos de
Instalação
Artefatos
de Instalação
Implementar
Componentes de
Teste e de Subsistemas
Componente
de Teste
Subsistema de 
Implementação
Implementador
TÓPICO 2 | PROCESSO UNIFICADO (UP)
29
2.2.2.3 Papel de Testador
É responsável por definir técnicas, estratégias, e principalmente definir os 
casos de testes que serão aplicados no sistema, ou seja, tem a função de analisar 
os resultados dos testes e no caso de necessidade, informar aos responsáveis que 
providenciem a correção.
FIGURA 17 – PAPEL DO TESTADOR
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_tstr.
htm>. Acesso em: 23 dez. 2014.
2.2.2.4 Papel de Gerente
O papel de gerente está relacionado principalmente com as atividades de 
planejamento, controle e sobre tudo a organização do projeto.
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
30
FIGURA 18 – PAPEL DE GERENTE
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_projm.
htm>. Acesso em: 23 dez. 2014.
2.2.2.5 Outros Papéis
Neste item é possível encontrar outros papéis que não foram classificados 
nos tipos anteriores como: interessados, desenvolvedor de curso, redator técnico 
e administrador de sistemas.
Como o RUP é uma ferramenta adaptável, novos papéis podem ser 
necessários e adicionados a um projeto ou processo específico.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
31
FIGURA 19 – DESENVOLVEDOR DE CURSO
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/
workers/wk_crsdv.htm>. Acesso em: 23 dez. 2014.
FIGURA 20 – ADMINISTRADOR DE SISTEMA
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/
workers/wk_sysad.htm>. Acesso em: 23 dez. 2014.
Desenvolvedor
do Curso
Materiais de 
Treinamento
Desenvolver 
Materiais de 
Treinamento
responsável por
Administrador
do Sistema
Suportar o 
Desenvolvimento
Infraestrutura de 
Desenvolvimento
responsável por
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
32
FIGURA 21 – REVISOR DE PROJETO
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workflow/ovu_mgm.
htm>. Acesso em: 23 dez. 2014.
2.2.3 AUP – Agile Unified Process
O Agile Unified Process é uma versão simplificada do RUP, que aplica 
técnicas ágeis de desenvolvimento dirigido por testes (TDD), modelagem ágil e 
fatoração. 
A AUP teve sua origem no início do século XXI, por meio de um grupo 
de engenheiros, consultores, autores, os quais, após muito estudo, denominaram 
esta pesquisa de The Agile Manifesto, tendo então como objetivo a apresentação 
e discussão de novas técnicas que poderiam ser utilizadas para desenvolver 
softwares, disponibilizando maior agilidade por meio dos conceitos aplicados às 
metodologias já existentes.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
33
Após a criação deste manifesto, percebeu-se que a AUP seria um método 
ágil e que poderia atender às seguintes prerrogativas:
a) Valorizar os indivíduos envolvidos no processo e as interações entre ambos.
b) Produzir softwares funcionais, não somente documentações completas e 
atualizadas.
c) Colaborar com os clientes e não apenas discutir picuinhas contratuais.
d) Estar preparado para a adaptação e introdução de mudanças.
Em sentido complementar, vale destacar os princípios que denominam a 
AUP:
a) Assumir simplicidade.
b) Flexibilidade para mudanças.
c) O software é o primeiro objetivo.
d) Viabilizar esforços futuros.
e) Alterações incrementais.
f) Maximizar o investimento dos interessados no software.
g) Modelar com propósito.
h) Múltiplos modelos.
i) Trabalho com qualidade. 
FIGURA 22 – FASES DO AUP
FONTE: Disponível em: <http://www.cs.sjsu.edu/~pearce/modules/lectures/se/aup.
htm>. Acesso em: 23 dez. 2014.
Testing
Implementation
Modeling
Deployment
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS34
FIGURA 23 – Fases do AUP
FONTE: Disponível em: <http://pt.slideshare.net/redecharles21/aup-seminario-final>. Acesso em: 
23 dez. 2014.
Ao contrário do RUP, conforme demonstra a figura acima, a AUP possui 
apenas sete disciplinas (Modelagem, Implementação, Teste, Implantação, 
Gerenciamento de configuração, Gerenciamento de projeto, Ambiente).
A filosofia de produção de artefatos é minimalista, ou seja, deve gerar o 
mínimo necessário de artefatos para produzir um sistema com qualidade.
2.2.4 Open UP – Open Unified Process
A OpenUP é uma implementação aberta da UP desenvolvida como parte 
do Eclipse Processes Framework, conhecida anteriormente como Basic Unified 
Process (BUP). OpenUP aceita, grande parte dos princípios utilizados no Processo 
Unificado, porém é um método independente de ferramenta, não exigindo grande 
precisão e detalhes nos documentos.
O processo baseia-se em quatro princípios (Colaboração, Evolução, 
Balanceamento e Foco).
O ciclo de vida também é dividido em quatro fases como no UP. Estas 
fases são divididas em interações, porém aqui as equipes se auto-organizam para 
planejar cada uma delas.
Test
Project Management
Configuration Management
Implementation
Deployment
Environment
Model
Inception
I1 E1 C1 T1 T2C2 Cn
Elaboration TransitionConstruction
Phases
Iterations
TÓPICO 2 | PROCESSO UNIFICADO (UP)
35
FIGURA 24 – CICLO DE VIDA OpenUP
FONTE: Disponível em: <http://open2up.blogspot.com.br/>. Acesso em: 23 dez. 2014.
Em relação ao UP, a maioria dos processos opcionais foi eliminada e 
outros foram mesclados. O resultado é um processo mais simples, mais ainda fiel 
aos princípios do RUP.
FIGURA 25 – MODELO DE CICLO DE VIDA DE UMA INTERAÇÃO OpenUp
FONTE: Disponível em: <http://pt.slideshare.net/jeanstreleski/open-up-gerenciando-projetos-
sob-principios-geis>. Acesso em: 23 dez. 2014.
2.2.5 EUP – Enterprise Unified Process
O modelo EUP visualiza ao desenvolvimento de software não apenas 
como um projeto a ser desenvolvido, mais como algo intrínseco ao ciclo de vida 
da empresa. Este modelo foi proposto como uma extensão ao modelo RUP para 
prover, além das fases do RUP, duas novas fases para tratar a evolução ou suporte 
ao sistema e à aposentadoria do sistema.
Iteration planning Stable weekly build Stable iteration 
build
Iteration review / 
Retrospective
Upfront planning
and architecture
Continuous
micro-increments / 
bug-fixing / builds
Continuous
bug-fixing / 
micro-increments / 
builds
A few 
hours
A few 
hours
A few 
days
- Escopo do sistema
- Requisitos do sistema
- Custo geral do sistema
- Riscos em potencial
- Baseline da Arquitetura
- Riscos em potencial
- Componentes do sistema
- Reusabilidade
- Qualidade do sistema
- Versões Alfa e Beta
- Release do sistema
- Teste Beta
- Conversão do BD
- Treinamentos
- Distribuição
- Documento de visão
- Lista de riscos
- Plano de interação
- Glossário
- Modelo de Caso de Uso
- Protótipos
- Protótipo
- Modelo de Design
- Modelo de Dados
- Modelo de Implantação
- Release do sistema
- Casos de Testes
- Material de Suporte
- Release
- Material de Suporte
- Casos de Testes
- Pacote de Distribuição
Objetivos do
Ciclo de Vida
FASES MARCOS OBJETIVOS ARTEFATOS
ElaboraçãoIniciação
Arquitetura do
Ciclo de Vida
Construção
Recurso Opera-
cional Inicial
Transição
Liberação do
Produto
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
36
FIGURA 26 – FASES EUP
FONTE: Disponível em: <http://www.enterpriseunifiedprocess.com/>. Acesso em: 23 dez. 2014.
O objetivo principal da disciplina de operação e suporte é manter o 
produto funcionando em produção. Afinal, estes devem garantir o correto 
funcionamento do software, a evolução dos processos, a realização dos backups, 
planos de recuperação de desastre devem ser criados e executados se necessário.
A fase de aposentadoria consiste na retirada de um sistema de operação 
onde sistemas antigos são substituídos por sistemas novos ou retirados de 
operação.
2.2.6 RUP-SE – Rational Unified Process 
– Systems Engineering 
O RUP-SE é uma extensão do modelo RUP, especialmente adequada para 
o desenvolvimento de sistemas de grande porte, envolvendo software, hardware, 
pessoas e componentes de informação.
TÓPICO 2 | PROCESSO UNIFICADO (UP)
37
FIGURA 27 – CICLO DE VIDA RUP-SE
FONTE: Disponível em: <http://www.devarticles.com/c/a/Development-Cycles/Organizing-RUP-
SE-Projects/1/>. Acesso em: 26 dez. 2014.
O Framework permite, neste caso, considerar o sistema a partir de 
diferentes perspectivas (lógica, física ou informacional). Isto pode ser bastante útil 
quando se deseja demonstrar ou discutir aspectos de um sistema com diferentes 
interessados.
Maiores informações acerca do processo unificado, bem como selecionar 
versões do processo unificado é possível por meio dos seguintes sites:
<www.rational.com/rup>. 
<http://.flylib.com/books>. 
<http://savannah.nongnu.org/>. 
<http://www.git-scm.com/>. 
<http://mercurial.selenic.com/>. 
IMPORTANT
E
38
RESUMO DO TÓPICO 2
Neste tópico, vimos:
• O Processo Unificado (UP), bem como conhecer suas principais definições, 
sua caracterização, suas fases, bem como suas derivações (RUP – Rational 
Unified Process; AUP – Agile Unified Process; OpenUp – Open Unifies Process; 
EUP – Enterprise Unified Process; RUP-SE – Rational Unified Process – Systems 
Engineering).
• A importância de cada uma das derivações apresentadas, e como podemos 
utilizá-las nos diferentes tipos de projetos. Afinal cada uma possui suas 
especificidades e suas características próprias. Neste sentido, para auxiliar 
na compreensão, foram apresentadas por meio das figuras as fases de cada 
processo.
Neste Momento, você está apto a realizar as autoatividades deste tópico, 
e, na sequência, iniciar o estudo do Tópico 3 desta unidade.
Bom estudo!
39
AUTOATIVIDADE
1 Descreva como se caracteriza processo unificado.
2 Explique as fases do processo unificado.
3 Entre os diversos papéis assumidos no RUP, quais são os que definem um 
conjunto de comportamentos e responsabilidades para determinada pessoa? 
Com base nesta afirmação, analise a figura a seguir:
Agora, assinale a alternativa CORRETA:
a) ( ) Outros papéis.
b) ( ) Papel do testador.
c) ( ) Papel do gerente.
d) ( ) Papel do desenvolvedor.
4 A figura a seguir se refere a qual das derivações apresentadas no Processo 
Unificado?
40
a) Open-Up – Open Unified Process.
b) AUP – Agile Unified Process.
c) RUP – Rational Unifies Process.
d) EUP – Enterprise Unified Process.
5 As interações que ocorrem nesta fase têm como objetivo detalhar a análise e 
expandir os casos de uso, para obter assim sua descrição detalhada e verificar 
as situações excepcionais, ou seja, são voltadas para a produção da arquitetura 
básica, e vários casos de uso são demonstrados com detalhes, possuindo uma 
arquitetura projetada que se utiliza de artefatos, que podem ser estáticos ou 
dinâmicos. A qual das fases esta afirmação se refere?
a) Construção.
b) Concepção.
c) Transição.
d) Elaboração.
Test
Project Management
Configuration Management
Implementation
Deployment
Environment
Model
Inception
I1 E1 C1 T1 T2C2 Cn
Elaboration TransitionConstruction
Phases
Iterations
41
TÓPICO 3
ESTRUTURAS E 
RELACIONAMENTOS
UNIDADE 1
1 INTRODUÇÃO
Conforme foi abordado nos tópicos anteriores, você entrou em contato 
com as definições acerca dos objetos, seus diferentes tipos e uma prévia sobre a 
Análise e Programação Orientada a Objetos.
Teve contato também com os princípios básicos da Orientação a Objetos, 
bem como seus principais conceitos. Agora, neste tópico, iremos abordar sobre as 
estruturas de relacionamento dos objetos, ou seja, de que forma estas estruturas 
auxiliam os analistas e desenvolvedores na composição e apresentação dos objetos 
dentro do contexto de software, possibilitando assim uma melhor visualização 
do problema a ser estudado.
Ainda neste contexto, vale frisar que o relacionamento entre os objetos 
ocorre quando um objeto se referencia ao outro, ouquando um método de um 
objeto é ativado por outro objeto.
2 TIPOS DE ESTRUTURAS E RELACIONAMENTOS
Segundo Correia e Tafner (2001, p. 39), “Na Programação Orientada a 
Objetos, as estruturas possibilitam os analistas ou programadores arranjar os 
objetos de forma que possa visualizar melhor o domínio e a complexidade do 
problema em estudo”. Existem dois tipos básicos de estrutura: Generalização-
Especialização e Todo-Parte, que serão estudadas na sequência.
E com relação aos relacionamentos, os autores descrevem que os 
relacionamentos ocorrem quando os objetos se referenciam uns aos outros 
(conexão de ocorrência), ou quando um objeto ativa um método de outro objeto 
(conexão de mensagem).
42
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
42
2.1 ESTRUTURA GENERALIZAÇÃO 
– ESPECIALIZAÇÃO (GE)
A Generalização é conhecida pelo conceito de associar indivíduos com 
atributos em comum, e ao mesmo tempo despreza as diferenças.
Quando adaptamos pela generalização, não estamos distorcendo seu 
conceito, estamos ampliando-o não apenas para o grupo de indivíduos, mas 
também vamos generalizar alguns atributos para que a aderência do conceito seja 
maior (ANGELANTONIO, 2014).
FIGURA 28 – EXEMPLO DE GENERALIZAÇÃO – ESPECIALIZAÇÃO
FONTE: Disponível em: <https://alexevalerio.wordpress.com/2014/04/07/modelagem-de-
banco-de-dados-generalizacaoespecializacao/>. Acesso em: 26 dez. 2014.
A Especialização é muito semelhante à herança, a qual já estudamos 
anteriormente. Assim, caso tenha interesse em realizar uma herança, deve utilizar 
a estrutura Generalização-Especialização.
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
43
2.2 ESTRUTURA TODO – PARTE (TP)
Este tipo de estrutura é bastante característico, uma vez que trata 
de agregação ou decomposição de objetos. “Essa estratégia é muito útil na 
identificação dos objetos e dos seus componentes diante de um determinado 
problema em estudo”. (CORREIA E TAFNER, 2001, p. 41).
FIGURA 29 – ESTRUTURA TODO-PARTE
FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. 
Acesso em: 26 dez. 2014.
Além desta definição, é importante destacar que a estrutura Todo-Parte é 
composta por uma característica conhecida por cardinalidade, que é importante 
para determinar o número de ocorrências em um relacionamento.
FIGURA 30 – CARDINALIDADE NA PRÁTICA
FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. Acesso em: 26 dez. 2014.
Todo
Parte 1 Parte 2
Automóvel Automóvel
0..1
4..5
Roda Roda Roda Roda Roda
44
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
44
No exemplo apresentado na figura 30, um carro, como todos sabem, é 
composto por quatro rodas (cinco, considerando o estepe), sendo todas iguais. 
Desta forma denominamos roda um objeto e se repete quatro vezes dentro do 
objeto carro. Em outras palavras, conforme a definição, roda ocorre quatro vezes 
neste relacionamento entre carro e roda.
2.3 CONEXÕES
Na Programação Orientada a Objetos, existem dois tipos de conexão 
entre os objetos, que são conhecidas por Conexões de Ocorrência e Conexões de 
Mensagens (serão estudadas posteriormente), porém é importante destacar que 
ambas não possuem nenhum tipo de hierarquia ou estrutura.
2.3.1 Conexões de ocorrência
Uma Conexão de Ocorrência existe quando um atributo de um objeto 
contém uma referência a outro objeto. Sendo assim, “a necessidade de criar uma 
conexão de ocorrência com frequência surge da identificação de atributos em um 
objeto que é redundante e que sob uma análise mais atenta, percebe-se fazerem 
parte de outro objeto”. (CORREIA e TAFNER, 2001, p. 43).
FIGURA 31 – CONEXÃO DE OCORRÊNCIA
FONTE: Correia e Tafner (2001, p. 44)
No diagrama representado pela Figura 31 existe uma conexão de 
ocorrência entre carro e pessoa, neste objeto carro contém um atributo chamado 
proprietário, que contém uma ocorrência para um objeto da classe pessoa.
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
45
2.3.2 Cardialidade
Conforme já foi visto anteriormente, Cardinalidade determina o número 
de vezes que um objeto é referenciado ou se referencia ao outro. Quando se refere 
à estrutura todo-parte, a cardinalidade é demonstrada por meio de pares de 
números adjacentes à linha que representa a relação entre os objetos.
FIGURA 32 – CARDINALIDADE ENTRE ALUNO, MATRÍCULA E MATÉRIA
FONTE: Disponível em: <http://e-reality-database.blogspot.com.br/2007/09/cardinalidade.html>. 
Acesso em: 26 dez. 2014.
Observando a Figura 32, contata-se que na cardinalidade existe o aluno que 
pode se matricular em no mínimo uma disciplina e no máximo três disciplinas, e 
neste contexto, cada matéria relaciona-se com as matrículas, e que podem ser de 
no mínimo 0 e no máximo n alunos matriculados.
2.3.3 Conexão de mensagem
Com relação à conexão de mensagem, pode-se dizer que uma mensagem 
é uma ação que envia um método específico no objeto receptor, fazendo com que 
este efetue um comportamento determinado. Este método, por sua vez, retorna 
ou não uma resposta para o objeto transmissor. Para simplificar, a conexão de 
mensagem ocorre sempre que um objeto envia uma mensagem a outro objeto, 
neste contexto apresenta-se o método transmissor e o receptor.
46
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
46
FIGURA 33 – CONEXÃO DE MENSAGEM
FONTE: Disponível em: <http://slideplayer.com.br/slide/365068/>. Acesso em: 
26 dez. 2014.
Para ajudar em sua compreensão, segue mais um exemplo de conexão de 
mensagem.
FIGURA 34 – OUTRO EXEMPLO DE CONEXÃO DE MENSAGEM
FONTE: Disponível em: <http://slideplayer.com.br/slide/365068/>. Acesso em: 26 dez. 2014.
Analisando as figuras que se referem à conexão de mensagem, pode-se 
perceber que na Figura 33 ocorre a transmissão de uma mensagem entre duas 
pessoas, ou seja, uma realiza uma pergunta e a outra consequentemente a 
responde.
Já na figura 34, estamos falando de um sistema que se refere à locação 
de filmes, neste a locação envia uma mensagem para verificar se o cliente está 
cadastrado para realizar a locação do filme, caso não esteja cadastrado retorna a 
mensagem solicitando o cadastro do cliente.
Cadastro_Cliente
Criar_Cliente
Consultar_Cliente Criar_C
liente
Cliente
Locação
A_Fita
A _Cliente
Locar_Fita_Cliente
Cliente
Locar_Fita
Liberar_Fita
Consultar_Disp
Cadastro_Fita
Consultar_Fita
1,1 1,1
1,1 1,1
0,n
0,n
0,n 0,n
C
onsultar_C
liente
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
47
2.3.4 Polimorfismo
Segundo a definição de Lima (2005), polimorfismo é o princípio em que 
classes derivadas de uma mesma superclasse podem invocar operações que 
têm a mesma assinatura, mas comportamentos diferentes em cada subclasse, 
produzindo resultados diferentes, dependendo de como cada objeto implementa 
a operação. Continuando, o autor destaca que é a capacidade de objetos diferentes 
possuírem operações com o mesmo nome e a mesma lista de argumentos, mas 
que executam tarefas de formas diferentes.
FIGURA 35 – POLIMORFISMO
FONTE: Disponível em: <http://www.tomasvasquez.com.br/cursocsharp/programacao_orientada_
objetos/polimorfismo>. Acesso em: 26 dez. 2014.
Por meio da figura apresentada sobre polimorfismo, foi possível perceber 
certa semelhança com a Herança que já foi estudada anteriormente, ou seja, a 
subclasse bicicleta e a subclasse carro, ambos herdaram da superclasse veículo os 
métodos movimentar e parar, assim cada objeto responde à mesma mensagem, 
porém cada um a sua maneira. Ou seja, a bicicleta movimenta-se em duas rodas, 
enquanto o carro necessita de quatro rodas para se movimentar, mas ambos 
pertencem à mesma superclasse veículo.
Processos de Herança
Membros de Herdados
Classe Veículo
• ...
• Movimentar
• Parar
• ...
Classe Bicicleta
• ...
• Movimentar
• Parar
• ...
Classe Carro
• ...
• Movimentar
• Parar
• ...
48
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
Herança
A herança é um mecanismo que permite a uma dada classe (classe 
derivada-subclasse) aceder a dados e métodos de uma outra classe (classe base-
superclasse). A utilização de herança aplica-se de uma formanatural a todos os 
procedimentos definidos de uma forma hierárquica, onde as classes derivadas 
herdam as propriedades da(s) classe(s) base(s).
O processo da criação de uma classe derivada, permite:
• Especialização: criação de uma classe específica de uma dada classe, como por 
exemplo a definição de uma classe para vectores de números inteiros com base 
na classe genérica vector.
• Generalização: criação de uma classe que prolonga o comportamento da classe 
base (oposto a especialização).
• Extensão: a classe derivada introduz novas funcionalidades à classe base, mas 
não altera as existentes.
• Limitação: a classe derivada restringe as funcionalidades de uma classe base, 
como, por exemplo, restringir as funcionalidades da classe vector por forma a 
implementar só as funcionalidades pretendidas.
• Combinação: utilização de herança múltipla por forma a criar novas classes de 
alto nível.
Visibilidade externa de uma classe:
class TESTE
{public: // Pode ser acedido por qualquer função
int f();
int x;
protected: // Pode ser acedido por qualquer função membro,
// função amiga ou classes derivadas;
int g();
int y;
private: // Só pode ser acedido pelas funções membro da
// própria classe ou por funções membro amigas
int h();
int z;
};
LEITURA COMPLEMENTAR
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
49
A parte protected: da classe permite:
• Definição de variáveis e métodos por forma a melhorar o acesso à classe base, 
por parte da classe derivada.
• Obter uma maior eficiência no acesso à classe base.
1.1. Herança Simples
class BASE
{public:
int x;
protected:
int y;
int h(int a);
private:
int z;
};
class NATO: public BASE
{public:
int f() { return(x + BASE::x + y);
int g() { return( h() ); }
private:
int x;
};
ou
class NATO: private BASE
{public:
int f() { return(x + BASE::x + y);
int g() { return( h() ); }
private:
int x;
};
class NATO: public BASE
Todos os membros public e protected da classe BASE são membros
public e protected da classe NATO
Todos os membros private da classe BASE não podem ser acedidos pela classe 
NATO.
class NATO: private BASE
Todos os membros public e protected da classe BASE são membros
private da classe NATO
Todos os membros private da classe BASE não podem ser acedidos pela classe 
NATO.
50
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
1.2. Herança Múltipla
class BASE1
{
public:
int x;
};
class BASE2
{
public:
int y;
};
class BASE3
{
public:
int z;
};
class NATO: public BASE1, public BASE2, public BASE3
{
public:
void f() { return(BASE1::x+BASE2::y+BASE3::z);
};
A Ordem de Derivação é Importante?
É importante para a inicialização (por omissão) das variáveis das classes 
bases e derivadas (ver inicialização de construtores).
Pode-se especificar várias vezes uma classe base numa classe derivada?
Não. Não se pode especificar mais de uma vez como classe básica de uma 
classe derivada, uma vez que uma referência à classe base seria ambígua.
class NATO: public BASE1, public BASE1 // erro
{
public:
void f() { return(BASE1::x+BASE2::y+BASE3::z);
};
Considere o seguinte conjunto de classes bases e derivadas, utilizando herança 
simples e múltipla.
class L
{
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
51
public:
int x;
};
class A: public L
{
public:
int y;
};
class B: public L
{
public:
int z;
};
class C: public A, public B
{
public:
int f() { return(A::y + A::L::x + B::z + B::L::x + y + z); }
};
Em problemas onde existam diversas herança, por vezes torna-se mais 
fácil visualizar a interligação destas classes, através da utilização de um esquema 
representativo da interligação (herança) entre as classes.
Visualização da herança para melhor compreender heranças complicadas
Como aceder à variável “x“ da classe “L“ pertencente à classe “A“?
int main()
{
C derivada;
derivada::A::x = 1; // aceder à variável “x“ da classe “L“ da classe “A“
derivada::B::x = 2; // aceder à variável “x“ da classe “L“ da classe “B“
}
FONTE: Disponível em: <http://www.estig.ipbeja.pt/~rmcp/estig/20062007/1s/lp/cplusplus/
heranca.pdf>. Acesso em: 26 dez. 2014.
52
UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS
Cardinalidade
Entenda quais são os tipos de relacionamentos e cardinalidade que usamos 
na análise de relacionamento no processo de modelagem de dados, o Modelo de 
Entidade e Relacionamento.
Relacionamento entre entidades é o tipo de ocorrência existente entre 
entidades e aplicáveis no processo de modelar dados. Entender isso é importante 
pois um modelo consistente é a base para um banco de dados de sucesso. O símbolo 
que representa o relacionamento no Modelo de Entidade e Relacionamento 
(MER) é um losango com o nome do relacionamento escrito no seu interior, como 
no exemplo a seguir.
Em um modelo de entidade e relacionamento, nem todas as entidades 
serão relacionadas, há casos em que não há ligação entre elas, nestes casos 
consideramos como entidades isoladas. Embora não seja tão comum, é importante 
levar em conta esta possibilidade. Mas quando as ligações existirem, elas serão 
classificadas de acordo com os tipos a seguir.
Tipos de relacionamento
Existem três tipos de relacionamento entre entidades:
• um-para-um
• um-para-muitos
• muitos-para-muitos
Relacionamento um-para-um
O relacionamento um-para-um é usado quando uma entidade A se 
relaciona com uma entidade B e vice-versa.
Este relacionamento é representado pelo sinal: 1:1
Veja o exemplo:
Pertence
Chefia1 1Gerente Seleção
TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS
53
Relacionamento um-para-muitos
O relacionamento um-para-muitos é usado quando uma entidade A pode 
se relacionar com uma ou mais entidades B.
Este relacionamento é representado pelo sinal: 1:N
Veja o exemplo:
Relacionamento muitos-para-muitos
O relacionamento muitos-para-muitos é usado quando várias entidades 
A se relacionam com várias entidades B.
Este relacionamento é representado pelo sinal: N:N ou N:M
Veja o exemplo:
Cardinalidade
A cardinalidade é um conceito importante para ajudar a definir o 
relacionamento, ela define o número de ocorrências em um relacionamento. Para 
determinar a cardinalidade, deve-se fazer a pergunta relativa ao relacionamento 
em ambas as direções.
Um departamento possui quantos empregados?
- no mínimo 1 e no máximo N.
Um empregado está alocado em quantos departamentos?
- no mínimo em 1 e no máximo em 1
Somando-se as cardinalidades, definimos o resultado final do 
relacionamento, ou seja, 1:N
 FONTE: Disponível em: <http://www.luis.blog.br/relacionamento-entre-entidades-tipos-e-
cardinalidade.aspx> Acesso em: 26 dez. 2014.
ForneceN NFornecedor Produto
Trabalha1 NSeção Funcionário
54
RESUMO DO TÓPICO 3
Neste tópico, vimos:
• As estruturas de relacionamento dos objetos, e como estas estruturas auxiliam 
os analistas e desenvolvedores na composição e apresentação dos objetos 
dentro do contexto de software, possibilitando, assim, uma melhor visualização 
do problema a ser estudado, facilitando a compreensão deste por parte de 
usuários de negócio e desenvolvedores. 
• O relacionamento entre os objetos ocorre quando um objeto se referencia ao 
outro, ou quando um método de um objeto é ativado por outro objeto.
Assim, ao término deste tópico concluímos a Unidade 1. Com isso, você, 
acadêmico(a), está apto(a) a aplicar os conhecimentos de Orientação a Objetos em 
suas atividades diárias.
Bom estudo!
55
AUTOATIVIDADE
1 Descreva os dois tipos básicos de estruturas que auxiliam os analistas na 
Análise e Orientação a Objetos: 
2 É conhecida pelo conceito de associar indivíduos com atributos em comum, 
e ao mesmo tempo despreza as diferenças. Assinale a alternativa CORRETA 
para esta definição:
a) ( ) Encapsulamento.
b) ( ) Generalização-Especialização.
c) ( ) Classe Abstrata.
d) ( ) Todo-Parte.
3 Observe a figura a seguir e identifique a quem ela pertence:
FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. Acesso em: 26 dez. 2014. 
4 Cardinalidade determina o número de vezes que um objeto é referenciado 
ou referencia ao outro, assim, com base nestadefinição, desenvolva uma 
figura que apresenta estas características:
56
57
UNIDADE 2
UNIFIED MODELING 
LANGUAGE (UML)
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
A partir desta unidade você será capaz de:
• conhecer sobre a introdução à UML, por meio de seu histórico;
• compreender a utilização do Levantamento de Requisitos, Prototipação, 
Prazos e Custos, entre outros;
• conhecer a respeito das fases do desenvolvimento de um sistema UML;
• compreender os modelos de elementos por meio das Classes, Objetos, Es-
tados, entre outros.
Esta unidade de ensino está dividida em três tópicos, sendo que no final de 
cada um deles, você encontrará atividades que contribuirão para a apropria-
ção dos conteúdos.
TÓPICO 1 – INTRODUÇÃO A UML
TÓPICO 2 – FASES DE DESENVOLVIMENTO DE UM SISTEMA UML
 
TÓPICO 3 – MODELOS DE ELEMENTOS
58
59
TÓPICO 1
INTRODUÇÃO A UML
UNIDADE 2
1 INTRODUÇÃO
Neste primeiro tópico, você terá acesso às especificidades do 
desenvolvimento de software, respondendo assim a uma pergunta básica: Por que 
modelar software?
Para responder a esta pergunta, no decorrer do tópico, será apresentado 
a você acadêmico: Como realizar uma análise e levantamento de requisitos; por 
que e para que serve um protótipo; como respeitar prazos e custos de um projeto; 
quais são os tipos de manutenção e quando incorremos em algum destes tipos; 
para finalizar o levantamento necessário de toda documentação mantendo assim 
um histórico detalhado do software.
É importante destacar o item Evolução, que contém os fatores que levam 
um sistema a se adaptar às necessidades da organização.
2 BREVE HISTÓRICO DA UML
 A Unified Modeling Language (UML), ou Linguagem de Modelagem 
Unificada, surgiu da união de três metodologias de modelagem: o método 
Booch, o método Object Modeling Technique (OMT) e o método Object Oriented 
Software Engineering (OOSE). Agora acadêmico, vamos entender um pouco 
desses métodos e como a união deles aconteceu:
• O método Booch foi definido por Booch, que trouxe a definição de que um 
sistema é analisado a partir de um número de visões, na qual cada visão é 
descrita por um número de diagramas e de modelos. Contudo, nesse método a 
simbologia era complexa de ser desenhada a mão, contendo também o processo 
pelo qual sistemas são analisados por micro e macro visões.
• OMT é uma técnica de Modelagem de Objetos ou Object Modelling Technique. 
Esse método foi desenvolvido General Electric (GE), empresa na qual James 
Rumbaugh trabalhava. O método OMT é basicamente voltado para testes de 
modelos e fundamentado nas especificações da análise de requisitos do sistema. 
O sistema que se baseia neste método é composto pela união dos modelos de 
objetos, funcional e use-cases.
• OOSE/Objectory – Esses dois métodos (OOSE e o Objectory) foram desenvolvidos 
com base da mesma visão de Ivar Jacobson. Jacobson traz no OOSE a visão do 
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
60
FIGURA 36 – EVOLUÇÃO NA NOTAÇÃO UML
FONTE: Disponível em: <http://marcosmoraisdesousa.blogspot.com.br/2012_04_01_archive.
html>. Acesso em: 15 fev. 2015. 
Na figura apresentada acima, você pode observar a evolução existente na 
Notação UML e como ocorreu cada um dos processos em suas respectivas datas.
método orientado a objetos, enquanto no Objectory é utilizado para construir 
sistemas nas suas mais variadas formas. Os dois métodos são fundamentos no 
uso de use-cases, ou seja, utiliza definições de requisitos iniciais e vistos por 
um ator externo. Cabe destacar ainda, que a engenharia de negócio utiliza o 
método Objectory, de forma adaptada, para modelagem e no melhoramentos 
dos processos referentes aofuncionamento de organizações.
Em 1997, a UML passa a ser adotado pela Object Management Group 
(OMG) ou Grupo de Gerenciamento de Objetos – www.omg.com - como 
linguagem padrão de modelagem. Em outubro do ano de 1994, Rumbaugh se 
juntou a Booch na Rational, objetivando unir os métodos Booch e OMT, após 
um ano de trabalho, foi lançado, em outubro do ano de 1995, se teve o esboço da 
versão 0.8 do Unified Process (UP) ou Processo Unificado. Neste mesmo período, 
Jacobson se associou à Rational, expandindo o escopo do projeto da UML para 
incorporar o método OOSE. Nasce então, em junho do ano de 1996, a versão 0.9 
da UML. Assim que a UML foi lançada ela passou a ser adotada por diversas 
grandes organizações de software da época.
Foi desta forma, que "Os três amigos", termo que Grady Booch, James 
Rumbaugh e Ivar Jacobson são conhecidos, decidiram criar uma Linguagem de 
Modelagem Unificada. 
TÓPICO 1 | INTRODUÇÃO A UML
61
3 POR QUE MODELAR SOFTWARE?
Muitos analistas ou desenvolvedores de softwares garantem que conseguem 
definir todas as necessidades de um sistema de informações de cabeça e que desde 
o início de suas atividades trabalham desta forma. 
Porém, peço que você, acadêmico, visualize uma situação da construção 
civil. Neste momento, faço a você a seguinte pergunta: 
Você delegaria a construção de sua casa à equipe responsável sem um 
projeto? 
Leve em consideração que você não sabe quando (tempo), quanto ($) e 
como fica sua casa depois de pronta.
Após esta reflexão, vale destacar que, por mais simples que seja, todo 
e qualquer sistema de informação deve ser modelado antes que se inicie sua 
implementação.
FIGURA 37 – MODELAGEM DE SOFTWARE
FONTE: Disponível em: <http://techne.pini.com.br/engenharia-civil/127/artigo286443-1.aspx>. 
Acesso em: 15 fev. 2015.
Material: blocos de concreto
Altura: 19cm
Largura: 14cm
Comprimento: 39cm
Fa:6 MPa
Quantidade: 25 unidade
Alterações controladas
também podem ser feitas 
em todos os demais 
projetos. As modificações
são atualizadas em todos
os documentos integrados
à base de dados
As informações lançadas no 
projeto de arquitetura são salvas 
no banco de dados central e 
ficam acessíveis às demais 
equipes envolvidas na obra
As informações do banco de dados são
lidas por todos os softwares da obra.
São usadas, por exemplo, para gerar
planilha de orçamento
do empreendimento
Banco de dados
Orçamento
Projetos
Propriedades da alvenaria
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
62
Na figura 37, você, acadêmico(a), pode perceber quão complexa é a 
construção civil, passando por inúmeros detalhes até o final do projeto, o mesmo 
vale para a área de TI, afinal, são os responsáveis por desenvolver o sistema 
utilizado pela construção civil, facilitando suas atividades, caso não haja um 
sistema que auxilie em todo o processo de construção, a chance de erro é enorme 
e com ele vem a possibilidade de falhas em todo o desenvolvimento do projeto.
Assim, um sistema de informação precisa possuir uma boa documentação, 
que precisa ser atualizada para que o sistema possa ser mantido com facilidade, 
rapidez e de maneira correta. “Modelar um sistema é uma forma bastante eficiente 
de documentá-lo, a documentação é apenas uma das vantagens fornecidas pela 
modelagem”. (GUEDES, 2004, p. 18). 
Partindo da importância do por que modelar, outra pergunta nos vem à 
mente, afinal quais os reais objetivos da modelagem?
Como principais objetivos, segundo Pontuschka (2010), temos: 
• Ajudar a visualizar o sistema como gostaríamos que ele fosse.
• Permitir a especificação da arquitetura e comportamento de um sistema.
• Fornecer padrões de desenvolvimento que servem como guia de construção do 
sistema.
• Documentar as decisões tomadas durante o processo de desenvolvimento.
Assim, observe o exemplo para uma melhor compreensão desta descrição:
FIGURA 38 – CARDINALIDADE ENTRE ALUNO, MATRÍCULA E MATÉRIA
FONTE: Disponível em: <http://slideplayer.com.br/slide/286444/>. Acesso em: 15 fev. 2015. 
Por meio desta figura, você pode verificar que o sistema parte do item 
de menor importância, porém é o que se tem no momento, para então chegar 
ao item de maior importância, ou seja, o que realmente se deseja. Desta forma 
compreende-se que a modelagem serve como uma ponte que faz a ligação entre 
o que se tem para assim chegar ao objetivoque se deseja.
Menos importante Mais importante
Jato militarAvião de papel
TÓPICO 1 | INTRODUÇÃO A UML
63
3.1 LEVANTAMENTO E ANÁLISE DE REQUISITOS
Acadêmico(a)! Nesta etapa do processo de modelagem, o engenheiro de 
software ou analista busca compreender as necessidades do usuário e quais são 
as informações que ele necessita visualizar no sistema. São realizadas inúmeras 
entrevistas, quando o usuário detalha como funcionam suas atividades, e quais 
são os processos atualmente afins que possam ser informatizados, e por fim, os 
serviços necessários fornecidos ao usuário ou cliente.
A comunicação é sem dúvida o maior desafio da fase de levantamento 
de requisitos e da engenharia de software, sendo caracterizada pela dificuldade 
em compreender um conjunto de conceitos vagos, abstratos e confusos que 
representam as necessidades e os desejos dos usuários e clientes e transformá-los 
em conceitos concretos, ou seja, criar um sistema apto para o cliente.
Outro fator crítico na fase de levantamento de requisitos são as incertezas 
dos usuários com relação às potencialidades do sistema de informação. Em geral, 
nesta fase, os engenheiros de software e analistas acabam 
Veja na tabela a seguir, os fatores críticos na fase de levantamento de 
requisitos que os engenheiros de software enfrentam para obter informações 
necessárias, com o intuito de concluir suas atividades e apresentar algo que o 
cliente deseja.
QUADRO 1 – FATORES CRÍTICOS NO LEVANTAMENTO DE REQUISITOS
Fatores Críticos %
1. Requisitos incompletos 13,1%
2. Falta de envolvimento do usuário 12,4%
3. Falta de recursos 10,6%
4. Expectativas irreais 9,9%
5. Falta de apoio executivo 9,3%
6. Mudança de requisitos e especificações 8,7%
7. Falta de planejamento 8,1%
8. Sistema não mais necessário 7,5%
FONTE: O autor
Vale destacar que ao observar o Quadro 1, os três primeiros colocados da 
lista são informações que os usuários devem fornecer ao engenheiro de software, 
o que por vezes ocorre de forma ineficaz, e compromete o trabalho desenvolvido.
Após saber quais são os fatores críticos, analise a figura a seguir e observe 
como realmente ocorre o levantamento de requisitos.
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
64
FIGURA 39 – LEVANTAMENTO DE REQUISITOS
FONTE: Disponível em: <http://isosoftware.blogspot.com.br/2009/09/importancia-dos-
requisitos-de-software.html>. Acesso em: 15 fev. 2015. 
Em sentido complementar, depois de encerradas as entrevistas e a fase 
de levantamento de requisitos, passam para a fase de análise de requisitos. 
Neste momento, os engenheiros e analistas de sistemas especificam e verificam 
se todos os requisitos foram bem compreendidos. “A partir da análise de 
requisitos são determinadas as reais necessidades do sistema de informação” 
(GUEDES, 2004, p. 20). 
Assim, ao analisar a figura acima, é possível concluir que boa parte 
das falhas existentes neste processo poderiam ser evitadas, afinal não foram 
claras o suficiente, ou seja, o usuário não soube o que explicar ao engenheiro, 
não conseguiu transmitir qual foi sua real necessidade com relação ao sistema. 
Porém destaca-se que o trabalho de desenvolvimento foi bem executado, mas 
desenvolvido de maneira distorcida à desejada pelo usuário. 
TÓPICO 1 | INTRODUÇÃO A UML
65
3.2 PROTOTIPAÇÃO
Segundo o Dicionário Aurélio da Língua Portuguesa, Protótipo nada mais 
é que o primeiro exemplar, o primeiro modelo, o original.
Quando se tratar de tecnologia da informação, na fase de prototipação 
do projeto são desenvolvidos “modelos”, “desenhos” ou “protótipos” das telas 
que irão compor o sistema de informação, com isto é possível compreender 
melhor o propósito do software que está sendo desenvolvido, o negócio do cliente, 
propor melhorias, minimizar riscos e maximizar os tempos de desenvolvimento 
e consequentemente os lucros para o cliente.
Vamos exemplificar por meio de uma figura, facilitando assim seu 
entendimento.
FIGURA 40 – PROTOTIPAÇÃO
FONTE: Disponível em: <http://www.diegomacedo.com.br/modelos-de-ciclo-de-vida/?print=print>. 
Acesso em: 15 fev. 2015.
construção
produto
construção
protótiporefinamentoprotótipo
avaliação
protótipo pelo
cliente
obtenção dos
requisitos
projeto
rápido
início
fim
Por meio das fases apresentadas na figura acima, você, acadêmico, verifica 
os passos executados pelo processo e quais são as sequências futuras, com o 
intuito de facilitar a visualização final do sistema por parte do cliente.
Com a utilização de protótipos pode-se evitar que após o desenvolvimento 
do software, o cliente identifique que o mesmo não atende completamente as suas 
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
66
necessidades devido às falhas de comunicação ocorridas entre o usuário e o 
engenheiro nas fases de levantamento e análise de requisitos.
Um protótipo pode ser desenvolvido a partir de um desenho em um papel 
ou utilizando ferramentas que nos apoiam neste processo. 
A prototipação é um processo que tem como objetivo facilitar o 
entendimento dos requisitos, apresentar conceitos e funcionalidades do software. 
Desta forma podemos propor uma solução adequada para o problema do cliente, 
aumentando sua percepção de valor (CAMARINI, 2013).
Vale destacar que a adoção deste tipo de ferramenta pode induzir ao 
usuário, cliente a se equivocar e achar que o software se encontra em um estágio 
avançado de desenvolvimento no qual ele não está ainda. “É preciso deixar claro 
ao usuário que, o que está sendo apresentado é apenas um rascunho do que será 
o software quando estiver finalizado o desenvolvimento” (GUEDES, 2004, p.21).
Observe a Figura a seguir para uma melhor compreensão dos processos 
que envolvem a prototipação.
FIGURA 41 – PROCESSOS DE UM PROTÓTIPO
FONTE: Disponível em: <http://slideplayer.com.br/slide/327207/>. Acesso em: 15 fev. 2015.
Todos os passos apresentados na figura acima são necessários para o 
processo de prototipação, afinal somente com a conclusão de todos os passos é 
que se pode chegar à avaliação do protótipo, ou seja, se ele realmente atenderá às 
necessidades de seus clientes.
Para nos apoiarmos nestes trabalhos, o engenheiro de software pode contar 
com alguns instrumentos, desde planilhas eletrônicas (Excel) onde é possível 
literalmente desenhar as telas ou ferramentas do tipo RAD (Rapid Application 
Development ou Desenvolvimento Rápido de Aplicações) como Delphi, Visual 
Basic ou Apex, entre outras. Estas ferramentas disponibilizam ambientes que nos 
permitem a construção e alteração de interfaces de forma muito rápida.
TÓPICO 1 | INTRODUÇÃO A UML
67
3.3 PRAZOS E CUSTOS
Segundo Barcellos (2013), entregar um produto com qualidade, dentro do 
prazo e custos esperados, é hoje um grande desafio para as organizações. Fatores 
como esses impulsionam o interesse, por parte das organizações, pela estimativa 
e controle dos custos dos projetos de software.
Assim, vale destacar que, logo após as primeiras entrevistas, os clientes 
ficam bastante ansiosos para saber quanto vai custar o sistema de informação e 
em quanto tempo eles o terão implantado e funcionando. 
Porém, estas não são as únicas perguntas que se buscam responder 
nesta etapa, mas é necessário verificar: quantos profissionais irão trabalhar no 
projeto? Como determinar a real complexidade do software? Como irão trabalhar 
para entregar o sistema no prazo? Entre outras dúvidas que são sanadas neste 
momento.
Mesmo assim, é difícil determinar com exatidão os prazos finais de entrega 
de um software. É recomendável sempre acrescentar uma margem de segurança à 
data de entrega para minimizar erros de estimativas.
FIGURA 42 – PRAZOS E CUSTOS
FONTE: Disponível em: <http://www.logimex.com.br/reducao-de-custos.php>. Acesso em: 15 
fev. 2015.
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
68
Durante o planejamento de um projeto de software é realizado o 
planejamento de custos, em que esforço, prazo e custos propriamente ditos são 
planejados para o projeto em questão. Quanto maior a experiência e conhecimentodo gerente do projeto, maior será sua capacidade de realizar um bom planejamento 
de custos (BARCELLOS, 2013).
Analisando a citação anterior, vale destacar a importância de um 
planejamento, sanando dúvidas, buscando desenvolver protótipos, entre outros 
meios para não estourar o orçamento, não frustrar o cliente por atraso na entrega 
do sistema, não ter margem para errar no desenvolvimento, afinal tudo tem um 
custo e um prazo para conclusão.
Uma estimativa errada pode trazer prejuízos financeiros ao cliente por 
não ter o projeto em operação e frustrar uma expectativa de mercado, assim 
como para empresa que desenvolve o sistema, como, por exemplo, o acréscimo 
no pagamento de salários de profissionais que não haviam sido provisionados 
neste projeto.
3.4 MANUTENÇÃO
É ilusão imaginar que a vida de um software se encerra logo após sua 
implantação, com certeza, ele será utilizado por anos, e durante este período de uso 
serão necessárias inúmeras manutenções, seja por defeito, seja por atualizações, 
impostos, alterações de alíquotas, indiferente do motivo, a manutenção é certa. 
Assim, lhe pergunto, acadêmico(a), você sabe o significado de manutenção 
e o seu custo? De acordo com Spínola (2013), a manutenção é caracterizada pela 
modificação do software já entregue ao cliente, ou seja, a manutenção é qualquer 
alteração no software após sua entrada em produção.
Com relação a custos, Guedes (2004) descreve que o custo de manutenção 
de um software pode ser de 40 a 60% do custo total do projeto.
Sendo assim, é possível dizer que a modelagem utilizada pela UML 
diminui os custos com manutenção, ou seja, com a modelagem correta, o sistema 
não apresenta erro e com isso não necessita de manutenção.
TÓPICO 1 | INTRODUÇÃO A UML
69
FIGURA 43 – MANUTENÇÃO DE SOFTWARE
FONTE: Disponível em: <http://tecnicovip.forumpratodos.com/>. Acesso 
em: 17 fev. 2015.
A modelagem não serve unicamente para diminuir a necessidade de 
futuras manutenções, mas também para facilitar a compreensão do 
sistema por quem tiver que mantê-lo, já que, em geral, a manutenção 
de um sistema é considerada uma tarefa ingrata pelos profissionais de 
desenvolvimento, por normalmente exigir que estes despendam grandes 
esforços para compreender códigos escritos por outros profissionais 
com estilos de desenvolvimento diferentes e que normalmente não se 
encontram mais na empresa (GUEDES, 2004, p. 23).
Desta forma, é importante frisar que quando utilizada uma modelagem 
correta, e se estiver associada a uma documentação completa e atualizada em um 
sistema de informação, é possível tornar mais rápido o processo de manutenção 
e evitar erros durante este processo.
Após algumas definições sobre manutenção, observe agora, os tipos de 
manutenções existentes em um software:
• Manutenção corretiva – é o tipo de manutenção utilizada na hora de realizar a 
correção de defeitos de funcionalidade do sistema, incluindo também acertos 
emergenciais do programa. 
• Manutenção evolutiva – este tipo de manutenção visa acrescentar novas 
funcionalidades e melhorias conforme solicitações realizadas pelos usuários.
• Manutenção adaptativa – são as modificações realizadas em um software 
adaptando a uma nova realidade. Ex.: inclusão de um novo imposto, uma nova 
regra imposta pelo governo.
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
70
FIGURA 44 – MANUTENÇÃO
FONTE: Disponível em: <http://www.gfi.pt/index.php?option=com_content&view=article&id=181>. 
Acesso em: 17 fev. 2015.
3.5 DOCUMENTAÇÃO HISTÓRICA
O termo documentação histórica foi adotado para justificar a guarda da 
documentação de um projeto por um longo período de tempo, ou seja, é histórica 
por guardar todas as modificações existentes em um sistema de informação.
Assim, segundo Hoffmann (2002, p. 8), “a documentação é ‘filha’ do 
projeto que a gera, enquanto ele estiver em execução. Quando o projeto terminar, a 
documentação sobreviverá a ele e, como ‘herdeira’, retém toda a riqueza, todos os 
resultados, as virtudes e (por que não?) as deficiências e as carências do projeto”.
Continuando seu pensamento, a autora descreve ainda que, 
a documentação, vista como uma ferramenta de auxílio a ser utilizada 
no momento de sua necessidade por todas as pessoas envolvidas com 
o sistema, precisa, para cumprir este papel, ser elaborada ao final de 
cada fase determinada pela metodologia adotada na organização para 
desenvolver seu sistema, bem como necessita ser atualizada sempre 
que houver uma modificação. (HOFFMANN, 2002, p. 11).
Qualquer manutenção que for realizada em um sistema de informação 
necessita ser documentada e modelada, somente assim não irá prejudicar manutenções 
futuras, afinal, pior do que não ter documentação de um sistema é ele estar desatualizado 
no momento de uma manutenção.
IMPORTANT
E
Incidências, 
erros e falhas
Identificação de 
potenciais problemas
Evoluções/adaptações
tecnológicas
Identificação
automatizada de
potenciais problemas
Predictiva
Adaptativa
Preventiva
Correctiva Evolutiva
Novas funcionalidades
TÓPICO 1 | INTRODUÇÃO A UML
71
FIGURA 45 – DOCUMENTAÇÃO DE SOFTWARE
FONTE: Disponível em: <http://www.ceviu.com.br/blog/info/artigos/documentacao-de-
software-e-necessaria/>. Acesso em: 2 fev. 2015.
Com base nas citações realizadas anteriormente, é necessário que todo 
sistema de informação ou software necessite de uma metodologia, que deve ser 
moderna e que ofereça a documentação completa. Assim, a empresa responsável 
pelo desenvolvimento do sistema deve definir a metodologia que irá adotar, 
com isso buscar sempre a efetividade, permanência, segurança, entre outras 
características por parte dos gestores e desenvolvedores.
4 EVOLUÇÃO
Segundo Wazlawick (2013), as Leis de Evolução de Lehman se aplicam 
apenas aos sistemas de tipo E (sistemas desenvolvidos pelos processos usuais de 
análise, projeto e codificação). Estabelecem que a evolução de software deste tipo 
é inevitável, e não apenas resultado de uma equipe de desenvolvimento. 
O autor destaca ainda que a evolução destes programas está sujeita a uma 
dinâmica de autorregulação que faz com que as medidas globais de esforço e 
outros atributos de processos sejam estatisticamente previsíveis.
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
72
Assim, a evolução dos sistemas de informação ocorre devido à grande 
dinâmica dos processos empresariais, governamentais e a globalização. À medida 
que estes processos evoluem precisa-se adequar os sistemas de informação à nova 
realidade dos processos.
Um sistema de informação deve ser estruturado de forma que permita 
acoplar novas funcionalidades ou até mesmo interagir com outros sistemas de 
informação, sejam internos ou externos.
FIGURA 46 – EVOLUÇÃO
FONTE: Disponível em: <http://yedaseveral.com.br/yeda-several/?page_id=580>. Acesso em: 2 
fev. 2015.
73
RESUMO DO TÓPICO 1
Neste tópico, você, acadêmico, teve a oportunidade de ampliar seus 
conhecimentos acerca da notação UML, afinal foi apresentado seu histórico, 
contendo sua origem e sua evolução até os dias atuais.
Partindo de seu histórico vale destacar a importância do software dentro 
das organizações. Para realizar este novo desafio necessitamos do levantamento 
de requisitos que atendam às necessidades específicas de cada departamento, 
analisando assim qual a melhor forma de desenvolver os requisitos solicitados.
Em um mercado cada vez mais competitivo, respeitar os prazos e os 
custos do desenvolvimento de um sistema faz com que a organização atinja com 
maior assertividade e rapidez seus objetivos e metas.
Preservar uma boa documentação do software é um dos pré-requisitos 
para a manutenção e constante evolução do sistema, afinal nem sempre uma 
manutenção ou evolução são realizadas pela equipe que desenvolveu o sistema 
original.
Bom estudo!
74
AUTOATIVIDADE
1 Agora, que você compreendeu a importância de modelar software, descreva 
quais são os principais objetivos da modelagem que foram apresentados:
2 Utilizando-se dos fatores críticos acercado Levantamento e Análise de 
requisitos, assinale V para as sentenças verdadeiras e F para as falsas.
( ) Os requisitos apresentados estão demonstrados de forma incompleta.
( ) A falta de envolvimento do usuário não ocorre, afinal, o mesmo está 
presente no desenvolvimento do projeto.
( ) Dentro das organizações é possível verificar a falta de apoio por parte 
dos executivos.
( ) Depois de pronto o projeto, jamais ocorrem mudanças de requisitos ou de 
especificações.
Agora, assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) V – F – V – F.
b) ( ) F – F – V – V.
c) ( ) V – V – F – V.
d) ( ) V – V – V – F.
3 Descreva o que você entendeu acerca da importância de prazos e custos em 
um projeto.
4 Você conseguiu compreender a importância da manutenção em um sistema 
de informação? Então, descreva os tipos de manutenção existentes:
5 Este termo foi adotado para justificar a guarda da documentação de um 
projeto por um longo período de tempo, ou seja, é histórico por guardar todas 
as modificações existentes em um sistema de informação. Do que estamos 
falando?
a) ( ) Prazos e Custos.
b) ( ) Manutenção.
c) ( ) Prototipação.
d) ( ) Documentação histórica.
75
a) ( ) Prototipação.
b) ( ) Evolução.
c) ( ) Manutenção.
d) ( ) Documentação histórica.
6 Observe a figura e verifique a qual das opções ela se refere.
76
77
TÓPICO 2
FASES DO DESENVOLVIMENTO DE 
UM SISTEMA UML
UNIDADE 2
1 INTRODUÇÃO
No Tópico 2 explanaremos acerca das fases de desenvolvimento de um 
sistema UML, características, requisitos e comportamento encontrado em cada 
uma delas.
Na análise de requisitos veremos como proceder ao levantamento de 
requisitos e aos envolvidos com o projeto. Já na fase análise apresentaremos os 
primeiros diagramas e as primeiras abstrações do sistema, suas funcionalidades e 
processos. Ao conhecermos mais sobre o design, exploraremos suas classes, seus 
atributos, métodos e nos aprofundaremos na infraestrutura onde, ao encerrarmos 
esta etapa teremos os documentos do projeto em um nível de detalhe onde já 
podemos disponibilizar para os programadores executarem a codificação. 
E por fim, a programação, quando as análises realizadas são codificadas 
em objetos sistêmicos que compõem o sistema de informação.
2 ANÁLISE DE REQUISITOS
Como visto, um pouco, no Tópico 1 desta unidade, Análise de Requisito 
descreve os requisitos necessários à condução dos negócios. 
Assim, é possível dizer que a fase de análise dos requisitos é responsável 
pela coleta dos dados que são indispensáveis e necessários para que o usuário 
do sistema possa solucionar seu problema e alcançar os objetivos desejados da 
organização, para isto são realizadas inúmeras entrevistas, em que o usuário 
detalha como funcionam suas atividades e quais são os processos atualmente 
afins que possam ser informatizados, e por fim, os serviços necessários fornecidos 
ao usuário ou cliente.
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
78
Nesta fase do projeto são expostas as incertezas dos usuários com relação 
às potencialidades do sistema de informação. Em geral, nesta fase, os engenheiros 
de software e analistas acabam sugerindo muitas características e funcionalidades 
do sistema que o cliente não havia imaginado. 
Por meio da figura a seguir, você pode observar os processos que ocorrem 
na análise de requisitos, sendo demonstrado como primeiro passo a entrada no 
processo e ao final o documento de requisitos. Vale lembrar que este documento 
apresenta as informações que o usuário deseja receber do sistema depois de pronto.
FIGURA 47 – ANÁLISE DE REQUISITOS
FONTE: Disponível em: <http://slideplayer.com.br/slide/44191/>. Acesso em: 17 fev. 2015.
Após apresentar a funcionalidade da Análise de Requisitos e como ela 
é elaborada, é necessário estar atento aos problemas que podem ocorrer neste 
processo. Monteiro (2010) descreve estes problemas como sendo:
1. Stakeholders (pessoas envolvidas no projeto) não sabem o que querem.
2. Stakeholders expressam requisitos em sua terminologia.
3. Stakeholders diferentes podem gerar requisitos conflitantes.
4. Fatores políticos e organizacionais podem influenciar os requisitos do sistema.
5. Requisitos mudam durante o processo de análise. Stakeholders novos podem 
surgir e o ambiente de trabalho muda.
Definição e 
especificação 
de requisitos
Documento
de requisitos
Validação
de requisitos
Coleta de 
requisitos
Entendimento
do domínio
Resolução
de conflito
Classificação
Atrib.
PrioridadeEntrada do
processo
TÓPICO 2 | FASES DO DESENVOLVIMENTO DE UM SISTEMA UML
79
FIGURA 48 – POSSÍVEIS PROBLEMAS NA ELABORAÇÃO DO PROJETO
FONTE: Disponível em: <http://pt.slideshare.net/computacaodepressao/análise-de-requisitos-1 
5926049>. Acesso em: 17 fev. 2015.
Esta figura demonstra o quão conflitante é o processo de análise de 
requisitos, afinal inúmeros são os problemas que ocorrem diariamente no 
desenvolvimento do projeto e, muitas vezes, o cliente ou usuário não sabem ao 
certo o que desejam, porém o analista deve estar atento para então conseguir 
capturar as informações e assim chegar às necessidades de seu cliente.
3 ANÁLISE
Na fase de análise são definidas as primeiras abstrações (classes e 
objetos) e mecanismos que estarão presentes no domínio do problema (sistema 
de informação que será desenvolvido). As classes são modeladas e conectadas 
através de relacionamentos com outras classes, que são descritas no Diagrama de 
Classe (JACOBY, 2013).
As colaborações que ocorrem entre classes também são registradas neste 
diagrama de classe, para assim desenvolver e atender os "use-cases" e requisitos 
modelados anteriormente, estas colaborações são criadas através de modelos 
dinâmicos em UML. 
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
80
Na análise, só serão modeladas classes que pertençam ao domínio 
principal do problema do software, ou seja, classes técnicas que fazem parte da 
infraestrutura necessária para suportar o sistema como classes que gerenciem 
banco de dados, interface, comunicação, concorrência e outros não estarão 
presentes neste diagrama.
Veja como se comporta a fase de análise no diagrama de classes. Vale 
lembrar que o tema Diagrama de Classes será aprofundado na Unidade 3 deste 
Caderno de Estudos.
FIGURA 49 – DIAGRAMA DE CLASSES
FONTE: Disponível em: <http://www.labin.unilasalle.edu.br/infoedu/siteinfoedu1_03/
trabalhos/sitescc/uml_final/exemplo.htm>. Acesso em: 5 fev. 2015.
Agência
Cod_Agência: String
Nome_Agência: String
Criar()
Destruir()
Histórico
Conta Corrente
Cliente
Possui
Possui
Possui
Possui
Possui
Possui Possui
Possui
1
1
1
1
1
1
1
0
*
*
*
*
*
* *
*
Operação
Aplicações Pré Fixadas
Poupança
Dependente
Data: Date
Operação: Operação
Valor: Num
Cod: String
Saldo: Num
Vetor_Aplic_PreFix: Aplic_Pre_Fixadas
Vetor Histórico: Histórico
Agência: Agência
Nome: String
CPF: String
Rua: String
Fone: String
Bairro: String
Cidade: String
CEP: String
Estado: String
Vetor Dependentes: Dependentes
Vetor Conta_Correntes: Conta_Corrente
Vetor Poupanças: Poupança
Nome: String
CPF: String
Parentesco: String
Vetor Poupanças: Poupança
Valor: Num
Data_Venc : date
Taxa: Num
Data_Venc : date
Criar()
Destruir()
Depositar()
Debitar()
Transferir()
Obter_saldo()
Aplicar_Prefix()
Criar()
Destruir()
Tirar_Extrato()
Retirar_Aplic_Prefix()
Criar()
Destruir()
Localizar()
Abrir_Conta_Corrente()
Remover_Conta_Corrente()
Adic_Dependente()
Excluir_Dependente()
Abrir_Poupança()
Fechar_Poupança()
Criar()
Destruir()
Localizar()
Abrir_Poupança()
Fechar_Poupança()
Criar()
Destruir()
Criar()
Destruir()
Criar()
Destruir()
Cod_Operação: String
Dooc_Operação: String
TÓPICO 2 | FASES DO DESENVOLVIMENTO DE UM SISTEMA UML
81
4 DESIGN (PROJETO)
Na fase de design, você, acadêmico(a), pode verificar que o resultado da 
análise é expandido em soluções técnicas. 
Jacoby (2013) descreve que novas classes, atributos, métodos e 
funcionalidades serão adicionados a fim de prover uma infraestruturatécnica 
necessária à interface do usuário e de periféricos, gerenciamento de banco de 
dados, comunicação com outros sistemas, entre outros.
O autor discorre ainda que as classes do domínio do problema modeladas 
na fase de análise são mescladas nessa nova infraestrutura técnica, tornando 
possível alterar tanto o domínio do problema quanto a infraestrutura. 
Por fim, o design resulta no detalhamento das especificações para a fase de 
programação do sistema. 
FIGURA 50 – PROGRAMAÇÃO DO SISTEMA
Fonte: Disponível em: <http://pt.slideshare.net/Ridlo/desenhando-componentes-de-
software-arquitetura-de-software>. Acesso em: 5 fev. 2015.
Você pode verificar na figura acima que as informações que chegam à fase 
Design são recebidas da Análise de Requisitos e da Análise, assim, filtrando como 
o sistema deve ser desenvolvido. 
É possível perceber que no Projeto (Visão Lógica), foram desenvolvidos 
diagramas de classes, diagramas de sequências, diagramas de atividades entre 
outros. Todos estes diagramas você verá com maiores detalhes na Unidade 3 
deste Caderno de Estudos.
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
82
5 PROGRAMAÇÃO
Na fase de programação as classes provenientes do design são 
convertidas para o código da linguagem orientada a objetos 
escolhida (a utilização de linguagens procedurais é extremamente 
não recomendada). Dependendo da capacidade da linguagem usada, 
essa conversão pode ser uma tarefa fácil ou muito complicada. No 
momento da criação de modelos de análise e design em UML, é melhor 
evitar traduzi-los mentalmente em código. (JACOBY, 2013, p. 2).
Em sentido complementar, Jacoby (2013, p. 2) descreve ainda que nas fases 
anteriores, os modelos criados são o significado do entendimento e da estrutura 
do sistema, então, no momento da geração do código, onde o analista conclua 
antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão 
mais demonstrando o real perfil do sistema. “A programação é uma fase separada 
e distinta onde os modelos criados são convertidos em código”.
Por fim, o sistema depois de pronto será disponibilizado para ser testado 
pelo usuário final. Este é o momento de verificar se os resultados apresentados 
pelo sistema estão realmente de acordo com as intenções e necessidades do 
usuário final.
Após definição de cada uma das etapas de desenvolvimento de um 
sistema, observe o Mapa Mental das fases da UML.
Linguagem Procedual é a linguagem de programação na qual o elemento 
básico de programação é a procedure (uma sequência de instruções – rotina, 
sub-rotina ou função – associadas a um nome próprio).
IMPORTANT
E
TÓPICO 2 | FASES DO DESENVOLVIMENTO DE UM SISTEMA UML
83
FI
G
U
R
A
 5
1 
–
 M
A
P
A
 M
E
N
TA
L 
D
A
S 
FA
SE
S 
D
A
 U
M
L
FO
N
T
E
: 
D
is
p
o
n
ív
e
l e
m
: 
<
h
tt
p
:/
/w
w
w
.d
ie
g
o
m
ac
e
d
o
.c
o
m
.b
r/
ta
g
/u
m
l?
p
ri
n
t=
p
ri
n
t-
p
ag
e
>
. A
c
e
ss
o
 e
m
: 
10
 f
e
v.
 2
0
15
.
84
RESUMO DO TÓPICO 2
Neste tópico foram abordadas as fases de desenvolvimento da UML. Com 
isso você pôde conhecer qual é o comportamento da análise de requisitos, que 
tem por objetivo coletar as informações das atividades desenvolvidas pelo cliente 
e assim iniciar o processo de desenvolvimento do sistema de informação.
A fase de análise foi apresentada por meio de exemplos, os primeiros 
diagramas e as primeiras abstrações de um sistema.
Acerca do design que tem por objetivo prover uma infraestrutura técnica 
necessária: a interface do usuário e de periféricos, gerenciamento de banco de 
dados, comunicação com outros sistemas, entre outros.
Finalizando as fases do desenvolvimento UML, foi apresentada a 
programação, em que as análises realizadas são codificadas em objetos sistêmicos 
que compõem o sistema de informação. O sistema depois de pronto será 
disponibilizado para ser testado pelo usuário final, sendo este o momento de 
verificar se os resultados apresentados pelo sistema estão realmente de acordo 
com as intenções e necessidades do usuário final.
Bom estudo!
85
AUTOATIVIDADE
1 Descreva os problemas que podem ocorrer durante o processo de Análise 
de Requisitos.
2 São definidas as primeiras abstrações (classes e objetos) e mecanismos que 
estarão presentes no domínio do problema (sistema de informação que será 
desenvolvido). Esta definição se refere à:
a) ( ) Prototipação.
b) ( ) Análise.
c) ( ) Análise de requisitos.
d) ( ) Programação.
3 Observe a figura a seguir e verifique a qual das alternativas ela se refere.
a) ( ) Análise de requisitos.
b) ( ) Design.
c) ( ) Programação.
d) ( ) Manutenção.
4 Com base nas informações recebidas no decorrer do tópico, relacione os 
itens conforme solicitado:
I. Programação.
II. Análise de requisitos.
III. Análise.
IV. Design.
86
( ) É responsável pela coleta dos dados que são indispensáveis e necessários 
para que o usuário do sistema possa solucionar seu problema e alcançar 
os objetivos desejados da organização.
( ) Descreve que novas classes, atributos, métodos e funcionalidades serão 
adicionados a fim de prover uma infraestrutura técnica necessária: a 
interface do usuário e de periféricos, gerenciamento de banco de dados, 
comunicação com outros sistemas.
( ) Só serão modeladas classes que pertençam ao domínio principal 
do problema do software, ou seja, classes técnicas que fazem parte da 
infraestrutura necessária para suportar o sistema como classes que 
gerenciem banco de dados, interface, comunicação, concorrência e outros 
não estarão presentes neste diagrama.
( ) As classes provenientes do design são convertidas para o código da 
linguagem orientada a objetos escolhida.
Agora, assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) II – IV – III – I.
b) ( ) I – II – III – IV.
c) ( ) III – I – IV – II.
d) ( ) IV – III – II – I.
87
TÓPICO 3
MODELOS DE 
ELEMENTOS
UNIDADE 2
1 INTRODUÇÃO
Neste tópico serão apresentados os modelos de elementos que compõem 
os diagramas. Estes elementos nada mais são do que as classes que definem os 
atributos e os métodos de um conjunto de objetos; os objetos representam um 
elemento que podemos manipular, acompanhar seu comportamento, criar ou 
destruir.
Estados representam a situação em que um objeto se encontra em um 
determinado momento durante o período em que este participa de um processo; os 
pacotes por sua vez são utilizados para demonstrar os limites de cada subsistema 
e como eles se inter-relacionam. Neste sentido, os componentes representam uma 
unidade de código de software; e por fim são apresentados os relacionamentos 
que ligam as classes/objetos entre si criando relações lógicas entre estas entidades. 
Um elemento pode existir em diversos tipos de diagramas, mas existem 
regras que definem que elementos podem ser mostrados em que tipo de diagrama 
(JACOBY, 2013). Todos os modelos de elementos descritos serão definidos e 
exemplificados a seguir.
2 CLASSES
Segundo Jacoby (2013), uma classe define os atributos e os métodos de 
um conjunto de objetos. Assim, todos os objetos desta classe (instâncias desta 
classe) compartilham o mesmo comportamento, e possuem o mesmo conjunto de 
atributos (cada objeto possui seu próprio conjunto). 
O autor destaca que o termo “TIPO” é por vezes usado ao invés de 
CLASSE, mas é importante mencionar que estes dois termos são a mesma coisa. 
Tipo é considerado um termo mais genérico.
Em outras palavras, Jacoby (2013) descreve que uma classe é a descrição 
de um tipo de objeto, onde todos os objetos são instâncias de classes. Assim, a 
classe descreve as propriedades e comportamentos daquele objeto. Objetos só 
podem ser instanciados de classes. 
88
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
Complementando seu pensamento, o mesmo autor discorre que 
normalmente usam-se classes para classificar os objetos que identificamos no 
mundo real. Tomando como exemplo Charles Darwin, que usou classes para 
classificar os animais conhecidos, e combinou suas classes por herança paradescrever a "Teoria da Evolução". A técnica de herança entre classes é também 
usada em orientação a objetos.
FIGURA 52 – CLASSES 
FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/776/uml-unified-
modeling-language-requisitos-classes-e-objetos.aspx>. Acesso em: 10 fev. 2015.
Identificar as classes de um sistema pode ser complicado, e deve ser feito 
por experts no domínio do problema a que o software modelado se baseia. 
As classes devem ser retiradas do domínio do problema e serem nomeadas pelo que elas 
representam no sistema (JACOBY, 2013).
IMPORTANT
E
Name: Classes
Author: Nogueira JR
Version: 1.0
Created: 15/09/2004 22:43:49
Updated: 07/10/2004 17:22:04
id Classes
cls Cliente
responsibilities
constraints
tags
{specification}
- CLI_ID: *
- CLI_DESCR:
- Nome: volatile char [2.. 7 ordered]
+ <<property>> pNome( ) : char
Cadastro dos Clientes
{Entrada manual}
Software = Windows XP
TÓPICO 3 | MODELOS DE ELEMENTOS
89
Na figura apresentada é possível visualizar como a classe é dividida e 
quais são os seus componentes.
3 OBJETOS
Segundo a definição de Jacoby (2013), um objeto é um elemento que 
podemos manipular, acompanhar seu comportamento, criar, destruir etc. Um 
objeto existe no mundo real. Pode ser uma parte de qualquer tipo de sistema, 
por exemplo, uma máquina, uma organização ou negócio. Existem objetos que 
não encontramos no mundo real, mas que podem ser vistos de derivações de 
estudos da estrutura e comportamento de outros objetos do mundo real.
Já Nogueira (2005) entende que um objeto é simplesmente alguma 
coisa que faz sentido no contexto de uma aplicação. Objeto é uma entidade 
independente, assíncrona e concorrente, armazena dados, encapsula serviços, 
troca mensagens com outros objetos, e é modelado para executar as funções 
finais do sistema.
Assim, em notação UML, Jacoby (2013) descreve ainda que um objeto 
é apresentado por meio de uma classe tendo seu nome destacado, e o nome 
do objeto pode ser mostrado opcionalmente precedido do nome da classe, 
conforme exemplo:
FIGURA 53 – NOME NA CLASSE
FONTE: Jacoby (2013)
Você irá visualizar mais a respeito de classes, em cada um dos diagramas que 
serão apresentados na Unidade 3 deste Caderno de Estudos.
Nome do Objeto
Atributos
Operações
Nome: "Pablo Barros"
Idade: 20
Criar()
Destruir()
Pablo Barros: Cliente
ESTUDOS FU
TUROS
90
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
4 ESTADOS
De acordo com Guedes (2004, p. 132), “um Estado representa a situação em 
que um objeto se encontra em um determinado momento durante o período em 
que este participa de um processo”. Assim, um objeto pode passar por diversos 
estados dentro de um mesmo processo.
Neste sentido, o autor descreve que um estado pode ser apresentado da 
seguinte forma:
a) A espera pela ocorrência em um evento.
b) A reação a um estímulo.
c) A execução de alguma atividade.
d) A satisfação de alguma condição.
Todos os objetos possuem um estado que significa o resultado de 
atividades executadas pelo objeto, e é normalmente determinada pelos valores 
de seus atributos e ligações com outros objetos (JACOBY, 2013).
O autor descreve que um objeto muda de estado quando acontece algo, 
o fato de acontecer alguma coisa com o objeto é chamado de evento. Através da 
análise da mudança de estados dos tipos de objetos de um sistema, podemos 
prever todos os possíveis comportamentos de alguns objetos de acordo com os 
eventos que os mesmos possam sofrer.
Na figura a seguir, você poderá observar as três fases do estado, sendo 
elas: Estado Inicial, Estado e o Estado Final, bem como os eventos que ocorrem 
no decorrer do processo.
FIGURA 54 – FASES DO ESTADO
FONTE: Disponível em: <http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/
uml1/uml1.htm>. Acesso em: 10 fev. 2015.
Evento
Estado
Estado inicial Estado finalTransición
On / OffOn / Off
Fotocopiadora
Encendida
TÓPICO 3 | MODELOS DE ELEMENTOS
91
5 PACOTES
Os pacotes permitem organizar elementos em grupos e costumam ser 
utilizados na modelagem de sistemas mais extensos, principalmente 
quando existem vários sistemas ou subsistemas integrados. Os pacotes 
são utilizados para demonstrar os limites de cada subsistema e como 
eles se inter-relacionam. Sendo assim, um pacote é representado por 
um retângulo contendo uma aba (GUEDES, 2004, p. 64).
Em sentido complementar, Jacoby (2013) descreve que Pacote é um 
mecanismo de agrupamento, onde todos os modelos de elementos podem ser 
agrupados. Em UML, um pacote é definido como: "Um mecanismo de propósito 
geral para organizar elementos semanticamente relacionados em grupos." 
(GALEOTE, 2010, p. 2). Todos os modelos de elementos que são ligados ou 
referenciados por um pacote são chamados de "Conteúdo do pacote". Um pacote 
possui vários modelos de elementos, e isto significa que estes não podem ser 
incluídos em outros pacotes.
FIGURA 55 – MODELOS DE PACOTES
FONTE: Disponível em: <http://w3.ualg.pt/~mzacaria/tutorial-uml/topico-pac.html>. Acesso 
em: 10 fev. 2015.
Tipo de Pacote 1 Pacote juntado
Tipo de Pacote 2 Pacote acedido
Pacote
Pacote contido Pacote importado
<<access>>
<<merge>>
<<import>>
Cada pacote é dono do seu conteúdo. Não é possível pôr a mesma classe em 
dois pacotes diferentes. Contudo, ela pode ser usada em diagramas que se encontram em 
diferentes pacotes (ZACARIAS, 2015).
IMPORTANT
E
92
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
6 COMPONENTES
Furlan (1998, p. 232) entende que “um componente representa uma 
unidade de código de software (fonte, binário ou executável) e pode ser usado 
para expor o compilador e dependências de runtime, incluindo sua localização 
em nós”. É desenhado como um retângulo maior e dois retângulos menores que 
protraem do seu lado esquerdo, conforme demonstra a figura.
FIGURA 56 – COMPONENTE
FONTE: Disponível em: <http://class-uml.blogspot.com.br/2012 
/05/uml.html>. Acesso em: 17 fev. 2015.
Um componente, segundo a visão de Jacoby (2013), pode ser tanto um 
código em linguagem de programação como um código executável já compilado. 
Segundo Crespo (2010), um componente é uma parte física e substituível 
de um sistema, que proporciona a realização de um conjunto de interfaces, como 
exemplo podemos citar: executáveis, bibliotecas, tabelas, ficheiros, documentos, 
entre outros. O autor complementa descrevendo que um componente representa 
um empacotamento físico de elementos relacionados logicamente (normalmente 
classes).
Na programação UML, Crespo (2010) destaca alguns tipos de componentes 
como sendo:
FONTE: Crespo (2010)
Componente
Archivo
fuente 1
Archivo
fuente 2
Icono 1
Icono 2
Dependencia
Componente
EXE
DLL 2
TÓPICO 3 | MODELOS DE ELEMENTOS
93
Observe no exemplo a ser apresentado, como um componente se comporta 
na construção de um diagrama.
FIGURA 57 – COMPONENTE NA CRIAÇÃO DE UM DIAGRAMA
FONTE: Disponível em: <http://www.ub.edu.ar/catedras/ingenieria/ing_software/
ubftecwwwdfd/uml1/uml1.htm>. Acesso em: 17 fev. 2015.
7 RELACIONAMENTOS
De acordo com Jacoby (2013), os relacionamentos ligam as classes/objetos 
entre si criando relações lógicas entre estas entidades. 
Os relacionamentos podem ser dos seguintes tipos:
a) Associação: É uma relação que descreve um conjunto de vínculos entre 
elementos de modelo. Conceitualmente, representam relacionamentos entre os 
tipos envolvidos com responsabilidades definidas através de operações de acesso 
e atualização, as associações segundo Furlan (1998, p. 118-120) podem ser:
Archivo
fuente 1
Archivo
fuente 2
Icono 1
Icono 2
Dependencia
Componente
EXE
DLL 2
94
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
Associações unárias: Quando há um relacionamento de uma classe para 
consigo própria conectando-se ambos os fins da associação a ela mesma (porém 
os dois fins são distintos). Veja o exemplo:
Associação binária: Quando há duas classes envolvidas na associação de 
forma direta de uma para a outra. Uma associação binária é desenhada como um 
caminho sólido que conecta doissímbolos de classe, sendo que tal caminho pode 
consistir em um ou mais segmentos conectados. Veja o exemplo:
Associação n-ária: É uma associação entre três ou mais classes, mas 
uma única classe pode aparecer mais de uma vez. Cada instância da associação 
representa n estruturas de classes respectivas. Vale destacar que as associações 
ternárias ou superiores são mostradas como diamantes conectados ao símbolo 
de classe através de linhas com um caminho do diamante para cada classe 
participante. Veja o exemplo:
TÓPICO 3 | MODELOS DE ELEMENTOS
95
Desta forma, pode-se dizer que uma associação nada mais é do que uma 
forma usada para demonstrar a dependência estrutural existente entre os objetos, 
o que ocorre normalmente em classes distintas, sendo desenhada por meio de 
linhas sólidas entre os pares de classes demonstrados:
Após as definições de associações, e os tipos existentes, observe a 
simbologia utilizada na construção dos diagramas.
FIGURA 58 – CONSTRUÇÃO DOS DIAGRAMAS
FONTE: Disponível em: <http://www.macoratti.net/net_uml1.
htm>. Acesso em: 17 fev. 2015.
Furlan (1998, p. 120) observa ainda que “a maior parte dos detalhes 
interessantes que ocorrem em uma associação é demonstrada em seus papéis”, 
os quais apresentam as seguintes informações: 
FONTE: Disponível em: <http://pt.slideshare.net/PauloVieiraFeitor/uml-6619738>. 
Acesso em: 17 fev. 2015.
Associação
Dependência
Agregação
Composição
Herança
96
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
FONTE: Disponível em: <http://pt.slideshare.net/PauloVieiraFeitor/uml-6619738>. Acesso 
em: 17 fev. 2015.
FONTE: Disponível em: <http://pt.slideshare.net/PauloVieiraFeitor/uml-6619738>. Acesso em: 
17 fev. 2015.
FONTE: Disponível em: <http://pt.slideshare.net/PauloVieiraFeitor/uml-6619738>. Acesso em: 
17 fev. 2015.
TÓPICO 3 | MODELOS DE ELEMENTOS
97
FONTE: Disponível em: <http://pt.slideshare.net/PauloVieiraFeitor/uml-6619738>. 
Acesso em: 17 fev. 2015.
FONTE: Disponível em: <http://pt.slideshare.net/PauloVieiraFeitor/uml-6619738>. 
Acesso em: 17 fev. 2015.
Agora, partindo deste contexto, onde foram apresentados em formas de 
figura os papéis que cada um dos itens exerce dentro da associação, observe a 
demonstração, a seguir, que compõe todos os itens apresentados.
98
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
FIGURA 59 – PAPÉIS DENTRO DA ASSOCIAÇÃO
FONTE: Furlan (1998, p. 121)
8 MECANISMOS GERAIS
A notação UML utiliza de alguns mecanismos na construção de seus 
diagramas, com o intuito de tratar informações adicionais que ainda não 
foram descritas. Sendo assim, observe a seguir os tipos de mecanismos gerais 
existentes, onde todos serão demonstrados por meio de exemplos para facilitar 
o entendimento.
Estereótipos: É considerado o núcleo do mecanismo de extensão de 
UML. Normalmente são utilizados para estender (enriquecer) o significado 
de um determinado elemento em um diagrama. Estes podem ser classificados 
em: estereótipos gráficos (ícone que lembre o significado do conceito a ele 
associado), e estereótipos de rótulo (um nome delimitado pelos símbolos << e 
>>) (GALEOTE, 2010).
TÓPICO 3 | MODELOS DE ELEMENTOS
99
FIGURA 60 – ESTEREÓTIPOS
FONTE: Disponível em: <http://www.prasabermais.com/analise/aula03.pdf>. Acesso em: 17 fev. 2015.
Notas explicativas: São utilizadas para comentar ou esclarecer alguma 
parte do diagrama. Estas notas podem ser descritas em texto livre, podendo 
corresponder a uma expressão formal utilizando OCL (Object Constraint Language 
– Linguagem de Restrição de Objetos). (GALEOTE, 2010).
FIGURA 61 – NOTAS EXPLICATIVAS
FONTE: Disponível em: <http://www.prasabermais.com/analise/aula03.pdf>. Acesso 
em: 17 fev. 2015.
Etiquetas (Tags): Os elementos gráficos de um diagrama da UML possuem 
propriedades predefinidas. Propriedades adicionais para elementos gráficos de 
um diagrama podem ser definidas através do uso de etiquetas. Existem algumas 
alternativas de notação para definição de etiquetas na UML: { tag = valor } ou { 
tag1 = valor1, tag2 = valor2...} ou { tag } (GALEOTE, 2010). 
100
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
FIGURA 62 – ETIQUETAS
FONTE: Disponível em: <http://slideplayer.com.br/slide/1669103/>. Acesso em: 17 fev. 2015.
Restrições: A todo elemento da UML está associado alguma semântica, 
onde cada elemento gráfico possui um significado bem definido que, uma vez 
entendido, fica implícito na utilização do elemento em algum diagrama. Sendo 
assim, as restrições permitem estender ou alterar a semântica natural de um 
elemento gráfico, ou seja, a restrição é igual à condição que deve ser satisfeita 
(GALEOTE, 2010). 
FIGURA 63 – RESTRIÇÕES
FONTE: Disponível em: <http://pt.slideshare.net/kyrios/uml-4983843>. Acesso em: 17 fev. 2015.
TÓPICO 3 | MODELOS DE ELEMENTOS
101
LEITURA COMPLEMENTAR
Conceitos de orientação a objetos e UML
O começo de tudo
A história da computação teve início na necessidade do homem em 
conseguir realizar cálculos. O caminho foi longo, iniciado com o ábaco, muitos 
anos antes da era cristã. A primeira máquina de calcular que apenas somava e 
subtraía vem surgir apenas em 1642, desenvolvida por Blaise Pascal. Em 1694, 
Gottfried Von Leibniz constrói a primeira calculadora que podia executar as quatro 
operações básicas, e em 1822, o matemático inglês Charles Babbage estabelecia 
os princípios do funcionamento dos computadores eletrônicos no projeto de sua 
máquina diferencial, capaz de realizar os cálculos necessários para elaborar uma 
tabela de logaritmos. A partir daí, outras invenções abriram caminhos para o que 
temos hoje. 
O marco inicial se dá com o primeiro computador eletrônico, o ENIAC 
(Eletrical Numerical Integrator and Calculator), surgido em 1945, e pesando cerca de 
30 toneladas. Até hoje os computadores ainda utilizam a arquitetura proposta por 
Von Neumann. Em 1951, surgia o primeiro computador fabricado comercialmente: 
o UNIVAC I, usado no censo americano por 12 anos seguidos.
A partir da década de 40, descobre-se a importância da computação, e 
essa passa a fazer parte da nossa história. Contudo, numa primeira fase ninguém 
pensava em software. Os esforços estavam voltados à evolução do hardware, 
buscando-se reduzir os problemas das primeiras máquinas. Assim, da primeira 
geração de computadores à válvula, passamos para a segunda geração, utilizando 
transistores.
A primeira linguagem de programação surgida foi a linguagem de 
máquina, na década de 50 – o Assembly. Nesse momento, a preocupação 
era restrita aos comandos, nem se pensava em análise, muito menos em 
modelagem de requisitos. A partir de então, surgem as linguagens de alto nível, 
como Fortran, Algol e Cobol.
 
Um rápido aumento na complexidade das demandas por softwares e a falta 
de técnicas para definição de novos sistemas culminaram em diversos problemas, 
entre eles: estouro de orçamento e prazo, softwares de baixa qualidade, requisitos 
não atendidos e código de manutenção difícil. Estava definida a crise de software. 
A solução para contornar a crise veio com o conceito da Engenharia de 
Software, em 1968. Objetivava-se trazer os princípios da Engenharia, com todo 
o seu planejamento e modelagem, para se resolver os problemas da área ainda 
imatura. No mesmo ano de 68, Dijkstra escreve sobre a programação estruturada; 
tinha início o marco do primeiro paradigma de desenvolvimento de sistemas.
 
102
UNIDADE 2 | UNIFIED MODELING LANGUAGE (UML)
Mas enquanto novas linguagens surgiam – Pascal, C –, ainda não se tinha a 
definição de uma metodologia de desenvolvimento de sistemas, até 1978, quando 
Tom DeMarco escreve seu livro sobre análise estruturada. Contudo, a dificuldade 
de manutenção dos diversos modelos gerados na fase de análise e projeto, fez 
com que se percebesse, nas duas décadas seguintes, que esse paradigma ainda 
não era a solução para a velha crise de software.
Naturalmente, logo se pensa que a orientação a objetos surgiu após a 
análise estruturada, como uma evolução dessa metodologia, buscando-se assoluções necessárias para um projeto confiável e de manutenção fácil. É correto 
imaginar que o paradigma da orientação a objetos tornou-se a solução para 
acompanhar a demanda cada vez maior e frequente do mercado, mas o erro está 
no posicionamento histórico do conceito de orientação a objetos, pois este surgiu 
muito antes do conceito da programação estruturada.
Em 1962, Ole-Johan Dahl e Kristen Nygaard criaram uma linguagem 
chamada Simula, baseada na linguagem Algol 60. O diferencial residia em seu 
objetivo: permitir o projeto de simulações. Surgia a primeira linguagem orientada 
a objetos, apresentando os conceitos de classe e herança. Essa foi a semente que 
inspirou o desenvolvimento de uma nova linguagem, a primeira totalmente 
orientada a objetos o SmallTalk. Nela, não existem tipos primitivos, tudo é 
representado em forma de objeto: números, caracteres etc. Disponibilizada ao 
público no início dos anos 80, SmallTalk solidificou para a comunidade os conceitos 
de classe, objeto, atributo, método, encapsulamento, herança e mensagem. A 
partir daí, novas linguagens surgiram, como o C++ (versão OO da linguagem 
C), Object Pascal (versão OO do Pascal), Eiffel e Java (criado a partir do C++). 
Conceitos fundamentais de orientação a objetos
Os conceitos da orientação a objetos surgiram da necessidade em se 
enfatizar unidades discretas, e obter a reutilização de código, mantendo-se a 
qualidade do software. O núcleo do pensamento OO predomina num foco sobre 
os dados, em vez dos processos, compondo módulos autossuficientes – os objetos 
–, encerrando em sua estrutura todo o conhecimento dos dados e dos processos 
para manipulação desses dados.
O que se obtém de principal na modelagem orientada a objetos é a 
possibilidade de se abstrair diretamente os conceitos do mundo real, sem 
subterfúgios para se chegar à solução computacional. 
Os conceitos fundamentais de orientação a objetos são o contrato que 
estabelece toda e qualquer implementação que se diga OO. Sendo assim, se 
um desses conceitos não for atendido, não podemos afirmar que determinada 
tecnologia possa ser nomeada como orientada a objetos. Isso aconteceu com a 
linguagem.
FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-8-conceitos-
de-orientacao-a-objetos-e-uml/11311>. Acesso em: 17 fev. 2015.
103
RESUMO DO TÓPICO 3
Neste tópico, você, acadêmico, teve oportunidade de conhecer os modelos 
de elementos que compõem os diagramas.
 
Vale relembrar as classes que definem os atributos e os métodos de um 
conjunto de objetos; os objetos, por sua vez, representam os elementos que 
podemos controlar na composição dos diversos tipos de diagramas.
Neste sentido, os estados dos objetos representam a situação em que se 
encontram em um determinado momento durante o período em que participam 
de um processo; com relação aos pacotes salientamos que são utilizados para 
demonstrar os limites de cada subsistema e como eles se inter-relacionam.
 Os componentes representam uma unidade de código de software; e os 
diferentes tipos de relacionamentos que ligam as classes/objetos entre si criando 
relações lógicas entre estas entidades. 
Para finalizar destacamos os diversos mecanismos gerais existentes na 
composição dos diagramas. São eles: Estereótipos, Notas Explicativas, Etiquetas 
e Restrições.
Neste momento, você está apto a desenvolver as autoatividades deste 
tópico.
Bom estudo!
104
AUTOATIVIDADE
1 Define os atributos e os métodos de um conjunto de objetos. Esta definição 
se refere à qual das alternativas a seguir?
a) ( ) Objetos.
b) ( ) Classes.
c) ( ) Pacotes.
d) ( ) Estados.
2 Descreva o que você entende por objeto e exemplifique.
3 Descreva as quatro formas em que os Estados são apresentados:
4 Verifique a figura a seguir e veja a qual das alternativas ela se refere.
a) ( ) Associação Ternária.
b) ( ) Associação Binária.
c) ( ) Generalização.
d) ( ) Multiplicidade.
5 Com relação aos mecanismos gerais apresentados na notação UML, 
relacione os itens a seguir:
I. Estereótipos.
II. Notas explicativas.
III. Etiquetas.
IV. Restrições.
( ) Representam os elementos gráficos de um diagrama da UML, possuem 
propriedades pré-definidas.
105
( ) Normalmente são utilizados para estender (enriquecer) o significado de 
um determinado elemento em um diagrama.
( ) São utilizadas para comentar ou esclarecer alguma parte do diagrama.
( ) A todo elemento da UML está associado alguma semântica, onde cada 
elemento gráfico possui um significado bem definido que, uma vez entendido, 
fica implícito na utilização do elemento em algum diagrama.
Agora, assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) III – I – II – IV.
b) ( ) I – III – IV – II.
c) ( ) II – IV – I – III.
d) ( ) IV – II – III – I.
106
107
UNIDADE 3
DIAGRAMAS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
A partir desta unidade você será capaz de:
• conhecer as particularidades do Diagrama de Casos de Uso;
• compreender o funcionamento do Diagrama de Classes;
• conhecer sobre o Diagrama de Sequência;
• conhecer a respeito dos demais diagramas existentes para a Programação 
Orientada a Objetos.
Esta unidade de ensino está dividida em quatro tópicos, sendo que no final 
de cada um deles, você encontrará atividades que contribuirão para a apro-
priação dos conteúdos.
TÓPICO 1 – DIAGRAMAS DE CASO DE USO
TÓPICO 2 – DIAGRAMA DE CLASSES
TÓPICO 3 – DIAGRAMAS DE SEQUÊNCIA
TÓPICO 4 – DEMAIS DIAGRAMAS EXISTENTES
108
109
TÓPICO 1
DIAGRAMAS DE CASOS 
DE USO
UNIDADE 3
1 INTRODUÇÃO
Este diagrama tem por objetivo apresentar uma visão externa e geral das 
funções e serviços que o sistema deverá oferecer aos usuários, sem se preocupar 
em como estes serão implementados.
É o mais abstrato e flexível de todos os diagramas da UML. Costuma ser 
utilizado, principalmente, no início da modelagem do sistema, principalmente 
nas etapas de Levantamento e Análise de Requisitos, embora possa ser consultado 
e alterado durante todo o processo de desenvolvimento. 
Vale destacar que “é bastante útil e recomendável que um diagrama de 
Casos de Uso seja apresentado aos clientes juntamente com um protótipo o que 
permitirá que um complemente o outro”. (GUEDES 2007, p. 45).
2 ATORES
De acordo com Guedes (2004, p. 44), “os atores representam os papéis 
desempenhados pelos diversos usuários que poderão utilizar de alguma maneira 
os serviços e funções do sistema”. Em outras palavras, o autor descreve que ator 
é toda pessoa que interage com o sistema indiferente do serviço ou da função 
exercida.
Vale destacar que “um ator pode desempenhar muitos casos de uso; um 
caso de uso pode ter reciprocamente vários atores desempenhando-o”. (FOWLER 
e SCOTT, 2000, p. 52). Observe a figura a seguir e compreenda a função do ator 
no processo.
UNIDADE 3 | DIAGRAMAS
110
FIGURA 64 – SIMBOLOGIA ATOR
FONTE: Disponível em: <http://www.purainfo.com.br/
artigos/o-que-e-uml/>. Acesso em: 12 fev. 2015.
FIGURA 65 – ATOR EM UM CASO DE USO
FONTE: Disponível em: <https://infohades.wordpress.com/2009/12/09/diagrama-de-casos-
de-uso/>. Acesso em: 12 fev. 2015. 
Ator
Recepcionista
Funcionário
do Estoque
Funcionário
do Marketing
Funcionário
da Limpeza
Cliente
Gerenciamento
Promoções
Gerenciamento
Hospedagem
Gerenciamento
Associados
Gerenciamento
Cliente
Gerenciamento
Estoque
Disponibilidade
de Quartos
TÓPICO 1 | DIAGRAMAS DE CASOS DE USO
111
Na figura apresentada, você, acadêmico, pode verificar que a mesma é 
composta por cinco atores (Recepcionista, Funcionário do Estoque, Funcionário 
de Marketing, Funcionário da Limpeza e por fim o Cliente). Neste contexto, cada 
um exerce sua função dentro do sistema com as suas especificidades. 
Vale destacar, neste momento, algumas características específicas de atores: 
determina papéis que são exercidos por pessoas; é um sistema de computação; 
pode ser considerado software, hardware, alguns dispositivos elétricos e até mesmo 
mecânicos.
3 CASO DE USO
Caso de Uso, segundo Guedes(2004, p. 46), “referem-se aos serviços, 
tarefas ou funções que podem ser utilizadas de alguma maneira pelos usuários 
do sistema, como emitir um relatório ou cadastrar a venda de algum produto”. 
Observe a Figura 63 que demonstra esta afirmação.
Já Furlan (1998, p. 170), define caso de uso como um “conjunto de 
sequências de ações que um sistema desempenha para produzir um resultado de 
valor a um ator específico”.
Caro acadêmico(a)! Verifique a figura a seguir e observe como o diagrama 
inicia sua composição, ou seja, demonstra quem é o ator, qual a interação e por 
fim o sistema que é o Caso de Uso.
FIGURA 66 – SIMBOLOGIA CASO DE USO
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/
o-que-e-uml/>. Acesso em: 12 fev. 2015.
FIGURA 67 – INTERAÇÃO ATOR E CASO DE USO
FONTE: Disponível em: <http://pt.slideshare.net/mjovinski/revisao-prova-1bimestre-3-
periodouniao>. Acesso em: 12 fev. 2015.
Manter Clientes
Caso de Uso
Sistema
Interação
Ator
UNIDADE 3 | DIAGRAMAS
112
Veja agora, uma figura que demonstra como ocorre este processo de 
interação entre Ator e Caso de Uso em um diagrama. 
FIGURA 68 – EXEMPLO DE CASOS DE USO
FONTE: Disponível em: <https://code.google.com/p/scmotel/downloads/detail?name=Diagrama%20
d>. Acesso em: 12 fev. 2015.
Analisando as definições apresentadas, observe que a figura é composta 
por três atores, sendo: cliente, atendente e a camareira, cada um destes atores 
realiza determinadas funções, tarefas ou serviços. No caso da camareira, sua 
função, ou seu caso de uso é conferir e realizar o lançamento do consumo, já o 
atendente por sua vez, exerce as funções ou caso de uso de escolher acomodação, 
solicitar fechamento de conta, conferir consumo, conferência, fazer reserva, 
entre outras.
Seu principal objetivo é ser de fácil compreensão para os usuários que 
estão iniciando na informática, auxiliar na tarefa de análise, delimita o sistema, 
entre outros.
Agora, faça uma análise das informações recebidas até o momento. É 
possível perceber que um caso de uso possui um ator que inicia, ou seja, gera 
o estímulo inicial para os demais atores que possam participar desse processo.
Escolher
Acomodação
Solicitar
Fechamento
da Conta
Conferência
Pagar
Fazer Reserva
Confirmar
Consumo
Lançar
Consumo
Cliente
Atendente
Camareira
TÓPICO 1 | DIAGRAMAS DE CASOS DE USO
113
4 DOCUMENTAÇÃO DE CASOS DE USO
Com uma explicação bem simples, Guedes (2004, p. 47) descreve que: 
A documentação de Caso de Uso costuma descrever por meio de uma 
linguagem bastante simples, a função em linhas gerais do Caso de 
Uso, quais Atores interagem com o mesmo, quais etapas devem ser 
executadas pelo Ator e pelo sistema para que o Caso de Uso execute 
sua função, quais parâmetros devem ser fornecidos e quais restrições 
e validações o Caso de Uso deve possuir.
FIGURA 69 – DOCUMENTAÇÃO DE CASO DE USO
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/o-que-e-uml/>. Acesso em: 12 fev. 2015.
Assim, ao analisar o exemplo de Documentação de Caso de Uso, você 
pode verificar quais as funções que serão exercidas pelos atores, quais os atores 
que irão compor este diagrama, quais os dados que devem ser levantados, qual a 
prioridade do sistema, enfim, apresentar a documentação de tudo que consta no 
diagrama para que todos possam compreender, se necessário.
Não existe um modelo padrão de documentação, porém é imprescindível que 
constem todas as informações necessárias no diagrama de Caso de Uso.
IMPORTANT
E
UNIDADE 3 | DIAGRAMAS
114
5 ASSOCIAÇÕES
Como o próprio nome já diz, representam as associações existentes 
entre os atores e os casos de uso que compõem o diagrama. De acordo com as 
informações descritas por Guedes (2004, p. 49),
uma associação entre um Ator e um Caso de Uso demonstra que o Ator 
utiliza-se, de alguma maneira, da função do sistema representada pelo 
Caso de Uso em questão, seja requisitando a execução daquela função, 
seja recebendo o resultado produzido por ela a pedido de outro Ator.
 Observe o exemplo apresentado.
FIGURA 70 – ASSOCIAÇÃO
FONTE: O autor
Observe que a associação existente entre o Ator e o Caso de Uso é 
representada por uma linha reta, em muitos casos podem apresentar setas, 
demonstrando assim a direção do diagrama.
Na continuidade deste tópico, serão apresentados os relacionamentos 
existentes entre o Ator e o Caso de Uso, sendo: Inclusão, Extensão e Generalização, 
os quais serão abordados na sequência.
6 INCLUSÃO
Segundo Fowler e Scott (2000, p. 53), “a associação de Inclusão ocorre 
quando há uma parte do comportamento que é semelhante em mais de um caso 
de uso e você não quer ficar copiando a descrição deste comportamento”. 
Pedir menu
Cliente
TÓPICO 1 | DIAGRAMAS DE CASOS DE USO
115
FIGURA 71 – SIMBOLOGIA INCLUSÃO
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/o-que-
e-uml/>. Acesso em: 13 fev. 2015.
Agora, observe um exemplo que demonstra a forma de utilização desta 
associação.
FIGURA 72 – INCLUSÃO
FONTE: Disponível em: <http://siuvv.rodrigoneto.com/doku.php?id=si_mat_p5_analise_
resumo>. Acesso em: 13 fev. 2015.
No caso da figura apresentada, houve a inclusão por três vezes, afinal, 
todas as funções requerem a mesma solicitação Fornecer Identificação, assim, 
esta rotina foi colocada em um caso de uso específico e todos os demais casos 
de uso podem utilizar-se deste serviço, evitando assim descrever esta rotina de 
passos em vários casos de uso.
7 EXTENSÃO
<<include>>
Obter Extrato
Realizar Saque
Realizar 
Transferência
Fornecer
Identificação
Cliente
<<include>>
<<include>>
<<include>>
Este tipo de associação, chamado de Extensão, é utilizado para descrever 
cenários opcionais de um Caso de Uso. “Os Casos de Uso estendidos descrevem 
cenários que somente ocorrerão em uma situação específica, se uma determinada 
condição for satisfeita”. (GUEDES, 2004, p. 52).
UNIDADE 3 | DIAGRAMAS
116
Fowler e Scott (2000, p. 54) afirmam que por meio desta construção, “o 
caso de uso estendido pode acrescentar comportamentos para o caso de uso-
base, mas este tipo de caso deve declarar certos ‘pontos de extensão’, e o caso de 
extensão pode acrescentar comportamento adicional somente naqueles pontos de 
extensão”, veja o exemplo.
FIGURA 73 – SIMBOLOGIA EXTENSÃO
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/o-que-e-
uml/>. Acesso em: 13 fev. 2015.
Agora, observe um exemplo que demonstra a forma de utilização desta 
associação.
FIGURA 74 – EXEMPLO DE EXTENSÃO
FONTE: Disponível em: <http://www.macoratti.net/11/09/net_ioop.htm>. Acesso em: 17 
fev. 2015.
Observe um exemplo que demonstra a interação entre os casos de uso e a 
utilização das associações inclusão e extensão.
<<extends>>
<<extends>>
<<extends>>
Editar Documento
Escritor
Substituir Texto
Corrigir
Ortografia
TÓPICO 1 | DIAGRAMAS DE CASOS DE USO
117
FIGURA 75 – ASSOCIAÇÃO INCLUSÃO / EXTENSÃO
FONTE: Disponível em: <http://wthreex.com/rup/portugues/process/modguide/md_bucm.
htm>. Acesso em: 17 fev. 2015.
8 ESPECIALIZAÇÃO/ GENERALIZAÇÃO
De uma forma geral, Angelantonio Jr (2013) descreve que a palavra 
generalização possui o conceito de agrupar, associar indivíduos que possuem 
atributos comuns, onde suas diferenças são desprezadas.
Em Especialização/Generalização Guedes (2004, p. 50) descreve que este 
tipo de relacionamento é uma forma de Associação entre Casos de Uso na qual 
existem dois ou mais Casos de Uso com características semelhantes, apresentando 
pequenas diferenças entre si. 
Vale lembrar que quando esta situação ocorre, costuma-se definir um Caso 
de Uso Geral que descreve as características compartilhadas por todos os Casos 
de Uso em questão e então relacioná-los com os outros Casos de Uso envolvidos, 
cuja documentação conterá somente as características específicas de cada um.
Passageiro
Guia Turístico Check-In de Grupo
Através de Check-In
<<estender>>
<<incluir>>
<<incluir>>
Check-In 
Individual
Administração 
de Bagagens
UNIDADE 3 | DIAGRAMAS
118
FIGURA 76 – SIMBOLOGIADE GENERALIZAÇÃO
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/o-que-e-uml/>. 
Acesso em: 17 fev. 2015.
FIGURA 77 – ESPECIALIZAÇÃO/ GENERALIZAÇÃO
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/modguide/
md_ucgen.htm>. Acesso em: 17 fev. 2015.
Observe o exemplo apresentado, as setas que demonstram a especialização/
generalização são apresentas no sentido do Caso de Uso especializado para o 
Caso de Uso Geral, ou seja, tanto o Pedido por Telefone como o Pedido pela 
Internet são demonstrados como especialização/generalização do Caso de Uso – 
Fazer Pedido. 
Fazer Pedido
Cliente Cliente de Internet
Pedido pela InternetPedido por Telefone
TÓPICO 1 | DIAGRAMAS DE CASOS DE USO
119
FIGURA 78 – ESPECIALIZAÇÃO/GENERALIZAÇÃO DO CASO DE USO
FONTE: Disponível em: <http://jkolb.com.br/especializacaogeneralizacao-
classes/>. Acesso em: 17 fev. 2015.
O mesmo ocorre com o exemplo de Caso de Uso Geral Pessoa, tanto Física 
como Jurídica são especialização de Pessoa.
9 EXEMPLOS DE DIAGRAMA DE CASOS DE USO
1. CONTROLE DE TAREFAS 
Arnaldo deseja escrever uma aplicação de controle de tarefas para 
colocar em seu Smartphone. As especificações da aplicação são as seguintes: 
O cadastro de cada tarefa contém o número da prioridade, representado 
por um valor real. Isso permite entrar com intervalos intermediários. 
Além da prioridade, o cadastro deve conter: o nome da tarefa, a data 
limite de execução (se houver), o percentual já concluído e o detalhamento 
da tarefa. Para cada tarefa há uma lista de itens que descrevem sua execução. 
Para cada item de execução, cadastram-se: 
• O percentual correspondente 
• A descrição da execução 
• A data da execução (quando for concluída) Quando uma tarefa receber 
100% de execução, esta deve ser movida automaticamente para a lista de 
tarefas concluídas, podendo ser apagada, se for o caso (MELO, 2006, p. 25).
Pessoa Física Pessoa Jurídica
Pessoa
UNIDADE 3 | DIAGRAMAS
120
1. LIGAÇÕES TELEFÔNICAS VIA MODEM
Bruna resolveu desenvolver uma aplicação para controlar as ligações 
telefônicas de sua casa, a fim de checar se o valor que paga mensalmente 
está correto. Assim, sempre que desejar, poderá listar as ligações efetuadas 
num determinado período, contabilizando o valor a pagar. Para que isso 
seja possível, toda ligação será feita pelo computador. A cada solicitação de 
ligação, a aplicação deverá registrar: a data da ligação, a hora da ligação, 
quantidade de minutos gastos (que deve ser registrado no momento que 
a ligação for encerrada), o número de pulsos (que deve ser calculado pela 
aplicação) e o telefone para onde se discou. A aplicação permitirá o controle 
de uma agenda de telefones, com número do telefone e o nome da pessoa de 
contato. O usuário poderá escolher, no momento da ligação, se deseja um 
dos registros da agenda ou se digitará diretamente o número do telefone. 
A forma de cálculo dos pulsos considera os seguintes critérios:
• A ligação ao ser completada já conta um pulso. A partir daí, a cada 4 
minutos de conversação concluída, cobra-se mais 1 pulso. 
• Cada pulso custa R$ 0.08 para ligações locais. 
• Os finais de semana possuem uma promoção: cada ligação contabiliza 
somente 1 pulso, independente do número de minutos de conversação.
Pessoa
<<extends>>
<<extends>>
Manter Tarefa
Manter Itens 
da Tarefa
Verificar 
Conclusão da 
Tarefa
TÓPICO 1 | DIAGRAMAS DE CASOS DE USO
121
FONTE: Disponível em: <http://ricardosantos.net/arquivos/UML1.pdf>. Acesso em: 17 fev. 2015
Pessoa
include
include
Listar ligações 
de um período
Manter agenda 
de telefone
Efetuar ligação 
telefônica
Calcular 
pulsos
Cadastrar valores 
variáveis para 
regra de cálculo
Resolução:
122
RESUMO DO TÓPICO 1
Neste tópico foram apresentas características de um dos diagramas mais 
utilizados da notação UML.
Estudamos os seus principais componentes, quando de sua utilização e 
estruturação.
Vimos que este diagrama tem por objetivo apresentar uma visão geral das 
funções e serviços do sistema que será desenvolvido.
Foram apresentados alguns exemplos, onde por meio deles você pode 
ter uma noção de sua construção e ao mesmo tempo aproveitá-los para o 
desenvolvimento de suas autoatividades.
Bom estudo!
123
Com base nas informações recebidas no decorrer deste tópico, desenhe o 
diagrama de Caso de Uso, para os exercícios a seguir:
1. OGO DE FORCA 
Cristina quer fazer um jogo da forca em computador para os seus filhos e 
sobrinhos. Os requisitos para o jogo estão a seguir: 
• O jogo consiste em se tentar acertar as letras de uma palavra escondida. Se 
o jogador errar a letra, surge mais um pedaço de um boneco que ao final irá 
para a forca. 
• As palavras ou frases para cada rodada são obtidas de um banco de palavras 
e frases, que o próprio jogador pode incrementar. 
• Cada palavra ou frase pertence a um tema. 
• A cada rodada, a aplicação sorteia se mostrará uma, duas ou três palavras, 
ou uma frase e escolhe aleatoriamente o tema e as palavras (ou frases). 
• A palavra (ou frase) é exibida, escondida e cada letra acertada desvenda sua 
posição correspondente. 
• Letras erradas são colocadas num quadro e um dos pedaços do boneco 
aparece. 
• O nome do jogador é guardado com seus pontos para fazer parte do quadro 
de maiores escores. Quando ele acerta a palavra, ganha 100 pontos e, para a 
letra que ficou encoberta, somam-se mais 15 pontos. MELO (2006, p. 43).
2. CLUBE DA LEITURA 
Gustavo tem uma coleção grande de revistas em quadrinhos. Por isso, resolveu 
emprestá-la para os amigos. Assim foi criado o Clube da Leitura. Mas para 
não perder nenhuma revista, seu pai lhe fez uma aplicação que cadastra as 
revistas e controla o empréstimo. 
Para cada revista, cadastram-se: o tipo de coleção, o número da edição, o ano 
da revista e a caixa onde está guardada. Cada caixa tem uma cor, uma etiqueta 
e um número. 
Para cada empréstimo cadastram-se: o amiguinho que pegou a revista, qual 
foi a revista, a data do empréstimo e a data de devolução. Cada criança só 
pode pegar uma revista por empréstimo.
O cadastro do amiguinho consiste de: nome, nome do responsável, telefone e 
de onde é o amigo. MELO (2006, p. 48).
3. Condomínio
Marina é síndica do prédio onde mora. A fim de melhor gerenciar o 
condomínio, ela encomendou uma aplicação a um amigo.
A aplicação deve atender aos seguintes requisitos:
AUTOATIVIDADE
124
1º Para um apartamento devem-se cadastrar: seu número de porta, a 
quantidade de quartos, o tipo de ocupação (proprietário, inquilino ou vazio), 
o nome do proprietário e o telefone do proprietário. Um proprietário pode ter 
mais de um apartamento no prédio.
2º Mensalmente devem ser lançadas as despesas para o condomínio do 
mês, além das despesas específicas de um apartamento ou um grupo de 
apartamentos, como por exemplo: a taxa de salão de festas.
3º O condomínio é calculado por tipo de apartamento (de acordo com o 
número de quartos). Para chegar ao valor pago pelas despesas, têm-se os 
seguintes passos:
a) Verificar o somatório de quartos de todo o prédio.
Ex.: apto 101 (2 quartos); 102 (3 quartos); 201 (2 quartos); 202 (3 quartos) = total 
de quartos = 10
b) Dividir o valor da despesa (que pode ser fixo, como fundo de reserva; ou 
variável, como água) pelo somatório de quartos e multiplicar o resultado pelo 
número de quartos do apartamento.
Ex.: água - 200,00 
Apto 101 200,00/10x2= 40,00
102 200,00/10x3= 60,00
201 200,00/10x2= 40,00
202 0,00/10x3= 60,00
4º Para cada item do condomínio cadastra-se a referência (ex.: mar/05 - 
referente ao mês da conta; 1/3 - fator de parcelamento).
5º O condomínio é pago diretamente com a Síndica. Se for pago com atraso, 
cobra-se multa de 2%. O condômino pode optar em pagar a multa no mês 
seguinte. Nesse caso, o percentual passa para 5% e é lançada como despesa 
do próximo condomínio.
Completa-se, então, para o cadastro de cada condomínio de apartamento, a 
data do pagamento e o valor pago.
125
TÓPICO 2
DIAGRAMA DE CLASSES
UNIDADE 3
1 INTRODUÇÃOEste diagrama apresenta uma visão de como as classes serão organizadas 
e preocupa-se em definir a sua estrutura lógica.
O diagrama de Classes é composto pelas classes que formam o sistema 
e suas associações ou relacionamentos. Neste diagrama temos a abstração das 
classes com seus atributos e métodos. “O diagrama de classes serve ainda como 
base para a construção da maioria dos outros diagramas da linguagem UML”. 
(GUEDES, 2007, p. 45).
2 CLASSES, ATRIBUTOS E MÉTODOS
Com relação às Classes, podemos considerá-las como todo e qualquer 
conjunto de objetos que possuem as mesmas definições tanto para os atributos 
quanto para os métodos, ou seja, possuem características e comportamentos 
comuns (FARINELLI, 2007).
Santos (2009), em seu estudo, descreve que classe é um conjunto de 
objetos com propriedades e comportamentos semelhantes e com relacionamentos 
comuns com outros objetos. Desta forma, as classes são as partes mais importantes 
de qualquer sistema orientado a objetos. Usam-se as classes para capturar o 
vocabulário do sistema que está em desenvolvimento. Essas classes podem 
incluir abstrações que são parte do domínio do problema, assim como as classes 
que fazem uma implementação. Podemos usar ainda as classes para representar 
itens de software, de hardware e até itens que sejam somente conceituais. Exemplo: 
A classe Pessoa deverá ter atributos e métodos comuns.
126
UNIDADE 3 | DIAGRAMAS
FIGURA 79 – CLASSE 
FONTE: Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376>. Acesso em: 17 fev. 2015.
Para uma melhor compreensão, observe este exemplo da Classe Pessoa, 
utilizando a notação UML. Lembre-se de que esta é uma Classe Concreta.
FIGURA 80 – CLASSE PESSOA
FONTE: Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376>. Acesso em: 17 fev. 2015
Para determinar o nome da Classe utilize sempre um substantivo, afinal é 
considerado o identificador desta classe: Pessoa, Produto, Carro, entre outros.
IMPORTANT
E
Pessoa
Nome
Idade
GetNome
GetIdade
Nome da Classe
Atributos
Métodos
TÓPICO 2 | DIAGRAMA DE CLASSES
127
Agora que você compreendeu o significado da Classe, vamos iniciar 
nossos estudos acerca dos componentes desta classe, ou seja, você sabe o que é 
MÉTODO?
Métodos são procedimentos ou funções que realizam as ações próprias 
do objeto. Assim, os métodos são as ações que um objeto pode realizar. Tudo 
que o objeto faz é realizado através de seus métodos, afinal é por meio destes 
métodos que um objeto se manifesta e até mesmo interage com os outros objetos 
(FARINELLI, 2007). Em outras palavras, métodos nada mais são do que os 
componentes de um objeto, ou as funções que o mesmo exerce.
Desta forma, agora que você já sabe seu conceito, demonstramos como 
ocorre a declaração por meio da UML.
• Modificador de acesso – public, private
• Tipo de Retorno – void, int, double etc.
• Nome que indica o método
• Parênteses – apresenta a lista de argumentos
• { } – descreve o corpo do método
FONTE: Disponível em: <http://slideplayer.com.br/slide/397636/. Acesso em: 17 fev. 2015.
Agora, verifique o exemplo para uma completa compreensão destes itens:
FONTE: Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376>. 
128
UNIDADE 3 | DIAGRAMAS
Exemplo de Método
FONTE: Disponível em: <http://pt.slideshare.net/ludimila_monjardim/poo-03fundamentos-
java>. Acesso em: 17 fev. 2015.
Agora, chegou o momento de finalizar este item. Assim verifique como 
procedemos em relação ao Atributo. Você sabe o que é um Atributo?
Atributo na visão de Guedes (2004) representa as características de uma 
classe, ou seja, as peculiaridades que costumam variar de objeto para objeto, 
como a altura em um objeto da classe Pessoa ou a Cor em um objeto da classe 
Carros e que permitem diferenciar um objeto de outro da mesma classe devido a 
essas variações.
É importante destacar que os atributos de um objeto sofrem alterações de 
valor por meio de estímulos internos ou externos, por exemplo: o endereço de sua 
residência pode sofrer alterações, uma vez que o indivíduo more de aluguel, ou 
até mesmo por ter adquirido um novo lar.
De acordo com Correia e Tafner (2001, p. 16), “cada objeto é responsável 
pela mudança de seu próprio atributo e mais nenhum outro”.
Assim, você, acadêmico, pode observar que existe certa independência de 
cada objeto com relação aos outros, desta forma permite-se certa liberdade em 
suas modificações, sem medo de interferir internamente nos outros objetos.
Os métodos, por sua vez, são procedimentos ou funções que realizam as 
ações próprias do objeto. Assim, os métodos são as ações que um objeto pode 
realizar. Tudo que o objeto faz é realizado através de seus métodos, afinal é por 
meio destes métodos que um objeto se manifesta e até mesmo interage com os 
outros objetos (FARINELLI, 2007).
TÓPICO 2 | DIAGRAMA DE CLASSES
129
Segundo Santos (2009), os atributos são pertencentes à classe, eles podem 
ser do tipo primitivo ou referência (objetos), e seus modificadores podem ser: 
public, private, protected ou default. Vale destacar que o ciclo de vida destes atributos 
está vinculado ao ciclo de vida da classe Variáveis Locais, as quais são definidas 
dentro dos métodos. Elas têm um ciclo de vida vinculado ao ciclo dos métodos, 
também chamadas de Variáveis Temporárias.
FIGURA 81 – MÉTODO
FONTE: Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376>. Acesso em: 17 fev. 2015.
3 ABSTRAÇÃO
Segundo Ambler (1998, p. 6), “o mundo é um lugar complexo”. Para 
que consigamos lidar com esta complexidade, formamos generalizações, ou 
abstrações das coisas existentes nele. 
public class Disciplina {
 private int cargaHoraria;
 private String nome;
 public Disciplina(String nome, int
 cargaHoraria){
 this .nome = nome;
 this .cargaHoraria =
 
calcCargaHoraria(cargaHoraria);
 }
 public String getNome( ){
 return nome;
 }
 public int getCargaHoraria( ){
 return CargaHoraria;
 }
 public int calcCargaHoraria(int
 qdeHoras)}
 int horasPlanejamento = (int)
 ( qdeHoras * 0,1);
 return CargaHoraria =
 horasPlanejamento + qdeHoras;
 }
}
Atributos
Modificador
Variáveis
temporárias
130
UNIDADE 3 | DIAGRAMAS
Possuímos o recurso de abstração como forma de entender problemas 
tidos como complexos. Assim, diante de um problema complexo, 
procura-se dividi-lo em problemas menores, e feito isso, resolvemos 
cada um deles até encontrar a solução do problema inteiro. [...] 
O uso da abstração permite também que determinadas partes do 
problema ganhem maior ou menor peso, assim, detalhes podem ser 
desconsiderados em determinados momentos para que outros sejam 
ressaltados. (FARINELLI, 2007, p. 16).
FIGURA 82 – ABSTRAÇÃO
FONTE: Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376>. Acesso em: 17 fev. 2015.
4 ENCAPSULAMENTO
Para que você, acadêmico, compreenda a definição de Encapsulamento, 
Farinelli (2007), em seu estudo, descreve que encapsulamento é o princípio de 
projeto pelo qual cada componente de um programa deve agregar toda informação 
relevante para sua manipulação como uma unidade (uma cápsula).
Neste momento, vale destacar que o mais importante é que ocorra 
interação entre dois objetos, porém é necessário que cada um saiba da totalidade 
de operações disponíveis pelo seguinte objeto, somente assim poderá enviar e 
receber as informações necessárias, ou possa ordenar a realização de determinados 
procedimentos. Para uma melhor compreensão deste assunto, peço que você 
observe a Figura 83.
TÓPICO 2 | DIAGRAMA DE CLASSES
131
FIGURA 83 – ENCAPSULAMENTO
FONTE: Disponível em: <http://java-famesul.blogspot.com.br/2010/09/encapsulamento.html>. 
Acesso em: 17 fev. 2015.
Verifique agora como fica a Classe Pessoa utilizando o encapsulamento.
Pessoa.java 
public class Pessoa{
 private String nome;
 private String sobrenome;
 private String dataNasc;
 private String rg;
 private String[] telefones;
 
 public String getNome(){
 return nome;
 }
Operações/métodos/interfacepública
Dados/Atributos/propriedades
privada
Classe Empregado e método
getSalario
O atributo salario
O atributo salario somente poderá ter
um valor atribuído ou alterado,
através de método público.
Através do método getSalario, que
tem modificador public, podemos
manipular ou recuperar o valor do
atributo salario.
public class Empregado {
public Empregado( ){
public double getsalario( ){
salario=0,00;
return this.salario;
}
}
}
private double salario;
132
UNIDADE 3 | DIAGRAMAS
 public void setNome(String n){
 nome = n;
 }
 public String getSobrenome(){
 return sobrenome;
 }
 public void setSobrenome(String s){
 sobrenome = s;
 }
 public String getDataNasc(){
 return dataNasc;
 }
 public void setDataNasc(String d){
 dataNasc = d;
 }
 public String getRg(){
 return rg;
 }
 public void setRg(String r){
 r = rg;
 }
 public String getTelefones(){
 return telefones;
 }
 public void setTelefones(String[] telefones){
 telefones[] = telefones;
 }
}
FONTE: Disponível em: <http://www.devmedia.com.br/classes-abstratas-e-encapsulamento/7515>. 
Acesso em: 17 fev. 2015.
TÓPICO 2 | DIAGRAMA DE CLASSES
133
4.1 HIERARQUIA DAS CLASSES
Conforme o Dicionário da Língua Portuguesa Aurélio (2015), hierarquia 
significa: Classificação ou ordenação segundo determinados critérios; Classe; 
Categoria; entre outras definições.
Assim, nos exemplos apresentados até agora, você poderá verificar que 
representam duas classes distintas, cada uma com suas características, suas 
especificidades, porém na hierarquia das classes, ambos pertencem à mesma 
classe, a dos Mamíferos. Observe esta representação na Figura 84.
FIGURA 84 – HIERARQUIA DAS CLASSES
FONTE: Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376>. Acesso em: 17 fev. 2015.
Segundo Farinelli (2007), as classes são definições de como os objetos 
devem ser e não existem na realidade, sendo assim, somente os objetos tem 
existência.
Para finalizar o pensamento acerca da hierarquia das classes, vale destacar 
que são chamadas de “ancestrais” as classes de que as demais dependem e 
“descendentes” as classes originadas a partir de outra.
5 HERANÇA
Segundo Guedes (2004, p. 41), o conceito de Herança trabalha com o 
conceito de superclasses e subclasses. Uma superclasse, também chamada de 
classe-mãe, é uma classe que possui classes derivadas a partir dela, chamadas 
de subclasses, também conhecidas como classes-filha. As subclasses, ao serem 
derivadas a partir de uma superclasse, herdam suas características, ou seja, 
seus atributos e métodos.
SuperClasse
SubClasses
Pessoa
Terceiro
Professor
Autônomo Professor
Pessoal
Operacional
Pessoal
Administrativo
Aluno Funcionário
134
UNIDADE 3 | DIAGRAMAS
Já Santos (2009) descreve que herança é o mecanismo pelo qual 
elementos mais específicos incorporam a estrutura e o comportamento de 
elementos mais gerais. Assim, uma classe derivada herda a estrutura de 
dados e métodos de sua classe “base”, mas pode seletivamente adicionar 
novos métodos, estender a estrutura de dados, redefinir a implementação de 
métodos já existentes.
Em outras palavras, herança é o que se herda, um bom exemplo é a 
herança hereditária, ou seja, a filha herda características tanto da mãe quanto 
do pai. A vantagem de utilização da herança é simples, ao cadastrar uma 
classe com atributos e métodos definidos, derivando uma subclasse a partir 
da classe já criada, não há necessidade de cadastrar os atributos e os métodos 
novamente, a subclasse herda automaticamente, permitindo assim a utilização 
de um código já pronto. 
Uma subclasse herda atributos e comportamento de sua classe imediatamente 
superior à superclasse, e também possui atributos e operações específicas dela mesma. 
(SANTOS, 2009).
IMPORTANT
E
TÓPICO 2 | DIAGRAMA DE CLASSES
135
FIGURA 85 – EXEMPLO DE HERANÇA (IMPLEMENTAÇÃO – PESSOA, ALUNO, TERCEIRO, 
FUNCIONÁRIO)
FONTE: Disponível em: <http://java-famesul.blogspot.com.br/2010/09/heranca.html>. Acesso 
em: 15 fev. 2015.
5.1 HERANÇA MÚLTIPLA
No caso da Herança Múltipla, ela é assim denominada pelo fato de herdar 
suas características ou ações, ou seja, seus atributos e seus métodos de duas ou 
mais superclasses. No exemplo apresentado na Figura 86, você pode observar 
que a classe Gerente-Vendas, herda características tanto da superclasse Vendedor 
quanto da superclasse Gerente, criando assim uma nova classe.
O diferencial da herança múltipla está no fato da nova classe herdar as 
características de duas superclasses, porém nada impede que tenha atributos 
próprios.
public abstract class Pessoa {
 protected String idPessoa;
 protected int idade;
 protected String nome;
 public Pessoa(String nome)
 {
 this.nome = nome;
 }
 public abstract String getNome( );
 public void setidPessoa( )
 { }
 public abstract int getIdade( );
 public void setIdade(int idade)
 { }
}
Professor
Autônomo
Pessoal
Operacional
public class Terceiro extends Pessoa{
 private int codigoTerceiro;
 public Terceiro(String nome)
 {
 super(nome);
 }
 public int getIdade( )
 {
 return ( );
 }
 public String getNome( )
 {
 return " ":
 };
}
public class Funcionario extends Pessoa{
 private int codigofuncionario;
 public Funcionario(String nome)
 {
 super(nome);
 }
 public int getIdade( )
 {
 return ( );
 }
 public String getNome( )
 {
 return " ":
 };
}
public class Aluno extends Pessoa{
 public Aluno(String nome)
 {
 super(nome);
 }
 public int getIdade( )
 {
 return ( );
 }
 public String getNome( )
 {
 return " ":
 };
}
Professor PessoalAdministrativo
136
UNIDADE 3 | DIAGRAMAS
FIGURA 86 – HERANÇA MÚLTIPLA
FONTE: Disponível em: <http://www.devmedia.com.br/heranca-teoria-e-pratica/5274>. Acesso 
em: 15 fev. 2015.
Observe outro exemplo:
Exemplo> Implementação da classe Pessoa, Pessoa Física e a Pessoa 
Jurídica e a interface Mamífero.
FIGURA 87 – IMPLEMENTAÇÃO DE CLASSES
FONTE: O Autor
Pessoa
Empregado
Vendedor Gerente
Gerente - Vendas
Estudante
public abstract class Pessoa {
 protected String idPessoa;
 protected int idade;
 protected String nome;
 
 public Pessoa(String nome)
 {
 this.nome = nome;
 }
 public abstract String getNome( );
 public abstract int getIdade( );
 public void setIdade(int idade){ }
}
public interface Mamifero {
 final int qdeOlhos=2;
 
 public int getQdepernas( );
}
public class PessoaFisicaI extends Pessoa{
 implements Mamifero;
 public PessoaFisica(String nome)
 {
 super(nome);
 }
 public int getQdepernas( ){
 return 2;}
 public String getNome( ){
 return " ";}
 public int getIdade( ){
 return 0:}
}
public class PessoaJuridicaI extends Pessoa{
{
 public PessoaJuridica(String nome)
 {
 super(nome);
 }
 public int getIdade( )
 {
 return ( );
 }
 public String getNome( )
 {
 return " ";
 }:
}
implements extends
extends
TÓPICO 2 | DIAGRAMA DE CLASSES
137
6 CLASSE ASSOCIATIVA
Segundo Guedes (2004, p. 83), “classes associativas nada mais são do 
que as classes produzidas quando da ocorrência de associações que possuem 
multiplicidade muitos (*) em todas as suas extremidades”. 
O autor descreve ainda que estas classes associativas são necessárias nesses 
casos porque não existe um repositório que possa armazenar as informações 
produzidas pelas associações já que todas as classes envolvidas apresentam 
multiplicidade e isto obriga que seu atributo-chave seja transmitido às outras 
classes envolvidas e como todas possuem a mesma multiplicidade, nenhuma 
delas pode receber os atributos das outras, assim é preciso criar uma classe 
associativa para armazenar os atributos transmitidos pela associação, o que não 
impede que a classe associativa possua atributos próprios, além dos recebidos.
Em outras palavras, este tipo de classe pode armazenar as informações 
produzidas por ela ou produzidaspelas classes nas quais possui associação, pode 
também receber atributos das classes associativas, porém pode possuir atributos 
próprios.
Veja na tabela, a seguir, as instruções para utilização das multiplicidades 
das classes associativas.
• Herança – Permite que tiremos vantagem das similaridades entre as classes 
representando relacionamentos do tipo “é” ou “é semelhante”.
• Superclasse – Quando a classe “B” herda as características da classe “A” dizemos que “A” é 
uma superclasse de “B”.
• Subclasse – Quando a classe “B” herda características da classe “A” dizemos que “B” é uma 
subclasse de “A”.
• Herança Simples – Quando a classe herda características de uma única classe dizemos 
que ocorre uma herança simples.
• Herança Múltipla – Quando uma classe herda características de mais de uma classe 
dizemos que ocorre uma herança múltipla. Repare que nem todas linguagens Orientadas a 
Objeto suportam herança múltipla. (AMBLER, 1998, p. 9).
IMPORTANT
E
138
UNIDADE 3 | DIAGRAMAS
TABELA 1 – MULTIPLICIDADE DAS CLASSES ASSOCIATIVAS
FONTE: Disponível em: <http://slideplayer.com.br/slide/364427/>. Acesso em: 15 fev. 2015.
Agora, veja dois exemplos de como as classes associativas são apresentadas 
dentro do processo de Diagrama de Classes.
FIGURA 88 – DIAGRAMA DE CLASSES 1
FONTE: Disponível em: <http://hugohabbema.blogspot.com.br/2009/08/o-diagrama-de-
classes.html>. Acesso em: 12 fev. 2015.
FIGURA 89 – DIAGRAMA DE CLASSES 2
FONTE: Disponível em: <http://jkolb.com.br/classe-associativa/>. Acesso em: 12 fev. 2015.
Multiplicidade Significado
0..1 No mínimo zero e no máximo um. Indica que os objetos das 
classes não precisam obrigatóriamente estar relacionados mas, 
se houver, apenas uma instância da classe se relaciona.
1..1 Um e somente um. Indica que apenas um objeto da classe se 
relaciona com a outra classe.
0..* No mínimo nenhum e no máximo múitos. Indica que pode ou 
não haver instâncias da classe participante do relacionamento.
* Muitos. Indica que muitos objetos da classe estão envolvidos.
1..* No mínimo um e no máximo muitos. Indica que há pelo menos 
um objeto envolvido no relacionamento, podendo haver muitos.
3..5 No mínimo três e no máximo cinco.
Aluno
- nome: chair
-dtNascimento: char
Turma
- nome: chair
-dtNascimento: char
AlunoTurma
- sala : int
Aluno
1..* 1..*
Turma
Artigo
- TitArtigo: Character
-dtNascimento: char
*Registrar ( ): void
*Consultar ( ): void
Autor
- NomeAutor: Character
- EndAutor: Character
- TelAutor: Character
- EmailAutor: Character
*Registrar ( ): integer
*Consultar ( ): integer
Escreve
1..* 1..*
Escreve
TÓPICO 2 | DIAGRAMA DE CLASSES
139
7 RESTRIÇÃO
FIGURA 90 – RESTRIÇÕES
FONTE: Disponível em: <http://slideplayer.com.br/slide/364427/>. Acesso em: 12 fev. 2015.
8 PERSISTÊNCIA
Novamente há necessidade de recorrer ao dicionário da Língua Portuguesa 
Aurélio (2015) e verificar a definição de persistência, que pode ser encontrada 
como: Ação ou efeito de persistir; Qualidade do que dura; que persiste.
Já com relação à persistência de um objeto na programação orientada a 
objeto, este se refere ao tempo em que um objeto se mantém na memória, seja ela 
a memória principal (RAM) ou auxiliar (Meio magnético).
Para que um objeto se torne persistente, o mesmo deve ser salvo em algum 
meio de armazenamento (disco rígido). Quando se refere a salvar um objeto, usa-
se o termo gravar, em mídia qualquer, o valor que estes atributos possuem e as 
informações que são necessárias para a manutenção deste objeto com os demais.
Vale destacar que dados persistentes consistem nos bancos de dados 
compartilhados, acessados e atualizados através de transações. Por exemplo, 
banco de dados pessoais, banco de dados de inventário e banco de dados de 
vendedores, todos contêm dados persistentes.
“Restrições constituem-se em informações extras que definem condições a 
serem validadas durante a implementação dos relacionamentos entre as classes”. 
(GUEDES, 2004, p. 84). Na verdade, as restrições podem ser utilizadas na maioria 
dos diagramas UML, no entanto, são mais comumente encontradas no Diagrama 
de Classes. 
Observe que as restrições são apresentadas por textos que se encontram 
entre chaves no Diagrama de Classes, veja o exemplo.
Artigo
- attribute0: int
- attribute1: int
+ operation0( ): void
+ operation1( ): void
Autor
- attribute2: int
- attribute3: int
+ operation2( ): void
+ operation3( ): void
1..* 1..*
Escreve
{O autor deve ser brasileiro}
140
UNIDADE 3 | DIAGRAMAS
Os dados podem ser Persistentes ou Transientes. 
Dados Persistentes são armazenados fora do contexto do programa, 
existem mesmo quando o programa for fechado e podem ser 
recuperados a qualquer momento. Dados Transientes são dados 
que são válidos apenas dentro do programa ou transação. Quando 
o programa é fechado ou a transação termina os dados se perdem 
(LARMAN, 2004, p. 522).
9 EXEMPLOS DE DIAGRAMAS DE CLASSES
1º Exemplo – Diagrama de Classe – Consultório Médico
FONTE: Disponível em: <http://www.macoratti.net/net_uml1.htm>. Acesso em: 12 fev. 2015.
nome
rg
endereço
telefone
data de nascimento
profissão
medida preventiva
tipo de exame
VerificarPascienteCadastrado( )
AdicionarPaciente( )
ObterPaciente( )
ObterConsulta( )
AdicionarConsulta( )
LocalizarPaciente( )
CadastrarPaciente( )
Paciente
marcada
em
consulta
0..n
0..n 0..n 0..1 1..n
1
é formada por
realiza
Agenda
ano
AbrirAgenda( )
ResgatarAgendaDia( )
ResgatarAgenda2Dia( )
ResgatarAgendaSemana( )
Serviço
descrição
preço
RegistrarServiço( )
RecuperarServiço( )
Consulta
histórico
RegistrarConsulta( )
RecuperarHistoricoConsulta( )
Horário
data
hora
ObterHorariosDisponiveis( )
AlterarDisponibilidadeHorario( )
Limpeza/Restauração
material usado
dente tratado
Exame
TÓPICO 2 | DIAGRAMA DE CLASSES
141
2º Exemplo – Diagrama de Classes – Estoque
FONTE: Disponível em: <http://www.dee.ufma.br/pub/UML/Livraria/DiClaEstoque.html>. 
Acesso em: 12 fev. 2015. 
3º Exemplo – Programa Videolocadora
O Programa Original
• O programa é simples: ele calcula e emite um extrato de um cliente numa 
videolocadora.
• Vamos executar o programa para ver uma saída possível:
C:\...\locadora-v1>java Locadora
Registro de Aluguéis de Juliana
 
O Exorcista 3.5
Men in Black 2.0
Jurassic Park III 9.0
Planeta dos Macacos 12.0
Pateta no Planeta dos Macacos 12.0
O Rei Leão 42.0
Valor total devido: 80.5
Você acumulou 8 pontos de alugador frequente
Eis o diagrama UML das classes principais
142
UNIDADE 3 | DIAGRAMAS
• A classe Fita é usada apenas para conter os atributos (locadora-v1\Fita.java)
public class Fita {
 public static final int NORMAL = 0;
 public static final int LANÇAMENTO = 1;
 public static final int INFANTIL = 2;
 private String título;
 private int códigoDePreço;
 public Fita(String título, int códigoDePreço) {
 this.título = título;
 this.códigoDePreço = códigoDePreço;
 }
 public String getTítulo() {
 return título;
 }
 public int getCódigoDePreço() {
 return códigoDePreço;
 }
TÓPICO 2 | DIAGRAMA DE CLASSES
143
 public void setCódigoDePreço(int códigoDePreço) {
 this.códigoDePreço = códigoDePreço;
 }
}
• A classe Aluguel representa o aluguel de uma fita por certo número de dias 
(locadora-v1\Aluguel.java)
public class Aluguel {
 private Fita fita;
 private int diasAlugada;
 public Aluguel(Fita fita, int diasAlugada) {
 this.fita = fita;
 this.diasAlugada = diasAlugada;
 }
 public Fita getFita() {
 return fita;
 }
 public int getDiasAlugada() {
 return diasAlugada;
 }
}
• A classe Cliente representa um freguês da locadora de vídeo (locadora-v1\
Cliente.java)
import java.util.*;
public class Cliente {
144
UNIDADE 3 | DIAGRAMAS
 private String nome;
 private Collection fitasAlugadas = new Vector();
 public Cliente(String nome) {
 this.nome = nome;
 }
 public String getNome() {
 return nome;
 }
 public void adicionaAluguel(Aluguelaluguel) {
 fitasAlugadas.add(aluguel);
 }
 public String extrato() {
 final String fimDeLinha = System.getProperty("line.separator");
 double valorTotal = 0.0;
 int pontosDeAlugadorFrequente = 0;
 Iterator alugueis = fitasAlugadas.iterator();
 String resultado = "Registro de Alugueis de " + getNome() + fimDeLinha;
 while(alugueis.hasNext()) {
 double valorCorrente = 0.0;
 Aluguel cada = (Aluguel)alugueis.next();
 // determina valores para cada linha
 switch(cada.getFita().getCódigoDePreço()) {
 case Fita.NORMAL:
 valorCorrente += 2;
TÓPICO 2 | DIAGRAMA DE CLASSES
145
 if(cada.getDiasAlugada() > 2) {
 valorCorrente += (cada.getDiasAlugada() - 2) * 1.5;
 }
 break;
 case Fita.LANÇAMENTO:
 valorCorrente += cada.getDiasAlugada() * 3;
 break;
 case Fita.INFANTIL:
 valorCorrente += 1.5;
 if(cada.getDiasAlugada() > 3) {
 valorCorrente += (cada.getDiasAlugada() - 3) * 1.5;
 }
 break;
 } //switch
 // trata de pontos de alugador frequente
 pontosDeAlugadorFrequente++;
 // adiciona bônus para aluguel de um lançamento por pelo menos 2 dias
 if(cada.getFita().getCódigoDePreço() == Fita.LANÇAMENTO &&
 cada.getDiasAlugada() > 1) {
 pontosDeAlugadorFrequente++;
 }
 // mostra valores para este aluguel
 resultado += "\t" + cada.getFita().getTítulo() + "\t" + valorCorrente + 
fimDeLinha;
 valorTotal += valorCorrente;
 } // while
 // adiciona rodapé
 resultado += "Valor total devido: " + valorTotal + fimDeLinha;
146
UNIDADE 3 | DIAGRAMAS
• Finalmente, a classe Locadora exercita o programa:
public class Locadora {
 public static void main(String[] args) {
 Cliente c1 = new Cliente("Juliana");
 c1.adicionaAluguel(new Aluguel(new Fita("O Exorcista ", Fita.
NORMAL), 3));
 c1.adicionaAluguel(new Aluguel(new Fita("Men in Black ", Fita.
NORMAL), 2));
 c1.adicionaAluguel(new Aluguel(new Fita("Jurassic Park III ", Fita.
LANÇAMENTO), 3));
 c1.adicionaAluguel(new Aluguel(new Fita("Planeta dos Macacos ", 
Fita.LANÇAMENTO), 4));
 c1.adicionaAluguel(new Aluguel(new Fita("Pateta no Planeta dos 
Macacos ", Fita.INFANTIL), 10));
 c1.adicionaAluguel(new Aluguel(new Fita("O Rei Leao ", Fita.
INFANTIL), 30));
 resultado += "Você acumulou " + pontosDeAlugadorFrequente +
 " pontos de alugador frequente";
 return resultado;
 }
}
TÓPICO 2 | DIAGRAMA DE CLASSES
147
 System.out.println(c1.extrato());
 }
}
FONTE: Disponível em: <http://walfredo.dsc.ufcg.edu.br/cursos/2003/progII20031/aulas/design.
htm>. Acesso em: 12 fev. 2015.
148
RESUMO DO TÓPICO 2
Ao término deste tópico, você, acadêmico(a), teve a oportunidade de 
conhecer os principais conceitos envolvidos na Orientação a Objetos.
Neste momento, você está ciente das definições e diferenças entre Atributos 
e Métodos; afinal Atributos se referem às características apresentadas pelo Objeto 
e os Métodos se referem a Ações realizadas por este Objeto. Teve conhecimento 
acerca das Classes dos Objetos.
Foram destacadas também as formas pelas quais os Objetos herdam, tanto 
os Atributos como os Métodos de suas Classes Superiores, porém é importante 
lembrar que cada objeto pode possuir Atributos ou Métodos próprios. 
Bom estudo!
149
AUTOATIVIDADE
1 É o princípio de projeto pelo qual cada componente de um programa deve 
agregar toda informação relevante para sua manipulação como uma unidade. 
Identifique a alternativa CORRETA:
a) ( ) Abstração.
b) ( ) Classe Pura.
c) ( ) Encapsulamento.
d) ( ) Objeto.
2 Com relação a Atributos e Métodos, descreva com suas palavras a diferença 
existente entre ambos.
3 Entre as alternativas a seguir, identifique os Atributos utilizando a letra A e 
os Métodos dos objetos utilizando a letra M:
Descrição Assinale (A / M) Descrição Assinale (A / M)
Um nome Cor dos olhos
Latir Correr em círculos
Comer Beber
Uma idade Cor dos Pelos
Sentar Peso
Comprimento 
dos Pelos
Dormir
4 Com base nas informações recebidas no decorrer deste tópico, desenhe o 
diagrama de Classe Completo, para os exercícios a seguir:
a) Jogo da Forca
Cristina quer fazer um jogo da forca em computador para os seus filhos e 
sobrinhos. Os requisitos para o jogo estão a seguir: 
• O jogo consiste em se tentar acertar as letras de uma palavra escondida. Se 
o jogador errar a letra, surge mais um pedaço de um boneco que ao final irá 
para a forca. 
• As palavras ou frases para cada rodada são obtidas de um banco de palavras 
e frases, que o próprio jogador pode incrementar. 
• Cada palavra ou frase pertence a um tema. 
• A cada rodada, a aplicação sorteia se mostrará uma, duas ou três palavras, 
ou uma frase e escolhe aleatoriamente o tema e as palavras (ou frases). 
• A palavra (ou frase) é exibida escondida e cada letra acertada desvenda sua 
posição correspondente. 
150
• Letras erradas são colocadas num quadro e um dos pedaços do boneco 
aparece. 
• O nome do jogador é guardado com seus pontos para fazer parte do quadro 
de maiores escores. Quando ele acerta a palavra, ganha 100 pontos e, para 
letra que ficou encoberta, somam-se mais 15 pontos. MELO (2006, p. 43).
b) Clube de Leitura
Gustavo tem uma coleção grande de revistas em quadrinhos. Por isso, 
resolveu emprestar para os amigos. Assim foi criado o Clube da Leitura. Mas 
para não perder nenhuma revista, seu pai lhe fez uma aplicação que cadastra 
as revistas e controla o empréstimo. 
Para cada revista, cadastram-se: o tipo de coleção, o número da edição, o ano 
da revista e a caixa onde está guardada. Cada caixa tem uma cor, uma etiqueta 
e um número. 
Para cada empréstimo cadastram-se: o amiguinho que pegou a revista, qual 
foi a revista, a data do empréstimo e a data de devolução. Cada criança só 
pode pegar uma revista por empréstimo.
O cadastro do amiguinho consiste de: nome, nome do responsável, telefone e 
de onde é o amigo MELO (2006, p. 48). 
c) Pediatra
Dra. Janete é Pediatra e tem três consultórios em bairros distintos, onde atende 
em horários diferentes. Ana, sua secretária, trabalha nos três consultórios.
Para que a marcação de consultas seja centralizada, Ana tem que carregar as 
três agendas de um lado para outro.
Dra. Janete contratou um analista “freelancer” para lhe desenvolver um sistema 
que controle a marcação de consultas e a ficha dos pacientes.
Para os pacientes, é preciso controlar: nome, endereço, telefones de contato, 
data de nascimento, data da primeira consulta, e-mail, se é particular ou 
conveniado a plano de saúde. No caso de ser conveniado, registrar qual é o 
plano de saúde. Para cada plano de saúde credenciado é preciso controlar o 
limite de consultas no mês, por paciente.
Dra. Janete atende no consultório da Ilha às segundas e sextas-feiras, de 9h às 
18h. Na Tijuca, ela atende terça e quarta de 10h às 18h. Na quinta, ela atende 
em Bonsucesso, de 10h às 18h. O intervalo das consultas é de trinta minutos. O 
horário de almoço é sempre de 12h30 às 13h30. Só são permitidos três encaixes 
por dia. Para clientes novos, Ana anota o nome do cliente e o seu telefone. 
É preciso identificar se uma consulta é de revisão, como por exemplo, para 
entrega de exames. Nesse caso, ela não é cobrada.
A marcação de consultas deve considerar uma data futura limite. (MELO, 
2006, p. 52).
151
TÓPICO 3
DIAGRAMA DE SEQUÊNCIA
UNIDADE 3
1 INTRODUÇÃO
O diagrama de sequência tem como propósito determinar a sequência que 
os eventos devem ter ao se executar um processo, verificando quais condições 
devem ser satisfeitas, quais métodos serão disparados e as mensagens que são 
enviadas. Assim, determinar a ordem em que os eventos ocorrem na execução do 
sistema. 
“O diagrama de sequência baseia-se no Diagrama de Caso de Uso, 
normalmente existem diversos diagramas de sequênciaem um projeto, um para 
cada processo do sistema”. Furlan (1998, p. 104).
2 ATORES
Conforme já visto anteriormente, em Diagrama de Caso de Uso, ator 
é toda pessoa que interage com o sistema indiferente do serviço ou da função 
exercida. Vale lembrar que segundo Fowler e Scott (2000, p. 52) “um ator pode 
desempenhar muitos casos de uso; um caso de uso pode ter reciprocamente 
vários atores desempenhando-o”.
FIGURA 91 – EXEMPLO SIMBOLOGIA ATOR
FONTE: Disponível em: <http://pt.slideshare.net/CursoSENAC/anlise-orien 
tada-a-objetos-diagrama-de-sequencia>. Acesso em: 12 fev. 2015.
Cliente
UNIDADE 3 | DIAGRAMAS
152
3 OBJETOS
Segundo Guedes (2004, p. 105), “os objetos deste diagrama representam 
as instâncias das classes envolvidas no processo ilustrado pelo Diagrama de 
Sequência”. Estes objetos por sua vez são apresentados como retângulos contendo 
um texto que identifica primeiramente o nome do objeto, em minúscula, e depois 
o nome da classe, com letras iniciais maiúsculas, a que o objeto pertence. 
FIGURA 92 – OBJETOS NO DIAGRAMA
FONTE: Disponível em: <http://pt.slideshare.net/CursoSENAC/anlise-orientada-
a-objetos-diagrama-de-sequencia>. Acesso em: 12 fev. 2015.
4 LINHA DE VIDA
A Linha de Vida demonstra o objeto durante o tempo em que ele existiu 
enquanto houve o processo. As Linhas de Vida são representadas por linhas finas 
verticais tracejadas partindo do retângulo que representa o objeto. A linha de 
vida é interrompida com um X quando o objeto é destruído (OLIVEIRA, 2015).
Vale destacar que o objeto pode ser criado durante o processo, ele não 
preciso existir desde o início do processo. Observe a figura.
: ContaCorrente : Cliente
TÓPICO 3 | DIAGRAMA DE SEQUÊNCIA
153
FIGURA 93a – DESENVOLVENDO OBJETO
FONTE: Disponível em: <https://msdn.microsoft.com/pt-br/library/dd409376.aspx>. Acesso em: 
12 fev. 2015.
5 FOCO DE CONTROLE OU ATIVAÇÃO
Segundo Guedes (2004, p. 107), “foco de controle ou ativação indica 
os períodos em que um determinado objeto está participando ativamente do 
processo, ou seja, identifica os momentos em que um objeto está executando um 
ou mais métodos utilizados em um processo específico”.
Os focos de controle ou a ativação, como são conhecidos, são representados 
por uma linha mais grossa, demonstrado junto com a linha de vida.
Observe novamente a Figura Desenvolvendo Objetos.
Customer Restaurant
Bank
Linha de
Vida
Dinner Now
System
[until complete] add Order Item
Confirm Order
Confirm Order
Send Order
OK
OK
Confirmed
Deliver Food
Payment detail
Loop
Process Payment
UNIDADE 3 | DIAGRAMAS
154
FIGURA 93b – DESENVOLVENDO OBJETO
FONTE: Disponível em: <https://msdn.microsoft.com/pt-br/library/dd409376.aspx>. Acesso em: 12 fev. 2015.
6 MENSAGENS OU ESTÍMULOS
Este item é de fácil compreensão, afinal, as mensagens ou estímulos são 
utilizados para demonstrar a ocorrência de eventos, que normalmente forçam 
a chamada de um método em algum dos objetos envolvidos no processo 
(OLIVEIRA, 2015).
Dentro do processo, as mensagens ou estímulos são representados por uma 
seta, desta forma indicam que enviou a mensagem e na sequência quem a recebeu.
FIGURA 94 – MENSAGENS OU ESTÍMULOS
FONTE: Disponível em: <http://slideplayer.com.br/slide/1255493/>. Acesso 
em: 15 fev. 2015.
Customer Restaurant
Bank
Linha de
Vida
Dinner Now
System
[until complete] add Order Item
Confirm Order
Confirm Order
Send Order
OK
OK
Confirmed
Deliver Food
Payment detail
Loop
Process Payment
Foco de
controle ou
ativação
Controlador
Congresso
ConsTema ( )
: Tema 
TÓPICO 3 | DIAGRAMA DE SEQUÊNCIA
155
De acordo com Guedes (2004, p. 108), estas mensagens podem ser 
disparadas da seguinte forma:
• Entre um ator e outro ator.
• Entre um ator e um objeto.
• Entre um objeto e um objeto.
• Entre um objeto e um ator.
 
Assim, sua representação dentro do processo ocorre por meio de uma 
seta indicando a direção, ou seja, quem recebe a mensagem e quem enviou a 
mensagem, desta forma, ligando os dois componentes envolvidos. Vale destacar 
que estas mensagens aparecem sempre na horizontal, entre a linha de vida e o 
foco de controle ou ativação, observe nas próximas figuras como as mensagens 
podem ser representadas dentro do diagrama de sequência.
FONTE: Disponível em: <http://www.theclub.com.br/restrito/revistas/201308/umld1308.aspx>. 
Acesso em: 13 fev. 2015.
msgSincrona(parametro)
msgAssincrona
<<create>>
new( ) Objeto: nomeClasse
Representação da mensagem do tipo Call
Representação da mensagem do tipo Send
Representação da mensagem do tipo Create
msgAutoDelegacao( )
Representação da mensagem do tipo Call de auto delegação
retorno
Representação da mensagem do tipo Return
<<destroy>>
kill( )
Representação da mensagem do tipo Destroy
UNIDADE 3 | DIAGRAMAS
156
Agora, observe um exemplo no qual estas representações de mensagem 
estão envolvidas no processo.
FIGURA 95 – MENSAGENS NO PROCESSO
FONTE: Disponível em: <http://www.theclub.com.br/restrito/revistas/201308/umld1308.aspx>. 
Acesso em: 13 fev. 2015.
7 MENSAGENS DE RETORNO
Mensagem de retorno por sua vez, nada mais é do que o retorno recebido 
pela mensagem que foi enviada, ou seja, a resposta pelo estímulo disparado, este 
retorno pode ser com uma mensagem específica, ou simplesmente um OK, ou 
NOK que representa a negação, observe a figura:
:Usuario
informaDados("Login", "Senha")
[usuarioOk = = True] : new( )
<<create>>
<<destroy>>
kill( )
<<boundary>>
: telaLogin
<<entity>>
: usuarios
<<boundary>>
: telaPrincipal
usuarioOk:=consultaUsuario("Login", "Senha")
TÓPICO 3 | DIAGRAMA DE SEQUÊNCIA
157
FIGURA 96 – MENSAGEM DE RETORNO
FONTE: Disponível em: <http://pt.slideshare.net/CursoSENAC/anlise-orientada-a-
objetos-diagrama-de-sequencia>. Acesso em: 17 fev. 2015.
8 AUTOCHAMADAS OU AUTODELEGAÇÕES
Como o próprio nome já diz, são as mensagens que o objeto envia para si 
mesmo, ou seja, são mensagens que partem da linha de vida do objeto e atingem 
a linha de vida do próprio objeto conforme demonstrado a seguir:
FIGURA 97 – AUTOCHAMADAS
FONTE: Disponível em: <http://sistemas.riopomba.ifsudestemg.edu.br/dcc/materiais/475302279_
DIAGRAMA%20DE%20SEQ%C3%9C%C3%8ANCIA.pdf>. Acesso em: 17 fev. 2015.
: ContaCorrente : Cliente
1: atualizaCliente( )
Cliente Atualizado OK
Mensagem
de retorno
autor1 : Autor
Validar CPF : ValCPF ( )
UNIDADE 3 | DIAGRAMAS
158
9 CONDIÇÕES OU CONDIÇÕES DE GUARDA
Este item indica que uma mensagem só poderá ser enviada a um objeto se 
uma determinada condição for verdadeira. “As condições de guarda são descritas 
normalmente em colchetes na mensagem, mas podem também ser representadas 
por meio de restrições”. (GUEDES, 2004, p. 112).
FIGURA 98 – CONDIÇÕES
FONTE: Disponível em: <http://jkolb.com.br/condicoes-ou-condicoes-de-guarda/>. Acesso em: 
17 fev. 2015.
1 : [Se necessário] Atualizar cliente: Gravar ( )
conta1 : Conta Comum fisica1 : Física
TÓPICO 3 | DIAGRAMA DE SEQUÊNCIA
159
10 EXEMPLOS DE DIAGRAMAS DE SEQUÊNCIA
1º Exemplo:
FONTE: Disponível em: <https://code.google.com/p/pcds-2007-1/downloads/detail?name= 
DiagramaDeSequencia-CadastroDeUsuario.v2.jpg>. Acesso em: 17 fev. 2015.
2º Exemplo: Processo de Abertura de Conta
FONTE: Disponível em: <http://slideplayer.com.br/slide/391466/>. Acesso em: 17 fev. 2015.
<<jsp>>
: TelaUsuario
: UsuarioAction : Usuario : UsuarioDAO
1: [Adicioinar ou Atualizar] exec( )
1.2: [Se retornou null] new( )
2.1: delete(id:int) : void
3.1: findAll( ) : List
1.3: set*( )
Retorna null se não existe
Retorna objeto salvo
Retorna objeto salvo
Retorna Lista de objetos
Retorna sucesso
2: [Excluir] exec ( )
3: [Listar] exec ( )
1.1: findByLoging(login: String) : Usuario
1.4: save(entity:BaseEntity) : BaseEntity
Retorna Lista de objetos encontrados
:Cliente :Banco
1: Solicita ( )
{Abertura da Conta}
2: Consultar Cliente( )
6: Abrir Conta: Abertura( )
4: Validar CPF: ValCPF( )
7: Registrar Histórico: Gravar( )
Histórico registrado com sucesso
8:
{Fornecer valor de
deposito e senha}[Se existir] Dados do Cliente
Cliente atualizado
5: Pedido aprovado( )
hist: Históricoconta1: Conta Comumfisica1: fisica
3: [Se necessário] Atualizar Gravar( )
UNIDADE 3 | DIAGRAMAS
160
3º Exemplo: Processo emitir relatório de convênio
FONTE: Disponível em: <http://spammichelangelo.googlecode.com/svn/trunk/SisPAM/Arquitetura/
Diagramas/diagramas%20de%20sequencia/>. Acesso em: 17 fev. 2015.
4º Exemplo: Processo Emitir Receita
FONTE: Disponível em: <http://spammichelangelo.googlecode.com/svn/trunk/SisPAM/Arquitetura/
Diagramas/diagramas%20de%20sequencia/>. Acesso em: 17 fev. 2015.
:Funcionario :ConvenioAction :ConvenioFacade dao : Convenio
1: InformaDadosConsulta( ) 1.1: submeteDados( ) 1.1.1: dadosObrigatorios( )
1.1.3: verificarConvenios( )
retornaConvenios
retornaRelatorioConvenios
dao : Log
1.1.4: gravaLogSeguranca( )
<<create>>
1.1.2: dadosInvalidos( )
Se os dados
obrigatorios não forma
preenchidos ou são
dados invalidos retorna
mensagem de erro.
Se os existirem
dados retornar 
mensagem de erro.
:médico :ReceitaAction
2: selecionaEmissaoReceita( )
2.1: EmissaoReceita( )
receitaEmitidaSucesso
receitaEmitidaSucesso
3: informaDadosReceita( ) 3.1: submeteDadosReceita( )
solicitaDadosReceita
:ReceitaFacade dao : Paciente
1: consultaPaciente( )
1.1: consultaPaciente( )
retornaDadosPaciente
1.1.1: dadosObrigatorios( )
3.1.3: emiteReceita( )
3.1.4: gravaLogSeguranca( )
<<create>>
<<create>>
Se paciente não
existir retornar 
mensagem de erro.
Se os dados
obrigatorios não forma
preenchidos ou são
dados invalidos retorna
mensagem de erro.
dao : Log
dao : HistoricoProntuario
1.1.2: dadosInvalidos( )
1.1.3: verificaExistencia( )
retornaDadosPaciente
3.1.1: dadosObrigatorios( )
3.1.2: dadosInvalidos( )
TÓPICO 3 | DIAGRAMA DE SEQUÊNCIA
161
5º Exemplo: Processo Manter Agendamento Consulta
FONTE: Disponível em: <http://spammichelangelo.googlecode.com/svn/trunk/SisPAM/Arquitetura/
Diagramas/diagramas%20de%20sequencia/>. Acesso em: 17 fev. 2015.
Agora que você pode verificar por meio de alguns exemplos como 
funciona o Diagrama de Sequência, vamos treinar um pouco:
1. Construa um Diagrama de Sequência para abrir uma conta, conforme 
a descrição a seguir: 
O cliente que deseja abrir uma conta no banco encaminha um 
pedido de abertura de conta, com a documentação necessária. O funcionário 
do banco irá consultar o cadastro do cliente por meio do seu CPF, para 
determinar se o solicitante já se encontra cadastrado. Se o cliente já estiver 
cadastrado, a consulta retornará as informações do cliente, caso contrário 
retornará um valor significando que o cliente ainda não possui cadastro 
na instituição. Em seguida, o cadastro do cliente poderá ser atualizado, 
caso necessário, podendo gerar uma nova instância da classe Cliente, se o 
solicitante ainda não estiver registrado, ou simplesmente atualizar os dados 
do mesmo, se houver necessidade de alguma atualização. 
Antes de finalizar a atualização do cliente, algumas inconsistências 
devem ser levadas a efeito, uma delas é o disparo do método para validação 
do CPF pelo próprio objeto da classe Cliente. Após o término da atualização, 
o objeto da classe cliente retornará algum sinal para o funcionário do banco, 
para indicar que o cliente foi atualizado com sucesso ou se ocorreu algum 
erro. 
O banco então irá informar ao cliente se o seu pedido foi ou não 
aprovado. Em caso de aprovação, o cliente irá fornecer o valor inicial 
necessário para a abertura da conta e escolherá a senha. O funcionário irá 
disparar o método de abertura na classe ContaComum, ou seja, criará um 
novo objeto ContaComum. 
:Funcionario :AgendamentoAction facade : Agendamento dao : Agendamento
1: consultaAgendamentos( )
<<exibeAgendamentos>>
<<retornaAgendamentos>>
1.1: consulta( )
1.1.1: verificarExistencia( )
Se não houver 
agendamento retornar 
mensagem de erro.
UNIDADE 3 | DIAGRAMAS
162
Após ter sido criado pela chamada do método abertura, o objeto de 
ContaComum irá disparar o método gravar para gerar uma nova instância 
da classe Histórico, registrando o movimento gerado pela abertura da 
conta, pois, para abrir uma conta, a instituição exige que o cliente deposite 
algum valor na mesma. O método gravar retornará um sinal indicando que 
o movimento foi registrado com sucesso e o método abertura disparado 
na classe ContaComum, por sua vez, retornará o número da conta gerado, 
indicando que a conta foi criada com sucesso e finalizando o processo de 
abertura de conta.
Resolução:
2. Construa um Diagrama de Sequência encerrar uma conta, conforme a 
descrição abaixo: 
Primeiramente um cliente se encaminha ao caixa do banco, 
representado pelo ator Funcionário e solicita o encerramento de uma 
determinada conta comum. O caixa então irá verificar se a conta informada 
realmente existe e se a senha informada é verdadeira, por meio do disparo 
do método consulta. Caso a conta realmente exista, o próprio método irá 
chamar o método de validação de senha para verificar se a senha informada 
pelo usuário está correta. Em caso positivo, será verificado o saldo da conta. 
Se o saldo retornado for positivo, então o caixa irá retirar o 
dinheiro da conta, o saque efetuado deverá ser registrado no histórico das 
movimentações. Em seguida o objeto de ContaComum retornará o valor 
do saldo para o atendente que deverá ser igual a zero se o método for 
executado com sucesso. 
Finalmente, o atendente irá chamar o método encerramento para 
fechar a conta do cliente no objeto de ContaComum. Antes de concluir 
a execução, esse método pode, caso a conta a ser encerrada seja a única 
c1:Cliente g1:Gerente
1: Solicita abertura
de Conta( )
2: [se pedido aprovado] 
Fornece o valor inicial( )
2.2: abertura de conta 
concluida( )
1.1: consulta cliente: consCliente(cpf long)
1.2: [se necessario] gravarDados( )
2.1: valCpf(cpf long)
<<create>>
2.1.1: gravar(c1:ContaComum, 
valordouble)
Historico gravado com sucesso
[se encontrar] Exibe dados do cliente
Cliente atualizado
<<create>>
2.1: abertura(valor double, tipoint, senha: String)
Informa número da conta gerada
h1: Histórico
c1: Conta
Comum
f1: Fisica
TÓPICO 3 | DIAGRAMA DE SEQUÊNCIA
163
possuída pelo cliente, atualizar o cadastro do mesmo, definindo o seu status 
como inativo, por meio do método gravar no objeto de Física. 
Caso tenha sido possível atualizar a instância da classe Física, então 
o método gravar retornará um valor indicando que o cliente foi atualizado. 
A conta retornará um valor que instruirá o software mostrar ao atendente 
a mensagem: “Conta Encerrada com Sucesso”, finalizando o processo de 
encerramento de conta.
Resolução:
FONTE: Disponível em: <http://vqv.com.br/lucelia/projSistemas/ExerciciosDiagramaDeSequencia03.
pdf>. Acesso em: 17 fev. 2015.
c1:Cliente g1:Gerente
1: Solicita encerramento
de Conta( )
1.1: consulta(numConta:Long)
1.1.1: [se encontrar] vaiSenha(senha String)
1.1.1.1: [se senha válida] verSaldo( )
1.2.1: registrar histórico gravar( )
2.1: [se conta única] Atualizar status do cliente gravar( )
Cliente atualizado
Histórico registrado com sucesso
1.2: efetuarSaque(se saldo positivo)
2: Encerrar conta encerramento( )
Conta encerrada com sucesso
saldo
saldo zerado
3: Conta encerrada( )
h1: Históricoc1: Conta Comum f1: Fisica
164
RESUMO DO TÓPICO 3
Ao término deste tópico, você teve a oportunidade de conhecer acerca do 
Diagrama de Sequência, sua influência no desenvolvimento do sistema, como 
acontece sua interação com atores, objetos e quais estímulos estes sofrem.
Assim, determinar a ordem em que os eventos ocorrem na execução do 
sistema. 
Neste momento, você está ciente que este diagrama se baseia no Diagrama 
de Caso de Uso, das definições, métodos de controle e estímulos. 
Bom estudo!
165
AUTOATIVIDADE
1 (Eletrobras) Observe o diagrama de sequência mostrado a seguir.
Observe as seguintes assertivas sobre o diagrama de sequência dado:
l - Os nomes dos objetos participantes da sequência são: TFRMEMPRESTIMO,TCNTEMPRESTIJMO e LEITOR.
II - ObterCodLeitor é um serviço de cntEmprestimo.
III - ObterCodLeitor é executado antes de MostraNomeLeitor.
Agora, assinale a alternativa que apresenta a resposta CORRETA:
a) ( ) Somente a l está correta.
b) ( ) Somente a II está correta.
c) ( ) Somente a III está correta.
d) ( ) As alternativas l e II estão corretas. 
2 Faça um Diagrama de Sequência para representar um cliente que efetua 
uma retirada de R$ 50,00 em um caixa automático. A retirada deve ser 
debitada na conta corrente do cliente.
3 Complete o exercício anterior para permitir saques somente quando há 
saldo na conta corrente e se o valor do saque for inferior a R$ 1.000,00.
cntEmprestimo
: TCNTEMPRESTIMO
Create
ObterCodLeitor
MostraNomeLeitor
NomeLeitor(cod : string)
frmEmprestimo
: TFRMEMPRESTIMO
leitor
:LEITOR
166
167
TÓPICO 4
DEMAIS DIAGRAMAS 
EXISTENTES
UNIDADE 3
1 INTRODUÇÃO
Neste tópico abordaremos os diagramas que são opcionais no 
desenvolvimento UML, no entanto, não menos importantes, pois havendo a 
necessidade geram documentação importante ao desenvolvimento do sistema. 
São estes:
Diagrama de serviços.
Diagrama de colaboração.
Diagrama de atividades.
Diagrama de estados.
2 DIAGRAMAS DE SERVIÇOS
Uma definição de simples compreensão para diagramas de serviços: é a 
apresentação em forma de uma figura, um mapa, um fluxograma, entre outros, 
que representa com precisão o sistema de serviço. 
Tem a funcionalidade de formatar ou reformatar as etapas envolvidas no 
desenvolvimento do serviço. Observe sua funcionalidade por meio das figuras a 
seguir. 
UNIDADE 3 | DIAGRAMAS
168
FIGURA 99 – RECEBIMENTO DE MERCADORIAS 1
FONTE: Disponível em: <http://www.doceshop.com.br/blog/como-fazer-diagrama-ser-
produtivo-reduzir-custos/>. Acesso em: 17 fev. 2015.
Administração
envia
Problemas Possíveis
N.F 2ª Via
N.F 1ª Via
Pedido de
Material
Produto faltando; 
Produto errado; 
Caixas abertas ou 
estragadas
Produto a mais 
ou sem prazo 
de validade
Produto a mais 
ou sem prazo 
de validade
Processo de 
reposição e 
estocagem
Envia N.Fs 
e Pedido de 
Material para 
balcão
OK?
Arquiva
Analisa Pedido 
de Material 
para esperar 
fornecedor
Recebe
Caminhão do
Fornecedor e 
pega as N.Fs
N.F 2ª Via
N.F 1ª Via
Anexa ao 
respectivo 
Pedido do 
Material
Pedido do 
Material
N.F 2ª Via
N.F 1ª Via
Pedido do 
Material
Oferta local 
para descarregar 
Material
Verifica se N.Fs 
e materiais 
conferem
Não
Sim
TÓPICO 4 | DEMAIS DIAGRAMAS EXISTENTES
169
FIGURA 100 – RECEBIMENTO DE MERCADORIAS 2
FONTE: Disponível em: <http://www.okconcursos.com.br/apostilas/apostila-gratis/111-
administracao-geral/1151-gestao-de-qualidade#.VOD2WfnF91Y>. Acesso em: 17 fev. 2015.
3 DIAGRAMA DE COLABORAÇÃO
INÍCIO
CLIENTE
Entra no 
restaurante e pede 
uma mesa
CLIENTE
Aguarda Mesa
CLIENTE
Analiza o cardápio 
e faz o pedido
MAITRE
Registra e 
encaminha o 
pedido
Mesa
disponível?
RECEPCIONISTA
Encaminha o 
cliente à mesa
RECEPCIONISTA
Entrega senha e 
encaminha cliente 
ao bar
RECEPCIONISTA
Mesa é 
disponibilizada
SIM
NÃO
Segundo Guedes (2004, p. 122) 
Diagrama de Colaboração (Diagrama de Comunicação na UML2) 
é muito semelhante ao Diagrama de Sequência apresentado 
anteriormente, porém esses diagramas diferenciam-se principalmente 
porque o Diagrama de Sequência concentra-se na sequência temporal 
em que os eventos ocorrem e as mensagens são chamadas, enquanto o 
Diagrama de Colaboração preocupa-se com a organização estrutural 
dos objetos, em como os objetos estão vinculados e as mensagens que 
estes trocam entre si.
UNIDADE 3 | DIAGRAMAS
170
Já Figueiredo (2014), em seu estudo que Diagrama de Colaboração, se 
preocupa e define a estrutura de como os objetos estão vinculados, idênticos ao 
Diagrama de Classes, e indicam quais as mensagens que são trocadas entre os 
objetos como no Diagrama de Sequência.
Veja os exemplos:
1. Diagrama de Colaboração Pesquisar Vendas
FONTE: Disponível em: <http://www.macoratti.net/Cursos/vbn_ado/vbn_cur1.htm>. Acesso 
em: 17 fev. 2015.
2. Este Diagrama de Comunicação demonstra a troca de mensagens existentes 
entre timer, a bomba d’água e o tambor.
Usuário
2. Informa tipo
data
1. Solicita tipo data
3. Buscar data (data)
Interface
Pesquisar
<<fronteira>>
Pesquisar
<<controle>>
BD
Tabela
Item locação
4. Apresentar
informações
4. Retornar
informações
TÓPICO 4 | DEMAIS DIAGRAMAS EXISTENTES
171
FONTE: Disponível em: <http://www.macoratti.net/net_uml3.htm>. Acesso em: 17 fev. 2015.
3. Diagrama de colaboração que descreve parte do fluxo de eventos do caso de 
uso Recebimento de Item de Depósito no Sistema de Máquina de Reciclagem.
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/modguide/md_coldm.
htm>. Acesso em: 17 fev. 2015.
1 :TempoMolho( )
2 :EnviarAgua( )
3 :ArmazenarAgua( )
: Tambor
: Timer
: Bomba
D'água
Cliente
1: insert item ( )
5: finish( )
11: getPaperAmount ( )
8: print( )
Painel do Cliente
Impressora de Recibos
Dispositivo
de Alarme
Tipo do Item
de Depósito
Lista de Itens
de Depósito
Receptor do
Item de Depósito
2: newItem( )
6: printReceipt( )
3: newItem( )
7: getItems( )
9: initAll( )
4: incr( )
10: init( )
12: alarme( )
UNIDADE 3 | DIAGRAMAS
172
4 DIAGRAMA DE ATIVIDADES
Diagrama de Atividades é o diagrama com maior ênfase ao nível de 
algoritmo da UML e provavelmente o mais detalhista. 
Apresenta muitas semelhanças com os antigos fluxogramas utilizados 
para desenvolver a lógica de programação e determinar o fluxo 
de controle de um algoritmo, sendo inclusive comum encontrar 
Diagramas de Atividades utilizando pseudocódigos ou mesmo 
linguagens de programação, como C ou Pascal (GUEDES, 2004, p. 152).
O autor descreve ainda que este diagrama preocupa-se em descrever 
os passos a serem percorridos para a conclusão de um método ou algoritmo 
específico e não de um processo completo como é o caso dos Diagramas de 
Sequência e Colaboração, ou seja, este diagrama concentra-se na representação 
do fluxo de controle de uma atividade.
Neste Diagrama é possível verificar a existência de três estados obrigatórios, 
sendo: Estado Inicial, Estado Final e o Estado de Ação.
O Diagrama de Atividades descreve a sequência de atividades, com 
suporte para comportamento condicional e paralelo. Um diagrama 
de atividades é uma variante de um diagrama de estados no qual a 
maioria, se não todos, dos estados é estado de atividade. Portanto, 
muito da terminologia segue a mesma terminologia de diagrama de 
estados. FONTE: Disponível em: <http://www.trabalhosfeitos.com/
ensaios/Informatica-Diagrama-De-Atividades/69370.html>. Acesso 
em: 24 fev. 2015.
Observe os exemplos:
TÓPICO 4 | DEMAIS DIAGRAMAS EXISTENTES
173
1. Retirando dinheiro de um caixa eletrônico (para cartões de crédito).
FONTE: Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/
atividades/diag_atividades.htm>. Acesso em: 17 fev. 2015.
2. Diagrama de Atividades do Processo de Solicitação de Serviços à Divisão de 
Desenvolvimento.
FONTE: Disponível em: <http://www.ufpi.br/nti/index/pagina/id/4689>. Acesso em: 17 fev. 2015.
swimiane
AMT Machine BankCustomer
activity
join
merge
branch
[valid PIN] [invalid PIN]
[balance < amount][balance >= amount]
guard
expression
fork
insert card
Enter amount
Take money from slot
Take card
Eject card
Show balance
Debit account
Authorize
Check account balance
end
Enter pin
start
Cliente - Administração 
Superior
Divisão de 
Desenvolvimento
Chefe de Divisão de Desenvolvi-
mento ou Coordenador de Sistemas
Solicitar 
serviço
Priorizar 
serviços
Homologar 
serviços
entregue
Foi encontrado algum
problema após
homologação? Sim
Sim
Sim
Não
Não
Não
Avaliar 
serviço
Executar 
serviço
Verificar 
serviço
executada
Foi encontrado 
algum problema 
após verificação?
Corrigir 
problemas 
encontrados
Serviço é 
legítimo?
UNIDADE 3 | DIAGRAMAS
174
5 DIAGRAMAS DE ESTADOS
Este tipo de diagrama “é uma técnica conhecidapara descrever o 
comportamento de um sistema. Eles descrevem todos os estados possíveis em que 
um objeto particular pode estar e como o estado do objeto muda como resultado 
de eventos que atingem”. (FOWLER e SCOTT, 2000, p. 113). Na maioria das 
técnicas de OO, os diagramas de estados são projetados para uma classe única 
para mostrar o comportamento ao longo do tempo de vida de um único objeto. 
Já Ramos (2013) descreve que um diagrama de estados (statechart), 
também conhecido por diagrama de transição de estado ou por máquina de 
estados, permite modelar o comportamento interno de um determinado objeto, 
subsistema ou sistema global.
Veja o exemplo:
1º Exemplo
FONTE: Disponível em: <http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2013_1/
UML_Aula3.pdf>. Acesso em: 17 fev. 2015.
TÓPICO 4 | DEMAIS DIAGRAMAS EXISTENTES
175
2º Exemplo: Diagrama de estado para o objeto Login.
Modelagem do sistema de login. Para que o usuário seja autenticado, ele 
deve fornecer dois valores: SSN (Social Security Number) e o PIN (Personal ID 
Number). Após a submissão é feita uma validação.
FONTE: Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/
estado/diag_estados.htm>. Acesso em: 17 fev. 2015.
3º Exemplo: Um sistema de leilão.
Para que um lance seja efetuado com sucesso, a oferta tem que ser válida 
e o cliente tem que ter crédito suficiente.
FONTE: Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/
estado/diag_estados.htm>. Acesso em: 17 fev. 2015.
Rejecting
Validating
Cancel/Quit
[not valid]/Display error message
[valid]/Start transaction do/validate SSNand PIN
final state
action
activityguardevent
submit
Press key[key!= shift-tab]/Display dot
Press tab OR move cursor to PIN
field/Cursor to PINPress shift-tab OR move cursor 
to SSN field/Cursor to SSN
Press key[key!= tab]/Display key
Getting PIN
Getting SSN
/Cursor to SSN
initial state
Retry/Clear SSN, PIN entries
submit
transition
state
Auction
[reject, unwilling to rebid]
[reject, continue]
[bid offered]
[authorized]
thread
fork
Authorizing Credit
[not authorized]
composite state
Bidding
substate
join
[accept]Getting Bid Evaluating Accepting
Cancelled
Rejected
Checking OK
Purchased
UNIDADE 3 | DIAGRAMAS
176
Símbolo Designação Descrição Utilização
Ator Uma entidade (pessoas ou 
sistemas externos) que intera-
ge com o sistema a modelar.
Diagramas de 
casos de utiliza-
ção, de classes, 
de sequência e 
de colaboração.
Use case Uma sequência de acções 
executadas pelo sistema de 
forma a obter um resultado 
visível para um ator
Diagramas de 
casos de utiliza-
ção.
<<texto>> Estereótipo Os estereótipos permitem a 
classificação de elementos. 
Por exemplo, as classes que 
representam janelas da apli-
cação podem ser classificadas 
com o estereótipo <<form>>*.
Todos os diagra-
mas.
Associação Representa uma associação 
ou relação entre dois elemen-
tos num diagrama.
Todos os diagra-
mas.
Relação 
“uses”
Tipo especial de relação que 
indica que um caso de utiliza-
ção usa obrigatoriamente as 
funcionalidades de um outro 
caso de utilização
Diagramas de 
casos de utiliza-
ção.
Relação “ex-
tends”
Tipo especial de relação que 
indica que um caso de utiliza-
ção pode opcionalmente es-
tender as funcionalidades de 
um outro caso de utilização
Diagramas de 
casos de utiliza-
ção.
ELEMENTOS GRÁFICOS DA NOTAÇÃO UML 
Existem símbolos que auxiliam no processo de desenvolvimento, os mesmos 
possuem certa semelhança com os símbolos utilizados nos fluxogramas, porém 
de fácil compreensão, tendo como principal diferença a utilização sistemática do 
princípio de abstração em um contexto limitado, de um método apenas, e não de 
todo o objeto, conforme descrito por Correia e Tafner (2001, p. 26).
A notação mais utilizada para criação de fluxos em Análise Orientada a 
Objetos é a UML figura 19, que apresenta uma legenda dos elementos gráficos 
utilizados nos diagramas UML.
Figura 1 – Tabela de Elementos Gráficos da Notação UML
LEITURA COMPLEMENTAR
Utilizador
*uses*
<<extends>>
Introduzir Facturas
TÓPICO 4 | DEMAIS DIAGRAMAS EXISTENTES
177
Símbolo Designação Descrição Utilização
Package Unidade lógica de agrupa-
mento de elementos para 
simplificar a leitura de um 
diagrama.
Cada elemento num modelo 
pertence apenas a um “packa-
ge”. Adicionalmente, os no-
mes dos elementos devem ser 
únicops em cada “package”.
Todos os diagra-
mas.
Comentário 
ou nota
Comentários textuais e/ou 
gráficos que se podem adicio-
nar aos elementos de um dia-
grama para explicar/detalhar 
certos aspectos que possam 
ser dúbios.
Todos os diagra-
mas.
Classe
 
Uma classe é uma descrição 
de um conjunto de objectos 
que partilham os mesmos 
atributos, operações, relações 
e semântica. São uma forma 
de representar os diferentes 
conceitos existentes num sis-
tema/problema.
Diagramas de 
classes.
Classe abs-
tracta
Um tipo especial de classe que 
não possui objectos, servindo 
normalmente como base para 
especialização de outras classes.
Denotada pelo nome em itálico.
Diagramas de 
classes.
Objecto Uma instância específica de 
uma classe. Corresponde à 
atribuição de valores concre-
tos aos atributos da classe.
Denotada pelo nome subli-
nhado.
Diagramas de 
classes.
Associação 
unidireccio-
nal
Uma relação navegável entre 
dois elementos mas apenas 
num sentido (ex., composição 
de classes).
Todos os diagra-
mas.
Generaliza-
ção
Uma relação que indica a espe-
cialização (herança) de um ele-
mento a partir de outro. Isto é, 
o elemento apontado pela seta 
é um caso mais geral do outro 
elemento. Denota uma relação 
“é um” ou “do tipo”.
Diagramas de 
classes e de ca-
sos de utiliza-
ção.
Formulários
Pessoa
-nome: String
+falar( )
Pessoa
-nome: String
+falar( )
indivíduo : Pessoa
nome : String = 
Paulo Sousa
UNIDADE 3 | DIAGRAMAS
178
Símbolo Designação Descrição Utilização
Dependência Uma relação que indica a 
existência de uma depen-
dência entre dois elementos 
de tal forma que uma altera-
ção num dos elementos pode 
afectar o outro .
Diagramas de 
classes, casos de 
utilização e de 
instalação.
Associação 
n-ária
Uma associação entre n ele-
mentos.
Diagramas de 
classes.
Agregação Uma relação de agregação 
entre elementos. É uma re-
lação “todo/parte” onde um 
elemento é composto por vá-
rios outros elementos.
Diagramas de 
classes.
Classe de 
associação
Uma associação com as carac-
terísticas de (e representada 
por) uma classe.
Diagramas de 
classes.
Restrição Uma restrição é um mecanis-
mo que permite a criação de 
condições e restrições boo-
leanas a aplicar a um ou mais 
elementos (ex., associações).
Todos os diagra-
mas.
“Interface” Este estereotipo não deve ser 
confundido com interface 
com utilizador. Interface re-
presenta uma “vista” sobre as 
operações de uma classe.
Diagramas de 
classes.
Interface Uma interface é uma colecção 
de especificações de operações 
para definir um serviço sem 
ditar a sua implementação.
Diagramas de 
instalação.
“Utility” Este estereotipo representa 
um agrupamento de opera-
ções e atributos que não per-
tencem a nenhuma classe do 
problema (ex., funções de bi-
blioteca)
Diagrama de 
classes.
Estado Representa o estado de um 
objecto durante o seu tempo 
de vida, enquanto espera por 
um evento ou efectua alguma 
acção.
Diagramas de 
estado.
parentesco
- grau
<<interface>> 
IConsultas
+obterNome( ) : String
<<untility>> 
Matemática
+PI : double = 3,14159
+pow( ) : double
.
{OR}
.
em espera
IConsultas
TÓPICO 4 | DEMAIS DIAGRAMAS EXISTENTES
179
Símbolo Designação Descrição Utilização
Estado inicial O estado inicial de um dia-
grama de estados, onde se 
inicia a execução da máquina 
de estados.
Diagramas de 
estado.
Estado final O estado final de um diagra-
ma de estados, onde a execu-
ção da máquina de estados 
finaliza.
Diagramas de 
estado.
Actividade Representa uma actividade 
que o objecto efectua.
Diagrama de ac-
tividades.
Transição Indicauma transição entre 
dois estados devido à ocor-
rência de determindas condi-
ções ou eventos.
Diagramas de 
estado e de acti-
vidade.
Decisão Elemento que permite tomar 
uma decisão entre dois ou 
mais fluxos alternativos.
Diagramas de 
estado e de acti-
vidade
Bifurcação ou 
confluência
Permite a divisão ou reagru-
pamento de fluxos de controlo
Diagramas de 
estados e de ac-
tividades
Nodo Representa um elemento físi-
co na instalação do sistema. 
Normalmente com capacida-
de de processamento.
Diagramas de 
instalação.
Instância de 
um nodo
Representa um dispositivo con-
creto da rede (ex., o computador 
do gabinete 23).
Denotado pelo nome sublinhado.
Diagramas de 
instalação.
Componente Um componente é uma parte fí-
sica do sistema que corresponde 
à realização de um conjunto de 
interfaces e/ou classes.
Diagramas de 
instalação.
“boundary” Tipo de classe de análise usa-
da para modelar as interac-
ções entre um sistema e os 
seus actores.
Representam normalmente, 
janelas de aplicação, APIs, etc.
Diagramas de 
classes de aná-
lise.
“control” Tipo de classe de análise usa-
da para encapsular modelar o flu-
xo de controlo para um dado caso 
de utilização.
Representam coordenação e se-
quenciamento de outros objectos.
Diagramas de 
classes de aná-
lise.
validar
PC
GAB033
acesso a dados
UNIDADE 3 | DIAGRAMAS
180
Símbolo Designação Descrição Utilização
“entity” Tipo de classe de análise usa-
da para modelar informação 
com grande duração (possi-
velmente persistente)
Diagramas de 
classes de aná-
lise.
Linha tem-
poral
Representa a linha temporal 
da existência de um objecto.
Ao longo da linha serão re-
presentadas as activações do 
objecto bem como as mensa-
gens recebidas e enviadas.
Diagramas de 
sequência.
Mensagem 
síncrona
Mensagem trocada entre dois 
objectos que vai activar o ob-
jecto chamado. Pelo facto de 
ser uma mensagem síncrona, 
o objecto chamador fica à es-
pera que o objecto chamado 
termine o processamento an-
tes de continuar.
Corresponde normalmente à 
invocação de uma operação 
do objecto chamado.
Diagramas de 
sequência.
Mensagem 
assíncrona
O assincronismo permite que 
a mensagem seja enviada ao 
objecto chamado, e que o ob-
jecto chamador continue ime-
diatamente a sua execução 
(i.e., sem esperar pela respos-
ta)
Diagramas de 
sequência.
Chamada de 
procedimen-
to
Indicação explícita da invoca-
ção de um método no objecto 
chamado.
Diagramas de 
sequência.
Mensagem 
de retorno
Indica o retorno de uma men-
sagem. É omitida nas mensa-
gens síncronas.
 
Ativação Indica um tempo de proces-
samento num objecto.
Diagramas de 
sequência.
cliente
Objecto
Mensagem
Mensagem
Mensagem
Mensagem
FONTE: Disponível em: <http://www.dei.isep.ipp.pt/~psousa/aulas/EINF/guiaUML.htm>. Acesso 
em: 17 fev. 2015.
Como usar os símbolos
Os símbolos são utilizados para desenhar um esboço do sistema, uma 
espécie de fluxograma, porém menos complexo. É importante observar a linguagem 
TÓPICO 4 | DEMAIS DIAGRAMAS EXISTENTES
181
utilizada dentro dos símbolos, deve conter um único verbo, normalmente utiliza-
se os verbos no infinitivo, por exemplo: receber, abrir, imprimir, consultar, entre 
outros.
Para melhor compreensão, observe a figura 2, a mesma demonstra a 
utilização dos símbolos na criação de um diagrama, o qual demonstra o método 
Modificar-Salário deve-se proceder da seguinte forma: o método Modificar_
Salário recebe um parâmetro que se refere ao percentual de aumento e aplica o 
mesmo sobre o atributo salário, conforme demonstra a figura.
Figura 2 – Digrama de Método Modificar Salário.
FONTE: O Autor
Auxiliando você no entendimento deste tópico segue mais um exemplo 
de diagrama, conforme demonstra a figura 3.
Receber o valor em VALPER
Retornar
Operação |legal
Sim
Não
Retornar
Operação Bem Sucedida
Salário = Salário* (1+(VALPER/100))
VALPER < 0 ?
UNIDADE 3 | DIAGRAMAS
182
Figura 3 – Outro exemplo
FONTE: Disponível em: <http://www.unifal-mg.edu.br/nti/solicitacao-de-suporte>. Acesso em: 
17 fev. 2015.
Cliente
início Execução Finalização
Atendimento
Solicita suporte via 
requisição web
Dar retorno ao 
cliente
Encaminhar Solicitação 
ao setor responsável*
OU
Executa atendimento 
símples
Atendimento Geral - Triagem
* Esse passo inicia um novo fluxo no setor que recebe a requisição.
Registrar Solicitação
183
RESUMO DO TÓPICO 4
Neste tópico, você teve a oportunidade de conhecer acerca dos diagramas 
que são opcionais no desenvolvimento UML, mas não menos importantes, pois 
havendo a necessidade geram documentação importante ao desenvolvimento do 
sistema.
 Para finalizar este tópico foram apresentados exemplos dos diagramas 
(Serviços, Colaboração, Atividades, Estados).
Neste Momento você está apto a realizar as autoatividades deste tópico.
Bom estudo!
184
AUTOATIVIDADE
1 Com base nas informações a seguir, você deve desenvolver os seguintes 
diagramas:
• Diagrama de Classes.
• Diagrama de Caso de Uso.
• Descrição dos Casos de Uso – Abrir Conta.
• Descrição dos Casos de Uso – Fechar Conta.
• Diagramas de Sequência.
• Diagrama de Estados.
SISTEMA DE CONTROLE DE RESTAURANTE:
a) Primeiramente, elabore um diagrama de classes e um de casos de uso para 
o sistema de controle de Restaurante, cujos requisitos estão descritos a seguir. 
Descreva os casos de uso Abrir Conta e Fechar Conta, seguindo os itens de 
descrição de casos de uso, e em seguida, elabore os diagramas de sequência 
correspondentes:
• Garçons são cadastrados por um dos gerentes, que pode ser o proprietário 
ou não, com nome, identidade, matrícula, endereço e telefone.
• Quando uma conta é aberta pelo Caixa, deve ser registrada a mesa, o garçom 
que está atendendo, a data e o horário de abertura da conta.
• Durante a noite, produtos do cardápio são solicitados pelos clientes e 
associados à sua conta pelo próprio Garçom através de um PalmTop, cada 
produto em uma determinada quantidade, gerando um item da conta.
• A cada item associado à Conta enquanto ela está aberta, seu total vai sendo 
calculado.
• O Cliente pode cancelar uma Conta, solicitando ao Garçom, mas somente se 
ainda não tiver itens cadastrados.
• Quando do Cancelamento. Um aviso deve ser emitido ao Gerente.
• Produtos do cardápio são organizados por categorias de produtos, como 
Bebidas, Petiscos, Carnes, Aves, Massas e Sobremesas.
• Produtos possuem um preço e um código.
• Quando do fechamento de uma conta pelo Garçom, a pedido do Cliente, o 
sistema deve registrar a data e o horário do fechamento e calcular o seu valor 
total, imprimindo a correspondente nota fiscal.
• Ao final de cada semana, as comissões dos garçons devem ser calculadas 
com base no somatório das contas que cada um atendeu na semana.
• O percentual aplicado para cálculo das comissões pode variar de tempos em 
tempos, devendo ser mantido pelo sistema.
• Deve ser extraído também um relatório de ocupação semanal das mesas, 
indicando, por mesa, as faixas de horário de ocupação por data.
185
• Gerentes também devem ser cadastrados pelo proprietário do restaurante 
com nome, endereço, telefone e CPF.
• Proprietários executam todas as funções de Gerentes, além de cadastrar os 
Gerentes.
b) Elabore o diagrama de estados para o objeto Conta.
186
187
REFERÊNCIAS
AMBLER, Scott W. Análise e projeto orientados a objeto: seu guia para 
desenvolver sistemas robustos com tecnologia de objetos. Rio de Janeiro: 
Editora IBPI Press, 1998.
ANGELANTONIO Jr., Roberto de. Trabalhando com generalização e 
especialização de dados. 2003. Disponível em: <http://www.devmedia.com.
br/trabalhando-com-generalizacao-e-especializacao-de-dados-revista-sql-
magazine-103/25665>. Acesso em: 17 fev. 2015.
ANGELANTONIO Jr., Roberto de. Trabalhando com generalização e 
especialização de dados - Revista SQL Magazine 103. Disponível em: <http://
www.devmedia.com.br/trabalhando-com-generalizacao-e-especializacao-de-
dados-revista-sql-magazine-103/25665>. Acesso em: 23 dez. 2014.
ARAÚJO, Marcelo C. Análise orientada a objetos.Engenharia de Software 
Magazine. São Paulo, Ano: 01 – Edição 02, p. 46-52, 22 e 23 de maio 2009.
BARCELLOS, Monalessa Perini. Planejamento de custos em ambientes de 
desenvolvimento de software orientados à organização. Tese, Universidade 
Federal do Rio de Janeiro. Jun. 2013.
CAMARINI, Bruno. Prototipação e sua importância no desenvolvimento de 
software. Disponível em: <http://www.dextra.com.br/prototipacao-e-sua-
importancia-no-desenvolvimento-de-software/ >. Acesso em: 2 fev. 2015.
CORREIA, Carlos Henrique; TAFNER, Malcon Anderson. Análise orientada a 
objetos. Florianópolis: Editora Visual Books, 2001.
DAVID, Marcio Frayze. Programação orientada a objetos: uma introdução. 2007. 
Disponível em: <http://www.hardware.com.br/artigos/programacao-orientada-
objetos/>. Acesso em: 22 dez. 2014.
DICIONÁRIO AURÉLIO. Disponível em: <http://www.dicionariodoaurelio.
com/ > Acesso em: 26 fev. 2015.
FARINELLI, Fernanda. Conceitos básicos de programação orientada a objetos. 
2007. Disponível em: <http://sistemas.riopomba.ifsudestemg.edu.br/dcc/
materiais/1662272077_POO.pdf>. Acesso em: 22 dez. 2014.
FIGUEIREDO, Eduardo. Diagrama de colaboração. 2014. Disponível em: 
<http://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/uml-diagrama-
colaboracao_v01.pdf>. Acesso em: 17 fev. 2015.
188
FOWLER, Martins; SCOTT, Kendall. UML Essencial – Um breve guia para a 
linguagem-padrão de modelagem de objetos. Porto Alegre: Editora Bookman, 
2000.
FURLAN, Jose Davi. Modelagem de objetos através da UML. São Paulo: Editora 
Makron Book, 1998.
GALEOTE, Sidney. Mecanismos gerais da UML. Disponível em: <http://www.
prasabermais.com/analise/aula03.pdf >. Acesso em: 17 fev. 2015.
GUEDES, Gilleanes T. A. UML Uma abordagem prática. São Paulo: Editora 
Novatec. 2004.
GUEDES, Gilleanes T. A. UML 2 – guia prático. 2 ed. São Paulo: Editora 
Novatec, 2007.
HOFFMANN, Elisabeth. Elaboração e armazenamento de documentação de 
sistemas informatizados. Disponível em: <http://celepar7cta.pr.gov.br/portfolio.
nsf/0/48758ba6fd138b9403256be50047aabd/$FILE/Monografia_v_final.pdf > 
Acesso em: 2 fev. 2015.
JACOBY, Luciano. UML – Linguagem de Modelagem Unificada. Disponível em: 
<http://www.ebah.com.br/content/ABAAAArqkAA/apostila-uml>. Acesso em: 
17 fev. 2015.
LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao 
projeto orientados a objetos e ao Processo Unificado. Porto Alegre, Editora 
Bookman, 2004.
LIMA, Adilson da Silva. UML 2.0 – Do requisito à solução. 1 ed. São Paulo: 
Editora Érica, 2005.
MELO, Ana Cristina. Exercitando modelagem em UML – 51 exercícios 
resolvidos. Rio de Janeiro: Editora Brasport Livros e Multimídia, 2006.
MONTEIRO, Alexandre. Análise e validação dos requisitos. Disponível em: 
<http://slideplayer.com.br/slide/44191/> Acesso em: 17 fev. 2015.
NOGUEIRA, Admilson. UML – Introdução e histórico. Disponível em: <http://
www.linhadecodigo.com.br/artigo/763/uml-unified-modeling-language-
introducao-e-historico.aspx> Acesso em: 17 fev. 2015.
OLIVEIRA, Antônio Ricardo de; FERNANDES, Leila Maria Pereira; TAVEIRA, 
Gilda Aché. SENAC – modelagem de dados. Rio de Janeiro. Editora: Senac 
Nacional 2000.
189
OLIVEIRA, Lucélia. Diagrama de sequência. Disponível em: <http://sistemas.
riopomba.ifsudestemg.edu.br/dcc/materiais/475302279_DIAGRAMA%20DE%20
SEQ%C3%9C%C3%8ANCIA.pdf > Acesso em: 17 fev. 2015.
PONTUSCHKA, Maurício Nacib. Modelagem de software orientada a objetos. 
Disponível em: <http://www.pucsp.br/~tuska/2012/MSOO/antigas/Aula02.ppt>. 
Acesso em: 17 fev. 2015. 
RAMOS, Ricardo Argenton. UML – Diagrama de Estado. 2013. Disponível em: 
<http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2013_1/UML_
Aula3.pdf>. Acesso em: 17 fev. 2015.
REBOUÇAS, Pedro Emiliano de Oliveira. Mapeamento do processo unificado 
em relação ao
cmmi buscando compatibilidade com o mps.br focado na gerência de 
requisitos. 2007. Disponível em: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_pedro_reboucas.pdf> Acesso em: 8 fev. 2015.
SANTOS, Rildo F. Linguagem de modelagem unificada – UML. 2009. 
Disponível em: <http://pt.slideshare.net/Ridlo/uml-1858376 > Acesso em: 17 fev. 
2015.
SENE, Rafael Peria de. RUP - primeiros passos. Disponível em: <http://www.
tiespecialistas.com.br/2011/02/rup-primeiros-passos/>. Acesso em: 8 fev. 2015.
SPÍNOLA, Rodrigo. Manutenção de software: Definições e Dificuldades. 
Disponível em: <http://www.devmedia.com.br/manutencao-de-software-
definicoes-e-dificuldades-artigo-revista-sql-magazine-86/20402>. Acesso em: 17 
fev. 2015.
WAZLAWICK, Raul Sidnei. Engenharia de software: conceitos e práticas. São 
Paulo. Editora Campus, 2013.