Modelagem de Sistemas com UML e Orientacao a Objetos

Prévia do material em texto

Brasília-DF. 
ModelageM de SiSteMaS coM UMl 
e orientação a objetoS
Elaboração
Camila de Luna Maciel Gadelha
Produção
Equipe Técnica de Avaliação, Revisão Linguística e Editoração
Sumário
APRESENTAÇÃO ................................................................................................................................. 4
ORGANIZAÇÃO DO CADERNO DE ESTUDOS E PESQUISA .................................................................... 5
INTRODUÇÃO.................................................................................................................................... 7
UNIDADE I
INTRODUÇÃO ....................................................................................................................................... 9
CAPÍTULO 1
MODELAGEM DE SISTEMAS DE SOFTWARE .............................................................................. 9
CAPÍTULO 2
INTRODUÇÃO À ORIENTAÇÃO A OBJETOS .............................................................................. 16
UNIDADE II
PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS .......................................................................... 20
CAPÍTULO 1
OBJETOS E CLASSES ............................................................................................................... 20
CAPÍTULO 2
ABSTRAÇÃO, ENCAPSULAMENTO, HERANÇA E POLIMORFISMO ............................................... 24
CAPÍTULO 3
AGREGAÇÃO/COMPOSIÇÃO E GENERALIZAÇÃO/ESPECIALIZAÇÃO ....................................... 31
UNIDADE III
MODELAGEM DE SISTEMAS COM UML ................................................................................................. 35
CAPÍTULO 1
INTRODUÇÃO À UML: HISTÓRICO E CONCEITOS ..................................................................... 35
CAPÍTULO 2
INTRODUÇÃO AOS DIAGRAMAS DA UML ................................................................................ 41
CAPÍTULO 3
VISÃO GERAL DA UML 2.0 ...................................................................................................... 54
CAPÍTULO 4
USO DE FERRAMENTAS CASE ................................................................................................. 58
UNIDADE IV
PRINCIPAIS DIAGRAMAS ESTRUTURAIS DA UML ...................................................................................... 65
CAPÍTULO 1
DIAGRAMAS DE CLASSES ....................................................................................................... 65
CAPÍTULO 2
DIAGRAMA DE COMPONENTES .............................................................................................. 79
CAPÍTULO 3
DIAGRAMA DE PACOTES ........................................................................................................ 83
UNIDADE V
PRINCIPAIS DIAGRAMAS DE COMPORTAMENTO DA UML ...................................................................... 88
CAPÍTULO 1
DIAGRAMA DE CASOS DE USO .............................................................................................. 88
CAPÍTULO 2
DIAGRAMA DE SEQUÊNCIA .................................................................................................... 99
CAPÍTULO 3
DIAGRAMA DE ATIVIDADE ..................................................................................................... 112
UNIDADE VI
ESTUDO DE CASO ............................................................................................................................. 121
CAPÍTULO 1
DESCRIÇÃO ......................................................................................................................... 121
CAPÍTULO 2
DIAGRAMAS DE CASOS DE USO ........................................................................................... 124
CAPÍTULO 3
DIAGRAMAS ESTRUTURAIS: CLASSES, PACOTES E COMPONENTES .......................................... 133
CAPÍTULO 4
DIAGRAMAS DE COMPORTAMENTO: SEQUÊNCIA E ATIVIDADES ............................................ 140
PARA (NÃO) FINALIZAR ................................................................................................................... 148
REFERÊNCIAS ................................................................................................................................ 149
5
Apresentação
Caro aluno
A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se 
entendem necessários para o desenvolvimento do estudo com segurança e qualidade. 
Caracteriza-se pela atualidade, dinâmica e pertinência de seu conteúdo, bem como pela 
interatividade e modernidade de sua estrutura formal, adequadas à metodologia da 
Educação a Distância – EaD.
Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade 
dos conhecimentos a serem oferecidos, possibilitando-lhe ampliar conceitos 
específicos da área e atuar de forma competente e conscienciosa, como convém 
ao profissional que busca a formação continuada para vencer os desafios que a 
evolução científico-tecnológica impõe ao mundo contemporâneo.
Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo 
a facilitar sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na 
profissional. Utilize-a como instrumento para seu sucesso na carreira.
Conselho Editorial
6
Organização do Caderno 
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em 
capítulos, de forma didática, objetiva e coerente. Eles serão abordados por meio de textos 
básicos, com questões para reflexão, entre outros recursos editoriais que visam a tornar 
sua leitura mais agradável. Ao final, serão indicadas, também, fontes de consulta, para 
aprofundar os estudos com leituras e pesquisas complementares.
A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de 
Estudos e Pesquisa.
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita 
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante 
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As 
reflexões são o ponto de partida para a construção de suas conclusões.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Praticando
Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer 
o processo de aprendizagem do aluno.
7
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Para (não) finalizar
Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem 
ou estimula ponderações complementares sobre o módulo estudado.
8
Introdução
A UML (Unified Modeling Language – Linguagem de Modelagem Unificada) tornou-se, 
nos últimos anos, a linguagem padrão de modelagem adotada internacionalmente 
pela indústria de Engenharia de Software. Ela é uma linguagem visual utilizada para 
modelar softwares baseados no paradigma de orientação a objetos. 
Este material procura ensinar os conceitos básicos de modelagem de sistemas segundo 
o paradigma da orientação a objetos, usando como base a linguagem UML. Para isso, a 
linguagem UML é apresentada mediante a ilustração de seus diversos diagramas, onde 
alguns de seus componentes são detalhados e como eles interagem.
Objetivos
 » Apresentar o conceito de modelagem de sistemas segundoo paradigma 
de orientação a objetos.
 » Apresentar os princípios básicos da orientação a objetos e os principais 
conceitos.
 » Introduzir a linguagem UML, apresentando seu histórico, principais 
conceitos e uma visão geral da versão 2.0 da linguagem.
 » Descrever e ilustrar os principais diagramas da UML e apresentar um 
estudo de caso exemplo.
 » Apresentar as principais ferramentas de modelagem UML existentes no 
