Orientação a Objetos: Conceitos e Benefícios

Prévia do material em texto

1ºAula
Orientação a objetos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• conhecer os conceitos de Orientação a Objetos;
• compreender as dificuldades de se observar um problema e transformar em uma solução;
• entender os benefícios da orientação a objetos.
Prezados(as) alunos(as),
Em nossa primeira aula, vamos estudar os conceitos 
importantes sobre orientação a objetos.
Se ao final desta aula tiverem dúvidas, vocês poderão saná-
las através das ferramentas da plataforma de ensino.
Conto com a sua participação, aproveite para ler e refletir 
os objetivos de aprendizagem, afinal da sua participação 
dependerá seu aprendizado.
Bom Trabalho!
Bons estudos!
141
Análise de Sistemas II 6
Seções de estudo
1 – Conceitos da orientação a objetos
2 – A complexidade do domínio do problema
3 – Benefícios da orientação a objetos
1 - Conceitos da orientação a objetos
CONCEITO
CURIOSIDADE
“Uma abordagem orientada a objetos para o desenvolvimento de 
software 
O conceito de orientação a objetos já vem sendo 
discutido há algum tempo. Por volta de 1970, surgiram 
as primeiras publicações, mas a sua maior disseminação 
ocorreu nos anos 90, quando se tornou uma das principais 
metodologias de desenvolvimento de software. Desde o 
lançamento da primeira linguagem orientada a objetos, a 
SIMULA, várias referências da engenharia de software mundial 
como: Peter Coad, Edward Yourdon e Roger Pressman 
abordaram extensamente a análise orientada a objetos como 
um grande avanço no desenvolvimento de sistemas.
No início dos anos 80, surgiu a análise essencial para 
sistemas em tempo real, que ajudaram a análise estruturada 
por eventos, delimitando a área de atuação do sistema, através 
da utilização da lista de eventos, o conceito de “tecnologia 
introduzindo o modelo Entidade Relacionamento (DER). 
As suas principais vantagens residem em oferecer critérios 
objetivos para o particionamento do sistema, observando 
suas características, facilita a obtenção da solução, através dos 
eventos, isola os requisitos de restrições de implementação, 
de análise e sincroniza a modelagem de dados com a de 
processos.
Entretanto, os sistemas desenvolvidos baseados nas 
técnicas estruturadas ainda apresentam algumas limitações, 
principalmente quando da inclusão de novas funções ou 
alterações em funções já existentes, que na maior parte das 
vezes, provocam problemas em outras partes do software.
A grande esperança que levou aos estudos da orientação 
a objetos com mais intensidade foi a de suprir algumas 
das principais preocupações das empresas de software: a 
necessidade cada vez mais crescente de se construir softwares 
corporativos de forma muito mais rápida, com baixo custo, 
em desenvolvimento de software, de Orientação a Objetos. 
apresenta a sua visão do que entende por essa abordagem. 
Alguns dos conceitos encontrados são:
• a orientação a objetos pode ser vista como a 
abordagem de modelagem e desenvolvimento 
de sistemas que facilita a construção de sistemas 
complexos a partir de componentes individuais;
• o desenvolvimento orientado a objetos é a técnica 
de construção de software na forma de uma coleção 
estruturada de implementações de tipos abstratos 
de dados;
• desenvolvimento de sistemas orientado a objetos é 
um estilo de desenvolvimento de aplicações onde 
o encapsulamento potencial e real de processos 
e dados é reconhecido num estágio inicial de 
desenvolvimento e num alto nível de abstração, 
com vistas a construir de forma econômica o que 
• a orientação a objetos é uma forma de organizar o 
software como uma coleção de objetos discretos que 
incorporam estrutura de dados e comportamento;
• quando construídos corretamente, sistemas 
possuem estruturas bem conhecidas e provêm a 
oportunidade de criar e implementar componentes 
totalmente reutilizáveis;
• modelos orientados a objetos são implementados 
convenientemente, utilizando uma linguagem de 
programação orientada a objetos. A engenharia de 
software orientada a objetos é muito mais que utilizar 
mecanismos de sua linguagem de programação, é 
saber utilizar, da melhor forma possível, todas as 
técnicas da modelagem orientada a objetos;
• a orientação a objetos não é só teoria, mas uma 
usadas em inúmeros projetos e para construção de 
diferentes tipos de sistemas;
• a orientação a objetos requer um método que integre 
o processo de desenvolvimento e a linguagem 
de modelagem com a construção de técnicas e 
ferramentas adequadas.
A Orientação a Objetos é um dos maiores, e talvez o 
maior avanço em software destes últimos anos. Ela nos oferece 
uma forma mais natural de se analisar o mundo e transformar 
as necessidades em programas que irão resolver nossos 
problemas. Ela nos permite construir sistemas melhores e 
mais fáceis de dar manutenção.
As técnicas de análise estruturadas ainda hoje são as mais 
sempre tiveram grande aceitação desde que foram lançadas 
sendo utilizadas, a decomposição das funções (chamada 
mostrou-se inadequada em situações de sistemas complexos 
aperfeiçoamentos foram introduzidos desde então, e ajudaram 
existe uma probabilidade maior de que os sistemas criados 
142
7
com as técnicas estruturadas sejam mais difíceis de serem 
incrementados com novas funções e as alterações em funções 
já existentes, muitas vezes, provocam sérios problemas em 
outras partes do software.
A orientação a objetos permite modelar de forma mais 
natural o mundo real, pois as estruturas de dados são vistas 
como objetos, ou seja, têm características e funções. Seu maior 
objetivo é aumentar a produtividade do desenvolvimento de 
software através de uma maior expansibilidade e reutilização 
de código, além de controlar a complexidade e o custo de 
manutenção.
1.1
Por muitos anos, o termo “orientado a objetos” (OO) 
foi usado para denotar uma abordagem de desenvolvimento 
de software que usava uma das linguagens de programação 
orientadas a objeto (ex. Ada 95, C++ , Eiffel, Smalltalk). Hoje, 
o paradigma abrange uma visão completa da Engenharia de 
Software. Edward Berard, citado por Pressman (2006, p.552) 
Os benefícios da tecnologia orientada 
a objetos são incrementados se ele for 
endereçado cedo - através do processo de 
engenharia de software, considerando que a 
tecnologia OO deve avaliar seu impacto em 
todo este processo. Simplesmente empregar 
a programação OO (OOP) não irá produzir 
os melhores resultados. Os engenheiros de 
software e seus gerentes devem considerar 
também itens como Análise de Requisitos 
OO (OORA), projeto OO (OOD), análise 
de domínio OO (OODA), sistemas de banco 
de dados OO (OODBMS) e engenharia de 
software auxiliada por computador orientada a 
objetos (OOCASE). (PRESSMAN, 2006, s/p)
A orientação ao objeto se dedica a desenvolver um 
modelo orientado a objetos do domínio da aplicação. Os 
estão associadas com o problema a ser resolvido.
O enfoque da orientação a objetos é uma visão sobre um 
mundo como uma coletânea de objetos que interagem entre 
si, apresentando características próprias que são representadas 
pelos seus atributos e operações.
No paradigma orientado a objetos, os dados e as funções 
são vistos de forma agregada, não ocorrendo uma modelagem 
separada para cada um desses componentes; portanto, sob 
esse ponto de vista, a orientação a objetos favorece uma 
modelagem mais natural, que melhor retrata a realidade, 
pois processos e dados estão coligados, não se encontram 
dissociados em nenhuma atividade real.
software
2
problema
A tarefa da equipe de desenvolvimento de software é 
construir a ilusão da simplicidade (Booch, 2005), como mostra 
software 
o usuário.
Para o usuário, não importa o quão complexa é a estrutura interna 
do software, para ele o que importa é se o software resolve suas 
necessidades de forma fácil, rápida e segura. Para o usuário, o 
sistema deve ser simples.
A complexidade de um software é uma propriedade 
essencial e não acidental. Observa-se que a herança da 
complexidade deriva de quatro elementos:• A complexidade do domínio do problema – o 
domínio do problema que estamos citando aqui não 
está relacionado com “dominar o problema”, mas 
sim a abrangência, o escopo do problema, este escopo 
envolve os dados, informações, procedimentos, 
o problema. Geralmente a pessoa que desenvolve 
não é quem conhece o domínio do problema que 
está sendo analisado. É preciso destacar também 
que a tarefa de levantamento das necessidades do 
sistema é complicada e demorada, além disso, estas 
necessidades podem mudar ao longo do trabalho, 
ou seja, são instáveis. Devemos pensar também que 
o sistema precisará evoluir para continuar sendo útil 
para a empresa, portanto o domínio do problema 
não está apenas nos requisitos atuais levantados, 
mas também nas possibilidades de necessidades 
futuras que devem ser percebidas pela equipe de 
análise.
• 
– os desenvolvedores devem 
criar a ilusão da simplicidade, ou seja, por mais 
complexo que o software possa ser na sua arquitetura 
interna e nos seus procedimentos, para o usuário 
deve parecer sempre uma coisa simples e de 
fácil utilização. Outro ponto importante é que 
o tamanho do software não está ligado á sua 
qualidade, programas grandes demais não são 
ou mais complexos que outros menores, nem 
mesmo podemos dizer que programas menores 
são melhores porque foram melhor estruturados, 
tudo vai depender de como o software é construído 
e com que desenvoltura ele resolve os problemas 
do usuário. Outro problema importante que precisa 
ser gerenciado é a comunicação entre os integrantes 
da equipe de desenvolvimento, para evitar 
• 
– Um 
mesmo problema pode ser resolvido de várias 
de interesses entre integrantes da equipe de 
desenvolvimento, que podem querer, cada um dos 
integrantes, defender sua alternativa de solução 
como sendo a melhor entre todas as outras. 
Algumas vezes o desenvolvedor pode acabar 
143
Análise de Sistemas II 8
perdendo tempo tentando “reinventar a roda”, ou 
seja, criar coisas que já existem, ou ainda não querer 
aproveitar recursos já disponíveis, seria como se um 
construtor quisesse fabricar os tijolos que irá usar 
na sua obra, ou plantar as árvores para ter a madeira 
que precisará durante a construção. A falta de 
padronização dos procedimentos é outro problema 
que é comum na indústria de software
muito o trabalho em equipe.
• 
um sistema deverá se comportar em determinadas 
situações é uma tarefa que exige um grande esforço 
de equipe e uma grande percepção das necessidades 
e limitações do usuário.
software
Podemos dizer que sistemas complexos são aqueles que 
possuem algumas das características fundamentais, como:
• possuem um longo ciclo de vida;
• 
todos os detalhes do projeto;
• a complexidade pode ultrapassar a capacidade da 
percepção humana, o que vai exigir um esforço em 
conjunto para resolver determinados problemas;
• em alguns sistemas, a complexidade estará sempre 
presente e pode apenas ser gerenciada e não 
superada, mesmo que este gerenciamento deva ser 
Serão descritos a seguir alguns princípios para administrar 
a complexidade, ou seja, levar ordem ao caos.
Figura 1.1. A complexidade do software
Fonte: Booch (2005)
2.1
trazendo ordem ao caos
Administrar a complexidade dos sistemas é tarefa 
essencial, pois sem ela os sistemas acabam por não atender 
todas as necessidades dos usuários, ou podem atender de 
forma errada, além disso, os prazos não serão cumpridos e o 
de construção do sistema.
2.1.1
Dividir um problema maior em partes menores é 
importante para facilitar o entendimento das necessidades, 
pois é muito mais tranquilo administrar problemas menores 
um sistema de software complexo está sendo projetado é 
essencial decompô-lo em partes cada vez menores, cada 
Dessa forma, é possível satisfazer a uma restrição real que 
existe sobre a capacidade de cognição humana: para entender 
qualquer nível de um sistema, é necessário compreender 
somente um pequeno número de partes de uma vez (ao invés 
inteligente endereça diretamente a complexidade inerente do 
software através de uma divisão forçada do espaço do estado 
do sistema” (BOOCH, 2005, s/p).
Para entender melhor o problema como um todo, é 
preciso que se tenha inicialmente uma visão geral sobre 
ele, sem se preocupar inicialmente com os detalhes 
procedimentais que possam aparecer no decorrer do processo 
de desenvolvimento. A partir daí, esse problema “grande” 
deverá ser subdividido em problemas menores e, aí sim, a cada 
subdivisão, os detalhes irão aparecer naturalmente, mas aí já 
será mais fácil administrar a complexidade desses problemas, 
uma vez que eles irão aparecer em porções menores.
A complexidade é organizada como uma hierarquia, 
um sistema complexo é composto por subsistemas inter-
relacionados que, por sua vez, têm seus próprios subsistemas 
e assim por diante, até que se chegue a componentes 
quais serão os componentes mais elementares de um sistema 
e quais são os mais primitivos será uma decisão arbitrária 
da equipe de análise e depende basicamente da visão que o 
observador do sistema terá.
pois descobrir as abstrações e mecanismos comuns num sistema 
Um dos maiores problemas para os desenvolvedores 
de software é conseguir transformar necessidades de 
gerenciamento de informação em soluções de software. Os 
experimentos de Miller, citados por Booch (2005) relatam que 
ele concluiu que “um indivíduo pode compreender somente 
sete (mais ou menos duas) partes de informação ao mesmo 
tempo. Este número aparece como sendo independente do 
conteúdo da informação”. Miller observou que “o espaço do 
julgamento absoluto e o espaço de memória imediata impõem 
várias limitações na quantidade de informação que as pessoas 
estão aptas a receber, processar e relembrar.
Através da organização dos estímulos de entrada 
simultaneamente em várias direções e sucessivamente 
144
Highlight
9
dentro de uma sequência de partes, o ser humano é capaz de 
interromper esse engarrafamento (entrave) de informação.” 
perceber até sete níveis de informação sem se perder, com 
uma variação de mais ou menos duas. A partir deste número 
da informação. Em termos contemporâneos, este processo é 
chamado .
Uma forma de facilitar o entendimento de sistemas 
complexos é descobrir abstrações, mecanismos comuns e 
elementos já conhecidos em outras situações.
CURIOSIDADE
Um motorista consegue dirigir um novo modelo de carro 
Wulf, citado por Booch, (2005) descreve que:
os humanos desenvolveram uma técnica 
poderosa e excepcional para lidar com a 
complexidade. Eles a abstraem. Uma vez 
que o ser humano é inábil para dominar um 
objeto complexo por total, ele escolhe ignorar 
os detalhes não essenciais, lidando, no lugar, 
com um modelo de objetos idealizado e 
generalizado” (BOOCH, 2005, s/p).
Em cada nível de abstração, os elementos cooperam 
entre si para desempenharem suas funcionalidades por meio 
de uma interface e oferecem serviços para os níveis mais altos.
3
O benefício principal do desenvolvimento Orientado a 
Objetos não é reduzir o tempo de desenvolvimento. Ele pode 
levar mais tempo que o desenvolvimento convencional 
porque na Orientação a Objetos se pretende que haja a 
promoção da reutilização futura e a redução dos erros 
posteriores e futuras manutenções. O tempo transcorrido até 
que o código esteja completo pela primeira vez é possivelmente 
ou em alguns casos ligeiramente maior.
O benefício da Orientação a Objetos consiste em que as 
interações subsequentes são mais rápidas e mais fáceis do que 
empregando um método convencional, porque as revisões estão 
mais localizadas. A prática mostra que é necessário um menor 
número de interações porque um maior número de problemas 
são descobertos e corrigidos durante o desenvolvimento.
As técnicas de Orientação a Objeto pressupõem que 
se possam criar sistemas compondo-se objetos previamente 
criados e, consequentemente, reduzindo-se o tempo 
produtividade e qualidade.
Durante as seções anteriores comentamos sobre algumas 
das vantagens do uso datecnologia de orientação a objetos 
para desenvolvimento de sistemas, vamos agora destacar 
detalhes de alguns dos principais benefícios:
• 
desenvolvimento estruturado, em que se elabora um 
projeto e depois se faz os programas, podemos ter 
seus objetivos depois de implementado. No 
desenvolvimento OOP (Object Oriented Project, ou 
Projeto Orientado a Objetos), devido ao fato deste 
ser feito de maneira quase que interativa com o 
A pouca quantidade de código programável 
projeto.
• 
reage aos erros imprevistos como: uma falha na 
impressora, ou um disco cheio. Tanto maior for a 
potencialidade, maior a capacidade do programa 
em causar o menor “estrago” possível aos dados e 
evitar uma saída drástica do sistema.
• - Dizemos que quanto maior for a 
extensibilidade do software, maior será sua capacidade 
analistas.
• - A capacidade de se otimizar a 
produtividade do programador depende diretamente 
da maneira como o software disponibiliza a 
reutilização do código (programa fonte) gerado. 
já reutiliza código anteriormente gerado, porém a 
perfeita reutilização consiste na utilização completa 
de um código gerado para algum sistema sem 
qualquer outra adaptação prévia.
• - A aplicação dos 
conceitos da orientação a objetos na análise de 
sistemas permitirá modelar a empresa ou as áreas 
da aplicação de uma forma mais natural, visto que 
os recursos a serem aplicados retratam com mais 
facilidade o mundo real. A capacidade de retratar 
o universo pesquisado é moldado em diagramas 
mundo real. A própria transição entre etapas na 
construção do software, aplicando- se o paradigma 
os mesmos conceitos e linguagem.
• 
de métodos reduz a complexidade na construção 
do código dos programas. Isso traz simplicidade 
software.
Devemos lembrar que os benefícios da orientação a 
objetos serão maiores e mais evidentes se ela for adotada do 
software.
Na prática, podemos dizer que a maior vantagem 
da orientação a objetos é a facilidade de manutenção do 
sistema (quando OO é aplicado corretamente). Mas, tem 
como desvantagem um maior tempo para desenvolvimento. 
Levantar um sistema orientado a objetos dá um pouco mais de 
145
Highlight
Highlight
Análise de Sistemas II 10
trabalho que um sistema procedural, pois temos que planejar 
o sistema pensando nos objetos e suas funções e não apenas 
nas funções que o sistema irá executar.
A orientação a objetos também possui algumas desvantagens 
• maior tempo necessário para o desenvolvimento do 
projeto do sistema;
• complexidade no aprendizado para 
desenvolvedores de linguagens estruturadas – 
com o desenvolvimento estruturado sentem maior 
orientação a objetos;
• maior uso de memória, por exemplo para aplicações 
móveis em algumas linguagens como o JavaME;
• maior esforço na modelagem de um sistema OO do 
que um sistema estruturado, porém oferece menor 
• dependência de funcionalidades já implementadas 
em superclasses no caso da herança, implementações 
espalhadas em classes diferentes (veremos o 
CURIOSIDADE
Retomando a aula
A orientação a objetos surgiu com o intuito de tornar 
possível criar sistemas mais complexos de forma mais rápida 
e que pudessem receber manutenção de forma que não fosse 
necessário fazer muitas mudanças na estrutura do projeto do 
sistema.
Apesar da maior complexidade nos trabalhos iniciais, a 
orientação a objetos permite que sistemas mais complexos 
possam ser desenvolvidos mais rapidamente.
2 – A complexidade do domínio do problema
A complexidade dos sistemas precisa ser administrada, 
mas isto não é uma tarefa simples, pois envolve uma série 
de problemas relacionados a: complexidade do domínio do 
caracterização do comportamento de sistemas.
Uma das formas de gerenciar a complexidade é a 
decomposição, que permite dividir problemas grandes em 
partes menores, tornando-os problemas menores e mais 
facilmente gerenciáveis.
Os principais benefícios da orientação a objetos são: 
exatidão, potencialidade, extensibilidade, reutilização, 
mais simples.
No entanto, vamos observar que foram citadas várias 
outras vantagens, entre elas, a maior facilidade quando se 
software.
Podemos apontar outros benefícios importantes como 
o ciclo de vida mais longo para os sistemas, desenvolvimento 
mais acelerado sem que isto implique em perda da qualidade, 
possibilidade de se construir sistema muito mais complexos 
pela incorporação de funções prontas (reutilização), menor 
custo para desenvolvimento e manutenção de sistemas.
Vale a pena
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006. SOMMERVILLE, I. Engenharia 
de Software. 8ª Edição. Addison Wesley, 2007. BOOCH, 
Grady, JACOBSON, Ivar; RUMBAUGH, James. UML – 
guia do usuário. Elsevier, Rio de Janeiro. 2005.
pena ler
• YOUTUBE. Conceitos básicos de orientação a 
objetos. Disponível em: <http://www.youtube.com/
pena assistir
Minhas anotações
146
2ºAula
Características de objetos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• entender as definições dos termos mais utilizados na orientação a objetos;
• compreender as dificuldades de se observar um problema e transformar em uma solução;
• entender os benefícios da orientação a objetos.
Prezados(as) alunos(as),
Nesta segunda aula, vamos conhecer as definições dos 
Se ao final desta aula tiverem dúvidas, vocês poderão saná-
las através das ferramentas da plataforma de ensino.
Conto com a sua participação, aproveite para ler e refletir 
os objetivos de aprendizagem, afinal da sua participação 
dependerá seu aprendizado.
Bom Trabalho!
Bons estudos!
147
Análise de Sistemas II 12
Seções de estudo
1 – Objetos
2 – Classes
3 – Características da orientação a objetos
1
 
CONCEITO
Grady Booch (1955-) é um informático 
americano. Seu livro “Software 
Engineering with Ada” lançou as raízes 
do projeto orientado a objetos. Esse 
trabalho evoluiu para uma metodologia 
de desenvolvimento de sistemas 
orientados a objetos publicada em seu 
livro “Object- Oriented Analysis and 
Design with Applications”. Em 1996, 
em parceria com Ivar Jacobson e James 
Rumbaugh, lançou uma linguagem 
que se tornou um padrão da indústria, a 
UML. (Wikipedia, 2013)
Um objeto pode 
entidade do mundo real 
que tem uma identidade. 
citados por Booch (2005, 
p. 91) oferecem a seguinte 
No mundo real um objeto limita-se a existir, mas, no 
que se refere ao mundo da tecnologia da informação, cada 
qual pode ser 
referenciado inequivocamente (RUMBAUGH et al., 2005).
Os objetos podem representar uma entidade concreta 
(o parágrafo de um documento, a janela num computador, 
um aluno deste curso, o carro do aluno, um arquivo do 
computador) ou uma entidade conceitual (uma regra num 
sistema ou uma estratégia de jogo).
Figura 2.1. Características do objeto.
Fonte: Booch (2005)
A estrutura de um objeto é representada por um 
conjunto de atributos. O comportamento do objeto é 
representado por um conjunto de operações que podem ser 
executadas sobre o objeto. Objetos com a mesma estrutura e 
o mesmo comportamento são agrupados em uma estrutura 
que chamamos de .
Em outras palavras, um é algo distinguível que 
contém um (atributos ou propriedades) e possui um 
. O comportamento é como um objeto 
age e reage, em termos de mudanças em seu estado e troca de 
mensagens. Uma é alguma ação que um objeto 
executa sobre outro para obter uma reação. Cada objeto tem 
uma e é distinguível de outro, mesmo que seus 
atributos sejam idênticos. Instâncias de classes são chamadas 
de objetos.
 do 
mudanças do estado do objeto interagindo com o seu mundo 
externo, através das operações realizadas pelo objeto.
A comunicação entre objetos se dá por meio de troca de 
mensagens. Assim, para acessar a estrutura de dados de outro 
objeto, um objeto deve enviar uma mensagem para aquele 
outro objeto. Uma mensagem consiste do nome de uma 
operação e dos argumentos requeridos para que a operação 
seja executada.
O comportamento de um objeto representa como 
este objeto reage, em termosde suas mudanças de estado, 
mensagens a que um objeto pode responder representa seu 
comportamento.
A troca de mensagens é uma parte da equação
comportamento de um objeto, uma vez que o estado de um 
objeto afeta seu comportamento. Na maioria das linguagens 
de programação orientadas a objetos, as operações que os 
clientes podem executar são tipicamente declaradas como 
métodos, que fazem parte da declaração das classes (veremos 
o conceito de classe mais adiante). O estado de um objeto 
representa os resultados cumulativos de seu comportamento 
(BOOCH, 2005).
Um objeto é, pois, uma entidade que tem seus atributos 
representados por tipos de dados e seu comportamento 
representado por operações.
A criação de um objeto é chamada de . 
Cada instância tem seus próprios valores para seus atributos, 
mas compartilha o nome e os comportamentos dos atributos 
com as outras instâncias da mesma classe.
A orientação a objetos possui alguns conceitos 
fundamentais que norteiam todas as formulações e facilitam 
a sua aplicação em software. As seções que seguem apresentam 
outra
sã s e 
metodologias baseadas em objetos.
2 - Classes
Uma e é o agrupamento de objetos que possuem 
características idênticas, ou seja, com a mesma estrutura de 
atributos ou propriedades) e comportamento 
(operações).
148
Highlight
13
Os atributos são “variáveis” ou campos que indicam 
possíveis informações armazenadas por um objeto de uma 
classe. Por exemplo: nome, cpf, endereço.
Métodos são funcionalidades da classe. Exemplo: 
calcular saldo, atualizar estoque, lançar nota.
O conceito de classe é bastante semelhante ao conceito 
de tipo de dados de outras linguagens tradicionais. Da mesma 
o um 
conjunto de valores numéricos que possuem casas decimais, 
ou strings como um conjunto de valores alfanuméricos, 
chamados de cadeia de caracteres,
o conceito de uma classe.
As classes são um conjunto de “coisas”. Posteriormente, 
veremos que essas coisas são chamadas de objetos que 
apresentam características semelhantes. Numa classe, além 
seu “comportamento”, que é expresso através de funções e 
procedimentos.
Uma classe é uma abstração que descreve as propriedades 
importantes para uma aplicação e não leva em conta as outras. 
Exemplos de classes: Parágrafo, Janela, Aluno, Carro. Cada 
de objetos 
individuais. Cada objeto é uma de uma classe. 
Assim, cada instância de classe tem seus próprios valores para 
cada um dos atributos da classe, mas compartilham os nomes 
dos atributos e métodos com as outras instâncias da classe.
Pensemos na classe CARRO. Essa classe define os 
comportamentos e atributos de um carro, e existem atributos 
que serão comuns a todos os carros. As rodas e o motor são 
atributos comuns a qualquer carro. Já uma Ferrari possui 
atributos que são específicos dela, o valor por exemplo.
Figura 2.2. Classe de objetos – Classe Carro.
Fonte: Booch (2005)
Uma classe é um conjunto de objetos do mesmo tipo. 
Todos os objetos de uma classe têm a mesma característica e 
realizam as mesmas funções.
Fazendo uma comparação entre o Modelo Entidades 
Relacionamentos (MER ou DER) e o Modelo Orientado a 
objetos (OO), podemos dizer que:
MER....................................................................................OO
Entidades.......................................................................Classes
Ocorrência.....................................................................Objeto
Atributo.......................................................................Atributo
3
objetos
A Orientação a Objetos se caracteriza principalmente 
Usando como exemplo um sistema de cadastramento 
de veículos, teríamos, entre outras, a classe VEÍCULOS que 
conteria um conjunto de registros ou ocorrência, um para 
cada veículo cadastrado. Cada um destes registros representa 
um OBJETO para a OOA (Object Oriented Analysis - Análise 
Orientada a Objetos).
Se aprofundássemos a nossa análise, descobriríamos 
que existem tipos diferentes de veículos tais como: veículo-
caminhão, veículo-de-passeio e veículo- ônibus. Estaríamos 
diante das subclasses da classe veículo. É interessante notar 
que,
a cada uma das subclasses, também existem atributos e 
comportamentos comuns entre elas, isto é, as subclasses 
herdam características das classes hierarquicamente 
superiores. Este aspecto – HERANÇA – é profundamente 
explorado e é uma das razões de ser das tecnologias orientadas 
a objeto.
Pelo que foi exposto até agora parece não haver muita 
diferença entre a Análise Orientada a Objetos e a Modelagem 
Entidade-Relacionamento, mas essa diferença existe e é 
fundamental.
Na OOA, guardamos nas classes de objeto mais que 
simplesmente os dados ou atributos; guardamos também, os 
serviços exclusivos sobre esses dados.
No exemplo da classe VEÍCULOS, teríamos os atributos 
Placa, Proprietário, Data-Compra, Potência, Marca, Cor 
etc. E os serviços Incluir- Veículo, Calcular-idade-Veículo, 
Deletar-Veículo, entre outros. Para a subclasse VEÍCULOS 
– CAMINHÃO, além do que foi herdado, teríamos os 
atributos Capacidade-de-cargas e Distância-entre-Eixos, e 
mais os serviços de Calcular- Tempo-Vida-Útil e Reservar-
Espaço-para-frete.
Na OOA, só é possível incluir, alterar, acessar e 
excluir objetos de uma classe através de um acionamento 
de seus serviços exclusivos. Trata-se do conceito de 
ENCAPSULAMENTO, que dá a uma classe de objetos, 
características de “caixa-preta”. Para acionar estes serviços, o 
usuário ou outro objeto deve emitir uma mensagem para o 
objeto receptor, indicando qual função deve ser executada e 
quais os argumentos servirão de parâmetros para essa função. 
Nas linguagens tradicionais, não orientadas a objetos, seria 
algo parecido com acionar uma sub- rotina chamando um 
procedimento ou função.
3.1 - Abstração
A abstração consiste em enfocar os aspectos mais 
importantes de um objeto (visão externa; o que é e o que ele 
faz), ignorando suas características internas (visão interna; 
como ele deve ser implementado).
149
Análise de Sistemas II 14
Abstração é uma das formas fundamentais do ser humano 
lidar com complexidade. Shaw, citado por Booch (2005, p. 
sistema que dá ênfase a alguns dos 
detalhes ou propriedades do sistema enquanto suprimem 
outros. Uma boa abstração é aquela que enfatiza detalhes que 
que são, para o momento, imateriais ou desviadores do foco.”
Uma abstração denota as características 
essenciais de um objeto que o distinguem 
de todos os outros tipos de objetos e 
desta maneira, fornece limites conceituais 
do observador. A abstração enfoca a visão 
exterior de um objeto e serve para separar o 
comportamento essencial do objeto de sua 
implementação. (BOOCH, 2005)
Figura 2.3. A abstração enfoca as características essenciais de um objeto, 
relativas à visão do observador. Fonte: Booch (2005)
a 
abstração diferente do objeto focado, enquanto a vovó vê o 
gato como uma bola de pelos, a veterinária vê sua anatomia. 
Cada uma vê da forma do seu interesse.
Abstração é o princípio de ignorar os 
aspectos de um assunto não relevante para o 
propósito em questão, tornando possível uma 
concentração maior nos assuntos principais. 
A abstração consiste então na seleção que 
um analista faz de alguns aspectos, ignorando 
outros (COA
Figura 2.4. Transformação do problema em modelo de sistema, através da 
abstração Fonte: http://www.cpdee.ufmg.br
e estamos 
considerando é complexo; em vez de tentar compreender o 
todo, selecionamos parte dele. Sabemos que existem detalhes 
adicionais; simplesmente optamos por não considerá-los 
neste momento.
Ao aplicar a abstração de dados, um analist
atributos e os serviços que manipulam exclusivamente esses 
atributos. O único jeito de chegar até os atributos é através de 
um serviço. Os atributos e seus serviços podem ser tratados 
como um todo intrínseco (COAD OURDON, 1992).
3.2
s 
abstrações. A estrutura do objeto é importante uma vez que 
ilustra como diferentes objetos colaboram uns com os outros 
através de padrões de interação, chamadosmecanismos. A 
estrutura de classes é igualmente importante, uma vez que 
destaca a estrutura comum e comportamento dentro de um 
s 
dentro de um sistema de software complexo não é uma tarefa 
fácil, uma vez que requer a descoberta de padrões entre vários 
objetos. No entanto, a partir do momento em que essas 
estruturas estiverem mapeadas, a estrutura do sistema e seu 
entendimento se tornam bastante
3.3 - Encapsulamento
O encapsulamento consiste em ocultar ao usuário o 
funcionamento interno de uma classe. A principal vantagem 
do encapsulamento é permitir que os programadores mudem 
a implementação de uma classe sem que precisem alterar 
algum código gerado. O encapsulamento é o empacotamento 
de dados (atributos) e de operações sobre estes (métodos), 
também conhecido como a capacidade de “esconder 
informação” de detalhes de implementação (abstração).
No caso da orientação a objetos, os dados não podem ser 
acessados diretamente, mas através de mensagens enviadas 
para as operações. O uso de encapsulamento permite que a 
implementação d sem afetar 
as aplicações que usam este objeto ou a forma de acessá-lo.
Figura 2.5. O encapsulamento esconde os detalhes da implementação de um 
objeto. Fonte: Booch (2005)
No encapsulamento, os usuários têm conhecimento 
apenas das operações que podem ser realizadas e precisam 
estar cientes apenas do que as operações realizam e não como 
elas estão implementadas (BOOCH, 2005).
150
Highlight
Highlight
15
O encapsulamento é mais frequentemente alcançado 
através do ocultamento das informações, que é o processo 
de esconder os detalhes de um objeto que não contribuem 
para suas características essenciais; tipicamente a estrutura de 
um objeto é escondida, bem como a implementação de seus 
métodos.
Por exemplo, para se cadastrar uma localização turística 
e suas atrações através de um sistema desenvolvido para 
Web, uma pessoa não precisa conhecer sua estrutura interna 
(tabelas, atributos, classes) nem tão pouco como se dá a 
implementação de seus métodos. Sabe-se que é necessário 
acessar a página via Internet, mas não é preciso saber como 
esta operação é implementada (construída). Dessa forma, o 
usuário precisa conhecer apenas a interface (neste caso, as 
telas) que permite a ele executar operações do tipo incluir, 
alterar, excluir ou consultar, e não como essas operações são 
de fato implementadas.
3.4
A Herança é uma das principais características da 
orientação ao objetos, pois permite o reaproveitamento de 
métodos e atributos, diminuindo o tempo de desenvolvimento 
do sistema e facilita as futuras manutenções.
A herança consiste no compartilhamento de atributos e 
operações entre as classes baseado num relacionamento de 
hierarquia. Permite que uma nova classe seja descrita a partir 
de outra classe já existente (reutilização). A subclasse herda 
as características e o comportamento da superclasse, além de 
poder adicionar novas características e comportamentos aos 
herdados; por exemplo, a classe herda da classe 
algumas propriedades e operações, pois a classe 
automóvel pertenc
A Herança é um mecanismo onde temos uma classe 
 outra, adicionando todas as funcionalidades 
e propriedades daquela primeira (chamada de superclasse) e 
podendo adicionar outras funcionalidades e propriedades para 
a classe criada a partir da primeira (chamada de subclasse). 
Sua utilização força que a subclasse inclua todos os métodos e 
propriedades de sua superclasse;
A utilização da herança representa mais que uma 
simples economia na criaçã
o um comportamento (método) é alterado, 
todas as classes que descendem dela terão acesso aos métodos 
atualizados, sem a necessidade de serem refeitos.
Uma (como 
no caso do exemplo anterior) e posteriormente
termos de subclasses e assim sucessivamente. Podemos dizer 
com isso que a classe automóvel é uma subclasse da classe 
veículo e que a classe veículo é uma superclasse.
O conceito de herança para o paradigma da orientação 
a objetos é bastante semelhante ao conceito de herança que 
conhecemos no nosso dia a dia. Cada um de nós herdou 
características existentes em nossos antecessores, sejam elas 
características físicas ou de comportamento. Da mesma 
forma, as classes e, por consequência, seus objetos, também 
têm a possibilidade de herdar características e métodos 
 para seus antecessores.
Figura 2.6. Exemplo de Herança. Fonte: Microsoft.com
Esta relação entre classes é uma das grandes vantagens 
de sistemas orientados a objetos por causa da redução de 
trabalho resultante durante o projeto e a programação destes.
Existem dois tipos de herança:
• herança simples, onde uma subclasse tem somente 
uma superclasse, ou seja, uma subclasse herda 
apenas as características de uma superclasse;
• herança múltipla, na qual uma subclasse herda 
simultaneamente de várias superclasses.
3.5 - 
o 
pode se comportar de forma diferente em classes diferentes. 
que é diferente para as instâncias de classe círculo e polígono 
ou a operação diferente para janela de computador e 
para uma peça de um jogo de xadrez. Uma operação que tem 
mais de um método que a implementa é dita , ou 
seja, pode possuir várias formas. Uma mesma função pode 
apresentar diferentes “comportamentos”, daí o nome do 
O usuário não precisa saber quantas implementações 
existem para uma operação, ou explicitar qual método deve 
ser utilizado: a linguagem de programação deve ser capaz de 
selecionar o método correto a partir do nome da operação, 
classe do objeto e argumentos (parâmetros) para a operação. 
Assim, novas classes podem ser adicionadas sem a necessidade 
á existente, pois cada classe apenas 
os seus métodos e atributos.
Retomando a aula
Um objeto é qualquer “coisa”, lugar, relatório, evento, 
tela ou conceito que se aplique ao sistema. Todo objeto 
pertence a uma classe e tem seus próprios atributos. Os 
151
Análise de Sistemas II 16
atributos dos objetos são mutáveis e podem receber valores 
diferentes conforme as características do objeto.
Uma classe representa um conjunto de objetos. Estes, 
apesar de possuírem atributos iguais, têm valores diferentes 
em seus atributos. Uma classe é um modelo e todos os seus 
objetos têm os mesmos atributos, embora sejam atributos que 
podem ter valores diferentes, e os mesmos métodos.
Na abstração, nós isolamos os objetos que queremos 
representar do ambiente complexo em que se situam, e nesses 
objetos representamos someta as características que são 
relevantes para o problema em questão.
O encapsulamento é um dos pilares da orientação a 
objetos, sua característica é ocultar partes da implementação, 
e assim construir softwares que atinjam suas funcionalidades e 
escondam os detalhes de implementação do mundo exterior. 
Os objetos encapsulados funcionam como uma caixa preta, 
sabe- se da sua interface externa, mas não precisa se preocupar 
com o que acontece dentro dela.
A herança é uma das principais características das 
linguagens de programação orientadas a objetos, permite 
o reaproveitamento de métodos e atributos diminuindo o 
tempo de desenvolvimento, ainda reduz as linhas de código, 
desta forma facilita as manutenções futuras.
das classes, este trabalha com a redeclararão de métodos 
herdados, ou seja, os métodos têm a mesma assinatura (têm 
o mesmo nome), mas a forma de implementação utilizada 
diferem o da superclasse.
Vale a pena
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006. SOMMERVILLE, I. Engenharia 
de Software. 8ª Edição. Addison Wesley, 2007. BOOCH, 
Grady, JACOBSON, Ivar; RUMBAUGH, James. UML – 
guia do usuário. Elsevier, Rio de Janeiro. 2005.
pena ler
• YouTube. Vídeo aula de orientação a objetos. Disponível em: 
<http://www.youtube.com/watch?v=t9Cd7EWL0eo . 
Acesso em 01/12/2013
pena assistir
Minhas anotações
152
3ºAula
Técnicas orientadas a Objetos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• entender os objetivos das técnicas de modelagem orientadas a objetos;
• conhecer as principaistécnicas criadas;
• comparar as técnicas;
• observar pontos positivos e negativos em cada uma delas.
Prezados (as) alunos (as),
Continuando nosso aprendizado, na aula 3 vamos 
conhecer algumas das mais importantes técnicas utilizadas na 
orientação a objetos.
Se ao final desta aula tiverem dúvidas, vocês poderão saná-
las através das ferramentas da plataforma de ensino.
Conto com a sua participação, aproveite para ler e refletir 
os objetivos de aprendizagem, afinal, da sua participação 
dependerá seu aprendizado.
Bom Trabalho!
Bons estudos!
153
Análise de Sistemas II 18
Seções de estudo
1 – Introdução
2 – Principais Técnicas
3 – Discussão sobre as metodologias
1 - Introdução
O desenvolvimento orientado a objetos diz respeito aos 
procedimentos de concepção de sistemas a partir dos 
conceitos básicos anteriores e envolve a utilização de 
e implementação.
A metodologia consiste na construção de um modelo 
de um domínio de aplicação e na posterior adição a este 
dos detalhes de implementação durante o projeto de um 
sistema. Existem atualmente várias Metodologias Orientadas 
a Objetos, mas apenas algumas serão descritas a seguir, não de 
forma exaustiva, mas sim apresentando uma breve descrição 
dos conceitos, processos e técnicas utilizadas em cada uma 
delas, de forma a ser possível encontrar semelhanças e 
diferenças.
Existem várias técnicas, ou métodos, para o 
desenvolvimento orientado a objetos. Estas técnicas se 
tornaram populares nos anos 90. Suas principais características 
serão citadas a seguir.
2
2.1
O método de Grady Booch para desenvolvimento 
orientado a objetos é dividido em 3 fases: análise de requisitos, 
análise de domínios e projeto, com ênfase maior no projeto. 
Este método provê os seguintes diagramas: de classes, de 
transição de estados, de objetos, temporais, de módulos e de 
processos.
O método Booch está disponível em muitas versões. 
de um número de visões, em que cada visão é descrita por 
um número de modelos e diagramas. Ele traz uma simbologia 
complexa de ser desenhada a mão, contém também o processo 
pelo qual os sistemas são analisados por macro e micro visões.
O método descrito por Booch (2005) é constituído, 
basicamente, pelas fases de , 
do domínio e . Tem como providenciar uma 
notação e um processo de desenvolvimento, dando especial 
atenção ao aspecto da comunicação entre a fase de análise e 
desenho de um sistema de software Orientado a Objetos. Este 
método tem um caráter amplo que, endereçando os aspectos 
das ferramentas de análise e desenho Orientado a Objetos, 
inclui modelagem dos objetos, modelagem da análise, desenho 
da aplicação, desenho da implementação e ciclo de vida dos 
processos.
Booch propõe diferentes visões para descrever os 
sistemas. O modelo lógico, isto é, o domínio do problema, 
é representado na estrutura de classes e objetos. O diagrama 
de objetos mostra como os objetos interagem uns com os 
outros, enquanto que os diagramas de classe são de índole 
mais estática. Assim, os diagramas de objetos descrevem 
o comportamento dinâmico do sistema. O conceito de 
subsistema, neste método, é entendido como um diagrama 
de módulos, tendo um paralelismo, em termos do papel que 
representa, com os diagramas de categoria e de classes. Os 
subsistemas representam conjuntos de módulos relacionados 
de uma forma lógica.
Um dos grandes pressupostos do método de Booch 
(1996) é criar um modelo do sistema, passível de ser 
implementado. Os vários conceitos deste método estão 
distribuídos, com diferentes níveis de abstração, nas três fases 
do processo, indicados a seguir:
 - produz dois tipos de 
das funções principais do sistema. Devem ser 
inputs e outputs do sistema, ou uma lista 
de referências para planos de ação, procedimentos, 
mecanismos chave que o sistema deve providenciar, 
incluindo o estado de entrada, saída e as mudanças 
de estado esperadas. Estes mecanismos chave 
servem para validar o domínio do modelo, descobrir 
operações, bem como testar determinados casos.
 - - esta fase inclui:
• Diagramas de classe abstratos;
• 
• Herança;
• Diagramas de cenários dos objetos;
• 
 -
análise, adicionando as estruturas e comportamentos 
necessários para implementação do domínio 
em estudo. O modelo iniciado durante a análise 
serve como base para a construção do modelo de 
desenho. São adicionadas as seguintes contribuições 
ao modelo:
• descrições arquiteturais;
• descrições do protótipo;
• diagramas de categoria;
• diagramas de classe;
• diagramas de objeto;
• 
2.2
Esta técnica utiliza um modelo único para todas as fases, 
OOA – Object Oriented Analysis (Análise Orientada a Objeto), 
OOD - Object Oriented Design (Projeto Orientado a Objeto) e 
OOP – Object Oriented Programming (Implementação Orientada 
a Objeto), o que torna mais simples e compreensível o 
154
19
desenvolvimento.
Este método é tido como adequado para o 
desenvolvimento de sistemas segundo o paradigma dos 
entre as fases de análise, desenho e implementação, bem 
questão.
São encontrados 4 grandes benefícios na utilização deste 
método em relação aos métodos de análise tradicionais:
• melhoramento da Interação entre o analista e o 
cliente do sistema;
• aumento da consistência interna entre análise, 
• reutilização;
• providencia uma representação consistente entre as 
diversas fases;
De acordo com Coad/Yourdon, o maior benefício 
da análise OO, resulta da redução da complexidade de um 
determinado problema. Segundo os autores deste método, 
uma aproximação OO consiste de classes, objetos, herança e 
comunicação via mensagens.
O principal objetivo deste método é permitir a 
práticas e estratégias para a prossecução do mesmo. Trata-
se de um método de desenvolvimento orientado ao objeto 
com um domínio de aplicação bastante alargado, incidindo 
na manipulação de classes e objetos respeitantes ao domínio 
do problema, no interface homem-máquina e na gestão das 
tarefas inerentes ao processo de desenvolvimento.
Disponibiliza uma extensão que abarca o conceito de 
reengenharia, de forma a ser possível desenvolver um modelo 
com base no redesenho dos processos organizacionais.
Este método utiliza uma arquitetura de desenvolvimento 
constituída por quatro componentes principais:
• interação humana;
• domínio do problema;
• gestão de tarefas de tempo real;
• gestão dos dados;
2.3
Método criado por Sally Shlaer e Stephen Mellor em 
1988, que fornece um conjunto integrado de modelos de 
análise e que depois são traduzidos (Recursive Design) durante 
o projeto.
informação consiste em uma organização e uma representação 
conceitualização do domínio de um problema.
A técnica propõe uma forma de pensar de modo 
abstrato, problemas a resolver empregando conceitos do 
mundo real ao invés de conceitos de computadores. Trata-
para o desenvolvimento de software a uma escala industrial. É 
baseado no paradigma dos objetos, tendo sido desenvolvido 
no ambiente de projetos do mundo real. Estes projetos 
incluíam manufatura e aplicações de controle de processos, 
operações bancárias, telecomunicações, e aplicações de defesa 
governamental.
de software visualizando o problema sem recorrer de forma 
de modelos de análise orientados ao objeto, que podem ser 
Recursive Design (RD), que 
produz o desenho do sistema através da translação dos 
modelos de análise.
O Modelo de Informação, baseado no modelo relacional 
dos dados, se fundamenta em pensar acerca de problemas 
a resolver empregando modelos que estão organizados, 
informações numa estrutura formal. “Coisas”, ou exemplos 
como objetos, as características destas instâncias são resumidas 
como atributos 
são resumidas como relacionamentos. Os modelos de estado 
de dados mostram a sequência, podendo cada processo ser 
Este processo de sumarização requer que cada 
situação esteja sujeita e conforme as políticas ou as normas 
problema.
As regras e a formalidade permitem que os modelos 
sejam matematicamente transformados noutros tipos de 
dados pode ser transformada numa lista ligada,árvore, ou um 
conjunto de listas baseado em classes equivalentes.
O processo de construção dos modelos de análise OO é 
no modelo de informação de objetos, sendo depois descrito 
Em resumo, este método apresenta os seguintes 
benefícios:
• 
funcional do sistema, na fase de análise;
• aproximação integrada - O método providencia uma 
cobertura extensiva ao ciclo de vida com transições 
utilizando o Recursive Design;
• reutilização - Sistematiza e suporta a reutilização 
de todos os domínios, pois estes são tratados em 
transportados para outros sistemas;
• automação - Porque o processo é baseado na 
translação do modelo de análise, é altamente 
susceptível de automação;
2.4 Objectory
Os métodos OOSE e o Objectory foram desenvolvidos 
baseados no mesmo ponto de vista formado por Ivar 
155
Análise de Sistemas II 20
Jacobson. O método OOSE é a visão de Jacobson de um 
método orientado a objetos, já o Objectory é usado para a 
construção de sistemas tão diversos quanto forem.
Ambos os métodos são baseados na utilização de use-
um ator externo. O método Objectory também foi adaptado 
para a engenharia de negócios, na qual é usado para modelar 
e melhorar os processos envolvidos no funcionamento de 
empresas.
Esses métodos permitem, durante a análise, aprofundar o 
entendimento de como o sistema deve ser realmente utilizado. 
centrando-se na compreensão da forma como o sistema 
está e será utilizado antes de ser feita a alteração pretendida. 
Organizando a análise e o desenho através de sequências de 
interações com o utilizador e utilizando cenários, o método 
produz sistemas bastante robustos e amigáveis, adaptando as 
alterações de uma forma suave.
Este método divide o desenvolvimento em processos, 
que, diferentemente das fases de desenvolvimento tradicionais, 
podem ser iterados e sobrepostos. Estes processos produzem 
uma série de modelos interligados, facilitando posteriormente 
a junção dos mesmos através de uma modelagem consistente.
Para Jacobson, todos os sistemas se alteram durante o 
seu ciclo de vida, tendo a manutenção dos mesmos um peso 
muito grande em termos de custos de desenvolvimento. 
Muitos métodos de desenvolvimento adequam-se a novos 
desenvolvimentos, mas tratando as revisões do modelo 
de uma forma pouco adequada. Os desenvolvimentos 
iniciais devem ser vistos como uma atividade importante, 
a base do sistema.
O método é descrito como um conjunto de processos 
que interagem entre si durante o desenvolvimento do projeto, 
através de diferentes modelos. Os processos principais são a 
análise, construção e teste.
dos requisitos. Consiste num modelo orientado ao caso em 
estudo, com descrições da interface com o utilizador, e um 
modelo dos objetos do domínio. Este modelo é baseado 
nos conceitos de actors (atores) e use cases (casos de uso). 
que deve ser executado pelo sistema, respectivamente. 
Os actors podem ser pessoas ou máquinas. Cada um deles 
pode executar um número diferente de tarefas, bem como 
participar na operação do sistema. Executa uma sequência 
de transações em permanente diálogo com o sistema. A uma 
use case. Cada use case é 
use cases corresponde aos requisitos funcionais do sistema a 
construir.
o desenvolvimento do sistema passa para a construção do 
independentemente do ambiente de implementação 
selecionado. Embora possa ser utilizado o modelo de 
base para a implementação, isto não resulta numa estrutura 
robusta.
O modelo de análise representa uma estrutura mais 
estável e fácil manutenção. No processo de análise é criado 
um modelo Conceitual do sistema a construir. Nesta 
fase, os modelos são desenvolvidos de forma a facilitar a 
compreensão do sistema, privilegiando a comunicação com 
o cliente.
No processo de construção, é desenvolvido o sistema 
a partir dos modelos criados anteriormente. A construção 
inclui o desenho e a implementação, resultando um sistema 
completo.
O processo de teste integra os componentes do sistema, 
testando-o e decidindo se está pronto a ser distribuído ao 
cliente.
2.5
Vários são os métodos para modelagem de sistemas 
orientados a objetos (por exemplo, Rumbaugh, Booch, 
Wirfs-Brock, Coad, etc.), entre eles estão os métodos 
Fusion e OMT, porém alguns são muito menos abordados 
pelos autores de livros e artigos do meio. O método OMT 
possui um número maior de material disponível enquanto 
que o Fusion parece ser o método menos popular dentre 
os outros.
Métodos estruturados são limitados na descrição 
do comportamento dinâmico dos sistemas orientados a 
objetos.
A seguir, serão apresentadas algumas características 
importantes dos métodos citados e, em seguida, será 
mostrada uma abordagem comparativa entre esses métodos, 
fazendo uma análise do processo de desenvolvimento 
adotado em ambos os métodos, com uma visão técnica e 
operações.
2.6 Object Modelling 
Technique
É um método desenvolvido pela GE (General Electric) 
onde James Rumbaugh trabalhava e foi proposta por ele em 
1991, baseada na modelagem Entidades/Relacionamentos 
com extensão para o modelo de classes, herança e métodos. 
A técnica foi estendida para focalizar o projeto de banco de 
dados relacional.
Possuidor de uma grande variedade de conceitos, talvez 
o maior de todos, esta metodologia é composta de quatro 
fases: análise, projeto do sistema, projeto dos objetos e 
implementação, como mostra a Figura 3.1.
O método é especialmente voltado para o teste dos 
do sistema. O modelo total do sistema baseado no método 
OMT é composto pela junção dos modelos de objetos, 
funcional e use-cases.
A técnica OMT se distingue pela sua divisão em 4 fases:
2.6.1 - Análise
• 
156
21
• construir o modelo de objetos, com as suas sub-
atividades;
• desenvolver o modelo dinâmico, com as suas sub-
atividades;
• construir o modelo funcional, com as suas sub-
atividades;
• 
subatividades.
2.6.2
• organizar o sistema em subsistemas;
• 
• alocar os subsistemas aos processadores e tarefas;
• encontrar uma estratégia básica para implementar o 
armazenamento dos dados;
• determinar mecanismos para controlar o acesso aos 
recursos globais;
• escolher a natureza da implementação;
• manipular as condições de fronteira.
2.6.3
• obter operações do modelo funcional e dinâmico;
• desenhar os algoritmos que implementam as 
operações;
• otimizar os caminhos de acesso aos dados;
• ajustar a estrutura das classes de forma a permitir a 
herança entre as mesmas;
• desenhar a implementação das associações;
• determinar a representação exata dos atributos dos 
objetos;
• colocar as classes e associações em módulos.
2.6.4 - Implementação
• desenho da base de dados;
• escrita do código.
Como principais características, destacam-se a separação 
clara entre análise e projeto, a inclusão de todos os conceitos 
A fase de análise é composta por três modelos, os quais 
recomenda-se que sejam seguidos na ordem apresentada a 
seguir:
 - modelo de objetos;
 - modelo dinâmico;
 - modelo funcional.
O modelo de objetos descreve a estrutura estática do 
sistema, com as classes, os relacionamentos existentes entre 
as classes, os atributos e operações que caracterizam cada 
classe; como resultado, tem-se um diagrama Entidade/
Relacionamento estendido.
Figura 3.1. Visão geral de desenvolvimento do método OMT. Fonte: Acervo pessoal
O modelo dinâmico captura os aspectos temporais 
do modelo de objetos utilizando diagramas de máquina de 
estados.
A modelagem funcional descreve a transformação dos 
dados em termos de como os valores de saída são derivados 
dos valores de entrada, utilizando para isso os DFD.
2.7
A técnica Fusion (Fusão) corresponde a uma integração 
das técnicas OMT e de Booch, na qual os dois modelos de 
objeto e de interface visam a representar os aspectos estáticos 
e dinâmicos do problema.
O método Fusion 
sistema, fornecendo uma interface mais amigável com a 
documentação sobre o comportamento dinâmico dos objetos 
e tratamento completo a respeito do ciclo de vida associado 
ao desenvolvimento de software.
dos requisitose a implementação com o uso de uma 
linguagem de programação. O método Fusion é formado por 
uma sequência de etapas dentro de cada fase e os resultados 
de cada uma das fases são explicitamente enviados para uma 
alguns tipos de sistemas concorrentes.
O processo de desenvolvimento do método Fusion é 
dividido em análise, projeto e implementação.
sistema, produzindo modelos que descrevem os seguintes 
elementos;
 - classes de objetos existentes;
 - relacionamentos;
 - operações que podem ser executadas;
 - sequências disponíveis para as operações.
Na fase de projeto, o modelo de operações gerado 
modelos:
 - como as operações serão implementadas pelas 
157
Análise de Sistemas II 22
interações entre os objetos;
 - como as classes farão referências mútuas e como 
estarão relacionadas através da herança;
 - os atributos das classes e suas operações.
Na implementação, o projeto será transformado em 
 -
na forma de métodos pertencentes a uma classe 
selecionada;
 - as sequências permitidas para as operações são 
reconhecidas por máquinas de estado.
utilizando pré-condições e pós-condições (Figura 3.2). A pré-
condição caracteriza as condições sob as quais a operação 
poderá ser ativada. A pós-condição descreve como o estado 
do sistema será alterado pela operação, e quais os eventos que 
serão enviados aos agentes.
Alteração ocorrida
Figura 3.2. Operações do sistema
O modelo de operações é mostrado em forma de uma 
de cada ação:
 Abrir conta
 
 novo cliente
 
 
 
Figura 3.3. Exemplo de modelo de operações do método Fusion
2.8
O RUP ( ) é um framework genérico 
para processos de desenvolvimento de software, criado pela 
empresa Rational Software Corporation, que está fortemente 
centrado na arquitetura, funcionalidade (caso de uso) e o 
desenvolvimento iterativo e incremental (inspirado no ciclo 
de vida espiral de Boehm), que aplica a UML, para o projeto 
e a documentação.
O RUP é um processo de desenvolvimento de software e, 
como tal, descreve os papéis e as atividades que cada membro 
da equipe de projeto deve desempenhar ao longo do ciclo 
de desenvolvimento do software e os produtos que devem 
ser gerados como resultado destas atividades, os chamados 
artefatos.
O RUP usa a UML, que é uma notação consistente que 
pode ser aplicada tanto para a engenharia de sistemas quanto 
a engenharia de negócios.
Uma notação padrão serve aos seguintes papéis:
• serve como uma linguagem para comunicar decisões 
que não são óbvias ou que não podem ser deduzidas 
do próprio código.
• 
todas as decisões estratégicas e táticas importantes.
• 
pessoas raciocinem e para que as ferramentas sejam 
manipuladas.
2.9 - UML
UML ou 
métodos OMT, Booch e OOSE que está sendo submetido a 
OMG para a padronização.
A UML é uma linguagem de modelagem para documentar 
análise e desenho de um sistema. A UML é uma linguagem 
totalmente orientada a objetos, que une as melhores práticas 
e metodologias da Engenharia de Software. É considerada a 
sintaxe geral para criar um modelo lógico de um sistema. Ela 
é utilizada para descrever pontos de um sistema e da forma 
como ele é percebido de várias visões durante a análise e sua 
arquitetura. É uma linguagem que visa capturar conhecimento 
e expressar esse conhecimento.
Seu propósito é a modelagem de sistemas, documentar de 
maneira interativa e visual, proporcionar melhor compreensão 
e sinergia entre o analista e o cliente envolvido no processo de 
desenvolvimento.
A UML ( ) é uma tentativa de 
padronizar a modelagem orientada a objetos de uma forma 
que qualquer sistema, seja qual for o tipo, possa ser modelado 
corretamente, com consistência, fácil de se comunicar com 
outras aplicações, simples de ser atualizado e compreensível. 
Existem várias metodologias de modelagem orientada a 
objetos que até o surgimento da UML causavam muitas 
discussões entre a comunidade de desenvolvedores orientado 
trazendo as melhores ideias de cada uma destas metodologias. 
construção e documentação de sistemas, estabelecida pela 
OMG (Object Management Group).
uma linguagem de modelagem e não uma metodologia, ou 
seja, não tem noções do processo. Um método consiste de 
uma linguagem de modelagem e de um processo. A linguagem 
desenhar projetos.
O processo é o caminho de quais passos serão utilizados 
na elaboração de um projeto, ou seja, pode-se utilizar os 
permitindo que o desenvolvedor faça o seu próprio processo 
de acordo com as necessidades, em função do tipo de software 
a ser desenvolvido (tempo real, sistema de informações, 
produto desktop), o tamanho da equipe a ser envolvida, o nível 
de formalismo exigido e a facilidade de comunicação desejada, 
158
23
tipos de processos e em todo o ciclo de desenvolvimento de 
software.
A técnica UML será descrita mais detalhadamente mais 
adiante.
3 - Discussão sobre as metodologias
É muito difícil que uma comparação sistemática possa 
fazer justiça a ambos os métodos apresentados, Fusion e 
OMT. Muitos aspectos precisam ser analisados; o ideal seria 
os dois métodos e pela mesma equipe de trabalho. Entretanto, 
mostraremos algumas vantagens e desvantagens de cada um 
dos métodos em relação ao outro.
comum também em vários outros métodos, está no processo, 
considerado fraco na orientação dos integrantes da equipe de 
desenvolvimento pelas diversas fases do desenvolvimento do 
software. Porém, a fase de análise tem um processo muito bem 
inter-relacionamento.
O modelo de operações do método Fusion fornece 
uma base descritiva do sistema muito mais clara, deixando 
transparentes as entradas, saídas e alterações com a 
mas deixa a desejar na visão global do sistema.
No método OMT, o modelo funcional não é muito 
comportamentos em virtude dos DFD’s serem essencialmente 
operacionais. Já no modelo de objetos, é possível registrar 
uma grande quantidade de informações estruturais.
O OMT é afetado pelo projeto de Banco de Dados 
Relacional e muitos conceitos essenciais são introduzidos para 
muitos trabalhos. Nele se dá pouca ênfase aos relacionamentos 
existentes entre as funções a serem executadas por um sistema 
e como elas determinam as interfaces de classes.
As diferenças afetam o processo de desenvolvimento 
e em última análise, o próprio software desenvolvido. Aqui 
citamos algumas:
 - Deslocamento do esforço de desenvolvimento 
para a análise: Uma abordagem baseada em 
objetos concentra a maior parte do esforço de 
desenvolvimento do software na fase de análise do 
ciclo de vida. Esse esforço adicional é compensado 
pela implementação mais rápida e simples. Como 
o projeto resultante é mais limpo e adaptável, as 
 - Ênfase na estrutura de dados e não nas funções: A 
encapsulados que ocultam sua implementação 
 - Processo de desenvolvimento inteiriço: Não existem 
descontinuidades nas quais a notação de uma fase 
seja substituída por outra em outra fase;
 - Iterativo, não sequencial: Embora a descrição da 
OMT seja necessariamente linear, o processo real 
é iterativo. Cada iteração acrescenta ou esclarece 
feito, o conduz a menores possibilidades de erros e 
inconsistências.
No método Fusion, há uma grande facilidade no 
entendimento do modelo de operações por ser bem descritivo 
e detalhado, fornecendo até os resultados alcançados pelos 
muito pela modelagem funcional, que não considera a 
seqüência dos processos de valores ou as decisões.
Nenhum dos dois métodos apresentados pode ser 
de um sistema, haja vista que cada um possui características 
muito importantes para concepção do processo.
a critério da equipe de trabalho.
relacionamentos entre as classes é mais clara no método 
OMT, sem contar a facilidade de utilização, ou até migração, 
por parte dos projetistas por utilizar conceitos da modelagem 
estática, muito absorvida pela equipe de trabalho.
O método Fusion usa o dicionário de dados como um 
repositório central.
Retomando a aula
As técnicas existentes permitem e aprimoram a construção 
do modelo do sistema, para posterior inclusão de detalhes da 
implementação(programação). Várias são as metodologias 
existentes, cada uma delas com suas características, pontos 
fortes e fracos. É importante ler e aprimorar o conhecimento 
em cada uma delas para podermos entender de que forma 
cada uma pode ajudar no projeto do sistema.
Nesta seção, vimos características das técnicas de Booch, 
Coad/Yourdon, Shlaer/Mellor, OOSE/Objectory, OMT, 
Fusion, UML e RUP. Conhecemos pontos importantes de 
cada uma delas.
técnicas Fusion e OMT, apontando pontos fortes e fracos de 
cada uma delas.
159
Análise de Sistemas II 24
Vale a pena
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006. SOMMERVILLE, I. Engenharia 
de Software. 8ª Edição. Addison Wesley, 2007. BOOCH, 
Grady, JACOBSON, Ivar; RUMBAUGH, James. UML – 
guia do usuário. Elsevier, Rio de Janeiro. 2005.
pena ler
Minhas anotações
160
4ºAula
Análise orientada a objetos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• conhecer os modelos da análise orientada a objetos;
• entender os conceitos de associações entre os objetos.
Prezados (as) alunos (as),
Nesta aula 4 estudaremos sobre os modelos da Análise 
Orientada a Objetos.
Se ao final desta aula tiverem dúvidas, vocês poderão saná-
las através das ferramentas da plataforma de ensino.
Conto com a sua participação, aproveite para ler e refletir 
os objetivos de aprendizagem, afinal da sua participação 
dependerá seu aprendizado.
Bom Trabalho!
Bons estudos!
161
Análise de Sistemas II 26
Seções de estudo
1 – Modelos: Objeto, Dinâmico e Funcional
2 – Objetos e classes
3 – Ligações e associações
1
Funcional
modelagem da aplicação e do domínio no qual ela opera. Esta 
fase focaliza o quê necessita ser feito e não como deve ser feito. 
A etapa inicial da fase de análise consiste no estabelecimento 
dos requisitos do problema a ser resolvido, fornecendo uma 
visão conceitual do sistema proposto.
O diálogo subsequente com o usuário, o conhecimento 
da área e a experiência adquirida do mundo real são elementos 
adicionais que servem de entrada para a análise. A saída desta 
fase de análise é um modelo “formal” que captura os aspectos 
de controle e transformação funcional de dados.
Um modelo é uma abstração que tem como propósito 
entender um problema antes de solucioná-lo. A partir de 
modelos, é possível simular e testar sistemas antes de construí-
los, facilitar a comunicação com os usuários e os outros 
membros da equipe de desenvolvimento, visualizar e reduzir 
a complexidade dos problemas a tratar.
No caso da metodologia OMT, obtém-se os modelos 
objeto, dinâmico e funcional.
1.1
O Modelo Objeto serve para representar os aspectos 
estáticos, estruturais, de “dados” de um sistema.
O modelo objeto descreve a estrutura de objetos no 
sistema: sua identidade, suas relações com os outros objetos, 
seus atributos e suas operações. Este modelo tenta capturar 
a estrutura estática dos componentes do mundo real que se 
pretende representar. O modelo objeto tem uma representação 
com seus atributos e operações, e organizados segundo 
hierarquias e associações com os diagramas de outras classes.
Para construir o modelo objeto, é necessário seguir os 
seguintes passos:
• 
• preparar um dicionário de dados;
• 
objetos;
• 
• 
herança;
• 
• 
• agrupar as classes em módulos.
1.2 - Modelo Dinâmico
O Modelo Dinâmico serve para representar os aspectos 
temporal, comportamental e de “controle” de um sistema.
Para construir o modelo dinâmico, é necessário seguir os 
seguintes passos:
• reparar cenários de sequências de interação típicas;
• 
• preparar um rastro de eventos para cada cenário;
• construir um diagrama de estados;
• 
consistência.
1.3 - Modelo Funcional
O Modelo Funcional serve para representar os aspectos 
transformacionais e de “função” de um sistema.
Para construir o modelo funcional, é necessário seguir os 
seguintes passos:
• 
• construir um DFD mostrando dependências 
funcionais;
• descrever funções;
• 
entre objetos;
• 
2
Todos os objetos têm uma identidade e são distinguíveis. 
Eles são instâncias (ocorrências) de classes de objetos que 
descrevem grupos de objetos com similaridade nas 
propriedades (atributos), comportamento (operações ou 
métodos), relações com os outros objetos e semântica.
Figura 4.1. Representação de uma classe. Fonte: Acervo pessoal
Figura 4.2. Representação de classe e objetos. Fonte: Acervo pessoal
162
27
relações é composta de dois tipos de diagramas mostrados na 
• um , que representa classes 
de objetos e tem a função de ser um esquema, um 
padrão ou um “template” para os dados;
• um , utilizado para 
representar instâncias de classes e tem o objetivo de 
descrever como um conjunto particular de objetos 
se relaciona com outro.
O atributo é colocado na segunda parte da caixa, como 
por detalhes opcionais tais como tipo (precedido por “:”) e 
de objeto não são necessários no modelo objeto, pois cada 
objeto já tem a sua própria identidade (a partir de seus valores).
Figura 4.3. Ilustração de Classes e Objetos. Fonte: Acervo pessoal
Figura 4.4. Ilustração de Atributos e Valores. Fonte: Acervo pessoal
Uma operação pode ser aplicada a ou por objetos numa 
classe. A mesma operação pode se aplicar a várias classes 
métodos em várias classes, eles devem ter a mesma assinatura 
(em número e tipos de argumentos). As operações se 
4.5. Cada operação pode ser seguida de detalhes opcionais 
tais como lista de argumentos (colocada entre parênteses após 
o nome, separados por “,” ) e tipo de resultado (precedido 
por “:”). A notação generalizada para classes de objetos se 
Figura 4.5. Operações com Objetos. Fonte: Acervo pessoal
Figura 4.6. Generalização da notação de modelagem de objetos. Fonte: Acervo 
pessoal
3 - Ligações e associações
A ou link é uma conexão física ou conceitual 
entre instâncias de objetos. Por exemplo: Marco Aurélio 
Freitas Santos UNIGRAN. Uma ligação é 
uma túpla correspondente a uma lista ordenada de instâncias 
de objetos. Uma ligação é uma instância de uma associação 
(relacionamento).
Figura 4.7. Exemplo de associação. Fonte: Acervo pessoal
Uma associação descreve um grupo de ligações com 
estrutura e semântica comuns. Por exemplo: uma pessoa 
uma instituição. Todas as ligações de uma 
associação conectam objetos das mesmas classes. O 
base de dados.
Associações e ligações são descritas por verbos. 
Associações são inerentemente bidirecionais e podem ser lidas 
nos dois sentidos. Por exemplo: num primeiro sentido pode-se 
ler: Marco Aurélio Freitas Santos UNIGRAN 
e no sentido inverso, UNIGRAN Marco Aurélio 
Freitas Santos. Associações são muitas vezes implementadas 
em linguagens de programação como apontadores (atributo 
de um objeto que contém referência explícita a outro) de um 
objeto para outro. Por exemplo: objeto Pessoa pode conter 
atributo empregado que aponta para um conjunto de objetos 
Instituição.
Uma ligação mostra a relação entre dois ou mais objetos. 
correspondentes. Observa-se, nesta notação, que a associação 
corresponde a uma linha entre classes e que os nomes de 
associação aparecem em itálico.
Figura 4.8. Associação um-para-um e links. Fonte: Acervo pessoal
163
Análise de Sistemas II 28
As associações (relacionamentos) podem ser binárias, 
ternárias ou de ordem maior. De fato, a maior parte é 
será comentado a seguir). A simbologia OMT para ternária 
ou n-ário é um losango com linhas conectando as classes 
relacionadas. O nome da associação é escrito dentre do 
losango; entretanto, os nomes de associação são opcionais. A 
Figura 4.9. Associação ternária e links. Fonte: Acervo pessoal
A 
uma classe podem se relacionar a uma única instância 
de classe associada. Esse conceito é também conhecido 
como cardinalidade de relacionamento. A multiplicidade 
restringe o número de objetos relacionados. A multiplicidade 
problema. Requisitos vagos tornam a multiplicidade incerta. 
Não é possível determinar muito cedo a multiplicidade no 
processo de desenvolvimento de software;num primeiro 
tempo, determinam-se objetos, classes, ligações e associações 
e depois se decide a respeito de multiplicidade. A distinção 
mais importante é entre “um” e “vários”; entretanto existem 
símbolos especiais para “exatamente um”, “um ou mais”, 
“intervalos”, “”zero ou mais”, “zero ou um”, conforme 
Figura 4.10. Notação para associações múltiplas. Fonte: Acervo pessoal
3.1 - Ligações e associações 
avançadas
3.1.1 - Associação Recursiva
É possível conectar uma classe a ela mesma através de 
uma associação e que ainda representa semanticamente a 
conexão entre dois objetos, mas os objetos conectados são 
da mesma classe. Uma associação deste tipo é chamada de 
associação recursiva.
Figura 4.11. Exemplo de uma associação recursiva. Fonte: Acervo pessoal
3.1.2 - Atributo de ligação
É similar ao caso da classe, onde um atributo é uma 
propriedade dos objetos desta, um atributo de ligação é uma 
apresenta o caso onde permissão-de-acesso é um atributo da 
associação Acessível-por. Cada atributo de ligação tem um valor 
É ainda possível ter atributos de ligações para associações 
ligações ternárias. Apesar de poder substituir os atributos de 
ligação por atributos de objetos da associação, é preferível 
manter atributos de ligação.
Figura 4.12. Atributo de ligação para associação “muitos-para-muitos”. Fonte: 
Acervo pessoal
Figura 4.13. Atributos de ligação para associação um para vários (papéis). Fonte: 
Acervo pessoal
3.1.3 - Modelagem de associação 
como classe
Às vezes, é útil modelar uma associação como classe. 
mostra um exemplo disto. Essa opção é particularmente útil 
quando ligações podem participar em associações com outros 
objetos ou quando ligações são sujeitas a operações.
Figura 4.14. Modelando uma associação como Classe. Fonte: Acervo pessoal
164
29
3.1.4
As associações entre objetos podem ter uma ordem 
implícita. O padrão para uma associação é desordenado (ou 
associação pode ser muito útil em casos como este: janelas de 
um sistema têm que ser ordenadas na tela (uma está no topo, 
uma está no fundo e assim por diante). A associação ordenada 
de associação entre as duas classes.
3.1.5
especial que reduz a multiplicidade efetiva de uma associação, 
distinguindo objetos dentro do conjunto na extremidade 
com associações de um para vários (1..*) ou vários para vários 
3.1.6 - Agregação
A agregação é uma relação “parte-todo” ou “uma-parte-
de” na qual os objetos representando os componentes de 
algo são associados com um objeto representando a junção 
deles (“assembly”). Algumas propriedades da classe junção 
classe junção e uma classe componente. A agregação é 
então uma forma especial de associação. A simbologia da 
agregação é similar a da associação (linha), exceto pelo fato 
de um pequeno losango indicar o lado da junção da relação, 
Figura 4.16. Agregação. Fonte: Acervo pessoal
3.1.7
Generalizações e herança são abstrações poderosas que 
permitem compartilhar similaridades entre as classes, apesar 
de preservar suas diferenças.
é uma relação do tipo “é um” entre uma 
Por exemplo, numa farmácia, a classe PRODUTOS é uma 
superclasse de MEDICAMENTOS e PERFUMARIA. 
Atributos e operações comuns a um grupo de subclasses 
são reagrupados na superclasse e compartilhados por cada 
subclasse. Diz-se que cada subclasse herda as características 
de sua superclasse.
A notação para a generalização é um triângulo conectando 
4.17. As palavras próximas ao triângulo no diagrama são 
discriminadores (atributos de um tipo enumeração que indica 
qual propriedade de um objeto está sendo abstraído por uma 
relação de generalização particular). Os discriminadores estão 
relacionados em correspondência um-a-um com as subclasses 
da generalização.
165
Análise de Sistemas II 30
É possível relação de herança em vários níveis. A herança 
em 2 ou 3 níveis (até 5 em alguns casos) de profundidade é 
aceitável; já a mais de 10 níveis é excessiva.
A generalização facilita a modelagem a partir de classes 
estruturadas e da captura do que é similar e do que é diferente 
nas classes. A herança de operação é de grande ajuda durante 
a implementação para facilitar a reutilização de código.
entre classes, enquanto a herança diz respeito ao mecanismo 
de compartilhar atributos e operações usando a relação de 
generalização. Generalização e especialização são dois pontos 
de vista da mesma relação, no primeiro caso vista a partir da 
superclasse e no segundo da subclasse: a superclasse generaliza 
3.1.8
Um módulo é uma construção lógica para reagrupar 
classes, associações e generalizações. Um módulo captura 
uma perspectiva ou uma vista de uma situação, como no caso 
de um , existem várias visões correspondentes a 
, , . Um modelo objeto 
consiste de um ou vários módulos. A noção de módulo força 
a particionar um modelo objeto em peças gerenciáveis. Uma 
mesma classe pode ser referenciada em módulos diferentes. 
De fato, referenciando a mesma classe em múltiplos módulos 
é o mecanismo para interligar módulos entre si.
Retomando a aula
Na primeira seção, vimos que o modelo Objeto descreve 
a estrutura de objetos no sistema: sua identidade, suas relações 
com os outros objetos, seus atributos e suas operações. 
O modelo Dinâmico serve para representar os aspectos 
temporal, comportamental e de “controle” de um sistema. 
O modelo Funcional serve para representar os aspectos 
transformacionais e de “função” de um sistema.
Um , que representa classes de 
objetos e tem a função de ser um esquema, um padrão ou um 
“template” para os dados.
Um , utilizado para representar 
instâncias de classes e tem o objetivo de descrever como um 
conjunto particular de objetos se relaciona com outro.
A ou link é uma conexão física ou conceitual 
entre instâncias de objetos. Uma associação recursiva é 
quando uma classe se conecta a ela mesma através de uma 
associação entre dois objetos desta mesma classe.
Vale a pena
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006. SOMMERVILLE, I. Engenharia 
de Software. 8ª Edição. Addison Wesley, 2007.
pena ler
Minhas anotações
166
5ºAula
Modelagem dinâmica
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• entender os conceitos de estados e eventos;
• diferenciar atividades e ações;
• compreender o diagrama de estados.
Prezados (as) alunos (as),
Nesta aula 5 veremos as características dos modelos 
dinâmico e funcional.
Se ao final desta aula tiverem dúvidas, vocês poderão saná-
las através das ferramentas da plataforma de ensino.
Conto com a sua participação, aproveite para ler e refletir 
os objetivos de aprendizagem, afinal da sua participação 
dependerá seu aprendizado.
Bom Trabalho!
Bons estudos!
167
Análise de Sistemas II 32
Seções de estudo
1 – O modelo Dinâmico
2 – O modelo Funcional
3 – Comparações entre modelos
1
O modelo dinâmico descreve os aspectos do sistema que 
Esse modelo tenta capturar o controle, aspecto de um sistema 
que descreve as sequências de operação que ocorrem em 
resposta a estímulos externos, sem levar em conta o que as 
operações fazem, quem as ativa e como são implementadas. 
Os conceitos utilizados nesta modelagem dinâmica são os de 
eventos que representam os estímulos externos e de estados 
que representam os valores de objetos.
representa os estados e a sequência de eventos permitidos 
num sistema para uma classe de objetos. Os estados e 
eventos podem ainda ser organizados de forma hierárquica e 
representados num diagrama de estados estruturados.
1.1 - Eventos e estados
Um é caracterizado pelos valores dos atributos 
e pelas ligações mantidas por um objeto. Um 
corresponde a um estímulo individual de um objeto a outro. 
O representa o modelo de eventos, 
estados e transições de estado para uma classe dada. O modelo 
consiste de vários diagramas de estados, um para 
cada classe com comportamento dinâmico importante; ele 
mostra o modelo de atividade para um sistema completo. 
Cada máquina de estados se executa de forma concorrente