mercado.
9
UNIDADE IINTRODUÇÃO
CAPÍTULO 1
Modelagem de sistemas de software
Uma característica intrínseca de sistemas de software é a complexidade de seu 
desenvolvimento, que aumenta à medida que o sistema cresce. Para ter uma 
ideia da complexidade envolvida na construção de alguns sistemas, pense 
no tempo e nos recursos materiais necessários para se construir uma casa de 
cachorro. Para essa tarefa, provavelmente tudo que se precisa e de algumas 
ripas de madeira, alguns pregos, uma caixa de ferramentas e certa dose de 
amor por seu cachorro. Depois de alguns dias a casa estaria pronta. O que dizer 
da construção de uma casa para sua família? Certamente tal empreitada não 
seria realizada tão facilmente. O tempo e os recursos necessários seriam uma 
ou duas ordens de grandeza maiores do que o necessário para a construção da 
casa de cachorro. O que dizer, então, da construção de um edifício? Certamente, 
para se construir habitações mais complexas, algum planejamento adicional é 
necessário. Neste planejamento, engenheiros e arquitetos constroem plantas 
dos diversos elementos de habitação antes do início da construção propriamente 
dita (BEZERRA, 2015).
Na construção de sistemas de software, assim como na de sistemas habitacionais, 
também há uma gradação de complexidade. Para a construção de sistemas de software 
mais complexos, é igualmente necessário um planejamento inicial. O equivalente ao 
projeto de plantas da engenharia civil também deve ser realizado. 
Essa necessidade leva ao conceito de modelo, tão importante no desenvolvimento de 
sistemas. 
De uma maneira mais ampla, um modelo pode ser visto como uma representação 
idealizada de um sistema a ser construído. São várias as razões para se utilizar modelos 
na construção de sistemas, dentre elas (BEZERRA, 2015):
10
UNIDADE I INTRODUÇÃO
1. Gerenciamento da complexidade: pode haver diversos modelos de 
um mesmo sistema, cada qual descrevendo uma perspectiva do sistema 
a ser construído. Assim, detalhes irrelevantes que podem dificultar 
o entendimento do sistema podem ser ignorados por um momento 
estudando-se separadamente cada um dos modelos;
2. Comunicação entre as pessoas envolvidas: os modelos de um 
sistema servem também para promover a difusão de informações relativas 
ao sistema entre os indivíduos envolvidos em sua construção;
3. Redução nos custos do desenvolvimento: a correção de erros 
no desenvolvimento de sistemas é menos custosa quando detectada e 
realizada ainda no(s) modelo(s) do sistema (por exemplo, é muito mais 
fácil corrigir uma maquete do que pôr abaixo parte de um edifício);
4. Previsão do comportamento futuro do sistema: o comportamento 
do sistema pode ser discutido mediante uma análise dos seus modelos, 
pois eles servem como um “laboratório” em que diferentes soluções 
para um problema relacionado à construção do sistema podem ser 
experimentadas.
A modelagem não se restringe a grandes sistemas. Até sistemas de software 
equivalentes a casas de cachorro poderão receber os benefícios da modelagem. 
Porém, é absolutamente verdadeiro que, quanto maior e mais complexo for o 
sistema, maior será a importância da modelagem.
Princípios da modelagem
O uso da modelagem tem uma rica história em todas as disciplinas de engenharia. Essa 
experiência sugere quatro princípios básicos de modelagem, descritos a seguir (BOCH 
et al, 2006):
A escolha dos modelos a serem criados têm profunda influência sobre a maneira como 
um determinado problema é atacado e como uma solução é definida.
Em outras palavras, os modelos devem ser bem escolhidos. Os modelos corretos 
iluminarão de forma brilhante os problemas de desenvolvimento mais complicados, 
proporcionando conclusões que simplesmente não seriam possíveis de outra maneira. 
Modelos inadequados causarão confusões, desviando a atenção para questões 
irrelevantes. É importante destacar que a escolha dos modelos poderá ser modificada, 
11
INTRODUÇÃO I UNIDADE I
de maneira significativa, de acordo com a visão de mundo da pessoa envolvida. Apesar 
desse fato, o ponto mais importante é que cada visão de mundo conduz a um tipo 
diferente de sistema, com custos e benefícios diversos.
Cada modelo poderá ser expresso em diferentes níveis de precisão.
Ao desenvolver um sistema complexo, às vezes poderá ser necessária uma visão 
panorâmica, e em outros momentos, poderá ser preciso retornar ao nível dos alicerces. 
Por exemplo, em sistemas de software, às vezes um modelo de interface para o usuário, 
de execução rápida e simples, será exatamente o que será preciso, em outros casos, será 
necessário retornar a níveis mais baixos, como ao especificar as interfaces para várias 
plataformas. Em qualquer situação, os melhores tipos de modelos serão aqueles que 
permitem a escolha do grau de detalhamento, dependendo de quem esteja fazendo a 
visualização e por que deseja fazê-la. 
Os melhores modelos estão relacionados à realidade.
Será melhor utilizar modelos que tenham uma clara conexão com a realidade e, nos 
casos em que essa conexão seja fraca, saber de maneira exata, como esses modelos 
diferem do mundo real. O segredo será ter certeza de que sua simplificação não ocultará 
detalhes importantes. No caso de softwares o problema maior está no fato de não haver 
uma conexão básica entre o modelo de análise e o modelo de projeto do sistema. Falhas 
nessa conexão podem resultar, ao longo do tempo, em uma divergência entre o sistema 
concebido e o sistema construído.
Nenhum modelo único é suficiente. Qualquer sistema não trivial será melhor 
investigado por meio de um pequeno conjunto de modelos quase independentes.
Não existe um modelo que por si só esboce todos os detalhes de um software. Para 
compreender sua arquitetura existem diversas visões que contém aspectos estruturais 
e comportamentais que em conjunto representam a base de um projeto de software.
Por que modelar software?
Qual a real necessidade de se modelar um software? Muitos “profissionais” 
podem afirmar que conseguem determinar todas as necessidades de um 
sistema de informação de cabeça, e que sempre trabalharam assim. Qual a real 
necessidade de se projetar uma casa? Um pedreiro experiente não é capaz de 
construí-la sem um projeto? Isso pode ser verdade, mas a questão é muito mais 
ampla, envolvendo fatores extremamente complexos, como levantamento e 
12
UNIDADE I INTRODUÇÃO
análise de requisitos, prototipação, tamanho do projeto, complexidade, prazos, 
custos, documentação, manutenção e reusabilidade, entre outros. Existe uma 
diferença gritante entre construir uma pequena casa e construir um prédio 
de vários andares. Obviamente, para se construir um edifício é necessário, em 
primeiro lugar, desenvolver um projeto muito bem-elaborado, cujos cálculos 
têm de estar extremamente corretos e precisos. Além disso, é preciso fornecer 
uma estimativa de custos, determinar em quanto tempo a construção estará 
concluída, avaliar a quantidade de profissionais necessária à execução da obra, 
especificar a quantidade de material a ser adquirida para a construção, escolher o 
local que o prédio será erguido etc. Grandes projetos não podem ser modelados 
de cabeça, nem mesmo a maioria dos pequenos projetos pode sê-lo, exceto, 
talvez, aqueles extremamente simples (GUEDES, 2011).
Na realidade, por mais simples que seja, todo e qualquer sistema deve ser modelado 
antes de se iniciar sua implementação, entre outras coisas, porque os sistemas de 
informação frequentemente costumam ter a propriedade de “crescer”, isto é, aumentar 
em tamanho, complexidadee abrangência. Muitos profissionais costumam afirmar que 
sistemas de software são “vivos”, porque nunca estão completamente finalizados. 
Na verdade, o termo correto seria “dinâmicos”, pois normalmente os sistemas de 
software estão em constante mudança. Tais mudanças são devidas a diversos fatores, 
como, por exemplo (GUEDES, 2011):
 » os clientes desejam constantemente modificações ou melhorias no 
sistema;
 » o mercado está sempre mudando, o que força a adoção de novas estratégias 
por parte das empresas e, consequentemente, de seus sistemas;
 » o governo seguidamente promulga novas leis e cria novos impostos e 
alíquotas ou, ainda, modifica as leis, os impostos e alíquotas já existentes, 
o que acarreta a manutenção no software.
Assim, um sistema de software precisa ter uma documentação extremamente 
detalhada, precisa e atualizada para que possa ser mantido com facilidade, rapidez e 
correção, sem produzir novos erros ao corrigir os antigos. Modelar um sistema é uma 
forma bastante eficiente de documentá-lo, mas a modelagem não serve apenas para 
isso: a documentação é apenas uma das vantagens fornecidas pela modelagem.
13
INTRODUÇÃO I UNIDADE I
Escrevendo modelos de software
A modelagem de um software implica em criar modelos de software, mas o que é 
realmente um modelo de software? Um modelo de software captura uma visão de um 
sistema físico, é uma abstração do sistema com certo propósito, como descrever aspectos 
estruturais ou comportamentais do software. Esse propósito determina o que deve 
ser incluído no modelo e o que é considerado irrelevante. Assim, um modelo descreve 
completamente aqueles aspectos do sistema físico que são relevantes ao propósito do 
modelo, no nível apropriado de detalhe.
A modelagem de sistemas de software, em geral, envolve a utilização de notações 
gráficas para a construção dos modelos. A partir de desenhos gráficos (diagramas) 
os desenvolvedores têm uma representação concisa do sistema. No entanto, embora 
diagramas consigam expressar diversas informações, em muitos momentos há a 
necessidade de adicionar informações na forma de texto, com o objetivo de explicar ou 
definir certas partes desse diagrama. Assim, dado um modelo de uma das perspectivas 
de um sistema, diz-se que o seu diagrama e a informação textual associada a ele formam 
a documentação desse modelo (BEZERRA, 2015).
A modelagem de sistemas de software consiste na utilização de notações 
gráficas e textuais com o objetivo de construir modelos que representam as 
partes essenciais de um sistema, considerando-se várias perspectivas diferentes 
e complementares.
Nos próximos capítulos, serão apresentados diversos modelos cujos componentes são 
desenhos gráficos, que seguem algum padrão lógico para a modelagem de sistemas de 
software.
Evolução histórica da modelagem de sistemas
A Lei de Moore é bastante conhecida na área de computação. Embora, seja, 
conhecida como lei, foi apenas uma declaração, feita em 1965 pelo engenheiro 
Gordon Moore, cofundador da Intel. A Lei de Moore estabelece que a “densidade 
de um transistor dobra em um período entre 18 e 24 meses”. Isso significa que 
se um processador pode ser construído hoje com capacidade de processamento 
P, em 24 meses pode-se construir um processador com capacidade 2P. Em 48 
meses, pode-se construir um com capacidade 4P, e assim por diante. Ou seja, a 
Lei de Moore implica uma taxa de crescimento exponencial na capacidade de 
processamento dos computadores. (BEZERRA, 2015).
O que a Lei de Moore tem a ver com a modelagem de sistemas de software?
14
UNIDADE I INTRODUÇÃO
O rápido crescimento da capacidade computacional das máquinas resultou na 
demanda por sistemas de software cada vez mais complexos, que tirassem proveito de 
tal capacidade. O surgimento desses sistemas complexos resultou na necessidade de 
reavaliação da forma de se desenvolver sistemas. Em função disso, desde o aparecimento 
do primeiro computador até os dias de hoje, as técnicas utilizadas para a construção 
de sistemas computacionais têm evoluído de forma impressionante principalmente no 
que diz respeito à modelagem de sistemas (BEZERRA, 2015).
A seguir, é apresentado um breve resumo histórico da evolução das técnicas de 
desenvolvimento de acordo com BEZERRA (2015):
 » Décadas de 1950/1960: os sistemas de software eram bastante 
simples. O desenvolvimento desses sistemas era feito de forma “ad-hoc”. 
Os sistemas eram significativamente mais simples e, consequentemente, 
as técnicas de modelagem também eram mais simples: era a época dos 
fluxogramas e dos diagramas de módulos;
O termo ad-hoc significa neste contexto “direto ao assunto” ou “direto ao que 
interessa”. Talvez o uso desse termo denote a abordagem dessa primeira fase 
do desenvolvimento de sistemas, na qual não havia um planejamento inicial. 
O código-fonte do programa a ser construído era ele próprio o modelo.
 » Década de 1970: nesta época, computadores mais avançados e 
acessíveis começaram a surgir. Houve uma grande expansão do mercado 
computacional. Sistemas mais complexos começavam a surgir. Por 
conseguinte, modelos mais robustos foram propostos. Neste período, 
surgem a programação estruturada e o projeto estruturado;
 » Década de 1980: nesta fase, os computadores se tornaram ainda mais 
avançados e baratos. Surge à necessidade por interfaces mais sofisticadas, 
o que originou a produção de sistemas de softwares mais complexos. 
O paradigma de modelagem estruturada surgiu no início desse período;
 » Início da década de 1990: este é o período em que surge um novo 
paradigma de modelagem, o paradigma da orientação a objetos (conceito 
que será abordado nos próximos capítulos);
 » Fim da década de 1990: o paradigma da orientação a objetos atinge 
sua maturidade. Os conceitos de padrões de projeto, frameworks, 
componentes e qualidade começam a ganhar espaço. Surge a Linguagem 
15
INTRODUÇÃO I UNIDADE I
de Modelagem Unificada (UML) (conceito que será abordado nos 
próximos capítulos).
1. Dê o conceito de modelo no processo de desenvolvimento de software.
2. Quais são as razões para a utilização de modelos para a construção de 
sistemas de software?
3. Cite os quatro princípios básicos da modelagem.
4. Explique com suas palavras o histórico da evolução das técnicas de 
desenvolvimento de sistemas.
5. Pesquise e responda: Após a década de 1990 surgiram novas técnicas 
de desenvolvimento de software? Quais? Explique.
16
CAPÍTULO 2
Introdução à orientação a objetos
A construção de um sistema de software consiste, normalmente, no mapeamento do 
problema a ser resolvido no mundo real (o espaço do problema) em um modelo de 
solução no espaço de soluções, ou seja, o meio computacional. A modelagem envolve, 
então, a identificação de objetos e operações relevantes no mundo real e o mapeamento 
desses em representações abstratas no mundo computacional. 
A distância existente entre o problema no mundo real e o modelo abstrato construído, 
convencionou-se chamar gap semântico e, obviamente, quanto menor ele for, mais 
direto será o mapeamento e, portanto, mais rapidamente serão construídas soluções 
para o problema. Sob essa ótica, diversas técnicas e métodos têm sido propostos para as 
diferentes fases do processo de desenvolvimento de software, buscando minimizar esse 
problema. Um exemplo indispensável e o paradigma da orientação a objetos.
Há alguns anos, Alan Key, um dos pais da orientação a objetos, pensou em como 
construir um sistema de software a partir de agentes autônomos que interagem entre 
si. Com isso, ele estabeleceu os seguintes princípios da orientação a objetos (BEZERRA, 
2015):
1. qualquer coisa é um objeto;
2. objetos realizam tarefas por meio da requisição de serviços a outros 
objetos;
3. cada objeto pertence a uma determinada classe. Uma classe agrupa 
objetos similares;
4. a classe é um repositório para comportamento associado ao objeto;
5. classes são organizadas em hierarquias.
O paradigma de orientação a objetos visualizaum sistema de software como uma coleção 
de agentes interconectados chamados objetos. Cada objeto é responsável por realizar 
tarefas específicas. Para cumprir com algumas das tarefas sob sua reponsabilidade, um 
objeto pode ter que interagir com outros objetos. É pela interação entre objetos que 
uma tarefa computacional é realizada (BEZERRA, 2015).
17
INTRODUÇÃO I UNIDADE I
É o paradigma de orientação a objetos que os seres humanos utilizam no 
cotidiano para a resolução de problemas, uma pessoa atende a mensagens 
(requisições) para realizar um serviço; essa mesma pessoa envia mensagens a 
outras para que elas realizem serviços. Por que não aplicar essa mesma forma de 
pensar à modelagem de sistemas?
A orientação a objetos oferece um número de conceitos bastante apropriados para a 
modelagem de sistemas. Os modelos baseados em objetos são úteis para a compreensão 
de problemas, para a comunicação com os especialistas e usuários das aplicações, e 
para a realização das tarefas ao longo do ciclo de desenvolvimento de software.
A orientação a objetos, como técnica para modelagem de sistemas, diminui a 
diferença semântica entre a realidade modelada e os modelos construídos.
Vantagens/benefícios da orientação a objetos
A utilização do paradigma da orientação a objetos apresenta uma série de vantagens, 
cada vez mais necessárias no atual desenvolvimento de sistemas computacionais. Entre 
tais vantagens, podem ser destacadas as seguintes (CORREIA; TAFNER, 2006):
 » Gap semântico reduzido: o mundo real é composto por objetos, 
e o mesmo ocorre com o mundo computacional, facilitando assim a 
compreensão; 
 » Centralização de dados e funções: os dados e as funções são 
centralizados em uma única unidade, o objeto; 
 » Reutilização: o conceito de herança em orientação a objetos (conceito 
que será visto mais adiante), permitindo um ganho significativo de tempo 
e custo; 
 » Modularização: não só no que se refere aos pacotes, mas principalmente 
ao tratamento de classes; 
 » Compatibilidade: os modelos desenvolvidos (análise, projeto e 
programação) são claramente relacionados e complementares;
 » Manutenibilidade: as classes centralizam os dados e funções daquilo 
que tratam, ficando mais fácil localizar os pontos necessários em uma 
manutenção, evitando parcialmente o verdadeiro efeito “bola de neve” 
que uma manutenção mal planejada pode causar;
18
UNIDADE I INTRODUÇÃO
 » Ocultamento de Informação: uma classe enxerga apenas a interface 
de outra classe, o que evita vários erros acidentais.
Além dessas vantagens, um grande benefício da orientação a objetos consiste em reunir 
em uma mesma estrutura dos dados e processos que são executados sobre esses dados, 
permitindo assim um maior grau de organização e simplicidade do sistema de software.
Princípios básicos da orientação a objetos
Conforme dito, a orientação a objetos é um paradigma de análise, projeto e programação 
de sistemas de software baseado na composição e interação entre diversas unidades 
de software chamadas objetos. Esses objetos do sistema representam instâncias das 
entidades existentes no mundo real (do domínio do sistema), descritas por meio de 
classes que englobam atributos, operações e relacionamentos.
Os principais objetivos da orientação a objetos são:
 » diminuir a distância conceitual entre o mundo real (domínio do problema) 
e o modelo abstrato de solução (domínio da solução); 
 » trabalhar com noções intuitivas (objetos e ações) durante todo o ciclo de 
vida, atrasando, ao máximo, a introdução de conceitos de implementação.
Segundo os autores Coad e Yourdon (1993), a abordagem da orientação a objetos segue 
cinco princípios básicos de administração da complexidade e modelagem de domínio 
e projeto:
 » Abstração: é relativo à diminuição da atenção em aspectos menos 
importantes e ao aumento da percepção do que é realmente relevante em 
um determinado aspecto do mundo real. Abstração é também definido 
como um conceito que englobe atributos e serviços referentes a um 
determinado propósito;
 » Encapsulamento: a ideia do encapsulamento está ligada à ocultação 
dos detalhes de implementação de um determinado objeto do sistema. 
O encapsulamento ajuda a minimizar o trabalho de desenvolvimento de 
um novo sistema, pois se torna mais fácil utilizar partes do programa 
de forma isolada. Estas partes refletem a modelagem de requisitos 
específicos do projeto, com interfaces para serviços de interesse de outras 
partes do projeto;
19
INTRODUÇÃO I UNIDADE I
 » Herança: o conceito de herança está centrado na ideia de organizar uma 
taxonomia entre as classes do domínio, evidenciando as semelhanças 
entre classes em relação a atributos e serviços;
 » Associação: as associações presentes nessa abordagem têm como 
princípio explicitar a relação entre abstrações do mundo real. Pode-se 
dizer, inclusive, que a hierarquia é um tipo de associação, comumente 
chamada de generalização ou especialização;
 » Comunicação com mensagens: é a maneira pela qual os objetos 
do sistema se comunicam, já que de acordo com os princípios gerais 
da abordagem orientada a objetos, os objetos podem realizar ou obter 
serviços de outros objetos que encapsulam aspectos complexos do 
sistema.
Um bom resumo do que pode ser considerado um sistema orientado a objeto: 
“Um sistema construído usando um método orientado a objetos é aquele cujos 
componentes são partes encapsuladas de dados e funções, que podem herdar 
atributos e comportamento de outros componentes da mesma natureza, e 
cujos componentes comunicam-se entre si por meio de mensagens” (COAD; 
YOURDAN, 1993).
1. O que é o paradigma de orientação a objetos? Quais os seus princípios.
2. Cite 4 vantagens da utilização do paradigma de orientação a objetos 
para a modelagem de sistemas de software.
3. Quais são os principais objetivos da orientação a objetos?
4. Cite os cinco princípios básicos da orientação a objetos para a 
administração da complexidade na modelagem de sistemas.
5. Considere o mapa de uma cidade que mostra rodovias e prédios em 
que esconde prédios. Um mapa pode ser considerado um modelo? Por 
quê? Discuta as características desse mapa com relação ao princípio 
de Abstração.
20
UNIDADE II
PRINCIPAIS CONCEITOS 
DA ORIENTAÇÃO A 
OBJETOS
CAPÍTULO 1
Objetos e classes
O mundo real é formado de coisas. Como exemplos dessas coisas, pode-se citar um 
cliente, uma loja, uma venda, um pedido de compra, um fornecedor etc. Na terminologia 
de orientação a objetos, essas coisas do mundo real são denominadas “objetos” 
(BEZERRA, 2015). Do ponto de vista da modelagem de sistemas, um objeto é uma 
entidade que incorpora uma abstração relevante non contexto de uma aplicação. 
Um objeto possui um “estado” (informação), exibe um “comportamento” bem definido, 
expresso por um número de operações para examinar ou alterar o estado, e tem 
“identidade” única. Em outras palavras, um objeto é algo que precisa ser representado 
computacionalmente e que tem propriedades próprias, um comportamento e uma 
identidade única.
Figura 1. Um objeto possui estado, exibe algum comportamento bem definido e possui identidade própria 
(BOOCH, 1994).
21
PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS │ UNIDADE II
O estado de um objeto compreende o conjunto de suas propriedades, associadas 
a seus valores correntes. Propriedades de objetos, são geralmente referenciadas 
como atributos e, portanto, o estado de um objeto diz respeito aos seus atributos 
e aos valores a eles associados. (BOOCH, 1994).
A comunicação entre objetos dá-se por meio de troca de “mensagens”. Para acessar a 
informação de estado de um objeto, é necessário enviar uma mensagem para ele. Uma 
mensagem consiste do nome de uma operação e os argumentos requeridos. Assim, o 
comportamento de um objeto representa como este objeto reage às mensagens a ele 
enviadas.
O conjunto de mensagens o que um objeto pode responder representa 
seu comportamento. Um objeto é, pois, uma entidade que tem seu estadorepresentado por um conjunto de atributos (uma estrutura de informação) e seu 
comportamento representado por um conjunto de operações. (BOOCH, 1994).
Figura 2. Objetos interagem por meio do envio de mensagens.
 
Objet
Objet
Objet
Objet
Objet Objet
Cada objeto tem uma identidade própria, que lhe é inerente. Todos os objetos 
têm existência própria, ou seja, dois objetos são distintos mesmo se seu estado e 
comportamento forem iguais. No mundo real, um objeto limita-se a existir, mas, no 
que se refere ao mundo computacional, cada objeto dispõe de um identificador único 
pelo qual pode ser referenciado inequivocamente.
Seres humanos costumam agrupar objetos. Provavelmente, realizam esse processo 
mental de agrupamento para tentar gerenciar a complexidade de entender as coisas 
do mundo real. De fato, é bem mais fácil entender a ideia martelo do que entender 
todos os martelos que existem. Na terminologia da orientação a objetos, cada ideia é 
denominada “classe de objetos”, ou simplesmente “classe”. Uma classe é a descrição 
dos atributos e serviços comuns a um grupo de objetos. Sendo assim, pode-se entender 
uma classe como sendo um molde a partir do qual objetos são construídos. 
22
UNIDADE II │ PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS
Ainda sobre terminologia, diz-se que um objeto é uma “instância” de uma classe 
(BEZERRA, 2015).
A ênfase da orientação a objetos é dada na criação das classes, e não dos objetos, 
como se poderia pensar pelo nome.
É importante notar que, classe é uma abstração das características de um grupo de coisas 
do mundo real. Na maioria das vezes, as coisas do mundo real são muito complexas 
para que todas as suas características sejam representadas em uma classe. Além disso, 
para fins de modelagem de um sistema, somente um subconjunto de características 
pode ser relevante. Portanto, uma classe representa uma abstração das características 
relevantes do mundo real (BEZERRA, 2015).
Pressman (2006) classifica e mostra exemplos de objetos relacionados com 
sistemas de software. São eles:
 » entidades externas: (outros sistemas, dispositivos, pessoas etc.) que 
produzem ou consomem informação para ser usada por meio de um 
sistema de software; 
 » coisas: (relatórios, displays, sinais, letras etc.) que são partes do domínio 
da informação para o problema; 
 » ocorrências ou eventos: (uma transferência de propriedade, o aspecto 
dos movimentos de robôs etc.) que ocorrem dentro do contexto da 
operação do sistema; 
 » papéis: (gerente, engenheiro, vendedor etc.) executados por pessoas 
que interagem com o sistema; 
 » unidades organizacionais: (divisões, grupos, times etc.) que são 
relevantes para o sistema; 
 » locais: (chão de fábrica, locais de carga etc.) que estabelecem o 
contexto do problema e as funções gerais do sistema; 
 » Estruturas: (sensores, computadores, veículos etc.) que definem uma 
classe de objetos ou, no extremo, classes relacionadas de objetos.
23
PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS │ UNIDADE II
Mensagens e métodos
A abstração incorporada por um objeto é caracterizada por um conjunto de operações que 
podem ser requisitadas por outros objetos, ditos clientes. Métodos são implementações 
reais de operações. Para que um objeto realize alguma tarefa, é necessário enviar a ele 
uma mensagem, solicitando a execução de um método específico. Um cliente só pode 
acessar um objeto por meio da emissão de mensagens, isto é, ele não pode acessar ou 
manipular diretamente os dados associados ao objeto. Os objetos podem ser complexos 
e o cliente não precisa tomar conhecimento de sua complexidade interna. O cliente 
precisa saber apenas como se comunicar com o objeto e como ele reage.
Embora existam diferentes tipos de operações, elas podem ser divididas em três 
categorias (PRESSMAN, 2002):
 » operações que manipulam dados;
 » operações que executam cálculos computacionais;
 » operações que monitoram um objeto para ocorrência de um evento de 
controle.
Conforme dito anteriormente, as mensagens são o meio de comunicação entre objetos 
e são responsáveis pela ativação de todo e qualquer processamento. Dessa forma, é 
possível garantir que clientes não serão afetados por alterações nas implementações de 
um objeto que não alterem o comportamento esperado de seus serviços. Vale lembrar 
que uma mensagem estimula a ocorrência de algum comportamento no objeto receptor 
da mesma e o comportamento é estabelecido quando uma operação é executada.
Diferencie objeto, classe e instância.
1. Para atender às necessidades de informação de uma biblioteca 
universitária. Identifique os possíveis objetos/classes para esse sistema 
e como eles trocam mensagens entre si
24
CAPÍTULO 2
Abstração, encapsulamento, herança e 
polimorfismo
O mundo real é extremamente complexo. Tal complexidade pode ser percebida ao 
analisar os detalhes de tal mundo, mesmo que concentrando em algum objeto em 
particular. Essa característica é transferida para o mundo computacional, quando da 
criação de uma solução computadorizada para um problema do mundo real. Alguns 
dos elementos fundamentais na geração desta complexidade são:
 » a complexidade do próprio domínio do problema; 
 » a dificuldade no gerenciamento do processo de desenvolvimento do 
sistema necessário;
 » o leque de variadas soluções que podem ser encontradas no projeto do 
sistema. 
A orientação a objetos procura administrar essa complexidade por meio de uma série 
de conceitos, conforme introduzido em capítulos anteriores, tais como abstração, 
encapsulamento, polimorfismo e herança, os quais são descritos a seguir.
Abstração
Uma das principais formas do ser humano lidar com a complexidade e por meio do 
uso de abstrações. As pessoas geralmente tentam compreender o mundo construindo 
modelos mentais de partes dele. Tais modelos são uma visão simplificada de algo, dos 
quais apenas elementos relevantes são considerados. Modelos mentais, portanto, são 
mais simples do que os complexos sistemas que eles modelam. 
Considerando, por exemplo, um mapa como um modelo do território que ele representa. 
Um mapa é útil porque abstrai apenas aquelas características do território que se deseja 
modelar. Se um mapa incluísse todos os detalhes do território, provavelmente teria o 
mesmo tamanho do território e, portanto, não serviria a seu propósito. 
Da mesma forma que um mapa precisa ser significativamente menor que o território 
que mapeia, incluindo apenas informações cuidadosamente selecionadas, um 
modelo mental abstrai apenas as características relevantes de um sistema para seu 
entendimento. Assim, pode-se definir abstração como sendo o princípio de ignorar 
25
PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS │ UNIDADE II
aspectos não relevantes de um assunto, segundo a perspectiva de um observador, 
tornando possível uma concentração maior nos aspectos principais do mesmo. 
De fato, a abstração consiste na seleção que um observador faz de alguns aspectos de um 
assunto, em detrimento de outros que não demonstram ser relevantes para o propósito 
em questão, ou seja, a abstração é aplicada de acordo com o interesse do observador, e 
por isso de um mesmo objeto pode-se ter diferentes visões, como demonstra a Figura 3. 
Figura 3. A abstração enfoca as características essenciais de um objeto.
Fonte: (BOOCH,1994)
Uma abstração é qualquer modelo que inclui os aspectos mais importantes 
(essenciais) de alguma coisa, ao mesmo tempo em que ignora os detalhes menos 
importantes. Abstrações permitem gerenciar a complexidade e concentrar a 
atenção nas características essenciais de um objeto. Note que uma abstração é 
dependente da perspectiva: o que é importante em um contexto pode não ser 
importante em outro (BEZERRA, 2015).
Encapsulamento
No mundo real, um objeto pode interagir com outro sem conhecer seu funcionamento 
interno. Uma pessoa, por exemplo, geralmente utiliza uma televisão sem saber 
efetivamente qual a sua estrutura interna ou como seus mecanismos internossão 
ativados. Para utilizá-la, basta saber realizar algumas operações básicas, tais como ligar/
desligar a televisão, mudar de um canal para outro, regular volume, cor etc. Como estas 
operações produzem seus resultados, mostrando um programa na tela, não interessa 
ao telespectador.
26
UNIDADE II │ PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS
O mecanismo de “encapsulamento” é uma forma de restringir o acesso ao comportamento 
interno de um objeto. Um objeto que precise da colaboração de outro objeto para 
realizar alguma tarefa simplesmente envia uma mensagem a este último. 
O método que o objeto requisitado usa para realizar a tarefa não é conhecido dos objetos 
requisitantes (BEZERRA, 2002). 
Certamente, o objeto requisitante precisa conhecer quais as tarefas que outro objeto 
sabe fazer ou que informação ele conhece. Para tanto, a classe de um objeto descreve 
o seu comportamento. Na terminologia da orientação a objetos, diz-se que um objeto 
possui uma “interface” (Figura 4). 
Em termos bastantes simples, a interface de um objeto é O QUE ele conhece e o 
que ele sabe fazer, sem descrever COMO o objeto o faz. A interface de um objeto 
define os serviços que ele pode realizar e consequentemente as mensagens que 
ele recebe. Uma interface pode ter várias formas de implementação. Mas, pelo 
Princípio do Encapsulamento, a implementação de um objeto requisitado não 
importa para um objeto requisitante (BEZERRA, 2015).
Figura 4. Princípio do encapsulamento: visto externamente, o objeto é a sua interface.
Fonte: (BEZERRA, 2015).
Mediante o encapsulamento, a única coisa que um objeto precisa saber para pedir 
a colaboração de outro objeto é conhecer a sua interface. Isso contribui para a 
autonomia dos objetos. Cada objeto envia mensagens a outros objetos para realizar 
certas tarefas, sem se preocupar em como as tarefas são realizadas. A aplicação da 
abstração, neste caso, está em esconder os detalhes de funcionamento interno de um 
objeto (BEZERRA, 2015).
27
PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS │ UNIDADE II
Figura 5. O encapsulamento oculta os detalhes de implementação de um objeto.
Fonte: (BOOCH,1994).
Abstração X encapsulamento
Abstração e encapsulamento são conceitos complementares: enquanto 
a abstração enfoca o comportamento observável de um objeto (o que se 
deve mapear), o encapsulamento enfoca a implementação que origina esse 
comportamento (como realizar a abstração). Encapsulamento é frequentemente 
conseguido por meio do ocultamento de informação, ou seja, escondendo 
detalhes que não contribuem para suas características essenciais. Geralmente, 
em um sistema orientado a objetos, a estrutura de um objeto, e a implementação 
de seus métodos, são encapsuladas (BOOCH, 1994).
A principal motivação para o encapsulamento é facilitar a reutilização de objetos e 
garantir estabilidade aos sistemas. Um encapsulamento bem feito pode servir de base 
para a localização de decisões de projeto que necessitam ser alteradas. Uma operação 
pode ter sido implementada de maneira ineficiente e, portanto, pode ser necessário 
escolher um novo algoritmo. Se a operação está encapsulada, apenas o objeto que a 
define precisa ser modificado, garantindo estabilidade ao sistema.
Herança
A herança é outra forma de abstração utilizada na orientação a objetos. As características 
e o comportamento comuns a um conjunto de objetos podem ser abstraídos em uma 
classe. A herança pode ser vista comum nível de abstração acima da encontrada entre 
classes e objetos (BEZERRA, 2002).
O conceito de herança na orientação a objetos lembra o conceito de herança 
genética, na qual um elemento descendente herda as características de um 
elemento ancestral.
28
UNIDADE II │ PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS
Na herança, classes semelhantes são agrupadas em hierarquias (ver Figura 6). Cada 
nível de uma hierarquia pode ser visto como um nível de abstração. Cada classe em um 
nível da hierarquia herda as características das classes nos níveis acima. Esse mecanismo 
facilita o compartilhamento de comportamento comum entre um conjunto de classes 
semelhantes. Além disso, as diferenças ou variações de uma classe em particular podem 
ser organizadas de forma mais clara (BEZERRA, 2002).
Figura 6. Princípio da herança: classes podem ser organizadas em hierarquias. 
 
FIGURA 
FIGURA LINHA 
é um tipo é um tipo 
QUADRADO CÍRCULO
é um tipo é um tipo 
Maior 
abstração 
Menor 
abstração 
Fonte: Adaptada de (BEZERRA, 2015).
De acordo com o exemplo da Figura 6, pode-se dizer que a classe “Figura Geométrica” 
é subclasse (descendente ou filha) da classe “Figura” e superclasse (ancestral) da classe 
“Quadrado”.
Um conjunto de abstrações frequentemente forma uma hierarquia e, pela 
identificação dessas hierarquias, é possível simplificar significativamente o 
entendimento sobre um problema (BOOCH, 1994). Em suma, hierarquia é uma 
forma de arrumar as abstrações.
Formas de herança
Há dois tipos de herança na orientação a objetos: simples e múltipla. A herança é 
denominada “simples” quando uma classe herda características de apenas uma 
superclasse. Por exemplo, pode-se ter como superclasse uma classe chamada Pessoa, e 
dela derivar uma subclasse chamada Funcionário. Esta nova classe, Funcionário, herda 
todas as características da sua superclasse Pessoa, e de mais nenhuma outra. Nada 
impede, entretanto, que uma mesma superclasse gere mais de uma subclasse. 
Por exemplo, uma superclasse Pessoa pode gerar uma subclasse Cliente da mesma 
forma que pode gerar uma subclasse Funcionário, conforme mostrado na Figura 7.
29
PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS │ UNIDADE II
Figura 7. Herança simples com dois descendentes.
 
PESSOA 
FUNCIONÁRIO CLIENTE 
é um tipo é um tipo 
A herança é denominada múltipla quando uma classe herda características de duas ou 
mais superclasses. Usando o exemplo do Funcionário e do Cliente, deve-se estar atento 
para o fato de que um funcionário pode vir a ser um cliente também. Para tanto, o que 
pode ser feito é criar uma nova subclasse clamada Funcionário-Cliente, que tem como 
superclasses as classes Funcionário e Cliente, conforme mostrado na Figura 8. Esta 
nova classe, Funcionário-Cliente, herda todas as características de Pessoa, Funcionário 
e Cliente.
Figura 8. Herança múltipla.
 
PESSOA 
FUNCIONÁRIO CLIENTE 
é um tipo de é um tipo de 
FUNCIONÁRIO-CLIENTE 
é um tipo de é um tipo de 
Polimorfismo
Polimorfismo é a propriedade de uma ou mais classes responderem a mesma mensagem, 
cada uma de uma forma diferente. Uma mesma mensagem pode apresentar formas de 
execução diferentes, próprias de cada objeto. Um exemplo de polimorfismo é mostrado 
na Figura 9. Cavalo e gato são tipos de mamífero e emitir som é uma ação que todos eles 
fazem, só que cada um de uma forma diferente.
O polimorfismo é uma característica da orientação a objetos que está diretamente 
ligada à herança. Pode-se dizer que uma operação (método) que já foi definida 
no ancestral redefinido no descendente com um comportamento diferente.
30
UNIDADE II │ PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS
Figura 9. Exemplo de polimorfismo.
 
MAMÍFERO 
CAVALO GATO 
é um tipo de é um tipo de 
emitir som 
1. Diferencie herança e polimorfismo e mostre exemplos para cada um 
deles.
31
CAPÍTULO 3
Agregação/composição e 
generalização/especialização
Em qualquer sistema os objetos se comunicam, trocando mensagens. Em sistemas 
não triviais, geralmente, existe uma quantidade razoável de objetos e classes e há 
necessidade de gerenciar tais elementos. Assim, é preciso estruturar as classes. 
Vários mecanismos têm sido propostos nesse sentido, alguns deles são apresentados 
a seguir.
Generalização/especialização
Muitas vezes, um conceito geral pode ser especializado, adicionando-se novas 
características. Da maneira inversa, pode ser extraído de um conjunto de conceitos, 
características comuns que, quando generalizadas, formam um conceito geral. 
As abstraçõesde especialização e generalização estão estritamente relacionadas com 
o princípio de Herança apresentado anteriormente. Com elas, é possível construir 
hierarquias de classes, subclasses, subsultasses, e assim por diante.
Nesse sentido, a generalização permite generalização permite abstrair, a partir de um 
conjunto de classes, uma classe mais geral contendo todas as características comuns. 
A especialização é a operação inversa e, portanto, permite especializar uma classe em 
um número de subclasses, explicitando as diferenças entre as novas subclasses. Deste 
modo é possível compor a hierarquia de classes. Esses tipos de relacionamento são 
conhecidos também como relacionamentos “é um tipo de”, onde um objeto da subclasse 
também “é um tipo de” objeto da superclasse. Neste caso uma instância da subclasse é 
dita uma instância indireta da superclasse.
Para mostrar um exemplo da aplicação da estrutura generalização/especialização será 
usado o mesmo exemplo apresentado nas formas de herança, aquele que trata das 
classes Pessoa, Funcionário e Cliente. Nesse caso, tem-se a classe Pessoa como a mais 
alta classe generalizada, sendo então a superclasse da estrutura. 
Abaixo dela encontram-se as suas subclasses, Funcionário e Cliente, que nada mais 
são que especializações da classe Pessoa. A Figura 10 identifica a classe genérica e as 
abstrações.
32
UNIDADE II │ PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS
Figura 10. Exemplo de uma estrutura generalização/especialização.
 
PESSOA 
Nome 
RG 
CPF 
FUNCIONÁRIO 
Matrícula 
Salário 
CLIENTE 
Limite Crédito 
Preferências 
Fonte: Autor.
Resumindo os conceitos complementares de hierarquia, herança, generalização e 
especialização:
 » hierarquia: mecanismo para organização de classes que se relacionam de 
maneira estruturada e ordenada, em níveis;
 » herança: mecanismo que permite que uma subclasse herde características 
de sua superclasse;
 » generalização: mecanismo que permite extrair conceitos comuns de 
várias classes, posicionando-os em um local comum e compartilhado, a 
superclasse;
 » especialização: mecanismo que permite especializar um conceito comum, 
refinando características, por meio de adição e/ou modificação de itens, 
criando diferentes subclasses.
Agregação/composição
Uma forma especial de relacionamento entre objetos é a composição ou agregação. 
Parte do poder dos softwares orientados a objetos advém de sua habilidade de 
manipular objetos complexos, como sendo compostos de vários outros objetos mais 
simples. Um carro, por exemplo, é composto por motor, rodas, carroceria etc. 
Um motor, por sua vez, é composto de bloco, válvulas, pistões, e assim por diante.
33
PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS │ UNIDADE II
Nesse sentido, composição é o relacionamento todo-parte/uma-parte-de onde os 
objetos representando os componentes de alguma coisa são associados a um objeto 
representando o todo. Em outras palavras, a composição é um tipo forte de associação, 
do qual um objeto agregado é composto de vários objetos componentes.
A principal diferença entre composição e agregação é que a composição é 
ainda um tipo mais forte de agregação. Na agregação, um objeto-parte pode 
continuar existindo mesmo com a exclusão do objeto-todo. Por exemplo, carro 
e motor. Ao se excluir o objeto-todo, basta excluir os relacionamentos dele com 
os objetos-parte. Na composição um objeto-parte não continua existindo se o 
objeto-todo for excluído. Por exemplo, nota fiscal e item de nota fiscal. Ao se 
excluir o objeto-todo, devem excluir os objetos-parte a ele associados.
Um bom exemplo para ilustrar a composição/agregação pode ser a relação entre um 
carro e seus componentes, conforme mostrado na Figura 11. O carro tratado como um 
objeto pode ser decomposto em diversos outros objetos, como o motor, as rodas, o 
painel, o banco, as portas etc. Pode-se seguir com a decomposição e avançar sobre o 
motor, que pode ser dividido em distribuidor, carburador etc. Portanto, percebe-se que 
um objeto mais complexo, muitas vezes, nada mais é que um agregado de diversos 
outros objetos mais simples.
Figura 11. Exemplo de uma estrutura agregação/composição.
 
CARRO 
 
MOTOR 
 
RODA 
Fonte: Autor.
34
UNIDADE II │ PRINCIPAIS CONCEITOS DA ORIENTAÇÃO A OBJETOS
Agregação/composição também possui outro componente, a cardinalidade, 
que significa quantos elementos fazem parte da estrutura. Por exemplo, o carro 
possui quatro rodas (cinco para o caso do estepe), que sob o ponto de vista da 
análise, são todas iguais, ou seja, cada roda é igual à outra. Assim, uma roda como 
objeto se repete de quatro a cinco vezes dentro do objeto carro. Estendendo a 
cardinalidade também ao motor do carro exemplo, tem-se uma relação de 0-1 
do motor com o carro, e de 1-1 do carro para com o motor. Em outras palavras, 
o motor pode estar em nenhum ou um carro, e o carro deve ter no mínimo um 
motor e no máximo um também. Não se tem visto até o momento carro com 
dois motores, mas certamente existem vários motores sem carro (em oficinas 
mecânicas, por exemplo).
1. Mostre exemplos de agregação/composição e especialização/
generalização.
35
UNIDADE IIIMODELAGEM DE 
SISTEMAS COM UML
CAPÍTULO 1
Introdução à UML: histórico e conceitos
Breve histórico da UML
Considerando a evolução histórica da modelagem de sistemas apresentado no Capítulo 
2 da Unidade I, um detalhamento da primeira metade da década de 1990, mostra 
que surgiram várias propostas de técnicas para modelagem de sistemas segundo o 
paradigma orientado a objetos. O quadro 1 lista algumas das técnicas existentes durante 
esse período, do qual nota-se uma grande proliferação de propostas para a modelagem 
de orientada a objetos. Era comum duas técnicas possuírem diferentes notações gráficas 
para modelar uma mesma perspectiva de um sistema. 
Ao mesmo tempo, cada técnica tinha seus pontos fortes e fracos em relação à notação 
utilizada (BEZERRA, 2015).
A essa altura percebeu-se a necessidade da existência de uma linguagem que viesse a se 
tornar um padrão para a modelagem de sistemas, que fosse aceita e utilizada amplamente 
pela indústria e pelos ambientes acadêmicos. Surgiram, então, alguns esforços nesse 
sentido de padronização, o que resultou na definição da UML (Unified Modeling 
Language) em 1996, como a melhor candidata para ser a linguagem “unificadora” 
de notações, diagramas e formas de representação existentes em diferentes técnicas 
(BEZERRA, 2015).
Embora a concepção da UML tenha sido influenciada por vários métodos de análise 
e projeto orientados a objeto, há particularmente três notações das quais a UML é 
derivada: BoochMethod, OMT e OOSE (conforme mostrado no quadro 1). Estes eram, 
até meados da década de 1990, os métodos de modelagem orientada a objetos mais 
populares entre os profissionais da área de desenvolvimento de software. A notação 
definida para UML é, então, uma união de diversas notações preexistentes, com alguns 
36
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
elementos removidos e outros elementos adicionados com o objetivo de torná-la 
expressiva.
Quadro 1. Principais propostas de técnicas de modelagem orientada a objetos durante a década de 1990.
ANO AUTOR (TÉCNICA)
1990 Shaler & Mellor.
1991 Coad & Yourdon (OOAD – Object-Oriented Analysis and Design).
1993 GradyBooch (BoochMethod).
1993 Ivar Jacobson (OOSE – Object-Oriented Software Engineering).
1995 James Rumbaugh et al (OMT – Object Modeling Technique).
1996 Wirfs-Broock (Responsability Driven Design)
1996 (Fusion).
Fonte: Adaptada de Bezerra (2015).
Em 1997, a OMG (Object Management Group) tornou a UML uma linguagem 
de modelagem padrão para aplicações orientadas a objeto. A importância dessa 
padronização está no fato de que a OMG possui mais de 800 filiados, incluindo empresas 
como IBM, HP, Borland etc. Ou seja, os principais softwares utilizados são modelados 
e idealizados por meio da UML (MATOS, 2002).
A versão 2.0 da UML foi oficialmente lançada emjulho de 2005 e a definição completa 
da UML está contida na Especificação da Linguagem de Modelagem Unificada da 
OMG. Essa especificação pode ser obtida gratuitamente no site da OMG, disponível 
em: <www.omg.org>.
Conceitos da UML
A UML é uma linguagem visual para modelar sistemas orientados a objeto. Isso 
quer dizer que a UML é uma linguagem constituída de elementos gráficos (visuais) 
utilizados na modelagem que permitem representar os conceitos do paradigma da 
orientação a objetos. Por meio dos elementos gráficos definidos nesta linguagem podem 
ser construidos diagramas que representam diversas perspectivas de um sistema 
(BEZERRA, 2015).
Cada elemento gráfico possui uma sintaxe (ou seja, uma forma predeterminada 
de desenhar o elemento) e uma semântica que definem o que significa o elemento e 
para quê ele deve ser utilizado. Além disso, conforme descrito mais adiante, tanto à 
sintaxe quanto a semântica da UML são extensíveis. Essa extensibilidade permite que 
a UML seja adaptada às características específicas de casa projeto de desenvolvimento 
(BEZERRA, 2015).
37
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
Por que a UML é uma linguagem? Realmente soa estranho dizer que a UML é uma 
linguagem, sabendo que sua função é bem parecida com a de outras ferramentas 
de modelagem, tais como o Diagrama de Fluxo de Dados (DFD), o Diagrama 
de Entidades e Relacionamentos (DER) etc. Obviamente que se questiona: “... 
quer dizer que esses outros diagramas também são uma linguagem? ” Uma 
linguagem (mesmo as do mundo da informática) deve seguir uma gramática (em 
que todos os elementos básicos de representação sejam indicados) e também a 
um conjunto de regras sintáticas, tal qual o idioma português. Talvez faltasse aos 
outros diagramas essa rigidez sintática em que outro diagrama (mesmo que no 
seu nível de abstração), devesse obedecer à sua sintática mantendo a semântica 
trazida de outro diagrama, ou seja, um diagrama, efetivamente, não se encaixava 
no outro, a não ser que se fizesse um grande esforço para enxergar, por exemplo, 
o que um DFD tem a ver com o seu respectivo DER. O esforço da UML é permitir 
que desde a representação das funções básicas do sistema (e seus respectivos 
responsáveis) até o planejamento da arquitetura de implementação, todo o 
processo aconteça de maneira coerente e com uma estreita ligação com o plano 
anterior (MATOS, 2002)
A UML é independente tanto de linguagens de programação quanto de processos de 
desenvolvimento. Isso quer dizer que, a UML pode ser utilizada para a modelagem de 
sistemas, não importa qual a linguagem de programação será utilizada na implementação 
do sistema, ou qual a forma (processo) de desenvolvimento adotada. 
Esse é um fator importante para a utilização da UML, pois diferentes sistemas de 
software requerem diferentes abordagens de desenvolvimento (BEZERRA, 2015). 
Mais detalhadamente, referem-se algumas das suas características:
 » é apenas uma sintaxe – a UML é apenas uma linguagem. Diz quais 
os elementos de modelagem, os diagramas disponíveis e as regras a eles 
associados. Não diz quais os diagramas a criar nem quando. Isso diz 
respeito à metodologia usada: Rational Unified Process (RUP), Feature 
Driven Development (FDD) etc.;
 » é abrangente – a UML pode ser usada para modelar uma grande 
variedade de sistemas e está concebida para poder ser atualizada de 
modo a satisfazer qualquer requisito de modelagem;
 » é independente da linguagem usada – a UML é independente da 
linguagem de alto nível a usar no código (Java, C++ etc.);
38
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
 » é independente do processo de criação dos modelos – o 
processo pelo qual os modelos são criados é independente da definição 
da linguagem. É necessário um processo desses além do uso da UML por 
si só;
 » linguagem bem documentada – o guia de notação da UML está 
disponível como referência para todas as sintaxes disponíveis na 
linguagem;
 » a sua aplicação não é rígida – o guia da notação UML não é suficiente 
para que se saiba usá-la, já que se trata de uma linguagem de modelagem 
genérica que por isso necessita de ser adaptada a cada situação em 
particular.
A UML é uma composição das boas características de outras notações de 
ferramentas direcionadas à orientação a objetos. Ou seja, a UML é aferra menta 
ideal para criar, compreender, testar, validar, arquitetar (lógica fisicamente) e 
ainda identificar todos os possíveis comportamentos do sistema, especialmente 
os sistemas orientados e objeto. Convém salientar que a orientação a objetos 
é o cerne da maioria dos sistemas construídos atualmente: desde os sistemas 
comerciais (baseados em componentes, eventos e hierarquias de formulários) 
até os complexos sistemas para Web. Em suma, o porquê de conhecer a UML 
está simplesmente relacionado à realidade do processo de desenvolvimento de 
software (MATOS, 2002).
Visões de um sistema com UML
O desenvolvimento de um sistema de software complexo de manda que seus 
desenvolvedores tenham a possibilidade de examinar e estudar esse sistema a partir de 
diversas perspectivas. Os autores da UML sugerem que um sistema pode ser descrito 
por cinco visões interdependentes desse sistema (BEZERRA, 2015). Cada visão enfatiza 
aspectos diferentes do sistema, são elas:
 » visão de casos de uso: descreve o sistema do ponto de vista externo 
comum como um conjunto de interações entre o sistema e os agentes 
externos ao sistema. Esta visão é criada inicialmente e direciona o 
desenvolvimento de outras visões do sistema;
39
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
 » visão de projeto: enfatiza as características do sistema que dão 
suporte, tanto estrutural quanto comportamental, às funcionalidades 
externamente visíveis do sistema;
 » visão de implementação: abrange o gerenciamento de versões do 
sistema, construídas por meio do agrupamento de módulos (componentes) 
e subsistemas;
 » visão de implantação: corresponde à distribuição física do sistema em 
seus subsistemas e à conexão entre essas partes;
 » visão de processo: esta visão enfatiza as características de concorrência 
(paralelismo), sincronização e desempenho do sistema.
Dependendo das características e da complexidade do sistema, nem todas as 
visões precisam ser construídas.
Vantagens da UML
Dentre as vantagens em se adotar a UML como ferramenta para a modelagem e 
documentação de sistemas, convém destacar (DEVMEDIA, 2015):
 » a UML foca na representação visual de diferentes elementos e aspectos 
de um software. Devido às suas características bastante intuitivas, 
esta linguagem permite uma compreensão mais rápida, assim como 
abrangente, de componentes e funcionalidades que fazem parte de uma 
aplicação;
 » sistemas extensos costumam apresentar relacionamentos complexos 
entre as diferentes partes que os compõem. Muitas vezes, a simples 
descrição textual de dependências entre os diversos recursos de uma 
aplicação pode ser confusa, não atingindo o resultado esperado e 
que é, basicamente, possibilitar uma clara compreensão sobre como 
tais elementos interagem. O uso de UML pode simplificar tal tarefa, 
permitindo a elaboração de diagramas à primeira vista simples, mas que 
resumem o difícil trabalho de descrever como classes e processos estão 
relacionados entre si;
 » desenvolvedores de diferentes plataformas podem compreender com 
mais facilidade as características de um sistema (independentemente da 
40
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
tecnologia na qual este foi concebido). Isto se deve ao fato da UML ser 
uma linguagem independente de plataforma, além de corresponder a um 
padrão de ampla aceitação dentro da área de software;
 » ainda considerando o item anterior, os modelos UML representam uma 
excelente ferramenta para a demonstração de conceitos de Orientação a 
Objetos, sobretudo no que se refere a explicações a respeito de padrões 
de projeto e outras soluções genéricas passíveis de reaproveitamento emnovos projetos;
 » a forte ênfase dada por esta linguagem à padronização também contribui, 
sem sombra de dúvidas, para um melhor desempenho das funções dentro 
dos times de implementação de projetos. Os diferentes profissionais 
envolvidos na codificação de uma aplicação têm na UML um meio que 
facilita a comunicação e a transmissão de ideias, partindo-se para isto da 
premissa de que todos contam com um conhecimento adequado desta 
linguagem.
Algumas questões devem ser ponderadas ao se adotar a UML para a geração de 
documentação em um projeto de software (DEVMEDIA, 2015):
 » em muitas situações será necessário sincronizar a documentação do 
projeto, atualizando diagramas elaborados em um estágio inicial para 
que contemplem as últimas mudanças efetuadas numa aplicação. Este 
tipo de atividade costuma consumir uma parcela significativa de tempo, 
devendo ser bem planejado a fim de evitar atrasos ou, até mesmo, ser 
deixado de lado por representar um processo relativamente trabalhoso;
 » é essencial que a construção de modelos UML priorize partes mais 
complexas ou críticas de um sistema. A documentação de funcionalidades 
e estruturas relativamente simples pode não agregar muito ao projeto, 
sendo desaconselhável investir tempo neste tipo de tarefa (quando o 
foco poderia justamente estar direcionado a elementos de uma maior 
importância dentro do contexto geral da aplicação);
 » a construção de modelos muito extensos pode dificultar a compreensão de 
determinados pontos de um sistema. A montagem de representações com 
um escopo mais reduzido pode ser a melhor opção em alguns momentos, 
visto que permite um melhor entendimento de alguns detalhes que 
passariam despercebidos em um diagrama abrangendo um contexto bem 
maior. 
41
CAPÍTULO 2
Introdução aos diagramas da UML
No geral, a UML abrange três tipos de blocos de construção: os itens (things), 
relacionamentos (relationships) e diagramas (diagrams).
Os itens são considerados como cidadãos de primeira classe, pois são a base para 
explicitação das entidades do mundo real. Os itens se dividem em:
 » itens estruturais: consistem em elementos conceituais ou físicos 
do modelo, ou seja, a representação estática das partes formadoras do 
domínio e do projeto. Os itens estruturais são compostos por classes (nós, 
componentes, classes ativas), interfaces, casos de uso e colaboração;
 » itens comportamentais: descrevem a parte dinâmica dos elementos 
do domínio e do projeto. Os itens comportamentais são compostos de 
interações (mensagens) e de máquinas de estado;
 » itens de agrupamento: descrevem a parte organizacional do modelo 
de domínio e de projeto. São notações que auxiliam a granularidade das 
relações e a sua decomposição. Os itens de agrupamento são compostos por 
apenas um item chamado pacote (package). Os pacotes possuem a tarefa 
de agrupar tantos os itens estruturais quanto os itens comportamentais;
 » itens anotacionais: são, basicamente, os comentários do modelo. 
Esses comentários são postos em retângulos chamados de notas. As notas 
podem ser aplicadas tanto a um item quanto a um agrupamento de itens. 
Os relacionamentos são as notações existentes para descrição de conexão conceitual, 
lógica ou física entre os itens.
Os diagramas consistem em uma representação gráfica de um conjunto de itens 
conectados por seus relacionamentos. Os diagramas servem para representar diferentes 
contextos e perspectivas.
A linguagem UML é composta por treze diagramas, classificados em diagramas 
estruturais e de comportamento. A Figura 12, apresenta a estrutura das categorias de 
diagramas utilizando a própria notação da UML (que será vista mais adiante).
42
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
Figura 12. Organização geral dos diagramas da UML.
 
<<abstract>> 
Diagrama Estrutural 
<<abstract>> 
Diagrama 
<<abstract>> 
Diagrama de Comportamento 
Os diagramas estruturais, ilustrados na Figura 13, tratam o aspecto estrutural tanto 
do ponto de vista do sistema quanto das classes. Existem para visualizar, especificar, 
construir e documentar os aspectos estáticos de um sistema, ou seja, a representação 
do seu esqueleto e estruturas “relativamente estáveis”. Os aspectos estáticos de um 
sistema de software abrangem a existência de itens como classes, objetos, pacotes e 
componentes.
Figura 13. Diagramas estruturais da UML. 
 
Diagrama de 
Classes 
<<abstract>> 
Diagrama Estrutural 
Diagrama de 
Pacotes 
Diagrama de 
Componentes 
Diagrama de Objetos Diagrama de Estrutura Composta 
Diagrama de 
Implantação 
Os diagramas de comportamento, ilustrados na Figura 14, são voltados a descrever o 
sistema modelado quando em execução, ou seja, a modelagem dinâmica do sistema. São 
usados para visualizar, especificar, construir e documentar os aspectos dinâmicos do 
sistema, ou seja, a representação das partes que “sofrem alterações”, como por exemplo, 
o fluxo de mensagens ao longo do tempo e a movimentação física de componentes em 
uma rede.
43
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
Figura 14. Diagramas de comportamento da UML.
 
<<abstract>> 
Diagrama Estrutural 
<<abstract>> 
Diagrama de Interação 
Diagrama de Casos de 
Uso
Diagrama de Máquina de 
Estados
Diagrama de 
Atividades
Diagrama de 
Sequência
Diagrama de 
Comunicação
Diagrama de 
Tempo
Diagrama de Visão Geral de 
Interação
Por que a UML é composta por tantos diagramas? O objetivo disto é fornecer 
múltiplas visões do sistema a ser modelado, analisando-o e modelando-o sob 
diversos aspectos, procurando-se, assim, atingir a completitude da modelagem, 
permitindo que cada diagrama complemente os outros.
Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determinada óptica. 
É como se o sistema fosse modelado em camadas, sendo que alguns diagramas enfocam 
o sistema de forma mais geral, apresentando uma visão externa do sistema, como é o 
objetivo do Diagrama de Casos de Uso, enquanto outros oferecem uma visão de uma 
camada mais profunda do software, apresentando um enfoque mais técnico ou ainda 
visualizando apenas uma característica específica do sistema ou um determinado 
processo. A utilização de diversos diagramas permite que falhas sejam descobertas, 
diminuindo a possibilidade da ocorrência de erros futuros.
A seguir, são descritos e exemplificados cada um dos diagramas oferecidos pela UML, 
destacando suas principais características. Nas próximas Unidades serão destacados os 
diagramas da UML mais utilizados.
Diagrama de classes
O diagrama de classes é provavelmente o mais utilizado e é um dos mais importantes 
da UML. Serve de apoio para a maioria dos demais diagramas. Como o próprio nome 
diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos 
e métodos que cada classe tem, além de estabelecer como as classes se relacionam e 
trocam informações entre si (GUEDES, 2011). A Figura 15, apresenta um exemplo 
desse diagrama.
44
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
Figura 15. Exemplo de diagrama de classes. 
Fonte: (GUEDES, 2011).
Diagrama de casos de uso
O diagrama de casos de uso é o diagrama mais geral e informal da UML, utilizado 
normalmente nas fases de levantamento e análise de requisitos do sistema, embora 
venha a ser consultado durante todo o processo de modelagem e possa servir de base 
para outros diagramas. Apresenta uma linguagem simples e de fácil compreensão 
para que os usuários possam ter uma ideia geral de como o sistema irá se comportar. 
Procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware 
especial) que utilizarão de alguma forma o software, bem como os serviços, ou seja, as 
funcionalidades que o sistema disponibilizará aos atores, conhecidas nesse diagrama 
como casos de uso (GUEDES, 2011). A Figura 16, apresenta um exemplo desse diagrama.
45
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
Figura 16. Exemplo de diagrama de casos de uso.
Fonte: GUEDES, 2011.
Diagrama de objetosO diagrama de objetos está amplamente associado ao diagrama de classes. Na verdade, 
o diagrama de objetos é praticamente um complemento do diagrama de classes e 
bastante dependente deste. O diagrama fornece uma visão dos valores armazenados 
pelos objetos de um diagrama de classes em um determinado momento da execução de 
um processo do software (GUEDES, 2011). A Figura 17, apresenta um exemplo desse 
diagrama.
46
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
Figura 17. Exemplo de diagrama de objetos. 
Fonte: (GUEDES, 2011).
Diagrama de pacotes
O diagrama de pacotes é um diagrama estrutural que tem por objetivo representar 
os subsistemas ou submódulos englobados por um sistema de forma a determinar as 
partes que o compõem. Pode ser utilizado de maneira independente ou associado com 
outros diagramas. Esse diagrama pode ser utilizado também para auxiliar a demonstrar 
a arquitetura de uma linguagem, como ocorre com a própria UML ou ainda para definir 
as camadas de um software ou de um processo de desenvolvimento (GUEDES, 2011). 
A Figura 18, apresenta um exemplo desse diagrama.
Figura 18. Exemplo de diagrama de pacotes.
Fonte: (GUEDES, 2011).
47
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
Diagrama de sequência
O diagrama de sequência é um diagrama comportamental que se preocupa com a 
ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um 
determinado processo. Em geral, baseia-se em um caso de uso definido pelo diagrama 
de mesmo nome e apoia-se no diagrama de classes para determinar os objetos das 
classes envolvidas em um processo. Um diagrama de sequência costuma identificar o 
evento gerador do processo modelado, bem como o ator responsável por esse evento, e 
determina como o processo deve se desenrolar e ser concluído por meio da chamada de 
métodos disparados por mensagens enviadas entre os objetos (GUEDES, 2011). 
A Figura 19, apresenta um exemplo desse diagrama.
Figura 19. Exemplo de diagrama de sequência. 
Fonte: (GUEDES, 2011).
Diagrama de comunicação
O diagrama de comunicação era conhecido como de colaboração até a versão 1.5 
da UML, tendo seu nome modificado para diagrama de comunicação a partir da 
versão 2.0. Está amplamente associado ao diagrama de sequência: na verdade, um 
complementa o outro. As informações mostradas no diagrama de comunicação com 
frequência são praticamente as mesmas apresentadas nos de sequência, porém com 
um enfoque distinto, visto que esse diagrama não se preocupa com a temporalidade 
48
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
do processo, concentrando-se em como os elementos do diagrama estão vinculados 
e quais mensagens trocam entre si durante o processo (GUEDES, 2011). A Figura 20, 
apresenta um exemplo desse diagrama.
Figura 20. Exemplo de diagrama de comunicação. 
Fonte: (GUEDES, 2011).
Diagrama de máquina de estados
O diagrama de máquina de estados demonstra o comportamento de um elemento 
por meio de um conjunto finito de transições de estado, ou seja, uma máquina de 
estados. Além de poder ser utilizado para expressar o comportamento de uma parte 
do sistema, quando é chamado de máquina de estado comportamental, também pode 
ser usado para expressar o protocolo de uso de parte de um sistema, quando identifica 
uma máquina de estado de protocolo. Como o diagrama de sequência, o de máquina 
de estados pode basear-se em um caso de uso, mas também pode ser utilizado para 
acompanhar os estados de outros elementos, como, por exemplo, uma instância de 
uma classe (GUEDES, 2011). A Figura 21, apresenta um exemplo desse diagrama.
49
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
Figura 21. Exemplo de diagrama de máquina de estados. 
Fonte: GUEDES, 2011.
Diagrama de atividade
O diagrama de atividade era considerado um caso especial do antigo diagrama de gráfico 
de estados, hoje conhecido como diagrama de máquina de estados, conforme descrito 
na seção anterior. A partir da UML 2.0, foi considerado independente do diagrama 
de máquina de estados. O diagrama de atividade preocupa-se em descrever os passos 
a serem percorridos para a conclusão de uma atividade específica, podendo esta ser 
representada por um método com certo grau de complexidade, um algoritmo, ou mesmo 
por um processo completo. O diagrama de atividade concentra-se na representação 
do fluxo de controle de uma atividade (GUEDES, 2011). A Figura 22, apresenta um 
exemplo desse diagrama. 
50
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
Figura 22. Exemplo de diagrama de atividades.
Fonte: GUEDES, 2011.
Diagrama de visão geral de interação
O diagrama de visão geral de interação é uma variação do diagrama de atividade que 
fornece uma visão geral dentro de um sistema ou processo de negócio. Esse diagrama 
passou a existir apenas a partir da UML 2(GUEDES, 2011). A Figura 23 apresenta um 
exemplo desse diagrama.
51
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
Figura 23. Exemplo de diagrama de visão geral de integração.
Fonte: GUEDES, 2011.
Diagrama de componentes
O diagrama de componentes está amplamente associado à linguagem de programação 
que será utilizada para desenvolver o sistema modelado. Esse diagrama representa os 
componentes do sistema quando o mesmo for ser implementado termos de módulos 
de código-fonte, bibliotecas, formulários, arquivos de ajuda, módulos executáveis etc. 
e determina como tais componentes estarão estruturados e irão interagir para que o 
sistema funcione de maneira adequada (GUEDES, 2011). A Figura 24 apresenta um 
exemplo desse diagrama.
52
UNIDADE III │ MODELAGEM DE SISTEMAS COM UML
Figura 24. Exemplo de diagrama de componentes.
Fonte: GUEDES, 2011.
T1. Diagrama de implantação
O diagrama de implantação determina as necessidades de hardware do sistema, as 
características físicas como servidores, estações, topologias e protocolos de comunicação, 
ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado (GUEDES, 
2011). A Figura 25 apresenta um exemplo desse diagrama.
Figura 25. Exemplo de implantação.
Fonte: GUEDES, 2011.
53
MODELAGEM DE SISTEMAS COM UML │ UNIDADE III
Diagrama de estrutura composta
O diagrama de estrutura composta descreve a estrutura interna de um classificador, 
como uma classe ou componente, detalhando as partes internas que o compõem, como 
estas se comunicam e colaboram entre si. Também é utilizado para descrever uma 
colaboração em que um conjunto de instâncias cooperam entre si para realizar uma 
tarefa (GUEDES, 2011). A Figura 26 apresenta um exemplo desse diagrama.
Figura 26. Exemplo de estrutura composta.
Fonte: GUEDES, 2011.
Diagrama de tempo ou de temporização
O diagrama de tempo descreve a mudança no estado ou condição de uma instância de 
uma classe ou seu papel durante um período. Tipicamente utilizado para demonstrar a 
mudança no estado de um objeto no tempo em resposta a eventos externos (GUEDES, 
2011). A Figura 27 apresenta um exemplo desse diagrama.
Figura 27. Exemplo de tempo ou de temporização.
Fonte: GUEDES, 2011.
54
CAPÍTULO 3
Visão geral da UML 2.0
Os objetivos que levaram os desenvolvedores da linguagem UML a lançar a versão 2.0 
foi reestruturá-la e refiná-la de maneira a torná-la mais fácil de aplicar, implementar e 
adaptar, melhorando sua precisão e capacidade de reutilização.
Um dos principais problemas enfrentados pela linguagem UML era causado pela 
constante evolução tecnológica na área de software, o que impedia que a UML se 
tornasse totalmente utilizável no momento em que uma empresa adotava uma tecnologia 
nova, devido ao fato da UML não prever ou não ser compatível com determinadas 
características inovadoras da tecnologia em questão. Assim, os desenvolvedores da 
UML decidiram permitir a criação de perfis a partir do núcleo da linguagem, permitindo, 
dessa maneira, que os usuários adaptassem a linguagem a uma plataforma ou domínio 
de aplicação específico (GUEDES, 2011).
Conceitos básicos: modelos, metamodelos e 
metaclasses
Conforme já descrito anteriormente, um modelo captura